journal(2): mumble scope correction — non-HTTP health = high-blast-radius core-harness feature (wait_healthy/canonical/generic), deserves dedicated effort; re-pick next unit = mattermost-lts (HTTP-native, no core changes)

machine-docs/JOURNAL-2.md

@@ -745,3 +745,30 @@ channel-list presence beyond TCP health); PARITY.md; e2e (light/fast). web_clien
 the mumbleweb overlay is enabled. Open question to resolve in code: how the generic install tier
 (HTTP health) behaves for a non-HTTP recipe — may need a per-recipe "health kind = tcp" in
 recipe_meta consumed by the generic harness.
+
+---
+
+## 2026-05-29 — mumble scope CORRECTION: non-HTTP health is a high-blast-radius core-harness feature, not a light add
+
+On deeper inspection, mumble's non-HTTP nature is NOT a small adaptation. The HTTP health assumption
+is baked into the CORE health path used by EVERY recipe + the 2w warm system:
+- `run_recipe_ci._load_meta` defaults (HEALTH_PATH/HEALTH_OK) + the mirrored `conftest._recipe_meta`.
+- `lifecycle.wait_healthy(domain, ok_codes, path, ...)` — the orchestrator's post-deploy HTTP poll at
+  THREE call sites (run_recipe_ci.py:467 warm/canonical, :633, :737).
+- `canonical.deploy_canonical` health gate (warm-cache, 2w).
+- `generic.assert_serving` (HTTP fetch + served_cert) and restore-health.
+Supporting a TCP/protocol recipe means threading a `HEALTH_KIND` (http|tcp) through ALL of these with
+default="http" preserving current behavior. That's a legitimate harness feature but HIGH BLAST RADIUS
+(a regression breaks every recipe and the warm sweep), so it warrants a dedicated, careful effort with
+unit tests + a no-regression re-run of an HTTP recipe + Adversary scrutiny of the core change — NOT a
+tail-of-session cram. **Filed as its own unit (Q4.2 stays open; needs the non-HTTP-health harness
+feature first).** Also: mumble's app is only on the `proxy` net and routes via a traefik `mumble` TCP
+entrypoint cc-ci lacks (HostSNI + TLS passthrough) — the custom protocol test still needs the
+python-sidecar-on-proxy-net probe.
+
+**Next-unit re-pick:** prefer an HTTP-NATIVE recipe that uses the proven harness with zero core
+changes — **mattermost-lts (Q4.5)** is the candidate (HTTP UI+API via traefik; §4.3 = create-a-message
+round-trip is pure test-authoring, not harness surgery). Scout it next: confirm it's HTTP-native +
+self-contained DB (vs needing a dep), mirror-check, then enroll (recipe_meta + lifecycle overlays +
+≥2 specifics + PARITY note [no reference corpus → P2 vacuous]). Keeps blast radius low and adds real
+coverage. mumble/mailu (non-HTTP) batch behind the HEALTH_KIND harness feature.