REPORT.md carries the deployed sentence quoted from the RUNNING binary (kubectl cp + byte grep, both controls), the stopping line as it reads in all three places, the enumerated deferred set, the two provider questions, the register census, and the ArgoCD verification. R-437 filed: the register compression sweep is OWED and was deliberately not run here. Measured first — 12 of 181 rows / ~25 KB of 316 KB (about 7%) carry a closed leading verdict — so it buys little and touches everything, and it is the exact operation that misfiled seven rows in August (R-378; the seventh, R-87, sat wrong for nine days, R-405). The row carries the scope so it can be picked up cold. The live alarm trigger was NOT run and the report says so in its own section rather than substituting quietly: this alarm only fires on a real fall in a real customer's snapshot count, so firing it means either deleting real backups or POSTing a falsified report claiming demo-hp lost its own. That would write a fabricated point into a customer's report history, move its latch and baseline, and mail the operator a second alarm about a real box hours after the first one already confused him. Covered instead by the deployed-bytes proof plus three red-proofed tests driving saveReport -> Check -> notify. What remains unproven is named: that the dispatcher delivers THIS wording to a mailbox. Register 688 -> 700 lines; 182 rows; open-state 170. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01LB8FmJaGd2cyjvy6dbEjpM
documentation/backlog/
OPEN-ITEMS.md is the register of open work and the file to read first — it holds only what is
open, one row per item, every row with a state and an owner. ROADMAP.md is the full history and
reasoning behind the R-n IDs, including shipped and killed items; an ID is minted there, and a new
instance of an existing item attaches to that ID rather than getting its own.
The rest of this folder: verified-LIVE findings with implementable fix plans that are not yet
implemented. Preserved here
(instead of on git branches) per the trunk-based, no-branches rule — the fix itself is implemented later
directly on main, during a normal/supervised session.
-
FIX-M18-NOTES.md — dump re-validation runs every 5 min (perf). FIXED in controller v0.62.0 @
f8afe5c(2026-06-14). (was on the deletedfelhom-controllerbranchfix/m18-dump-validation-cache.) -
FIX-M19-NOTES.md —
deriveStackNamemisattribution edge (low-incidence correctness). FIXED in controller v0.62.0 @6bab68b(2026-06-14). (was on the deleted branchfix/m19-stackname-crossref.) -
FOLLOWUP-golden-default-controller-tag.md — the golden bakes a stale controller (
:0.43.0when queued; had rotted again to:0.85.1by resolution). FIXED in felhom-agent @ceca355(2026-07-03):build-golden.shv2.0.0 makes the controller tag a MANDATORY argument (a required arg cannot rot) and golden 0.98.3 was baked + clean-room-validated (bake → first-boot-current → self-manage → app deploy, on the drill VM — no supervised touch of live guests needed) + published + vouched. Evidence:../audits/DRILL-golden-098-2026-07-03.md.
Related: the live-drive fixspec (../audits/live-drive-fixspec-2026-06-14.md) carries the deferred
supervised items F9 (HDD provisioning/guest-attach), F20-BUG2 (durable_id scheme), F20-BUG3 (async
mkfs) — to be implemented in the agent/golden supervised session.