beo-review

Purpose

Emit one terminal verdict.

Primary owned decision

Emit exactly one terminal verdict: accept, fix, or reject.

Ownership predicate

• Execution scope is complete for the current feature or bead set.
• Review evidence includes locked requirements, plan, changed files, verification, and approval reference.
• The requested work is assessment, not implementation or root-cause diagnosis.
• A terminal verdict is needed before closure, learning, or reactive-fix routing.

Writable surfaces

• .beads/artifacts/<feature_slug>/REVIEW.md — verdict, evidence, and (for rejected features) a non-promotable rejection retrospective.
• Reactive-fix bead descriptions only when canonical approval and artifact rules allow them.
• Invalidate current approval-record.json and clear approval/readiness mirrors only when reactive-fix bead description changes exceed the retained approval envelope.
• Shared state/handoff fields allowed by beo-reference → skill-contract-common.md.

Canonical: beo-reference → artifacts.md Locally enforced as:

• Use the canonical REVIEW.md minimum template.
• Keep specialist prompts evidence-only.
• Create reactive-fix beads only when the canonical approval rule is satisfied.

Hard stops

• Apply the canonical go-mode handoff gate from beo-reference → go-mode.md; if persistence evidence is absent or false, clear go-mode before normal gates.

Verdict authority

• Do not implement fixes.
• Do not accept without required verification evidence.
• Do not let specialist evidence emit the terminal verdict.

Reactive fixes and debug

• Do not create reactive-fix beads unless every condition in the canonical Reactive-fix approval rule (beo-reference → artifacts.md) is satisfied; route to beo-debug when root cause is unproven, or to beo-plan when the fix scope exceeds the current approval envelope.
• A bounded reactive fix still routes to beo-validate; bounded scope does not grant direct execution.
• When routing to beo-debug, write debug_return.return_to to STATE.json before handoff.
• Direct beo-review → beo-debug handoff is legal only when owner-state is fresh and unambiguous; if owner-state is stale, contradictory, or colliding, route to beo-route first.

Approval and scope coverage

• Do not review an execution bundle unless ready_for_review=true, finalized_at is present, and changed_file_hashes covers every aggregate changed/generated file.
• Independently compute the live execution diff from actual working tree/VCS state and execution-bundle.json.dirty_baseline, then compare it to execution-bundle.json.aggregate_changed_files; do not limit review to files self-reported by the bundle and do not accept self-reported scope_respected flags as the sole confirmation.
• If live file hashes or diff evidence diverge from the finalized bundle, abort review and route to beo-route or user according to owner-state evidence; do not silently attribute concurrent edits to the execution bundle.
• REVIEW.md Approval/Scope Lens must list every file in the union of live execution diff files and aggregate_changed_files; any unlisted file or changed file missing from aggregate_changed_files is a P1 finding that blocks accept.

Finalized bundle mismatch triage

When the finalized bundle and live diff disagree:

• live diff contains files not in aggregate_changed_files — block accept; route to user or beo-route by owner-state evidence
• concurrent edits are proven — route to user or beo-route by owner-state evidence
• bundle incomplete but same execution attempt — route to owner-state resolution; do not silently repair the bundle
• post-execution pre-review dirty files: if files in the live diff appear changed after finalized_at (i.e., their content hashes differ from changed_file_hashes in the finalized bundle), this indicates post-execution modification. Review must not attribute these changes to the execution bundle. Record the affected files as post-execution modifications, classify the finding as P1 if any in-scope file was modified, and route to user or beo-route for owner-state resolution. Do not accept when post-execution in-scope modifications are present and unaccounted for.

Verdict output card

Verdict: accept | fix | reject
Evidence checked:
Approval/scope result:
Verification result:
Blocking findings:
Learning disposition: no-learning | durable-candidate | unclear | rejection-retrospective
Learning evidence: <source artifacts or pattern refs supporting disposition>
Continue via: beo-compound | beo-validate | beo-plan | beo-explore | beo-debug | user | done
Note: beo-debug applies when root cause is unproven for a fix finding; user applies when external clarification or access is required; common paths are beo-compound (durable learning), beo-validate (bounded fix), and done (no-learning accept).
Authority note: display-only; canonical authority remains in the referenced state/artifact surface.

Learning disposition is governed by beo-reference → learning.md; local review output mechanics and optional metrics live in references/review-operations.md.

Learning disposition default

Default accepted closure is done unless review evidence identifies a specific durable or unclear learning candidate. Do not route to beo-compound merely to ask whether learning exists. When review classifies no-learning but evidence contains a reusable pattern, a non-isolated failure mode, or a cross-feature boundary decision, the classification is misclassified. Classify as unclear when in doubt; route to beo-compound rather than done whenever the signal is ambiguous. Reserve no-learning only for obviously isolated accepted changes with no reusable signal.

Allowed next owners

• beo-compound
• beo-validate
• beo-plan
• beo-explore
• beo-debug
• user
• done
• beo-route — only for exceptional owner-state resolution under canonical route doctrine.

References

• beo-reference → operator-card.md — read when formatting verdict output.
• beo-reference → artifacts.md — read when writing REVIEW.md, reactive-fix bead fields, and applying the review severity taxonomy (P0/P1/P2/P3).
• beo-reference → approval.md — read when checking reactive-fix approval retention.
• beo-reference → pipeline.md — read when routing after verdict.
• beo-reference → learning.md — read when splitting accepted-work closure.
• references/review-operations.md — read when formatting local review disposition details and optional metrics.
• references/review-specialist-prompts.md — read when gathering specialist evidence without verdict authority.