Files
felhom.eu/documentation/backlog
admin 56c7e373a3
gates / gates (push) Successful in 18s
SPIKE: what an app update actually does, and which other paths do it too
THE GATE IS ANSWERED: YES. compose up -d upgrades an app whose compose file has
already moved, and the Restart button does it — 18.3s with a network pull when
the target image is absent, 0.5s when present, against a negative control that
did not even recreate the container. The boot reconciler does the same thing
unattended when an app fails to come back (bootrecon.go:269 -> StartStack).

AND ONE FEAR IS SMALLER THAN THE BRIEF CLAIMED: a plain power cut upgrades
nothing. Docker restores the old containers and the reconciler logs 'no
boot-orphaned apps (nothing to start)'.

AND ONE IS BIGGER: app data CANNOT be rolled back. Once a migration has run,
the old image refuses to start — Nextcloud: 'the version of the data (32.0.9.2)
is higher than the docker image version (31.0.14.1) and downgrading is not
supported'. 'Rollback' is the wrong word for this arc and is struck.

Phases 0-6 all run, on demo-hp (Tier 0, disposable). Phase 6 run on operator
confirmation. Peti's box was never contacted. No production code written in any
repo: felhom-controller is at 960d29b0612c before and after, tree clean, and
build/vet/test are green — run at the end to prove exactly that.

Register: R-438/439/440 updated with live evidence; R-441..R-445 opened
(restore-vs-sync conflict; remove_hdd_data inert with no paths.hdd_path, 128 MB
left behind; update reports success over a broken app; no fleet fstrim; hub
telemetry outlives the app). Capability map gains three measured rows. The
mechanism is written down in 02-controller-module-map.md as MEASURED BEHAVIOUR,
not [DESIGN] — the operator has not ruled. STATUS.md carries the one decision.

Five claims in the brief are named as wrong, including two of my own method.
2026-09-01 21:35:32 +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.md — deriveStackName 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.