---
name: review-business-delivery
description: Use when reviewing complex business delivery artifacts, AI-generated plans, PR diffs, or module designs for permission gaps, illegal state transitions, missing audit logs, weak exception handling, unclear dashboard metrics, missing tests, or incomplete acceptance evidence.
---

# Review Business Delivery

## Core Principle

Review behavior and risk before wording. Findings must be evidence-based, severity-ranked, and tied to a verification action.

The review output should help the team decide whether to accept, conditionally accept, or reject the delivery.

## Inputs

Use any available inputs:

- Requirement scope and non-goals.
- RBAC matrix and permission control plan.
- State transition table and illegal transition list.
- Audit SOP and exception-state list.
- Dashboard metric dictionary and API acceptance record.
- Code diff, API contract, test result, Browser verification record, or PR description.
- Project rules and constraints.

If source evidence is missing, create an `证据缺口` section instead of guessing.

## Review Flow

1. Confirm delivery scope: what is being reviewed and what is outside scope.
2. Check source evidence: paths, rules, design tables, test results, and verification records.
3. Review permission risk: page/menu, button, backend API, and data scope.
4. Review state risk: legal transitions, illegal transitions, terminal states, duplicate submits, and role restrictions.
5. Review audit risk: action coverage, field completeness, masking, failure behavior, and consistency with business writes.
6. Review exception risk: empty, missing, invalid, forbidden, duplicate, concurrent, and downstream failure states.
7. Review dashboard risk: formula, filter, dimension, data source, permission, empty state, and manual calculation.
8. Review tests and acceptance: commands, roles, sample data, browser evidence, and unresolved risks.
9. Output findings sorted by severity.

## Severity

| Level | Meaning |
| --- | --- |
| P0 | Data loss, privilege bypass, irreversible wrong state, or release-blocking failure |
| P1 | Security, permission, audit, or state-machine defect with realistic business impact |
| P2 | Missing acceptance evidence, unclear metric, weak exception handling, or test gap |
| P3 | Maintainability, naming, documentation, or minor consistency issue |

## Output Contract

```md
## Review 结论

通过 / 有条件通过 / 不通过

## 问题清单

| 等级 | 模块 | 问题 | 证据 | 风险 | 修复建议 | 验收方式 |
| --- | --- | --- | --- | --- | --- | --- |

## 证据缺口

| 缺口 | 影响 | 需要谁补充 |
| --- | --- | --- |

## 待确认

| 问题 | 决策人 | 建议默认值 |
| --- | --- | --- |
```

Use the templates and checklists in `assets/` when writing files.

## Quality Gates

- Findings lead the response; summaries are secondary.
- Every P0/P1 finding cites a source path, table row, endpoint, role, state, metric, or verification record.
- Every finding has a concrete fix direction and acceptance method.
- Review does not accept frontend-only security controls.
- Missing tests or missing evidence are called out explicitly.
- Unclear business rules are marked `待确认`, not invented.

## Common Mistakes

- Do not write "整体不错" before listing risks.
- Do not merge all issues into one generic recommendation.
- Do not downgrade permission bypass, illegal state transitions, or missing audit for critical actions.
- Do not claim an issue is fixed without verification evidence.
- Do not review only code style when the requested delivery is business behavior.