R-302: the abandon banner promises only what the box can still see is true
gates / gates (push) Successful in 10s

The retrieval clause rendered unconditionally on every page and is false on a
reachable state - the same screen where the orphan card says we cannot tell.

The condition is a fingerprint PINNED at the decision, not a comparison against
the current key. The obvious proxy asks about the wrong key: the set-aside
copies were written under an older key the box no longer has, so on a
twice-rebuilt box the proxy promises about copies nothing can open. Demonstrated
- under the proxy, the replaced-package and legacy cases both flip back to
promising.

The pin is a recorded assumption and says so: nothing on the box records which
key wrote those copies. Empty is not a match. A countdown started before this
carries no pin and takes the cautious branch, not a backfill.

A sweep of all 36 templates found a fourth instance (backups page, same
condition applied) and a fifth (the confirmation screen, correctly left alone -
true at the moment of the decision).

New retrieval_promise_gate registers each claim with a reason rather than
banning a verb: a string ban failed twice, and the honest replacement copy
contains the stem.
This commit is contained in:
2026-08-12 15:27:29 +02:00
parent 1b66010298
commit 89712563a0
11 changed files with 554 additions and 3 deletions
+42
View File
@@ -1,3 +1,45 @@
## v0.213.0 — the banner promises only what the box can still see is true (2026-08-12, R-302) — MinAgent 0.127.0
**The abandon countdown told every customer who had given up their off-site history: *„Addig még
visszaszerezheted őket a helyreállítási kóddal."* Unconditionally, on every page. It is false on a
reachable state — and it rendered on the same screen as the orphan card correctly saying we cannot tell.
**Why the obvious condition was rejected, recorded so nobody re-proposes it.** The natural proxy —
*does the hub hold a key different from the one this box uses?* — asks about the WRONG key. The
set-aside copies were written under an OLDER key the box no longer has, which is why they were set
aside. On a twice-rebuilt box the proxy answers “yes, promise it” about copies no key on file can open:
right in the ordinary case, wrong in the very case that started the investigation. **Demonstrated, not
argued** — under the proxy both Scenario B (package replaced) and Scenario D (legacy countdown) flip
back to promising.
**Instead the fact is recorded at the one moment it is a fact.** `startAbandonCountdown` pins the hubs
escrow key fingerprint as cached AT THE DECISION (`AbandonPinnedEscrowKeySHA256`). From then on the box
asks one exact question — *is the hub still holding that same package?* — rather than guessing which key
is which. Written once, never refreshed: a field re-read at render answers a different question. Same
shape as R-300s ownership record two sessions ago.
**⚠ IT IS A RECORDED ASSUMPTION, AND IT SAYS SO.** Nothing on the box records which key wrote the
set-aside copies. The pin presumes the package held at the decision is that one — true in the ordinary
rebuilt-box story, not provable, and wrong on a twice-rebuilt box. Written into the field comment and
into R-302 so it can be narrowed later rather than hardening into a fact.
- **The certain half always renders**: the deletion and its date. Only the retrieval clause is conditional.
- **Empty is not a match**, on either side — the hub sends “” for a package sealing no repository password.
- **A countdown started before this release carries no pin and takes the cautious branch.** Not
backfilled: that would assert as recorded-at-the-decision something read long afterwards.
- **A FOURTH and FIFTH instance of the same promise were found by sweeping every template.** The backups
page block (`„a mentéseid visszaszerezhetők, és a törlés elmarad"`) got the same condition — fixing the
strip and not the page would leave one contradicting the other. The abandon CONFIRMATION screen
(`recovery.html`) was deliberately left: it renders at the moment of the decision, where the promise is
true by construction, because that is the package about to be pinned.
**New gate — `retrieval_promise_gate.py`, and it pins the CLAIM rather than the word.** A string ban was
tried twice and failed twice (singular vs plural; then one verb vs another). It cannot simply be
broadened either: **the honest replacement copy contains the stem**, inside a question about whether the
thing is knowable. So every retrieval-claim occurrence across all 36 templates is now REGISTERED with a
reason, and unregistered ones fail. Proven by planting all three historical wordings in turn — each
convicted, each cleared on removal.
## v0.212.0 — the second promise (2026-08-12, R-299) — MinAgent 0.127.0
**R-299 — the orphan cards OTHER sentence made the same unevaluable promise, and the spec said it was