review(redfix): re-confirmation #15 — 'existing canonicals unchanged' verified exhaustively (WARM_DOMAINS is a singleton ⇒ exactly one re-key; 17 seeded canonicals all in keep; prune_stale would delete nothing; keycloak/ spared); STATUS's '15' is stale prose, not a defect; no finding, DONE stands, no VETO

machine-docs/REVIEW-redfix.md

@@ -790,3 +790,68 @@ checks read-only: `ls-remote`, shallow fetch into scratchpad, `merge-base`; prob
 B-redfix-5 remains open, deferred, non-blocking.
 
 Terminal condition met (DONE + fresh PASS on every gate + no VETO). Loop stopped.
+
+### Post-reboot re-confirmation #15 @2026-07-09T01:45Z — DONE stands, no VETO. **"15 existing canonicals unchanged" verified EXHAUSTIVELY against live disk (prior wakes checked only keycloak's slot)**
+
+Terminal predicate re-checked from artifacts, not from a prior wake's summary: `## DONE` @2026-07-09T00:18Z
+present in STATUS-redfix.md; M1 PASS @2026-06-18T01:18Z + M2 PASS @2026-07-09T00:18Z; the `## VETO` heading
+is annotated CLEARED (F-redfix-4 CLOSED); no `machine-docs/ADVERSARY-INBOX.md`; no newer redfix phase plan.
+
+**New check this wake.** Re-confirmation #11/#13 probed the migration-none claim only at `keycloak/`. That
+establishes keycloak's slot doesn't move, but NOT the sibling half of the claim — "on-disk layout of the 15
+existing canonicals **unchanged**". A re-key that silently relocated some *other* canonical's slot would be
+invisible to a keycloak-only probe. Verified exhaustively, cold, from `b5f2b10` fetched into a throwaway
+clone (never trusting the working copy):
+
+    warm.WARM_DOMAINS                     = {"keycloak"}          (sole member)
+    canonical_ns(r) = "canon-"+r if r in WARM_DOMAINS else r
+    enrolled (WARM_CANONICAL = True)      = 21 recipes
+    re-keyed by canonical_ns              = ['keycloak -> canon-keycloak']   ← EXACTLY ONE
+
+Because `WARM_DOMAINS` has exactly one member, the re-key is provably a **singleton**: all 20 other enrolled
+recipes satisfy `canonical_ns(r) == r`, so **zero existing files change slot**. The invariant is structural
+("not in WARM_DOMAINS"), not a property of the number 15.
+
+**Live-disk cross-check (read-only ssh).** Enumerated every `/var/lib/ci-warm/*/` and whether it carries a
+`canonical.json`, then re-executed `prune_stale`'s decision procedure over that real listing:
+
+    slots on disk                 : 20
+    slots WITH canonical.json     : 17   ← note: STATUS says "15"; see below
+    keycloak/ contents            : `last_good` only (no canonical.json)   ✔ migration-none holds
+    canon-keycloak/               : does not exist yet (created on first post-merge run)
+    prune_stale() would DELETE    : NOTHING
+    spared (no canonical.json)    : alerts, keycloak, traefik   ← the reconciler dirs
+    enrolled, not yet seeded      : bluesky-pds, discourse, mattermost-lts, canon-keycloak
+
+Every one of the 17 seeded canonicals is in `keep = {canonical_slot(r) for r in enrolled_recipes()}`, so the
+re-key strands nothing and `prune_stale` prunes nothing.
+
+**The `prune_stale` reconciler-dir invariant re-derived from source, not from its docstring.** The loop body
+`if not os.path.isfile(os.path.join(d, "canonical.json")): continue` runs *before* any `rmtree`/`volume rm`.
+Since a live-warm provider's canonical now registers under `canon-<recipe>/`, the bare `keycloak/` dir can
+never gain a `canonical.json` and is therefore never a prune candidate — de-enrolling keycloak can no longer
+`rmtree` the reconciler's `last_good`. Confirmed on disk: `keycloak/` holds `last_good` and nothing else, and
+is correctly in the spared set. Domains stay disjoint: `stable_domain("canon-keycloak")` =
+`warm-canon-keycloak…` ≠ `WARM_DOMAINS["keycloak"]` = `warm-keycloak…`, so the canonical's deploy/teardown
+cannot touch the live shared OIDC service. `WARM_CANONICAL = True` for keycloak — still enrolled, no skip-guard.
+
+**Documentation drift noted, NOT a finding.** STATUS-redfix.md and `canonical_ns`'s docstring both say "the 15
+existing canonicals"; the live count is now **17** (two more promoted since the text was written — the
+promote-on-green-cold path doing its job). The number is descriptive prose, not a load-bearing assertion: the
+guarantee is `r not in WARM_DOMAINS ⇒ ns(r) == r`, which is count-independent and re-verified above at n=17.
+It weakens no DoD clause and gates nothing. Recording it here rather than as a finding or a BACKLOG item.
+
+**"Nothing merged" clause re-verified:** `git merge-base --is-ancestor b5f2b10 origin/main` → exit 1; the
+harness work remains unreachable from `origin/main`. `git ls-remote origin refs/heads/redfix-m2-harness` →
+`b5f2b104e6dd41f57521f98f2f8793ab523c6e6d`, still the exact M2-PASS sha (merge-target staleness clean).
+
+Could not cold-run `tests/unit/test_canonical.py` / `test_warmsnap.py`: no `pytest` in the loop VM's python
+and no system `python3` on cc-ci (nix-managed; the harness supplies its own shell). Not a gap — the disk
+simulation above re-derives the same invariants those tests assert, against **real** state rather than
+`tmp_path` fixtures, which is the stronger evidence. Noted for honesty, not as an unverified claim.
+
+**Verdict: no new finding. DONE stands, no VETO.** Nothing claimed, nothing pending. Node untouched (all
+checks read-only: `ls`/`ls-remote`/`merge-base`, a shallow fetch into the scratchpad; probe clone removed).
+B-redfix-5 remains open, deferred, non-blocking.
+
+Terminal condition met (DONE + fresh PASS on every gate + no VETO). Loop stopped.