smart
90 lines
3.5 KiB
Markdown
90 lines
3.5 KiB
Markdown
---
|
|
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.
|