Phase-close prompt

Paste when a phase has met its acceptance gates and is ready to close. This prompt enforces MR-2 (friction → next phase, never retrofit) and MR-10 (verification round mandatory) mechanically. The reviewer subagent owns this turn.

---

Prompt to paste

You are closing Phase <> of this project. You are operating as the reviewer subagent (see AGENTS.xml). The auditor has already certified the acceptance checks; your job is to verify, run the verification round, classify friction, and write the phase-close decision doc.

If the auditor has not certified yet, stop — this prompt is premature.

Step 1 — Verify acceptance evidence

For each acceptance gate in MILESTONES.md § Phase <>:

1. Locate the auditor’s evidence doc(s) in docs/roles/auditor/outputs/.
2. Verify the evidence concretely supports the gate. Vague evidence (“looks good”, “seemed to work”) is a block.
3. Cross-reference against the implementer’s session logs to check the work claimed was the work performed.
4. Verdict per gate: pass, block, or advisory.

If any gate is block, stop. Route back to the implementer with the specific blocking evidence. Do not proceed to verification round.

Step 2 — Run the verification round

Now invoke prompts/03-verification-round.md inline (do not start a new session). Read it as your next instructions, perform the round, then return here.

The verification round produces a list of surfaced friction items with three categorisations:

• closed — fixed within this phase. Allowed only for trivial follow-ups (typos, broken links, single-line bugs caught during review). Anything substantive cannot be closed; defer it.
• in-budget — acceptable carry. Documented and explicitly accepted. Each in-budget item needs a sentence justifying why this is acceptable carry, not a bug.
• deferred to phase <<N+1>> — assigned a milestone ID M<<N+1>>.x.y in this same commit. The deferred items become MILESTONES.md entries before the phase-close doc is written.

If a friction item resists categorisation — you can’t decide if it’s in-budget or deferred — default to deferred. In-budget is a higher bar; if you’re unsure, the conservative move is to give it a milestone ID.

Step 3 — Classify and update MILESTONES.md

Update MILESTONES.md in this exact order:

1. Add deferred items as M<<N+1>>.x.y entries under Phase <<N+1>>‘s subphases. Use nested numbering (.1, .2) under existing subphases when the friction logically belongs there; create new subphases when it doesn’t fit.
2. Set Phase <> status to closed with today’s ISO date.
3. Update the Active phase pointer to Phase <<N+1>> (status will become next).
4. If any acceptance gate’s wording surfaced as ambiguous during review, propose a clarification in MILESTONES.md and flag it to me. Do not silently rewrite gates.

Step 4 — Write the phase-close decision doc

Create docs/decisions/<<TODAY_ISO>>-phase-<<N>>-close.md with this structure:

# Phase <<N>> — <<TITLE>> — closed

**Date:** <<TODAY_ISO>>
**Predecessor:** `docs/decisions/<<DATE>>-phase-<<N>>-open.md`
**Status:** closed
**Successor:** Phase <<N+1>> (status: next)

## Acceptance gate verdicts
| Gate | Verdict | Evidence |
| ---- | ------- | -------- |
| <<gate text>> | pass | <<auditor doc path>> |

## Invariants
| Invariant | Status | Note |
| --------- | ------ | ---- |
| I-1 | holds | <<evidence>> |
| I-2 | holds | <<evidence>> |
| <<new in this phase: I-N>> | introduced | <<spec citation>> |

## Friction budget (verification round)

### Closed within phase (trivial only)
- ...

### In-budget (accepted carry)
- <<item>> — <<justification>>

### Deferred to phase <<N+1>>
| Item | Milestone ID | Why deferred |
| ---- | ------------ | ------------ |
| ...  | M<<N+1>>.x.y | ... |

## Anti-shape audit
For each drift watch in north-star:
- <<ANTISHAPE_1>> — observed pulls during phase: <<count or "none">>; <<note>>
- <<ANTISHAPE_2>> — ...

## Handoff to phase <<N+1>>
- Artefacts phase <<N+1>> needs to read: <<list>>
- Subagent roster updates: <<additions, modifications, deprecations>>
- Open questions raised this phase, not yet answered: <<list>>
- Recommended phase-open trigger: paste `prompts/01-phase-open.md` with N=<<N+1>>.

## Sign-off
- Auditor: <<file path of certifying evidence>>
- Reviewer: <agent run>
- Human: <name + date when confirmed>

Step 5 — Self-audit

Before declaring done:

• Every deferred friction item has a milestone ID and appears in MILESTONES.md.
• No acceptance gate verdict is block (those route to implementer; you wouldn’t be here).
• The decision doc cites every auditor evidence file.
• MILESTONES.md status is closed for Phase <>, next for Phase <<N+1>>.
• No content from a closed phase’s MILESTONES.md entry was edited in a way that would break MR-7 (decision docs append-only). The MILESTONES.md entry can be updated; the decision docs cannot.

Step 6 — Hand off

End your turn with:

• Path to the phase-close decision doc.
• Count of: in-budget items, deferred items.
• The next milestone (M<<N+1>>.1) and which subagent owns it.
• Recommended next action: usually paste prompts/01-phase-open.md with N=<<N+1>>.

If the deferred-items count is >3, surface a warning: “Phase <> deferred a lot. Consider re-reading the phase scope before opening <<N+1>>.” This is the precursor to north-star realignment.

---

Notes for the human

• The single most common temptation at phase close is to “just fix this one thing real quick” before declaring closed. Don’t. That’s MR-2 violation. Defer it. The cost of carrying a tiny fix to the next phase is much lower than the cost of letting phases bleed into each other.
• The deferred-count warning at Step 6 is a leading indicator. Two phases in a row with >3 deferred items means the phase decomposition is wrong; consider re-running bootstrap-style calibration on the upcoming phases.
• The reviewer can refuse to close. If it does, read its refusal carefully — it’s almost always pointing at a real architectural issue, not bureaucracy.