Review B — 上位文档对齐分析
Sub-agent (researcher) 在主会话外的独立 review，于 2026-05-27 完成。原文未删改。
关键发现：战略白皮书还使用了"行动方案"（L109）、"行动判断"（L158、L182）、"行动准备"（L286、L310）这些被否决的术语。这是 P0 级别的冲突。
战略白皮书需要的修改
S1. 必须修改（P0）—— 被否决术语仍在使用
新架构 §2「概念使用约定」明确：用「交易准备/交易决策/交易行动」；不用「行动准备/行动判断/行动方案」。新架构 §23「拒绝概念的处理」也把"行动准备/行动判断/行动方案"列为战略级硬约束。但白皮书自身仍有 5 处违反：
- 白皮书 L109：
- 现状："形成条件化判断、准备行动方案和复盘历史判断"
- 建议改为："形成条件化判断、准备交易行动前检查与复盘历史判断"
- 白皮书 L158：第 6.1 节
- 现状："准备一次行动判断，这些任务不应该被压成同一种回答格式"
- 建议改为："准备一次交易决策，这些任务不应该被压成同一种回答格式"
- 白皮书 L182：第 7 节
- 现状："还是准备行动判断"
- 建议改为："还是准备交易决策"
- 白皮书 L286：第 11 节 §5 验证项
- 现状："条件化、概率化的行动准备支持是否有价值"
- 建议改为："条件化、概率化的交易准备支持是否有价值"
- 白皮书 L310：第 12 节
- 现状："反方、条件化判断、历史复盘和行动准备支持"
- 建议改为："反方、条件化判断、历史复盘和交易准备支持"
理由：新架构 §2 把术语规范化为战略层硬约束并要求 grep 级核查；战略白皮书作为事实源若自相矛盾，会让下游派生的术语校验失效。这是 P0 反例：上位若先违反，下游 verify 失败。
S2. 建议修改（P1）—— 任务类型清单一致性
- 白皮书未列出第一阶段七类任务清单。产品定义 §4.2、新架构 §2/§4 都已明确"七类"（解释/分析/比较/复盘/风险识别/交易准备/交易决策辅助）。
- 建议：在 §6.3「懂判断」末尾或 §7 末尾补一段："第一阶段识别七类金融认知任务：解释、分析、比较、复盘、风险识别、交易准备、交易决策辅助。具体定义由产品定义文档承接。"
- 理由：避免白皮书 L158、L182、L286 等用临时词组让下游各处拼接清单时出现漂移。
S3. 建议补 stub 指针（P2）
| 新增概念 | 出处 | 建议白皮书 stub 位置 |
|---|---|---|
| 候选→已确认两步状态写入（用户主权 + StateCandidate） | 新架构 §11 + ADR-007 | §14 用户画像与敏感信息末尾补："长期状态对象的写入遵循候选→用户确认两步契约，由工程架构文档承接" |
| 4 层 Provider 降级链 + 用户自配置 Provider 为 first-class | 新架构 §9 / §13 | §14 第二段（本机 Provider 配置）后补一句指针："用户在本地优先单机部署中配置 Provider 偏好是 first-class，工程层提供 4 层降级保障 LLM 不可用时仍可用" |
| 反方/失效条件不被画像裁剪的硬约束 | 新架构 §13「关键不变量」 | 白皮书 §14 已暗示"画像不裁剪事实空间"，可加一句"该约束在工程层落为综合层的非可选契约" |
产品定义文档需要的修改
P1. 必须修改（P0）
无。产品定义文档已完整使用"交易准备/交易决策辅助"，未发现被否决术语残留；StateCandidate、TaskGroup、Watchlist、Judgment Record 措辞与新架构 §4 完全一致。
P2. 建议修改（P1）—— 文档分工句细化
- 产品定义 L24：
- 现状："如果冲突发生在工程细节或实现顺序上，以本目录下的工程化文档为准"
- 建议改为加一句："架构文档（architecture.md）中关于状态对象生命周期、降级链、子系统职责、ADR 等工程细节是本文档的延伸定义，本文档不重复定义。"
- 理由：新架构 §4 显式说明"工程实现按 first-class 概念组织数据模型与接口"，产品定义文档需对接，让读者知道术语下沉到何处。
P3. 建议补 stub 指针（P2）
| 新增概念 | 出处 | 建议产品定义 stub 位置 |
|---|---|---|
| 6 子系统全景 | 新架构 §9 | §1 末尾或 §11 末尾补"工程实现按 6 子系统组织，详见架构文档 §9" |
| 候选→已确认两步写入与 4 个候选类型（Judgment/Watchlist/ProfileSignal/SessionRename） | 新架构 §11 | §3.4「Judgment Record」末尾："Judgment Record 的写入走候选→用户确认两步，工程承接详见架构 §11"；§3.5「动态用户画像」也应补同样的 stub |
| 4 层 Provider 降级链 + 用户自配置 Provider 为 first-class | 新架构 §9 | §9 多入口契约中"FinBayes 可以支持用户本地部署"段后补 stub："Provider 选择走 4 层降级（用户配置 → 系统默认 → 本地嵌入 → 缓存+规则 → 受限菜单），保障 LLM 不可用时基础能力可用，详见架构 §9/§13" |
| 凭证不变量的端到端阻断（输入边界 hook + 输出端过滤 + 状态/审计永不接触） | 新架构 §17 | §10.3 末尾加 stub："此承诺的工程实现细节（输入/输出双向 hook、状态/审计/Cache 不接触凭证、执行类工具注册拒绝）见架构 §17" |
| 任务识别策略待定（ADR-004 进行中） | 新架构 §22 / §23 | §4.3 末尾补一句："自然语言到任务的识别策略由 ADR-004 决议，第一阶段倾向 LLM Function Calling 主导" |
上位文档一致性强项（不必动）
- 战略白皮书 §8（生态分工）、§14（凭证不变量、本机 Provider 配置 vs 金融执行凭证区分）、§15（未决问题清单）与新架构 §2/§17 完全一致，是工程文档的稳固上位。
- 产品定义文档 §4.2 七类任务清单、§4.4 交易类回答三规则、§7 输出形态认知要素清单与新架构 §4 字字对齐。
- 产品定义文档 §10.4（本机 Provider 凭证 vs 金融执行凭证语义区分）、§11.1（认知/执行分工）已是新架构 §2/§17 的精确上位。
反向修改（新架构需服从上位的项）
经全文对照未发现新架构与战略白皮书或产品定义文档实质冲突。新架构 §2 明确声明"任务类型清单来自产品定义文档，本文不增不减不改名"，§23 把所有被否决概念列为战略级硬约束而非工程决策。唯一可能的轻度张力：
- 新架构 §3 列出"8 个质量属性"含"战略保真度第一"，但白皮书与产品定义文档未直接命名"质量属性"列表。这不构成冲突，只是新架构对上位的工程级翻译。无需反向修改。
关键路径建议：先修 S1（5 处行动准备/判断/方案 → 交易准备/决策/行动），这是阻断点；其余 P1/P2 可一并起草一个白皮书 + 产品定义双文档的对齐 PR，走 governance/change-protocol.md 流程。