journal(redfix): M2 — bluesky verify blocked by abra non-chaos tag-revert (recipe fixes need chaos); keycloak/mumble (harness) verify cleanly, doing next

machine-docs/JOURNAL-redfix.md

@@ -390,3 +390,21 @@ cc-ci's gitea clone; warm-gitea intact (idle 3.5.3, promote didn't fire on the r
 recipe PR #2 stands but the fix needs a rework (likely: a more robust seed that runs regardless of
 config version, OR provide a 1.24-valid oauth2 JWT secret so gitea never rewrites app.ini — investigate
 WHY 1.24 regenerates it). Deferring gitea; proceeding to bluesky-rename / keycloak / mumble verifies.
+
+## 2026-06-18T03:30Z — M2 bluesky verification BLOCKED by abra non-chaos tag-revert; keycloak/mumble next
+
+Root cause of the bluesky rename verify failure: the deployed service was `..._app` (not `pds`).
+`run_recipe_ci` CCCI_SKIP_FETCH copies my renamed clone to the per-run tree, BUT abra's NON-CHAOS
+pinned deploy (bluesky's tag 0.3.0+v0.4.219 is ANNOTATED) does `git checkout <tag>` in the per-run
+tree, REVERTING my rename to the tag's `app:`. So the renamed recipe never deployed; the branch
+harness then execs `service=pds` -> "no running container <stack>_pds" -> backup/restore/custom red.
+(This also re-explains the earlier "abra dropped the alias" — it was the same tag-revert, not a drop.)
+gitea's tag is lightweight -> deploy_app uses chaos -> my gitea fix DID deploy (install passed); its
+failure is a real transition issue, not a revert.
+
+IMPLICATION: verifying a RECIPE fix (bluesky, gitea) via CCCI_SKIP_FETCH needs a CHAOS deploy (uses the
+checkout, not the tag). HARNESS fixes (keycloak canonical_domain, mumble retry) are runner/test code
+from the branch checkout — NO tag-revert — so they verify cleanly. Doing keycloak + mumble next.
+For bluesky: force chaos (deploy_app does chaos when has_ccci_overlay) OR reconsider a cc-ci-side
+overlay fix (alias + caddyfile override) — both verifiable; recipe PR #4 (rename) stays as the ideal
+upstream fix. gitea: rework + reproduce-with-inspection.