audit-plan

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Plan Flow Audit

计划流程审计

YOUR ARGUMENTS:
$ARGUMENTS

Arguments are provided above via

$ARGUMENTS

. Parse them to determine the plan folder path (e.g.,

plans/detector-refactor

). Do NOT ask the user to re-provide the path.

This skill performs a holistic flow audit of a multi-phase implementation plan. It assesses whether phases connect coherently as a pipeline — NOT whether individual phases comply with templates (that's

/review-plan

's job).

传入参数:
$ARGUMENTS

参数通过上方的

$ARGUMENTS

提供。解析参数以确定计划文件夹路径（例如：

plans/detector-refactor

）。请勿要求用户重新提供路径。

本功能对多阶段实施计划进行全面的流程审计。它评估各阶段是否能连贯地构成一个流程管线——而非检查单个阶段是否符合模板要求（这是

/review-plan

的职责）。

Critical

关键注意事项

Do NOT modify plan files, phase files, or codebase files — this skill only writes the audit report
Read ALL phase files, not just a sample — the value of this audit is completeness
Ground findings in actual codebase files, not just plan documents
When you claim a phase targets a file that doesn't exist, verify with Glob first
Distinguish between intentional design choices and actual discrepancies

请勿修改计划文件、阶段文件或代码库文件——本功能仅生成审计报告
读取所有阶段文件，而非仅抽样——审计的价值在于完整性
所有发现需基于实际代码库文件，而非仅计划文档
当你声称某个阶段的目标文件不存在时，先通过Glob进行验证
区分有意的设计选择与实际的不一致问题

Task Tracking

任务跟踪

Tasks survive context compacts — skipping this check causes lost progress and repeated work.

Before starting work, run

TaskList

to check if tasks already exist from a previous session or before a compact. If tasks exist:

Read existing tasks with
```
TaskGet
```
for each task ID
Find the first task with status
```
pending
```
or
```
in_progress
```
Resume from that task — do NOT recreate the task list

If no tasks exist, create them after reading the master plan (Step 1):

Example task list:

Task 1: Read the master plan
Task 2: Read all phase files and extract metadata
Task 3: Build dependency graph
Task 4: Assess data flow consistency
Task 5: Evaluate phase ordering
Task 6: Identify stale artifacts
Task 7: Cross-check "Done" phases against codebase
Task 8: Assess risk for pending phases
Task 9: Write audit report
Task 10: Return summary

Mark each task

in_progress

when starting and

completed

when done.

任务会在上下文压缩后保留——跳过此检查会导致进度丢失和重复工作。

开始工作前，运行

TaskList

检查是否存在来自之前会话或压缩前的任务。若存在任务：

对每个任务ID使用
```
TaskGet
```
读取现有任务
找到第一个状态为
```
pending
```
或
```
in_progress
```
的任务
从该任务继续——请勿重新创建任务列表

若不存在任务，在读取主计划（步骤1）后创建任务：

示例任务列表：

Task 1: 读取主计划
Task 2: 读取所有阶段文件并提取元数据
Task 3: 构建依赖关系图
Task 4: 评估数据流一致性
Task 5: 评估阶段排序合理性
Task 6: 识别陈旧工件
Task 7: 对照代码库交叉检查“已完成”阶段
Task 8: 评估待处理阶段的风险
Task 9: 撰写审计报告
Task 10: 返回总结

开始任务时将其标记为

in_progress

，完成后标记为

completed

。

Why This Audit Exists

本审计的存在意义

/review-plan

checks individual files. This audit checks the connections between them. Problems that only appear at the whole-plan level:

Problem	How It Manifests	Cost If Missed
Circular dependencies	Phase A waits for B, B waits for A — deadlock	Implementation stalls, requires plan restructuring
Missing dependencies	Phase 5 uses a table from Phase 3 but doesn't declare it	Phase 5 fails at runtime, debugging time wasted
Wrong ordering	Consumer phase runs before its data producer	Code compiles but crashes, phase must be re-sequenced
Stale artifacts	plan.md says "Done" but phase file says "Pending"	`/implement` picks the wrong next phase
"Done" phase not actually done	Phase marked complete but deliverables missing from codebase	Downstream phases build on a false foundation

The audit report feeds into

/implement

— it checks the plan review verdict before building. A flow audit catches structural problems that per-phase reviews cannot see.

/review-plan

检查单个文件的合规性，而本审计检查文件之间的关联。只有在整体计划层面才会显现的问题包括：

问题类型	表现形式	遗漏后的代价
循环依赖	阶段A等待阶段B，阶段B等待阶段A——形成死锁	实施停滞，需要重新调整计划结构
缺失依赖	阶段5使用阶段3生成的表，但未声明该依赖	阶段5在运行时失败，浪费调试时间
排序错误	消费阶段在数据生成阶段之前运行	代码可编译但会崩溃，必须重新排序阶段
陈旧工件	plan.md显示“已完成”但阶段文件显示“待处理”	`/implement` 会选择错误的下一阶段
“已完成”阶段未实际完成	阶段标记为已完成，但代码库中缺少交付物	下游阶段基于错误的基础进行构建

审计报告将提供给

/implement

——它会在构建前检查计划审核结论。流程审计能发现单阶段审核无法察觉的结构性问题。

Output Location

输出位置

The flow audit report goes in the

reviews/planning/

subfolder alongside per-phase reviews:

Write to:

{plan-folder}/reviews/planning/flow-audit.md

Examples:

plans/250202-voice-assistant/reviews/planning/flow-audit.md

plans/250202-api-refactor/reviews/planning/flow-audit.md

Create the

reviews/planning/

directory if it doesn't exist.

Note: Per-phase template/codebase reviews go in the same folder — see
/review-plan
. Code/implementation reviews go in
reviews/code/
— see
/code-review
.

流程审计报告需放在

reviews/planning/

子文件夹中，与单阶段审核报告放在一起：

写入路径:

{plan-folder}/reviews/planning/flow-audit.md

示例：

plans/250202-voice-assistant/reviews/planning/flow-audit.md

plans/250202-api-refactor/reviews/planning/flow-audit.md

若

reviews/planning/

注意: 单阶段模板/代码库审核报告放在同一文件夹——详见
/review-plan
。代码/实施审核报告放在
reviews/code/
——详见
/code-review
。

Step 1: Read the Master Plan

步骤1：读取主计划

Read

{plan-folder}/plan.md

completely. Extract:

Phase table — all phases with titles, status, and any noted issues
ADRs / Decision Log — decisions that constrain phase design
Critical Issues section — known problems already documented
Architectural North Star — patterns all phases must follow

Note any phases marked as deprecated, renumbered, or amended.

完整读取

{plan-folder}/plan.md

，提取以下内容：

阶段表——所有阶段的标题、状态及任何已记录的问题
ADR/决策日志——约束阶段设计的决策
关键问题部分——已记录的已知问题
架构核心准则——所有阶段必须遵循的模式

注意任何标记为已弃用、重新编号或修订的阶段。

Step 2: Read All Phase Files

步骤2：读取所有阶段文件

Use Glob to find all phase files:

{plan-folder}/phase-*.md

For EACH phase file, extract from the frontmatter and overview:

Field	Where to Find
Phase number	Filename `phase-NN-*`
Title	Frontmatter `title:`
Status	Frontmatter `status:`
Dependencies	Frontmatter `dependencies:`
What it produces	Overview section
What it consumes	"How This Phase Fits" or "Prerequisites" sections
Key files it targets	Implementation steps (file paths mentioned)

Build a mental model of the full dependency graph as you read.

使用Glob查找所有阶段文件：

{plan-folder}/phase-*.md

对每个阶段文件，从前置元数据和概述部分提取以下信息：

字段	查找位置
阶段编号	文件名 `phase-NN-*`
标题	前置元数据 `title:`
状态	前置元数据 `status:`
依赖项	前置元数据 `dependencies:`
产出物	概述部分
消耗物	“本阶段的定位”或“先决条件”部分
目标关键文件	实施步骤中提及的文件路径

读取过程中构建完整依赖关系图的心智模型。

Placeholder Check

占位符检查

Run the placeholder validator across all phase files to catch skeleton content early:

bash

echo '{"cwd":"."}' | uv run $CLAUDE_PROJECT_DIR/.claude/hooks/validators/validate_no_placeholders.py \
  --directory {plan-folder} --extension .md

If the validator exits non-zero, flag any placeholder-containing phases as stale artifacts in the report (Step 6). Phases with

[To be detailed]

TBD

, or other skeleton markers cannot be meaningfully audited for flow.

在所有阶段文件中运行占位符验证器，尽早发现框架性内容：

bash

echo '{"cwd":"."}' | uv run $CLAUDE_PROJECT_DIR/.claude/hooks/validators/validate_no_placeholders.py \
  --directory {plan-folder} --extension .md

若验证器返回非零值，在报告（步骤6）中将包含占位符的阶段标记为陈旧工件。包含

[To be detailed]

、

TBD

或其他框架标记的阶段无法进行有意义的流程审计。

Step 3: Build Dependency Graph

步骤3：构建依赖关系图

From the data collected in Step 2, construct the full dependency graph.

For each phase, document:

Declared dependencies (from frontmatter
```
dependencies:
```
field)
Implicit dependencies (phase references data/files/services created by another phase but doesn't declare it)
What downstream phases depend on it

Check for:

Issue Type	How to Detect
Circular dependencies	Phase A depends on B, B depends on A (directly or transitively)
Missing dependencies	Phase X uses output from Phase Y but doesn't list Y in dependencies
Unnecessary dependencies	Phase X lists Phase Y but doesn't actually use any of Y's output
Orphaned phases	Phase exists but no other phase depends on it AND it doesn't depend on anything
Dependency on deprecated phase	A phase depends on a phase marked `status: deprecated`

根据步骤2收集的数据，构建完整的依赖关系图。

对每个阶段，记录：

声明的依赖项（来自前置元数据
```
dependencies:
```
字段）
隐式依赖项（阶段引用了其他阶段创建的数据/文件/服务，但未声明该依赖）
哪些下游阶段依赖于本阶段

检查以下问题：

问题类型	检测方式
循环依赖	阶段A依赖阶段B，阶段B依赖阶段A（直接或间接）
缺失依赖	阶段X使用阶段Y的输出，但未在依赖项中列出Y
不必要依赖	阶段X列出阶段Y，但未实际使用Y的任何输出
孤立阶段	阶段存在，但没有其他阶段依赖它，且它不依赖任何其他阶段
依赖已弃用阶段	某阶段依赖标记为 `status: deprecated` 的阶段

Step 4: Assess Data Flow Consistency

步骤4：评估数据流一致性

Trace how data flows through the plan pipeline. For plans involving data transformations (API -> storage -> consumption), check:

Source consistency — Do all phases agree on where data comes from?
Schema consistency — Do phases that share data structures use the same types/interfaces?
Pattern consistency — Is there one architectural pattern or do different phases use contradictory approaches?
- Example: Some phases have components query the database directly while others expect data passed via context/props
Table/entity naming — Do all phases reference the same table names consistently?
File path consistency — Do phases reference files that actually exist at those paths?

Verify against codebase: For key files referenced by "Done" phases, use Glob to check they exist. For critical claims (e.g., "Phase 11 updated the orchestrator to load summary data"), read the actual file to confirm.

追踪数据在计划流程管线中的流动。对于涉及数据转换的计划（API -> 存储 -> 消费），检查：

数据源一致性——所有阶段是否对数据来源达成一致？
Schema一致性——共享数据结构的阶段是否使用相同的类型/接口？
模式一致性——是否采用统一的架构模式，还是不同阶段使用矛盾的方法？
- 示例：部分阶段让组件直接查询数据库，而其他阶段期望通过上下文/属性传递数据
表/实体命名一致性——所有阶段是否一致地引用相同的表名？
文件路径一致性——阶段引用的文件是否确实存在于指定路径？

对照代码库验证： 对于“已完成”阶段引用的关键文件，使用Glob确认其存在。对于关键声明（如“阶段11更新了编排器以加载汇总数据”），读取实际文件进行确认。

Step 5: Evaluate Phase Ordering

步骤5：评估阶段排序合理性

Assess whether the current phase sequence makes logical sense:

Infrastructure before consumers — Are foundational phases (schemas, services, APIs) ordered before phases that use them?
Producers before consumers — Does the phase that creates data run before phases that read it?
Refactoring order — For refactoring plans, is the new system built before the old system is deprecated/removed?
Test timing — Are testing phases positioned to test code that already exists?
Cleanup last — Are deprecation, migration, and drop phases at the end?

Flag ordering issues like:

A consumer phase runs before its data producer
A centralized service is created AFTER the things that should use it
Tests are written before the code they test exists
Cleanup runs before all references are migrated

评估当前阶段顺序是否符合逻辑：

基础设施先于消费者——基础阶段（Schema、服务、API）是否排在使用它们的阶段之前？
生产者先于消费者——生成数据的阶段是否排在读取数据的阶段之前？
重构顺序——对于重构计划，是否先构建新系统再弃用/移除旧系统？
测试时机——测试阶段是否安排在待测试代码已存在之后？
清理工作后置——弃用、迁移和删除阶段是否放在最后？

标记以下排序问题：

消费阶段在数据生成阶段之前运行
集中式服务在需要使用它的组件之后创建
在待测试代码编写前就编写测试
在所有引用迁移完成前就执行清理

Step 6: Identify Stale Artifacts

步骤6：识别陈旧工件

Check for:

Artifact	How to Find
Deprecated phase files	`status: deprecated` in frontmatter but file still exists
Duplicate phase numbers	Multiple files with same `phase-NN-` prefix
Broken inter-phase links	`[[phase-XX]]` or `[Phase XX](./phase-XX-*)` links that point to non-existent files
Renumbered but not updated	Phase file title says "Phase 17" but filename says `phase-18-*`
Phase table mismatches	plan.md phase table lists a phase title/file that doesn't match the actual file
Stale status	plan.md says "Done" but phase file says "Pending" (or vice versa)

检查以下内容：

工件类型	查找方式
已弃用阶段文件	前置元数据中 `status: deprecated` 但文件仍存在
重复阶段编号	多个文件使用相同的 `phase-NN-` 前缀
损坏的阶段间链接	`[[phase-XX]]` 或 `[Phase XX](./phase-XX-*)` 链接指向不存在的文件
重新编号但未更新	阶段文件标题显示“阶段17”但文件名为 `phase-18-*`
阶段表不匹配	plan.md的阶段表列出的阶段标题/文件与实际文件不符
状态不一致	plan.md显示“已完成”但阶段文件显示“待处理”（反之亦然）

Step 7: Cross-Check "Done" Phases Against Codebase

步骤7：对照代码库交叉检查“已完成”阶段

For phases marked as "Done", spot-check 2-3 key claims against the actual codebase:

Pick 2-3 "Done" phases that make testable claims (e.g., "created table X", "updated file Y", "added field Z to interface")
Use Glob/Grep to verify the claim holds in the codebase
Check if
```
{plan-folder}/reviews/code/phase-{NN}.md
```
exists for each "Done" phase — a passing code review verdict is stronger evidence than file existence alone
Flag any "Done" phases whose deliverables can't be found

This prevents the plan from proceeding on a false foundation.

对标记为“已完成”的阶段，抽查2-3个关键声明是否与实际代码库一致：

选择2-3个包含可测试声明的“已完成”阶段（如“创建了表X”、“更新了文件Y”、“为接口Z添加了字段”）
使用Glob/Grep验证声明在代码库中是否成立
检查每个“已完成”阶段是否存在
```
{plan-folder}/reviews/code/phase-{NN}.md
```
——通过代码审核的结论比文件存在更具说服力
标记任何无法找到交付物的“已完成”阶段

这可防止计划基于错误的基础继续推进。

Step 8: Assess Risk for Pending Phases

步骤8：评估待处理阶段的风险

For each pending phase, evaluate risk based on:

Risk Factor	High Risk	Low Risk
Dependencies	Depends on phases with known issues	Dependencies are clean and verified
File targets	References files that don't exist or are uncertain	Targets well-known, stable files
Scope	Touches many files across many directories	Focused on 1-2 files
Pattern clarity	Introduces new patterns not seen in codebase	Follows established patterns from "Done" phases
Blocking	Many downstream phases depend on it	Few or no downstream dependencies

对每个待处理阶段，基于以下因素评估风险：

风险因素	高风险	低风险
依赖项	依赖存在已知问题的阶段	依赖项清晰且已验证
目标文件	引用不存在或不确定的文件	目标为知名、稳定的文件
范围	涉及多个目录下的多个文件	仅聚焦1-2个文件
模式清晰度	引入代码库中未出现过的新模式	遵循“已完成”阶段的既定模式
阻塞性	许多下游阶段依赖它	很少或没有下游依赖

Step 9: Write Audit Report

步骤9：撰写审计报告

Write the report to:

{plan-folder}/reviews/planning/flow-audit.md

Create the

reviews/planning/

directory if it doesn't exist.

If the report already exists (re-auditing after fixes), Read the existing file first — the Write tool silently fails on existing files without a prior Read. A re-audit should fully overwrite the previous report since the value is a fresh holistic view, not incremental updates.

将报告写入：

{plan-folder}/reviews/planning/flow-audit.md

若

reviews/planning/

若报告已存在（修复后重新审计），先读取现有文件——Write工具在未先读取的情况下会静默覆盖失败。重新审计应完全覆盖之前的报告，因为其价值在于全新的整体视角，而非增量更新。

Report Structure

报告结构

markdown

undefined

markdown

undefined

Flow Audit: {Plan Title}

流程审计：{计划标题}

Audited: {date} Phases reviewed: {count} ({done count} Done, {pending count} Pending, {deprecated count} Deprecated) Overall Assessment: {Coherent | Minor Issues | Significant Issues | Major Restructuring Needed}

审计日期: {日期} 已审核阶段: {数量}（{已完成数量}个已完成，{待处理数量}个待处理，{已弃用数量}个已弃用） 整体评估: {连贯 | 存在小问题 | 存在重大问题 | 需要重大重构}

1. Dependency Graph

1. 依赖关系图

{Visual or textual representation. Use indentation to show dependency chains.}

{可视化或文本表示。使用缩进显示依赖链。}

Dependency Issues

依赖问题

#	Issue	Phases Affected	Severity	Suggested Fix
1	...	P05, P12	High	...

序号	问题	受影响阶段	严重程度	建议修复方案
1	...	P05, P12	高	...

2. Data Flow Analysis

2. 数据流分析

Architecture Pattern(s)

架构模式

{Describe the data flow pattern(s) used across the plan}

{描述计划中使用的数据流模式}

Inconsistencies

不一致问题

#	Issue	Phases Affected	Details
1	...	...	...

序号	问题	受影响阶段	详情
1	...	...	...

3. Phase Ordering Assessment

3. 阶段排序评估

Current Order

当前顺序

{List phases in order with one-line description}

{按顺序列出各阶段及一行描述}

Ordering Issues

排序问题

#	Issue	Current Order	Suggested Order	Rationale
1	...	P12 after P11	P12 before P11	Loader should exist before orchestrator uses it

序号	问题	当前顺序	建议顺序	理由
1	...	P12在P11之后	P12在P11之前	加载器应在编排器使用前存在

4. Stale Artifacts

4. 陈旧工件

#	Artifact	Type	Location	Action Needed
1	...	Deprecated file	phase-17-unit-tests-update.md	Delete or archive

序号	工件	类型	位置	需执行操作
1	...	已弃用文件	phase-17-unit-tests-update.md	删除或归档

5. "Done" Phase Verification

5. “已完成”阶段验证

Phase	Claim Checked	Verified?	Notes
P01	Summary table created	Yes/No	...
P11	Orchestrator loads summaries	Yes/No	...

阶段	验证的声明	是否验证通过？	备注
P01	创建了汇总表	是/否	...
P11	编排器加载汇总数据	是/否	...

6. Risk Assessment (Pending Phases)

6. 待处理阶段风险评估

Phase	Risk	Key Risk Factors	Recommendation
P12	High	Depends on P11 which may have ordering issues	Review dependency direction
P14	Medium	Modifies Edge Function with complex existing logic	Read function before implementing

阶段	风险等级	关键风险因素	建议
P12	高	依赖可能存在排序问题的P11	审查依赖方向
P14	中	修改包含复杂现有逻辑的Edge Function	实现前先阅读函数代码

7. Recommendations (Priority Order)

7. 建议（按优先级排序）

[Critical] {Description} — Fix before continuing implementation
[High] {Description} — Fix before implementing affected phases
[Medium] {Description} — Fix for plan hygiene
[Low] {Description} — Nice to have

undefined

[关键] {描述} — 继续实施前需修复
[高] {描述} — 实施受影响阶段前需修复
[中] {描述} — 为保持计划整洁需修复
[低] {描述} — 可选优化

undefined

Step 10: Return Summary

步骤10：返回总结

After writing the report, return to the main agent:

Report location — file path
Overall assessment — one-line verdict
Critical/High issues count — how many need attention before implementation continues
Top 3 findings — the most impactful discoveries
Recommendation — whether to proceed, fix first, or restructure

撰写报告后，向主Agent返回以下内容：

报告位置——文件路径
整体评估——一行结论
关键/高优先级问题数量——继续实施前需关注的问题数量
前3项发现——影响最大的发现
建议——是否继续推进、先修复或重构

Resuming After Context Compact

上下文压缩后恢复工作

If you notice context was compacted or you're unsure of current progress:

Run
```
TaskList
```
to see all tasks and their status
Find the
```
in_progress
```
task — that's where you were
Run
```
TaskGet {id}
```
on that task to read full details
Continue from that task — don't restart from the beginning

Tasks persist across compacts. The task list is your source of truth for progress, not your memory.

Pattern for every work session:

TaskList → find in_progress or first pending → TaskGet → continue work → TaskUpdate (completed) → next task

若发现上下文已被压缩或不确定当前进度：

运行
```
TaskList
```
查看所有任务及其状态
找到
```
in_progress
```
任务——这是你之前的工作位置
对该任务运行
```
TaskGet {id}
```
以读取完整详情
从该任务继续——不要从头开始

任务会跨压缩会话保留。任务列表是进度的唯一可信来源，而非你的记忆。

每个工作会话的模式：

TaskList → 找到in_progress或第一个pending任务 → TaskGet → 继续工作 → TaskUpdate（标记为completed）→ 下一个任务

Constraints

约束条件

Source files are read-only — do NOT modify plan files, phase files, or codebase files. The only file you write is the audit report at
```
{plan-folder}/reviews/planning/flow-audit.md
```
All phases — read every phase file, not just a sample
Codebase grounding — verify at least 2-3 "Done" phase claims against actual code. Use file paths from the phases themselves (implementation steps list target files)
No template checking — that's
```
/review-plan
```
's job. Focus on flow, not format
Severity calibration — only mark issues as Critical if they would cause implementation failure. Use High for likely problems, Medium for hygiene issues, Low for suggestions
Pipeline awareness —
```
/implement
```
checks the plan review verdict before building. Your audit report influences whether implementation proceeds or blocks

源文件为只读——请勿修改计划文件、阶段文件或代码库文件。仅可写入
```
{plan-folder}/reviews/planning/flow-audit.md
```
路径下的审计报告
所有阶段——读取每个阶段文件，而非仅抽样
基于代码库——至少验证2-3个“已完成”阶段的声明与实际代码一致。使用阶段自身提供的文件路径（实施步骤中列出的目标文件）
不检查模板——这是
```
/review-plan
```
的职责。聚焦于流程，而非格式
严重程度校准——仅当问题会导致实施失败时标记为关键。高优先级用于可能出现的问题，中优先级用于整洁性问题，低优先级用于建议
管线感知——
```
/implement
```
在构建前会检查计划审核结论。你的审计报告会影响实施是否继续或被阻塞

Troubleshooting

故障排除

Too Many Phase Files

阶段文件过多

Symptom: Plan has 30+ phases and reading all of them is slow.

Fix: Read frontmatter + overview section only (first 60 lines) for initial pass. Deep-read only phases flagged as problematic during the dependency/flow analysis.

症状： 计划包含30+个阶段，读取所有文件速度缓慢。

解决方法： 初始仅读取前置元数据+概述部分（前60行）。仅对依赖/流分析中标记为有问题的阶段进行深度读取。

Plan Has No Dependency Metadata

计划无依赖元数据

Symptom: Phase files don't have

dependencies:

in frontmatter.

Fix: Infer dependencies from content — look for "requires Phase X", "uses table from Phase Y", "after Phase Z is complete" in the overview and prerequisites sections. Flag the missing metadata as a stale artifact.

症状： 阶段文件的前置元数据中没有

dependencies:

。

解决方法： 从内容推断依赖项——在概述和先决条件部分查找“需要阶段X”、“使用阶段Y生成的表”、“阶段Z完成后”等表述。将缺失的元数据标记为陈旧工件。

"Done" Phase Can't Be Verified

“已完成”阶段无法验证

Symptom: Phase claims to have modified a file but Glob/Grep can't confirm.

Fix: Don't assume the phase wasn't implemented — the file might have been refactored or renamed since. Check git history if available, or note as "Unverifiable" rather than "Not Done."

症状： 阶段声称修改了某个文件，但Glob/Grep无法确认。

解决方法： 不要假设阶段未实施——文件可能自那以后被重构或重命名。若有可用的git历史则检查，否则标记为“无法验证”而非“未完成”。