admin
9c69b3ff07
gates / gates (push) Successful in 27s
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
40 lines
2.7 KiB
Markdown
40 lines
2.7 KiB
Markdown
# Draft — the line to append to the capability map's UPDATE row (`00-capability-map.md` line 105)
|
|
|
|
*(Appended to the existing "Update is GUARDED …" row's evidence column. `<…>` filled at the end.)*
|
|
|
|
---
|
|
|
|
**WIDENED 2026-09-21 (the update night) from 3 apps to `<N>`, and NARROWED in one place by the same
|
|
run.** `audits/DRILL-update-night-2026-09-21.md`. On scratch guest 9202 (controller v0.261.0),
|
|
against a **private drill catalog** so the live catalog carried no test reference at any point,
|
|
`<N>` real within-a-major upstream edges were walked through the product's own guarded Update, each
|
|
app seeded and read back **through its own front door** (R-156) with a negative control on every
|
|
readback: **`<P>` proven, `<F>` failed, `<I>` inconclusive.**
|
|
|
|
**What the PROVEN edges prove, precisely:** the app moved, the four version observables agreed, and
|
|
the data the app itself was given came back through the app's own interface afterwards. `<MIG>` of
|
|
them printed a verbatim migration line.
|
|
|
|
**What the FAILED edges prove, and they are the more valuable half.** `<FAILED_LIST>`.
|
|
`adventurelog v0.12.1 → v0.13.0` applied **nine database migrations successfully** and then never
|
|
bound its port; the update held after the full health wait, the hold sentence named the tier, the
|
|
date and what the copy holds, and the restore the sentence names brought the app back. **That is
|
|
this row's own promise, exercised on a real upstream edge rather than a staged one.**
|
|
|
|
**AND THE NARROWING, which this row must carry because it is the same mechanism:** the `verifying`
|
|
phase trusts the `.felhom.yml` probe absolutely, and **two of the 53 templates name a probe the app
|
|
does not answer** — `tandoor` (port 8080; it listens on 80) and `zipline` (`/api/health`; it answers
|
|
404 there, while the compose healthcheck in the same file uses `/api/healthcheck` and is green).
|
|
For those apps a **successful** update is stopped by its own health wait: tandoor was measured
|
|
**serving HTTP 200 on the new version at four samples across five minutes**, with docker's own
|
|
healthcheck green, and was then stopped by `failAndHold` and the household sent to a restore they
|
|
did not need. **R-618, P1.** No data was lost and the restore works — but "the update is guarded"
|
|
must not be read as "the guard is right about whether the app came up".
|
|
|
|
**Still true and unchanged:** no automatic rollback (by measurement); the route back is the restore;
|
|
a multi-major jump ends held honestly.
|
|
|
|
**Not measured on this venue, and named rather than assumed:** every event and every customer mail.
|
|
Guest 9202 runs `hub.enabled: false` and the notifier returns before it logs (**R-620**), so the
|
|
whole "who was told" half of `08` was structurally unobservable tonight.
|