Step 11 · 综合归纳 + 第一性原理根因 + 整改方案
0. 本报告边界
本报告不是两份独立 review 的合并 synthesis（用户先前明确不要），而是对两份独立 review 共发现的 ~60+ 问题做第一性原理根因分析 + 系统性整改方案设计，最终对齐用户三大 review 要求。
输入：Step 10 两份完整通读 review。 输出：4 个根因 + 4 个整改包 + 3 个用户决策点。 不一个问题一个 patch。
1. 执行摘要
当前状态（cd49b8a baseline）：
- 启动 C-1 的工程实施层"能不能跑代码"层面：58-65%（Codex / 主控视角下界）
- 工程实施层"能不能 100% 达到产品定义+架构所述范围"：M0 范围 85% / M1-M7 范围 40-50%
- 用户三大要求：完整性 / 100% 保真 / 切片可行性都判 CONDITIONAL
核心判断：当前不该启动 C-1，但不该再继续打 patch。前 10 步 review + 8 次修复（17 + 6 + 6 + N 个）证明"问题—修复"循环不收敛 — 每次修完都暴露新问题，原因是根因没被处理。
第一性原理根因：把 60+ 问题压成 4 个深层根因（§3）。
整改方案：4 个整改包（§4），不一个问题一个 patch；完成后启动信心度 → 80%+。
决策点：用户 3 选 1（§7） — 决定整改投入级别。
2. Step 10 两份独立 review 问题汇总（按性质归类，7 个 category）
把 Claude 主控 N1-N10 + Codex C-1 起手 5 红点 + 段 1/2/3 各 3-5 条 + 9 主控风险 + 7 P0 前置 = ~60 个独立问题，按问题性质而非所属章节重新归类。
| Cat | 性质 | 问题数 | 典型代表 |
|---|---|---|---|
| A | 跨文档/跨章节字段漂移 | 14 | StructuredCognitionResult §4 动态组合 vs 1.1 契约固定 10 要素；M0 §3 7 字段 vs contract 10 要素；§11/§27 6 状态机 vs §20/§26 5 状态机；§21 8 维 rubric vs §29 11 维；§27 evals/ vs agent-pack eval/；§6 S1-S9 vs §20 S1-S8 编号错位；MCA M0 固定 B1 vs sample B1/B2 |
| B | 可执行语义陷阱（实施会写错代码） | 8 | §10 S2 失败隔离 vs §12 asyncio.TaskGroup 自动取消；§19 migration Verify→Roll→Continue 失败语义；§17 凭证图"绝不进入审计 trail"易被误读；§13 L3 缓存命中 →LLMOK；§16 MCP 写进 socket 限制；ContextVar trace 传播 stale 描述 |
| C | ADR/契约状态 stale 漂移 | 10 | ADR-008/010 已 accepted 但主架构 4-5 处仍标"待写/待定"；§22 仍把 ADR-004~010 当 7 条待定；§27 写"详见 ADR-008 待"；E4 缓解仍标 ADR-010 待定；M0 pack §15 仍写 ADR-010 待 accepted；ADR-007 引用几乎全部不带 namespace |
| D | 工程化承接断层 | 7 | M1-M7 工程包 0 起草；ADR-005/006/007/009 待写；engineering/README.md 文档清单失修；horizontal-concerns-bundle 待起草；§29 4 子系统未进 §27 代码路径；goal-execution.md deprecated 但仍在 README 阅读顺序 |
| E | 决策权空洞 / AI 自循环签字 | 6 | 27 项 owner map 中 19 项 AI 自循环；MP-3 战略不变量被归"PR audit trail 30 min inline 决议"；DA-1~DA-4 法务 owner"待指定"；主控自己同时是 spec 起草+reviewer+验收人（fresh-eyes 二阶漏洞）；商业承诺与工程实施无验证回路；Phase 5 首季评估 owner 空挂 |
| F | 上下文预算 / 切片不适配 | 6 | agent-pack budget=8000 token vs 实际需要 38-45K；m0-walking-skeleton 单文件 91K；agent-pack anchor "27-认证密钥治理" 错；agent-pack 19 source 1500/source 配置装不下；Archon ai-semi-manual-sla 24h reviewer 超 M0 pack §11.3 边界；C-1 task packet scope 过宽 |
| G | 测试 / 审计闭环不严 | 5 | §6 S2 vs §20 S2 业务编号语义不同；测试 5 状态机 vs §11 6 状态机；§24 风险表 P2 数错 9 vs 11；M0 自动验收只覆盖部分 §26 机械断言；safe eval allowlist 缺 str |
合计 56 个问题，加上若干小问题约 60+。
关键观察：Cat A（跨文档字段漂移）+ Cat C（ADR stale）合计 24 项 / 占 40% — 这两类全部是同一类问题在不同位置反复出现。
3. 第一性原理根因分析（4 个深层根因）
把 60+ 问题穿透到根因层 — 不是每条问题独立成因，而是少数几个结构性问题反复表现。
根因 1 · 单一事实源不存在（解释 Cat A + C = 24 项 / 40%）
现象：同一字段/状态机/枚举/路径在多个 .md 文档中独立定义，各自演化。
实例：
- StructuredCognitionResult 字段定义在 §4 业务对象 / §9 子系统 / cognition-1.1-contract / m0-walking-skeleton / subsystems/eval-harness 五处独立定义 — 五处口径不完全一致
- 状态机数量在 §11 / §20 / §26 / §27 四处独立列举 — 6 / 5 / 5 / 6
- 评估维度在 §21（8 维 rubric） / §29（11 维 EvalHarness） / ADR-007 supplement（11 维）三处独立列举
- 代码路径在 §27 / agent-pack.yaml / m0-pack §2 / subsystems/*.md 四处独立写
为什么会出现：架构主文件最早是"唯一事实源"，但随着 anti-bloat-guard 引入 + engineering-packs 派生 + subsystems 拆出 + topic agent-pack 引入，事实源实质上已经分裂，却没有任何机制锁定"哪一份是 source of truth"，也没有"修改一份自动 propagate 到其他份"的 hook。
深层结构：架构主文件已经从"事实源"退化为"叙述源"，但仓内文档（agent-pack / 工程包）仍把它当"事实源"引用，造成多源同等权威但不同步。
根因 2 · 实施承接是手工劳动（解释 Cat D = 7 项）
现象：M0 之后没有任何文档告诉实施 Agent 怎么进入 M1；ADR-005/006/007/009 待写没有 deterministic 起草时点；engineering-packs 派生靠人工记得。
为什么会出现：主架构 §28 表标"M1-M7 工程包待起草"，但没有触发条件、没有 owner、没有时间表。架构 §23「待写 ADR 段」说"M0 不阻塞，实施 Agent 按当前倾向执行并在 PR 描述标注"— 这等于把"几时把待写 ADR 转 accepted"完全交给随机事件。
深层结构：架构层与工程实施层之间没有"承接生成器"机制 — 每次 milestone/subsystem/ADR 的产物都是单次手工劳动，没有 template + checklist + Archon gate 强制承接。M0 完成后必然出现"无人触发 M1 工程包起草"的真空。
根因 3 · AI 自决策网络无法承担产品立场决策（解释 Cat E = 6 项 / 组织层）
现象：owner map 27 项中 19 项 AI 自循环签字；MP-3 涉及战略不变量"不直接下单"但归"PR audit trail 30 min inline 决议"；法务/数据治理/UX/数据科学家 owner 全部"待指定"。
为什么会出现：FinBayes 当前是单人 + 多 AI agent 协作模式，owner map 起草时没有显式区分"哪些决策 AI 双签可以代偿、哪些必须人类签"。结果默认归"Claude 主控 + Codex 双签"导致 19/27 项 AI 自决策。
深层结构：owner map 没有"决策权分级"。所有 27 项 owner 字段都是平级"双签"，没有区分：
- (a) 战略不变量级：必须人类签字才能启动（如 MP-3 kelly_cap × 不直接下单）
- (b) 合规/法务级：必须真人 owner（即使暂时空缺，必须有提名时间表）
- (c) 工程实施细节级：AI 双签可代偿
主控 fresh-eyes 二阶漏洞（spec 起草人当自己 spec reviewer）也属于这一类 — 不是文档可以修的，是组织决策机制问题。
根因 4 · review 范式与文档复杂度不匹配（解释 Cat F + G + H = 11 项）
现象：抽查 review 在架构主文件 269K / 6057 行规模下问题数低估 1:2.5；verify-kb 只查链接 + glossary，不查跨章节编号/计数/状态一致性；agent-pack budget 8K 与现实 38K 不符；测试编号错位事故位、风险表数错、状态机计数不一致全部抽查发现不了。
为什么会出现：仓内 review 范式假设"抽查覆盖代表整体质量"，verify-kb 只做"形式层"校验（链接通、glossary 同步）不做"内容层"校验（跨章节一致性）。对核心契约文件这个假设破产。
深层结构：仓内有"两道防线"应该挡住跨章节漂移 — verify-kb（机械）+ 人工 review。verify-kb 没做内容一致性检查；人工 review 在文档复杂度超过某阈值（粗估 > 100K chars / > 2000 行）后抽查必失效。两道防线都没覆盖跨章节一致性。
4. 整改方案（4 个整改包，不一个问题一个 patch）
设计原则：每个整改包对应 1 个根因，关闭一片问题而非一条。
整改包 I · 建立 contracts/ 单一事实源层（解决根因 1，关闭 Cat A + C = 24 项）
核心动作：把"跨多份 .md 重复定义的核心 schema"上抽到 contracts/ 目录的 machine-readable source，所有 .md 引用而非重复定义。
最小可行集：
contracts/
structured-cognition-result.yaml # 10 要素 + 6 顶层字段 + Task 元数据
state-machines.yaml # 6 状态机 + 状态枚举 + transition
business-scenarios.yaml # S1-S9 编号 + 任务类型 + 状态变化
evaluation-dimensions.yaml # 11 维 + MCA 7 轴 + 8 label
code-paths.yaml # src/finbayes/* + evals/ + tests/ 路径树
mca-buckets.yaml # 7 轴 + 8 label（B5a/B5b 拆分）
adr-states.yaml # ADR 状态 single source (accepted / waiting / superseded)
配套机制：
- 改
verify-kb：所有 .md 引用 schema 字段/状态/枚举/路径时 → grep 出对应 contracts/*.yaml；不存在则视为 broken reference（fail build） - 改
derive-agent-pack.mjs：agent-pack.yaml 的 source / outputs / anchors 从 contracts/code-paths.yaml 派生 - 改 ADR template：accepted ADR 必须 update contracts/adr-states.yaml 状态字段 + verify-kb hook 自动 grep 全仓"ADR-NNN 待写/待定"残留
- 主架构 §4 / §9 / §21 / §27 / §28 / §29 改为引用 contracts/* 而非重复定义
关闭问题：StructuredCognitionResult 五处不一致 / 状态机 6 vs 5 / 评估维度 8 vs 11 / 代码路径 evals 单复数 / 场景编号错位 / ADR 状态 stale / namespace 不一致
工作量：约 3-5 天（建 contracts/ + 改 verify-kb + 改派生脚本 + 主架构关键段引用化）
整改包 II · 承接生成器 + 工程包模板（解决根因 2，关闭 Cat D = 7 项）
核心动作：把"每个 milestone / subsystem / ADR 的工程包派生"从手工劳动变成 template + Archon gate 强制承接。
最小可行集：
engineering-packs/
_template/
milestone-pack-template.md # 含 §1 范围 / §2 接口子集 / §3 schema / §11 验收 / §14 测试 等 15 节占位
subsystem-pack-template.md # 含 §1 职责 / §2 接口 / §9 里程碑映射 等 9 节占位
README.md # 目录入口，列全部 pack 清单
m1-state-confirmation.md # 用 template 起草，§1-§3 写"待 M0 收尾启动"占位
horizontal-concerns-bundle.md # 同上，覆盖 §18/§19/§20/§26 横切
配套机制：
- 改
.archon/workflows/milestone-MN.yaml：每个 milestone 收尾 gate 强制 trigger "next milestone pack draft 启动" 作为 blocking task；不完成不进入 next milestone - 改
engineering/README.md：文档清单按实际全量列出（4 + 6 packs + 4 subsystems + anti-bloat + owner-map = 16 份）；删除 goal-execution.md 从阅读顺序（仅保留"历史参考"链） - 改 ADR 模板：每个 accepted ADR 必须附"承接 task 清单"（哪些工程包必须引用、哪些代码必须实现）
关闭问题：M1-M7 工程包零起草 / ADR-005/006/007/009 待写无时点 / engineering/README 失修 / horizontal-concerns 缺位 / §29 4 子系统未进 §27 代码路径（自动通过 contracts/code-paths.yaml 闭合）
工作量：约 2-3 天（写 template + 改 Archon + 改 README + 起占位 M1 pack）
整改包 III · 决策权分级 + 真人 owner 时间表（解决根因 3，关闭 Cat E = 6 项）
核心动作：把 owner map 27 项重新分类为 3 档；每档有不同启动条件；空缺 owner 强制提名时间表。
最小可行集：
| 档 | 决策性质 | owner 字段格式 | 启动条件 |
|---|---|---|---|
| P0 战略不变量级 | 涉及战略不变量 / 产品立场 / 合规底线 | 必须含人类用户签字 ID + 签字日期 | C-1 启动前必关闭，AI 不能代签 |
| P1 工程契约级（有外部影响） | 涉及合规 / 用户数据治理 / Provider 接入 / 评测口径 | AI 双签 + "真人 owner 待提名（X 月 X 日前）" | C-1 可启动，但需"真人 owner 招募时间表"标到里程碑日历 |
| P2 工程实施细节级 | 字段语义 / fixture 边界 / 测试断言 / 错误码 | AI 双签即可 | C-1 期间 inline 决议 OK |
27 项重新分类：
- P0（5 项）：MP-3（kelly_cap × 不直接下单）/ DA-1（数据 license）/ DA-2（爬取合规）/ DA-3（跨源仲裁）/ DA-4（历史回填窗口）
- P1（8 项）：MP-1/2/4/5 / DA-5/6 / RX-5（金融专家挑战机制）/ Phase 5 首季评估 owner
- P2（14 项）：其余字段语义/工程细节
真人 owner 招募时间表（写入 owner map + 标到 milestone-MN.yaml 日历）：
- 法务 owner：M1 启动前 2 月（处理 DA-1~DA-4）
- 数据治理 owner：M1 启动前 1 月
- 金融领域专家：M0 期间召集（处理 RX-5 + 8 机制挑战）
- 数据科学家 / 半人工标注 reviewer：T0+2 月前到位（Phase 5 用）
- UX：M1 启动前 1 月
配套机制：
- 改
ADR-003：补 fresh-eyes 二阶原则（"spec 起草人不当自己 spec PR reviewer；至少 1 个 milestone gate 由人类工作流维护者亲自走"） - 加
pr-review-checklist.md第 11 项：每个 PR 必须 grep 是否触及 P0 项；触及 P0 必须 attach 人类签字 audit trail 段 - M1 范围加"商业信号采集任务"承接战略白皮书 §15 商业未决
关闭问题：AI 自循环签字 / MP-3 inline 决议路径 / 法务 owner 待指定 / Phase 5 owner 空挂 / 主控 fresh-eyes 二阶 / 商业承诺无验证回路
工作量：约 1-2 天（重写 owner map + 改 ADR-003 + 加 PR checklist + 写招募时间表）
整改包 IV · 自动校验升级 + review 范式（解决根因 4，关闭 Cat F + G + H = 11 项）
核心动作：verify-kb 加 cross-section consistency 子检查（机械可查的）+ 把"核心契约文件强制完整通读"写入 review 范式 playbook。
最小可行集：
scripts/audit_cross_section_consistency.mjs（verify-kb 子项）：
- ADR 状态 propagate 检查：accepted ADR 在 contracts/adr-states.yaml 中 → grep 全仓所有"ADR-NNN 待写/待定/待 accepted"残留 → fail
- 编号一致性：grep 主架构 + 工程包中所有
S\d+/MP-\d+/DA-\d+/ADR-\d+→ 必须 match contracts/business-scenarios.yaml 等枚举 - 计数一致性：grep "N 个状态机" / "N 维评测" → 必须 match contracts/state-machines.yaml / evaluation-dimensions.yaml count
- namespace prefix 一致性：所有 ADR-{007,008,009} 引用必须带 workstream/ 前缀（contracts/adr-states.yaml namespace 字段）
- 路径一致性：所有
evals//eval//src/finbayes/*引用必须 match contracts/code-paths.yaml
commons/playbooks/document-review-paradigm.md（新增）：
- 核心契约文件（架构主文件 / 产品定义 / cognition-contract / 4 subsystems）强制完整通读，不允许抽查决议启动
- 文档复杂度阈值：> 100K chars / > 2000 行 触发"抽查无效"警告
- 双视角 review 默认两路独立 + 第一性原理 + 不参考前轮
agent-pack budget 修正（属于 Cat F，单独修但归入此包）：
- max_tokens: 8000 → 45000
- cognition-1.1-contract.md include_mode: spec → full
- anchor
"27-认证密钥治理"→"17-边界与安全" - per_source_tokens: 1500 → 4000
关闭问题：跨章节编号错位 / 计数错位 / namespace 不一致 / ADR stale 残留 / agent-pack budget 不符 / anchor 错 / 抽查范式失效
工作量：约 2-4 天（写 audit 脚本 + 写 review playbook + 修 agent-pack）
5. 整改包优先级 + 工作量
| 包 | 解决根因 | 关闭问题数 | 工作量 | 启动信心提升 | P |
|---|---|---|---|---|---|
| III 决策权分级 + 真人 owner | 根因 3 | 6（Cat E） | 1-2 天 | +5-7% | P0 |
| IV 自动校验 + review 范式 | 根因 4 | 11（Cat F+G+H） | 2-4 天 | +8-10% | P0 |
| II 承接生成器 | 根因 2 | 7（Cat D） | 2-3 天 | +5-8% | P1 |
| I contracts/ 单一事实源 | 根因 1 | 24（Cat A+C） | 3-5 天 | +10-15% | P1 |
合计：约 8-14 个工作日；启动信心度 65% → 85%+。
优先级理由：
- III 优先：解决组织层决策权，AI 无法替代，必须先把人类签字路径建好，否则 I/II/IV 都修完了 C-1 启动仍卡在产品立场决议
- IV 紧接：解决 review 范式 + 机械校验，是后面 I/II 工作正确性的"两道防线"，先建好防线再大改 contracts/
- II 第三：解决工程承接断层，但 M1-M7 是 M0 之后的事，M0 启动不阻塞
- I 最后：工作量最大但收益最高；建议作为 M0 期间持续推进任务，T0+30 天前完成
6. 启动决议（pre / post 整改对比）
| 维度 | Pre 整改（当前） | Post 整改（4 包完成） |
|---|---|---|
| Claude 主控启动信心 | 65-68% | 85%+ |
| Codex 起手 PR 跑通概率 | 58% | 78-82% |
| 完整性 / 冗余 / 冲突 | CONDITIONAL（30+ 跨章节漂移） | PASS（contracts/ 锁住） |
| 100% 落地保真度 | M0=85% / M1-M7=40-50% | M0=92% / M1-M7=70%（承接生成器） |
| 切片可行性 | FAIL（agent-pack budget 8K vs 实际 38K） | PASS（agent-pack 修 + horizontal-bundle） |
| AI 自循环签字风险 | 19/27 项 AI 双签 | 降到 14/27（P0 强制人签 + P1 真人 30 天回查） |
| review 范式 | 抽查为主（漏 1:2.5 问题） | 核心文件强制完整通读 + cross-section 机械校验 |
当前不该启动 C-1。完成整改包 III + IV（约 3-6 天）后可启动；I + II 作为 M0 期间持续推进。
7. 给用户的 3 个决策点
决策 7.1 整改投入级别
| 选项 | 投入 | 启动信心 | 风险 |
|---|---|---|---|
| A. 全做 4 包 | 8-14 天 | 85%+ | 启动延后 2 周但 M0 跑通后不返工 |
| B. P0 优先 III+IV，I+II 启动后做 | 3-6 天 | 75-80% | 启动稍快，M0 期间会撞到 M1 承接断层 |
| C. 最小仅 III（决策权）+ IV.agent-pack 修正 | 2-3 天 | 70-72% | 启动最快，但跨章节漂移仍在，每次 PR 都可能撞到 |
推荐 B（P0 优先），理由：III + IV 解决"组织层 + review 范式"两个长期问题，不做 I + II 短期不阻塞 M0 启动，但中期必撞 M1 承接断层 — 不如先启动 M0 再持续推 I + II（已写入 M0 期间动作）。
决策 7.2 contracts/ 单一事实源层是否值得建
整改包 I 是最大工程量（3-5 天）+ 持续维护成本。如果不建：
- 60% 的跨章节漂移问题靠 verify-kb cross-section 子检查捕获（整改包 IV）— 是"事后机械捕获"而非"事前结构禁止"
- 主架构会持续作为"事实源",但实质是叙述源
- 选 B（不建 contracts/）可接受，需要在 M1 启动前评估是否升级
推荐做：投入大但 ROI 高（关闭 24 项 / 40% 问题）。
决策 7.3 主控 fresh-eyes 二阶问题处理
ADR-003 fresh-eyes 原则当前只覆盖"实施者不当自己代码 reviewer"，未覆盖"spec 起草人不当自己 spec reviewer"。主控（我作为 AI）同时承担 spec 起草 + PR review + 验收 6 位一体，是结构性 bias。
| 选项 | 描述 |
|---|---|
| a. 人类用户至少 1 个 milestone gate 亲自走 | 不只签字，亲自 review 关键 PR；主控辅助 |
| b. AI 三方互审（Claude + Codex + 第三个角色如 OOSO） | 解决 fresh-eyes 但仍是 AI 内部互审 |
| c. 接受现状 | 主控自评 + 仓内事实兜底，T0+3 月时由 Phase 5 评估校准 |
推荐 a（人类至少 1 个 milestone gate）— 不能完全靠 AI 内部消化产品立场决策。
8. 元 review · 为什么 10 步 review 没收敛？
诚实反思：前 10 步 + 8 次修复（17 + 6 + 6 + N 个 patch）证明"问题—修复"循环不收敛。原因：
- 前 9 步全部是"问题驱动"而非"根因驱动" — 每次 review 找到 N 个具体问题，每次修复就修这 N 个；下一轮 review 又发现 M 个新问题。从未停下来问"这些问题背后有共同根因吗"。
- 修复都是 patch 级：M0 schema_version 加一个字段、fixture 加一段七轴、agent-pack budget 改一个数字 — 全是"按问题位置打补丁"，没有改变产生问题的结构（多源同等权威没机制 propagate）。
- Step 9/Step 10 才引入"主控视角" — 前 8 步全部在"治理 reviewer + 工程实施"两端，没看到组织层决策权空洞、fresh-eyes 二阶、M1-M7 承接断层 — 这些才是真正的根因。
- 架构主文件抽查决议启动：直到 Step 10 完整通读才暴露 24 项跨章节漂移 — 抽查范式与 6057 行文档复杂度根本不匹配。
给后续工作流的启示（meta-playbook 反馈）：
- review 范式应当显式分两类：第一类"问题驱动 review"（找 N 个问题）；第二类"根因驱动 review"（穿透到结构性根因）。第一类 N+1 轮不收敛时强制切到第二类。
- 复杂文档（> 100K chars）的 review 必须"完整通读"，不允许抽查。
- 主控视角应当前置而非后置：项目启动前就引入"项目负责人视角"判断组织层风险，不要 9 步之后才补。
9. 关联资产
- Step 10 双视角完整 review：
2026-05-28-step10-fresh-claude-master-review.md/2026-05-28-step10-fresh-codex-impl-review.md - 前 9 步 review 全量索引：见
2026-05-28-pre-engineering-readiness.md§6 - 上位事实源：FinBayes 战略白皮书 / product-definition / architecture / ADR-007 supplement / ADR-008 supplement
- 待用户决策后启动：整改包 II 占位 / III 重写 owner map / IV verify-kb 升级