⚠️ 阶段 1 步骤已被重判（2026-06-10）：本 ADR 的基线切换结论（新基线 = 大驼峰 CurvatureLabs/FinBayes）不变、仍生效；但其阶段 1 Step 1.1–1.7 的原方案已由 ADR-028 D-3 逐行重判（cognition 从「集成审计、保护孤岛」翻转为「抛弃静态实现、目的保留」，Step 1.3 从机械 sed 改名细化等）。阶段 1 步骤与闸门定义以 ADR-028 为准。
ADR-024 基线选定为 CurvatureLabs/FinBayes（承认 Codex 5/20-5/26 路线）
文件名沿用早先版本（"基线切换至 CurvatureLabs/finclaw"），正文以当前正式决定为准：选定
CurvatureLabs/FinBayes（大驼峰）作为新基线。
状态
accepted（owner 2026-06-06 拍板，经四方完整对比 + 重做事实核 + 承认 Codex 5/20-5/26 已有路线）。
背景
§9（CURRENT-MILESTONE）定下"完整可用金融 agent 产品"的方向后，主控做了两轮基线对比：
- 第一轮（6/6 上午）只盯了三个候选（当前 FinBayes 工程仓 / martin-Finclaw / CurvatureLabs/finclaw 小写 / Hermes），结论选小写 finclaw。
- 第二轮（6/6 下午）owner 提醒「还有一个
CurvatureLabs/FinBayes（大驼峰）」，主控实地核才发现：- 它是 owner 2026-05-20 主动从 martin 整仓 copy 进来当"transformable baseline"的副本（README 自陈），不是裸 martin。
- Codex 在它的
codex/finbayes-analysis-runtime分支上已经做了 6 天密集工作（5/20-5/26），包括：- 6,325 行金融认知契约层（
finclaw/cognition/，taxonomy + DAG orchestrator + evidence model + synthesis validator + widget projection，martin 完全没有这层） - 5,580 行新测试（13 个文件，martin 自己零测试）
- 23 份治理级设计文档（G0 audit → G2 closeout → 4 份 Package C 评测 → 4 份 vs-martin 30-case 评测 → v2-engineering-landing）
- Live Kimi 30/30 PASS（avg 45.3s/case、widget 完整率 100%、quality grade A、0 fallback、0 raw error）—— 这是本系列第一次有 cognition 层在真模型上跑通 30 案全过的实证
- 已主动对齐治理仓
Labs-FinTecAI/projects/finbayes，下一步指向goal-execution.md里的 G1: First-screen Answerability
- 6,325 行金融认知契约层（
- 唯一硬伤：所有 Codex 工作 0 commit，全在工作树（35 modified + 整个
finclaw/cognition//tests//docs/design//scripts/untracked），但git add . && git commit即可解决。
四方对比同一把尺，关键事实：
| 维度 | martin | Hermes | finclaw（小写） | FinBayes（大驼峰） |
|---|---|---|---|---|
| 代码量 | 18.2K | 1M+ | 21.4K | 32.4K（martin 18.2 + Codex 14.2） |
| 活跃度 | 9 周静默 | 16h 前 commit | 今天 commit | Codex 6 天密集但 0 commit |
| 金融工具 | 31 个 | 0 | 1（实质） | 继承 31 个 + 1 cognition tool |
| 事后复盘线 / 校准 | watchlist 字符串覆盖 | nudge（管 agent 记什么，不管判断对不对） | schema 齐、引擎未连 | 6.3K 行认知契约层 + Live PASS 实证 |
| 渠道 / 产品面 | 12 渠道 | 22 渠道 + 3 套 UI + 6 部署后端（工程天花板） | FastAPI + React | 继承 martin 12 渠道 |
| 测试网 | 0 | 3,763+ | 480 全过 + FakeProvider | 5,580 行 + Live 30/30 PASS |
| 设计文档 | 后期 LLM 生成 | 完整 | 2,865 行与代码对齐 | 23 份治理级文档 |
| 工程卫生 | CI 删 | uv.lock + CVE | pyproject + 测试守门 | 0 commit（最大债，可立解） |
| 距"完整可用"距离 | 大（要补 judgment + 测试） | 最大（要从零长金融层） | 中（要补金融工具 + scheduler，6-9 周） | 最近（3-5 周，已 Live PASS） |
决策
- 新基线 =
CurvatureLabs/FinBayes（大驼峰，本地工程仓）。承认 Codex 5/20-5/26 在此仓上的全部代码产出（cognition 契约层 + 新测试 + Live Kimi 30/30 PASS 实证）作为本次构建的基线资产。 - 第一步：把 Codex 6 天工作落 commit（
git add . && git commit -m "baseline: import Codex G0→G2 closeout + Package C Live PASS"），解决"0 commit 在工作树"的工程卫生债。这是任何后续动作的前置。 - 保留与不再走，要分清：
- 保留：Codex 的代码（
finclaw/cognition/）+ 测试（tests/test_finbayes_*）+ Live Kimi 30/30 PASS 实证。这些是阶段 1 "不退化" 的保护对象。 - 不再走：Codex 当时规划的下一步路线（
docs/design/finbayes-v2-engineering-landing.md指向的 "G1 first-screen answerability"）已过期失效——因为它锚定的是 5/26 之前的治理仓口径，而 5/27-6/6 治理仓做了多轮修订（ADR-013 / ADR-021 kelly_cap 退役 / ADR-022 术语整顿 / §9 快慢两条线方法论 / INV-15/16 加入 / owner 6/6 取消交易限制），Codex 一概不知。 - 改走：本次重构按 owner 6/6 拍板的两阶段框架走（详见下方「执行框架」段）——阶段 1 不退化（与 Codex 规划无关）+ 阶段 2 按最新治理文档 + 反向矫正。
- 保留：Codex 的代码（
- martin / finclaw（小写） / Hermes 在此版本里的位置：
- martin：作为大驼峰 FinBayes 的上游 baseline，工具集已经继承在
finclaw/子包内，不需要再"借"或"移植"。 - finclaw（小写）：owner 自己之前的 FastAPI 重构项目，作为未走的路保留，不再当基线候选；它的 React 前端在团队 Web 前端集成阶段可参考。
- Hermes：作为设计参照（学它的 steer / nudge / MCP 三 transport / Ink TUI / 工程范式如 uv.lock + CVE 跟踪），不当基线、不搬码。
- martin：作为大驼峰 FinBayes 的上游 baseline，工具集已经继承在
- 执行环境：新会话在 owner 自己终端跑，能连真模型本地网关，真数据 / 真模型自己就能跑、自己验；owner 做最后验收。owner 授权与本次纪律详见下方「执行方式」段。
执行方式（owner 2026-06-06 拍板）
owner 授权：① claude/ 分支自动提交（不动 main、不跳 git hook）；② Auto Mode 已开；③ 本次不加交易 / 下单 / 执行类限制（先完成完备功能集成，边界以后再定）；④ 本阶段不接 FinTecEval（效果暂由 owner 在自己终端 + Codex 设计的 Package C 评测体系验）。
Auto Mode 说明：Claude Code 的 AI 权限分类器——常规安全操作（读文件、跑测试、加文件等）自动批准，危险操作（删库、push main、改密钥、跳 git hook）照旧问 owner。owner 接受由此带来的更高 token 消耗。
Dynamic Workflows / /loop / /goal / Skill 按需用、不强制：Claude Code 内置的动态工作流（一段 JS 编排脚本同时跑多个子 agent + 对抗式验证 + 断点续跑）、/loop 或 /goal（把目标拆成"抽干一个队列直到机器可判定的完成条件"）、Skill（把可复用做法写成配方文件放进 Claude Code 的 skills 目录）——这些是新会话可选的工具，哪一阶段哪一段合适就用哪一段（比如包改名机械替换、对 martin 30 case 对比、清单类审计就合适用工作流并行 + Skill 复用做法；线性的一次性步骤就别套）。不是要全套都套上。
撤回 / 修订的早先论述
- 早先版本说"新基线 =
CurvatureLabs/finclaw（小写）"，那是只对了三方对比（漏了大驼峰）的结论。正式作废。 - 早先版本说"FinBayes 认知核未经实证、且唯一一次同模型对照输给 martin"——这指的是旧 FinBayes 仓（
FinBayes（本地旧工程仓））的认知核（synthesize_cognition + MCA + S1 + posterior）。大驼峰 FinBayes 仓的 cognition 契约层是 Codex 另起炉灶的不同实现（taxonomy + DAG orchestrator + evidence model + synthesis validator），并且已经有 Live Kimi 30/30 PASS。两者别混。
执行框架（两阶段，owner 2026-06-06 追加拍板）
owner 建议把本次基线重构分两阶段，主控核后接受、且认为它比"治理对齐 + 去 martin 化并行"的早先框架更对（理由：保护 Codex 已 PASS 实证、明确"基线立得住"的闸门、承认治理仓也可能有过期项需要反向矫正）。
阶段 1：基线立得住、不退化
目标：让大驼峰 FinBayes 在 FinBayes 身份下，产品形态/能力至少与 martin 原仓持平，不出现任何退化。
步骤：
- Step 1.0 收齐 Codex 6 天工作（
git add . && git commit -m "baseline: ..."） - Step 1.1 集成审计（只读）：核 Codex cognition 层是否充分用上 martin 已有能力（12 channels / cron / heartbeat / 31 工具 /
ChannelCognitionPayload全连通否） - Step 1.2 集成强化（如审计发现差距）
- Step 1.3 去 martin 化 PR-1（机械改名）：包名
finclaw → finbayes+ 内部路径/Docker/bridge/skills/tests，约 1,000 行 - Step 1.4 去 martin 化 PR-2（自陈文档）：LICENSE / README / 删 ARCHITECTURE.md + COMMUNICATION.md / SECURITY.md 改邮箱，约 250 行
- Step 1.5 INV-11 凭证脱敏（安全基础设施，从治理对齐工作线提前到此）：搬旧 FinBayes 仓
credential_filter.py，约 150 行 - Step 1.6 去 martin 化 PR-3（灵魂重写）：bootstrap 模板 SOUL/AGENTS/USER 等 +
context.pyidentity 硬编码完全重写，约 350 行 - Step 1.7 退化检查 + 对 martin 对比（阶段闸门）：同 case 同条件下（同模型/参数/数据源）FinBayes vs martin-Finclaw 6 维度（输出质量 / 执行效率 / token 消耗 / 成功率 / 工具调用深度 / 结构化产物完整度）只强不弱，不出现任何退化
总工作量：约 5-7 个工作日。
阶段 2：战略对齐 + 反向矫正
目标：在阶段 1 稳定基线之上，与治理仓最新上下位文档双向对齐——既把"基线该建但还没建"的部分建起来，也回写治理仓里已过期的项（如交易/执行限制按 owner 6/6 取消、某些 INV 在 Codex Live PASS 实证下是否仍是必须、8 机制/MCA 是否治理仓让步）。
步骤：
- Step 2.0 治理文档反向矫正第一波：取消交易/下单/执行限制（已知确定项）+ 评估 INV-01/INV-02 等是否调整
- Step 2.1 上下行差距清单：分必建 / 应建 / 可推迟
- Step 2.2 战略对齐执行：ontology 重组（MP-4 单层 task_type）、INV-15/INV-16 快慢两条线骨架、MP-5 surface 元数据、INV-02/INV-13 validator、23 份 design doc 术语整顿（ADR-022）
- Step 2.3 战略一致性 review
总工作量：取决于反向矫正后最终留多少；粗估 2-4 周。
详细方案存放
阶段 1 完整方案（含集成审计 10 类清单 + 去 martin 化 11 项决策 + 3 PR 触达清单 + Step 1.7 闸门）存大驼峰 FinBayes 仓 handoff-anchors/2026-06-06-stage-1-baseline-not-regressed.md，不入本治理仓。阶段 2 详细方案待阶段 1 完成后展开。
边界与后果
- 诚实完成门：完成标准只认"代码接好 + 测试过 + 没破坏原有"，不拿测试全绿冒充"产品做好了"。Live 质量由 owner 在自己终端 + 阶段 1 Step 1.7 「vs martin 6 维度只强不弱」闸门 + Codex 设计的 Package C 评测方法验。
- 包名 / 身份 / LICENSE：阶段 1 PR-1（机械改名）改包名
finclaw → finbayes、CLI 兼容别名删；阶段 1 PR-2（自陈文档）改 LICENSE Copyright →Curvature Labs（owner 11 项决策已全部接受默认建议，详见阶段 1 文档）。 - 许可：继承 martin 的 MIT。
- 工程产物不进治理仓：代码 / 日志 / state / 计划留大驼峰 FinBayes 仓或私有运行环境。
- 小写 finclaw 仓的
claude/baseline-rebuild分支作废（已在该分支头部加废止标记 commit）。该仓本身保留、作为 owner 早先 FastAPI 重构项目（"未走的路"）。
关系
- 取代早先版本的 ADR-024 决议（选小写 finclaw 那版）。
- 接 ADR-023 · 方案 Z 对 martin 立场修正：martin 作为大驼峰 FinBayes 的上游 baseline 已经被继承，方案 Z「不直接 rebase martin 单体」仍守（我们用的是 owner 2026-05-20 主动 import 的本地副本 + Codex 6 天改造，不是 fork martin 公开仓）。
- 详细执行方案 / 交接事实源存大驼峰 FinBayes 仓
handoff-anchors/，不入本治理仓。