where-felhom-stands: bring the picture up to 2026-08-22, and stop the page disagreeing with its source

Eight claims re-checked against the drill and the v0.218.0 fixes; three moved, all downward.

  backup.offsite            walked -> partial. "18 snapshots, daily, unbroken" was true on
                            2026-08-09 and false by 2026-08-21: the next snapshot after that date
                            was put there by hand, twelve days later. The rebuild lost the target
                            and the per-app switches came back off, so a run reported "backup OK:
                            0 app(s) backed up".
  fail.wiped-reinstalled.data  walked -> partial. A real reinstall orphans BOTH off-premises tiers:
                            restic silently for 12 days (R-193), and the PBS archives from before
                            the reinstall cannot be opened by the rebuilt box at all (R-366).
  backup.fill-warning       walked -> partial. The warning fires correctly, but the watcher runs
                            once a day, so a filesystem that fills at 03:31 goes unannounced for
                            ~24 h. Watched silent while a volume sat at 99%.

Five re-checked and held: backup.tier1 and recover.byte-identical carry the R-355/R-354 story and
their fixes; backup.restore-proof stays grey for a sharper reason (orphaned archives, not an
untested tier); backup.sikeres gains two fresh instances; fail.customer-self-restore records that
R-356 now blocks 40 of 53 apps regardless of who is driving.

render_stands.py: the header's commit shas were hardcoded, so the page cited the August 9th commits
while the YAML said otherwise - the stale-build-product failure the renderer exists to prevent. They
are parsed now. The count beside them said "15 status(es) moved in that pass" when 15 was every
recorded move ever; it now separates the two numbers.

check_stands passes, and was itself proven able to convict first: a claim marked `missing` flipped to
`walked` in a scratch copy fired rule 5 by name (use.dlna), and the real file still passes.

scripts/CHANGELOG.md

@@ -1,3 +1,20 @@
+## render_stands.py — the page stopped disagreeing with its own source (2026-08-22)
+
+**The header's commit shas were hardcoded in the renderer, not read from the YAML.** `verified_on`
+was parsed; `verified_against` never was. So the page printed
+`felhom-agent 28ba8593b8, felhom-controller c732fe1283, hub 56f8aa611c` no matter what the dataset
+said — and on 2026-08-22 the YAML header was updated to the current commits while the rendered page
+went on citing the August 9th ones. **A build product silently disagreeing with the file it is built
+from is exactly the failure this renderer's own docstring says it exists to prevent** ("it began going
+stale the moment it was committed, which is the one thing a picture of 'where we stand' must not do").
+`load()` now parses `verified_against` and the header renders from it; the literals are gone from both
+the script and the output, checked.
+
+**And the count beside it was wrong in a way that flattered us.** It read "N status(es) moved in that
+pass" while N was every claim carrying a `changed:` block — 15, accumulated since the dataset began,
+not 15 moves in one pass. It now reads "15 claim(s) carry a recorded status move (8 re-checked in this
+pass)", the second number counting claims whose own `verified.date` equals the header date.
+
 ## due_checks_gate.py v1.0.1 + instructions_gate.py — the today-override announces itself (2026-08-18)
 
 **Both gates read `FELHOM_GATE_TODAY` so their suites can control "today"; neither said so.** A shell