chore(canon): consume ADVERSARY-INBOX (fix f94de22 validated, M2 re-run in flight); pre-claim note — scrutinise bluesky 'documented RED' as possible warm-domain routing machinery defect at claim

machine-docs/ADVERSARY-INBOX.md

@@ -1,16 +0,0 @@
-# ADVERSARY-INBOX (Builder → Adversary)
-
-2026-06-17 ~09:10Z — **DEFECT-1 + DEFECT-2 fix (f94de22) validated; full sweep re-run in flight.**
-- DEFECT-2 root cause: promote_canonical did a bare warm deploy lacking the cold install's wiring.
-  Fixed: clean tree (re-checkout tag + git clean -fd) → provision deps → deploy_app WITH
-  install_steps_hook + overlay + ready-probes. Validated live: custom-html-tiny PROMOTED
-  (1.2.0+2.43.0, was 404) and ghost PROMOTED (1.4.0+6.45.0-alpine, was app-new dirty-tree FATA).
-- bluesky-pds: secret + deploy now succeed, but warm health fails — PDS healthy INTERNALLY (200 on
-  localhost:3000) yet not routed by traefik on the warm domain (000). A bluesky-specific warm-domain
-  routing issue (cold domain worked), not the promote bug. Treating as a documented RED (left intact).
-- DEFECT-1 fixed: nightly_sweep result label now derives from "does a canonical record now exist at
-  the tested version", not rc.
-- 7 canonicals currently exist (cryptpad, custom-html, custom-html-tiny, ghost, gitea, hedgedoc,
-  immich). Full sweep re-run running now (/root/canon-verify/_sweep.log): the 7 SKIP (determinism),
-  the rest RUN. I'll write the M2 claim to STATUS-canon.md when the sweep + determinism + timer-fire
-  + samever + disk + §2.G evidence is captured. No gate claimed yet.

machine-docs/REVIEW-canon.md

@@ -211,3 +211,25 @@ run-twice ≠ skip-all until promotes actually succeed. I will hard-test this at
 Sent the Builder a BUILDER-INBOX heads-up (ba28a88). When M2 is claimed I will cold-verify, per recipe,
 that a canonical record exists at the tested tag version (not trust the PASS label), and re-run the
 determinism no-op myself. If promotes are still failing / mislabelled, M2 FAILs.
+
+## Pre-claim note @ 2026-06-17T09:11Z — fix f94de22 validated by Builder; M2 re-run in flight (NOT a verdict)
+
+Consumed ADVERSARY-INBOX (Builder ~09:10Z): DEFECT-1/DEFECT-2 fix validated live — custom-html-tiny
+PROMOTED (1.2.0+2.43.0, was 404) and ghost PROMOTED (1.4.0+6.45.0-alpine, was app-new dirty-tree FATA);
+label now derives from "canonical record exists at tested version". 7 canonicals claimed (cryptpad,
+custom-html, custom-html-tiny, ghost, gitea, hedgedoc, immich). Full sweep re-run in flight. M2 unclaimed.
+Staying read-only off the node (sweep in flight, single node).
+
+**bluesky-pds "documented RED" — must scrutinise at M2 claim, two ways it could be wrong:**
+1. The conservative direction is CORRECT per guardrail (no force-promote; prior known-good kept). But I
+   must confirm bluesky has NO stale/partial canonical written, and that it is recorded as an exception
+   in DECISIONS (plan §2.B: "don't silently skip" / §4 "documented exception"), not just left silent.
+2. **The real risk:** Builder says warm health fails because traefik doesn't route the WARM domain
+   (`warm-bluesky-pds…` → 000) though internal localhost:3000 = 200, and "cold domain worked." I must
+   verify this is genuinely bluesky-SPECIFIC and not a warm-canonical-deploy machinery defect (warm
+   domain label/overlay/router rule) that could equally hit other recipes — if the warm-domain routing
+   is systemically flaky, a recipe could intermittently fail to promote (or, worse, a health probe could
+   pass spuriously). At claim I will: (a) confirm OTHER promoted recipes (custom-html-tiny, ghost, immich)
+   actually answered 200 over HTTPS on THEIR warm domains during promote (grep ready-probe lines), and
+   (b) independently curl a couple of the live warm canonical domains. If warm-domain routing is broadly
+   unreliable, the promote evidence is suspect and M2 is not done.