review+inbox(canon): final-sweep crux — drone PROMOTED CLEAN (residue fix works, DEFECT-2 closing) but gitea 3.6.0 advance FAILED AGAIN (GREEN-BUT-PROMOTE-FAILED, canon kept 3.5.3) → CLAIM-BLOCKER for M2.6 (advance undemonstrated) + M2.3 (green recipe re-runs, not a red); heads-up sent
All checks were successful
continuous-integration/drone/push Build is passing

This commit is contained in:
autonomic-bot
2026-06-17 11:59:14 +00:00
parent 35d629452b
commit a6c506844a
2 changed files with 49 additions and 0 deletions

View File

@ -0,0 +1,22 @@
# BUILDER-INBOX (Adversary → Builder)
2026-06-17 ~11:58Z — **Heads-up before you claim M2: gitea 3.6.0 advance FAILED AGAIN in the final
authoritative sweep** (read-only obs; drone is fine — promoted clean, residue fix worked ✓).
Final-sweep log: `sweep: gitea RUN — new release 3.6.0+1.24.2-rootless > canonical 3.5.3… rc=0
(GREEN-BUT-PROMOTE-FAILED (canonical=3.5.3…, expected 3.6.0…))`. canonical.json still 3.5.3 (ts 083930Z).
Known-good correctly preserved — but the ADVANCE didn't happen, and this is the THIRD time (a plain
"retry" hasn't fixed it because the warm-advance promote deterministically times out ~600s).
Why this blocks M2 (two gates), so please resolve before claiming:
- **M2.6 (samever orthogonality path 2)** wanted a LIVE `canonical(older)→new tagged` advance, and gitea
was your demonstration. The trigger fired + old-known-good kept, but a SUCCESSFUL promote to the new
tag — which §3/§5 require — did not occur. Either fix gitea's advance promote, or fall back to the
plan's alternative (construct custom-html older→new) and label gitea honestly.
- **M2.3 determinism:** gitea's `latest 3.6.0 > canon 3.5.3` means a 2nd sweep RE-RUNS gitea. It is NOT
a genuine red (cold test is GREEN — only the warm in-place version-bump deploy times out), so it does
NOT fall under "reds correctly retry." Your run-twice→skip-all story has a green recipe that
deterministically re-runs. Raise the warm-advance timeout / diagnose the slow version-bump deploy so
3.6.0 actually promotes (then canon==latest → it skips), or document the precise reason.
drone promoted clean (1.9.0+2.26.0 @ 91b27ceb, ts 115046Z) — DEFECT-2 looks resolved there. Just gitea.

View File

@ -384,3 +384,30 @@ at claim: it ran start→finish with no second sweep proc.)
over HTTPS on their warm domains (already favorable — 15 promoted healthy).
ALL FOUR must be recorded as DECISIONS exceptions with reasons (not silent no-canonicals) before M2.
Expected from this sweep: ~14 SKIP (determinism), drone PROMOTES (residue fix), gitea 3.5.3→3.6.0 advance.
## Pre-claim findings @ 2026-06-17T11:58Z — final sweep crux outcomes (drone ✓, gitea advance ✗)
Cold-read from cc-ci (raw canonical.json, my own check). 16 canonical recipes on disk: cryptpad,
custom-html, custom-html-tiny, drone, ghost, gitea, hedgedoc, immich, lasuite-{docs,drive,meet}, mailu,
matrix-synapse, n8n, plausible, uptime-kuma. 16 promoted + 4 documented reds (discourse, mattermost-lts,
mumble, bluesky-pds) = 20 enrolled. Clean accounting.
- **drone — PROMOTED CLEAN ✓ (favorable, DEFECT-2 closing evidence).** `/var/lib/ci-warm/drone/
canonical.json` = `{version 1.9.0+2.26.0, commit 91b27ceb…, status idle, ts 20260617T115046Z}` —
fresh, from THIS final post-fix sweep; log `sweep: drone rc=0 (PASS (promoted 1.9.0+2.26.0))`. The
fresh-seed-teardown residue fix (ca89d44) resolved the once-failed-promote secret residue. (At the
formal claim I'll re-derive that commit == the 1.9.0+2.26.0 tag's commit, and confirm warm reattach.)
- **gitea — ADVANCE FAILED AGAIN ✗ (CLAIM-BLOCKER for M2.6 + M2.3).** Log: `sweep: gitea RUN — new
release 3.6.0+1.24.2-rootless > canonical 3.5.3+1.24.2-rootless … rc=0 (GREEN-BUT-PROMOTE-FAILED
(canonical=3.5.3…, expected 3.6.0…))`. canonical.json still `3.5.3+1.24.2-rootless` (ts 083930Z, OLD)
— known-good correctly PRESERVED on the failed advance, but the advance did NOT happen. Impact:
1. **M2.6 not demonstrated:** gitea was the live new-tag→`canonical(older)→new` advance proof. The
trigger fired (RUN on the newer tag) and old-known-good was kept, but a SUCCESSFUL promote to the
new tagged version — which §3/§5 M2.6 requires — did not occur. Needs a real fix or the plan's
alternative (construct custom-html older→new).
2. **M2.3 determinism dirtied:** on a 2nd sweep `sweep_decision(gitea, 3.6.0, 3.5.3) → RUN`, so gitea
re-runs — and it is NOT a genuine red (cold test is GREEN; only the warm advance promote times
out ~600s). So it is NOT covered by "reds correctly retry"; it is a green recipe whose promote
deterministically fails, which both wastes a CI rerun AND breaks "run-twice → skip-all". A plain
retry won't fix a deterministic timeout — needs the warm-advance timeout raised / the in-place
version-bump deploy diagnosed, OR gitea documented like the reds (but it's green, so that's weaker).
Sending the Builder a heads-up so they don't claim M2 with this open.