跳到主要内容

Codex 评审结论（L3 §7–10）

总评​

§7–9 大方向可用，基本守住 L2 一主四辅、五能力域、运营控制面、消费者优先级、G6 未冻结边界。暂不能放行 §11–29：主要卡在 §8 把「信息资产库与检索」弱化为存储设施、§10 时序跳过/压缩 Perception Record 与 Delivery Artifact。

必修 blocking​

  1. §8 容器图弱化「一主四辅」的信息资产库与检索系统：容器图只有 Access/Process/Output/Console，资产库只落成 MySQL/Weaviate 基础设施；L2 明确它是四辅之一、不等同数据库。须显式表达资产库/检索逻辑容器，否则 §15/§16/ADR-08 无法下推。
  2. §10 S1/S2 跳过 Perception Record：§4/§6 已定义 Raw→Record→Asset，§10 图从 Proc 直接写 Store 为资产，无 Record 生成/待复核/低置信节点 → §11 状态机失 Record 触发点。
  3. §10 Delivery Artifact 用语/状态不统一：S2「Store->>Out: 交付」易混成动作/通道；应明确 Delivery Artifact 的创建/交付/确认/失败重试位置。

建议 non-blocking​

  1. §10 只画 S1/S2/S5/S8，S3/S4/S6/S7 以「沿用」带过偏弱；各有不同状态分支，不宜完全共用主图。
  2. §7 机器客户端与 ATM 在图中并列，易误判同等硬主线；建议补「评估对象，不抢 ATM 第一验证场景」。
  3. §8 现行频率（Scraper ~60s、~1s）应标观察值，不被 §12 当 SLA / 固定调度。

亮点​

  • §7 接触契约忠实承接 L2 §15.4，G6 保持 proposed 不越权冻结。
  • §8 未把五能力域误写成部署边界（逻辑按五域、物理允许同实例多 Job）。
  • §9 接口/失败模式足以启动细化，保留 webhook 无 ACK、抽取失败不静默丢、授权拦截等缺口。
  • 边界语义干净，无 FinBayes 残留（FinBayes 只读证据包消费、认知归 FinBayes）。