## 【逻辑漏洞】

1. ROI 公式量纲不成立 | “ROI = 人工成本 ÷ (预估 token 上限 × 15)” | 人工成本通常以金额或工时计，token 是数量，二者未经单价换算不能直接相除；所得阈值“3~5”没有稳定含义 | 补充统一计价单位、token 单价、人工时薪、质量收益和失败成本，并定义 ROI 的统计口径

2. ROI 分母未反映多 Agent 的真实成本 | “分母按单 agent 基准估算 token，×15…不按多 agent 实际消耗估算” | 固定乘数只是先验假设，无法用于事后验证，也会掩盖不同任务的实际放大倍数；文中又称复杂任务可能达到 30~50 倍 | 区分“立项预估 ROI”和“结案实测 ROI”，后者必须使用实际 token、工具、人工和等待成本

3. “调低 ROI 预期”方向含糊 | “若任务涉及该区域…或大幅调低 ROI 预期” | 不清楚是降低预估收益、降低准入阈值，还是接受更差 ROI；三者会导向相反决策 | 明确调整的是公式中的哪个变量，以及调整后是否更容易还是更难进入多 Agent 流程

4. 适切性第一问混合了两个不同条件 | “经常失败、或需要大量人类追问吗？” | “经常失败”和“追问多”不是同一风险，且“一次通过率 >80%”无法覆盖追问次数、任务复杂度和失败严重度 | 拆分成功率、追问次数、上下文超限和失败损失等独立判据，并定义统计样本窗口

5. “纯创意类不可验证”属于过度推论 | “纯创意类 → 别上” | 创意任务仍可通过约束满足、候选多样性、人类偏好评测等方式验收；输出可验证性不等于只能客观量化 | 补充允许偏好评测或候选比较的适用条件，不要把“主观”直接等同于“不可验收”

6. 反向量化样例统计上不稳健 | “随机抽 3 个新人…比例 ≥66%” | 3 人样本中“≥66%”实际近似要求 2/3，通过率每变化一人就跳变 33.3%，无法稳定衡量文档质量 | 补充样本选择、独立性、任务时限、成功定义及最低样本量

7. “参考改写”的验证门槛不能证明适配性 | “通过原仓库全部测试 + 我方冒烟场景” | 原仓库测试主要证明上游版本行为，我方冒烟仅覆盖核心路径，均不足以证明许可、依赖、安全、性能和完整验收项满足 | 增加适配矩阵、依赖审计、完整验收覆盖和安全检查；原仓库测试只能作为证据之一

8. “过不了就确认没有”结论不成立 | “过不了就降级为‘确认没有’” | 找到参考实现但验证失败，不等于“没有现成实现”；会丢失“存在但不适用/验证失败”这一重要状态 | 增加“存在但不适配”或“验证失败”结论，并记录失败原因

9. 文件无交集不代表任务可并行 | “有交集的模块强制串行…无依赖并行” | 模块可能通过数据库、生成物、配置、接口语义或共享测试环境产生隐性冲突，文件列表不能完整表达依赖 | 增加资源级、契约级、数据级、环境级依赖和冲突声明

10. 串行化不能解决所有权冲突 | “有交集的模块强制串行” | 两个 worker 即使串行修改同一文件，也可能覆盖、撤销或误解前一个 worker 的修改 | 明确同文件多阶段修改的所有权转移、基线版本、补丁应用和冲突复核机制

11. 上下文预算百分比缺少基数 | “系统提示 ≤10%…worker 摘要 ≤50%” | 未说明按模型最大上下文、当前调用窗口还是任务累计 token 计算；各项之和也无法处理工具返回突增 | 定义预算基数、预留安全边界、超额裁剪顺序和摘要失败处理

12. Reviewer 分歧判定掩盖真实差异 | “一方多报一条不算分歧” | 多出的 blocking issue 可能是严重漏洞；将集合包含关系直接视为一致，会把“接受”和“存在额外阻断项”混为一谈 | 按验收项 ID、严重度和 verdict 比较；新增阻断项至少应进入核实状态，不能直接视为一致

13. 空报告规则把正常通过判为无效 | “任一 reviewer 返回空 blocking_issues → 判定无效” | 验收全部通过时，`blocking_issues=[]` 是正常结果；该规则会使正常 accept 永远触发人工检查 | 区分“字段缺失/未执行检查”和“执行完成后无阻断项”，要求 checklist 完整性而不是要求必须报问题

14. Reviewer schema 无法可靠做集合比对 | “blocking_issues: [‘string’]” | 自由文本没有稳定 ID、严重度、验收项关联和规范化键，Code 层无法可靠判断子集、重复或同一问题 | 为 issue 增加稳定 ID、acceptance_id、severity、location、fingerprint 和 evidence 字段

15. 失败阶梯并非真正的“逐级升级” | “逐级升级，不许跳级”与“首次指纹漂移判 L2” | 第二次计入阶梯的失败可以直接进入 L2，未经历 L1；“不许跳级”与实际状态转换不一致 | 给出明确状态机和合法迁移表，说明哪些路径允许跳过 L1

16. 同因失败被直接归因为 Brief 问题，因果不足 | “同因失败 2 次…信号含义：Brief 的问题” | 同一错误重复可能来自实现能力不足、测试错误、环境稳定故障或架构约束，不足以证明 Brief 有问题 | 增加证据判据；只有发现目标、约束、依赖或验收描述缺陷时才回写 Brief

17. 指纹漂移被直接归因为模块问题，因果不足 | “指纹漂移…信号含义：模块的问题” | 修复前一问题后暴露下一问题是正常调试过程，不必然说明模块不可治理 | 区分“连锁暴露”“新引入回归”“独立缺陷”和“随机漂移”，再决定是否进入逃生舱

18. 默认进入妥协模式可能降低最终质量 | “首次指纹漂移…默认落妥协模式（补丁 + FIXME）” | 指纹漂移一次就允许硬编码或补丁，可能把正常多缺陷任务过早转化为技术债 | 增加风险等级、安全域禁用条件、技术债批准人、清偿期限和退出标准

19. “误触发代价只是一条技术债”低估风险 | “不是一次大手术” | 补丁可能造成安全、数据一致性、维护和合规风险，不一定是低成本可逆操作 | 对逃生舱做影响评估，并规定认证、支付、数据迁移等高风险领域不得默认妥协

20. 灰轨放行公式不足以保证授权 Bug 已被修复 | “灰轨失败集合 ⊆ 已授权翻转清单” | 若某个授权修复的 Bug 实际未修，原灰测试仍绿，失败集合为空，仍满足子集条件；只能依赖白轨碰巧覆盖该行为 | 增加“每个授权翻转项必须有对应白测试通过或明确放弃记录”的双向覆盖约束

21. “白测试从契约编译”无法覆盖全部行为契约 | “白测试是契约文件…的编译产物，禁止手写” | TS interface、Protobuf、OpenAPI 通常只能生成结构或基础请求测试，无法自动推出轮换、安全语义、幂等性等行为断言 | 定义行为契约 DSL、生成器能力边界和人工审核机制；不确定能生成的行为不得声称完全自动化

22. 对比归一化可能掩盖真实回归 | “列表比较前排序” | 列表顺序在很多接口中具有业务语义；统一排序会把顺序回归误判为相等 | 由契约逐字段声明是否无序，不得全局默认排序

23. 指纹标定样本量不足以支撑 90% 结论 | “30 个样本分类准确率 ≥90%” | 30 个注入样本高度人工化，且每类约 10 个，无法证明真实运行中的泛化能力 | 增加真实历史失败、交叉验证、混淆矩阵和置信区间，并单独评估跨模块故障

24. 健康指标的归因过于单一 | “L3 占比超过 → 粒度过细” | L3 高还可能来自任务选择错误、worker 能力不足、契约差、环境不稳定或预算过低 | 为每个指标定义多因素诊断流程，不要直接绑定单一原因

---

## 【不可执行】

1. Phase 1 时间盒没有可计算基准 | “通用功能 15-20%…基础设施 25-30%” | 未说明百分比相对于总工期、token 预算、人工工时还是 Phase 预算，也未规定到时如何停止 | 指定基数、计时主体、超时动作和允许延长的审批条件

2. “完整搜索记录”没有完成标准 | “确认没有（附完整搜索记录）” | 搜索空间开放且不可穷尽，无法判断何时算“完整” | 定义必查源、查询数量、关键词变体、时间范围、停止条件和记录 schema

3. 原仓库全部测试通常不可稳定复现 | “必须通过原仓库全部测试” | 上游可能缺失环境、依赖已失效、测试耗时过长或包含平台特定测试；没有例外处理 | 增加不可复现分类、环境锁定、豁免审批和替代证据

4. Phase 0 要求“完整场景”但未给产出责任 | “冒烟场景…+ 完整场景（全量）” | “产出五样”只明确写了“冒烟场景”，未说明谁在何时生成、审核和冻结完整场景 | 将完整场景列为正式交付物，并指定负责人、版本和变更流程

5. 上游就绪标志没有机器定义 | “上游就绪标志” | 未说明是文件存在、测试通过、契约版本匹配还是人工批准，Code 层无法据此自动 blocked/unblocked | 定义结构化状态、满足条件、发布者和失效条件

6. Contract as Code 的行为层没有统一执行器 | “行为约束…写成 CI 测试” | 不同项目和语言的 CI、测试框架、环境依赖不同，不能仅靠一句“写成测试”执行 | 规定测试生成器、运行入口、环境镜像、超时、结果格式和失败归属

7. 文件锁粒度和生命周期未定义 | “声明冲突的文件…物理互斥” | 未说明锁在编辑、提交还是整个 worker 生命周期持有；worker 崩溃后是否释放也未写 | 定义锁获取、续租、超时、崩溃回收、死锁检测和强制解锁审计

8. “限定在文件清单内写入”无法覆盖生成文件 | “builder 限定在其文件清单内写入” | 编译器、格式化器、包管理器、代码生成器可能修改锁文件、快照和生成物，容易导致任务无法完成 | 增加允许写入模式、生成物声明和动态扩权审批流程

9. 调用超限直接 kill 没有成果保全 | “超限 kill 并标记” | 没有说明未提交修改、临时文件、锁和状态如何处理，可能留下污染工作区 | kill 前保存状态或隔离工作树；定义清理、回滚和是否允许续跑

10. token 熔断后的业务状态不清楚 | “单任务 token 超预算 120% → 强制中断” | 未说明中断后是失败、暂停、降级还是转人工，也未说明部分结果是否可验收 | 定义熔断状态、产物封存、恢复授权和下游阻塞规则

11. SQLite 断点恢复缺少幂等协议 | “进程重启后从 DB 恢复” | 恢复时可能重复派发、重复写文件、重复部署或重复执行迁移；仅持久化状态不能保证安全恢复 | 增加任务幂等键、租约、操作日志、提交点和副作用补偿

12. 环境失败重试策略过于机械 | “自动重试上限 3 次” | 没有退避、抖动、故障类型区分和总时限，可能对持续故障重复施压 | 增加指数退避、可重试错误白名单、熔断窗口和环境恢复探测

13. 主观验收的“双 Reviewer 独立”没有隔离办法 | “双 Reviewer 独立判定” | 未说明是否隔离彼此输出、随机化顺序、使用相同模型或不同模型；同模型同 prompt 可能高度相关 | 定义上下文隔离、模型配置、随机种子、评审顺序和串谋/相关性控制

14. “根因分析一句话”没有质量校验 | “输出一句话失败根因分析” | 只限制形式，不要求证据；生成一个貌似具体但错误的根因即可继续 | 要求引用日志、失败项和反证，并由规则或 Reviewer 校验可证伪性

15. 顾问模式后的执行闭环缺失 | “人类在 IDE 中手动接受” | 未说明人类完成后由谁提交、如何重新进入测试、失败算哪一轮、是否更新指纹 | 补充人工接管后的状态流转、产物格式、回归测试和重新入阶梯规则

16. 高腐化区标记范围无法可靠确定 | “标记高腐化区” | 未说明按文件、目录、模块、服务还是契约标记；跨模块故障可能被错误归到单一路径 | 定义 zone 划分算法、人工修订权限、继承规则和失效/解除条件

17. “原代码灰轨 100% 绿”可能无法满足 | “原代码 100% 绿” | 遗留系统可能本来就有 flaky、环境依赖或不可运行测试；流程没有基线例外 | 定义隔离 flaky、稳定性采样、豁免和不可建立灰轨时的替代路径

18. 契约生成与提交责任不唯一 | “由人类或最强推理档模型…生成并 Commit” | 未说明谁批准、谁拥有 Git 身份、谁处理冲突、模型是否有写权限 | 指定契约 owner、审批者、提交主体和保护分支规则

19. 模型降级回退指标缺少统计窗口 | “通过率下降 >10% → 自动回退” | 未定义绝对下降还是相对下降、样本量、观察周期和任务难度校正，无法自动执行 | 补充基线窗口、最小样本量、显著性规则和任务分层

20. 附录 schema 与正文判定无法直接衔接 | “conclusion=notfound 时 searchtrace 必填” | schema 实际枚举为 `not_found`、字段为 `search_trace`；实现按附注校验会找不到字段 | 统一机器字段名并提供正式 JSON Schema 和版本号

21. JWT 示例的依赖排程不充分 | “批 3：M3d ∥ M5” | M5 是 e2e 补齐，通常依赖所有迁移模块完成；若确实可并行，文中未给出其独立依据，属“不确定” | 明确 M5 可先执行的部分、依赖版本和最终重跑时机

---

## 【缺失项】

1. 缺少端到端任务状态机 | “Phase -1 至 Phase 6” | 只有阶段叙述，没有完整状态、合法迁移、终态及恢复路径，尤其 blocked、killed、熔断、人工接管之间关系不清 | 增加机器可执行的状态枚举和迁移表

2. 缺少验收清单的变更控制 | “对照 Phase 0 原始验收标准” | 执行中发现需求错误或遗漏时，没有谁能改、如何版本化、已有 brief 如何失效的机制 | 增加验收项 owner、版本、审批、影响分析和重新覆盖检查

3. 缺少契约版本兼容策略 | “契约文档（唯一 schema 来源）” | 没有版本号、兼容性规则、废弃期和多版本并存方案，跨批次 worker 可能引用不同契约 | 增加契约版本、兼容性检查、锁定版本和升级流程

4. 缺少代码合并与提交策略 | “worker 输出必须符合契约” | 未定义分支/worktree、commit 粒度、合并顺序、冲突解决者和失败回滚 | 增加隔离工作区、提交规范、合并责任和原子回滚机制

5. 缺少测试环境隔离 | “并行…跑测试” | 并行 worker 可能共享数据库、端口、缓存或容器，导致污染和假失败 | 为每个任务分配隔离环境、命名空间和清理流程

6. 缺少测试 flaky 的一般处理 | “灰轨…排除 flaky” | 仅对灰轨提到 flaky，普通验收测试、冒烟和完整场景没有重跑及判定规则 | 增加 flaky 检测、隔离、重试和责任归属

7. 缺少安全与密钥治理 | “WebFetch”“cloud CLI”“K8s client” | 未说明凭据注入、最小权限、密钥脱敏、网络出口和敏感日志处理 | 增加 secrets 管理、临时凭据、审计、脱敏和网络策略

8. 缺少高风险操作审批 | “deployer…部署、配置管理” | 数据删除、生产发布、权限变更等可产生不可逆副作用，却未设置独立审批门 | 增加环境分级、变更审批、dry-run、双人确认和生产禁区

9. 缺少常规交付的回滚方案 | “回滚旧实现”只出现在受控重写 | 非重写任务、数据迁移、部署失败时没有统一回滚和补偿机制 | 为各类副作用定义 rollback point、恢复演练和失败补偿

10. 缺少数据迁移一致性机制 | “data-worker…数据迁移、ETL” | 没有事务边界、校验和、双写、断点、重放、回滚及隐私处理 | 增加数据迁移专用协议和验收项

11. 缺少 Human Checkpoint 的响应规则 | “触发 Checkpoint ③” | 未定义审批人、SLA、超时默认动作、拒绝后流向和授权有效期，任务可能永久悬挂 | 增加责任人、响应时限、超时终态和授权范围

12. 缺少预算的非 token 成本 | “预算计数器”“token 超预算” | 工具调用、云资源、CI 时间、人类评审和等待成本没有纳入预算，ROI 会失真 | 建立统一成本账本并按任务归集

13. 缺少产物完整性与来源验证 | “详细结果写文件只回摘要” | 领导只看摘要时，无法保证摘要与落盘内容一致，也未校验文件是否被篡改 | 增加内容哈希、产物 manifest、签名或可追溯引用

14. 缺少日志中的敏感信息规则 | “失败根因分析内容”“详细日志落盘” | 错误日志可能包含密钥、用户数据和源码，当前 observability schema 未包含分级或脱敏 | 增加日志分类、脱敏、访问控制、保留期和删除机制

15. 缺少供应链与许可证审批 | “所有采用代码记来源与许可” | 记录许可不等于许可兼容、漏洞安全或允许商用 | 增加许可证政策、依赖漏洞扫描、来源可信度和审批流程

16. 缺少验收证据留存 | “逐项检查” | verdict 只有文本 detail，没有强制关联日志、测试报告、截图或性能原始数据 | 每个验收项要求 evidence URI、哈希、执行环境和时间戳

17. 缺少任务取消与优先级机制 | “拆批串行” | 没有用户取消、需求变更、紧急任务抢占或批次重排规则 | 增加 cancel/pause/resume、优先级和安全终止流程

18. 缺少长期技术债闭环 | “强制打 # FIXME: Tech Debt” | 只打标签，没有 owner、期限、工单、风险等级和逾期处理，妥协模式可能永久化 | 自动创建技术债记录并设置负责人、到期日和阻断规则

19. 缺少“完成”的统一定义 | “status: done” | worker 的 done、模块验收通过、Phase 完成、任务交付之间没有统一 Definition of Done | 分层定义完成条件及所需证据

20. 缺少流程自身的版本迁移机制 | “状态持久化…支持断点续传” | 运行中升级文档、prompt、schema 或 Code 层时，旧任务如何恢复没有说明 | 增加流程版本固定、数据库迁移和旧任务兼容策略

---

## 【与其他部分冲突】

1. “规则全部外置”与领导 Prompt 内大量硬规则冲突 | “检查规则全部外置” / “并行前必须比对…” | Prompt 中仍包含“必须”“不并行”“直接回 Phase 3”等执行规则，并非只保留启发式判断 | 明确哪些是启发式、哪些是 Code 层强制；硬规则从 Prompt 中移除或承认其双重实现并规定一致性测试

2. “无需记忆数量限制”与 Prompt 写死数量冲突 | “你不需要记忆任何数量限制” / “复杂：3 并行上限” | 同一 Prompt 明确包含 `3` 和 `max_workers`，仍要求模型记忆数量限制 | 数量只从运行时配置注入或仅由 Code 层执行

3. 领导“不执行”与其维护并提交契约的职责冲突 | “拆解/路由/跟踪/综合（不执行）” / “领导维护统一的接口契约文档” | 维护契约属于产生和修改项目资产，不是纯调度；第十一节又称契约由人类或模型生成并 Commit | 指定独立契约 owner，明确领导仅引用、提议还是有权修改

4. 契约生成阶段前后不一致 | “Phase 4：接口契约下发” / “Phase 2 生成并 Commit” | 一处表现为 Phase 4 才维护下发，另一处要求 Phase 2 已生成；Phase 3 又要求引用契约条目 | 固定契约首次生成、审批、冻结和下发的唯一阶段

5. 客观验收原则与主观验收路径冲突 | “验收者不靠主观判断” / “主观任务…双 Reviewer 独立判定” | 后者承认部分任务必须主观判断，前者却表述为绝对原则 | 将原则限定为“尽量可验证”，并为主观项定义独立评审量表

6. “空 blocking 不等于通过”与“空报告无效”不一致 | “不自动等于通过” / “判定无效，转 Checkpoint ③” | 前者只是说不能仅凭空数组通过，后者直接把任何空数组判无效，处理强度不同 | 统一为基于 checklist 和证据完整性的判定

7. L3 出口与逃生舱序列重复且边界不清 | “顾问模式后仍失败…升级 L3” / “L3…顾问模式” | 顾问模式已在 L2 用尽后，L3 又可以再次选择顾问模式，没有说明第二次有何不同 | 区分 L2 顾问与 L3 顾问的权限、人员或目标，或禁止无变化地重复选择

8. “自动第 2 次重写禁止”与“人工可授权第 2 次”表述易冲突 | “禁止自动第 2 次重写” / “人工批准可授权第 2 次” | 若只读拦截表，容易理解为第 2 次完全禁止；权限边界分散在两节 | 用单一状态机明确：自动额度、人工额度、累计额度及触发条件

9. Brief 重写计数口径与 Code 层表述不一致 | “brief_rewrite 仅统计 L1 触发” / “覆盖性缺口…直接回 Phase 3 补 brief” | 两者都发生 Phase 3 修改，但一个叫重写、一个叫补缺且不计数，机器上没有定义区分标准 | 定义操作类型字段和判定主体，防止把实质重写伪装成覆盖补缺

10. Worker 分类数量与起步配置不一致 | “Worker 分类（6 类）” / “起步 3 个（code-reviewer / test-runner / debugger）” | 六类中没有名为 `code-reviewer` 的类型，`debugger` 又不是表内正式类型；同时起步配置缺少明确 builder | 统一类型注册表、别名和起步启用集合

11. Reviewer 的工具约束前后命名不一致 | “reviewer 无写权限（Bash 白名单）” / “Read, Grep, Glob + Bash 白名单” | 两处未说明 Bash 白名单是否保证只读；许多 Bash 命令可间接修改文件 | 给出实际命令白名单及文件系统只读隔离，不能只靠角色描述

12. “完整测试每轮重跑”与调用硬上限可能冲突 | “修复轮次后必须重跑全量” / “maxtoolcallsperworker=15” | 大型项目完整测试可能需要分片、重试和日志分析，15 次工具调用可能无法完成；没有优先级或豁免 | 让 test-runner 单独计费，或按任务规模配置上限并保留硬总预算

13. 高腐化区字段名不一致 | “maxladderlevel”“escapehatchesused” / “max_ladder_level”“escape_hatches_used” | 数据表字段与读取字段不一致，按文档实现会查询失败 | 统一数据库列名并提供迁移和 schema 校验

14. 修订记录称“五分类”，正文只列三类 | “失败类型五分类” / “三类不计入阶梯的失败” | 不确定另外两类是否已删除、遗漏或仍被实现依赖，版本记录与现行规范不一致 | 标明废弃项或恢复完整分类，修订记录不能代替当前定义

15. “类型检查让 LLM 彻底退出契约对齐”与行为层契约冲突 | “编译器/类型检查器执行…LLM 彻底退出” / “行为层…写成 CI 测试” | 编译器只能覆盖类型层，无法完成 TTL、轮换等行为契约对齐 | 将 Phase 6 对齐拆为类型检查和行为测试，并分别定义执行者

16. “最强推理档验收不降”与起步期统一主力档冲突 | “起步期：全部统一用主力档” / “最强推理档：架构、安全、验收，不降” | 不清楚起步期安全和验收究竟使用主力档还是最强推理档 | 明确起步期是否存在风险任务例外

17. Phase 1 示例时间盒超出正文范围 | “基础设施…25-30%” / “时间盒 28%” | 数值本身在范围内，但未说明示例中的基数；与正文同样不可计算，不能作为可执行示范 | 在示例中给出总预算及对应小时或 token

18. “交付五样”与示例最终“四件套”不对应 | “产出五样” / “交付四件套” | 前者是需求阶段产物，后者是最终交付物，层级可能不同；但文中没有明确区分，容易误认为验收项或日志包被遗漏，属“不确定” | 明确阶段产物与客户交付物的不同清单及映射关系

---

## 框架级问题

1. 框架把“多 Agent 协作”过度建模为线性瀑布流程 | 当前以 Phase -1 至 Phase 6 为主轴，但契约发现、模块切分、测试设计和实现通常需要迭代反馈 | 一旦 Phase 2 或 Phase 0 假设在实现中被证伪，只能借“失败阶梯”绕回，导致正常需求学习被误判为失败 | 应补充受控迭代环，而不是把所有回退都纳入故障治理

2. 失败阶梯把错误指纹当成核心控制变量，层级选错 | 指纹只能描述表面失败信号，不能可靠推出 Brief、模块或架构层面的根因 | 当前 L1/L2/L3 的因果映射会把分类准确率问题放大成重写、技术债或人工升级决策 | 应以“证据化根因 + 风险等级 + 可逆性”为主轴，指纹只用于去重和关联

3. 契约被赋予了超出其能力的中心地位 | 文档假定类型契约、生成测试和编译检查可以基本阻断契约漂移 | 大量业务语义、性能、安全、状态机和跨服务约束无法由 TS/Protobuf/OpenAPI 自动推导 | 应明确契约体系的覆盖边界，并保留人工设计、模型检查和运行时验证的多层保障

4. Code 层与 Prompt 层并未形成真正单一事实源 | 同一规则同时存在于正文、领导 Prompt、Code 层表格、Checkpoint 和附录示例中 | 版本演进后极易出现当前文档已经暴露的字段、数量、阶段和状态不一致 | 应把可执行规则收敛成版本化 schema