REPORT + CONTEXT: A4 reverses its own premise, the naming half, and the first R-264 reader

A4's evidence contradicts the task's framing and the register now says so: peti-felhom
is a real machine with 482 reports and a real person behind it; david -> tester-1 is a
record that has never had a host, an escrow or a report. The risk is real; only the
word that named it was wrong.

CONTEXT gains three standing rulings: read the fact that carries the RISK (heals_last_hour,
not state) and decode the one that decides the question (heal_succeeded — R-260's lesson);
one secret in two situations keeps its name and changes its sentence, and the mail must
name the page the machine actually shows; and evidence dies in the INTERMEDIATE revert —
with the corollary that a durable citation may never point at a file whose contract is to
be overwritten, which is why the R-316 report was moved to audits/ before this one was
written.

CONTEXT.md

@@ -15,6 +15,95 @@
 > would make one of the two audiences stop reading. `STATUS.md` is also a **view of `OPEN-ITEMS.md`**
 > and holds nothing of its own; this file does hold its own content, namely the standing rulings below.
 
+## A fact the boxes send and the hub cannot read is a future false green — and one now has a reader (2026-08-13, R-319)
+
+**The first of R-264's twenty-one unconsumed facts is read.** The agent emitted `guest_net` on every
+heartbeat for **twenty-three days** (agent v0.92.0, R-54, 2026-07-21) while the string occurred
+**nowhere** in `felhom.eu/hub/` — stored as raw text in `report_json`, reaching no check, no alarm and
+no screen. Hub v0.104.0 models it: `parseGuestNet`/`guestNet` in `web/hosts.go`, rendered as the
+host-detail **Guest network** card.
+
+**The rule this instance teaches, and it generalises past guest networking:**
+
+- **Read the fact that carries the RISK, not the fact that is easiest to render.** Here that is
+  `heals_last_hour`, not `state`. A guest the watchdog keeps repairing is healthy at every instant
+  anyone looks and is nevertheless failing — rendering the state alone gives it a green tick, which is
+  the failed-disk-drawn-as-a-healthy-empty-disk shape wearing different clothes.
+- **Decode the field that decides the question, not five of the eight.** `heal_succeeded` was added
+  mid-build for exactly this: six FAILED repairs is a guest that is down, six successful ones is a
+  nuisance, and the count alone cannot tell them apart. **R-260 is the standing warning** — a hub
+  decoder three fields short of the agent dropped the one its checker existed to answer.
+- **Three absences, three sentences.** Agent too old / capable agent silent / guest state not asserted.
+  All render unknown; conflating them is how an operator starts ignoring a card. The state switch is an
+  **allow-list**, so adding a state to the agent can never silently paint it green here.
+- **REMOVING an allowlist entry is what proves a reader is wired.** An allowlisted tag is *skipped* by
+  `wire_contract_gate.py`. Re-labelling the eight `guest_net` entries would have left the new reader's
+  own fields unchecked while the gate reported coverage. Deleting them moved checked tags **182 → 190**
+  and skipped **88 → 80** — the positive control that the wiring is real, independent of any test.
+- **A card is not an alarm, and building the card first is deliberate.** No email was added: the
+  incident behind this (a killed `dhclient`, tunnel down 1 h 15 m, nobody told) was a **visibility**
+  failure, and with zero repairs ever recorded on either demo box any alarm threshold would be invented.
+  **The visible count is what will supply the threshold.**
+
+**Where the twenty stand** (R-264, counts measured from the allowlist rather than estimated):
+**8 read · 5 deliberately not consumed · 1 redundant · 6 still owed a reader.** The gate grew a **third**
+entry kind — `not consumed, deliberately` — because an undecided fact and a decided one must not read
+alike, and *"arguably owed"* had been carried for five days as though it were a decision.
+
+**Two findings came out of deciding the last one rather than from building anything:**
+
+- **R-321** — `reporting_disabled` is *redundant* (`health.status = "disabled"` travels beside it, is
+  decoded, and IS rendered), **but `StalenessChecker.Check` is age-only** (`monitor/staleness.go:88+`,
+  sole skip `IsCustomerBlocked`), so a deliberately-silent box still alarms `node_stale` then
+  `node_down`. **Decoding the flag would have felt like progress and left the alarm firing** — the fix
+  belongs in the checker, which already holds the status it needs.
+- **R-322** — `retrieval_promise_gate.py` has **never scanned the hub**, which composes every customer
+  e-mail, i.e. the copy read *before* any box screen. A hand scan with its own four stems returns zero,
+  so it is a scope gap rather than a live defect — recorded before someone writes the first hub-side
+  retrieval promise assuming the guard has them covered.
+
+## One secret in two situations keeps its NAME and changes its SENTENCE — and the mail must name the page the machine shows (2026-08-13, R-295 hub half)
+
+The box side shipped 2026-08-10; the hub half was dropped twice and was the last place „Visszaállító
+kód" survived — in the **mails**, the one surface a customer reads *before* they see any screen. It is
+now „**Beállító kód**" everywhere; the ten-word escrow code stays „**Helyreállítási kód**"; no
+dashboard-code mail names both.
+
+**The mechanism worth carrying: the mail names a PAGE, and which page depends on state only the hub
+knows.** `ReissueForReenroll` sent the *reset* mail, directing the customer to „Elfelejtett jelszó" —
+but a rebuilt box has no password, so the controller computes `reset := s.authEnabled()` → false
+(`felhom-controller/controller/internal/web/claim.go:279`), renders „**A szerver beállítása**", and
+serves **no login page at all**. The named route was not on their screen. **The two situations are
+distinguishable only at the hub, because the hub chose which call site fired** — so the fix is a new
+`EmailKind` (`reenroll`), not a reworded shared template. A `default` branch falls back to the
+first-setup mail, which is the safe direction and is pinned so a future reader knows it was chosen.
+
+**The re-enrol mail deliberately says nothing about apps or backups.** A clean-slate reinstall is
+precisely where that reassurance could be false; `TestFormatClaimEmail_ReenrollPromisesNothingAboutTheData`
+guards the CLAIM rather than one phrasing of it.
+
+**Naming is not function, and the pin says so:** `TestReenrollSplit_ChangesTheMailNotTheSecret` — the
+generation still advances, the stored bcrypt hash still verifies the emailed code, no plaintext is
+persisted. Box-side companion: the controller's `TestResetCode_StillAcceptedOnTheSetupPage`.
+
+## Evidence dies in the INTERMEDIATE revert, not the final one (2026-08-13, R-320)
+
+Twice in three days, on the same box at the same point, a phase's logs were destroyed by a revert to
+`virgin` *between* phases (drill 2026-08-12 Phase A→B; R-316 2026-08-13 Part 1→2). Both times the
+golden-bake runbook's existing *"scp the log OUT first"* was applied to the **final** teardown and not
+the middle one. Both times the conclusions survived on luck.
+
+**Standing rule 5** now: evidence comes off at the end of the phase that produced it, before any revert
+— **the pull is the LAST ACT OF THE PHASE**, not a step to remember later. Four homes:
+`workspace-CLAUDE.md`, `runbooks/target-selection.md`, `RUNBOOK-rehearsal-v3.md`, `PROMPT-TEMPLATE.md`
+report item 8. **And the already-gone case is documented rather than improvised:** say so plainly and
+reproduce the finding independently.
+
+**A corollary this session hit immediately:** the second incident was recorded in `REPORT.md`, which
+every session overwrites — writing tonight's report would have **destroyed the record of a destroyed
+record**. It was preserved to `audits/REPORT-r316-installer-v1.28.0-2026-08-13.md` first. *A durable
+citation may never point at a file whose contract is to be overwritten.*
+
 ## Material retained is not history recoverable — ask the three questions separately (2026-08-12)
 
 **"We keep the old key" and "the customer can get their old backups back" are three questions, and