windy-git/docs/TURNOVER-2026-08-14.md

Windy Git — turnover, 2026-08-14

Paste the block at the bottom into a fresh terminal. Everything above is context for whoever reads this file directly.

Where things stand

Windy Git is live and in use: app.windygit.com (forge), api.windygit.com (our plane), on Veron 1 behind a Cloudflare Tunnel, zero inbound ports, $0/mo. 143 repos, 85 tests green, health ok on all four checks.

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.

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 port-mapped to the VM) and fails on ours (the job runs inside a container, so localhost is the job itself). The service is reachable as postgres.

repo	workflow
windy-mind	migrations.yml
windy-registry	ci.yml
WindyCloud	ci.yml

eternitas was already fixed this way — see eternitas PR #149 for the exact shape, including the comment explaining why. Fix must go to GitHub, not Windy Git: the sync runs GitHub → Windy Git and force-pushes over local edits.

Proven by direct comparison, same runner and same postgres:16-alpine image: windy-git's own gate uses @postgres:5432 and passes its migration round-trip; eternitas' used @localhost:5432 and failed.

Traps that will waste your time

• git pull -q hides errors. A divergent branch once made a "deploy" run 20 minutes against stale code while reporting success. Use git fetch && git merge --ff-only and read the output.
• Never force-push a branch a deploy checkout tracks (--amend orphaned /srv/windygit/src once).
• Gitea's env-to-ini SETS but never UNSETS, and sometimes appends a duplicate. GITEA__DEFAULT__APP_NAME does not work at all — Gitea reads APP_NAME from the top level of app.ini; the env var creates a literal [default] section it ignores. Edit app.ini on the host.
• Cloudflare caches /assets/* for 6h and no token in this stack can purge. Version brand asset filenames (theme-windy.v2.css), not query strings.
• base64 wraps at 76 chars and corrupts long tokens in test commands → curl (43), phantom HTTP 000. Use base64 -w0.
• Kit 0 is fragile. 54 containers on 4 vCPU. Two production incidents in two days, both from non-production workloads. Check uptime before deploying anything there, and build before recreating so the swap is seconds.

Open items, roughly by value

1. The three-repo localhost fix above.
2. Get non-prod work off Kit 0. 12 dev/demo containers on the box running identity, the CA, mail, Matrix and the broker. Cost two incidents already; the postgres-adapter fix would not have prevented either.
3. Login is ~4–6s — postgres-adapter.ts:114 forks a node -e process per query. Measured: node startup alone is 1.7s on Kit 0 vs 0.01s on Veron. The fix is one function (persistent worker + pg.Pool), not the "468 call sites" the SOTU scoped. See docs/incidents/2026-08-12-login-latency-analysis.md.
4. Privileged dind sits beside broad-scoped tokens on the CI host — Grant's call, needs a decision not a code change.
5. Push-velocity throttling is declared but unenforceable from our plane (git push never touches the API); needs a Gitea pre-receive hook.

Read these first

• ~/.claude/.../memory/project_windy_git.md — the full record, densest source
• DNA_STRAND_MASTER_PLAN.md — D-1…D-9 locked decisions, I-1…I-13 invariants
• docs/AUDIT-fable-2026-08-13.md — second-auditor findings and dispositions
• docs/CUTOVER.md — the GitHub↔Windy Git migration plan and its one rule

---

Copy-paste prompt

Picking up Windy Git (agent-native code+model host on Veron 1, live at
app.windygit.com). Read these before doing anything:

  1. ~/.claude/projects/-home-grantwhitmer/memory/project_windy_git.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)

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: 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.

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.

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