From 4accd22d50b5d4cf90e166839b84892b90935961 Mon Sep 17 00:00:00 2001 From: autonomic-bot Date: Wed, 17 Jun 2026 09:35:11 +0000 Subject: [PATCH] =?UTF-8?q?review(canon):=20pre-claim=20observations=20?= =?UTF-8?q?=E2=80=94=20DEFECT-1=20label=20fix=20live/honest;=20NEW=20mirro?= =?UTF-8?q?r-sync=20drone=20rc=3D128=20swallowed=20(scrutinise=20=C2=A72.C?= =?UTF-8?q?);=20determinism=20M2.3=20run-twice-skip-all=20at=20risk=20for?= =?UTF-8?q?=20red/promote-failed=20recipes?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- machine-docs/REVIEW-canon.md | 27 +++++++++++++++++++++++++++ 1 file changed, 27 insertions(+) diff --git a/machine-docs/REVIEW-canon.md b/machine-docs/REVIEW-canon.md index 711332b..801b58e 100644 --- a/machine-docs/REVIEW-canon.md +++ b/machine-docs/REVIEW-canon.md @@ -233,3 +233,30 @@ Staying read-only off the node (sweep in flight, single node). actually answered 200 over HTTPS on THEIR warm domains during promote (grep ready-probe lines), and (b) independently curl a couple of the live warm canonical domains. If warm-domain routing is broadly unreliable, the promote evidence is suspect and M2 is not done. + +## Pre-claim observation @ 2026-06-17T09:34Z — read-only sweep-progress peek (NOT a verdict) + +Sweep re-run still in flight (proc 1712141 from `/etc/cc-ci/runner`); 7 canonicals on disk. Captured +from `_sweep.log` so it survives log growth: +- **DEFECT-1 fix is LIVE and honest:** `sweep: bluesky-pds rc=0 (GREEN-BUT-PROMOTE-FAILED + (canonical=none, expected 0.3.0+v0.4.219))` — the label no longer claims `PASS (promoted)` on a + failed promote. Favorable; I will still confirm the label matches the on-disk registry per recipe at + claim before closing DEFECT-1. +- `cryptpad / custom-html / custom-html-tiny` → `SKIP no-new-version` (latest tag == canonical). The + skip path works for promoted recipes. +- `discourse rc=143 → FAIL (red; canonical unchanged)` — legit red (timeout/SIGTERM), canonical kept. +- **NEW — `sweep: mirror-sync drone rc=128 (non-fatal — continuing)`:** drone's faithful mirror-sync + FAILED (git rc=128) yet the sweep proceeded to RUN drone against the un-synced mirror. SCRUTINISE at + claim: plan §2.C requires the mirror be reconciled to upstream FIRST; a swallowed sync failure means + the recipe may be tested against a stale mirror (wrong tags/version) — the trigger (D) and tagged + promote then rest on un-synced state. Is rc=128 a benign "already up to date / no upstream" case or a + real sync failure? Must check what drone's sync hit and whether the tested tag is genuinely upstream's. +- **DETERMINISM (M2.3) — central risk crystallising:** bluesky-pds (promote-failed) and discourse (red) + both end `canonical=none`, so a 2nd sweep → `sweep_decision(latest, None) → RUN`, NOT skip. Plan M2.3 + literally requires run-twice → "SKIPS every recipe." That can hold ONLY if every enrolled recipe + actually promoted. Red/promote-failed recipes legitimately re-run (no known-good to protect) — which + is arguably correct behaviour but is NOT "skip every recipe." At the M2 claim I will require the + Builder's determinism evidence to honestly reconcile this with §3/§5: either (i) every recipe promotes + so run-twice is a true no-op, or (ii) a reasoned, plan-consistent argument that the no-op property + applies to the promoted set and red recipes correctly retry — and I'll judge it against the plan, not + accept a partial skip-all relabelled as success.