Round 3 · 双视角综合 brief
0. 本轮新增价值
Round 3 与 Round 1+2 的本质差异：
- Round 1+2：Claude 治理 reviewer × Codex 工程视角 — 都在「文档体系内部」找问题（字段 / namespace / promoted_to / 反查链路 / fixture 边界）。
- Round 3：Claude 主控视角 × Codex 工程实施主力视角 — 跳出文档体系，问「这套文档真的能让 C-1 跑起来 / 跑通了之后能撑住组织级承诺吗」。
两轮所看到的风险几乎不重叠，且互相覆盖了对方的盲点。
1. 双视角并列对比表
| 维度 | Codex 工程实施视角 | Claude 主控视角 |
|---|---|---|
| 核心问题 | C-1 PR 起手能否一次跑通 | C-1 启动后能否撑住组织级承诺 |
| 置信度 | 88%（schema surface 可转译 + contract test 形状清楚） | 72%（文档体系扎实但真人决策网络空洞） |
| Step 8 6 项 closure | 5 项干净关闭 + 1 项 closure 但引入回归 | 不在 Round 3 关注范围（已在 Round 1+2 验证） |
| 最大风险 | eval str() allowlist 缺口（封 __builtins__ 后断言 DSL 兼容性破坏） | AI 自循环签字（27 owner map 中 19 项 = Claude + Codex 双签） |
| 新威胁数 | 4 条（1 P1 + 2 P2 + 1 P3） | 5 条（协同 / 合规 / 长期 / 商业 / 技术暗债） |
| 建议主控动作 | 5 条（锁 scope / 锁 module surface / 修 str / 展七轴 / 最小读取序列） | 3 条收紧条件（MP-3 人类拍板 / DA-1~DA-4 真人覆盖 trace / v3-sync 兜底） |
| 覆盖盲点 | 安全 allowlist 与断言 DSL 之间无回归检查 | Round 1+2 把视角框在「治理 / 工程」二端，漏了「主控」第三端 |
2. 双视角共识
两边独立得出但相互印证：
-
「能启动」≠「能跑通」≠「能撑住」。
- Codex：「可以启动 C-1」比 Round 2 更成立，但「起手即跑通」不该报 95% 以上。
- Claude 主控：12 项准入全绿，但「跨团队协同就绪度」「决策与资源分配可执行性」均给 2/5。
-
Round 1+2 的文档治理 closure 与 Round 3 的执行可行性不能互相代偿。
- Codex 视角下：Step 6 17 项 + Step 8 6 项 closure 全部确认，但局部工程回归（
strallowlist）只有 Round 3 才看见。 - 主控视角下：F5 整改后 27 项 owner map 在 Round 2 是 closure 工件，在 Round 3 却是「调度可执行性失败的证据」。
- Codex 视角下：Step 6 17 项 + Step 8 6 项 closure 全部确认，但局部工程回归（
-
「待指定 / 待对齐」标记的工程层成本与组织层成本被各自低估。
- Codex：cognition-1.1-contract §8「待对齐 4 条」其中 MP-3 / MP-2 / DA-6 已经在影响 C-1 import/test 行为。
- 主控：同 4 条「待对齐」中 MP-3 涉及战略不变量「不直接下单」的下游消费协议，AI 双签无法承担产品立场决策责任。
-
主控不能直接照 topic pack 给 C-1。
- Codex：agent-pack outputs 同时要求
cognition/types.py+ SQLite DDL + provider shim + eval runner + integration test，C-1 首 PR 应只切 schema surface + import smoke + contract test + sample fixture 最小落盘。 - 主控：需要在 C-1 task packet 第一段锁 scope，且建立「跨 PR 战略不变量周巡」机制，不让 PR 累积偏离。
- Codex：agent-pack outputs 同时要求
3. 双视角差异（互补盲点）
| Codex 看到 Claude 主控没看到 | Claude 主控看到 Codex 没看到 |
|---|---|
__builtins__ 封锁后 pytest_check 表达式 str() 立即失效（工程回归） | 27 项 owner 中 19 项 AI 自循环签字（决策网络空洞） |
types.py / contract_v1_1_m0.py / finbayes.cognition.v11 三套 import surface 并存 | MP-3 kelly_cap 与「不直接下单」战略不变量下游协议未绑定 |
mca_bucket 七轴模板仅 bucket_label，模型要求七轴必填的展开缝隙 | DA-1~DA-4 法务空缺（M2 接入 12 Provider 时合规债集中爆雷） |
| agent-pack outputs 范围大于 C-1 首 PR | Phase 5 首季评估 owner 空挂（持续构建 v2 叙事 3 个月后静默退化） |
| —— | v3-downstream-sync 悬置 7 项 P0（M1 启动时的暗债） |
| —— | 商业承诺与工程实施之间无验证回路（M0 跑通 ≠ 商业可启动） |
4. 合并的启动决议
结论：可以启动 C-1，但需在 task packet 中绑定两类前置条件：
4.1 工程层前置（Codex 提出，主控必须在 task packet 中显式锁定）
- C-1 task packet 锁 scope：只做
src/finbayes/cognition/types.pyschema surface +src/finbayes/cognition/v11.pyre-export +test_pydantic_schema_stability.py+ 5 条 sample fixture 最小落盘；不做 DDL / provider / eval runner / integration test。 - 锁 Python module surface：
types.py为事实实现，v11.py从types.pyre-export §3.5 类以满足 §14.5 import 路径；废弃contract_v1_1_m0.py第三份实现。 - Step 8 安全回归修复：把
safe_globalsallowlist 加str，或把 credential 断言改成结构化字段扫描；先跑 sample runner smoke。 - fixture 七轴展开：每条
mca_bucket在 C-1 task packet 中展开七轴字段；credential / execution rejection 样例不实例化 Task；固定task_id保证 CI 可重放。 - 最小读取序列：C-1 agent 按
agent-pack.yaml→cognition-1.1-contract.md§1/§5/§6 →m0-walking-skeleton.md§3/§3.5/§8/§11/§14.5 →milestone-field-evolution-matrix.md顺序 load，不一次 full load。
4.2 组织层前置（Claude 主控提出，人类用户必拍板）
- MP-3 由人类用户先拍板（不直接下单战略不变量保护），AI 双签不算数。建议形式：在 ADR-008 supplement §2.5 加 audit trail 段，显式说明「
kelly_cap下游消费协议：禁止任何下游系统把kelly_cap > 0当作 actionable trading signal；下游消费方必须显式承诺仅作为认知材料的不确定性度量呈现给人类用户，不进入自动执行链路」。 - DA-1~DA-4 法务 ADR 必须留「主控暂代 + M1 前真人覆盖」trace：owner map 显式声明「主控暂代到 T0+X 天，逾期暂停 Provider 接入」，标到里程碑日历上。
- v3-downstream-sync 给兜底：要么主控声明「M0 期间不依赖未关闭的 7 项 P0」（需逐项 audit），要么 M0 启动前先关闭。
4.3 启动决议综合判定
- 工程实施侧：4.1 五条进 C-1 task packet 后，Codex 估 C-1 首 PR 跑通概率 88%；若主控不锁 scope，降到 72-78%。
- 组织协同侧：4.2 三条人类用户拍板/兜底后，主控信心从 72% 提升到「条件启动 OK」。两边合在一起，是「文档体系 + 真人决策网络」的组合启动门槛。
5. 留给下一步的事
| 优先级 | 事项 | 责任路径 | 触发时点 |
|---|---|---|---|
| P0 | 写 C-1 task packet（含 4.1 五条工程前置） | Claude 主控起草 + 人类用户审 | C-1 启动前 |
| P0 | MP-3 人类拍板（ADR-008 supplement §2.5 audit trail 段） | 人类用户拍板 | C-1 启动前 |
| P0 | owner map 加「人类 owner 兜底列」+「待指定填充协议（T0+30 天）」 | Claude 主控 + 人类用户审 | C-1 启动后 1 周内 |
| P1 | DA-1~DA-4 加「主控暂代 + M1 前真人覆盖」trace | Claude 主控 | C-1 启动后 2 周内 |
| P1 | v3-downstream-sync 7 项 P0 audit 或关闭 | Claude 主控 + L2 reviewer | M0 收尾前 |
| P2 | 跨 PR 战略不变量周巡 checklist（主控自用） | Claude 主控 | C-1 首 PR 之后开始 |
| P2 | 「fixture 字段完整性 vs Pydantic 模型」回归 hook | C-1 第二轮 PR | M0 中段 |
| P3 | Phase 5 首季评估 owner 招募（数据科学家 / 半人工标注 reviewer） | 人类用户 | T0+2 月前到位 |
6. Round 3 元 review
6.1 为什么 Round 3 才看到这些？
- Round 1+2 视角天花板：把所有视角都框在「文档治理 / 工程实施」两端 → 文档体系满意但漏了「主控调动决策时的真人接入路径」、漏了「修安全时的断言 DSL 兼容性」。
- Round 3 视角下放：(a) Claude 主控视角从「文档治理者」切到「项目负责人」，看到了组织层；(b) Codex 工程实施主力视角不再做「文档审核」，而是模拟 C-1 首 PR 真的跑会发生什么，看到了局部工程回归。
6.2 对后续 review 节奏的启示
不需要 Round 4。Round 3 已经覆盖了「文档体系内 / 文档体系外 / 工程实施起手 / 组织决策网络」四个象限。下一次 review 应当在 C-1 首 PR 跑完之后，做**「真跑出来的结果 vs Round 3 估算」**的回归对照（Codex 估 88% 是否兑现 / 主控 3 条前置条件是否真发挥作用），而不是再做一轮文档审视。
6.3 给 meta-playbook 的反馈
- 「双视角 review」应当显式区分「平视双视角」（Round 1+2 治理 × 工程）与「下放双视角」（Round 3 主控 × 工程实施主力）。前者在文档体系内交叉验证，后者跳出文档体系看真实执行可行性。
- 「文档治理 closure」不能作为「执行可行性 closure」。Round 2 的 F5 整改 closure 在 Round 3 主控视角下被重新识别为「决策权空洞」证据 — 这是双工件性质，需在 meta-playbook 中显式标注。