acceptance-review
Acceptance Review
Treat the authoritative requirement as an acceptance contract and the implementation as its proof. Run the review read-only. When fixes are also requested, finish the verdict before handing its gaps to an implementation workflow.
1. Build the contract
Resolve the subject, comparison base, authoritative issue, specification, or decision contract, repository rules, linked decisions, and stated exclusions. When authority begins in a meeting or transcript, when the claimed decision is disputed, or when two policies conflict and neither is marked superseded, invoke product-management:decision-trace first and consume its acceptance handoff rather than reinterpreting the raw source here.
Map every in-scope normative statement to one independently decidable criterion. Preserve its source identifier and meaning; split combined statements only when their outcomes can differ. Record each criterion's observable outcome, affected surfaces, edge cases, assumptions, and exclusions. Represent each missing or conflicting authority question as one ambiguity criterion; defer only criteria that depend on it and continue judging criteria with settled authority.
Never select one of two competing unresolved policies as the authority, and never report a status that holds under only one of them. Test the criterion against every candidate policy. When the candidates produce different statuses, mark the criterion unverified and request the lineage or supersession evidence that would select the authority. When every candidate produces the same status, record the conflict and report that status. When no decision-lineage handoff is available, still test every candidate this way, and name the lineage or supersession evidence that would resolve the conflict.
When no authoritative issue, specification, or decision record is supplied, stop and request one. Never build the contract from the diff, the pull request description, or the review request itself. Say that no acceptance decision is possible without an authoritative requirement, and route a request about general code quality to a general code review.
Complete when: the authoritative contract and implementation subject are explicit, every in-scope normative statement maps exactly once, and every ambiguity and exclusion is recorded.
2. Trace the proof
For each criterion, trace the real production path from entry point through state, boundaries, errors, and observable outcome. Search every caller, implementation, and sibling surface that shares the behavior. Use base comparison to establish regression.