Phase 8 · Deployment — how it works, worked, and referenced

Months of building, and the riskiest day is the one where you change nothing — you just point real customers at what you already proved.

Phase 8 isn't where the system gets built. It's where a named human says go, out loud, with the rollback plan on the table.

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

Go-live is a ceremony, not a scramble

In most projects, deployment is the night everyone holds their breath: untested scripts, a fresh build, surprises at 2 a.m. In this method that drama is already spent. The pipeline that will touch production has existed since the foundation was laid, and every merge for months has ridden the very same rails.

The idea

Phase 8 invents nothing. The deploy pipeline, the test environment, the environment-as-code — all built earlier and exercised hundreds of times. What this week adds is the one part a machine must never own: the decision to ship, the rehearsal of failure, and a person putting their name to go.

A good Phase 8 is boring. If it's exciting, something was skipped — the excitement just means the surprises got saved for the worst possible moment.

At Harbor Mutual

By go-live week, Harbor had 44 feature specs built and verified, and documentation proven by use the week before. Production already existed — as infrastructure code that had simply never taken a real claim.

Where Harbor stood entering the week

"The system runs in dev and test; production exists as Bicep that has never taken a real claim. This week it takes its first."

Nothing new got built to go live. The same proven thing just got pointed at real customers.

Skip the rehearsal and…

The drama you didn't spend in rehearsal — where it costs an afternoon — gets spent during an incident instead, where it costs minutes of downtime with an audience watching.

Go deeper — the full method

In this method, Phase 8 invents nothing — the pipeline has existed since Foundation, the test environment since the first hardening pass, and every merge for months has deployed itself to dev through the same rails that will now touch production. What Phase 8 adds is the part machines must never own: the rollout decision, the rehearsal, and a named human saying go — out loud, on the record, with the rollback plan on the table.

A good Phase 8 is boring. The drama gets spent in rehearsal, where it costs nothing. This is also the week the engagement's success metric stops being instrumentation and starts being real: production traffic puts the first true numbers on the clock the client hired us to fix.

Phase 8 answers four questions, and nothing else:

Is the path to production proven? (deploy → roll back → redeploy, rehearsed in test — a rollback that has never run is a wish, not a plan)
Is the rollout shape decided and owned? (cutover, pilot, or parallel run — chosen by the client's product owner and operations, with the trigger conditions written down)
Did a named human say go? (the ceremony: evidence presented, every role asked, the decision recorded — gates report, humans decide, and this is the decision the rule exists for)
Is production verifiably healthy? (smoke tests green against live endpoints, monitoring receiving real data, the first real traffic watched end to end)

New features, alert tuning, and incident-response drills are out of scope — the backlog is closed, and monitoring is Phase 9's job (this phase only confirms data is flowing). Data migration is in scope only if the engagement scoped it; a migration nobody signed up for does not sneak in through the deployment door.

The rule that governs everything

The machine prepares the evidence; a human says go

This is the least code-writing phase of the whole engagement, on purpose. The AI does the assembling, the running, the watching. People make the one decision that matters here — and carry the accountability for it. A machine reports; a named human signs.

The idea

Claude drafts the release notes, drafts the deploy checklist and rollback steps, runs the smoke checks, and watches the first real traffic alongside the humans.
People decide go or no-go, pick how traffic arrives, execute the promotion with their own hands, and own every result.

What the AI never does: deploy to production unattended, decide go or no-go, or mark its own smoke results as the final word. The go/no-go is the mandatory human stop the whole standard bends around.

At Harbor Mutual

Through the whole week, the keyboard belonged to Harbor's people. Tom Reilly, their platform engineer, executed every promotion. The production access list never included a single member of the consulting pod.

What was simply true by go-live week

"The pod never touched production. Tom executed every promotion; the secrets rotated to values the pod has never seen."

In a few weeks the pod leaves. So this week, every hand on the keyboard is a hand that stays.

Go deeper — the full method

The least code-writing phase of the engagement, and deliberately so. Claude prepares evidence; humans make the only decision that matters here.

Drafts the release notes from the merged specs. Every spec since Foundation is a feature with a written goal and acceptance checks — the release notes assemble them for an audience that never saw a spec: what's new, what's fixed, what's not in this release, what users do differently.
Drafts the deployment checklist and rollback procedure from the RUNBOOK Phase 7 proved, ordered and observable: every step has an expected outcome and a verification.
Runs the smoke suite against test and, after go-live, against production — and reports results per journey, pass/fail, with evidence.
Watches the first real traffic alongside the humans: the first production transactions traced end to end against expected behavior.

What Claude never does: deploy to production unattended, decide go or no-go, pick the rollout shape, or mark its own smoke results as the final word. The go/no-go is the mandatory human stop the whole standard bends around — always, this release and every release after it.

The thing that moves to production

Promote the exact artifact you proved — never a fresh build

There's a tempting shortcut at go-live: "let's just do a quick fresh build for production." It feels harmless. It quietly puts something into production that no environment has ever actually verified.

The idea

Promotion means moving the same proven thing up the ladder: dev → test → production. Same pipeline, same code, a different target. Never a rebuild, never a hand-copy.

The moment you rebuild "real quick" for production, you've broken the chain of proof. The thing customers hit is no longer the thing that passed the tests — it's an unverified system wearing a verified one's badge.

At Harbor Mutual

The release candidate that passed every smoke check in test on Wednesday was, byte for byte, the thing that took Harbor's first real claim on Thursday.

From the team's notes on the week

"What ran in test on Wednesday is byte-for-byte what took Harbor's first claim on Thursday."

The production environment itself was also promoted, not improvised — provisioned from the same infrastructure code that had built dev and test.

Go deeper — the full method

Promotion means moving the same proven artifact up an environment: dev → test → production. The same pipeline, the same code, a different target — never a rebuild, never a hand-copy. The moment production gets a fresh build "real quick" instead of the promoted artifact that passed test, production runs something no environment ever verified.

The production environment itself is promoted, not improvised. It provisions from the same infrastructure code — the Bicep — that built dev and test, reviewed like the HIGH-risk change it is and executed by the client's platform engineer. IaC / Bicep means infrastructure as code: the environments defined in version-controlled files, so the production environment comes from the same source that built the others rather than being hand-assembled.

The chain of proof

The artifact that passed test is byte-for-byte the artifact that takes real traffic. Break that chain with a convenience rebuild and every test result you collected describes a different system than the one customers hit.

The plan you must have before you ship

A rollback that has never run is a wish, not a plan

Everybody writes a rollback procedure. Far fewer ever run it. A documented, reviewed, never-executed rollback gets its real first test during an actual incident — the worst possible time to discover it doesn't work.

The idea

Before any production promotion, the path gets rehearsed in test, for real: deploy → roll back → redeploy — run by the same hands that would run it at 2 a.m.

And the rollback needs a written trigger — "roll back if X" — decided in calm daylight, not invented mid-incident. A rollback that has never executed is a hope; after the rehearsal it's a procedure with evidence.

At Harbor Mutual

On Tuesday, the rehearsal rollback failed. The old app revision came back up and crashed on startup — two config keys added since had moved forward independently of the artifact, so the old code didn't know them.

Tuesday's rehearsal timeline

"14:31 Execute RUNBOOK rollback to previous revision — FAIL. Previous revision crash-looped on startup."

The fix, then Wednesday's clean re-run

"Version app configuration WITH the release artifact. Re-rehearsal: rollback to previous revision + its config — OK (3 min 52 s, old revision Healthy)."

Why Tuesday's failure was the win

A rollback that fails in rehearsal, by appointment, costs an afternoon. The same failure on Thursday night is an outage with an audience. The rehearsal exists to buy failures at rehearsal prices.

Go deeper — the full method

The rehearsal, in test: deploy → roll back → redeploy. The rollback runs for real, by the hands that would run it at 2 a.m., from the RUNBOOK Phase 7 cold-verified. A rollback that has never executed is a hope; after the rehearsal it is a procedure with evidence.

The rollback is the exact, rehearsed procedure that returns production to the previous version — with a written trigger ("roll back if X"), not a judgment call invented mid-incident. The evidence is a timestamped timeline of each step — deploy, roll back, redeploy — with the outcome of each and the time back to healthy, attached to the go/no-go packet.

A failed first rehearsal goes in alongside the clean one: found-and-fixed is stronger evidence than never-stressed. Anything the rehearsal breaks gets fixed through the loop and re-rehearsed. Never promote past a failed rehearsal — fix it, re-rehearse, and move the window if you must.

The rehearsal buys failures at rehearsal prices

The rollback doesn't roll back, a migration won't reverse, a config diverges between test and production — this is the phase working, not the phase failing. The same surprise during a live incident costs downtime with an audience.

How the traffic actually arrives

Decide how real users meet the system — the client decides, in writing, before the ceremony

"Go live" isn't one thing. Does everyone switch at once? A small pilot group first? Does the new system run alongside the old one for a while? That's a product and operations decision — and it can't be improvised in the go/no-go meeting.

The idea — three shapes

Full cutover — everyone moves to the new system at once.
Pilot cohort — a small, chosen group goes first.
Parallel run — new and old run side by side for a while.

Whichever it is, the client's product owner and operations own it, in writing, before the ceremony — including what happens to work already in flight and what the fallback is, with the conditions that trigger it.

At Harbor Mutual

Luis Ortega, Harbor's product owner, chose cutover at intake: from go-live, every new claim in every channel enters the new system; claims already in flight finish in the old process where they started. No migration — none was scoped, none sneaks in.

Legacy intake stays warm as a fallback for 30 days · written triggers: intake error rate above 2% for 30 minutes, or verification down with the queue still growing

Owned by a named human, in writing, in the go/no-go packet — not a shrug at the meeting.

Go deeper — the full method

The rollout shape is how production traffic arrives: full cutover, a pilot cohort, or a parallel run alongside the old process. A product and operations decision, made by the client, before the ceremony. The Pod Lead convenes the rollout-shape session; the product owner and operations decide — what shape, what happens to work in flight in the old process, what the fallback is and for how long. Written down, with trigger conditions, before any ceremony.

The hypercare window gets agreed with the client's operations the same day — length and response expectations written down before the ceremony, so it goes in the packet as a commitment, not a courtesy. One to two weeks is the usual shape.

If the rollout shape unravels late — operations discovers the parallel-run staffing, or the in-flight-work answer, doesn't hold — better the week stretches than the shape gets improvised at the ceremony. And any data migration is in scope only if the engagement scoped it: "while we're at it, migrate the old claims" is scope arriving through the deployment door, and it doesn't.

The single most protected stop in the standard

Every named role gets asked — and a no is cheap

Before production, the evidence goes on the table and every named role is asked, in turn: go, no, or held. The decision and its reasoning get recorded with names. This is the decision the whole rule about humans deciding exists for — every release, this one and every one after.

The idea

Each role answers go, no, or held. A held answer names its condition, and the ceremony waits until it's met or becomes a no. Anyone can say no, and a no today is cheap.

The thing to watch for is the opposite: a ceremony where nobody in the room could plausibly say no, because the decision was really made days ago. That's theater — and theater here is how outages get scheduled.

At Harbor Mutual

Wednesday, 16:00. Seven people asked by name — release manager, platform, operations, security, product, quality, sponsor. Six immediate goes. Then security:

Dan Kowalski (security) — Held
until the secrets-rotation record was attached to the packet, not merely referenced — then go

Five minutes of friction — exactly the kind the ceremony exists to make cheap. A go/no-go where friction is unwelcome is the theater to fear.

The failure mode to watch

Go/no-go theater: the meeting exists to nod. The tell is that nobody could plausibly say no. Make the no cheap and the evidence real, or the ceremony protects nothing.

Go deeper — the full method

The go/no-go is the decision ceremony before production: the evidence on the table, every named role asked in turn, and an explicit human decision. The single most protected stop in the standard. It comes at the end of the dress-rehearsal day.

The evidence packet on the table: rehearsal results, smoke results, the rollback trigger, the rollout shape, the notification list. Every named role asked in turn — release manager, platform engineer, operations, security, product owner, quality, sponsor. Anyone can say no, and a no is cheap today. The decision and its rationale are recorded with names.

Each role answers go, no, or held — a held answer names its condition, and the ceremony waits until it is met or it becomes a no. The Pod Lead records every answer with the name, the time, and one line of rationale; that record, plus the decided window, is the artifact.

Theater is how outages get scheduled

A go/no-go where no one could plausibly say no is theater, and theater here is how outages get scheduled. When someone does say no, then no is the answer — the ceremony exists to make that cheap; the date moves, the reason gets fixed, and nobody is ever punished for the no that prevented the outage.

Telling people what shipped

Release notes assemble themselves from the specs you already merged

Release notes are usually written from memory at the last minute, and they show it. Here they don't have to be — because every feature shipped this engagement was a written spec with a goal and acceptance checks. The raw material already exists.

The idea

The AI drafts the release notes from the merged specs, then translates them for an audience that never saw a spec: what's new, what's fixed, what's not in this release, and what (if anything) users must do differently.

The same applies to the deploy checklist and rollback steps — drafted from the runbook the documentation phase already proved, with every step given an expected outcome and a way to verify it.

At Harbor Mutual

The release notes were drafted from the 45 merged specs, then refreshed mid-week after one more spec (the rollback fix) merged. They went to Harbor's stakeholders plainly written:

What the notes covered

"What the new intake does, what changes for the claims office, what is not in this release (auto-insurance, adjuster-initiated merges), and the acknowledgment clock now enforced by the system rather than by vigilance."

Go deeper — the full method

Release notes are what this release delivers, written for people who didn't build it: features, fixes, limitations, and what (if anything) users must do differently. Claude drafts them from the merged specs — every spec since Foundation is a feature with a written goal and acceptance checks, so the raw material already exists — then translates them for an audience that never saw a spec.

The deployment checklist and rollback procedure get the same treatment, drafted from the RUNBOOK Phase 7 proved: every step ordered and observable, with an expected outcome and a verification, and sign-off lines for the ceremony roles. The Orchestrators drive the release-notes and checklist drafting and fix anything the rehearsal surfaces — through the loop, like any change.

The release notes are owned by the Pod Lead; the deployment checklist by the Setup Owner (the release manager). They are drafted by the machine and owned by named humans — a machine reports, a person signs.

Proving production is actually healthy

Check it for real — without the check itself causing the incident

A deploy that "succeeded" isn't proof the system works. You verify it — but the verification of a day-old production system must never be the thing that corrupts it. So the checks are reads and harmless writes only.

The idea

A smoke test is a fast, non-destructive check that the deployed system actually works — one journey per top-priority user story. If it can corrupt real data, it isn't a smoke test.

Two more things must be true: monitoring is receiving real data (tuning the alerts comes later, but flying blind is unacceptable), and the very first real transactions get watched end to end by the people who own the outcome.

At Harbor Mutual

Production smoke ran green at 07:25 through test-mode paths — no real letters dispatched, no real records left behind. Then at 08:14 the first real claim arrived, watched end to end:

11.4 → 3h 6m median days-to-decision baseline → the first production claim, end to end

Steering heard "data point," not "result" — one good day is not a median. The credibility spent overclaiming week one never comes back.

The trap to avoid

A destructive smoke test that writes real records into a day-old production system. Then the verification step is the incident. Reads and harmless writes through the test-mode paths only.

Go deeper — the full method

A smoke test is a fast, non-destructive check that the deployed system actually works — one test per top-priority user journey, reads and harmless writes only. If it can corrupt data, it is not a smoke test. The Quality Engineer assembles the suite from the end-to-end journeys the hardening passes already built, trimmed to the non-destructive, test-mode paths — it is not written this week.

Production smoke runs against live endpoints using the test-mode paths built for exactly this: production endpoints that accept flagged synthetic transactions, exercising the full journey without dispatching anything real or leaving unflagged records — built during Foundation and Build precisely so production can be verified safely. The Quality Engineer confirms monitoring is receiving production data — alert tuning is Phase 9, but blind is unacceptable today.

The first real traffic gets watched end to end, deliberately: the first true transactions traced against expected behavior, with the people who own the outcome looking at the same screen. The first number is reported with its caveat — one good day is a data point, not a median; the target gets judged on the median, in Phase 9 and beyond.

Now watch the whole thing happen

Go-live week, end to end

You've got the ideas; here's the actual rhythm at Harbor. Five business days, with go-live deliberately mid-week — never the last day before a weekend, because the day after go-live is a working day for finding what go-live shook loose. Step through it.

Monday · checklist, secrets, rollout shape

Set the table before anyone deploys

The deploy checklist gets walked top to bottom and the production access list cut to least privilege. Every secret the pod ever touched gets rotated to values the pod can't read — Harbor's security signs it. And the product owner decides the rollout shape: cutover at intake, with a 30-day warm fallback and written triggers.

Tuesday · promote the env, rehearse the failure

The day the rollback failed — on purpose, in test

Production provisions from the same infrastructure code that built dev and test. Then the rehearsal in test: deploy, roll back, redeploy — by the hands that would run it for real. The rollback failed. That's Tuesday doing its job: the fix rode the loop, the runbook got corrected, and the cause is gone before it could ever reach production.

Wednesday · dress rehearsal & the ceremony

A clean run, then seven names on a decision

The candidate promotes to test through the full procedure; the smoke suite runs green, one journey per top-priority story. Then at 16:00 the go/no-go: the evidence packet on screen, seven roles asked in turn. Security held until a record was attached, then go. Seven goes, recorded with names. Window set: Thursday 07:00.

Thursday · go-live

The same artifact, now taking real claims

07:00, the promotion runs — Tom executes, the release manager calls each step. The same artifact that passed test goes to production. 07:25, production smoke green through test-mode paths; monitoring confirmed receiving. 08:14, the first real claim: a burst pipe, traced end to end, a coverage recommendation 3 hours 6 minutes after it was reported.

Friday · hypercare day one, then the gate

Watch it live, then close the phase

The two-week hypercare window opens — Harbor's operators driving, the pod beside them. Day one surfaces one finding (a retry burst during a vendor blip — no claim affected), logged as a Phase 9 alert candidate. Release notes go out. The gate passes; the sponsor signs at steering with the first production numbers and an honest caveat. Billing milestone six.

1 / 5

Go deeper — the full method

The default calendar is 5 business days, with go-live mid-week — never the last day before a weekend, because the day after go-live is a working day for finding what go-live shook loose. It stretches when the rehearsal fails (good — that is its job) or the client's change-control board adds latency.

Day 1 — the checklist, the secrets, and the rollout shape. The Phase 7 handoff's deployment checklist gets walked: configuration per environment reviewed, the production access list confirmed against least privilege, stakeholder notifications drafted with the deployment window. Secrets rotate before go-live — everything the pod ever touched gets rotated into production-only values the pod cannot read; the client's security signs the rotation. The Pod Lead convenes the rollout-shape session; the hypercare window is agreed the same day.
Day 2 — promote the environment, rehearse the failure. The production environment provisions from the same infrastructure code that built dev and test — reviewed like the HIGH-risk change it is, executed by the client's platform engineer. The rehearsal in test: deploy → roll back → redeploy, by the hands that would run it at 2 a.m. Anything the rehearsal breaks gets fixed through the loop and re-rehearsed.
Day 3 — the dress rehearsal and the ceremony. The release candidate deploys to test through the full procedure; the smoke suite runs, one journey per top-priority story, non-destructive, results recorded per test. The go/no-go ceremony, end of day: the evidence packet on the table, every named role asked in turn, the decision and rationale recorded with names.
Day 4 — go-live. The promotion runs in the agreed window: the client's platform engineer executes, the release manager calls each checklist step. The same artifact that passed test goes to production — promoted, not rebuilt. Production smoke runs against live endpoints through the test-mode paths; monitoring is confirmed receiving; the first real traffic gets watched end to end.
Day 5 — hypercare day one, then the gate. The agreed hypercare window begins: dashboards open, the client's operators driving with the pod beside them. Release notes go out; the automated gate check runs; the Phase 9 handoff is drafted. Steering: the gate sign-off, the billing milestone, and the first production numbers on the outcome scorecard, however early.

When the week stretches

The rehearsal fails → fix it through the loop, re-rehearse, move the window; never promote past a failed rehearsal. Change control adds a board → the evidence packet is built to pass it; surface the latency at steering, don't absorb it. Someone says no at the go/no-go → then no is the answer; the date moves, the reason gets fixed.

How it goes wrong

The failure modes, and the defense against each

Every one of these has scheduled an outage somewhere. Knowing them by name is half the defense — and Harbor's structure caught two of them in the act.

The trap	What it looks like	The defense	At Harbor
The Friday deploy	Going live the last day before a weekend, so the system's first hard day happens with nobody watching	Go live mid-week; the day after go-live is a working day on purpose.	Go-live Thursday, hypercare Friday
The rollback only ever written	Documented, reviewed, never run — then executed for the first time during an incident	Rehearse it in test, by the client's own hands, before the ceremony.	Caught — the Tuesday rehearsal failure
Go/no-go theater	The decision was really made days ago; the meeting exists to nod	Make the no cheap and the evidence real, or the ceremony protects nothing.	Security held until a record was attached
The rebuilt artifact	A fresh build "real quick" for prod instead of the promoted one that passed test	Promote, never rebuild — the same artifact moves up.	Byte-for-byte the tested candidate
Destructive smoke tests	A verification step that writes real records into a day-old production system	Reads and harmless writes through the test-mode paths built for this.	Test-mode paths only, no real records
Scope through the deploy door	"While we're at it, migrate the old claims" — a migration nobody scoped	If it wasn't scoped, it isn't in this release.	Cutover at intake; in-flight claims drain in legacy
Hypercare as a courtesy	Treating the post-go-live window as optional goodwill	It's part of the deployment — the cheapest learning the engagement gets.	Two-week window, operators driving

Go deeper — the full method

Named failure modes, because every one of these has scheduled an outage somewhere. Knowing them by name is half the defense.

The Friday deploy. Going live the last day before a weekend, so the system's first hard day happens with nobody watching. Go live mid-week; the day after go-live is a working day on purpose.
The rollback that was only ever written. Documented, reviewed, never run — then executed for the first time during an incident, where every surprise costs minutes of downtime. Rehearse it in test, by the client's own hands, before the ceremony.
Go/no-go theater. The decision was really made days ago; the meeting exists to nod. The tell: nobody in the room could plausibly say no. Make the no cheap and the evidence real, or the ceremony protects nothing.
The rebuilt artifact. Production gets a fresh build "real quick" instead of the promoted artifact that passed test — and now production runs something no environment ever verified. Promote, never rebuild.
Destructive smoke tests. A verification step that writes real records into a day-old production system. Smoke tests are reads and harmless writes through the test-mode paths built for this; anything else is the verification causing the incident.
Deploying ahead of the operators. The system goes live before the people who run it have rehearsed, because the date was sacred and their calendar wasn't. The date moves; the rehearsal doesn't.
Scope through the deployment door. "While we're at it, migrate the old claims" — a migration nobody scoped, attempted under a deadline, against production data. If it wasn't scoped, it isn't in this release.
Hypercare as a courtesy. Treating the post-go-live window as optional goodwill instead of part of the deployment. The first week of production is where the system meets reality; being absent for it forfeits the cheapest learning the engagement will ever get.

When Phase 8 is done

The system is live — and the clock is finally real

Deployment ends with the rollback rehearsed, a recorded go, the proven artifact in production, smoke green against live endpoints, and monitoring receiving real data. The success metric stops being instrumentation and starts being traffic — the first true numbers on the clock the client hired you to fix. Where to go next:

Phase 9 →Monitoring — alert thresholds from real baselines, the drill, and the retrospective. The Reference view →The precise mechanics of Phase 8 — roles, the five-day calendar, artifacts, the exact gate.

Before anything ships, one handoff and one proven artifact arrive

What Phase 8 received

Harbor Mutual — a fictional regional insurer — hired a five-person pod to rebuild how property-insurance claims get reported and decided. A claim takes a median of 11.4 days from FNOL (first notice of loss) to a coverage decision; the target is 5 days or less. Phase 7 closed Friday 2026-07-17 with the documentation cold-verified by Harbor's own people. Deployment builds nothing new — it starts from what Build proved and what Phase 7 wrote down.

Inherited from Phase 7 — the deployment starts from these, on disk phase8-handoff.md RUNBOOK.md README.md api-docs.md rc-1.0.0 — the release candidate, already proven in test

The four things that shape the week

Nothing about deployment is invented this week. Four rules from the standard decide how it goes, and not one of them is a machine's to make.

Promote, never rebuild. The exact artifact that passed test is the artifact that takes real traffic — rc-1.0.0, byte for byte, never a fresh build for production.
Rehearse the rollback. Deploy → roll back → redeploy, run in test by the client's own hands before any production promotion. A rollback that has never run is a wish.
The client owns the rollout shape. Cutover, pilot, or parallel run — decided by Harbor in writing, with triggers, before the ceremony.
Rotate the secrets. Everything the pod ever touched moves to production-only values the pod cannot read — the handoff made literal.

Where the week is headed

Five business days, go-live deliberately mid-week — never the last day before a weekend, because the day after go-live is a working day for finding what go-live shook loose.

Nobody new joins the story. That is the point of the week: every hand on the keyboard is a hand that stays after the pod leaves. Tom Reilly executes every promotion; the production access list never includes a pod member.

Where Harbor stood entering the week

"The system runs in dev and test; production exists as Bicep that has never taken a real claim. This week it takes its first."

Our pod

Maya ChenPod Lead — owns the go/no-go ceremony

Rob FeldSetup Owner — the release manager this week; owns the checklist

Jonah KimOrchestrator — ships the rollback fix, spec 0046

Sara WhitfieldOrchestrator — checks the rollback fix

Nadia BrooksQuality Engineer — owns the smoke suite and the production verification

Harbor Mutual

Tom ReillyPlatform engineer — executes every promotion and both rehearsals

Dan KowalskiIT security — rotates the secrets; holds at the ceremony

Luis OrtegaProduct owner — owns the rollout shape

Dee AlvarezIntake supervisor — runs intake on the new system, go-live day

Karen VossSponsor — signs the gate at steering

Harbor on-call leadOperations — walks the rollback, drives hypercare

The ID codes, decoded

Every artifact in this engagement carries a stable identifier, so a decision made in week two can still be traced in month nine. On this page you'll see four:

Code	What it is	Born in	Example here
`NNNN`	A spec — one feature in one file, `specs/NNNN-name.md`	Build	Build closed at 0044; 0045 was Phase 7's defect fix; 0046 is this week's config-versioning fix
`rc-X.Y.Z`	A release candidate — the exact built artifact, promoted up the environments unchanged	Build / Deploy	rc-1.0.0 (Tuesday's rehearsal), rc-1.0.1 (promoted to production Thursday)
`C-NN`	A constraint from Phase 0 — a hard limit the system must honor	Phase 0	C-04: two states require claim acknowledgment within 15 business days — now enforced by the system, not by vigilance
`Q-NN`	An open question with a named owner	any	Q-17: the postal dispatch vendor, live for the first time this week

Build closed at spec 0044; the backlog is feature-complete. The only new code this week is spec 0046 — the fix the rollback rehearsal forced. Everything else is promotion, not construction.

The machine's steps, the humans' five days, braided

The procedure, step by step

Phase 8 is the least code-writing phase in the standard. The plugin runs a short, mostly agent-driven sequence; the standard wraps it in the human work a real deployment needs — the rehearsal, the rollout decision, the secrets rotation, and the one ceremony the whole method bends around. Below, they're braided: what the tool runs, what the humans do that the tool cannot, and the file each step 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 7/20 · plugin Step 0 opens · Step 1

Set the table: the checklist, the secrets, the rollout shape

Advancing into Phase 8 fires the plugin's first move: a go/no-go HITL gate (Step 0) that asks the human the deployment target, the rollback plan, who to notify, staging-only or production, and the window. Then Step 1 — Claude drafts the pre-deployment checklist from the proven RUNBOOK, and the release notes from the merged specs.

Tooling /sdlc-next → Step 0 HITL go/no-go Step 1 drafts checklist + release notes

Out — under .sdlc/artifacts/08-deployment/ deployment-checklist.md release-notes.md secrets rotation record — method requires it; no command writes it rollout-shape decision — method requires it; no command writes it

The gap you should know about

The plugin fires its only go/no-go here — a single AskUserQuestion, up front, before any rehearsal or smoke evidence exists. The standard's recorded ceremony (seven roles, evidence on the table) is Wednesday, after the dress rehearsal. And two of this day's biggest jobs — rotating every secret the pod touched, and deciding the rollout shape — are neither plugin steps nor plugin artifacts. Human work that today leaves no receipt.

At Harbor

The checklist gets walked top to bottom; the production access list is cut to least privilege — two Harbor operators, Tom, the pipeline identity, no pod member. Dan and Tom rotate every credential the pod touched to production-only values in Harbor's Key Vault, and Dan signs. Luis, Dee, and Harbor's ops decide the rollout shape: cutover at intake, a 30-day warm fallback, written triggers.

Day 2 — Tue 7/21 · plugin Step 1 verify · Step 2

Promote the environment, then rehearse the failure — on purpose

The production environment provisions from the same infrastructure code that built dev and test — a HIGH-risk change, reviewed line by line. Then the rehearsal the standard demands, run in test by the hands that would run it at 2 a.m.: deploy → roll back → redeploy. The plugin's Step 2 spawns devops-automator to deploy against the RUNBOOK; on a build failure it spawns build-error-resolver.

Tooling Step 2 → devops-automator (uses RUNBOOK.md) the rehearsal — the client's own hands; no command runs it

Out rollback rehearsal evidence — the timestamped timeline; no command writes it the go decision to promote the env — a human review

Does the plugin rehearse the rollback? No.

Step 1's checklist carries a "Rollback verification (deploy → roll back → redeploy)" line, and rollback-procedure.md exists as an optional artifact. But nothing writes the timestamped rehearsal evidence, and nothing requires the client's operators to be the ones who run it. The registry's exit gate says the rollback must be "rehearsed in test by the client's operators" — an exit criterion for evidence no command produces and no required file holds.

At Harbor

The rollback failed. The previous app revision crash-looped on startup: two config keys added since had moved forward independently of the artifact, so the old code didn't know them. That is Tuesday doing its job. Jonah opens spec 0046 — version the app configuration with the release artifact — and it rides the full loop: plan approved, built, graded, checked by Sara (non-author), merged. The RUNBOOK is corrected the same afternoon.

Day 3 — Wed 7/22 · plugin Step 3 · Step 6 · the ceremony

A clean re-run, the smoke suite, then seven names on a decision

The re-rehearsal runs clean — the old revision healthy in under four minutes. The candidate promotes to test through the full written procedure, and the plugin's Step 3 spawns e2e-runner to run the smoke suite: one non-destructive journey per top-priority story. Then the human work the plugin does not perform: the go/no-go ceremony, evidence packet on screen, every named role asked in turn.

Tooling /e2e → e2e-runner (test) /visual-explainer → the evidence packet the ceremony — humans in a room; no command runs it

Out smoke-test-results.md — test .sdlc/reports/phase08-visual.html the go/no-go record — the seven-role table; no command writes it

The most protected stop has no required home

The go/no-go is the single most protected stop in the standard — yet the plugin's only form for it is go-no-go-record.md, marked optional. The registry's exit gate requires "a recorded go/no-go with every named role asked and answered," but the artifact that would hold that record is optional and nothing writes it. The seven-role table you'll see in §05 is hand-authored.

At Harbor

16:00. Seven roles asked by name — release manager, platform, operations, security, product, quality, sponsor. Six immediate goes. Then Dan Kowalski, security: held until the secrets-rotation record was attached to the packet, not merely referenced — then go. Five minutes of friction, which is exactly what a real human stop looks like. Decision: GO. Window Thursday 07:00.

Day 4 — Thu 7/23 · plugin Step 4 · go-live

The same artifact, now taking real claims

07:00: the promotion runs in the agreed window. The client's platform engineer executes; the release manager calls each checklist step. The plugin's Step 4 re-spawns e2e-runner against the production target — but the promotion itself is a human's hands, never the AI unattended. The same artifact that passed test goes to production: promoted, not rebuilt.

Tooling /e2e → e2e-runner (production, test-mode paths) the promotion — Tom executes, Rob calls the steps

Out smoke-test-results.md — production appended the first real traffic, watched end to end

At Harbor

07:25 production smoke green through the test-mode paths — no real letters dispatched, no real records left behind. Monitoring confirmed receiving. 08:14 the first real FNOL: a burst pipe, reported through the portal, traced end to end — queue entry, replica verification (140 ms), fast-path recommendation (single dwelling, no injury, under $25k, the 61% case), acknowledgment through the postal vendor (Q-17, live for the first time), landing in Gail Tran's queue with a coverage recommendation 3 hours 6 minutes after FNOL. 27 claims by close; the legacy fallback warm and untouched.

Day 5 — Fri 7/24 · plugin Steps 5–7 · the gate

Watch it live, draft the handoff, then the gate reports and a human signs

The two-week hypercare window opens — Harbor's operators driving, the pod beside them. Step 5 drafts the Phase 9 handoff; Step 6 renders the visual report; Step 7 runs the gate. The gate checks the files and stops; advance_phase.py will not move the engagement forward without a named human's sign-off.

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

Out phase9-handoff.md .sdlc/reports/phase08-report.html the sponsor's signature — billing milestone 6

What the gate actually checks

check_gates.py verifies that four files — release-notes.md, deployment-checklist.md, smoke-test-results.md, phase9-handoff.md — exist, are non-empty, and contain no placeholder text. It never enforces the registry's real conditions: rollback rehearsed by the client's operators, a recorded go/no-go, production smoke passing. Those are surfaced as manual review items and never block the exit code. The human is stopped and asked to sign; the checklist they should be signing against is never put in front of them.

At Harbor

Day one of hypercare surfaces one finding — an acknowledgment-dispatch retry burst during a postal-vendor blip, no claim affected — logged as a Phase 9 alert candidate, not a defect. The release notes go out. The gate passes; Karen signs at steering with the first production numbers and the honest caveat. Billing milestone 6.

1 / 5

Everything that exists on Friday and didn't on Monday

What Phase 8 produced

The deployment's whole output, named. Blue rows are written by a command and checked by the gate. Amber rows are the method's human work — required by this standard, produced by no tool, and today leaving no file behind. For a phase whose signature moves are a rehearsal, a rotation, and a ceremony, the amber rows are most of what matters.

Artifact	What it actually is	Written by	Signed by	Lives at	Feeds
release-notes.md	What this release delivers, written for people who never saw a spec: features, fixes, limitations, what changes for users	Claude, from the 45 merged specs (Step 1)	Pod Lead	`.sdlc/artifacts/08-deployment/`	Harbor's stakeholders; go-live
deployment-checklist.md	Every step ordered and observable, with an expected outcome and a verification; the rollback procedure lives here as a checklist line	Claude, from the proven RUNBOOK (Step 1)	Setup Owner	`.sdlc/artifacts/08-deployment/`	The promotion; the rollback
smoke-test-results.md	One non-destructive journey per top-priority story, run in test then production, pass/fail per journey with evidence	`/e2e` → `e2e-runner` (Steps 3–4)	Quality Engineer	`.sdlc/artifacts/08-deployment/`	The go/no-go packet; Phase 9
phase9-handoff.md	Deployment summary, current system state, monitoring requirements, known issues in production, escalation contacts	Step 5 drafts; Pod Lead completes	Pod Lead	`.sdlc/artifacts/08-deployment/`	Phase 9, directly
phase08-report.html phase08-visual.html	The gate result and artifact inventory, and the rendered go/no-go evidence packet — self-contained HTML	`generate_phase_report.py`; `/visual-explainer`	—	`.sdlc/reports/`	The manual sign-off gate; the ceremony
rollback rehearsal evidence	The timestamped deploy → roll back → redeploy timeline, run in test by the client's operators, with time-back-to-healthy — the proof the rollback is a procedure, not a wish	The client's operators, by hand	Setup Owner	no path — `rollback-procedure.md` is optional; nothing writes the evidence	The go/no-go packet
rollout-shape decision	Cutover / pilot / parallel chosen; the in-flight-work answer; the fallback and its trigger conditions — owned by the client, in writing, before the ceremony	Product Owner + operations	Product Owner	no path — nothing writes it	The go/no-go packet; hypercare
the go/no-go record	Every named role asked and answered, the decision and its rationale recorded with names — the durable proof a human said go	Pod Lead, by hand	Pod Lead	no path — `go-no-go-record.md` is optional; nothing writes it	The exit gate; the audit trail
secrets rotation record	Production secrets rotated to values the pod never held, signed by the client's security — the handoff made literal	Setup Owner + client security	Client security	no path — nothing writes it	The go/no-go packet; Phase C access revocation

Read the amber rows again

Four of the nine things Phase 8 is supposed to produce have nowhere to live — and they are the four that are this phase: the rehearsal that found Harbor's crash-loop, the rollout decision Luis owns, the ceremony seven people stood in, and the rotation that made the handoff real. The plugin marks the go/no-go record and the rollback procedure optional while its own registry demands both at the exit gate. Human work is not the problem. Human work without a receipt is.

Deliberately not produced in Phase 8: alert definitions and thresholds (Phase 9 sets them against real baseline data), new features of any kind, and any data migration that was not explicitly scoped — the deployment door is not where scope arrives.

The week's most valuable event, reproduced whole

A rollback that has never run is a wish, not a plan

On Tuesday the rehearsal rollback failed — the previous app revision crash-looped on startup because two config keys added since had moved forward independently of the artifact. The fix rode the loop as spec 0046; Wednesday's re-rehearsal ran clean. This is the evidence timeline, both runs, exactly as it was attached to the go/no-go packet — the artifact the plugin never writes.

Tue 7/21  14:02  Test env: deploy release candidate rc-1.0.0      OK (9 min)
          14:31  Execute RUNBOOK rollback to previous revision    FAIL
                 Previous revision crash-looped on startup: required
                 config keys (added wk 9, wk 12) absent from old code,
                 present in current app configuration. Config had moved
                 forward independently of the artifact.
          15:10  Spec 0046 opened: version app configuration WITH the
                 release artifact (config snapshot per revision; rollback
                 restores both). Rides the loop: plan approved, built,
                 graded, checked by non-author, merged.
          17:40  RUNBOOK rollback procedure corrected; deploy-test green.
Wed 7/22  08:05  Re-rehearsal: deploy rc-1.0.1                    OK (8 min)
          08:19  Rollback to previous revision + its config       OK (3 min 52 s,
                 old revision Healthy)
          08:31  Redeploy rc-1.0.1                                OK (8 min)
                 Procedure executed end-to-end by Tom Reilly. Evidence
                 (logs + timings) attached to the go/no-go packet.

Why Tuesday's failure was the win

A rollback that fails in rehearsal, by appointment, cost an afternoon and produced spec 0046. The same failure during a Thursday-night incident would have been an outage with an audience. Both rehearsals went in the evidence packet — the failed one and the clean one — because "we found the hole and closed it" is stronger evidence than an unblemished record nobody stress-tested. Never promote past a failed rehearsal: fix it, re-rehearse, and move the window if you must.

Seven names on a decision — and one held answer

Artifact: the go/no-go record

Wednesday 16:00. The evidence packet on screen — Tuesday's failed rehearsal and Wednesday's clean one (both), the smoke results, the rotation record, the rollout shape with its triggers, the notification list, the window. Seven people asked in turn, by name. This is the record Maya kept — hand-authored, because the plugin marks it optional and nothing writes it.

Role	Name	Asked	Answer
Release manager	Rob Feld	16:09	Go — rehearsal evidence attached (Tue fail + Wed clean), checklist ready
Platform	Tom Reilly	16:10	Go — I executed both rehearsals; the procedure is mine
Operations	Harbor on-call lead	16:11	Go — rollback walked by my team, triggers understood
Security	Dan Kowalski	16:18	Held until the rotation record was attached to the packet — then go
Product	Luis Ortega	16:19	Go — rollout shape and in-flight answer are mine, in writing
Quality	Nadia Brooks	16:20	Go — smoke green per journey in test; production plan is test-mode only
Sponsor	Karen Voss	16:21	Go

Decision: GO. Window Thursday 2026-07-23 07:00, maintenance window 90 minutes, fallback trigger conditions attached. Recorded by Maya Chen.

Dan's held answer is the ceremony working

A go/no-go where friction is unwelcome is theater — and theater here is how outages get scheduled. Five minutes of "attach the record, don't reference it" is what a real human stop looks like. Anyone could have said no, and a no today is cheap.

An exhibit from smoke-test-results.md — and the first real FNOL

Check it for real — without the check itself causing the incident

07:25, production smoke green — every journey through the test-mode paths, no real letters dispatched, no real records left behind beyond flagged test rows. Monitoring confirmed receiving. Then at 08:14 the first real claim arrived, and the room watched it end to end.

11.4 → 3h 6m median days-to-decision baseline → the first production claim, end to end

The smoke suite (test, then production)

One non-destructive journey per top-priority story, test-mode paths only:

Portal FNOL to acknowledgment (test mode)
Phone intake with no policy number routing to manual review
The fast-path recommendation surfacing to an adjuster queue
A duplicate report joining its existing claim
A replica-window degradation showing "pending verification" with its staleness timestamp

All green; results recorded per journey. Monitoring confirmed receiving — the dashboards Phase 3 wired show production telemetry. Tuning the alerts is Phase 9's job; today the requirement is simply not flying blind.

The first FNOL, traced

A policyholder reported a burst pipe through the portal. Queue entry, replica verification (140 ms), fast-path recommendation (single dwelling, no injury, under $25k — the 61% case), acknowledgment dispatched through the postal vendor (Q-17's integration, live for the first time), and the claim landed in Gail Tran's queue with a coverage recommendation 3 hours and 6 minutes after FNOL.

Dee's team ran intake all day on the new system; 27 claims arrived by close of business. The legacy fallback stayed warm and untouched.

The first number was reported with its caveat

3.1 hours against an 11.4-day baseline is a thrilling data point — and steering heard "data point," not "result." One good day is a data point, not a median; the 5-day target gets judged on the median, in Phase 9 and beyond. The credibility spent overclaiming week one is never recovered at close.

The handoff — and what crosses into Monitoring

Artifact: the Phase 9 handoff (summary)

Drafted Friday by Claude (Step 5), carried into Monitoring.

Deployed: rc-1.0.1 to production, Thursday 2026-07-23 07:00–07:25, by Harbor's platform engineer through the pipeline. Rollout: cutover at intake; legacy fallback warm for 30 days with written triggers.
System state: all services healthy; replica verification live; acknowledgment dispatch live through the postal vendor; test-mode paths available for ongoing smoke.
Monitoring must cover: the RUNBOOK's five failure scenarios (each names its alert), plus one new candidate from hypercare day one — acknowledgment-dispatch retry bursts during vendor blips. Thresholds to be set against real baseline data, not guesses.
Known issues: none open; spec 0046 (config versioned with artifact) merged during rehearsal week.
Escalation: Harbor on-call first; Tom for platform; the pod during the two-week hypercare window; contacts listed with hours.

What Phase 9 receives

A phase ends by handing the next one a package, not a feeling. Everything below crosses the boundary into Monitoring: the live system, the deployment record, the verification evidence, and the one finding hypercare has already surfaced. The Build backlog closed at 0044 — no numbered open question travels with this handoff; the questions now are thresholds, and those come from measured reality in Phase 9.

Crosses into Phase 9 phase9-handoff.md release-notes.md deployment-checklist.md smoke-test-results.md RUNBOOK.md — the five failure scenarios the go/no-go record + rehearsal evidence the first production baseline — a data point, not a median

All names, numbers, and documents are invented but internally consistent — the 11.4-day baseline, the spec IDs, and the constraint and question IDs trace through every artifact on this page.

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

Phase 8 takes about five business days, and almost none of it is typing. The software doesn't change this week — only who is looking at it. Read this once end to end before you start: two steps need people booked days ahead, and one step must never be automated.

Before you type anything

What you need first

Six things. Four of them are people or decisions, not software — and two of them have to exist before anything reaches production, not during.

The plugin, installed. If /sdlc-status isn't in your slash command list, run /plugin marketplace add MCKRUZ/claude-code-sdlc then /plugin install claude-code-sdlc@mckruz.
uv installed (the plugin runs Python scripts through it). pip install uv or brew install uv.
Phase 7 closed, and phase8-handoff.md read. That's the entry criteria. If you haven't read the handoff, you don't yet know what you're deploying.
The production environment provisioned, and its configuration and secrets ready. Provisioned from the same infrastructure code that built dev and test — not hand-built this week.
A written rollback plan, before the promote. Not "we'd redeploy the old version." The exact steps, plus the trigger — the written condition that makes someone decide to roll back. You will rehearse it at step 04; it has to exist before then.
A named go/no-go decision owner. One person — usually the release manager — owns the promote decision, and everyone knows who it is. Also name the client's platform engineer who will actually run the promotion, and book the client's operators for rehearsal week.

The mistake new people make

Treating the rollback as a document. A rollback that has never been executed is a wish. It gets run for the first time at step 04, in test, by the client's own operators — and if those people can't make rehearsal week, the deployment date moves. The rehearsal doesn't.

Type this — the phase opens with a planning gate, not the decision

Start the phase

You type /sdlc

What happens: Claude reads phase8-handoff.md and shows you the Phase 8 guidance, then stops before any deployment activity and asks five questions in a picker: the deployment target and strategy (blue/green, rolling, canary, or direct replacement), the rollback plan and its trigger condition, who must be notified before / during / after, whether this is test-only or test plus production, and the deployment window — when it starts and how long it runs.

What you do: answer with decisions the client has already made, not your preferences. If you don't know the answer to one of them, that's the finding — go get it agreed before you type anything else.

This is not the go/no-go

This gate plans the deployment. The go/no-go decides it, and it happens at step 07, after the rehearsal and the smoke results exist. Don't let a good conversation here feel like approval — there is no evidence on the table yet.

Nothing to type — the checklist and the credentials

Walk the checklist, rotate the secrets

You type nothing — ask Claude in the session to draft, then walk it with the client

What happens: no command does this. Claude drafts deployment-checklist.md from the RUNBOOK that Phase 7 proved: every step ordered, each with an action, an expected outcome, and how to verify it. It also needs a rollback procedure with decision criteria, a post-deployment verification section, and sign-off lines.

What you do: walk the checklist with the client's platform engineer. Review the configuration for the target environment. Cut the production access list to least privilege. Draft the stakeholder notifications with the window in them. Then rotate every credential the pod has ever touched to production-only values the pod has never held, and write secrets-rotation-record.md: each credential, what it was for, where it now lives, the rotation date, and anything deliberately not rotated with the reason and who accepted the risk.

The pod cannot sign the rotation

The secrets rotation is confirmed by the client's security function, by name, or it is not confirmed. If it genuinely did not happen, write a line in the file reading WAIVED: <name> — <reason>. The gate accepts that and prints it, with the name, in the report the approver signs against. A missing file still blocks. The escape is from the work, not from the record.

You now have deployment-checklist.md secrets-rotation-record.md — signed by client security

Nothing to type — and this one belongs to the client

Get the rollout shape decided

You type nothing — this is a session with the client's product owner and operations

What happens: the client decides how production traffic arrives — a full cutover, a pilot cohort, or a parallel run alongside the old process. You write it down as rollout-shape-decision.md: the shape and why, what happens to work already in flight in the old process, the fallback, and the conditions that would trigger it. Named owner, dated.

What you do: route the decision, don't make it. Then get it written before the ceremony. A rollout shape improvised at the go/no-go is a rollout shape nobody in operations has staffed.

You now have rollout-shape-decision.md — optional; the gate won't block on it, but the approver is asked

Don't move on until: someone with a name owns the shape and the in-flight-work answer. "We'll decide at the ceremony" means it gets decided under time pressure by whoever speaks first.

Nothing to type — the most useful hour of the week

Rehearse the rollback in test

You type nothing — the client's operators drive; you watch and take timestamps

What happens: in the test environment, the client's own operators run deploy → roll back → redeploy. For real. From the procedure in the checklist, with their own permissions, using the same hands that would do it at 2 a.m.

What you do: record it in rollback-rehearsal.md — the timeline with each step stamped (deploy, the decision to roll back, rollback complete, redeploy), the time back to healthy measured rather than estimated, who ran it by name, the written trigger conditions, and what broke that nobody expected.

A clean first rehearsal is suspicious

A rehearsal where nothing surprised anyone was probably not run against anything real. If the first attempt fails, that is the rehearsal doing its job — put the failed run in the file next to the clean one. Found-and-fixed is stronger evidence than never-stressed. Fix what it surfaced through the normal loop, re-rehearse, and move the window. Never promote past a failed rehearsal.

You now have rollback-rehearsal.md — timestamped, with names

Type this — the dress rehearsal

Deploy to test and smoke it

You type /e2e

What happens: the release candidate goes to the test environment through the full procedure — the client's platform engineer executes it, calling each checklist step. Then the smoke suite runs: one journey per top-priority user story, minimum, non-destructive (reads and harmless writes only). You are not writing this suite this week — it is assembled from end-to-end journeys that already exist, trimmed to the safe paths.

What you do: record results per test in smoke-test-results.md: the environment, a table of test / story / environment / result / notes, any issues found with their severity and resolution, and references to the screenshots captured as evidence. Keep the test and production sections separate — you'll add the production half at step 09.

Two helpers this phase names that don't exist

The phase definition tells Claude to spawn an agent called devops-automator for the deployment and e2e-runner for the smoke tests. Neither ships with the plugin. Do the deploy through your pipeline and run your end-to-end suite directly. build-error-resolver is real — /sdlc-setup installs it into .claude/agents/, and it's the right thing to reach for if the deployment build fails. /e2e is listed as this phase's primary skill but also isn't part of the plugin; if you don't have it, run the suite however your project already runs it.

You now have smoke-test-results.md — test section filled in

Nothing special to type — but write it now, not on go-live day

Draft the release notes

You type nothing — ask Claude to draft release-notes.md from the merged specs

What happens: Claude assembles the notes from every spec merged since the build started. There's no dedicated command for it; /sdlc reminds you what the file must contain.

Section	What goes in it
Version	The semantic version and the release date
Summary	What this release delivers — two or three sentences, for stakeholders
New features	User-facing capabilities added
Bug fixes	Issues resolved
Breaking changes	Anything that requires the people using it to do something
Known limitations	What doesn't work yet, and what has caveats
Upgrade path	How to move from the previous version, if there is one

What you do: read the draft as someone who never saw a spec, because that's who it's for. Cut every internal term. If a line only makes sense to the people who built the system, rewrite it or delete it.

You now have release-notes.md

Nothing to type — and nothing here is ever automated

The go/no-go

You type nothing — this is a meeting, and it is the point of the phase

A named human decides whether this goes to production. Not a gate, not a command, not Claude. Every release, this one and every one after it.

What happens: the evidence goes on the table — the rehearsal record, the smoke results, the written rollback trigger, the rollout shape, the notification list, the deployment window. Then every named role is asked in turn: release manager, platform engineer, operations, security, product owner, quality, sponsor. Each answers go, no, or held. A held answer names its condition, and the ceremony waits until that condition is met or it becomes a no.

What you do: write go-no-go-record.md as it happens — every role, the name, the time, the answer, and one line of rationale each, plus the decision and the agreed window. Write it in the room, not from memory afterwards.

The gate has no idea what belongs in this file

go-no-go-record.md is a required artifact, but unlike every other required file in this phase it has no content specification behind it. The automated check only confirms the file exists, isn't empty, and has no leftover TODO. The list above is what actually has to be in it — nothing will tell you if you leave half of it out.

Go/no-go theater

The failure mode is a ceremony where the decision was really made days ago and the meeting exists to nod. The tell: nobody in the room could plausibly say no. A no is cheap today and expensive next week — make it genuinely available, and never punish the person who used it.

You now have go-no-go-record.md — a named human said go, on the record

Nothing to type — the client's engineer runs it

Promote to production

You type nothing in Claude — the promotion runs through the pipeline

What happens: in the agreed window, the client's platform engineer promotes the same artifact that passed test to production. The release manager calls each checklist step out loud; the pod and the client's operators watch the same dashboards.

What you do: stay off the keyboard. The people who will run this system in a month should be the ones running it today, with you beside them. Log each step and its outcome as you go — deployment-log.md is an optional artifact and this is where it gets written.

Promote, never rebuild

Do not kick off a fresh build for production "real quick." A rebuilt artifact is something no environment ever verified, and you have just spent a week verifying the other one.

There is no production deploy workflow in the kit

The kit ships one deploy workflow: .github/workflows/deploy-dev.yml, and it targets dev only. It is a starter skeleton — its deploy, health-check and restore steps are placeholders (<<DEPLOY_STEP>>, <<HEALTH_CHECK>>, <<RESTORE_LAST_GOOD>>) you wire to the client's platform. Promotion beyond dev is deliberately not automated and not shipped: you build that path with the client, and step 04 is where you prove it works. Don't go looking for a deploy-prod file — it doesn't exist, and expecting it is how a promotion turns into an improvisation.

Type this — then watch, with your hands off

Smoke production and watch the first real traffic

You type /e2e

What happens: the same smoke suite runs against live production endpoints — one journey per top-priority story, non-destructive, through the test-mode paths built for exactly this. Results go into the production section of smoke-test-results.md, alongside the test results and the go/no-go decision with its rationale.

What you do: three things. Confirm the smoke suite is green. Confirm monitoring is receiving production data — tuning the alerts is Phase 9's job, but going live blind is not acceptable today. Then trace the first real transactions end to end against expected behaviour, with the people who own the outcome looking at the same screen.

If it can corrupt data, it isn't a smoke test

Reads and harmless writes only, through flagged test-mode paths that leave no unflagged records. The classic own-goal in this phase is a verification step that causes the incident it was meant to catch.

Don't move on until: the production smoke section is filled in with a result per test, and someone has watched a real transaction all the way through.

Nothing to type — the path you rehearsed

If it goes wrong, roll back

You type nothing — the operators run the procedure they rehearsed at step 04

What happens: you already know when to call it, because the trigger condition was written down before the promote and rehearsed in test. Someone calls it, the operators run the procedure, and production returns to the last known-good version.

What you do: do not debug forward in production. Roll back first, then diagnose in test. Record the incident under "Issues found" in smoke-test-results.md and in deployment-log.md, fix the cause through the normal loop, re-rehearse, and go back to step 07 — a second promote needs a second recorded go.

A rollback is not a failed phase. Promoting past a failed rehearsal is. The whole design of this week is to make the expensive discovery happen somewhere cheap.

Type this — the machine checks your paperwork

Run the gate

You type /sdlc-gate

What happens: it checks that seven required files exist, aren't empty, and have no leftover placeholder text — TODO, TBD, PLACEHOLDER, [INSERT. Then it renders the phase's exit conditions as review items for the human who signs, and opens an HTML report in your browser.

The seven it requires release-notes.md deployment-checklist.md smoke-test-results.md phase9-handoff.md rollback-rehearsal.md go-no-go-record.md secrets-rotation-record.md

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

What the gate does NOT check

It cannot tell whether the rollback actually ran, whether the ceremony actually happened, or whether production smoke actually passed. Those three are its exit conditions, and they are rendered for review only — they never block. Four more things the delivery standard requires to close this phase aren't in the automated list at all: monitoring receiving production data, the first real traffic traced end to end, hypercare underway on its agreed window, and the release notes actually sent to stakeholders. A green gate means the paperwork exists. Walk those seven yourself.

The phase definition also asks for an interactive visual report generated with a /visual-explainer skill. That skill isn't part of the plugin, and no gate checks for the file — treat it as optional polish for the stakeholder review, not a blocker.

Type this — last thing in the phase

Sign off and advance

You type /sdlc-next

Before you type it: draft phase9-handoff.md — what was deployed, when and where; the current system state and how to verify it; what monitoring must cover; known issues in production; and the escalation contacts, by name. Then run steering with the sponsor: the deployment record, the smoke results, and the first real production numbers on the outcome scorecard, however early. This gate is a billing milestone.

What happens: it re-runs the gates, opens the report, and stops to ask you to confirm before it moves anything. Say yes and it advances the project to Phase 9. Then it pulls every open question out of your handoff document and blocks until each one is answered or explicitly defaulted — no Phase 9 work gets written until they are.

What you do: answer them properly. In this phase they're usually the things production just taught you, and Phase 9 is where they turn into alerts.

Phase 8 is done when state.yaml says Phase 9 a named human's go is on the record production smoke green and monitoring receiving data hypercare underway on its agreed window

Keep these handy

Commands you'll use constantly

Type this	When
`/sdlc-status`	Any time you're lost. Shows what phase you're in and what's missing.
`/sdlc`	Start of every work session. Tells you what to do next.
`/sdlc-gate`	After each artifact lands, not just at the end. Cheaper to fix one file at a time.
`/sdlc-phase-report`	Regenerate the HTML report to share with stakeholders before sign-off.
`/sdlc-coach`	You're stuck and want to be walked through it conversationally instead of following a list.

Rule of thumb for the whole phase: Claude prepares the evidence, humans make the decision. Every other phase has judgment calls you could arguably automate one day. This one has exactly one that you never will — a deployment without a recorded human go isn't a deployment, it's an incident.

Reference · Phase 8 · Deployment

The precise mechanics — the exact roles, calendar, artifacts, and gate, including the tooling 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 Harbor artifacts (every ID and quote), see Example.

The four questions

Phase 8 answers four questions, and nothing else. New features, alert tuning, and incident-response drills are out of scope; data migration is in scope only if the engagement explicitly scoped it.

Is the path to production proven? (deploy → roll back → redeploy, rehearsed in test — a rollback that has never run is a wish)
Is the rollout shape decided and owned? (cutover, pilot, or parallel run — chosen by the client, with trigger conditions written down)
Did a named human say go? (the ceremony: evidence presented, every role asked, the decision recorded)
Is production verifiably healthy? (smoke green against live endpoints, monitoring receiving real data, first real traffic watched end to end)

The human / AI contract for this phase

Human drives	Claude does	Mandatory human stops
The client's platform engineer executes the promotion and the rehearsal with their own permissions. The release manager owns the checklist; the product owner owns the rollout shape; every named role answers at the go/no-go.	Drafts release notes from the merged specs; drafts the deploy checklist and rollback procedure from the proven RUNBOOK; runs the smoke suite against test and production and reports per journey; watches the first real traffic alongside the humans.	The go/no-go decision is human-owned — always, every release. Claude never deploys to production unattended, decides go/no-go, picks the rollout shape, or marks its own smoke results final. Phase advance.

Who is involved

Our side

Person	Load	Workstream
Setup Owner	80–100%	The release manager — owns the checklist, the rehearsal, the secrets rotation, the promote decision at the ceremony. Pairs with the client's platform engineer who executes
Quality Engineer	60–80%	Owns the smoke suite (one journey per top-priority story, non-destructive), the rehearsal evidence, and the production verification after go-live
Pod Lead	40–60%	Owns the go/no-go ceremony — the roles, the evidence packet, the recorded decision. Routes the rollout-shape decision to the client. Runs steering
Orchestrators	20–40%	Draft the release notes and checklist; fix anything the rehearsal surfaces — through the loop, like any change

Client side

Person	Needed for	How much
Platform / DevOps engineer	Executes the rehearsal and the production promotion with their own permissions — the pod beside them, not on the keyboard	The week, on and off
Product Owner	The rollout shape: who gets the new system, when, and what happens to work in flight. Decided before the ceremony	2–3 hours
Security	Signs the secrets rotation and the production access list; sits in the ceremony	1–2 hours
Operations / on-call	Walk the rollback themselves in rehearsal week, sit in the ceremony, drive during hypercare	3–4 hours
Sponsor	The go/no-go (informed, and asked) and the gate steering	1–2 hours

If the client's operators cannot make rehearsal week, the deployment moves — not the rehearsal. Going live ahead of the people who will run the system is how a successful deploy becomes next month's incident.

The five-day calendar

The default is five business days, with go-live mid-week — never the last day before a weekend. It stretches when the rehearsal fails (good — that is its job) or the client's change-control board adds latency.

Day	Focus	What happens	Tooling
1	Checklist, secrets, rollout shape	Checklist walked; production access list cut to least privilege; secrets rotated to production-only values the pod can't read, signed by client security; rollout-shape session (cutover/pilot/parallel, in-flight answer, fallback + triggers); hypercare window agreed	`/sdlc-coach`
2	Promote env, rehearse failure	Production provisioned from infrastructure code (HIGH-risk review, client engineer executes); the rehearsal in test — deploy → roll back → redeploy by the client's own hands; anything broken fixed through the loop and re-rehearsed	— (rehearsal is human; fixes ride the loop)
3	Dress rehearsal & ceremony	Candidate deploys to test through the full procedure; smoke suite runs (one journey per top-priority story, non-destructive); the go/no-go ceremony — evidence packet on the table, every role asked, decision recorded with names	`/e2e`, `/visual-explainer`
4	Go-live	Promotion runs in the agreed window (client engineer executes, release manager calls steps); same artifact promoted, not rebuilt; production smoke green via test-mode paths; monitoring confirmed receiving; first real traffic traced end to end	`/e2e`
5	Hypercare day one, then the gate	Hypercare window opens (operators driving, pod beside); release notes go out; automated gate check; Phase 9 handoff drafted; steering with the gate sign-off and the first production numbers on the scorecard	`/sdlc-gate`, `/sdlc-phase-report`, `/sdlc-next`

When the rehearsal fails, fix it through the loop, re-rehearse, and move the window — never promote past a failed rehearsal. When change control adds a board, surface the latency at steering; don't absorb it.

The artifacts

Artifact	Drafted by	Owned by	Done means
Release notes	Claude (from the merged specs)	Pod Lead	Readable by people who never saw a spec: features, fixes, limitations, what changes for users
Deployment checklist	Claude (from the proven RUNBOOK)	Setup Owner	Every step ordered, observable, and verified in rehearsal; sign-off lines for the ceremony roles
Rollback procedure + evidence	Claude (drafts), client ops (executes)	Setup Owner	Executed in test by the client's own operators — deploy, roll back, redeploy — with the trigger condition written down
Rollout-shape decision	Product owner + operations	Product Owner	Cutover/pilot/parallel chosen; in-flight work answered; fallback and trigger conditions recorded
Smoke results (test + prod)	Claude (runs), QE (owns)	Quality Engineer	One non-destructive journey per top-priority story, green in both environments, results recorded per test
The go/no-go record	Pod Lead	Pod Lead	Every named role asked and answered, decision and rationale recorded — the durable proof a human said go
Secrets rotation record	Setup Owner + client security	Client security	Production secrets rotated to values the pod never held; signed
Phase 9 handoff	Claude (drafts)	Pod Lead	Deployment summary, system state, monitoring requirements, known issues, escalation contacts

Deliberately not produced: alert definitions and thresholds (Phase 9 sets them against real baseline data), new features of any kind, and any data migration that was not explicitly scoped — the deployment door is not where scope arrives.

The cadences

Rhythm	Who	What
Daily 15-min pod sync	Whole pod	Checklist state, rehearsal findings, the window countdown
The rehearsal	Client platform + ops, pod beside them	Deploy → roll back → redeploy in test, by the hands that will own it
The go/no-go ceremony	All named roles	Evidence presented, every role asked, decision recorded — the phase's defining event
Hypercare	Client operators driving, pod beside	The agreed post-go-live window: dashboards open, findings triaged into the loop or Phase 9
Steering	Sponsor + Pod Lead	Falls at the gate: the deployment record and the first production numbers on the outcome scorecard

The exit gate

Phase 8 closes when all of these are true:

The rollback was executed in test by the client's own operators — deploy, roll back, redeploy — before any production promotion
The production environment was provisioned from code and the secrets rotated to values the pod never held, signed by client security
The rollout shape is decided, written, and owned by the client — including the in-flight-work answer and the fallback trigger
A recorded go/no-go happened — every named role asked, the decision and rationale on record (the most protected stop)
Production deployment succeeded through the pipeline — the same artifact that passed test, promoted, not rebuilt
Production smoke tests passed: one non-destructive journey per top-priority story
Monitoring is receiving production data (tuning comes in Phase 9; blind does not)
The first real traffic was traced end to end and matched expected behavior
Hypercare is underway on its agreed window, and release notes went to stakeholders
The Phase 9 handoff exists: state, monitoring requirements, known issues, escalation contacts
A named human on each side approved the advance — gates report, humans decide

The go/no-go is the single most protected stop in the standard. A ceremony where nobody could plausibly say no is theater — and theater here is how outages get scheduled.

What goes wrong

The Friday deploy. Going live the last day before a weekend, so the system's first hard day happens with nobody watching. Go live mid-week.
The rollback that was only ever written. Documented, reviewed, never run — then executed for the first time during an incident. Rehearse it in test, by the client's own hands.
Go/no-go theater. The decision was really made days ago; the meeting exists to nod. The tell: nobody could plausibly say no.
The rebuilt artifact. A fresh build "real quick" for prod instead of the promoted artifact that passed test. Promote, never rebuild.
Destructive smoke tests. A verification step that writes real records into a day-old production system. Reads and harmless writes through the test-mode paths only.
Deploying ahead of the operators. The system goes live before the people who run it have rehearsed. The date moves; the rehearsal doesn't.
Scope through the deployment door. "While we're at it, migrate the old claims" — a migration nobody scoped. If it wasn't scoped, it isn't in this release.
Hypercare as a courtesy. Treating the post-go-live window as optional goodwill. It's the cheapest learning the engagement will ever get.