sakura-review

name	sakura-review
description	Review final changes against the specification, acceptance contract, and actual verification evidence, then return PASS, PASS_WITH_NOTES, FIX_REQUIRED, or BLOCKED. Use for final completion decisions or independent code review; do not implement a feature from scratch.

Sakura Review

Role

Inspect correctness, scope, regression risk, security, privacy, compatibility, and completion evidence before delivery, then return one deterministic verdict.

Use When

• The active milestone or complete task has finished verification.
• The user requests review of a working tree, commit, branch, or pull request.
• The task needs a reliable Done decision.

Do Not Use When

• No reviewable diff or implementation exists.
• Critical verification has not run and no valid blocker explains why.
• The user requested implementation or technical research.

Inputs

• The actual diff and relevant code context.
• docs/project/PRODUCT_SPEC.md, ACCEPTANCE.md, and EXECUTION_PLAN.md.
• Task state, verification results, error history, and current limitations.
• Replication scope, levels, contracts, matrix, evaluator result, and gaps when an existing system is the target.

Outputs

• Specific findings ordered by severity.
• A location, evidence, impact, and smallest repair direction for every finding.
• One of PASS, PASS_WITH_NOTES, FIX_REQUIRED, or BLOCKED.
• A handoff to Done, sakura-fix, or another required stage.

Workflow

1. Confirm the review scope and preserve unrelated user changes.
2. Inspect the actual diff, surrounding code, and real verification output instead of summaries alone.
3. Check every Must acceptance item, failure path, regression risk, security boundary, privacy concern, and compatibility requirement.
4. Check for unrelated refactoring, unexpected artifacts, secrets, and evidence gaps.
5. For replication work, confirm that target and architecture signals produced the correct L1-L4 requirement, every required level has evidence, and no mandatory gap or approximation is hidden.
6. Require every finding to identify a location, explain impact, and provide an actionable repair direction.
7. Select one verdict from the severity and completion rules.
8. When acting as the parent, write review state and run the completion gate only when the task is eligible to finish. A delegated reviewer returns findings and a report verdict but never writes shared state or Done.

Read review-checklist.md for a formal review. Read completion-evaluation.md before deciding whether the task is complete.

Quality Gate

• The review is based on actual code and verification evidence.
• Findings are concrete and evidence-based, without vague advice or filler praise.
• Blocking and non-blocking issues are clearly separated.
• The verdict matches acceptance, verification, and task state.
• A failed review cannot write Done.
• The parent independently checks delegated findings against the actual diff and remains the only owner of the final review verdict.
• Replication Done is rejected when any capability is under-classified, partial, approximate, lacks required evidence, or has an open mandatory gap.

Failure and Fallback

• Return BLOCKED when critical code, environment, acceptance, or evidence is unavailable.
• Return FIX_REQUIRED and hand off to sakura-fix when a blocking implementation problem exists.
• Return to sakura-spec when expected product behavior is wrong.
• Return PASS_WITH_NOTES only when remaining items are explicitly non-blocking.

Upstream and Downstream

• Upstream: sakura-verify, or a user-requested independent review.
• Downstream: Done, sakura-fix, sakura-spec, or Blocked.

Handoff

Include the verdict, blocking count, key findings, completion evidence, unverified items, remaining risks, and next action. Only PASS or PASS_WITH_NOTES with zero blockers may proceed to Done.