跳到主要内容

Codex Worker-Dispatch 任务包

使用方式：

  1. 替换占位符：把本文档中所有 ${REPO_ROOT} 替换为你本地 Labs-FinTecAI 仓库的绝对路径（macOS 上类似 /Users/<your_name>/Programs/Labs-FinTecAI）
  2. 复制全文：把替换后的全文（从"## 任务说明"起）复制到 Codex / ChatGPT Pro 中作为提示词
  3. 粘贴回结果：Codex 完成后把它的 review report 粘贴回 Claude Code 即可整合

本任务是 worker-dispatch（CC 包装的自包含任务包），不是 peer-handoff。Codex 与 3 个 Claude Code sub-agent 并行做不同维度的 review，互相不引用，形成跨 Agent 三角验证。

任务说明​

你是一名独立架构 reviewer。任务是深度 review FinBayes 工程架构文档（约 5800 行，9 部分 27 节），重点放在 3 个维度：

维度 1：战略保真度（核心维度）​

FinBayes 战略白皮书 v2 是上位事实源。新架构文档不得违反以下战略不变量：

  1. 凭证不变量："金融执行凭证——私钥、助记词、钱包恢复短语、交易所登录凭证、交易所 API key、经纪商 API key、银行账户、信用卡等——FinBayes 一律不收、不存、不训练，即使为了'提升服务质量'也不收"
  2. 不直接下单 / 不持账户凭证：FinBayes 在金融信息和交易行动之间，是认知层不是执行层
  3. 不替用户决策：输出是认知材料（条件化、可复盘、带不确定性），不是执行指令
  4. 用户画像主权：用户可查看 / 修改 / 清空画像；画像只用于沟通效率，不裁剪事实空间
  5. 被否决概念清单（不可引入到工程文档）：
    • 11 条字段级强约束（指某次重写期被否决的"输出必须含 11 个字段"机械契约）
    • 默认 vs 行动准备双模式（结构 + 命名都被否决）
    • 升格为关系定义的"认知协作伙伴"
    • L3 长期状态四承诺
    • 零状态前提
    • 情绪桥 / 信任债承诺
    • "行动准备 / 行动判断 / 行动方案"作为任务类型名（重写工作流统一规范为"交易准备 / 交易决策 / 交易行动"）

维度 2：业务建模与工程实施的逻辑自洽​

  • 第 4 节定义的 7 个 first-class 业务对象（Session / Watchlist / Judgment Record / Dynamic Profile / State Candidate / Fin Object / Task）在第 11 节状态机、第 15 节 SQLite 表、第 27 节模块映射中字段、状态转移、表 schema、代码路径是否前后一致？
  • 第 9 节 6 个子系统（Input/Output Pipeline / Task Orchestration / Evidence + Synthesis / State Management / Capability Registry / Provider Adapter Pool）在第 10 节 sequence 图、第 13 节降级路径、第 27 节模块映射中职责、接口、命名是否一致？
  • 候选→已确认两步写入路径（第 11 节）是否真的被第 9 / 10 / 15 节工程化承接？

维度 3：写作纪律​

新架构文档遵循以下纪律：

  • 内容 > 形式：每个段落 / 表格服务实施者疑问，不为模板齐整堆砌
  • 建设型而非防御型：重点说"做什么 / 怎么做"，不变成"不许什么 / 不是什么"清单
  • 不解释方法论：方法论选择放 ADR，主文档只引结论
  • 抽象 vs 具体：优先用 FinBayes 实际场景，少用"系统应该"一般论述
  • 图配三段说明：图表达什么 / 图特意不表达什么 / 怎么读这张图
  • 专有名词第一次出现给一句话解释

抽查 5-10 节，检查是否存在违反纪律的内容（如某节大段方法论展开 / 某节防御型清单超过半页 / 某图未配三段说明）。

待 review 的文件​

主文档：${REPO_ROOT}/projects/finbayes/engineering/architecture.md（5796 行）

关联资产（如需 cross-check）：

  • 上位战略白皮书：${REPO_ROOT}/projects/finbayes/strategic-whitepaper.md（447 行）
  • 上位产品定义文档：${REPO_ROOT}/projects/finbayes/engineering/product-definition.md（526 行）
  • 已通过的 ADR：${REPO_ROOT}/governance/workstreams/finbayes-arch-rewrite/decisions/ADR-001-工程范式.md / ADR-002-架构文档结构.md / ADR-003-工程实施栈与协作.md

关键背景​

  • 文档由 27 章重写工作流产出（governance/workstreams/finbayes-arch-rewrite/）
  • 工程范式：Harness Workflow + 里程碑切片 + Walking Skeleton 试点（M0-M7）
  • 工程协作：OpenSpec + Archon + Claude Code 主控 + Codex 实施（你！）
  • 架构方法论：arc42 + C4 + ADR + DDD 业务建模
  • 4 层降级：L1 用户 Provider / L1' 系统默认 / L2 本地嵌入式 / L3 缓存+规则 / L4 受限菜单
  • LLM Function Calling 主导意图识别（不预设意图分类管道）
  • 单进程 asyncio.TaskGroup 第一阶段优先（不引入分布式拆分）
  • 本地优先单机部署（SQLite + OS Keychain + 可选本地 LLM）

你要做的事​

  1. 完整读完 architecture.md（5796 行）—— 不要只抽样
  2. 抽样读 strategic-whitepaper.md 关键段落（§ 1 / § 4-7 / § 14-15）做战略保真度 cross-check
  3. 抽样读 product-definition.md 关键段落（§ 4-7）看任务类型 / 输出契约
  4. 跑下面的具体核查项：

核查项 A：禁词 grep 与同义改写​

  • 在 architecture.md 全文搜：行动准备 / 行动判断 / 行动方案 / 认知协作伙伴 / 情绪桥 / 信任债 / 零状态前提 / L3 长期状态 / 11 条字段
  • 注意已禁词清单的元引用是合法的（§ 17 Review Gate 段 / § 23 拒绝概念表 / § 26 同义改写审计示例）
  • 关注同义改写：是否有"行动倾向 / 行动指向"等改写绕过

核查项 B：凭证不变量端到端​

  • 验证 § 15 Credential Store 段、§ 17 边界与安全段、§ 27 代码模块映射对凭证不变量的承接是否首尾贯通
  • 验证审计 trail（§ 18）、缓存（§ 15）、状态对象 schema（§ 4 / § 11）等任何地方没有任何字段名 / 表名 / 字段说明暗示存储凭证
  • 验证 ADR-010（输出端凭证样式过滤位置）的初步倾向是否够审慎

核查项 C：业务对象端到端一致性​

  • 抽 3 个对象（Watchlist / Judgment Record / State Candidate），在 § 4 / § 11 / § 15 / § 27 中追踪字段、状态、表名、模块路径是否一致

核查项 D：子系统职责无漂移​

  • 抽 2 个子系统（Task Orchestration / Provider Adapter Pool），看 § 9 / § 10 / § 12 / § 13 / § 27 中描述是否一致

核查项 E：M0 走通骨架的"工程化可执行性"​

  • § 25 M0 描述是否真的能让一个工程师在 1-2 天内完成？
  • 缺什么"工程包"（输入清单 / 验收脚本 / 测试 fixture / 配置模板）？

核查项 F：上位文档对齐​

  • strategic-whitepaper.md 有 5 处旧术语命中（"行动准备/方案/判断"）— 这些应该改吗？给出明确意见
  • product-definition.md 是否完全与新架构对齐？有没有遗漏的反向更新？

输出要求​

按以下结构产出 review report（中文，2000-3500 字，markdown 格式）：

# Codex 独立 Review Report — FinBayes 架构文档 v2

## 维度 1：战略保真度

### P0 阻断（必须修订）
- ...

### P1 重要（建议修订）
- ...

### 强项（值得保留）
- ...

## 维度 2：业务建模与工程实施一致性

### 业务对象端到端一致性
- Watchlist：...
- Judgment Record：...
- State Candidate：...

### 子系统职责一致性
- Task Orchestration：...
- Provider Adapter Pool：...

### 严重不一致清单
- ...

## 维度 3：写作纪律

### 抽查 5-10 节的结论
- § N：...
- ...

### 违反纪律的具体位置
- ...

## M0 走通骨架可执行性

### 工程包齐全度评分（10 分制）
- ...

### 缺什么（如要让我接手 M0，我需要补这些）
- ...

## 上位文档对齐意见

### 战略白皮书的 5 处旧术语
- L109 "行动方案"：建议改为... / 不改的话理由是...
- L158 "行动判断"：...
- L182 "行动判断"：...
- L286 "行动准备"：...
- L310 "行动准备"：...

### 产品定义文档需要回写的项
- ...

## 与其他 Reviewer 不重叠的独立发现
（这里是你独立 review 中发现但与"跨章一致性 / 上位对齐 / 工程可实施性"其他 reviewer 维度不重复的点）
- ...

## 给 ADR-004 至 ADR-010 起草的建议
（你对 7 条待写 ADR 中你最有把握的几条，给出 80 行内的"建议草稿要点"）
- ...

完成后把这份 report 整体粘贴回 Claude Code。

不要做什么​

  • 不修改任何文件（只 review，不编辑）
  • 不抢答上位文档的修订（只给意见，最终修订由 Claude Code 在主会话中走 governance/change-protocol.md 流程）
  • 不引用与本任务无关的 Codex 历史会话
  • 不假装读了没读到的章节（如果上下文窗口紧张，明示哪些章节没完整读到）
  • 不重新设计架构（这是 review 不是 redesign）

完成后​

把 review report 粘贴回 Claude Code 主会话即可。Claude Code 会把你的 report 与 3 个 sub-agent 的 report + 自身分析整合成统一行动方案。