Evidence off the machine at the end of the phases that produced it (R-320). Teardown follows. PHASE 2 — the two database engines, through the REAL Update button: - MariaDB 11.6 -> 12.3 on nextcloud: PROVEN, and pressed through the button for the first time. All four SPIKE-r459 observables: the datadir's own record moved 11.6.2 -> 12.3.3; the engine itself says "already upgraded ... no need to run mariadb-upgrade again"; the entrypoint says "Major version upgrade detected ... Check required!" and then STARTED and FINISHED it (not the `skipped due to $MARIADB_AUTO_UPGRADE` line R-459 feared); and the engine took its own pre-upgrade backup, 631 905 B. The seeded Nextcloud account read back. - PostgreSQL 16 -> 17 on docmost: FAILED exactly as R-463 predicted and nobody had measured. 5.1 s to held; the pin named 17 while nothing ran; the restore brought it back in 29.1 s. The engine's REFUSAL LINE was destroyed by failAndHold before any probe could read it, so it was REPRODUCED INDEPENDENTLY with a control on every step (R-320). PHASE 3 — the bad days. B1 produced THE UNATTENDED HOLD, which this project has never had: the caller pressed once with nobody watching, the app held after 312.9 s, and passes 2 and 3 pressed nothing. B2 put the pin back on a pull failure in 1.0 s. B3 refused `busy` six times. B4 showed there is NO single-flight — 5 of 5 updates ran at once and all ended honest. B5 cut the power in `backing-up` and the box recovered itself and said so. B7 refused under the 2 GB floor. B9 found R-458's risk narrower than the row states. PHASE 4 — every badge on the box is TRUE, and the held app answers all four of Q4's questions. FINDINGS, five new and three corrections to existing rows. The one that matters: R-618 is P1 — two templates name a health probe the app does not answer, and because the guarded update waits on that same probe, a SUCCESSFUL update ends by STOPPING a working app. Measured: tandoor served HTTP 200 on the new version at four samples across five minutes and was then stopped. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0159rPz1ZhFKsS53msqPYxtS
2.1 KiB
The alarm truth table for the update night, scored against 08-alarm-ladder.md
READ THE LIMIT FIRST, because it bounds every row. Guest 9202 runs with hub.enabled: false.
Every notifier entry point returns before it logs anything (notify/notifier.go:269, :359, :917, :959, :1058), so no hub event and no customer mail could be produced or observed tonight. The
hub was not enabled on 9202 to get around this: that would register an unclaimed host at the live
hub and could mail a real address, and the brief fences the hub. Filed as R-620.
So this table scores the surfaces that DO exist here — what the household READS (the app page, the dashboard, the backups page) and what the box's own log records — and says "unmeasurable here" for the send side rather than leaving a blank that could be read as "nothing fired".
| # | what happened | should it alarm, per 08 |
did the box classify it that way | what the household could READ | verdict |
|---|
The three things this table is for
1. Which alarm fired and was it true.
2. Which should have fired and did not.
3. The one that is structurally invisible on this venue. Every row's "who was told" column is
answered only for the SCREEN. 08 §6.1's severity contract and §6.2's delivery grain were not
exercised at all, and no row below may be read as evidence about them.
A note on unhealthy, because two of tonight's findings turn on it
08 §4 puts unhealthy deliberately in the NOT-down set — "a running container whose
healthcheck is failing. Folding it in reintroduces the flapping fix-3 was written to stop." That
ruling is why tandoor and zipline reading unhealthy all night produced no alarm at all, and it
is the right ruling. But R-618 shows the cost of the other half of that decision: the same probe
result that is correctly ignored by the alarm ladder is NOT ignored by the guarded update's
verifying phase, which waits on it and then stops the app. One probe, two consumers, opposite
tolerances — and nothing says so in either document.