REPORT + CONTEXT: R-100 producer half (v0.181.0), proven live

CONTEXT.md

@@ -7,7 +7,21 @@
 >
 > Ask Claude Code: "Please update CONTEXT.md with what we did today"
 
-Last updated: 2026-07-28 (v0.180.0 — F-OBS: the dead-app check gets a positive observable)
+Last updated: 2026-07-28 (v0.181.0 — R-100: the offsite last-SUCCESS anchor)
+
+> **2026-07-28 — v0.181.0 (R-100).** `OffboxTarget.LastSuccess` + wire field `last_success`; the hub
+> (v0.80.0) anchors offsite staleness on it. **`LastRun` is written unconditionally on every run
+> INCLUDING failures** — it records an ATTEMPT — so the hub's "how long since LastRun" verdict read a
+> nightly-failing tier as perfectly fresh forever. The rule is the pure `offboxAnchorAfterRun(prev, at,
+> runErr)`: a failure neither ADVANCES nor CLEARS the anchor (both are distinct bugs; clearing it would
+> make one bad night look like never-succeeded). `LastStatus == "error" ⇒ stale` was rejected — it pages
+> on every blip, the F-A1 noise mode. **TWO SILENT-WIPE SITES CLOSED** (`offboxConfigHandler` and
+> `ApplyOffsiteTarget` both rebuild the target and copy runtime status field-by-field — omitting
+> LastSuccess would erase the anchor on any settings save or hub re-apply). **LESSON: my first test
+> modelled the rule in a local closure and stayed GREEN when production was mutated — hollow; the
+> extraction to a pure function is what made the red-proof bite.** Live on demo-hp: failing run advanced
+> `last_run` to 11:25:48Z while `last_success` HELD at 11:24:20Z; demo-felhom healthy → advanced. The
+> settings-save preservation was proven live too. Detail: `REPORT.md` + `felhom.eu/REPORT-r100.md`.
 
 > **2026-07-28 — v0.180.0 (F-OBS).** Source: `audits/CAMPAIGN-8-backup-restore-2026-07-27.md`.
 > On a default `logging.level: info` box there was **no positive observable that `deadapp-check` had