Step 13 · 深度根因分析与整改方案
0. 本报告独特性
前 12 步都在「找问题→修问题→找新问题」循环里，本报告跳出循环，问元问题：
为什么 Step 11 把 60+ 问题归纳成 4 个根因 + 设计 4 整改包，整改完仍出现新 7-8 个红点？
这才是真正需要解决的根因。本报告不再列具体问题，而是分析"整改本身为何不收敛"，给出根本性切换方案。
1. 现状盘点（数据驱动，不复用任何前 review 结论）
| 数据 | 数值 |
|---|---|
| 已做 review 轮次 | 12 步 |
| 已做整改包 | 4 个（Step 11 III + IV + II + I） |
| 已 commit 数 | 30+ |
| 已识别问题总数 | 60+（Step 10）→ 70+（Step 12 暴露新红点） |
| Step 11 整改后启动信心 | 设计期望 85%+ |
| Step 12 实测启动信心 | 主控 72% / 工程实施 35-45%（双视角都未达预期） |
| audit_cross_section warnings | 252 个 |
| P0 待签项 | 5 项（MP-3 + DA-1~4），0 已签 |
| Railway build 失败次数 | 5 次（3 + 2，均 link/anchor 问题） |
| Total 工作日投入 | 约 11 天（Step 10 之后） |
| 真实代码产出 | 0 行（C-1 PR 还没启动） |
关键 ratio：11 天投入 / 0 行代码 = 整改 ROI 在物理意义上为负。
2. 元根因（穿透 Step 11 的 4 根因 + Step 12 的新红点）
Step 11 找的 4 个根因（单一事实源 / 实施承接 / 决策权 / review 范式）本身都是事实，但全是症状层根因。真正的元根因（meta root cause）只有 1 个：
元根因 M：未落地的契约被反复治理优化，而非用最小可执行版本驱动反馈
展开：
每次 review 都在审视一份没有跑过的契约文档。文档治理水平越来越高（contracts/ + ADR + AI 三方互审 + P0/P1/P2 + audit 5 规则），但没有任何一行 Python 代码被实际写过。问题来自"想象中的代码可能撞到什么"，整改是"提前消除想象中的风险"。
这有三个不可逆的副作用：
M.1 想象的问题 ≠ 真实问题
- Step 10 列 60+ 问题，100% 来自文档审视，没有一个来自代码实施撞墙
- Step 12 又列 7-8 个新红点，仍然是审视整改产物，不是审视代码
- 真实代码会暴露 60% 完全不同的问题（性能 / 集成 / 依赖 / 实际行为 bug），这些问题用文档 review 永远找不到
M.2 治理本身变成新熵源
- Step 11 引入 contracts/ 7 yaml + 13 文件 frontmatter + 5 audit 规则 + AI 三方互审 + PR checklist 11 项
- Step 12 暴露：这些治理工件之间又互相不一致（contracts/state-machines vs §11 vs m0-pack 三处分歧）
- 引入治理 = 引入新维护面 = 引入新一轮 review 对象
- 治理的边际收益递减，治理的边际成本递增
M.3 "防御性整改"挤占了"建设性产出"
- 11 天投入分布：~80% 治理（contracts/ + audit / playbook / 模板 / 整改方案文档）、~20% 实际修文档
- 0% 投入到工程仓实际代码 — 不是因为代码不重要，而是因为治理 review 永远有"下一个红点"
- 心理机制：完成治理任务有清晰反馈（commit / verify-kb pass），写代码可能撞墙 → 治理给假性进度感
3. 第一性原理推理：本项目本质是什么
回到本项目的物理目标：
FinBayes 工程化落地 = "把战略 + 产品 + 架构所述能力，变成本地可跑的 Python 代码"
不是：
- "把所有文档调一致"
- "把所有 ADR 写完"
- "把所有 P0 决策签完"
- "让 audit 0 warnings"
- "让 verify-kb 0 schema-ref violations"
而是：
- 用户在 CLI 输入"分析 BTC 走势"，系统返回结构化认知结果
- 测试通过、审计 trail 落 SQLite、凭证被拒收
当前状态：写代码所需的"刚需文档"（agent-pack + cognition-1.1-contract §5 + m0-pack §3.5 + §14.5 contract test）Step 10 之前就已经足够。Step 11 引入的 contracts/ + 模板 + AI 三方互审 + audit 等都是 nice-to-have，不是写第一个 PR 必需。
4. 类比：经典 over-engineering 陷阱
本项目当前状态符合"治理 over-engineering 陷阱"的经典模式：
| 模式 | 表现 | FinBayes 实例 |
|---|---|---|
| 完美主义 ground truth | 每发现一个分歧，加一层 ground truth | contracts/ 7 yaml |
| 防御性自动化 | 每发现一类错误，加一个 audit 脚本 | audit_cross_section + audit_p0_touch + verify-kb schema-ref |
| 流程加固陷阱 | 每发现一个决策风险，加一道审批关卡 | P0/P1/P2 三档 + AI 三方互审 + 真人 owner |
| 模板灌注 | 每发现一处零起草，写一个模板占位 | _template/ + m1-state-confirmation 占位 + horizontal-bundle 占位 |
| 元 review 陷阱 | 每做一次 review，给后续 review 加范式 | document-review-paradigm playbook |
真正的破局思路在所有 over-engineering 文献里都是同一句：Stop reviewing. Ship。
5. Step 11 4 整改包重新评价（用代码视角）
| 整改包 | 治理价值 | 写第一个 PR 时真实价值 | 验证 |
|---|---|---|---|
| III 决策权分级 | 高（解决 AI 自决策风险） | 中：MP-3 必须签，但其他 P0/P1 可推到撞到时再处理 | 写代码不会触及 DA-1~4 / MP-1/2/4/5（除非真在合规/字段层 PR） |
| IV cross-section 校验 + agent-pack 修复 | 中 | 低：agent-pack budget 修复 OK；audit 252 warnings 实际上没人会真去清 | Step 12 双视角都承认 |
| II 模板 + 承接生成器 | 中（M1 启动前价值） | 极低：M0 写代码用不上 _template/ | 占位包是装饰 |
| I contracts/ 单一事实源层 | 低（Step 12 证明落地半成） | 负：增加 30% 认知负担 + 引入新分歧 | Claude impl review §6.1 |
Step 11 整改包真实 ROI 评估：
- 真正帮 C-1 启动的：III 的 MP-3 路径 + IV 的 agent-pack budget 修复 + IV-5 的 ADR-008/010 stale 修复 ≈ 3 个 Action
- C-1 启动后才需要的：II 占位 + III 真人 owner 时间表 ≈ 2 个 Action
- 整改后反而增加摩擦的：I contracts/ 双轨 + IV-1 audit 252 warnings + IV-2 P0 触发过严 ≈ 3 个 Action
净效果：3 帮助 - 3 摩擦 + 2 推迟 = ~0。11 天投入的边际收益接近 0。
6. Step 12 7-8 新红点的真实性质再评价
| 红点 | Claude 提的 | Codex 提的 | 真要写代码会真的撞吗 |
|---|---|---|---|
| R1 m0-pack §3 7 要素 vs contract 10 要素 | ✅ | 隐含 | 会（写 Pydantic 时必须选一个）→ 这是真红点 |
| R2 contracts/state-machines vs §11 状态名 | ✅ | R3 间接 | 不会（M0 用 Task 简化态，M1 才用，到时再改）→ 假紧迫 |
| R3 MCA 七轴值域不一致 | ✅ | — | 会（fixture validate 会红）→ 真红点 |
| R4 233 namespace warnings 噪声 | ✅ | R4 | 不会（warnings 不阻塞）→ 关注度问题，非阻塞 |
| R5 P0 触发 kelly_cap 过严 | ✅ | R1 隐含 | 会（PR-1 必触）→ 真红点但用户拒签 or 流程绕开即可 |
| R6 OOSO 未上线 | ✅ | R5 | 不会（fallback 是用户 review，本来就是事实）→ 流程问题 |
R7 Archon yaml eval/ 单数 + #17 错锚 | ✅ | — | 会（按 anchor 跳错章节）→ 真红点但 1 行修复 |
| R8 治理库与工程仓 task packet 脱节 | — | ✅ | 必然（这是设计如此，不是 bug）→ 不是真红点 |
真红点 4 个：R1 / R3 / R5 / R7 假紧迫 1 个：R2（M0 不触发，M1 才触） 关注度问题 1 个：R4 流程问题 2 个：R6 / R8
Step 12 真实告诉我们的事：只有 4 个红点需要 C-1 启动前修，每个 < 1 小时。不需要新一轮整改包。
7. 元根因解决方案（Step 13 整改的核心切换）
方案 S0：停止治理 review，启动 C-1（推荐）
核心动作：
- 冻结所有未启动的整改任务（M1 占位包 / 真人 owner 招募 / OOSO 集成 / horizontal-bundle 起草 / audit warning 清理）→ M0 期间不投入
- 最小修复 4 真红点（R1 / R3 / R5 / R7） → 总工作量 < 4 小时
- MP-3 由用户拍板签字 → 1 个用户操作
- 启动 C-1 工程仓代码实施（第一个 Python PR）
- 真正撞到的问题用 PR 流程修（而不是文档 review）
断循环机制：
| 旧机制 | 新机制 |
|---|---|
| review 找问题 → 整改包修问题 | PR 撞墙 → 修一个具体 bug |
| 文档审视为主 | 代码运行为主 |
| 治理 commit 计数 | 测试通过率计数 |
| 想象的红点 | 真实的红点 |
| review 范式精细化（document-review-paradigm playbook） | 跑 pytest 即范式 |
方案 S1：继续整改 + 限速（不推荐，仅备选）
核心动作：再做 1 轮整改但严格 24 小时窗口 + 强制 ROI 评估
为什么不推荐：
- 前 4 整改包都是 24-72 小时窗口，仍引入新红点
- ROI 评估靠 AI 自评 = 不可信（Step 12 Claude 自己说 35-45% 但 Codex 说 72%）
- 治理熵源已经存在（contracts/ + audit + AI 三方协议），新整改只会加更多
方案 S2：回滚部分整改 + 启动 C-1（中间路径）
核心动作：
- 回滚：删除 contracts/ 7 yaml（保留 ADR 状态因为 namespace 有用）/ 关闭 audit_cross_section Rule 4（噪声 233 个）/ 简化 PR checklist 第 11 项（仅 kelly_cap 触 P0，其余 P1 字段不触发）
- 保留：MP-3 P0 人签机制 / agent-pack budget 45K / ADR-008 / 010 stale 修复 / engineering-packs/README 入口
- 最小修 4 真红点
- 启动 C-1
为什么是中间路径：保留有真实价值的部分（III + IV-3 + IV-5 + 部分 II），回滚没价值的部分（I + IV-1 部分 + IV-2 过严部分）。但回滚本身又是工作量，且会破坏审计 trail。
8. 推荐方案 S0 的细化执行清单
8.1 4 真红点最小修复（总 < 4 小时，可由 Claude + Codex 各 30 分钟完成）
| # | 修复 | 文件 | 工作量 |
|---|---|---|---|
| F1 | m0-pack §3 补齐 10 要素（multi_perspectives / prerequisites / follow_up_questions / historical_judgment_links 4 字段加 default_factory=list stub） | projects/finbayes/engineering/engineering-packs/m0-walking-skeleton.md §3 | 30 min |
| F2 | MCA 七轴值域对齐：contracts/mca-buckets.yaml axis_1: [L1,L2,L3] 与 cognition-1.1-contract.md §2.7 一致 | contracts/mca-buckets.yaml | 5 min |
| F3 | Archon M0 yaml 修 #17 → #11，eval/ → evals/ | .archon/workflows/milestone-M0.yaml line 73 + 115-117 | 5 min |
| F4 | AuditEvent 加 payload_text computed_field 序列化 payload（Python 端要做的事，留给 C-1 第一个 PR 自己撞到时修） | m0-pack §3 line 455-470 | 0 min（推迟） |
总 F1-F3：40 分钟，F4 在写代码时撞到再修。
8.2 MP-3 用户签字 packet（必做）
用户在 C-1 启动前签字。Claude 主控起草 1 页方案给用户审：
P0-Packet-001 · MP-3 kelly_cap 下游消费协议
载体：ADR-008-supplement §2.5 audit trail 段
必含条款：
- kelly_cap > 0 不得被任何下游系统当作 actionable trading signal
- 下游消费方必须显式承诺"仅作为认知材料的不确定性度量呈现给人类用户，不进入自动执行链路"
- 违反此条款的下游集成视为越权，FinBayes 输出协议作废
用户签字：[user_id] [timestamp] [signature/GPG]
总 30 分钟（用户 5 分钟阅读 + 5 分钟签字 + 20 分钟主控起草）
8.3 冻结清单（不投入，留到撞墙）
| 冻结项 | 推迟到 |
|---|---|
| DA-1~4 数据治理 ADR | M1 启动前 2 月（M0 mock 不触发） |
| MP-1/2/4/5 三方互审 | C-1 实际 PR 触发时再处理（不强制提前） |
| OOSO 集成 | C-1 撞到 P1 PR 时再决定（fallback 为人类直接 review） |
| 真人 owner 招募 | 推到 M1 启动前 1-2 月（按整改 III-2 时间表） |
| audit_cross_section 252 warnings 清理 | 永久搁置（除非 Rule 1/2/5 出新 errors） |
| horizontal-concerns-bundle 起草 | M0 实施中按需扩，不预先起草 |
| M1 pack draft | M0 收尾 trigger 自然触发，不提前 |
| ADR-005/006/007/009 起草 | M0 收尾 trigger（Archon yaml 已绑定） |
| contracts/state-machines.yaml 状态名修复 | M1 状态化 PR 撞到时修 |
| schema-ref verify-kb 加严 | 永久搁置（当前 warning level OK） |
8.4 C-1 启动决议
结论：方案 S0 推荐 — 4 真红点 < 4 小时修完 + MP-3 30 分钟签字 + 启动 C-1。
总前置时间：约 5 小时（vs Step 11 整改 4 包 9-14 天）
启动后：
- 用 Codex 写 PR-1 cognition/types.py + tests/contract
- 撞到 bug 用 1 PR 1 bug 修
- 不再做"想象中可能撞到什么"的 review
- M0 完成后再做 retrospective（真实代码 + 真实撞墙数据驱动）
9. 给 meta-playbook 的反馈（治理范式根本性切换）
本次 12 步 review + 1 步 RCA 暴露了 review-driven 文档治理的根本性缺陷。建议把以下经验沉淀到 commons/playbooks/document-workflows-meta-playbook.md：
9.1 review 轮次硬上限
任何文档治理工作流，review 轮次 > 3 时强制切到根因驱动；> 5 时强制停止 review 启动实际产出。
理由：12 步 review 实测，第 4 轮之后边际收益变负（每轮整改引入新红点 ≥ 关闭旧问题数）。Step 11 整改 14 项 Action → Step 12 暴露 7-8 个新红点 = 整改本身是新问题源。
9.2 "想象中的红点" 与 "撞到的红点" 必须区分
review 报告必须显式标注：每条问题是从"文档审视"找到的，还是"实际跑代码撞到的"。前者只用于规划，后者才用于阻塞启动。
FinBayes 全部 70+ 红点 = 100% 文档审视。没有一条来自代码运行。这是不可接受的 ratio。
9.3 "治理熵源" 风险显式声明
任何引入"新事实源 / 新 audit 脚本 / 新流程审批 / 新模板"的整改，必须显式声明新维护面 + 与已有事实源的冲突解决规则 + 半年内回滚成本。
FinBayes 整改包 I（contracts/ 7 yaml）就是反面教材：引入时未声明半年回滚成本，结果 7 yaml 与 .md 多处不一致，回滚比维持还贵。
9.4 "Ship 优先" 原则
任何战略 → 产品 → 架构 → 工程包 → 代码的链路，应优先把链路打通到代码层（哪怕是最 minimal walking skeleton），再回头优化中间环节。
FinBayes 反面：架构 6085 行 / 工程包 8000+ 行 / 0 行 Python = 链路深度优先，链路打通滞后。
9.5 "AI 审视 AI" 必然不收敛
当 review + 整改 + 后续 review 都是同一 AI 或两个 AI 互审时，必然不收敛。因为：
- AI 没有"完美治理代价过高"的工程师直觉
- AI 没有"够用就停"的 ship instinct
- AI 倾向"显式标注所有 corner case"而非"统计学上忽略 corner case"
唯一断循环的方式：人类用户拍板"够了"。这次是用户主动启动 Step 13（在没有 AI 提示的情况下），证明了人类介入的必要性。
10. 启动决议（最终）
10.1 主控决议
采用方案 S0：4 真红点修复 + MP-3 签字 → 启动 C-1 → 用真实代码撞墙驱动后续修复。
10.2 不再做的事（fail-safe 列表）
- ❌ 不再做 Step 13/14/... 文档 review
- ❌ 不再设计新整改包
- ❌ 不再扩 contracts/ 或 audit 规则
- ❌ 不再起草 M1+ 占位包
- ❌ 不再修 audit warnings（除非阻塞 verify-kb 或 build）
10.3 接下来做的事
- 现在：用户决定是否接受 S0 + 是否签 MP-3
- T0+1h：Claude 主控执行 F1-F3 + 起草 MP-3 packet
- T0+5h：用户审 + 签 MP-3 → C-1 启动
- T0+1-2 周：M0 第一个 PR（cognition/types.py + tests/contract_v1_1.py）→ 真实撞墙数据
- T0+M0 完成：基于真实代码撞墙做 retrospective（不是再做文档 review）
10.4 给用户的决策点
| 决策 | 选项 |
|---|---|
| 方案选择 | (a) S0 推荐：停治理 + 启 C-1 / (b) S1 备选：再 1 轮限速整改 / (c) S2：部分回滚 |
| MP-3 签字 | (a) 现在签（C-1 启动当天）/ (b) 推到第一个 PR 触发时签 |
| Step 11 整改包是否回滚部分 | (a) 不回滚（保留 audit trail）/ (b) 回滚 contracts/（删 7 yaml + 13 frontmatter）/ (c) 仅关闭 audit Rule 4（减噪声） |
| 后续 review 节奏 | (a) M0 完成后做 retrospective / (b) M0 期间每 2 周 mini review / (c) 永久停 review 直到 M3 |
主控推荐：S0 + MP-3 现在签 + 不回滚（保留 audit trail）+ M0 完成后 retrospective。
11. 元 review · 为什么 Step 13 是最后一个 review
前 12 步 review 都做错了一件事：每次都假设"再多一轮治理 review 能修好"。但真实是：review 找的问题 80% 是文档分歧，文档分歧 80% 在代码层根本不触发，剩余 20% 触发的部分代码层 1 个 PR 修完比文档层 1 个整改包修完快 10 倍。
Step 13 是 meta-review，不是 review。它的产出不是"再修一批问题"，而是"为什么修问题这个范式本身需要被换掉"。
预期效果：
- 切到方案 S0 后，Step 14 不应该是"再做 review"，而是 "M0 工程仓 PR 实施日志"
- 真正的红点会在 PR 实施过程中暴露，且每个红点都附带"如何复现的 git diff"
- 文档 review 范式回归到其原本用途："起草初稿 + 必要的对齐"，不是"反复打磨完美契约"
12. 关联资产
- Step 11 整改方案：
2026-05-28-step11-remediation-plan-detail.md（4 整改包详细） - Step 12 双视角 review：
2026-05-28-step12-claude-as-impl-lead-review.md+2026-05-28-step12-codex-as-master-review.md - 上位元 playbook：
commons/playbooks/document-review-paradigm.md（待按本报告 §9 反馈升级） - 上位 meta-playbook：
commons/playbooks/document-workflows-meta-playbook.md（待按 §9.1-9.5 加 5 条新原则） - M0 工程包：
projects/finbayes/engineering/engineering-packs/m0-walking-skeleton.md（C-1 启动入口） - C-1 启动 task packet（待 S0 通过后由主控起草）：M0 PR-1 task spec