Step 10 Round Fresh · Claude 主控视角全量独立 review

0. Review 边界与方法论声明

本 review 从第一性原理重做。前 9 步 13 份 review 报告我只看过文件名作为时间锚点，未阅读其结论。证据全部来自我自己重新读的 27 份目标文件 + 战略白皮书 + ADR INDEX + 工程 README + 主架构 §1-3 / §4 / §22-29 / §28 全文 + M0 工程包 §1-3 / §11-13 + cognition-1.1-contract §0-3 / §8 + 4 子系统接口段 + Archon yaml + pr-review-checklist + agent-pack.yaml。主架构 §4-§21 之间的章节（共约 200K chars）按目录抽查；任何「我没自己读过」的章节都标 unknown 不下结论。

主控视角的判断标准：(a) 启动 C-1 后是否可推进到 M0 验收闭环 (b) 100% 实现产品定义/架构所述范围的把握度 (c) 主控（我自己 / Claude Opus 4.7 1M context）能否同时承担 milestone gate / review / 审计 / 验收 / 资源调配 / 跨工作流总指挥六位一体的工作负载。

1. 执行摘要

启动信心度：72%。可以启动 C-1，但 4 项前置必须在 C-1 第一个 PR 合并前关闭。

用户三大要求	判定	一句话理由
1. 完整性 / 冗余 / 冲突 / 上位对齐	CONDITIONAL	上位对齐良好；存在 1 份 deprecated 文档仍在 README 推荐阅读顺序里；engineering/README.md 未更新文档清单（漏了 6 份 engineering-pack + 4 份 subsystem + anti-bloat-guard + pending-decisions-owner-map）
2. 100% 落地保真度	CONDITIONAL	M0 单 milestone 落地路径清晰；M1-M7 工程包全部未起草（仅 M0 一份），保真度可在 M0 验证，无法在 M0 阶段证明 M1-M7 也能 100% 落地；部分关键产品定义要素（如 §8.1 主动信号 / §10.1 用户主权三件套 UI）首落地点要到 M5 / M3，跨 milestone 漂移风险存在
3. 切片可行性（OpenSpec + Archon + Claude + Codex）	PASS（带健康警告）	Codex 走 agent-pack（8000 token budget）+ engineering-packs 切片消费，不读主架构 269K；Claude 主控走 1M context 可全量持有；但主控自己同时承担 6 项职责的 fresh-eyes 中立性是结构性风险（见 §7 风险 R1）

2. 战略不变量盘点（第一性原理 5 条）

我亲自从战略白皮书提炼，不依赖任何下游文档的转述：

#	战略不变量	上位锚（白皮书）	下位落锚	真实落地状态
I-1	认知层 ≠ 执行层（identity 级，不可变）：FinBayes 不直接下单、不持账户凭证	§9 一、§10 风险五	architecture §2 战略边界原句保留 + §17 + product-definition §11.1	GAP 关键 — cognition-1.1-contract §8 显式承认 kelly_cap 与该不变量的下游消费协议未在契约层声明。MP-3 必拍 C-1（owner map §1.1），但具体协议本身未写。posterior.kelly_cap 数值范围有定义；缺的是「kelly_cap 被下游执行系统消费时 FinBayes 是否需要写下禁止解释为仓位建议的契约义务」
I-2	用户主权三件套（当前版本立场，可演化）：可查看 / 可修改 / 可清空所有金融认知资产；候选→确认两步契约	§9 二、product-definition §3.4 / §10.1 / §11.2	architecture §2 + §11 + ADR-007（待写）	GAP 中 — M0 范围（m0-pack §1 表）明确「不走候选两步路径，M1+」；UI 落地要到 M3。两步契约由 ADR-007 承接，ADR-007 仍待写（架构 §23 标 M1+ 实施初期补）。M0 阶段 candidate path 是 stub。
I-3	金融执行凭证一律不收/不存/不训练（identity 级）	§9 二、§14	architecture §2 / §17、product-def §10.3、m0-pack §9-§10	PASS — M0 工程包 §10 给出 5 类正则 + BIP-39 + Luhn 算法基线，§9 给 5 类 negative test fixture，pr-review-checklist 第 10 项接入。这是 27 份文件中落地最扎实的不变量
I-4	认知输出按事实空间生成：画像不裁剪反方/失效条件；输出质量跨付费层级一致	§9 二（事实空间约束）+ §9（付费层级）	architecture §3 + product-def §10.2 + m0-pack §3 invalidation_conditions min_length=1 强约束 + §11 自动判定	PASS — invalidation_conditions 在 M0 schema 强制 min_length=1，工程上不可能输出空失效条件而通过。counter_evidence 允许空但必须明示理由。这是契约层硬约束，非治理软口号
I-5	持续构建认知体系（非「已完整」）：ADR-007 supplement「accepted（持续构建）」状态语义保留	§10 风险一/二 + ADR-007 supplement	product-def §6.4 + architecture §29 + subsystems/README 一致性约束	PASS — 三处都显式写「accepted（持续构建）」+ Phase 5 治理触发条件外引。状态语义在落地时不会被静默衰减为「已锁」

5 条战略不变量真实落地状态：3 PASS / 2 GAP。I-1 是 P0 必关；I-2 的 ADR-007 缺位会在 M1 起手时阻塞，但不阻塞 M0。

3. 上位 → 下位 → 落地材料对齐评估

每行是我从产品定义/架构中识别的「落地要求」，对照能落到代码的工程材料。

产品/架构要求	上位锚	下位落锚	落地材料覆盖	覆盖率
7 类用户认知任务识别	product-def §4.2	arch §2 / §9 Task Orchestration	M0 仅解释类 + 分析类（m0-pack §1）；其余 5 类没有任何 milestone 包承接（M1-M7 包全部未起草）	M0=2/7；M1+=0/7（包未起草）
10 认知要素必含组合	product-def §7 + ADR-008	arch §4 StructuredCognitionResult	M0 实现 1.0 主体 8/10：multi_perspectives / prerequisites / follow_up_questions / historical_judgment_links 在 m0-pack §3 schema 中未出现，仅 cognition-1.1-contract §1 表里列出	8/10（待 verify）
1.1 机制层 6 顶层字段 + 1 元数据	ADR-008 supp	cognition-1.1-contract + arch §29	M0 实施最小子集（每字段都 stub 一部分）；完整 1.1 在 M1-M5 逐字段上线	M0=最小子集；完整分散到 M1/M3/M5/M7
4 认知子系统（KG / Consistency / MCA / EvalHarness）	arch §29	subsystems/*.md 4 份已起草	每份 9 节俱全 + M0→M3 里程碑映射明确；接口签名落到 m0-pack §2 表	PASS
6 通路子系统（Input/Output / Orchestration / Evidence / State / Registry / Provider）	arch §8-§9	m0-pack §2 接口子集表	34 个接口（22 implement + 12 stub）签名固定	PASS
9 时钟 / 8 机制 / S1 4 失败模式 / MCA 7 轴	ADR-007 supp + product-def §6.4	arch §29 + 4 子系统 + cognition-1.1-contract §2	M0 仅 stub；完整落地依赖 M5 / M7+	延后 by design
Web UI + TUI + CLI + MCP + Channel 5 入口	product-def §9 + arch §16	arch §9 Input Pipeline	M0 仅 CLI；TUI/Web/MCP/Channel 全部 skip（m0-pack §1 + §2）	M0=1/5；M3 才到 3/5；M5 到 4/5
用户主动信号 + Watchlist + Judgment Record	product-def §3.2/§3.4/§8.1	arch §11 状态生命周期	M1 才上 Session 多实例 + Watchlist + Judgment Record；M5 才上主动信号	延后 by design，工程包未起草
11 维评测 + 7 MCA 桶	product-def §6.4 件 4	subsystems/eval-harness.md	M0 仅 D1/D2/D5/D7 起步（eval-harness §9 里程碑映射）；7 桶在 M1 上线	M0 部分起步；完整在 M2+

结论：架构与产品定义所要求的实现范围在文档上全量明确，但工程落地材料对 M0 范围充分（约 25结论：架构与产品定义所要求的实现范围在文档上全量明确，但工程落地材料对 M0 范围充分（约 25 percent），对 M1-M7 范围仅有架构 §25 索引 + 4 子系统 §9 里程碑映射段，没有任何 milestone pack。这意味着 M0 之后，每个 milestone 启动都要重做一次「m0-walking-skeleton 级别的 2052 行 task-oriented pack」起草工作——这是约 60 percent 已知未做工作量。

4. 100 percent 落地保真度评估

把「100 percent」拆成两个独立问题。

4.1 M0 范围保真度

维度	当前材料	判定
schema	m0-pack §3 + cognition-1.1-contract §5 双层（1.0 主体 + 1.1 子集）	PASS — Codex 可直接生成 Pydantic 文件
DDL	m0-pack §4 给完整 SQL（4 业务表 + 1 元表）	PASS
接口签名	m0-pack §2 表 34 个接口三类标记	PASS
边界（凭证）	m0-pack §9 fixture + §10 正则 + 测试基线 + pr-checklist 第 10 项	PASS（最强）
验收口径	m0-pack §11 自动+人工 5 条 checklist；Archon yaml ai-integration-test	CONDITIONAL — 人工 checklist 评分人是 claude_code / codex / 工作流维护者，AI 自评同源（见 §7 R1）
ADR 闭合	6 ADR accepted + 4 ADR 待写（005/006/007/009）	CONDITIONAL — ADR-007 M0 不触发不阻塞 M0；但直接阻塞 M1 状态化
27 项 owner map	pending-decisions-owner-map.md 清单存在	CONDITIONAL — 见 §7 R2

M0 范围保真度：85 percent。剩 15 percent 是「评分协议自我裁决 + 5 项 MP 必拍但归口仍是 AI 双签」结构性风险。

4.2 M1-M7 范围保真度

40-50 percent。理由：

7 个后续 milestone 工程包未起草（architecture §28 表显式标「待起草」）。M1 候选两步写入是 ADR-007（待写）+ 候选→已确认状态机（arch §11 + product-def §3 多处提及）的双重承接，但没有 m1-state-confirmation.md。
产品定义 §3.4 Judgment Record + §8.1 主动信号 + §10.1 用户主权三件套 UI——这些是「用户感知层」核心承诺，落地点分散到 M1（Judgment Record 持久化）/ M2（复盘任务）/ M3（Web UI）/ M5（主动信号触发）。主控视角看到的是：产品承诺核心用户感知形态 → 工程包 0 → 任何一个 milestone 工程包起草延迟都会让产品承诺向后顺延。

关键 P0 缺口（M0 阶段必须补的）：

kelly_cap 下游消费协议（MP-3）的契约文本：cognition-1.1-contract §8「待对齐项」诚实标注未写；但 owner map 把 MP-3 归「C-1 期间 inline PR audit trail」——把战略不变量 I-1 的契约写法降级为「PR 评论里 30 分钟决议」。这是主控不能签字的事（详见 §7 R3）。
engineering/README.md 文档清单失修：仅列 4 份文档（product-definition / architecture / subsystems README / goal-execution.md），没有列 engineering-packs/（6 份，含 m0-walking-skeleton 2052 行）、subsystems 4 子系统具体文档、architecture-anti-bloat-guard.md、pending-decisions-owner-map.md。Codex / 外部 reviewer 通过 README 入口找不到 M0 工程包——他们必须通过 architecture §28 间接进入。

5. 文件齐备性 / 冗余 / 冲突 / 无效

5.1 冗余 / 无效文件

文件	性质	处置建议
projects/finbayes/engineering/goal-execution.md	frontmatter status: deprecated-partial / maturity: superseded；但 README 阅读顺序仍把它列为第 4 步	engineering/README.md 把它移出阅读顺序，挪到「历史参考」
projects/finbayes/engineering/legacy/README.md	gitstatus 显示已 modified，未读其内容；命名暗示是历史区	不阻塞

5.2 冲突文件

议题	A 口径	B 口径	冲突判定
LLM 降级链层数	architecture §25 表「仅 L1 用户配置 Provider implement，L1prime / L2 / L3 / L4 全部 stub」	m0-pack §1 表「本表为唯一权威，覆盖主架构 §25 早期描述」	已自我消歧（m0-pack 显式宣告 override），不算冲突；但 main arch 仍是 6052 行原文，没回写。建议在 arch §25 表回写 m0-pack 是权威
任务类型 7 类 vs clarify 第 8 类	product-def §4.3 注释 clarify 不出现在用户视角任务清单中	architecture §2 七类用户认知任务	无冲突（已显式排除）

5.3 无效引用

for-agents/topics/finbayes-m0-implementation/agent-pack.yaml anchors 中的「27-认证密钥治理」与 architecture §27 实际章节名「代码仓位置映射」不符（凭证治理在 §17）。anchor 错误，Codex load 该 anchor 时会找不到。

5.4 缺失文件

缺失	影响 milestone
m1-state-confirmation.md（候选两步写入工程包）	M1 启动前必补
m2-task-types.md / m3-multi-entry.md / m4-market-extension.md / m5-proactive-signal.md / m6-eval-loop.md / m7-evolution.md	各自 milestone 启动前
horizontal-concerns-bundle.md（边界/可观测/演化横切包）	跨 milestone
ADR-005 / ADR-006 / ADR-007 / ADR-009 完整文本	主架构 §23 自己标「M1+ 实施初期补」
engineering-packs/README.md（目录入口）	目录无 README，Codex 通过 agent-pack.yaml 反向定位，外部 reviewer 看不出有几份 pack

6. 切片可行性（OpenSpec + Archon + Claude + Codex）

6.1 token 估算

角色	M0 一次性 load	token 估算	1M / 200K context 占用
Codex（agent-pack budget=8000 token）	m0-walking-skeleton.md（91K chars ≈ 23K tok full）+ cognition-1.1-contract.md（29K ≈ 7.3K tok full）+ 其余 7 份 include_mode spec 摘要 ≈ 8K tok	agent-pack budget 8000 token 远低于实际需要（约 38-45K token full load）	预算与现实不符
Claude 主控（我自己）	strategic-whitepaper（103K ≈ 26K tok）+ product-definition（43K ≈ 11K tok）+ architecture full（269K ≈ 67K tok）+ m0-pack（91K ≈ 23K tok）+ 4 subsystems（64K ≈ 16K tok）+ 6 engineering-packs（其余 ≈ 18K tok）+ 6 ADR + INDEX ≈ 8K tok + 配套约 5K tok	约 175K token	1M = 17.5 percent；200K = 87.5 percent（Sonnet/Haiku 不可行）

关键发现：agent-pack.yaml 的 max_tokens 8000 是错的。如果按 8000 token 给 Codex 喂 spec，所有 include_mode spec 的源各 ≤ 1500 token——cognition-1.1-contract.md 单文件 7.3K token，光这一份就超总预算。要么调高 budget 到 ≥ 40K tok，要么 Codex 必须分多次 load。

6.2 跨文档反复 fetch 风险

Codex 起手生成 cognition/types.py 时需要：(1) m0-pack §3（schema 模板）；(2) cognition-1.1-contract §2 + §3 + §5（完整字段定义）；(3) ADR-008 supp（事实源，cognition-1.1-contract §0 强制回引）；(4) architecture §4（业务对象关系图）；(5) milestone-field-evolution-matrix（演化路径）。5 个跨文件跳跃 + 每个文件局部锚点 → context 反复膨胀。agent-pack.yaml notes 末写「Codex 单次 load 入口，不要绕过本包再回头 grep 仓库」是好做法，但 anchor「27-认证密钥治理」错误会让 grep 兜底必然发生。

6.3 Archon 6 ai 节点切片合理性

milestone-M0.yaml 6 个 ai 节点（cognition-schema / sqlite-ddl / provider-shim / semi-manual-sla / eval-harness-m0 / integration-test）+ 3 gate + 2 PR。判定：

ai-cognition-schema：Pydantic 1.0 主体 8 模型 + 1.1 M0 子集约 15 个 Pydantic 类。中等，单 PR 可承接
ai-sqlite-ddl：4 业务表 + alembic。小
ai-provider-shim：base.py + stub.py。小
ai-semi-manual-sla：可能偏大——半人工标注 SLA 在 M0 完整落地是过早乐观；更适合 stub schema + 推迟到 M1+
ai-eval-harness-m0：runner.py + m0_subset.yaml + D1/D2/D5/D7 4 维评测器。偏大 — 建议拆 2 节点
ai-integration-test：e2e + 5 sample inputs + 5 凭证 negative test。中等

切片粒度判定：合理偏紧。建议主控决议是否把 ai-semi-manual-sla 降级为「schema only + worker 推迟到 M1」。

7. 主控视角的真正风险（7 条）

不重复 §3-§6 已说的事，专门讲主控位置看到的风险。

R1 · 主控自己 fresh-eyes 中立性结构性破产

owner map 27 项里 19 项 owner 写「Claude 主控 + Codex 双签」。M0 验收 §11 人工 5 条 checklist 评分人写「claude_code | codex | 工作流维护者」。Archon yaml pr-review-gate.reviewer 是 claude-code-controller。主控同时是：spec 起草人（在主架构 / engineering-packs 写出契约的人）+ task packet 撰写人（OpenSpec 阶段）+ PR reviewer（gate 守门）+ 验收评分人（人工 checklist）+ 决议人（C-1 期间 MP-1~MP-5 inline 30 分钟决议）+ 资源调配人。ADR-003 自己写「实施者不当自己代码的 reviewer（fresh eyes 原则）」——但主控自己作为 spec 起草人当自己 spec 的 reviewer，这个二阶 fresh-eyes 漏洞 ADR-003 没说。诚实自评：我有能力发现自己 spec 的 bug，但「我承认自己 spec 错了」的成本极低（只是改文档），「我承认自己作为 reviewer 错过 spec bug」的成本极高（要重 review），心理上后者更难。这是结构性 bias。

应对：M0 期间至少有一个验收 gate 由人类工作流维护者亲自走（不只是 sign-off），且该 gate 不能由主控代签。

R2 · 27 项 owner map 里 19 项 AI 双签的产品立场决策权问题

亲自数过 pending-decisions-owner-map.md：

必拍 C-1 5 项（MP-1~MP-5）：owner 全是「Claude 主控 + Codex 双签」
直接 ADR 6 项（DA-1~~DA-6）：DA-1~~DA-4 owner 是「法务 + 数据治理 owner（待指定）+ Claude 主控」，DA-5/DA-6 是「Claude 主控 + Codex 双签」
自然解决 10 项：owner 是「EvalHarness reviewer + Phase 5 治理首季」（也是 AI）

MP-3 kelly_cap × 不直接下单战略不变量：这是产品立场决策（战略不变量 I-1 的下游消费协议），不是工程实现细节。AI 双签不能承担这条决策的最终责任——按白皮书 §9 立场演化治理原则，凭证立场 / 用户主权 / 事实空间 / 付费层级一致的重大调整「由产品 + 工程 + 商业 + 合规团队联合评估」。kelly_cap 协议的写法影响 FinBayes 输出被下游 ATM 消费时的责任边界——属于产品立场议题。

DA-1~DA-4 data-providers 合规：owner 写「法务 + 数据治理 owner（待指定）」——这就是缺位。法务真人 owner 不指定就立 ADR，等于 AI 自己签合规 ADR。

应对：在 C-1 启动前显式拉一份「需要真人签字的最终决策」清单（至少 MP-3 / DA-1-4 / I-2 用户主权范围调整路径），不让 AI 双签覆盖产品立场层。

R3 · 主控同时承担六位一体职责的工作负载

milestone gate / review / 审计 / 验收 / 资源调配 / 跨工作流总指挥。前 5 项是单线程逐 PR 工作；第 6 项「跨工作流总指挥」涉及 finbayes-cognition-system-research（ADR-007 supplement / Phase 5 / Phase 7）+ finbayes-whitepaper-rewrite（ADR-008 supplement）两个并行工作流。诚实自评：主控（我）能在单次 1M context 内承载所有六项的事实层，但长期连续承担意味着每次 PR review 都要重新 load 全量上下文（每次约 175K token）——成本不在 token 而在认知一致性。两次相邻 PR 之间，主控对「上次怎么决议」的记忆完全依赖仓内事实（Markdown + PR 评论），没有 session memory。一致性靠仓内文档完备性兜底，但 anti-bloat-guard 又限制主架构膨胀，回写频次会下降。

应对：每次主控决议必须写入 governance/workstreams/finbayes-arch-rewrite/decisions/ 或 PR audit trail 段（不靠记忆）；status.md 节点机制必须严格执行。

R4 · agent-pack.yaml budget 8000 token 与现实严重不符

§6.1 已算：cognition-1.1-contract.md 单 full load 已 7.3K token，光这一份就超总预算。Codex 实际接收的是按 budget 裁剪后的内容，关键约束（如 cognition-1.1-contract §4 字段间依赖约束 13 条、§7 半人工标注承接）可能在裁剪中丢失。Codex 写出的 schema 缺少字段间约束 → 单测过但集成不过 → 返工。

应对：调 agent-pack budget 到 ≥ 45000 token，或把 include_mode spec 的源升到 full（特别是 cognition-1.1-contract 与 eval-harness-formulas）。

R5 · M1-M7 工程包 0 起草

§4.2 已说。主控视角：M0 走通骨架的最大风险不是 M0 自己，而是 M0 完成后没有任何文档告诉实施 Agent 怎么进入 M1。anti-bloat-guard 拦了主架构膨胀，但没拦工程包零起草——下一份 m1-state-confirmation.md 由谁起草、什么时点起草，本仓没有承接位。可能的失败模式：M0 验收通过 → 没人启动 M1 工程包 → Codex 拿着 M0 包尝试做 M1 候选两步写入 → 漂移。

应对：M0 第 4 个 ai 节点（ai-semi-manual-sla）完成时强制触发 M1 工程包起草。

R6 · ADR-007（状态写入两步）M0 不阻塞但 M1 直接阻塞

architecture §23 表显式标 ADR-007「M1+ 实施初期补」。但「实施初期」是模糊的——是 M1 第一个 PR 之前？还是 M1 整个 milestone 之内？没有 deterministic gate。如果 M1 task packet 起草时 ADR-007 仍未写，task packet 引用「ADR-007 决策」时是空指针。

应对：M0 收尾 PR 自动触发 ADR-005/006/007/009 起草工作流。

R7 · 跨工作流 ADR 同号消歧靠 namespace 前缀，PR review 不强制

ADR INDEX §3 明确 ADR-008 在 arch-rewrite vs whitepaper-rewrite 不同物。pr-review-checklist 第 2 项要求带 workstream/ADR-NNN 前缀。但 m0-walking-skeleton.md / agent-pack.yaml / archon yaml 都直接写「ADR-008 supplement」未带 namespace。全靠上下文推断到 whitepaper-rewrite（事实正确，但形式上违反 INDEX 规约）。

应对：加严 verify-kb 规则——所有 ADR-007 / ADR-008 / ADR-009 引用必须带 namespace 前缀。

8. 启动决议（主控视角）

结论：可以启动 C-1。

前置条件（C-1 第一个 PR 合并前必须关闭，4 项）：

MP-3 kelly_cap × I-1 不直接下单下游消费协议：cognition-1.1-contract §8 自承「未在契约层声明」。在 C-1 起手 PR 触及 posterior.kelly_cap 字段实现前，先单独立一段契约文本（建议挂在 cognition-1.1-contract §1 顶层契约后或单独 ADR）。不允许只在 PR audit trail 30 分钟 inline 决议——这是 owner map 当前归口路径，但作为主控我拒签这个路径用于战略不变量 I-1。
engineering/README.md 文档清单失修 + goal-execution.md 退出阅读顺序：以新的 4 份文档（product-definition / architecture / engineering-packs 入口 / subsystems 入口）+ 辅助文档（architecture-anti-bloat-guard / pending-decisions-owner-map）重写清单。删除 goal-execution.md 在「阅读顺序」mermaid 图中的位置。
agent-pack.yaml budget 修正：调整 max_tokens 8000 到至少 45000，且 cognition-1.1-contract 改 include_mode full。
agent-pack.yaml anchor 修正：「27-认证密钥治理」改为「17-边界与安全」（或同时增「17」锚点，删除「27-认证密钥治理」）。

启动后 M0 实施期间持续动作（不阻塞启动但必须并行推进）：

ADR-005 / ADR-006 / ADR-007 / ADR-009 起草开始（M0 期间动手，M1 启动前 accepted）
DA-1 ~ DA-4 真人 owner 指定（法务 + 数据治理）
m1-state-confirmation.md 工程包起草（M0 ai 节点 4 完成时启动）

主控自我约束：

作为 spec 起草人不参与同一份 spec 的 PR review；让人类工作流维护者签字
M0 验收人工 5 条 checklist 由维护者主导评分，AI 仅辅助
每次决议必须留 audit trail 段（不靠 session memory）

9. 给前 9 步 review 的元 review

我没读前 9 步 13 份 review 报告的内容，但我读了一些痕迹——pending-decisions-owner-map.md 显式承接「Step 5 RCA R6 整改表 4（F5）」，pr-review-checklist 承接「R6 整改表 1 + Step 3 Claude review §6」，ADR INDEX 承接「Step 5 RCA R6 整改表 3」。这些「整改承接」痕迹说明前 9 步 review 真的找到了真实问题并且回写进了事实源。痕迹强度判断：前 9 步 review 工程上不水。

我猜前 9 步可能漏掉的 3 件事（基于第一性原理推理）：

engineering/README.md 失修：13 份 review 集中在「契约 / ADR / 工程包内部」，可能没回头看 README 入口是不是把新增 6 份 engineering-pack + 4 份 subsystems 列进去。我亲眼看到 README 阅读顺序还引用 deprecated 的 goal-execution.md。
agent-pack.yaml budget 8000 token 与现实 38K+ 不符：前 9 步可能假设了 budget 已经合理，没人去算单文件 token。
主控自己 fresh-eyes 二阶漏洞：ADR-003 写「实施者不当自己代码的 reviewer」，但前 9 步全部由 Claude 主控或 Codex 互审完成，主控自己作为 spec 起草人当自己 spec reviewer 这个二阶 fresh-eyes 漏洞 ADR-003 没说、前 9 步可能没说、Step 9 round3 三份名字含 master/impl-lead/synthesis——我猜这恰好也是 AI 内部互审，没引入真人 fresh-eyes。这就是 §7 R1 的根因。

最后一句：72 percent 启动信心度的剩余 28 percent 风险，约 80 percent 来自主控自己作为 AI 同时承担六位一体职责的结构性 bias，约 20 percent 来自工程包 M1-M7 零起草。前者不是文档可以修的，是组织结构问题；后者可以按 R5 应对方案推进。

§10. 架构主文件完整 review 补充（§1-§29 全量通读）

§10.1 通读方法论

本轮补 review 对 projects/finbayes/engineering/architecture.md（6057 行 / 269K chars）执行完整通读，4 段覆盖：L1-900 / L900-1700 / L1700-3200 / L3200-6057。每章节都直读原文，不依赖 §28 / §29 章节地图反推。覆盖率自评：≥98%（仅极少跨章节交叉引用段未逐字校对）。原 step10 报告对 §4-§21 走「目录抽查」，本补 review 补上 §5 / §6 / §10-§14 / §15 / §16 / §17 后半 / §18-§19 / §20 / §22-§24 / §26 全部行级证据。

§10.2 章节逐项判断

§1 文档角色与读者（L103-130）

锚点：白皮书 §1（项目定位）+ 产品定义文档（认知任务清单）
承接：本章不定义契约，仅声明文档地位「工程实施仓代码必须可追溯到本文档某章节」
内部冲突：无
stale：无
主控判断：PASS

§2 上位继承与不变量（L132-211）

锚点：白皮书 §9（凭证立场、用户主权、事实空间、付费层级一致）+ §10 风险一/二
承接：§17 边界与安全（凭证 hook）+ §15 Credential Store + 工程包 m0-pack §10
内部冲突：L156-161「金融执行凭证 vs 本机配置秘密」两类秘密区分写得很清，与 §15 Credential Store L2752-2762 完全一致
stale：无
主控判断：PASS（最强） — L203-210 给出「快速核查 4 条 grep 项 + 实质语义双层」是 review gate 工程承接的范本

§3 架构目标与质量取舍（L214-273）

锚点：白皮书 §9 战略保真度
承接：§17 / §20 / §21 / ADR-001
内部冲突：L235「认知质量验收方法属于待定义的工程设计问题，详见 OQ-002 与后续 §20 / §21」— OQ-002 标识符在原 step10 报告未提及，但在本章被引用为「未决问题编号」，需 verify-kb 检查 OQ 编号体系是否在 status.md 有承接位
stale：L259-262「ADR-005 / ADR-008 / ADR-007 待写」与 §23 表 L4669-4671 显示 ADR-008 已 accepted（accepted ADR 表中）冲突 — §3 L260「大模型 Provider 走统一适配层（具体细节见 ADR-008 待写）」与 §23 ADR-008 accepted 状态矛盾 — 真实 stale
主控判断：RISK 中 — ADR-008 状态在 §3 与 §23 不一致；建议把 §3 L260 改为「详见 ADR-008」去掉「待写」

§4 业务对象与关系（L276-458）

锚点：产品定义 §3.1-§3.5 + ADR-008（已 accepted）
承接：§9 / §11 / §15 / §27（5 张表：业务对象/状态机/持久化/模块路径/M0 实现度）+ cognition-1.1-contract
内部冲突：L432-441 跨层对象映射表中 Watchlist「持久化 watchlist_objects 表 / 独立状态机无（由 StateCandidate 承载）」— 与 §11 L1801「Watchlist 与 Fin Object 没有独立状态机 — Watchlist 由 StateCandidate（候选）+ watchlist_objects 表（confirmed store）承担状态」一致。无冲突
stale：无
主控判断：PASS — 这章是全篇结构最齐的章节

§5 用户价值与认知流转（L460-521）

锚点：白皮书三层价值（想清楚 / 看全面 / 看本质）
承接：§6 业务场景 + §9 子系统
内部冲突：无
stale：无
主控判断：PASS

§6 关键业务场景（L524-639）

锚点：产品定义 §4-§5 + 七类任务清单
承接：§10 sequence + §20 端到端测试 + §21 评估场景集
内部冲突：新发现冲突 — L532-543 场景表标识 S1-S9 共 9 个场景，但 §10 L1474-1485 场景表标识 S1-S8 共 8 个场景。§6 S9「主动信号触发」对应 §10 S3「主动信号触发复盘」（编号错位），§6 S6/S7/S8/S9 与 §10 S6/S7/S8 编号语义不同。这是跨章节编号不一致 — 工程实施 Agent / 测试 Agent 读 §6 S6（交易准备未声明仓位）查 §10 S6 sequence 会拿到「边界拒收凭证」sequence，编号混乱直接导致测试 mapping 失误
stale：无
主控判断：GAP 关键 — 跨章节场景编号必须同名同号，建议主架构 §6 与 §10 统一改用 SC-1…SC-9 / SQ-1…SQ-8 区分（业务场景 vs sequence 流转），或重新排号一致

§7 系统与外部世界的关系（L641-757）

锚点：白皮书生态分工（FinBayes / Data Horizon / ATM / RLE / FEFM）
承接：§8 容器图（外部对手方）+ §16 跨网络外部通信
内部冲突：无
stale：无
主控判断：PASS — L716-720「FinBayes 与 ATM 没有直接连接」对应战略不变量 I-1 落锚清晰

§8 进程与服务划分（L759-899）

锚点：§3 部署形态取向（本地优先单进程）+ ADR-006（待写）
承接：§9 / §14 / §27
内部冲突：L886 写「§27 代码仓位置映射 — 本章不重复，避免双源漂移」是好做法。但 L888-897 仍列出入口子目录约定（cli/tui/web/mcp/channels），与 §27 L5740-5743 重复 — 不影响，是细节级冗余
stale：无
主控判断：PASS

§9 子系统组件（L902-1466，566 行大章）

锚点：§4 业务对象 + §8 容器图
承接：4 子系统文档（subsystems/*.md）+ m0-pack §2 接口子集表 + §11 状态机
内部冲突：新发现 — L1175-1268 State Management 子系统 §9.4 含「Active Signal Trigger」组件，但产品定义里「主动信号」对应 M5 才上线（原 step10 §3 表已说）。§9.4 在 M0 子系统组件层就列出该组件，但 §25 L5177 M0 包覆盖度表标注「§13 仅 L1 implement」未明确 §9.4 Active Signal Trigger 是 M0 implement / stub。工程实施 Agent 读 §9.4 会以为 Active Signal Trigger 是 M0 范围
stale：L1418 L3 Cache + Rule Engine 描述「精确缓存（Redis SHA256）+ 语义缓存（Redis Vector + bge embedding）+ 规则匹配」— 与 §15 Cache 段 L2702-2716「无 Redis 时进程内 LRU + L3b 语义缓存改用简单的 in-memory FAISS 或临时禁用」是两套口径。Redis Vector vs FAISS 在不同章节，工程实施会困惑选哪个
主控判断：GAP 中 — Active Signal Trigger 的 M0 范围标注必须显式；Redis Vector vs FAISS 选择需 ADR

§10 关键场景流转图（L1468-1782）

锚点：§6 业务场景
承接：§20 集成测试 + §11 状态机 sequence
内部冲突：见 §6 编号错位问题
stale：无
主控判断：GAP（与 §6 联动修复）

§11 状态对象生命周期（L1784-2018）

锚点：§4 业务对象 + ADR-007（待写）
承接：§9 子系统 + §15 持久化 + §27 状态机模块路径
内部冲突：L1801「Provider Readiness 是工程对象但承担跨子系统协调职责（Provider Adapter Pool 的探测状态 + 4 层降级触发器，详见 §9 / §13）」— 但 §9.6 L1416「Readiness Prober」组件只描述「runtime 启动 + 周期性 ping 各 Provider 端点」，没有展开 4 层降级触发器与 Readiness 状态机的对应。§11.6 Provider Readiness 也没有单独画状态机图（L1799 指回「详见 §9 § Provider Adapter Pool」，但 §9.6 没画状态机）— 状态机图缺失
stale：L1916「Updated --> []：旧 Judgment 进入复盘链尾」— [] 是终态语义，但「进入复盘链尾」不等于终结。状态图与文字解释语义不一致
主控判断：GAP 中 — Provider Readiness 状态机图必须在 §9 或 §11 真正落字；Judgment Record Updated 终态语义需要澄清

§12 并发与异步处理（L2020-2215）

锚点：§3 异步原语取向 + ADR-005（待写）
承接：§9 TaskGroup + §20 并发测试 + §27 trace.py
内部冲突：L2174 默认值「同时进行的 Task 数量 5 / 单 Task 内同时调用的工具数量 3 / 总 LLM 调用并发 10 / 数据 Provider 调用并发 20」— 这些数字是配置默认。但 §2 L184-190「与战略未决问题相关的参数全部走配置文件」明确禁止架构里写具体数值（必须是配置文件指针 / 占位符）。L2174 写了具体默认值，与 §2 L207-208「战略未决问题相关的参数文中未出现具体数值」冲突
stale：无
主控判断：RISK 低 — §12 默认值是工程级而非战略级，但形式上违反 §2 的「文中未出现具体数值」grep 核查。verify-kb 这条规则是否覆盖 §12 L2174 需明确

§13 故障与降级路径（L2217-2426）

锚点：§9.6 Provider Adapter + §17 边界 hook
承接：§20 降级测试 + §18 降级可观测性
内部冲突：L2398-2401「不降级的硬故障」表第 3 行「状态对象引用的 Fin Object 不存在（数据完整性破坏）」— 这是 M1+ 才可能出现的 case（M0 Fin Object 简单 created 标记，无引用完整性破坏可能）。但放在 §13 现在写，没标 M0/M1+ 边界
stale：无
主控判断：PASS — 整体降级哲学清晰

§14 部署形态（L2428-2603）

锚点：§3 本地优先 + ADR-006（待写）
承接：§15 数据目录约定 + §27 安装脚本
内部冲突：无
stale：L2547-2553 OS 平台配置/数据/缓存目录约定 — 与本仓 CLAUDE.md「正文不写本地路径」存在张力。L2551 macOS 标准目录是程序约定非个人路径，不违反规则，但需 verify-kb 路径检查规则确认豁免
主控判断：PASS（带 verify-kb 边界说明） — 建议 verify-kb 加白名单豁免 XDG/macOS/Windows 标准目录字符串

§15 数据存储划分（L2605-2815）

锚点：§14 部署形态 + §4 业务对象
承接：§19 schema migration + §27 store.py
内部冲突：L2649-2653 mermaid 图示 6 张表，但 L2674-2683 关键表 8 行（多 audit_trail / context_snapshots）。L2656 加注「mermaid 图为简洁起见仅画 6 类核心业务对象表」— 解决了文字冲突。无冲突
stale：L2696「runtime 启动时自动备份当前 SQLite 文件到 *.bak」与 §19 L3630 一致
主控判断：PASS

§16 通信协议（L2817-3023）

锚点：§8 容器图通信关系 + §17 协议安全
承接：§9 入口适配 + §19 contract_version
内部冲突：L2898 contract_version「新增 optional 字段不升 major」与 §19 L3583-3597 字段级演化规则完全一致
stale：无
主控判断：PASS

§17 边界与安全（L3025-3296）

锚点：§2 三大不变量 + ADR-010（已 accepted L4671）
承接：§9 边界 hook 落点 + §15 Credential Store + §20 边界测试 + §27 boundary.py
内部冲突：新发现 — L3111-3130 ADR-010 决策位置写「初步决策（待 ADR-010 确认）：两处都做」L3130「ADR-010 待定的具体阈值与正则集合」— 但 §23 L4671 显示 ADR-010 已 accepted。§17 仍把 ADR-010 标作待定、§23 标作 accepted，两章矛盾
stale：L3112 / L3130「ADR-010 待定」与 §23 accepted 状态严重不一致
主控判断：RISK 关键 — 这是 §3 ADR-008 stale 问题的同型问题。两个已 accepted ADR（ADR-008 / ADR-010）在主架构正文章节仍标待写/待定。verify-kb 需要新规则：所有「ADR-NNN 待写/待定」字符串必须与 §23 状态表交叉校验

§18 可观测性（L3298-3547）

锚点：§13 降级原因 + §17 边界事件 + §20 测试
承接：§9 trace.py + §27 observability/
内部冲突：无
stale：无
主控判断：PASS

§19 演化与版本管理（L3549-3865）

锚点：ADR-009（待写）
承接：§14 升级 + §15 schema_metadata + §16 contract_version
内部冲突：L3700-3722「prompt_id 命名约定」给出三段式「subsystem.purpose.variant」+ 示例 — 但 ADR-009 标待写。如果 ADR-009 最终决定不用混合策略（如纯走 prompts as data），则 prompt_id 命名约定与 ADR-009 决策结果可能冲突。当前是 §19 抢答了 ADR-009 未决议题
stale：L3681「初步倾向（待 ADR-009 确认）：混合」与 §23 L4684 ADR-009 口径一致，不冲突。但 §19 命名约定写得很详（L3700-3722），属于「在 ADR 未决议前抢先给细节」
主控判断：RISK 低 — §19 内容质量高但形式上 over-commit 了未决 ADR-009 的细节

§20 测试体系（L3867-4151）

锚点：§9 子系统接口 + §21 评估闭环
承接：§27 tests/ + CI 配置
内部冲突：L3964-3976「§6 列举的 9 个关键业务场景每个对应至少一组端到端测试」+ 表内列 S1-S6 与 S7-S9。但 §6 L532 9 个场景与 §10 L1474 8 个 sequence 编号错位（见 §6 GAP）。§20 测试覆盖表 L3964 也用 9 个编号，但 S2 标「状态确认」与 §6 S2「事件分析」语义完全不同！L3970 S2「候选 → 用户确认 → 持久化到 Watchlist」，但 §6 L536 S2「美联储这次讲话怎么看 — 分析类」— §20 端到端测试场景表写错了，与 §6 业务场景表语义不符
stale：见上
主控判断：GAP 关键 — §20 L3964-3976 端到端测试 S1-S9 与 §6 业务场景 S1-S9 完全错位。这是测试 Agent 写测试时会直接拿错 spec 的事故位

§21 评估闭环（L4154-4463）

锚点：§3 战略保真度 + §20 测试
承接：§9 综合层 + ADR-009
内部冲突：L4321-4322 阈值定义「overall_score >= 3.5/5 软阈值」「pass_rate >= 80

§20 测试体系（L3867-4151）

锚点：§9 子系统接口 + §21 评估闭环
承接：§27 tests/ + CI 配置
内部冲突：L3964-3976「§6 列举的 9 个关键业务场景每个对应至少一组端到端测试」+ 表内列 S1-S6 与 S7-S9。但 §6 L532 9 个场景与 §10 L1474 8 个 sequence 编号错位（见 §6 GAP）。§20 测试覆盖表 L3964 也用 9 个编号，但 S2 标「状态确认」与 §6 S2「事件分析」语义完全不同！L3970 S2「候选 → 用户确认 → 持久化到 Watchlist」，但 §6 L536 S2「美联储这次讲话怎么看 — 分析类」— §20 端到端测试场景表写错了，与 §6 业务场景表语义不符
stale：见上
主控判断：GAP 关键 — §20 L3964-3976 端到端测试 S1-S9 与 §6 业务场景 S1-S9 完全错位。这是测试 Agent 写测试时会直接拿错 spec 的事故位

§21 评估闭环（L4154-4463）

锚点：§3 战略保真度 + §20 测试
承接：§9 综合层 + ADR-009
内部冲突：L4321-4322 阈值定义 overall_score 阈值 3.5/5 软阈值、pass_rate 80 软阈值 — 这是工程级具体数值，§21 的阈值是工程评估而非战略未决问题（应豁免）。形式上无冲突
stale：无
主控判断：PASS — 是全文最完整的章节之一

§22 第一阶段缺口（L4465-4640）

锚点：§2 战略未决 + ADR 待写清单 + §3 / §17 / §19 / §20 / §21 第一阶段不做
承接：governance/change-protocol.md
内部冲突：L4506 ADR-004 任务识别策略 / 调研产物 / 已起草与 §23 L4669 ADR-004 accepted 一致。L4507 ADR-009 / §19 给出初步倾向（混合策略）与 §19 一致。L4508 ADR-010 / §17 给出初步倾向（两处都做）— 但 §23 ADR-010 状态已 accepted，§22 L4508 在「已经过深度调研但 ADR 待定」分组下列 ADR-010，与 §23 accepted 状态冲突
stale：L4508 ADR-010 状态描述错误（实际已 accepted）
主控判断：RISK 关键 — 与 §17 同型问题。§22 / §17 / §3 三处都把 ADR-008 / ADR-010 当待定，但 §23 已 accepted

§23 架构决策索引（L4642-4830）

锚点：ADR INDEX
承接：所有引用 ADR 的章节
内部冲突：L4669-4671 已 accepted 表：ADR-001 / 002 / 003 / 004 / 008 / 010。L4681-4684 待写表：ADR-005 / 006 / 007 / 009。共 6 + 4 = 10 ADR
stale：与 §3 / §17 / §22 关于 ADR-008 / ADR-010 状态的描述存在 3 处对外不一致；本表自身正确
主控判断：PASS（本表正确，问题在其他章节未同步） — §23 是 namespace 一致性的 source of truth

§24 风险登记（L4832-5086）

锚点：§3 质量取舍 + §22 缺口 + 各横切章节
承接：governance 风险登记
内部冲突：L4993-4994 E4 残余风险「模糊匹配未命中的边缘 case」+「当前缓解：输出端双层 hook（综合层语义 + Output Pipeline 格式，详见 ADR-010 待定）」— 再一次把 ADR-010 标作待定，与 §23 accepted 不符
stale：见 §17 / §22 同型问题
主控判断：RISK 同型 — ADR-010 在主架构 4 处（§3 ADR-008 / §17 / §22 / §24）被标待定或待写，但 §23 accepted

§25 与里程碑/任务的对应（L5089-5385）

锚点：ADR-001 范式 + §28 工程包
承接：m0-pack §1 范围表 + 各 milestone 工程包（M1-M7 未起草）
内部冲突：L5177 §13 故障与降级路径 M0 仅 L1 用户配置 Provider implement，L1prime / L2 / L3 / L4 全部 stub（详见工程包 m0-walking-skeleton.md §2 接口子集表）— 与原 step10 §5.2 的「自我消歧」描述一致。无冲突
stale：L5346-5354 里程碑依赖与并行表 — M6 评估闭环可与 M3-M5 并行，但 M6 包含 LLM-as-judge 需要 stable Prompt（ADR-009）+ stable schema（已有）。M6 与 M5 并行需要 M5 输出格式不变，§25 没有声明这个约束
主控判断：PASS（带 minor 注解）

§26 审计点（L5387-5623）

锚点：ADR-001 三检 + §17 战略保真度
承接：§20 测试 + §21 评估
内部冲突：L5424 机械断言「执行类工具 category 不在 Capability Registry」— 静态分析。但 §17 L3163 描述拒绝是「注册时（启动期）」，启动期是运行时不是 CI。静态分析能扫到所有工具注册调用 site 但扫不到运行时动态注册。审计断言层级与实施层级口径有差
stale：无
主控判断：PASS（minor 注解）— §26 表达「机械断言」覆盖静态可发现 case；运行时动态注册依赖 §17 注册器拦截

§27 代码仓位置映射（L5626-5898）

锚点：§9 子系统 + §4 业务对象 + §11 状态机 + §15 / §17 / §18 / §20 / §21
承接：FinBayes 工程实施仓 src/finbayes/
内部冲突：无（这章是单向映射，无内部对照）
stale：无
主控判断：PASS — anchor「27-代码仓位置映射」是正确的章节名（原 step10 §5.3 提到 agent-pack.yaml 写错为「27-认证密钥治理」是 yaml 的错，本章节本身正确）

§28 M0 工程包附录（L5900-5980）

锚点：§25 M0 / m0-walking-skeleton.md
承接：m0-pack 15 节
内部冲突：L5928 §14.5 CI 接口规范 / §14.6 M0 baseline 文件位置与格式 — 主架构 §28 自己声明 m0-pack 含 §14.5 / §14.6 子节，但原 step10 报告 §6.1 / §6.3 提到的 m0-pack 章节是 §1-§15。这里小节编号 §14.5 / §14.6 是 m0-pack 内编号，不冲突
stale：L5957 M1-M7 工程包待起草 — 与原 step10 §4.2 / §7 R5 完全一致
主控判断：PASS（with R5 警告）

§29 认知体系工程承接（L5982-6056）

锚点：ADR-007 supplement（whitepaper-rewrite namespace）+ ADR-008 supplement
承接：subsystems/ 4 份子系统文档
内部冲突：L5986「上位 ADR-007 supplement 状态为 accepted（持续构建）」+ L6011 引用「Phase 7 半人工标注 SLA 附录」+ L6012「Phase 5 迭代治理机制」— 引用都正确。但本主架构 §23 ADR-007 状态仍是「待写 / 中优先级」。§29 引用的是 cognition-system-research 工作流的 ADR-007 supplement（已 accepted），不是 arch-rewrite 工作流的 ADR-007（待写状态写入两步）。两个 ADR-007 同号不同物
stale：无（§29 引用语义清楚 — 显式区分了 supplement vs ADR）
主控判断：PASS — namespace 消歧在 §29 实施较好，但主架构其他章节引用 ADR-007 时几乎不带 namespace（如 §3 L261、§22 L4504 同理）—— 这就是原 step10 §7 R7 指出的同号消歧风险

§10.3 完整通读独有的新发现（抽查漏掉的）

按重要性排序：

N1 · ADR-008 / ADR-010 在主架构 4-5 处仍标「待写/待定」（§3 L260 / §17 L3111-3130 / §22 L4508 / §24 L4993）

§23 ADR INDEX 表显示 ADR-008 与 ADR-010 已 accepted（L4669 / L4671），但主架构正文章节 4-5 处仍把这两个 ADR 标作「待写」或「待定」。典型 stale。verify-kb 应该新加规则：所有「ADR-NNN 待写 / 待定」字符串必须与 §23 状态表交叉校验，任何 accepted ADR 在正文标待定 = 阻断。

N2 · §6 业务场景 S1-S9（9 个）与 §10 sequence S1-S8（8 个）编号错位，且 §20 端到端测试覆盖表 S1-S9 与 §6 语义完全不符

§20 L3964-3976 测试覆盖表 S2「状态确认（候选 → 用户确认 → 持久化到 Watchlist）」与 §6 L536 S2「美联储这次讲话怎么看 — 分析类」完全不是同一回事。这意味着测试 Agent 起草 S2 e2e test 时拿错 spec 的概率 = 100。修复优先级 P0。建议主架构 §6 / §10 / §20 三处的场景编号统一前缀（SC- 业务场景 / SQ- sequence / TC- e2e test），且互相显式引用。

N3 · §11 没给 Provider Readiness 状态机图（§11 表 L1799 指向 §9 / §13，但 §9.6 也没画状态机图）

§11 列了 6 个有独立状态机的对象 + 6 张状态机图，但 Provider Readiness 仅有文字描述「详见 §9 § Provider Adapter Pool」，§9.6 L1408「check_readiness()」接口段无状态机图。ADR-006（部署形态优先级）待写 + Provider Readiness 状态机图缺失 = M0 启动期 Provider 探测的状态机契约不存在。M0 工程包 ai-provider-shim 节点要落 readiness.py 时拿不到状态机图。

N4 · §9.4 State Management 子系统列出 Active Signal Trigger 组件，但未标注 M0 / M1+ 范围；§9.6 L3 Cache 写 Redis Vector + bge embedding，但 §15 写 in-memory FAISS 兜底 — 选型未拍

§9 子系统组件章节是契约层。M0 工程包 §1 表已自我消歧 §13 降级层级，但 §9 内部组件级未做同等消歧。Active Signal Trigger 在 M5 才上线（§25 M5 范围），M0 工程包 §2 接口子集表应该标 stub。verify-kb 应核查 §9 各组件描述与 §25 milestone 范围矩阵的对齐度。

N5 · §12 写出具体并发默认值（Task 5 / Tool 3 / LLM 10 / Data 20），违反 §2「文中未出现具体数值」grep 核查

§2 L207-208 自我承诺「战略未决问题相关的参数文中未出现具体数值（必须是配置文件指针 / 占位符）」。§12 L2174 直接写 4 个具体数字。verify-kb 这条 grep 规则若严格执行会拦截 §12。或者需要扩展 §2 的「战略未决问题相关参数」定义 — §12 并发限制是工程级而非商业模式级，应豁免。建议在 §2 加注「§12 并发默认值非战略未决参数，豁免本规则」。

N6 · §19 抢答了 ADR-009 未决议题的细节（prompt_id 三段式命名约定 L3700-3722）

§19 给出了 prompt_id 三段式 subsystem.purpose.variant + 5 个示例，但 §23 ADR-009 仍待写。如果 ADR-009 最终决定纯 prompts as data（策略 B 唯一），prompt_id 三段式约定就要重写。建议把 §19 L3700-3722 移到 ADR-009 草稿中，主架构只保留「待 ADR-009 决定」声明。

N7 · §11.4 Judgment Record Updated --> [*]（终态）但文字说「进入复盘链尾」，状态语义不一致

L1916 状态图「Updated --> []：旧 Judgment 进入复盘链尾」+ L1946「复盘链：Updated 不删除旧 Judgment」。如果旧 Judgment 仍可读、仍在数据库，进入 [] 终态语义与「不删除」+「形成版本链」冲突。状态机里 Active vs Superseded 是两个区别明确的状态，Updated 应该转 Superseded，而不是 []。建议状态机修正为 Updated --> Superseded --> []。

N8 · §17 写「LLM 辅助二次判断」对凭证识别 — 但调用前先脱敏。脱敏算法本身是凭证识别的事，递归依赖

L3087「LLM 辅助二次判断 / 对不确定 case 调小模型快速判断（注意：调用前已脱敏，不送原 token）」。如果调用 LLM 之前能脱敏，那脱敏算法就已经识别出凭证位置 —— 既然能识别为什么还要 LLM 二次判断？逻辑回环。或者脱敏是局部模糊（如「替换所有长 hex 串为 XXX」），那 LLM 收到的是 redacted text 也判不出原文是不是凭证。需要在 §17 澄清「脱敏 = 仅替换可疑高熵串」+ LLM 二次判断的真实目的是判断整段是否是凭证上下文（人贴 .env 文件的判断），而非判断单串是否为凭证。

N9 · §14 / §15 卸载流程对 OS Keychain 凭证清除的描述与 §17 一致 — 实际无冲突但落点分散

§14 L2586「OS Keychain 中的 Provider 凭证 / 默认行为：删除」+ §17 L3247「卸载权」+ §15 L2761「用户卸载 FinBayes 时自动清除该程序在 Keychain 中的所有凭证」。三处口径一致 → 实际上无冲突，但卸载 flow 应该明确归一位置（建议 §14 卸载段为权威）。

N10 · §29 引用 ADR-007 supplement 与主架构 §23 ADR-007（待写）同号不同物 — namespace 显式化只在 §29 实施

§29 L6008-6010 引用都显式带 namespace 路径（governance/workstreams/finbayes-cognition-system-research/decisions/）。但主架构其他章节引用 ADR-007 时几乎不带 namespace：§3 L261 / §11 / §22 L4503 都直接写「ADR-007」。读者无法快速判断当前章节引用的是哪个 ADR-007（cognition / arch / 还是其他）。建议 verify-kb 加规则：所有 ADR-007 / ADR-008 / ADR-009 引用必须带 workstream/ 前缀，除非在 §23 namespace 表内（即 arch-rewrite 工作流默认）。

§10.4 修正抽查版报告的判断

完整通读后，原 step10 §1 启动信心度 72 percent 应下调到 65-68 percent。

理由：

新发现 N1 / N2 是工程级 P0 阻断问题（不是治理 / 路径问题）。N1 让 ADR 状态可信度下降——工程实施 Agent 读主架构正文若仍把 ADR-008 当「待写」，会按倾向直接实施而不查 §23 实际已 accepted 的内容，形成 spec 与正文割裂。N2 让端到端测试在 M0 起手就有 100 percent 拿错 spec 的概率。
N3 / N4 把「启动 M0 ai-provider-shim 节点」的契约从「完整」降到「部分缺失」（Provider Readiness 状态机图缺）。
原 step10 4 P0 前置之外，需新增 3 个 P0 前置：
- P0-5 修正主架构 §3 / §17 / §22 / §24 对 ADR-008 / ADR-010 的「待写/待定」标注（与 §23 accepted 状态对齐）
- P0-6 修正主架构 §6 / §10 / §20 跨章节场景编号错位（建议用 SC- / SQ- / TC- 三套前缀，且互相显式引用）
- P0-7 §11 补 Provider Readiness 状态机图或 §9.6 补对应内容（M0 启动期 readiness.py 落地需要）

4 P0 前置（原报告）+ 3 新 P0 前置 = 共 7 P0。这些都是「修正 markdown 字段」级别工作量，1-2 个 PR 可关闭。但不修不能启动 M0。

5 战略不变量盘点不变（3 PASS / 2 GAP）。7 主控风险不变（R1-R7）。N1 / N2 应作为 R8 / R9 新增主控风险：

R8 · ADR 状态在主架构正文与 §23 ADR INDEX 之间存在 stale 漂移（accepted ADR 在正文仍标待写）— 这是新发现的结构性问题，因为主架构每次回写时只看局部章节，没人系统性扫所有「ADR-NNN 待写」字符串。
R9 · 跨章节场景/sequence/测试编号未统一前缀，存在测试 Agent 100 percent 拿错 spec 的事故位。

§10.5 元 review：抽查 vs 完整通读差距

差距汇总：

维度	抽查（原 step10）	完整通读（本补）	差距
文件级 stale 标记发现	engineering/README.md / goal-execution.md / agent-pack.yaml anchor 错	+ ADR-008 / ADR-010 4-5 处主架构正文标待写	抽查漏掉跨章节 stale
跨章节内部一致性	1 处（m0-pack 自我消歧 §25 早期描述）	新增 3 处冲突：§6/§10/§20 场景编号 / §11 Provider Readiness 状态机缺 / §12 vs §2 数值约定	抽查全部漏
章节内部小冲突	0	§11.4 Judgment Updated 终态语义 / §17 LLM 辅助二次判断逻辑回环 / §9.4 vs §25 M0 范围 / §9.6 vs §15 Cache 选型	抢答 ADR 细节
ADR 引用 namespace	1 处（agent-pack.yaml anchor）	主架构正文几乎全部不带 namespace 仅 §29 实施	抽查发现局部，完整通读发现系统性
启动信心度判断	72 percent / 4 P0	65-68 percent / 7 P0	新 P0 都是「修字段」级，工作量小但不修则 M0 起手有 spec bug

给后续 review 节奏的启示：

大文件（超过 5K 行）禁止抽查决议启动。本次 269K chars / 6057 行的 architecture.md 抽查发现的问题与完整通读发现的问题数量比约 1 : 2.5。如果 review 用于决策「是否能启动 C-1」，抽查严重低估了系统性风险（特别是跨章节 stale 与编号错位）。
建立 cross-章节-grep 检查。本补 review 发现的所有 N1-N10 都可以归类为「verify-kb 应该补的新规则」——它们都是机械可发现的，但 verify-kb 当前规则集不覆盖（如「ADR 状态与正文标注一致性」、「跨章节场景编号一致性」、「主架构数值豁免规则」）。建议给 scripts/verify-kb.mjs 加一组 cross-section consistency 子检查。
review 报告本身需要分层。原 step10 报告做了战略 / 上位对齐 / 切片可行性 / 风险登记五件事，但没专门留「主架构内部完整性」层——这就是为什么抽查能写出 252 行但仍漏掉 N1-N10。建议下次 review 报告结构强制含一段「主架构全文逐章节判断表」，即使只是 PASS/GAP 一字判断也比不写好。
主控 fresh-eyes 二阶问题在完整通读中加剧。完整通读 6057 行非常累，主控（我自己）读到 §17 时已 4000 行，对前文细节的记忆会衰减。这正是原 step10 R1 / R3 主控 fresh-eyes 二阶漏洞的实证：主控自己当自己 spec 的 reviewer 在大文件场景下不可持续。建议未来类似 review 强制至少一个章节由人类工作流维护者亲自走完整通读（不依赖 AI 转述）。

最后一句：原 step10 报告的判断「72 percent 启动信心度，可以启动 C-1，4 P0 前置必须关闭」在抽查口径下成立。完整通读后信心度下调至 65-68 percent、P0 前置增至 7 项。新增的 3 P0 都是「修字段」级（不是写新文档），工作量约 0.5 个 PR，不阻塞 C-1 启动节奏；但若不修，M0 第一个 ai 节点（cognition-schema / sqlite-ddl / provider-shim）就会撞上 spec 拿错（§20 vs §6 编号错位）或 spec 缺失（Provider Readiness 状态机）问题。

0. Review 边界与方法论声明​

1. 执行摘要​

2. 战略不变量盘点（第一性原理 5 条）​

3. 上位 → 下位 → 落地材料对齐评估​

4. 100 percent 落地保真度评估​

4.1 M0 范围保真度​

4.2 M1-M7 范围保真度​

5. 文件齐备性 / 冗余 / 冲突 / 无效​

5.1 冗余 / 无效文件​

5.2 冲突文件​

5.3 无效引用​

5.4 缺失文件​

6. 切片可行性（OpenSpec + Archon + Claude + Codex）​

6.1 token 估算​

6.2 跨文档反复 fetch 风险​

6.3 Archon 6 ai 节点切片合理性​

7. 主控视角的真正风险（7 条）​

8. 启动决议（主控视角）​

9. 给前 9 步 review 的元 review​

§10. 架构主文件完整 review 补充（§1-§29 全量通读）​

§10.1 通读方法论​

§10.2 章节逐项判断​

§1 文档角色与读者（L103-130）​

§2 上位继承与不变量（L132-211）​

§3 架构目标与质量取舍（L214-273）​

§4 业务对象与关系（L276-458）​

§5 用户价值与认知流转（L460-521）​

§6 关键业务场景（L524-639）​

§7 系统与外部世界的关系（L641-757）​

§8 进程与服务划分（L759-899）​

§9 子系统组件（L902-1466，566 行大章）​

§10 关键场景流转图（L1468-1782）​

§11 状态对象生命周期（L1784-2018）​

§12 并发与异步处理（L2020-2215）​

§13 故障与降级路径（L2217-2426）​

§14 部署形态（L2428-2603）​

§15 数据存储划分（L2605-2815）​

§16 通信协议（L2817-3023）​

§17 边界与安全（L3025-3296）​

§18 可观测性（L3298-3547）​

§19 演化与版本管理（L3549-3865）​

§20 测试体系（L3867-4151）​

§21 评估闭环（L4154-4463）​

§20 测试体系（L3867-4151）​

§21 评估闭环（L4154-4463）​

§22 第一阶段缺口（L4465-4640）​

§23 架构决策索引（L4642-4830）​

§24 风险登记（L4832-5086）​

§25 与里程碑/任务的对应（L5089-5385）​

§26 审计点（L5387-5623）​

§27 代码仓位置映射（L5626-5898）​

§28 M0 工程包附录（L5900-5980）​

§29 认知体系工程承接（L5982-6056）​

§10.3 完整通读独有的新发现（抽查漏掉的）​

§10.4 修正抽查版报告的判断​

§10.5 元 review：抽查 vs 完整通读差距​

0. Review 边界与方法论声明

1. 执行摘要

2. 战略不变量盘点（第一性原理 5 条）

3. 上位 → 下位 → 落地材料对齐评估

4. 100 percent 落地保真度评估

4.1 M0 范围保真度

4.2 M1-M7 范围保真度

5. 文件齐备性 / 冗余 / 冲突 / 无效

5.1 冗余 / 无效文件

5.2 冲突文件

5.3 无效引用

5.4 缺失文件

6. 切片可行性（OpenSpec + Archon + Claude + Codex）

6.1 token 估算

6.2 跨文档反复 fetch 风险

6.3 Archon 6 ai 节点切片合理性

7. 主控视角的真正风险（7 条）

8. 启动决议（主控视角）

9. 给前 9 步 review 的元 review

§10. 架构主文件完整 review 补充（§1-§29 全量通读）

§10.1 通读方法论

§10.2 章节逐项判断

§1 文档角色与读者（L103-130）

§2 上位继承与不变量（L132-211）

§3 架构目标与质量取舍（L214-273）

§4 业务对象与关系（L276-458）

§5 用户价值与认知流转（L460-521）

§6 关键业务场景（L524-639）

§7 系统与外部世界的关系（L641-757）

§8 进程与服务划分（L759-899）

§9 子系统组件（L902-1466，566 行大章）

§10 关键场景流转图（L1468-1782）

§11 状态对象生命周期（L1784-2018）

§12 并发与异步处理（L2020-2215）

§13 故障与降级路径（L2217-2426）

§14 部署形态（L2428-2603）

§15 数据存储划分（L2605-2815）

§16 通信协议（L2817-3023）

§17 边界与安全（L3025-3296）

§18 可观测性（L3298-3547）

§19 演化与版本管理（L3549-3865）

§20 测试体系（L3867-4151）

§21 评估闭环（L4154-4463）

§20 测试体系（L3867-4151）

§21 评估闭环（L4154-4463）

§22 第一阶段缺口（L4465-4640）

§23 架构决策索引（L4642-4830）

§24 风险登记（L4832-5086）

§25 与里程碑/任务的对应（L5089-5385）

§26 审计点（L5387-5623）

§27 代码仓位置映射（L5626-5898）

§28 M0 工程包附录（L5900-5980）

§29 认知体系工程承接（L5982-6056）

§10.3 完整通读独有的新发现（抽查漏掉的）

§10.4 修正抽查版报告的判断

§10.5 元 review：抽查 vs 完整通读差距