journal(redfix): M2 gitea fix v1 (seed) broke 3.5.3->3.6.0 transition (wizard mode); reverted clone, needs rework; proceeding to bluesky/keycloak/mumble

machine-docs/JOURNAL-redfix.md

@@ -372,3 +372,21 @@ cold green -> promote -> warm-bluesky-pds 200.
   (needs branch exec-refs) -> keycloak canonical at warm-canon-keycloak (needs branch) -> mumble.
   NOTE: mumble "green under load" is hard to reproduce deterministically; plan = show branch run still
   green + reason about the budget (or construct concurrent load).
+
+## 2026-06-18T03:00Z — M2 gitea fix v1 (seed) BROKE the transition — needs rework
+
+gitea advance verification (fixed 3.6.0): install tier PASSED FULLY (fresh 3.6.0 + my fix: API 200,
+admin auth OK — so the seed works for a FRESH deploy), but upgrade/backup/restore/custom ALL FAILED:
+`READY_PROBE not ready: /api/v1/version (last status 404) within 600s` after the 3.5.3->3.6.0 chaos
+redeploy → gitea came up in INSTALL-WIZARD mode (serves 200 but no API/admin = no valid app.ini).
+The LFS custom test's repo-create also 404'd (same wizard-mode cause).
+
+So my seed-once fix is fine for fresh install but FAILS the 3.5.3->3.6.0 transition — exactly the path
+the canon fix needs. Likely cause: on the chaos redeploy from a 3.5.3 stack (docker_setup_sh_v1, no
+seed) the docker-setup config didn't update to my v2 (seed) while compose moved app.ini to the staging
+path → /etc/gitea/app.ini empty → wizard. (To confirm: reproduce + inspect the post-redeploy container
+— is docker_setup_sh_v2 mounted? does /etc/gitea/app.ini exist? gitea log.) Reverted the fix from
+cc-ci's gitea clone; warm-gitea intact (idle 3.5.3, promote didn't fire on the red cold run). gitea
+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.