【历史参考】 本文保留 FinBayes 早期工程化讨论和旧实现上下文，便于追溯。当前战略、产品定义和工程化落地以 engineering/ 子目录为准。

FinBayes 三步 Goal 执行计划

For agentic workers: REQUIRED SUB-SKILL: Use writing-plans or equivalent implementation-planning discipline before changing code. Execute one Goal at a time and close each Goal with fresh evidence.

Goal: 用三步 /goal 把 FinBayes 从产品定义和基线改造设计推进到可实施、可验收、可异常续接的工程路线。

Architecture: G0 先初始化并审计新基线仓；G1 一次性落下最小完整产品闭环并冻结 Product Contract；G2 只在该契约上补齐多入口一致性、辅助主动能力和最终硬化。

Tech Stack: Python / FastAPI / Pydantic / martinpmm-Finclaw-inspired runtime；实际代码落点为 FinBayes 工程仓。

0. 上下文预算规则

为避免 /goal 一启动就读取过多文档，后续每个 Goal 默认只读：

FinBayes Goal 精简上下文包；
当前 Goal 产生或依赖的目标仓文档，例如 G0 audit、G1 Product Contract；
FinBayes 工程仓 中当前要修改的源代码和工程入口文件。

FinBayes 产品定义文档、历史基线改造材料和参考项目报告是 drill-down 材料，只在精简上下文无法裁决时按需读取。当前工程化落地默认读取 engineering/ 下的现行文档。

1. 仓库策略

不在 martinpmm/Finclaw 参考仓 中直接实施 FinBayes 改造。该仓是参考基线仓，默认只读。

本轮新基线实施目录已经确定为：

FinBayes 工程仓

G0 的首要任务不是再选择仓库，而是初始化并审计 FinBayes 工程仓。该目录当前是干净空目录，尚不是 git 仓库；G0 应建立新基线仓，并说明如何从 martinpmm/Finclaw 参考基线导入或映射起点。

2. 为什么是三步

多 Goal 拆分适合边界稳定的工程迁移，但 FinBayes 当前不是单纯工程重构，而是在第三方金融 Agent 基线上重建产品目标、任务体系、输出契约和多入口 runtime。把同一轮改造拆成七八个小 Goal，会出现以下风险：

风险	表现	三步方案的处理
局部最优	某个 Goal 只为通过模型、API 或测试验收，忽略真实产品闭环	G1 必须一次性验证五个贯穿场景
契约漂移	后续 Goal 为了接 TUI、MCP 或 Heartbeat 修改核心输出结构	G1 冻结 Product Contract，G2 不允许破坏
入口割裂	Chat、Task、TUI、CLI、MCP 各自生成不同语义的结果	G1 定义统一 FinancialCognitionTask 和 StructuredCognitionResult
产品退化	被实现成单一金融 Agent，多市场和多 Agent 只是字段	G1 必须支持至少 crypto + us_stocks 的任务语义
误入执行层	行动判断被工程实现成交易执行前检查或下单辅助	全程保留认知层边界，不接交易执行

关键原则：G1 完成后必须冻结 FinBayes Product Contract；G2 只能在此契约上做 additive / backward-compatible 改动。

3. 三步总览

Step	Goal Objective	主要产物	退出门槛	是否改产品代码
G0	初始化新基线仓并完成基线审计	`FinBayes 工程仓 docs/design/finbayes-g0-baseline-audit.md`	新基线仓、导入方式、测试基线、可复用模块、G1 触达边界和续接锚点明确	否；只允许产出审计文档
G1	实现最小完整产品闭环	核心模型、两层任务 registry、adapter、最小入口接入、测试、`finbayes-product-contract.md`	Product Contract 冻结；两层任务体系进入工程；样例场景作为覆盖性验收通过	是；改核心 runtime、模型、adapter、测试和契约文档
G2	完成多入口一致性与最终硬化	跨入口一致性、Channel 摘要、Watchlist Heartbeat 候选、端到端验收、contract regression	不破坏 G1 契约；入口语义一致；非执行边界保持	是；只允许兼容性增强和补充能力

4. 当前资料状态

资料	状态	对 Goal 的作用
FinBayes 产品定义文档	active	定义产品定位、用户、任务、Watchlist、动态画像、输出契约和非目标
历史基线改造材料	historical	早期定义从 `martinpmm/Finclaw` 基线改造到 FinBayes runtime 的架构方案；当前以工程化目录为准
FinBayes Goal 精简上下文包	active	每个 Goal 默认必读上下文，避免上下文爆炸
本文（FinBayes 三步 Goal 执行计划）	active	G0/G1/G2 的目标、复制即用指令、验收门槛与续接要求
FinBayes Goal 中断续接包	active	支撑上下文压缩失败、额度中断、新会话或其他 Agent 接手
`martinpmm/Finclaw 参考仓`	第三方参考基线，只读	用于理解能力来源，不作为直接改造落点
`FinBayes 工程仓`	已指定，当前为空目录	本轮新的 FinBayes 基线实施目录；G0 负责初始化和审计

5. G0：实施前基线审计

5.1 Goal

初始化 FinBayes 工程仓，确认当前工程现实，避免后续 /goal 回退到旧仓或在参考仓中直接改造。

G0 不实现新产品能力。G0 可以初始化新基线仓、读取工程、运行测试发现、产出审计文档，但不得改产品代码。

G0 完成后必须能回答：

当前工程哪些文件已经被改动；
哪些模块可复用；
哪些测试当前可跑；
G1 会触达哪些文件；
哪些用户改动需要避让；
若任务中断，新 Agent 从哪里继续。

5.2 可直接用于 `/goal` 的指令

完成 FinBayes G0 实施前基线审计。

默认必读：
- projects/finbayes/legacy/goal-compact-context.md

参考基线仓：
- martinpmm/Finclaw 参考仓

要求：
1. 不得直接在 martinpmm/Finclaw 参考仓内实施改造；该仓只读。
2. 使用 FinBayes 工程仓作为新 FinBayes 基线仓；若尚未初始化 git，则初始化。
3. 基于 martinpmm/Finclaw 的架构和代码形态建立起点；采用复制、fork、worktree 或显式导入方案时必须说明理由。
4. 在 FinBayes 工程仓内执行 git status --short、git diff --name-only，并读取 AGENTS.md、README.md、pyproject.toml 或等价入口文件。
5. 映射现有 Chat、Task、Runtime、Models、Skill、Tool、Session、Cognition、Boundary 相关模块。
6. 运行最小测试发现或测试基线，失败必须记录真实失败原因。
7. 产出 FinBayes 工程仓 docs/design/finbayes-g0-baseline-audit.md，包含初始化方式、参考基线来源、当前状态、风险、测试证据、G1 建议触达范围和中断续接信息。

完成标准：
- FinBayes 工程仓已明确；
- martinpmm-Finclaw 仍只读；
- 审计文档存在且内容完整；
- G1 触达边界和验证命令明确；
- 未回滚、覆盖或机械重写用户改动。

6. G1：FinBayes 最小完整产品闭环

6.1 Goal

在 FinBayes 工程仓 中实现 FinBayes 的最小完整产品闭环，并冻结 FinBayes Product Contract。

最小完整闭环指：

6.2 可直接用于 `/goal` 的指令

在 FinBayes 工程仓内实现 FinBayes G1 最小完整产品闭环。

默认必读：
- projects/finbayes/legacy/goal-compact-context.md
- FinBayes 工程仓 docs/design/finbayes-g0-baseline-audit.md

产品目标：
让系统从用户自然表达开始，能识别真实意图，映射为金融认知任务，按市场、任务、视角调度 Agents 与金融原子 Skills，输出 StructuredCognitionResult，并支持 Session 追问、Watchlist 最小对象、动态画像信号占位和 Web / TUI / CLI / MCP / Channel 可共用契约。

必须实现两层金融任务类型：
A. 用户意图大类：解释、分析、对比、验证/复盘、风险识别、行动判断。
B. 内部任务执行类型：新闻/事件影响分析、单标的基本面分析、技术面状态分析、链上数据解读、宏观数据解读、财报/公告解读、多资产横向比较、观点反证检查、历史判断复盘、风险清单生成、条件化行动判断、结构化报告生成。

必须实现或调整：
1. FinBayes 核心模型：InputEnvelope、FinancialCognitionTask、StructuredCognitionResult、WatchlistObject、DynamicCognitionProfile、TaskTemplate、ClarificationRequest、MarketPack。
2. 金融认知任务 registry：用户意图大类、内部执行任务类型、market pack、所需 skills、是否需要澄清、是否需要边界检查。
3. 输入 adapter：Chat / Task / CLI-like payload 转换为 InputEnvelope 和 FinancialCognitionTask。
4. 输出 adapter：现有 runtime 结果、普通文本结果或市场分析结果转换为 StructuredCognitionResult。
5. 最小 API 或 runtime 接入：至少让一个主入口能验证完整链路。
6. Session 后续追问基础：能关联 session_id、previous task/result reference。
7. Watchlist 最小对象：支持 asset/theme/event/sector/narrative。
8. 执行边界：行动判断只能输出条件、风险、信息缺口和观察动作，不进入下单、调仓、账户操作或自动交易。
9. 冻结 FinBayes 工程仓 docs/design/finbayes-product-contract.md。
10. 增加针对模型、任务 registry、adapter、边界和任务类型覆盖的测试。

验收场景只是覆盖性样例，不允许硬编码这些字符串。它们必须证明两层任务体系成立。完整样例池见本文 §8。

不得实现：
- Web UI 页面；
- 交易执行、下单、调仓、账户操作；
- 完整多 Agent 平台；
- 完整 MCP server；
- 完整 Channel 分发；
- Heartbeat 主动提醒；
- 针对样例问题的字符串硬编码；
- 回滚或覆盖用户已有改动。

完成标准：
- FinBayes Product Contract 已冻结；
- 两层金融任务类型进入工程 registry 和测试；
- 至少 crypto + us_stocks 任务语义可验证；
- StructuredCognitionResult 不是单一文本包装；
- 样例场景作为覆盖性验收通过；
- 新增和关键既有测试有新鲜输出证据。

6.3 Product Contract 必须冻结的内容

finbayes-product-contract.md 至少包含：

核心对象和字段；
用户意图大类；
内部任务执行类型；
任务状态和事件语义；
Chat / Task / TUI / CLI / MCP / Channel 如何共享结构化结果；
crypto 和 us_stocks 的 market pack 表达；
Watchlist 对象类型；
任务模板和澄清请求对象；
执行边界字段和禁止输出；
兼容旧接口的策略；
G2 不得破坏的字段清单。

7. G2：多入口一致性与最终硬化

7.1 Goal

在不破坏 G1 FinBayes Product Contract 的前提下，完成多入口一致性、Channel 摘要、Watchlist Heartbeat 候选和最终产品验收。

G2 是补齐和硬化，不是重新定义。G2 的前置条件：

G0 审计存在；
G1 Product Contract 存在；
两层金融任务类型已有工程 registry 和测试证据；
G1 至少有模型、registry、adapter 和边界测试证据。

若任一条件缺失，应回到 G1。G2 不允许用「先补入口」绕过 Product Contract。

7.2 可直接用于 `/goal` 的指令

在 FinBayes 工程仓内完成 FinBayes G2 多入口一致性与最终硬化。

默认必读：
- projects/finbayes/legacy/goal-compact-context.md
- FinBayes 工程仓 docs/design/finbayes-g0-baseline-audit.md
- FinBayes 工程仓 docs/design/finbayes-product-contract.md

本 Goal 不允许重新定义 G1 的核心对象。除非发现严重 bug，否则所有改动必须 additive / backward-compatible，并在 closeout 中列出 contract diff。

请完成：
1. 让 Chat、Task API、TUI/CLI、MCP contract-ready 入口共享同一 FinancialCognitionTask 和 StructuredCognitionResult 语义。
2. Channel 只输出结构化摘要和用户可读结果，不输出内部 runtime 过程。
3. Heartbeat / proactive alerts 只作为 Watchlist 认知刷新候选，不触发交易执行。
4. 用覆盖性样例验证两层任务体系、跨入口一致性和非执行边界。
5. 补齐跨入口一致性测试、contract regression test 和边界测试。
6. 更新 closeout 文档，说明 G1 contract 是否保持兼容。

不得实现：
- Web UI 页面；
- 交易执行；
- 自动调仓；
- 账户连接；
- 将 Watchlist 变成交易提醒或下单信号；
- 将 TUI/CLI 变成低质量降级入口。

完成标准：
- Chat / Task / TUI-CLI / MCP contract-ready 入口输出语义一致；
- Channel 和 Heartbeat 保持认知辅助边界；
- G1 Product Contract 未被破坏，或 breaking-risk 已被显式评审；
- 关键测试、构建或 smoke 验证有新鲜输出证据。

8. 贯穿验收场景样例池

以下场景作为样例池，用于校准方向和验收覆盖。它们不是功能枚举，也不是硬编码目标；验收的重点是证明两层金融任务体系成立，并能支持同类但不同表达的问题。

场景	用户输入	验收关注
Crypto 行动判断	`现在还能追 SOL 吗？`	行动判断意图 -> 条件化行动判断 + 风险清单 + crypto market pack
美股分析	`NVDA 财报后现在怎么看？`	分析意图 -> 财报 / 公告解读 + 单标的基本面分析 + 风险清单 + us_stocks market pack
复盘追问	`我之前看多 ETH 的理由还成立吗？`	验证 / 复盘意图 -> 历史判断复盘 + 观点反证检查；Session 连续性
Watchlist	`把这个主题加入关注，后面有变化提醒我复盘。`	WatchlistObject + 认知刷新候选；不触发交易执行
外部调用	外部 Agent 通过 CLI/MCP 请求分析市场事件	同一 FinancialCognitionTask 和 StructuredCognitionResult 契约可被外部入口复用

9. Product Goal Conformance Review

每个 Goal closeout 都必须包含以下表格：

检查项	结论	证据
是否仍是认知层应用
是否未进入执行层
是否实现两层金融任务类型
FinancialCognitionTask 是否仍是核心工作单元
Session 是否仅作为组织机制
crypto + us_stocks 是否仍有市场语义
Agents / Skills 边界是否仍成立
Watchlist 是否仍是关注对象集合
动态画像是否避免静态问卷主路径
Web UI 是否保持 contract-ready 而非本轮实现
TUI / CLI 是否保持完整入口定位

10. Closeout 模板

Goal:
Status:
FinBayes 工程仓:
Files changed:
Product Goal Conformance:
Task taxonomy coverage:
Scenario sample coverage:
Contract changes:
Tests run:
Known gaps:
Do-not-touch / user-change notes:
Next Goal prompt:
Recovery checkpoint:

11. 建议验证命令

实际命令以 FinBayes 工程仓 的工程入口和 G0 审计为准。每个 Goal 至少应先执行：

cd FinBayes 工程仓
git status --short
git diff --name-only

G0 建议执行：

cd FinBayes 工程仓
python -m pytest --collect-only server/tests

G1/G2 建议根据新增测试执行类似命令：

cd FinBayes 工程仓
python -m pytest server/tests/test_finbayes_contract_models.py server/tests/test_finbayes_task_registry.py server/tests/test_finbayes_contract_adapter.py -q
python -m pytest server/tests -q

若仓库使用其他测试入口，必须在 G0 审计中记录替代命令。

12. 中断续接要求

每个 Goal 都必须留下一个可由新会话或其他 Agent 接手的状态锚点。最低要求：

FinBayes 工程仓 的真实路径；
当前 Goal 状态；
已改文件和未完成文件；
最近一次成功验证命令；
最近一次失败验证命令；
当前 Product Contract 是否已冻结；
下一条应执行的命令；
禁止回滚的用户改动。

完整续接规范见 FinBayes Goal 中断续接包。

0. 上下文预算规则​

1. 仓库策略​

2. 为什么是三步​

3. 三步总览​

4. 当前资料状态​

5. G0：实施前基线审计​

5.1 Goal​

5.2 可直接用于 /goal 的指令​

6. G1：FinBayes 最小完整产品闭环​

6.1 Goal​

6.2 可直接用于 /goal 的指令​

6.3 Product Contract 必须冻结的内容​

7. G2：多入口一致性与最终硬化​

7.1 Goal​

7.2 可直接用于 /goal 的指令​

8. 贯穿验收场景样例池​

9. Product Goal Conformance Review​

10. Closeout 模板​

11. 建议验证命令​

12. 中断续接要求​