[devinder-dev]

What

Closes Phase 2 in docs/CONTEXT.md's "Where we are": what is live, and the tests that proved it.

Phase 2, as merged and applied

• infra: guard namespace relay (Pod Security restricted, ClusterIP-only Services) #21: guards on namespace relay (Pod Security restricted, ClusterIP-only Services).
• infra: Postgres 18.6 on a disk that survives deletion #22: Postgres 18.6 on a disk that is kept on delete, applied by hand, with the relay login.
• feat: schema v1 and migrations before every rollout #27 (replaces feat: schema v1 and migrations before every rollout #25): migration 001, and the migrate Job before every rollout (ADR 0006).
• feat: connect the API to Postgres, with Postgres in the tests (step 2.6) #26: the API waits for the database before it listens; Postgres in the tests.

The live evidence, posted on the PRs

• infra: Postgres 18.6 on a disk that survives deletion #22: a login from another pod as relay, a wrong password refused, 5432 closed from outside,
  and the deletion drill: the data survived deleting the pod, the StatefulSet and the claim.
• feat: schema v1 and migrations before every rollout #27: the Role checked both ways, the installed script identical to git, and migration 001
  applied by its Job. Two negative tests:
  • a Job that can't start fails within 150 s;
  • a rollback to Phase 1's release under load: 123,904 requests, 0 failed.
• feat: connect the API to Postgres, with Postgres in the tests (step 2.6) #26 (live 2 Nov): both pods log ✅ database answered before they listen; /health/ready
  answers 200 from outside.

Docs only.

[AbdikhaniAbdirashid]

Docs only, so I checked the claims against the cluster and the code rather than reading past
them. Everything I could verify is accurate:

Claim	How I checked it
Postgres 18.6, local-path-retain	select version(), and the PVC's StorageClass
the app logs in as relay, not a superuser	select rolname, rolsuper → relay | f
migration 001, schema v1, applied	schema_migrations holds 20261031140445; the 6 tables are owned by relay
every deploy runs the migrations first	relay-deploy.sh:112 calls run_migrations before the apply on 122
a migration that can't start fails within 150 s	activeDeadlineSeconds: 150, with backoffLimit: 0
the API waits, then listens	both pods log ✅ database answered before Server listening
readiness never checks the database	/health/ready answers 200 from outside, and routes/health.ts says why
5432 closed from outside	nc -z -w 3 81.88.23.71 5432 refuses, while 443 answers

One line I'd reword

an unreachable database answers 503 service_unavailable

True of the code, but it sits in a list of things that are live, and right now no request can
produce it. api/src/routes/ holds only health.ts, there is no repositories folder, and the only
SQL outside the tests is in db.ts. isDatabaseUnavailable is covered by unit tests that hand it
fabricated { code } objects — which is the right test for a pure function, but it is not the same
kind of evidence as the rows above it.

I would make that explicit, something like: "an unreachable database answers 503
service_unavailable (unit-tested; the first request that can reach it arrives in Phase 3)."
Otherwise the defense question "show me a 503" has no answer and it looks like we lost it, when in
fact there is nothing to show yet.

One question, from the cluster

postgres-0 was replaced on 2 Nov at 16:17 UTC — 25 minutes after #26's pods started at 15:51,
and after Phase 2 was done. The server has not rebooted (up since 22 Oct) and the container has 0
restarts, so the pod itself is new. What the StatefulSet shows:

generation: 3        but only one ControllerRevision (rev 1, 1 Nov 14:20)
PVC data-postgres-0: created 1 Nov 14:21, untouched

So the spec was edited twice in ways that never changed the pod template — consistent with scaling
to 0 and back. The deployer account can't touch StatefulSets, so it was done by hand.

If that was you testing the database-outage path live, it belongs in this list — it is the
strongest evidence Phase 2 has, and it is the one thing the section is missing. If it wasn't you,
I'd like to know what edited the StatefulSet 25 minutes after a deploy.

Worth noting either way: the API pods have 0 restarts and the same start time, so they stayed in
service while the database was gone. That is exactly what "readiness never checks the database" is
for — though it proves less than it looks like today, since nothing queries the database yet.

Not your job, just so you know

"Where we are" says nothing about Phase 5. Once the dashboard pipeline (#30) and its manifest (#24)
are in, I'll add that line myself in a separate docs PR.

Approving. The reword is a suggestion, not a condition — but I'd take it before the defense.