claim(redfix-M2): all 6 canon-sweep failures FIXED + verified green

mattermost-lts (PR #1, !testme #901), discourse (PR #4, !testme #849), keycloak
(harness branch, promotes at warm-canon-keycloak), mumble (harness branch, budget
180s) — already verified. gitea (PR #2 @a0f2db8, app.ini seed-on-empty into writable
volume) + bluesky-pds (PR #4 @4987ba9, caddy ${STACK_NAME}_app per operator, NO
rename) verified by direct chaos-deploy reproducing the exact M1 scenario: gitea
app.ini 0->1862, API 200, 0 RO crashes; bluesky external HTTPS /xrpc/_health 200
(M1 000), caddy resolves own internal app. Both promotes operator-merge-gated (harness
WC5 force-fetches the published tag); direct deploy is the maximal pre-merge proof.
No standing exceptions. Nothing merged.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Bacy8SJhBebNAGoYsi1Fxt

machine-docs/JOURNAL-redfix.md

@@ -470,3 +470,53 @@ Restored the bluesky tag; node clean; warm-keycloak 200.
 - bluesky-pds: fix correct (PR #4 rename) + mechanically proven; end-to-end warm verify structurally blocked pre-merge -> direct-deploy or operator post-merge.
 - gitea: PR #2 seed fix BROKE 3.5.3->3.6.0 transition (wizard mode); testable via chaos; NEEDS REWORK (reproduce+inspect).
 NOT claiming M2 — bluesky end-to-end + gitea rework outstanding.
+
+## 2026-06-18T05:53Z — M2 gitea VERIFIED (v3 seed) + bluesky VERIFIED (${STACK_NAME}_app); 6/6
+
+**gitea — rework was already done (v3, a0f2db8) but unverified; verified it.** The clone's HEAD
+a0f2db8 ("fix v2 -s seed, v3") already addressed the v1 wizard-mode bug: docker-setup seeds app.ini
+into the writable /etc/gitea volume `if [ ! -s /etc/gitea/app.ini ]` (seed-on-EMPTY, not -f
+seed-on-missing — a 3.5.3-old-recipe canonical leaves a 0-byte app.ini placeholder in the config
+volume, which -f wrongly treats as present). Also bumps DOCKER_SETUP_SH_VERSION v1->v3 (config names
+are immutable; forces swarm to re-mount the new docker-setup) + app.ini config target ->
+/etc/gitea/app.ini.init (staging). Pushed v3 to PR #2 (force-replaced the broken v1 d4145266).
+
+VERIFICATION (direct chaos-deploy onto the REAL idle 3.5.3 canonical volumes; /tmp/redfix-gitea-m2-directproof.log):
+reattached the retained config volume (0-byte app.ini = genuine pre-fix M1 state) with the v3 recipe.
+Result: app.ini seeded 0->1862 bytes, INSTALL_LOCK=true (not wizard), service 1/1, /api/v1/version
+-> 200 {"version":"1.24.2"}, /api/healthz 200, retained 3.5.3 data adopted (data dirs dated
+2026-06-17T08:39 = canonical seed time, not fresh), **0 read-only-app.ini crashes** (M1 crashed here).
+
+WHY NOT the harness WC5 promote: it is STRUCTURALLY merge-gated. run_recipe_ci.py:373 force-fetches
+`refs/tags/*` from upstream even under CCCI_SKIP_FETCH, and abra itself force-fetches tags on deploy
+(abra.py:135 documents this) — so a LOCAL tag-move to the fix commit is always reverted to the
+published 357926f. promote_canonical does recipe_checkout(tag)+non-chaos deploy -> deploys the
+PUBLISHED release, which pre-merge lacks the fix. Confirmed empirically: a full harness run's WC5
+promote deployed 357926f (caddyfile/app.ini OLD) -> crashed exactly like M1. So end-to-end
+canonical-advance needs the operator to merge PR #2 + re-cut 3.6.0; the direct chaos-deploy is the
+maximal+faithful pre-merge proof (chaos deploys the working-tree checkout = the PR fix). Node left
+clean: warm-gitea undeployed (idle 3.5.3, volumes retained), app.ini reset to 0-byte for re-verify,
+canonical.json UNCHANGED (3.5.3 idle e6a1cc79), recipe tag restored to upstream 357926f.
+
+**bluesky — operator directive (2026-06-18): NO rename; use ${STACK_NAME}_app.** Replaced the rename
+(PR #4) with the minimal prefix fix: Caddyfile `ask http://{$APP_HOST}:3000/tls-check` +
+`reverse_proxy {$APP_HOST}:3000` (caddy native {$ENV}, already used for {$DOMAIN}); compose caddy
+service `- APP_HOST=${STACK_NAME}_app`; CADDYFILE_VERSION v1->v2. Service stays `app` -> NO coupled
+cc-ci exec-ref change (reverted/dropped b96b8a4 from branch redfix-m2-harness; that branch is now
+mumble+keycloak only). 3-file recipe-PR-only diff. Pushed to PR #4 ci/warm-routing-alias (4987ba9,
+force-replaced the rename). Pattern per matrix-synapse/mailu/mumble.
+
+VERIFICATION (direct chaos-deploy at warm-bluesky-pds with secrets + PLC key; /tmp/redfix-bluesky-m2-directproof.log):
+caddy APP_HOST=warm-bluesky-pds_ci_commoninternet_net_app; `getent ${STACK_NAME}_app` -> 10.0.3.x
+(bluesky's OWN internal net) while `getent app` (M1's bare target) -> 10.10.0.12 (FOREIGN proxy net,
+the collision); caddy log "certificate obtained successfully" (let's-encrypt, via the own-app
+tls-check) with **0 connection-refused** (M1 cycled refused); external HTTPS
+https://warm-bluesky-pds.../xrpc/_health -> **200** {"version":"0.4.219"} (M1 was 000). GOTCHA: abra
+`secret insert` (no -C -o) force-fetches+checks out the .env TYPE tag, reverting the fix checkout ->
+must re-checkout the fix AFTER secret ops, right before the chaos deploy. Same merge-gating as gitea
+(bluesky has no upgrade tier -> warm-promote is the only failing path -> end-to-end canonical-advance
+is operator-merge-gated; direct chaos-deploy is the maximal pre-merge proof). Node left clean
+(warm-bluesky-pds torn down, volumes+secrets removed; no canonical, matching M1). Live warm-keycloak
+200 throughout.
+
+**6/6 VERIFIED.** Claiming M2.