Responds to the independent review of the writer-branch PR.
Adopted (the reviewer's strongest recommendation): a test that PROVES master is
protected, rather than documenting the setting. It attempts a direct push to
master with the deploy key and requires it to be rejected - the same way an
attacker would find out. It currently FAILS, which is the correct result: branch
protection is genuinely not enabled on armistace/blog, and the failure is now
visible in every test run instead of buried in prose.
Cannot fix from here: setting branch protection on armistace/blog returns
403 "user should be an owner or a collaborator with admin write"
for the bot account (it is a collaborator, not the owner). This is an operator
action, documented in docs/writer-branch-workflow.md with the exact Gitea
settings. Until it is done the writer-branch model is advisory, not enforced.
Also fixed three assertions that were stale rather than wrong:
- "installer markers present" now accepts the post-install state (config.php
populated) as valid, since the operator has completed the installer.
- "posts found == 20" is now ">= 20" - the operator has added a file, so an
exact count was always going to fail.
- "branch == master" is now master|atheos-writer - the writer branch is the
intended steady state under the new workflow, so asserting master was
asserting the opposite of the design.
Result: 40 passed, 1 failed - the single failure being the branch-protection gap.
Provisions a LAN-only browser code editor (Atheos) in an Alpine 3.23 LXC on the
scotty PVE node, with armistace/blog cloned and ready to edit. Built via the
AI-DLC workflow; the full process trail is in aidlc-docs/.
Deliverables
- scripts/provision.sh rebuild the guest from scratch (re-runnable)
- scripts/update-atheos.sh move Atheos to latest upstream and RE-PIN
- scripts/build-and-test.sh captures evidence for every acceptance criterion
- files/atheos.conf nginx vhost (socket path byte-matches the FPM pool)
- files/ssh-config ~atheos/.ssh/config deploy-key alias
- RUNBOOK.md operational guide (START AT STEP 1)
- docs/security-notes.md credential model + wider-web hardening TODOs
- docs/resiliency-notes.md what a non-PoC deployment would need
Design decisions
- D1 no git identity is configured by the agent; the operator sets it. Git will
refuse the first commit until then, which is deliberate (requirement FR-11).
- D2 Atheos pinned to commit f90cd18 (build 611) with a verified tarball sha256,
plus update-atheos.sh as the deliberate escape hatch.
- D3 nginx :80, web root /var/www/atheos, php-fpm over a unix socket.
- D6 git auth is a per-repository DEPLOY KEY scoped to armistace/blog, not a
personal access token (a PAT's write:repository scope reaches every repo the
account can write).
Verified on the live guest (40 checks, 0 failures)
- AC-2 Atheos served over HTTP 200 by nginx+php-fpm; socket paths byte-match
- AC-3 20 posts + themes/cleanblog present; owned by the php-fpm user
- AC-4 all five writable paths writable as the service user
- AC-5 remote targets armistace/blog; deploy key authenticates over SSH
- AC-6 survival proven with a real container restart, marker byte-identical
- AC-8 no python/pelican/pip/make and no DB engine - scope boundary enforced
- FR-11 git identity is empty; deploy key mode 600 owned by the service user
Traps documented in the RUNBOOK (each cost real debugging time)
- The Gitea SSH user is `gitea`, NOT `git` (app.ini SSH_USER=gitea). With `git`,
sshd answers "Invalid user git" and rejects before reading authorized_keys,
which is indistinguishable from a bad key.
- The Gitea SSH endpoint is the LAN address (:22 is not forwarded publicly).
- `uptime` and `free` report the PVE HOST inside an LXC without lxcfs, so a
container that just restarted can claim days of uptime.
hermes