Files

T

2026-07-02 10:04:32 +08:00

3.6 KiB

Raw Permalink Blame History

name, description

name	description
track-review-fix-loop	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

Normalize review findings: ensure each issue has an ID, severity, module, risk, and suggested verification.
Decide validity: 成立, 不成立, or 需确认; cite evidence.
Map valid fixes to changed files, tables, prompts, rules, or templates.
Verify each fix using commands, API checks, browser steps, role-based tests, or manual calculation.
Identify regressions: related permissions, states, audit actions, dashboard metrics, and exception states to re-check.
Decide asset sedimentation: rule, checklist, prompt, Command, Skill, example, or no asset.
Output unresolved items with owner and next step.

Output Contract

## 修复闭环结论

完成 / 部分完成 / 未完成

## 修复记录

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

3.6 KiB Raw Permalink Blame History