Capstone Defense Handoff — Claude Code Guide

Capstone handoff for the defense

A handoff should reduce the reviewer's time to the first useful decision: what to show, where the evidence is, the claim boundaries, and which question must be decided next. It is not promotional copy and does not replace an actual evidence record.

Start with the narrative core flow, then provide the exact entry point, acceptance, known limitations, open questions, and the recommended next decision. Mark every unverified result as Unknown instead of filling it with plausible numbers.

Reviewer handoff structure

• Context: the problem, primary user, and bounded capstone outcome.
• Demo path: a short sequence of actions and expected signals.
• Evidence map: links to the diff, checks, notes, and documented examples.
• Limitations: what was not checked, is not supported, or is not a production claim.
• Decision request: GO, HOLD, feedback, or the next bounded slice.
• Owner and next step: who makes the decision and where work continues.

Defense handoff example

# CAPSTONE_DEFENSE_HANDOFF.md
Problem: <bounded user problem>
Demo path: <three to five observable steps>
Evidence: <links or file anchors>
Known limits: <unsupported cases and Unknowns>
Claims excluded: production deployment, user validation, scale
Decision requested: GO / HOLD / feedback on next slice
Next owner: <role>; next step: <bounded action>
Status: documented example; defense outcome: Unknown.