---
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.