Files
felhom.eu/documentation/backlog
admin 338b2ccf86 agent 0.114.0 published + vouched; R-115 files the recurring publish gap
PART 1 — Session C unblocked.
Agent 0.114.0 (the R-113 fix) was built, pushed and deployed but never
published, so a fresh drill box would have installed 0.113.0 and proven the bug
rather than the fix. Published from the clean tree at b58d7bc via
scripts/publish-agent.sh; sha 5e4c15ebee2d7583d57301d1f7c9cc7d4276262966bf738b05e34653bfd18c31,
verified by an INDEPENDENT round-trip GET (http=200, sha match, binary
self-reports 0.114.0), and the hub manifest read back after the write.

Deliberately NOT done, each with a reason:
- No golden bake. The golden bakes the CONTROLLER, not the agent, and
  host-install fetches them as separate generic packages (:1945 / :2573). Golden
  0.185.1 is current, so there is no new-agent-against-old-golden risk.
- min_agent NOT raised, stays 0.113.0. It expresses what the CONTROLLER requires
  of the agent, and controller v0.185.0 declares MinAgent 0.113.0 — which
  0.114.0 already satisfies. Raising it to 0.114.0 would have been a false claim
  AND would have held demo-hp and drill-r50. No box is held; no §3 STOP fired.
- Global controller floor NOT raised (v0.156.0), per R-111's reasoning.
- wrapper_sha256 preserved verbatim; re-checked against configs/felhom-pbs-apply
  before and after — no drift both times.

demo-hp RULING: left on 0.113.0. The R-113 fix is not live-validated, so putting
it on a second box widens exposure for no proof, and Session C's nested box
takes its agent from the manifest, not from demo-hp's host agent. Move the fleet
once, after Session C.

PART 2 — R-115 opened (WAITING-ON-OPERATOR).
The finding is the RECURRENCE, not either instance: publishing is a remembered
step, and it was forgotten within eight hours of R-111 documenting it as
forgettable. Filed as a new ID with a back-pointer rather than reopening R-111,
because R-111's finding (the channel WAS stale) is closed and verified
end-to-end, while the process defect that caused it is a distinct problem with a
distinct fix and owner. Class cross-linked to R-29 (a control that exists and is
never walked) WITHOUT minting a second ID for it. Options are stated as the
operator's decision, with mechanisms (build-step, deploy gate) separated from
reminders (checklist, manual) — R-29's whole finding being that reminders do not
hold. No code written, by design.

R-111 gains a deferred-leg-recurred line; its shipped evidence is untouched and
it is NOT reopened. R-113 records that Session C is now unblocked.
2026-07-29 19:03:59 +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.