docs: refresh the turnover prompt for the actual next task
Some checks failed
check / gate (push) Successful in 18s
canary / probe (push) Failing after 6s

Co-Authored-By: Claude (Fable 5) <noreply@anthropic.com>
This commit is contained in:
Grant Whitmer
2026-08-14 17:31:23 -04:00
parent 86326ca6a7
commit db055a1922

View File

@@ -114,27 +114,32 @@ app.windygit.com). Read these before doing anything:
2. ~/windy-git/docs/TURNOVER-2026-08-14.md 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) 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 State: live and in use. Grant signs in with his existing Windy account (SSO
(SSO fixed 08-14 across windy-pro PRs #346/#347). Agents authenticate with real fixed across windy-pro #346/#347). Agents authenticate with real EPT signature
EPT signature verification. 143 repos, 85 tests green, health ok. verification. 143 repos, 85 tests green, health ok.
TASK: three repos have workflows that reach their Postgres service at TASK: finish the CI fix. Four repos had workflows reaching Postgres through a
@localhost:5432, which fails on our runner because the job runs inside a host port; all four are patched and merged (eternitas #149, windy-mind #100,
container — the service is reachable as `postgres`. Fix: 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 Start by reading those job logs from the GITEA WEB UI (app.windygit.com -> repo
windy-registry .github/workflows/ci.yml -> Actions -> failing run). Do NOT use the jobs API — it returns "job not found"
WindyCloud .github/workflows/ci.yml 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. First hypothesis to test: windy-mind, WindyCloud and eternitas all use
The fix must go to GitHub, not Windy Git — the sync is GitHub -> Windy Git and `astral-sh/setup-uv`, and eternitas' job failed with `error: Failed to spawn:
force-pushes over local edits. Open one PR per repo, then sync and confirm the pytest` even after the action resolved correctly. The uv toolchain may not be
migration job actually goes green rather than assuming it. 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 - verify the WHOLE flow, not the half that curls easily
- never `git pull -q` in a deploy path; it hides errors - never `git pull -q` in a deploy path; it hides errors
- check Kit 0's `uptime` before deploying there; it has had two incidents - fixes go to GitHub, not Windy Git (sync is GitHub -> Windy Git, force-push)
in two days from non-production workloads - service containers: use the service NAME and its INTERNAL port (5432),
- build before recreating a container so the swap is seconds never the mapped host port
- check Kit 0's `uptime` before deploying there; two incidents in two days
from non-production workloads
``` ```