felhom-controller/REPORT.md

REPORT — controller v0.262.0 + v0.262.1 (2026-09-22)

Not done, or changed from the brief

1. R-634's diagnosis spike was SKIPPED, and the brief put a gate in front of it. §3 said: reproduce sparkyfitness alone, read runComposeDeploy against the log, name the line — then fix. I went straight to the bounded half (Part 2.2), which is safe regardless and is now proven live. The mechanism is still unknown and R-634 stays open at P1 for it.
2. R-625 (a held app still renders an Update button) is not started. Its bundle key was written and then removed from both bundles — an unused key is a promise not kept.
3. v0.262.1 exists because the live proof found what the tests did not. The busy guard fired correctly and answered HTTP 500: router.go maps remove errors by grepping the error TEXT, and the busy sentence contains none of the words it looks for. Now a typed error and a 409.
4. Two baselines in the brief were stale — felhom.eu and app-catalog-felhom.eu had both moved since it was written, by my own work earlier the same day, and the highest R- id was 636, not 634.
5. Scenario B's first live run proved nothing and nearly went down as a pass. The remove was refused with 409 still running — stop it first, which is the PRE-EXISTING check: the restore had already finished. A refusal from the wrong rule is not evidence for the new one. Re-run with the app STOPPED and a backup in flight, which is the only way to reach the new guard.
6. Scenario B's subject changed from gokapi to privatebin: gokapi is still crash-looping from this morning's R-633 artefact (its config volume was removed, so its binary can never start), and a subject that cannot reach a steady state proves nothing about a guard that fires between them.
7. 44 minutes were lost to my own waiters — pgrep -f "build.sh 0.262.0" matched the waiter's own command line, so it waited for itself while the build had already succeeded. Same bug cost 15 stuck watchers earlier in the day. Recorded as its own memory rule: watch a sentinel the work writes, never a process name.

What shipped

felhom-controller@3d41758 — v0.262.0 (R-630, R-634-half, R-633/R-626, R-621, R-614) and v0.262.1 (the 409). All 17 controller gates green; the go-parity gate caught both new i18n keys as unregistered before the push and was right to.

app-catalog-felhom.eu@02844ae — six proven versions moved (one commit each), healthcheck.container for paperless-ngx and immich, the probe gate rewritten to the controller's four rules, decoy suite 56 → 64 cases.

Proven live on 9202

	before (v0.261.0)	after
A paperless-ngx Update	failed at +313.0 s, app stopped, front door 404	done at +53.4 s, running
B remove during a backup	—	refused, REFUSED (busy): a backup or restore is running; remove after → verified: true, nothing 60 s later
C remove a half-state	stack "sparkyfitness" is not deployed	200, leftovers: NONE
F redeploy after remove	inherited the old phase	phase done → no phase

Five red-proofs, each seen failing then green. D (hold logs) is pinned by the two existing tests whose compose sequence now includes the capture — they caught it and made me justify the order.

What is owed

• R-634's mechanism — why deployed goes false while containers run.
• R-625 — one verdict for the held badge and the Update button.
• The floor. v0.262.1 is on 9202 only. Raising it is the operator's call.