docs: R-189, R-188 and R-186 closed (agent v0.122.0); R-185 stays open

- OPEN-ITEMS: all three rows closed with their measurements. R-189 records the
  migration consequence seen live (a pre-R-189 record has no tier and is not
  reportable, so upgrading does not retroactively make an old proof visible).
  R-188 records both directions demonstrated and the fixture cleaned up. R-186
  carries the before/after sha values including the CGO_ENABLED discrepancy.
  The priority list states explicitly that R-185 is the one left open from that
  group and that this session did not touch it.
- capability map: the restore-proof row now says the evidence path itself had a
  gap — the proof reached the hub only because no restart intervened — and what
  closed it.
- CONTEXT: S-19 (a proof is durable and reportable, a failure is neither, and
  why) and S-20 (the release ordering, what each step protects, and how a binary
  is verified).
- STATUS: rewritten for the operator, back to one screen.

CONTEXT.md

@@ -17,6 +17,48 @@
 
 ## Standing rulings
 
+**S-19 — a restore-test PROOF is durable and reportable; a FAILURE is neither, and that asymmetry is
+the design (2026-08-03, R-189; agent v0.122.0).**
+
+*The rule.* Only successful restore-tests are written to `RestoreTestState`, and that state is what
+the host report carries after a restart. Failures live only in the in-memory `backup.Store`.
+
+*Why, in one line each.* A **success suppresses future work** — under R-86's per-archive due-check a
+proven archive is never re-tested, so a lost proof leaves the box quietly less tested than it
+believes, for a whole archive generation (a week on the offsite tier). A **failure causes future
+work** — a failing tier stays due and is retried at the next evaluation, so a lost failure heals
+itself within one interval, while a *persisted* failure would outlive the fault it describes.
+
+*What the report does with the two.* The collector merges them: **one entry per tier, newest by
+`TestedAt` wins**. A fresh failure therefore beats a stored success (the failure is the news and
+exists nowhere else), a stored success beats a stale in-memory entry after a restart, and a tier can
+never appear twice — the hub would read that as two tests.
+
+*It refuses to lie.* A persisted record missing the archive **or** the tier produces **no entry**: an
+unproven tier reading as proven would be worse than the defect this closes. Run mechanics (scratch
+VMID, duration) are not re-invented — an absent duration is not a claim, a fabricated one would be.
+**Migration consequence, seen live:** a pre-R-189 record has no tier, so upgrading does not
+retroactively make an old proof visible to the hub; the tier's next real proof fills it in.
+
+**S-20 — the release order is build → tag LOCALLY → publish → push tag, and every step protects
+something (2026-08-03, R-188 + R-186).**
+
+The tag is created before the publish, so the build and the tag describe the same commit. It is
+**pushed** after, because the push is what wakes CI (`on: [push]`) and a tag visible before its
+package made `check-published-versions.py` correctly fail a *correct* release — measured on roughly
+every second release, and R-168 mails those failures to the operator.
+
+The invariant the old order protected is **asserted directly instead**: the gate now also refuses a
+**published version with no tag**, as a bounded probe (frontier + patch gaps) that prints its own
+coverage, because the package listing api is 401 without a token and absence cannot be enumerated.
+A half-done release is loud: publish-then-failed-push dies naming the recovery command, and a failed
+publish deletes the local-only tag so a retry is clean.
+
+**A released binary is independently verifiable** — `-trimpath -buildvcs=false` means the same source
+yields the same bytes with or without the tag; the verification command lives in
+`felhom-agent/CLAUDE.md`. Both build paths (`release-agent.sh` and `publish-agent.sh`'s fallback) use
+identical flags: they differed by `CGO_ENABLED=0` and produced binaries 74 KB apart for one version.
+
 **S-17 — restore-testing is PER ARCHIVE GENERATION, and the hub's staleness window follows each
 tier's own rhythm (2026-08-03, R-86; agent v0.121.0 + hub v0.91.0).**