diff --git a/docs/TURNOVER-2026-08-14.md b/docs/TURNOVER-2026-08-14.md
index 8175fc7..3bd495a 100644
--- a/docs/TURNOVER-2026-08-14.md
+++ b/docs/TURNOVER-2026-08-14.md
@@ -114,27 +114,32 @@ app.windygit.com). Read these before doing anything:
   2. ~/windy-git/docs/TURNOVER-2026-08-14.md
   3. ~/windy-git/DNA_STRAND_MASTER_PLAN.md  (D-1..D-9, I-1..I-13)
 
-Current state: live and in use. Grant signs in with his existing Windy account
-(SSO fixed 08-14 across windy-pro PRs #346/#347). Agents authenticate with real
-EPT signature verification. 143 repos, 85 tests green, health ok.
+State: live and in use. Grant signs in with his existing Windy account (SSO
+fixed across windy-pro #346/#347). Agents authenticate with real EPT signature
+verification. 143 repos, 85 tests green, health ok.
 
-TASK: three repos have workflows that reach their Postgres service at
-@localhost:5432, which fails on our runner because the job runs inside a
-container — the service is reachable as `postgres`. Fix:
+TASK: finish the CI fix. Four repos had workflows reaching Postgres through a
+host port; all four are patched and merged (eternitas #149, windy-mind #100,
+WindyCloud #89, windy-registry #31). windy-registry's `postgres integration`
+went failure -> success, proving the approach. But windy-mind and WindyCloud
+`migrations` still FAIL and I could not determine why.
 
-  windy-mind      .github/workflows/migrations.yml
-  windy-registry  .github/workflows/ci.yml
-  WindyCloud      .github/workflows/ci.yml
+Start by reading those job logs from the GITEA WEB UI (app.windygit.com -> repo
+-> Actions -> failing run). Do NOT use the jobs API — it returns "job not found"
+for the ids the runs report, which is what blocked the last session.
 
-Copy the exact shape from eternitas PR #149 (already merged), comment included.
-The fix must go to GitHub, not Windy Git — the sync is GitHub -> Windy Git and
-force-pushes over local edits. Open one PR per repo, then sync and confirm the
-migration job actually goes green rather than assuming it.
+First hypothesis to test: windy-mind, WindyCloud and eternitas all use
+`astral-sh/setup-uv`, and eternitas' job failed with `error: Failed to spawn:
+pytest` even after the action resolved correctly. The uv toolchain may not be
+landing on PATH inside these job containers — one shared root cause rather than
+three.
 
-Ground rules that have already been paid for the hard way:
+Ground rules already paid for the hard way:
   - verify the WHOLE flow, not the half that curls easily
   - never `git pull -q` in a deploy path; it hides errors
-  - check Kit 0's `uptime` before deploying there; it has had two incidents
-    in two days from non-production workloads
-  - build before recreating a container so the swap is seconds
+  - fixes go to GitHub, not Windy Git (sync is GitHub -> Windy Git, force-push)
+  - service containers: use the service NAME and its INTERNAL port (5432),
+    never the mapped host port
+  - check Kit 0's `uptime` before deploying there; two incidents in two days
+    from non-production workloads
 ```