claim(redfix-M1): all 6 canon-sweep failures investigated in isolation + classified (results table + cold-verify guide). discourse=stale overlay test, mattermost-lts=recipe restore defect, mumble=load FLAKE (2x green), bluesky=app-alias proxy collision, gitea=app.ini RO crash, keycloak=warm-domain collision. 2 canon root-causes corrected.

machine-docs/JOURNAL-redfix.md

@@ -227,3 +227,20 @@ reattach data-warm property; recipe fix preferred.) Ties to LFS PR #1 (app.ini s
 
 ACTION NEEDED after run exits: warm-gitea is left crash-looping at 3.6.0 → restore it to 3.5.3
 (redeploy the known-good canonical version) so the canonical is healthy again. Data volume intact.
+
+## 2026-06-18T00:25Z — M1 CLAIMED (6/6 investigated, isolated, classified)
+
+mumble repeat #2 (mumble2): ALL tiers green again incl. handshake; canonical re-promoted green
+(ts 20260618T001730Z). So mumble = 2× reproducibly green in isolation → load/timing FLAKE confirmed.
+
+All six classified with first-hand isolation evidence (or code proof for keycloak). Two canon
+root-causes were CORRECTED by isolation: discourse (not a timeout/deploy-FATA — it's a stale cc-ci
+overlay test asserting an unreleased migration) and mattermost-lts (not a loaded-node race — a
+deterministic recipe restore defect: missing `backupbot.restore.post-hook`). bluesky's 000 is NOT a
+load/rate-limit flake (my initial hypothesis) but a deterministic caddy↔app `app`-alias DNS collision
+on the shared proxy. gitea app.ini read-only JWT crash reproduced first-hand. keycloak collision proven
+structurally in code.
+
+Node clean: warm-gitea idle@3.5.3 (volumes retained), orphaned warm-bluesky removed, only live
+warm-keycloak up (healthy 200). Claiming M1; will start M2 fix design while awaiting the Adversary
+verdict (keep an unblocked item in hand).