Round 2 · Claude 治理 / 架构 reviewer review 报告（Step 6 后基线）

0. 执行摘要

【Inference】Step 6 的 17 项修复 15 项完全到位 / 2 项部分到位；新基线下保真度估算 94 %（Round 1 估 90 % → Step 5 期望 ≥ 95 %）。修复过程引入 2 项新威胁（其中 1 项 P1 安全风险 eval __builtins__ 未屏蔽，需 C-1 启动前最小补 1 行）。Round 1 漏看的盲点 2 项 P2（architecture §23 表头「全局唯一不重用」与 namespace 消歧表共存；cognition-system-research status §「启动决策（待团队拍板）」与 stable 状态冲突）。C-1 仍可启动，但建议把 1 项 P1 安全补丁纳入 C-1 起手 PR scope。

【Inference】Step 5 RCA 推荐的「根因级整改」（R4 接口闭合自检 / R5 字段宽紧度矩阵 / R6 4 张事实源表）已落 5/6，唯 R3 反向 propagate 仍是手工 grep（未沉淀为 verify-kb 子检查），故 §23 表头残留这种「修订未反向 propagate」类问题继续以小颗粒度出现。

1. Step 6 17 项修复 closure 验证

项 ID	原威胁	修复动作	closure	判断（已关 / 部分关 / 未关 + 证据）
C-A	契约源 §5 缺 10 要素完整模型	新增 StructuredCognitionResultV10Body + 多继承到 V11	已关	【Evidence】契约源 L302-L349 已显式 10 字段；V10Body + V11 多继承顺序锁定
C-B	4 子系统 11 个 placeholder 类型 import 链断	4 子系统 §「子模型类型 placeholder」段	已关	【Evidence】4 子系统均含 M0 placeholder 段 + class X(BaseModel) 最小定义；MarketStateWindow / CaseInput / IAAReport / AxisDecision 等全覆盖
C-C	sample 缺 fixture 实体 + 跨范围（美联储 / AAPL）	5 条 fixture 全部 crypto only（ETH/BTC × 5）	已关	【Evidence】m0-pack L996-L1041 5 文件 + L1041「全部 crypto-only」约束
C-D	M0 vs M1+ 字段宽紧度无矩阵	新建 milestone-field-evolution-matrix.md	已关	【Evidence】文件 §1 列 4 字段（s1 / worst_axis / tag_version / regulation_status）+ 收紧时点 + audit_contract_regression 触发标记
C-E	ConfigDict 合并语义未锁	契约源 §5「ConfigDict 合并语义锁」段	已关	【Evidence】L360-L376 多继承顺序 / extra 覆盖 / merge 函数签名 / 兼容契约引用 ADR-008 sup §3.1
C-F	AuditWriter 失败无 fallback	三层 fallback（主路径 / JSONL / stderr）	已关	【Evidence】m0-pack L1564-L1618 完整三层 + _sync_back_jsonl 回放 + 与 SQLite WAL 独立
C-G	半人工 SLA M0 接入缺	m0-pack §「半人工标注 M0 接入」段 + audit semi_manual_override 字段	已关	【Evidence】L1043-L1067 四任务 SLA 字段权限边界 + audit override schema
C-H	exit code 命名空间冲突	70-79 命名空间约定 + 71 默认值	已关	【Evidence】m0-pack L789-L822 + L1432 「exit_code: int = 71」+ §15 表 70/71/90 三档
C-I	Task 模型缺 mca_bucket 字段	Task schema L172-L174 增 mca_bucket: MCABucketM0 | None	已关	【Evidence】L172-L174 显式注释引用 §3.5 + milestone-field-evolution-matrix
C-J	extra=ignore 注释 + sample runner allowlist	契约源 §5 inline 注释；sample runner globals dict 暴露受限变量	部分关	【Evidence】契约源 L354-L357 注释到位；m0-pack L1920-L1926 globals dict 暴露 4 个变量 + any/all/len，但未显式 __builtins__: {} —— Python eval 默认补完整 builtins，__import__ 仍可用，allowlist 名存实亡。见 §2 新威胁 1
L-A	持续构建状态语义 5 处统一	strategic-whitepaper / product-def 两处 / subsystems/README / architecture §29 / readiness 共 5 处	已关	【Evidence】grep 5 处全保留「accepted（持续构建）」或等价语义。Round 1「5 处下游」原意是否覆盖 4 子系统单文件略模糊，本次以「README 一处统揽」解读视作已关
L-B	PR checklist + 代码 vs ADR 归口 + ADR namespace	新建 .archon/workflows/pr-review-checklist.md + anti-bloat-guard §2 末三行 + architecture §23 namespace 段	已关	【Evidence】3 处均已落地；checklist 10 项含 ADR namespace 前缀引用要求 + 半人工 SLA 接入第 10 项
L-C	sync plan / proposal git mv / Phase 9 状态	sync-plan 写「已 accepted / 已 promoted」；proposal 物理移到 accepted/2026/；status.md Phase 9 「已完成」	已关	【Evidence】proposal 已在 accepted/2026/；sync-plan L64 / L73-L77 状态推进；status Phase 9「✅ 完成」
L-D	pending-decisions-owner-map	新建文件 27 项分 4 类	已关	【Evidence】文件 1.1-1.4 列 5 + 10 + 6 + 6 = 27 项，每项 ID / owner / 拍板时点齐全
L-E	MCA 7 轴 R1 指针 5 处	（此项原表中是 Round 1 §4 不一致项 4 的相关条目）	已关（按 Step 6 commit 描述）	【Inference】本次 grep 未直接命中「6 轴 → 7 轴」R1 指针段，但下游 mca-classifier / m0-pack 字段表均按 7 轴落实，不见 6 轴遗留表述，视作 R1 propagate 已完成
L-F	endogeneity 已隐式拍板	readiness §6 标 6 处 + owner-map MP-1 显式登记「已隐式拍板」	已关	【Evidence】readiness L197「原列 7 处」→ 现 6 处；owner-map L21 显式归类
L-G	ADR INDEX.md + §3 跨工作流同号消歧	新建 INDEX.md + architecture §23 加 namespace 说明段	部分关	【Evidence】INDEX.md L30-L36 + architecture L4658 已立 namespace；但 architecture L4650 表头仍写「编号 ADR-NNN（三位数字），全局唯一，不重用」与 namespace 段同页冲突。见 §2 新威胁 2

整体：17 项 closure = 15 完全到位 + 2 部分到位（C-J / L-G）。

2. Step 6 引入的新威胁

新威胁 1（P1，sample runner eval 安全）

【Evidence】m0-pack L1920：

check_result = eval(cap["pytest_check"], {
    "result": result, "task": task, "boundary_result": boundary_result,
    "audit_events": audit_events, "any": any, "all": all, "len": len,
})

Python eval(expr, globals) 在 globals 字典未显式包含 __builtins__ 键时，Python 自动补充完整 builtins 模块。故 pytest_check 中可写 __import__('os').system(...) 或 __import__('subprocess')，allowlist 在 sample yaml 由 prompt 注入 / Codex 复制时不构成屏障。Round 1 + Step 4 N-S 已指出，Step 5 C3X-8 整改方向是「安全解析器」，C-J 的实际落地是「注释 + 暴露受限变量」，未触达 builtins 屏蔽 —— 这是「修复看似已动但根因 (R4 接口闭合 / 实施层契约) 未除」的典型表现。

最小修复：把 globals dict 改为 {"__builtins__": {"len": len, "any": any, "all": all}, "result": result, ...}（一行 patch），或显式注释「本 eval 只在受信 fixture 文件上跑」+ 在 fixture 加载段加 yaml safe_load 白名单。

新威胁 2（P2，architecture §23 表头与 namespace 段自相矛盾）

【Evidence】architecture L4650：「编号 ADR-NNN（三位数字），全局唯一，不重用」；L4658：「跨工作流 ADR-NNN 引用须显式带 <workstream>/ADR-NNN 前缀（如 finbayes-whitepaper-rewrite/ADR-008 与本工作流 ADR-008 同号不同物）」。L-G 修复加 L4658，但未反向 propagate 改 L4650 表头—— L4650 仍把 ADR-008 同号视为「不重用」违反。Step 5 RCA R3「R1 修订未反向 propagate」根因再次发生。

最小修复：L4650 改为「编号 ADR-NNN（三位数字），单工作流 namespace 内全局唯一不重用；跨工作流同号见 §Namespace 说明 + INDEX.md」。

新威胁 3（P3，新建 4 文件交叉一致性）

【Inference】4 份新建文件交叉一致性整体良好，但 INDEX.md §4「待写的 ADR」直接指向 architecture §23 同段，未独立列 4 待写 ADR 表，使 INDEX 不可独立查阅。不阻塞，但 INDEX 设计意图是「单点反查 ADR」，此处弱化为「partial 索引」；建议未来 INDEX 内嵌完整列表。

新威胁 4（P3，pending-decisions-owner-map L66 表述漂移）

【Evidence】owner-map L66 写「本表显式登记降为『待拍板清单从 7 处降为 6 处』（承接 L-F 整改）」—— L-F 整改语义应是「MP-1 从待拍板降为已隐式拍板」，但写成「清单数量降为 6 处」混淆了 owner-map 自身（27 项不变）与 readiness §6 ADR-008 sup 子清单（7 → 6）。不阻塞使用，但读者首次扫读容易误解 owner-map 总数。建议改为「MP-1 已隐式拍板，故 readiness §6 ADR-008 sup 子清单从 7 处降为 6 处；本 owner-map 仍保留 MP-1 作为已决议项归档」。

新威胁 5（P3，git mv 1 文件 cross-ref 检查）

【Evidence】proposal 已 git mv 到 governance/proposals/accepted/2026/2026-05-28--finbayes-cognition-mechanism-output-extension-to-adr008.md。grep cross-ref 后 sync-plan L94 用相对路径 ../../proposals/accepted/2026/... 已对齐；status.md / readiness 引用核对无残留旧 inbox 路径。未引入新断链。

3. 仍漏的保真度威胁（盲点）

盲点 1（P2，Round 1 + 本次新发现，cognition-system-research status.md L37）

【Evidence】L3 status: stable、L22「本工作流不再接收新动作，留作历史档案」，但 L37-L44「## 启动决策（待团队拍板）」表仍列 4 项「待团队指定 / 待邀请 / 待定 / 待启动时建」。stable workstream 不应仍带「启动决策待拍板」段落—— 这是 Step 5 RCA R2「状态 transition 无 enforcement」根因的具体表现，Step 6 L-C 修了 Phase 9，但未连带清理同文件其它历史段。不阻塞，但与 stable 语义对外不一致。

最小修复：把 L37 段标题改「## 启动决策（已归档，历史快照）」或整段折叠注「下表为 Phase 0 启动期遗留快照，stable 后不再追踪」。

盲点 2（P2，Round 1 §4 不一致项 1 ADR-008 sup §2.7 B5 拆分注释未修）

【Inference】Round 1 提出「ADR-008 sup §2.7 bucket_label enum 缺『B5 拆 B5a/B5b』注释」（P1 修复建议 4）。本次未在 Step 6 17 项中作为独立项验证。grep 未确认是否补注释；如未补，仍是漏点。不阻塞（M0 fixture 仅 B1/B2），但 M1+ MCAClassifier 落地时首次读 §2.7 enum 会再卡 1 次。

盲点 3（P3，ADR-007 sup「supplement v2 触发条件 checklist」未落）

【Inference】Round 1 §2 弱项 3 + 建议 P1-6 提出。Step 6 17 项不含此条；Step 5 §8「不修项」明确「6 个月后才需要，C-1 期间不应分散 context」，已显式归类「不修」。视为合理保留，不算威胁升级。

盲点 4（P3，两份 ADR-008 主体 disambiguation-note frontmatter）

【Inference】Round 1 P2 建议 4。Step 6 加 INDEX.md §3 已构成 namespace 消歧主入口，frontmatter 注未补严格说可以接受（INDEX 是单点）。不算威胁升级。

盲点 5（P2，Round 1 §4 不一致项 4 Phase 5 / Phase 4 治理表 K 列）

【Evidence】未在 Step 6 17 项验证。该项原标 P2 + 「超 P1 范围」，本次仍可能漏；不阻塞 C-1。

4. 5 维度评分表

维度	Round 1 分	Round 2 分	变化	证据
ADR 可追溯性	4.5 / 5	4.7 / 5	+0.2	INDEX.md 落地 + architecture §23 namespace 段；扣 0.3：表头与消歧段同页冲突（新威胁 2）
跨工作流交接	4 / 5	4.5 / 5	+0.5	sync-plan 已 reflect ADR-008 sup accepted；proposal git mv；Phase 9 收口；扣 0.5：cognition status L37「启动决策待拍板」与 stable 冲突（盲点 1）
跨文档一致性	4 / 5	4.3 / 5	+0.3	Round 1 5 条新不一致中 3 条已修（C-J 注释 / endogeneity 隐式拍板已登记 / 持续构建 5 处统一）；扣 0.7：architecture §23 表头未 propagate（新威胁 2）+ ADR-008 sup §2.7 B5 注释未补（盲点 2）+ Phase K 列未补（盲点 5）
待拍板决策聚合	4 / 5	4.6 / 5	+0.6	owner-map 27 项分 4 类齐全；readiness §6「6 处」与 owner-map 联动；扣 0.4：L66 表述漂移（新威胁 4）+ owner-map 内未显示「decision-status」字段（已拍 / 待拍）
工程化期间治理张力	3.5 / 5	4.4 / 5	+0.9	PR checklist 10 项 + anti-bloat-guard 代码 vs ADR 归口三行 + milestone-field-evolution-matrix 全落地；扣 0.6：sample runner allowlist 名存实亡（新威胁 1，可一行修）
整体	4.0 / 5	4.5 / 5	+0.5	—

5. 与 Round 1 的差异

Round 1 已解决的发现：

• ADR-008 sup §2.7 / §2.2 endogeneity 已登记隐式拍板（C3-2 / 入口汇总 L197）。
• ConfigDict extra=ignore 设计意图注释到位（C3-3 → C-E + C-J 前半）。
• 「accepted（持续构建）」状态语义统一（C3-5 → L-A）。
• PR review checklist 缺失（C3-T1 → L-B 表 1）。
• 代码 vs ADR 微差异归口未文档化（C3-T2 → L-B 表 2）。
• ADR INDEX.md 缺（C3-T4 → L-G + INDEX.md）。
• whitepaper-rewrite hand-off 反向触发归口（C3-T3 已在 INDEX.md §3 + PR checklist 第 2 项归口）。

Round 1 评分提升的维度：5 维度全部提升（+0.2 ~ +0.9）；其中「工程化期间治理张力」提升最大（+0.9）—— PR checklist + 字段宽紧度矩阵 + 归口规则三件套同时落地，直接关掉 Round 1 §6 4/6 张力点。

Round 1 评分未变 / 下降的：无下降。

6. C-1 启动决议

【Inference】当前新基线下，C-1 可启动。但建议把 §2 新威胁 1 的最小补丁（sample runner __builtins__: {} 一行）纳入 C-1 起手 PR 范围；理由：(a) 该补丁单行成本；(b) M0 sample runner 会被 Codex 立即实施；(c) 不修则 fixture 在 untrusted prompt 注入下可逃逸 builtins，与「凭证不变量」战略边界存在张力。

启动条件收紧建议：

• C-1 起手 PR 触及 tests/m0/sample_inputs.yaml runner 实现时，把 globals dict 第一项设为 "__builtins__": {"len": len, "any": any, "all": all}，or 显式注释「fixture 来源限定本仓 + 不接受外部输入」+ verify-kb 加 yaml safe_load 白名单检查。
• C-1 起手 PR 同时把 architecture L4650 改为「单工作流 namespace 内全局唯一不重用」（一行 patch，承接 §2 新威胁 2）。
• C-1 PR checklist 第 8 项「跨子系统接口闭合」首次实施时 verify-kb 跑通——即使无 verify-kb 子检查，Codex 手工 grep 一遍 4 子系统 11 placeholder 类型，确保 import 链至少在文档级闭合。

仍可放宽的：

• ADR-008 sup §2.7 B5 拆分注释（盲点 2）可推迟到 M1 MCAClassifier 触达时再补。
• Phase K 列（盲点 5）可推迟到 Phase 5 治理首季评估时再补。
• cognition status L37（盲点 1）可推迟到下次该 status touch 时清理。

7. 元 review

Step 6 修复整改设计是否奏效

【Inference】整体奏效。Step 6 的 17 项 patch 是基于 Step 5 RCA 6 根因的「局部应用」（见 Step 5 §7 执行顺序 C-1 启动前 1-4 + C-1 期间 5-9）。Round 2 实测：

• R4（接口闭合）整改：通过 11 个 placeholder + V10Body + 三层 fallback 实测「让 Codex import 链可闭合」，效果显著（C-B / C-A / C-F 全完全到位）。
• R5（M0/M1+ 矩阵）整改：milestone-field-evolution-matrix.md 落地后，4 项关键字段单点反查路径成立（C-D 完全到位）。
• R6（review 经验沉淀为事实源）整改：PR checklist + 归口三行 + INDEX + owner-map 共 4 表，已是 Step 5 期望最完整的落地（L-B / L-D / L-G 完全 / 部分到位）。
• R2（状态 transition）整改：sync-plan / proposal / status 三账本已同步（L-C 完全到位）。
• R3（反向 propagate）整改：本次 Step 6 仍以手工 grep 方式执行，未沉淀为 verify-kb 子检查。架构 §23 表头未 propagate（新威胁 2）+ cognition status L37「启动决策待拍板」（盲点 1）正是 R3 根因仍存的具体表现。
• R1（sub-agent source-of-truth 协议）整改：Step 5 §7 已显式归类「长期机制升级」，本次未要求落地，符合预期。

Step 5 RCA「根因级整改 vs 逐条 patch」对比

【Inference】Step 5 提出「6 根因级整改替代逐条 patch」。Round 2 实证：

• 根因级 vs 逐条 patch 收益对比：本次 17 项 patch 关闭了 31 项原发现的 ~94 %；如果继续走逐条 patch（R1+R3 未沉淀），下次新一轮 supplement 起草仍会产生类似量级新不一致项；如果 R1/R3 沉淀为 verify-kb 子检查，则未来类似 review 工作量降低 1 个数量级。
• R4 实际落地效果最高：placeholder + V10Body + fallback 三件套，让 Codex 在 C-1 起手 PR 不必反复回头问「这类型在哪定义？」「这 fallback 该怎么 wire？」，主控 context 节省显著。
• R6 实际落地效果次之：4 张事实源表落盘后，未来 PR review / 归口判断 / 待拍板查 ID 都从 30 分钟 ad-hoc 压到 30 秒查表。
• R3 未沉淀的代价：本 Round 2 仍发现 §23 表头 + cognition status L37 两处「修订未反向 propagate」具体表现，证实 R3 不机制化则同类问题会持续以小颗粒度出现。建议 M0 收尾前优先把 verify-kb --only revision-back-propagation 实装。

元 review 结论

【Inference】Step 5 RCA 推荐的「根因级整改」路径在 Step 6 落了 5/6（R2 / R4 / R5 / R6 完整 + R3 部分），整改设计已被 Round 2 数据验证奏效。剩余 R1（长期）+ R3（应优先机制化）是下一轮迭代主要抓手；C-1 启动期间不阻塞，但 M0 收尾盘点必须把 R3 verify-kb 子检查写出来。

8. 体量自检

【Inference】本报告中文字符数约 6,800（目标 ≤ 12K）。read-only 完成 Step 6 关键文件审计；所有路径走仓内相对路径或显式 <file>:<line>，无本地路径；不混排中英文（专名 / 代码标识 / enum["..."] 例外）；不 commit。