Registers and evidence for the campaign and its fix pass.
OPEN-ITEMS: R-214..R-223. Six SHIPPED (R-215/216/217/218/219/222); three deliberately
still open and each blocks a real flow (R-214 console banner, R-220 drives unenrollable
after a rebuild, R-221 a rebuilt box cannot run the escrow ceremony); R-223 minted and
WAITING-ON-OPERATOR (vouch agent 0.125.0). R-213 and R-202 untouched.
Capability map: a new row for the customer's UNAIDED journey, recorded FAILED and staying
failed until a re-walk passes — fixes are not a journey. The existing rebuild row is
corrected where it said R-198's retention was unit-proven only: it was proven in production
on the first supersession since the fix, identity_blob retained at 572 B byte-length exact.
CLAUDE.md comment-vs-code table: eighth entry — ResolveManagedFloor, the first where the
false invariant was a GUARD rather than a comment alone.
STATUS: the headline is now "the backup promise is proved, the recovery journey is not",
and the one thing waiting on the operator.
Syncs documentation/runbooks/workspace-CLAUDE.md with the workspace root file.
Row 7: the B2 refusal claimed the previous unit was untouched; nothing-deleted
held, untouched was measured false.
Also records WHY it survived review: it passed a full green suite AND three of
its own red-proofs, because every one of them asserted the mechanism inside
captureAllRecoveryUnits and none asserted the consequence across the whole
backup run. The test that would have caught it is the one the fix ships —
fingerprint the tree before and after, and compare.
Follow-up acting on the observations filed with runbooks/target-selection.md.
operations/nodes.md
- The demo-hp NVMe was documented "PRESENT AND UNENROLLED -- do not touch" and
listed under "What is NOT enrolled here (deliberately)". Both are FALSE and had
been for eight days: it was enrolled 2026-07-22 through the normal Tarhely flow
and is now /mnt/nvme-1tb -- the enrolled user-data drive AND the felhom-backup
target (verified live 2026-07-30: nvme0n1 -> /mnt/nvme-1tb, and
dir: felhom-backup / path /mnt/nvme-1tb / is_mountpoint 1). The fence's own
condition (join via Tarhely, not the installer, not by hand) was SATISFIED, so
the prohibition expired with it -- while still contradicting the task specs that
correctly sent drill-VM disks there. Retracted with its reason recorded, and the
caution that IS still live kept (dir storage at the mountpoint ROOT, else
exactMount fails and the storage reads disconnected forever).
- Component versions REMOVED and a note explains why: agent/controller/hub versions
change several times a day, so a number written in an inventory is wrong within
hours and then read as fact -- and the fleet is not uniform (on 2026-07-30 the two
boxes ran different agent AND different controller versions). Points at the
authorities instead: hub /hosts + /configs, felhom-agent --version, docker ps.
- Site addresses now say re-check rather than asserting one (the N100 read .162, not
the recorded .147); records that LAN literals are unreachable from DooPlex while
the boxes are away. Adds the target-selection pointer: this page is what the
hardware IS, that page is what may be done to it.
PROMPT-TEMPLATE.md -- the upstream generator of the defect
- Section 12's "Do NOT touch [the untouchable]" asked the spec author to name a
THING. Now asks for the forbidden ACT plus its REASON, with the demo-hp case as
the worked example of how a bare object-fence over-reads.
- Section 13 gains the positive counterpart, which was the actual gap: if a task
needs a machine to break, NAME IT. Listing only what is off-limits leaves the
most valuable unfenced machine as the residual choice.
runbooks/workspace-CLAUDE.md (+ the untracked root copy re-synced, verified identical)
- Host table gains a Blast radius column and the missing demo-hp row, notes felhotest
as Connection refused, and points at target-selection.md. This is the file that
loads FIRST every session, so leaving it with the old table would have undercut
the whole fix.
No code, no build, no deploy, no host reconfigured or renamed.
isStale counted from last_run, written unconditionally on failure, so a nightly-failing
tier read as fresh forever. Now anchored on last_success with an explicit legacy degrade
(logged once) and the never-ran branch untouched. emitStale states the real reason.
Both marked SHIPPED + PROVEN-LIVE in OPEN-ITEMS and the campaign doc. All three
of Campaign 8's alarm findings are now closed (F-CRIT-1, F-CRIT-2, F-A1).
Adds the standing rule earned by this arc to the versioned workspace CLAUDE.md:
a comment asserting an invariant needs a test pinning it, or it is a wish — with
all six shipped-false-guarantee instances catalogued, and the corollary that a
test should assert the CONSEQUENCE (does the alarm fire?) not the MECHANISM
(does suppression expire?).
R-88b closed (agent v0.105.0 + controller v0.178.0) — age_state gives 'unknown'
its own representation, with empty meaning legacy rather than unknown so the
first-backup valve keeps working on un-upgraded boxes.
R-97 note updated: hub v0.79.0 (R-97c) replaced a FALSE operator-only comment
with a real register — the comment claimed a guarantee the code did not provide.
Standing rule 4 (R-96): a recommendation that is not followed gets one line
saying why. Added to the live CLAUDE.md and this versioned copy — the live file
is not in a git repo, so committing to it alone would leave the rule as durable
as the chat it came from.
READY re-ranked: R-95 now leads.
The workspace root /mnt/5_hdd/felhom.eu/git/CLAUDE.md is NOT a git repo — this is
its only version-controlled copy, and it had drifted since 2026-07-19. Committing
the three standing rules to the live file alone would have left them exactly as
undurable as the chat log they came from, which is the whole point of R-96.
admin