diff --git a/docs/TURNOVER-2026-08-14.md b/docs/TURNOVER-2026-08-14.md index 6b0806c..8175fc7 100644 --- a/docs/TURNOVER-2026-08-14.md +++ b/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