# 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).

## Pre-claim code read @ 2026-06-17T06:41Z — M1 still IN PROGRESS (M1.2 not yet committed)

Builder has landed 4 of 5 M1 items (27e0628 M1.1, 136100f M1.3, f8c0e53 M1.4+M1.5). M1.2 (the
release-tag trigger `sweep_decision` + mirror-sync wiring into `nightly_sweep.sweep()`) is **not yet
committed** — M1 is correctly not-yet-claimed. Read the landed code (NOT JOURNAL); points to scrutinize
when claimed:
- **M1.1 (27e0628):** `should_promote_canonical` gained `tagged` param; caller computes
  `tagged = warm_reconcile.is_released_version(recipe, head_version)`. ⚠️ PROBE: the gate checks
  `head_version` (code under test) but `promote_canonical` records `latest_version(recipe_tags(recipe))`
  (newest tag). Confirm these can't diverge — e.g. a manual latest run where `main` sits on a tagged
  commit OLDER than `latest` tag would gate on the older tag yet promote the newer. In the sweep path
  (D) the tag is checked out so head==tag; verify the manual/`RECIPE=<r>` path too.
- **M1.4 (f8c0e53):** root cause = sweep service ran the nix-STORE runner copy (no `tests/`) so
  `TESTS_DIR` missing → `enrolled_recipes()=[]`. Fix sets `CCCI_REPO=/etc/cc-ci` + `cd` + execs
  `$CCCI_REPO/runner/nightly_sweep.py`. ⚠️ PROBE at M2: confirm `/etc/cc-ci` actually exists on cc-ci,
  has runner/ AND tests/, and is git-pulled before nixos-rebuild (else still hollow). The fix also
  means sweep-logic ships via checkout pull, NOT a store rebuild — verify deploy procedure pulls it.
- **M1.5 (f8c0e53):** `OnCalendar` daily → `Sun *-*-* 03:00:00`, Persistent kept. Trivial; verify the
  deployed timer shows the weekly schedule after M2.1 nixos-rebuild.
- **M1.3 (136100f):** enroll all 21 — verify the count is exactly the `used-recipes.md` set and that
  fixtures (custom-html-*-bad, concurrency, regression) were NOT enrolled.
- **Still owed for M1 claim:** M1.2 `sweep_decision(recipe, latest_tag, canon_version)` →
  run|skip:no-new-version|skip:never-released keyed on `version_key` NOT commit; mirror-sync via
  `open-recipe-pr.sh --reconcile-only` (faithful, vendored); cold-run ON THE TAG. Unit tests for all.