DRILL — R-389: only the first broken app per hour reached the operator (2026-08-23)

Hub v0.107.0 → v0.108.0. No controller release, so no golden and no floor. Live leg on demo-hp (Tier 0) plus the hub. UNATTENDED. Method: the hub's own SQLite records plus the controller log. Guest and hub DB are UTC; the hub pod logs CEST.

No halt condition fired.

The pair that says it

Same box, same shape — two apps down four minutes apart, inside one hour:

2026-08-23 09:27:51  sent        BookStack     <- v0.107.0
2026-08-23 09:31:51  suppressed  PrivateBin        operator cooldown 1h, key=demo-hp:app_start_failed

2026-08-23 11:56:57  sent        OpenGist      <- v0.108.0
2026-08-23 12:00:57  sent        Calibre-Web

2 sent / 0 suppressed, where the day before the identical shape gave one of each.

And the keys, from the hub's own suppression rows — it records the key only when it declines:

operator cooldown 1h, key=demo-hp:app_start_failed:opengist
operator cooldown 1h, key=demo-hp:app_start_failed:calibre-web

against v0.107.0's shared key=demo-hp:app_start_failed.

The fence, and why it is not decoration

crossdrive_failed is severity error, reaches the operator leg, and carries stack_name — through CrossDriveDetails, a different struct from AppDetails. A rule of the form "if the details carry a stack_name, split per app" would have split it and silently undone R-182.

Proven live: two different apps' crossdrive_failed, one minute apart →

sent        opengist
suppressed  calibre-web    operator cooldown 1h, key=demo-hp:crossdrive_failed

Byte-identical to the derived v0.107.0 key. No app suffix. That is why cooldownStackSuffix takes the event type as well as the details, unlike its two siblings.

Part 2 — the burst, measured

Three apps stopped in one scan (kimai, romm, paperless-ngx, none with a live cooldown — checked first, because a stale one would have halved the count and made the answer look better than it is):


attempted	3
sent	3
suppressed	0

Judgement: per-app is the right grain, and this volume is acceptable. The reference box has 8 deployed apps, so a total outage is 8 mails; the boot grace (90 s), the quiesce grace (180 s) and the per-app edge trigger absorb reboots, backup cycles and persistently-dead apps. No digest row was filed. The reopening condition is stated rather than left implicit: it scales linearly with app count and has no ceiling, so a box large enough that a total outage is unreadable is the point at which the answer becomes a digest with a customer message — not a wider cooldown.

Part 3 — gate 11, and the spec discrepancy it forced

The gate refuses a push whose REPORT.md carries an observation with neither FILED: R-NNN nor NOT-A-FINDING: <reason>.

The specification said an item may "cite an R-NNN that resolves". That rule would have passed the very item the gate was built to catch. Yesterday's lost observation reads "This is R-182's known cooldown-key shape…" — R-182 resolves, and it is cited as an analogy, not as the row that files it. No parser can tell citation-as-precedent from citation-as-filing by reading prose. The marker is therefore explicit, and the discrepancy is recorded in the gate's docstring rather than quietly resolved. EDGE 7 in the evidence is that exact case, convicted.

Control	Expected	Observed
historical: yesterday's real section, verbatim	refuse	exit 1, naming both items
plant an observation with no row	refuse	exit 1
add the row	pass	exit 0
remove the observation	pass quietly	exit 0
`FILED:` a row that does not resolve	refuse	exit 1
`NOT-A-FINDING:` with no reason	refuse	exit 1
both markers on one item	refuse	exit 1
section present, no numbered items	inconclusive	exit 2, saying what it could not read
no `REPORT.md` at all	inconclusive	exit 2
a bare `R-182` mention (the trap)	refuse	exit 1

Evidence index (`evidence/`)

File	What it shows
`redproof-1-key.txt`	suffix dropped from the key → `1 operator mail(s), want 2`, and the live key shape reproduced
`redproof-2-allowlist.txt`	allow-list removed → `crossdrive_failed`, `app_deployed`, `app_removed`, `backup_failed` all split per app
`gate11-01-historical-redproof.txt`	yesterday's actual observations section, refused
`gate11-02-three-controls.txt`	plant → refuse, file → pass, remove → pass
`gate11-03-edges.txt`	seven boundaries incl. the R-182 trap
`live-01`…`live-05`	Scenarios A and B: both sent, then each suppressed under its own key
`live-06`, `live-07`	Scenario C: crossdrive stays coarse
`live-08`, `live-09`	the burst, with its pre-check
`live-10-full-controller-log.txt`	1803 lines, pulled before the restore

Teardown

Nothing provisioned. Five apps were stopped across the walk (opengist, calibre-web, kimai, romm, paperless-ngx) and all were restarted and confirmed healthy — 17 containers up. No app was rebuilt, redeployed or restored; the three retained subjects (docmost, bookstack, privatebin) were not touched at all.

Hub-side, stated explicitly. The hub was written this session: deployment to v0.108.0 via the manifest, and six probe events were POSTed to the live hub for Scenarios B and C (two app_start_failed, two crossdrive_failed, plus the two from yesterday's Scenario H that were deliberately left in place). They are inert event rows for demo-hp and are named here rather than left to be found. Every count in this drill is filtered by created_at >= T0 precisely so those rows cannot contaminate it. Nothing else: no appliance registered, no customer created, no artifact manifest changed, floor untouched.

README.md