memory: snapshot — althing v3 fleet-wide at 3.1.1, sec on GPU0

The in-flight section was a day stale: it still described run 3c as the
live subject on a box where nothing had moved. Rewritten around what is
actually true now -- v3 deployed fleet-wide, the post office relocated
to nh3-docker, sec serving on GPU0, run 3c still held on power.

Six new decision entries, three of which carry findings that outlive
their incident: the inbound half of the handle-resolution bug (a stale
ALTHING_HANDLE reads another agent's mailbox and reports it empty,
which is a second route into the failure v3 exists to prevent), the OOM
attribution to Claude Code sessions, and the operator's two explicit
belays recorded so a later session does not re-raise them as new.

Auto-archival fired at 301 lines and moved exactly one entry. Three
others were old enough and every one carries a still-open deferred
pointer -- the parked CI flip, muninn-gate's submit path, and the triton
backend deferred to the Ada refresh. Held back per the guards; an
over-cap file that keeps live decisions beats a scannable one that lost
them. The entry that did move had its deferred item closed today:
nh3-extdev's staged v2.1.2 wheel is moot now that the box runs 3.1.1.

persistent-memory.d/2026-08-28-althing-v3-cutover.md

@@ -148,3 +148,71 @@ re-verified end to end.
 means repeating that by hand. The fleet pattern (skaldsong, soong-lab) is a gitea registry pull;
 this should join it. The old nh3-dev volume is left in place untouched — not a rollback path
 (the operator ruled that out), just not deleting the only other copy on the day of the move.
+
+---
+
+## `[2026-08-28, later]` The release train: 3.0.1 → 3.1.1 in one afternoon, and the registry
+
+Six releases landed the same day as the cutover. **The container was touched exactly once** (the
+nh3-docker move); every other release was herald- or client-side, established each time by
+forseti's **import-graph argument** — asking what `althing/post_office/*` IMPORTS rather than
+reading the diff. A diff tells you what moved; an import graph tells you what can be affected.
+
+    3.0.1  pane routes (a pane agent can register its own route)
+    3.0.2  the docs are now checked against the CLI, not against each other  — NO redeploy
+    3.0.3  PANE_SETTLE_S=0.3, the write/submit race
+    3.1.0  herald writes $ALTHING_ROOT/post-office; dev-launch reads it  — BOTH binaries
+    3.1.1  warn when ALTHING_HANDLE disagrees with launch-history
+
+**Deploy recipe per release:** `uv build --wheel` on nh3-dev → `uv tool install --force .`
+locally → stage the wheel to nh3-extdev and install under `UV_TOOL_DIR=/opt/uv-tools` with
+`/home/infra-ops/.local/bin/uv` → restart both `althing-po-herald` units.
+`playbooks/nh3-extdev-althing-v3.yaml` does the extdev half.
+
+## ⚠ THE REPEATED DEFECT — a verify that half-passes, four costumes in one day
+
+Every one of these was written correctly for its first run and silently wrong on the next:
+
+    1. install step gated on `postbox` not existing   -> right for the cutover, would SKIP
+                                                          every release after and report success
+    2. content check pinned to the PREVIOUS release's markers -> passes forever, asserts nothing
+    3. ONE file:marker pair against a TWO-file release  -> asserts half a release
+    4. a Go template `{{ }}` inside elway, whose own substitution ate it -> FAILED on a green deploy
+
+**The check now matches on PRESENCE (`grep -q`), never a count**, and takes a LIST of
+`file:marker` pairs bumped per release. 3.1.1's own release note said
+`grep -c handles_launched_at dev_launch.py # 2+`; the real count there is 1 (the definition,
+with 2 in postbox.py), so a count assertion would have reported FAILED on a byte-perfect install.
+
+## The registry, and why the namespace is `claude-bot`
+
+    gitea.phasefinal.com/claude-bot/althing-post-office:3.0.0@sha256:410fed41...
+
+Digest-pinned, not tag-floating — a tag is a mutable pointer on a registry anyone can re-push and
+this container is the whole bus. ⚠ **claude-bot's token carries `write:package` and `docker
+login` SUCCEEDS, but package namespaces are owned**: pushing to `vh/` returns
+`unauthorized: authentication required` AFTER a successful login — an ownership refusal wearing a
+credential error's clothes. Publishing under claude-bot's own namespace also satisfies the
+standing directive to stop reusing the operator's personal credentials.
+
+## The deployed CC plugin copies are a release step NOBODY owns
+
+`sync_skill.sh` covers the SKILL, not the plugin. Nothing in the repo reaches
+`~/.local/share/althing-plugin/` or `~/.claude/plugins/cache/althing/althing/0.0.1/`. Both must be
+`rsync -a --delete`'d from the repo's `plugin/` **on every release**, by hand, or they carry the
+previous release's bugs into the live surface — which happened: forseti's new docs-vs-CLI check
+found `postbox reply --to` twice in `plugin/commands/inbox.md`, **the file a CC session reads
+every time it drains its inbox**, and both my deployed copies had it.
+
+⚠ **A running CC session keeps the plugin text it loaded at startup.** Files being right is
+necessary and not sufficient — the session has to restart. I synced the copies at 09:30 and was
+handed the v2 `/althing:monitor` text an hour later, calling three deleted binaries.
+
+## Peer skill copies: I stopped hand-syncing, deliberately
+
+I wrote into eitri/dvalin/bil's repos three times (operator-authorised, and right while they were
+dark and could not pull). **Once they were awake and pulling, it became a race I was losing** —
+canonical moved three times in an hour and I was chasing a one-line version-banner lag. It also
+cost provenance: dvalin had to correct their own account of their file because my write looked
+like a pre-existing partial. Two writers, no lock. `sync_skill.sh` deliberately does not write
+into peer trees; althing owns canonical and peers pull. Respect that boundary once they can.