smart
95 lines
3.6 KiB
Markdown
95 lines
3.6 KiB
Markdown
---
|
|
name: track-review-fix-loop
|
|
description: Use when turning review findings into a fix-tracking record, deciding whether findings are valid, mapping fixes to files, verifying results, documenting unresolved items, or deciding which issues should become reusable rules, checklists, prompts, examples, or team assets.
|
|
---
|
|
|
|
# Track Review Fix Loop
|
|
|
|
## Core Principle
|
|
|
|
A review issue is not closed by saying "fixed". It closes only when the team records validity, changed artifacts, verification evidence, unresolved risk, and whether the lesson should become a reusable asset.
|
|
|
|
## Inputs
|
|
|
|
- Review report with numbered findings.
|
|
- Requirement or acceptance criteria.
|
|
- Code diff, design document, generated tables, or changed files.
|
|
- Test results, Browser verification evidence, API response samples, or manual validation notes.
|
|
- Existing team rules, checklists, examples, and asset index.
|
|
|
|
If validation evidence is missing, mark the item as `未闭环`.
|
|
|
|
## Status Model
|
|
|
|
Use one of these statuses for each review item:
|
|
|
|
| Status | Meaning |
|
|
| --- | --- |
|
|
| `成立-已修复` | Finding is valid, changed artifacts are listed, and verification evidence exists |
|
|
| `成立-暂不修复` | Finding is valid but deferred with reason, owner, and follow-up date |
|
|
| `不成立` | Finding is invalid with evidence |
|
|
| `需确认` | Finding depends on business or technical decision not available in current evidence |
|
|
| `未闭环` | Fix is claimed but evidence is missing |
|
|
|
|
## Workflow
|
|
|
|
1. Normalize review findings: ensure each issue has an ID, severity, module, risk, and suggested verification.
|
|
2. Decide validity: `成立`, `不成立`, or `需确认`; cite evidence.
|
|
3. Map valid fixes to changed files, tables, prompts, rules, or templates.
|
|
4. Verify each fix using commands, API checks, browser steps, role-based tests, or manual calculation.
|
|
5. Identify regressions: related permissions, states, audit actions, dashboard metrics, and exception states to re-check.
|
|
6. Decide asset sedimentation: rule, checklist, prompt, Command, Skill, example, or no asset.
|
|
7. Output unresolved items with owner and next step.
|
|
|
|
## Output Contract
|
|
|
|
```md
|
|
## 修复闭环结论
|
|
|
|
完成 / 部分完成 / 未完成
|
|
|
|
## 修复记录
|
|
|
|
| Review 编号 | 等级 | 问题 | 状态 | 修改文件/产物 | 验证证据 | 剩余风险 | 资产沉淀 |
|
|
| --- | --- | --- | --- | --- | --- | --- | --- |
|
|
|
|
## 未闭环事项
|
|
|
|
| 编号 | 原因 | 负责人 | 下一步 | 截止时间 |
|
|
| --- | --- | --- | --- | --- |
|
|
|
|
## 资产更新建议
|
|
|
|
| 来源问题 | 资产类型 | 建议文件 | 更新内容 |
|
|
| --- | --- | --- | --- |
|
|
```
|
|
|
|
Use `assets/修复记录.template.md` and `assets/Review修复闭环检查清单.md` when creating files.
|
|
|
|
## Asset Decision Guide
|
|
|
|
| If the issue is... | Asset |
|
|
| --- | --- |
|
|
| Repeated project convention violation | rule |
|
|
| Repeated review checklist miss | checklist |
|
|
| Reusable question or generation pattern | prompt |
|
|
| One-step repeatable agent action | command |
|
|
| Multi-step judgment workflow | skill |
|
|
| Good or bad teaching sample | example |
|
|
|
|
## Quality Gates
|
|
|
|
- Every fixed issue has verification evidence.
|
|
- Every deferred issue has owner and next step.
|
|
- Every invalid issue has source evidence, not opinion.
|
|
- P0/P1 issues cannot be marked complete without direct verification.
|
|
- Asset updates are specific file suggestions, not vague "沉淀经验".
|
|
|
|
## Common Mistakes
|
|
|
|
- Do not close issues with "已修复" without evidence.
|
|
- Do not erase invalid findings; keep why they are invalid.
|
|
- Do not mark business decisions as technical fixes.
|
|
- Do not create a Skill for a one-off checklist item.
|
|
- Do not ignore regressions around permissions, state transitions, audit logs, and dashboard metrics.
|