cc-ci/machine-docs/REVIEW-canon.md

REVIEW-canon — Adversary verdicts for the canon (canonical-sweep) phase

SSOT for what is being verified: /srv/cc-ci/cc-ci-plan/plan-phase-canon-canonical-sweep.md. Gates: M1 (machinery works locally, each piece proven) and M2 (proven end-to-end in real CI), plus the operator-required samever-orthogonality proof. ## DONE only after fresh PASS on both.

---

Orientation @ 2026-06-17T06:18Z — Adversary online for canon phase; no gate claimed yet

Prior phase samever is DONE + Adversary-verified (M1 1310a95, M2 199f5b6, no VETO). The canon phase has not been bootstrapped by the Builder yet: no STATUS-canon.md / BACKLOG-canon.md, no claim(/status(canon commits, no inbox. I am idling per liveness protocol and will verify promptly when M1 is CLAIMED (watchdog will ping on the claim).

Independent COLD baseline of the claimed starting state (§1) — captured before any canon work

Verified from my own clone + a cold ssh cc-ci, NOT from the Builder:

• Enrollment: exactly one recipe sets WARM_CANONICAL = True → custom-html. (grep -rl 'WARM_CANONICAL *= *True' tests/*/recipe_meta.py → 1 hit.) Matches §1 "only custom-html enrolled".
• canonical.json records on cc-ci: exactly one, for custom-html: /var/lib/ci-warm/custom-html/canonical.json = {recipe: custom-html, version: 1.13.0+1.31.1, commit: 2b82ebabde74a9d9b1fd4cb49722a7037b18a176, status: idle, ts: 20260617T050314Z}, retained volume warm-custom-html_..._content present.
  • NOTE — plan §1 is now slightly stale. The plan (authored 04:43Z) says "ZERO canonical.json records exist." That was true at authoring, but the just-completed samever M2 e2e (custom-html two-run) wrote this record at 05:03:14Z. So there is now exactly one canonical, produced by samever's promote path. This is favorable evidence for canon M1(A) — the promote path already demonstrably writes a real, reusable record + retains the volume for custom-html — but the Builder must NOT cite custom-html's pre-existing canonical as proof of canon's new work (tagged-gate, trigger, all-enrolled, mirror-sync). I will require fresh, canon-attributable evidence for each M1/M2 sub-claim.
• Timer: nightly-sweep.timer enabled+active, daily OnCalendar (NEXT 2026-06-18 03:00:24 UTC), last fired 2026-06-17 03:09:20 UTC exit 0. So the timer plumbing works; the job was a near-no-op (only custom-html enrolled). Phase must (F) move this to weekly and (M2) prove a real fire advances canonicals, not exit-0 on an empty set.

What I will adversarially probe when claimed (from the plan, not the Builder's narrative)

• M1(A): a canon-attributable green cold run writes canonical.json AND --quick warm-reattach reuses it; promote now ALSO requires a release tag — feed an UNTAGGED state, confirm NO promote.
• M1(C): mirror-sync is faithful upstream sync only — never pushes our changes to mirror main, never disturbs unrelated PRs. Will diff before/after on a mirror.
• M1(D): trigger keyed on latest release tag vs canonical version, NOT commit — new untagged commits on main with same tag ⇒ SKIP; newer tag ⇒ run cold on that tag.
• M1(B): all ~21 recipes enrolled; warm-volume disk budget recorded (not silently dropped).
• M2: full sweep promotes greens / leaves reds intact / skips unchanged; run-twice ⇒ skip-all determinism; real (non-hollow) timer fire; tagged-promote proof (untagged green ⇒ no promote).
• samever orthogonality: (a) no-new-tag ⇒ SKIPPED; (b) new-tag ⇒ canonical(older)→new, real delta, promote; step-back NEVER fires in the sweep. Construct scenarios if the live set doesn't cover both.
• §2.G: if plausible's canonical lands at 3.0.1, UPGRADE_BASE_VERSION retired cleanly (key + resolver branch + docs + tests) AND plausible still resolves base 3.0.1 dynamically + passes — else kept with a recorded DECISIONS reason. Will re-derive, not trust.
• Guardrail: NO AI at runtime (pure script + timer).