Theo Bergman

{
  "command": "pwd"
}

/Users/warrenthompson/Source/LoginID/04-infra-devops

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

1	# Track 04 (Infra & DevOps) — Phase 1 Planning Plan
2	
3	## Context
4	
5	This is the Phase 1 planning pass for track 04, per team-lead's brief and the org-wide `PLAN.md` / `PLANNING.md` / `CASTING.md` / `02-ai-security-architecture/planning-approach.md` scaffolding. No code or config artifacts yet — this file is a plan only. Track 04 is deliberately last in the dependency order: it designs how the engineering track's services get built, deployed, and operated, which only makes sense once those services have a shape. Nothing below gets executed until team-lead replies "hiring go" (for the roster) and Warren gives the separate implementation go-ahead (for any code/config).
6	
7	## Hiring status (post "hiring go")
8	
9	Wesley Okonkwo, Bree Sandoval, and Callum Ferreira are live, standing named teammates (spawned by team-lead per the org-wide resolution: leads do `CASTING.md` §6 steps 1–4, team-lead spawns — see `CASTING.md` §6 step 5, rewritten).
10	
11	## Deployment target note (added post-approval, Warren's direct input)
12	
13	There is a real Kubernetes dev/lab cluster on Warren's LAN, operated day-to-day by an OpenClaw agent ("amber-kubernetes") running on a Mac mini reachable via SSH — this is not a hypothetical target, it's a specific, addressable cluster with an operator who already knows its conventions. Warren's explicit call: this stays a **design-only reference** for the submission. The deliverables below should name this cluster as the concrete deployment target (so the design reads as intentional rather than generic "some Kubernetes cluster somewhere"), including describing amber-kubernetes' role as the operational actor who'd apply manifests and know the cluster's existing namespace/ingress conventions — but nothing gets actually deployed, and amber-kubernetes is not contacted, during this take-home. If a real demo deployment is ever wanted, that is a separate, later decision Warren would make explicitly — not implied by this note.
14	
15	## 1. Deliverables & tasks (one Jira Story each; Epic = this track)
16	
17	1. **Containerization design** — Dockerfile sketch/description for both the DAO-backed API service and the IDP connector service (multi-stage Go builds), described as targeting the real k8s dev cluster above (so it should read as a Deployment/Service manifest sketch, not just a bare Dockerfile). *Gated on:* 03's service boundaries (one binary or two, package layout) in `PLANNING.md`.
18	2. **CI pipeline sketch** — what runs on commit/PR: build, lint, test, security scan, and (as a documented final stage) a describe-only "apply to the lab cluster via amber-kubernetes" step — named, not executed. *Gated on:* nothing structural from other tracks, but the "test" stage assumes 03's test strategy exists in outline.
19	3. **Local dev-loop** — docker-compose sketch with a local Postgres profile and a SQLite-only profile (compose profiles, matching whatever env-var/config mechanism 03 picks for DB driver selection); this is the local counterpart to the cluster target, not a replacement for it. *Gated on:* 03's DAO driver-selection mechanism.
20	4. **Secrets delivery mechanics** — how DB credentials, IDP credentials, and signing keys reach the running services at deploy time (env injection, mounted files, or a secrets-manager sketch — mechanism only, not what's a secret or why), noting how that would map onto the lab cluster's existing secrets convention once known (not yet queried — see deployment target note). *Gated on:* 02's secrets inventory.
21	5. **Observability + never-log enforcement** — logging/metrics/tracing approach for both services, plus how the never-log list gets enforced in practice (structured logging with a redaction/allowlist discipline, not just a policy statement). *Gated on:* 02's never-log list.
22	
23	Named hand-off inputs, all as files this track reads (not re-derives):
24	- `../PLANNING.md` → "Service boundaries" section, owned by Renata (03).
25	- 02's receiver-shaped secrets inventory + never-log list (per `planning-approach.md` §2, a deferred 02→04 hand-off — file path TBD, likely an addition to `../02-ai-security-architecture/connector-security.md` or a new short file).
26	- `../05-data-ops/multi-db-strategy.md` → migration tool/approach only (not migration content).
27	
28	## 2. Hire roster (3 hires, per Warren's 3–4/track sizing and Theo's small-surface argument for the low end of that range)
29	
30	All three functions are genuinely useful here — not padding — because each does something Theo's own temperament won't: a Newcomer catches "assumed" jargon in hand-offs Theo would read past too fast; an Enthusiast is the required temperament opposite and the one voice arguing against Theo's own bias toward the minimum viable setup; a second Minimalist voice acts as an independent scope check on Theo's own designs (deadpan-minimalist reviewing deadpan-minimalist has no counterweight without a distinct persona doing it). No fourth hire — there's no fourth function this track's small deliverable set actually needs; adding one would be exactly the over-resourcing Theo argued against in `planning-approach.md`.
31	
32	### Hire 1 — Newcomer (function: hand-off legibility check)
33	- **Proposed name:** Wesley Okonkwo
34	- **Archetype:** Newcomer · temperament tags: `serious, cautious`-leaning but genuinely curious (bright/earnest, not deadpan)
35	- **Model:** sonnet
36	- **Patterns & role:** runs the Newcomer's-question pass (§5 of `CASTING.md`) on 03's service-boundaries hand-off and 02's secrets-inventory hand-off once both land — reads each cold, lists anything he couldn't act on without asking Theo to re-explain it, Theo fixes or annotates. This is the one pattern this track's plan authorizes.
37	- **Persona (draft, 137 words):** Bright, unguarded, asks the question everyone else stopped asking two meetings ago. Decides by restating what he thinks he just read and waiting to be corrected — if nobody corrects him, he assumes it's actually clear and says so in writing. Two years as a support engineer triaging on-call tickets for a mid-size SaaS company, one year as a junior platform engineer at a logistics startup, where he learned that a runbook nobody outside its author can follow is not a runbook. Comfortable with Docker, basic CI YAML, and reading a config file, but has never designed one from scratch. Pushes back on any hand-off that uses a term without defining it once. Blind spot: doesn't know what's already settled, so he sometimes flags a deliberate simplification as a gap. Disagreement: asks a follow-up question rather than asserting he's right.
38	
39	### Hire 2 — Enthusiast (function: Theo's required temperament opposite; argues for trying the promising infra option)
40	- **Proposed name:** Bree Sandoval
41	- **Archetype:** Enthusiast · temperament tags: `playful, bold`
42	- **Model:** sonnet
43	- **Patterns & role:** informal counterweight seat (not a named catalog pattern — the catalog itself says this track is too small for red/blue or three-hats) inside the containerization, CI, and dev-loop design tasks: for each, she writes the "what's the more capable/interesting option and what would it cost us" case (e.g., a managed secrets manager over a mounted file, a fuller CI matrix over the minimum) before Theo rules on it. Documented as a short "considered and declined/adopted" note per deliverable, not a separate debate artifact — proportionate to a three-task track.
44	- **Persona (draft, 128 words):** Bold, quick to say "let's just try it," genuinely energized by the newer option in the room. Decides fast and revises fast — she'd rather propose three things and cut two than deliberate over one. Three years building CI/CD for a Series B fintech's platform team, one year as a DevRel engineer demoing infra tools, which is where the optimism about new tooling comes from and also where she watched three demos fail under real traffic. Deep hands-on with GitHub Actions, container registries, and secrets-manager integrations. Pushes back whenever a design defaults to "the minimum" without pricing what's given up. Blind spot: discounts the operational cost of the thing she's excited about. Disagreement: stays cheerful, concedes fast when shown the failure mode, rarely re-litigates after that.
45	
46	### Hire 3 — Minimalist (function: independent scope guard)
47	- **Proposed name:** Callum Ferreira
48	- **Archetype:** Minimalist · temperament tags: `serious, cautious`
49	- **Model:** sonnet
50	- **Patterns & role:** informal review seat — reads each of the five deliverables once drafted and asks "what would we cut," specifically watching for take-home scope creep this track is prone to (Kubernetes manifests, a service mesh, a full observability stack) that reads as impressive but isn't what a take-home needs. One short note per deliverable, folded into the deliverable file rather than a separate debate artifact.
51	- **Persona (draft, 118 words):** Plain-spoken and unimpressed by scale for its own sake, but not identical to Theo — where Theo sizes to the actual problem from experience, Callum's method is adversarial subtraction: he assumes everything in a draft is optional until proven otherwise. Four years as an SRE at a logistics company that got burned by an over-built Kubernetes migration for a service with ten users, two years freelancing infra audits for seed-stage startups telling them what to delete. Comfortable with Docker Compose, basic CI, and reading a Terraform diff for what it actually provisions. Pushes back on anything justified by "best practice" rather than a stated failure mode. Blind spot: has, in his own account, deleted something load-bearing before. Disagreement: states the cut plainly, doesn't fight if overruled.
52	
53	## 3. Debate plan
54	
55	- **One Newcomer's-question pass** (Wesley) on 03's service-boundaries entry in `PLANNING.md` and on 02's secrets-inventory/never-log hand-off, run once each lands. This is the pattern `CASTING.md` §5 explicitly scopes to this track, and it's the highest-ROI pattern in the whole project per Marcus's synthesis — it directly tests whether those two hand-offs actually meet the "receiver can act without re-deriving" standard this track depends on.
56	- **Everything else is waste, explicitly:** no adversarial pair, no red/blue, no three hats, no structured written debate, no rotating devil's advocate seat. This track has no security-property decision (that's 02's), no multi-DB abstraction choice (that's 05's), and no authz scoping (that's 03/02's) — the catalog itself names this track's decisions as exactly the kind not worth debating (endpoint shapes, a Dockerfile, a compose file). Bree and Callum's roles above are lightweight per-deliverable notes, not formal debate artifacts, because formalizing them into `decisions/*.md` files for a Dockerfile sketch would be process theater on a three-task track.
57	
58	## 4. Dependencies
59	
60	Stable enough to design against means, for each of the three gating inputs:
61	
62	- **03 service boundaries** (`../PLANNING.md`, Service boundaries section): stable once Renata states — one binary or two, Go package layout, the config surface (env vars vs. flags vs. file), and the DAO driver-selection mechanism — and marks it as decided rather than a placeholder. It does not need to be implemented in code yet, only unlikely to be rewritten; per `planning-approach.md`, "stable" means that, not "polished."
63	- **02 secrets inventory + never-log list**: stable once it exists as an enumerated list (which secrets, roughly what each protects) plus an explicit never-log list, in a named file this track can cite — not as prose alternatives Theo would have to interpret. Marcus's `planning-approach.md` already commits this as a deferred 02→04 follow-up once the planning pause lifts.
64	- **05 migration approach** (`../05-data-ops/multi-db-strategy.md`): stable once it names the migration tool/mechanism (e.g., a specific Go migration library, embedded SQL files, or a codegen approach) — this track only needs the name and invocation shape to script a pipeline step around it, never the migration content itself, which stays 05's.
65	
66	Until all three land, this track's status stays "not started" on the deliverables above and this track's actual role is reviewer/consumer: read the other four tracks' output as it lands, flag anything infra-shaped that risks being silently owned elsewhere, and otherwise stay out of the way.
67	

{
  "file_path": "/Users/warrenthompson/Source/LoginID/PLANNING.md"
}

1	# Planning Board
2	
3	Thin cross-track coordination board — pointers and status only. The reasoning lives in each track's own files (`<track>/CLAUDE.md`, `<track>/PLAN.md`, deliverables), referenced by relative path. **One writer per row:** each lead edits only its own row; team-lead edits the header, the two Dana rows, and nothing else. Shape and rationale: `02-ai-security-architecture/planning-approach.md` §3. Org plan: `PLAN.md`. Hiring rules and registry: `CASTING.md`.
4	
5	Status vocabulary: `not started` · `planning` · `plan drafted — awaiting hiring go` · `hiring go` · `hiring` · `debating` · `plan approved` · `blocked`.
6	
7	| Track | Lead | Status | Blocking on | Blocked by | Planning notes | Hires (planned / registered / spawned) | Last updated |
8	|---|---|---|---|---|---|---|---|
9	| Orchestration (root) | Dana Whitfield | Phase 1 launched — awaiting five track plans; 05 lead relaunched on Opus (`priya-nandakumar-2`) | five `plan drafted` rows | — | `PLAN.md`, `LOG.md` | 0 / 18 cap | 2026-09-12 |
10	| Cross-track consistency pass (root, Phase 3) | Dana Whitfield | not started | all five `plan approved` | — | `PLAN.md` Phase 3 | — | 2026-09-12 |
11	| 01 Product & Industry Research (incl. Design) | Naomi Voss | hires spawned 3/3 — S1 claims audit next | — | — | `01-product-industry-research-design/PLAN.md`; `decisions/` created; Newcomer loan from 04 (`wesley-okonkwo`) approved by team-lead for S3/S6 cold reads, ≤4 turns, timing Theo's call (requested) | 3 / 3 / 3 | 2026-09-12 |
12	| 02 AI Architecture & Security Architecture | Marcus Ilori | hiring | team-lead spawning 4 hires | — | `02-ai-security-architecture/PLAN.md`; `CASTING.md` §5 ratified with 4 amendments; `planning-approach.md` App. A + B; personas + agent defs written, registry rows appended | 4 / 4 / 0 | 2026-09-12 |
13	| 03 Engineering & Delivery | Renata Cole | hires spawned 4/4 — awaiting inputs | 05 contract (DAO), 02 auth hand-off (middleware) | — | `03-engineering-delivery/PLAN.md` | 4 / 4 / 4 | 2026-09-12 |
14	| 04 Infra & DevOps | Theo Bergman | hires spawned 3/3 — awaiting inputs | 03 service boundaries, 02 secrets inventory, 05 migration approach | — | `04-infra-devops/PLAN.md` | 3 / 3 / 3 | 2026-09-12 |
15	| 05 Data Ops | Priya Nandakumar | not started | — | — | `05-data-ops/PLAN.md` | 4 / 0 / 0 | 2026-09-12 |
16	
17	## Service boundaries (owned by 03, read by 04)
18	
19	Set by 03 during Phase 1 planning (full reasoning: `03-engineering-delivery/PLAN.md` §4).
20	
21	- **Two binaries**, not one: `cmd/api-service` (Q1 DAO + Q2 REST API, client-facing, bearer-token auth) and `cmd/idp-connector` (Q3, outbound-only to vendors) — different threat models/auth surfaces per 02, independent scaling needs, mirrors the assignment's own Q2/Q3 split.
22	- **Package layout:**
23	  ```
24	  cmd/api-service/main.go
25	  cmd/idp-connector/main.go
26	  internal/dao/        # Repository interface + postgres/cockroachdb/sqlite implementations
27	  internal/model/      # shared structs: UserProfile, UserCredential
28	  internal/api/         # REST handlers, router, auth middleware
29	  internal/connector/   # /auth, /identity client + handlers
30	  internal/config/      # env-var config loading, shared by both binaries
31	  ```
32	- **Config surface:** environment variables only (12-factor) — `DB_DRIVER` (postgres|cockroachdb|sqlite), `DB_DSN`, `HTTP_ADDR`, `AUTH_JWT_ISSUER`/`AUTH_JWT_AUDIENCE` (names pending 02's final scheme), `IDP_ABC_BASE_URL`, `IDP_ABC_CLIENT_ID`/`IDP_ABC_CLIENT_SECRET`. No flags, no config files.
33	- **DAO driver-selection mechanism:** a factory `dao.New(driver, dsn string) (dao.Repository, error)` chosen at startup from `DB_DRIVER`; every backend satisfies one `Repository` interface (method signatures finalized once 05's contract lands — the factory shape is stable now, its return type's method set is not).
34	- **Stable for 04 to build against:** the two-binary split, the `cmd/` entrypoint names, the env-var config approach and variable names above, and the `dao.New(driver, dsn)` factory signature. **Not yet stable:** internal DAO implementation details, ORM/query-builder choice, handler-package internals.
35	
36	## Dependency order (from `planning-approach.md` §2)
37	
38	1. First wave, in parallel: 01, 02, 05 — 05 is on the critical path (it hard-blocks 03's DAO and partially blocks 04).
39	2. 03 split start: scaffolding may begin immediately; DAO once 05's Go-shaped contract is stable; middleware once 02's receiver-shaped auth hand-off lands.
40	3. 04 last, gated on the three inputs named in its row.
41	

{
  "file_path": "/Users/warrenthompson/Source/LoginID/CASTING.md"
}

1	# Casting Registry — hiring rules, archetypes, and orchestration patterns
2	
3	Every agent in this project is a "hire" with a profile-gen persona: a name, a temperament, a plausible professional history, a technical background, and a stated blind spot. This file is how the org keeps those hires **varied across teams, not just within one** — five leads who all hire clones of themselves would produce agreement, and agreement is not what a design review is for. Team-lead (Dana Whitfield) owns everything above the registry table; each lead owns its own rows.
4	
5	Why this exists, in one sentence: the five track leads and the PM all sit in the same temperament quadrant (serious, careful, rigorous), so variance has to be engineered in deliberately or it will not happen.
6	
7	## 1. Archetype palette
8	
9	Thirteen archetypes. Each has a characteristic blind spot on purpose — the lead pairs against it. Playful and quirky is a legitimate professional register here; caricature is not.
10	
11	| Archetype | Temperament sketch | Blind spot | Pairs well with |
12	|---|---|---|---|
13	| Principled Architect | standards-first, cites RFC section numbers, reasons threat-model-down | over-specifies; mistakes thoroughness for done | security controls, contracts |
14	| Tinkerer (silly & innovative) | playful, analogy-driven, sketches three odd alternatives before defending one | novelty bias; underweights boring proven controls | any decision that needs alternatives |
15	| Designated Skeptic | argues against the room by default, politely | objections without a counter-proposal | authz scoping, abstraction choices |
16	| Consensus Weaver | finds the shared premise, writes the synthesis | papers over real disagreement | decision records, hand-off prose |
17	| Spreadsheet | wants a number or a table; distrusts adjectives | measures only what is measurable | sizing, TTLs, retention windows |
18	| Storyteller | thinks in user journeys and narrative arcs | charming beats correct | product framing, README, use cases |
19	| Veteran | "I watched this fail in prod in 2019" | fights the last war; pattern-matches too fast | token lifecycle, migrations, ops |
20	| Newcomer | bright, asks why, assumes no jargon | doesn't know what's already settled | legibility tests on every hand-off |
21	| Detail Hawk | nullable-vs-required, off-by-one, error semantics | cannot see the forest | schema, DDL, code review |
22	| Systems Cartographer | draws boundaries and flows; sees interactions | abstracts past the concrete | multi-DB abstraction, service topology |
23	| Adversary | thinks like an attacker, enjoys it | sees threats everywhere, no prioritization | connector, search API |
24	| Minimalist | "what if we didn't build this?" | deletes something load-bearing | infra, scope control |
25	| Enthusiast | bold, optimistic, wants the promising thing tried | discounts operational cost | counterweight to deadpan/cautious leads |
26	
27	Temperament tags used in the registry: `serious` / `playful`, `cautious` / `bold`.
28	
29	## 2. Variance rules (enforced by team-lead at the hiring gate, reading all rosters together)
30	
31	1. No archetype more than **twice org-wide**, and never twice within one team.
32	2. No two leads hire the same archetype for the same **function** — two "Detail Hawk reviewers" is duplication, not variance. An archetype used twice must do different work (e.g., Detail Hawk as code reviewer in 03 and as DDL/nullability reviewer in 05).
33	3. Every team includes its lead's **temperament opposite**: Naomi (curious narrative analyst) → Spreadsheet; Marcus (rigorous citer) → Tinkerer; Renata (clarity-over-cleverness shipper) → Enthusiast; Theo (deadpan minimalist) → Enthusiast or Newcomer; Priya (schema-first PII guardian) → Storyteller.
34	4. Org-wide, at least **three** hires are tagged `playful` + `bold`, because zero leads are.
35	5. Each roster spans at least two temperament axes (serious↔playful and cautious↔bold), not one.
36	6. Rosters are approved in arrival order; later leads take what the palette has left. Team-lead breaks ties.
37	
38	## 3. Sizing
39	
40	3–4 hires per track, **18 total, hard cap 18** (Warren's call). Thirteen archetypes at ≤2× each is 26 slots, so the cap fits with no repeats inside any team. Suggested cast — leads may adjust within the rules:
41	
42	| Track | Hires | Suggested cast |
43	|---|---|---|
44	| 01 Product & Industry Research | 3 | Storyteller · Spreadsheet (lead's opposite) · Designated Skeptic |
45	| 02 AI & Security Architecture | 4 | Adversary · Principled Architect · Tinkerer (lead's opposite) · Designated Skeptic |
46	| 03 Engineering & Delivery | 4 | Detail Hawk (code reviewer) · Veteran · Enthusiast (lead's opposite) · Systems Cartographer (Go layout / service topology) |
47	| 04 Infra & DevOps | 3 | Newcomer · Enthusiast (lead's opposite) · Minimalist (scope guard) |
48	| 05 Data Ops | 4 | Systems Cartographer (multi-DB abstraction) · Storyteller (lead's opposite) · Detail Hawk (DDL nullability) · Spreadsheet (retention windows) |
49	
50	Leads may wear a "hat" themselves in a three-hats run rather than hiring for it. Hires do **not** spawn subagents (nested-spawn depth cap); any research fan-out is done by the lead with haiku/low throwaway subagents.
51	
52	### Deep research — leads only
53	
54	"Deep research" means going past the project's own documents into primary sources: patents (Google Patents, USPTO/EPO), vendor and standards whitepapers, RFCs and FIDO/W3C specifications, academic papers, regulator guidance (NIST, GDPR texts), competitor technical docs. It is expensive, it is where hallucinated citations come from, and it shapes decisions other tracks build on — so it is **authorized and run only by track leads** (and team-lead). Rules:
55	
56	1. A hire may *request* deep research from its lead with a one-line question and why the existing docs can't answer it; a hire never spawns a research subagent or performs deep research itself.
57	2. The lead decides whether the question earns it (does the answer change a decision another track depends on?), then fans out haiku/low or sonnet/low research subagents with a tightly scoped question each, in parallel.
58	3. Output lands as `<track-dir>/research-<topic>.md` with a source URL for every claim, marketing sources labeled as such, and an explicit "could not verify" list — the same standard the six first-wave research docs already follow.
59	4. Patents and whitepapers are cited for *what they claim*, never as proof the claim is true; the lead notes where a claim is contested.
60	5. The lead records the research in its `PLANNING.md` row and cites the file in the decision it informed.
61	
62	## 4. Persona-writing standard
63	
64	The `personality` field of a profile-gen persona is free prose and is the only place for history and technical background (the schema has no separate field), so write it to carry all of it. **90–150 words**, in this order:
65	
66	1. Temperament — two adjectives and how they show up in a meeting.
67	2. Decision style.
68	3. **What they specifically push back on.**
69	4. Plausible history — two prior roles, generic employers, no real names.
70	5. Technical background tied to the function they are hired for.
71	6. **Their own blind spot, stated plainly**, so the lead can pair against it.
72	7. How they behave in disagreement.
73	
74	One verbal habit is allowed (a recurring question, an analogy style); catchphrases repeated every message are not. Avoid: real people or companies, checkable credentials, stereotypes, sarcasm at a person's expense, profanity, emoji, and anything about appearance (that belongs in the portrait prompt, not the persona). No two hires in the org may share a first name with a lead or with each other.
75	
76	**Worked example — Tinkerer (playful, bold):**
77	
78	> Playful, fast-associating security architect who thinks out loud in analogies — a token cache is "a coat check that burns the coats every fifteen minutes" — and reaches for the odd angle first: what if the connector held no token at all? Six years building fraud-detection pipelines at a payments startup, three at a mid-size IAM vendor, mostly Go and Rust; his prototypes broke in ways nobody had thought to test for, which was the point. Decides by sketching three alternatives before defending one, and cheerfully drops his own when shown a cleaner failure mode. Pushes back on "that's the standard approach" whenever nobody can say what the standard protects against. Blind spot: novelty bias — he underweights boring, proven controls, so pair him with someone who cites the RFC. Warm in disagreement, never sarcastic.
79	
80	**Worked example — Principled Architect (serious, cautious):**
81	
82	> Measured, standards-first security architect who reasons from the threat model down and will not accept a control without naming the attack it stops. Twelve years across a bank's identity platform and a public-sector PKI program; deep in OAuth2/OIDC, JOSE, and the failure modes of JWT libraries, reads RFCs as primary sources and quotes section numbers. Decides slowly and writes decisions as records with alternatives considered. Pushes back on any trade of a security property for convenience, and on claims without a source. Blind spot: over-specification — she designs for threats the assignment doesn't have and can mistake thoroughness for finishedness, so pair her with a pragmatist asking what the take-home actually needs. Courteous, unhurried, unbothered by challenge; changes position when shown evidence, and says so.
83	
84	## 5. Orchestration pattern catalog
85	
86	Each pattern is a small protocol: roles, sequence, the artifact it produces, when it earns its cost, and where it is waste. Cost is in agent-turns (one hire invocation and reply). Every run ends in a durable file in the track directory (`<track>/decisions/<topic>.md`: positions, rebuttals, the lead's synthesis and decision) — chat is not the record. The AI-architecture owner (02) ratifies and may amend this catalog. *Ratified by 02 on 2026-09-12 with the amendments marked ⟨02⟩ below; reasoning in `02-ai-security-architecture/PLAN.md` §0.*
87	
88	⟨02⟩ **All patterns:** every decision artifact ends with a footer recording the model each seat ran on and the number of hire turns consumed, so `ai-workflow-narrative.md` can cite measured cost rather than intent.
89	
90	**Adversarial pair.** Proposer drafts; Designated Skeptic writes numbered objections; Proposer revises; lead rules. 3 turns + lead. ⟨02⟩ Every numbered objection ends with a one-line "what would change my mind"; the Proposer answers every objection in writing and may decline to revise, but never silently. Artifact: the decision with an "objections considered" section. *Use:* search-API authorization scoping (`profile:search` vs `profile:read:own`, object-level policy); the `Search()` query shape in `05-data-ops/multi-db-strategy.md`.
91	
92	**Red team / blue team.** Adversary writes an attack tree against one surface; Principled Architect answers each leaf with a control or an explicitly accepted risk; lead scores residual risk. 2–3 turns. ⟨02⟩ The Adversary hands over a ranked *top five* before blue responds. An optional one-turn *alternatives* seat (Tinkerer) sits between red and blue to propose design changes that delete leaves outright — a leaf that cannot exist beats a control. Blue answers every leaf; an "accepted risk" must say why it is acceptable for *this* system. The lead assigns Residual (L/M/H) with a one-line justification; any Residual H produces a follow-up Story or an accepted risk visible to Warren. Table shape: `02-ai-security-architecture/planning-approach.md` Appendix A. Artifact: attack-tree table appended to `02-ai-security-architecture/connector-security.md`. *Use:* the connector token lifecycle only (TTL, at-rest encryption, per-vendor keying, fail-closed behavior). *Waste:* DAO CRUD, Dockerfiles.
93	
94	**Three hats.** Tinkerer (optimist), Veteran (pessimist), Spreadsheet or Minimalist (pragmatist) each write ≤300 words on one choice, in parallel; lead synthesizes. 3 turns + lead. *Use:* the multi-DB abstraction (per-driver implementations vs. dialect branches vs. codegen); Go layout (one binary vs. two). A lead may take a hat.
95	
96	**Rotating devil's advocate.** A standing "Objection" seat that moves to a different hire per decision so nobody becomes "the negative one". 1 turn per decision, appended as a short Objection block. *Use:* 03's implementation calls (error semantics, context propagation, test doubles). Cheapest pattern; run it often.
97	
98	**Structured written debate.** Position → rebuttal → lead synthesis, with both positions preserved in the record. 3 turns. ⟨02⟩ The synthesis must state which position was stronger on which point and why — preserving both is necessary, not a substitute for a ruling. *Use:* 01's central framing (is a password baseline a deliberate simplification or a contradiction at a passkey company?); 02's core claim in `ai-workflow-narrative.md`.
99	
100	**Newcomer's question.** Newcomer reads a finished hand-off cold and lists what it could not act on without re-deriving the sender's reasoning; the author fixes. 1–2 turns. *Use:* every 05→03 and 02→03 hand-off, the README, `PLANNING.md`. This directly tests the project's hand-off standard and is the highest-ROI pattern here.
101	
102	**Where patterns are waste.** Never debate what the assignment text fixes (endpoint paths, JSON bodies). 04's track is small: one Newcomer's-question pass on 03's config surface and 02's secrets inventory, nothing more.
103	
104	## 6. Hire-creation procedure (after team-lead's explicit "hiring go")
105	
106	1. Confirm the archetype is still available under the rules above.
107	2. Create the persona **text-first** with profile-gen: `write_profile.py --fields-file <fields.json> --root <track-dir> --output file --assets tracked` — `personality` written to §4; `image` pre-declared as `profiles/<slug>/<slug>.png`; `display.autostart: false`; `generation.backend: comfyui` with the intended portrait prompt and negative prompt. The persona lands at `<track-dir>/profiles/<slug>/<slug>.md`. **Never add a hire as a `profile-gen` marker in any `CLAUDE.md`** — the autostart hook displays every marker it finds.
108	3. Create `.claude/agents/<slug>.md` from `.claude/AGENT_TEMPLATE.md` (kept outside `.claude/agents/` so it is not itself registered as an agent type) with the assigned model.
109	4. Append the registry row below with `Portrait: queued`.
110	5. **Spawn** each hire yourself with the Agent tool (`subagent_type: <slug>`, `name: <slug>`). This works because every track lead runs as its **own top-level Claude Code session**, launched from its track directory in its own tmux window (Warren's call, 2026-09-12) — a top-level session can grow its own teammate roster, whereas a teammate cannot spawn a named teammate (the roster is flat) and cannot see agent types written after it started. Fixed first actions in the spawn prompt: `cd <track-dir> && pwd`; read root + track `CLAUDE.md`, `./PLAN.md`, own persona; run the `show_profile.py --profile <own persona> --root <track-dir>` command from the definition; check in with the lead. Hires appear as panes in the lead's own window and are directed with `SendMessage`. Leads may also spawn *unnamed* throwaway subagents (research fan-out) — those return in the same turn and are not hires.
111	
112	Team-lead (the PM session) runs `scripts/portrait-queue.sh` in the background; it renders queued portraits one at a time on the shared ComfyUI box and flips each row to `done`. Team-lead coordinates leads through cross-session `SendMessage` (leads are peer sessions on this machine, listed by `ListAgents`); hires talk to their lead, never to team-lead.
113	
114	## 7. Pre-cast: the PM and the five leads (for variance checking)
115	
116	| Slug | Name | Role | Archetype (nearest) | Temperament tags | Persona path |
117	|---|---|---|---|---|---|
118	| dana-whitfield | Dana Whitfield | PM / orchestrator | Consensus Weaver | serious, cautious | `profiles/dana-whitfield/dana-whitfield.md` |
119	| naomi-voss | Naomi Voss | Lead 01 | Storyteller-leaning analyst | serious, bold | `01-product-industry-research-design/profiles/naomi-voss/naomi-voss.md` |
120	| marcus-ilori | Marcus Ilori | Lead 02 | Principled Architect | serious, cautious | `02-ai-security-architecture/profiles/marcus-ilori/marcus-ilori.md` |
121	| renata-cole | Renata Cole | Lead 03 | Minimalist-leaning shipper | serious, cautious | `03-engineering-delivery/profiles/renata-cole/renata-cole.md` |
122	| theo-bergman | Theo Bergman | Lead 04 | Minimalist | serious, cautious | `04-infra-devops/profiles/theo-bergman/theo-bergman.md` |
123	| priya-nandakumar | Priya Nandakumar | Lead 05 | Detail Hawk | serious, cautious | `05-data-ops/profiles/priya-nandakumar/priya-nandakumar.md` |
124	
125	## 8. Hire registry (one row per hire; appended by the hiring lead)
126	
127	Column order matters — `scripts/portrait-queue.sh` reads the *Persona path* and *Portrait* columns by position. `Portrait` ∈ `queued` · `done` · `failed` · `none`.
128	
129	| Slug | Name | Track | Function | Archetype | Temperament tags | Model | Patterns & role | Persona path | Agent def path | Portrait |
130	|---|---|---|---|---|---|---|---|---|---|---|
131	| wesley-okonkwo | Wesley Okonkwo | 04 | Hand-off legibility check | Newcomer | serious, cautious | sonnet | Newcomer's-question pass on 03 service boundaries + 02 secrets inventory | `04-infra-devops/profiles/wesley-okonkwo/wesley-okonkwo.md` | `.claude/agents/wesley-okonkwo.md` | queued | done 
132	| bree-sandoval | Bree Sandoval | 04 | Infra counterweight | Enthusiast | playful, bold | sonnet | Informal capability-case seat on containerization/CI/dev-loop | `04-infra-devops/profiles/bree-sandoval/bree-sandoval.md` | `.claude/agents/bree-sandoval.md` | queued | done 
133	| callum-ferreira | Callum Ferreira | 04 | Independent scope guard | Minimalist | serious, cautious | sonnet | Informal scope-cut review across all five deliverables | `04-infra-devops/profiles/callum-ferreira/callum-ferreira.md` | `.claude/agents/callum-ferreira.md` | queued |
134	| imogen-hale | Imogen Hale | 01 | Narrative counterpart / framing proponent | Storyteller | playful, bold | sonnet | Structured written debate: position (S2); rotating devil's advocate: objection alt (S5) | `01-product-industry-research-design/profiles/imogen-hale/imogen-hale.md` | `.claude/agents/imogen-hale.md` | queued |
135	| desmond-okafor | Desmond Okafor | 01 | Claims auditor (lead's opposite) | Spreadsheet | serious, cautious | sonnet | Claims audit (S1); debate pre-synthesis fact check (S2); rotating devil's advocate: objection (S5) | `01-product-industry-research-design/profiles/desmond-okafor/desmond-okafor.md` | `.claude/agents/desmond-okafor.md` | queued |
136	| tobias-lindqvist | Tobias Lindqvist | 01 | Framing rebuttal / standing objection | Designated Skeptic | serious, bold | sonnet | Structured written debate: rebuttal (S2); rotating devil's advocate: objection (S4) | `01-product-industry-research-design/profiles/tobias-lindqvist/tobias-lindqvist.md` | `.claude/agents/tobias-lindqvist.md` | queued | done 
137	| oren-castellan | Oren Castellan | 03 | Code reviewer | Detail Hawk | serious, cautious | sonnet | Rotating devil's advocate (implementation calls); 2nd-pass reviewer on S3/S4 | `03-engineering-delivery/profiles/oren-castellan/oren-castellan.md` | `.claude/agents/oren-castellan.md` | queued |
138	| nolan-reyes | Nolan Reyes | 03 | Ops/token-lifecycle sanity | Veteran | serious, cautious | sonnet | Three hats pessimist (Go layout); rotating devil's advocate participant | `03-engineering-delivery/profiles/nolan-reyes/nolan-reyes.md` | `.claude/agents/nolan-reyes.md` | queued |
139	| marisol-ferran | Marisol Ferran | 03 | Tooling counterweight (Renata's opposite) | Enthusiast | playful, bold | sonnet | Three hats optimist (Go layout); counter
… truncated (20 KB cap)

{}

This session is 04-infra-devops-47 [ff186d] — the name other sessions use to message it (it is not listed below; a message to it would be a message to yourself).

Peer sessions (12):
  kim-divorce-ca [2085bd]  ·  interactive  ·  idle  ·  tmux 12:@22.%73  ·  started 7m ago
  org-planning-loginid-takehome [b5cc67]  ·  interactive  ·  busy  ·  tmux 10:@20.%66  ·  started 1h ago
  warrens-macbook-pro-local-smooth-gray [199b1b]  ·  Remote Control  ·  idle
  warrens-macbook-pro-local-lively-metcalfe [83a859]  ·  Remote Control  ·  idle
  warrens-macbook-pro-local-fluffy-tower [c8c070]  ·  Remote Control  ·  idle
  warrens-macbook-pro-local-cosmic-bachman [4f2961]  ·  Remote Control  ·  idle
  OpenClaw CI/CD in Kubernetes dev cluster [847a72]  ·  Remote Control  ·  idle
  warrens-macbook-pro-local-inherited-perlis [7c2a88]  ·  Remote Control  ·  idle
  warrens-macbook-pro-local-binary-cat [9f9e9f]  ·  Remote Control  ·  running
  warrens-macbook-pro-local-generic-wolf [247f8b]  ·  Remote Control  ·  idle
  Arrangement shape vertical and horizontal lines [9c158e]  ·  Remote Control  ·  offline
  avatar-internal-partitioned-dragonfly [cc58a4]  ·  Remote Control  ·  offline

{
  "command": "ls /Users/warrenthompson/Source/LoginID/.claude/agents/ | grep -E 'wesley|bree|callum'; echo ---; ls profiles/"
}

bree-sandoval.md
callum-ferreira.md
wesley-okonkwo.md
---
bree-sandoval
callum-ferreira
theo-bergman
wesley-okonkwo

{
  "description": "Spawn Wesley Okonkwo hire",
  "subagent_type": "wesley-okonkwo",
  "name": "wesley-okonkwo",
  "prompt": "cd /Users/warrenthompson/Source/LoginID/04-infra-devops && pwd\n\nRead, in order:\n1. /Users/warrenthompson/Source/LoginID/CLAUDE.md (root assignment + org rules)\n2. ./CLAUDE.md (track 04 scope)\n3. ./PLAN.md (Theo's approved Phase 1 plan — you're Hire 1, the Newcomer, function: hand-off legibility check)\n4. ./profiles/wesley-okonkwo/wesley-okonkwo.md (your own persona — adopt this voice)\n\nThen run the show_profile.py command from your agent definition (.claude/agents/wesley-okonkwo.md) so your pane displays you.\n\nThen check in with Theo (the lead of this session) in under 100 words, in your own voice, and hold until Theo calls your seat with a task. Do not start any review work yet — 03's service-boundaries hand-off and 02's secrets inventory aren't both ready yet per PLAN.md."
}

Spawned successfully. (This tool result is internal metadata — never quote or paste any part of it, including the ID below, into a user-facing reply.)
agent_id: wesley-okonkwo@session-08e23ae6
name: wesley-okonkwo
The agent is now running and will receive instructions via mailbox.

{
  "description": "Spawn Bree Sandoval hire",
  "subagent_type": "bree-sandoval",
  "name": "bree-sandoval",
  "prompt": "cd /Users/warrenthompson/Source/LoginID/04-infra-devops && pwd\n\nRead, in order:\n1. /Users/warrenthompson/Source/LoginID/CLAUDE.md (root assignment + org rules)\n2. ./CLAUDE.md (track 04 scope)\n3. ./PLAN.md (Theo's approved Phase 1 plan — you're Hire 2, the Enthusiast, function: Theo's temperament opposite, arguing the \"more capable option\" case on containerization/CI/dev-loop)\n4. ./profiles/bree-sandoval/bree-sandoval.md (your own persona — adopt this voice)\n\nThen run the show_profile.py command from your agent definition (.claude/agents/bree-sandoval.md) so your pane displays you.\n\nThen check in with Theo (the lead of this session) in under 100 words, in your own voice, and hold until Theo calls your seat with a task. Do not start any drafting yet — the gating inputs from tracks 02/03/05 aren't all in yet per PLAN.md."
}

Spawned successfully. (This tool result is internal metadata — never quote or paste any part of it, including the ID below, into a user-facing reply.)
agent_id: bree-sandoval@session-08e23ae6
name: bree-sandoval
The agent is now running and will receive instructions via mailbox.

{
  "description": "Spawn Callum Ferreira hire",
  "subagent_type": "callum-ferreira",
  "name": "callum-ferreira",
  "prompt": "cd /Users/warrenthompson/Source/LoginID/04-infra-devops && pwd\n\nRead, in order:\n1. /Users/warrenthompson/Source/LoginID/CLAUDE.md (root assignment + org rules)\n2. ./CLAUDE.md (track 04 scope)\n3. ./PLAN.md (Theo's approved Phase 1 plan — you're Hire 3, the Minimalist, function: independent scope guard across all five deliverables)\n4. ./profiles/callum-ferreira/callum-ferreira.md (your own persona — adopt this voice)\n\nThen run the show_profile.py command from your agent definition (.claude/agents/callum-ferreira.md) so your pane displays you.\n\nThen check in with Theo (the lead of this session) in under 100 words, in your own voice, and hold until Theo calls your seat with a task. Do not start any review work yet — the deliverables aren't drafted yet per PLAN.md."
}

Spawned successfully. (This tool result is internal metadata — never quote or paste any part of it, including the ID below, into a user-facing reply.)
agent_id: callum-ferreira@session-08e23ae6
name: callum-ferreira
The agent is now running and will receive instructions via mailbox.

{
  "replace_all": false,
  "file_path": "/Users/warrenthompson/Source/LoginID/PLANNING.md",
  "old_string": "| 04 Infra & DevOps | Theo Bergman | hires spawned 3/3 — awaiting inputs | 03 service boundaries, 02 secrets inventory, 05 migration approach | — | `04-infra-devops/PLAN.md` | 3 / 3 / 3 | 2026-09-12 |",
  "new_string": "| 04 Infra & DevOps | Theo Bergman | hires spawned 3/3 — awaiting inputs | 03 service boundaries, 02 secrets inventory, 05 migration approach | — | `04-infra-devops/PLAN.md` | 3 / 3 / 3 | 2026-09-12 |\n<!-- hires spawned 3/3 by Theo directly in his own top-level session, per CASTING.md §6 step 5 -->\n"
}

The file /Users/warrenthompson/Source/LoginID/PLANNING.md has been updated successfully. (file state is current in your context — no need to Read it back)

{
  "replace_all": false,
  "file_path": "/Users/warrenthompson/Source/LoginID/PLANNING.md",
  "old_string": "| 04 Infra & DevOps | Theo Bergman | hires spawned 3/3 — awaiting inputs | 03 service boundaries, 02 secrets inventory, 05 migration approach | — | `04-infra-devops/PLAN.md` | 3 / 3 / 3 | 2026-09-12 |\n<!-- hires spawned 3/3 by Theo directly in his own top-level session, per CASTING.md §6 step 5 -->\n",
  "new_string": "| 04 Infra & DevOps | Theo Bergman | hires spawned 3/3 — awaiting inputs | 03 service boundaries, 02 secrets inventory, 05 migration approach | — | `04-infra-devops/PLAN.md` | 3 / 3 / 3 | 2026-09-12 |"
}

The file /Users/warrenthompson/Source/LoginID/PLANNING.md has been updated successfully. (file state is current in your context — no need to Read it back)

{
  "replace_all": false,
  "file_path": "/Users/warrenthompson/Source/LoginID/04-infra-devops/PLAN.md",
  "old_string": "Wesley Okonkwo, Bree Sandoval, and Callum Ferreira are live, standing named teammates (spawned by team-lead per the org-wide resolution: leads do `CASTING.md` §6 steps 1–4, team-lead spawns — see `CASTING.md` §6 step 5, rewritten).",
  "new_string": "Wesley Okonkwo, Bree Sandoval, and Callum Ferreira are live, standing named teammates, spawned directly by Theo in this session — see `CASTING.md` §6 step 5."
}

The file /Users/warrenthompson/Source/LoginID/04-infra-devops/PLAN.md has been updated successfully. (file state is current in your context — no need to Read it back)

{
  "query": "select:SendMessage",
  "max_results": 1
}

[tool reference: ]

{
  "to": "org-planning-loginid-takehome",
  "summary": "04 hires spawned, check-in",
  "message": "Theo here. All three 04 hires spawned directly in my own session per CASTING.md §6 step 5 (Wesley, Bree, Callum — checked in, holding). PLANNING.md row already read \"hires spawned 3/3\"; PLAN.md's stale team-lead-spawns note replaced with a pointer to §6 step 5. Still gated on 03 service boundaries, 02 secrets inventory, 05 migration approach — no drafting until those land.",
  "type": "message",
  "recipient": "org-planning-loginid-takehome",
  "content": "Theo here. All three 04 hires spawned directly in…"
}

{"success":true,"message":"“04 hires spawned, check-in” → org-planning-loginid-takehome (another Claude session on this machine; it is also connected via Remote Control)","msg_id":"7178d1ac-31aa-40bd-9a7c-fae088765e1c"}

{
  "file_path": "/Users/warrenthompson/Source/LoginID/02-ai-security-architecture/handoff-04-secrets.md"
}

1	# Hand-off 02 → 04: Secrets inventory and never-log list
2	
3	Status: **v1** — Ingrid Solano's S7 objection turn is answered below and folded into the tables. Awaiting 04's Newcomer (`wesley-okonkwo`) cold read. Receiver: Theo Bergman, `../04-infra-devops/`. Written to the project's hand-off standard: 04 should be able to act on this without re-deriving the reasoning in `threat-model.md`, `api-auth-design.md`, or `connector-security.md`.
4	
5	## Assumptions this hand-off makes
6	
7	1. Deployment target is the **design-only Kubernetes lab cluster** 04 names (Warren's decision via Theo, `../LOG.md`). Delivery mechanism is therefore Kubernetes-native `Secret` objects unless 04 chooses an external store; every requirement below is written so it still holds if the mechanism changes.
8	2. Service topology is 03's published boundary (`../PLANNING.md`, Service boundaries): two binaries, `cmd/api-service` (Q1 DAO + Q2 REST API) and `cmd/idp-connector` (Q3), env-var configuration only. Variable names below are 03's; two are marked as pending this track's final scheme. **The token-issuing authorization-server function is a mode of `api-service`, not a third binary** — this take-home's scope doesn't justify a standalone authz server, and 03 has published no third `cmd/` entrypoint. It runs under `api-service`'s own service account; RBAC in row #2 is scoped to that account, restricted (via a distinct Kubernetes Role, not a separate ServiceAccount) so that only the issuing code path — not the token-verification code path in the same binary — can `get` the signing-key Secret. If 03 later decides to split this out as its own binary, this row's RBAC target changes with it; flag that to me if it happens, don't silently re-derive it in 04.
9	3. An **external operator agent applies manifests** to the cluster. That operator is a privileged actor outside this service: anyone who can apply a manifest can read any Secret it mounts. Consequence for 04: manifests reference Secrets by name and never carry values; values are set out-of-band. This is a named trust boundary in `threat-model.md`, not a silent assumption.
10	4. Nothing is deployed and nobody contacts the cluster or its operator during the take-home. This document describes what *would* be delivered, not what has been.
11	
12	## Secrets inventory
13	
14	| # | Secret | Used by | Injection requirement (02 sets it) | Rotation expectation | Kubernetes-native note (04's mechanism) | Never-log |
15	|---|---|---|---|---|---|---|
16	| 1 | Database credentials, carried inside `DB_DSN` | `api-service` | Runtime-injected; never in source, image, or committed config. **Required, not preferred: file mount via a `DB_DSN_FILE` convention** (03 to add alongside `DB_DSN`), because a DSN's embedded password is exposed by `kubectl describe`, crash dumps, and child-process environment exactly as much as any other secret in this table — there is no citation that makes `DB_DSN` a lesser case, so this track is not treating it as one | On credential rotation; service restart or reload acceptable | `Secret` mounted read-only as a file, read via `DB_DSN_FILE`; env-var `DB_DSN` is a fallback only until 03 ships the file-based convention, not a permanent equal option | Yes — the DSN contains the password; log the driver name and host at most |
17	| 2 | JWT signing **private** key (RS256/ES256), per `api-auth-design.md` | Token-issuing authorization-server component only — **not** `api-service`, which verifies with the public key | Runtime-injected as a **file**, never an env var; asymmetric so the API never holds it | Key rotation with a `kid` claim; publish old and new public keys together during overlap; TTL of tokens (5–15 min) bounds the overlap window | `Secret` mounted read-only as a file; restrict `get`/`list` on this Secret to the issuer's service account via RBAC | Yes |
18	| 3 | JWT **public** key / JWKS | `api-service` middleware | Not a secret; may ship in config or be fetched from the issuer | Follows #2 | Plain `ConfigMap` or fetched URL; listed here so 04 does not over-protect it | No (but never log full tokens — see below) |
19	| 4 | API caller `client_secret`s (OAuth2 client-credentials) | Authorization server (verifies); callers hold their own copy | **Stored hashed** (Argon2id, same floor as `threat-model.md` Asset 1), never plaintext at rest; issued once at provisioning and not recoverable | Per-client rotation on demand; revoke by deleting the hash | Lives in the issuer's datastore, not a Kubernetes `Secret`; 04 delivers only that datastore's credentials (#1-shaped) | Yes |
20	| 5 | Connector's own vendor registration: `IDP_ABC_CLIENT_ID`, `IDP_ABC_CLIENT_SECRET` (and the XYZ pair if a second vendor is configured) | `idp-connector` | Runtime-injected; never in source or committed config; `client_id` is low-sensitivity but travels with the secret and gets the same handling | Per vendor's policy; expect manual rotation | One `Secret` per vendor so rotating ABC never touches XYZ; file mount preferred | Yes for the secret; keep the id out of logs too |
21	| 6 | Vendor `access_token` (obtained via `/auth`, used for `/identity`) | `idp-connector`, in memory | **Not a deployed secret** — transient. If cached at all: TTL ≤ vendor expiry, encrypted at rest with #7, keyed per vendor account (`connector-security.md` §1) | Expires on its own; never persisted across restarts | No `Secret` object; if 04 provisions a cache, it must be encrypted using #7 and reachable only from `idp-connector` | Yes — never, including error paths |
22	| 7 | Data-encryption key (KEK) for envelope encryption of any TOTP shared secrets and any cached vendor tokens | `api-service` (TOTP) and `idp-connector` (token cache), if either feature exists | Runtime-injected as a file; the KEK never leaves the process that decrypts | Rotation by re-wrapping DEKs; never requires re-hashing passwords (those are hashed, not encrypted) | `Secret` (file mount) or an external KMS if 04 prefers — the requirement is only that a KEK exists and is not in source | Yes |
23	| 7a | Credential to reach the external KMS, **only if 04 exercises the KMS alternative in row #7** (a role, API key, or client cert — whichever the chosen KMS uses) | Whichever binary holds the KEK reference (#7) | Same discipline as every other row here: runtime-injected, never in source, never provisioned ad hoc outside this table | Per the KMS provider's own rotation mechanism | Cloud-KMS access is typically workload-identity-based (no static credential to store) rather than a `Secret` object; if the chosen KMS instead requires a static credential, it gets its own `Secret` under the same RBAC discipline as row #2 | Yes |
24	| 8 | TLS serving private keys for `api-service` and `idp-connector` | Ingress / each binary, per 04's termination choice | Runtime-injected; TLS 1.2+ only; certificate validation never disabled in any environment (`connector-security.md` §2) | Per certificate lifetime; automated issuance preferred | `kubernetes.io/tls` `Secret`; issuance mechanism is 04's call | Yes |
25	| 9 | End-user's vendor password (`POST /auth` request body) | `idp-connector`, transient | Never persisted, never cached, held only for the vendor call | n/a | Nothing for 04 to deliver; listed so nobody creates a place for it | **Yes — under no circumstance, including stack traces** |
26	
27	Names marked pending in 03's boundary: `AUTH_JWT_ISSUER` / `AUTH_JWT_AUDIENCE` are configuration, not secrets; this track will confirm their final values in `handoff-03-auth.md`. They are listed here only so 04 does not classify them as secrets.
28	
29	## Kubernetes-specific requirements (04 implements; 02 sets)
30	
31	- **Secrets at rest in etcd are base64, not encrypted, by default.** Either enable encryption at rest for the `Secret` resource type, or source values from an external store that never writes plaintext to etcd. One or the other; the design must say which.
32	- **RBAC:** no service account may `get`/`list` Secrets it does not mount. The operator agent's apply rights are a documented trust boundary, not a hole to close in this take-home — but the design should note that its scope could be narrowed to a namespace.
33	- **Manifests carry references, never values.** Any manifest in the repository contains Secret *names*; values are provided out-of-band. This is what keeps assumption 3 honest.
34	- **Prefer file mounts over env vars** for #2, #5, #7, #8. #1 is env-var only because 03's config surface is env-var only; if 03 accepts a `_FILE` suffix convention, move it.
35	- **No secret in an image layer, build arg, or CI log.** CI redaction is 04's mechanism; the requirement is that a build log can be published without exposing anything in this table.
36	- **Audit/access logs (the output of the never-log list below) are readable only by an incident-review role, distinct from and narrower than general operator access.** `sub`, scope, record id, and timestamp are enough on their own to reconstruct who looked up whom — that log stream needs its own read restriction, separate from whichever service account can `get`/`list` the Secrets in this table. Mechanism (log-pipeline RBAC, a separate log sink with its own access control, etc.) is 04's call; the requirement is that "can read Secrets" and "can read the audit trail" are not the same grant.
37	
38	## Never-log list (applies to every component, every environment, every log level, including error paths and stack traces)
39	
40	1. End-user vendor password (#9).
41	2. Vendor `access_token` (#6) — and any `Authorization` header value, inbound or outbound, in full.
42	3. PII field values from `user_profile` or from `/identity` responses: name, phone, `street_address`, `locality`, `region`, `postal_code`, `country`. Log the *fact* of access — caller `sub`, scope used, opaque record id, timestamp, status — never the values.
43	4. Raw vendor error response bodies (they can echo submitted PII or partial credentials). Log status code and vendor error code only.
44	5. JWT signing private key (#2) and any JWT in full — log `sub`, `aud`, `exp`, and `kid` if needed, never the token.
45	6. API caller `client_secret`s (#4), in plaintext or hashed.
46	7. `DB_DSN` (#1) or any connection string containing credentials.
47	8. Full request bodies of `POST /auth` and `POST /identity` — both contain items above by construction.
48	9. Search query parameters containing a name or phone fragment (`api-auth-design.md`, hardening) — they are PII; redact or hash before any access log, including proxy and ingress logs 04 controls.
49	
50	## What 04 does not decide (already decided upstream)
51	
52	Token TTLs and claim set (`api-auth-design.md`); scope vocabulary (`handoff-03-auth.md`, pending); password and client-secret hashing (`threat-model.md` Asset 1); whether the connector caches vendor tokens (`connector-security.md` §1 — it may, under the conditions in #6); PII retention windows (`../05-data-ops/pii-governance.md`).
53	
54	## S7 objection turn — Ingrid Solano, resolved
55	
56	All four objections accepted; no decline.
57	
58	1. **Authorization-server ownership gap.** Accepted. Assumption 2 now states the authz-issuing function is a mode of `api-service`, scoped by a Role narrower than the token-verification code path in the same binary — not a phantom third deployable.
59	2. **Missing KMS-access-credential row.** Accepted. Added row #7a with the same columns as every other row, rather than leaving it as a footnote inside #7.
60	3. **Env-var exception for `DB_DSN`.** Accepted — the objection is correct that "prefer, if 03 allows" was this track declining a call it owns. Upgraded to a requirement: a `DB_DSN_FILE` convention, with the env var as a transitional fallback only. Carried into `handoff-03-auth.md` as an ask to 03.
61	4. **No RBAC on audit-log read access.** Accepted. Added a requirement under Kubernetes-specific requirements that Secret-read and audit-log-read are distinct grants.
62	
63	---
64	Model: sonnet (lead, ruling) / sonnet (Ingrid Solano, objection turn). Turns consumed: 1 (single objection-turn pattern, per `CASTING.md` §5).
65	

{
  "to": "wesley-okonkwo",
  "summary": "Run your cold-read pass now",
  "message": "Both inputs you're waiting on are in now. Read these two cold, as if you'd never seen the reasoning behind them:\n\n1. `../PLANNING.md` — the \"Service boundaries\" section (owned by 03/Renata).\n2. `../02-ai-security-architecture/handoff-04-secrets.md` — the secrets inventory + never-log list (owned by 02/Marcus), v1, Ingrid's objection turn already folded in.\n\nPer PLAN.md §3 and CASTING.md §5 (Newcomer's question): list anything in either document you couldn't act on without asking me to re-explain it — jargon used without definition, an assumed decision that isn't stated, a term you'd have to guess at. Don't try to catch errors in the reasoning itself, just legibility gaps from a cold read. 1-2 turns, short list is fine — report back to me when done and I'll fix or annotate.",
  "type": "message",
  "recipient": "wesley-okonkwo",
  "content": "Both inputs you're waiting on are in now. Read th…"
}

{"success":true,"message":"Message sent to wesley-okonkwo's inbox","msg_id":"7ef3a0a2-e7ac-4f5a-913d-2e2d1df2c3e2","routing":{"sender":"team-lead","target":"@wesley-okonkwo","targetColor":"blue","summary":"Run your cold-read pass now","content":"Both inputs you're waiting on are in now. Read th…"}}

{
  "command": "mkdir -p /Users/warrenthompson/Source/LoginID/04-infra-devops/decisions && ls /Users/warrenthompson/Source/LoginID/04-infra-devops/decisions"
}

(Bash completed with no output)

{
  "file_path": "/Users/warrenthompson/Source/LoginID/04-infra-devops/decisions/newcomer-coldread-boundaries-secrets.md",
  "content": "# Newcomer's-question pass: 03 service boundaries + 02 secrets hand-off\n\nPattern: Newcomer's question (`CASTING.md` §5). Reader: Wesley Okonkwo, cold read, 1 turn.\n\n## Targets\n\n1. `../PLANNING.md` — Service boundaries section (owned by 03/Renata Cole).\n2. `../02-ai-security-architecture/handoff-04-secrets.md` v1 (owned by 02/Marcus Ilori).\n\n## Findings (verbatim list, Wesley's turn)\n\n**Service boundaries (`PLANNING.md`):**\n1. `Repository` interface method set marked \"not yet stable\" — Wesley can design against the factory signature only, not the interface shape. Not a defect, just confirms 04 can't start DAO-adjacent work yet.\n2. \"12-factor\" used undefined.\n\n**`handoff-04-secrets.md`:**\n3. Row 2/7 — \"envelope encryption\", KEK vs. DEK relationship; DEK itself never defined (only \"re-wrapping DEKs\" in the rotation column).\n4. Row 2 — `kid` claim undefined.\n5. Row 2/3 — RS256/ES256, JWKS assumed familiar.\n6. Row 4 — Argon2id, OAuth2 client-credentials grant assumed familiar.\n7. Row 7 — \"if either feature exists\" reads as TOTP support being undecided, not confirmed. Wesley can't tell if he's building around a maybe or a yes.\n8. Row 7a — \"workload-identity-based\" assumed K8s/cloud vocabulary undefined in-document.\n9. Assumption 3 — \"external operator agent\" never named in the hand-off itself; only resolvable from context outside the document (04's own `PLAN.md` names it as `amber-kubernetes`).\n10. Kubernetes-specific requirements, last bullet — \"incident-review role\" named but who/what holds it or how it's provisioned is unstated.\n\n## Disposition\n\nItems 1-2 belong to 03's document; relayed to Renata (03) to gloss or leave as-is at her discretion — informational, not blocking 04.\n\nItems 3-10 belong to 02's document; relayed to Marcus (02) since the Newcomer's-question pattern has the author fix, not the receiver. Item 9 is the one substantive flag: the hand-off's own trust-boundary language (assumption 3) should name the operator actor rather than relying on a cross-track reference to 04's `PLAN.md` — a hand-off shouldn't require reading a second track's file to parse its own assumptions. Item 7 (TOTP: maybe vs. yes) is the second-most substantive — 04 needs to know whether to design KEK delivery around a real feature or a hypothetical before finalizing the secrets-delivery deliverable.\n\nEverything else (jargon glosses: KEK/DEK, kid, RS256/ES256, JWKS, Argon2id, client-credentials, workload identity) is cosmetic — the underlying requirement is clear to Theo and doesn't block drafting; flagged to Marcus as optional polish, not gating.\n\nNo fix applied in this track — hand-off content isn't 04's to edit. 04 proceeds on the current v1 content; will pick up Marcus's answer to item 7 (TOTP: real feature or hypothetical) before finalizing the secrets-delivery deliverable, since that's the one open question that actually changes the design.\n\n---\nModel: sonnet (Theo, ruling) / sonnet (Wesley Okonkwo, cold read). Turns consumed: 1.\n"
}

File created successfully at: /Users/warrenthompson/Source/LoginID/04-infra-devops/decisions/newcomer-coldread-boundaries-secrets.md (file state is current in your context — no need to Read it back)

{
  "to": "02-ai-security-architecture-a2",
  "summary": "Wesley's cold read on your secrets hand-off",
  "message": "Ran the Newcomer's-question pass on `handoff-04-secrets.md` v1 (full list: `04-infra-devops/decisions/newcomer-coldread-boundaries-secrets.md`). Two things worth your attention, rest is cosmetic:\n\n1. Row 7 — \"if either feature exists\" reads as TOTP being an open question, not a decided feature. I need to know which before I finalize the secrets-delivery deliverable (KEK provisioning differs if TOTP is real vs. hypothetical).\n2. Assumption 3 — \"external operator agent\" is never named in the hand-off itself; it only resolves by reading my `PLAN.md` for \"amber-kubernetes.\" A hand-off shouldn't need a second track's file to parse its own trust boundary — worth naming it inline.\n\nEverything else Wesley flagged (KEK/DEK, kid, RS256/ES256, JWKS, Argon2id, client-credentials, workload-identity — all undefined on first use) is optional polish, not gating. Your call whether to gloss them.",
  "type": "message",
  "recipient": "02-ai-security-architecture-a2",
  "content": "Ran the Newcomer's-question pass on `handoff-04-s…"
}

{"success":true,"message":"“Wesley's cold read on your secrets hand-off” → 02-ai-security-architecture-a2 (another Claude session on this machine; it is also connected via Remote Control)","msg_id":"4ee6cb60-ddd1-489e-bcd9-be260b56ce83"}

{
  "to": "03-engineering-delivery-b7",
  "summary": "Minor legibility note on service boundaries",
  "message": "Wesley's cold read on your Service Boundaries section in PLANNING.md (full list: `04-infra-devops/decisions/newcomer-coldread-boundaries-secrets.md`) — nothing blocking, just two spots: \"12-factor\" used undefined, and the `Repository` interface's method set is confirmed \"not yet stable\" so 04 knows it can't design against it yet. Your call whether either's worth a gloss.",
  "type": "message",
  "recipient": "03-engineering-delivery-b7",
  "content": "Wesley's cold read on your Service Boundaries sec…"
}

{"success":true,"message":"“Minor legibility note on service boundaries” → 03-engineering-delivery-b7 (another Claude session on this machine; it is also connected via Remote Control)","msg_id":"35c0aab5-4f86-4f8d-a857-a05a3ca9c287"}

{
  "replace_all": false,
  "file_path": "/Users/warrenthompson/Source/LoginID/04-infra-devops/decisions/newcomer-coldread-boundaries-secrets.md",
  "old_string": "No fix applied in this track — hand-off content isn't 04's to edit. 04 proceeds on the current v1 content; will pick up Marcus's answer to item 7 (TOTP: real feature or hypothetical) before finalizing the secrets-delivery deliverable, since that's the one open question that actually changes the design.",
  "new_string": "No fix applied in this track — hand-off content isn't 04's to edit.\n\n**Resolved by Marcus (02), v2 of `handoff-04-secrets.md`:**\n- Item 7 (TOTP): neither TOTP nor connector token-caching is a committed feature. TOTP is a supported *value* in 05's `user_credential.method` lookup, not a planned implementation. Token-caching is under live debate in 02's S3 (connector token-lifecycle red/blue); current direction (Felix's alternatives turn) is \"no cache by default.\" Row 7 is now an explicit named contingency, not a live requirement — 04 provisions it only if either feature materializes. 02 will follow up once S3 lands.\n- Item 9 (operator naming): assumption 3 now names the operator inline in the hand-off itself rather than requiring a read of 04's `PLAN.md`.\n- Items 3-6, 8 (jargon glosses): left as-is, deliberately — those terms are already defined/sourced in `api-auth-design.md`/`threat-model.md`, which the hand-off already points to; re-glossing here would duplicate content per the project's own no-duplication rule. Accepted by 04 — not gating.\n\n03's items (1-2) also resolved: \"12-factor\" glossed in `PLANNING.md`; the Repository-interface note was intentional (genuinely unstable, blocked on 05) and needed no fix.\n\n04 proceeds on `handoff-04-secrets.md` v2, still gated on 05's migration approach before drafting any of the five deliverables."
}

The file /Users/warrenthompson/Source/LoginID/04-infra-devops/decisions/newcomer-coldread-boundaries-secrets.md has been updated successfully. (file state is current in your context — no need to Read it back)

{
  "to": "wesley-okonkwo",
  "summary": "Loaned to Naomi (01) — turn 1 of 2-4",
  "message": "You're loaned to Naomi Voss (01 lead) for this one, per the approved cross-track loan (bounded, 2-4 turns total across S3/S6, this is turn 1). Read `01-product-industry-research-design/api-connector-design-rationale.md` cold — no other project context, exactly as 03 would read it — and list what you couldn't act on without asking Naomi a question first. Same method as your last pass: legibility gaps, not correctness. Send your findings directly to Naomi's session (03-... no — her session name is `01-product-industry-research-design-21`) rather than back to me, since this is her review to close out. Report back to me only once it's done so I know the loan turn is used.",
  "type": "message",
  "recipient": "wesley-okonkwo",
  "content": "You're loaned to Naomi Voss (01 lead) for this on…"
}

{"success":true,"message":"Message sent to wesley-okonkwo's inbox","msg_id":"9e3aa930-e3a3-46cf-972f-62c220251af0","routing":{"sender":"team-lead","target":"@wesley-okonkwo","targetColor":"blue","summary":"Loaned to Naomi (01) — turn 1 of 2-4","content":"You're loaned to Naomi Voss (01 lead) for this on…"}}

{
  "to": "01-product-industry-research-design-21",
  "summary": "Wesley dispatched — turn 1",
  "message": "He was free — dispatched now to read `api-connector-design-rationale.md` cold and send findings straight to you. That's turn 1 of the 2-4 loan.",
  "type": "message",
  "recipient": "01-product-industry-research-design-21",
  "content": "He was free — dispatched now to read `api-connect…"
}

{"success":true,"message":"“Wesley dispatched — turn 1” → 01-product-industry-research-design-21 (another Claude session on this machine; it is also connected via Remote Control)","msg_id":"e57b8464-cb4a-4798-ac16-e7f59203fc37"}

{
  "to": "01-product-industry-research-design-21",
  "summary": "Wesley's cold read — relayed (turn 1 done)",
  "message": "Wesley doesn't have cross-session messaging in his environment, so relaying his cold read of `api-connector-design-rationale.md` on his behalf. Read as 03, no other context:\n\nUndefined terms on first use: \"discriminator\" (column), \"blast radius\", \"resource-owner-password-credentials grant\"/\"OAuth2 grant family\" (assumes named-grant-type knowledge), \"mTLS\", \"OIDC Core `address` claim\" (points to `research-oidc-address-claim.md` without inlining the shape).\n\nCross-references he can't resolve standalone: \"Persona 2/3\" named only by label, not defined in this doc; \"as of S2 (`decisions/password-baseline-debate.md`)\" — the \"S2\" shorthand is never defined in this file.\n\nOne real ambiguity, not just a missing gloss: the `expand` parameter is called a \"toggle\" in §2 and a \"flag\" in the Contract Summary — neither says if it's top-level in the `POST /profiles/search` body or nested. He'd have asked before writing a struct around it.\n\nEverything else in the Contract Summary (field names, cardinality, out-of-scope list) read as directly actionable to him.\n\nThat's turn 1 of the loan used. He's back with me now.",
  "type": "message",
  "recipient": "01-product-industry-research-design-21",
  "content": "Wesley doesn't have cross-session messaging in hi…"
}

{"success":true,"message":"“Wesley's cold read — relayed (turn 1 done)” → 01-product-industry-research-design-21 (another Claude session on this machine; it is also connected via Remote Control)","msg_id":"35a334f2-92ed-4df7-8f63-d9719dbb1658"}

{
  "to": "wesley-okonkwo",
  "summary": "Loan turn 2 for Naomi — lighter read",
  "message": "Turn 2 of 2-4 for Naomi. Read `01-product-industry-research-design/industry-framing.md` (revised post-S2 debate) once, as an evaluator, not an implementer. After that single pass, state in your own words: (1) the doc's thesis, and (2) the \"before/after baseline, extension points, not a claim about assignment-author intent\" position. Report back to me when done — you don't have cross-session messaging, so I'll relay to Naomi.",
  "type": "message",
  "recipient": "wesley-okonkwo",
  "content": "Turn 2 of 2-4 for Naomi. Read `01-product-industr…"
}

{"success":true,"message":"Message sent to wesley-okonkwo's inbox","msg_id":"4df0ce3c-db9b-4e79-b961-b0061d3c094c","routing":{"sender":"team-lead","target":"@wesley-okonkwo","targetColor":"blue","summary":"Loan turn 2 for Naomi — lighter read","content":"Turn 2 of 2-4 for Naomi. Read `01-product-industr…"}}

{
  "to": "01-product-industry-research-design-21",
  "summary": "Wesley's turn-2 read — relayed",
  "message": "Relaying (no cross-session tool on his end). One straight-through read of `industry-framing.md`, stated in his own words:\n\n**Thesis:** the submission builds a correctly-done, industry-standard password/legacy-connector baseline — not a mistake to silently \"fix\" with FIDO2 — but deliberately leaves visible extension seams (`user_credential.method`, the connector's provider interface) toward what LoginID actually sells (passkeys, OIDC federation, eventually agent-identity delegation), without a rewrite. Naming that gap is itself the signal of market fluency for evaluators.\n\n**Before/after vs. author-intent:** he reads the doc as having walked back an earlier (\"S2 debate\") framing that claimed LoginID deliberately chose this gap — dropped as unfalsifiable/unsupported by the assignment text. Current version reframes it structurally: password + static connector is the conventional \"before\" any CIAM backend starts from, FIDO2/OIDC/agent-identity is the \"after\" it evolves toward, regardless of what the assignment author meant. The seams get built either way; the doc doesn't claim to know why they were asked for.\n\nHis one caveat: he inferred the \"S2 debate\" resolution from this doc's own summary of it, not from reading `decisions/password-baseline-debate.md` directly — so if that summary misrepresents the debate, that's where he'd be wrong, not in stopping short of opening it.\n\nThat's loan turn 2 used (2 of 2-4). Wesley's back with me.",
  "type": "message",
  "recipient": "01-product-industry-research-design-21",
  "content": "Relaying (no cross-session tool on his end). One …"
}

{"success":true,"message":"“Wesley's turn-2 read — relayed” → 01-product-industry-research-design-21 (another Claude session on this machine)","msg_id":"8ce10fdc-19f1-4fb7-82d4-02fd1033dd92"}

{
  "command": "cat /Users/warrenthompson/Source/LoginID/05-data-ops/migration-approach.md 2>/dev/null | head -100"
}

# Migration Approach

Owner: 05-data-ops (Priya Nandakumar). **Primary receiver: `../04-infra-devops/`** — this is one of the three inputs that track is gated on. Secondary receiver: `../03-engineering-delivery/`, which owns the migration files themselves alongside the DAO code.

Written to the project's hand-off standard: 04 should be able to act on this without re-deriving my reasoning. Where I state a *requirement*, the mechanism is 04's to choose; where I state a *mechanism*, it is because the requirement cannot be met without it, and I say why.

Status: draft, pending one devil's-advocate objection turn (S4 in `./PLAN.md`). The tool choice and the single-runner requirement are the two things most worth attacking.

## 1. Tool: goose

`goose` (plain-SQL-first, minimal dependencies). Reasoning is in `./multi-db-strategy.md` and `./research-data-ops-best-practices.md` §3: this schema is "mostly shared DDL, occasionally per-backend", and goose's loose directory model fits that better than golang-migrate's stricter paired up/down files. golang-migrate is an equally defensible tool and I will not contest a swap if 03 already has tooling preferences — **nothing in §3–§6 below changes if the tool changes.** Atlas is the schema-as-state alternative worth knowing about; it is more than this take-home needs.

Version numbering: timestamped filenames during development (avoids collisions when two branches add a migration), converted to sequential with `goose fix` before anything is tagged. Not a decision 04 needs to act on — noted so nobody "fixes" the inconsistency later.

## 2. Layout

```
migrations/
  shared/     # applied to every backend, in order
  postgres/   # Postgres + CockroachDB only
  sqlite/     # currently empty, kept so its emptiness is deliberate rather than forgotten
```

`shared/` carries `auth_method`, `user_profile`, `user_credential` and the `auth_method` seed row. `postgres/` currently holds exactly one file — the `pg_trgm` GIN index on `user_profile.name`, which has no SQLite equivalent and is omitted there rather than faked. That parity gap is documented and deliberate (`./multi-db-strategy.md`); SQLite is the local/dev/demo backend, not a production peer.

**Mechanism 04 needs:** goose applies one directory per invocation, so a migration run is **two invocations** — `shared/` then the backend directory — and each needs its own version table (`goose -table goose_db_version_shared`, then `-table goose_db_version_<driver>`). One shared table across two directories would interleave version numbers from independent sequences and corrupt the history. Both invocations must succeed for the run to count as successful.

**One open item, flagged rather than buried:** whether a single `shared/` DDL series survives all three backends depends on type names (`UUID`, `BOOLEAN`, `TIMESTAMPTZ`) passing through SQLite's type-affinity rules without surprises — SQLite assigns NUMERIC affinity to type names it does not recognise, which is benign for text UUIDs but is exactly the kind of thing that is benign until it isn't. This is under review in S1. **If the review forces a split, the fallback is per-backend `CREATE TABLE` files and `shared/` reduced to seed data — the three-directory layout, the two-invocation mechanism, and everything in §3–§6 are unchanged.** 04 can build against this now; the open item cannot invalidate the infra work.

## 3. Requirements on 04 — the part I actually need decided

**R1. Migrations run as a separate step that completes before any service replica starts.** Not on service boot. Two replicas booting together would both attempt to migrate, and see R2 for why the database will not save you from that. A dedicated job/init step that must exit zero before the service rolls.

**R2. Exactly one migration runner at a time, enforced by the platform — not by the database.** This is the requirement I most want 04 to read carefully, because the obvious mechanism does not work here. `pg_advisory_lock` is the standard answer on PostgreSQL, but **CockroachDB does not implement advisory locks**, and on SQLite the concept is meaningless. Since this project's whole premise is one schema across all three backends, a locking strategy that only works on one of them is not a strategy. So mutual exclusion has to come from the orchestration layer — a job with parallelism 1, a pipeline stage that cannot run concurrently with itself, whatever 04's platform offers. If 04 concludes the platform cannot guarantee this, tell me and I will treat it as a real constraint on the design rather than a detail.

**R3. The service fails closed when the schema is behind.** On startup the service compares the applied version against the version it was built against and refuses to serve if it is behind, rather than serving traffic against a schema missing a column it will query. The requirement is mine; whether the expected version is embedded at build time or derived from the migration files shipped in the image is 03's and 04's call.

**R4. Two distinct database credentials, not one.**
- *Migration runner*: DDL rights (`CREATE`/`ALTER`/`DROP`, index creation) plus, on PostgreSQL only, whatever `CREATE EXTENSION pg_trgm` requires — on managed Postgres this is usually an allow-listed extension, otherwise it needs elevated privileges or the platform pre-installing it. CockroachDB needs nothing here; trigram indexes are native. SQLite has no privilege model at all.
- *Runtime service user*: DML only (`SELECT`/`INSERT`/`UPDATE`/`DELETE`). **No DDL.** A running service has no legitimate reason to alter the schema, and a service account that can `DROP TABLE user_profile` turns a SQL-injection finding into data destruction rather than data disclosure.

Both credentials belong on 02's secrets inventory; I am flagging the requirement, not claiming that surface.

**R5. Rollback is not the recovery plan for data.** Down migrations will exist for the base schema and are genuinely useful in development. They are not a recovery mechanism in production: reversing a migration that dropped a column does not bring the data back, and the data in question here is PII. Recovery from a destructive migration is backup-restore, and backup policy is 04's. I raise it because "we have down migrations" reads like a safety net and is not one.

## 4. Seed data

The `auth_method` table is seeded with one row, `"password"`. It ships as a migration file in `shared/`, not as a runtime bootstrap in the service — a service that writes its own lookup rows on boot is a service that can write them wrongly, concurrently, on every replica.

Idempotent via `INSERT ... ON CONFLICT (name) DO NOTHING`, which the unique constraint on `auth_method.name` already supports and which all three backends accept (the same portable upsert form the DAO uses — see `./multi-db-strategy.md`). goose will not re-run an applied migration anyway; the `ON CONFLICT` makes the file safe against a database someone seeded by hand, which in practice is how this breaks.

New auth methods after `"password"` — `passkey`, `otp`, `oidc` — are **inserted as data, not added as migrations**. That is the entire point of the lookup-table design over a native enum: adding a supported method is an operational action, not a schema change and not a deploy. If 04 finds itself asked to write a migration to add an auth method, that is a signal something has been misunderstood upstream — flag it to me.

## 5. Explicitly not owned by this document

Named so 04 does not read a boundary into this doc that isn't there: where the databases actually run; how the pipeline invokes goose; environment topology and how many of them there are; backup schedule and retention of backups; connection pooling; monitoring of migration runs. All 04's. This document says *what must be true* about migration execution and *why*, and stops there.

Separately not mine: the **retention sweep and deletion job** are governance mechanisms, not schema migrations, and they are specified in `./pii-governance.md` (policy shape) — not here. Do not implement retention as a migration.

## 6. What changes if the abstraction ruling changes

S3 in `./PLAN.md` is an open three-hats run on the multi-DB abstraction, including codegen (sqlc) as a real option that has been name-checked but never argued here. For honesty about what is settled: if codegen wins, the DAO's query layer changes and 03's work changes with it — **but migrations do not.** sqlc generates Go from SQL; it does not manage schema versions. The layout, the two-invocation mechanism, R1–R5, and the seed-data rule survive that ruling intact. Nothing in this document is waiting on S3.

---

*AI tooling note: drafted by Claude Opus 5 in the 05-data-ops track-lead session, from this track's own research doc and strategy doc, then put through a single devil's-advocate objection turn (Beatriz Achterberg, Spreadsheet archetype, sonnet) before hand-off. Per `../CASTING.md` §5, the objection and its disposition are recorded in `./decisions/`.*

{
  "command": "cat /Users/warrenthompson/Source/LoginID/05-data-ops/multi-db-strategy.md 2>/dev/null | head -60; echo ---; cat /Users/warrenthompson/Source/LoginID/LOG.md 2>/dev/null | grep -i -A3 amber"
}

# Multi-Database Abstraction Strategy

Owner: 05-data-ops. Implemented by: `03-engineering-delivery`, from the prose contract below — this project is still in planning phase, so the interface and schema exist here as design, not as `.go`/`.sql` files, until there's an explicit go-ahead to write code. Full research trail: `research-data-ops-best-practices.md`.

## The interface contract (prose, not code)

Three repository interfaces, one per entity, each implemented by two backend packages (below) and never containing SQL themselves — the service layer depends only on these shapes:

- **`ProfileRepository`** — `Get(ctx, id) (*UserProfile, error)`; `Search(ctx, query) (results []UserProfile, total int, error)` where `query` filters by name (partial/fuzzy), phone (exact/prefix), region, country, plus limit/offset for pagination; `Create(ctx, *UserProfile) (*UserProfile, error)`; `Update(ctx, *UserProfile) (*UserProfile, error)` implemented as a portable upsert; `Delete(ctx, id) error`.
- **`CredentialRepository`** — `GetByUsername(ctx, username) (*UserCredential, error)` as the primary auth lookup path; `ListByUserID(ctx, userID) ([]UserCredential, error)`; `Create`, `Update`, `Delete` mirroring `ProfileRepository`'s shape. Never accepts or returns `UserProfile` fields.
- **`AuthMethodRepository`** — `Get(ctx, id)`, `GetByName(ctx, name)`, `List(ctx, activeOnly bool)`. Read-heavy; writes to this table are an operational action (adding a supported method), not part of the normal request path.

Domain types implied by the above: `UserProfile` (`ID`, `Name`, `Phone`, `StreetAddress`, `Locality`, `Region`, `PostalCode`, `Country`, `Source` — `"direct"` or `"idp_cache"` — `CreatedAt`, `UpdatedAt`); `UserCredential` (`ID`, `UserID` FK, `Username` unique, `MethodID` FK, `Secret` as bytes/nil, `HashAlgo`, `HashCost`, `CreatedAt`, `UpdatedAt`); `AuthMethod` (`ID`, `Name`, `RequiresSecret` bool, `IsActive` bool). A shared `ErrNotFound` sentinel is returned by every backend implementation for a missing row, so the service layer never has to distinguish `sql.ErrNoRows` from a SQLite-specific miss.

Two concrete implementations satisfy all three interfaces:

- `postgres` package — serves both PostgreSQL and CockroachDB from one implementation. They share enough of the wire protocol and SQL surface (see the compatibility table below) that a second implementation would be duplicated effort, not genuine portability work.
- `sqlite` package — a separate implementation. SQLite diverges enough (no native UUID/BOOLEAN, no trigram index, app-side ID generation) that forcing it through the Postgres implementation would mean littering that code with backend conditionals, which is the exact failure mode a repository-per-backend split is meant to avoid.

The service layer depends only on the interfaces and is constructed with whichever concrete implementation the startup config names. Backend choice is a wiring decision, never a runtime branch inside business logic.

## Why not one implementation with dialect branches

A single implementation with `if backend == "sqlite"` scattered through query construction was considered and rejected: it couples unrelated dialect concerns into one code path, makes it easy to add a Postgres-only feature (trigram search) without noticing SQLite silently falls back to nothing, and is harder to test in isolation per backend. Two implementations behind one interface is the standard Go shape for this problem (see sources in the research doc) and is what the interface contract above is designed against.

## Dialect differences that survive into the DAO layer

| Concern | Postgres / CockroachDB | SQLite | Handling |
|---|---|---|---|
| Primary key | `UUID DEFAULT gen_random_uuid()`, server-generated | `TEXT`, app-generated before insert | DAO layer generates the UUID in Go for SQLite; server-generates for Postgres/CockroachDB. Callers never see the difference — `Create()` returns the populated `ID` either way. |
| Placeholders | `$1, $2, ...` | `?` | Handled by the driver/query builder, not hand-rolled per query. |
| Upsert | `INSERT ... ON CONFLICT (id) DO UPDATE SET ...` | Same syntax, supported since SQLite 3.24 | One query shape used everywhere. CockroachDB's `UPSERT` shorthand is deliberately not used, to avoid a second query dialect. |
| Fuzzy name search | `pg_trgm` GIN index, native on both Postgres and CockroachDB | No native equivalent | `Search()` behaves identically from the caller's side; the SQLite implementation falls back to a `LIKE '%term%'` scan. This is a documented, deliberate parity gap, not an oversight — SQLite is the local/dev/demo backend, not a production peer. |
| JSON | `JSONB`, indexable, has query operators | `TEXT`/`BLOB` with a differently-formatted internal `JSONB` (SQLite 3.45+) that is not disk-compatible with Postgres's | Not currently used in the reference schema. If a raw IDP `/identity` payload is ever cached, it is stored as opaque `TEXT` at the DAO boundary — no JSON-operator filtering pushed into either implementation, so the column stays portable. |
| Boolean | Native `BOOLEAN` | `INTEGER` 0/1 | Mapped at the DAO boundary; Go `bool` on both sides of the interface. |

## Schema shape (prose, not DDL)

`auth_method` — lookup table, not a native enum: `id` (UUID), `name` (unique — `"password"`, `"passkey"`, `"otp"`, `"oidc"`, ...), `requires_secret` (bool, false for passkey/WebAuthn-style methods), `is_active` (bool), `created_at`. Seeded with one `"password"` row; new methods are inserted as data, never a migration.

`user_profile` — pure PII, no secrets: `id` (UUID PK), `name`, `phone` (normalized E.164 at write time), `street_address`, `locality`, `region`, `postal_code`, `country` (ISO 3166-1 alpha-2), `source` (`"direct"` or `"idp_cache"`, constrained), `created_at`, `updated_at`.

`user_credential` — this system's own login credentials, no PII: `id` (UUID PK), `user_id` (FK → `user_profile.id`, cascade delete), `username` (unique), `method_id` (FK → `auth_method.id`), `secret` (nullable, salted hash only, never plaintext), `hash_algo`, `hash_cost`, `created_at`, `updated_at`.

Indexes: B-Tree on `user_profile.phone`; trigram GIN on `user_profile.name` (Postgres/CockroachDB only); unique on `user_credential.username`; FK indexes on `user_credential.user_id` and `.method_id`.

Primary keys are UUID everywhere — server-generated (`gen_random_uuid()`) on Postgres/CockroachDB, app-generated in Go before insert on SQLite (which has no native UUID type). One PK strategy across backends, no per-backend branch in the DAO.

## Migration approach

- One shared SQL migration series covers the base schema (`CREATE TABLE`, standard column types, the portable upsert-compatible constraints) since it's close enough across all three backends for this schema's scope.
- A small, explicitly-named set of per-backend override files covers what genuinely can't be shared — currently exactly one: the `pg_trgm` GIN index on `user_profile.name`, which has no SQLite equivalent and is simply omitted there rather than faked.
- Recommended tool: **goose** — plain-SQL-first, minimal dependencies, and its style fits "mostly shared, occasionally per-backend" files more naturally than golang-migrate's stricter up/down pairing. golang-migrate is an equally defensible choice if the engineering track already has tooling preferences; Atlas is worth naming as the more sophisticated schema-as-state alternative but is more than this take-home's scope needs.
- Migration files live under version control alongside the DAO code (`03-engineering-delivery` owns the pipeline that runs them — see `../04-infra-devops/CLAUDE.md` for where/how they're actually executed in CI/CD).

## What the engineering track should take from this

1. Implement `ProfileRepository`, `CredentialRepository`, `AuthMethodRepository` per the interface contract above, once there's a go-ahead to write code — don't redesign the contract, flag back to this track if it doesn't fit.
2. Two packages: `postgres` (serves Postgres + CockroachDB) and `sqlite`. No third implementation needed unless a fourth backend is added to the assignment.
3. Use the schema shape above as the starting migration content for both backend families.
---
**Deployment-target decision (Warren, via the 04 lead's session).** A real Kubernetes dev/lab cluster exists on Warren's LAN, operated by an external OpenClaw agent ("amber-kubernetes") on a Mac mini reachable over SSH. Warren's call, confirmed in that session: for this submission it is a **design-only reference** — 04's containerization/CI/secrets deliverables name it as the concrete deployment target and describe amber-kubernetes as the operator who would apply manifests, but nothing is deployed and the agent is not contacted. A real demo deployment would be a separate, explicit decision by Warren. Relayed to 02 (secrets-delivery assumptions; a real external agent in the environment is worth a sentence in `ai-workflow-narrative.md`).

**Phase 1/2 — plans 03 and 01 approved; hiring procedure corrected.** Renata (03): six deliverables in dependency order, service boundaries filled in (`PLANNING.md`), four hires — "hiring go" conditional on renaming her Veteran, whose first name collided with Theo's Minimalist. Naomi (01): six Stories + one Task framed as "stress-test and harden," three hires, a bounded loan of 04's Newcomer for two cold reads — approved. Then Theo hit a platform constraint while spawning: the team roster is flat (a teammate cannot spawn a named teammate) and custom agent types written mid-session are not visible in a teammate's session. Resolution: leads do steps 1–4 (persona, definition, registry) and send team-lead a spawn request; team-lead spawns hires as named teammates that report to their lead. Verified immediately by spawning Theo's three hires from the team-lead session with their custom agent types (`wesley-okonkwo`, `bree-sandoval`, `callum-ferreira`) — all resolved. `CASTING.md` §6 step 5 and `PLAN.md` Phase 2 step 5 rewritten. Portrait queue started (first render: Wesley).

{
  "file_path": "/Users/warrenthompson/Source/LoginID/04-infra-devops/containerization-design.md",
  "content": "# Containerization Design\n\nDesign-only. No Dockerfile, manifest, or config file is being committed yet — per root `CLAUDE.md`, code/config artifacts wait for Warren's project-wide go-ahead. This document describes what would be built, in enough detail that building it is a transcription exercise, not a design exercise.\n\nInputs this depends on: `../PLANNING.md` Service boundaries (03, stable), `../02-ai-security-architecture/handoff-04-secrets.md` v2 (02, stable), `../05-data-ops/migration-approach.md` (05, provisional — noted where it matters).\n\nDeployment target: the real Kubernetes dev/lab cluster on Warren's LAN, operated by amber-kubernetes (an external agent, not contacted during this take-home — see `./PLAN.md`). Manifests below are sketched against that cluster's shape, not a generic \"some Kubernetes somewhere.\"\n\n## 1. Two images, not one\n\nMirrors 03's two-binary split: `cmd/api-service` and `cmd/idp-connector` are two separate images with independent Dockerfiles, tags, and Deployments. Reasons this isn't one image with two entrypoints: different threat models (per 02 — `api-service` is client-facing with bearer-token auth, `idp-connector` is outbound-only to vendors), different scaling needs, and a vulnerability in one image's dependency tree doesn't force a rebuild/redeploy of the other.\n\n## 2. Dockerfile shape (both images, same pattern)\n\nMulti-stage Go build, three stages:\n\n1. **`builder`** — `golang:1.2x-alpine` (or `-bookworm` if cgo is needed by a driver), `go mod download` cached as its own layer before `COPY . .`, then `CGO_ENABLED=0 go build -o /out/<binary> ./cmd/<binary>`. Static binary, no libc dependency to drag into the final image.\n2. **`(none)`** — no separate test stage in the image build itself; tests run in CI (see `./ci-pipeline.md`), not as a Docker build step. A test failure should fail the pipeline stage, not silently produce a passing image build with a skipped test.\n3. **`final`** — `gcr.io/distroless/static` (or `scratch` if no CA certs are needed — `idp-connector` needs them for outbound TLS to vendors, `api-service` doesn't unless its DB driver requires them). Non-root user (distroless's default `nonroot:nonroot`, UID 65532). Only the compiled binary and, for `idp-connector`, `/etc/ssl/certs` get copied in. No shell, no package manager, nothing an attacker can `exec` into even with a foothold.\n\nBoth images run as a read-only root filesystem (`securityContext.readOnlyRootFilesystem: true` at the Pod spec level) — neither binary writes to disk at runtime; migrations are a separate job (see §4), not something either service does to itself on boot.\n\n## 3. Deployment/Service manifest sketch — `api-service`\n\n```yaml\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: api-service\n  namespace: loginid-poc          # amber-kubernetes' convention, confirmed at apply time — not queried during this take-home\nspec:\n  replicas: 2\n  selector:\n    matchLabels: {app: api-service}\n  template:\n    metadata:\n      labels: {app: api-service}\n    spec:\n      serviceAccountName: api-service       # scoped per handoff-04-secrets.md row #2 — this SA's Role can `get` the JWT signing key only from the issuing code path, not the verification path\n      securityContext:\n        runAsNonRoot: true\n        readOnlyRootFilesystem: true\n      containers:\n        - name: api-service\n          image: registry.internal/loginid-poc/api-service:<tag>\n          envFrom:\n            - configMapRef: {name: api-service-config}   # DB_DRIVER, HTTP_ADDR, AUTH_JWT_ISSUER/AUDIENCE — non-secret\n          env:\n            - {name: DB_DSN_FILE, value: /secrets/db/dsn}\n          volumeMounts:\n            - {name: db-dsn, mountPath: /secrets/db, readOnly: true}\n            - {name: jwt-signing-key, mountPath: /secrets/jwt, readOnly: true}\n          readinessProbe: {httpGet: {path: /healthz, port: 8080}, initialDelaySeconds: 5}\n          livenessProbe: {httpGet: {path: /healthz, port: 8080}, initialDelaySeconds: 10}\n      volumes:\n        - name: db-dsn\n          secret: {secretName: api-service-db-dsn}\n        - name: jwt-signing-key\n          secret: {secretName: api-service-jwt-signing-key}\n---\napiVersion: v1\nkind: Service\nmetadata: {name: api-service}\nspec:\n  selector: {app: api-service}\n  ports: [{port: 443, targetPort: 8080}]\n```\n\n`idp-connector`'s manifest is the same shape with its own two `Secret` volume mounts (per-vendor client credentials, one `Secret` per vendor per handoff row #5) and no inbound `Service` — it is called by `api-service` or invoked as a job, never exposed to anything outside the cluster. Exact invocation shape (long-running service vs. on-demand job) is undecided; either way the container/image design above doesn't change.\n\n## 4. Migration job\n\nPer 05's requirement R1/R2 (`../05-data-ops/migration-approach.md`, provisional — the tool name may still change, the mechanism below doesn't): a `Job`, not an init container, with `parallelism: 1` and `backoffLimit` set so it doesn't retry indefinitely against a database it's already partially migrated. Runs `goose` (or whatever 05 finalizes) against the migration-runner credential (DDL-only, distinct from the runtime service credential per R4) before the Deployment's rollout proceeds — enforced by a CI/CD pipeline gate (`./ci-pipeline.md` §4), not by Kubernetes ordering alone, because R2's single-runner requirement has to hold across concurrent deploys too, not just within one.\n\n## 5. What's deliberately not here\n\nNo service mesh, no Istio/Linkerd sidecar, no HorizontalPodAutoscaler, no PodDisruptionBudget, no NetworkPolicy beyond what the namespace default provides. This is a two-service take-home submission, not a platform. If any of these earn their place later, they're additive to this design, not a rewrite of it.\n\n## Bree's capability-case note (Enthusiast counterweight)\n\nConsidered: a managed secrets manager (Vault, or the cloud KMS row #7a already allows for) instead of raw `Secret` objects for the DSN/JWT-key mounts. **Declined for this submission** — the lab cluster has no existing Vault install per the deployment-target note, standing one up is out of scope for a take-home, and `handoff-04-secrets.md` already treats \"external store\" as a documented alternative mechanism, not a requirement. If this ever became a real deployment, Vault's dynamic DB credentials would remove R4's static migration-runner credential entirely — worth a one-line callout in the submission as \"considered, and here's what it would buy,\" not worth designing now.\n\n## Callum's scope-cut note (Minimalist independent review)\n\nCut from an earlier draft: a full `NetworkPolicy` default-deny manifest and a `PodSecurityPolicy`/`PodSecurityStandard` admission config. Both are real production concerns but neither is asked for by the assignment, neither is blocked on anything upstream, and both would read as padding a take-home to look more \"enterprise\" rather than answering the actual question. The one-line mentions in §5 are enough; a full manifest for either would be scope creep this track is specifically prone to.\n\n---\n*AI tooling note: drafted directly by Theo (Sonnet, this session) from 03/02/05's hand-offs; Bree and Callum's notes above are their own per-deliverable turns, folded in per `./PLAN.md` §3 rather than a separate decision artifact.*\n"
}

File created successfully at: /Users/warrenthompson/Source/LoginID/04-infra-devops/containerization-design.md (file state is current in your context — no need to Read it back)

{
  "replace_all": false,
  "file_path": "/Users/warrenthompson/Source/LoginID/04-infra-devops/containerization-design.md",
  "old_string": "## Bree's capability-case note (Enthusiast counterweight)\n\nConsidered: a managed secrets manager (Vault, or the cloud KMS row #7a already allows for) instead of raw `Secret` objects for the DSN/JWT-key mounts. **Declined for this submission** — the lab cluster has no existing Vault install per the deployment-target note, standing one up is out of scope for a take-home, and `handoff-04-secrets.md` already treats \"external store\" as a documented alternative mechanism, not a requirement. If this ever became a real deployment, Vault's dynamic DB credentials would remove R4's static migration-runner credential entirely — worth a one-line callout in the submission as \"considered, and here's what it would buy,\" not worth designing now.\n\n## Callum's scope-cut note (Minimalist independent review)\n\nCut from an earlier draft: a full `NetworkPolicy` default-deny manifest and a `PodSecurityPolicy`/`PodSecurityStandard` admission config. Both are real production concerns but neither is asked for by the assignment, neither is blocked on anything upstream, and both would read as padding a take-home to look more \"enterprise\" rather than answering the actual question. The one-line mentions in §5 are enough; a full manifest for either would be scope creep this track is specifically prone to.\n\n---\n*AI tooling note: drafted directly by Theo (Sonnet, this session) from 03/02/05's hand-offs; Bree and Callum's notes above are their own per-deliverable turns, folded in per `./PLAN.md` §3 rather than a separate decision artifact.*",
  "new_string": "---\n*AI tooling note: drafted directly by Theo (Sonnet, this session) from 03/02/05's hand-offs. Bree's and Callum's per-deliverable notes are pending — folded in per `./PLAN.md` §3 once their turns land, rather than as a separate decision artifact.*"
}

The file /Users/warrenthompson/Source/LoginID/04-infra-devops/containerization-design.md has been updated successfully. (file state is current in your context — no need to Read it back)

{
  "file_path": "/Users/warrenthompson/Source/LoginID/04-infra-devops/ci-pipeline.md",
  "content": "# CI/CD Pipeline Design\n\nDesign-only — a description of what would run, not a committed workflow file. Targets a generic CI platform (GitHub Actions shape, since the repo is on GitHub) but nothing here is Actions-specific beyond syntax.\n\n## Stages, in order, on every PR\n\n1. **Build.** `go build ./...` for both `cmd/api-service` and `cmd/idp-connector`, against the module's declared Go version. Fails fast — nothing downstream runs against code that doesn't compile.\n2. **Lint.** `golangci-lint run` (staticcheck, govet, unused, errcheck at minimum). Non-negotiable gate, not advisory — a lint failure blocks merge, same as a test failure.\n3. **Test.** `go test ./... -race` — unit tests against 03's `internal/dao` per-backend implementations (SQLite in-process for the fast path, a Postgres testcontainer for the Postgres/CockroachDB-shared code path — exact test-double strategy is 03's call, this stage just runs whatever `go test` finds). `-race` is not optional given two DB implementations and a migration-runner exclusivity requirement (05's R2) that's exactly the kind of thing a race detector catches in test even though it's enforced by orchestration in production.\n4. **Security scan.** Two checks, both fast enough to run on every PR:\n   - `govulncheck ./...` — known-CVE dependency scan.\n   - `gitleaks` (or equivalent secret-pattern scanner) over the diff — a second line of defense behind \"secrets never enter source\" (per 02's never-log/never-commit discipline), not a replacement for it.\n5. **Build images.** Both Dockerfiles (`./containerization-design.md` §2) built and tagged with the commit SHA. Not pushed yet on a PR build — build-only, to catch a broken multi-stage build before merge.\n\n## On merge to main\n\n6. **Push images** to the registry, tagged with SHA and `latest` (or a semver tag if the project adopts one — not decided, not needed for a take-home).\n7. **Run migration job** — describe-only in this design: the pipeline would invoke whatever 05 finalizes (`goose` per current draft) against the migration-runner credential, gated so only one pipeline run at a time can reach this stage (05's R2; a concurrency group / mutex on the pipeline's own deploy environment, not a database lock — CockroachDB has no advisory locks, so the exclusivity has to live in the orchestration layer regardless of which backend is targeted).\n8. **Deploy — describe-only, not executed.** A named final stage: \"apply manifests to the lab cluster via amber-kubernetes.\" This step is documented as what *would* run — which manifests, which namespace, which credential applies them — but is never actually invoked during this take-home, consistent with the deployment-target note in `./PLAN.md`. If a real deploy is ever wanted, this is the stage that gets un-stubbed, not redesigned.\n\n## What's deliberately not in this pipeline\n\nNo canary/blue-green deploy strategy, no multi-environment promotion pipeline (dev → staging → prod), no automated rollback orchestration beyond \"the migration job's `backoffLimit` and the Deployment's own rollout history.\" A take-home doesn't need a release engineering platform; it needs to show the shape of one.\n\n---\n*AI tooling note: drafted directly by Theo (Sonnet, this session) from 03's test-strategy outline and the containerization design above. Bree's and Callum's per-deliverable notes pending.*\n"
}

File created successfully at: /Users/warrenthompson/Source/LoginID/04-infra-devops/ci-pipeline.md (file state is current in your context — no need to Read it back)

{
  "file_path": "/Users/warrenthompson/Source/LoginID/04-infra-devops/local-dev-loop.md",
  "content": "# Local Dev-Loop\n\nDesign-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.\n\n## Two compose profiles, matching 03's `DB_DRIVER` env var\n\n```yaml\n# docker-compose.yml (sketch)\nservices:\n  api-service:\n    build: {context: ., dockerfile: cmd/api-service/Dockerfile}\n    environment:\n      DB_DRIVER: ${DB_DRIVER:-sqlite}\n      DB_DSN: ${DB_DSN:-file:/data/dev.db}\n      HTTP_ADDR: \":8080\"\n    ports: [\"8080:8080\"]\n    volumes: [\"sqlite-data:/data\"]\n    profiles: [\"sqlite\"]\n\n  api-service-pg:\n    extends: {service: api-service}\n    environment:\n      DB_DRIVER: postgres\n      DB_DSN: postgres://dev:«REDACTED»@postgres:5432/loginid_dev?sslmode=disable\n    depends_on: [postgres]\n    profiles: [\"postgres\"]\n\n  postgres:\n    image: postgres:16-alpine\n    environment: {POSTGRES_USER: dev, POSTGRES_PASSWORD: dev, POSTGRES_DB: loginid_dev}\n    ports: [\"5432:5432\"]\n    profiles: [\"postgres\"]\n\n  idp-connector:\n    build: {context: ., dockerfile: cmd/idp-connector/Dockerfile}\n    environment:\n      IDP_ABC_BASE_URL: ${IDP_ABC_BASE_URL:-http://mock-idp:9090}\n      IDP_ABC_CLIENT_ID: dev-client\n      IDP_ABC_CLIENT_SECRET: dev-secret\n    profiles: [\"sqlite\", \"postgres\"]\n\nvolumes:\n  sqlite-data:\n```\n\n`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 isn't in the local loop — it's wire-compatible enough with Postgres per 05's strategy doc that the Postgres profile exercises the shared code path; a CockroachDB-specific compose profile would test the same code again, not new code.\n\n## Dev credentials are dev credentials\n\nThe `dev`/`dev` Postgres password and the hardcoded `dev-client`/`dev-secret` above 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.\n\n## Migrations locally\n\n`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.\n\n## What's deliberately not here\n\nNo hot-reload/live-rebuild tooling (`air`, `reflex`), 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.\n\n---\n*AI tooling note: drafted directly by Theo (Sonnet, this session) from 03's config surface and the containerization design above. Bree's and Callum's per-deliverable notes pending.*\n"
}

File created successfully at: /Users/warrenthompson/Source/LoginID/04-infra-devops/local-dev-loop.md (file state is current in your context — no need to Read it back)

{
  "file_path": "/Users/warrenthompson/Source/LoginID/04-infra-devops/secrets-delivery.md",
  "content": "# Secrets Delivery Mechanics\n\nDesign-only. This document implements the delivery mechanism for what `../02-ai-security-architecture/handoff-04-secrets.md` v2 specifies must be a secret and why — this track doesn't decide what's a secret, only how it reaches a running process. Row numbers below refer to that hand-off's inventory table.\n\n## Mechanism: Kubernetes-native `Secret` objects, file-mounted\n\nPer the hand-off's Kubernetes-specific requirements: every secret in the inventory is delivered as a `Secret` resource, mounted read-only as a file into the consuming Pod, never passed as a plaintext env var except the one named transitional exception below. Manifests reference `Secret` **names** only (`secretName: api-service-db-dsn`) — values are never in a manifest, never in source, never in an image layer. Values are provisioned out-of-band by whoever applies the manifest (amber-kubernetes, per the deployment-target note) — this take-home describes that step, doesn't perform it.\n\n| Row | Secret | Mount | Consuming ServiceAccount / RBAC |\n|---|---|---|---|\n| #1 | `DB_DSN` | File, read via `DB_DSN_FILE` (03's convention, per the hand-off's upgraded requirement). Env-var `DB_DSN` supported only as a fallback until 03 ships the `_FILE` convention. | `api-service` SA |\n| #2 | JWT signing private key | File only, never env | Restricted Role scoped to the issuing code path within `api-service`'s own SA — not the verification path, per the hand-off's assumption 2 |\n| #3 | JWT public key / JWKS | Not a `Secret` — `ConfigMap` or fetched URL | n/a |\n| #4 | API caller `client_secret`s | Not a Kubernetes `Secret` — lives in the authorization server's own datastore (hashed, Argon2id) | Datastore credentials are shaped like row #1, delivered the same way |\n| #5 | `IDP_ABC_CLIENT_ID`/`SECRET` (+ XYZ pair) | File, one `Secret` per vendor so rotating one never touches the other | `idp-connector` SA |\n| #6 | Vendor `access_token` | Not deployed — transient, in-memory only. If cached, encrypted with #7's KEK; no `Secret` object | n/a |\n| #7 | KEK for envelope encryption | File. Per the hand-off's resolved v2: not a live requirement until TOTP or token-caching actually materializes — provisioned only if/when 05 or 02 confirms one of those features is real | `api-service` and/or `idp-connector` SA, whichever feature lands |\n| #7a | KMS-access credential | Only if the KMS alternative to #7 is exercised; workload-identity-based where the platform supports it, otherwise a `Secret` under the same RBAC discipline as #2 | Whichever binary holds #7 |\n| #8 | TLS serving private keys | `kubernetes.io/tls` `Secret`, automated issuance preferred (cert-manager or equivalent) | Ingress, or each binary if TLS terminates at the pod |\n| #9 | End-user vendor password | Nothing to deliver — transient request-body data, never persisted | n/a |\n\n## RBAC discipline\n\nNo ServiceAccount `get`s or `list`s a `Secret` it doesn't mount — enforced by a `Role`/`RoleBinding` per service, scoped to exactly the `Secret` names in the table above for that service, not a blanket namespace-read grant. Per the hand-off, this is narrower still for row #2: `api-service`'s own SA needs a distinct Role restricting the signing-key `Secret` to the issuing code path, which in practice means either a second SA for the issuer mode or a sidecar/init-container pattern that reads the key and the main container process never does — the exact split is an implementation detail for 03, not a change to this delivery mechanism.\n\nThe audit/access-log read requirement (hand-off, Kubernetes-specific requirements, last bullet) is a **separate** RBAC grant from Secret access — see `./observability.md` for how that log stream is isolated.\n\n## Secrets-at-rest in etcd\n\nPer the hand-off's explicit either/or: this design's answer is **enable encryption at rest for the `Secret` resource type** at the cluster level (an `EncryptionConfiguration` with a KMS or `aescbc` provider), rather than sourcing every value from an external store. Reasoning: an external store (Vault, cloud secrets manager) is real infrastructure this lab cluster doesn't currently run, and standing one up is out of scope for a take-home submission whose deployment is design-only anyway; cluster-level encryption-at-rest is a one-time `kube-apiserver` flag, not a new service to operate. If this became a real deployment with an existing Vault install, that would be the better answer — named here as the alternative, not designed.\n\n## CI-side secret handling\n\nNo secret in an image layer, build arg, or CI log — enforced by the pipeline's own gitleaks stage (`./ci-pipeline.md` §4) plus the container design never `COPY`ing anything but the compiled binary. CI's own credentials to reach the registry and (in the describe-only deploy stage) the cluster are themselves managed as CI-platform secrets (GitHub Actions encrypted secrets or equivalent) — same discipline, different delivery surface, not re-specified here since it's a standard CI-platform mechanism rather than something this design invents.\n\n---\n*AI tooling note: drafted directly by Theo (Sonnet, this session) from `handoff-04-secrets.md` v2. Bree's and Callum's per-deliverable notes pending.*\n"
}

File created successfully at: /Users/warrenthompson/Source/LoginID/04-infra-devops/secrets-delivery.md (file state is current in your context — no need to Read it back)

{
  "file_path": "/Users/warrenthompson/Source/LoginID/04-infra-devops/observability.md",
  "content": "# Observability + Never-Log Enforcement\n\nDesign-only. Covers logging, metrics, and tracing for both services, and — the harder half — how `handoff-04-secrets.md`'s never-log list gets enforced as a mechanism, not just stated as a policy.\n\n## Logging\n\nStructured logging (`slog`, Go stdlib — no third-party logging library needed for two services this size), JSON output, one line per event. Every log line that touches a request carries `sub` (caller identity), the endpoint, status, and a request id — never the request or response body wholesale. This is the pattern the never-log list requires (hand-off item 8: \"full request bodies of `POST /auth` and `POST /identity`... both contain items above by construction\") — the enforcement mechanism is that handlers log a small, explicit field set assembled by hand, never `log.Printf(\"%+v\", req)` or equivalent reflection-based dumps of a request/response struct. A struct that contains a password field can't leak through a log statement that never receives the struct.\n\n**Enforcement beyond \"write it carefully\":**\n- A lint rule (a `golangci-lint` custom check, or a simple `go vet`-style grep in CI) that flags any log call passing a whole request/response struct, a `*http.Request` body, or any variable named/typed to match the never-log list's fields (`password`, `token`, `secret`, `dsn`, `client_secret`). Not foolproof — a determined developer can rename around it — but it catches the accidental case, which is the common one.\n- Error-path discipline: wrapped errors are logged with `err.Error()` truncated/sanitized where the error type is known to carry sensitive detail (a DB driver error can echo the DSN; a vendor HTTP client error can echo the response body per hand-off item 4) — the wrapping layer strips those before the error reaches a log call, not the log call itself deciding case-by-case.\n\n## Metrics\n\nStandard RED metrics (rate, errors, duration) per endpoint, via Prometheus client library, scraped by whatever the lab cluster already runs (not stood up new for this take-home). Labels: method, route, status class — never a label with cardinality tied to user data (no `sub` or phone number as a metric label; that turns a metrics backend into an accidental PII store with no access control at all, which is a worse leak than a log line since metrics systems are typically more widely readable).\n\n## Tracing\n\nOpenTelemetry SDK, exported via OTLP to whatever collector the lab cluster runs, if any — named as the mechanism a real deployment would use; not something this take-home stands up. Span attributes follow the same discipline as log fields: caller identity and route, never PII values or secret material as a span attribute (span attributes are exactly as leak-prone as log fields and get less scrutiny in practice).\n\n## The never-log list, operationalized\n\nHand-off's nine items map to two enforcement surfaces, not nine separate mechanisms:\n\n1. **Application-level:** the structured-logging discipline above (explicit field sets, the lint check, error-wrapping sanitization) covers items 1, 2, 5, 6, 7 (password, tokens, JWTs, client secrets, DSN) — these never enter a Go `log`/`slog` call in the first place.\n2. **Proxy/ingress-level:** item 9 (\"search query parameters containing a name or phone fragment... redact or hash before any access log, including proxy and ingress logs 04 controls\") is the one item application code can't fully own, since ingress access logs are written by the ingress controller, not the service. Mechanism: an ingress-level log-format override that logs the request path with query string stripped (or a regex redaction on the `phone`/`name` query params specifically) rather than the default full-URL access log format. This is a one-time ingress ConfigMap change, not a per-request code path.\n3. Item 3 (PII field values from `/identity` or `user_profile`) and item 4 (raw vendor error bodies) are the same discipline as #1 applied to the connector specifically — the connector logs \"called vendor X, got status Y,\" never the response body.\n\n## Audit-log access is a separate grant from Secret access\n\nPer the hand-off's Kubernetes-specific requirements: the log stream carrying `sub`/scope/record-id/timestamp (the \"fact of access\" the never-log list still permits) is itself sensitive enough to reconstruct who looked up whom, so it gets its own RBAC — a distinct, narrower `Role` bound to an incident-review group, separate from any ServiceAccount's `Secret`-read grant (`./secrets-delivery.md`). Mechanism: if logs go to a cluster-local sink (e.g., Loki), that sink's read API gets its own RBAC/auth in front of it, not the same one guarding `kubectl get secrets`; if logs go to an external platform, the equivalent is a scoped read-only role in that platform, provisioned separately from any cluster credential.\n\n## What's deliberately not here\n\nNo SLOs/error-budget policy, no alerting-rule catalog, no log-retention-window design (that's 05's PII-retention territory for anything log-adjacent to PII, per `../05-data-ops/pii-governance.md` — this document only says logs must exclude PII values in the first place, not how long the remaining metadata is kept). A take-home needs the shape of an observability approach and a credible enforcement mechanism for the one hard requirement (never-log); it doesn't need a full SRE runbook.\n\n---\n*AI tooling note: drafted directly by Theo (Sonnet, this session) from `handoff-04-secrets.md` v2's never-log list. Bree's and Callum's per-deliverable notes pending.*\n"
}

File created successfully at: /Users/warrenthompson/Source/LoginID/04-infra-devops/observability.md (file state is current in your context — no need to Read it back)

{
  "replace_all": false,
  "file_path": "/Users/warrenthompson/Source/LoginID/04-infra-devops/containerization-design.md",
  "old_string": "      containers:\n        - name: api-service\n          image: registry.internal/loginid-poc/api-service:<tag>\n          envFrom:\n            - configMapRef: {name: api-service-config}   # DB_DRIVER, HTTP_ADDR, AUTH_JWT_ISSUER/AUDIENCE — non-secret\n          env:\n            - {name: DB_DSN_FILE, value: /secrets/db/dsn}\n          volumeMounts:",
  "new_string": "      containers:\n        - name: api-service\n          image: registry.internal/loginid-poc/api-service:<tag>\n          resources:\n            requests: {cpu: \"100m\", memory: \"128Mi\"}\n            limits: {cpu: \"500m\", memory: \"256Mi\"}\n          envFrom:\n            - configMapRef: {name: api-service-config}   # DB_DRIVER, HTTP_ADDR, AUTH_JWT_ISSUER/AUDIENCE — non-secret\n          env:\n            - {name: DB_DSN_FILE, value: /secrets/db/dsn}\n          volumeMounts:"
}

The file /Users/warrenthompson/Source/LoginID/04-infra-devops/containerization-design.md has been updated successfully. (file state is current in your context — no need to Read it back)

{
  "replace_all": false,
  "file_path": "/Users/warrenthompson/Source/LoginID/04-infra-devops/containerization-design.md",
  "old_string": "`idp-connector`'s manifest is the same shape with its own two `Secret` volume mounts (per-vendor client credentials, one `Secret` per vendor per handoff row #5) and no inbound `Service` — it is called by `api-service` or invoked as a job, never exposed to anything outside the cluster. Exact invocation shape (long-running service vs. on-demand job) is undecided; either way the container/image design above doesn't change.",
  "new_string": "`idp-connector`'s manifest is the same shape with its own two `Secret` volume mounts (per-vendor client credentials, one `Secret` per vendor per handoff row #5), its own `resources` block (`idp-connector` is I/O-bound waiting on vendor calls, not CPU-heavy — requests `{cpu: 50m, memory: 64Mi}`, limits `{cpu: 250m, memory: 128Mi}`), and no inbound `Service` — it is called by `api-service` or invoked as a job, never exposed to anything outside the cluster. Exact invocation shape (long-running service vs. on-demand job) is undecided; either way the container/image design above doesn't change.\n\n**On process vs. host isolation (per 03/Renata, `../PLANNING.md`):** the two-binary split is a process boundary, not a placement guarantee — if both Pods land on the same node, the failure isolation it buys (a stalled vendor call can't starve `api-service`'s own connection pool) depends on resource limits actually being enforced, not just on the processes being separate. The `limits` blocks above are that enforcement: a CPU limit means a stuck `idp-connector` can't starve `api-service`'s scheduling on a shared node, and a memory limit means it gets OOM-killed rather than pressuring the node into evicting something else. This is on top of, not instead of, 03's own connector-side backpressure (`context.WithTimeout` on every outbound vendor call, bounded retry/backoff on token refresh, per their S4) — that bounds how long the connector *tries*; these limits bound what it can *cost the node* while it's trying. A `PodAntiAffinity` `preferredDuringScheduling` rule to keep them off the same node is a cheap additional step worth naming, though not required given the limits above."
}

The file /Users/warrenthompson/Source/LoginID/04-infra-devops/containerization-design.md has been updated successfully. (file state is current in your context — no need to Read it back)

{
  "to": "03-engineering-delivery-b7",
  "summary": "Resource limits added — isolation is mine to enforce",
  "message": "Fair, and that's my call to make, so I made it: added `resources.requests/limits` to both Pod specs in `containerization-design.md` (CPU+memory, sized differently per service — connector is I/O-bound, not CPU-heavy) plus a note explaining these enforce the isolation the process split implies even if colocated, on top of your S4 backpressure, not instead of it. Also named a `PodAntiAffinity` as a cheap optional extra. Noted your context.WithTimeout/backoff work is yours, not assumed solved on my end. Thanks for flagging it.",
  "type": "message",
  "recipient": "03-engineering-delivery-b7",
  "content": "Fair, and that's my call to make, so I made it: a…"
}

{"success":true,"message":"“Resource limits added — isolation is mine to enforce” → 03-engineering-delivery-b7 (another Claude session on this machine)","msg_id":"42fba630-ce1e-4464-8514-8f08e447a070"}

{
  "to": "bree-sandoval",
  "summary": "Review all five draft deliverables",
  "message": "All five deliverables are drafted now: `./containerization-design.md`, `./ci-pipeline.md`, `./local-dev-loop.md`, `./secrets-delivery.md`, `./observability.md`. Read them.\n\nPer your role in PLAN.md §2: for containerization, CI, and dev-loop specifically, write the \"what's the more capable/interesting option and what would it cost us\" case for anywhere I defaulted to the minimum — short, per-deliverable, a few sentences each, not a separate debate doc. I'll fold your notes directly into each file as a labeled section. Report back to me when done.",
  "type": "message",
  "recipient": "bree-sandoval",
  "content": "All five deliverables are drafted now: `./contain…"
}

{"success":true,"message":"Message sent to bree-sandoval's inbox","msg_id":"0324cd94-7348-47d2-8e1b-25be32295ecd","routing":{"sender":"team-lead","target":"@bree-sandoval","targetColor":"green","summary":"Review all five draft deliverables","content":"All five deliverables are drafted now: `./contain…"}}

{
  "to": "callum-ferreira",
  "summary": "Scope-cut review of all five deliverables",
  "message": "All five deliverables are drafted now: `./containerization-design.md`, `./ci-pipeline.md`, `./local-dev-loop.md`, `./secrets-delivery.md`, `./observability.md`. Read them.\n\nPer your role in PLAN.md §2: what would you cut from each? Watching specifically for take-home scope creep (k8s manifests, service-mesh-adjacent stuff, an over-built observability stack) that reads as impressive but isn't what the assignment needs. Short note per deliverable. I'll fold your notes directly into each file. Report back to me when done.",
  "type": "message",
  "recipient": "callum-ferreira",
  "content": "All five deliverables are drafted now: `./contain…"
}

{"success":true,"message":"Message sent to callum-ferreira's inbox","msg_id":"593f9048-c3c4-4d4f-b7dc-3e523c6f6eaf","routing":{"sender":"team-lead","target":"@callum-ferreira","targetColor":"yellow","summary":"Scope-cut review of all five deliverables","content":"All five deliverables are drafted now: `./contain…"}}

{
  "file_path": "/Users/warrenthompson/Source/LoginID/04-infra-devops/containerization-design.md",
  "offset": 55,
  "limit": 15
}

55	            - {name: jwt-signing-key, mountPath: /secrets/jwt, readOnly: true}
56	          readinessProbe: {httpGet: {path: /healthz, port: 8080}, initialDelaySeconds: 5}
57	          livenessProbe: {httpGet: {path: /healthz, port: 8080}, initialDelaySeconds: 10}
58	      volumes:
59	        - name: db-dsn
60	          secret: {secretName: api-service-db-dsn}
61	        - name: jwt-signing-key
62	          secret: {secretName: api-service-jwt-signing-key}
63	---
64	apiVersion: v1
65	kind: Service
66	metadata: {name: api-service}
67	spec:
68	  selector: {app: api-service}
69	  ports: [{port: 443, targetPort: 8080}]

{
  "replace_all": false,
  "file_path": "/Users/warrenthompson/Source/LoginID/04-infra-devops/containerization-design.md",
  "old_string": "**On process vs. host isolation (per 03/Renata, `../PLANNING.md`):** the two-binary split is a process boundary, not a placement guarantee — if both Pods land on the same node, the failure isolation it buys (a stalled vendor call can't starve `api-service`'s own connection pool) depends on resource limits actually being enforced, not just on the processes being separate. The `limits` blocks above are that enforcement: a CPU limit means a stuck `idp-connector` can't starve `api-service`'s scheduling on a shared node, and a memory limit means it gets OOM-killed rather than pressuring the node into evicting something else. This is on top of, not instead of, 03's own connector-side backpressure (`context.WithTimeout` on every outbound vendor call, bounded retry/backoff on token refresh, per their S4) — that bounds how long the connector *tries*; these limits bound what it can *cost the node* while it's trying. A `PodAntiAffinity` `preferredDuringScheduling` rule to keep them off the same node is a cheap additional step worth naming, though not required given the limits above.",
  "new_string": "**On process vs. host isolation (per 03/Renata, `../PLANNING.md`):** the two-binary split is a process boundary, not a placement guarantee — the `resources.limits` above are what actually enforce it if both Pods land on the same node, on top of (not instead of) 03's own connector-side backpressure (`context.WithTimeout`, bounded retry/backoff, their S4)."
}

The file /Users/warrenthompson/Source/LoginID/04-infra-devops/containerization-design.md has been updated successfully. (file state is current in your context — no need to Read it back)

{
  "replace_all": false,
  "file_path": "/Users/warrenthompson/Source/LoginID/04-infra-devops/secrets-delivery.md",
  "old_string": "| #7 | KEK for envelope encryption | File. Per the hand-off's resolved v2: not a live requirement until TOTP or token-caching actually materializes — provisioned only if/when 05 or 02 confirms one of those features is real | `api-service` and/or `idp-connector` SA, whichever feature lands |\n| #7a | KMS-access credential | Only if the KMS alternative to #7 is exercised; workload-identity-based where the platform supports it, otherwise a `Secret` under the same RBAC discipline as #2 | Whichever binary holds #7 |",
  "new_string": "| #7 | KEK for envelope encryption | File. Per the hand-off's resolved v2: not a live requirement until TOTP or token-caching actually materializes — provisioned only if/when 05 or 02 confirms one of those features is real. If a KMS is used instead of a mounted key (row #7a), its access credential follows the same delivery discipline as row #2. | `api-service` and/or `idp-connector` SA, whichever feature lands |"
}

The file /Users/warrenthompson/Source/LoginID/04-infra-devops/secrets-delivery.md has been updated successfully. (file state is current in your context — no need to Read it back)

{
  "replace_all": false,
  "file_path": "/Users/warrenthompson/Source/LoginID/04-infra-devops/observability.md",
  "old_string": "## Tracing\n\nOpenTelemetry SDK, exported via OTLP to whatever collector the lab cluster runs, if any — named as the mechanism a real deployment would use; not something this take-home stands up. Span attributes follow the same discipline as log fields: caller identity and route, never PII values or secret material as a span attribute (span attributes are exactly as leak-prone as log fields and get less scrutiny in practice).",
  "new_string": "## Tracing\n\nNot built out here — a two-service take-home with no running collector doesn't get more credible by naming OpenTelemetry. If ever added, it follows the same field discipline as logging."
}

The file /Users/warrenthompson/Source/LoginID/04-infra-devops/observability.md has been updated successfully. (file state is current in your context — no need to Read it back)

{
  "replace_all": false,
  "file_path": "/Users/warrenthompson/Source/LoginID/04-infra-devops/containerization-design.md",
  "old_string": "## 5. What's deliberately not here\n\nNo service mesh, no Istio/Linkerd sidecar, no HorizontalPodAutoscaler, no PodDisruptionBudget, no NetworkPolicy beyond what the namespace default provides. This is a two-service take-home submission, not a platform. If any of these earn their place later, they're additive to this design, not a rewrite of it.",
  "new_string": "## 5. NetworkPolicy: adopted, not cut\n\nConsidered and dropped from an earlier pass as scope creep, then reconsidered: §3's claim that `idp-connector` is isolated because it never gets an inbound `Service` is a paper boundary without one. Anything else on the namespace's default-allow network can still reach it directly and skip `api-service`'s auth path entirely — which undermines the exact \"different threat models\" reasoning 02 gave for splitting the images in the first place. A minimal default-deny `NetworkPolicy` for the `idp-connector` Pod, with one explicit `ingress` rule allowing traffic only from `api-service`'s pod selector, is ~15 lines and one more manifest to keep in sync — cheap relative to what it closes. Included below; everything else in this section stays cut.\n\n```yaml\napiVersion: networking.k8s.io/v1\nkind: NetworkPolicy\nmetadata: {name: idp-connector-default-deny}\nspec:\n  podSelector: {matchLabels: {app: idp-connector}}\n  policyTypes: [Ingress]\n  ingress:\n    - from: [{podSelector: {matchLabels: {app: api-service}}}]\n```\n\n## 6. What's deliberately not here\n\nNo service mesh, no Istio/Linkerd sidecar, no HorizontalPodAutoscaler, no PodDisruptionBudget. This is a two-service take-home submission, not a platform. If any of these earn their place later, they're additive to this design, not a rewrite of it."
}

The file /Users/warrenthompson/Source/LoginID/04-infra-devops/containerization-design.md has been updated successfully. (file state is current in your context — no need to Read it back)

{
  "replace_all": false,
  "file_path": "/Users/warrenthompson/Source/LoginID/04-infra-devops/ci-pipeline.md",
  "old_string": "3. **Test.** `go test ./... -race` — unit tests against 03's `internal/dao` per-backend implementations (SQLite in-process for the fast path, a Postgres testcontainer for the Postgres/CockroachDB-shared code path — exact test-double strategy is 03's call, this stage just runs whatever `go test` finds). `-race` is not optional given two DB implementations and a migration-runner exclusivity requirement (05's R2) that's exactly the kind of thing a race detector catches in test even though it's enforced by orchestration in production.",
  "new_string": "3. **Test.** `go test ./... -race` — unit tests against 03's `internal/dao` per-backend implementations: SQLite in-process for the fast path, plus **two** testcontainer jobs against the shared `postgres` package — one on Postgres, one on CockroachDB. Considered running CockroachDB only in the local dev-loop (wire-compatible enough with Postgres that testing both looked redundant) and reconsidered for CI specifically: wire-compatible isn't schema-compatible, and a Postgres-only test matrix means a CockroachDB-specific SQL quirk (UUID defaults, upsert syntax, lock semantics) surfaces at deploy time instead of at PR time. CockroachDB ships an official single-node Docker image, so this is a config addition to the test job, not new infrastructure — a few extra minutes of CI wall-clock for catching it at the cheapest possible point. `-race` is not optional given two DB implementations and a migration-runner exclusivity requirement (05's R2) that's exactly the kind of thing a race detector catches in test even though it's enforced by orchestration in production."
}

The file /Users/warrenthompson/Source/LoginID/04-infra-devops/ci-pipeline.md has been updated successfully. (file state is current in your context — no need to Read it back)

{
  "replace_all": false,
  "file_path": "/Users/warrenthompson/Source/LoginID/04-infra-devops/local-dev-loop.md",
  "old_string": "## What's deliberately not here\n\nNo hot-reload/live-rebuild tooling (`air`, `reflex`), 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.",
  "new_string": "## Hot-reload for `api-service`, dev-profile only\n\nConsidered 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.\n\n## What's deliberately not here\n\nNo 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."
}

The file /Users/warrenthompson/Source/LoginID/04-infra-devops/local-dev-loop.md has been updated successfully. (file state is current in your context — no need to Read it back)

{
  "replace_all": false,
  "file_path": "/Users/warrenthompson/Source/LoginID/PLANNING.md",
  "old_string": "| 04 Infra & DevOps | Theo Bergman | hires spawned 3/3 — awaiting inputs | 03 service boundaries, 02 secrets inventory, 05 migration approach | — | `04-infra-devops/PLAN.md` | 3 / 3 / 3 | 2026-09-12 |",
  "new_string": "| 04 Infra & DevOps | Theo Bergman | five deliverables drafted, Bree/Callum notes folded in | — | — | `04-infra-devops/PLAN.md`; `containerization-design.md`, `ci-pipeline.md`, `local-dev-loop.md`, `secrets-delivery.md`, `observability.md` | 3 / 3 / 3 | 2026-09-12 |"
}

<tool_use_error>File has been modified since read, either by the user or by a linter. Read it again before attempting to write it.</tool_use_error>

{
  "file_path": "/Users/warrenthompson/Source/LoginID/PLANNING.md",
  "offset": 1,
  "limit": 20
}

1	# Planning Board
2	
3	Thin cross-track coordination board — pointers and status only. The reasoning lives in each track's own files (`<track>/CLAUDE.md`, `<track>/PLAN.md`, deliverables), referenced by relative path. **One writer per row:** each lead edits only its own row; team-lead edits the header, the two Dana rows, and nothing else. Shape and rationale: `02-ai-security-architecture/planning-approach.md` §3. Org plan: `PLAN.md`. Hiring rules and registry: `CASTING.md`.
4	
5	Status vocabulary: `not started` · `planning` · `plan drafted — awaiting hiring go` · `hiring go` · `hiring` · `debating` · `plan approved` · `blocked`.
6	
7	| Track | Lead | Status | Blocking on | Blocked by | Planning notes | Hires (planned / registered / spawned) | Last updated |
8	|---|---|---|---|---|---|---|---|
9	| Orchestration (root) | Dana Whitfield | Phase 2 complete — all 18 hires live in five lead sessions; Phase 3 debates under way | 02 hand-offs to 03/04; 05 S1 contract; first `decisions/` artifacts | — | `PLAN.md`, `LOG.md` | 18 / 18 (cap) | 2026-09-12 |
10	| Cross-track consistency pass (root, Phase 3) | Dana Whitfield | not started | all five `plan approved` | — | `PLAN.md` Phase 3 | — | 2026-09-12 |
11	| 01 Product & Industry Research (incl. Design) | Naomi Voss | plan approved — S1–S6 all done (claims audit, password-baseline debate, connector rationale hardened + cold read, search-authz requirements, UX notes, evaluator-legibility cold read) | — | — | `01-product-industry-research-design/PLAN.md`; `decisions/claims-audit.md`, `decisions/password-baseline-debate.md`, `decisions/rationale-cold-read.md` (S3+S6) all written; Newcomer loan from 04 (`wesley-okonkwo`) closed at 2/2-4 turns, both passed clean | 3 / 3 / 3 | 2026-09-12 |
12	| 02 AI Architecture & Security Architecture | Marcus Ilori | S3, S4, S6, S7 done — S5/S8/S9/S10 next | — | — | `02-ai-security-architecture/PLAN.md`; S3 `decisions/connector-token-lifecycle-redblue.md` + table in `connector-security.md`; S4 `decisions/search-authz-scoping.md` + finalized scoping in `api-auth-design.md`; S6 `handoff-03-auth.md` sent to 03; S7 `handoff-04-secrets.md` v1 sent to 04, cold-read and fixed | 4 / 4 / 4 | 2026-09-12 |
13	| 03 Engineering & Delivery | Renata Cole | hires spawned 4/4 — `handoff-03-auth.md` received, cold read clean | 05 contract (DAO) | — | `03-engineering-delivery/PLAN.md`; `handoff-03-auth.md` accepted, `DB_DSN_FILE` folded into Service boundaries config surface | 4 / 4 / 4 | 2026-09-12 |
14	| 04 Infra & DevOps | Theo Bergman | hires spawned 3/3 — awaiting inputs | 03 service boundaries, 02 secrets inventory, 05 migration approach | — | `04-infra-devops/PLAN.md` | 3 / 3 / 3 | 2026-09-12 |
15	| 05 Data Ops | Priya Nandakumar | hires spawned 4/4 — S4 drafted, S2/S3 debates next | — | — | `05-data-ops/PLAN.md`; 6 stories S1–S6, S1 = Go-shaped contract in `multi-db-strategy.md` (critical path); S4 `migration-approach.md` + S5 retention table unblock 04; `migration-approach.md` drafted for 04 (R1–R5; single-runner requirement is platform-enforced — pg_advisory_lock is unavailable on CockroachDB), pending one objection turn; deep research authorized+run (lead): `05-data-ops/research-cockroachdb-postgres-semantics.md` — one Go package CAN serve Postgres+CockroachDB but needs an engine-aware retry/error seam (CRDB SERIALIZABLE returns client-retryable 40001; sentinel translation must be SQLSTATE-only); corrects R2 of `migration-approach.md`; factory mismatch closed with 03 direct (two-party): `dao.Repository` composite exposing `Profiles()`/`Credentials()`/`Methods()`, `dao.New` signature unchanged — cited in S1 | 4 / 4 / 4 | 2026-09-12 |
16	
17	## Sessions (owned by team-lead)
18	
19	Each lead is its own top-level Claude Code session in its own tmux window. Use the session name with `SendMessage` (confirm with `ListAgents`); hires are teammates of their lead's session and are reached through the lead.
20	

{
  "replace_all": false,
  "file_path": "/Users/warrenthompson/Source/LoginID/PLANNING.md",
  "old_string": "| 04 Infra & DevOps | Theo Bergman | hires spawned 3/3 — awaiting inputs | 03 service boundaries, 02 secrets inventory, 05 migration approach | — | `04-infra-devops/PLAN.md` | 3 / 3 / 3 | 2026-09-12 |",
  "new_string": "| 04 Infra & DevOps | Theo Bergman | five deliverables drafted, Bree/Callum notes folded in | — | — | `04-infra-devops/PLAN.md`; `containerization-design.md`, `ci-pipeline.md`, `local-dev-loop.md`, `secrets-delivery.md`, `observability.md` | 3 / 3 / 3 | 2026-09-12 |"
}

The file /Users/warrenthompson/Source/LoginID/PLANNING.md has been updated successfully. (file state is current in your context — no need to Read it back)

{
  "replace_all": false,
  "file_path": "/Users/warrenthompson/Source/LoginID/04-infra-devops/PLAN.md",
  "old_string": "Until all three land, this track's status stays \"not started\" on the deliverables above and this track's actual role is reviewer/consumer: read the other four tracks' output as it lands, flag anything infra-shaped that risks being silently owned elsewhere, and otherwise stay out of the way.",
  "new_string": "## 5. Status (updated post-drafting)\n\nAll three gating inputs landed (03 boundaries stable, 02 secrets hand-off v2, 05 migration approach provisional-but-stable-for-04-per-05's-own-note) and Warren gave the go to start against them once the usage reset. All five deliverables drafted: `./containerization-design.md`, `./ci-pipeline.md`, `./local-dev-loop.md`, `./secrets-delivery.md`, `./observability.md`. Bree's capability-case notes (NetworkPolicy adopted, CockroachDB CI job adopted, hot-reload adopted; HPA/service-mesh declined) and Callum's scope-cut notes (isolation-paragraph trim, anti-affinity dropped, KMS row folded, tracing cut to one line) are folded directly into the files, not a separate decisions artifact, per PLAN.md §3's proportionality call. `newcomer-coldread-boundaries-secrets.md` in `./decisions/` covers Wesley's earlier hand-off legibility pass. Wesley also ran a bounded two-turn loan for 01 (Naomi), closed clean."
}

The file /Users/warrenthompson/Source/LoginID/04-infra-devops/PLAN.md has been updated successfully. (file state is current in your context — no need to Read it back)

{
  "to": "org-planning-loginid-takehome",
  "summary": "04's five deliverables done",
  "message": "All five 04 deliverables drafted and reviewed: containerization design (Dockerfile shape + K8s manifest sketch targeting the lab cluster, incl. a NetworkPolicy adopted after Bree's push), CI pipeline (added a CockroachDB test job on Bree's case), local dev-loop (compose, two DB profiles, hot-reload adopted), secrets delivery (implements 02's inventory row-by-row), observability (never-log enforcement mechanism, tracing cut to one line on Callum's scope-guard pass). PLANNING.md row updated. No code/config committed — still design-only per root CLAUDE.md.",
  "type": "message",
  "recipient": "org-planning-loginid-takehome",
  "content": "All five 04 deliverables drafted and reviewed: co…"
}

{"success":true,"message":"“04's five deliverables done” → org-planning-loginid-takehome (another Claude session on this machine)","msg_id":"b75a9359-b08d-4a1b-a1d8-579b9ff14877"}

{
  "command": "grep -n -i \"provisional\\|goose\\|migration\" /Users/warrenthompson/Source/LoginID/04-infra-devops/containerization-design.md /Users/warrenthompson/Source/LoginID/04-infra-devops/ci-pipeline.md"
}

/Users/warrenthompson/Source/LoginID/04-infra-devops/containerization-design.md:5:Inputs this depends on: `../PLANNING.md` Service boundaries (03, stable), `../02-ai-security-architecture/handoff-04-secrets.md` v2 (02, stable), `../05-data-ops/migration-approach.md` (05, provisional — noted where it matters).
/Users/warrenthompson/Source/LoginID/04-infra-devops/containerization-design.md:21:Both images run as a read-only root filesystem (`securityContext.readOnlyRootFilesystem: true` at the Pod spec level) — neither binary writes to disk at runtime; migrations are a separate job (see §4), not something either service does to itself on boot.
/Users/warrenthompson/Source/LoginID/04-infra-devops/containerization-design.md:76:## 4. Migration job
/Users/warrenthompson/Source/LoginID/04-infra-devops/containerization-design.md:78:Per 05's requirement R1/R2 (`../05-data-ops/migration-approach.md`, provisional — the tool name may still change, the mechanism below doesn't): a `Job`, not an init container, with `parallelism: 1` and `backoffLimit` set so it doesn't retry indefinitely against a database it's already partially migrated. Runs `goose` (or whatever 05 finalizes) against the migration-runner credential (DDL-only, distinct from the runtime service credential per R4) before the Deployment's rollout proceeds — enforced by a CI/CD pipeline gate (`./ci-pipeline.md` §4), not by Kubernetes ordering alone, because R2's single-runner requirement has to hold across concurrent deploys too, not just within one.
/Users/warrenthompson/Source/LoginID/04-infra-devops/ci-pipeline.md:9:3. **Test.** `go test ./... -race` — unit tests against 03's `internal/dao` per-backend implementations: SQLite in-process for the fast path, plus **two** testcontainer jobs against the shared `postgres` package — one on Postgres, one on CockroachDB. Considered running CockroachDB only in the local dev-loop (wire-compatible enough with Postgres that testing both looked redundant) and reconsidered for CI specifically: wire-compatible isn't schema-compatible, and a Postgres-only test matrix means a CockroachDB-specific SQL quirk (UUID defaults, upsert syntax, lock semantics) surfaces at deploy time instead of at PR time. CockroachDB ships an official single-node Docker image, so this is a config addition to the test job, not new infrastructure — a few extra minutes of CI wall-clock for catching it at the cheapest possible point. `-race` is not optional given two DB implementations and a migration-runner exclusivity requirement (05's R2) that's exactly the kind of thing a race detector catches in test even though it's enforced by orchestration in production.
/Users/warrenthompson/Source/LoginID/04-infra-devops/ci-pipeline.md:18:7. **Run migration job** — describe-only in this design: the pipeline would invoke whatever 05 finalizes (`goose` per current draft) against the migration-runner credential, gated so only one pipeline run at a time can reach this stage (05's R2; a concurrency group / mutex on the pipeline's own deploy environment, not a database lock — CockroachDB has no advisory locks, so the exclusivity has to live in the orchestration layer regardless of which backend is targeted).
/Users/warrenthompson/Source/LoginID/04-infra-devops/ci-pipeline.md:23:No canary/blue-green deploy strategy, no multi-environment promotion pipeline (dev → staging → prod), no automated rollback orchestration beyond "the migration job's `backoffLimit` and the Deployment's own rollout history." A take-home doesn't need a release engineering platform; it needs to show the shape of one.

{
  "replace_all": false,
  "file_path": "/Users/warrenthompson/Source/LoginID/04-infra-devops/containerization-design.md",
  "old_string": "Per 05's requirement R1/R2 (`../05-data-ops/migration-approach.md`, provisional — the tool name may still change, the mechanism below doesn't): a `Job`, not an init container,",
  "new_string": "Per 05's requirement R1/R2 (`../05-data-ops/migration-approach.md` — **provisional, pending Priya's objection-turn ruling; treat this whole section as subject to revision until she marks it final**, though the tool name is the only likely change, not the mechanism): a `Job`, not an init container,"
}

The file /Users/warrenthompson/Source/LoginID/04-infra-devops/containerization-design.md has been updated successfully. (file state is current in your context — no need to Read it back)

{
  "replace_all": false,
  "file_path": "/Users/warrenthompson/Source/LoginID/04-infra-devops/ci-pipeline.md",
  "old_string": "7. **Run migration job** — describe-only in this design: the pipeline would invoke whatever 05 finalizes (`goose` per current draft) against the migration-runner credential, gated so only one pipeline run at a time can reach this stage (05's R2; a concurrency group / mutex on the pipeline's own deploy environment, not a database lock — CockroachDB has no advisory locks, so the exclusivity has to live in the orchestration layer regardless of which backend is targeted).",
  "new_string": "7. **Run migration job** — describe-only in this design, and **provisional pending 05's objection-turn ruling on `migration-approach.md`**: the pipeline would invoke whatever 05 finalizes (`goose` per current draft) against the migration-runner credential, gated so only one pipeline run at a time can reach this stage (05's R2; a concurrency group / mutex on the pipeline's own deploy environment, not a database lock — CockroachDB has no advisory locks, so the exclusivity has to live in the orchestration layer regardless of which backend is targeted)."
}

The file /Users/warrenthompson/Source/LoginID/04-infra-devops/ci-pipeline.md has been updated successfully. (file state is current in your context — no need to Read it back)

{
  "to": "org-planning-loginid-takehome",
  "summary": "Both holds addressed",
  "message": "Confirmed — Bree's/Callum's rationale was already inline in each deliverable (labeled sections: \"NetworkPolicy: adopted, not cut,\" the CockroachDB-job paragraph in CI, the hot-reload note in dev-loop, tracing cut to one line), not just folded silently. Strengthened both holds explicitly: containerization-design.md §4 and ci-pipeline.md's migration-job stage now say outright \"provisional, pending Priya's objection-turn ruling on migration-approach.md\" rather than just \"provisional.\" The K8s manifest sketch already stated it's design-only, nothing applied, no operator contact — unchanged, and I'll keep it that way. Team staged and holding for the consistency pass.",
  "type": "message",
  "recipient": "org-planning-loginid-takehome",
  "content": "Confirmed — Bree's/Callum's rationale was already…"
}

{"success":true,"message":"“Both holds addressed” → org-planning-loginid-takehome (another Claude session on this machine)","msg_id":"dc61a26f-4113-412a-90d7-090fa4728f4d"}

{
  "command": "grep -n -i \"advisory\" /Users/warrenthompson/Source/LoginID/04-infra-devops/*.md"
}

/Users/warrenthompson/Source/LoginID/04-infra-devops/ci-pipeline.md:8:2. **Lint.** `golangci-lint run` (staticcheck, govet, unused, errcheck at minimum). Non-negotiable gate, not advisory — a lint failure blocks merge, same as a test failure.
/Users/warrenthompson/Source/LoginID/04-infra-devops/ci-pipeline.md:18:7. **Run migration job** — describe-only in this design, and **provisional pending 05's objection-turn ruling on `migration-approach.md`**: the pipeline would invoke whatever 05 finalizes (`goose` per current draft) against the migration-runner credential, gated so only one pipeline run at a time can reach this stage (05's R2; a concurrency group / mutex on the pipeline's own deploy environment, not a database lock — CockroachDB has no advisory locks, so the exclusivity has to live in the orchestration layer regardless of which backend is targeted).

{
  "replace_all": false,
  "file_path": "/Users/warrenthompson/Source/LoginID/04-infra-devops/ci-pipeline.md",
  "old_string": "gated so only one pipeline run at a time can reach this stage (05's R2; a concurrency group / mutex on the pipeline's own deploy environment, not a database lock — CockroachDB has no advisory locks, so the exclusivity has to live in the orchestration layer regardless of which backend is targeted).",
  "new_string": "gated so only one pipeline run at a time can reach this stage (05's R2, strengthened per Priya's correction: CockroachDB's `pg_try_advisory_lock` variants silently no-op — a second runner reads back as if it acquired the lock rather than erroring — so a DB-advisory-lock guard isn't just unavailable, it's actively unsafe to rely on here; a concurrency group / mutex on the pipeline's own deploy environment is the only exclusivity mechanism this design uses, and it doesn't touch the database at all)."
}

The file /Users/warrenthompson/Source/LoginID/04-infra-devops/ci-pipeline.md has been updated successfully. (file state is current in your context — no need to Read it back)

{
  "to": "wesley-okonkwo",
  "summary": "Loan turn 1 for Priya (05)",
  "message": "New loan, turn 1 of ≤4, for Priya Nandakumar (05 lead). You haven't read her track's reasoning docs, which is the point — read `../05-data-ops/migration-approach.md` cold, exactly as 03 would (the doc's stated primary receiver, alongside us). List what you couldn't act on without asking Priya a question first — same method as your earlier passes. You don't have cross-session messaging, so report back to me and I'll relay to her session (`data-ops-planning-phase`).",
  "type": "message",
  "recipient": "wesley-okonkwo",
  "content": "New loan, turn 1 of ≤4, for Priya Nandakumar (05 …"
}

{"success":true,"message":"Message sent to wesley-okonkwo's inbox","msg_id":"19a449c9-bf0b-4216-a6a5-6787a77e1d41","routing":{"sender":"team-lead","target":"@wesley-okonkwo","targetColor":"blue","summary":"Loan turn 1 for Priya (05)","content":"New loan, turn 1 of ≤4, for Priya Nandakumar (05 …"}}

{
  "to": "data-ops-planning-phase",
  "summary": "Wesley dispatched + advisory-lock correction folded in",
  "message": "He was free — dispatched now for the cold read on `migration-approach.md`, reporting back to me since he has no cross-session tool; I'll relay. Also folded your advisory-lock correction into `ci-pipeline.md`'s migration-job stage: rewrote \"CockroachDB has no advisory locks\" to state the actual failure mode (try-lock silently no-ops rather than erroring, so it's not just unavailable but actively unsafe to lean on) — the orchestration-layer-only exclusivity design was already what I had, so nothing else in my docs changes. Will treat the whole migration section as provisional until your objection turn closes.",
  "type": "message",
  "recipient": "data-ops-planning-phase",
  "content": "He was free — dispatched now for the cold read on…"
}

{"success":true,"message":"“Wesley dispatched + advisory-lock correction folded in” → data-ops-planning-phase (another Claude session on this machine; it is also connected via Remote Control)","msg_id":"c88efcb1-36af-4c45-9108-17633602da96"}

{
  "to": "data-ops-planning-phase",
  "summary": "Wesley's cold read on migration-approach.md — relayed",
  "message": "Relaying (no cross-session tool on his end). Cold read of `migration-approach.md`, turn 1 of ≤4:\n\nUndefined-on-first-use terms: \"goose\" (never states it's a Go CLI migration runner before assuming familiarity), \"`goose fix`\" (can guess it renumbers timestamped files, but unstated), \"type-affinity\"/\"NUMERIC affinity\" (SQLite typing model assumed), the three `pg_advisory_lock`/`pg_try_advisory_lock`/`pg_advisory_xact_lock` primitives (named and distinguished as R2's central argument, but \"advisory lock\" itself is never defined), \"`pg_trgm` GIN index\" (named twice with real privilege consequences in R4 but never says what it does or why `name` needs it — he can't tell if it's background or actionable).\n\nOne punted-but-clear item: R3's \"version the service was built against\" is explicitly left as \"03's and 04's call\" — he flags he can't design the actual check from this doc alone, which reads as correct rather than a gap, since the doc itself defers it.\n\nRecurring cross-reference gap (same one from his last loan): \"S1\"/\"S3\"/\"S4\" shorthand for open items in `./PLAN.md` is used three times with no inline definition — he can't independently locate what they refer to without opening that file.\n\nOne thing he wants confirmed rather than assumed: R2's \"tell me if 04 concludes the platform cannot guarantee [single-runner exclusion]\" reads as a genuinely open question handed to us, not something already resolved — he thinks that's intentional but flagged it since his stated blind spot is mistaking a deliberate open item for a gap.\n\nTurn 1 of ≤4 used. He's back with me.",
  "type": "message",
  "recipient": "data-ops-planning-phase",
  "content": "Relaying (no cross-session tool on his end). Cold…"
}

{"success":true,"message":"“Wesley's cold read on migration-approach.md — relayed” → data-ops-planning-phase (another Claude session on this machine; it is also connected via Remote Control)","msg_id":"0d160491-7878-43b3-a2a5-92b8f58d512f"}

{
  "command": "grep -n -i \"credential\\|R4\\|CREATE EXTENSION\\|pg_trgm\" /Users/warrenthompson/Source/LoginID/04-infra-devops/containerization-design.md /Users/warrenthompson/Source/LoginID/04-infra-devops/secrets-delivery.md"
}

/Users/warrenthompson/Source/LoginID/04-infra-devops/containerization-design.md:72:`idp-connector`'s manifest is the same shape with its own two `Secret` volume mounts (per-vendor client credentials, one `Secret` per vendor per handoff row #5), its own `resources` block (`idp-connector` is I/O-bound waiting on vendor calls, not CPU-heavy — requests `{cpu: 50m, memory: 64Mi}`, limits `{cpu: 250m, memory: 128Mi}`), and no inbound `Service` — it is called by `api-service` or invoked as a job, never exposed to anything outside the cluster. Exact invocation shape (long-running service vs. on-demand job) is undecided; either way the container/image design above doesn't change.
/Users/warrenthompson/Source/LoginID/04-infra-devops/containerization-design.md:78:Per 05's requirement R1/R2 (`../05-data-ops/migration-approach.md` — **provisional, pending Priya's objection-turn ruling; treat this whole section as subject to revision until she marks it final**, though the tool name is the only likely change, not the mechanism): a `Job`, not an init container, with `parallelism: 1` and `backoffLimit` set so it doesn't retry indefinitely against a database it's already partially migrated. Runs `goose` (or whatever 05 finalizes) against the migration-runner credential (DDL-only, distinct from the runtime service credential per R4) before the Deployment's rollout proceeds — enforced by a CI/CD pipeline gate (`./ci-pipeline.md` §4), not by Kubernetes ordering alone, because R2's single-runner requirement has to hold across concurrent deploys too, not just within one.
/Users/warrenthompson/Source/LoginID/04-infra-devops/secrets-delivery.md:14:| #4 | API caller `client_secret`s | Not a Kubernetes `Secret` — lives in the authorization server's own datastore (hashed, Argon2id) | Datastore credentials are shaped like row #1, delivered the same way |
/Users/warrenthompson/Source/LoginID/04-infra-devops/secrets-delivery.md:17:| #7 | KEK for envelope encryption | File. Per the hand-off's resolved v2: not a live requirement until TOTP or token-caching actually materializes — provisioned only if/when 05 or 02 confirms one of those features is real. If a KMS is used instead of a mounted key (row #7a), its access credential follows the same delivery discipline as row #2. | `api-service` and/or `idp-connector` SA, whichever feature lands |
/Users/warrenthompson/Source/LoginID/04-infra-devops/secrets-delivery.md:33:No secret in an image layer, build arg, or CI log — enforced by the pipeline's own gitleaks stage (`./ci-pipeline.md` §4) plus the container design never `COPY`ing anything but the compiled binary. CI's own credentials to reach the registry and (in the describe-only deploy stage) the cluster are themselves managed as CI-platform secrets (GitHub Actions encrypted secrets or equivalent) — same discipline, different delivery surface, not re-specified here since it's a standard CI-platform mechanism rather than something this design invents.

{
  "replace_all": false,
  "file_path": "/Users/warrenthompson/Source/LoginID/04-infra-devops/secrets-delivery.md",
  "old_string": "| #9 | End-user vendor password | Nothing to deliver — transient request-body data, never persisted | n/a |",
  "new_string": "| #9 | End-user vendor password | Nothing to deliver — transient request-body data, never persisted | n/a |\n| — | Migration-runner DB credential (05's R4, not in 02's inventory — flagged there as belonging to this surface) | File, same discipline as row #1. **Provisioning differs by backend:** on PostgreSQL specifically this credential needs `CREATE EXTENSION` rights for `pg_trgm` (the trigram index behind `user_profile.name` search) — usually an allow-listed extension on managed Postgres, otherwise elevated privilege; CockroachDB needs nothing extra (trigram indexing is native); SQLite has no privilege model at all. Distinct from the runtime service credential (DML-only, no DDL) per R4 — provisioning one shared credential for both would hand the running service the same extension-install rights the migration job needs, which it has no reason to hold. | Migration `Job`'s own ServiceAccount only |"
}

The file /Users/warrenthompson/Source/LoginID/04-infra-devops/secrets-delivery.md has been updated successfully. (file state is current in your context — no need to Read it back)

{
  "to": "wesley-okonkwo",
  "summary": "Loan turn 2 for Priya — DAO contract",
  "message": "Turn 2 of the same loan, still for Priya. All six migration-approach findings fixed, thanks noted. She'd like you to spend the rest of the loan on her 05→03 DAO contract instead of re-reading the migration doc. Hold for her to send you the file — I'll pass it along when it lands.",
  "type": "message",
  "recipient": "wesley-okonkwo",
  "content": "Turn 2 of the same loan, still for Priya. All six…"
}

{"success":true,"message":"Message sent to wesley-okonkwo's inbox","msg_id":"0ae7f5f7-3684-4cdb-b3fa-e1a2a51cf221","routing":{"sender":"team-lead","target":"@wesley-okonkwo","targetColor":"blue","summary":"Loan turn 2 for Priya — DAO contract","content":"Turn 2 of the same loan, still for Priya. All six…"}}

{
  "to": "data-ops-planning-phase",
  "summary": "Wesley reserved for the DAO contract; credential row added",
  "message": "Passed thanks to Wesley — he's holding his remaining loan turns for the DAO contract cold read, ready whenever you send it my way. Also: your fix note about pg_trgm/CREATE EXTENSION being backend-specific was more than a glossary point on my end too — I didn't have the migration-runner credential broken out as its own row in secrets-delivery.md, just folded into the containerization doc's prose. Added it explicitly now: Postgres-only CREATE EXTENSION rights, CockroachDB none, SQLite no privilege model, kept distinct from the runtime DML-only credential per your R4. Good thing to have surfaced.",
  "type": "message",
  "recipient": "data-ops-planning-phase",
  "content": "Passed thanks to Wesley — he's holding his remain…"
}

{"success":true,"message":"“Wesley reserved for the DAO contract; credential row added” → data-ops-planning-phase (another Claude session on this machine; it is also connected via Remote Control)","msg_id":"d8a9df0b-598f-4a05-bcaa-e03aef4bc630"}

{
  "command": "grep -n -i \"R3\\|fail.closed\\|fails closed\" /Users/warrenthompson/Source/LoginID/04-infra-devops/*.md"
}

(Bash completed with no output)

{
  "file_path": "/Users/warrenthompson/Source/LoginID/04-infra-devops/containerization-design.md",
  "offset": 1,
  "limit": 10
}

1	# Containerization Design
2	
3	Design-only. No Dockerfile, manifest, or config file is being committed yet — per root `CLAUDE.md`, code/config artifacts wait for Warren's project-wide go-ahead. This document describes what would be built, in enough detail that building it is a transcription exercise, not a design exercise.
4	
5	Inputs this depends on: `../PLANNING.md` Service boundaries (03, stable), `../02-ai-security-architecture/handoff-04-secrets.md` v2 (02, stable), `../05-data-ops/migration-approach.md` (05, provisional — noted where it matters).
6	
7	Deployment target: the real Kubernetes dev/lab cluster on Warren's LAN, operated by amber-kubernetes (an external agent, not contacted during this take-home — see `./PLAN.md`). Manifests below are sketched against that cluster's shape, not a generic "some Kubernetes somewhere."
8	
9	## 1. Two images, not one
10	

{
  "replace_all": false,
  "file_path": "/Users/warrenthompson/Source/LoginID/04-infra-devops/containerization-design.md",
  "old_string": "Inputs this depends on: `../PLANNING.md` Service boundaries (03, stable), `../02-ai-security-architecture/handoff-04-secrets.md` v2 (02, stable), `../05-data-ops/migration-approach.md` (05, provisional — noted where it matters).",
  "new_string": "Inputs this depends on: `../PLANNING.md` Service boundaries (03, stable), `../02-ai-security-architecture/handoff-04-secrets.md` v2 (02, stable), `../05-data-ops/migration-approach.md` (05, **final**)."
}

The file /Users/warrenthompson/Source/LoginID/04-infra-devops/containerization-design.md has been updated successfully. (file state is current in your context — no need to Read it back)

{
  "file_path": "/Users/warrenthompson/Source/LoginID/04-infra-devops/containerization-design.md",
  "offset": 40,
  "limit": 45
}

40	      securityContext:
41	        runAsNonRoot: true
42	        readOnlyRootFilesystem: true
43	      containers:
44	        - name: api-service
45	          image: registry.internal/loginid-poc/api-service:<tag>
46	          resources:
47	            requests: {cpu: "100m", memory: "128Mi"}
48	            limits: {cpu: "500m", memory: "256Mi"}
49	          envFrom:
50	            - configMapRef: {name: api-service-config}   # DB_DRIVER, HTTP_ADDR, AUTH_JWT_ISSUER/AUDIENCE — non-secret
51	          env:
52	            - {name: DB_DSN_FILE, value: /secrets/db/dsn}
53	          volumeMounts:
54	            - {name: db-dsn, mountPath: /secrets/db, readOnly: true}
55	            - {name: jwt-signing-key, mountPath: /secrets/jwt, readOnly: true}
56	          readinessProbe: {httpGet: {path: /healthz, port: 8080}, initialDelaySeconds: 5}
57	          livenessProbe: {httpGet: {path: /healthz, port: 8080}, initialDelaySeconds: 10}
58	      volumes:
59	        - name: db-dsn
60	          secret: {secretName: api-service-db-dsn}
61	        - name: jwt-signing-key
62	          secret: {secretName: api-service-jwt-signing-key}
63	---
64	apiVersion: v1
65	kind: Service
66	metadata: {name: api-service}
67	spec:
68	  selector: {app: api-service}
69	  ports: [{port: 443, targetPort: 8080}]
70	```
71	
72	`idp-connector`'s manifest is the same shape with its own two `Secret` volume mounts (per-vendor client credentials, one `Secret` per vendor per handoff row #5), its own `resources` block (`idp-connector` is I/O-bound waiting on vendor calls, not CPU-heavy — requests `{cpu: 50m, memory: 64Mi}`, limits `{cpu: 250m, memory: 128Mi}`), and no inbound `Service` — it is called by `api-service` or invoked as a job, never exposed to anything outside the cluster. Exact invocation shape (long-running service vs. on-demand job) is undecided; either way the container/image design above doesn't change.
73	
74	**On process vs. host isolation (per 03/Renata, `../PLANNING.md`):** the two-binary split is a process boundary, not a placement guarantee — the `resources.limits` above are what actually enforce it if both Pods land on the same node, on top of (not instead of) 03's own connector-side backpressure (`context.WithTimeout`, bounded retry/backoff, their S4).
75	
76	## 4. Migration job
77	
78	Per 05's requirement R1/R2 (`../05-data-ops/migration-approach.md` — **provisional, pending Priya's objection-turn ruling; treat this whole section as subject to revision until she marks it final**, though the tool name is the only likely change, not the mechanism): a `Job`, not an init container, with `parallelism: 1` and `backoffLimit` set so it doesn't retry indefinitely against a database it's already partially migrated. Runs `goose` (or whatever 05 finalizes) against the migration-runner credential (DDL-only, distinct from the runtime service credential per R4) before the Deployment's rollout proceeds — enforced by a CI/CD pipeline gate (`./ci-pipeline.md` §4), not by Kubernetes ordering alone, because R2's single-runner requirement has to hold across concurrent deploys too, not just within one.
79	
80	## 5. NetworkPolicy: adopted, not cut
81	
82	Considered and dropped from an earlier pass as scope creep, then reconsidered: §3's claim that `idp-connector` is isolated because it never gets an inbound `Service` is a paper boundary without one. Anything else on the namespace's default-allow network can still reach it directly and skip `api-service`'s auth path entirely — which undermines the exact "different threat models" reasoning 02 gave for splitting the images in the first place. A minimal default-deny `NetworkPolicy` for the `idp-connector` Pod, with one explicit `ingress` rule allowing traffic only from `api-service`'s pod selector, is ~15 lines and one more manifest to keep in sync — cheap relative to what it closes. Included below; everything else in this section stays cut.
83	
84	```yaml

{
  "replace_all": false,
  "file_path": "/Users/warrenthompson/Source/LoginID/04-infra-devops/containerization-design.md",
  "old_string": "## 4. Migration job\n\nPer 05's requirement R1/R2 (`../05-data-ops/migration-approach.md` — **provisional, pending Priya's objection-turn ruling; treat this whole section as subject to revision until she marks it final**, though the tool name is the only likely change, not the mechanism): a `Job`, not an init container, with `parallelism: 1` and `backoffLimit` set so it doesn't retry indefinitely against a database it's already partially migrated. Runs `goose` (or whatever 05 finalizes) against the migration-runner credential (DDL-only, distinct from the runtime service credential per R4) before the Deployment's rollout proceeds — enforced by a CI/CD pipeline gate (`./ci-pipeline.md` §4), not by Kubernetes ordering alone, because R2's single-runner requirement has to hold across concurrent deploys too, not just within one.",
  "new_string": "## 4. Migration job\n\nPer 05's requirement R1/R2 (`../05-data-ops/migration-approach.md`, **final**): a `Job`, not an init container, with `parallelism: 1` and `backoffLimit` set so it doesn't retry indefinitely against a database it's already partially migrated. Runs `goose` against the migration-runner credential (DDL-only, distinct from the runtime service credential per R4 — and, on PostgreSQL specifically, needing `CREATE EXTENSION` rights for `pg_trgm` that the runtime credential must never hold, per `./secrets-delivery.md`) before the Deployment's rollout proceeds — enforced by a CI/CD pipeline gate (`./ci-pipeline.md` §4), not by Kubernetes ordering alone, because R2's single-runner requirement has to hold across concurrent deploys too, not just within one.\n\nR2's mechanism is orchestration-layer exclusivity (a concurrency-gated pipeline stage, `./ci-pipeline.md` §4), not a database lock — final reasoning: a transaction-scoped lock (`pg_advisory_xact_lock`, CockroachDB-compatible) releases between `goose`'s per-file transactions, so a second runner could interleave mid-run even with one held; a session-scoped lock would span the whole run but CockroachDB doesn't support that scope. No single database mechanism covers both the right scope and the right engine, so the exclusivity has to live outside the database entirely, on every backend, not just CockroachDB. 05 also names a cheap backstop — a unique constraint on `goose`'s version-table `version_id` column, added in the first migration regardless of whether goose's default schema already has one — so a second runner that does slip through fails loudly on insert instead of interleaving silently. That's a migration-file change (03/05's to make), not something 04 builds, but it's worth naming here since it's the backstop behind this job's own exclusivity design, not a replacement for it.\n\n**Fail-closed schema check (R3, final):** the readiness probe below isn't just a liveness ping — `api-service` must refuse to serve if either of goose's two version tables (`shared/` and its backend-specific directory, per `migration-approach.md` §2's two-invocation mechanism) is behind the version the binary was built against. A check against only one table can pass while the other is stale — e.g. `shared/` current but the Postgres-only `pg_trgm` index migration unapplied — which is a passing check that proves nothing. `/healthz` above is liveness only; a separate `/readyz` (or the same endpoint gated by both checks) is where this lives, wired to whatever version-embedding mechanism 03 picks (build-time constant vs. reading the shipped migration files) — the check comparing *both* tables is 04's requirement to build against; the embedding mechanism is 03's call."
}

The file /Users/warrenthompson/Source/LoginID/04-infra-devops/containerization-design.md has been updated successfully. (file state is current in your context — no need to Read it back)

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

1	# CI/CD Pipeline Design
2	
3	Design-only — a description of what would run, not a committed workflow file. Targets a generic CI platform (GitHub Actions shape, since the repo is on GitHub) but nothing here is Actions-specific beyond syntax.
4	
5	## Stages, in order, on every PR
6	
7	1. **Build.** `go build ./...` for both `cmd/api-service` and `cmd/idp-connector`, against the module's declared Go version. Fails fast — nothing downstream runs against code that doesn't compile.
8	2. **Lint.** `golangci-lint run` (staticcheck, govet, unused, errcheck at minimum). Non-negotiable gate, not advisory — a lint failure blocks merge, same as a test failure.
9	3. **Test.** `go test ./... -race` — unit tests against 03's `internal/dao` per-backend implementations: SQLite in-process for the fast path, plus **two** testcontainer jobs against the shared `postgres` package — one on Postgres, one on CockroachDB. Considered running CockroachDB only in the local dev-loop (wire-compatible enough with Postgres that testing both looked redundant) and reconsidered for CI specifically: wire-compatible isn't schema-compatible, and a Postgres-only test matrix means a CockroachDB-specific SQL quirk (UUID defaults, upsert syntax, lock semantics) surfaces at deploy time instead of at PR time. CockroachDB ships an official single-node Docker image, so this is a config addition to the test job, not new infrastructure — a few extra minutes of CI wall-clock for catching it at the cheapest possible point. `-race` is not optional given two DB implementations and a migration-runner exclusivity requirement (05's R2) that's exactly the kind of thing a race detector catches in test even though it's enforced by orchestration in production.
10	4. **Security scan.** Two checks, both fast enough to run on every PR:
11	   - `govulncheck ./...` — known-CVE dependency scan.
12	   - `gitleaks` (or equivalent secret-pattern scanner) over the diff — a second line of defense behind "secrets never enter source" (per 02's never-log/never-commit discipline), not a replacement for it.
13	5. **Build images.** Both Dockerfiles (`./containerization-design.md` §2) built and tagged with the commit SHA. Not pushed yet on a PR build — build-only, to catch a broken multi-stage build before merge.
14	
15	## On merge to main
16	
17	6. **Push images** to the registry, tagged with SHA and `latest` (or a semver tag if the project adopts one — not decided, not needed for a take-home).
18	7. **Run migration job** — describe-only in this design, and **provisional pending 05's objection-turn ruling on `migration-approach.md`**: the pipeline would invoke whatever 05 finalizes (`goose` per current draft) against the migration-runner credential, gated so only one pipeline run at a time can reach this stage (05's R2, strengthened per Priya's correction: CockroachDB's `pg_try_advisory_lock` variants silently no-op — a second runner reads back as if it acquired the lock rather than erroring — so a DB-advisory-lock guard isn't just unavailable, it's actively unsafe to rely on here; a concurrency group / mutex on the pipeline's own deploy environment is the only exclusivity mechanism this design uses, and it doesn't touch the database at all).
19	8. **Deploy — describe-only, not executed.** A named final stage: "apply manifests to the lab cluster via amber-kubernetes." This step is documented as what *would* run — which manifests, which namespace, which credential applies them — but is never actually invoked during this take-home, consistent with the deployment-target note in `./PLAN.md`. If a real deploy is ever wanted, this is the stage that gets un-stubbed, not redesigned.
20	
21	## What's deliberately not in this pipeline
22	
23	No canary/blue-green deploy strategy, no multi-environment promotion pipeline (dev → staging → prod), no automated rollback orchestration beyond "the migration job's `backoffLimit` and the Deployment's own rollout history." A take-home doesn't need a release engineering platform; it needs to show the shape of one.
24	
25	---
26	*AI tooling note: drafted directly by Theo (Sonnet, this session) from 03's test-strategy outline and the containerization design above. Bree's and Callum's per-deliverable notes pending.*
27	

{
  "replace_all": false,
  "file_path": "/Users/warrenthompson/Source/LoginID/04-infra-devops/ci-pipeline.md",
  "old_string": "7. **Run migration job** — describe-only in this design, and **provisional pending 05's objection-turn ruling on `migration-approach.md`**: the pipeline would invoke whatever 05 finalizes (`goose` per current draft) against the migration-runner credential, gated so only one pipeline run at a time can reach this stage (05's R2, strengthened per Priya's correction: CockroachDB's `pg_try_advisory_lock` variants silently no-op — a second runner reads back as if it acquired the lock rather than erroring — so a DB-advisory-lock guard isn't just unavailable, it's actively unsafe to rely on here; a concurrency group / mutex on the pipeline's own deploy environment is the only exclusivity mechanism this design uses, and it doesn't touch the database at all).",
  "new_string": "7. **Run migration job** — describe-only in this design, per `../05-data-ops/migration-approach.md`, **final**: the pipeline invokes `goose` against the migration-runner credential, gated so only one pipeline run at a time can reach this stage. Final reasoning (05's R2, corrected from an earlier draft): CockroachDB's `pg_try_advisory_lock` variants silently no-op rather than erroring, but even a working lock scope doesn't solve this — a transaction-scoped lock (the only kind CockroachDB supports) releases between `goose`'s per-file transactions, letting a second runner interleave mid-run, while a session-scoped lock that would span the run isn't available on CockroachDB at all. No database mechanism covers both the right scope and the right engine, so exclusivity lives entirely outside the database: a concurrency group / mutex on the pipeline's own deploy environment. Note `goose fix` (§1 of the migration doc) is a pre-first-application step, not a pre-tag tidy-up — irrelevant to this pipeline's own stages but worth remembering if a `make` target ever wraps it."
}

The file /Users/warrenthompson/Source/LoginID/04-infra-devops/ci-pipeline.md has been updated successfully. (file state is current in your context — no need to Read it back)

{
  "command": "grep -n \"notes pending\" /Users/warrenthompson/Source/LoginID/04-infra-devops/*.md"
}

/Users/warrenthompson/Source/LoginID/04-infra-devops/ci-pipeline.md:26:*AI tooling note: drafted directly by Theo (Sonnet, this session) from 03's test-strategy outline and the containerization design above. Bree's and Callum's per-deliverable notes pending.*
/Users/warrenthompson/Source/LoginID/04-infra-devops/local-dev-loop.md:65:*AI tooling note: drafted directly by Theo (Sonnet, this session) from 03's config surface and the containerization design above. Bree's and Callum's per-deliverable notes pending.*
/Users/warrenthompson/Source/LoginID/04-infra-devops/observability.md:38:*AI tooling note: drafted directly by Theo (Sonnet, this session) from `handoff-04-secrets.md` v2's never-log list. Bree's and Callum's per-deliverable notes pending.*
/Users/warrenthompson/Source/LoginID/04-infra-devops/secrets-delivery.md:37:*AI tooling note: drafted directly by Theo (Sonnet, this session) from `handoff-04-secrets.md` v2. Bree's and Callum's per-deliverable notes pending.*

{
  "command": "cd /Users/warrenthompson/Source/LoginID/04-infra-devops\nfor f in ci-pipeline.md local-dev-loop.md observability.md secrets-delivery.md; do\n  perl -0pi -e \"s/Bree's and Callum's per-deliverable notes pending\\./Bree's (capability-case) and Callum's (scope-cut) per-deliverable notes reviewed and folded in inline above, per PLAN.md §3./\" \"$f\"\ndone\ngrep -n \"reviewed and folded\" *.md"
}

local-dev-loop.md:65:*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.*
ci-pipeline.md:26:*AI tooling note: drafted directly by Theo (Sonnet, this session) from 03's test-strategy outline 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.*
secrets-delivery.md:37:*AI tooling note: drafted directly by Theo (Sonnet, this session) from `handoff-04-secrets.md` v2. Bree's (capability-case) and Callum's (scope-cut) per-deliverable notes reviewed and folded in inline above, per PLAN.md §3.*
observability.md:38:*AI tooling note: drafted directly by Theo (Sonnet, this session) from `handoff-04-secrets.md` v2's never-log list. Bree's (capability-case) and Callum's (scope-cut) per-deliverable notes reviewed and folded in inline above, per PLAN.md §3.*

{
  "replace_all": false,
  "file_path": "/Users/warrenthompson/Source/LoginID/04-infra-devops/observability.md",
  "old_string": "## What's deliberately not here",
  "new_string": "## Retention-sweep observability (05's S5 requirement, final)\n\nPer `../05-data-ops/pii-governance.md`: the retention sweep must emit, per data class per run, three metrics — rows examined, rows deleted, and **the age of the oldest surviving row in that class**. An alert fires when that age exceeds the class's stated retention window plus one sweep interval. This is the one metric in this document tied to a specific reasoning worth repeating: a sweep job that silently stops running produces no error and no symptom on its own — \"rows deleted\" can't tell a broken sweep from a legitimately empty one, since both report zero. Oldest-surviving-row age is the one number that keeps climbing when the job is dead and holds steady when it's healthy, which is why it's the alerting signal, not just a nice-to-have metric alongside the other two.\n\nMechanism: the sweep job (whatever invokes it — a CronJob against the lab cluster, per 05's mechanism-agnostic requirement) emits these as Prometheus metrics with a `class` label (one label value per retention class, e.g. `vendor_token_cache`, `idp_identity_cache` — never a label carrying the PII itself, same discipline as the RED-metrics rule above) rather than only a log line, since a log line nobody's alerting on has the same \"silent failure\" problem the requirement exists to solve. The alert rule is `oldest_surviving_row_age_seconds{class=\"X\"} > (retention_window_seconds + sweep_interval_seconds)`, evaluated per class.\n\n## What's deliberately not here"
}

The file /Users/warrenthompson/Source/LoginID/04-infra-devops/observability.md has been updated successfully. (file state is current in your context — no need to Read it back)

{
  "to": "data-ops-planning-phase",
  "summary": "All final-version changes folded in",
  "message": "Dropped \"provisional\" everywhere, marked migration-approach.md final in both files. Folded in:\n- Corrected R2 reasoning (transaction-scope-vs-engine-coverage tradeoff, not just \"no advisory locks\") in ci-pipeline.md and containerization-design.md.\n- Named the version_id unique-constraint backstop in containerization-design.md's migration job section (flagged as 03/05's migration-file change, not mine, but worth citing next to my exclusivity mechanism).\n- Added the R3 fail-closed check as its own paragraph — both version tables, not one, tied to a /readyz distinct from /healthz.\n- Added the migration-runner credential's CREATE EXTENSION/pg_trgm provisioning detail already, now cross-referenced from the migration-job section too.\n- New: retention-sweep observability in observability.md — rows examined/deleted/oldest-surviving-row-age as Prometheus metrics with a per-class label, alert on oldest-row-age exceeding window+interval, with your \"silent failure\" reasoning stated as the reason it's the alerting signal and not just a log line.\n\nThanks for running this all the way through — the corrections landed clean.",
  "type": "message",
  "recipient": "data-ops-planning-phase",
  "content": "Dropped \"provisional\" everywhere, marked migratio…"
}

{"success":true,"message":"“All final-version changes folded in” → data-ops-planning-phase (another Claude session on this machine)","msg_id":"83e506c5-aa2d-41c5-a831-d4fc259de949"}

{
  "to": "org-planning-loginid-takehome",
  "summary": "04 deliverables updated to final migration-approach.md",
  "message": "05's migration-approach.md went final; all three \"provisional\" markers in 04's deliverables are gone. Folded in the corrected R2 reasoning, the R3 fail-closed check (both version tables, not one — was a real gap in my earlier draft), the migration-runner credential's Postgres-only CREATE EXTENSION detail, and a new retention-sweep observability requirement from 05's S5 (rows examined/deleted/oldest-surviving-row-age metrics with alerting). All five deliverables current. Team still staged for the consistency pass.",
  "type": "message",
  "recipient": "org-planning-loginid-takehome",
  "content": "05's migration-approach.md went final; all three …"
}

{"success":true,"message":"“04 deliverables updated to final migration-approach.md” → org-planning-loginid-takehome (another Claude session on this machine)","msg_id":"d7e575ab-18a8-4e9e-afbe-68460461a83f"}

{
  "command": "grep -n -A80 \"^## Phase 4\" /Users/warrenthompson/Source/LoginID/PLAN.md | head -120"
}

(Bash completed with no output)

{
  "command": "grep -n -i \"phase 4\\|phase4\" /Users/warrenthompson/Source/LoginID/PLAN.md"
}

145:### Phase 4 — Jira (Warren's go: 2026-09-12, "start building out the backlog")
163:- Phase 4: one Epic per track and stories under them visible on the LT board.

{
  "file_path": "/Users/warrenthompson/Source/LoginID/PLAN.md",
  "offset": 140,
  "limit": 45
}

140	9. **Retention and deletion** — `05/pii-governance.md` S5 numbers and deletion-job contract vs. `04/observability.md` (logs must not outlive the data) vs. `02/threat-model.md` assumptions.
141	10. **Narrative claims** — `02/ai-workflow-narrative.md` vs. `LOG.md` and the `decisions/` files it cites: every claimed outcome must point at a file that says what the narrative says it says; null results reported, not only hits.
142	11. **Root files** — root `CLAUDE.md` Status, `PLANNING.md` rows, `CASTING.md` registry (18 rows, portraits `done`), `PLAN.md` phases vs. reality; `grep -c profile-gen:start` totals 6; no code artifacts anywhere.
143	12. **Cross-cutting — enforcement sites** (principle from 05's S2, `05/decisions/search-query-shape.md`): for every caller-visible guarantee stated in any hand-off (`02/handoff-03-auth.md`, `02/handoff-04-secrets.md`, `05/multi-db-strategy.md` S1, `PLANNING.md` Service boundaries), name the enforcement site — DDL constraint, index, normalization step, conformance test, middleware check, CI job. A guarantee with no named site is listed as a *gap*, owned by the hand-off's author.
144	
145	### Phase 4 — Jira (Warren's go: 2026-09-12, "start building out the backlog")
146	
147	Team-lead is the single Jira writer (one authenticated session, one audit trail); leads author. Each lead writes `<track-dir>/backlog.md` — the in-repo, versioned backlog, which is itself a submission artifact — and team-lead transcribes it into project `LT` (cloudId `db488eae-d6cb-4100-92a9-e7a4519fc176`) and writes the issue keys back into the file.
148	
149	`backlog.md` format, identical for every track:
150	- Header: track, lead, Epic title (team-lead creates one Epic per track; the key is written back here).
151	- One section per Story, in dependency order: **Title** (imperative, ≤ 80 chars); **Description** (what and why, 3–8 sentences, citing the deliverable and decision files by relative path); **Acceptance criteria** as a checklist — the first criterion is always the hand-off standard ("the receiving track can act on this without re-deriving the reasoning"), and every caller-visible guarantee names its enforcement site; **Depends on** (other tracks' story titles, which become Jira "blocks/is blocked by" links); **Model/effort** recommended for implementation (from `planning-approach.md`); **Type** Story or Task; **Labels** (`track-0N`, plus `security-graded` where 02's second-review rule applies, `no-code-yet` until Warren's code go).
152	- Stories arising from the consistency pass are added under whichever track owns the fix, with a `from-consistency-pass` label; a jointly owned story (e.g., the derived-data deletion gap across 02/04/05) is created once under the track that owns the enforcement site, with the other two linked as dependencies.
153	
154	Order: 01 authors and is transcribed immediately (closed first, least touched by the pass); 05 has stories ready and follows; 02/03/04 author now and are transcribed the moment the consistency pass reports, so pass-driven revisions land once. Implementation still waits for Warren's explicit code go-ahead; "backlog strong enough to start implementation" is team-lead's call to Warren, defined as: every track's stories transcribed, every cross-track dependency linked, every pass finding either resolved or carried as a story, and 03's implementation stories each pointing at a stable contract.
155	
156	## Verification
157	
158	- Phase 0: `PLAN.md`, `LOG.md` (backfilled), `PLANNING.md`, `CASTING.md`, `.gitignore` exist at root; `.claude/AGENT_TEMPLATE.md` exists; root `CLAUDE.md` Status updated; `git log` shows the Phase 0 milestone commit; `find . -name '*.go' -o -name '*.sql' -o -name 'go.mod'` still returns nothing.
159	- Every later phase: `LOG.md` has an entry and `git log` has a milestone commit for it; `diff ~/.claude/plans/cuddly-nibbling-cherny.md PLAN.md` is empty or `PLAN.md` is newer.
160	- Phase 1: five `plan_approval_request`s received and answered; each approved plan has all four mandatory sections; every roster passes the variance rules when read together (no archetype > 2×, each team has its lead's opposite, no duplicate archetype-per-function across teams); total hires ≤ cap.
161	- Phase 2: for every registry row, `<track>/profiles/<slug>/<slug>.md` exists with a `## Personality` section containing history and technical background, `.claude/agents/<slug>.md` exists with model/effort frontmatter; `grep -c "profile-gen:start" */CLAUDE.md CLAUDE.md` still totals 6 (no hire markers); each hire's pane status bar shows its own track directory and its own persona name (tmux `capture-pane` check, as done for the leads); `portrait-queue.sh` log shows serialized progress.
162	- Phase 3: each planned pattern produced its decision artifact file; `PLANNING.md` rows all read "plan approved"; consistency-pass report delivered.
163	- Phase 4: one Epic per track and stories under them visible on the LT board.
164	
165	## Decisions confirmed with Warren before execution
166	
167	- Hire sizing: **confirmed by Warren** — the larger org, 3–4 per track, 18 total, hard cap 18.
168	- Portraits: **confirmed by Warren** — text-first personas for all hires, portraits for all 18 via the serialized background queue (18 renders at 2–10 min each on the shared box ≈ 1–3 hours, overlapping the planning debates; personas display name-only until each lands).
169	- Effort: implemented as inherit-high plus `haiku → low` via project `.claude/settings.json`, since the harness has no per-agent effort key.
170	- tmux: leads stay in window 2 (the 3×2 grid); when hires appear, team-lead moves each team's hires into a new tmux window named for the track (`01-product`, `02-security`, …) so no window exceeds ~6 panes. Team-lead owns layout.
171	

{
  "file_path": "/Users/warrenthompson/Source/LoginID/04-infra-devops/backlog.md",
  "content": "# Track 04 — Infra & DevOps Backlog\n\nTrack: 04-infra-devops. Lead: Theo Bergman. Epic: \"Infra & DevOps: Containerization, CI/CD, and Operations\" (key: TBD, team-lead fills in on transcription).\n\nAuthored 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.\n\n## Story 1 — Containerize `api-service` and `idp-connector`\n\n**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), and a default-deny `NetworkPolicy` on `idp-connector` so its \"no inbound Service\" isolation claim actually holds against the namespace's default-allow network.\n\n**Acceptance criteria:**\n- [ ] The receiving track (whoever implements/reviews this) can act on the manifests without re-deriving the reasoning in `containerization-design.md`.\n- [ ] 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.\n- [ ] Neither Pod can write to its own root filesystem at runtime — enforcement site: `securityContext.readOnlyRootFilesystem: true`.\n- [ ] `idp-connector` is unreachable except from `api-service` — enforcement site: the `NetworkPolicy` ingress rule scoped to `api-service`'s pod selector.\n- [ ] A stuck `idp-connector` cannot starve `api-service` if colocated on one node — enforcement site: `resources.limits` on both Pod specs.\n- [ ] 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.\n\n**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`).\n\n**Model/effort:** Sonnet, medium.\n\n**Type:** Story.\n\n**Labels:** `track-04`, `no-code-yet`.\n\n## Story 2 — Deliver secrets to both services per 02's inventory\n\n**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).\n\n**Acceptance criteria:**\n- [ ] 02 (the hand-off's author) confirms this implementation matches `handoff-04-secrets.md` v2's inventory without needing to re-explain any row.\n- [ ] 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).\n- [ ] No ServiceAccount can `get`/`list` a `Secret` it doesn't mount — enforcement site: per-service `Role`/`RoleBinding` scoped to named `Secret`s.\n- [ ] 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.\n- [ ] `Secret` resources are encrypted at rest in etcd — enforcement site: cluster `EncryptionConfiguration`.\n\n**Depends on:** 02 — `handoff-04-secrets.md` (received, v2, final); 05 — `migration-approach.md` R4 (final).\n\n**Model/effort:** Sonnet, medium.\n\n**Type:** Story.\n\n**Labels:** `track-04`, `security-graded`, `no-code-yet`.\n\n## Story 3 — CI/CD pipeline: build, lint, test, scan, migrate, describe-only deploy\n\n**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).\n\n**Acceptance criteria:**\n- [ ] A developer or reviewer can act on this pipeline description without re-deriving why each stage exists.\n- [ ] A lint or test failure blocks merge — enforcement site: required-status-check on the PR, not advisory.\n- [ ] A CockroachDB-specific SQL incompatibility surfaces at PR time, not deploy time — enforcement site: the dedicated CockroachDB testcontainer job.\n- [ ] 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.\n- [ ] No secret enters a build log or image layer — enforcement site: `gitleaks` stage plus the Dockerfile's minimal `COPY` list (Story 1).\n- [ ] 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.\n\n**Depends on:** 03 — test-strategy outline for `go test ./...` to run against; 05 — `migration-approach.md` (final).\n\n**Model/effort:** Sonnet, medium.\n\n**Type:** Story.\n\n**Labels:** `track-04`, `no-code-yet`.\n\n## Story 4 — Local dev-loop: compose profiles for SQLite and Postgres\n\n**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).\n\n**Acceptance criteria:**\n- [ ] A new developer can run either profile from this file alone, without asking what `DB_DRIVER` values are valid.\n- [ ] The `postgres` profile exercises the shared `postgres`-package code path (Postgres + CockroachDB) — enforcement site: compose service definition wiring `DB_DRIVER=postgres`.\n- [ ] 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).\n- [ ] 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.\n\n**Depends on:** 03 — `DB_DRIVER`/config-surface env vars (already stable, per `PLANNING.md`).\n\n**Model/effort:** Sonnet, low.\n\n**Type:** Story.\n\n**Labels:** `track-04`, `no-code-yet`.\n\n## Story 5 — Observability: logging, metrics, never-log enforcement, retention-sweep alerting\n\n**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.\n\n**Acceptance criteria:**\n- [ ] 02 confirms the never-log list (`handoff-04-secrets.md`'s nine items) is fully covered by a named enforcement site, not just a policy statement.\n- [ ] No password, token, JWT, client secret, or DSN reaches a log call — enforcement site: explicit-field logging discipline plus the CI lint check.\n- [ ] Search-endpoint name/phone query fragments never appear in ingress access logs — enforcement site: ingress log-format override / redaction.\n- [ ] Audit-log read access is a distinct RBAC grant from Secret-read access — enforcement site: separate `Role` bound to an incident-review group.\n- [ ] 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.\n\n**Depends on:** 02 — `handoff-04-secrets.md`'s never-log list (final); 05 — `pii-governance.md` S5 retention numbers and data-class names (final).\n\n**Model/effort:** Sonnet, medium.\n\n**Type:** Story.\n\n**Labels:** `track-04`, `security-graded`, `no-code-yet`.\n\n## Story 6 — Derived-data deletion / log-retention enforcement (placeholder, pending consistency pass)\n\n**Description:** Placeholder for the enforcement site of \"logs and any derived/cached data must not outlive the data they're derived from\" — the interaction the consistency pass is explicitly checking (`PLAN.md` \"Retention and deletion\": `05/pii-governance.md` S5 numbers and deletion-job contract vs. `04/observability.md` vs. `02/threat-model.md` assumptions). 04 is the presumptive owner of the enforcement site if the pass confirms it's a log-retention/observability-pipeline mechanism (e.g., a log-sink retention policy matching 05's window, not a separate deletion job) rather than a DAO-level or connector-level mechanism. Not filled in beyond this placeholder until the pass reports, per team-lead's instruction — this story exists so the gap is tracked now rather than discovered after transcription.\n\n**Acceptance criteria:**\n- [ ] Left open pending the consistency pass's ruling on which track owns the enforcement site.\n\n**Depends on:** 02 — `threat-model.md` assumptions about derived-data lifetime; 05 — `pii-governance.md` S5 deletion-job contract and retention numbers.\n\n**Model/effort:** TBD, pending scope.\n\n**Type:** Story.\n\n**Labels:** `track-04`, `from-consistency-pass`, `no-code-yet`.\n"
}

File created successfully at: /Users/warrenthompson/Source/LoginID/04-infra-devops/backlog.md (file state is current in your context — no need to Read it back)

{
  "to": "org-planning-loginid-takehome",
  "summary": "04's backlog.md written",
  "message": "`04-infra-devops/backlog.md` written: 6 stories in dependency order (containerization → secrets delivery → CI pipeline → local dev-loop → observability → derived-data deletion placeholder). Retention-sweep alerting is in Story 5's acceptance criteria; the migration-runner CREATE EXTENSION detail is in Story 2's. Story 6 is left as a genuine placeholder — I named it as 04's presumptive ownership if the pass confirms the enforcement site is log/observability-pipeline-shaped, but didn't fill in acceptance criteria beyond \"pending the pass's ruling,\" since I don't want to write criteria for a scope I don't own yet. Every guarantee across Stories 1-5 names its enforcement site per the cross-cutting rule. All stories carry `no-code-yet`; Story 2 and 5 also carry `security-graded`. Ready for transcription whenever you get to 04 in the order.",
  "type": "message",
  "recipient": "org-planning-loginid-takehome",
  "content": "`04-infra-devops/backlog.md` written: 6 stories i…"
}

{"success":true,"message":"“04's backlog.md written” → org-planning-loginid-takehome (another Claude session on this machine)","msg_id":"57a2ec04-9f09-4602-a431-3223e5eb09b7"}

{
  "command": "grep -n \"^##\\|^### F\\|04-infra\\|04's\\|Theo\" /Users/warrenthompson/Source/LoginID/decisions/cross-track-consistency.md | head -100"
}

3:Run 2026-09-12 as a fresh Fable session with no accumulated context, against the 12-seam checklist in `PLAN.md` ("Consistency-pass checklist") plus the four items handed over by the 05 lead. Only finished deliverables were read; no existing file was modified. Line numbers are from the files as they stood at the start of the pass (the working tree changed underneath the pass — see Mechanical checks). Owning leads: 01 Naomi Voss, 02 Marcus Ilori, 03 Renata Cole, 04 Theo Bergman, 05 Priya Nandakumar; root files Dana Whitfield.
5:## Executive summary
15:## Seam 1 — `/identity` response and `/auth` request shapes — CONTRADICTION
23:## Seam 2 — Authorization scopes and their semantics — CONTRADICTION
39:## Seam 3 — Config surface and secrets — CONTRADICTION
43:**F12 (contradiction — version label).** `handoff-04-secrets.md:3` reads "Status: **v1** … Awaiting 04's Newcomer (`wesley-okonkwo`) cold read." The cold read happened and its fixes are in the file (`04/decisions/newcomer-coldread-boundaries-secrets.md:36-39`); 04 cites "v2" in `secrets-delivery.md:3,37`, `observability.md:44`, `containerization-design.md:5`, and `newcomer-coldread-boundaries-secrets.md:43`; `PLAN.md:134` and `02/CLAUDE.md:51` say v1. One document, three labels. Owner: Marcus. Fix: update the Status line to v2 and remove "Awaiting".
45:**F13 (contradiction — signing-key custody).** `handoff-04-secrets.md:17` row 2: "Used by: Token-issuing authorization-server component only — **not** `api-service`". Same document, Assumption 2 (`:8`): "The token-issuing authorization-server function is a mode of `api-service`, not a third binary … RBAC … restricted (via a distinct Kubernetes Role, not a separate ServiceAccount) so that only the issuing code path — not the token-verification code path in the same binary — can `get` the signing-key Secret." `handoff-03-auth.md:20` compresses the contradiction into one sentence: "The private signing key never touches `api-service`; it lives with the token-issuing function, which is a mode of `api-service`." 04 then implements the only thing the manifest can do: mounts `api-service-jwt-signing-key` at `/secrets/jwt` into the `api-service` container of a two-replica Deployment (`containerization-design.md:39,55,61-62`) — every replica, verification path included. A Role restricting `get` on a Secret has no effect on a volume mount; the file is readable by the whole process. `secrets-delivery.md:24` concedes the requirement "in practice means either a second SA for the issuer mode or a sidecar/init-container pattern", which the manifest does not do. Owner: Marcus for the requirement (the manifest follows it). Smallest fix, one document first (`handoff-04-secrets.md` Assumption 2 and row 2): the issuer runs as a separate Deployment of the same `api-service` image, selected by an environment variable 03 adds to the config surface (the surface allows no flags — `PLANNING.md:46`), with its own ServiceAccount that alone mounts the signing key; the `api-service` Deployment mounts nothing but the DSN. Then Theo removes the mount at `containerization-design.md:55,61-62` and adds the issuer Deployment.
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.
51:## Seam 4 — Connector token lifecycle — CONTRADICTION
55:**F17 (contradiction — stale references to a cache that no longer exists).** After the S3 ruling, these still describe a cached token: «REDACTED» row 7 says the red/blue is "(in progress)" and caching is the "current direction"; `:52` says the connector "may [cache], under the conditions in #6"; `secrets-delivery.md:16` "If cached, encrypted with #7's KEK"; `03/PLAN.md:23` consumes "token lifecycle: TTL, storage, refresh, never-persist-in-plaintext"; `03/decisions/context-propagation.md:23` names "any token-persistence write" as a detach point; the go-layout diagram lists "token lifecycle (TTL/refresh/no-plaintext-persist)" (`go-layout-debate.md:45-49`); and `04/observability.md:37` invents a retention class `vendor_token_cache`. None is load-bearing, but each tells a reader the opposite of the ruling. Owners: Marcus (`handoff-04-secrets.md:22,52`), Renata (`03/PLAN.md:23`, `context-propagation.md:23`), Theo (`observability.md:37`, `secrets-delivery.md:16`). Fix: one-line edits; the primary is `handoff-04-secrets.md` row 7 and "What 04 does not decide", which is the hand-off 04 built from. F3 (seam 1) is the substantive lifecycle contradiction and is not repeated here.
57:## Seam 5 — DAO contract — CONTRADICTION
73:## Seam 6 — Multi-DB behavior — GAP
75:**F24 (agree).** The engine-aware retry seam (`multi-db-strategy.md:319-331`; `research-cockroachdb-postgres-semantics.md:11`), the `LIKE` case-folding fix (`multi-db-strategy.md:37,208`; `decisions/multi-db-abstraction.md:27`), and 04's CI matrix — SQLite in-process plus separate Postgres and CockroachDB testcontainer jobs (`04/ci-pipeline.md:9`) — are mutually consistent. CI does run against every backend including CockroachDB.
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".
81:**F27 (minor — false claim).** `ci-pipeline.md:9` says `-race` catches "a migration-runner exclusivity requirement (05's R2)". The Go race detector is intra-process; R2 concerns two runner processes. Owner: Theo. Fix: delete the clause.
83:## Seam 7 — Migrations — CONTRADICTION
85:**F28 (contradiction — 05 internal, propagated to 04).** `migration-approach.md:24`, marked "final" (`:7`), says `shared/` "carries `auth_method`, `user_profile`, `user_credential`, `deletion_log` … and the `auth_method` seed row", with `postgres/` holding exactly one file. The field-level schema it must implement gives every table per-engine DDL: `UUID DEFAULT gen_random_uuid()` vs `TEXT` (`multi-db-strategy.md:341`), `TEXT COLLATE "C"` vs `TEXT COLLATE BINARY` (`:342`), a regex `CHECK` vs a `GLOB` `CHECK` (`:343`), `TIMESTAMPTZ` vs `TEXT` (`:350`), `BYTEA` vs `BLOB` (`:363`), `BOOLEAN` vs `INTEGER` (`:388`). A single shared `CREATE TABLE` series cannot express this; SQLite's type affinity would swallow the type names but not the collation or CHECK syntax. The document's own fallback — "per-backend `CREATE TABLE` files and `shared/` reduced to seed data" (`:28`) — is what §5 actually requires, and `:28` still says the question "is under review in story S1" although S1 is closed. The checklist forbids anything provisional remaining; this is provisional and wrong in its default. Owner: Priya. Fix, one document (`migration-approach.md` §2): `shared/` = seed data only; `postgres/` and `sqlite/` hold the DDL; the two-invocation mechanism, R1–R5 and 04's design are unchanged (as `:28` already promises). R3's example ("`shared/` current but the `pg_trgm` index unapplied", `:42`) still holds.
93:## Seam 8 — `auth_method` and credential storage — CONTRADICTION
101:## Seam 9 — Retention and deletion — GAP
105:**F36 (contradiction — class names).** `observability.md:37` labels the sweep metrics by "retention class, e.g. `vendor_token_cache`, `idp_identity_cache`". 05's classes are `source='direct'`, `source='idp_cache'`, and orphaned `idp_cache` (`pii-governance.md:32-34`); `vendor_token_cache` is not a retention class and describes a cache the S3 ruling abolished (F17). An alert keyed to a nonexistent class fires never. Owner: Theo. Fix: use 05's `source` values plus an `orphan` label.
107:**F37 (gap — log retention is disclaimed by both candidate owners).** `observability.md:41`: "no log-retention-window design (that's 05's PII-retention territory for anything log-adjacent to PII …)". `pii-governance.md:72`: derived data "sits across `../02-ai-security-architecture/` … and `../04-infra-devops/` (log retention and where those logs physically live)". The checklist's question — logs must not outlive the data — is answered by neither. Treated in full under "Deletion gap" below.
109:## Seam 10 — Narrative claims — CONTRADICTION
121:## Seam 11 — Root files — CONTRADICTION
125:**F44 (contradiction — stale Status sections).** Root `CLAUDE.md:69`: "Phase 0 scaffolding done, Phase 1 (leads plan in plan mode and propose hires) next" — reality per `LOG.md:61` and `PLANNING.md:9-15` is Phase 3 complete. `03/CLAUDE.md:36`: "No implementation has started. This track's CLAUDE.md is scaffolding only" — 03 has four decision records, an accepted contract and filled service boundaries. `04/CLAUDE.md:37`: "No infra work has started. Do not begin until …" — 04 has five drafted deliverables. 01, 02 and 05 `CLAUDE.md` Status sections are current. Owners: Dana (root), Renata, Theo. Fix: turn-boundary edits of one paragraph each.
127:**F45 (contradiction — board vocabulary).** `PLAN.md:155` requires that at Phase 3 close "`PLANNING.md` rows all read 'plan approved'". Only 01 (`PLANNING.md:11`) and 05 (`:15`) do; 02 (`:12`), 03 (`:13`) and 04 (`:14`) carry free text outside the status vocabulary at `:5`. The Dana row (`:9`) says "02 on S8–S10" while the 02 row says all Stories but S11 are done. Owners: Marcus, Renata, Theo, Dana.
135:## Seam 12 — Cross-cutting: enforcement sites — GAP
145:## Vocabulary sweep across the hand-offs — GAP
149:- **`JWKS`** (`handoff-04-secrets.md:18`; `handoff-03-auth.md:20`, "JWKS or a fetched public key"). Undefined. Consequential: "fetched from the issuer" implies the issuer exposes an HTTP endpoint and `api-service` calls it at startup and on rotation — a network path with no config variable, no NetworkPolicy rule, and no failure mode stated. Receivers: Theo, Renata.
153:- **"audit record" / "logged with the audit record"** (`handoff-03-auth.md:28,42-54`). Whether this is the log stream 04 operates or a table 05 would own determines who retains a compliance artifact and for how long; no document says. Receivers: Theo, Priya.
154:- **"a mode of `api-service`"** (`handoff-04-secrets.md:8`; `handoff-03-auth.md:20`). Mechanically undefined — the config surface permits no flags — and the source of F13. Receivers: Renata, Theo.
156:- **`DEK`** (`handoff-04-secrets.md:22`, "re-wrapping DEKs"). Undefined (Wesley item 3); contingency-only, low consequence now. Receiver: Theo.
159:## Deletion gap — derived data — GAP (joint 02/04/05)
161:**Statement.** A subject-deletion request reaches `user_profile` and, by cascade, `user_credential` (`pii-governance.md:51`). It does not reach application logs, metrics, connector traces, ingress access logs, or crash dumps, none of which has a `source` column, a clock, or a key (`pii-governance.md:70`). 05 records this as unmodelled and names the upstream control: "if PII never enters a log, there is nothing to delete from it — which makes 02's never-log list the real control here" (`:72`). 02's list (`handoff-04-secrets.md:38-48`) and 04's enforcement (`observability.md:21-27`) are where that control lives; 04's log-retention window is explicitly not designed (`observability.md:41`) and each of 04 and 05 assigns it to the other (F37). `04/backlog.md` Story 6 (written during this pass) holds a placeholder awaiting this ruling.
163:**Does the current never-log list achieve "PII never enters a log"?** Not quite. It is close on intent — items 3, 4, 8 and 9 cover PII field values, vendor error bodies, request bodies and query fragments, and 04's metrics rule (`observability.md:15`) keeps PII out of labels — but three paths remain: (a) database driver error text, which on Postgres carries the failing row or key value and which 03 routes to logs as wrapped errors (F50) — the largest hole, and one no item on the list names; (b) `username`, absent from the list although it is typically an email address and appears in `ErrDuplicateUsername` driver detail — `connector-security.md:36` hedges only on the *vendor* username; (c) the audit log itself, permitted by design (`sub`, scope, opaque record id, timestamp — `handoff-03-auth.md:46-52`), which is pseudonymous rather than PII-free and, after a profile deletion, is the only remaining record that a given record id was looked up by a given caller — acceptable, but its retention window is the one nobody has set. Panic traces and Go's `net/http` server logs do not include request bodies, so item 8 holds there.
167:**Owners and smallest fixes.** Marcus: two lines added to the never-log list (driver error detail; `username`). Renata: the translation function sanitizes driver errors to code plus constraint name before wrapping (one sentence in `error-semantics.md`). Priya: one row for the audit log in `pii-governance.md`'s retention table, basis marked unknown. Theo: replace `observability.md:41`'s disclaimer with "log-sink retention = 05's audit-log window; enforcement site: sink retention policy".
169:## Mechanical checks

{
  "command": "sed -n '57,100p' /Users/warrenthompson/Source/LoginID/decisions/cross-track-consistency.md"
}

## Seam 5 — DAO contract — CONTRADICTION

**F18 (agree — the seam's explicit test passes).** The sentinel set is byte-identical: `03/decisions/error-semantics.md:33` lists `ErrNotFound`, `ErrAlreadyExists`, `ErrDuplicateUsername`, `ErrInvalidMethod`, `ErrInvalidQuery`, `ErrInvalidArgument`, `ErrInvalidCredential`, matching `05/multi-db-strategy.md:282-288` exactly, seven for seven. The translation rule matches (`error-semantics.md:34` ↔ `multi-db-strategy.md:298`). `PLANNING.md:47`'s composite (`Profiles()/Credentials()/Methods()`) matches `multi-db-strategy.md:94-97`. `context-propagation.md` item 1 (multi-table writes in one `Tx`) is satisfied by `CreateProfileWithCredential` (`context-propagation.md:31` ↔ `multi-db-strategy.md:99-101,232-244`).

**F-pag (contradiction — 02→03 vs 05→03 on pagination).** `handoff-03-auth.md:37`: "**Cursor-based pagination only** — no offset-based paging." `api-auth-design.md:59`: "offset walks turn a capped page size into full-table enumeration." `multi-db-strategy.md:191`: `Offset int // 0..10_000`; `decisions/search-query-shape.md:36`: "Limit/offset … Keyset rejected as designing for an uncommitted dataset size." 03 has accepted both hand-offs. 02's stated reason does not actually distinguish the two: a keyset cursor also permits a full page-by-page walk; the enumeration control is the cumulative distinct-record counter (`api-auth-design.md:61`), not the paging scheme. Owner: Marcus. Smallest fix, one document (`handoff-03-auth.md:37`): "opaque cursor at the API boundary; it may encode the DAO's offset; enumeration resistance rests on the cumulative counter" — and correct the reason at `api-auth-design.md:59`. The alternative (05 moving to keyset) reopens an accepted contract for no security gain.

**F19 (contradiction — cancellation).** `multi-db-strategy.md:228`: "`Context` is first on every method and cancellation is honoured." `context-propagation.md:23`: "Credential writes … use `context.WithoutCancel` … for the actual commit" — inside the DAO, which would mean the DAO does not honour cancellation on those methods. Owner: Renata. Fix: state that any detach happens in the handler before the DAO call (a fresh bounded context passed in), so the contract's guarantee stands unmodified; drop "token-persistence write" (F17).

**F20 (gap — the hand-off's first section contradicts its second).** `multi-db-strategy.md:9-13` still says `Update` is "implemented as a portable upsert", phone is "exact/prefix", pagination is "limit/offset" with no ceiling, and there is one sentinel `ErrNotFound`. All four are retracted lower down (`:214-222`, `:187`, `:190-191`, `:282-288`), and `:214` says "this changes the earlier prose" — but a receiver reading top-down meets three retracted statements before the retraction. This fails the hand-off standard (`planning-approach.md:39`) in a document that otherwise meets it unusually well. Owner: Priya. Fix: one banner line at `:5` naming the Go-shaped contract as authoritative, or delete `:9-13`.

**F21 (gap — the deletion mechanism has no DAO method and no implementer).** `pii-governance.md:50-51` specifies a bulk sweep and a subject-deletion request sharing "the same code path", each writing a `deletion_log` row; `multi-db-strategy.md:392-406` defines the table. The Go contract has no `DeletionLogRepository`, no sweep or delete-expired method, and `Profiles().Delete(ctx, id)` writes no log row (`:168,:257`); `:228` forbids 03 from opening a transaction to combine the two. 03's stories S1–S6 (`03/PLAN.md:20-25`) contain no sweep job; `pii-governance.md:77` gives 04 "where … deletion jobs actually run", not the code. So the retention policy's mechanism cannot be implemented against the contract and no track owns writing it. Owner: Priya (contract), then Renata (a story). Fix, one document (`multi-db-strategy.md`): add to the composite a `DeleteExpired(ctx, class, olderThan)` returning rows examined, rows deleted and oldest-surviving age (the three metrics `pii-governance.md:62` demands) and a `DeleteProfile(ctx, id, reason, externalRef)` — both writing `deletion_log` in the same transaction.

**F22 (gap — who writes `idp_cache` rows).** `go-layout-debate.md:78-80`: "`internal/dao` is imported ONLY by `cmd/api-service` — `idp-connector` has no DB access, by design: it never touches `user_profile`/`user_credential` storage." `multi-db-strategy.md:222`: "Resolving an `/identity` payload to an existing profile row is **the connector's problem**, not the DAO's … The connector decides identity and then calls `Create` or `Update`." `pii-governance.md:52` describes the re-hydration upsert without naming the writer. Owner: Priya (wording). Fix: `:222` → "the connector's caller (`api-service`) decides identity"; the diagram stands.

**F23 (minor).** `PLANNING.md:47` says "the three sub-interfaces' method signatures finalize once 05's contract lands" and omits `CreateProfileWithCredential` and `Close()`; the contract has landed. Owner: Renata.

## Seam 6 — Multi-DB behavior — GAP

**F24 (agree).** The engine-aware retry seam (`multi-db-strategy.md:319-331`; `research-cockroachdb-postgres-semantics.md:11`), the `LIKE` case-folding fix (`multi-db-strategy.md:37,208`; `decisions/multi-db-abstraction.md:27`), and 04's CI matrix — SQLite in-process plus separate Postgres and CockroachDB testcontainer jobs (`04/ci-pipeline.md:9`) — are mutually consistent. CI does run against every backend including CockroachDB.

**F25 (gap — the conformance suite exists as a requirement but not as anyone's deliverable).** 05 makes the per-driver ruling "conditional on" a single suite "written once against the interface, executed against every backend" (`multi-db-strategy.md:436-442`; `decisions/multi-db-abstraction.md:21,32`). 03's test story is "Table-driven unit tests for DAO (mocked driver)" (`03/PLAN.md:24`) with hand-written fakes (`decisions/test-double-strategy.md:19`); `ci-pipeline.md:9` runs "unit tests against 03's `internal/dao` per-backend implementations". Only `error-semantics.md:36` acknowledges §7, and only for sentinel parity. The backends are wired in CI; the suite that would run on them is nobody's story. Owner: Renata. Fix, one document (`03/PLAN.md` S5): add the conformance suite against the `Repository` interface, run against all three drivers, as a named deliverable.

**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".

**F27 (minor — false claim).** `ci-pipeline.md:9` says `-race` catches "a migration-runner exclusivity requirement (05's R2)". The Go race detector is intra-process; R2 concerns two runner processes. Owner: Theo. Fix: delete the clause.

## Seam 7 — Migrations — CONTRADICTION

**F28 (contradiction — 05 internal, propagated to 04).** `migration-approach.md:24`, marked "final" (`:7`), says `shared/` "carries `auth_method`, `user_profile`, `user_credential`, `deletion_log` … and the `auth_method` seed row", with `postgres/` holding exactly one file. The field-level schema it must implement gives every table per-engine DDL: `UUID DEFAULT gen_random_uuid()` vs `TEXT` (`multi-db-strategy.md:341`), `TEXT COLLATE "C"` vs `TEXT COLLATE BINARY` (`:342`), a regex `CHECK` vs a `GLOB` `CHECK` (`:343`), `TIMESTAMPTZ` vs `TEXT` (`:350`), `BYTEA` vs `BLOB` (`:363`), `BOOLEAN` vs `INTEGER` (`:388`). A single shared `CREATE TABLE` series cannot express this; SQLite's type affinity would swallow the type names but not the collation or CHECK syntax. The document's own fallback — "per-backend `CREATE TABLE` files and `shared/` reduced to seed data" (`:28`) — is what §5 actually requires, and `:28` still says the question "is under review in story S1" although S1 is closed. The checklist forbids anything provisional remaining; this is provisional and wrong in its default. Owner: Priya. Fix, one document (`migration-approach.md` §2): `shared/` = seed data only; `postgres/` and `sqlite/` hold the DDL; the two-invocation mechanism, R1–R5 and 04's design are unchanged (as `:28` already promises). R3's example ("`shared/` current but the `pg_trgm` index unapplied", `:42`) still holds.

**F29 (agree — the 04 side).** R1 (job before rollout) ↔ `containerization-design.md:78`; R2 (orchestration exclusivity, with the corrected reasoning) ↔ `containerization-design.md:80` and `ci-pipeline.md:18`, both restating the "right scope or right engine, never both" argument verbatim; R3 (both version tables) ↔ `containerization-design.md:82`; R4 (two credentials, `CREATE EXTENSION` on Postgres only) ↔ `secrets-delivery.md:20`; R5 ↔ `containerization-design.md:78` (`backoffLimit`) and `ci-pipeline.md:23`. The single-runner requirement is platform-enforced everywhere it appears.

**F30 (open item correctly presented).** Whether goose's default version table has a unique `version_id` is stated as "unverified here — I am not asserting it either way" (`migration-approach.md:40`), with the actionable backstop independent of the answer; `decisions/migration-approach-objections.md:25-27` records why it was left open; `containerization-design.md:80` repeats "regardless of whether goose's default schema already has one". Nowhere is it asserted as fact. Confirmed and left open, as instructed.

**F31 (minor — stale research text).** `research-cockroachdb-postgres-semantics.md:40` still mandates "by SQLSTATE code only — never by matching … constraint-name substrings" and `:55` says "`Update()` in our contract *is* a portable upsert"; both were superseded (`multi-db-strategy.md:298,214`) with no correction marker in the research file, although `05/CLAUDE.md` says corrections are "visible in place". Owner: Priya.

## Seam 8 — `auth_method` and credential storage — CONTRADICTION

**F32 (agree).** `auth_method` as a lookup table with `requires_secret` and `is_active` is consistent across `threat-model.md:8`, `multi-db-strategy.md:43,141-147,382-390`, `api-connector-design-rationale.md:58`, and `migration-approach.md:54-58`; 02's method-aware hashing decision (`threat-model.md:14-17`) targets the reserved columns 05 kept unchanged (`05/PLAN.md:142`); passkey rows carry `secret NULL` in both (`threat-model.md:17` ↔ `multi-db-strategy.md:157,372-376`).

**F33 (contradiction — 01 claims more than the schema supports).** `industry-framing.md:36`: "`webauthn` or `passkey` tomorrow, **without changing the table shape**." `api-connector-design-rationale.md:13`: "a future `"webauthn"` row would have a public key and credential ID instead, not a password field left null by convention." The schema has no public-key, credential-id or counter column; `secret` is "Salted hash only" (`multi-db-strategy.md:363`); and 02 says public-key material "does not belong in `secret`/`hash_algo`/`hash_cost` at all if/when a passkey method is actually added" (`threat-model.md:17`), with counter and credential-id integrity as separate requirements (`:32`). A passkey row today is exactly "a password field left null by convention" (`secret_state = 'none'`), and adding passkeys changes the table shape. Owner: Naomi. Fix, one document (`industry-framing.md:36` and the mirror at `api-connector-design-rationale.md:13`): "without changing the `method` discriminator — method-specific columns or a side table arrive by migration".

**F34 (minor contradiction — column type).** `threat-model.md:12` describes `secret` as "nullable TEXT" and `:15` stores the PHC string "inside the `secret` column's own text"; the contract types it `BYTEA`/`BLOB`, Go `[]byte` (`multi-db-strategy.md:133,363`). Storable, but the description is wrong and `secret_state` (`:134`) is never mentioned by 02. Owner: Marcus. Fix: `threat-model.md:12` → "bytes holding the PHC-encoded string". Latent, no fix now: the table-level CHECK (`:372-376`) requires `hash_algo`/`hash_cost` whenever a secret is set, so an encrypted-not-hashed TOTP secret (`threat-model.md:32`) is unrepresentable — consistent with 02's own statement that TOTP is uncommitted (`handoff-04-secrets.md:22`), but worth one sentence in either document.

{
  "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: ${DB_DSN:-file:/data/dev.db}
15	      HTTP_ADDR: ":8080"
16	    ports: ["8080:8080"]
17	    volumes: ["sqlite-data:/data"]
18	    profiles: ["sqlite"]
19	
20	  api-service-pg:
21	    extends: {service: api-service}
22	    environment:
23	      DB_DRIVER: postgres
24	      DB_DSN: postgres://dev:«REDACTED»@postgres:5432/loginid_dev?sslmode=disable
25	    depends_on: [postgres]
26	    profiles: ["postgres"]
27	
28	  postgres:
29	    image: postgres:16-alpine
30	    environment: {POSTGRES_USER: dev, POSTGRES_PASSWORD: dev, POSTGRES_DB: loginid_dev}
31	    ports: ["5432:5432"]
32	    profiles: ["postgres"]
33	
34	  idp-connector:
35	    build: {context: ., dockerfile: cmd/idp-connector/Dockerfile}
36	    environment:
37	      IDP_ABC_BASE_URL: ${IDP_ABC_BASE_URL:-http://mock-idp:9090}
38	      IDP_ABC_CLIENT_ID: dev-client
39	      IDP_ABC_CLIENT_SECRET: dev-secret
40	    profiles: ["sqlite", "postgres"]
41	
42	volumes:
43	  sqlite-data:
44	```
45	
46	`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 isn't in the local loop — it's wire-compatible enough with Postgres per 05's strategy doc that the Postgres profile exercises the shared code path; a CockroachDB-specific compose profile would test the same code again, not new code.
47	
48	## Dev credentials are dev credentials
49	
50	The `dev`/`dev` Postgres password and the hardcoded `dev-client`/`dev-secret` above 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.
51	
52	## Migrations locally
53	
54	`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.
55	
56	## Hot-reload for `api-service`, dev-profile only
57	
58	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.
59	
60	## What's deliberately not here
61	
62	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.
63	
64	---
65	*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.*
66	

{
  "replace_all": false,
  "file_path": "/Users/warrenthompson/Source/LoginID/04-infra-devops/local-dev-loop.md",
  "old_string": "```yaml\n# docker-compose.yml (sketch)\nservices:\n  api-service:\n    build: {context: ., dockerfile: cmd/api-service/Dockerfile}\n    environment:\n      DB_DRIVER: ${DB_DRIVER:-sqlite}\n      DB_DSN: ${DB_DSN:-file:/data/dev.db}\n      HTTP_ADDR: \":8080\"\n    ports: [\"8080:8080\"]\n    volumes: [\"sqlite-data:/data\"]\n    profiles: [\"sqlite\"]\n\n  api-service-pg:\n    extends: {service: api-service}\n    environment:\n      DB_DRIVER: postgres\n      DB_DSN: postgres://dev:«REDACTED»@postgres:5432/loginid_dev?sslmode=disable\n    depends_on: [postgres]\n    profiles: [\"postgres\"]\n\n  postgres:\n    image: postgres:16-alpine\n    environment: {POSTGRES_USER: dev, POSTGRES_PASSWORD: dev, POSTGRES_DB: loginid_dev}\n    ports: [\"5432:5432\"]\n    profiles: [\"postgres\"]\n\n  idp-connector:\n    build: {context: ., dockerfile: cmd/idp-connector/Dockerfile}\n    environment:\n      IDP_ABC_BASE_URL: ${IDP_ABC_BASE_URL:-http://mock-idp:9090}\n      IDP_ABC_CLIENT_ID: dev-client\n      IDP_ABC_CLIENT_SECRET: dev-secret\n    profiles: [\"sqlite\", \"postgres\"]\n\nvolumes:\n  sqlite-data:\n```\n\n`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 isn't in the local loop — it's wire-compatible enough with Postgres per 05's strategy doc that the Postgres profile exercises the shared code path; a CockroachDB-specific compose profile would test the same code again, not new code.\n\n## Dev credentials are dev credentials\n\nThe `dev`/`dev` Postgres password and the hardcoded `dev-client`/`dev-secret` above 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.",
  "new_string": "```yaml\n# docker-compose.yml (sketch)\nservices:\n  api-service:\n    build: {context: ., dockerfile: cmd/api-service/Dockerfile}\n    environment:\n      DB_DRIVER: ${DB_DRIVER:-sqlite}\n      DB_DSN_FILE: /run/secrets/db_dsn\n      HTTP_ADDR: \":8080\"\n    ports: [\"8080:8080\"]\n    volumes: [\"sqlite-data:/data\"]\n    secrets: [db_dsn]\n    profiles: [\"sqlite\"]\n\n  api-service-pg:\n    extends: {service: api-service}\n    environment:\n      DB_DRIVER: postgres\n    depends_on: [postgres]\n    profiles: [\"postgres\"]\n\n  postgres:\n    image: postgres:16-alpine\n    environment:\n      POSTGRES_USER: dev\n      POSTGRES_PASSWORD_FILE: /run/secrets/postgres_password\n    ports: [\"5432:5432\"]\n    secrets: [postgres_password]\n    profiles: [\"postgres\"]\n\n  idp-connector:\n    build: {context: ., dockerfile: cmd/idp-connector/Dockerfile}\n    environment:\n      IDP_ABC_BASE_URL: ${IDP_ABC_BASE_URL:-http://mock-idp:9090}\n    secrets: [idp_abc_client_id, idp_abc_client_secret]\n    profiles: [\"sqlite\", \"postgres\"]\n\nsecrets:\n  db_dsn: {file: ./.dev-secrets/db_dsn}                       # untracked; developer creates once, e.g. \"file:/data/dev.db\" or a postgres:// DSN\n  postgres_password: {file: ./.dev-secrets/postgres_password}\n  idp_abc_client_id: {file: ./.dev-secrets/idp_abc_client_id}\n  idp_abc_client_secret: {file: ./.dev-secrets/idp_abc_client_secret}\n\nvolumes:\n  sqlite-data:\n```\n\n`.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.\n\n`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.\n\n## Dev credentials are dev credentials\n\nThe 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."
}

The file /Users/warrenthompson/Source/LoginID/04-infra-devops/local-dev-loop.md has been updated successfully. (file state is current in your context — no need to Read it back)

{
  "file_path": "/Users/warrenthompson/Source/LoginID/04-infra-devops/ci-pipeline.md",
  "offset": 9,
  "limit": 1
}

9	3. **Test.** `go test ./... -race` — unit tests against 03's `internal/dao` per-backend implementations: SQLite in-process for the fast path, plus **two** testcontainer jobs against the shared `postgres` package — one on Postgres, one on CockroachDB. Considered running CockroachDB only in the local dev-loop (wire-compatible enough with Postgres that testing both looked redundant) and reconsidered for CI specifically: wire-compatible isn't schema-compatible, and a Postgres-only test matrix means a CockroachDB-specific SQL quirk (UUID defaults, upsert syntax, lock semantics) surfaces at deploy time instead of at PR time. CockroachDB ships an official single-node Docker image, so this is a config addition to the test job, not new infrastructure — a few extra minutes of CI wall-clock for catching it at the cheapest possible point. `-race` is not optional given two DB implementations and a migration-runner exclusivity requirement (05's R2) that's exactly the kind of thing a race detector catches in test even though it's enforced by orchestration in production.

{
  "replace_all": false,
  "file_path": "/Users/warrenthompson/Source/LoginID/04-infra-devops/ci-pipeline.md",
  "old_string": "CockroachDB ships an official single-node Docker image, so this is a config addition to the test job, not new infrastructure — a few extra minutes of CI wall-clock for catching it at the cheapest possible point. `-race` is not optional given two DB implementations and a migration-runner exclusivity requirement (05's R2) that's exactly the kind of thing a race detector catches in test even though it's enforced by orchestration in production.",
  "new_string": "CockroachDB ships an official single-node Docker image, so this is a config addition to the test job, not new infrastructure — a few extra minutes of CI wall-clock for catching it at the cheapest possible point. `-race` is not optional given two DB implementations with genuine concurrent-access paths worth catching in-process."
}

The file /Users/warrenthompson/Source/LoginID/04-infra-devops/ci-pipeline.md has been updated successfully. (file state is current in your context — no need to Read it back)

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

1	# Observability + Never-Log Enforcement
2	
3	Design-only. Covers logging, metrics, and tracing for both services, and — the harder half — how `handoff-04-secrets.md`'s never-log list gets enforced as a mechanism, not just stated as a policy.
4	
5	## Logging
6	
7	Structured logging (`slog`, Go stdlib — no third-party logging library needed for two services this size), JSON output, one line per event. Every log line that touches a request carries `sub` (caller identity), the endpoint, status, and a request id — never the request or response body wholesale. This is the pattern the never-log list requires (hand-off item 8: "full request bodies of `POST /auth` and `POST /identity`... both contain items above by construction") — the enforcement mechanism is that handlers log a small, explicit field set assembled by hand, never `log.Printf("%+v", req)` or equivalent reflection-based dumps of a request/response struct. A struct that contains a password field can't leak through a log statement that never receives the struct.
8	
9	**Enforcement beyond "write it carefully":**
10	- A lint rule (a `golangci-lint` custom check, or a simple `go vet`-style grep in CI) that flags any log call passing a whole request/response struct, a `*http.Request` body, or any variable named/typed to match the never-log list's fields (`password`, `token`, `secret`, `dsn`, `client_secret`). Not foolproof — a determined developer can rename around it — but it catches the accidental case, which is the common one.
11	- Error-path discipline: wrapped errors are logged with `err.Error()` truncated/sanitized where the error type is known to carry sensitive detail (a DB driver error can echo the DSN; a vendor HTTP client error can echo the response body per hand-off item 4) — the wrapping layer strips those before the error reaches a log call, not the log call itself deciding case-by-case.
12	
13	## Metrics
14	
15	Standard RED metrics (rate, errors, duration) per endpoint, via Prometheus client library, scraped by whatever the lab cluster already runs (not stood up new for this take-home). Labels: method, route, status class — never a label with cardinality tied to user data (no `sub` or phone number as a metric label; that turns a metrics backend into an accidental PII store with no access control at all, which is a worse leak than a log line since metrics systems are typically more widely readable).
16	
17	## Tracing
18	
19	Not built out here — a two-service take-home with no running collector doesn't get more credible by naming OpenTelemetry. If ever added, it follows the same field discipline as logging.
20	
21	## The never-log list, operationalized
22	
23	Hand-off's nine items map to two enforcement surfaces, not nine separate mechanisms:
24	
25	1. **Application-level:** the structured-logging discipline above (explicit field sets, the lint check, error-wrapping sanitization) covers items 1, 2, 5, 6, 7 (password, tokens, JWTs, client secrets, DSN) — these never enter a Go `log`/`slog` call in the first place.
26	2. **Proxy/ingress-level:** item 9 ("search query parameters containing a name or phone fragment... redact or hash before any access log, including proxy and ingress logs 04 controls") is the one item application code can't fully own, since ingress access logs are written by the ingress controller, not the service. Mechanism: an ingress-level log-format override that logs the request path with query string stripped (or a regex redaction on the `phone`/`name` query params specifically) rather than the default full-URL access log format. This is a one-time ingress ConfigMap change, not a per-request code path.
27	3. Item 3 (PII field values from `/identity` or `user_profile`) and item 4 (raw vendor error bodies) are the same discipline as #1 applied to the connector specifically — the connector logs "called vendor X, got status Y," never the response body.
28	
29	## Audit-log access is a separate grant from Secret access
30	
31	Per the hand-off's Kubernetes-specific requirements: the log stream carrying `sub`/scope/record-id/timestamp (the "fact of access" the never-log list still permits) is itself sensitive enough to reconstruct who looked up whom, so it gets its own RBAC — a distinct, narrower `Role` bound to an incident-review group, separate from any ServiceAccount's `Secret`-read grant (`./secrets-delivery.md`). Mechanism: if logs go to a cluster-local sink (e.g., Loki), that sink's read API gets its own RBAC/auth in front of it, not the same one guarding `kubectl get secrets`; if logs go to an external platform, the equivalent is a scoped read-only role in that platform, provisioned separately from any cluster credential.
32	
33	## Retention-sweep observability (05's S5 requirement, final)
34	
35	Per `../05-data-ops/pii-governance.md`: the retention sweep must emit, per data class per run, three metrics — rows examined, rows deleted, and **the age of the oldest surviving row in that class**. An alert fires when that age exceeds the class's stated retention window plus one sweep interval. This is the one metric in this document tied to a specific reasoning worth repeating: a sweep job that silently stops running produces no error and no symptom on its own — "rows deleted" can't tell a broken sweep from a legitimately empty one, since both report zero. Oldest-surviving-row age is the one number that keeps climbing when the job is dead and holds steady when it's healthy, which is why it's the alerting signal, not just a nice-to-have metric alongside the other two.
36	
37	Mechanism: the sweep job (whatever invokes it — a CronJob against the lab cluster, per 05's mechanism-agnostic requirement) emits these as Prometheus metrics with a `class` label (one label value per retention class, e.g. `vendor_token_cache`, `idp_identity_cache` — never a label carrying the PII itself, same discipline as the RED-metrics rule above) rather than only a log line, since a log line nobody's alerting on has the same "silent failure" problem the requirement exists to solve. The alert rule is `oldest_surviving_row_age_seconds{class="X"} > (retention_window_seconds + sweep_interval_seconds)`, evaluated per class.
38	
39	## What's deliberately not here
40	
41	No SLOs/error-budget policy, no alerting-rule catalog, no log-retention-window design (that's 05's PII-retention territory for anything log-adjacent to PII, per `../05-data-ops/pii-governance.md` — this document only says logs must exclude PII values in the first place, not how long the remaining metadata is kept). A take-home needs the shape of an observability approach and a credible enforcement mechanism for the one hard requirement (never-log); it doesn't need a full SRE runbook.
42	
43	---
44	*AI tooling note: drafted directly by Theo (Sonnet, this session) from `handoff-04-secrets.md` v2's never-log list. Bree's (capability-case) and Callum's (scope-cut) per-deliverable notes reviewed and folded in inline above, per PLAN.md §3.*
45	

{
  "replace_all": false,
  "file_path": "/Users/warrenthompson/Source/LoginID/04-infra-devops/observability.md",
  "old_string": "Mechanism: the sweep job (whatever invokes it — a CronJob against the lab cluster, per 05's mechanism-agnostic requirement) emits these as Prometheus metrics with a `class` label (one label value per retention class, e.g. `vendor_token_cache`, `idp_identity_cache` — never a label carrying the PII itself, same discipline as the RED-metrics rule above) rather than only a log line, since a log line nobody's alerting on has the same \"silent failure\" problem the requirement exists to solve. The alert rule is `oldest_surviving_row_age_seconds{class=\"X\"} > (retention_window_seconds + sweep_interval_seconds)`, evaluated per class.\n\n## What's deliberately not here\n\nNo SLOs/error-budget policy, no alerting-rule catalog, no log-retention-window design (that's 05's PII-retention territory for anything log-adjacent to PII, per `../05-data-ops/pii-governance.md` — this document only says logs must exclude PII values in the first place, not how long the remaining metadata is kept). A take-home needs the shape of an observability approach and a credible enforcement mechanism for the one hard requirement (never-log); it doesn't need a full SRE runbook.",
  "new_string": "Mechanism: the sweep job (whatever invokes it — a CronJob against the lab cluster, per 05's mechanism-agnostic requirement) emits these as Prometheus metrics with a `class` label matching 05's actual retention classes — `source=\"direct\"`, `source=\"idp_cache\"`, and `orphan` for an orphaned `idp_cache` row (`../05-data-ops/pii-governance.md`), never a label carrying the PII itself, same discipline as the RED-metrics rule above. (An earlier draft of this section invented `vendor_token_cache`/`idp_identity_cache` as class names — those don't correspond to anything 05 tracks and described a connector token cache the S3 ruling never adopted; corrected here.) The alert rule is `oldest_surviving_row_age_seconds{class=\"X\"} > (retention_window_seconds + sweep_interval_seconds)`, evaluated per class.\n\n## Log-sink retention: the deletion-gap enforcement site\n\nApplication logs, metrics, and traces have no `source` column, no clock tied to a `user_profile` row, and no key a subject-deletion request could reach by cascade — a deleted profile's data can still exist in a log line indefinitely. 05's never-log list (`handoff-04-secrets.md`) and this document's enforcement mechanism (above) are the upstream control — if PII never enters a log, there's nothing in a log to expire — but that only holds for the fields on the list. What's left (chiefly the audit trail: `sub`, scope, opaque record id, timestamp — permitted by design, pseudonymous rather than PII-free) still needs a retention window, and that window's enforcement site is **this track's**: the log sink's own retention policy (the Loki/cluster-local sink named under \"Audit-log access,\" above, or the external platform's retention setting if logs go there instead), configured to 05's audit-log retention row in `pii-governance.md`'s table. Not a deletion job 04 writes — a retention setting on infrastructure 04 already operates.\n\n## What's deliberately not here\n\nNo SLOs/error-budget policy, no alerting-rule catalog beyond the retention-sweep alert above. A take-home needs the shape of an observability approach and a credible enforcement mechanism for the one hard requirement (never-log); it doesn't need a full SRE runbook."
}

The file /Users/warrenthompson/Source/LoginID/04-infra-devops/observability.md has been updated successfully. (file state is current in your context — no need to Read it back)

{
  "file_path": "/Users/warrenthompson/Source/LoginID/04-infra-devops/secrets-delivery.md",
  "offset": 14,
  "limit": 4
}

14	| #4 | API caller `client_secret`s | Not a Kubernetes `Secret` — lives in the authorization server's own datastore (hashed, Argon2id) | Datastore credentials are shaped like row #1, delivered the same way |
15	| #5 | `IDP_ABC_CLIENT_ID`/`SECRET` (+ XYZ pair) | File, one `Secret` per vendor so rotating one never touches the other | `idp-connector` SA |
16	| #6 | Vendor `access_token` | Not deployed — transient, in-memory only. If cached, encrypted with #7's KEK; no `Secret` object | n/a |
17	| #7 | KEK for envelope encryption | File. Per the hand-off's resolved v2: not a live requirement until TOTP or token-caching actually materializes — provisioned only if/when 05 or 02 confirms one of those features is real. If a KMS is used instead of a mounted key (row #7a), its access credential follows the same delivery discipline as row #2. | `api-service` and/or `idp-connector` SA, whichever feature lands |

{
  "replace_all": false,
  "file_path": "/Users/warrenthompson/Source/LoginID/04-infra-devops/secrets-delivery.md",
  "old_string": "| #6 | Vendor `access_token` | Not deployed — transient, in-memory only. If cached, encrypted with #7's KEK; no `Secret` object | n/a |\n| #7 | KEK for envelope encryption | File. Per the hand-off's resolved v2: not a live requirement until TOTP or token-caching actually materializes — provisioned only if/when 05 or 02 confirms one of those features is real. If a KMS is used instead of a mounted key (row #7a), its access credential follows the same delivery discipline as row #2. | `api-service` and/or `idp-connector` SA, whichever feature lands |",
  "new_string": "| #6 | Vendor `access_token` | **Not deployed and not built** — per the S3 ruling, `idp-connector` does not cache vendor tokens; nothing to provision here | n/a |\n| #7 | KEK (Key-Encrypting-Key) for envelope encryption — wraps a per-record Data-Encryption-Key (DEK) rather than encrypting data directly, so rotating the KEK means re-wrapping DEKs, not re-encrypting everything | File. Not a live requirement — provisioned only if/when TOTP (a supported `auth_method` value, not a committed implementation) actually materializes; the token-caching use case named in an earlier draft no longer applies, per row #6. | `api-service` SA, if/when TOTP lands |"
}

The file /Users/warrenthompson/Source/LoginID/04-infra-devops/secrets-delivery.md has been updated successfully. (file state is current in your context — no need to Read it back)

{
  "replace_all": false,
  "file_path": "/Users/warrenthompson/Source/LoginID/04-infra-devops/backlog.md",
  "old_string": "## Story 6 — Derived-data deletion / log-retention enforcement (placeholder, pending consistency pass)\n\n**Description:** Placeholder for the enforcement site of \"logs and any derived/cached data must not outlive the data they're derived from\" — the interaction the consistency pass is explicitly checking (`PLAN.md` \"Retention and deletion\": `05/pii-governance.md` S5 numbers and deletion-job contract vs. `04/observability.md` vs. `02/threat-model.md` assumptions). 04 is the presumptive owner of the enforcement site if the pass confirms it's a log-retention/observability-pipeline mechanism (e.g., a log-sink retention policy matching 05's window, not a separate deletion job) rather than a DAO-level or connector-level mechanism. Not filled in beyond this placeholder until the pass reports, per team-lead's instruction — this story exists so the gap is tracked now rather than discovered after transcription.\n\n**Acceptance criteria:**\n- [ ] Left open pending the consistency pass's ruling on which track owns the enforcement site.\n\n**Depends on:** 02 — `threat-model.md` assumptions about derived-data lifetime; 05 — `pii-governance.md` S5 deletion-job contract and retention numbers.\n\n**Model/effort:** TBD, pending scope.\n\n**Type:** Story.\n\n**Labels:** `track-04`, `from-consistency-pass`, `no-code-yet`.",
  "new_string": "## Story 6 — Configure log-sink retention for the audit trail\n\n**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.\n\n**Acceptance criteria:**\n- [ ] The hand-off standard: 02 and 05 can each confirm their half (never-log list scope; retention-table row) without needing this story rewritten.\n- [ ] 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.\n- [ ] 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.\n- [ ] 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.\n\n**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).\n\n**Model/effort:** Sonnet, low.\n\n**Type:** Story.\n\n**Labels:** `track-04`, `from-consistency-pass`, `no-code-yet`."
}

The file /Users/warrenthompson/Source/LoginID/04-infra-devops/backlog.md has been updated successfully. (file state is current in your context — no need to Read it back)

{
  "file_path": "/Users/warrenthompson/Source/LoginID/04-infra-devops/CLAUDE.md",
  "offset": 30,
  "limit": 10
}

30	
31	## AI tooling note
32	
33	Record which AI tool/workflow was used to produce this track's design output and how.
34	
35	## Status
36	
37	No infra work has started. Do not begin until the engineering track's service boundaries are defined enough to containerize and deploy against.
38	
39	<!-- profile-gen:start slug=theo-bergman -->

{
  "replace_all": false,
  "file_path": "/Users/warrenthompson/Source/LoginID/04-infra-devops/CLAUDE.md",
  "old_string": "## Status\n\nNo infra work has started. Do not begin until the engineering track's service boundaries are defined enough to containerize and deploy against.",
  "new_string": "## Status\n\nPlan 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). Consistency-pass fixes applied (F14, F17, F26, F27, F36, F37/deletion-gap, F44); F12/F13 pending Marcus's resolution in `handoff-04-secrets.md`. No code or config committed — still design-only per root `CLAUDE.md`."
}

The file /Users/warrenthompson/Source/LoginID/04-infra-devops/CLAUDE.md has been updated successfully. (file state is current in your context — no need to Read it back)

{
  "file_path": "/Users/warrenthompson/Source/LoginID/PLANNING.md",
  "offset": 7,
  "limit": 10
}

7	| Track | Lead | Status | Blocking on | Blocked by | Planning notes | Hires (planned / registered / spawned) | Last updated |
8	|---|---|---|---|---|---|---|---|
9	| Orchestration (root) | Dana Whitfield | Phase 4 — Warren's go; Epics LT-1…LT-5 created; 01 transcribed (LT-6…LT-13), 05 in progress; 02/03/04 queued behind the consistency pass; all five `backlog.md` authored | consistency-pass report | — | `PLAN.md`, `LOG.md`; Jira project `LT` | 18 / 18 (cap) | 2026-09-12 |
10	| Cross-track consistency pass (root, Phase 3) | Dana Whitfield | running — fresh Fable session against the 12-seam checklist (`PLAN.md`) plus 05's four items | — | — | `decisions/cross-track-consistency.md` (root, on completion) | — | 2026-09-12 |
11	| 01 Product & Industry Research (incl. Design) | Naomi Voss | plan approved — S1–S6 all done (claims audit, password-baseline debate, connector rationale hardened + cold read, search-authz requirements, UX notes, evaluator-legibility cold read) | — | — | `01-product-industry-research-design/PLAN.md`; `decisions/claims-audit.md`, `decisions/password-baseline-debate.md`, `decisions/rationale-cold-read.md` (S3+S6) all written; Newcomer loan from 04 (`wesley-okonkwo`) closed at 2/2-4 turns, both passed clean | 3 / 3 / 3 | 2026-09-12 |
12	| 02 AI Architecture & Security Architecture | Marcus Ilori | all Stories done except S11 (post-code-go-ahead) — ready for consistency pass | — | — | `02-ai-security-architecture/PLAN.md`; S3/S4/S6/S7 as before; S5 `decisions/ai-workflow-claim-debate.md` (ruled against a general multi-agent-beats-solo claim, for a narrower mechanism-level one); S8 `decisions/second-review-security-docs.md` (required an independence reassignment mid-run — caught before running; 10 accepted findings, 0 declined); S9 `ai-workflow-narrative.md` revised with the org layer, measured costs, and the S5/S8 lessons stated plainly; S10 verified already clean, no edit needed | 4 / 4 / 4 | 2026-09-12 |
13	| 03 Engineering & Delivery | Renata Cole | Phase 4 — `backlog.md` written, 10 stories S1–S10, awaiting transcription | team-lead transcription; Warren's implementation go-ahead | — | `03-engineering-delivery/PLAN.md`, `backlog.md`; `handoff-03-auth.md` v2 accepted; `decisions/error-semantics.md` + `decisions/context-propagation.md` reconciled against 05's contract; Oren's 4 findings all ruled by 05, contract updated with `CreateProfileWithCredential` composite method | 4 / 4 / 4 | 2026-09-12 |
14	| 04 Infra & DevOps | Theo Bergman | five deliverables drafted, Bree/Callum notes folded in | — | — | `04-infra-devops/PLAN.md`; `containerization-design.md`, `ci-pipeline.md`, `local-dev-loop.md`, `secrets-delivery.md`, `observability.md` | 3 / 3 / 3 | 2026-09-12 |
15	| 05 Data Ops | Priya Nandakumar | **plan approved**; backlog authored → Epic `LT-5`, transcribing | — | — | `05-data-ops/PLAN.md`; 6 stories S1–S6, S1 = Go-shaped contract in `multi-db-strategy.md` (critical path); S4 `migration-approach.md` + S5 retention table unblock 04; `migration-approach.md` drafted for 04 (R1–R5; single-runner requirement is platform-enforced — pg_advisory_lock is unavailable on CockroachDB), pending one objection turn; deep research authorized+run (lead): `05-data-ops/research-cockroachdb-postgres-semantics.md` — one Go package CAN serve Postgres+CockroachDB but needs an engine-aware retry/error seam (CRDB SERIALIZABLE returns client-retryable 40001; sentinel translation must be SQLSTATE-only); corrects R2 of `migration-approach.md`; S3 ruled `05-data-ops/decisions/multi-db-abstraction.md` — per-driver confirmed, but on reviewability not cost (only 2 real conditionals, doc's rejection reasoning corrected); codegen is orthogonal, 03's choice; **requirement on 03: one conformance suite run against every backend** — SQLite `LIKE` is case-insensitive vs Postgres case-sensitive, so the documented parity gap is a correctness gap, not a performance one; S2 ruled `05-data-ops/decisions/search-query-shape.md` — 8/8 objections accepted; adopted principle: **every caller-visible guarantee names an enforcement site (DDL constraint, index, normalization, or conformance test) — one with no site is a hope, not a guarantee**; **S1 Go-shaped contract stable in `05-data-ops/multi-db-strategy.md`** — 03 may start the DAO; S6 cold read (Saoirse, deliberately kept unfamiliar) returned 14 blocking items, all accepted and fixed: `Update`/`Upsert` are FULL REPLACES (nil NULLs the column), `Upsert` conflicts on id only (identity resolution is the connector's problem), error translation revised to structured codes + our own named constraints (SQLite has no SQLSTATE), `ErrInvalidArgument` added for CHECK violations, `is_active` enforcement site named; S5 closed in `05-data-ops/pii-governance.md` — retention windows (24mo direct / 30d cache / 7d orphan, all proposed pending product-legal), deletion mechanism, and the health check that matters: **alert on age-of-oldest-surviving-row per class, since a stopped sweep produces no error at all**; `deletion_log` added to the schema, PII-free by construction; `05-data-ops/backlog.md` authored — 7 stories (6 delivered, 1 open: derived-data deletion, owner TBD by the pass); keys written back by team-lead; S4 final and delivered to 04 (`migration-approach.md`) — objection turn overturned R2's *reasoning* while the requirement stood: a txn-scoped advisory lock releases between goose files, so it cannot cover a multi-file run; factory mismatch closed with 03 direct (two-party): `dao.Repository` composite exposing `Profiles()`/`Credentials()`/`Methods()`, `dao.New` signature unchanged — cited in S1 | 4 / 4 / 4 | 2026-09-12 |
16	

{
  "replace_all": false,
  "file_path": "/Users/warrenthompson/Source/LoginID/PLANNING.md",
  "old_string": "| 04 Infra & DevOps | Theo Bergman | five deliverables drafted, Bree/Callum notes folded in | — | — | `04-infra-devops/PLAN.md`; `containerization-design.md`, `ci-pipeline.md`, `local-dev-loop.md`, `secrets-delivery.md`, `observability.md` | 3 / 3 / 3 | 2026-09-12 |",
  "new_string": "| 04 Infra & DevOps | Theo Bergman | plan approved — five deliverables drafted, Bree/Callum notes folded in, `backlog.md` written (Epic `LT-4`), consistency-pass fixes applied except F12/F13 (pending Marcus) | F12/F13 resolution from Marcus | — | `04-infra-devops/PLAN.md`; `containerization-design.md`, `ci-pipeline.md`, `local-dev-loop.md`, `secrets-delivery.md`, `observability.md`, `backlog.md` | 3 / 3 / 3 | 2026-09-12 |"
}

The file /Users/warrenthompson/Source/LoginID/PLANNING.md has been updated successfully. (file state is current in your context — no need to Read it back)

{
  "to": "org-planning-loginid-takehome",
  "summary": "04 pass fixes done",
  "message": "04 pass fixes done. One line per finding:\n\n- F14 (compose leaks forbidden values): local-dev-loop.md rewritten to use compose file-based `secrets:` (untracked `.dev-secrets/*`) for DB_DSN_FILE, Postgres password, and both IDP client credentials — no literal secret values in the file anymore.\n- F26 (CockroachDB-locally reasoning): reworded to \"omitted for loop speed, not redundancy — the CockroachDB path is genuinely different code, exercised in CI instead.\"\n- F27 (false -race/R2 claim): deleted the clause; -race justified only by genuine in-process concurrency now.\n- F36 (invented retention class names): observability.md now uses 05's real classes (`source=\"direct\"`, `source=\"idp_cache\"`, `orphan`) instead of the fabricated `vendor_token_cache`/`idp_identity_cache`.\n- F17 (stale cache references in my files): secrets-delivery.md row #6 now states the connector doesn't cache tokens at all (S3 ruling); row #7's KEK note drops the token-cache use case.\n- F37 / deletion gap: observability.md's disclaimer replaced with \"log-sink retention = 05's audit-log window; enforcement site: sink retention policy\"; backlog.md Story 6 rewritten from a placeholder to a real story with acceptance criteria, owned by 04.\n- F44 (stale CLAUDE.md Status): updated at this turn boundary.\n- F45 (status vocabulary): PLANNING.md row now leads with \"plan approved\", blocking-on field narrowed to F12/F13.\n- DEK vocabulary gap (receiver-only, low consequence): glossed inline in secrets-delivery.md row #7 while I was there.\n\nF12/F13 left untouched pending Marcus — will fix `handoff-04-secrets.md`'s version label and remove the JWT-signing-key mount from `api-service`'s Deployment (adding a separate issuer Deployment) the moment he settles the topology change. JWKS and \"audit record\" vocabulary gaps (joint with Renata/Priya) not resolved unilaterally — flagging as still open, not silently closed.",
  "type": "message",
  "recipient": "org-planning-loginid-takehome",
  "content": "04 pass fixes done. One line per finding:\n\n- F14 (c…"
}

{"success":true,"message":"“04 pass fixes done” → org-planning-loginid-takehome (another Claude session on this machine)","msg_id":"0c52a50e-613a-4579-b74b-c9cc977a0d39"}

{
  "command": "grep -n \"shared/\\|postgres/\\|sqlite/\" /Users/warrenthompson/Source/LoginID/04-infra-devops/*.md"
}

/Users/warrenthompson/Source/LoginID/04-infra-devops/containerization-design.md:82:**Fail-closed schema check (R3, final):** the readiness probe below isn't just a liveness ping — `api-service` must refuse to serve if either of goose's two version tables (`shared/` and its backend-specific directory, per `migration-approach.md` §2's two-invocation mechanism) is behind the version the binary was built against. A check against only one table can pass while the other is stale — e.g. `shared/` current but the Postgres-only `pg_trgm` index migration unapplied — which is a passing check that proves nothing. `/healthz` above is liveness only; a separate `/readyz` (or the same endpoint gated by both checks) is where this lives, wired to whatever version-embedding mechanism 03 picks (build-time constant vs. reading the shipped migration files) — the check comparing *both* tables is 04's requirement to build against; the embedding mechanism is 03's call.
/Users/warrenthompson/Source/LoginID/04-infra-devops/research-infra-devops-best-practices.md:130:- [Why CockroachDB and PostgreSQL are compatible](https://www.cockroachlabs.com/blog/why-postgres/)

{
  "to": "data-ops-planning-phase",
  "summary": "No changes needed on my end",
  "message": "Checked — nothing in my docs describes `shared/`'s contents, only that it's one of the two version tables goose tracks (`containerization-design.md`'s R3 fail-closed paragraph), which is still true under the corrected layout. R1-R5, the two-invocation mechanism, and the migration-runner credential's CREATE EXTENSION detail are all directory-content-agnostic on my side, as you said. Nothing to fix here.",
  "type": "message",
  "recipient": "data-ops-planning-phase",
  "content": "Checked — nothing in my docs describes `shared/`'…"
}

{"success":true,"message":"“No changes needed on my end” → data-ops-planning-phase (another Claude session on this machine)","msg_id":"e114175e-e588-41e1-b496-802104d836a7"}

{
  "file_path": "/Users/warrenthompson/Source/LoginID/04-infra-devops/observability.md",
  "offset": 33,
  "limit": 6
}

33	## Retention-sweep observability (05's S5 requirement, final)
34	
35	Per `../05-data-ops/pii-governance.md`: the retention sweep must emit, per data class per run, three metrics — rows examined, rows deleted, and **the age of the oldest surviving row in that class**. An alert fires when that age exceeds the class's stated retention window plus one sweep interval. This is the one metric in this document tied to a specific reasoning worth repeating: a sweep job that silently stops running produces no error and no symptom on its own — "rows deleted" can't tell a broken sweep from a legitimately empty one, since both report zero. Oldest-surviving-row age is the one number that keeps climbing when the job is dead and holds steady when it's healthy, which is why it's the alerting signal, not just a nice-to-have metric alongside the other two.
36	
37	Mechanism: the sweep job (whatever invokes it — a CronJob against the lab cluster, per 05's mechanism-agnostic requirement) emits these as Prometheus metrics with a `class` label matching 05's actual retention classes — `source="direct"`, `source="idp_cache"`, and `orphan` for an orphaned `idp_cache` row (`../05-data-ops/pii-governance.md`), never a label carrying the PII itself, same discipline as the RED-metrics rule above. (An earlier draft of this section invented `vendor_token_cache`/`idp_identity_cache` as class names — those don't correspond to anything 05 tracks and described a connector token cache the S3 ruling never adopted; corrected here.) The alert rule is `oldest_surviving_row_age_seconds{class="X"} > (retention_window_seconds + sweep_interval_seconds)`, evaluated per class.
38	

{
  "replace_all": false,
  "file_path": "/Users/warrenthompson/Source/LoginID/04-infra-devops/observability.md",
  "old_string": "Mechanism: the sweep job (whatever invokes it — a CronJob against the lab cluster, per 05's mechanism-agnostic requirement) emits these as Prometheus metrics with a `class` label matching 05's actual retention classes — `source=\"direct\"`, `source=\"idp_cache\"`, and `orphan` for an orphaned `idp_cache` row (`../05-data-ops/pii-governance.md`), never a label carrying the PII itself, same discipline as the RED-metrics rule above. (An earlier draft of this section invented `vendor_token_cache`/`idp_identity_cache` as class names — those don't correspond to anything 05 tracks and described a connector token cache the S3 ruling never adopted; corrected here.) The alert rule is `oldest_surviving_row_age_seconds{class=\"X\"} > (retention_window_seconds + sweep_interval_seconds)`, evaluated per class.",
  "new_string": "Mechanism: the sweep job (whatever invokes it — a CronJob against the lab cluster, per 05's mechanism-agnostic requirement) emits these as Prometheus metrics with a `class` label matching 05's actual retention classes — `source=\"direct\"`, `source=\"idp_cache\"`, and `orphan` for an orphaned `idp_cache` row (`../05-data-ops/pii-governance.md`), never a label carrying the PII itself, same discipline as the RED-metrics rule above. (An earlier draft of this section invented `vendor_token_cache`/`idp_identity_cache` as class names — those don't correspond to anything 05 tracks and described a connector token cache the S3 ruling never adopted; corrected here.) The alert rule is `oldest_surviving_row_age_seconds{class=\"X\"} > (retention_window_seconds + sweep_interval_seconds)`, evaluated per class.\n\n**Batched sweeps: only a drained result feeds the metric.** 05's `DeleteExpired` is batched (a bounded `maxRows` per call, `SweepResult.Drained` marking the last batch of a sweep) — `OldestSurvivingAt` is meaningful only on a `Drained == true` result, since mid-sweep the oldest deletable row is still present by construction and would read as stale on every batch but the last. The sweep job emits `oldest_surviving_row_age_seconds` only from drained results, never from an intermediate batch; the alert rule above already only ever sees what's published, so this is a constraint on what the job emits, not an extra filter the alert needs to apply. Getting this wrong means the alert fires on every sweep and gets muted, which is worse than not having it."
}

The file /Users/warrenthompson/Source/LoginID/04-infra-devops/observability.md has been updated successfully. (file state is current in your context — no need to Read it back)

{
  "to": "03-engineering-delivery-b7",
  "summary": "Fixed — metric now only emitted on drained results",
  "message": "Good catch, would've fired every sweep. Fixed in observability.md: the sweep job only emits `oldest_surviving_row_age_seconds` from a `Drained == true` result — made it a constraint on what gets published, not something the alert rule has to filter for, since the alert only ever sees what's emitted anyway. Matches your S11 plan to only publish OldestSurvivingAt on drained results.",
  "type": "message",
  "recipient": "03-engineering-delivery-b7",
  "content": "Good catch, would've fired every sweep. Fixed in …"
}

{"success":true,"message":"“Fixed — metric now only emitted on drained results” → 03-engineering-delivery-b7 (another Claude session on this machine)","msg_id":"935438d7-c3f5-4603-a8c4-d788be85922f"}

{
  "file_path": "/Users/warrenthompson/Source/LoginID/04-infra-devops/containerization-design.md",
  "offset": 30,
  "limit": 45
}

30	  namespace: loginid-poc          # amber-kubernetes' convention, confirmed at apply time — not queried during this take-home
31	spec:
32	  replicas: 2
33	  selector:
34	    matchLabels: {app: api-service}
35	  template:
36	    metadata:
37	      labels: {app: api-service}
38	    spec:
39	      serviceAccountName: api-service       # scoped per handoff-04-secrets.md row #2 — this SA's Role can `get` the JWT signing key only from the issuing code path, not the verification path
40	      securityContext:
41	        runAsNonRoot: true
42	        readOnlyRootFilesystem: true
43	      containers:
44	        - name: api-service
45	          image: registry.internal/loginid-poc/api-service:<tag>
46	          resources:
47	            requests: {cpu: "100m", memory: "128Mi"}
48	            limits: {cpu: "500m", memory: "256Mi"}
49	          envFrom:
50	            - configMapRef: {name: api-service-config}   # DB_DRIVER, HTTP_ADDR, AUTH_JWT_ISSUER/AUDIENCE — non-secret
51	          env:
52	            - {name: DB_DSN_FILE, value: /secrets/db/dsn}
53	          volumeMounts:
54	            - {name: db-dsn, mountPath: /secrets/db, readOnly: true}
55	            - {name: jwt-signing-key, mountPath: /secrets/jwt, readOnly: true}
56	          readinessProbe: {httpGet: {path: /healthz, port: 8080}, initialDelaySeconds: 5}
57	          livenessProbe: {httpGet: {path: /healthz, port: 8080}, initialDelaySeconds: 10}
58	      volumes:
59	        - name: db-dsn
60	          secret: {secretName: api-service-db-dsn}
61	        - name: jwt-signing-key
62	          secret: {secretName: api-service-jwt-signing-key}
63	---
64	apiVersion: v1
65	kind: Service
66	metadata: {name: api-service}
67	spec:
68	  selector: {app: api-service}
69	  ports: [{port: 443, targetPort: 8080}]
70	```
71	
72	`idp-connector`'s manifest is the same shape with its own two `Secret` volume mounts (per-vendor client credentials, one `Secret` per vendor per handoff row #5), its own `resources` block (`idp-connector` is I/O-bound waiting on vendor calls, not CPU-heavy — requests `{cpu: 50m, memory: 64Mi}`, limits `{cpu: 250m, memory: 128Mi}`), and no inbound `Service` — it is called by `api-service` or invoked as a job, never exposed to anything outside the cluster. Exact invocation shape (long-running service vs. on-demand job) is undecided; either way the container/image design above doesn't change.
73	
74	**On process vs. host isolation (per 03/Renata, `../PLANNING.md`):** the two-binary split is a process boundary, not a placement guarantee — the `resources.limits` above are what actually enforce it if both Pods land on the same node, on top of (not instead of) 03's own connector-side backpressure (`context.WithTimeout`, bounded retry/backoff, their S4).

{
  "replace_all": false,
  "file_path": "/Users/warrenthompson/Source/LoginID/04-infra-devops/containerization-design.md",
  "old_string": "      serviceAccountName: api-service       # scoped per handoff-04-secrets.md row #2 — this SA's Role can `get` the JWT signing key only from the issuing code path, not the verification path\n      securityContext:\n        runAsNonRoot: true\n        readOnlyRootFilesystem: true\n      containers:\n        - name: api-service\n          image: registry.internal/loginid-poc/api-service:<tag>\n          resources:\n            requests: {cpu: \"100m\", memory: \"128Mi\"}\n            limits: {cpu: \"500m\", memory: \"256Mi\"}\n          envFrom:\n            - configMapRef: {name: api-service-config}   # DB_DRIVER, HTTP_ADDR, AUTH_JWT_ISSUER/AUDIENCE — non-secret\n          env:\n            - {name: DB_DSN_FILE, value: /secrets/db/dsn}\n          volumeMounts:\n            - {name: db-dsn, mountPath: /secrets/db, readOnly: true}\n            - {name: jwt-signing-key, mountPath: /secrets/jwt, readOnly: true}\n          readinessProbe: {httpGet: {path: /healthz, port: 8080}, initialDelaySeconds: 5}\n          livenessProbe: {httpGet: {path: /healthz, port: 8080}, initialDelaySeconds: 10}\n      volumes:\n        - name: db-dsn\n          secret: {secretName: api-service-db-dsn}\n        - name: jwt-signing-key\n          secret: {secretName: api-service-jwt-signing-key}\n---\napiVersion: v1\nkind: Service\nmetadata: {name: api-service}\nspec:\n  selector: {app: api-service}\n  ports: [{port: 443, targetPort: 8080}]\n```\n\n`idp-connector`'s manifest is the same shape with its own two `Secret` volume mounts (per-vendor client credentials, one `Secret` per vendor per handoff row #5), its own `resources` block (`idp-connector` is I/O-bound waiting on vendor calls, not CPU-heavy — requests `{cpu: 50m, memory: 64Mi}`, limits `{cpu: 250m, memory: 128Mi}`), and no inbound `Service` — it is called by `api-service` or invoked as a job, never exposed to anything outside the cluster. Exact invocation shape (long-running service vs. on-demand job) is undecided; either way the container/image design above doesn't change.",
  "new_string": "      serviceAccountName: api-service       # this SA mounts nothing from the signing-key row — see the issuer Deployment below\n      securityContext:\n        runAsNonRoot: true\n        readOnlyRootFilesystem: true\n      containers:\n        - name: api-service\n          image: registry.internal/loginid-poc/api-service:<tag>\n          resources:\n            requests: {cpu: \"100m\", memory: \"128Mi\"}\n            limits: {cpu: \"500m\", memory: \"256Mi\"}\n          envFrom:\n            - configMapRef: {name: api-service-config}   # DB_DRIVER, HTTP_ADDR, AUTH_JWT_ISSUER/AUDIENCE — non-secret\n          env:\n            - {name: DB_DSN_FILE, value: /secrets/db/dsn}\n          volumeMounts:\n            - {name: db-dsn, mountPath: /secrets/db, readOnly: true}\n          readinessProbe: {httpGet: {path: /healthz, port: 8080}, initialDelaySeconds: 5}\n          livenessProbe: {httpGet: {path: /healthz, port: 8080}, initialDelaySeconds: 10}\n      volumes:\n        - name: db-dsn\n          secret: {secretName: api-service-db-dsn}\n---\napiVersion: v1\nkind: Service\nmetadata: {name: api-service}\nspec:\n  selector: {app: api-service}\n  ports: [{port: 443, targetPort: 8080}]\n---\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: api-service-issuer\n  namespace: loginid-poc\nspec:\n  replicas: 2\n  selector:\n    matchLabels: {app: api-service-issuer}\n  template:\n    metadata:\n      labels: {app: api-service-issuer}\n    spec:\n      serviceAccountName: api-service-issuer   # the ONLY SA that mounts the JWT signing key, per handoff-04-secrets.md row #2 / F13's fix\n      securityContext:\n        runAsNonRoot: true\n        readOnlyRootFilesystem: true\n      containers:\n        - name: api-service\n          image: registry.internal/loginid-poc/api-service:<tag>   # same image as api-service — mode selected below, not a separate build\n          resources:\n            requests: {cpu: \"100m\", memory: \"128Mi\"}\n            limits: {cpu: \"500m\", memory: \"256Mi\"}\n          envFrom:\n            - configMapRef: {name: api-service-config}\n          env:\n            - {name: DB_DSN_FILE, value: /secrets/db/dsn}\n            - {name: APP_MODE, value: issuer}   # 02's resolution to F13: same image as the verifying Deployment, a second Deployment/SA, selected by this env var — not a third binary, not a flag (the config surface permits none)\n          volumeMounts:\n            - {name: db-dsn, mountPath: /secrets/db, readOnly: true}\n            - {name: jwt-signing-key, mountPath: /secrets/jwt, readOnly: true}\n          readinessProbe: {httpGet: {path: /healthz, port: 8080}, initialDelaySeconds: 5}\n          livenessProbe: {httpGet: {path: /healthz, port: 8080}, initialDelaySeconds: 10}\n      volumes:\n        - name: db-dsn\n          secret: {secretName: api-service-db-dsn}\n        - name: jwt-signing-key\n          secret: {secretName: api-service-jwt-signing-key}\n```\n\n**Why two Deployments of one image, not RBAC on one:** a `Role` restricting `get` on the signing-key `Secret` does nothing once that `Secret` is already volume-mounted into a container — every replica of that Deployment can read the file regardless of who's allowed to `kubectl get` it. The only way to keep the verification code path (every `api-service` replica) from being able to read the private key is to never mount it there at all. `APP_MODE=issuer` on the second Deployment is 03's addition to the config surface (env-var only, no flags, per `PLANNING.md`); the same binary handles both modes, wired by that variable, not two separate images. This was F13 in the consistency pass — the earlier version of this manifest mounted the key into `api-service` directly, which the RBAC comment here used to (incorrectly) imply was sufficient.\n\n`idp-connector`'s manifest is the same shape with its own two `Secret` volume mounts (per-vendor client credentials, one `Secret` per vendor per handoff row #5), its own `resources` block (`idp-connector` is I/O-bound waiting on vendor calls, not CPU-heavy — requests `{cpu: 50m, memory: 64Mi}`, limits `{cpu: 250m, memory: 128Mi}`), and no inbound `Service` — it is called by `api-service` or invoked as a job, never exposed to anything outside the cluster. Exact invocation shape (long-running service vs. on-demand job) is undecided; either way the container/image design above doesn't change."
}

The file /Users/warrenthompson/Source/LoginID/04-infra-devops/containerization-design.md has been updated successfully. (file state is current in your context — no need to Read it back)

{
  "command": "grep -n \"row #2\\|#2 |\" /Users/warrenthompson/Source/LoginID/04-infra-devops/secrets-delivery.md"
}

12:| #2 | JWT signing private key | File only, never env | Restricted Role scoped to the issuing code path within `api-service`'s own SA — not the verification path, per the hand-off's assumption 2 |
24:No ServiceAccount `get`s or `list`s a `Secret` it doesn't mount — enforced by a `Role`/`RoleBinding` per service, scoped to exactly the `Secret` names in the table above for that service, not a blanket namespace-read grant. Per the hand-off, this is narrower still for row #2: `api-service`'s own SA needs a distinct Role restricting the signing-key `Secret` to the issuing code path, which in practice means either a second SA for the issuer mode or a sidecar/init-container pattern that reads the key and the main container process never does — the exact split is an implementation detail for 03, not a change to this delivery mechanism.

{
  "replace_all": false,
  "file_path": "/Users/warrenthompson/Source/LoginID/04-infra-devops/secrets-delivery.md",
  "old_string": "| #2 | JWT signing private key | File only, never env | Restricted Role scoped to the issuing code path within `api-service`'s own SA — not the verification path, per the hand-off's assumption 2 |",
  "new_string": "| #2 | JWT signing private key | File only, never env | `api-service-issuer` SA only — a second Deployment of the same `api-service` image, selected by `APP_MODE=issuer`. The verifying `api-service` Deployment's SA mounts nothing from this row (`./containerization-design.md`) |"
}

The file /Users/warrenthompson/Source/LoginID/04-infra-devops/secrets-delivery.md has been updated successfully. (file state is current in your context — no need to Read it back)

{
  "replace_all": false,
  "file_path": "/Users/warrenthompson/Source/LoginID/04-infra-devops/secrets-delivery.md",
  "old_string": "No ServiceAccount `get`s or `list`s a `Secret` it doesn't mount — enforced by a `Role`/`RoleBinding` per service, scoped to exactly the `Secret` names in the table above for that service, not a blanket namespace-read grant. Per the hand-off, this is narrower still for row #2: `api-service`'s own SA needs a distinct Role restricting the signing-key `Secret` to the issuing code path, which in practice means either a second SA for the issuer mode or a sidecar/init-container pattern that reads the key and the main container process never does — the exact split is an implementation detail for 03, not a change to this delivery mechanism.",
  "new_string": "No ServiceAccount `get`s or `list`s a `Secret` it doesn't mount — enforced by a `Role`/`RoleBinding` per service, scoped to exactly the `Secret` names in the table above for that service, not a blanket namespace-read grant. Row #2 is why this is a topology decision, not an RBAC one: a `Role` restricting `get` on a `Secret` does nothing once that `Secret` is volume-mounted into a container, so keeping the verification path from reading the signing key means never mounting it into `api-service`'s Deployment at all — hence the second `api-service-issuer` Deployment in `./containerization-design.md`, not a Role scoped \"more narrowly\" on the same Pod."
}

The file /Users/warrenthompson/Source/LoginID/04-infra-devops/secrets-delivery.md has been updated successfully. (file state is current in your context — no need to Read it back)

{
  "command": "cd /Users/warrenthompson/Source/LoginID && sed -i '' 's/consistency-pass fixes applied except F12\\/F13 (pending Marcus)/consistency-pass fixes applied, including F12\\/F13 (issuer split-Deployment topology)/; s/F12\\/F13 resolution from Marcus | — /— | — /' PLANNING.md 2>&1 | head -5\ngrep -n \"04 Infra\" PLANNING.md"
}

14:| 04 Infra & DevOps | Theo Bergman | plan approved — five deliverables drafted, Bree/Callum notes folded in, `backlog.md` written (Epic `LT-4`), consistency-pass fixes applied, including F12/F13 (issuer split-Deployment topology) | — | — | `04-infra-devops/PLAN.md`; `containerization-design.md`, `ci-pipeline.md`, `local-dev-loop.md`, `secrets-delivery.md`, `observability.md`, `backlog.md` | 3 / 3 / 3 | 2026-09-12 |
Shell cwd was reset to /Users/warrenthompson/Source/LoginID/04-infra-devops