Desmond Okafor

{
  "command": "pwd"
}

/Users/warrenthompson/Source/LoginID/01-product-industry-research-design

{
  "file_path": "/Users/warrenthompson/Source/LoginID/04-infra-devops/refinement/LT-48.md"
}

1	# LT-48 refinement — S4: local dev-loop, compose profiles for SQLite and Postgres
2	
3	**Product Owner:** Naomi Voss (01). **Research team:** Desmond Okafor (claims check), Tobias Lindqvist (objection seat). **Engineering:** Theo Bergman (04). **Source:** `04-infra-devops/backlog.md` Story 4 (LT-48), design already done in `04-infra-devops/local-dev-loop.md`.
4	
5	**Who did the work:** Refined by Naomi Voss (PO).
6	
7	## Why this one, now
8	
9	Low-risk, low-effort (`sonnet, low`), fully designed already (`local-dev-loop.md`'s compose sketch), no dependency on anything still in flight — a clean pull between larger stories.
10	
11	## What this story actually is
12	
13	Committing `local-dev-loop.md`'s sketch as a real `docker-compose.yml` plus the small supporting pieces it names: `.dev-secrets/` gitignored with an init target/README, the `air` hot-reload target scoped to dev profiles only, and a mock `idp-connector` target for local runs. Not a redesign — the design doc is explicit that this is a sketch to commit, not a proposal to re-litigate.
14	
15	## Acceptance criteria (restated from `backlog.md` S4)
16	
17	- [ ] A new developer can run either profile (`docker compose --profile sqlite up` / `--profile postgres up`) from this file alone, without asking what `DB_DRIVER` values are valid — enforcement site: the compose file itself states valid values, no external doc required to start.
18	- [ ] The `postgres` profile exercises the shared `postgres`-package code path (Postgres, and by extension CockroachDB's shared code) — enforcement site: `api-service-pg`'s `DB_DRIVER: postgres` wiring.
19	- [ ] Dev credentials never appear in `secrets-delivery.md`'s mechanism or in any real manifest — enforcement site: `.dev-secrets/` is `.gitignore`d, values are placeholder/dev-only, and the file states explicitly (as `local-dev-loop.md` already does) that this isn't the security design.
20	- [ ] Hot-reload (`air`) has zero effect on the production image build — enforcement site: the `air` target/service is scoped to compose dev profiles only; `cmd/api-service/Dockerfile` (the actual production build, `containerization-design.md`) is untouched by this story.
21	- [ ] **Added — `.gitignore` actually covers `.dev-secrets/`,** checked directly rather than assumed: a placeholder-credential file that *should* be untracked but isn't would be a real, if low-severity, instance of the same "committed secret-shaped value" concern this project polices everywhere else (`gitleaks` in CI, the never-log list). Enforcement site: `.gitignore` entry, confirmed present, plus a `git status` check post-`make dev-secrets-init` showing the four files as untracked.
22	- [ ] **Added — the `postgres` profile's `postgres` service doesn't collide with the real cluster's own Postgres on a developer's machine** (both default to port 5432) — not a security concern, a "second thing entirely eats a dev's afternoon" concern (this project has already lost time to unrelated-looking failures that were actually port/quota collisions — the LT-46 quota incident is the same *category* of "worked in isolation, collided in combination"). Enforcement site: the compose file's port mapping, or a documented override instructions if a fixed mapping is intentional.
23	
24	## Non-goals
25	
26	- No local Kubernetes (`kind`/`minikube`) — explicitly ruled out in `local-dev-loop.md`.
27	- No CockroachDB profile locally — CI's dedicated job already covers that path; the local loop doesn't need every backend on every save, per the design doc's own reasoning.
28	- No change to the production Dockerfile or CI pipeline — this story is additive, a new file plus small supporting pieces, not a modification to `containerization-design.md`/`ci-pipeline.md`.
29	- No production credential handling review — dev credentials are explicitly out of `secrets-delivery.md`'s scope by design, not something this story needs to re-justify.
30	
31	## PO review script
32	
33	1. Read the committed `docker-compose.yml` directly against `local-dev-loop.md`'s sketch — confirm it matches (or note deliberate, sensible deviations), not a from-scratch reinterpretation.
34	2. `docker compose --profile sqlite up` and `docker compose --profile postgres up` each independently, from a clean checkout with no prior `.dev-secrets/` — confirm no undocumented prerequisite blocks either from starting.
35	3. Confirm `.dev-secrets/` is genuinely untracked (`git status` after `make dev-secrets-init` or equivalent) and appears in `.gitignore`.
36	4. Confirm the `air`-based dev target is only reachable via a dev compose profile — read `cmd/api-service/Dockerfile` directly and confirm it's unmodified by this story's diff.
37	5. Confirm the `postgres` profile's Postgres service either uses a non-default host port or the file documents the override for a developer who already has something on 5432.
38	
39	## Research team review
40	
41	**Desmond Okafor — claims check:** [pending]
42	
43	**Tobias Lindqvist — objection:** [pending]
44	
45	**Naomi Voss — ruling:** [pending]
46	

{
  "file_path": "/Users/warrenthompson/Source/LoginID/04-infra-devops/local-dev-loop.md"
}

1	# Local Dev-Loop
2	
3	Design-only — a docker-compose sketch, not a committed `docker-compose.yml`. Local counterpart to the cluster target in `./containerization-design.md`, not a replacement for it: this is what a developer runs on a laptop; the cluster design is what the submission targets as the real deployment shape.
4	
5	## Two compose profiles, matching 03's `DB_DRIVER` env var
6	
7	```yaml
8	# docker-compose.yml (sketch)
9	services:
10	  api-service:
11	    build: {context: ., dockerfile: cmd/api-service/Dockerfile}
12	    environment:
13	      DB_DRIVER: ${DB_DRIVER:-sqlite}
14	      DB_DSN_FILE: /run/secrets/db_dsn
15	      HTTP_ADDR: ":8080"
16	    ports: ["8080:8080"]
17	    volumes: ["sqlite-data:/data"]
18	    secrets: [db_dsn]
19	    profiles: ["sqlite"]
20	
21	  api-service-pg:
22	    extends: {service: api-service}
23	    environment:
24	      DB_DRIVER: postgres
25	    depends_on: [postgres]
26	    profiles: ["postgres"]
27	
28	  postgres:
29	    image: postgres:16-alpine
30	    environment:
31	      POSTGRES_USER: dev
32	      POSTGRES_PASSWORD_FILE: /run/secrets/postgres_password
33	    ports: ["5432:5432"]
34	    secrets: [postgres_password]
35	    profiles: ["postgres"]
36	
37	  idp-connector:
38	    build: {context: ., dockerfile: cmd/idp-connector/Dockerfile}
39	    environment:
40	      IDP_ABC_BASE_URL: ${IDP_ABC_BASE_URL:-http://mock-idp:9090}
41	    secrets: [idp_abc_client_id, idp_abc_client_secret]
42	    profiles: ["sqlite", "postgres"]
43	
44	secrets:
45	  db_dsn: {file: ./.dev-secrets/db_dsn}                       # untracked; developer creates once, e.g. "file:/data/dev.db" or a postgres:// DSN
46	  postgres_password: {file: ./.dev-secrets/postgres_password}
47	  idp_abc_client_id: {file: ./.dev-secrets/idp_abc_client_id}
48	  idp_abc_client_secret: {file: ./.dev-secrets/idp_abc_client_secret}
49	
50	volumes:
51	  sqlite-data:
52	```
53	
54	`.dev-secrets/` is `.gitignore`d; a `.dev-secrets/README` (or a `make dev-secrets-init` target) writes the four files with placeholder dev values on first run. This isn't cosmetic — the inventory's rules apply to every environment, including dev: row 5 says vendor client credentials are "never in source or committed config", and row 1's `DB_DSN_FILE` is "Required, not preferred," with no development exemption written anywhere. Compose's file-based `secrets:` mechanism is the local equivalent of the `Secret` volume mounts in `./secrets-delivery.md` — same shape (a file path the process reads), just backed by a bind-mounted file instead of a Kubernetes object.
55	
56	`docker compose --profile sqlite up` for the zero-dependency path (no Postgres container, fastest inner loop); `docker compose --profile postgres up` when a developer needs to exercise the Postgres-specific code path (the `pg_trgm` index, per `../05-data-ops/multi-db-strategy.md`). CockroachDB is omitted here for loop speed, not because it's redundant — the CockroachDB code path (`withRetry`'s engine-aware retry, `multi-db-strategy.md`) is genuinely different code from the Postgres path, which is exactly why `./ci-pipeline.md` runs a dedicated CockroachDB job; the local loop just doesn't need every backend on every save.
57	
58	## Dev credentials are dev credentials
59	
60	The values developers put in `.dev-secrets/*` are local-only, never used outside a developer's own machine, and never the pattern used in `./containerization-design.md` or `./secrets-delivery.md` — those go through the mechanisms 02 specifies. Worth stating explicitly so nobody reads this file as the security design.
61	
62	## Migrations locally
63	
64	`goose up` (or whatever 05 finalizes) run by hand or via a `make migrate` target against whichever profile is active — no orchestration-layer exclusivity needed locally since there's exactly one developer and one instance. The R2 requirement (`../05-data-ops/migration-approach.md`) is a production/CI concern; the local loop doesn't need to simulate it.
65	
66	## Hot-reload for `api-service`, dev-profile only
67	
68	Considered cutting `air` as unneeded polish, reconsidered: `docker compose build && up` on every change is a slow inner loop for a project a developer iterates on repeatedly, and the cost of adding it is close to zero — one `air`-based dev target in the compose file, no production image impact since it only applies to the `sqlite`/`postgres` dev profiles, never `./containerization-design.md`'s images. Worth doing, not worth debating further.
69	
70	## What's deliberately not here
71	
72	No local Kubernetes (`kind`/`minikube`) mirroring the lab cluster — compose is the right altitude for a two-service Go project's local loop; a local k8s cluster would be solving a problem this project doesn't have.
73	
74	---
75	*AI tooling note: drafted directly by Theo (Sonnet, this session) from 03's config surface and the containerization design above. Bree's (capability-case) and Callum's (scope-cut) per-deliverable notes reviewed and folded in inline above, per PLAN.md §3.*
76	

{
  "file_path": "/Users/warrenthompson/Source/LoginID/04-infra-devops/backlog.md"
}

1	# Track 04 — Infra & DevOps Backlog
2	
3	Track: 04-infra-devops. Lead: Theo Bergman. Epic: "Infra & DevOps: Containerization, CI/CD, and Operations" (key: LT-4).
4	
5	Authored now per Phase 4; will be re-checked against the consistency pass's cross-cutting findings (`PLAN.md` §"Cross-cutting — enforcement sites") once that report lands, particularly for Story 6 below. All stories carry `no-code-yet` — Warren's Phase 4 go covers backlog authoring, not implementation; a separate, explicit code go-ahead is still required before any `.go`, Dockerfile, CI config, or compose file is written for real.
6	
7	## Story 1 — Containerize `api-service` and `idp-connector` (LT-45)
8	
9	**Description:** Build the two multi-stage Go images (distroless final stage, non-root, read-only root filesystem) and the Deployment/Service/NetworkPolicy manifests targeting the lab cluster, per `./containerization-design.md`. Covers both binaries' Dockerfiles, resource requests/limits sized per service (CPU-bound `api-service` vs. I/O-bound `idp-connector`), the migration `Job` (parallelism 1, gated by the CI pipeline's exclusivity mechanism, not Kubernetes ordering alone), a default-deny `NetworkPolicy` on `idp-connector` so its "no inbound Service" isolation claim actually holds against the namespace's default-allow network, and — per the consistency pass's F13 finding — a **third manifest**: `api-service-issuer`, a second Deployment of the same `api-service` image (`APP_MODE=issuer`) whose own ServiceAccount is the only one that mounts the JWT signing key, since RBAC on the `Secret` verb does nothing once it's volume-mounted into the verifying Deployment's replicas.
10	
11	**Acceptance criteria:**
12	- [ ] The receiving track (whoever implements/reviews this) can act on the manifests without re-deriving the reasoning in `containerization-design.md`.
13	- [ ] Both images build from a pinned Go version, produce a static binary, and contain nothing but the binary (+ CA certs for `idp-connector`) — enforcement site: multi-stage Dockerfile's final `COPY` list.
14	- [ ] Neither Pod can write to its own root filesystem at runtime — enforcement site: `securityContext.readOnlyRootFilesystem: true`.
15	- [ ] `idp-connector` is unreachable except from `api-service` — enforcement site: the `NetworkPolicy` ingress rule scoped to `api-service`'s pod selector.
16	- [ ] A stuck `idp-connector` cannot starve `api-service` if colocated on one node — enforcement site: `resources.limits` on both Pod specs.
17	- [ ] The migration `Job` cannot start a second concurrent run — enforcement site: the CI pipeline's concurrency-gated deploy stage (Story 3), not a database lock.
18	- [ ] The JWT signing private key is mounted into `api-service-issuer` only, never into `api-service`'s own Deployment — enforcement site: `api-service`'s manifest carries no volume/mount referencing that `Secret` at all, verified by manifest inspection, not RBAC.
19	
20	**Depends on:** 03 — `cmd/api-service` and `cmd/idp-connector` build as real binaries (service boundaries already stable, per `PLANNING.md`); 05 — final migration tooling name for the `Job`'s invocation (already final, `05-data-ops/migration-approach.md`).
21	
22	**Model/effort:** Sonnet, medium.
23	
24	**Type:** Story.
25	
26	**Labels:** `track-04`, `no-code-yet`.
27	
28	## Story 2 — Deliver secrets to both services per 02's inventory (LT-46)
29	
30	**Description:** Implement the Kubernetes-native `Secret` delivery mechanism in `./secrets-delivery.md`: file-mounted secrets keyed by name only in manifests, RBAC scoped per-service (and, for the JWT signing key, scoped to the issuing code path specifically, not `api-service`'s verification path), cluster-level encryption-at-rest for the `Secret` resource type, and the migration-runner credential's backend-specific provisioning (`CREATE EXTENSION pg_trgm` rights on PostgreSQL only, nothing extra on CockroachDB, no privilege model on SQLite) kept distinct from the runtime service credential (DML-only, no DDL, per 05's R4).
31	
32	**Acceptance criteria:**
33	- [ ] 02 (the hand-off's author) confirms this implementation matches `handoff-04-secrets.md` v2's inventory without needing to re-explain any row.
34	- [ ] No `Secret` value appears in a manifest, image layer, build arg, or CI log — enforcement site: manifests reference names only; CI's `gitleaks` stage (Story 3).
35	- [ ] No ServiceAccount can `get`/`list` a `Secret` it doesn't mount — enforcement site: per-service `Role`/`RoleBinding` scoped to named `Secret`s.
36	- [ ] The migration-runner credential and the runtime service credential are provisioned as two distinct `Secret`s, never one — enforcement site: separate `Secret` objects, separate `Role`s, per 05's R4.
37	- [ ] **Re-scoped per Warren's ruling (2026-09-13), replacing the original etcd-encryption criterion — see `refinement/LT-46.md` for the full record:** application secret material is not stored in etcd; delivered by Vault Agent with per-`ServiceAccount` Vault roles — enforcement site: Vault policy per role, plus a namespace check that none of the six application `Secret`s exist. Accepted platform exceptions stay as Kubernetes `Secret`s and are named explicitly, not silently grandfathered.
38	
39	**Depends on:** 02 — `handoff-04-secrets.md` (received, v2, final); 05 — `migration-approach.md` R4 (final).
40	
41	**Model/effort:** Sonnet, medium.
42	
43	**Type:** Story.
44	
45	**Labels:** `track-04`, `security-graded`, `no-code-yet`.
46	
47	## Story 3 — CI/CD pipeline: build, lint, test, scan, migrate, describe-only deploy (LT-47)
48	
49	**Description:** Stand up the pipeline in `./ci-pipeline.md`: build/lint/test(`-race`, three DB targets: SQLite, Postgres, CockroachDB)/security-scan/image-build on every PR; push-images/migration-job/describe-only-deploy on merge. The migration-job stage is where 05's R2 exclusivity requirement is actually enforced — a concurrency-gated pipeline stage, not a database lock, since no single lock mechanism covers both the right scope (session, to span `goose`'s per-file transactions) and the right engine (CockroachDB supports transaction-scope only).
50	
51	**Acceptance criteria:**
52	- [ ] A developer or reviewer can act on this pipeline description without re-deriving why each stage exists.
53	- [ ] A lint or test failure blocks merge — enforcement site: required-status-check on the PR, not advisory.
54	- [ ] A CockroachDB-specific SQL incompatibility surfaces at PR time, not deploy time — enforcement site: the dedicated CockroachDB testcontainer job.
55	- [ ] Only one migration run can reach the migrate stage at a time, across concurrent deploys — enforcement site: the pipeline's own concurrency group/mutex on the deploy environment.
56	- [ ] No secret enters a build log or image layer — enforcement site: `gitleaks` stage plus the Dockerfile's minimal `COPY` list (Story 1).
57	- [ ] The final deploy stage is documented (which manifests, which namespace, which credential) but not invoked — enforcement site: stage exists as a named, non-executing step until a separate real-deploy decision is made.
58	
59	**Depends on:** 03 — test-strategy outline for `go test ./...` to run against; 05 — `migration-approach.md` (final).
60	
61	**Model/effort:** Sonnet, medium.
62	
63	**Type:** Story.
64	
65	**Labels:** `track-04`, `no-code-yet`.
66	
67	## Story 4 — Local dev-loop: compose profiles for SQLite and Postgres (LT-48)
68	
69	**Description:** Build the `docker-compose.yml` in `./local-dev-loop.md`: `sqlite` and `postgres` profiles matching 03's `DB_DRIVER` env var, a mock/local `idp-connector` target, hot-reload (`air`) for `api-service` in dev profiles only, and local-only dev credentials clearly distinguished from the real secrets mechanism (Story 2).
70	
71	**Acceptance criteria:**
72	- [ ] A new developer can run either profile from this file alone, without asking what `DB_DRIVER` values are valid.
73	- [ ] The `postgres` profile exercises the shared `postgres`-package code path (Postgres + CockroachDB) — enforcement site: compose service definition wiring `DB_DRIVER=postgres`.
74	- [ ] Dev credentials never appear in `./secrets-delivery.md`'s mechanism or in any real manifest — enforcement site: explicit statement in the file plus separate variable naming (`dev`/`dev`, hardcoded client id/secret).
75	- [ ] Hot-reload has zero effect on the production image build — enforcement site: `air` target scoped to compose dev profiles only, never `./containerization-design.md`'s Dockerfile.
76	
77	**Depends on:** 03 — `DB_DRIVER`/config-surface env vars (already stable, per `PLANNING.md`).
78	
79	**Model/effort:** Sonnet, low.
80	
81	**Type:** Story.
82	
83	**Labels:** `track-04`, `no-code-yet`.
84	
85	## Story 5 — Observability: logging, metrics, never-log enforcement, retention-sweep alerting (LT-49)
86	
87	**Description:** Implement `./observability.md`: structured `slog` logging with an explicit-field discipline (never a whole request/response struct through a log call), a lint check flagging never-log-list field names, RED metrics with no PII-cardinality labels, ingress-level query-string redaction for search endpoints, RBAC-separated audit-log read access, and 05's S5 retention-sweep requirement — rows-examined/rows-deleted/oldest-surviving-row-age metrics per data class, with an alert when oldest-row-age exceeds retention-window-plus-sweep-interval, since a dead sweep job produces zero rows-deleted either way and gives no other symptom.
88	
89	**Acceptance criteria:**
90	- [ ] 02 confirms the never-log list (`handoff-04-secrets.md`'s eleven items, per the F50 consistency-pass additions of items 10-11) is fully covered by a named enforcement site, not just a policy statement.
91	- [ ] No password, token, JWT, client secret, or DSN reaches a log call — enforcement site: explicit-field logging discipline plus the CI lint check.
92	- [ ] Search-endpoint name/phone query fragments never appear in ingress access logs — enforcement site: ingress log-format override / redaction.
93	- [ ] Audit-log read access is a distinct RBAC grant from Secret-read access — enforcement site: separate `Role` bound to an incident-review group.
94	- [ ] A stopped retention-sweep job triggers an alert within one sweep interval of its window being exceeded — enforcement site: the `oldest_surviving_row_age_seconds` alert rule, per data class.
95	
96	**Depends on:** 02 — `handoff-04-secrets.md`'s never-log list (final); 05 — `pii-governance.md` S5 retention numbers and data-class names (final).
97	
98	**Model/effort:** Sonnet, medium.
99	
100	**Type:** Story.
101	
102	**Labels:** `track-04`, `security-graded`, `no-code-yet`.
103	
104	## Story 6 — Configure log-sink retention for the audit trail (LT-20)
105	
106	**Description:** The consistency pass (`../decisions/cross-track-consistency.md`, "Deletion gap") ruled the enforcement site: a subject-deletion request reaches `user_profile`/`user_credential` by cascade but not application logs, metrics, or the audit trail, none of which has a `source` column or a deletion hook. 02's never-log list is the upstream control (PII values never enter a log in the first place, per `./observability.md`'s enforcement mechanism), which leaves exactly one remaining artifact needing a retention window: the audit trail itself (`sub`, scope, opaque record id, timestamp) — pseudonymous, not PII-free, and after a profile deletion the only remaining record that a given record id was looked up by a given caller. The enforcement site for its expiry is a retention policy on the log sink 04 already operates (Loki or equivalent, per `./observability.md`'s "Audit-log access" section) — not a deletion job, not a DAO method. 05 adds one row to `pii-governance.md`'s retention table for the audit-log window (basis: unknown, pending legal); 02 adds the two vocabulary/list fixes the pass identified for the never-log list (driver-error detail, `username`). This story configures the sink's retention setting to that window once it's a number.
107	
108	**Acceptance criteria:**
109	- [ ] The hand-off standard: 02 and 05 can each confirm their half (never-log list scope; retention-table row) without needing this story rewritten.
110	- [ ] The audit-log stream expires no later than 05's stated window — enforcement site: the log sink's retention configuration (a Loki `retention_period` or equivalent for the chosen sink), not application code.
111	- [ ] The retention configuration is separate from, and does not touch, any other log stream's retention or any Secret-access RBAC (`./secrets-delivery.md`) — enforcement site: sink-level retention is scoped per log stream/index, not global.
112	- [ ] Confirmed this is a configuration value, not a deletion job: no new DAO method, no new `cmd/` entrypoint, no scheduled job beyond what `./observability.md`'s retention-sweep story (Story 5) already covers for `user_profile`/`user_credential`-derived data.
113	
114	**Depends on:** 02 — never-log list additions (driver-error detail, `username`) confirmed; 05 — `pii-governance.md` audit-log retention-window row (basis: unknown, pending legal, per the pass).
115	
116	**Model/effort:** Sonnet, low.
117	
118	**Type:** Story.
119	
120	**Labels:** `track-04`, `from-consistency-pass`, `no-code-yet`.
121	
122	---
123	
124	## Story 7 — Database provisioning in-namespace: Postgres, DB credentials Secret, migration Job, DB_DSN_FILE wiring (LT-52)
125	
126	**Status: new** — created from a gap found during 01's LT-40 refinement (`03-engineering-delivery/refinement/LT-40.md`): none of this track's existing stories (LT-45/46/47/48/49/LT-20) actually deploy a running database instance into `loginid-takehome` — they all assume a DB target already exists. Without it, LT-39's handlers have nothing real behind the DAO, and LT-34/LT-39/LT-40/LT-51's joint live-URL review can't exercise a genuine data path. Full refinement: `04-infra-devops/refinement/postgres-in-namespace.md`.
127	
128	**Description:** A single-replica PostgreSQL `StatefulSet` (with a `PersistentVolumeClaim`) in `loginid-takehome` — a managed instance would be disproportionate infra/cost for this take-home's scale, and a single `StatefulSet` matches this project's existing "small, isolated, no HA beyond what's needed" pattern (Theo's call, confirmed). Plus: a DB credential `Secret` provisioned out-of-band per the pattern already established for the JWT signing key (`deploy/issuer-secret-bootstrap.yaml`); the two-invocation goose migration `Job` in the corrected order (backend directory first, then `shared/`, per `05-data-ops/migration-approach.md`'s own corrected ordering); and `DB_DSN_FILE` wiring so `api-service` actually connects. **CockroachDB is explicitly out of scope for deployment** — it's exercised in CI only (LT-47's testcontainer job), never deployed live in this cluster; stated here so a reviewer doesn't expect to find it running.
129	
130	**Acceptance criteria:**
131	- [ ] Single-replica PostgreSQL `StatefulSet` + `PersistentVolumeClaim` running in `loginid-takehome`.
132	- [ ] A default-deny `NetworkPolicy` scopes Postgres's ingress to `api-service` (and the migration `Job`'s pod) only — matching `idp-connector-default-deny`'s existing shape, not the namespace's default-allow.
133	- [ ] DB credential `Secret` provisioned out-of-band, never through the CI-applied manifest set — same discipline as the JWT signing key.
134	- [ ] Migration-runner credential (DDL rights) and runtime service credential (DML-only, cannot run DDL) are two distinct `Secret`s — enforcement site: the runtime role's Postgres grants exclude `CREATE`/`ALTER`/`DROP`, verified by a failed DDL attempt under that role.
135	- [ ] Migration `Job` runs goose in the corrected order — backend directory (`postgres/`) first, `shared/` second — each against its own version table (`goose_db_version_postgres`, `goose_db_version_shared`); both invocations must succeed for the `Job` to count as successful.
136	- [ ] The migration `Job` is idempotent — a re-run against an already-migrated database applies zero new versions and exits successfully, not an error.
137	- [ ] The migration `Job` completes before `api-service`'s rollout — deploy pipeline ordering, not assumed Kubernetes scheduling.
138	- [ ] `DB_DSN_FILE` (not `DB_DSN`) is set in `api-service`'s live Deployment, pointing at the mounted runtime credential — precedence exercised in the running pod, not only in `internal/config`'s existing unit test.
139	- [ ] `/healthz` reflects real DB connectivity as a boolean/enum field only (consistent with 02's existing ruling on the endpoint's response shape) — never a connection string, host, port, or driver `DETAIL` text, even when the DB is unreachable.
140	- [ ] `deploy/manifests.yaml`'s header comment (currently: "no migration Job, no DB_DSN secret") is updated to match reality.
141	- [ ] `ResourceQuota` headroom for the new `StatefulSet` pod confirmed and adjusted in the same PR if needed — shown in the PR description, not discovered as a second `FailedCreate` (per the `api-service-issuer` incident).
142	
143	**Depends on:** 03 — `api-service`'s `DB_DSN_FILE` config surface (already stable); 05 — `migration-approach.md` (final, corrected ordering).
144	**Blocks:** LT-39's live-URL review (joint with LT-40/LT-51).
145	**Model/effort:** Sonnet, medium.
146	**Type:** Story.
147	**Labels:** `track-04`, `security-graded`.
148	
149	---
150	
151	## Story 8 — Small hardening: wait for Postgres Service DNS before the migration Job connects (follow-up to LT-52)
152	
153	**Status: new** — not blocking, flagged by team-lead after the first real deploy. The migration `Job`'s first attempt hit `lookup postgres.loginid-takehome.svc ... no such host` — Postgres's `StatefulSet` rollout reported Ready before its headless `Service`'s DNS record had actually propagated. The `Job`'s own `backoffLimit: 2` retry absorbed it cleanly (second attempt succeeded), so this didn't block the deploy — but it's a race worth closing rather than relying on retry luck indefinitely.
154	
155	**Description:** Add an `initContainer` (or a small wait loop in the main container's command) to the migration `Job` that polls DNS resolution of `postgres.loginid-takehome.svc` (or a TCP connect to `postgres:5432`) before invoking `goose`, so the first real attempt doesn't depend on winning a race against Service registration.
156	
157	**Acceptance criteria:**
158	- [ ] Migration `Job` waits for Postgres to be reachable (DNS + TCP) before running goose, not just for the `StatefulSet`'s own readiness probe.
159	- [ ] No change to `backoffLimit` or the goose invocation order/logic — this is additive, not a replacement for existing retry behavior.
160	
161	**Depends on:** none — small, self-contained follow-up to LT-52.
162	**Model/effort:** Sonnet, low.
163	**Type:** Task.
164	**Labels:** `track-04`.
165	
166	---
167	
168	## Story 9 — Scope gitleaks to PR commits, add a separate scheduled full-history scan
169	
170	**Status: new** — flagged during PR #34's review. `pr-check.yml`'s gitleaks job scans full history (`fetch-depth: 0`, needed for the tool to work at all) — meaning a leaked-pattern match in *any* commit on a branch fails the PR even after a later commit rewrites/removes it, and would fail every subsequent PR on main forever if such a commit were ever merged. Not currently a live incident (Renata is rewriting the offending commit on her own unmerged branch), but the CI design itself has this sharp edge regardless of whether any specific finding is real or a false positive.
171	
172	**Description:** Two changes, per team-lead's leaning (adopted here, not just recorded neutrally):
173	1. Scope the PR-check gitleaks scan to only the PR's own commits (`--log-opts="origin/${{ github.base_ref }}..HEAD"`), so history already on `main` isn't rescanned on every subsequent PR.
174	2. Add a separate, scheduled (e.g. nightly or on-push-to-main) full-history gitleaks scan as its own workflow, so the full-hi
… truncated (20 KB cap)

{
  "command": "grep -rln \"docker-compose\\|local-dev-loop\\|dev-secrets\" /Users/warrenthompson/Source/LoginID --include=*.md | grep -v \"/04-infra-devops/local-dev-loop.md\\|/04-infra-devops/refinement/LT-48.md\\|/04-infra-devops/backlog.md\""
}

(eval):1: no matches found: --include=*.md

{
  "command": "grep -rl \"docker-compose\\|local-dev-loop\\|dev-secrets\" /Users/warrenthompson/Source/LoginID 2>/dev/null | grep '\\.md$' | grep -v \"04-infra-devops/local-dev-loop.md\\|04-infra-devops/refinement/LT-48.md\\|04-infra-devops/backlog.md\""
}

/Users/warrenthompson/Source/LoginID/PLANNING.md
/Users/warrenthompson/Source/LoginID/PLAN.md
/Users/warrenthompson/Source/LoginID/LOG.md
/Users/warrenthompson/Source/LoginID/03-engineering-delivery/README.md
/Users/warrenthompson/Source/LoginID/decisions/cross-track-consistency.md
/Users/warrenthompson/Source/LoginID/04-infra-devops/research-infra-devops-best-practices.md
/Users/warrenthompson/Source/LoginID/04-infra-devops/PLAN.md
/Users/warrenthompson/Source/LoginID/04-infra-devops/CLAUDE.md

{
  "command": "grep -n -i \"docker-compose\\|local-dev-loop\\|dev-secrets\" /Users/warrenthompson/Source/LoginID/03-engineering-delivery/README.md /Users/warrenthompson/Source/LoginID/decisions/cross-track-consistency.md /Users/warrenthompson/Source/LoginID/04-infra-devops/CLAUDE.md"
}

/Users/warrenthompson/Source/LoginID/04-infra-devops/CLAUDE.md:16:- Local dev-loop story: how a developer would run this stack locally (e.g., docker-compose with a local Postgres and the services).
/Users/warrenthompson/Source/LoginID/04-infra-devops/CLAUDE.md:28:- A local dev-loop description (e.g., docker-compose sketch).
/Users/warrenthompson/Source/LoginID/04-infra-devops/CLAUDE.md:37:Plan approved, hires spawned 3/3, five deliverables drafted and reviewed (`containerization-design.md`, `ci-pipeline.md`, `local-dev-loop.md`, `secrets-delivery.md`, `observability.md`), `backlog.md` written (Epic LT-4). All consistency-pass findings owned by this track are fixed, including F12/F13 (the JWT-signing-key issuer now runs as a separate `api-service-issuer` Deployment, never mounted into the verifying `api-service` Deployment). No code or config committed — still design-only per root `CLAUDE.md`.
/Users/warrenthompson/Source/LoginID/03-engineering-delivery/README.md:7:- **Q1 — DAO layer** (`internal/dao`, `internal/dao/postgres`, `internal/dao/sqlite`): `user_profile`/`user_credential` storage behind one `Repository` interface, real implementations for Postgres/CockroachDB and SQLite. Verified against the actually-deployed Postgres database, and in CI against real Postgres and CockroachDB service containers — `.github/workflows/pr-check.yml`'s `build-lint-test` job sets `TEST_POSTGRES_DSN`/`TEST_COCKROACHDB_DSN` and runs `go test ./...` against them directly; reproduce locally by setting those two env vars to a running Postgres/CockroachDB instance and running the same command (no docker-compose step of this repo's own — `pr-check.yml` uses GitHub Actions service containers). A cross-backend conformance suite (`internal/dao/conformance`, LT-38) asserts all three backends behave identically, not just that their Go signatures match.
/Users/warrenthompson/Source/LoginID/decisions/cross-track-consistency.md:47:**F14 (contradiction — compose leaks inventory-forbidden values).** The compose sketch sets `DB_DSN: postgres://dev:«REDACTED»@postgres:5432/…` (`local-dev-loop.md:24`) and `IDP_ABC_CLIENT_ID: dev-client` / `IDP_ABC_CLIENT_SECRET: dev-secret` as literal env values (`:38-39`) in a file that would be committed. Row 5 of the inventory says these are "never in source or committed config" with "file mount preferred" (`handoff-04-secrets.md:20`) and row 1 makes `DB_DSN_FILE` "Required, not preferred" (`:16`). The disclaimer at `local-dev-loop.md:50` explains the intent but the inventory grants no development exemption. Owner: Theo. Fix, one document (`local-dev-loop.md`): use `${IDP_ABC_CLIENT_SECRET:?}`-style required variables sourced from an untracked `.env`, and `DB_DSN_FILE` pointing at a bind-mounted dev file — or ask Marcus for an explicit dev-profile exemption row.
/Users/warrenthompson/Source/LoginID/decisions/cross-track-consistency.md:79:**F26 (contradiction — reasoning, 04 internal).** `local-dev-loop.md:46`: a CockroachDB profile "would test the same code again, not new code." The contract's `withRetry` "retries only when `engine == cockroachdb`" (`multi-db-strategy.md:331`) — the CockroachDB path is different code, which `ci-pipeline.md:9` itself argues ("wire-compatible isn't schema-compatible"). Owner: Theo. Fix: reword to "omitted locally for loop speed; the CockroachDB path is exercised in CI".
/Users/warrenthompson/Source/LoginID/decisions/cross-track-consistency.md:202:**What changed.** F12 fixed (`handoff-04-secrets.md:3` is v2; 04's five references agree). F13 fixed at its source and downstream: `handoff-04-secrets.md:8` and row 2 (`:17`) define the issuer as "a second Deployment of the same `api-service` image … with its own ServiceAccount that alone mounts the signing-key Secret"; `containerization-design.md:39,68-108` adds `api-service-issuer` with `APP_MODE: issuer` and removes the mount from `api-service`; `secrets-delivery.md:12,24` state why RBAC alone could not do it. F14 fixed: `local-dev-loop.md:14-48` uses compose file-based `secrets:` from an untracked `.dev-secrets/`, no literal secret values remain. F15 fixed: inventory row 10 (`handoff-04-secrets.md:26`); `PLANNING.md:46` adds `CONNECTOR_JWT_AUDIENCE`, `CONNECTOR_CLIENT_ID`/`CONNECTOR_CLIENT_SECRET`. `DB_DSN_FILE` precedence and the issuer/audience literals still agree everywhere.
/Users/warrenthompson/Source/LoginID/decisions/cross-track-consistency.md:226:**What changed.** F28 closed: `migration-approach.md:17-38` makes `shared/` "seed data only — no CREATE TABLE", `postgres/` and `sqlite/` carry all DDL, the correction is visible in place, and "No open items remain in this document" (`:38`). R1–R5 unchanged and still matched by `containerization-design.md:116-120` and `ci-pipeline.md`; the two-invocation mechanism and R3's worked example still hold. The goose `version_id` item remains presented as unverified (`:50`) — left open, as instructed. F27 fixed: `ci-pipeline.md:9` no longer claims `-race` catches R2. F26 fixed: `local-dev-loop.md:56`. Nothing provisional remains; no regression found.
/Users/warrenthompson/Source/LoginID/decisions/cross-track-consistency.md:277:`handoff-03-auth.md:20` now says the signing key "never touches the verifying `api-service` Deployment … runs as its **own Deployment** (`APP_MODE=issuer`, its own ServiceAccount) … the separation has to be a second Deployment, not RBAC alone" — matching `handoff-04-secrets.md:8,17`. `PLANNING.md:46` lists `APP_MODE` = `verifier` (default) | `issuer` alongside `CONNECTOR_JWT_AUDIENCE` and `CONNECTOR_CLIENT_ID`/`_SECRET`. `containerization-design.md:68-115` adds the `api-service-issuer` Deployment, its `Service` (`:109-111`) and a reachability paragraph (`:115`: the verifier fetches JWKS from `https://api-service-issuer.loginid-poc.svc/jwks`). `local-dev-loop.md` remains file-based. Version labels in 04's five references still read v2 and the hand-off is v2. No regression.