due-checks gate (R-341), floor raise recorded (R-343), snapshot coverage (R-342)

PART 1+2 — dated checks stop being wishes. R-341 booked two measurements as
prose in a register row; nothing read those dates and nothing would have
objected when they passed. The dates now live in a DUE-CHECKS block INSIDE
OPEN-ITEMS.md (inside, so no sidecar can drift from it) and a new gate reads
them. Registered as #10 in repo_gates.py, --fast, so it runs in BOTH the
pre-push hook and CI.

  exit 0  nothing due (prints pending count + nearest date; empty block too)
  exit 1  a row is due/overdue (due <= today, UTC -- due TODAY counts), or a
          row names an item with no R-row
  exit 2  block absent/duplicated/unparseable -- INCONCLUSIVE, never 0

It REFUSES rather than warns, and its docstring states the limitation: it is
NOT a scheduler, it fires on the next push, not on the date.

37 tests. BOTH red-proofs run and reverted -- and the first one earned its
keep by catching a hollow assertion of MINE rather than confirming the gate:
flipping <= to < left a due-today row in neither bucket, min() raised on an
empty list, and the TRACEBACK exited 1, so "rc == 1" passed while the
boundary was wrong. An exit code cannot tell a verdict from a crash. The test
now asserts the conviction banner and the absence of a traceback, and the gate
returns 2 rather than crashing if that partition breaks again.

PART 3 — the floor raise, and the premise was WRONG. Read back from the store
(not the form): min_controller_version = 0.216.0 @ 12:36:58Z, zero
per-customer overrides, no "managed floor HELD" line. But read 5 shows the
raise was NOT a no-op: demo-felhom had been on 0.214.0 since 12 Aug and
auto-updated 0.214.0 -> 0.216.0 at 12:37:07Z -- NINE SECONDS after the save,
exactly the immediate action publish-train rule 2 documents. No error events
followed; it restarted clean.

R-343 is therefore filed OPEN, not CLOSED: the closing condition was all five
reads clean and no directive served. It went well, but a record calling it
inert when it moved a customer box is what misleads the next reader. The row
also states why the floor was behind -- rule 2 policy, not drift, earned by
the 2026-07-11 skew onto Peti's box -- and cites ResolveManagedFloor
(store.go:2068) plus the two build-felhom-iso.sh facts (build-time at :267,
fails open at :78-82) rather than asserting them.

Two boxes are below the floor and neither reports: drill-r50 (blocked,
powered off) and peti-felhom (host row deleted). peti-felhom was NOT
contacted -- its row records that a report from a deleted host 401s and is
not persisted, so the raise cannot reach it.

PART 4 — R-342 filed READY, quoting stop2-snapshot.txt verbatim: Hetzner
server snapshot 421440873 covers /dev/sda only; /mnt/pbs-datastore is a
separate Volume that snapshots exclude, so a rollback restores software state
and NOT the datastore. Fine for that upgrade; the safeguard for any future
procedure that could touch the datastore does not exist and is Viktor's call.

Also: CLAUDE.md's gate list named 6 of 10 registered gates -- completed
rather than appending a 7th to a wrong list (124 -> 128 effective, ceiling
200). Capability map deliberately unchanged; no row cites a floor or golden
version. repo_gates.py fully green, 10/10.

scripts/repo_gates.py

@@ -15,6 +15,21 @@ Gates, in order (all must pass; **non-zero exit on any failure**):
   5. reuse-refs      every path cited by this repo's REUSE.md still resolves
   6. instructions    CLAUDE.md length/versions/TEMPORARY, rule-file scoping, workspace-copy identity
   7. golden-currency a released controller has a golden carrying it (R-242)
+  8. wire-contract   every emitted field is decodable by its receiver (G-1)
+  9. hub-copy        the hub's customer-facing words, against the retired-name list (R-324)
+ 10. due-checks      a dated check in OPEN-ITEMS.md that has come due (R-341)
+
+WHY 10 IS HERE (2026-08-18, R-341). R-341 booked two dated measurements — +24 h and +7 d —
+as a sentence inside a register row. Nothing read those dates, and nothing would have said a word
+when they passed; the row would simply have gone quiet and stayed that way. That is the same shape
+as R-242 (a rule filed without a mechanism, which recurred the next day) and as the R-29 census
+finding below, where the checks nobody was told to run were the ones that had been failing for
+weeks. The dates now live in a machine-readable block INSIDE OPEN-ITEMS.md — inside, so there is no
+sidecar to drift from the register — and this gate refuses the push once one comes due. It REFUSES
+rather than warns, deliberately: a warning is the thing that gets scrolled past, and this repo has
+the census to prove it. It is `--fast` (stdlib file read, no network) so it runs in both the
+pre-push hook and CI. **It is not a scheduler and its docstring says so** — it fires on the next
+push after a date passes, not on the date.
 
 WHY 7 IS HERE (2026-08-08, R-242). R-242 was filed as a rule with no mechanism — *a controller
 release is not finished until a golden carries it* — and RECURRED THE NEXT DAY: v0.206.0 shipped
@@ -72,6 +87,8 @@ GATES = [
     # R-324 — the hub composes every customer e-mail and renders the binding pages, and until
     # 2026-08-13 no guard in either repo had ever looked at them. Fast: pure file reads.
     ("hub-copy",        os.path.join(SCRIPTS, "hub_copy_gate.py"),        [],      True),
+    # R-341 — dated checks in the register were prose that nothing read. Fast: stdlib file read.
+    ("due-checks",      os.path.join(SCRIPTS, "due_checks_gate.py"),      [],      True),
 ]
 
 VERDICT = {0: "OK", 1: "FAILED", 2: "INCONCLUSIVE"}