review(canon): pre-fix sweep DONE (15 canonicals); NEW red mumble rc=1 (must fix-or-document); plausible promoted 3.1.0+v2.0.0 not 3.0.1 → §2.8 retirement must re-derive dynamic base vs actual canonical

machine-docs/REVIEW-canon.md

@@ -346,3 +346,20 @@ Conclusion: footgun is structurally mitigated AND live-confirmed unharmed — fa
 CLAIM: confirm NO OTHER enrolled recipe's `canonical_domain` collides with a live/shared service (so the
 fresh-seed teardown only ever hits a disposable warm-<recipe> stack), and that the final sweep's keycloak
 absence holds at the sweep's launch HEAD.
+
+## Pre-claim observation @ 2026-06-17T11:23Z — pre-fix sweep FINISHED (0 procs); 15 canonicals
+
+Final tail of the pre-fix serial sweep (1741209): n8n PASS(3.4.0+2.23.2), plausible
+PASS(3.1.0+v2.0.0), uptime-kuma PASS(3.1.0+2.4.0); **mumble rc=1 FAIL (red; canonical unchanged)**.
+Canonical count = 15. Two new claim-scrutiny points:
+- **mumble — NEW red (rc=1, not a timeout), not previously documented.** Before M2 it must be either
+  fixed (promotes clean) or recorded as a DECISIONS exception with a reason — a silent no-canonical is
+  not acceptable (same bar I'm holding bluesky/discourse/drone to). Watch for the diagnosis.
+- **plausible promoted at `3.1.0+v2.0.0`, NOT the `3.0.1` the plan §2.G anticipated.** The §2.8
+  UPGRADE_BASE_VERSION retirement reasoning ("canonical at 3.0.1 → dynamic base resolves 3.0.1 → pin
+  redundant, drop the broken 3.0.0") must be RE-DERIVED against the actual canonical 3.1.0+v2.0.0: at
+  claim verify that with plausible's real canonical, the dynamic upgrade base resolves to a correct
+  green release (NOT the broken 3.0.0 clickhouse-404 base) and plausible's upgrade tier passes — only
+  then is dropping the pin safe. If not, the pin stays with a recorded reason (§2.G GATE).
+Builder's plan next: deploy fixes to /etc/cc-ci, re-promote drone (fresh-seed fix) + retry gitea 3.6.0,
+then launch the FINAL authoritative sweep = the M2.2 evidence (postdates ca89d44+d072d7e, enrolled=20).