Files
felhom.eu/documentation/backlog
admin ad28699761
gates / gates (push) Successful in 7s
docs: R-157 A / R-170 / R-171 closed — boot recovery finished
Controller v0.190.0. Docs only here; no hub change, no hub version bump.

- audits/DIAG-bootrecon-drive-absent-2026-08-02.md — NEW. The Part 0 diagnosis,
  including the run that produced a FALSE NEGATIVE and the mechanism behind it
  (the agent re-binds an unmounted drive within ~60s, so the drive gate's startup
  reconcile restarted the apps one second before the sweep looked). Records that
  the write hazard was blocked only by an ACCIDENTAL filesystem permission that no
  code owns and no test pins.
- architecture/02 §0a — the boot-recovery contract (S-1): both gates read desired
  state; the sweep observes a SETTLED fleet and each sample must refresh first;
  nothing is started without asking, fail-safe. Plus the durable warning:
  Manager.StartStack has no gate of its own.
- 00-capability-map — the boot-recovery row, with the repeat count cited per N.5
  (6 of 6 hard resets) rather than a bare PROVEN-LIVE.
- OPEN-ITEMS / ROADMAP — R-157 CLOSED (both mechanisms), R-170 CLOSED, R-171 NEW
  and closed the same session, marked a regression from v0.189.0.
- STATUS.md — the power-cut line moved from "What's broken" to "What works right
  now" with its repeat count; one dated bullet in the change log.
- CONTEXT.md S-13 — the lessons worth carrying: "it didn't happen this time" is
  not a disproof; widening a window makes previously-unreachable overlaps
  reachable; and a settle detector is only as good as the freshness of what it
  samples — the fix's own defect, found live rather than by review.
2026-08-02 20:38:21 +02:00
..

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 deleted felhom-controller branch fix/m18-dump-validation-cache.)

  • FIX-M19-NOTES.mdderiveStackName misattribution edge (low-incidence correctness). FIXED in controller v0.62.0 @ 6bab68b (2026-06-14). (was on the deleted branch fix/m19-stackname-crossref.)

  • FOLLOWUP-golden-default-controller-tag.md — the golden bakes a stale controller (:0.43.0 when queued; had rotted again to :0.85.1 by resolution). FIXED in felhom-agent @ ceca355 (2026-07-03): build-golden.sh v2.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.