docs: record three-repo CI fix results — 1 of 3 verified

windy-registry's postgres integration went failure -> success, proving the fix.
windy-mind and WindyCloud still fail for a cause I could not determine: the
jobs API returns 'job not found' for the ids the runs report, so logs were not
retrievable that way. Next session should read them from the Gitea web UI.

Records the trap that the three repos did NOT share one pattern — a naive
localhost->postgres swap would have left WindyCloud on port 15432.

Co-Authored-By: Claude (Fable 5) <noreply@anthropic.com>

docs/TURNOVER-2026-08-14.md

@@ -13,7 +13,34 @@ Grant signs in with his existing Windy Word credentials — no second account.
 Agents authenticate with real Eternitas EPT signature verification and are
 rate-limited by integrity band.
 
-## The immediate next task
+## DONE since this was written — the three-repo CI fix
+
+All three PRs are **merged and synced**: windy-mind #100, WindyCloud #89,
+windy-registry #31 (eternitas #149 earlier).
+
+**Result: 1 of 3 verified fixed, 2 still failing for an undetermined reason.**
+
+- ✅ **windy-registry** — `postgres integration` went **failure → success**. The
+  fix is proven correct.
+- ❌ **windy-mind**, **WindyCloud** — `migrations` still fails. The DATABASE_URL
+  is definitely right now; the cause is something else and was **not
+  determined** — the jobs API returns "job not found" for the ids the runs
+  report, so logs could not be retrieved that way.
+
+**Next session: read those job logs from the Gitea web UI** (`app.windygit.com`
+→ repo → Actions → the failing run), not the jobs API. Suspicion worth checking
+first: both use `astral-sh/setup-uv`, and eternitas' equivalent job failed with
+`error: Failed to spawn: pytest` even after the action resolved — so the uv
+toolchain may not be landing on PATH in these containers. That would be a
+different, shared root cause.
+
+**A trap worth keeping:** the three repos did NOT share one pattern. A naive
+`localhost` → `postgres` swap would have left **WindyCloud on port 15432** (it
+maps `15432:5432`) and windy-registry on a `job.services.postgres.ports[…]`
+expression. Service-name networking always uses the container's **internal**
+port — 5432 — never the mapped host port.
+
+## The original task description (superseded above)
 
 **Three repos need a one-line CI fix.** Their workflows reach a Postgres service
 at `@localhost:5432`, which works on GitHub-hosted runners (services are