windyadmin/windy-git
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

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

Browse Source 
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
1 changed files with 22 additions and 17 deletions
Download Patch File Download Diff File Expand all files Collapse all files

39
docs/TURNOVER-2026-08-14.md
View File

@@ -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
```