Night 2026-10-28 (part): design notes R-1255/R-1254 (03), R-528 (08, live on Tester 1 + the operator's mail); capability map E8/E9 PROVEN-LIVE, B2 re-checked; 2 claims walked (35 -> 33 not walked); evidence + red-proofs

documentation/architecture/03-host-agent.md

@@ -569,6 +569,16 @@ never opens, re-seals or logs it; the audit (`escrow_carried`) carries host ids
 hosts → no carry, `escrow_carry_refused` to the operator. The box then sees „identity present", its mint guard (R-241)
 holds, and it offers the recovery screen. Proven live 2026-10-21 (`audits/fixes-2026-10-21/P1-live/`: the right code
 opened the household's history, Nextcloud's 3 031 files came back byte-identical, the next off-site run appended).
+**[DESIGN] 2026-10-28 night — WHICH retained row is carried (R-1255 H3; felhom.eu `1ee6d5a5`, rides the next hub
+release):** the newest retained row that has an identity blob AND a repository-password hash; only when no row has a
+hash, the newest row as before (a legacy package whose hash was never recorded may still seal the password — never fewer
+ways back). Before, the newest row alone was taken: a newer package without the password was carried while the
+household's real one stayed under the deleted host. **And the set-aside purge (R-1255 H4):** a set-aside is named
+`<repo>.orphaned-<YYYYMMDDTHHMMSSZ>` (unique per run; was the date, which a same-day abandonment freed for the next
+set-aside), and a retained row is purged only when it was tagged with the deleted path no later than that path's
+deletion (`repo_tagged_at`; a row tagged before the column existed uses `superseded_at`) — a reused path's later copy is
+still stored, and its packages stay. Store tests `TestR1255_*`, red before the fix; no live proof (a hub deploy is not
+tonight's).
 
 #### The separation principle (the rule that governs every posture)
 Reading customer data needs **BOTH** the encrypted chunks **AND** a usable key. **Zero-knowledge
@@ -652,6 +662,15 @@ nothing waiting 404, hub failure 502 (still waiting). A controller that has not
 R-978 order. Proven on demo-hp 2026-10-19: ceremony 1 typed back → code 1 opens the hub's package, code 0 is a kept
 earlier one (422); ceremony 2 shown and abandoned → code 1 still opens it, code 2 opens nothing
 (`audits/day-2026-10-19/P1/escrow-*.txt`).
+**[DESIGN] 2026-10-28 night — a lost or late answer (R-1254 H2; agent `5ddd124` + controller `e33cffa`, unreleased):**
+the upload at the claim or the confirm can lose its answer AFTER the hub stored the package, and the household was then
+told „the previous code still works" — false. Now, after a failed upload, the agent asks the hub which package it holds
+(`GET /api/v1/hosts/<id>/escrow`, the identity blob compared byte for byte, ciphertext only, 15 s): THIS package → a
+success; another package → 502, the old sentence (now true); no answer → **504**, a sentence that promises nothing about
+either code, the wait goes on. The controller words 504 and its own failed call as „Nem tudjuk biztosan… Őrizd meg
+mindkét kódot…" (`api.escrow.confirm_store_unknown`), and waits up to 60 s for the claim and the confirm (was the
+client's 15 s — shorter than the agent's 30 s upload, so an abandoned claim could store a package whose code reached
+nobody). Tests `TestR1254_*` in both repos, red first. Live proof with the agent release (the vouch).
 
 #### Custody across generations — what the hub retains when a blob is superseded (hub v0.60.0; **contract corrected hub v0.93.0, R-198**)