feat: self-hosted Wiki.js for this repository, no login

[PhilippTheServer]

Closes #3

docker compose up -d      # → http://localhost:3000

Wiki.js 2.5 + PostgreSQL, serving this repository's pages, readable immediately with no
login. One command from a fresh clone — no setup wizard, no account creation.

Why a bootstrap container

Wiki.js needs three manual steps before it shows a single page: a browser setup wizard, an
admin account, and a storage target configured in the admin UI. That is exactly the
friction this issue is about, so wikijs/bootstrap.py does them over Wiki.js's own APIs —
POST /finalize for the wizard, then GraphQL for the rest.

It runs once and exits. Re-running only refreshes content and repairs configuration that
has drifted, so it doubles as the reload command.

Design notes

Your checkout is mounted read-only. The Local File System target is a push target —
left enabled it would try to write edits back out. Bootstrap enables it, imports, then
disables it again, so Wiki.js never writes into anyone's working tree.

README is dropped after import. It documents the repository, not the project, so it
does not belong in the published page list.

An admin account exists because Wiki.js requires one, but nothing asks you to use it.
Credentials are in the README; this is a local stack on a throwaway database.

WIKI_PORT overrides the port, since 3000 is commonly taken.

Verification

tools/check_wikijs.py fails when a page is missing, returns a non-200, or bounces an
anonymous visitor to a login screen. CI runs it against a real stack (docker compose up,
bootstrap in the foreground so a failure surfaces there, then the check).

From a clean slate — docker compose down -v then docker compose up -d:

$ docker inspect -f '{{.State.ExitCode}}' opentaberna-wiki-bootstrap-1
0

$ docker compose logs bootstrap
[bootstrap] waiting for http://wiki:3000
[bootstrap] Wiki.js is responding
[bootstrap] running the setup wizard
[bootstrap] setup complete, waiting for Wiki.js to restart
[bootstrap] signed in
[bootstrap] site configured
[bootstrap] importing pages from /wiki-content
[bootstrap] import complete
[bootstrap] removed non-wiki page: README
[bootstrap] guests can read without signing in
[bootstrap] 8 pages available:
[bootstrap]     /API/Architecture  —  API Architecture
[bootstrap]     /Authorization  —  Authorization
[bootstrap]     /Configuration  —  Configuration
[bootstrap]     /Database/Architecture  —  Database Architecture
[bootstrap]     /Deployment  —  Production Deployment
[bootstrap]     /Getting-Started  —  Getting Started
[bootstrap]     /Orders-and-Fulfillment  —  Orders and Fulfillment
[bootstrap]     /home  —  OpenTaberna
[bootstrap] ready — open the wiki, no login required

$ python3 tools/check_wikijs.py
Checked 8 pages against http://localhost:3030.
OK — every page is served, and no page asks for a login.

The check bites. With guest read revoked through the admin API, every page fails:

$ python3 tools/check_wikijs.py
Checked 8 pages against http://localhost:3030.

8 problem(s):

  FAIL  /API/Architecture: HTTP 403
  FAIL  /Authorization: HTTP 403
  FAIL  /Configuration: HTTP 403
  FAIL  /Database/Architecture: HTTP 403
  FAIL  /Deployment: HTTP 403
  FAIL  /Getting-Started: HTTP 403
  FAIL  /Orders-and-Fulfillment: HTTP 403
  FAIL  /home: HTTP 302 — redirected away, guests cannot read it

Re-running bootstrap restored it ([bootstrap] granting guests read access) and the check
went green again — which is also the idempotency evidence.

One thing worth flagging

My first version of this check passed /home in that locked-down run. Wiki.js answers an
unauthorised guest with a 302 to /login, urllib followed it, and the login page returns
200 carrying the site title — so the title assertion matched and a fully locked-down wiki
looked fine. The check now refuses to follow redirects and treats a 3xx as the failure it
is. Without that it would have been a check that could not fail for the reason it exists.

Verified on Wiki.js 2.5.314 (ghcr.io/requarks/wiki:2.5). CI has not run on this branch
yet.