Product Capability

Activate when approved product intent exists but engineering still needs an explicit
capability boundary. Do not activate for product discovery without an approved decision,
implementation detail already owned by architecture, or a wording-only request.

Preflight

Read the smallest authoritative set that establishes the actor, visible promise,
authorization boundary, business rules, data ownership, lifecycle, rollout or migration
constraints, non-goals, current consumers, and existing architecture. Classify each
statement as approved product truth, observed implementation, engineering preference, or
unresolved question.

Missing product truth stops the handoff before a capability artifact or implementation
effect. Never promote an inference, default, adjacent feature, or possible future
consumer into approved scope.

Single contract

Publish the result at the project's declared product-context owner; do not invent a path
or parallel planning stack. Include only:

• capability: actor, surface, and material outcome;
• constraints: fixed rules, invariants, trust and ownership boundaries;
• implementation contract: inputs, outputs, states, transitions, and policy implications
  justified by current evidence;
• non-goals: explicitly excluded behavior;
• open questions: exact owner decisions that block implementation;
• handoff: ready for implementation, architecture review, or product decision.

The contract owns product intent, not schemas, service design, or delivery steps.
Reference those owners instead of copying them. A handoff is implementation-ready only
when every required product decision is resolved; otherwise return the first blocking
question without fallback scope or fabricated policy.