Phase C · Close & Transfer — how it works, worked, and referenced

The code was done weeks ago. The system is live, watched, and quiet. So why isn't the engagement over?

Because "done" was never about the code. It's about whether the client can run all of this — the system, the build loop, the judgment — without us in the room.

The engagement ends when the client can run this without us — proven by use, observed, unassisted. Every idea below is paired with the real thing: the close of the Harbor Mutual engagement, a fictional but fully worked project.

Why this phase exists at all

Leaving is a deliverable, not an afterthought

Most projects end by drifting: the team rolls off, a few people keep answering questions on the side, and one day everyone notices it's over. That's not a close. That's a slow leak — and it leaves the client depending on people who are already gone.

The idea

The whole engagement was built so the client's own people learned to run it as they went. Phase C is where that claim stops being an intention and gets proven the same way everything else got proven — by use, observed, without help.

So this phase has a job nobody enjoys: make ourselves unnecessary, on purpose, and prove it. Hands off the keyboard early, out of the room by the test, out of the building at the end.

At Harbor Mutual

By the time Phase C started, Harbor had been doing the handover all along without a ceremony for it. Their lead engineer co-signed every architecture decision back in March. Their newest hire cold-verified the README as a total stranger. Their on-call answered the incident drill.

Phase C wasn't a handover event — it was the moment the handover that had been happening for five months finally got tested, and then proven on the record.

Skip this phase and…

You leave a dependency, not a capability. The client owns a system they can't actually run — and the people who could are billing somewhere else now.

Go deeper — the full method

The engagement does not end when the code is done — the code was done weeks ago. It ends when the client can run all of this without us: the system, the harness, the loop, and the judgment. Phase C is where that claim stops being an intention and gets proven the same way everything else in this standard gets proven — by use, observed, without help.

The whole engagement built toward this phase. The kit was adapted in the open in Foundation so the client's engineers saw how it works. Their lead engineer co-signed every ADR. Their platform engineer executed every promotion. Their newest hire cold-verified the README. Their on-call answered the drill. Phase C is not a handover event; it is the moment the handover that has been happening all along is tested — and then we leave, cleanly, and the standard itself learns from the engagement before the door closes.

Where the engagement is when this phase opens: live in production, observable, drilled, retrospected. The client's operators hold the watch. One thing remains unproven — that the client's team can run the build loop, intent through deploy, without us in the driver's seat. That is the single question Phase C exists to answer.

The rule that governs the whole method

The harness was always the operating system — never us

Throughout the engagement, the AI did the drafting and most of the typing while humans made every decision and carried the accountability. Phase C asks the question that rule was always building toward: was the thing running this project the harness, or was it secretly us?

The idea

The harness — the project's instructions, its specs, its skills and guardrails, all versioned in the client's own repo — was the operating system the whole time. The AI ran inside it. The pod ran inside it.

If that's true, then the client's people can step into the same seats and the machine keeps working. If it's not true — if something only lived in a pod member's head — this phase is where that lie surfaces, while there's still time to fix it.

At Harbor Mutual

The proof was continuity. During the transfer, the same AI agent kept working inside the same harness — only now the client's engineers were the ones driving it.

The question the whole phase answers

"Could Harbor operate this if the pod vanished tonight?"

Nothing about the agent changed when the hands on the wheel did. That's how you know it was the harness running the project, not the people leaving.

Go deeper — the full method

Claude is not handed over — Claude was never ours. The harness, the agents, the skills, and the keys have been the client's since Foundation; what transfers in Phase C is the human judgment around them. Claude's work this phase is bounded and specific:

Audits the harness, read-only. A sweep of the repo for anything that would strand the client: skills with pod-specific assumptions, hooks referencing paths or permissions only we had, conventions that live in pod memory instead of CLAUDE.md. Every finding becomes a documented fix the client Setup Owner merges.
Drafts the final handoff report from the engagement's own records: every gate, every phase report, the metrics history, the debt log, the open items with owners.
Drafts the harvest PR against our standard repo from the Phase 9 retrospective's list — client specifics stripped, patterns generalized — for the pod to review and our standard's deputy to merge.
Keeps working for the client. During the shadow flip and the close gate, Claude is the same agent inside the same harness — driven now by the client's Orchestrators. That continuity is the proof the harness, not the pod, was the operating system.

What Claude never does: drive the close-gate spec (nobody from our side does — that is the test), approve the client team's work as the gate evidence, or write the retrospective's candor for them.

What these three weeks must answer

Four questions — and deliberately nothing else

Everything Phase C does exists to answer exactly four questions. New features are out of scope unless they're the vehicle for the test — and a "quick follow-on" is a brand-new agreement, not a quiet extension of this one.

The idea — the four questions

Can their people run the loop? First with us checking, then one real change end to end with nobody from our side driving.
Is the harness fully theirs? A sweep finds nothing only we understand, and a named client owner has merged changes themselves.
Is the record complete and delivered? Every report, the outcomes dashboard, the debt log — in their hands, in their tooling.
Did we leave cleanly — and did the standard learn? Our access revoked and audited; the lessons sent home before they evaporate.

At Harbor Mutual — the four answers

Ines ran a HIGH-risk change end to end, hit a guardrail, escalated correctly, shipped to production — zero pod hands.
The audit found two small things; Wes, Harbor's owner, merged the fix for each — and a change of his own on top.
Every report 0 through C, the dashboard re-pointed to Priti, the debt log in Harbor's tracker with Harbor owners.
Every pod seat and key revoked and confirmed by Harbor's security; four patterns sent back into our own standard.

The temptation to resist

At the very end, "could you just build one more thing while you're here?" feels generous to say yes to. It isn't. Scope at close is still scope — it burns the calendar the test needs, and it belongs to a new SOW with its own Phase 0.

Go deeper — the full method

Phase C answers four questions, and nothing else:

Can their people run the loop? Their engineers orchestrate real specs with our Checkers first; then one real spec end-to-end with nobody from the pod driving.
Is the harness fully theirs? The audit finds nothing undocumented; the client Setup Owner is named and has merged harness changes themselves.
Is the record complete and delivered? Every phase report, the outcomes dashboard, the debt log — handed over, in their hands, in their tooling.
Did we leave cleanly — and did the standard learn? Access revoked and audited; the harvest PR opened against our own repo before the engagement's lessons evaporate.

New features for the client are out of scope unless they are the vehicle — the specs run during this phase are real work from the client's own backlog, chosen because the close gate must be run on something that matters. A follow-on engagement, if there is one, is a new SOW with its own Phase 0, not a quiet extension of this one. Scope at close is still scope; it burns the calendar the gate needs, and the Pod Lead holds that line precisely because everyone else in the room has an incentive not to.

How the transfer actually starts

The shadow flip — their hands, our eyes

You can't prove someone can drive by describing the car. The transfer opens by reversing the roles that built the whole project: the client's engineers take the driver's seat on real work, and the pod is demoted to checking.

The idea

This is the inverse of how the build began — back then we drove and they watched; now they drive and we watch. The pod becomes Checkers only: review the work, coach by question ("what does the spec say about that path?"), and never, ever grab the keyboard.

And every time a Checker wanted the keyboard gets written down — because each one is a gap in the transfer with a name on it. The point isn't to look good; it's to find what hasn't transferred yet, while it's still cheap to fix.

At Harbor Mutual

Three real changes from Harbor's own backlog rode the loop with Harbor driving and the pod checking:

0047 — adjuster queue saved filters (Ines)
0048 — intake supervisor daily digest (Ines)
0050 — claims-search timeout messaging (Wes)

The bar didn't move an inch: plan-then-build, the automated grader, a non-author reviewer, merge deploys. Jonah and Sara coached by question and logged every keyboard itch as a transfer gap.

Why "real work" matters here

These aren't exercises invented for the occasion. They're ordinary backlog items, mixed difficulty, each sized to finish within the week. A rehearsal with no stakes teaches the rehearsal, not the job.

Go deeper — the full method

The shadow flip is week one's work. The client's engineers take the Orchestrator seat on real specs from their own backlog — triage with their PO, spec writing, bounds, plan approval, driving the agent — while the pod serves only as Checkers. Coaching happens by question ("what does the spec say about that path?"), never by taking the keyboard. At least three real specs ride the loop this way, and the bar is the same bar: the grader runs, a non-author approves, merge deploys.

The specs come out of the client's own intent triage like any other work — ordinary backlog items, mixed tiers, each sized to merge within the week. The Pod Lead confirms each one is real work, not an exercise built for the occasion. A rehearsal with no stakes teaches the rehearsal, not the job.

The pod Checkers log every place they had to coach — every moment they wanted the keyboard — because each one is a transfer gap with a name. The Quality Engineer rolls those logs into the shadow-flip spec record: per spec, who orchestrated, who checked, the grader and Checker outcomes, and the gaps.

Finding what only we understand

Audit the harness for anything living in our heads

The most dangerous thing you can leave behind is knowledge that never made it into the repo — a convention "everyone just knows," a script that only works on a pod laptop, a setting nobody wrote down. It works fine right up until the people who knew it are gone.

The idea

So the harness gets swept — the AI reads the whole repo looking for assumptions that only the pod could satisfy, and a human walks every skill, hook, and convention asking one blunt question: could their team operate this if we vanished tonight?

Every finding becomes a documented fix — and here's the clever part: the client's owner merges each one. The gap closes, and the client owner's real merge history starts to exist at the same time. Two birds.

At Harbor Mutual

After a five-month engagement, the sweep found only two things — because every harness change had been a reviewed PR all along, in the open, where Wes could see it:

Finding 1

The grader's prompt said "review per MCKRUZ standards" — a phrase only the pod could resolve. Rewritten to state the actual rule inline.

Finding 2 — both merged by Wes

A hook read a lint config from a path that existed on pod machines but wasn't in the repo. Pinned into the repo; path made repo-relative.

Go deeper — the full method

The harness audit runs in parallel with the shadow flip: Claude's read-only sweep plus the Setup Owner's walk of every skill, hook, and convention, asking one question — could their team operate this if we vanished tonight? It is a sweep for the indispensable: a skill with pod-specific assumptions, a hook referencing a path or permission only we had, knowledge living in pod memory instead of CLAUDE.md.

Findings get fixed by documented PRs that the client Setup Owner merges, which kills two birds: the gap closes, and the client owner's merge history starts being real. "Ask the pod" must return zero results before the gate — that is the bar the audit exists to clear.

The indispensable pod member

One person's head still holds how something really works, discovered the week after they leave. The harness audit exists for exactly this. Two findings after a five-month engagement is short precisely because the open-adaptation habit from Foundation made every harness change a reviewed PR the client could already see.

An owner, not a label

The harness gets a real owner — proven by their merge history

It's easy to put a name in a slide: "Harbor's Setup Owner is Wes." It means nothing. A harness with a named owner who has never actually changed it doesn't have an owner — it has a label.

The idea

The test for real ownership is the git log, not the org chart. Before we leave, the client's Setup Owner must have merged harness changes themselves — the audit fixes, and at least one improvement of their own.

And the rule that protected us protects them too: no role without a deputy. A named client engineer reviews the owner's harness changes, the same way our deputy reviewed ours. The safety practice transfers along with the keys.

At Harbor Mutual

Wes didn't just merge the two audit fixes. He shipped a harness change of his own, unprompted:

An onboarding bootstrap skill for new Harbor engineers — born directly from Ines's stumble during the July README checkout, turning that one bad day into a permanent practice.

Tom became his named deputy. "Harbor has a Setup Owner" stopped being an org-chart claim and became a git log.

Go deeper — the full method

The client Setup Owner is the named client engineer who owns the harness after close — and who must have merged harness changes themselves before we leave, not merely been told about them. Merge history is the test: the audit fixes, plus at least one change of their own, or the harness has no owner — it has a label.

By week two the client Setup Owner ships at least one harness change of their own — their improvement, their PR, their deputy arrangement on their side. The no-role-without-a-deputy rule transfers too: a named client engineer reviews the client Setup Owner's harness changes, the way our deputy reviewed ours.

The Setup Owner in name only

A client owner who was named in a deck but never merged anything. The defense is mechanical: the git log, not the org chart. The audit fixes plus one change of their own, or it didn't happen.

The test the whole phase exists for

The close gate — one real change, solo, with us silent in the room

This is the moment everything was building toward. The client team runs one real change end to end — deciding it's worth doing, writing the spec, driving the agent, grading it, reviewing it, merging, deploying — with nobody from our side driving. We sit in the room, silent, taking notes.

The idea

The change has to be real: something the client genuinely needs, with a real risk level and real consequences if it goes wrong. A toy change picked because it can't fail proves nothing, and everyone in the room knows it.

And the one unbreakable rule: help voids the run. Any answer, hint, or keyboard touch from our side, and it doesn't count — the gap that question revealed becomes a finding, gets fixed, and the gate re-runs on a different real change. "They got through it with a little help" is a fail, for the same reason it was a fail at the README checkout.

At Harbor Mutual

The gate ran on a HIGH-risk change with a deadline: 0049 — decommission the legacy intake fallback, due at day 30 of the rollout. Ines drove the whole thing.

The wobble the observers were waiting for arrived right on cue:

The guardrail event

The agent's plan drifted toward editing a protected deploy file. The hook blocked it cold.

The judgment that transferred

Ines stopped, escalated the change to Wes as its own reviewed PR — exactly the rule she'd learned eight weeks earlier. The pod said nothing.

The wobble was the win

The best moment of the gate wasn't a flawless run — it was the agent drifting, the rails catching it, and a Harbor engineer responding with the right judgment, unprompted. Mechanics transfer in documents; judgment only shows up under observation.

Go deeper — the full method

The close gate is week two's defining event. One real spec — something the client genuinely needs, with a real risk tier — runs the loop end to end with nobody from the pod driving: their triage, their spec, their bounds, their plan approval, their Checker, their merge, the automatic deploy. The client's triage picks the spec; the Pod Lead confirms it clears the real-spec bar — real need, real tier, real consequences — before the run is scheduled.

The pod observes the way the QE observed the cold runs: present, silent, taking notes. The Quality Engineer's record captures each loop step with timestamps and names, every stall, every guardrail event and how the team responded, the merge and deploy that closed it, and the verdict. Stalls are data. Help — any answer, hint, or keyboard touch from our side — voids the run.

A failed or wobbly run is information, not embarrassment: the gap gets named, fixed — more reps, a harness clarification, a missing playbook line — and the gate is re-run on a different real spec. "They got through it with a little help" fails the close gate for the same reason it failed the README checkout.

The toy close gate

A copy change with a LOW tier and no stakes, chosen so it cannot fail. It proves nothing, and everyone in the room knows it. Real spec, real tier, real consequences — or the gate did not run.

Leaving so you provably can't come back

The clean exit — revoke our access and prove it

A close that ends with the pod still able to reach production isn't a close. It's a "we'll clean up the seats next sprint" that, months later, becomes a finding on somebody's security audit. Leaving cleanly is the last deliverable of the security posture the whole engagement ran on.

The idea

Every pod seat, token, repo permission, environment role, and vault key gets removed — as a dated checklist item, confirmed against the client's own audit trail by their security. Not a cleanup intention; a checklist with a date and a signature.

The list isn't improvised on the last day. It's drafted in week one from everything the engagement was ever granted, so week three is execution, not archaeology. The engagement ends with the pod provably unable to touch the system — which is not distrust, it's the posture being honored to the end.

At Harbor Mutual

Rob and Dan walked the revocation as a checklist, item by item, then confirmed it against Harbor's audit trail. By end of day the pod provably could not touch the system it built.

Dan signed the record. It went in the close packet next to Phase 8's secrets rotation — the engagement's bookends: we never held production secrets, and now we hold nothing at all.

The trap to name out loud

"We'll sort the seats out next sprint" un-revokes the whole thing. Revocation is a gate item with a date and a security signature, or it didn't happen.

Go deeper — the full method

Access revocation is the deliberate, audited removal of every pod credential, seat, and permission — a checklist item with a date, not an eventual cleanup. Every pod seat, token, repo permission, environment role, and vault access is removed on a checklist, confirmed against the client's audit trail by their security.

The Setup Owner drafts the checklist in week one from everything the engagement was ever granted — the Phase 0/1 access checklist, CI secrets, environment roles, vault policies — so that week three is execution, not discovery. The engagement ends with the pod provably unable to touch the system, which is not distrust; it is the last deliverable of the security posture the engagement ran on, bookended with Phase 8's secrets rotation: we never held production secrets, and now we hold nothing at all.

Access that lingers

"We'll clean up the seats next sprint." Months later the pod can still reach production, which is a finding on somebody's audit eventually. Revocation is a dated checklist item confirmed by their security, not a cleanup intention.

The two things that quietly un-do a close

Capability is a paid deliverable — not a parting gift

There are two warm, generous instincts at the end of a good engagement, and both of them quietly cancel the close. The first leaks the standard's value away for free. The second un-transfers everything you just proved, one Slack message at a time.

The idea

The capability was sold, not given. The client's team can now run this loop because a training workstream was priced into the contract from day one. That's why the close gate can be passed at all — it was paid for. If the client wants more help after close, that's a new agreement, made in daylight.

And the close means the close. The reflex to keep answering questions "just for a while" feels kind and slowly un-does the transfer. Future help is a future agreement, not an indefinite off-the-record retainer.

At Harbor Mutual

The engagement also paid the standard back. Four patterns Harbor's project surfaced went home through a single PR against our own repo — client specifics stripped, patterns generalized:

4 patterns harvested from Harbor → into the kit the next engagement starts from

An engagement that ends without a harvest taught the standard nothing. The next pod starts where Harbor finished — which is the whole reason the kit exists.

The quiet retainer

Hypercare reflexes that outlive their window are the most common way a clean close rots. It feels generous, and it un-transfers the engagement one free answer at a time.

Go deeper — the full method

The harvest is the mandatory improvements PR against our own standard and kit, carrying what this engagement taught: generalized skills, corrected templates, patterns worth repeating. Opened in this phase from the Phase 9 retrospective's list, reviewed by the pod, merged by the standard's deputy. This is the compounding asset doing its compounding; an engagement that ends without a harvest taught the standard nothing, and the next pod re-discovers this engagement's lessons at a client's expense. The harvest is a gate item, not a virtue.

The capability the client now holds was priced into the SOW from Phase 0 — the training workstream is why the close gate can be passed at all. If the client cannot name engineers to run the loop, the close gate cannot be passed, and that conversation belongs at steering weeks before this phase. Phase C reveals the transfer's state; it cannot manufacture one.

The quiet retainer

Hypercare reflexes outlive their window and the pod keeps answering questions for free, indefinitely, off the record. It feels generous and it un-transfers the engagement one message at a time. The close means the close; future help is a future agreement made in daylight.

Now watch the whole thing happen

The three weeks, end to end

You've got the ideas; here's the actual rhythm at Harbor. The pod gets deliberately less necessary as the weeks go: hands off the keyboard in week one, out of the room by the gate in week two, out of the building by the end of week three. Step through it.

Week 1 · Mon · the flip begins

Their hands take the wheel

The client's engineers take the driver's seat on real backlog work; the pod drops to Checkers only. The flow check and the intent triage are run by the client now — the queue numbers are theirs to read. In parallel, the harness audit's read-only sweep starts.

Week 1 · mid · three real specs

Coach by question, never by keyboard

At least three real changes ride the loop with the client driving and the pod checking. Every place a Checker wanted to grab the keyboard gets logged — each one a named gap in the transfer. The bar doesn't move: plan, grader, non-author reviewer, merge.

Week 1 · Fri · the audit closes

Findings fixed by the client's owner

The harness audit's findings — anything only the pod understood — get fixed as documented PRs that the client's Setup Owner merges. At Harbor, two findings, both merged by Wes, whose real ownership history starts here.

Week 2 · triage · choosing the gate spec

A real change, with real stakes

The client's triage picks the close-gate change from their own backlog; the Pod Lead confirms it clears the bar — real need, real risk tier, real consequences. At Harbor: decommission the legacy fallback, HIGH risk, with a hard deadline two days out.

Week 2 · the run · the close gate

Solo, end to end, observed and silent

The client runs the whole loop with nobody from the pod driving. The pod observes — present, silent, taking notes. A guardrail blocks the agent; the client engineer escalates correctly, unprompted. Stalls are data; any help from our side voids the run.

Week 2 · own · the owner ships

The client owner's own change

The client's Setup Owner ships at least one harness change of their own — their improvement, their PR, their named deputy reviewing it. The "no role without a deputy" rule transfers along with the keys.

Week 3 · record · the record hands over

Everything, in their tooling

The final handoff report; every phase report from 0 through the close; the outcomes dashboard re-pointed to client ownership with its caveats intact and the quarter-read date on their calendar; the debt log with owners and dates. Delivered into their tooling, not left in ours.

Week 3 · revoke · access goes dark

Provably unable to touch it

Every pod seat, token, permission, role, and key is removed on the checklist and confirmed against the client's audit trail by their security. By end of day, the pod provably cannot reach the system it built. Their security signs the record.

Week 3 · Fri · harvest & goodbye

Send the lessons home, then close

The harvest PR opens against our own standard repo with the engagement's lessons generalized, plus a retro file. The close steering hands the sponsor the record, the gate evidence, and the metric's read — and the last milestone bills. The engagement ends.

1 / 9

Go deeper — the full method

The default calendar is three weeks — long enough for the role flip to be real, short enough that the pod's presence doesn't quietly become a dependency again.

Week one — their hands, our eyes

The shadow flip: the client's engineers take the Orchestrator seat on real specs from their own backlog while the pod serves only as Checkers, coaching by question, never by keyboard. At least three real specs ride the loop this way, the bar unchanged. The pod Checkers log every transfer gap. The harness audit runs in parallel — Claude's read-only sweep plus the Setup Owner's walk — with findings fixed by PRs the client Setup Owner merges.

Week two — the close gate

One real spec, real risk tier, runs the loop end to end with nobody from the pod driving: their triage, their spec, their plan approval, their Checker, their merge, the automatic deploy. The pod observes — present, silent, taking notes. Help voids the run; a wobbly run is re-run on a different real spec. The client Setup Owner ships one harness change of their own this week, with their own named deputy reviewing it.

Week three — the clean exit

The record hands over: the final handoff report; every phase report 0 through 9; the outcomes dashboard re-pointed to client ownership; the debt log with owners and dates — delivered into their tooling. Access revokes on an audited checklist confirmed against the client's audit trail. The harvest PR opens against our standard repo. The close steering gives the sponsor the engagement record, the outcome metric's current read with its caveats, and the formal end of the SOW; the last billing milestone lands with the close gate's evidence attached.

When the three weeks stretch

The close gate fails → name the gap honestly at steering, fix it, re-run on a different real spec — leaving on schedule with an unpassed close gate is abandoning, with paperwork. The backlog has no real specs → that is a triage problem the client's PO now owns; solving it together is transfer work. "One more feature" arrives dressed as closure → a follow-on conversation with its own SOW, not the gate window. The pod becomes the pager again → hold the Phase 9 handover: their watch, the pod one escalation away, an escalation not a reflex.

How it goes wrong

The failure modes, and the defense against each

Every one of these is a way a close quietly fails while looking finished. Knowing them by name is half the defense — and Harbor's structure caught the ones that count.

The trap	What it looks like	The defense	At Harbor
The toy close gate	A no-stakes copy change picked so it can't fail — proving nothing	Real change, real tier, real consequences, or the gate didn't run.	HIGH-risk fallback decommission, dated
The helpful observer	Someone from the pod answers "one little question" mid-run	Help voids the run — same rule as the cold checkout. The question is a finding.	Held — pod silent through the wobble
The indispensable pod member	One head still holds how something really works — found the week after they leave	The audit; "ask the pod" must return zero results before the gate.	Two findings, both documented & fixed
The owner in name only	A client owner named in a deck who never merged anything	Merge history is the test: audit fixes plus one of their own.	Wes merged both fixes + a skill of his own
Access that lingers	"We'll clean up the seats next sprint"	A dated checklist confirmed by their security, not an intention.	Revoked & audit-confirmed, Dan signed
Scope dressed as closure	"Before you go, could you just…"	New work is a new SOW. The Pod Lead holds the line.	Held — follow-on = a new Phase 0
The skipped harvest	The pod rolls off and the lessons-PR never opens	The harvest is a gate item, not a virtue.	Four patterns sent home
The quiet retainer	Free answers continuing indefinitely, off the record	The close means the close; future help is a future agreement.	Clean break — who they call now: their own team

Go deeper — the full method

The indispensable pod member. One person's head still holds how something really works, discovered the week after they leave. The harness audit exists for exactly this; "ask the pod" must return zero results before the gate.
The toy close gate. The solo spec is a copy change with a LOW tier and no stakes, chosen so it cannot fail. It proves nothing, and everyone in the room knows it. Real spec, real tier, real consequences — or the gate did not run.
The helpful observer. Forty minutes into the solo spec, someone from the pod answers one little question. The run is void — same rule as the cold checkout, same reason. The gap the question revealed is the finding; record it, fix it, re-run.
The Setup Owner in name only. A client owner who was named in a deck but never merged anything. Merge history is the test: the audit fixes, plus at least one change of their own, or the harness has no owner — it has a label.
Access that lingers. "We'll clean up the seats next sprint." Months later the pod can still reach production, which is a finding on somebody's audit eventually. Revocation is a dated checklist item confirmed by their security, not a cleanup intention.
Scope dressed as closure. "Before you go, could you just—" at close burns the calendar the gate needs. New work is a new conversation with a new SOW; the Pod Lead holds that line precisely because everyone else in the room has an incentive not to.
The skipped harvest. The pod rolls off to the next engagement and the PR never opens; the standard learns nothing, and the next pod re-discovers this engagement's lessons at a client's expense. The harvest is a gate item, not a virtue.
The quiet retainer. Hypercare reflexes outlive their window and the pod keeps answering questions for free, indefinitely, off the record. It feels generous and it un-transfers the engagement one Slack message at a time. The close means the close; future help is a future agreement.

A finished engagement arrives — and three weeks to prove it can be let go

What Phase C received

Harbor Mutual — a fictional regional insurer — hired a five-person pod to rebuild how property-insurance claims get reported and decided. A claim took a median of 11.4 days from FNOL (first notice of loss) to a coverage decision; the target was 5 days or less. The code was done weeks ago. The system has been live since 7/23, observable, drilled, and retrospected, and Harbor's operators hold the watch. Phase C does not start from a blank page — it starts from a whole engagement's record and a running system, and it exists to prove one sentence: Harbor can run all of this without us.

Inherited from Phase 9 — the record, plus a system already in Harbor's hands close-handoff.md project-retrospective.md the running system — live since 7/23 the harness — Harbor's since Foundation

Four questions, and deliberately nothing else

Everything Phase C does answers exactly four questions. New features are out of scope unless they are the vehicle — the specs run this phase are real work from Harbor's own backlog, chosen because the close gate must run on something that matters.

Can their people run the loop?
Is the harness fully theirs?
Is the record complete and delivered?
Did we leave cleanly — and did the standard learn?

The two arcs to watch

Ines Roy is the one to watch. In July she had never opened the repo and cold-verified the README as a stranger. She closes the engagement by orchestrating a HIGH-risk spec through the loop, solo. And Wes Carter, who co-signed the first ADR back in March, finishes as what the Phase 2 example promised he would become: Harbor's Setup Owner — proven by his merge history, not the org chart.

The entry bar, confirmed at the Step 0 HITL gate

Client engineers named and available to orchestrate real specs — at least three with pod Checkers, then one solo. The Setup Owner named, ready to merge. The training workstream was priced into the SOW back in Phase 0.

Our pod

Maya ChenPod Lead — the transfer is hers

Rob FeldSetup Owner — handing over; walks the audit and the revocation

Jonah Kim & Sara WhitfieldCheckers only this phase, then silent observers

Nadia BrooksQuality Engineer — owns and records the gate evidence

Harbor Mutual

Wes CarterHarbor's Setup Owner as of this phase — merges the audit fixes and one change of his own

Ines RoyEngineer — Orchestrator now; drives the solo close-gate spec

Tom ReillyPlatform engineer — Wes's harness deputy; executes the production deploy

Luis OrtegaProduct owner — triage is his room now

Dan KowalskiIT security — signs the HIGH sign-off and the revocation

Priti ShahData lead — inherits the outcomes dashboard · Karen Voss — sponsor, signs the close

The ID codes, decoded

Every artifact in this engagement carries a stable identifier, so a decision made in month one can still be traced at close. Phase C leans on just two — the sequence has been running since Foundation:

Prefix	Means	Born in	Example here
`NNNN`	A spec — one change in one file, riding the full loop	Foundation on	Build closed at 0044; the close phases continued 0045–0046; this phase adds 0047–0050
`ADR-NNN`	An architecture decision record — a signed choice	Phase 2 on	Complete through ADR-013, none open

The specs are the vehicle for the whole phase: 0047, 0048 and 0050 are the shadow-flip specs; 0049 — decommission the legacy intake fallback — is the solo close-gate spec, HIGH tier, real consequences, due 8/22.

The plugin's eight steps, the standard's three weeks, braided

The procedure, week by week

Close is eight numbered steps in claude-code-sdlc and three working weeks in this standard — the same close seen twice. Unlike the opening phases, this one runs on a calendar of weeks, not days: a week to flip the roles, a week for the gate, a week to leave. Below, they're braided: what the tool runs, the human ritual the tool cannot perform, and the file each week 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

Week 1 — Mon 8/10–Fri 8/14 · plugin Steps 0–2 · their hands, our eyes

Flip the roles: the client drives real specs while the pod only checks

The transfer opens by reversing the roles that built the project. A blocking human gate first: Claude asks whether client engineers are named and available, whether the Setup Owner is ready to merge, and which real backlog items are candidates — nothing begins until a human confirms the transfer is real. Then the shadow flip: Harbor's engineers take the Orchestrator seat on at least three real specs, and the pod serves only as Checkers, coaching by question, never by taking the keyboard. In parallel, a read-only agent sweeps the repo for anything that would strand the client if the pod vanished tonight.

Tooling Step 0 HITL gate → AskUserQuestion /sdlc-status → the flow-check queue, typed by Harbor Agent(Explore) → read-only harness sweep human decision — who orchestrates, which specs are real

Out close-gate-evidence.md — the shadow-flip section harness-audit.md — findings and fixes access-revocation-checklist.md — drafted early, from every grant

At Harbor

Three real specs ride the loop with Harbor Orchestrators and pod Checkers, the bar unchanged: 0047 (adjuster queue saved filters, Ines), 0048 (intake-supervisor daily digest, Ines), 0050 (claims-search timeout messaging, Wes). Jonah and Sara coach only by question and log every place they wanted the keyboard — each one a transfer gap with a name. The audit sweep returns only two findings after a five-month engagement, because Foundation's open-adaptation habit made every harness change a PR Wes had already read.

The pattern to notice, early

The shadow-flip record and the audit findings are human work — no command writes them. But watch where they land: close-gate-evidence.md and harness-audit.md are required artifacts the gate checks for. The plugin makes the human ritual leave a file and refuses to close without it. Hold that thought for Section 03.

Week 2 — Mon 8/17–Fri 8/21 · plugin Step 3 · the close gate

One real change, solo, with the pod silent in the room

The phase's defining test. One real spec — real risk tier, real consequences — runs the loop end to end with nobody from the pod driving: their triage, their spec, their bounds, their plan approval, their Checker, their merge, the automatic deploy. The pod observes the way the Quality Engineer observed the cold runs in Documentation and Deployment: present, silent, taking notes. There is no plugin command from the pod's side — that is the test. A run that needs help is void; the gap the help revealed is the finding, fixed and re-run on a different real spec. This week the client Setup Owner also ships one harness change of their own.

Tooling none from our side — Harbor types everything; the pod is silent risk:high → security.yml → the security-reviewer agent

Out close-gate-evidence.md — the solo observation, names and timestamps harness-audit.md — the owner's own-change evidence the verdict — a human call, PASS or re-run

At Harbor

Spec 0049 — decommission the legacy intake fallback, tier HIGH, due 8/22. On Thursday 8/20 Ines orchestrates; the agent's plan drifts toward editing deploy-dev.yml, a gated path, and the hook blocks the edit. Ines escalates to Wes exactly as the rules prescribe; it ships as its own harness PR. Grader PASS, Wes the non-author Checker, Dan's HIGH sign-off, merged, production on Harbor's go/no-go — the fallback dark two days early. Wes ships an onboarding bootstrap skill of his own; Tom is named his harness deputy. The wobble was the win: the rails caught the drift and a Harbor engineer answered with the right judgment, unprompted.

The one place the plugin already does what this rewrite asks

close-gate-evidence.md is the positive example. Everywhere else a human ritual — a spike, a threat review — happens and leaves no receipt the gate checks. Here the close gate is a pure human ritual, and the plugin requires its receipt: the file is in artifacts.required, and check_gates.py refuses to close until it exists, is non-empty, and carries no placeholder. The ritual leaves a file the gate reads. That is the pattern the whole rewrite argues for.

Week 3 — Mon 8/24–Fri 8/28 · plugin Steps 4–8 · the clean exit

Hand over the record, revoke access, feed the standard, and go

The last week is execution, not discovery. The record hands over into Harbor's own tooling: a script drafts the final handoff report from the engagement's records, an agent fills the narrative slots, and every phase report and the outcomes dashboard move to client ownership. Access revokes on the checklist drafted in week one — every seat, token, and role removed and confirmed against Harbor's audit trail. The harvest PR opens against the firm's own standard repo, and a retro file is written into it. The gate runs, the report renders, and a named human on each side signs the close.

Tooling generate_handoff_report.py → final-handoff-report.md Agent(Explore) → fill the [Fill:…] slots; draft the harvest /sdlc-phase-report → generate_phase_report.py /visual-explainer → .sdlc/reports/close-visual.html /sdlc-gate → check_gates.py

Out final-handoff-report.md close-visual.html close-report.html access-revocation-checklist.md — executed and signed outcomes-dashboard-handover.md harvest PR + retro file — in the standard repo

At Harbor

Every phase report ships; the outcomes dashboard is re-pointed to Priti with the October quarter-read on Harbor's calendar, caveats intact; the debt log sits in Harbor's tracker with Harbor owners. On Wednesday 8/26 Rob and Dan walk the revocation item by item, audit-confirmed, Dan signs — bookended with Phase 8's secrets rotation. The harvest PR opens against MCKRUZ/intent-driven-development with four patterns, and retros/2026-harbor-mutual.md is written. Friday 8/28 the close steering: Karen gets the record and the 4.2-day read; the final milestone bills. The engagement ends.

Where even Close reverts to unchecked human work

The exit gate requires the harvest PR opened and the retro file written — but neither lives in .sdlc/. They land in the standard repo, which check_gates.py never walks, and harvest-pr-notes.md is only optional. The same is true of the outcomes-dashboard handover: required to close, but its artifact is optional, so nothing verifies it. Three of Phase C's exit conditions have no automated eyes on them at all.

1 / 3

Everything the close produces, and who actually writes it

What Phase C produced

The whole output of the close, named. Blue rows are written by a command. Green rows are the point of this page — rituals only a person can perform, which the harness nonetheless requires to leave a file, and which the gate then checks. Nobody's memory is load-bearing. Amber rows are the work that still evaporates when the meeting ends.

Phase C is the only phase in the engagement that does this. Everywhere else, a threat review or a spike or a cold-checkout test happens, matters, and leaves nothing behind. Here, the client's engineer ships one real change alone with the pod silent in the room — and close-gate-evidence.md records that it happened. That is the pattern the other eight phases are missing.

Artifact	What it actually is	Written by	Signed by	Lives at	Feeds
final-handoff-report.md	The engagement record in one place: every phase gate and sign-off, the phase-report index, the metrics history, the debt log, and who Harbor calls now	`generate_handoff_report.py` drafts; Explore agent + Pod Lead enrich	Pod Lead	`.sdlc/artifacts/close/`	Harbor's incoming team
close-report.html	The gate result and artifact inventory, self-contained — the document the sponsor reads before the final sign-off	`generate_phase_report.py` (via `/sdlc-gate`)	—	`.sdlc/reports/`	The close steering
close-visual.html	The transfer scorecard, the audit findings, the revocation tracker and the harvest summary, rendered	`/visual-explainer`	—	`.sdlc/reports/`	The close steering
close-gate-evidence.md	The shadow-flip record (≥3 specs) and the solo close-gate observation: names, timestamps, every stall and guardrail event, the merge that deployed, the verdict	Quality Engineer, by hand	Pod Lead	`.sdlc/artifacts/close/` — required & gate-checked	The close gate itself
harness-audit.md	Every transfer-risk finding, its fix and the client Setup Owner's merge, the owner's own change, and the "ask the pod" zero result	Explore sweeps; Setup Owner walks and writes	client Setup Owner	`.sdlc/artifacts/close/` — required & gate-checked	Harbor's operation of the harness
access-revocation-checklist.md	Every pod credential, its removal date, the audit-trail confirmation, and the production-secret rotation	Setup Owner + client security, by hand	client security	`.sdlc/artifacts/close/` — required & gate-checked	The clean exit
outcomes-dashboard-handover.md	The dashboard re-pointed to client ownership, caveats intact, the quarter-read date on their calendar	QE + client data lead	Client	optional artifact — the gate never checks it	Harbor's own quarterly read
harvest PR + harvest-pr-notes.md	The generalized skills, corrected templates, and repeatable patterns sent home to the standard, client specifics stripped	Explore drafts; the pod opens the PR	the standard's deputy	a PR in another repo — the gate can't see it	The next engagement
retro file (retros/….md)	One file recording what this engagement changed about the standard and why	Pod Lead, by hand	the standard's owner	delivery-standard repo — outside .sdlc/, unchecked	The standard's compounding memory

Read the amber rows again — and notice which kind they are

Six of Phase C's nine outputs are human-authored, not tool-written. Here is the difference that matters, and it is the whole argument of this rewrite: three of them — the close-gate evidence, the harness audit, and the revocation checklist — are required artifacts with a real path that check_gates.py refuses to close without. The plugin makes the human ritual leave a file. That is exactly what Phase 2's spikes and threat models should do and don't. The other three — the dashboard handover, the harvest PR, and the retro file — are the true gap: required to close, but the dashboard artifact is optional and the harvest lands in another repo the gate never walks. Human work is not the problem. Human work without a receipt is — and Close is the one phase that mostly gets this right.

Deliberately not produced in Phase C: a transition-services annex that quietly keeps the pod on retainer — ongoing help is a new agreement made in daylight, with its own Phase 0 — and any "final improvements" to Harbor's code outside the loop. The loop is theirs now, and so is every change.

The engagement's last and most important gate — one exhibit, reproduced whole

The close gate — one real change, solo, with us silent in the room

The close-gate spec was real, with a date attached: 0049 — decommission the legacy intake fallback, due at day 30 of the rollout (8/22). Luis confirmed at triage the fallback triggers had never fired in thirty days of production; the room debated the tier and landed it HIGH — re-standing the legacy intake would take days, and hard-to-undo is the definition. Nobody from the pod was in the discussion. The tier debate itself was the judgment transferring.

The run, Thursday 8/20

Ines orchestrated: plan mode, bounds, the agent built. The wobble the observers were waiting for arrived on schedule — the agent's plan drifted toward editing the deploy workflow YAML to remove the fallback wiring, a gated path.

The hook blocked the edit; Ines stopped, took the workflow change to Wes, and it shipped as its own reviewed harness PR — exactly the escalation the rules prescribe, executed by someone who learned those rules eight weeks earlier. The pod, in the room, said nothing. Stalls are data; help voids the run.

The close-gate evidence (as recorded)

Spec 0049 — close-gate observation, N. Brooks recording

09:05 Triage (Luis, Wes, Ines, Tom): tier set HIGH. 10:20 Plan reviewed by Ines; deploy workflow change identified as OUT of agent scope. 11:35 PreToolUse hook BLOCKED agent edit of deploy-dev.yml; Ines escalated to Wes per gated-path rule; shipped as separate harness PR. 14:10 Build complete; risk:high → security-reviewer pass. 15:25 Grader: PASS. 15:50 Checker: Wes; HIGH sign-off: D. Kowalski. 16:15 Merged. 17:00 Production on Harbor go/no-go (Tom executed). Fallback dark, two days ahead of deadline.

Verdict

Close gate PASSED — real spec, end to end, observed, unassisted. One guardrail event, handled correctly by the client team without prompting. Pod participation: none.

The wobble was the win — and the receipt is required

The gate's best moment was the blocked edit — not because the agent drifted, but because the rails caught it and a Harbor engineer responded with the right judgment, unprompted. A toy spec would have proven nothing; 0049 fired the full HIGH path with zero pod hands. Mechanics transfer in documents; judgment only shows up under observation. And this whole log is not a nicety — it is close-gate-evidence.md, the required artifact the gate reads before it lets the engagement close. The ritual and its receipt are the same object.

Two findings, both merged by Wes — and a merge history that made him the owner

Audit the harness for anything living in our heads

The harness audit ran in parallel with the shadow flip: a read-only sweep plus Rob's walk of every skill and hook, asking one question — could Harbor operate this if the pod vanished tonight? After a five-month engagement the sweep found only two things, because the open-adaptation habit from Foundation made every harness change a reviewed PR Wes could already see. The point of the audit is not the findings; it is who merged them.

#	Finding	Why it would have stranded Harbor	Fix — merged by Wes
1	The grader agent's prompt said "review per MCKRUZ standards" — a reference only the pod could resolve	A future Harbor engineer tuning the grader has no idea what the phrase binds to	Prompt rewritten to state the actual rules inline; PR merged by Wes
2	The stop-gate hook resolved a lint configuration from a path that existed on pod machines but not in the repo	The hook silently weakens the day Harbor runs it on a fresh machine	Configuration pinned into the repo; hook path repo-relative; PR merged by Wes

The test for a real owner: merge history, not the org chart

"Harbor has a Setup Owner" is a claim until it becomes a git log. Wes didn't just merge the two audit fixes — he shipped a harness change of his own: an onboarding bootstrap skill for new Harbor engineers, born from Ines's step-4 stall during the Phase 7 cold README checkout, turning a bad day into a permanent practice. His PR, no plugin command — Wes deciding the harness needed something and shipping it through the same loop everyone uses.

"Ask the pod" must return zero results before the gate. It did.

The both-eyes rule transfers too

Tom Reilly is named Wes's harness deputy — a Harbor engineer who reviews the Setup Owner's own harness changes, the way the pod's deputy reviewed the pod's.

No role without a deputy was the rule that protected the pod from a single point of failure. It survives the pod's departure — the Setup Owner is never the sole approver of the foundation they own, on either side of the handover.

A Setup Owner named in a deck but who never merged anything is a label. Wes is an owner because the git log says so.

Week three — the capability was bought, and the access is provably gone

Capability is a paid deliverable — not a parting gift

The ability Harbor now holds was not a farewell favor tossed in at the end. The training workstream was priced into the SOW back in Phase 0, and the shadow flip and the close gate are that capability being delivered and proven, on the clock, against real work. A close that leaves the client able but the pod still holding keys is only half done — so the same week proves the other half: the pod can no longer touch the system it built.

Capability, bought and delivered

The specs run this phase were real backlog items, not exercises — which is the only reason driving them proved anything. Ines went from a stranger who cold-verified the README in July to the Orchestrator of a HIGH-risk decommission in August. That distance is what the SOW paid for, and the close gate is the receipt.

A follow-on, if Harbor wants one, is a new agreement made in daylight with its own Phase 0 — not a transition-services annex that quietly keeps the pod on retainer.

The clean exit — revoke our access and prove it

On Wednesday 8/26 every pod seat, token, repo permission, environment role, and vault access was walked as a checklist by Rob and Dan, item by item, then confirmed against Harbor's audit trail. By end of day the pod provably could not reach production.

Dan signed the record. It went in the close packet next to the secrets rotation from Phase 8 — the engagement's bookends: we never held production secrets, and now we hold nothing at all.

The checklist wasn't improvised on the last day — Rob drafted it in week one from everything the engagement was ever granted, so week three was execution, not archaeology.

The traps to name out loud

"We'll sort the seats out next sprint" un-revokes the whole thing — revocation is a dated, security-signed, audit-confirmed gate item or it didn't happen. And "before you go, could you just…" burns the calendar the close needs; hypercare reflexes that outlive their window un-transfer the engagement one free answer at a time. Harbor got a clean break: who they call now is their own team.

There is no next phase — only what outlives the pod

What Harbor keeps

Every other phase ends by handing the next one a package. Close ends differently: there is no next phase and no handoff out. What crosses the boundary here is not a handoff — it is everything that stays, now that the people who built it are gone. The test of the whole engagement is that this list runs without them.

Stays with Harbor — the operating system, not the operators the harness (CLAUDE.md, .claude/, the agents & skills) specs/0001…0050 adr-registry.md — ADR-001…013 RUNBOOK.md the outcomes dashboard + metrics history the running system & its drilled alerts final-handoff-report.md

The decision history is the part that compounds

The harness is the operating system — it was Harbor's since Foundation, and it ran the project, not the people leaving. But the piece that quietly matters most is adr-registry.md: every architectural choice from March onward, ADR-001 through ADR-013, with the rejected options and their reasons still attached. When a Harbor engineer asks in month nine "why does coverage read a nightly replica?", the answer is a signed record with Wes's own name on it, not a Slack search that comes up empty.

The specs, the RUNBOOK, the risk-tier map, the cadence calendar — the whole factory, and the loop that runs it, are Harbor's now. So is the debt log, in Harbor's tracker with Harbor owners and dates.

What we keep — the harvest loop

The engagement paid the standard back too. Four generalized patterns went home through a single PR against the firm's own repo, client specifics stripped, merged by the standard's deputy:

kit/workflows + RUNBOOK template: configuration versioned with the release artifact — rollback restores both (from spec 0046).
kit/skills/test-writer: timezone-boundary cases for every suite touching a date the business reads.
kit/templates — alert definitions: the suppression-window-plus-recovery-check pattern for designed downtime.
kit/templates — alert definitions: the vendor-blip severity split — warning on burst, critical on sustained.
retros/2026-harbor-mutual.md: one file recording what this engagement changed about the standard and why.

The next pod starts where Harbor finished. The harvest is a gate item, not a virtue — an engagement that ends without it taught the standard nothing.

The close steering, Friday 8/28 — the last number, with its caveat intact

11.4 → 4.2 days from FNOL to coverage decision in March → the completed-claims median in August (under the 5-day target)

Karen got the engagement record, the close-gate evidence, and the metric's read — stated with the cohort caveat in writing. Completed claims skew fast; the unbiased read is October's, on a dashboard Harbor owns, watched by alerts Harbor drilled, fed by a system Harbor ships changes to through a loop Harbor runs. The SOW closed; the final milestone billed with the gate evidence attached. Who Harbor calls now: their own team. The engagement ends the way it ran — underclaimed and verifiable.

All names, numbers, and documents are invented but internally consistent. That last sentence — a system Harbor ships changes to, through a loop Harbor runs, watched by alerts Harbor drilled, read on a dashboard Harbor owns — is the deliverable. Everything else this page described was in service of making it true.

You've been handed an engagement that's nearly over and told to run Phase C. This page is what you actually type, in order, and what you do between the typing.

Phase C takes about three weeks. Almost none of it is typing. The phase does not close because a date arrived — it closes when the client's own team has run one real piece of work end to end through the loop, unaided, while you watched. Read this once end to end before you start; two of the steps have to begin in week one or the whole calendar slips.

Before you type anything

What you need first

Four things, and three of them are people or decisions someone else has to make. If any of the first two are missing, stop — that is a steering conversation, not a scheduling one.

Named client engineers who will drive. At least three of them, available to orchestrate real specs while you only check — and then one who runs a spec solo. Without them the close gate cannot be passed at all. This is the training workstream that was priced into the SOW back in Phase 0; if nobody was ever named, Phase C reveals that, it cannot fix it.
A named client Setup Owner. The client engineer who owns the harness after you leave. They must be named before this phase starts, and by the end they must have merged harness changes themselves.
Real backlog items to run the loop on. Ordinary work the client genuinely needs, mixed risk tiers, each small enough to merge inside the window. Not exercises invented for the occasion.
The prior phase actually closed. Phase 9's exit gate passed and close-handoff.md reviewed. Check with /sdlc-status — the project should read Phase C (slug close), active.

The mistake new people make

Treating Phase C as paperwork — write the report, revoke the seats, go home. The paperwork is the easy part and none of it is the gate. The gate is a person on the client's team shipping something real without you. Everything else on this page exists to support that one event.

Type this — first thing, before you schedule anything

Open the phase and confirm the transfer is real

You type /sdlc

What happens: Claude reads close-handoff.md and the Phase 9 retrospective, shows you the Phase C guidance, then stops at a blocking gate and asks you four questions in a picker: are client engineers named and available to orchestrate real specs; is the client Setup Owner named and ready to merge harness changes themselves; which real backlog items are the candidates for the shadow-flip specs and the close-gate spec; and what pod access exists to revoke — seats, tokens, repo permissions, environment roles, vault policies. Nothing else in the phase starts until you answer.

What you do: answer honestly, including when the answer is no. If the client cannot name engineers to run the loop, say so here rather than discovering it in week two. A "no" at this gate is a steering conversation with the sponsor about the transfer — it is not a reason to keep going and hope.

Don't move on until: you have real names against the first two questions and a shortlist of real backlog items against the third. The fourth answer becomes step 02's input, so write it down properly — that list is the seed of the revocation checklist.

Nothing to type — and it has to start in week one

Draft the access-revocation checklist

You type no command drafts this — you write it, by hand, from records

What you do: build access-revocation-checklist.md now, three weeks before you'll execute it. Walk every source of access the engagement was ever granted: the Phase 0/1 access checklist, CI secrets, environment roles, vault policies, repo permissions, seats. One row per credential.

Why so early: if you start this in week three it becomes a discovery exercise, and discovery is exactly what you don't have time for on the way out the door. Drafted in week one, week three is execution — tick, confirm, tick, confirm.

You now have access-revocation-checklist.md — a draft; nothing generates it

Also note which production secrets the pod ever touched. Those don't get removed, they get rotated into values the pod cannot read — a separate job in step 07.

Week one — they type, you don't

The shadow flip: at least three real specs

They type /sdlc-spec and you type nothing at all

What happens: the roles that opened Build reverse. The client's engineers take the Orchestrator seat on real specs from their own backlog — triage with their Product Owner, writing the spec, setting the bounds, approving the plan, driving the agent — and the pod serves only as Checkers. The bar does not move: the grader runs, a non-author approves, merge deploys. /sdlc-spec is the same command they'd use on any other change; it scaffolds the spec, proposes a risk tier for a human to confirm, and enforces the Definition of Ready before the work can be delegated.

What you do: check, and coach by question only — "what does the spec say about that path?" — never by taking the keyboard. And log every single moment you wanted to grab it. Each one of those is a transfer gap with a name, and the log is the actual output of this week. Roll it up per spec: who orchestrated, who checked, the grader and Checker outcomes, and the gaps.

You now have close-gate-evidence.md — the shadow-flip section; you write it

Three is a hard floor, and "real" is a hard word

Three real specs is an exit condition, not a target to negotiate down. And a spec built for the occasion doesn't count — it has to be work the client actually needs, with a real risk tier and real consequences. Confirm each one clears that bar before it runs, not after.

Week one, in parallel — you ask Claude, in plain English

Audit the harness for anything only you understand

You type no slash command runs this — you ask Claude for a read-only sweep

What happens: you ask Claude to run a read-only audit of the harness for transfer risk — sweeping CLAUDE.md, .claude/ (skills, agents, hooks, settings) and specs/ for three things: skills or hooks that assume paths, permissions or tools only the pod ever had; conventions the repo refers to but never documents; and knowledge that lives in someone's head instead of in the repo. It lists each finding with its location and why it would strand the client. The phase definition carries the exact wording of that request — copy it rather than improvising.

What you do: the sweep only surfaces candidates. The Setup Owner then walks every skill, hook and convention by hand against one question: could their team operate this if we vanished tonight? Then — and this is the part people skip — every finding becomes a documented fix that the client's Setup Owner merges. Not you. Their merge, in their history.

On top of the fixes, the client Setup Owner ships at least one harness change of their own this phase: their idea, their PR, reviewed by a named deputy on their side. Merge history is the test.

You now have harness-audit.md — findings, fixes, and who merged them

"Ask the pod" must return zero results

The failure this step exists to catch is the indispensable pod member — one person's head still holds how something really works, and everyone finds out the week after they leave. A Setup Owner who was named in a deck but never merged anything is a label, not an owner, and the audit will not catch that for you. Check the merge log.

Week two — nothing to type, and that is the entire point

The close gate: one real spec, solo, observed

You type nothing — if anyone from the pod touches a key, the run is void

One real spec — something the client genuinely needs, at a real risk tier — runs the loop end to end with nobody from the pod driving. Their triage, their spec, their bounds, their plan approval, their Checker, their merge, the automatic deploy.

What you do: sit there and take notes. Present, silent, writing. Record each loop step with a timestamp and a name, every stall, every guardrail event and how the team responded, and the merge and deploy that closed it. Then write the verdict.

Stalls are data. Help voids the run. If someone on their side gets stuck for twenty minutes and works it out, that is a pass with a note. If someone on your side answers one small question forty minutes in, the run is over — not as punishment, but because the thing you were measuring stopped being measurable.

A failed run is information, not embarrassment

Name the gap, fix it — more reps, a harness clarification, a missing line in a playbook — and re-run on a different real spec. "They got through it with a little help" is a fail. Record the voided run, the gap it revealed, the fix, and the spec you re-ran on; that record is part of the evidence, not something to bury.

You now have close-gate-evidence.md — the observation record; you write it

Week three — run a script, then do the thinking it can't

Hand over the record

You type generate_handoff_report.py → final-handoff-report.md

What happens: the script drafts final-handoff-report.md straight from the engagement's own records — the index of every phase report, the per-phase gate-and-sign-off table pulled from state.yaml, the metrics history, and the spec backlog. It fills everything that is data and marks everything that isn't with a [Fill: ...] slot. It writes to .sdlc/artifacts/close/ and refuses to overwrite a report a human has already edited unless you pass --force.

What you do: fill the marked slots, because they are exactly the parts no script can produce — how the outcomes landed against the problem statement written in Phase 0 and with what caveats, the debt log with an owner and a date on every line, the open items, and who the client calls now (their own team). Ask Claude for a read-only sweep of the engagement record to draft those slots; then read every line as the sponsor will.

Two more things hand over alongside it: every phase report from 0 through 9, and the outcomes dashboard — re-pointed to client ownership with its caveats intact, and the quarter-read date (the day the outcome metric gets its first full-period reading) on the client's calendar. Record that handover in outcomes-dashboard-handover.md.

This script isn't behind a slash command

Unlike the gate checks, nothing wraps generate_handoff_report.py in a /sdlc-* command — you invoke it yourself through uv, the way the plugin runs all its Python. Ask Claude to run it if you're unsure of the exact invocation for your install; the plugin's own path variable resolves it. Delivered means delivered into the client's tooling, not left in a folder on your laptop.

You now have final-handoff-report.md — drafted by script, finished by you outcomes-dashboard-handover.md — optional artifact, you write it

Week three — nothing to type, execute the checklist

Revoke every credential, audited

Every pod seat, token, repo permission, environment role and vault access — removed on the checklist you drafted in step 02, then confirmed against the client's own audit trail by their security.

What you do: walk it item by item with the client's operations or platform person and their security. Mark each one removed, with a date. Then go back through and mark each one confirmed. Separately, rotate any production secret the pod ever touched into a production-only value the pod cannot read, and get that signed by client security.

"Removed" and "confirmed" are two different columns

A checklist where everything says removed and nothing says confirmed is an intention, not a revocation. The engagement is supposed to end with the pod provably unable to touch the system — that's not distrust, it's the last deliverable of the security posture the whole engagement ran on. "We'll clean up the seats next sprint" is how pods still have production access a year later.

You now have access-revocation-checklist.md — every row removed and confirmed

Week three — the step that pays for the next engagement

Open the harvest PR back to the standard

You type no command — you ask Claude to draft it, then you open the PR yourself

What happens: you ask Claude to read the Phase 9 retrospective and this engagement's harness changes, and draft the improvements the engagement earned — generalized skills, corrected templates, patterns worth repeating — with every client-specific name, number and domain detail stripped out. Each candidate comes with the evidence behind it and the file in the standard it would touch.

What you do: open that as a pull request against the firm's own delivery-standard repo. The pod reviews it; the standard's deputy merges it. Then write one file into that repo's retros/ folder: what this engagement changed about the standard, and why. Record the whole thing locally in harvest-pr-notes.md.

Why it's mandatory: this is the compounding asset compounding. An engagement that ends without a harvest taught the standard nothing, and the next pod re-discovers these lessons at a client's expense. It is a gate item, not a virtue.

Nothing can verify this for you

The harvest PR lands in a different repository, so the gate cannot see it and never will. The gate asks about it, and harvest-pr-notes.md is the only local receipt — a receipt you wrote. The same is true of the retro file. If you're the last person touching this engagement, you are the only check on whether the harvest happened.

You now have harvest-pr-notes.md — optional artifact, and the only local trace a retro file in the standard's repo — outside this project entirely

Type this — the machine checks your work, up to a point

Build the reports and run the gate

You type /sdlc-gate → check_gates.py

What happens: seven gates run against Phase C and an HTML report opens in your browser at .sdlc/reports/close-report.html. The blocking part checks that the four required artifacts — final-handoff-report.md, harness-audit.md, close-gate-evidence.md and access-revocation-checklist.md — exist, have real content, and are structurally sound. The rest of the phase's exit conditions are rendered as prose checks for the human who signs: they always come back as REVIEW and they never block.

What you do: fix whatever it flags and run it again until it's clean. Then share the HTML report at the close steering — it is the review artifact the final sign-off is made against, and the last billing milestone lands with it.

Before the steering, the phase also asks for an interactive visual report at .sdlc/reports/close-visual.html — the transfer scorecard, the audit findings and their merges, the revocation tracker, and the harvest summary. That's the /visual-explainer skill, not an /sdlc command. If it isn't available in your install, generate equivalent HTML and say so.

What the gate does NOT check — read this twice

A green gate on Phase C is a check on four markdown files. It cannot verify the one thing this phase is about. No automated check can tell whether a client team really ran a real spec unaided, whether the spec was real or a toy, whether anyone from the pod quietly helped, whether the client Setup Owner actually merged anything, whether a credential was truly confirmed against their audit trail, or whether the harvest PR was ever opened — two of those live in repositories and systems this gate cannot see at all. The standard's exit criteria are strictly larger than anything the plugin can enforce. Walk them yourself.

Type this — the last command of the engagement

Sign the close

You type /sdlc-next

Before you type it: run the close steering with the sponsor. The engagement record, the outcome metric's current read with its caveats intact, the close-gate evidence, the formal end of the SOW, and the answer to the only question left — who they call now (their own team), and what a future engagement would look like (a new Phase 0, in daylight, with its own SOW).

What happens: it re-runs the gates, then stops and asks you to confirm. Phase C is the terminal phase — there is no next phase to advance into and no handoff out. When it passes, the project is complete and the command tells you where future work would re-enter.

What you do: get a named human on each side to sign. Gates report, humans decide — one last time. Then stop answering questions. Hypercare reflexes that outlive their window un-transfer the engagement one message at a time; if the client wants ongoing help, that is a new agreement, not a habit.

The engagement is done when the client team ran one real spec end to end, unassisted the harness has a client owner with merges to prove it access is revoked and confirmed against their audit trail the harvest PR is open against the standard a named human on each side has signed

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 in this phase.
`/sdlc-coach`	You want to be walked through it conversationally. For Phase C it asks the questions that matter: how many real specs have their engineers orchestrated, where did you want to grab the keyboard, is the close-gate spec a real one.
`/sdlc-gate`	Before the close steering, and again after every fix, until it's clean.
`/sdlc-phase-report`	Regenerate the HTML report at any time — for the steering deck, or after you've edited an artifact.

Rule of thumb for the whole phase: the less you type, the better it's going. Phase C is the one phase where your hands on the keyboard is the failure signal. If you find yourself driving, stop — that's the finding, and it belongs in the record.

Reference · Phase C · Close & Transfer

The precise mechanics — the exact roles, the three-week calendar, the artifacts, and the close gate, including the 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 C answers four questions, and nothing else. New features are out of scope unless they are the vehicle — the specs run this phase are real work from the client's own backlog, chosen because the close gate must be run on something that matters.

Can their people run the loop? (their engineers orchestrate real specs with our Checkers first; then one real spec end-to-end with nobody from the pod driving)
Is the harness fully theirs? (the audit finds nothing undocumented; the client Setup Owner is named and has merged harness changes themselves)
Is the record complete and delivered? (every phase report, the outcomes dashboard, the debt log — handed over, in their hands, in their tooling)
Did we leave cleanly — and did the standard learn? (access revoked and audited; the harvest PR opened against our own repo before the lessons evaporate)

The human / AI contract for this phase

Human drives	Claude does	Mandatory human stops
The client's engineers orchestrate real specs, then the close-gate spec solo. The Pod Lead runs the transfer; the client Setup Owner merges every harness fix.	Audits the harness read-only; drafts the final handoff report from the engagement's records; drafts the harvest PR against our standard. Keeps working for the client — same agent, same harness, now driven by the client.	Claude never drives the close-gate spec, never serves as the gate evidence, never writes the retrospective's candor. The close-gate run, the access revocation, and the goodbye are no plugin command.

Who is involved

Our side

Person	Load	Workstream
Pod Lead	60–80%	Runs the transfer — the shadow-flip schedule, the close-gate observation, the final steering, the clean exit. Holds the line against scope dressed as closure.
Orchestrators	40–60%	Become Checkers only — review the client engineers' specs, coach by question rather than by keyboard, then stop
Setup Owner	30–50%	Runs the harness audit with Claude, fixes findings by documented PR that the client Setup Owner merges, hands over the last keys
Quality Engineer	20–40%	Verifies the transfer by observation; owns the close-gate evidence and the final outcomes-dashboard handover

Client side

Person	Needed for	How much
Their engineers	Orchestrating real specs — at least three with our Checkers, then the close-gate spec solo	The thread of the phase
Client Setup Owner	Named before the phase; merges the audit-finding PRs and at least one harness change of their own	Steady hours
Product Owner	Their own intent triage — the decision clock and the vague-line test are theirs now	Their normal cadence
Operations / platform	Confirm the access revocation against their audit trail; receive the last operational keys	2–3 hours
Sponsor	The close steering — the engagement record, the outcome read, the formal end	1 hour

If the client cannot name engineers to run the loop, the close gate cannot be passed — and that conversation belongs at steering weeks before this phase. The training workstream was priced into the SOW from Phase 0; Phase C reveals the transfer's state, it cannot manufacture one.

The three-week calendar

Week	Theme	What happens
One	Their hands, our eyes	The shadow flip — client engineers orchestrate at least three real specs with the pod as Checkers, coaching by question and logging every transfer gap. The harness audit runs in parallel; findings fixed by PRs the client Setup Owner merges.
Two	The close gate	One real spec, real risk tier, runs the loop end to end with nobody from the pod driving — observed, silent, recorded. Help voids the run; a wobbly run is re-run on a different real spec. The client Setup Owner ships one harness change of their own.
Three	The clean exit	The record hands over into client tooling; access revokes on an audited checklist; the harvest PR opens against our standard repo; the close steering ends the SOW and bills the final milestone with the gate evidence attached.

Three weeks is long enough for the role flip to be real, short enough that the pod's presence doesn't quietly become a dependency again. If the close gate fails, that is the most important stretch: name the gap, fix it, re-run on a different real spec. Leaving on schedule with an unpassed close gate is not closing — it is abandoning, with paperwork.

The artifacts

Artifact	Drafted by	Owned by	Done means
Shadow-flip spec record	Quality Engineer	Pod Lead	At least three real specs orchestrated by client engineers with pod Checkers — the bar unchanged
Harness audit + fixes	Claude (sweep), Setup Owner (walk)	Client Setup Owner	Nothing only-we-understand remains; every finding fixed by a documented PR the client Setup Owner merged
Close-gate evidence	Quality Engineer (observation record)	Pod Lead	One real spec, end to end, client-driven, observed and unassisted — names, timestamps, and the merge that deployed
Final handoff report	Claude (drafts)	Pod Lead	The engagement record in one place: gates, reports, metrics history, debt log, open items with owners
Outcomes dashboard handover	Quality Engineer + client data lead	Client	Re-pointed to client ownership, caveats intact, the quarter-read date on their calendar
Access revocation record	Setup Owner + client security	Client security	Every pod credential removed, confirmed against the client's audit trail
The harvest PR	Claude (drafts), pod (reviews)	Our standard's owner	Opened against our repo with client specifics stripped; merged by the standard's deputy
The retro file	Pod Lead	Our standard's owner	One file in our repo's retros/: what this engagement changed about the standard and why

Deliberately not produced: a transition-services annex that quietly keeps the pod on retainer (ongoing help is a new agreement made in daylight), and any "final improvements" to the client's code outside the loop — the loop is theirs now, and so is every change.

The cadences

Rhythm	Who	What
Their daily flow check	Client team, pod observing	Run by the client from week one — the queue numbers are theirs to read now
Their intent triage	Client PO + their engineers	The vague-line test and the decision clock, client-run; the pod watches the bar hold
The close-gate observation	Client team driving, QE observing	Week two's defining event — present, silent, recorded
The exit checklist walk	Setup Owner + client security	Week three: access, keys, seats, audit trail — item by item
The close steering	Sponsor + Pod Lead	The formal end: the record, the read, the gate evidence, the goodbye

The close gate

The engagement closes when all of these are true, verified at the close steering:

The harness audit ran and found nothing undocumented — no skill or hook only we understand; every finding fixed by a PR the client Setup Owner merged
The client Setup Owner is named and has merged harness changes themselves — including at least one of their own
Client engineers completed at least three real specs as Orchestrators with pod Checkers — the bar unchanged
The close gate: the client team ran one real spec end-to-end — triage, spec, delegate, grade, merge, deploy — without us driving. Observed, unassisted; a run that needed help was re-run on a different real spec (billing teeth)
Every phase report is delivered and the outcomes dashboard handed over, caveats intact, with the quarter-read date on the client's calendar
The debt log is in the client's hands with owners and dates
Our access is revoked — every seat, token, and permission — and confirmed against the client's audit trail (billing teeth)
The harvest PR is opened against our standard repo, and the retro file is written
A named human on each side signed the close — gates report, humans decide, one last time

The close-gate run and the access revocation are the two items with the most weight. A toy spec instead of a real one, or "we'll clean the seats up later," is how a close looks finished while failing. Real spec, real tier, real consequences — and a dated, audit-confirmed revocation — or it didn't happen.

What goes wrong

The indispensable pod member. One person's head still holds how something really works, discovered the week after they leave. The audit exists for this; "ask the pod" must return zero results before the gate.
The toy close gate. A copy change with a LOW tier and no stakes, chosen so it cannot fail. It proves nothing. Real spec, real tier, real consequences — or the gate did not run.
The helpful observer. Someone from the pod answers one little question mid-run. The run is void — same rule as the cold checkout. The gap the question revealed is the finding; record it, fix it, re-run.
The Setup Owner in name only. A client owner named in a deck who never merged anything. Merge history is the test: the audit fixes, plus at least one change of their own.
Access that lingers. "We'll clean up the seats next sprint." Revocation is a dated checklist item confirmed by their security, not a cleanup intention.
Scope dressed as closure. "Before you go, could you just—" burns the calendar the gate needs. New work is a new conversation with a new SOW.
The skipped harvest. The pod rolls off and the PR never opens; the standard learns nothing, and the next pod re-discovers this engagement's lessons at a client's expense. The harvest is a gate item, not a virtue.
The quiet retainer. Hypercare reflexes outlive their window and the pod keeps answering questions for free, indefinitely. It feels generous and it un-transfers the engagement one message at a time.