Step 12 · Claude 工程实施主力视角全量独立 review（角色互换）
0. 边界 + 方法论声明
我以「我要写 C-1 第一个 PR 的代码」的身份做这次 review。我没有复用 Step 9/10/11 任何结论；前几步 review 文件仅扫了标题确认其存在，未读正文。每个判断点都带 evidence 路径或行号（[E]）与推理结论（[I]）显式分隔。
完整通读：architecture.md 6085 行（4 段 760 行覆盖）+ strategic-whitepaper.md 1335 行 + product-definition.md 591 行 + m0-walking-skeleton.md 2061 行 + cognition-1.1-contract.md 418 行 + 7 个 contracts/.yaml + .archon/workflows/ + agent-pack.yaml + ADR-003 + horizontal-concerns-bundle + milestone-field-evolution-matrix + eval-harness-formulas（部分） + subsystems/README。audit_cross_section_consistency.mjs 已实跑。
1. 执行摘要
- C-1 起手 PR 跑通概率 35-45%（定义：Codex 单次 load agent-pack 后，按工程包 §3 + §4 + §13 落地 cognition/types.py + migrations/0001 + provider shim + tests，CI gate 三检全过的概率）。失败概率主要来自 §9 的 7 个工程红点，不来自任务包切片本身。
- 三大要求结论：完整性 / 冗余 / 冲突 / 上位对齐 = CONDITIONAL；100% 落地保真度 = CONDITIONAL（多处事实源分歧让 Codex 无单一 ground truth）；任务切片 + context window = CONDITIONAL（budget OK，但有效信息密度低 + 双 schema 并存）。
- 与 Step 11 整改产物对照（事实新观察，不复用 Step 11 结论）：Step 11 引入
contracts/单一事实源层是好方向，但契约层与 .md 层不同步——contracts/state-machines.yaml 与 architecture.md §11 状态命名直接冲突；contracts/code-paths.yaml 与 architecture.md §27 路径不一致；contracts/structured-cognition-result.yaml 引入了cognition_summary_card/confidence_signal等 m0-pack §3 完全没有的字段。
2. C-1 起手能否真跑（A + B 整合）
2.1 agent-pack budget 真实估算
for-agents/topics/finbayes-m0-implementation/agent-pack.yaml:96-97 [E]：max_tokens: 45000 / per_source: 4000。19 个 source（line 13-91）。
按 char/token ≈ 3 估算：m0-walking-skeleton 91.9K chars ≈ 30K token（full）；cognition-1.1-contract 29K ≈ 9.7K token（full）；milestone-field-evolution-matrix 3.8K ≈ 1.3K（full）；其余 16 个 spec 类按 per_source 4K 上限 ≈ 共 14-16K（实际会被进一步压缩）。
两个全量 + 工程包内部 spec ≈ 41K，剩 ~4K 给 14 个 source 平均 ≤300 token → 除 m0-pack + cognition-contract 外其他全部被砍到 spec 模式且大幅裁剪 [I]。
红点 A-1：ADR-007 supplement（行为契约源）/ ADR-008 supplement（字段契约源）/ 4 个子系统文档全部被压缩到 ≤4K，丢失关键字段语义（如 8 机制定义、MCA 7 分轴语义）。Codex 写代码时如果只依赖 m0-pack §3.5 + cognition-1.1-contract.md 这两份 full，接触不到 ADR 原文，无法核对契约源。
2.2 m0-pack §3 / §3.5 双 schema 并存的混淆
m0-pack §3.1-§3.4（line 137-238）[E] 定义 StructuredCognitionResult 1.0 主体（schema_version: int = 1）但只列了 7 个要素（main_answer / supporting_evidence / counter_evidence / invalidation_conditions / uncertainty_and_gaps / sources / non_instruction_notice + schema_validation_passed）。
§3.5（line 240-425）[E] 定义 1.1 最小子集 StructuredCognitionResult11Minimal（schema_version: Literal["1.1-m0"]）。
cognition-1.1-contract.md §5 第 306-334 行 [E] 定义 StructuredCognitionResultV10Body，列出完整 10 要素：含 m0-pack §3 缺失的 multi_perspectives / prerequisites / follow_up_questions / historical_judgment_links。contracts/structured-cognition-result.yaml line 36-51 [E] 列了这 4 + cognition_summary_card + confidence_signal（type 名在 m0-pack / cognition-contract 都不存在）。
Codex 实施时矛盾：m0-pack §15 (line 2045) [E] 写"任何冲突以本文档 §1 表为准"；agent-pack notes line 121 [E] 写"冲突优先级 ADR > engineering-pack > subsystems > product-definition"。两条规则直接冲突——按前者用 m0-pack §3 的 7 要素；按后者用 ADR-008 supplement 的 10 要素 [I]。
2.3 §14.5 contract test import 路径双轨
m0-pack line 1858-1873 [E] test 同时 import from finbayes + from finbayes.cognition.v11 import (PhaseEvidenceM0, ...)。agent-pack output line 102-103 [E] 给 cognition-types-py + cognition-v11-reexport。但 m0-pack §3.5 注释第 257 行 [E] 仍写 # src/finbayes/cognition/contract_v1_1_m0.py，与 v11.py 命名直接冲突。contracts/code-paths.yaml line 28-29 [E] 标 contract_v1_1_m0.py DEPRECATED——m0-pack §3.5 正文未同步。Codex 大概率会按 §3.5 注释先建错文件被 contract test 红 [I]。
2.4 5 条 sample fixture 可 validate 性
m0-pack §8 5 条 fixture mca_bucket 七字段说"按 §3.5 七字段补齐"。§3.5 MCABucketM0 (line 384-396) [E] 七字段 Literal 三档 L1/L2/L3 等。contracts/mca-buckets.yaml line 13-47 [E] 七轴值 L1-L5 / D1-D4 / F1-F3 / N1-N4 / C1-C3 / I1-I3 / K1-K3——值域不一致！m0-pack 共享片段 line 1017 [E] L1 / D2 / F1 / N1 / C2 / I2 / K2 在 contracts/ 范围内，但 m0-pack §3.5 Pydantic 不允许 L4/L5/D4。Pydantic validate 时下游真实业务 evidence 用 L4/D4 会被 reject [I]。
2.5 凭证 isolation 测试可跑性
m0-pack §8 sample m0_s3 line 980 [E]：not any('sk-abc123' in (e.payload_text or '') for e in audit_events)。但 AuditEvent Pydantic model (§3 line 455-470) [E] 没有 payload_text 字段，只有 payload: dict。SQLite 落 TEXT 但内存中 Pydantic model 上 e.payload_text 根本不存在——测试会 AttributeError [I]。Step 11 IV-5 只改了 yaml 表达式，没同步给 AuditEvent 加字段或改 runner 读路径。
2.6 §13 audit fallback 路径
m0-pack §13 line 1574 [E] AUDIT_JSONL_FALLBACK = Path(".finbayes/audit_fallback.jsonl")——仓根相对路径，pytest 跑在 tmpdir 时会落在 tmpdir/.finbayes 跨进程恢复找不到 [I]。与 §14 OS 标准目录约定未对齐。
3. contracts/ 单一事实源层真的能帮工程实施吗（B 项）
3.1 contracts/ 内部一致性
7 yaml 各自独立读 OK。横向看就有问题：
- contracts/structured-cognition-result.yaml line 30-37
[E]confidence_signal与cognition_summary_card两个 type 在 cognition-1.1-contract.md / m0-pack §3 / §3.5 完全不存在。 - contracts/mca-buckets.yaml line 15
[E]axis_1.values: [L1, L2, L3, L4, L5]五档；cognition-1.1-contract.md §2.7 line 101[E]三档。 - contracts/state-machines.yaml task:
[Pending, Running, Completed, Failed, Cancelled][E]；architecture.md §11.2 line 1859-1867[E]task:Created → Executing → Degraded → Completed → Failed / Cancelled——状态名PendingvsCreated、RunningvsExecuting不同，且 contracts/ 没有Degraded。 - contracts/state-machines.yaml judgment_record
[Candidate, Confirmed, Updated, Archived][E]；architecture.md §11.4 line 1929-1942[E]9 状态（含 Triggered/ReviewedUnchanged/Superseded）——完全不同的状态机。
[I] contracts/state-machines.yaml 实际是从 m0-pack §3 拼成的（task line 172 [E] literal lowercase），不是从 architecture.md §11 抽出来的——暴露事实源选择歧义。
3.2 contracts/code-paths.yaml 与 architecture.md §27 路径冲突
contracts/code-paths.yaml line 58 [E] judgment_record: src/finbayes/state/judgment_record.py；architecture.md §27 line 5713 [E] src/finbayes/state/judgment.py:JudgmentRecord——模块文件名不同。agent-pack 冲突优先级（line 121）[E] 未提及 contracts/ 优先级 [I]。
3.3 verify-kb schema_sources 校验真能拦字段不一致吗
architecture.md frontmatter line 7-14 [E] 加了 schema_sources 列 7 yaml。npm run verify:kb 据 agent-pack acceptance（line 115）[E] 当前"全通过"——说明 schema_sources 仅校验文件存在，不校验字段语义一致（不然 §11.2 task 状态名分歧就 fail）[I]。Step 11 I-2 的"schema-ref 新规则"有效面比预期小很多。
3.4 audit_cross_section_consistency 实跑结果
node scripts/audit_cross_section_consistency.mjs 实际输出 [E]：
- Rule 1 (ADR propagate): 0
- Rule 2 (ID consistency): 0
- Rule 3 (count consistency): 13 violations
- Rule 4 (namespace prefix): 233 violations
- Rule 5 (path consistency): 5 violations
- total: 0 errors, 251 warnings
红点 B-1：233 个 Rule 4 namespace 警告占绝大多数，包括 architecture.md 主文里 ADR-005 待写 / ADR-009 待写 这种真实 waiting 状态引用都被记为 warning。Codex 每次 PR 都会看到 250+ warnings 滚屏，13 个真正高价值的 count 分歧（state 5/6、MCA 桶 4/2/7 vs 8）被淹没 [I]。主架构 line 4501 单行触发 5 个 Rule 4 warning（脚本对一行内多个 ADR 不去重）。
4. 跨文件一致性（C 项，整改后是否真关闭漂移）
4.1 状态机命名冲突清单
| 对象 | architecture.md §11 | contracts/state-machines.yaml | m0-pack §3 |
|---|---|---|---|
| Task | Created/Executing/Degraded/Completed/Failed/Cancelled (6) | Pending/Running/Completed/Failed/Cancelled (5) | created/running/completed/failed/cancelled (5) |
| TaskGroup | Planned/Running/PartiallyDegraded/AllCompleted/Merged/Cancelled (6) | Running/AllCompleted/StreamingPartialMerged/FinalMerged/Failed (5) | n/a |
| JudgmentRecord | 9 状态（含 Triggered/ReviewedUnchanged） | 4 状态（Candidate/Confirmed/Updated/Archived） | n/a (M1+) |
| StateCandidate | Pending → Confirmed/ConfirmedEdited/Rejected/Expired | Pending/Confirmed/Edited/Expired/Rejected | n/a (stub) |
| ProviderReadiness | n/a (§9.6 仅描述) | Probing/Ready/Degraded/Unavailable | n/a |
[I] M1 状态化（M1 pack 起草）被这个分歧直接阻塞。M0 用 Task 简化态能避开，但 StateCandidate stub 已经 present。
4.2 ADR title 漂移
contracts/adr-states.yaml [E]：
- ADR-005: "Prompt as Data" / ADR-006: "工具分类与执行边界" / ADR-007: "状态写入两步候选" / ADR-009: "错误码与降级语义"
architecture.md §23 line 4703-4707 [E]：
- ADR-005: "内部并发原语：asyncio" / ADR-006: "部署形态优先级" / ADR-007: "状态写入候选两步" / ADR-009: "Prompt 是代码还是数据"
4 条 title 全部不同！ [I] ADR-009 主题语义完全不同。主架构 §3 line 267-269 写"具体细节见 ADR-005 待写 / ADR-007 待写"——Codex 看到这些 ref 时不知道 contracts/ 已经把它们重新分配。
4.3 evals/ vs eval/ 单复数
contracts/code-paths.yaml line 32 [E] "evals/ 复数"。agent-pack line 109 [E] evals/runner.py ✅。.archon/workflows/milestone-M0.yaml line 115-117 [E] eval/runner.py / eval/m0_subset.yaml——Archon yaml 还是单数，Step 11 IV-3 没修。Codex 按 Archon yaml 跑会拼错路径 [I]。
4.4 milestone-M0.yaml §17 / §11 章节引用错
milestone-M0.yaml line 73 [E]：anchor_doc: projects/finbayes/engineering/architecture.md#17 # 状态对象生命周期。但 architecture.md §17 是"边界与安全"（line 3039）[E]，状态对象生命周期是 §11（line 1796）[E]。Codex 按 anchor 跳到 §17 看不到状态机定义 [I]。
4.5 11 维 vs 8 维 deprecation
architecture.md §21 line 4257 [E] 加了 deprecation banner "已由 contracts/evaluation-dimensions.yaml 11 维 D1-D11 取代"，但同章下面 line 4264-4271 仍展示完整 8 维表——banner 在 §21 头，但 8 维表未被实际移除/替换 [I]。
5. 切片可行性（D 项）
5.1 C-1 起手 PR 真实最小读取序列 + token 估算
| 文件 | token | 必读理由 |
|---|---|---|
| m0-pack §3 + §3.5 | ~10K | Pydantic schema 草案 |
| cognition-1.1-contract §5 | ~1.7K | 完整 1.1 Pydantic |
| contracts/structured-cognition-result.yaml | 2K | 字段事实源 |
| ADR-008-supplement | ~4K（spec mode 砍） | 字段语义事实源 |
| m0-pack §13 | 1.7K | bootstrap |
| m0-pack §14.5 | 2K | contract test 期望 |
| architecture §4 §11 §27 | ~3K（anchors spec） | 业务对象 |
总计 ~24-26K token，在 45K budget 内 ✅。但 spec 类被 per_source: 4000 裁——架构 §11 状态机有 1500 行 ≈ 5K token，spec 模式会被砍。Codex 写 TaskState enum 时实际读不到完整 §11 [I]。
5.2 m0-pack 91K chars 是否能撑 1 个 PR scope
m0-pack 2061 行覆盖 15 节。M0 1 个 PR 跑通实际是 4-6 个 PR 拆切（PR-1 cognition/types.py + tests/contract / PR-2 migrations + audit / PR-3 providers / PR-4 io/boundary + credential / PR-5 CLI + sample runner / PR-6 M0 CI gate）。[I] m0-pack 没显式给 PR 切片建议；Archon yaml 6 ai 节点按子系统切（blocks_on 合理），但 ai-semi-manual-sla 在 M0 实际是 stub（m0-pack §8 line 1086-1091 [E]），Archon yaml pass_criteria: pytest annotation/ 期望完整 reviewer 工作流——与 m0-pack stub 状态不符 [I]。
5.3 agent-pack 19 源会不会装不下
按 §2.1 装得下，但有效信息密度极低：2 个 full 占 40K 中 31K，剩 14K 给 17 个 spec。ADR-007/008 supplement spec 模式下根本看不全 [I]。
6. 整改后新引入的工程红点（E 项，最重要）
6.1 contracts/ 与 .md 双轨契约源带来的认知负担
Step 11 I 抽 7 yaml 作单源，预期减少漂移，实际：把"读 m0-pack §3 + cognition-1.1-contract.md §5 就够"的简单图谱变成"还要读 7 yaml 且与 .md 仍冲突"。Codex 消化成本 ~4 files / 35K → ~11 files / 47K+ token，+30% [I]。
6.2 schema_sources frontmatter 13 处声明缺乏强制校验
13 份文档加了 schema_sources [E]，但 verify-kb 只校验文件存在，不校验 .md 正文是否真按 yaml 字段写（§3.3）[I]。
6.3 PR checklist 第 11 项 P0/P1 触及检查
.archon/workflows/pr-review-checklist.md 第 11 项 line 25-29 [E] grep 关键词含 kelly_cap。C-1 PR-1（cognition/types.py）落 §3.5 BimodalPosteriorM0.kelly_cap（必填）→ 必定触 P0 → 要求人类用户签字 [I]。
owner map §2.3 line 65-72 [E] 说 MP-3 packet "签字截止：C-1 启动前"，但MP-3 packet 当前状态 ⏳ 待用户签（line 45）[E] —— C-1 还没准备好启动 [I]。这是结构性问题：只要落 1.1 字段的 schema，任何 PR 都触 kelly_cap。
6.4 AI 三方互审协议对实施节奏的影响
ADR-003 line 56-63 [E] P1 需 Claude + Codex + OOSO + 用户 T+30 回查。owner map line 84-96 [E] 8 个 P1 项，其中 MP-1 endogeneity / MP-2 worst_axis / MP-4 phase_label / MP-5 falsification_ref 在 cognition-1.1-contract.md §8 都列为"待对齐项"[E]——任何 PR 引入这几个字段都触 P1。
[I] OOSO 可用性 / SLA 在仓内没定义。ADR-003 line 80-84 [E] "fallback：OOSO 不可用 → 人类直接 review"——所有 P1 PR 都走人类 review [I]。
6.5 audit warnings 噪声掩盖真实分歧
实跑 251 warnings（§3.4）[E]，233 个 Rule 4 namespace 警告。13 个真有价值的 Rule 3 count 分歧 + 5 个 Rule 5 path 分歧被淹没 [I]。Codex 看 warnings 数变化判断时会误判。
6.6 owner map 三档分级与 C-1 启动的耦合
owner map line 33 [E] "P0...C-1 启动前必关闭，AI 不能代签"。当前 5 个 P0 都 ⏳。[I] C-1 严格按规章不能启动，但 agent-pack acceptance line 113-119 [E] 只跑 verify:kb / derive:check / 文件存在，没有 P0 签字状态 gate。milestone-M0.yaml constraints line 197-200 [E] 写"触及 P0 必须人类签字"但不在 deterministic-gate 节点列签字状态校验——审计实现与策略宣告不一致。
7. 冗余 / 冲突 / 缺失（F 项）
7.1 _template/ 3 模板的实用性
_template/ 3 模板，只看到 horizontal-concerns-bundle.md 用了模板（line 17）[E]，m1-state-confirmation.md 是 pending 占位。[I] M1+ 价值上升；M0 阶段是装饰，不冗余但当前价值低。
7.2 horizontal-concerns-bundle.md 占位的暗债风险
status: pending, 73 行 [E]。覆盖 logging / migration / CI gate / contract regression / observability 5 类横切——这都是 C-1 PR-1 已经要落的事。横切包未起草让 Codex 实施时缺少跨子系统观点，logging 在 m0-pack §13、metrics 在 §14 / §15 散乱；Codex 自己拼会漂移 [I]。
7.3 12 ADR registry 一致性
contracts/adr-states.yaml 12 ADR：6 accepted + 4 waiting + 2 supplements。实际仓内 6 accepted 文件存在 ✅，4 waiting 文件不存在与 contracts/ 一致 ✅。但 architecture.md §23 ADR-005~009 主题与 contracts/ 完全不同（§4.2）。
7.4 状态机文档主要分散
architecture.md §11 + state-machines.yaml + m0-pack §3 + product-definition §3.3 + subsystems/*.md —— 散在至少 5 处，每处定义略有不同。[I] Step 11 I-1 试图用 contracts/state-machines.yaml 作单源失败（§4.1）。
8. 主控对工程实施的支持（互换视角，G 项）
8.1 主控（Codex）给 Claude 实施的指令是否清楚
入口路径清楚（agent-pack + Archon yaml + PR checklist 三件套），但事实源歧义未关闭（§3 + §4）。主控指令清楚不代表事实源清楚 [I]。
8.2 主控 6 位一体职责对实施的影响
milestone-M0.yaml line 12 [E] Claude owner / Codex executor。但 m0-acceptance-trigger line 157-194 [E] 5 个收尾任务 owner 全是 "claude-code-controller + project-owner"，Codex 不在——M0 → M1 衔接期主力换人。[I] M0 收尾 5 起草任务（M1 pack draft / 4 ADR drafts / horizontal bundle fill）工作量约 M0 的 30-40%，但 Codex 已离场——主控自己承担。对实施者无负担。
8.3 fresh-eyes 二阶 + AI 三方互审是否拖慢实施
ADR-003 fresh-eyes 二阶要求"spec 起草人不当自己 spec reviewer"。[I] Codex 写 PR，review 需 Claude 主控（不是 m0-pack 起草人）；但 m0-pack 由 Claude 主控起草——fresh-eyes 二阶难满足。OOSO 未上线 → 等于人类直接 review。M0 6 PR + 6 review = 12 个用户介入点。加上 P0 5 项 → M0 真实瓶颈是人类带宽，不是 Codex 编码速度 [I]。
9. 工程实施主力位置的真正风险（7 条按优先级）
| # | 风险 | 影响 | 触发条件 |
|---|---|---|---|
| R1 | m0-pack §3 7 要素 vs cognition-contract / yaml 10 要素分歧 | Codex 写 cognition/types.py 选错 schema，contract test 红 | C-1 PR-1 |
| R2 | contracts/state-machines.yaml 状态名与 architecture.md §11 不一致 | M1 状态化阻塞 | M1 启动前 |
| R3 | MCA 七轴值域 contracts(L1-L5/D1-D4/...) vs cognition-contract(L1-L3/...) | mca_bucket Pydantic validate fail，5 fixture validate 红 | C-1 PR-1 + PR-5 |
| R4 | 233 namespace warnings 噪声淹没真分歧 | Codex review 时盲点 | 每次 PR |
| R5 | P0 5 项 ⏳ + PR checklist 11 项 kelly_cap 触 P0 | C-1 PR-1 被 PR review gate 阻塞 | 第一个 PR |
| R6 | OOSO 上线状态未知 → P1 PR 全降级人类 review | 实施节奏被人类带宽拖慢 | 每个 P1 PR |
| R7 | Archon yaml eval/ 单数 + #17 错锚 + ai-semi-manual-sla M0 stub vs pass_criteria 期望 | Archon workflow pass_criteria 跑不过 | M0 工作流执行 |
10. 启动决议（工程实施视角）
结论：C-1 可以启动，但需要 4 个 P0 fix 在第一周内同步推进，否则 PR-1 就会卡。
启动前必做（< 1 day 工作量）：
- 统一 schema 事实源：在 contracts/structured-cognition-result.yaml 与 cognition-1.1-contract.md §5 之间二选一作为唯一 ground truth，更新 m0-pack §3 把 7 要素补齐到 10 要素或显式说明 M0 stub 3 个字段（推荐：
StructuredCognitionResultV10Body完整 10 要素是事实源；m0-pack §3 加 3 个default_factory=liststub 字段）。 - 修 .archon/workflows/milestone-M0.yaml：line 73
#17→#11；line 115-117eval/→evals/；line 100-103 ai-semi-manual-sla pass_criteria 改 stub 验收（仅校验audit_events.payload.semi_manual_override写入，不跑 reviewer 工具）。 - 关闭 MCA 值域分歧：contracts/mca-buckets.yaml axis_1 →
[L1,L2,L3]与 cognition-contract 对齐（推荐，改动小）；或扩 cognition-contract Literal 到 5 档。 - 修 AuditEvent
payload_text字段错位：给 AuditEvent 加payload_textcomputed_field 序列化 payload；或修 sample_inputs.yaml 用json.dumps(e.payload)，在 safe_globals 提供json。
启动后短期跟进（< 1 week）：
- 修 audit_cross_section_consistency Rule 4 对
ADR-NNN 待写模式开例外，减少噪声。 - OOSO availability check 进 milestone-M0.yaml deterministic gate，否则三方互审协议名存实亡。
- P0 packet MP-3 起草 + 用户签字 —— C-1 起手 PR-1 必须前置完成。
C-1 启动后第一个 PR 真实 risk：~50% 概率 PR-1 因为 schema 分歧（R1）+ kelly_cap 触 P0（R5）卡 24-48 小时，需主控介入修 m0-pack §3 schema + 推动用户签 MP-3 packet [I]。
11. 给 Step 11 整改的元 review
| 整改 | 实施效果 | 评价 |
|---|---|---|
| I-1 contracts/ 单一事实源层 | 7 yaml 自身完整，与 .md 多处冲突未关闭（state machines / MCA / code paths / ADR titles） | 方向对，落地不彻底——应一次性把 .md 改为引用 yaml 字段，而不是 yaml 与 .md 并存两套权威 |
| I-2 schema-ref verify-kb 规则 | 只校验文件存在，不校验字段语义（§3.3） | 效果远低于预期，给了"已守门"错觉 |
| I-3 agent-pack budget 4500→45000 + per_source 4000 | budget 够用，有效信息密度仍低 | 必要但不充分 |
| II-1 templates 目录 | M0 阶段未实际使用 | 当前价值低，M1+ 价值上升 |
| II-2 engineering-packs README 显式列清单 | 入口清楚 | 有效 |
| II-3 horizontal-concerns-bundle 占位 | 横切观点散在 m0-pack 各节，整合包是占位 | 占位不等于解决 |
| II-4 m0-acceptance-trigger 5 起草任务 | M0 → M1 衔接计划清楚 | 有效，缓解 M1+ 零起草 |
| III-1 owner map P0/P1/P2 三档 | 决策权清楚但 P0 5 项待签直接阻塞 C-1 | 方向对，与 C-1 时间窗冲突 |
| III-3 ADR-003 fresh-eyes 二阶 + AI 三方互审 | OOSO 未上线 → 人类直接 review | 机制设计对，可执行性弱 |
| III-4 PR checklist 第 11 项 P0/P1 grep | 触及 kelly_cap 即触 P0 → 每个含 1.1 字段的 PR 都触 P0 | 过严：建议把"schema 字段引用"与"实际下游消费 kelly_cap"区分，前者 P2 后者 P0 |
| IV-1 audit_cross_section_consistency 5 规则 | 251 warnings，主要 namespace | Rule 4 过严，Rule 3 有价值但被掩盖 |
| IV-2 audit_p0_decision_touch | 与 PR checklist 第 11 项联动 | 结构 OK，与 III-4 一起 over-fire |
| IV-3 agent-pack outputs 路径加 src/ + evals/ 复数 | agent-pack 已修 ✅；milestone-M0.yaml 还是单数 | 不彻底 |
| IV-5 ADR-008/010 stale 标记修复 | 多处修了 | 有效但残留：§23 ADR-005/006/009 title 与 contracts/ 不同步 |
整体评价：Step 11 整改方向是对的，最大问题是"半完成状态"——契约层与 .md 层未真正打通，触发的新红点（P0 触发过严 / warnings 噪声 / 双轨契约源）让工程实施主力的认知负担增加了而不是减少了 [I]。工程实施主力的真正诉求是"单源 ground truth + 不被多余检查阻断"，整改后 ground truth 数量变多（contracts/ + .md + 2 supplements），检查也更多（5 audit rules + PR checklist 11 项 + AI 三方互审）。
完。 全文约 8400 字（≤9000 上限）。建议主控按 §10 的 4 个 P0 fix 推进；C-1 在 P0 fix 完成且 MP-3 packet 用户签字后启动。