ADR-012 — SVA-9：战略愿景对齐九层防御方案
§0 决策简述
决议：FinBayes 工程化落地的对齐目标，从"对架构文档/产品定义文档保真度 100%"升级为"战略愿景对齐（Strategy-to-Vision Alignment, SVA）"——交付的产品必须 100% 兑现战略白皮书 / 产品定义 / 架构文档联合阐述与预期的 FinBayes，且不会因为落地走偏，导致交付后还要数轮大迭代才能回归战略愿景。
实现手段：九层愿景保障栈（L0.5 → L8）。每一层正向保障愿景的一个侧面被兑现，并各自划清一条兜底边界（这一层负责接住什么、不接住什么）。九层覆盖：隐式不变量 codify、契约源、契约测试、三阶段实施 SOP、Archon 编排 gate、功能正确性评测、人最终签字、战略姿态评测、真人使用体验校验。
叙述口径（承接 2026-05-29 fresh review W3）：本 ADR 的框架不是"九层防什么"，而是"为兑现战略愿景，每层正向保障什么 + 兜底边界划在哪"。原因：目标是 100% 兑现愿景（Build-Y），把每层叙述成"防 X"会把正向保障压扁成禁令——与 ADR-013 codify 哲学换轨 的 Build-Y 优先口径一致。九层的实质不变，只是叙述从 Prevent 口径转为 Build-Y 口径 + 标注兜底边界。
§1 上下文：为什么"保真度 100%"不够
Step 10-13 review 闭环暴露的核心问题：所谓"保真度 100%"是工程化产物对一份冻结文档的语义对齐度，但战略愿景包含文档之外的隐性约束：
- 隐式不变量：白皮书写了"FinBayes 不下单"，但什么代码路径能违反它？需要 codify 成不变量测试，否则只是文字承诺。
- 价值姿态：白皮书定义"用户主权 / 认知透明 / 不替决策"是战略价值，但代码层很容易绕过——比如返回一个 confidence_score 当 single number 就破坏了"认知透明"。
- 演进对齐：架构 / 产品文档会迭代，工程化落地若只盯当前快照，新版本一出就过时。
仅靠"保真度评测（D 维度）+ 人签"两层不够，因为：
- D 维度只测"功能对不对"，不测"姿态对不对"
- 人签依赖签字人当下的注意力，无系统性兜底
升级路径：在既有 6 层之上插入 3 层新保障（L0.5 / L7 / L8），并把既有 6 层中"模糊"的 3 层（L3 / L4 / L8 旧定义）做明确 SOP 化。
§2 SVA-9 九层愿景保障栈
下表每层给三件事：正向保障什么（这一层让愿景的哪个侧面被兑现）、兜底边界（这一层接住什么、把什么交给别层）、M0 阶段（M0 必跑 / M1+ 再上）。判定的去重原则见 §2bis（L5/L6/L7/L8 不互相承担）。
| 层 | 名称 | 正向保障什么 | 兜底边界 | M0 阶段 | 落地物 |
|---|---|---|---|---|---|
| L0.5 | 隐式不变量 codify | 把白皮书"用文字承诺"的隐性约束（不下单 / 不替决策 / 用户主权 / 8 机制定义不被代码层重定义）变成代码可断言的正向契约 | 只接"可 codify 成 test 的隐性约束"；禁用词类风格约束交 verify:kb hook（见 ADR-013 §3.3） | M0 必跑（10 条核心） | strategic-invariants-codified.md + tests/invariants/*.py |
| L1 | 契约源 | 字段级 / API 级 / 行为级显式契约就位，下游有单一事实源可读 | 只定义契约，不执行校验（校验在 L2） | M0 必跑 | contracts/ + engineering-packs/ + ADR |
| L2 | Contract test | 代码自动断言 L1 契约成立（结构、类型、必填、跨文档一致） | 只判"代码与契约是否一致"，不判功能好不好用（L5）、姿态对不对（L7） | M0 必跑 | Pydantic models + tests/contract_v1_1.py + 跨文档一致性 grep |
| L3 | 三阶段实施 SOP | 每个 PR 显式 plan → execute → verify，正向产出与验证段对称 | 只管实施过程合规，不判产物质量 | M0 必跑 | ADR-003-supplement-3-phase-implementation-SOP.md |
| L4 | Archon workflow gate | 把各层节点串成可重跑的 milestone 工作流，跑得起来才算过 | 只编排与门控，不替任何被串接的层做判断 | M0 必跑（M0 工作流到位即可，节点可逐步接入） | .archon/workflows/milestone-MN.yaml（真 Archon schema） |
| L5 | D 维度功能评测 | 功能正确性：产物内容对不对（D1-D11，如证据是否成立、字段值是否合理） | 只判"内容功能层对错"；不判流程（L6）、不判战略姿态（L7）、不判真人体感（L8） | M0 必跑（核心 D 维度子集；全量 D1-D11 M1+） | contracts/evaluation-dimensions.yaml + engineering-packs/eval-harness-formulas.md |
| L6 | 人最终签字 | 决策问责：一个不可推卸的 owner 看过 L0.5/L5/L7 报告后对 milestone 拍板放行 | 只判"流程是否合规 + 谁负责"；不重做评测（评测是 L5/L7 的事，L6 是看报告签字） | M0 必跑 | PR review + milestone gate（owner = 项目 owner） |
| L7 | V 维度战略姿态评测 | 战略姿态：产物的姿态对不对（V1 不替决策 / V2 认知透明 / V3 用户主权）——AI judge 但不 self-judge | 只判"姿态是否守住战略价值"；不判功能对错（L5）、不替真人下体验结论（L8） | M0 必跑（V1/V2/V3 各 1 组 prompt 即可起步；全量 prompt 集 M1+） | v-dimension-evaluation.md + Claude judge prompt |
| L8 | 真人使用体验校验 | 真实体感：真人用过之后"这是不是 FinBayes 该有的样子"——所有 AI 评 AI 之外的最终人类锚 | 只判"真人主观体感"；不替代功能/姿态的客观评测（L5/L7 先过，L8 才有意义） | M1+ 再上（M0 可选轻量化：1 case × 10 分钟试跑，不作 hard gate） | l1-user-vibe-check-cases.md |
§2bis · L5/L6/L7/L8 去职责重叠
四层最容易被理解成"都在评测"，导致重叠。明确分工——各判一件事，不互相承担：
| 层 | 判的是 | 谁来判 | 不负责 |
|---|---|---|---|
| L5 D 维度 | 功能对不对（内容客观正确性） | EvalHarness 自动 + 公式 | 姿态、流程、体感 |
| L7 V 维度 | 姿态对不对（战略价值守没守住） | AI judge（不 self-judge） | 功能对错、体感 |
| L8 真人体验 | 体感顺不顺（真人主观"是不是 FinBayes"） | 真人（项目 owner） | 客观评测（前置依赖 L5/L7） |
| L6 人签 | 谁拍板放行（看完上述报告问责签字） | 项目 owner | 重做任何评测 |
一句话：L5 评功能、L7 评姿态、L8 校体感、L6 担问责。L6 不重做 L5/L7/L8 的评测，只在它们报告齐备后签字；L8 在 L5/L7 客观评测过关后才上，避免真人替机器做客观判断。
L0.5 · 隐式不变量 codify（新增）
目的：把白皮书 / 产品定义里"用文字承诺"的约束变成"代码可断言"的不变量。
实现：起一份 strategic-invariants-codified.md，列出 N 条不变量（M0 阶段 10 条核心，后续滚动补）。每条给：
- 来源（白皮书 §X / 产品定义 §Y）
- 不变量陈述（一句话）
- 反例（违反的代码 / 输出长什么样）
- test 规格（Pydantic validator / unit test 思路 / grep pattern）
M0 必备：10 条不变量见 strategic-invariants-codified.md（与本 ADR 同 commit 落地）。
何时升级：架构 / 产品 / 白皮书每次迭代后，30 分钟扫一遍——新引入的不变量是否需要补 codify。
L1 · 契约源（既有）
承接 Step 11 整改包 I 的 contracts/ 单一事实源层，承接现有 engineering-packs/ + ADR 体系。本 ADR 不修改 L1 定义，只把它纳入 SVA-9 框架。
L2 · Contract test（既有，M0 第一个 PR 落地）
承接 Step 11 既有规划。M0 第一个 PR 必须包含：
tests/contract_v1_1.py：StructuredCognitionResult 1.1 字段 / 类型 / 必填校验tests/invariants/*.py：L0.5 不变量映射代码（每条不变量 ≥ 1 个 test）
L3 · 三阶段实施 SOP（新增 supplement）
目的：防范"直接动手 coding 而不先 plan / 后 verify"。借鉴 GSD（Get-Stuff-Done）范式但不引入其工具。
SOP：每个 PR（不论 Codex 还是 Claude 实施）必须显式三阶段：
- plan：在 PR 描述里写"做什么 / 为什么这样做 / 风险点 / 不做什么"——50-200 字
- execute：写代码 + commit
- verify：跑
npm run verify:kb+ 跑 contract test + 跑 invariant test + 自我 review checklist
落地：见 ADR-003-supplement-3-phase-implementation-SOP.md（本 commit 同步落地）。
L4 · Archon workflow gate（既有，P0-6 重写已落地）
承接 ADR-003 既定的 Archon 编排引擎。每个 milestone 的 .archon/workflows/milestone-MN.yaml 用真 Archon schema（name / description / nodes，nodes 含 bash / prompt / approval + depends_on），不脑补字段。M0 的 milestone-M0.yaml 已由 P0-6 重写到位并经 archon validate workflows milestone-M0 通过。富 gate 语义（pass_criteria / 阈值 / required_checks / 约束门 / 验收 trigger）落在契约规约 .archon/specs/milestone-M0.spec.yaml（P0-7：旧富 yaml 改后缀并迁出 workflows/ 扫描目录——实测 *.yaml glob 会扫描 .spec.yaml 并因缺 name 报错，故仅改后缀不足，须迁至 .archon/specs/）；可执行 DAG 的 prompt 一律指向规约同名节点，不抄契约正文，规避契约分裂。
L5 · D 维度功能评测（既有）
承接 ADR-007 supplement · 金融认知体系第一版正式构成 已规划的 D1-D11 评测体系。本 ADR 不修改 L5 定义。
职责边界：L5 只判功能内容对不对（证据是否成立、字段值是否合理）。姿态对不对交 L7，真人体感交 L8，流程问责交 L6。
M0 阶段：M0 跑核心 D 维度子集即可起步（覆盖 main_answer / supporting_evidence / sources 正确性），全量 D1-D11 M1+ 补齐——避免 M0 第一个 PR 就被 11 个维度全量评测压住。
L6 · 人最终签字（既有）
承接 Step 11 整改包 III 决策权分级与 owner map。本 ADR 不修改 L6 流程。
职责边界：L6 不重做评测——L5（功能）、L7（姿态）、L8（体感）的报告齐备后，owner 看完拍板放行并对结果问责。L6 保障的是"有一个不可推卸的人负责"，不是"再评一遍"。
M0 阶段：M0 必跑。
L7 · V 维度战略价值评测（新增）
目的：D 维度只测"功能对不对"，V 维度测"姿态对不对"。
3 个 V 维度：
- V1 不替决策（NotDeciding）：FinBayes 输出有没有越界帮用户拍板？反例如"建议买入 NVDA"。
- V2 认知透明（CognitiveTransparency）：用户能否看到推理过程？反例如只给一个 confidence score 没有 reasoning。
- V3 用户主权（UserSovereignty）：用户能否随时退出 / 拿走数据 / 不被锁定？反例如某 prompt 让用户必须遵循 FinBayes 给的判断框架。
职责边界：L7 只判姿态对不对（守没守住战略价值）；功能对错交 L5，真人体感交 L8。L7 与 L5 都用 AI，但判的东西正交——L5 判"算得对不对"，L7 判"姿态越没越界"。
评测方法：用 Claude 当 judge（不是 self-judge，要求 judge 输出 V1/V2/V3 分数 + 反例引用）。
M0 阶段：M0 起步只需 V1/V2/V3 各 1 组 prompt（保证三个姿态维度都被触碰），全量 10 组 prompt 集 M1+ 补——M0 不必一次铺满全量 prompt。
落地：见 v-dimension-evaluation.md（P0-4 落地）。
L8 · 真人使用体验校验（新增）
目的：L5（功能）/ L7（姿态）都是 AI 评 AI（包括 Claude judge AI），最终人类锚必须有真人体感。
职责边界：L8 只判真人主观体感（"这是不是 FinBayes 该有的样子"）；它不替机器做客观判断——功能客观对错是 L5、姿态客观越界是 L7。因此 L8 在 L5/L7 客观评测过关后才上才有意义。
M0 阶段（减负）：M0 第一个 PR 阶段的产物多为 stub / 中间态，真人 30 分钟全量体验性价比低，因此 M0 改为可选轻量化：1 case × 10 分钟试跑，不作 hard gate（结论入 milestone log 即可）。M1+ 起恢复完整 SOP：
M1+ 完整 SOP：每个 milestone 跑 1 次：
- 用户用 FinBayes 完成 3 个 case（每个 ≤ 10 分钟）
- 用户填一张 5 题问卷（用得顺不顺 / 信不信 / 是不是 FinBayes / 哪里别扭 / 是否会再用）
- gate：3 个 case 中 ≥ 2 个用户 confirm "是 FinBayes 该有的样子" → milestone pass
落地：见 l1-user-vibe-check-cases.md（P0-5 落地）。
§3 与既有体系的关系
| 既有 | SVA-9 怎么承接 |
|---|---|
| ADR-001 工程范式（M0/M1/.../ 三检 review gate） | M1+ 每个 milestone 必跑 L0.5 → L8 全 9 层；M0 减负：L8 真人体验降为可选轻量化、L5 跑核心子集、L7 跑各维度 1 组 prompt（详见 §2 表 M0 阶段列）；三检 review gate 是 L5/L6/L7 的具体落地形式 |
| ADR-003 工程实施栈（OpenSpec + Archon + Claude + Codex） | L4 = Archon gate；L3 = supplement 落地的实施 SOP；Claude/Codex 分工不变 |
| ADR-011 FB-RESUME | SVA-9 是"实施质量层"；FB-RESUME 是"推进连续性层"。两者并存，FB-RESUME 让 SVA-9 能跨 session 长跑数月 |
| Step 11 整改包 I/II/III/IV | I = L1；II = L4；III = L6；IV = 跨 section 校验属于 L2/L3 |
| Step 12 角色互换 review | 属于 L6 之上的兜底机制，不在 9 层内但承接 9 层 |
| Step 13 元根因深度分析 | SVA-9 的 L7/L8 是对 Step 13 "AI 自审 AI 必然不收敛"的工程化答案——L7 引入"AI judge 但不 self-judge"，L8 引入"真人 vibe" |
§4 九层落地物锚点（M0 启动时刻状态）
| 层 | 落地物路径 | 状态 |
|---|---|---|
| L0.5 | governance/workstreams/finbayes-arch-rewrite/strategic-invariants-codified.md | 本 commit 落地（P0-3） |
| L0.5 | tests/invariants/*.py（在工程仓 FinBayes） | M0 第一个 PR 落地（C-1） |
| L1 | contracts/ + engineering-packs/ + ADR | 已有 |
| L2 | tests/contract_v1_1.py（在工程仓 FinBayes） | M0 第一个 PR 落地（C-1） |
| L3 | ADR-003-supplement-3-phase-implementation-SOP.md | 本 commit 落地（P0-2） |
| L4 | .archon/workflows/milestone-M0.yaml（真 schema 可执行）+ .archon/specs/milestone-M0.spec.yaml（契约规约） | P0-6 重写已落地（archon validate 绿） |
| L5 | contracts/evaluation-dimensions.yaml + engineering-packs/eval-harness-formulas.md | 已有 D 维度，V 维度由 P1-1/P1-2 补 |
| L6 | PR review + milestone gate（owner = 项目 owner） | 已有 |
| L7 | v-dimension-evaluation.md | P0-4 落地 |
| L8 | l1-user-vibe-check-cases.md | P0-5 落地 |
§5 触发：何时升级到哪一层
| 场景 | 触发层 |
|---|---|
| 新 PR opened | L1 contract 读 → L2 contract test 跑 → L3 SOP 三段都得 explicit |
| M0 milestone gate（减负） | L0.5 invariant test + L2 contract test + L4 archon workflow + L5 核心 D 子集 + L6 人签 + L7 V1/V2/V3 各 1 组 prompt；L8 降为可选轻量化（1 case × 10 分钟，不作 hard gate） |
| M1+ milestone gate（完整） | 全 9 层都必跑一次（L0.5 invariant test + L2 contract test + L4 archon workflow + L5 全量 D 维度 + L6 人签 + L7 全量 V 维度 + L8 完整 3 case vibe check） |
| 战略白皮书 / 架构文档迭代 | L0.5 + L1 + L7 重审 30 分钟 |
| 紧急 hotfix | 至少 L2 + L3 verify 段 + L6 人签；可豁免 L7/L8（hotfix log 注明） |
| 持续推进无 milestone gate | 滚动跑 L2 + L3 即可，不必每 PR 全 9 层 |
§6 反模式（禁止）
- ❌ 跳过 L0.5 直接写代码 —— 白皮书的不变量没 codify，等于没承诺
- ❌ L2 contract test 用 mock 数据绕过真接口 —— 必须真跑 1.1 契约
- ❌ L3 plan 写 < 50 字 / 不写 verify 段 —— 等于没过 SOP
- ❌ L7 用 self-judge（Claude 评 Claude 的输出） —— 必须 Claude judge Codex 的输出 / 反之
- ❌ L8 vibe check 用 mock 用户 —— 必须真人（项目 owner 本人）
- ❌ L6 人签前没看 L0.5 / L7 报告 —— 等于空签
- ❌ 任何一层 fail 但 milestone gate 强过 —— 系统性破坏，必须回退
§7 后果
收益：
- 战略愿景对齐有系统性兜底，不依赖单点注意力
- 9 层并行运转，单层 fail 不会拖垮整体（其他层仍能 catch）
- 实施成本相对低：L0.5 / L7 / L8 三个新增层都是文件 + 简单流程，不引入新工具
- 与既有体系兼容（L1/L5/L6 不动），只是把"模糊承诺"显式化
成本：
- M1+ 每个 milestone 多了 ~3 小时（V 维度 1.5h + 真人 vibe check 1h + L0.5 不变量 review 0.5h）
- M0 减负后 约 ~1.5 小时（V 维度各维度 1 组 prompt ~0.5h + L5 核心子集 + L0.5 review 0.5h + L8 轻量 1 case 10 分钟可选）——避免 M0 第一个 PR 被全量评测压住
- 项目 owner 在 M1+ 每个 milestone 投入 30-60 分钟做 L8 vibe check（不可代劳）；M0 可选轻量化
- L7 judge prompt 需要随白皮书 / 产品定义迭代而维护
风险与缓解：
- 风险 1：L0.5 不变量列得过多导致 PR 老 fail
- 缓解：M0 仅 10 条核心，后续滚动加；不变量必须配反例验证可 fail，否则不收录
- 风险 2：L7 V 维度 judge prompt 漂移
- 缓解：judge prompt 进 git，跟着白皮书版本走；每季度 sanity check
- 风险 3：L8 vibe check 用户疲劳（每个 milestone 都跑 30 分钟）
- 缓解：M0/M1 高频，M2+ 改为每 2 个 milestone 跑 1 次
§8 SOP 速查（M0 启动前必备）
C-1（M0 第一个 PR）开 PR 之前必须就位：
| # | 项 | 状态 |
|---|---|---|
| 1 | L0.5 strategic-invariants-codified.md（10 条 + test 规格） | P0-3 |
| 2 | L3 ADR-003-supplement-3-phase-implementation-SOP.md | P0-2 |
| 3 | L4 .archon/workflows/milestone-M0.yaml 真 Archon schema（archon validate 绿） | P0-6 ✅ |
| 4 | L7 v-dimension-evaluation.md | P0-4 |
| 5 | L8 l1-user-vibe-check-cases.md（3 case 草案，M0 仅试跑 1 case 轻量化、不作 hard gate） | P0-5 |
| 6 | 旧 milestone-M0.yaml 改后缀 .spec.yaml 并迁至 .archon/specs/（避免被 workflows/ 扫描报错） | P0-7 ✅ |
| 7 | V1-V4 协作环境验证（archon doctor / validate / serve / hello-world）全绿 | C-1 启动 hard gate |
§8bis Audit trail / Changelog
| 日期 | 调整 | 理由 | 原结论是否保留 |
|---|---|---|---|
| 2026-05-29 | 承接 fresh review W3 · 九层减负 + 叙述正向化：① §0 / §2 叙述口径从"九层防御 / 每层防什么"改为"为兑现愿景每层正向保障什么 + 兜底边界"；② 新增 §2bis 明确 L5/L6/L7/L8 去职责重叠（L5 评功能 / L7 评姿态 / L8 校体感 / L6 担问责，不互相承担）；③ §2 表新增"M0 阶段"列，标注 M0 必跑 vs M1+ 再上——L8 真人体验 M0 降为可选轻量化（1 case × 10 分钟、不作 hard gate）、L5 跑核心 D 子集、L7 跑各维度 1 组 prompt；④ §3 / §5 / §7 / §8 同步标注 M0 减负 | 原方法论文档自身仍部分防御过重：L5/L6/L7/L8 评测层职责重叠、每 milestone +3h 对 M0 过载、命名偏 Prevent（目标其实是 100% 兑现愿景 = Build-Y）。本次去冗余 + 减 M0 负担 + 叙述正向化，与 ADR-013 Build-Y 优先口径对齐 | 保留。九层实质不变、不删任何一层；只去职责重叠、标注 M0/M1+ 分期、把叙述口径从 Prevent 转 Build-Y |