用途：对代码库做全量取证式审计，并产出分阶段、可回滚的重构计划。核心原则是先调查、再架构、最后改代码；代码是唯一事实来源，注释、文档、提交信息与命名都只是“声明”，需与实际执行逻辑核对，不一致本身即为发现（COMMENT_LIE）。每条发现须给出 path/file.ext:line-range 与最小证据片段，并按 CONFIRMED、LIKELY、SUSPECTED 标注置信度；无法证明未使用的代码不得删除。
主要能力：分阶段产出报告文件。PHASE 0 侦察（目录地图、入口与出口、配置面、数据模型、规模指标）；PHASE 1 可达性与接线真相（调用图、孤儿代码、断线接线、分层违规、导入环）；PHASE 2 重复审计（按簇分组，关注副本分歧）；PHASE 3 补丁式代码审计（回溯根因）；PHASE 4 忽略注释的缺陷搜寻（缺陷类扫描）；PHASE 5 功能集成验证（逐跳追踪并标记 CONNECTED/MISSING/DIVERGENT/UNVERIFIABLE，输出健康表）；PHASE 6 测试与安全网核查（关键路径覆盖、最小特征化测试）；PHASE 7 重构计划（目标架构、每簇规范实现、分步步骤表、禁止改动清单）；PHASE 8 执行（仅在批准后，一步一提交）。
使用方式：先与用户确认仓库路径、语言框架、构建运行测试方式、约束、范围与会话安排；超过约 5 万行建议分会话执行。各阶段写入 reports/ 下独立文件，并维护 reports/SUMMARY.md。
适用场景：需要系统审计、清理、重构或验证“是否真的可用”的代码库。
限制：PHASE 0–6 不得改动生产代码；PHASE 7 后须等待批准；不做大规模重写；动态分发、DI、反射、字符串注册路由、定时与队列任务、特性开关及外部调用方会使静态可达性判断受限，无法静态验证的结论应列入 OPEN_QUESTIONS。具体命令、模板与参考文件内容暂未提供。