Phase 3 · Foundation — how it works, worked, and referenced

For three phases, everyone wrote. Now someone has to build the place where the building happens — and prove it works before a single feature counts on it.

Phase 3 builds the factory, then pushes the thinnest real thing all the way through it — to catch the factory's defects while they're still cheap.

Every idea below is paired with the real thing — examples come from a fictional but fully worked engagement, Harbor Mutual, a regional insurer.

Why this phase exists at all

You don't build features yet — you build the factory that builds them

Three phases settled what to build and how it should be shaped. None of it has run. Foundation is the hinge: the place where the words become a working machine, with one real part already moving through it.

The idea

The product of this phase isn't a feature. It's a factory — a repo with rules, an automated pipeline that checks every change, and the rails an AI agent runs on so nobody has to remember the discipline. Every future change rides those rails.

Build the factory and stop there, and you've proven nothing. So Foundation also runs the thinnest possible slice of real software all the way through — to prove the factory actually works, with software, not with a diagram.

At Harbor Mutual

Harbor had a signed problem, signed requirements, and a chosen architecture — and not one line of it running anywhere.

What Foundation produced for Harbor

"A working factory with one part already moving through it: a portal claim flows end-to-end in Harbor's own dev environment, through the real pipeline, with the claim-to-decision clock ticking."

Not a feature. A factory — and proof it runs.

Skip the "prove it" half and…

You ship a pipeline that's green because nothing real ever ran through it. The defects stay hidden until Build, when every change trips over them.

Go deeper — the full method

This is the hinge: the phase where the documents stop and the software starts. The harness gets installed, the rails get built, the build loop runs for the first time, and the walking skeleton becomes running code in the client's own dev environment. Foundation closes, and the engagement crosses out of the gated phases and into the continuous Build loop.

Phase 3 answers four questions, and nothing else:

Is the harness real and adapted? The kit installed into the client repo, CLAUDE.md rewritten in the client's own domain, owned by the Setup Owner and reviewed by a deputy.
Are the rails real and enforced? CI hard gates, the grader workflow, the correctness workflow, the security workflow, the deploy pipeline, branch protection, the Bicep dev environment, secrets in the client's vault.
Does the loop actually run? The first specs go Intent → Delegate → Discern → merged → deployed — including at least one HIGH-risk spec — so the loop is proven before Build scales it.
Is the architecture real? The walking skeleton from Phase 2, running end-to-end in the client's dev environment through the real pipeline — proven by software, not by documents.

The full feature backlog, the test and production environments, and any feature breadth beyond the thinnest skeleton are out of scope — they belong to the Build loop and the hardening passes. Foundation builds the narrowest possible real thing on top of the real rails. Its product is not a feature; it is a working factory with one part already moving through it.

Skip the "prove it" half and…

You ship a pipeline that is green because nothing real ever ran through it. The defects stay hidden until Build, when every change trips over them.

The rules the agent works inside

Install the rulebook — then rewrite it in the client's own words

An AI agent is only as good as the context it loads when it starts work. The firm has a reusable starter kit. But a generic starter makes the agent guess the domain — and guesses differ every run.

The idea

The kit lands as a working starting point, not a blank repo: the rulebook, the templates, the checking agents, the pipeline files. It's built and improved between engagements — the client never pays to build it, only to adapt it.

The real work is the adaptation: rewriting the project's rulebook in the client's own domain — their terms, their tech stack, what counts as risky, what "done" means. And it happens in the open, as reviewed changes the client's own engineer reads — their first concrete look at how the pod works.

At Harbor Mutual

The kit was scaffolded in, then the rulebook was rewritten in Harbor's language — reviewed by Wes Carter, Harbor's lead engineer:

What went into Harbor's rulebook

"The domain glossary in Harbor's words (FNOL, PolicyOne, the snapshot replica, the regulatory clock), the .NET / Angular / SQL Server / Azure standards, the risk tiers, and the Definition of Checked."

Wes reviewing those changes was the engagement's first real handoff — rehearsed months before the close.

The trap to resist

The kit installed but not adapted. A generic rulebook means the agent guesses Harbor's domain, and guesses differ per run. The adaptation in the open is the point of the phase, not a formality to rush past.

Go deeper — the full method

The harness is the project's CLAUDE.md, specs, skills, agents, hooks, and settings — the context and rules every AI agent loads when it starts work in the repo. The kit is the firm's reusable engagement starter: templates, the grader and security-reviewer agents, hooks, pipeline YAML, Bicep starters. It is built and improved between engagements — every engagement ends with a retro that feeds improvements back into it — and lives in the firm's own standard repo. Phase 3 installs it into the client's repo and adapts it. The client never pays to build the kit — only to adapt it.

Claude scaffolds the repo from the kit: the CLAUDE.md template, the spec template, settings, skills, the grader and security-reviewer agents, the Stop hook, the workflow YAML, the Bicep starters. Then Claude adapts CLAUDE.md to the client: the domain glossary in the client's own words, the stack standards, the risk taxonomy, the gated paths, the Definition of Checked. A generic CLAUDE.md means agents guess the domain, and guesses differ per run.

The adaptation happens as reviewed PRs the client's lead engineer reads — these are the client team's first concrete look at how the pod works, months before the close transfer. This is Setup Owner craft, reviewed by the deputy.

The kit installed but not adapted

A generic CLAUDE.md means agents guess the domain, and guesses differ per run. The adaptation in the open is the point of the phase, not a formality to rush past.

Why discipline can't be a habit

Build rails, so nobody has to remember the rules

You could ask everyone to always run the tests, always get a second reviewer, always check the work against the spec. People forget. Rails don't. The discipline gets built into the machinery, so every change rides it automatically.

The idea — what the rails are

Automated checks — build, tests, lint, coverage run on every proposed change before it can merge.
A fresh reviewer agent — an AI that didn't write the code reads it against the spec and posts a verdict. It advises; a human decides.
A "you can't stop" rule — a script that refuses to let an agent finish its turn while the build is broken. "Done" stops being the agent's opinion.
Locked merging — no change merges without the checks green, the reviewer having run, and approval from someone who didn't write it.

At Harbor Mutual

Tom Reilly, Harbor's platform engineer, reviewed the five pipeline pieces — the ones he'd operate after the pod left — then locked merging down:

No change merges to the main branch without: the automated checks green, the reviewer agent having run, and one approval from a non-author. Riskier changes add a security review and a named sign-off.

Nobody at Harbor has to remember any of that. Every change runs on the rails by default.

Go deeper — the full method

The rails are all of the enforcement taken together: the CI gates, the grader, branch protection, and the deploy pipeline. Called rails because nobody has to remember them — every change runs on them.

CI — continuous integration: the automated checks (build, tests, lint, test coverage) that run on every proposed change before it can merge. Hard gates.
The grader — a fresh AI agent that did not write the code. It reads the spec and the change and posts a check-by-check verdict on the pull request. It is required to run, but its verdict advises — the human Checker decides.
The Stop hook — a script that fires when an agent tries to finish its turn. If tests fail or the build is broken, it refuses to let the agent stop. "Done" stops being the agent's opinion.
Branch protection — repository settings that make the gates mandatory: no change can merge without CI green, the grader having run, and an approval from someone who didn't write it. risk:high adds the security workflow and a named sign-off.

The whole point is that discipline is built into the machinery, not held in anyone's head. The client's platform engineer reviews the workflows — they operate them after the pod leaves — and the Setup Owner (or a named client admin) turns branch protection on.

The code that builds the factory itself

The environment and the pipeline are the riskiest code — so a human reads every line

This is the phase where the AI writes the most code in the whole opening. And the most heavily guarded — because this code is the factory. Get a feature wrong and you fix the feature. Get the pipeline wrong and you've poisoned every change that follows.

The idea

The cloud environment is defined in version-controlled files, not clicked together by hand — so it can be rebuilt, reviewed, and reasoned about. Same for the pipeline.

Both are rated HIGH risk on purpose: a human reviews every single change. They're hard to undo and they run in production later. The AI drafts; the Setup Owner's deputy and the client's own platform engineer read them before they merge. The AI is never the sole approver of the factory it built.

At Harbor Mutual

Claude drafted the environment definition and the pipeline; Rob (Setup Owner) and Tom (Harbor's platform engineer) reviewed every change.

What the environment included

"App hosting, the buffered queue, and a private, read-only, fully-audited connection to the snapshot replica — provisioned from code, not from clicks."

No part of it was hand-built off the rails to save a day.

The one unrecoverable mistake

A secret in the repo. A key in a commit isn't an edit you undo — it's a rotation event and an audit-log review. Secrets live in the client's vault from day one: never in code, never in the rulebook, never in a spec.

Go deeper — the full method

This is the phase where Claude writes the most code in the whole opening — and where that code is under the tightest gating, because the code is the factory. The risk taxonomy puts IaC and pipeline changes at HIGH for exactly this reason. IaC / Bicep is infrastructure as code: the cloud environment defined in version-controlled files instead of clicked together by hand. Bicep is Azure's language for doing this.

Claude drafts the Bicep for the dev environment; HIGH risk, human-reviewed on every change; the environment provisions from code, not from clicks. Secrets land in the client's Key Vault and GitHub secrets — never in code, never in CLAUDE.md, never in a spec. The data-flow brief goes to client security: what goes to the API, what doesn't, where the keys live, who can see usage.

What Claude never does: merge IaC or pipeline without human review, act as the sole approver of harness work, put a secret anywhere near the repo, or hand-build the skeleton off the rails to save a day. The Setup Owner's deputy and the client's DevOps read the IaC and pipeline before they merge — the both-eyes rule applied to the foundation.

The one unrecoverable mistake

A secret in the repo: a key in a commit is a rotation event and an audit-log review, not an edit. The client's vault from day one, never in code, never in CLAUDE.md, never in a spec.

The thinnest thing that proves the architecture

Build a walking skeleton, not a feature

The temptation is to build something impressive. Resist it. What proves the architecture is the thinnest possible end-to-end slice — bones, no muscle — that touches every layer the design promised.

The idea

A walking skeleton is the narrowest path that runs the whole way through: in one end, out the other, touching every architectural seam once. It proves the architecture works in practice, not on paper.

Everything past that thinnest path is Build scope wearing a Foundation badge. Width here delays the rails being proven and the gate being reached. Hold the skeleton to bones.

At Harbor Mutual

Harbor's skeleton was four slices — and deliberately nothing more:

The four slices, in order

"A portal claim creates a queue entry → a coverage check reads the replica → a test-mode acknowledgment → a metric event. End to end, no width."

One of those slices just emits the success metric — which means Harbor's claim-to-decision clock is measurable from day one of Build, not retrofitted at the end.

The trap to resist

"While we're here, add…" Every slice beyond the thinnest path is Build scope. It delays the proof Phase 3 exists to deliver. Let the backlog carry the rest.

Go deeper — the full method

The walking skeleton is the thinnest end-to-end slice of the system, built first to prove the architecture works in practice, not on paper. It is the narrowest path that runs the whole way through: in one end, out the other, touching every architectural seam once.

Everything past that thinnest path is Build scope wearing a Foundation badge. A feature-rich skeleton — "while we're here, add…" — delays the rails being proven and the gate being reached. Hold the skeleton to the thinnest end-to-end path and let the backlog carry the rest.

The slice that emits the outcome metric gets special attention: it makes the engagement's success metric measurable from day one of Build, so the scorecard has real data before the second feature merges — the metric is not a Phase 9 retrofit.

The feature-rich skeleton

The skeleton is the thinnest end-to-end slice that proves the architecture. Every slice added beyond that is Build scope wearing a Foundation badge — it delays the rails being proven and the gate being reached.

Why the skeleton runs the full discipline

The skeleton is the loop's dress rehearsal — nothing gets skipped

It's tempting to hand-build the skeleton fast, off the rails, "because it's just the skeleton." That's exactly backwards. The skeleton is precisely where the build loop must be proven — on software that's cheap to get wrong.

The idea

Every skeleton slice runs the full loop: someone writes down exactly what's wanted, an agent builds it inside set bounds, then the checks and a non-author prove it before it merges and ships.

And at least one slice must run the HIGH-risk path — tightest bounds, security review, a named sign-off — so the riskiest path is proven before Build ever depends on it. A skeleton built off the rails teaches the team nothing and hides the rails' defects until they're expensive.

At Harbor Mutual

The replica-read slice was HIGH risk — it touched the regulated integration:

Spec 0002 ran the HIGH path: tight agent permissions, the security workflow firing, the security-reviewer agent reading the change, and Dan Kowalski's named sign-off recorded in the change itself.

The HIGH path got proven on cheap software, before any real feature relied on it working.

Go deeper — the full method

The build loop is the per-spec cycle — Intent (decide and write what you want), Delegate (an agent builds it inside set bounds), Discern (checks and a non-author prove it) — that replaces batch implementation phases. A spec is one feature, described in one file in the repo (specs/NNNN-name.md): the goal, what is in and out of scope, testable acceptance checks, and a risk tier. No spec, no build.

Each skeleton slice runs the full loop: the slice triaged into a ready spec (Intent), the agent in plan mode first — reading the repo and proposing an approach but not changing files until a human approves — bounded per spec, the Stop hook refusing to finish on a failing build (Delegate), then the CI gates and grader on the PR and a human Checker (someone who didn't write the change) on the merge (Discern).

At least one slice runs the HIGH-risk path: tight agent permissions, the security workflow firing on the risk:high label and running the security-reviewer agent, a named human sign-off recorded in the PR. The HIGH path of the loop gets proven before Build ever relies on it. The skeleton is the loop's dress rehearsal — nothing gets skipped because it is "only the skeleton."

A rail that's never failed safely isn't proven

Break the rails on purpose — before they break by accident

A pipeline that's green because nothing real ever stressed it has proven nothing. The rails are proven by a change breaking and being caught — not by the configuration files merely existing.

The idea

So you force each failure deliberately and watch the rail hold:

A deliberately failing test — does the "you can't stop" rule actually block?
A planted mismatch between code and spec — does the reviewer agent actually catch and post it?
A known-bad deploy — does the pipeline actually restore the last good version?

A rail that has never failed safely has not been proven. This is a deliberate shakedown, not an accident waiting to happen in Build week three.

At Harbor Mutual

The rails got shaken down on purpose — and one defect surfaced early, for cheap:

The rail that broke first, day five

"The coverage gate miscounted generated files on the very first real slice — found and fixed while it cost an hour, not in Build week three when it would have blocked every change."

Each rail was forced to fail and proven to catch it: the stop rule blocked, the reviewer posted the miss, the deploy rolled back clean.

Go deeper — the full method

The rails get a deliberate shakedown: the Stop hook is proven to actually block a failing build, the grader is proven to actually post on a real PR, deploy-dev is proven to roll back cleanly. A rail that has never failed safely has not been proven.

Force each failure deliberately: a failing test proves the Stop hook blocks, a PR with a planted spec mismatch proves the grader posts the miss, and a known-bad deploy proves the pipeline restores the last good version. The setup review merges any harness corrections found during the week (Setup Owner + deputy).

A pipeline that exists but was never exercised — CI that is green because nothing real ran through it — has proven nothing. The rails are proven by a spec breaking and being caught, not by the YAML being present. This is the day the Build cadences get scheduled and two flow limits get set: the WIP cap (how much work may be in flight at once) and the review-wait tripwire (the wait-time threshold that, once crossed, stops new work starting until the review queue clears).

Now watch the whole thing happen

The two weeks, end to end

You've got the ideas; here's the actual rhythm at Harbor. The two weeks split cleanly: week one is the rails (access, the kit, the environment, the pipeline), week two is the skeleton (the four slices riding the loop, the architecture proven, the rails shaken down, the gate). Step through it.

Day 1 · kickoff & access

Get the keys, and prove they work

The access checklist closes: the pod gets repo access, the Setup Owner gets the power to lock merging, automation is turned on, and secrets start landing in the client's vault. The AI access procured back in Phase 0 gets a live smoke test — does Claude Code actually run on the client's seats and keys? — before anyone depends on it.

Day 2 · the kit, in the open

Install the rulebook, rewrite it in the client's words

The kit gets scaffolded into the client's repo — a working starting point, not a blank page. Then the rulebook gets adapted to the client's domain, stack, and risk tiers, as reviewed changes the client's lead engineer reads. Their first concrete look at how the pod works.

Day 3 · the environment

Provision from code, never from clicks

The AI drafts the cloud environment as version-controlled files — HIGH risk, human-reviewed on every change. Secrets land in the client's vault. A data-flow brief goes to security: what reaches the API, what doesn't, where the keys live, who can see usage.

Day 4 · the pipeline

Build the rails and lock them on

Five workflows get built and reviewed by the client's platform engineer: the automated checks, the reviewer agent, the correctness review, the security review, and the deploy. Then merging gets locked down — checks green, reviewer ran, non-author approval; risky changes add security plus a named sign-off. The Phase 2 security gates get wired in.

Day 5 · first slice through the loop

Real software hits the rails for the first time

The first skeleton slice runs the full loop end to end: written down, built by a bounded agent in plan mode, checked, approved by a non-author, deployed to dev automatically. Anything broken in the rails surfaces here, while it's cheap — at Harbor, a coverage-gate defect, fixed in an hour. End of week one: one slice live in dev through the real pipeline.

Day 6 · the first HIGH-risk slice

Prove the riskiest path before Build needs it

The slice touching the riskiest seam runs the loop at HIGH risk: tight permissions, the security workflow firing, the security-reviewer agent reading the change, a named human sign-off recorded. At Harbor that was the regulated replica read — proven before Build ever relied on the HIGH path working.

Day 7 · the remaining slices

Finish the skeleton — including the metric

The rest of the slices ride the loop. The slice that emits the success metric gets special attention — it makes the engagement's number measurable from day one of Build. Any security gate these slices touch fires on its first qualifying change; if none touch it, a throwaway probe change proves it fires anyway.

Day 8 · the skeleton, end-to-end

Connect the bones and walk them

The slices connect into a running skeleton in dev. The Quality Engineer verifies it against the Phase 2 definition: does it actually prove the architecture, end to end, under the rails? A first automated smoke journey walks the same path a user would — the thinnest proof the whole thread holds together.

Day 9 · harden the rails

Break the rails on purpose

A deliberate shakedown: force a failing build to prove the stop rule blocks, plant a spec mismatch to prove the reviewer posts the miss, ship a known-bad deploy to prove the rollback works. The setup review merges any harness corrections. The Build cadences get scheduled and two flow limits get set.

Day 10 · gate, demo, handoff

Working software in the client's environment

The automated gate check runs. The sponsor watches the walking skeleton run in their own dev environment, through the real pipeline, with the outcome metric ticking — working software, not slides. The Build handoff gets drafted, sign-off gets recorded, and the engagement crosses out of the gated opening into the continuous Build loop. Billing milestone.

1 / 10

Go deeper — the full method

The default calendar is two weeks (10 business days) — the longest of the opening phases, because it builds the factory and runs the first software through it. Week one is the rails: access, the kit install, the environment, the pipeline. Week two is the skeleton: the four slices riding the loop, the architecture proven end-to-end, the rails shaken down, the gate.

Week one — the rails

Day 1, kickoff and access. The Phase 0/1 access checklist closes: contributor access for the pod, branch-protection admin for the Setup Owner, GitHub Actions enabled, runner policy agreed, secrets provisioning started in the client's Key Vault. The Anthropic access procured in Phase 0 gets a live smoke test — Claude Code actually runs on the client's seats and keys. The Phase 2 open questions get their owners and due dates re-confirmed.
Day 2, the kit install, in the open. Claude scaffolds the client repo from the kit; CLAUDE.md gets adapted to the client's domain, stack, risk taxonomy, and Definition of Checked — as reviewed PRs the client's lead engineer reads.
Day 3, the dev environment. Claude drafts the Bicep; HIGH risk, human-reviewed on every change; provisions from code. Secrets land in the client's vault; the data-flow brief goes to security.
Day 4, the pipeline. The five workflows get built and reviewed by client DevOps (CI, grader, correctness, security, deploy-dev). Branch protection turns on. The build-time security gates from the Phase 2 threat review get wired into the security workflow.
Day 5, the first slice through the loop. The first skeleton spec runs the full build loop: Intent, Delegate (plan mode, bounded, the Stop hook), Discern (CI + grader, a human Checker), then the automatic deploy to dev. Anything broken in the rails gets found and fixed here, while it is cheap. End of week one: one slice live in dev.

Week two — the skeleton

Day 6, the first HIGH-risk slice. The slice that touches the riskiest seam runs the loop at HIGH risk: tight agent permissions, the security workflow firing on risk:high, a named sign-off in the PR. The HIGH path gets proven before Build relies on it.
Day 7, the remaining slices. The rest ride the loop. The metric-emitting slice gets special attention. Any build-time security gate these slices touch fires on its first qualifying PR — proven, not just configured; if none touch a gate, a probe PR proves it.
Day 8, the skeleton, end-to-end. The slices connect into the running skeleton in dev. The QE verifies it against the Phase 2 walking-skeleton definition. A first E2E smoke journey walks the whole thread.
Day 9, harden the rails, not the features. The deliberate shakedown. The setup review merges harness corrections. The Build cadences get scheduled and the WIP cap and review-wait tripwire get set.
Day 10, gate, demo, and the handoff into Build. The automated gate check runs. The exit demo: the sponsor sees the walking skeleton running in their own dev environment, through the real pipeline, with the outcome metric ticking. The Build handoff gets drafted; gate sign-off recorded; billing milestone. The engagement enters the Build loop.

When the two weeks stretch

Access or secrets provisioning stalls → a gating dependency, surfaced at steering on day one, not absorbed silently. The dev environment fights the IaC → expected friction, exactly what Phase 3 exists to discover before Build. A skeleton slice exposes a design gap → good; re-open the relevant ADR explicitly rather than patching around it. The client wants to widen the skeleton → that is Build scope; hold to the thinnest path.

How it goes wrong

The failure modes, and the defense against each

Every one of these has happened to someone. Knowing them by name is half the defense — and Harbor's structure caught some of them in the act.

The trap	What it looks like	The defense	At Harbor
"It's just the skeleton"	Hand-building the skeleton fast, off the rails, to save a day	The skeleton is where the loop must be proven. Every slice runs the full discipline.	All four slices rode the full loop
The pipeline that never ran	CI green because nothing real ever went through it	Prove rails by a change breaking and being caught, not by the YAML being present.	Caught — the day-9 shakedown
The kit, not adapted	A generic rulebook the agent has to guess against	Rewrite it in the client's words, in the open. Guesses differ per run.	Adapted in PRs Wes reviewed
Factory code merged unread	Environment or pipeline merged without review "to move faster"	HIGH risk, human-reviewed every change. Setup Owner is never sole approver.	Rob + Tom read every change
A secret in the repo	A key in a commit — the one unrecoverable mistake	Client's vault from day one; never in code, the rulebook, or a spec.	No secret touched the repo
The feature-rich skeleton	"While we're here, add…" — Build scope in a Foundation badge	Hold to the thinnest end-to-end path; let the backlog carry the rest.	Held to four bones-only slices
The demo on a laptop	A localhost demo that proves only that the code compiles	Demo in the client's own dev environment, through the real pipeline.	Ran in Harbor's dev environment

Go deeper — the full method

Skipping the loop "because it's just the skeleton." The skeleton is precisely where the loop must be proven. A skeleton hand-built off the rails teaches the team nothing and hides the rails' defects until Build, when they are expensive.
A pipeline that exists but was never exercised. CI that is green because nothing real ran through it. The rails are proven by a spec breaking and being caught, not by the YAML being present. A rail that has never failed safely has not been proven.
The kit installed but not adapted. A generic CLAUDE.md means agents guess the domain, and guesses differ per run. The adaptation in the open is the point of the phase.
IaC or pipeline merged without review to move faster. HIGH risk because they are hard to undo and run in production later. The Setup Owner is never the sole approver of their own foundation — the deputy and the client's DevOps read every change.
A secret in the repo. The one unrecoverable mistake: a key in a commit is a rotation event and an audit-log review, not an edit. The client's vault from day one.
A feature-rich skeleton. Every slice beyond the thinnest end-to-end path is Build scope wearing a Foundation badge — it delays the rails being proven and the gate being reached.
Deferring the deputy. "I'll name a deputy later" means the Setup Owner is approving their own foundation right now. The deputy is named on day one.
The demo on a laptop. The exit demo runs in the client's own dev environment, through the real pipeline, or it has not proven what Phase 3 exists to prove. A localhost demo proves the code compiles, not that the factory works.

When Phase 3 is done

The opening ends, and the factory takes over

Foundation closes with a working factory and one part already moving through it: the rails proven by failing safely, the skeleton running in the client's own environment, the success metric already ticking. The four gated phases are done; from here, every change rides the continuous Build loop. Where to go next:

The Build Loop →What the factory was built for — how every change from here gets specified, bounded, built, and proven. The Example view →The complete Harbor foundation — every spec, the pipeline, the Bicep, the gate, with every ID.

Five files land on disk, three things arrive only as knowledge, and two questions are still open

What Phase 3 received

Phase 2 closed Friday 2026-03-27 with four signed ADRs, contracts carrying REQ-014's error spec, two build-time security gates named, and a walking skeleton sliced into four specs. Harbor Mutual — a fictional regional insurer rebuilding how property-insurance claims get reported and decided, cutting an 11.4-day median from FNOL (first notice of loss) to a coverage decision down to 5 days or less — had a signed problem, signed requirements, and a chosen architecture, and not one line of it running anywhere. Foundation turns that into running software.

Inherited from Phase 2 — on disk under .sdlc/artifacts/02-design/ phase3-handoff.md design-doc.md api-contracts.md adrs/ + adr-registry.md deep-plan-checkpoint.yaml

Also inherited — but as knowledge in a head, because Phase 2 wrote no file for any of them the walking-skeleton definition the threat mitigation map — becomes the risk-tier map the NFR proving plan

Read that second row twice. Three of the things Phase 3 builds directly on never became files. The method required each of them; no command in claude-code-sdlc wrote any of them. They cross the boundary as what Nadia and Rob remember from Phase 2's Thursday — which is exactly why the people who were in that room are the people who build the foundation.

The architecture Phase 3 has to make real

Coverage checks read the nightly snapshot replica of PolicyOne directly (ADR-001), behind a verification service that owns the staleness contract. Claims live in a relational model plus an append-only event log (ADR-002). Surge is absorbed by a buffered ingestion queue and autoscaling (ADR-003). Email FNOL is extracted by an LLM with per-field confidence thresholds (ADR-004). Every one of those four mechanisms has to be exercised at least once by the walking skeleton — that is what makes the skeleton a proof rather than a demo.

What crossed on disk, and what didn't

The signed decisions, the contracts, and the planner's session state are files Phase 3 can open. The three things it most needs to act on — the exact slice to build, the two gates to wire, the numbers to prove — are not.

The walking-skeleton definition. Four slices, portal FNOL to metric event. Nadia carries it; on day 8 she verifies the running skeleton against it.
The threat mitigation map. Nine threats, seven mitigated in the design, two handed forward as build-time security gates. It becomes risk-tier-map.md this phase.
The NFR proving plan. Per quality target, the method and the place its number is read — the input to how the metric slice gets built.

Where the two weeks are headed

Week one builds the factory: access, the kit, the environment, the pipeline. Week two proves it, by pushing the thinnest real software all the way through — including one HIGH-risk slice — and then breaking the rails on purpose to prove they catch.

Two people to watch. Wes Carter, Harbor's lead engineer, reviews the harness adaptation — the first real handoff, months before the close. Tom Reilly, Harbor's platform engineer, joins this phase: he holds branch-protection admin, the runners, and the secrets, and reviews the pipeline he will operate after the pod leaves.

Carried in from Phase 2, still open on Monday

Q-17 — postal dispatch vendor and who provisions its credentials (Dan + Harbor ops) · Q-18 — the surge load-test dataset from the 2024 CAT event (Priti + Nadia)

Our pod

Maya ChenPod Lead — triages the skeleton into specs, runs the exit demo, owns the Build handoff

Rob FeldSetup Owner — the harness as a product; owns branch protection and secrets; never sole approver

Jonah KimOrchestrator / Checker — Setup Owner's deputy; authors spec 0002; reviews every harness change

Sara WhitfieldOrchestrator / Checker — authors the first slice; Checks and merges spec 0002

Nadia BrooksQuality Engineer — wires the gates, verifies the running skeleton against the Phase 2 definition

Harbor Mutual

Karen VossVP Claims Operations — sponsor; watches the exit demo, approves the advance

Wes CarterLead engineer — Setup Owner counterpart; reviews the CLAUDE.md adaptation PRs

Tom ReillyPlatform engineer — branch-protection admin, runners, secrets; reviews the pipeline

Dan KowalskiIT security — signs the data-flow brief; named sign-off on spec 0002; confirms the gates

Luis OrtegaProduct owner — confirms the skeleton is the right thinnest slice; light touch

The ID codes, decoded

Every artifact in this engagement carries a stable identifier, so a decision made in design week can still be traced in month nine. The ones Foundation leans on:

Prefix	Means	Born in	Example here
`ADR-NNN`	An architecture decision record — a signed choice	Phase 2	ADR-001 replica read · ADR-003 buffered queue
`REQ-NNN`	A functional requirement	Phase 1	REQ-014 same-business-day coverage · REQ-019 fast path
`C-NN` / `D-NN`	A constraint, or a product decision	Phase 0/1	C-04 regulatory clock · D-07 merge · D-09 fast path
`Q-NN`	An open question with an owner and a due date	any	Q-15 replica controls · Q-17, Q-18, Q-19
`NFR-NN`	A non-functional requirement — a quality target	Phase 1	NFR-02 the 10x surge
`NNNN`	A build spec — one feature in one file, `specs/NNNN-name.md`	Phase 3 on	0001–0004, the walking-skeleton slices

The spec ID is new this phase. From here to close, no code changes without a specs/NNNN-name.md in front of it — the unit the whole Build loop turns on.

The machine's eleven steps, the humans' ten days, braided

The procedure, step by step

Foundation is the least plugin-driven phase of the opening. Most days are code and rails, not drafts, so most carry no plugin command — the machine goes quiet and the humans build. Below, the two weeks are braided: what the tool does when it does anything, what the humans do that no command performs, and the file each day leaves behind. Step through it.

Legend a command does it — and writes the file a person does it — and it is recorded a person does it — and nothing records it

Day 1 — Mon 3/30 · plugin Step 0 HITL gate

Get the keys, prove they work, and confirm the plan before installing anything

Before the harness touches the repo, the plugin opens a blocking human gate: confirm which single skeleton slice carries the highest risk, confirm where the dev environment lives and who holds branch-protection admin, Actions, runner policy, and the secrets vault, and name the Setup Owner's deputy. Then the access checklist closes and the AI access procured in Phase 0 gets a live smoke test — does Claude Code actually run on the client's own seats and keys, before anyone depends on it?

Tooling /sdlc-next → Step 0 HITL gate human decision

Out the rails plan and the deputy, confirmed — not yet on disk

At Harbor

Pod contributor access granted; Rob gets branch-protection admin; Tom enables Actions and agrees Harbor-hosted runners; secrets provisioning starts in Harbor's Key Vault. Jonah is named Setup Owner's deputy. The smoke test passes — Claude Code runs on Harbor's seats and keys, the Phase 0 fallback rider never needed. Q-17 and Q-18 get their owners and due dates re-confirmed.

Day 2 — Tue 3/31 · plugin Step 1

Install the rulebook, then rewrite it in the client's own words

Claude scaffolds the repo from the firm's kit — the CLAUDE.md template, the spec template, settings, skills, the grader and security-reviewer agents, the Stop hook, the workflow YAML, the Bicep starters. A working starting point, not a blank page, built and improved between engagements so the client never pays to build it. Then the real work: adapting CLAUDE.md to the client's own domain, stack, risk taxonomy, and Definition of Checked — as reviewed PRs the client's lead engineer reads.

Tooling none — Claude scaffolds from the kit; the adaptation lands as reviewed PRs

Out — committed at the repo root, not under .sdlc/ CLAUDE.md specs/ .claude/settings.json .claude/hooks/stop-gate.ps1 .claude/agents/grader.md harness-inventory.md

At Harbor

CLAUDE.md rewritten in Harbor's language, reviewed by Wes: the domain glossary (FNOL, PolicyOne, the snapshot replica, the fast path at 61%, D-07 merge, the C-04 regulatory clock), the .NET 8 / Angular / SQL Server / Azure standards, the risk tiers, and the Definition of Checked. Wes reviewing those PRs was the engagement's first real handoff — rehearsed months before the close.

Day 3 — Wed 4/1 · plugin Step 4

Provision the environment from code, never from clicks

Claude drafts the dev environment as version-controlled Bicep — rated HIGH risk on purpose, so a human reads every line. The environment provisions from code, not from a portal, so it can be rebuilt and reasoned about. Secrets land in the client's vault. A data-flow brief goes to security: what reaches the API, what doesn't, where the keys live, who can see usage.

Tooling none — Claude drafts the Bicep against the kit starters; two humans review every change

Out infra/ — the Bicep dev environment data-flow brief — the standard requires it; the plugin emits no file

At Harbor

Rob and Tom review every Bicep change. It provisions app hosting for the intake service and the Angular portal, the buffered ingestion queue (ADR-003) sized for dev, and a private, read-only, fully-audited endpoint to the snapshot replica under the Q-15 controls. Key Vault references hold the Anthropic key, the Azure credentials, and the replica service account — no secret in code, in CLAUDE.md, or in any spec. Dan gets the data-flow brief.

The gap you should know about

The standard lists a data-flow brief as a Phase 3 artifact — client security has, in writing, what goes to the API and where the keys live. The plugin's registry lists no such file. Dan gets the briefing; nothing on disk records that he did. Human work, no receipt.

Day 4 — Thu 4/2 · plugin Steps 2–3

Build the rails, lock them on, and confirm the Phase 2 gates got wired

Five workflows get built and reviewed by the client's platform engineer — the CI checks, the grader, the correctness review, the security review, and the deploy. Then branch protection turns on: nothing merges without CI green, the grader having run, and a non-author approval; risk:high adds the security workflow and a named sign-off. The risk-tier map gets written from Phase 2's threat mitigation map — and this is the confirmation pass on the threat review: are the two build-time security gates from Phase 2 actually wired into the risk-tier map and the security workflow?

Tooling none — Claude drafts the workflow YAML and the risk-tier map; client DevOps reviews

Out .github/workflows/{ci,grader,correctness,security,deploy-dev}.yml risk-tier-map.md branch protection — a GitHub setting, not a committed file

At Harbor

Tom reviews the five workflows he will operate after the pod leaves; Rob turns on branch protection. The two Phase 2 gates get wired into security.yml: the document-upload malware scan (HIGH tier) and the acknowledgment-letter PII template-review gate, each registered against the path it guards so it fires independent of a spec's risk label.

The threat review is a live method question

The standard runs a design-level threat review in Phase 2, producing the mitigation map. The plugin mentions threat modeling in only one place — phases/03-foundation.md. The resolution taken here: it is genuinely both. Phase 2 is the design-level review; this is the foundation-level confirmation pass that the two gates it named actually got wired. Two passes, two phases, one map — logged as drift so the plugin repo can put the design-level step back where it belongs.

Day 5 — Fri 4/3 · plugin Step 5a

Real software hits the rails for the first time

The first skeleton spec rides the full Build loop end to end: authored from the kit template (Intent), built by a bounded agent in plan mode with the Stop hook refusing to finish on a broken build (Delegate), then CI and the grader on the PR and a non-author on the merge (Discern), then the automatic deploy to dev. Whatever is broken in the rails surfaces here, on cheap software, while it costs an hour.

Tooling /sdlc-spec → new_spec.py then the spec rides the loop — agent, hooks, gates, human Checker

Out specs/0001-queue-entry.md one slice live in dev via deploy-dev.yml

At Harbor

Spec 0001 (queue entry from a portal FNOL, MEDIUM): Sara authors it, the agent codes in plan mode under bounds, the Stop hook refuses on a failing build, the PR fires ci.yml and grader.yml, Jonah (non-author) approves and merges, deploy-dev.yml ships to dev. The coverage gate miscounts generated files on this very first run — found and fixed for an hour, not in Build week three when it would have blocked every PR.

Day 6 — Mon 4/6 · plugin Step 5b — a hard exit condition

Prove the riskiest path before Build ever depends on it

At least one slice must run the HIGH-risk path — tightest agent permissions, the security workflow firing, the security-reviewer agent reading the change, a named human sign-off recorded in the PR. The plugin marks this a hard exit condition: the HIGH path of the loop gets proven on cheap software, before any real feature relies on it working.

Tooling none — the HIGH-risk spec rides the loop; risk:high fires security.yml

Out specs/0002-replica-read.md Dan's named security sign-off in the PR

At Harbor

Spec 0002 (replica verification read) touched the regulated integration, so it ran HIGH: tight permissions, the risk:high label firing security.yml and the security-reviewer agent, Dan's named sign-off. The Q-15 controls were verified live against dev the same afternoon; ADR-001's staleness contract went in as real behavior. Reproduced in full in section 05.

Day 7 — Tue 4/7 · plugin Step 5c

Finish the skeleton — including the slice that emits the metric

The remaining slices ride the loop. The slice that emits the outcome metric gets special attention: it makes the engagement's number measurable from day one of Build, not retrofitted at the end. Any build-time security gate these slices touch fires on its first qualifying PR — proven, not just configured; if none touch a gate, a throwaway probe PR proves it fires anyway.

Tooling none — the specs ride the loop

Out specs/0003-ack-testmode.md specs/0004-metric-event.md the outcome metric measurable in dev — a property, not a file

At Harbor

Spec 0003 (test-mode acknowledgment, MEDIUM) is the first PR to touch acknowledgment templates, so the PII template-review gate fires live — proven, not just wired. Spec 0004 (metric event, LOW) emits the FNOL→coverage clock as a structured event; Harbor's headline number becomes measurable from Build day one. The document-upload malware gate had no qualifying PR yet, so a probe PR proved it fires, then closed unmerged.

Day 8 — Wed 4/8 · plugin Step 5d

Connect the bones and walk them

The slices connect into a running skeleton in dev: portal FNOL → queue entry → replica coverage check → test-mode acknowledgment → metric event. The Quality Engineer verifies it against the Phase 2 walking-skeleton definition — the one that never became a file. A first automated smoke journey walks the whole thread, the thinnest proof it holds together end to end.

Tooling /e2e → smoke journey

Out walking-skeleton-spec.md — per-slice loop evidence the deployed skeleton, verified — running software, not a file

At Harbor

Nadia walks the four slices against what she carried out of Phase 2's Thursday and confirms the architecture is proven in running software, not on paper. The E2E smoke journey follows the same path a claimant would. The verification has no artifact of its own — it is Nadia's judgment against a definition that only ever lived in her notes.

Day 9 — Thu 4/9 · plugin Steps 6–7

Break the rails on purpose — before they break by accident

A pipeline that is green because nothing real ever stressed it has proven nothing. So each rail gets forced to fail and watched to catch it: a deliberately failing build, a planted spec mismatch, a known-bad deploy. Then the cadence plan gets set — the flow check, intent triage, retro+, and setup review scheduled, and two flow limits agreed. This is human work end to end; the plugin prompts none of it and checks none of it.

Tooling none — a deliberate manual shakedown, then the humans set the cadences

Out pipeline-proof.md cadence-plan.md

At Harbor

The failing build proves the Stop hook blocks; the planted mismatch proves the grader posts; the bad deploy proves deploy-dev.yml rolls back to the last good version. The setup review (Rob + Jonah) merges the week's harness corrections. WIP cap set at two streams per Orchestrator; the review-wait tripwire at a one-working-day median. Q-17 lands (the postal vendor); Q-19 surfaces (its sandbox credentials, owner Tom + Harbor ops).

The shakedown has no automated witness

“The rails are proven, not just present” is one of the plugin's exit conditions — but check_gates.py can only confirm that pipeline-proof.md exists and is non-empty. It cannot know whether the Stop hook truly blocked or whether a human simply wrote that it did. The most important verification of the phase rests entirely on a human's word.

Day 10 — Fri 4/10 · plugin Steps 8–10 · the gate

Working software in the client's environment, then the gate

The machine returns for the finish. The gate check runs, the phase report renders, the sponsor watches the walking skeleton run in their own dev environment through the real pipeline with the outcome metric ticking — working software, not slides — and a named human on each side signs the advance. advance_phase.py will not move the engagement into Build without --confirmed.

Tooling /sdlc-gate → check_gates.py /sdlc-phase-report → generate_phase_report.py /visual-explainer /sdlc-next → advance_phase.py --confirmed

Out build-handoff.md foundation-report.md .sdlc/reports/phase03-report.html the sponsor's signature — billing milestone 4

At Harbor

The gate passes; the report renders. Karen watches a portal FNOL flow end to end in Harbor's dev environment with the clock ticking on the scorecard. Rob and Wes walk the harness, Tom confirms the pipeline, Dan confirms the gates, Karen approves. /sdlc-next advances into the Build loop. The four gated phases are done.

What the gate actually checks

The plugin's registry lists eleven exit conditions — branch protection enforced, each security gate fired on a real PR, the outcome metric measurable, the rails proven. But check_gates.py verifies only that four files exist and are placeholder-free, and renders the rest as manual REVIEW items it never blocks on. The human gate is real. Most of what it should be signing against, no code puts in front of them.

1 / 10

Everything that exists on Friday and didn't two weeks earlier

What Phase 3 produced

Foundation's output is a working factory, not a document set — which is why the ledger reads differently here. Blue rows are files committed to the repo and checked by the gate. Amber rows are the phase's real product that no file captures: running software, a GitHub setting, a briefing, an event that ticks. Those are the rows to argue about — because the gate's own exit conditions turn on them, and the gate cannot see them.

Artifact	What it actually is	Written by	Signed by	Lives at	Feeds
CLAUDE.md + .claude/ + specs/	The installed, adapted harness — the rulebook, templates, skills, the grader and security-reviewer agents, the Stop hook. The rules every agent loads before it works	Claude scaffolds from the kit; Setup Owner adapts	Setup Owner + deputy	`CLAUDE.md`, `.claude/`, `specs/`	Every Build spec, forever
workflows (×5)	ci, grader, correctness, security, deploy-dev — the rails as code: hard checks, a fresh-agent verdict, defect-hunt, security pass, the deploy	Claude drafts the YAML	Setup Owner + client DevOps	`.github/workflows/`	Every PR in Build
infra/ (Bicep)	The dev environment as version-controlled code: app hosting, the buffered queue, the private replica endpoint. Provisioned, not clicked	Claude drafts; Setup Owner + platform engineer review every change	Setup Owner	`infra/`	deploy-dev; Phase 8
specs/0001–0004.md	The four walking-skeleton slices, each authored from the kit template and ridden through the full loop	Orchestrators, from the kit spec-template	Pod Lead (triage)	`specs/`	The running skeleton
risk-tier-map.md	HIGH/MEDIUM/LOW taxonomy mirroring CLAUDE.md, with the two Phase 2 security gates registered against the paths they guard	Setup Owner, from the Phase 2 mitigation map	Setup Owner + client security	`.sdlc/artifacts/03-foundation/`	The Build loop's tier→ladder rule
cadence-plan.md	The Build calendar — flow check, intent triage, retro+, setup review — plus the WIP cap and review-wait tripwire; bans activity metrics	Pod Lead	Pod Lead	`.sdlc/artifacts/03-foundation/`	Every Build week
pipeline-proof.md	The forced-failure evidence: each rail broken on purpose and shown to catch it	Setup Owner + deputy	Setup Owner	`.sdlc/artifacts/03-foundation/`	foundation-report.md; the gate
harness-inventory.md walking-skeleton-spec.md	The record of what got installed, and the per-slice loop evidence for the skeleton	Setup Owner / QE	Setup Owner	`.sdlc/artifacts/03-foundation/`	Close harness audit; QE verification
build-handoff.md foundation-report.md	The ordered spec backlog, risk-tier map, cadences, and open questions — plus the phase's own summary and forced-failure cross-reference	Pod Lead / Setup Owner	Pod Lead	`.sdlc/artifacts/03-foundation/`	The Build loop, directly
phase03-report.html	The gate result and artifact inventory, self-contained — what the sponsor reads before signing	`generate_phase_report.py`	—	`.sdlc/reports/`	The manual sign-off gate
the deployed walking skeleton	The four slices running end-to-end in the client's dev environment, verified against the Phase 2 definition. The phase's whole point — and running software, not a file	The loop; QE verifies	Setup Owner + QE	no path — running software, not a file	The Build loop; Phase 8
branch protection	The rule that makes the rails mandatory: CI green + grader-ran + non-author approval; `risk:high` adds security + a named sign-off	Setup Owner, in GitHub	Setup Owner	no path — a GitHub setting, not a file	Every merge, forever
data-flow brief	What goes to the API, what doesn't, where the keys live, who sees usage — in security's hands, in writing	Setup Owner	Client security	no path — the plugin emits no file	Security sign-off
the security gates, fired	Proof that each build-time gate actually fired on a real (or probe) PR — not just that it is configured	The security workflow, on a PR	Client security	no path — PR history, not a committed file	The gate's “each has fired” check
the outcome metric, ticking	The FNOL→coverage clock, measurable in dev from the metric slice — the scorecard has real data before feature two	Spec 0004, running	QE	no path — a measured property, not a file	The scorecard; Phase 9

Read the amber rows again

Five of the things Foundation is judged on have nowhere to live. Four of the plugin's eleven exit conditions — the skeleton deployed and verified, the rails proven, each security gate fired, the metric measurable — describe running software and GitHub state, and check_gates.py can confirm none of them. The factory is real; the receipt that it works is a human's word. Human work is not the problem. Human work without a receipt is.

Deliberately not produced in Phase 3: the full feature backlog (Build triage owns it), the test and production environments (the first hardening pass and Phase 8 add them), and any feature breadth beyond the thinnest skeleton.

The adapted rulebook, the five workflows, and the environment — as shipped

Install the rulebook, then rewrite it in the client's own words

The factory is three things committed to Harbor's repo: a rulebook rewritten in Harbor's language, five workflows that enforce the discipline so nobody has to remember it, and a dev environment defined in code. Each is reviewed by the Harbor engineer who will own it after the pod leaves.

The adapted CLAUDE.md (the shape)

Scaffolded from the kit, adapted to Harbor in PRs Wes reviewed. The full file is longer; this is the shape:

What this project is — Harbor's property-claims intake rebuild; the FNOL→coverage median target of ≤5 days, and where that number is read from.
Domain glossary (Harbor's words) — FNOL, PolicyOne, the snapshot replica, the fast path (61% of claims, D-09), the duplicate-merge rule (D-07), the regulatory clock (C-04: 15 business days in two states).
Stack standards — .NET 8 / Angular / SQL Server / Azure / GitHub Actions, immutability defaults, Result<T> for expected failures, FluentValidation at the boundary.
Risk taxonomy — HIGH (the replica adapter, infra/, migrations/, auth, acknowledgment-letter templates, public API contracts); MEDIUM (new business logic, integrations); LOW (UI in existing patterns, copy, additive CRUD).
Gated paths — infra/, the replica adapter, migrations/, acknowledgment templates: the agent asks before touching these.
Definition of Checked — the spec's acceptance checks pass; the Stop hook is green; the grader has run; a non-author approved; HIGH risk carries a named sign-off.

The pipeline — five workflows

Built and reviewed by Tom; branch protection enforcing them:

Workflow	Trigger	What it does	Blocks?
`ci.yml`	Every PR	Build, test, lint, 80% coverage on new code	Hard block
`grader.yml`	Every PR	A fresh agent reads the spec in the diff, posts a check-by-check verdict	Required to run; verdict advisory
`correctness.yml`	Every PR	A fresh agent hunts for defects in the diff, posts high-confidence findings	Blocks on a high-confidence defect
`security.yml`	`risk:high` label or a gated path	Runs the security-reviewer agent over the diff	Pass + named sign-off required to merge
`deploy-dev.yml`	Merge to `main`	Ships to Harbor's dev environment; restores the last good version on a failed deploy	— (deploy step)

Branch protection on main: CI green + grader-ran + one non-author approval. risk:high adds security.yml passing and a named human sign-off recorded in the PR.

The Bicep dev environment, and the wired security gates

infra/ — provisioned from code

Resource group + app hosting for the intake service and the Angular portal.
The buffered ingestion queue (ADR-003), sized for dev; the surge load test waits on Q-18 and a test environment at hardening pass 1.
The private endpoint to the snapshot replica under the Q-15 controls — read-only service account, no public path, every access audited.
Key Vault references for the Anthropic key, the Azure credentials, and the replica service account. No secret in code, CLAUDE.md, or any spec.

The two build-time security gates, wired

The two gates Phase 2's threat review handed forward, now enforced in security.yml and each fired on a real (or probe) PR:

Document-upload malware scan — HIGH tier

Runs on every PR touching the upload path. The upload path itself is a Build spec, so a throwaway probe PR proved the gate fires, then closed unmerged.

Acknowledgment-letter PII template-review — fired live on 0003

Triggers on the templates path itself, independent of the risk label — which is why it fired on spec 0003's MEDIUM PR. PII leaves the system on paper, so a human reviews any template change.

The one unrecoverable mistake

A secret in the repo. A key in a commit is a rotation event and an audit-log review, not an edit. Harbor's Key Vault held the Anthropic key, the Azure credentials, and the replica service-account reference from day one — the data-flow brief gave Dan what he needed to sign off without a single secret in a commit.

The HIGH-risk slice, reproduced whole — the loop's dress rehearsal

The skeleton is the loop's dress rehearsal — nothing gets skipped

Harbor's skeleton was four slices and deliberately nothing more: a portal claim creates a queue entry → a coverage check reads the replica → a test-mode acknowledgment → a metric event. End to end, no width. Spec 0002 (replica verification read) was the HIGH-risk one — it touched the regulated integration and the Q-15 controls, and it ran the loop at HIGH risk on day 6, on cheap software, before any real feature relied on it. This is one specs/NNNN-name.md in full.

Spec 0002 — Replica verification read

Risk tier: HIGH · Authored: Jonah Kim · Checked: Sara Whitfield · Security sign-off: Dan Kowalski · Merged 2026-04-06

Goal. A coverage-verification service reads the PolicyOne snapshot replica directly (ADR-001) and returns coverage status with an as-of timestamp, honoring the staleness contract.

Why. REQ-014 promises same-business-day coverage status; ADR-001 chose the replica read as the source. This slice proves the integration and its degradation behavior in running software.

Scope in. The replica adapter, the verification service, the staleness contract (as-of timestamp; >36h escalates; refresh-window 02:00–04:30 degrades to pending-verification). Scope out. The fast-path escalation logic (REQ-019, a Build spec); real acknowledgment dispatch (0003 is test-mode).

Acceptance checks. Fresh data → status + as-of timestamp. Policy not found → needs-review with a reason code, never a silent “verified”. Refresh window or unreachable → pending-verification, intake never blocked. Snapshot >36h → staleness warning, written-acknowledgment-state claims escalate.

Delegation plan. The agent may touch the replica adapter and the verification service. Gated: the Q-15 service-account configuration and the private-endpoint settings (the agent proposes; a human applies). Plan-mode approval before any code.

Checking plan. Full ladder: CI hard gates, the grader, a non-author Checker (Sara). Because HIGH: the security.yml security-reviewer pass and Dan's named sign-off in the PR.

How it rode the loop. Plan approved by Jonah → agent implemented under tight permissions → Stop hook green → PR fired ci.yml, grader.yml, and (on the risk:high label) security.yml → Dan signed off → Sara merged → deploy-dev shipped it. The Q-15 controls were verified live against the dev environment the same afternoon.

Spec 0002 is the hard exit condition made concrete: at least one HIGH-risk slice runs the full loop, so the riskiest path is proven before Build ever depends on it. The other three slices — 0001 (MEDIUM), 0003 (MEDIUM, fired the PII gate), 0004 (LOW, emitted the metric) — rode the same loop; nothing was hand-built off the rails to save a day.

The day-9 shakedown, and the rail that broke first

Break the rails on purpose — before they break by accident

On day 9 the rails got shaken down on purpose — and one defect had already surfaced early, for cheap, on day 5. A pipeline that is green because nothing real ever stressed it has proven nothing. A rail that has never failed safely has not been proven.

The shakedown — recorded in pipeline-proof.md

Each rail forced to fail and proven to catch it:

A deliberately failing build proves the Stop hook blocks.
A PR with a planted spec mismatch proves the grader posts the miss.
A known-bad deploy proves deploy-dev rolls back cleanly — the environment returns itself to the last good version.

The setup review (Rob + Jonah, his deputy) merged the week's harness corrections — the coverage-gate fix, two CLAUDE.md glossary additions the agents kept missing. The Build cadences got scheduled, and two flow limits set: WIP cap at two streams per Orchestrator, and no new streams once the median review wait passes one working day.

The rail that broke first, day five

The coverage-gate defect

"The coverage gate miscounted generated files on the very first real slice — found and fixed while it cost an hour, not in Build week three when it would have blocked every PR."

Q-17 lands: Dan and Harbor ops choose the postal dispatch vendor; it surfaces Q-19 (vendor sandbox credentials), owner Tom + Harbor ops, due before the first acknowledgment-delivery spec in Build.

The receipt the gate can't read

pipeline-proof.md records that each rail caught its planted failure. But the gate only checks the file exists and is placeholder-free — not that the shakedown truly happened. The proof is a human's word, written down.

The Build handoff — and the questions that travel with it

What the Build loop receives

A phase ends by handing the next one a package, not a feeling. Everything below crosses the boundary out of the gated opening and into the continuous Build loop: the factory, the proof it runs, the ordered backlog, and the questions still open — carried forward under their original IDs, never silently dropped.

Crosses into the Build loop build-handoff.md risk-tier-map.md cadence-plan.md foundation-report.md CLAUDE.md + .claude/ + specs/ the deployed skeleton, running in dev the outcome metric, ticking

The Build handoff (summary)

Drafted day 10; the phase closed day 10 — billing milestone 4.

The factory: the adapted harness, the five-workflow pipeline, branch protection, and the Bicep dev environment — all owned by Rob, reviewed by Jonah and Tom.
The proof: the walking skeleton running in Harbor's dev environment, verified against the Phase 2 definition, with the FNOL→coverage clock ticking on the scorecard.
The risk-tier map: the HIGH/MEDIUM/LOW taxonomy in CLAUDE.md, plus the two build-time security gates registered against the paths they guard.
The cadences: flow check (daily), intent triage (weekly), retro+, setup review; WIP cap two streams per Orchestrator; halt new streams past a one-working-day median review wait.

Recommended first Build specs

The skeleton proved the architecture; these are the first features to ride the proven loop.

Fast-path escalation (REQ-019) — builds directly on spec 0002's replica read.
The document-upload path — the first PR to trigger the malware-scan gate for real.
Email FNOL extraction (ADR-004) — the engagement's first agentic spec, where the feature itself runs on an AI model: a 200-email golden set as acceptance criteria, the eval gate in CI, prompt and model changes tiered HIGH.

Open questions into Build

ID	Open question	Owner	Due
Q-18	Construction of the surge load-test dataset from the 2024 CAT (catastrophe) event — volume curve + channel mix	Priti Shah + Nadia Brooks	Before hardening pass 1
Q-19	Postal vendor sandbox credentials for the acknowledgment-delivery spec (follows Q-17's vendor choice)	Tom Reilly + Harbor ops	Before the first acknowledgment-delivery spec

The engagement crosses here from the gated opening into the continuous Build loop. There is no next gate — only the merge bar every change clears, and the cadences that keep it honest.

You've been handed a project and told to run Phase 3. This page is what you actually type, in order, and what you do between the typing.

Phase 3 takes about two weeks. It is the highest-risk phase in the opening — you are building the machine that checks every change after it, and nothing checks that machine except you. Read this once end to end before you start.

Before you type anything

What you need first

More than any other phase, and most of it is access you don't control. Chase the access on day one — the commands take minutes, the permissions take days.

Phase 2, closed. You need phase3-handoff.md read, the walking-skeleton definition (the thinnest end-to-end slice that proves the architecture), and threat-model.md with its guarded-path map. If Phase 2 produced no threat model, stop and do that review now — Step 4 wires the security gate from that map, and choosing guarded paths from memory at wiring time is how the gate ends up protecting whatever seemed sensitive on the day.
The plugin and uv. If /sdlc isn't in your slash command list, run /plugin marketplace add MCKRUZ/claude-code-sdlc then /plugin install claude-code-sdlc@mckruz. The plugin's scripts run through uv — pip install uv or brew install uv.
PowerShell (pwsh) on every machine that runs an agent. The Stop hook ships as .claude/hooks/stop-gate.ps1. Without pwsh the hook is registered and can never run — an agent finishes a turn on a red build and nothing objects. It fails silently, which is the worst way for a guardrail to fail.
Repo admin on the client's repo. Someone must be able to enable GitHub Actions, agree the runner policy, install the Claude GitHub App (/install-github-app — repo admin required), and apply branch protection. Name that person. "Access is being sorted" is not a name.
The ANTHROPIC_API_KEY repository secret. Settings → Secrets and variables → Actions. The grader, correctness and security workflows call the Claude API and there is a real per-PR token cost. Until this is set, security-review and correctness-review fail closed on the PRs they review — by design — and the grader stays green and does nothing.
A real dev environment and the client's secrets vault. Not a sandbox of yours. The exit demo runs in the client's environment or it has proven nothing.
A named deputy. The person who reviews every harness change you make. Named on day one. If you defer this, you are approving your own foundation right now.

The mistake new people make

Treating client access as a scheduling problem. Branch-protection admin, Actions enabled, runner policy and vault access are the gating dependency of this phase — the rails cannot be proven without them. If the client can't give their DevOps engineer four to six hours across the two weeks, that goes to the sponsor on day one, not into a quietly slipping schedule.

Type this — then stop, before you install anything

Confirm the plan

You type /sdlc

What happens: Claude shows you Phase 3 guidance and then immediately blocks on a human gate. It asks four things: are these the right thinnest end-to-end slices and which single one carries the highest risk; where the dev environment lives and who holds branch-protection admin, Actions enablement, runner policy and the secrets vault; who the Setup Owner's deputy is; and — if this is a library, CLI or skill rather than a service or app — what "deploy to dev" even means for this target. Nothing installs until you answer.

What you do: answer with facts, not intentions. Every one of these questions is really "is this real yet?" A named person with the access already granted is an answer. A ticket number is not.

Don't move on until: one slice is marked as the HIGH-risk one (it has to ride the loop at HIGH before this phase can close), and every access item has a human name against it.

Type this — the only big install of the phase

Put the harness in the repo

You type /sdlc-harness

What happens: it copies the plugin's bundled harness into the repo. It is idempotent — anything already there is left alone and reported as SKIPPED, so it is safe to run twice. What lands: CLAUDE.md, specs/spec-template.md, .claude/ (settings, hooks, agents, skills), .github/workflows/, .github/RAILS.md, .github/profile/ (the review rubrics, the branch-protection ruleset, CODEOWNERS), scripts/rails/, eval-datasets/, prompts/, and infra/ for the infrastructure code.

What you do: read the SKIPPED list, then commit all of it — including .claude/harness-manifest.json. That file is the receipt every future upgrade reads to tell your edits apart from the factory version. Lose it and upgrades get much worse.

If Phase 0 already ran /sdlc-setup, the harness is probably already here. To pull the plugin's newer version instead, use /sdlc-upgrade: it dry-runs first, brings forward files you never touched, leaves your adaptations alone, and writes a .harness-new sibling next to any file that changed on both sides. Merge each one by hand and delete it — a leftover .harness-new is an unfinished upgrade.

You now have CLAUDE.md — generic, not yours yet .github/workflows/ — the rails, unwired .claude/harness-manifest.json — the receipt

Don't move on until: it's committed. And be clear about what just happened — you installed a firm asset. The kit is not built on the client's clock; this phase only adapts it.

Nothing to type — and no command does this for you

Adapt it to the client

You type nothing — this is writing, reviewed as PRs

What you do: rewrite CLAUDE.md in the client's own language. Five things go in it: the domain glossary in their words, the stack standards, the risk taxonomy from Step 5, the gated paths, and the Definition of Checked (what must be true before a change counts as done). Then record what the kit installed and what you changed, per file, in harness-inventory.md.

How you do it: as pull requests the client's lead engineer actually reads. This is the client team's first concrete look at how the pod works — months before the handover. Doing it in a private branch and presenting it finished throws that away.

This one is invisible when you skip it

A generic CLAUDE.md installs clean, commits clean and passes every gate. It just quietly makes every agent guess the domain — and guesses differ per run, so the same spec produces different code on Tuesday than it did on Monday. Nothing in the tooling can tell an adapted file from an unadapted one.

The rule that holds all phase: every harness change is reviewed by the deputy. The author of the foundation is never its sole approver. That includes this step, and it includes you.

Editing, then one script — the longest step in the phase

Take the rails live

The workflows ship with holes in them on purpose. They do nothing useful until you fill the holes, connect the API access, and turn on branch protection.

First, fill in the placeholders. Search the installed files for <<LIKE_THIS>> markers and the @your-org/your-team owner handle in CODEOWNERS. There is a second marker style too — single-angle <PLACEHOLDER> on the eval-runner wiring and in infra/. Search for both, or you will miss half of them.

File	What you have to set
`ci.yml`	Your toolchain, restore/build/test commands, the solution or workspace path, any service provisioning, and the coverage floor (default 80%). Also the regex for what counts as source in the spec check
`grader.yml`	The committed-spec directory (reference: `specs/`) and the reviewer model
`correctness.yml`	The source-root pathspec — what it hunts for defects in
`security.yml`	The gated-path regex — the guarded paths from your Phase 2 threat model. Keep it in sync with CODEOWNERS and the security rubric's prose list
`deploy-dev.yml`	Every deploy and rollback step, the artifact name CI uploads, and the environment name. It ships as a starter that fails until you wire it

Then connect the API access. Install the Claude GitHub App (/install-github-app, repo admin required) and add the ANTHROPIC_API_KEY repository secret. The grader, correctness and security workflows are all agents; without these they cannot run.

Then turn on branch protection.

You type scripts/rails/apply-branch-protection.sh --dry-run scripts/rails/apply-branch-protection.sh

What happens: the dry run prints the plan; the second applies it and prompts you to confirm. It enforces five required checks plus a non-author approval and code-owner review.

What you do: read the ruleset JSON before you apply it. And from here on, change branch protection only by editing that JSON and re-running the script. Editing rules by hand in the GitHub UI puts the repo and the file out of sync, and the file is what the next person reads.

The five checks a PR must clear build-and-test spec-gate grader — must have run correctness-review security-review

Two checks the phase write-up doesn't mention

The kit enforces more than the standard's prose describes. spec-gate fails any PR that touches source without its spec in the same diff — the escape is the no-spec:chore label, and applying it is recorded. And the first step of build-and-test is a secret scan. Your first real PR will probably hit one of these; that is the rail working, not a misconfiguration.

One thing never to do: do not switch these workflows to pull_request_target to make something work. That exposes the secrets and the write token to code from forked pull requests.

Nothing to type — a required document

Write the risk-tier map

You type nothing — Claude drafts it in conversation, you decide the tiers

What you do: produce risk-tier-map.md — every area of the codebase with its tier and the reason for it, every guarded path with the workflow that fires on it, and the taxonomy itself repeated so agents reading CLAUDE.md see the same thing humans do. The security gates from the Phase 2 threat model must appear on this map.

Tier	What lands here	What it triggers
HIGH	Auth and identity, payments, personal or client data, schema migrations, public API contract changes, infrastructure and pipeline changes, AI-behaviour changes (prompts, models, tool definitions), anything hard to undo	Tight agent permissions, the full checking ladder, a security review pass, a named human sign-off
MEDIUM	New business logic, external integrations, changes to shared internal services	Standard permissions, the grader plus a human Checker
LOW	UI within existing patterns, copy, internal tooling, additive CRUD on established rails	Lighter review; the grader and the mechanical gates still run

Note where you are on this map: the pipeline YAML and the infrastructure code you have been writing since Step 2 are HIGH. Everything you build in this phase is subject to the tightest row of the table you are writing.

Nothing to type — and the one mistake you cannot undo

Provision the dev environment from code

You type nothing — no command drafts infrastructure code

What you do: have Claude draft the infrastructure code for the dev environment into infra/ (Bicep on the .NET/Azure default; the pattern works on any stack), then run every change through the same funnel, in this order:

The funnel schema-validate → policy check → dry-run → human approval → least-privilege apply

The dry run (bicep what-if or your platform's equivalent) is the step people skip when they're tired. It is the step that tells you what is about to be destroyed. The environment provisions from code, never from clicks in a portal — a clicked environment cannot be rebuilt and nobody can review it.

Then write data-flow-brief.md. One page for the client's security team: what leaves the repo for the model API, what does not and the mechanism that keeps it out, where credentials live (their vault, their tenant, their audit trail), who can see usage, the contractual position on whether their data trains a model, and a named person in their security function who signed it, with a date. They accept this, not you — the pod's own reading of it doesn't count.

The one unrecoverable mistake of the phase

A secret in the repo. Not in code, not in CLAUDE.md, not in a spec, not in a workflow file. A key in a commit is a rotation event and an audit-log review, not an edit — and git history keeps it after you delete the line. Secrets live in the client's vault and in GitHub secrets from day one.

Building a library, a CLI or a skill instead of a service? There is no environment to provision. Record N/A — {project_type} for the infrastructure artifacts and carry on — the rails still apply, and the gate reads the project type and reports those artifacts as not applicable rather than failing you.

If the brief genuinely didn't happen: say so in the file — a line reading WAIVED: <name> — <reason>. The gate accepts that and reports it, by name, in the record the approver signs. A missing file still blocks. The escape is from the work, never from the record.

Type this once per slice — then ride the loop

Run the walking skeleton through the loop

You type /sdlc-spec

What happens: it turns one slice into a ready spec at specs/NNNN-name.md. It walks you through the goal, why, what's in and out of scope, and acceptance checks that survive the vague-line test — could two people build different things from this? It surfaces silent product decisions to a decision list with named owners, proposes a risk tier and stops for you to confirm or override it, then runs a Definition-of-Ready check you re-run until it reads READY.

What you do: one spec per slice. One spec, one branch, one PR. Then ride each spec through the full loop — and it must be the full loop:

Every slice Intent → Delegate → Discern → merge → deploy

Delegate means the agent in plan mode, bounded by the spec, with the Stop hook refusing to let it finish on a red build. Discern means the CI gates and the grader on the pull request and a human Checker who did not write the change approving the merge. Then merge to main deploys it to the real dev environment automatically.

Two slices need special handling. The riskiest seam runs at HIGH: tight agent permissions, the risk:high label so the security workflow fires, and a named human sign-off recorded in the PR. At least one HIGH-risk spec through the full loop is a hard condition for closing this phase — the HIGH path gets proven before Build depends on it. And the slice that emits the engagement's outcome metric gets extra attention, because it is what makes the success metric measurable from day one of Build.

The single most common Foundation failure

Hand-building the skeleton off the rails "because it's only the skeleton", to save a day. Don't. The skeleton is the only cheap opportunity you will get to discover a gate that doesn't fire, a grader that doesn't post, or a deploy that doesn't roll back. Build around the rails and you find those defects in Build instead, where they are expensive and everyone is watching.

Don't move on until: every slice has ridden the loop, the slices connect end-to-end in the real dev environment, an automated smoke journey walks the same path a user would (the /e2e skill helps here; /tdd helps inside the slices), and the running software is checked against the Phase 2 walking-skeleton definition. Each slice compiling is not "done". Record the per-slice evidence — spec, PR, grader verdict, Checker, deploy — in walking-skeleton-spec.md. Nothing writes that file for you.

Nothing to type — the step that separates a rail from a decoration

Break every rail on purpose

A rail that has only ever seen green has not been tested. It has been assumed. Before this phase closes, make each one fail deliberately and watch it catch you. A blocking gate is only proven when both its block and its escape have been seen to work.

Rail	How you break it	What must happen
Stop hook	Break a source file — a failing test or a compile error — then try to end a Claude Code turn	The hook refuses to let the turn end and hands back the build error
grader	A PR whose spec claims something the diff does not do	The grader's comment calls out the mismatch. It never blocks — you are confirming it posts the miss
spec-gate	A throwaway PR touching source with no spec in the diff	Goes red, listing the touched files. Then apply `no-spec:chore` and confirm it goes green
coverage floor	A throwaway PR that pushes coverage below the floor	`build-and-test` goes red at the coverage step, naming the measured percentage and the floor
correctness	A planted logic defect — an inverted null check, an off-by-one that drops a row	Goes red anchored to the exact line. Then apply `accepted-risk:correctness` and confirm it goes green
deploy-dev	A known-bad deploy — a deliberately broken artifact or a health check pointed at a failing build	The deploy fails and the last known-good version is restored
security	A probe PR touching a guarded path with a planted HIGH issue	The check goes red
secret scan	A throwaway PR committing a fake but realistic credential — an invented key, never a real one	`build-and-test` goes red at its first step with the planted string redacted in the log

What you do: close every one of these unmerged, and write each result down in pipeline-proof.md — one entry per rail, with the PR link. That file is the only evidence this happened.

Nothing verifies this but you

No command runs the shakedown, and no gate check can tell whether you did it. A pipeline that has never caught anything is not proven — it is merely present. This is the highest-value hour of the phase and it is entirely on your integrity.

Nothing to type — two numbers to agree out loud

Set the cadences and the tripwires

What you do: write cadence-plan.md. It carries the calendar for the rhythms that start now and run all through Build — the daily flow check, weekly intent triage, retro+, and the setup review — each with a named owner. Then two numbers the pod agrees deliberately:

The WIP cap — how many changes may be in flight at once. Default: no more than two concurrent agent streams per Orchestrator. It stops the pod opening more changes than it can check.
The review-wait tripwire — the wait time that, once crossed, stops new work starting until the review queue clears. Default: a median of one working day. Review is the loop's real bottleneck, and this number is how the pod refuses to bury it.

The same file records the numbers that steer the loop: accepted-as-is rate, review wait, rework and revert rate, escaped bugs, the DORA four, and security-review wait on its own line. It also names the banned ones explicitly — velocity, story points, PR count, lines of code. Agents inflate every one of those, so measuring them measures nothing.

Don't just inherit the defaults. If your engagement needs different numbers, that's fine — write down the reasoning next to them. A number nobody argued about is a number nobody will honour.

Nothing to type — five files, no commands

Write the closing documents

Claude drafts these in conversation from the work you've done; you correct them. No /sdlc command produces any of them.

File	What goes in it
`foundation-report.md`	What was installed and how `CLAUDE.md` was adapted; the five workflows, branch protection, the Stop hook and the registered guarded paths; a line per rail proven by forced failure; the skeleton outcome including the HIGH-risk slice and the metric ticking in dev; open questions under their original IDs
`risk-tier-map.md`	From step 5 — the tier table with rationale, the registered security gates, and the taxonomy mirrored from `CLAUDE.md`
`cadence-plan.md`	From step 9 — the calendar, the WIP cap, the tripwire, the steering metrics and the banned ones
`build-handoff.md`	The ordered spec backlog ready for the first triage, the risk-tier map reference, the cadence calendar, the open questions, and what is proven and ready for Build
`data-flow-brief.md`	From step 6 — signed by a named person in the client's security function

Three more are optional but worth the twenty minutes: harness-inventory.md (step 3), pipeline-proof.md (step 8), and walking-skeleton-spec.md (step 7). Nothing creates them either. You can also generate an interactive HTML report for stakeholders with the /visual-explainer skill — the rails status board, the slice tracker, the risk-tier map and the cadence calendar.

What the gate will look for foundation-report.md risk-tier-map.md cadence-plan.md build-handoff.md data-flow-brief.md everything else — unchecked

Type these — the machine checks your work, badly

Review, then run the gate

You type /sdlc-review --edge-cases /sdlc-gate

What happens: /sdlc-review --edge-cases puts a fresh reviewer across this phase's artifacts, walking every branch and boundary, and writes review-report.md with findings rated CRITICAL through LOW. It is advisory and blocks nothing — but a CRITICAL or HIGH finding usually predicts a gate failure, so read it before you run the gate rather than after.

Then /sdlc-gate runs seven checks and opens an HTML report in your browser. In practice, for this phase, it does two things: it confirms the five required files exist, are not empty, and have no leftover placeholder text; and it prints three sentences for you to judge yourself — the skeleton is deployed and verified, the rails are proven not just present, at least one HIGH-risk spec ran the full loop. Those three always report as needing review. They never block.

What you do: fix what it flags and re-run until clean. A leftover TODO in one file is the usual culprit.

What the gate cannot see — read this twice

Almost the entire substance of Phase 3. The gate cannot check that branch protection is actually applied, that the security gates fired on a real PR, that the environment provisions from code, that no secret reached the repo, that the outcome metric ticks in dev, that the deputy reviewed the harness, or that the WIP cap and tripwire were agreed. The delivery standard requires every one of those before this phase closes. Five green files is not a closed phase. Walk that list yourself, out loud, with the deputy.

Type this — last thing in the phase

Demo, sign off, advance

You type /sdlc-next

Before you type it: run the exit demo. In the client's own dev environment, through the real pipeline, with the outcome metric ticking. Not on your laptop. A localhost demo proves the code compiles; it does not prove the factory works, and proving the factory works is the only reason this phase exists. Get the named sign-off from a human on each side.

What happens: it re-runs the gates, generates the report, then stops and asks you to confirm before it moves anything. Say yes and it advances the project into the Build loop. Then it surfaces every open question from your handoff and makes you answer or explicitly defer each one before any Build work starts.

Phase 3 is done when the skeleton runs in the client's dev environment every rail has failed safely at least once a named human on each side signed

There is no next phase gate. The Build loop has no batch artifact gate — from here the merge bar is the gate, on every single change, forever. Which is why step 8 mattered so much.

Keep these handy

Commands you'll use constantly

Type this	When
`/sdlc`	Start of every work session. Tells you what to do next.
`/sdlc-status`	Any time you're lost. Shows what phase you're in and what's missing.
`/sdlc-spec`	Before building any change — every slice, every time. No spec, no build.
`/sdlc-coach`	You're stuck and want to be walked through it conversationally instead of following a list.
`/sdlc-phase-report`	Regenerate the stakeholder HTML report without re-running the gate.

Rule of thumb for the whole phase: the agent proposes, a gate disposes. In this phase you are building the gate — so nothing you build here is allowed to merge on your own approval. If you find yourself about to approve your own pipeline change because the deputy is busy, stop. That is precisely the failure this entire machine exists to prevent, and you would be committing it inside the machine.

Reference · Phase 3 · Foundation

The precise mechanics — the exact roles, calendar, artifacts, and gate, including the pipeline and infrastructure specifics the How-it-works view leaves out. The full prose method sits under each section's “Go deeper” on the How it works tab; for the complete worked example with every ID and command, see Example.

The four questions

Phase 3 answers four questions, and nothing else. The full feature backlog, the test and production environments, and any breadth beyond the thinnest skeleton are out of scope — they belong to the Build loop and the hardening passes.

Is the harness real and adapted? (the kit installed into the client repo, CLAUDE.md rewritten in the client's own domain, owned by the Setup Owner and reviewed by a deputy)
Are the rails real and enforced? (CI hard gates, the grader workflow, the correctness workflow, the security workflow, the deploy pipeline, branch protection, the Bicep dev environment, secrets in the client's vault)
Does the loop actually run? (the first specs go Intent → Delegate → Discern → merged → deployed — including at least one HIGH-risk spec — so the loop is proven before Build scales it)
Is the architecture real? (the walking skeleton from Phase 2, running end-to-end in the client's dev environment through the real pipeline — proven by software, not by documents)

Its product is not a feature; it is a working factory with one part already moving through it.

Claude's role in this phase

Human drives	Claude does	Mandatory human stops
Setup Owner owns the harness as a product and owns branch protection & secrets; the deputy and client DevOps review every harness change; Orchestrators author and run the skeleton specs; humans Check every merge.	Scaffolds the repo from the kit; adapts CLAUDE.md to the client's domain; drafts the Bicep and the pipeline YAML; runs the walking-skeleton specs through the full loop in plan mode.	Never merges IaC or pipeline without human review; never the sole approver of harness work; never puts a secret near the repo; never hand-builds the skeleton off the rails.

This is the phase where Claude writes the most code in the whole opening — and where that code is under the tightest gating, because the code is the factory. IaC and pipeline changes are HIGH risk for exactly this reason.

Who is involved

Our side

Person	Load	Workstream
Setup Owner	90–100%	The harness as a product — installs and adapts the kit, drafts the Bicep and pipeline YAML, owns branch protection and secrets. Never the sole approver of their own foundation
Setup Owner's deputy	20–30%	Named on day one (senior Orchestrator). Reviews every harness change — pipeline, IaC, CLAUDE.md adaptation. The both-eyes rule applied to the foundation
Orchestrators	60–80%	Author the first specs from the Phase 2 slices and run them through the full build loop — their first real Intent → Delegate → Discern cycles
Pod Lead	40–50%	Triages the skeleton into ordered specs, assigns risk tiers, schedules the Build cadences, runs the exit demo, owns the handoff into Build
Quality Engineer	40–50%	Wires the mechanical gates, then verifies the running skeleton against the Phase 2 walking-skeleton definition

Client side

Person	Needed for	How much
DevOps / platform engineer	Branch-protection admin, Actions enabled, runner policy, secrets in their vault & GitHub; reviews the pipeline they operate after we leave	4–6 hours across two weeks
Security	Signs off the pipeline, the secrets handling, the data-flow brief; the build-time security gates get wired and confirmed	2–3 hours
Lead engineer / Setup Owner counterpart	Pairs into the harness build; reviews the kit-adaptation PRs — the client's first concrete look at how we work	4–6 hours
Product Owner	Confirms the skeleton slices are the right thinnest end-to-end path; light touch	~1 hour
Sponsor	The exit demo — working software in their own dev environment	45 min

If the client cannot give DevOps the time to provision access and review the pipeline, that is a gating problem, not a scheduling one — the rails cannot be proven without it. It goes to the sponsor at steering before the clock runs out.

The ten-day calendar

Day	Focus	What happens	Tooling
1	Kickoff & access	Access checklist closed; contributor access, branch-protection admin, Actions, runner policy, secrets provisioning started; live smoke test of Claude Code on client seats/keys; Phase 2 open questions re-confirmed	— (access, smoke test)
2	Kit install, in the open	Repo scaffolded from the kit; CLAUDE.md adapted to the client's domain, stack, risk taxonomy, Definition of Checked — as reviewed PRs the client's lead engineer reads	— (Claude scaffolds; PRs)
3	The dev environment	Bicep drafted (HIGH risk, reviewed every change); environment provisions from code; secrets land in the client's vault; data-flow brief to security	— (Claude drafts Bicep)
4	The pipeline	Five workflows built & reviewed by client DevOps (ci, grader, correctness, security, deploy-dev); branch protection on; Phase 2 security gates wired	— (Claude drafts YAML)
5	First slice through the loop	First skeleton spec rides the full loop (Intent → Delegate → Discern → deploy); rails exercised by real software; defects found & fixed cheap. One slice live in dev	— (spec rides the loop)
6	First HIGH-risk slice	The slice touching the riskiest seam runs the loop at HIGH risk: tight permissions, security workflow on `risk:high`, security-reviewer agent, named sign-off in the PR	— (HIGH-risk loop)
7	The remaining slices	The rest ride the loop; the metric-emitting slice gets special attention; build-time security gates fire on their first qualifying PR (or a probe PR proves them)	— (specs ride the loop)
8	Skeleton, end-to-end	Slices connect into the running skeleton in dev; QE verifies against the Phase 2 definition; a first E2E smoke journey walks the whole thread	`/e2e`
9	Harden the rails	Deliberate shakedown — Stop hook blocks, grader posts, deploy-dev rolls back; setup review merges harness corrections; Build cadences scheduled; WIP cap & review-wait tripwire set	— (manual shakedown)
10	Gate, demo, handoff	Automated gate check; exit demo (skeleton running in client dev, metric ticking); Build handoff drafted; gate sign-off recorded — billing milestone; engagement enters the Build loop	`/sdlc-gate`, `/sdlc-phase-report`, `/visual-explainer`, `/sdlc-next`

Foundation is the least plugin-driven phase of the opening: most days are code and rails, not drafts, so most carry no plugin command. The plugin returns at the gate. The default calendar is two weeks (10 business days) — the longest of the opening phases.

When the two weeks stretch

Access or secrets provisioning stalls on the client side. The rails cannot be proven without them; this is a gating dependency, surfaced at steering on day one, not absorbed silently into a slipping schedule.
The dev environment fights the IaC (a subscription policy, a missing role assignment). Expected friction — exactly what Phase 3 exists to discover before Build, not during.
A skeleton slice exposes a design gap. Good — the skeleton found in days what the documents missed. Re-open the relevant ADR explicitly rather than patching around it in code.
The client wants to widen the skeleton ("while we're here, add…"). That is Build scope; it delays the rails being proven and the gate being reached. Hold to the thinnest path and let the backlog carry the rest.

The artifacts

Artifact	Owned by	Done means
Installed harness (CLAUDE.md, `.claude/`, `specs/`, settings)	Setup Owner	Adapted to the client's domain, stack, and risk taxonomy; committed; reviewed by the deputy
Bicep dev environment	Setup Owner	Provisioned from code; HIGH-risk human review on every change; secrets in the client's vault
Pipeline workflows (ci, grader, correctness, security, deploy-dev)	Setup Owner	CI hard-gates; grader required to run; correctness blocks on a high-confidence defect; security fires on `risk:high`; deploy-dev on merge — all running, all reviewed by client DevOps
Branch protection	Setup Owner	Enforces CI green + grader-ran + non-author approval; `risk:high` adds the security workflow + a named sign-off
Walking-skeleton specs	Pod Lead	Each rides the full build loop; together they prove the architecture in running software
The walking skeleton (deployed)	Setup Owner + QE	End-to-end in the client's dev environment through the real pipeline; verified against the Phase 2 definition
Build-time security gates (wired)	Setup Owner + client security	The Phase 2 gates enforced in the security workflow; each fired at least once on a real PR
Data-flow brief	Setup Owner	Client security has, in writing: what goes to the API, what doesn't, where keys live, who sees usage
Cadence calendar + risk-tier map	Pod Lead	Flow check, intent triage, retro+, setup review scheduled; WIP cap and review-wait tripwire set; the risk-tier map lists each area with its tier and any security gate registered against it
Build handoff	Pod Lead	Ordered spec backlog, risk-tier map, cadences, open questions under their original IDs

Deliberately not produced: the full feature backlog (Build triage owns it), the test and production environments (the first hardening pass and Phase 8 add them), and any feature breadth beyond the thinnest skeleton.

The pipeline — five workflows

Workflow	Trigger	What it does	Blocks?
`ci.yml`	Every PR	Build, test, lint, 80% coverage on new code	Hard block
`grader.yml`	Every PR	A fresh agent reads the spec in the diff, posts a check-by-check verdict	Required to run; verdict advisory
`correctness.yml`	Every PR	A fresh agent hunts for defects in the diff, posts any high-confidence findings	Blocks on a high-confidence defect
`security.yml`	`risk:high` label	Runs the security-reviewer agent over the diff	Pass + named sign-off required to merge
`deploy-dev.yml`	Merge to `main`	Ships to the client dev environment; restores the last good version when a deploy fails	— (deploy step)

Branch protection on main: CI green + grader-ran + one non-author approval. risk:high adds security.yml passing and a named human sign-off recorded in the PR. Wiring a build-time security gate means registering its guarded path with the security workflow, so the workflow runs on any PR touching that path — independent of the spec's risk tier.

The cadences

Rhythm	Who	What
Daily 15-min pod sync	Whole pod	Rails progress, spec status, blockers
The kit-adaptation PRs	Setup Owner + client lead engineer	The client's first look at how we work — reviewed in the open, not handed over finished
Setup review	Setup Owner + deputy	Harness changes merged and reviewed; the first real run of a cadence that continues all through Build
Intent triage (begins here)	Pod Lead + Orchestrators	The skeleton slices become ordered specs; the Build loop's weekly cadence starts in this phase
Biweekly steering	Sponsor + Pod Lead	Falls at the end of the phase: the exit demo — working software in the client's own dev environment

The exit gate

Phase 3 closes — and the engagement enters the Build loop — when all of these are true:

The harness is installed, adapted to the client, committed, and reviewed by the Setup Owner's deputy (the Setup Owner is never the sole approver of their own foundation)
The pipeline runs: CI hard gates, the grader required to run, the correctness workflow blocking on a high-confidence defect, the security workflow on risk:high, deploy-dev on merge — all reviewed by the client's DevOps
Branch protection enforces CI green + grader-ran + non-author approval; risk:high adds the security workflow and a named sign-off
The Bicep dev environment is provisioned from code; secrets live in the client's vault, never in code
The build-time security gates from Phase 2 are wired, and each has fired on a real PR
The walking skeleton is deployed to the client's dev environment through the real pipeline — running software, not a document — and verified against the Phase 2 definition
At least one HIGH-risk spec has run the full loop (the HIGH path is proven before Build depends on it)
The rails are proven, not just present: the Stop hook actually blocks, the grader actually posts, deploy-dev actually rolls back
The outcome metric is measurable in dev (the metric slice exists and ticks)
The Build cadences are scheduled and the WIP cap and review-wait tripwire are set
A named human on each side approved the advance — gates report, humans decide

The gate sign-off is billing milestone 4. The engagement crosses from the gated opening into the continuous Build loop.

What goes wrong

Skipping the loop "because it's just the skeleton." The skeleton is precisely where the loop must be proven. A skeleton hand-built off the rails teaches the team nothing and hides the rails' defects until Build, when they are expensive.
A pipeline that exists but was never exercised. CI that is green because nothing real ran through it. The rails are proven by a spec breaking and being caught, not by the YAML being present.
The kit installed but not adapted. A generic CLAUDE.md means agents guess the domain, and guesses differ per run. The adaptation in the open is the point of the phase.
IaC or pipeline merged without review to move faster. HIGH risk because they are hard to undo and run in production later. The Setup Owner is never the sole approver of their own foundation.
A secret in the repo. The one unrecoverable mistake: a key in a commit is a rotation event and an audit-log review, not an edit. The client's vault from day one.
A feature-rich skeleton. Every slice beyond the thinnest end-to-end path is Build scope wearing a Foundation badge — it delays the rails being proven and the gate being reached.
Deferring the deputy. "I'll name a deputy later" means the Setup Owner is approving their own foundation right now. The deputy is named on day one.
The demo on a laptop. The exit demo runs in the client's own dev environment, through the real pipeline, or it has not proven what Phase 3 exists to prove. A localhost demo proves the code compiles, not that the factory works.