admin
a1a6c73fe1
R-449. Until today one app upgrade out of 53 had ever been measured, by hand, and the whole update arc was designed against that single data point. C3 first: the negative control, whose TO image exits immediately, came back failed. That is what makes the greens mean anything, and it cost 556s because a negative is only honest if it waits out the full settle window. Seven edges, three apps. All five real catalog upgrades kept the customer's data. The finding that changes an assumption the arc was carrying: whether an upgrade can be UNDONE is a property of the individual APP, not of upgrades. Docmost refuses - 'corrupted migrations: previously executed migration 20260213T085259-notifications is missing' - and privatebin does not. That reproduces the Nextcloud result on a second app by a DIFFERENT mechanism, so the struck word 'rollback' now rests on two measurements instead of one. The finding nobody was looking for, R-459: our own bookstack template moves MariaDB across a major and sets no MARIADB_* env at all, so the engine logs that the datadir upgrade it requires is being skipped, and serves anyway. The cause is assigned rather than guessed - the app half alone produces no upgrade line, both edges that move the engine produce it - which is exactly what decomposing E3 into E3a and E3b was for. It also explains why E3's abort looked like it worked: the datadir was never converted. Whether that ever breaks is NOT established, and the row says so. Also opened: R-460 (bookstack's file half cannot be seeded headlessly), R-461 (target-selection.md names a venue that does not exist and fences a VM that is gone), R-462 (the widening, costed with this run's real numbers - and the cost is dominated by fixtures, which do not amortise). Teardown all three layers, hub checked rather than asserted. local-lvm read 30.50 percent before and after. The capability map was deliberately NOT edited: this measured apps, not the product.
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.