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

@@ -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.