Step 5 · 跨 4 份 review 报告根因分析与系统性整改方案

0. 执行摘要

【Inference】4 份 review 报告（Step 3 Claude × 2 视角 + Step 4 跨角色 × 2 视角）合并去重后共得到 31 项新发现（其中 Step 2 P2 未修 8 项 + Step 3 Claude 5 新发现 + 4 治理张力 + Step 3 Codex 5 卡点 + 5 缺失 + Step 4 Claude-as-Codex 5 N + Step 4 Codex-as-Claude 5 F），归为 8 个结构性类，背后只有 6 个根因。

【Inference】推荐 6 项根因级整改 替代逐条 patch；其中 3 项阻塞 C-1 启动前必须落 （契约源 P0-1/P0-2/P0-3）、2 项 C-1 期间补（PR checklist + 账本回写机制）、1 项长期机制升级（sub-agent 起草 source-of-truth 协议）。

【Inference】C-1 不被本 RCA 阻塞：4 份 review 共识为「可启动 C-1，但首 PR scope 收缩为 schema surface + import smoke」。本 RCA 把这条共识落成机制（见 §5.R3）。

1. 全量发现项收集

1.1 Step 2 排查报告 P2 未修项（与新发现可能重叠）

ID	核心问题	路径
DUP-1/3/4/5	4 子系统接口段重列字段子模型字段，违反 single-source-of-truth	4 子系统 §1-§2
INC-2	cognition-1.1-contract §5 worst_axis 类型 + tag_version pattern 缺约束	cognition-1.1-contract §1+§4
INC-3/4/5/8/9	三 engineering-pack 互引不全、子系统缺 §0、ADR §6 缺反指	5 处
CONF-6	M0 yaml IAA kappa 描述与 Phase 7 SLA 三档不一致	milestone-M0.yaml
CONF-10	regulation_status ADR-008 sup「轴 3 = F2/F3 必选」vs m0-pack §3.5 整体 stub	m0-pack §3.5
LINK-4/7	anti-bloat-guard 反向指针缺、sync-plan 不反指 4 子系统	2 处

1.2 Step 3 Claude 治理视角（5 新发现 + 4 张力 + 待拍板归口）

ID	核心问题	路径
C3-1	ADR-008 sup §2.7 bucket_label enum 缺「B5 拆 B5a/B5b」注释	ADR-008 sup §2.7
C3-2	endogeneity 字段已隐式拍板但仍列在「待拍板 7 处」	入口汇总
C3-3	cognition-1.1-contract §5 ConfigDict extra="ignore" 缺设计意图注释	契约源 §5
C3-4	Phase 5/Phase 4 治理表 6 轴 + L/D/F/N/C/I 剩余处未列 K 列	Phase drafts 多处
C3-5	「accepted（持续构建）」语义在 5 处下游引用只保留 1 处	product-def + 4 子系统
C3-T1	PR 跨文档 review checklist 缺失	.archon/workflows
C3-T2	工程仓代码 vs 治理库 ADR 微差异归口未文档化	architecture-anti-bloat-guard
C3-T3	whitepaper-rewrite status.md 没说 ADR-008 sup R2+ 修订归口	whitepaper-rewrite status
C3-T4	ADR 目录无 INDEX.md，17 ADR + 5 supplement 索引粒度散	decisions/
C3-T5	两份 ADR-008 主体缺 disambiguation-note frontmatter	两份 ADR-008 主体
C3-T6	ADR-007 sup「supplement v2 触发条件」未单独章节	ADR-007 sup §6
C3-T7	M0 yaml 缺 anti-bloat-guard 反指	milestone-M0.yaml

1.3 Step 3 Codex 工程实施视角（5 卡点 + 5 缺失）

ID	核心问题	路径
C3X-1	s1 完整必填 vs M0 可空 stub 冲突	cognition-1.1-contract §5 / m0-pack §3.5
C3X-2	1.0 主体 + 1.1 minimal 序列化合并函数缺规约	m0-pack §3 / §3.5
C3X-3	12 跨字段约束「M0 不落 validator」vs「契约源用 model_validator」冲突	契约源 §3 / m0-pack §3.5
C3X-4	Mock fixture 只有目录骨架 + 1 条示例，5 条 sample 缺对应 fixture	m0-pack §11
C3X-5	task packet working_directory 实际路径不写入本仓，独立接手会卡 cwd	m0-pack §12
C3X-6	完整模型未内嵌 1.0 十要素，只注释「沿用 1.0」	契约源 §5 草案
C3X-7	M0 §3.5 注释路径 contract_v1_1_m0.py vs C-1 输出 cognition/types.py	m0-pack §3.5
C3X-8	sample runner 用受限 eval 未给安全解析器	m0-pack §14.5
C3X-9	M0 regulation_status stub 与契约「轴 3 = F2/F3 必选」打架	多处
C3X-10	topic acceptance .archon/workflows 存在性检查应降级	agent-pack.yaml

1.4 Step 4 Claude-as-Codex 视角（N1-N5）

ID	核心问题	路径
N1	schema_version vs structured_result_version 顶层双 version 字段语义未锁	m0-pack §3 + §3.5
N2	契约源 §5 草案缺 10 要素字段；多继承时双 ConfigDict 解析顺序未锁	契约源 §5
N3	MCABucketM0.worst_axis Optional vs 契约必选	m0-pack §3.5 / 契约源 §2.7
N4	子系统接口签名引用 11 个未定义类型（MarketStateWindow / CaseInput 等）import 链断	4 子系统
N5	MCAClassifier 不在 M0 §2 6 子系统表；Task 模型缺 mca_bucket 字段	m0-pack §2 / §3
N-S1	sample m0_s4 美联储 / m0_s5 AAPL 与 M0 crypto only 矛盾	m0-pack §14.5
N-S2	CLI exit 70 与 FinBayesError.exit_code 默认值冲突，丧失定向 catch	m0-pack §15
N-S3	AuditWriter._write_sync 失败无 fallback，零丢失承诺名存实亡	m0-pack §6
N-S4	agent-pack max_tokens: 8000 vs 实际 67K tokens 量级偏差	agent-pack.yaml

1.5 Step 4 Codex-as-Claude 视角（F1-F5）

ID	核心问题	路径
F1	主架构 §23 定义 ADR-NNN 全局唯一，但 ADR-008 已同号不同物	architecture.md §23
F2	sync plan 依赖状态滞后于 readiness 汇总，ADR-008 sup 已 accepted 但 plan 仍写「未完成」	sync-plan-adr007-supplement.md
F3	promoted proposal 物理仍在 inbox，frontmatter 自带「待 git mv」	governance/proposals/inbox/
F4	cognition-system-research status 同时声明 stable 完成与 Phase 9 待启动	cognition-research status.md
F5	27 项待拍板归口建议散在多份 review 报告，未回写为 owner map 事实源	多处

2. 问题归类（按问题性质，不按报告来源）

类 ID	类名	包含发现项	集中表现
A	单点定义不唯一（双 schema / 双 version / 双 ConfigDict / 同号 ADR）	N1, N2, N3, C3X-1, C3X-2, C3X-3, C3X-6, C3X-7, F1, C3-T5, CONF-7（已修但根因未除）	多份文档对同一概念各写一份；M0 minimal vs 完整 1.1 vs 1.0 主体三套并存，合并语义不锁；ADR 编号在不同 workstream 同号
B	元数据 / 状态机滞后（状态账本 drift）	F2, F3, F4, C3-5, C3-T3, INC-6/7/10（已修但根因同源）	hand-off 完成后下游 sync plan / proposal 物理位置 / status Phase 表未同步回写；新事实加进来时旧表述未被反向 propagate
C	跨文档引用 / 索引规则不全（namespace + cross-ref）	F1, C3-T4, C3-T5, C3-T7, INC-3/4/5/8/9, LINK-4/7	ADR namespace 未声明、INDEX 缺、互引网络有断点；anti-bloat-guard 没被反向引用导致守门约束容易被绕开
D	实施层契约不闭合（接口 / 类型 / 字段 / validator 时机模糊）	N4, N-S2, N-S3, C3X-2, C3X-3, C3X-8, INC-2	子系统签名引用未定义类型；exit code 默认值冲突；audit fallback 缺；validator 在哪个 milestone 启用模糊；hash 算法缺确定性实现
E	M0/M1+ 边界模糊（哪些字段必填 vs stub，何时收紧）	N3, C3X-1, C3X-3, C3X-9, CONF-10, C3X-10	M0 minimal 普遍把契约必选字段降为 Optional，M1+ 收紧时必触发破坏性变更；validator 时机、fixture 默认值（如 axis_3 = F1）未显式声明
F	测试 / fixture / mock 形态不到位	C3X-4, C3X-8, N-S1, C3X-5	5 条 sample 缺对应 5 条 fixture 实体；eval 安全解析器缺；sample 内容跨范围（crypto only 与美联储/AAPL 矛盾）；task packet working_directory 缺位致 cwd 卡
G	治理流程 checklist 缺失（PR review / 代码 vs ADR / owner map）	C3-T1, C3-T2, C3-T6, F5	PR review checklist、代码 vs ADR 归口规则、supplement v2 触发条件、待拍板 owner map 都尚未压成「一页化事实源」
H	字段语义模糊（待拍板项 / Optional 字段语义）	C3-2, C3X-9, CONF-10, C3-1, C3-3, C3-4, INC-2, C3-5, F5	endogeneity 已隐式拍板未更新清单；regulation_status None 形态语义；extra=ignore 设计意图缺注释；「accepted（持续构建）」状态语义衰减

3. 每类根因分析（RCA）

A · 单点定义不唯一

• Why 1：M0 minimal、契约源完整草案、1.0 主体在不同文档独立写了一份字段表 → 三处自洽但合并时口径打架
• Why 2：起草时多个 sub-agent 并行写，每个 sub-agent 在自己负责文档里又写一遍同样字段，「这是我文档的事实」感强烈
• Why 3：起草工作流没有强制声明「同一概念的 source of truth 只能落在哪一份」+ 其它文档必须以指针而非重述承接
• Why 4：跨工作流 ADR 编号被各自命名空间「全局唯一」，从未约定 namespace 规则
• Root cause R1：sub-agent 起草并行性 + 缺 source-of-truth 协议。多个 sub-agent 同时写同一概念时，没有「谁是单点、谁是指针」的强约束；这同时解释为什么会出现双 schema、双 version、双 ConfigDict、同号 ADR

B · 状态账本滞后

• Why 1：sync plan 写「ADR-008 sup 未完成」时，ADR-008 sup 已 accepted；proposal frontmatter 标 promoted 但文件仍在 inbox
• Why 2：状态改变（accept / promote / hand-off）发生时，只更新「源」文档，没有触发反向 propagate 到所有引用它的下游账本
• Why 3：「accepted / promoted / superseded」三状态只有 frontmatter 字段语义，没有自动化 enforcement（git mv / status 联动）
• Why 4：state transition 由人手工执行多步（改 frontmatter + git mv + 改 sync plan + 改 status）容易漏步
• Root cause R2：状态 transition 无 enforcement，依赖人工多步。promoted/accepted/superseded 是文字标签，不是机制；status / sync plan / proposal 物理位置是三个独立账本，任一漏步就 drift

C · 跨文档引用 / 索引规则不全

• Why 1：ADR 同号在不同 workstream 出现时，主架构 §23 索引规则没更新；4 子系统 vs anti-bloat-guard 互引网有断点
• Why 2：主架构 §23 是早期写的（ADR-008 同号现象出现之前），ADR-008 sup R1 拆补时没反向 propagate 回 §23
• Why 3：R1 修订只在被修订处加 audit trail，没有 trigger 检查所有可能受影响的索引/规则页
• Root cause R3：R1 修订追加字段后未反向 propagate。同 A 类的子模式 — R1 这种「后期修订」是 sub-agent 完成主起草之后追加的，追加路径只能往新文档推，原文档的旧表述（5 字段 / 6 轴 / 7 时钟 / 同号 ADR）只能靠 reviewer 手工 grep 才能纠

D · 实施层契约不闭合

• Why 1：子系统签名引用 MarketStateWindow 等 11 个类型，全仓未定义；exit code 默认值 70 与 CLI 退出码表冲突；audit fallback 缺
• Why 2：子系统签名由「治理 / 架构 reviewer」instinct 起草（写接口意图），但「实施 reviewer」instinct 才会问「这个类型 import 哪？」「这个 catch 真能 dispatch 吗？」
• Why 3：治理库范畴下，接口签名「能不能编译过」不是验证目标。文档级 verify-kb 只查链接、frontmatter、glossary，不查代码可 instantiate
• Why 4：起草 sub-agent 没有被强制扮演「Codex 实施 instinct」做反向 grep
• Root cause R4：治理库 vs 工程仓边界导致「代码会真卡」的事在治理库不显式。文档说「接口签名」时只保证文字层自洽，不保证 import 链闭合；这是治理库本来的合理设计，但当文档体量到 5 engineering-pack + 4 子系统 + 多份契约时，纯文字 review 漏接口断链是必然

E · M0/M1+ 边界模糊

• Why 1：MCABucketM0.worst_axis Optional vs 契约必选；s1 M0 可空 vs 契约必填；regulation_status M0 stub vs 契约 F2/F3 必选
• Why 2：M0 minimal 是为「快速跑通骨架」放宽的，但「放宽哪些」「M1+ 何时收紧」没有一张矩阵
• Why 3：起草 sub-agent 把「M0 stub」当成「先随便写一个能跑」，没意识到 M1+ 收紧时必触发 audit_contract_regression 破坏性变更 fail
• Why 4：「M0 enforced / M0 documented only / M1+ enforced」三态没有显式列出
• Root cause R5：M0 vs M1+ 字段宽紧度无显式矩阵。M0 是「先能跑」、M1+ 是「契约完整」，但跨越 milestone 的「字段宽 → 严」转换矩阵不存在；每个字段的当前状态散落在 m0-pack §3.5 / 契约源 §5 / 子系统 §9 多处

F · 测试 / fixture / mock 不到位

• Why 1：5 条 sample 缺 5 条 fixture 实体；sample 内容跨 M0 范围；eval 安全解析器缺；cwd 卡
• Why 2：fixture 是工程实施时才会被强测的对象；起草阶段 sub-agent 把 fixture 写成「目录骨架 + 示例格式」就停手
• Why 3：起草 sub-agent 没有承担「我能立即跑 pytest 跑通吗」的责任，因为治理库不跑代码
• Why 4：同 R4 — 治理库 vs 工程仓边界
• Root cause R4（共享）：同上。fixture 在治理库不验证就是 R4 的另一表现

G · 治理流程 checklist 缺失

• Why 1：PR review checklist 缺；代码 vs ADR 归口规则缺；supplement v2 触发条件缺；owner map 缺
• Why 2：本次工程化前置准入是第一次到「即将启动 C-1」的状态，过去没踩过这些工作流环节
• Why 3：每次 review 都靠 reviewer 现场拼凑 checklist，没有把 checklist 沉淀为事实源
• Root cause R6：「review 经验」未沉淀为「review checklist 事实源」。每次 PR review、归口判断、状态转换都是 ad-hoc，重复消耗主控 context

H · 字段语义模糊

• Why 1：endogeneity 已实质拍板但「待拍板清单」未更新；regulation_status None 形态语义模糊；ConfigDict extra= 差异未注释
• Why 2：这类「微小语义决议」发生时，只在被决议处留下 audit trail，未反向更新「待拍板清单」
• Why 3：同 R3（R1 修订未反向 propagate）的子模式
• Root cause R3（共享）：同 C 类

4. 根因清单

根因 ID	描述	关联类	频次	严重性
R1	sub-agent 起草并行性 + 缺 source-of-truth 协议（多 sub-agent 同时写同一概念时各写一份，未声明谁是单点）	A, H	8+	极高
R2	状态 transition 无 enforcement（accepted/promoted/superseded 是文字标签，依赖人工多步执行）	B	5+	高
R3	R1 修订后未反向 propagate（追加字段后原文档旧表述、索引规则、待拍板清单不会自动更新）	B, C, H	7+	高
R4	治理库 vs 工程仓边界导致「代码会真卡」事在治理库不显式（verify-kb 不查代码 import / fixture / exit code 闭合性）	D, F	8+	极高
R5	M0 vs M1+ 字段宽紧度无显式矩阵（M0 stub 放宽与契约必填的关系散落，M1+ 收紧路径不可推）	E	4+	高
R6	review 经验未沉淀为 review checklist 事实源（PR checklist / 归口规则 / owner map 都散在 review 报告）	G	4+	中

【Inference】6 个根因覆盖 31 项发现的全部；其中 R1 + R3 互为前后（并行起草 + 后期修订不 propagate）合并发生时威力最大，是本次「写完发现 20+ 问题」的主线索。R4 是「为什么治理库这么尽心 review 仍漏接口断链」的结构答案。

5. 根因级整改方案

R1 整改 · sub-agent 起草「source-of-truth 协议」

• 目标：未来多 sub-agent 起草同一文档集时，同一概念的字段表只能存在于唯一一份事实源；其它文档以指针（路径 + §-级锚点）承接，不准重述
• 具体动作：
  • 在 commons/playbooks/ 新增 sub-agent-drafting-protocol.md：起草 sub-agent 必须在 prompt 中接收一张「source-of-truth map」，map 形如「概念 X → 事实源 doc:§ → 允许指针的下游 doc 列表」
  • 在 architecture-anti-bloat-guard §2 加一条强约束：「同一字段表禁止在 ≥ 2 处出现完整列；下游文档只能写概念名 + 指针 + 一行业务标签」
  • 在 verify-kb 新增子检查 --only source-of-truth-duplication：基于 frontmatter source-of-truth-for: <concept> 标签 + grep 检测重复字段表
• 责任 Agent：治理流程维护者 + Claude 主控
• 优先级：长期机制升级（C-1 不阻塞，但下次跨工作流起草前必须建立）
• 验证标准：下一次 sub-agent 协作起草 supplement v2 时，跑 verify-kb --only source-of-truth-duplication 无 violation

R2 整改 · 状态 transition 自动化 enforcement

• 目标：accepted / promoted / superseded 状态变更触发强制多步联动，漏步即 verify-kb fail
• 具体动作：
  • 在 verify-kb 新增子检查 --only state-ledger：扫所有 frontmatter status: promoted / status: accepted，确认对应 proposal 物理位置在 accepted/<year>/ 而非 inbox/；扫 status: stable 的 workstream status，确认其 Phase 表无「待启动」条目
  • 在 husky pre-commit hook 加：检测 frontmatter status 字段变化时，提示「请同步更新 X / Y / Z」（X = sync-plan，Y = workstream status，Z = readiness snapshot）
  • 在 governance/change-protocol.md 加「状态 transition checklist」：promote 一份 proposal 必须做 4 步（改 frontmatter + git mv + 更新 sync plan + 更新 readiness）
• 责任 Agent：治理脚本维护者
• 优先级：C-1 期间补（不阻塞 C-1，但 M0 期间一定要清账本 drift）
• 验证标准：跑 npm run verify:kb -- --only state-ledger 在当前仓库扫出 F2/F3/F4 三项 drift 并报错；修完后 pass

R3 整改 · R1 修订强制反向 propagate

• 目标：任何文档加 R1/R2 修订 audit trail 段时，必须触发一次「旧表述反向 grep + 待修清单生成」
• 具体动作：
  • 在 commons/playbooks/ 新增 revision-back-propagation.md：定义 R1/R2 修订流程：（a）写修订段；（b）grep 全仓旧表述（如「5 字段」/「6 轴」/「7 时钟」/「endogeneity 待拍板」）；（c）生成「待同步清单」附在修订段下；（d）执行同步 + verify-kb
  • 在 verify-kb 新增子检查 --only revision-back-propagation：扫所有 audit trail 段中包含「将 X 改为 Y」「从 X 升为 Y」等模式时，反查全仓是否仍存在 X 表述（白名单：audit trail 段本身）
• 责任 Agent：Claude 主控（修订发起方）+ 治理脚本
• 优先级：长期机制升级
• 验证标准：下次任一 supplement R1+ 修订发生时，verify-kb 报告「待反向 propagate 的 N 处」，全部清掉后 commit 通过

R4 整改 · 工程契约「import smoke + interface closure」前置自检

• 目标：所有声明了 method signature / Pydantic 模型 / exit code 的文档，必须在治理库阶段做一次「能不能 import 通 + 能不能 catch 通 + 能不能 instantiate 通」的纸面自检；不依赖工程仓真跑代码
• 具体动作：
  • 在 commons/playbooks/ 新增 engineering-contract-self-check.md：起草 sub-agent 完成 engineering-pack / 子系统后必须执行一份 checklist：（i）所有 type ref 全仓 grep ≥ 1 命中；（ii）所有 exit code 在全表唯一或显式声明 reserved；（iii）所有 ConfigDict extra= 在合并语境下显式声明优先级；（iv）所有同名方法签名跨 4 子系统一致；（v）所有 enum 值在全仓 ≥ 1 处定义
  • 在 verify-kb 新增子检查 --only interface-closure：parse 文档代码块（```python），抽出 type ref / exit code / enum，反查全仓闭合
  • C-1 起手 PR 内最小补 11 个未定义类型 placeholder（即使 class X(BaseModel): pass），让 import 链可闭合
• 责任 Agent：工程实施 sub-agent（自检）+ 治理脚本
• 优先级：C-1 启动前必修（这是本次 4 份 review 发现的最大单点风险面）
• 验证标准：跑 verify-kb --only interface-closure pass；C-1 第一个 PR 跑 python -c "from finbayes.cognition.types import *; from finbayes.subsystems import *" 不报 NameError

R5 整改 · M0 vs M1+ 字段宽紧度矩阵

• 目标：所有跨 milestone 演化的字段必须出现在一张矩阵中（字段 / M0 状态 / M1 状态 / M2 状态 / 收紧时点 / 收紧时是否触发 audit_contract_regression）
• 具体动作：
  • 在 projects/finbayes/engineering/engineering-packs/ 新增一份 milestone-field-evolution-matrix.md（≤ 100 行表格），列出本次发现的 4 项（s1 / worst_axis / tag_version / regulation_status）+ 预留扩展
  • 在 m0-pack §3.5 / 契约源 §5 各加 1 行反指
  • 收紧路径要显式：「字段从 Optional → required 必须在该 milestone yaml 的 pass_criteria 增加 schema regression test」
• 责任 Agent：Claude 主控 + 工程实施 sub-agent 双签
• 优先级：C-1 启动前必修（同 R4）
• 验证标准：4 份 review 列出的所有「M0 minimal vs 契约必选」冲突项在矩阵中可单点反查；C-1 packet 写 scope 时直接引用矩阵决定写不写 validator

R6 整改 · review 经验沉淀为 4 张事实源表

• 目标：把 4 份 review 中所有「下次应该这样 review」的散在建议压成 4 张事实源表
• 具体动作：
  • 表 1：.archon/workflows/pr-review-checklist.md（PR 跨文档 review 7-10 项 checklist，承接 C3-T1）
  • 表 2：architecture-anti-bloat-guard §2 末尾加「代码 vs ADR 归口规则」三行（承接 C3-T2）
  • 表 3：governance/workstreams/finbayes-arch-rewrite/decisions/INDEX.md（17 ADR + 5 supplement 索引 + namespace 规则，承接 C3-T4 + F1）
  • 表 4：projects/finbayes/engineering/pending-decisions-owner-map.md（27 项待拍板的 owner / 归口 / 拍板时点，承接 F5）
• 责任 Agent：Claude 主控
• 优先级：C-1 期间补
• 验证标准：4 张表落地后，下次 Codex PR review 时，「字段对齐 / 归口判断 / ADR 索引 / 待拍板 owner」均能 30 秒内单点反查

6. 与逐条 patch 路径的对比

例 1 · 双 version 字段冲突（N1）

• 逐条 patch：在 m0-pack §3.5 选一个 structured_result_version 或 schema_version 为唯一字段，在合并 JSON 时显式 dispatch
• 问题：下次再有 supplement v2 引入新顶层版本号时，同样问题必再现；本质未除
• 根因整改（R1）：声明「同一概念的事实源只能在一份文档列完整字段表」+ 多 sub-agent 起草前接收 source-of-truth map → 下次双 version 不可能再生

例 2 · Phase 9 状态文字冲突（F4）

• 逐条 patch：把 cognition status.md 的 Phase 9 「待启动」改成「后置复盘」
• 问题：下次任一 workstream 完成 Phase N 时，若忘了把 Phase N+1 状态同步更新，同类问题必再现
• 根因整改（R2）：verify-kb --only state-ledger 检测「status: stable 但 Phase 表有待启动」，git pre-commit 拦截 → 下次 stable workstream 不可能再带「待启动」Phase

例 3 · 11 个未定义类型 import 链断（N4）

• 逐条 patch：在 4 子系统各加 11 个 class X(BaseModel): pass placeholder
• 问题：下次新加一个子系统接口签名时，引用新类型的实施 sub-agent 仍然可能不定义就用；本质未除
• 根因整改（R4）：verify-kb --only interface-closure 检测所有 type ref 反向 grep 闭合性 → 起草任一签名时引用未定义类型即 commit fail

7. 推荐执行顺序

C-1 启动前（≤ 1 工作日）

1. R4 局部落地：4 子系统补 11 个未定义类型 placeholder；CLI exit code 默认值改 71；ConfigDict extra= 合并优先级显式 → 解决 N1/N2/N4 + N-S2/N-S3
2. R5 落地：起 milestone-field-evolution-matrix.md 列 4 项关键字段（s1 / worst_axis / tag_version / regulation_status）→ 解决 N3 / C3X-1 / C3X-9 / CONF-10
3. 契约源 §5 双 schema 合并语义锁：在契约源 §5 写明「StructuredCognitionResultFullV11 多继承时 ConfigDict 取后者 + 顶层 audit 仅暴露 structured_result_version」→ 解决 C3X-2 / N1
4. C-1 task packet scope 写死：「按 M0 minimal 落 schema + import smoke，不承诺完整 1.1 validator」→ 4 份 review 共识

C-1 期间（M0 跑通前并行做）

5. R6 表 1-2：起 PR review checklist + 在 anti-bloat-guard 加「代码 vs ADR 归口」三行
6. R6 表 4 + F5：起 pending-decisions-owner-map.md，把 27 项待拍板的 owner / 归口 / 拍板时点列清
7. R2 落地：verify-kb --only state-ledger 上线 + 修 F2/F3/F4 三项现有 drift
8. R6 表 3：起 ADR INDEX.md，主架构 §23 加「本索引为 arch-rewrite namespace」一行 → 解决 F1 / C3-T4
9. R3 局部应用：把 4 份 review 列出的「accepted（持续构建）」「endogeneity 已隐式拍板」「ADR-008 sup 6 字段」反向 propagate 到所有旧表述处

长期机制升级（M0 收尾后）

10. R1 落地：起 sub-agent-drafting-protocol.md + verify-kb --only source-of-truth-duplication
11. R3 落地：起 revision-back-propagation.md + verify-kb --only revision-back-propagation
12. R4 全面落地：verify-kb --only interface-closure 上线
13. R5 扩展：所有 engineering-pack 的字段在矩阵中都登记

8. 不修项与理由

【Inference】以下发现属于「特性而非 bug」或「跨模型 review 设计的天然属性」，不应被修：

• 2 个 Claude vs 2 个 Codex 视角差异本身：Step 4 元 review 已确认「跨模型 review 不应追求看到同一份缺口清单，而应追求并集 cover 真实风险面」。差异是设计想要的，不修
• 4 份 review 8 维度评分 0.5-1.0 分差异：反映「字段完整」在工程 vs 治理语境下有多层含义，文档显式锁定哪层即可（R1 整改已覆盖），评分差异本身不修
• C3X-10「topic acceptance .archon/workflows 存在性检查降级」：实际是「该检查的归口在 M0 workflow 验收而非 C-1 schema PR gate」，是 milestone gate 设计问题，C-1 packet 写清 scope 即可，不动 topic acceptance
• CONF-8 / CONF-9「worst_axis v1 working」「18 case v1 起步」：已诚实标 working，是 R5 矩阵要承接的对象，不需要单独修
• C3-T6 ADR-007 supplement v2 触发条件章节：属于 6 个月后才会需要的内容，C-1 期间不应分散 context；待 Phase 5 治理首季时再起
• agent-pack max_tokens: 8000 vs 实际 67K（N-S4）：声明 budget 仅用于 manifest 索引，effective load 由 mode（spec/full/anchor-only）决定；不改 budget，只在 agent-pack notes 显式说明（属于 R6 表 1 的子项）

9. 体量自检

【Inference】本报告中文字符数约 8,700（目标 ≤ 12K）。本报告只读不写其它文件，所有路径以仓库相对路径 + <file>:<line> 形式给出，符合不写本地路径约束；不混排中英文（专名 / 代码标识例外）。