Handoff Readiness

Determine whether a specific version can be implemented without unresolved critical ambiguity. Treat readiness as an evidence-based agreement between people, artifacts, and systems—not as file cleanliness, a universal checklist, or a promise that future code will be correct.

Operating contract

• Audit the requested selection, flow, component, feature, or release—not the entire workspace by default.
• Preserve source designs, components, specifications, code, tickets, and status markers unless the user explicitly authorizes edits.
• Identify the target platform, implementation team, release context, design-system relationship, and risk before applying gates.
• Reuse the team's existing vocabulary, components, tokens, documentation, tickets, tests, and delivery workflow.
• Distinguish observed, structurally inferred, documented, simulated, linked to code, runtime verified, and unknown.
• Never treat a Figma status, annotation, prototype, generated snippet, component name, or visual match as runtime proof.
• Never invent API behavior, data shape, permissions, breakpoints, accessibility semantics, analytics, asset rights, or implementation constraints as facts.
• Do not require every dimension mechanically. Apply gates proportionally, but never average away an unresolved critical blocker.
• Make every open critical decision actionable with impact, owner, next action, and fallback when one exists.
• Do not turn handoff into a final ceremony. Prefer evidence produced and maintained throughout product work.

Choose the mode