From 8e15def15dcd04902b12756ccf4fc94b55455a8c Mon Sep 17 00:00:00 2001 From: autonomic-bot Date: Wed, 17 Jun 2026 12:22:52 +0000 Subject: [PATCH] review(canon): acceptance bar for gitea-exception (VERIFY custom-html advance really promoted + gitea app.ini-RO is recipe not machinery mount) + M2.3 reframing (accept IFF 2nd sweep: 15 skip / only documented exceptions run; flag as literal-DoD deviation for operator) --- machine-docs/REVIEW-canon.md | 30 ++++++++++++++++++++++++++++++ 1 file changed, 30 insertions(+) diff --git a/machine-docs/REVIEW-canon.md b/machine-docs/REVIEW-canon.md index fafc171..ac12262 100644 --- a/machine-docs/REVIEW-canon.md +++ b/machine-docs/REVIEW-canon.md @@ -418,3 +418,33 @@ preview already visible IN this run: n8n/plausible/uptime-kuma/immich/lasuite-*/ `SKIP no-new-version` = the just-promoted recipes correctly skip. Builder consumed my gitea heads-up (9303359: "gitea 3.6.0 advance — fixing; drone promoted clean"). Awaiting gitea fix + M2.3/M2.5/M2.6/ M2.7/M2.8 proofs before any M2 claim. + +## Pre-claim assessment @ 2026-06-17T12:21Z — gitea-exception diagnosis + M2.3 reframing (my acceptance bar) + +Builder landed bdc2ec4 (DECISIONS): gitea 3.6.0 warm-advance documented as a RECIPE issue + an M2.3 +determinism reframing. My standard for accepting these at the M2 claim: + +**gitea 3.6.0 exception — diagnosis plausible; two things I will independently verify (not take on faith):** +- Builder's isolation claim is the right shape: the warm-ADVANCE machinery is proven via a CONSTRUCTED + custom-html older→new advance (M2.6), so gitea's failure is gitea-specific not machinery. VERIFY the + custom-html advance ACTUALLY promoted (canonical advanced old→new, healthy) — that's load-bearing. +- The gitea crash is `JWT Secret … app.ini: read-only file system`. Cold FRESH 3.6.0 passes; warm + reattach-advance crashes. VERIFY this is genuinely a gitea-3.6.0/rootless-config + retained-volume + interaction (e.g. pre-existing 3.5.3 app.ini / rootless-UID), NOT our warm-promote mounting app.ini + read-only. If OUR machinery makes app.ini read-only (cold doesn't, warm does), it's a MACHINERY defect + mislabeled as a recipe issue — that would NOT be an acceptable exception and would fail M1(A)/M2. + Check: how does the warm advance mount/derive app.ini vs the cold install for gitea. +- gitea correctly KEEPS 3.5.3 (never promote unhealthy) — good; confirm 3.5.3 record + volume intact. + +**M2.3 reframing — ACCEPTABLE ONLY IF rigorously demonstrated + flagged as a DoD deviation.** Plan +§3/§5 LITERALLY say run-twice → "SKIPS every recipe … clean no-op". That ideal assumed all-promote; +reality = 15 promoted-at-latest + 5 that can't (4 genuine/documented reds + gitea recipe-bug). Builder's +operative property = "no promoted-at-latest recipe re-runs; reds + gitea correctly retry." This is +plan-consistent in SPIRIT (the no-op's purpose is no needless re-test of good-current recipes) and the +plan forbids weakening tests to force promotes — so the literal ideal is unachievable honestly. I will +ACCEPT it IFF: (i) an actual immediate 2nd sweep shows EXACTLY the 15 promoted-at-latest SKIP (no CI +rerun) and ONLY the documented exceptions (gitea + 4 reds) RUN — I will re-run/inspect this myself, not +trust a summary; (ii) every re-running recipe has a recorded DECISIONS reason; (iii) it is explicitly +noted as a deviation from the literal "skip every recipe" so the operator sees it. If a promoted-at- +latest recipe needlessly re-runs, or an undocumented recipe re-runs, M2.3 FAILs. NOT a veto now — this +is the bar I'll hold at the claim.