REPORT + CONTEXT: v0.202.0's rule, its live proof, and what was NOT verified live

CONTEXT gains the rule so it outlives the bug: on the unlock path the customer
is blamed only after a real attempt REFUSED their code; every other outcome,
including an unclassifiable one, says something else. Plus the two things that
must not be 'fixed' into it — elapsed time is never a classifier, and the error
TEXT is never read (when the distinction was not a value, the agent was changed
to provide one).

REPORT states the split honestly: the AGENT half is proven live on the venue
(400 -> 502 -> 400, same wrong code, only the hub's reachability changed), while
the controller's message selection rests on handler tests and red-proofs,
because /recovery correctly redirects since F7 set the old data aside and
restoring that state is the reconfiguration §11 forbids. Also records that the
correct codes were shredded by the previous session, so the live re-run used a
WRONG code — which makes the test harder, not weaker.

Two venue changes stated because they were not asked for, both restorations: a
fresh dashboard password (the previous session shredded it, leaving the box
impossible to log into) set through the supported --print-reset-code escape
hatch, and one normal off-site run to populate stats_known.

CONTEXT.md

@@ -1776,6 +1776,40 @@ Last updated: 2026-06-13 (v0.60.0 backlog-Medium cleanup)
 
 ---
 
+## THE UNLOCK PATH'S RULE (v0.202.0, 2026-08-06) — state it before changing anything there
+
+> **On the recovery unlock path the customer is blamed only after a real attempt REFUSED their code.
+> Every other outcome — including one that cannot be classified — says something else.**
+
+This is the rule, and it outlives the bug that produced it. It was learned twice, because fixing it
+once was not enough:
+
+- **v0.201.0** stopped an agent that is too OLD from being reported as a wrong code (R-216).
+- **v0.202.0** found the same defect through a different door: an agent that is **stopped**, and a hub
+  that cannot be **reached**, still fell through to a message about the code. Measured with a
+  **correct** code at 0.0299 s and 0.0556 s, against ~1.0 s for a real unseal — the machine accused the
+  customer of something it had not tried (R-224).
+- And the inverse: the one message that says *"check your ten words"* was unreachable on any box that
+  had re-escrowed, which is exactly the box a customer has just recovered (R-226).
+
+**How it is enforced.** `agentapi.ClassifyRecoveryFailure` maps the failure to one of five classes
+**from the value, never the text**; the typing message is reachable from **one** of them
+(`RecoveryAskedAndRefused`, i.e. HTTP 400, i.e. the bundle was fetched and `age` refused it); and the
+zero value is `RecoveryUnknown`, which renders **neutral**. **The safe default is the load-bearing
+part** — an unrecognised status must not fall into an accusation.
+
+**Two things that are deliberately NOT how it works, and must not be "fixed" into it:**
+
+1. **Elapsed time is never a classifier.** It is what diagnosed this, it is logged for the operator,
+   and that is all. A duration guard would be a second thing that can be wrong.
+2. **The error's TEXT is never read.** A string match is a defect waiting for a rewording. When the
+   distinction was not available as a value, the **agent was changed to provide one**
+   (`escrow.ErrBundleFetch` → HTTP 502, agent v0.126.0, `MinAgent 0.126.0`) rather than parsed for.
+
+**The coupling degrades safely and silently:** an agent below 0.126.0 answers 400 for both causes, so
+`FeatureRecoveryFailureClass` withholds the refusal reading and the 400 becomes neutral. The gate
+blocks nothing; it only decides whether the customer may be told to check their typing.
+
 ## CAMPAIGN 11 — what changed in v0.201.0 (2026-08-05)
 
 **The off-site key recovery is a COUPLED feature and now declares it.** It needs agent **0.125.0**