hermes
a6fb61d0ea
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.
33 lines
1.5 KiB
Markdown
33 lines
1.5 KiB
Markdown
# Unit of Work Plan — atheos-blog-lxc
|
|
|
|
**Stage**: INCEPTION — Units Generation (Part 1: Planning)
|
|
**Date**: 2026-09-29 · **Depth**: minimal
|
|
|
|
## Rationale
|
|
|
|
The unit boundaries were already surfaced in the approved execution plan and the operator approved
|
|
them ("continue looks good"). The decomposition is not genuinely in question — it follows the
|
|
component dependency chain directly. So this plan carries **no open questions**; asking any would be
|
|
ceremony. It is recorded here so the generation step is traceable rather than improvised.
|
|
|
|
## Decomposition principle
|
|
|
|
Units follow the **topological order of the dependency graph** — each unit ends in a state you can
|
|
verify, and no unit depends on a later one. This matters because a failure in U3 (the genuinely
|
|
uncertain one, Atheos-on-Alpine) must not leave U1/U2 work wasted or unverifiable.
|
|
|
|
## Plan
|
|
|
|
- [ ] Generate `unit-of-work.md` — unit definitions + responsibilities
|
|
- [ ] Generate `unit-of-work-dependency.md` — dependency matrix + build order
|
|
- [ ] Generate `requirement-to-unit-map.md` — **substitutes `unit-of-work-story-map.md`** (stories were skipped); every FR/NFR/AC assigned to exactly one unit
|
|
- [ ] Validate unit boundaries and dependencies
|
|
- [ ] Verify no requirement is unassigned
|
|
|
|
## Approval
|
|
|
|
Units were presented in the approved execution plan; the operator's "continue looks good" covers
|
|
this decomposition. No blocking questions.
|
|
|
|
`[Answer]:` *(leave blank — approval recorded from the execution-plan gate)*
|