acceptance-review

name	acceptance-review
description	WHEN deciding whether a PR, branch, diff, or current code fulfills an issue or specification; NOT for general code review, explanation, or implementation; builds an acceptance contract, proves each criterion, and returns a verdict.

Acceptance Review

Treat the authoritative requirement as a contract and prove it against the implementation. Keep the review read-only; hand requested fixes to an implementation workflow after the verdict.

1. Build the contract

Resolve the subject, comparison base, authoritative issue or specification, repository rules, linked decisions, and stated exclusions.

Map every normative statement to one independently decidable criterion. Preserve its source identifier and meaning; split combined statements when their outcomes can differ. Record the observable outcome, affected surfaces and edge cases, assumptions, and exclusions.

Complete when: every in-scope normative statement maps exactly once and every ambiguity or exclusion is visible.

2. Build 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. Compare with the base only to establish regression.

Keep three evidence lanes:

Lane	What counts
Implementation	Production wiring that can produce the outcome
Verification	Executed checks or runtime observations; name the command and result
Claim	Issue/PR prose, commits, names, and comments; intent only, never behavioral proof

Cite the exact file and line for code, and the file and case name for tests. Test presence is not a passing result.

Complete when: every criterion has a complete traced path or a named break, and every citation directly supports its row.

3. Exercise the contract

Run the smallest check that exercises each observable outcome. Broaden only for shared code, cross-surface behavior, regression risk, or high-risk boundaries. Record what each result proves. Keep the subject unchanged; make unavailable checks explicit.

Complete when: every criterion has executed evidence, decisive static evidence, or a named verification gap.

4. Decide

Status	Meaning
Covered	The complete production path supports the criterion and proportionate evidence passes
Partial	Some required outcomes, surfaces, or edge cases are unsupported
Missing	The production path is absent or disconnected
Regressed	Comparison evidence proves previously supported behavior broke
Unverified	Available implementation or execution evidence cannot decide the outcome

Set the overall verdict:

• Satisfies only when every criterion is covered.
• Does not satisfy when any criterion is partial, missing, or regressed.
• Indeterminate otherwise.

Report

Lead with the verdict, subject, base, and authoritative sources. Then provide:

ID	Criterion	Status	Implementation evidence	Verification evidence

List claims only when they clarify intent. Follow with gaps, unavailable checks, and the minimum evidence or implementation needed to close each row. Keep general code-review findings outside this report.