跳到主要内容

Step 10 Round Fresh · Codex 工程实施主力全量独立 review

0. 边界 + 方法论声明​

本轮按“C-1 第一个 PR 由我写”的视角重读当前源文档：战略白皮书、产品定义、架构抽样章节、M0 packs、4 子系统、ADR、Archon 与 agent-pack。历史 step review 正文未作为判断依据；只识别文件名以避开复用结论。判断均标【Evidence】或【Inference】。“跑通概率”定义为：按当前文档直接生成 C-1 schema + fixture + runner + gate，首轮 PR 不返工即可通过目标测试的概率。

1. 执行摘要​

  • 起手 PR 跑通概率：62%。
  • 冗余 / 无效 / 冲突 / 齐备 / 上位对齐：CONDITIONAL。
  • 100% 实现产品定义和架构所述范围：CONDITIONAL。C-1 只能交付 M0 walking skeleton，不能声称覆盖完整第一阶段。
  • OpenSpec + Archon + Claude 主控 + Codex 主力切片：当前 agent-pack FAIL；人工切片后 CONDITIONAL。

【Evidence】产品定义列 10 个用户可见输出要素 product-definition.md:307-318，并在 §7.3 列机制层 6 字段 + mca_bucket product-definition.md:351-360。M0 pack 声明 §3.5 只落最小子集 m0-walking-skeleton.md:123-126。【Inference】C-1 文档足以开工，但必须先锁几个口径，否则第一 PR 会在文档缝隙里返工。

2. C-1 起手能否真跑​

import surface​

【Evidence】M0 pack 路径写 src/finbayes/cognition/contract_v1_1_m0.py m0-walking-skeleton.md:249-250；contract test 从 finbayes.cognition.v11 导入 m0-walking-skeleton.md:1847-1855；Archon 产物写 cognition/types.py milestone-M0.yaml:55-67；cognition contract 草案也写 src/finbayes/cognition/types.py cognition-1.1-contract.md:148-151。【Inference】落点不是单一来源，C-1 会先遇到模块命名选择题。

schema_version​

【Evidence】§3 主体模型用 schema_version: int = 1；§3.5 _BaseM0 用 Literal["1.1-m0"] 并由 *M0 子类继承 m0-walking-skeleton.md:119-124、m0-walking-skeleton.md:274-284。contract test 同样按主体默认 1、M0 默认 "1.1-m0" 校验 m0-walking-skeleton.md:1835-1864。【Inference】版本默认值本身可实现；风险在 import surface。

safe eval​

【Evidence】sample 3 断言写 task is None and 'sk-abc123' not in str(audit_events) m0-walking-skeleton.md:971-972；runner allowlist 只有 any/all/len，且 __builtins__ 为空 m0-walking-skeleton.md:1958-1965。我用同等 globals 执行该表达式，得到 NameError: name 'str' is not defined。【Inference】当前 sample runner 会红。

fixture validate​

【Evidence】MCABucketM0 七轴字段 required，worst_axis/tag_version Optional m0-walking-skeleton.md:376-388。5 条 fixture 模板只写 mca_bucket: { bucket_label: B1/B2 }，并承认“实施时按 §3.5 七字段补齐” m0-walking-skeleton.md:1008-1041。【Inference】模板不能直接 Pydantic validate；C-1 必须生成完整七轴 fixture。

credential isolation​

【Evidence】产品定义要求凭证不进 Session、Judgment Record、Dynamic Profile、日志、训练数据或状态资产 product-definition.md:500-506；架构要求输入 hook 在 LLM 前拦截，且不写状态/审计 trail architecture.md:1698-1708。M0 test spec 覆盖 SQLite audit payload、fixtures/llm/、logs/ 三层 m0-walking-skeleton.md:1873-1880。【Inference】覆盖目标明确；但样例代码只展示 SQLite payload 检查 m0-walking-skeleton.md:1894-1901，目录 grep/log redact 需 C-1 补实现。

3. 文档 → 代码转译缝隙​

  • 字段对齐：【Evidence】contract 要 10 要素 + 6 字段，且 s1 必选、mca_bucket 属 Task 元数据 cognition-1.1-contract.md:22-31。M0 StructuredCognitionResult 只落 7 个内容字段，缺 multi_perspectives/prerequisites/follow_up_questions/historical_judgment_links m0-walking-skeleton.md:215-229；完整 body 才补齐 10 要素 cognition-1.1-contract.md:302-326。【Inference】若 C-1 只照 m0 pack 写，会与 agent-pack “10 要素 + 6 新增字段”期望不一致 agent-pack.yaml:99-101。
  • ConfigDict：【Evidence】完整 1.1 顶层 extra="ignore" 覆盖 1.0 extra="forbid" 是设计意图 cognition-1.1-contract.md:360-368；M0 _BaseM0 也用 ignore m0-walking-skeleton.md:410-414。【Inference】语义清楚，但实现测试要覆盖父类/子类合并。
  • AuditWriter：【Evidence】SQLite → JSONL → stderr+raise 三层 fallback 明确 m0-walking-skeleton.md:1579-1610；回放 _sync_back_jsonl 留 pass m0-walking-skeleton.md:1612-1618。【Inference】够写骨架，不够写完整恢复。
  • 凭证落点：【Evidence】ADR-010 已 accepted，决定综合层 + Output Pipeline 双处过滤 ADR-010-输出端凭证过滤位置.md:17-23；架构也有 boundary_check_output architecture.md:990-995。M0 pack §15 仍写 ADR-010 “待 accepted” m0-walking-skeleton.md:2042-2043。【Inference】实现应以 ADR-010 为准。

4. 跨文件一致性​

议题EvidenceInference
上位边界白皮书定位认知层 strategic-whitepaper.md:56-63；产品定义“不收不存不训练” product-definition.md:496-506；架构落到 I/O hook architecture.md:982-986对齐
10+6+MCA产品定义 §7/§7.3 与 contract §1 同向 product-definition.md:307-360、cognition-1.1-contract.md:22-31上位一致；M0 pack 是实现子集
LLM ProviderADR-008 M0 仅 L1、httpx、OpenAI-compatible ADR-008-LLM-Provider-接口抽象.md:17-25；架构是完整 4 层降级 architecture.md:1390-1430最小态 vs 目标态，不冲突
Data Providerdata-providers 明确 M0 不消费外部数据 data-providers.md:17-20；M0 pack 同样 mock-only m0-walking-skeleton.md:837-840C-1 不应做外部 adapter
MCAcontract 要 worst_axis/tag_version 必填 cognition-1.1-contract.md:95-99；M0 matrix 写 M1 收紧 milestone-field-evolution-matrix.md:20-23收紧路径清楚
M0 桶位MCA 子系统 M0 写固定 B1 mca-classifier.md:191-198；M0 sample 写 B1/B2 m0-walking-skeleton.md:1008分桶口径分歧

5. 切片可行性​

【Evidence】实测片段估算：m0 §3/3.5 ~3511 tokens，§8 fixtures ~1951，§11 ~467，§14.5 ~2062，cognition contract §1-6 ~5195，field matrix + ADR-008 + ADR-010 ~2118，Archon + agent-pack ~2460。【Inference】C-1 最小读取约 17.7k tokens；加产品/架构锚点约 20k+。

【Evidence】agent-pack 列 19 个 source agent-pack.yaml:13-90，预算 max_tokens: 8000、per_source_tokens: 1500 agent-pack.yaml:95-97，并要求不要绕过本包 agent-pack.yaml:119。【Inference】当前 pack 不可能完整承载这些 source；它是索引，不是自包含 implementation packet。

【Inference】m0-walking-skeleton.md 91K 单文件应拆成至少三包：schema/import、fixtures/runner、credential/audit。Archon 的 ai-cognition-schema、ai-sqlite-ddl、ai-provider-shim 可单 session；ai-eval-harness-m0 和 ai-semi-manual-sla 偏大。尤其 M0 pack 说“不上线 reviewer 工具串” m0-walking-skeleton.md:1077-1081，但 Archon 写 24h 双 reviewer/IAA artifacts milestone-M0.yaml:92-103，范围偏大。

6. 冗余 / 冲突 / 缺失​

  • legacy：当前 README 明确 legacy/ 只作历史追溯，不是事实源 projects/finbayes/README.md:21-33；engineering README 也标旧补充文档已归档 projects/finbayes/engineering/README.md:35-40。【Inference】legacy 风险低。
  • active 旧链：goal-execution.md 仍 active draft，README 标“待审视是否合并/归档” projects/finbayes/engineering/README.md:81-83。【Inference】实施者可能误读优先级。
  • 缺失/冲突清单：safe eval 缺 str；5 fixture 缺七轴；import path 三套；M0 7 字段 vs agent-pack 10 要素；MCA 固定 B1 vs fixture B1/B2；M0 pack 对 ADR-010 状态文字过期。
  • M1+ 越权：【Evidence】data-providers 锁 M2+ 数据源清单 data-providers.md:21-41，eval formulas 锁 D1-D11 全表 eval-harness-formulas.md:23-35。【Inference】作为路线图可接受，但 C-1 不能实现这些范围。

7. 工程实施主力位置的真正风险​

  1. import path 不统一导致首 PR 返工。
  2. sample runner 因 str 缺失直接红。
  3. fixture 模板不是可执行 fixture。
  4. agent-pack 8k 预算导致关键段截断。
  5. Archon 半人工节点超出 M0 pack 边界。
  6. 7 字段/10 要素验收口径不一致。
  7. MCA M0 分桶口径影响 EvalHarness 预期。

8. 启动决议​

因子对概率
上位边界、ADR-010、Provider M0 已收口+18%
schema_version 双轨有测试+10%
import surface 三套-12%
safe eval 必红-8%
fixture 七轴未展开-12%
agent-pack token 截断-14%

启动决议：Conditional GO。主控必须先锁 4 件事：1）M0 类单一模块落点；2）C-1 1.0 主体是 7 字段还是 10 字段；3）sample runner 是加 str 还是换 DSL；4）七轴 fixture 由主控补齐还是 Codex 在工程仓生成。

9. 给前 9 步 review 的元 review​

【Unknown】我未读取前 9 步 review 正文，不能判断某份报告具体漏了什么。

【Inference】如果前 9 步仍给出“可直接起手”的判断，则至少没有把这些工程红点升为启动阻断：str allowlist 必红、fixture 七轴缺字段、import path 三套、agent-pack 8k 不足、M0 7 字段 vs 10 要素、Archon 半人工节点超范围、MCA B1 vs B1/B2。

最终结论：文档可支撑 C-1，但不是直接可转译包；先锁口径，再写代码。

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

§10.1 通读方法论​

前面 §1-§9 是抽查 review，未通读 6057 行架构主文件。本节按 architecture.md 行段拆 3 段，每段独立 codex exec（不走 OMX $analyze，避免远程 compact 阈值），每段 read 对应行段 + 关键交叉文件。

  • 段 1：§1-§9，行 103-1467（约 64K chars）
  • 段 2：§10-§17，行 1468-3297（约 88K chars）
  • 段 3：§18-§29，行 3298-6057（约 116K chars）

覆盖率：100% 通读 §1-§29。每条判断带文件:行号 evidence；不重复 §0-§9 已写发现。

§10.2 段 1：§1-§9 完整通读补充（行 103-1467）​

§1 文档角色与读者​

  • 工程实施可转译性：PARTIAL。章节明确主架构角色是把战略/产品落到模块、接口、数据、部署（architecture.md:109、architecture.md:122-126），也给了写代码时的阅读路径（architecture.md:115）。但“遇到模糊点查 decisions/”和“Harness Workflow 与里程碑规范”没有在本节给具体文件路径，实施 Agent 仍需额外搜索，不能直接从本节跳到可执行入口（architecture.md:117、architecture.md:126）。
  • 下位承接：projects/finbayes/engineering/engineering-packs/m0-walking-skeleton.md；projects/finbayes/engineering/engineering-packs/cognition-1.1-contract.md；projects/finbayes/engineering/subsystems/*.md。
  • 内部冲突/stale：有。§1 说本文档落到“接口、数据、部署”（architecture.md:124），但本段覆盖的 §7 Data Horizon 接口仍标“生态协同契约章节（待起草）”（architecture.md:712），§1 对“可用总图”的承诺在生态接口上尚未闭合。
  • 新发现：§1 本身适合作为人读导览，不足以作为自动实施入口；建议后续补“从本节到 M0 pack / 1.1 contract / 4 子系统文档”的精确索引。

§2 上位继承与不变量​

  • 工程实施可转译性：PASS。战略边界可直接落成 runtime scope、工具注册拒收、状态写入禁凭证三类硬规则（architecture.md:142-144）；凭证条款给出输入拦截、状态/缓存/日志/审计不存、训练数据不入的机械承接（architecture.md:148-154）；用户画像不进证据筛选也有可测试语义（architecture.md:165-167）。
  • 下位承接：Input/Output Pipeline 的边界 hook（architecture.md:984-986）、State Management 的长期状态禁凭证与画像主权（architecture.md:1225-1229）、Capability Registry 的执行类工具拒收（architecture.md:1309-1328）。
  • 内部冲突/stale：无硬冲突。唯一实施缺口是“战略未决问题相关参数全部走配置文件”只列参数、不在本段给配置路径（architecture.md:185-193），需后文 §27/演化管理承接。
  • 新发现：§2 的 grep 必要条件适合作为文档 CI 最小 gate（architecture.md:203-210），但已明确“不替代实质语义 review”，所以不能只用字符串检查放行架构变更。

§3 架构目标与质量取舍​

  • 工程实施可转译性：PARTIAL。单进程、本地优先、asyncio、统一 Provider、两步写入、全量 audit 这些取向可直接转为工程约束（architecture.md:257-262）。质量属性表也能转成验收维度（architecture.md:231-240）。但认知质量评估方法仍指向待定义 OQ-002 / §20 / §21（architecture.md:234、architecture.md:238），不能独立生成完整测试套。
  • 下位承接：M0 pack 对 Pydantic、输出、凭证 grep、1.1 M0 schema、fixture 的自动判定有落地清单（m0-walking-skeleton.md:1270-1283）；EvalHarness 子系统承接 11 维评测和 Case Library 角色（eval-harness.md:13-24）。
  • 内部冲突/stale：有轻微口径分裂。§3 要“每个外部依赖有降级路径”（architecture.md:240），§9 Provider 给 L1-L4 全链路（architecture.md:1422-1430），但 M0 pack 明确 M0 仅实现最小子集/部分 stub（m0-walking-skeleton.md:123-126）。实施时需以 M0 pack 为阶段约束，不能按 §3/§9 全量实现。
  • 新发现：§3 的“响应性 vs 完整性”要求第一屏先出（architecture.md:247-249），但 §1-§9 尚未定义事件流 payload 字段；只能到后文或 M0 pack 找。

§4 业务对象与关系​

  • 工程实施可转译性：PARTIAL。7 个 first-class 对象、英文名、持久化表、状态机、模块路径、M0 实现列非常可转译（architecture.md:282-294、architecture.md:432-449）。但“认知结果”正文仍说“不固化字段表，按任务类型动态组合”（architecture.md:371-384），与下位 1.1 契约源的固定顶层契约不一致：1.1 明确 10 要素字段 + 6 顶层字段 + structured_result_version，且 mca_bucket 是 Task 元数据（cognition-1.1-contract.md:22-31）。
  • 下位承接：产品定义已把 5 个用户感知核心对象与工程派生对象分开（product-definition.md:155-163）；M0 pack 定义 1.0 主体字段和 1.1 最小子集（m0-walking-skeleton.md:215-229、m0-walking-skeleton.md:232-246）。
  • 内部冲突/stale：有。§4 把 StructuredCognitionResult 标为 M0 “implement”（architecture.md:438），但其正文“不固化字段表”会误导实现者跳过 Pydantic contract。应理解为“呈现层按任务类型动态组合”，不是模型字段动态。
  • 新发现：§4 对 Fin Object 类型覆盖很宽（标的、主题、事件、政策、关键人物、叙事等，architecture.md:322-331），但 M0 映射只说 FinObject implement（architecture.md:434），未在 §1-§9 给 object_type enum 或组合对象结构。

§5 用户价值与认知流转​

  • 工程实施可转译性：PARTIAL。三层价值能映射到任务识别、证据组织、综合层输出（architecture.md:468-472）；关键节点对 paraphrase-proof、Market Pack、第一屏题眼、两步沉淀、主动复盘都有明确业务约束（architecture.md:504-516）。但本节是业务流程，不给接口字段、事件流、状态候选 payload。
  • 下位承接：Task Orchestration 负责 LLM Function Calling、TaskGroup、clarify（architecture.md:1057-1069）；Evidence + Synthesis 负责 EvidencePlan / EvidencePacket / StructuredCognitionResult（architecture.md:1141-1156）；State Management 负责 candidate / confirmed（architecture.md:1231-1242）。
  • 内部冲突/stale：无明显冲突。
  • 新发现：§5 要“第一屏不暴露内部 trace、不只是字段列表、不退化为免责声明”（architecture.md:510），M0 pack 的 main_answer ≥30 字和非指令标注只能覆盖最低结构，不足以证明第一屏题眼质量（m0-walking-skeleton.md:222-229、m0-walking-skeleton.md:1274-1279）。

§6 关键业务场景​

  • 工程实施可转译性：PARTIAL。9 个场景覆盖任务类型和复合/主动信号（architecture.md:528-542），每个场景给出任务类型、认知要素、状态变化、业务约束（architecture.md:546-627），适合转成 scenario fixtures。限制清单也能直接转为 negative tests（architecture.md:631-637）。
  • 下位承接：M0 pack 的 5 条 sample fixture 位置和验收表达式承接部分场景（m0-walking-skeleton.md:1283）；EvalHarness 的 M0 子集接入 mock fixture（eval-harness.md:238）。
  • 内部冲突/stale：有阶段口径缺口。§6 把 S9 主动信号列入“第一阶段典型业务场景”（architecture.md:617-627），但 §4 映射 Watchlist / JudgmentRecord 为 M1+（architecture.md:435、architecture.md:439），StateCandidate 也是 stub（architecture.md:447）。如果“第一阶段”被工程误读为 M0，会把主动信号提前。
  • 新发现：S3/S6/S7 都有“仓位/风险预算/时间窗” gating（architecture.md:571、architecture.md:595-607），但 §1-§9 没定义持仓声明对象或输入字段，只在 Task Orchestration 图里作为 ContextLoad 文案出现（architecture.md:1023）。

§7 系统与外部世界的关系​

  • 工程实施可转译性：PARTIAL。边界图明确 7 类外部角色与 FinBayes 的连接（architecture.md:647-669），尤其 Trading Matrix 无直连、用户自主转交意图（architecture.md:676、architecture.md:716-720），可直接转成集成禁线。LLM/Data Provider 接触方式也可实现（architecture.md:694-706）。
  • 下位承接：Provider Adapter 负责 LLM/Data Provider 接入（architecture.md:1392-1408）；Capability Registry 拒收执行工具防止 Trading Matrix 能力混入（architecture.md:1309-1328）。
  • 内部冲突/stale：有。Data Horizon 接口契约仍“待起草”（architecture.md:712）；RLE 学习信号回流存在虚线未来关系（architecture.md:668）但又写“第一阶段范围：用户反馈采集 + RLE 接口契约”（architecture.md:726）。这两块在 §1-§9 不能直接编码，只能留 adapter placeholder。
  • 新发现：§7 对 FEFM 的处理很清晰：在 FinBayes 视角只是 LLM Provider（architecture.md:732-734），因此不应新增单独 FEFM 子系统。

§8 系统内部的进程与服务划分​

  • 工程实施可转译性：PASS。单进程、多入口共享 runtime、State Store 同进程库、Provider Adapter 为客户端模块都能直接落实（architecture.md:765-776）；容器职责、通信方式、入口目录也给了明确映射（architecture.md:846-858、architecture.md:862-872、architecture.md:884-898）。
  • 下位承接：M0 pack 的 src/finbayes/io/types.py、orchestration/types.py、cognition/types.py 等模型草案（m0-walking-skeleton.md:128-130、m0-walking-skeleton.md:215-229）。
  • 内部冲突/stale：无硬冲突。需要注意 Cache 写为“Redis 或内存”（architecture.md:856），通信表又说 Redis 通过本地客户端/进程内 LRU（architecture.md:869）；这是部署选择，不是接口冲突。
  • 新发现：§8 的“所有业务代码在 src/finbayes/ 下，按 6 子系统 + 入口适配分目录”（architecture.md:886）与 §9 后续 4 个认知体系子系统独立文档之间存在目录归属疑问：KnowledgeGraphService / ConsistencyMiddleware / MCAClassifier / EvalHarness 是否归入 6 子系统之一，§8-§9 没写。

§9 每个子系统的内部组件​

  • 工程实施可转译性：PARTIAL。6 子系统职责清楚（architecture.md:906-919），每个都有接口、失败模式、验收信号，主线数据流也闭合（architecture.md:1451-1464）。Input/Output、Task Orchestration、Evidence + Synthesis、State、Capability、Provider 都可拆任务（architecture.md:988-1011、architecture.md:1063-1087、architecture.md:1149-1172、architecture.md:1231-1268、architecture.md:1313-1342、architecture.md:1400-1445）。
  • 下位承接：4 个机制子系统文档补充主架构 §9 未展开的 1.1 字段生产/评测路径：KnowledgeGraphService 产 causal_graph / phase_evidence（knowledge-graph-service.md:13-22），ConsistencyMiddleware 产 s1（consistency-middleware.md:13-23），MCAClassifier 产 Task 元数据 mca_bucket（mca-classifier.md:13-38），EvalHarness 消费 1.1 全字段 + mca_bucket（eval-harness.md:24-38、eval-harness.md:152-154）。
  • 内部冲突/stale：有。§9 Evidence + Synthesis 只声明直接产 StructuredCognitionResult（architecture.md:1121、architecture.md:1155-1156），但 1.1 契约源要求 s1 必选且 mca_bucket 必选但不入本体（cognition-1.1-contract.md:29-31）；M0 pack 又把 s1 Optional、字段间约束不落 validator（m0-walking-skeleton.md:399-417）。因此 §9 主线不能单独作为 1.1 实施说明，必须同时加载 M0 pack + 1.1 contract + 4 子系统文档。
  • 新发现：Provider Adapter 在 §9 写 L1-L4 全链路并要求 L1 主失败自动 fallback（architecture.md:1426-1445），但 M0 pack 的 LLM 调用模型 is_fallback 注释为 M0 始终 False（m0-walking-skeleton.md:117-126上下文、m0-walking-skeleton.md:1268-1283验收只覆盖 schema/fixture）。这不是旧报告列过的“Provider 降级”红点，而是 §9 与 M0 验收口径的直接阶段错位。

段 1 完整通读独有的新发现（不重复 step10 原报告）​

  • StructuredCognitionResult 在 §4 被写成“动态组合、不固化字段表”（architecture.md:371-384），但产品定义与 1.1 契约已锁 10 要素 + 6 顶层字段 + Task 元数据（product-definition.md:163、cognition-1.1-contract.md:22-31）。应改成“字段契约固定，呈现/激活按任务动态”。
  • §9 的 6 子系统主线没有显式纳入 KnowledgeGraphService / ConsistencyMiddleware / MCAClassifier / EvalHarness，导致 1.1 字段生产链只能靠下位文档补齐（architecture.md:906-919 vs knowledge-graph-service.md:20、consistency-middleware.md:23、mca-classifier.md:38、eval-harness.md:24）。
  • Data Horizon / RLE 在 §7 被列为生态接口，但 Data Horizon contract 仍待起草、RLE 只说第一阶段采集接口契约（architecture.md:710-726），不能从 §1-§9 直接写真实集成，只能写 placeholder/stub。
  • S9 主动信号属于第一阶段场景（architecture.md:617-627），但 Watchlist / JudgmentRecord / StateCandidate 在 §4 均非 M0 完整实现（architecture.md:435、architecture.md:439、architecture.md:447），需要在工程任务包中显式标注 M0 不承诺主动信号闭环。
  • Provider Adapter 的 L1-L4 可用性承诺在 §9 很强（architecture.md:1390-1398、architecture.md:1422-1445），但 M0 验收主要覆盖 schema、输出、fixture 和有限 EvalHarness 子集（m0-walking-skeleton.md:1270-1283），实施时应避免把全降级链当 C-1 必做。

§10.3 段 2：§10-§17 完整通读补充（行 1468-3297）​

§10 关键场景流转图​

可转译性：整体可转译性高，8 个场景覆盖了第一阶段最关键的 e2e 入口：同步问答、复合 TaskGroup、主动信号、候选确认、Provider 降级、凭证拒收、clarify、长会话压缩（architecture.md:1472-1487）。S1 能直接变成端到端测试骨架：输入归一化、边界 hook、读上下文、加载工具池、LLM function calling、Evidence + Synthesis、审计、输出过滤、UserAnswerProjection（architecture.md:1500-1534）。S4 也能直接转成状态候选确认流：Candidate Buffer、确认、编辑确认、拒绝、清空当前 Session candidates（architecture.md:1607-1644）。S6 的凭证拒收序列位置正确，明确在 TO / LLM 前拦截，且不写任何状态对象 / 审计 trail（architecture.md:1692-1708）。

下位承接：§10 与后续章节衔接明确：场景关系表列出 S1 与 S2/S4/S5/S6/S7/S8 的派生关系，并说明状态对象生命周期由下一章承接（architecture.md:1768-1780）。可把 S1 作为基准 e2e，再对 Provider failure、clarify、candidate confirm 做参数化扩展。

内部冲突：S2 明确“任务 A 失败不阻塞任务 B”，最终归并时明示降级（architecture.md:1570-1572）；但 §12 的示意实现强调 asyncio.TaskGroup 任一子任务失败时自动取消其他子任务（architecture.md:2048-2051），并把这作为选择理由（architecture.md:2057-2061）。如果实现者照抄 §12，S2 的失败隔离会被破坏。这里不是概念冲突，而是可执行语义冲突。

stale / 待定：S5 标题和关键点都写“4 层降级”，但实际枚举是 L1、L1'、L2、L3、L4 五个命名层级（architecture.md:1648-1688）。若 L1' 是 L1 子层，应写成“4 类能力层 / 5 个路由节点”，否则测试矩阵会混。

新发现：S8 长会话压缩要求压缩失败时“Session 切断 + 新 Session 起 + 引用历史 Judgment Record”（architecture.md:1762-1764），但 §11 的 Session 状态机没有 FailedCompaction / Split / Fork 之类事件，只列 Active、Snapshotted、Archived、Deleted（architecture.md:1807-1835）。这会导致 e2e flow 里能写出失败分支，状态机里却找不到合法落点。

§11 状态对象生命周期​

可转译性：Session、Task、TaskGroup、Judgment Record、StateCandidate 都有 Mermaid 状态机和关键不变量，可直接转 enum + transition guard（architecture.md:1807-1978）。Session 删除不级联（architecture.md:1823-1835）、Task 终态不可逆与 Failed 可解释输出（architecture.md:1839-1870）、StateCandidate 状态（architecture.md:1950-1977）都能落测试。

下位承接：引用关系和生命周期独立性写得清楚：Session 引用 Task / TaskGroup / Snapshot / Fin Object，Judgment Record 引用 Fin Object / 创建 Session / 复盘链，StateCandidate 引用 Session 和目标 schema（architecture.md:1990-1997）；生命周期独立性也明确列出 Session、Judgment、Profile、Watchlist 之间不级联的删除边界（architecture.md:1998-2004）。这能承接 §15 的 SQLite 表和外键策略。

内部冲突：Judgment Record 生命周期从 Candidate 开始（architecture.md:1911-1928）；StateCandidate 也从 Pending 开始，并把 JudgmentCandidate 映射到 Judgment Record（architecture.md:1950-1985）。待确认判断到底是 judgment_records.state = Candidate，还是 state_candidates.type = JudgmentCandidate？两者不能同时作为主路径，否则确认、编辑、过期、审计会双写。

stale / 待定：本章开头说第 6 个 Provider Readiness 是独立状态机对象，承担 Provider Adapter Pool 探测状态与 4 层降级触发器（architecture.md:1788-1800），但本章没有展开 Provider Readiness 状态机，只说详见 §9 / §13。对实现来说，这一章标题承诺“每个有独立状态机的对象有哪些状态”（architecture.md:1784-1786），但 Provider Readiness 缺 enum、事件、终态和审计字段。

新发现：TaskGroup 状态机允许 Running --> Merged，同时又有 Running --> AllCompleted --> Merged（architecture.md:1874-1889）。若 Merged 是最终输出，Running 直接进入 Merged 会绕过“所有子任务终态”；若是增量 merge，又与“最终整合结果”定义冲突（architecture.md:1891-1905）。需区分 StreamingPartialMerged 与 FinalMerged。

§12 并发与异步处理​

可转译性：基础技术路线清晰：Python asyncio、Python 3.11+ asyncio.TaskGroup、CPU 密集任务进 executor、各层超时、Semaphore backpressure、阻塞调用 review gate（architecture.md:2024-2033、architecture.md:2145-2197）。这些能直接转成 asyncio runtime skeleton、pytest-asyncio 测试和 config 默认值。

下位承接：§12 承接 §10 的 TaskGroup 并发、§11 的 Task / TaskGroup 状态，且把失败隔离粒度分到 TaskGroup、Task、Evidence、Provider 四层（architecture.md:2093-2109）。测试约束也给出了并发、失败隔离、取消传播、超时、并发限制五类测试（architecture.md:2201-2213），适合成为工程任务清单。

内部冲突：最大问题是示意代码虽然标了“非最终实现”（architecture.md:2041-2043），但下面的“关键设计选择”又把同一行为正式化：任一子任务失败自动取消其他任务、ExceptionGroup 集中抛出、再由 merge_results 做 partial success（architecture.md:2048-2062）。这三句话放在一起不成立：如果异常逃出 TaskGroup，兄弟任务会被取消；如果要失败隔离，execute_task(t) 内部必须捕获可降级异常并返回 degraded result，只有不可恢复错误才让 TaskGroup 取消。当前文本会误导 Codex 写出“看似结构化并发，实际不满足 S2”的代码。

stale / 待定：ContextVar 段说 create_task 自动继承 context，又说 asyncio.to_thread 需显式转移（architecture.md:2063-2089）。后一条在现代 Python 语义下需复核；真正常需额外处理的是 run_in_executor 或第三方线程池。若不校正，会产生多余且不一致的 trace 传播代码。

新发现：用户取消语义中说“已完成的部分证据 / 部分结果保留至审计 trail”，并且用户会看到“部分结果已记录”（architecture.md:2112-2139）；§13 又说取消后可以基于审计 trail 中保留的部分证据“复活”任务（architecture.md:2366-2372）。但 §15 允许审计 trail 异步写入且“允许丢少量审计记录的边界 case”（architecture.md:2685-2689）。取消恢复依赖审计完整性，审计又允许丢失，这两个约束需要分级：普通 telemetry 可丢，取消恢复 / 状态变更 / 边界事件不可丢。

§13 故障与降级路径​

可转译性：总体降级哲学明确：明示、失败隔离、信息不足不硬编（architecture.md:2221-2229）。故障决策树覆盖输入边界、LLM L1/L1'/L2/L3/L4、工具、证据充足性、State Store、输出（architecture.md:2233-2298）。各模块矩阵也能转成错误码与 banner：LLM Provider 用户感知矩阵（architecture.md:2304-2315）、工具 / 数据源故障（architecture.md:2316-2326）、证据缺失处理（architecture.md:2327-2337）、State Store 降级（architecture.md:2339-2347）。

下位承接：§13 与 §16 错误码和 §18 可观测性承接强。降级事件要求记录层级、原因、时间戳、关联 Task / Session（architecture.md:2405-2414），§16 也提供了 PROVIDER_NOT_READY、EVIDENCE_UNAVAILABLE、STATE_STORE_READONLY、TASK_TIMEOUT 等跨协议错误码（architecture.md:2993-3009）。

内部冲突：决策树把 L3 缓存 / 规则命中接到 LLMOK（architecture.md:2241-2276），但 L3 本质是缓存 + 规则路径，不等同于 LLM 调用成功。若后续工具和综合层仍假设有 LLM 输出，就会把“受限模式”当“正常模型结果”。建议在实现模型中把 L3 输出类型拆成 ProviderResult 与 RestrictedRuleResult，否则 schema 校验和用户 banner 会混。

stale / 待定：Credential Store 不可用时退化为环境变量读取（architecture.md:2343-2347），而 §15 又强调 Credential Store 是 OS 系统凭证管理，金融执行凭证不进入 Credential Store，Credential 不通过日志 / 审计 / 序列化泄露（architecture.md:2740-2762）。环境变量是否允许作为 LLM / 数据 Provider key 的 fallback，需要更严：允许临时读取可以，但必须禁止 dump、禁止进入 config.yaml、禁止审计值、禁止长期缓存。当前一句话太宽。

新发现：配置错误要求“runtime 启动时明示”（architecture.md:2376-2388），但 §15 又支持 hot reload（architecture.md:2721-2737）。运行中热更新导致 key 失效或 URL 错误时，启动探测不够；需补“启动探测 + hot reload 探测 + task 前 readiness 快照”。

§14 部署形态​

可转译性：本地优先单机拓扑清楚：FinBayes Runtime 进程、LocalStore、OptionalLocalLLM、Browser/Terminal、CloudLLM/DataAPI/Data Horizon（architecture.md:2446-2497）。部署形态表也明确第一阶段本地优先和本地 + 远程 Provider 都支持，未来托管超出第一阶段（architecture.md:2432-2442）。

下位承接：§14 与 §15/§16 衔接较好。容器影响表把 State Store 从 SQLite 到未来 PostgreSQL、Cache 从本地到远程 Redis、Credential Store 从 OS Keychain 到云端密钥管理的演化列出（architecture.md:2501-2513）。安装初始化流程也承接了默认 Session 和 L3/L4 受限模式（architecture.md:2517-2542）。

内部冲突：Channel Adapter 被画在入口适配中，属于用户本机 Runtime 进程（architecture.md:2451-2456），§16 又说 Telegram 可走 HTTPS webhook 或 long polling，Discord 需要 HTTPS + WebSocket gateway，Slack 走 HTTPS webhook（architecture.md:2913-2930）。但 §16 同时规定 Web API / MCP 默认仅监听 127.0.0.1、外部网络访问被拒绝（architecture.md:2889-2893、architecture.md:2984-2989）。本地单机下 webhook 模式需要公网回调入口，和“外部访问拒绝”不兼容；第一阶段应默认 long polling / outbound-only，webhook 放到未来远程或显式 tunnel 配置。

stale / 待定：首次安装流程写“无 LLM 配置时进入 L3 / L4 受限模式”（architecture.md:2537-2540），但 L3 包含缓存与规则命中；首次启动通常没有历史缓存。这里应更精确：首次无 LLM 大概率直接 L4 受限菜单，只有内置规则可答的极少数查询走规则路径，不应暗示 L3 常态可用。

新发现：卸载默认行为中 OS Keychain 中的 Provider 凭证默认删除（architecture.md:2576-2587），但配置文件和 State Store 默认保留（architecture.md:2580-2585）。这符合安全优先，但会导致重装后有 providers.yaml 偏好顺序却没有 key。初始化流程需要识别“配置仍在、凭证已删”的半残留状态并引导重配，否则 Provider Readiness 会在重装后大量 401。

§15 数据存储划分​

可转译性：5 类持久化数据划分清楚：State Store / Cache / Config Store / Credential Store / Audit Trail（architecture.md:2605-2622）。SQLite 选择理由充分，关键表列出了 sessions、watchlist_objects、judgment_records、dynamic_profiles、state_candidates、fin_objects、audit_trail、context_snapshots（architecture.md:2662-2684）。用户数据动作也可直接转 CLI 命令和权限测试（architecture.md:2800-2813）。

下位承接：§15 对 §11 生命周期承接明显：Session 删除不删除 Judgment / Watchlist 的动作表与 §11 一致（architecture.md:2804-2811、architecture.md:1998-2004）。Credential Store 也承接 §17 的凭证不变量，明确金融执行凭证不进入 Credential Store，仅存本机配置秘密（architecture.md:2740-2762）。

内部冲突：审计 trail 同时是用户可查的解释链和可选 JSONL / SQLite 存储（architecture.md:2765-2784），但事务策略允许审计 trail 异步化并“允许丢少量审计记录”（architecture.md:2685-2689）。这与 §17 的边界事件审计、§13 的降级可观测性、§12 的取消恢复都冲突。应把 audit 分成 durable audit events 与 best-effort metrics/logs，前者必须事务性或至少 outbox 保证。

stale / 待定：本段只论证 SQLite，并在部署表里把未来托管 State Store 写为 PostgreSQL 候选（architecture.md:2508、architecture.md:2662-2670），但未说明为何第一阶段不用 Postgres / Neo4j，也未说明 JSONB/JSON 字段如何落 SQLite。candidate payload、Evidence DAG、audit payload 需要明确用 JSON1、TEXT JSON 还是拆表。

新发现：Cache 设计引入 Redis Vector、bge embedding、in-memory FAISS 或临时禁用（architecture.md:2701-2709）。这已经不是单纯缓存，而是语义检索组件，会牵涉依赖、embedding 模型、索引构建和隐私边界。若 M0/M1 实施按“Cache 可选”处理，L3b 语义缓存应明确为 later milestone；否则会把本地优先轻量部署复杂化。

§16 通信协议​

可转译性：通信关系按进程内、本机进程间、本机 UI、跨网络外部分四类（architecture.md:2821-2831），协议选择清楚。CLI/TUI/Web API/MCP/Channel 的入口形态都有基础协议与特征（architecture.md:2854-2930），可直接形成 adapter interface 和 smoke tests。

下位承接：进程内通信要求 Pydantic schema 校验，即使不走 RPC 也要跨子系统校验（architecture.md:2834-2851）。Web API contract versioning、错误码语义、协议演化策略都能承接后续 schema 版本化（architecture.md:2895-2900、architecture.md:2993-3021）。Provider HTTPS + Authorization 头也承接 §17 的网络与凭证传输约束（architecture.md:2934-2948）。

内部冲突：协议安全约束写“Web API / MCP 默认仅监听 127.0.0.1”（architecture.md:2984-2989），但 MCP Server 段写的是基于 stdio 的 JSON-RPC，无需 HTTP 服务（architecture.md:2901-2911），§17 也写 MCP Server 是 stdio、进程间、无网络（architecture.md:3201-3209）。把 MCP 写进“socket 限制”会误导实现者给 MCP 起监听端口。应改成“Web API 默认 127.0.0.1；MCP 默认 stdio，不监听 socket；若未来支持 MCP over HTTP 再受 localhost 限制”。

stale / 待定：LLM Provider 调用段说“所有 Provider 支持 SSE 流式响应”（architecture.md:2946-2948）。这对 OpenAI-compatible 主流云端大体成立，但“所有”过强，尤其本地 / 代理 / 自定义 Provider 未必可靠。实施时应按 capability discovery 标记 supports_streaming，否则 TUI/WebSocket 可能假设每个 Provider 都能流式。

新发现：Web API endpoint 列表有 /api/task/{id}/stream 且协议标为 WebSocket（architecture.md:2876-2888），但 REST 命名看起来像 GET endpoint；如果实现 FastAPI WebSocket，路径和 HTTP GET 查询需要分开声明。建议在工程包里明确：GET /api/task/{id} 是 HTTP，WS /api/task/{id}/stream 是 WebSocket，避免 OpenAPI / client 生成器把它当普通 GET。

§17 边界与安全​

可转译性：三条战略边界到工程承接位置清楚：凭证不变量、不得直接下单 / 持账户凭证、不替用户决策（architecture.md:3025-3039）。凭证端到端阻断图、凭证类型识别策略、安全回应、输出过滤、执行类工具注册拒绝、用户隔离、TLS、Prompt 注入、用户主权、Review Gate、安全可观测性都能拆成模块和测试（architecture.md:3043-3282）。

下位承接：本节与 §10 S6、§15 Credential Store、§16 协议安全、§18 可观测性都显式交叉引用（architecture.md:3286-3294）。用户特别提到 agent-pack anchor 把 §27 写成认证密钥治理但实际在 §17；当前源文档本身的边界与凭证治理确实在 §17，尤其 Credential Store 只在 §15 是存储承接，安全策略主语在 §17（architecture.md:3025-3294）。

内部冲突：凭证端到端阻断图画出 TaskFlow 绝不进入 State/Cache/审计 trail（architecture.md:3047-3074），但同节又说拒收事件进入审计 trail，只记录识别类型和时间戳（architecture.md:3103-3108），安全可观测性也要求输入边界拒收进入审计 trail（architecture.md:3269-3280）。语义上合理，但图的“绝不进入审计 trail”容易被理解成连拒收元事件也不记。建议改成“凭证原文绝不进入；脱敏拒收元事件进入审计”。

stale / 待定：输出端过滤写“初步决策（待 ADR-010 确认）：两处都做”，阈值与正则集合待定（architecture.md:3111-3130）。这不影响 M0 输入边界 hook，但会影响任何生成输出的 e2e test。如果 Codex 要写 §10 S1/S6 的完整验收，需先给最小输出过滤策略：高熵私钥样式是否剥除、banner 文案、审计字段。

新发现：执行类工具注册拒绝要求工具 schema category 枚举严格且“无 execution 选项”（architecture.md:3160-3165），但 Mermaid 拒绝机制又写 category in 'execution' 时拒绝（architecture.md:3150-3157）。如果枚举根本无 execution，反序列化阶段会先 schema invalid；如果要记录“尝试注册 execution 工具”的审计，需要 raw payload 预校验通道。当前文本少了这个两阶段校验边界。

段 2 完整通读独有的新发现​

  1. TaskGroup 失败隔离与 asyncio.TaskGroup 示例存在可执行冲突：§10 要求一个子任务失败不阻塞另一个（architecture.md:1570-1572），§12 却把“任一失败自动取消其他”作为结构化并发选择理由（architecture.md:2048-2061）。这是本段对工程实现最危险的误导点。

  2. 候选判断存在双主模型风险：Judgment Record 自己有 Candidate 状态（architecture.md:1911-1928），StateCandidate 又承载 JudgmentCandidate 到 Judgment Record 的转换（architecture.md:1950-1985）。需要决定待确认判断只落 Candidate Buffer，还是先建 judgment row；否则确认、编辑、过期和审计都会双写。

  3. 审计 trail 的可靠性等级没有分层：§12 取消恢复依赖审计（architecture.md:2135-2141），§13 降级解释依赖审计（architecture.md:2405-2414），§17 边界事件依赖审计（architecture.md:3269-3280），但 §15 允许审计异步且少量丢失（architecture.md:2685-2689）。这会直接影响可追溯性和安全验收。

  4. Channel webhook 与本地-only 网络边界冲突：§14 把 Channel Adapter 放在本机 runtime（architecture.md:2448-2493），§16 又列 Telegram/Slack webhook（architecture.md:2913-2930），同时禁止外部网络访问本机 API（architecture.md:2889-2893、architecture.md:2984-2989）。第一阶段应明确 outbound long polling 优先，webhook 不作为默认本地形态。

  5. SQLite 已被选定，但 JSON / 图谱 / 语义缓存边界还不够工程化：§15 论证 SQLite（architecture.md:2662-2670），但未说明 JSON payload 策略，也未解释为何不引入 Neo4j/Postgres JSONB；同时 L3b 引入 Redis Vector / bge / FAISS（architecture.md:2701-2709），会让“轻量本地优先”和“语义缓存增强”优先级混杂。

§10.4 段 3：§18-§29 完整通读补充（行 3298-6057）​

§18 可观测性​

可转译性：中高。审计 trail 事件类型已列出 task / provider / degradation / state / user action / boundary / proactive signal 等字段，能直接转成 AuditEvent payload 枚举（architecture.md:3317-3328）。trace ID 体系也足够落 session_id/task_id/tool_call_id/llm_call_id/trace_id（architecture.md:3377-3385）。指标名四类清楚，Provider 观测点覆盖调用前/中/后/失败（architecture.md:3389-3429, 3486-3497）。

下位承接：§27 已给出 state/audit.py、orchestration/trace.py、observability/metrics.py、observability/logging.py 和 CLI commands 的位置（architecture.md:5760-5769）。M0 里程碑只承诺审计 trail + task_id trace，不实现指标体系（architecture.md:5182-5183），这个边界有利于第一 PR 控制范围。

内部冲突：审计 trail 明确“不含完整 LLM 输入输出”，完整内容仅 debug 模式留存 N 天（architecture.md:3344-3346），但日志分级又允许 TRACE 写完整 prompt / 完整响应，并且只要求明示警告（architecture.md:3455-3473）。工程实现时这不是同一件事：审计表、debug 文件、TRACE 日志三者的存储位置、保留期、导出过滤规则没有单独 schema。若 Codex 直接实现，容易把 TRACE 当成普通日志落入可导出 diagnostic 包。

stale：§18 本身没有明显过期状态，但 M0 链路图只画 TO -.写入.-> Audit（architecture.md:5160），而 §18 图要求 TO/Tools/LLM/ES/SM/Output 都写审计（architecture.md:3365-3370），M0 验收又要求“完整 Provider 调用链”（architecture.md:5195）。这会让 M0 审计写入责任边界变窄。

新发现：可观测性缺的是“日志/审计/诊断导出”的三资产边界表。已有字段能写代码，但还不能防止 debug/TRACE 内容通过 diagnostic export 或 audit CLI 被误导出；这应成为 M0 logging/audit 的新增 negative test。

§19 演化与版本管理​

可转译性：中。接口 semver、数据 schema migration、Prompt、Provider、工具池五类资产拆分清楚（architecture.md:3553-3563），字段级 semver 规则可转成 contract diff 检查（architecture.md:3579-3604）。State Store migration 流程有元表字段和幂等约束（architecture.md:3617-3667）。

下位承接：M0 pack 已把 schema_version 写入 SQLite 元表和模型，且有 structured_result_version 的 1.1 最小子集策略（m0-walking-skeleton.md:575-578, 399-413）。契约源也把 1.0 body 与 1.1 additions 的合并语义锁定为 StructuredCognitionResultFullV11，顶层只暴露 structured_result_version（cognition-1.1-contract.md:349-368）。

内部冲突：migration 失败路径画成 Verify 失败 -> Roll -> Continue（architecture.md:3641-3644）。这对工程实现是危险信号：回滚到 bak 后是否继续启动、以旧 schema 只读启动、还是拒绝启动并要求用户确认，三个行为语义不同。当前图会诱导实现“失败也继续”，与“migration 失败时全量回滚到 bak，不留中间状态”不矛盾但不充分（architecture.md:3647-3655）。

stale：contract_version 缺失时“按最低支持版本处理或拒绝”是二选一未决（architecture.md:3605-3614），但 §26 要做 contract_version 正确递增机械断言（architecture.md:5454-5460）。如果不先锁缺失版本行为，协议层测试无法稳定写。

新发现：schema_metadata.migration_history 在幂等规则里是“JSON 数组，跳过已记录的 migration 文件名”（architecture.md:3650-3653），元表字段说明又是“from / to / timestamp / 备份位置”（architecture.md:3659-3667）。建议实现时把 history item 结构补成 {filename, from, to, checksum, backup_path, migrated_at}，否则幂等跳过和审计回溯各用一套字段。

§20 测试体系​

可转译性：高。单元、集成、E2E、LLM Mock、降级、边界、并发、测试数据、CI 分层都能直接翻成 pytest 目录和 fixture 策略（architecture.md:3896-4126）。录制重放的 hash 规则、fixture 入 Git、未命中 fail 也明确（architecture.md:3996-4027）。

下位承接：§27 已映射 tests/unit、tests/integration、tests/e2e/quick、tests/e2e/real、tests/degradation、tests/boundary 和 fixture 目录（architecture.md:5792-5804）。M0 pack 已给出对应测试目录树与 schema stability 测试（m0-walking-skeleton.md:1820-1864）。

内部冲突：§11 明确有 6 个独立状态机，含 Provider Readiness（architecture.md:1788-1801）；§27 也映射 6 个状态机（architecture.md:5701-5712）。但 §20 单元测试写“§11 的 5 个状态机的每个转移”（architecture.md:3902-3903），§26 M1 审计也写“5 个状态机”（architecture.md:5531）。这会让测试工程漏掉 Provider Readiness，正好是降级链最关键的状态机。

stale：§20 的 E2E 场景表仍把 S7-S9 写成“按当前任务类型清单”（architecture.md:3965-3975），但 §6 已明列 9 个场景（architecture.md:524-542）。测试工程最好直接落 9 场景 fixture，而不是把 S7-S9 留成自由口径。

新发现：CI 写每次 PR 跑端到端快档 + 边界 + verify-kb 且 15 分钟内完成（architecture.md:4113-4126），但集成测试又要求每个子系统至少 3 个跨子系统场景（architecture.md:3931-3958）。6 个通路子系统 + §29 4 个认知层子系统若都套“每子系统 3 场景”，PR 快档会膨胀到 30+ 集成场景，需在 M0/M1 分阶段明确哪些子系统进入 PR gate。

§21 评估闭环​

可转译性：中。Eval Set、Runner、Judge、Report、改进回路、Case Library、在线信号等概念可实现（architecture.md:4174-4203, 4206-4236, 4256-4286, 4371-4409）。评估运行器通过 runtime 公开 API 调用而不直接 import，是很好的工程边界（architecture.md:4281-4285）。

下位承接：§27 映射 evals/datasets、evals/runner、evals/rubrics、prompts/eval_judges、evals/results 和 evals/reports（architecture.md:5807-5817）。EvalHarness 子系统也明确输入 StructuredCognitionResult 1.1 + mca_bucket，输出 11 维评分和退化追踪（subsystems/eval-harness.md:13-24, 150-169）。

内部冲突：§21 评分 rubric 只有 8 个维度：反方、失效条件、证据归因、信息缺口、格式、表达密度、题眼、边界（architecture.md:4237-4252）。但 §29 明确认知体系承接的是 11 维评测 + 7 MCA 桶（architecture.md:5982-6004），ADR-007 supplement 和公式包也已把 D1-D11 固化（ADR-007-supplement.md:98-118；eval-harness-formulas.md:19-35）。如果按 §21 写 rubrics.yaml，会得到旧 8 维用户输出 rubric，而不是当前工程化 11 维 EvalHarness。

stale：§21 数据集规模写场景集 50-100 条（architecture.md:4206-4216），上位 Phase 4 已建议 8 个核心桶 × 20 = 160 起步样本，并落实 70/20/10（phase4-evaluation-system.md:271-284）。工程包 data-splits.md 已把 B5a/B5b 拆分后的 8 label 目录落成物理约定（data-splits.md:19-36, 104-120）。

新发现：§21 的硬阈值只管 regression failures 和 boundary violations（architecture.md:4323-4337），但 EvalHarness 当前还有 IAA kappa、桶内百分位最小样本量、bootstrap 带宽、D9 跨 ≥2 桶、D11 仅 B1/B2/B3 强制等条件（eval-harness-formulas.md:96-116, 212-214）。这些不是普通“软趋势”，至少要进 release 前的结构断言。

§22 第一阶段缺口​

可转译性：中低。缺口类别、触发条件和处理流程可转成 issue placeholder（architecture.md:4469-4483, 4572-4597, 4617-4625），但它更像“第一阶段不做事项”登记，不是 M0 缺口清单。

下位承接：§25 已把 M0 的 stub 范围单独列出，例如 L1' / L2 / L3 / L4 fallback 全 stub、指标体系暂不实现、migration 不实际触发（architecture.md:5175-5184）。这些 M0 缺口没有回写到 §22，导致 §22 无法作为 M0 issue tracker 的直接种子。

内部冲突：§22 写 ADR-004 至 ADR-010 共 7 条待定（architecture.md:4477-4482），并在“已经过深度调研但 ADR 待定”里列 ADR-004、ADR-009、ADR-010（architecture.md:4502-4509）。§23 与 ADR INDEX 则显示 ADR-004、ADR-008、ADR-010 已 accepted，待写只剩 ADR-005/006/007/009（architecture.md:4662-4685；decisions/INDEX.md:19-24, 38-40）。这不是单条 ADR 状态过期，而是 §22 缺口分类整体未同步。

stale：§22 把 OQ-002 说成“认知质量验收最终方法”待上线后数据积累（architecture.md:4499-4501），但 §29 + EvalHarness 已经把 11 维、MCA 分桶、70/20/10、IAA/SLA 作为工程承接索引（architecture.md:5982-6004）。OQ-002 可继续开放，但不能再让 §21/§29 看起来只是“第一阶段建议”。

新发现：缺口管理动作要求“工程实施仓 issue tracker 留 placeholder”（architecture.md:4617-4624），但 §27 又说工程实施仓物理路径不写本仓（architecture.md:5637-5640）。主架构需要给 placeholder 的抽象 ID 规则，否则 Codex 无法从本仓追踪缺口到工程仓 issue。

§23 架构决策索引​

可转译性：高。namespace、状态枚举、accepted/待写表、编号变迁、ADR 编写规范都能直接支持 review gate（architecture.md:4646-4685, 4694-4775）。

下位承接：ADR INDEX 对 namespace 消歧写得比主文档更强，明确 arch-rewrite ADR-008 是 Provider，whitepaper ADR-008 是 StructuredCognitionResult（decisions/INDEX.md:11-13, 30-36）。§23 主文档同步了这个方向（architecture.md:4650-4658）。

内部冲突：§23 自身基本一致；问题在下游章节复用 ADR 编号时仍有漏网。§27 业务对象映射写“Pydantic v2（详见 ADR-008 待）”（architecture.md:5693-5696），但本 namespace ADR-008 是 LLM Provider 接口且已 accepted（architecture.md:4670）。这是一个 namespace 口径滑回旧状态的证据。

stale：ADR 编写规范要求 accepted 后不直接改原文、只追加 superseded 关系（architecture.md:4770-4775），但当前主文档多个章节仍以内联“待定/待写”承载已 accepted ADR 的结论。后续不要只改 ADR 文件，应同步主文档引用段。

新发现：§23 的待写 ADR 段说 M0 不阻塞，实施 Agent 按当前倾向执行并在 PR 描述标注（architecture.md:4675-4685）。但 §19 Prompt 版本化和 §21 judge prompt 都会影响评估可复现（architecture.md:3670-3723, 4301-4307）。ADR-009 若拖到 M1+，M0 可以不做 Prompt as Data，但必须至少锁 judge/system prompt 的 prompt_id/prompt_version 字段，否则 M0 baseline 无法复跑。

§24 风险登记​

可转译性：中高。T/B/E/V 风险条目都有可能性、影响、当前缓解、残余风险和触发动作，可转成 risk register YAML 或 release checklist（architecture.md:4832-5050）。

下位承接：T5 schema migration 对 §19 有回链（architecture.md:4899-4907），E1/E2/E3/E4 对 §17/§20/ADR-010 有回链（architecture.md:4955-4995），V5 对 §21 的 Goodhart 软阈值设计有回链（architecture.md:5041-5049）。

内部冲突：风险汇总表 P2 数量写 9，但列出的风险是 T2/T4/T5/B3/B4/E2/E3/E4/V2/V3/V4 共 11 个（architecture.md:5053-5059）。这是机器可检出的汇总错误，会污染风险燃尽图或里程碑 audit report。

stale：E4 当前缓解仍写“详见 ADR-010 待定”（architecture.md:4987-4995），而 §23/ADR INDEX 已 accepted（architecture.md:4669-4671；decisions/INDEX.md:24）。这条虽然与 step10 的 ADR-010 stale 同源，但在风险登记里有额外后果：E4 的 mitigation status 可能被自动报告为未决。

新发现：风险表没有单列“评估体系版本错位 / 8 维 vs 11 维 / MCA 桶标签漂移”的风险。V2 只覆盖 Prompt 版本错位（architecture.md:5011-5019），V5 只覆盖 Goodhart（architecture.md:5041-5049）。结合 §21/§29 的差异，应新增一个 Eval Contract Drift 风险。

§25 与里程碑 / 任务的对应​

可转译性：高。M0-M7 范围、增量、验收和依赖表清晰（architecture.md:5105-5355）。M0 特别把 implement/stub 边界写清楚：仅 L1 用户 Provider，fallback stub；Cache/Credential/Config 简化；指标不实现；migration 不触发（architecture.md:5163-5185）。

下位承接：§28 M0 工程包确实存在，且 M1-M7 工程包文件目前不存在；engineering-packs/ 只有 M0、cognition contract、data/eval 辅助包和 matrix（wc 输出显示 m0 2052 行，未见 m1-m7 文件）。§25 的 M1-M7 因而还只是 milestone skeleton，不是 task packet。

内部冲突：§25 开头说“本架构文档的 27 章如何映射到工程实施仓”（architecture.md:5089-5101），但当前主文档已有 §29，§28/§29 正是落地映射附录。这个数字 stale 会影响自动生成章节追踪表。

stale：M6 依赖表写 M6 只必须前置 M2，可与 M3/M4/M5 并行（architecture.md:5351-5355）。但 EvalHarness 消费 causal_graph、phase_evidence、s1、mca_bucket，并要按 7/8 个 MCA label 分桶（subsystems/eval-harness.md:150-178）。如果 M4 市场扩展和 §29 认知层 stub 不够，M6 只能做 M0 子集，不应叫“完整闭环”。

新发现：M0 验收只要求 5 条手工样例 + 5 类凭证（architecture.md:5187-5196），但 §26 M0 审计还要求全部机械断言 + 结构断言（architecture.md:5514-5523）。M0 OpenSpec 需要以 §26 为准，把机械/结构断言列成 CI，不然 §25 的验收口径偏轻。

§26 审计点​

可转译性：中高。三检、四类断言、阻断条件和 PR 审计执行模型都很适合转成 CI + review checklist（architecture.md:5391-5413, 5416-5510, 5539-5594）。

下位承接：§27 映射 scripts/audit_strategy_fidelity.py 和 scripts/audit_contract_regression.py（architecture.md:5820-5829）。M0 pack 也有三检 Review Gate CI 模板和 CI 接口规范（architecture.md:5927-5929）。

内部冲突：战略保真度机械断言要求 grep private_key/mnemonic/api_secret 等字段名 0 命中，白名单仅“边界 hook 测试 fixture”（architecture.md:5420-5427）。但 M0 工程包和本架构文档本身大量包含这些词用于规则/测试说明。实现脚本必须限定工程仓代码/schema/config 路径，排除文档、测试样例和 credential pattern source，否则会常态误报。

stale：M2-M7 审计点完全下放给 OpenSpec 提案（architecture.md:5533-5535）。对 M1 后里程碑来说这可以接受；但 M6/M7 是评估和演化能力本身，若没有主架构最低审计点，OpenSpec 容易漏掉 11 维评测、migration 回滚演练、Prompt 版本可追溯这些跨包要求。

新发现：审计执行模型把“每次审计结论”写进 release notes + 审计 trail（architecture.md:5571-5582），但 runtime 审计 trail 是用户资产，记录 task/provider/state（architecture.md:3317-3347）。工程里程碑审计记录不应进入用户 runtime audit trail；应另设 engineering audit log / PR artifact。

§27 代码仓位置映射​

可转译性：高。src layout、6 通路子系统路径、业务对象、状态机、存储、通信、安全、可观测、Prompt、测试、评估、CI、配置、脚本都有明确路径（architecture.md:5630-5854）。

下位承接：agent-pack 把 architecture.md 作为 canonical source，但锚点写了 ["17-状态对象生命周期", "25-里程碑映射", "27-认证密钥治理"]（agent-pack.yaml:42-46）。实际 §27 标题是“代码仓位置映射”（architecture.md:5626-5628），这会让 anchor-based loader 找不到关键路径映射。

内部冲突：§27 顶层用 evals/（architecture.md:5651, 5807-5817），agent-pack output 却期待 eval/runner.py（agent-pack.yaml:106-108）。这会在 C-1 建目录时产生 eval vs evals 分叉。

stale：输出端凭证扫描仍写“ADR-010 决策后定”（architecture.md:5747-5757）。业务对象映射的“Pydantic v2 详见 ADR-008 待”也过期且 namespace 错位（architecture.md:5693-5696）。这两处属于 §27 直接影响代码落点的 stale，不只是文案。

新发现：§27 说每个 module docstring 含章节引用（architecture.md:5857-5867）。这是可追溯性好习惯，但如果自动 gate 强制每个模块都含 CHAP-NN，测试/fixture/迁移脚本会被污染。建议只对 src/finbayes/** 公共模块强制，migrations/tests/evals 用文件头 metadata 或 PR 描述追踪即可。

§28 M0 工程包附录​

可转译性：中高。§28 本身是索引，明确 M0 工程材料集中在 m0-walking-skeleton.md，并列出 15 节内容（architecture.md:5900-5932）。这比把代码草案塞主架构更可执行。

下位承接：M0 pack 实际存在且比主文档描述更厚：当前 m0-walking-skeleton.md 为 2052 行，而 §28 写约 1640 行（architecture.md:5932；wc evidence）。M1-M7 工程包文件在 engineering-packs/ 下确实未出现，§28 的“待起草”属实（architecture.md:5952-5965）。

内部冲突：Agent 消费路径建议 M0 实施 load M0 pack + 主架构 §17 + §27（architecture.md:5943-5951），但本段通读显示 M0 logging/audit 还必须 cross-check §18，测试/CI 必须 cross-check §20/§26，1.1 最小子集必须 cross-check §29。当前消费路径偏窄。

stale：§28 说主架构 6500 行 + M0 工程包 1600 行合并为 8000+ 行（architecture.md:5934-5942）；当前主架构 6057 行，M0 pack 2052 行，合计仍约 8109 行但构成变化了。若后续用行数估 context，需要刷新。

新发现：横向关注点合订包 horizontal-concerns-bundle.md 标为待起草（architecture.md:5965）。从 §18/§19/§20/§26 看，这不是锦上添花，而是 Codex 起 M0 的缺口：logging/audit、schema migration、CI gate、contract regression 横切多个模块，单靠 m0 pack 会漏边界。

§29 认知体系工程承接​

可转译性：中。§29 作为索引本身清晰，4 子系统、核心输出、上位事实源、依赖图、M0/M1-M3/v2 路径都有（architecture.md:5982-6056）。subsystems/README.md 与主文档基本一致，4 个文件也都存在（subsystems/README.md:22-44）。

下位承接：KnowledgeGraphService、ConsistencyMiddleware、MCAClassifier、EvalHarness 都有职责、接口、数据流、测试、v1 回退、待解决问题和里程碑映射（subsystems/knowledge-graph-service.md:13-22, 100-183；subsystems/consistency-middleware.md:23-72, 95-179；subsystems/mca-classifier.md:13-40, 122-198；subsystems/eval-harness.md:13-37, 150-239）。这说明 §29 不是空索引。

内部冲突：§29 反复写“7 MCA 桶”，同时列 B5a/B5b（architecture.md:5982-6004）。上位 ADR-007 也写“7 MCA 桶（R1 拆 B5）”但实际列出 B1/B2/B3/B4/B5a/B5b/B6/B7 共 8 个 label（ADR-007-supplement.md:118）。工程实现必须区分“7 分轴”和“8 个 bucket label”，否则 enum、目录、聚合报告会数错。

stale：§29 说 M1-M3 补齐 phase_matrix.cells、correlation_regime.pair_correlations、s1.second_order_branch、regulation_status.friction_layer 等（architecture.md:6050-6054），但 §25 把 M7 才定义为演化能力、M6 才完整评估闭环（architecture.md:5302-5340）。如果 M1-M3 就补齐太多认知字段，会和 milestone thicken 节奏冲突。

新发现：§29 的 4 子系统与 §27 的 6 通路子系统“正交”，但 §27 没给这 4 子系统的代码路径。现在 §27 只有 src/finbayes/cognition/、state/、providers/ 等通路路径（architecture.md:5668-5678），没有 knowledge_graph_service、mca_classifier、eval_harness 的落位规则。Codex 实施 §29 时会自行发明路径。

段 3 完整通读独有的新发现（5-8 条）​

  1. migration 失败后继续启动的语义危险：§19 图示 Verify 失败 -> Roll -> Continue（architecture.md:3641-3644），但没有定义继续启动的 schema 版本、只读模式或拒绝策略。
  2. 状态机数量在测试/审计处漂移：§11/§27 是 6 个状态机（architecture.md:1788-1801, 5701-5712），§20/§26 写 5 个（architecture.md:3902-3903, 5531），会漏 Provider Readiness。
  3. §21 仍是旧 8 维 rubric，未升级到 §29/ADR-007/EvalHarness 的 11 维 + MCA 分桶（architecture.md:4237-4252, 5982-6004；ADR-007-supplement.md:98-118）。
  4. §22 缺口清单整体 stale：仍把 ADR-004 至 ADR-010 当 7 条待定（architecture.md:4477-4482），而 §23/INDEX 已只剩 ADR-005/006/007/009 待写（architecture.md:4662-4685；decisions/INDEX.md:19-24, 38-40）。
  5. 风险汇总数错：P2 数量写 9，但实际列 11 个风险（architecture.md:5053-5059），会污染自动 risk report。
  6. §25 章节数 stale 且 M6 依赖偏弱：文档说映射 27 章（architecture.md:5089-5101），当前已有 §29；M6 只依赖 M2（architecture.md:5351-5355），但 EvalHarness 实际依赖 §29 4 子系统和 MCA 分桶。
  7. §27 的代码路径映射被 agent-pack 错锚点截断：agent-pack 写 27-认证密钥治理（agent-pack.yaml:42-46），实际 §27 是代码仓位置映射（architecture.md:5626-5628）。
  8. §29 4 子系统没有进入 §27 代码仓路径表：主文档给了认知层子系统索引，却未规定工程仓物理目录，Codex 会在 cognition/、state/、evals/ 之间自行选择。

启动信心度修正​

原 step10 给 C-1 起手 PR 跑通概率 62%。本段完整读完后，我建议下修到 58%。

下修理由不是 M0 主链更差，而是横向章节暴露了会直接影响第一 PR gate 的新不确定性：可观测性三资产边界未锁、migration 失败语义危险、测试/审计状态机数量不一致、§21 评估 rubric 未升级、§27 代码路径与 agent-pack 锚点漂移。它们不会阻止写出 M0 主流程，但会增加首轮 PR 在 CI/audit/review 上返工的概率。

仍保留 Conditional GO：M0 pack 和 §25 的 implement/stub 边界比主架构更具体，§18/§20/§26 给足了审计与测试方向，§29 的 4 子系统也确实有独立文档承接。条件是主控在开工前补一张 C-1 implementation packet：统一 evals/ 路径、状态机 6 个、M0 审计事件责任、§21 采用 11 维子集而非旧 8 维、§27 补 4 子系统落位。

元 review​

段 3 的主要价值不在再次证明 M0 主链能不能跑，而在暴露“主架构后半段的治理/质量/落地映射层”仍有几处异步更新。前 9 步和 step10 抽查抓住了 schema、fixture、import、ADR-010 等起手红点；本次完整通读新增的是另一类风险：章节索引、测试口径、评估维度、risk summary、agent-pack anchor、代码路径映射这些“不会马上让代码 import fail，但会让实施 Agent 选择错误验收面”的问题。

我的判断：完整架构已足够支撑 M0 实施，但不能把 §18-§29 当作完全同步的工程契约直接喂给 Codex。最小修复不是重写主文档，而是为 C-1 单独生成一页“段 3 补充约束”：6 状态机、11 维评测 M0 子集、runtime audit vs engineering audit 分离、evals/ 单一路径、§29 4 子系统路径、migration failure stop policy。这样可把 58% 拉回 65% 左右。