felhom.eu/REPORT-clear-the-ground-2026-08-08.md

REPORT — clearing the ground before the next walk (2026-08-08)

A sibling report: REPORT.md is overwritten per-session and a parallel session shares this clone.

Golden 0.206.0 baked and VOUCHED · the R-242 gate built and shown red→green · demo-hp's stale flag found wrong and cleared · STATUS.md 258 → 87 lines. felhom-controller and felhom-agent untouched.

---

1. Part 2's gate — FAILING first, then passing

Shown failing against today's state, before anything was baked. That ordering was the instruction and it is the gate's own red-proof:

  newest released controller : 0.206.0
  newest golden baked        : 0.205.0

GOLDEN CURRENCY GATE FAILED: controller v0.206.0 is released and NO golden carries it (newest bake is 0.205.0).
A machine installed right now would receive v0.205.0 — the release is written, tested and pushed, and NOT delivered.

Entry point exit 1; summary CONVICTED: golden-currency. After the bake, the same command:

  newest released controller : 0.206.0
  newest golden baked        : 0.206.0
golden currency gate OK

⚠ THE INTRODUCING PUSH USED --no-verify, to get past the gate's own conviction. Stated here, in scripts/CHANGELOG.md and in the commit message rather than worked around. The alternative — baking first so the gate had never been seen red — was explicitly rejected: a gate that has never been seen failing has not been shown to work. Every later push in this session was clean.

What it does not catch, and why the design is what it is

It checks the BAKE, not the VOUCH. Both .githooks/pre-push and CI run repo_gates.py --fast, which by contract selects only gates touching no network — so a hub-reading gate registered as non-fast would run in neither, which is exactly the R-29 census failure this runner was built to end. And the vouched version lives only in hub_settings, with no copy in git; putting one there would create a second source of truth that can drift, and a green gate over a false claim is the worst outcome available. So a bake without a vouch still passes. That half stays open on R-242 rather than being papered over.

It compares versions, not behaviour, so a release that changed nothing customer-visible also trips it. Accepted deliberately, and stated because a gate that cries wolf is one people learn to bypass: judging "customer-visible" by hand is precisely what failed three times (R-239, R-242, and this recurrence), and the cost of a false trip is one bake — the operation the project wants routine anyway. A waiver belongs in the register, never in a habit of --no-verify.

Inconclusive (exit 2) on an absent controller clone or an unparseable header: not knowing is never a pass.

---

2. Part 1 — the stale blob, all six questions

Read-only throughout. Nothing was cleared during the spike — the clearance in §3 came afterwards, on the operator's explicit approval.

Q1 — what set it, and when. MEASURED, traced to an act, to the second. At 2026-08-04 20:15:49 the hub emitted offsite_reissued and escrow_stale in the same second — an operator Re-issue, three minutes after escrow_blob_served at 20:12:40 and 20:12:54, i.e. during the R-201 recovery drill. That is offsite.ReissueCredentials's precautionary MarkEscrowStale call, which hub v0.95.0 removed the next day (R-196 / R-204 item 2) for marking healthy escrows stale. So: the drill's own Re-issue, by code that no longer exists. (Both 4-August candidates named in the task were live that day; the events separate them.)

Q2 — is the flag correct? MEASURED: NO. The hub's blob seals restic_pw_sha256 = 8a9e33aa4da6769c5aea1831f87759e10930e2ec1dea0062576484e0598d080a; the key the box is actually using hashes to the identical value. The blob covers the key. The flag was wrong from the moment it was set.

Q3 — what clears it? MEASURED: nothing, by itself. The only writer of stale_at = NULL is SaveHostEscrow's ON CONFLICT — a fresh escrow ceremony, which is the one act that would supersede the good blob. The only exit from the false alarm was the destructive act the false alarm recommends. No timer, no self-heal, no reconciler touches it.

Q4 — who can see it? Said plainly: effectively only a database read.

audience	what they see
the customer	a card, but stating a false reason (see below) and recommending the destructive act
the box	nothing — report.EscrowStatus has no Stale field, so it cannot see the flag at all
the operator	one page: the PBS-DR view (hub/internal/web/pbsdr.go:487) — the wrong tier for an off-site symptom
alerts / notifications	none. The one-shot escrow_stale event fired on 4 August and was never notified — a full notification_log census for that customer that day returns 8 rows, none of them this one. It has fired twice ever, both on 4 August

A flag that changes behaviour, that nothing sets, and that nobody who would look for it can see. Filed as R-248 in its own right, because it is the shape this fortnight has been about.

Q5 — what else does a stale blob suppress? Enumerated from code, not assumed. (1) the ACK's restic_pw_sha256 is withheld; (2) a pending box can never auto-confirm; (3) so every off-site run is refused indefinitely; (4) the customer is told to create a new code; (5) NEW — v0.206.0's shape (c) is inert, because the box records an empty hub hash and falls back to (a)/(b). (2) and (3) did not bite demo-hp, which was already escrowed before the flag landed and has been backing up healthily throughout — 12 snapshots, last success 2026-08-07T02:15:35Z. (4) and (5) did.

Q6 — demo-felhom? No — stale_at empty, and it records the hub hash normally. Can a freshly installed box reach this state? NO, and this is the answer that matters for the next walk. MarkEscrowStale has no production caller anywhere in the tree — a full census returns only its own definition, two comments and two test references. Nothing has set the column since hub v0.95.0 shipped on 2026-08-05. The next walk cannot meet this, by any route, unless it uses demo-hp itself — and that box is now clear.

The sharpest finding: the box states four falsehoods and recommends the destructive act

Live on demo-hp, controller v0.206.0:

STALE escrow: the hub's current blob carries NO password hash (hash-less supersession) — the stored recovery bundle does not cover the offsite password; create a new recovery code

Every clause is false. The hub has the hash and is withholding it; there was no supersession (host_escrow_superseded holds no row for this host); the bundle does cover the password. It raises EscrowStale, rendering the customer card „A letétben lévő helyreállítási csomag nem fedi a jelenlegi távoli mentési jelszót. Hozzon létre új helyreállítási kódot."

And the cause is R-241's shape for the third time. The hub already sends escrow_stale on the wire (json:"escrow_stale,omitempty"); the controller's struct has no matching field, so encoding/json drops it silently. The box cannot tell withheld because flagged from genuinely hash-less, and guesses the latter. The answer is available and discarded at the boundary — filed as R-247, and deliberately not fixed here (§0 forbids a controller change this session).

---

3. The bake, the vouch, and the flag clearance

version	0.206.0 · sha256 c85230b42f53baa9c1ee9986ac312c751d6cbc29fbe070d87bb2214429a9108e
size	656,750,694 bytes (uncompressed 2,003,138,560)
MinAgent	0.127.0

Round-trip verified, not trusted: fetched back (HTTP 200, byte count matches), re-hashed independently (matches), zstd -t clean, and tar -xO ./etc/felhom-controller-image out of the download → felhom-controller:0.206.0. That last step is the one that matters, because GOLDEN_VERSION is derived from the tag argument and could be right over stale content. Third witness: the hub's own dropdown lists 0.206.0 with data-sha="c85230b4…108e".

All acceptance markers pass; unit Result=success / ExecMainStatus=0; bake VM purged and reverted to virgin; token-leak grep on the committed log 0, with the instrument proven by a planted copy first. Evidence: documentation/tests/golden-0.206.0-2026-08-08/.

VOUCHED with the operator's approval. Verified from the stored hub_settings, not the flash:

field	before	after
artifact_golden_version	0.205.0	0.206.0
artifact_golden_sha256	8f49b2e8…4ee8	c85230b4…108e
artifact_agent_version	0.127.0	0.127.0 — unchanged
artifact_min_agent	0.127.0	0.127.0 — unchanged
artifact_wrapper_sha256	104db0a4…16b3	unchanged — carried through explicitly, because the handler clears it when omitted

The stale flag was cleared, with the operator's approval. One row, identity-matched on host_id and guarded on stale_at IS NOT NULL; changes() returned 1. Verified end to end: the hub serves the hash again, the box recorded hub_escrow_key_sha256 = 8a9e33aa…d080a at 11:10:19Z, and that is byte-identical to the key it is using — so shape (c) compares, matches, and correctly stays silent. The false warning is gone, proven with a positive control rather than an absent line: 0 escrow-confirm lines since the restart, while 5 scheduler lines in the same window prove the box was logging and the recorded hash proves an ACK was processed.

Method note, because it touched a production pod: the hub pod is Alpine with no sqlite3; it was installed into the container's ephemeral writable layer — image and node untouched, gone on restart. SQLite's own file locking coordinated the write with the live hub. An earlier attempt failed on quoting and changed nothing, which is the fail-safe working.

---

4. STATUS.md, R-245, and the queue audit

Rebuilt from the register: 258 → 87 lines. Not trimmed — the 100-line "what shipped recently" log was removed outright, because restating the CHANGELOGs here is what made the page grow back.

All three named defects fixed: the "waiting on you" list no longer asks the operator to decide the recovery screen (shipped 2026-08-05) or to approve an orphaned-backup deletion the register records as done the same day; the stray - **Nothing.** line is gone; and the DooPlex infrastructure work is now under its own heading — kept rather than dropped, with the reason stated on the page: they are real asks that need the operator, but they concern the machine this is built on, not what a customer receives. Dropping them would have lost real work.

R-245 re-filed as a decision taken, keeping the whole reasoning and gaining the condition that reopens it: quota — old set-aside history blocking new backups. A condition, not a calendar.

The queue audit. Parsing the state column exactly (grepping for the phrase over-matches rows that merely mention it): exactly one row carried WAITING-ON-OPERATOR — R-245 — and it was the settled one. So zero rows were genuinely waiting, and the drift was caught while it was still a single row.

---

5. R-244 — still owed, now measured

A read-only census, no truncation: app_log_issues holds 1309 rows; 71 reference a torn-down venue; of those 44 are orphans (safely deletable) and 27 are shared with a live customer and must be de-referenced, never deleted. 1238 untouched.

Not done here, and the reason is on the row: the fix is hub code, this session's scope forbade a hub version bump, and a hand-run SQL mutation over 71 rows — 27 needing surgical de-referencing — with no tested code path and no red-proof is the shape that goes wrong on a live database. What it needs: a cascade leg that removes the customer id from affected_customers / context_customer and deletes only rows that become empty, plus a one-off sweep for the four venues already gone. The next session starts from data rather than a guess.

---

6. Registers, CI, and what was not done

Opened: R-246 (the flag: wrong, traced, now cleared — the column ruling still owed), R-247 (the box states four falsehoods and recommends the destructive act; the ACK field it needs is already on the wire and dropped), R-248 (a behaviour-changing flag visible to nobody). Updated: R-242 (recurred within a day; bake half now gated, vouch half explicitly still open), R-244 (measured), R-245 (re-filed as decided). Highest register ID moves R-245 → R-248.

CI — and the gate broke it, which I caught by checking rather than assuming. Runs 241 (3ca9a7bbe6e5) and 243 (7850469d5b78) failed. 241 is expected and correct — the gate was legitimately red at that commit, and CI saw it. 243 was not: CI checks out ONE repo, shallow, so the gate found no sibling controller clone, exited 2 (INCONCLUSIVE) and turned CI red on every push. A permanently-red CI is the detector-nobody-hears failure that workflow exists to prevent.

Fixed by giving the gate what it needs, not by letting it skip (6f25e02828c8): a depth-1 fetch of the controller repo in CI, plain git, no JavaScript-action step. A skip would have been the fail-open shape this project keeps removing — and the gate would then have run in neither of its two automated homes. Verified green: runs 244 and 245 (6f25e02828c8) both success.

--no-verify was used exactly once, on commit 3ca9a7bbe6e5, to push past the gate's own conviction — §9.11's explicit question, answered. Every later push was clean.

No controller or agent change, as scoped. R-247's fix is a controller change and is therefore filed rather than made.

Observations — noticed, NOT acted on

• stale_at is a column with no production writer. It changes what a customer is told, and nothing can set it. Either give it an evidential setter or retire it; leaving it is leaving a trap that only a database read can spring. Recorded on R-246; not decided here.
• The escrow_stale event type appears never to be notifiable. It fired twice and reached notification_log neither time. I did not establish whether it is absent from the dispatcher's allow-list or merely suppressed, so I have not filed it — but if R-247 is taken up, that is worth five minutes first.
• The hub's EscrowStatus.Stale field is serialised and has no consumer anywhere. It is dead weight on the wire until R-247 gives it one.
• A new gate can break CI in a way the local run cannot show, because CI's checkout is narrower than a workstation's. That cost one red CI here and was caught only by pulling the run status. Worth remembering the next time a gate reads a sibling repo — the pre-push hook and CI do not see the same filesystem.