跳到主要内容

慢线（事后复盘 / 准确度校准）现状与落地设计

§0 这份文档是什么 + 结论先给​

ADR-025 定了「快慢两条线」：快线 = 即时应答的 ReAct 主循环；慢线 = 独立后台，按天 / 季度的尺度做失效条件监控 + 事后市场验证 + 准确度校准。本文是慢线的一次设计 pass（scoping + 设计，不写码）。

结论先给（两条）：

  1. 慢线的核心闭环已经建好并在跑——不是 ADR-025 当时（2026-06-07）写的「mostly 未建」。判断台账、两步写入、心跳每日复盘、校准（Brier / ECE / 可靠性曲线）都已落地接线（§1，带 file:line）。所以这一轮不是「从零造后台程序」，是在这套已经在转的闭环上，把它建到诚实、可信、健壮。
  2. 这一轮的核心，是让它的打分可信。 关键一步：判断入账时就冻结当时的行情快照，复盘才有诚实的基准去对照，而不是事后重新拉最新数据去评旧判断（那会系统性污染打分）。§9 金融 Agent 骨架 点明这条线的真正难度就在打分诚不诚实，所以第 1 刀 = P0 快照冻结（§4）。

现状来源说明：§1 现状地图来自一次只读代码摸底（FinBayes claude/baseline-rebuild 分支，出处带 file:line）。其中 P0 直接相关的判断台账 schema（finbayes/judgmentlog.py:40-59 无快照字段）已人工读码确认；其余条目以摸底为准，每刀动手前会逐条复核。

§1 现状：慢线核心已建（已接线）​

能力位置（FinBayes 仓）现状
判断台账finbayes/judgmentlog.pyappend-only JSONL（崩溃安全）。confirmed 行 = {judgment_id, symbol, rating, conviction, invalidation, as_of, ts}；outcome 行 = {…, verification_status, verdict, note, price, as_of, ts}。枚举：verification_status ∈ {watching,pending,verified,blocked,unverifiable}，verdict ∈ {correct,wrong,partly,indeterminate}。
两步写入finbayes/agent/tools/watchlist.py:416-493propose_judgment（暂存候选、不入账）→ 用户确认 → confirm_judgment 写 confirmed 行 + 生成稳定 judgment_id。这就是 ADR-007 / ADR-032 说的「候选→确认」两步。
记结果finbayes/agent/tools/watchlist.py:542-575record_outcome 写 outcome 行（只记日志、不改标准记录）。
心跳后台finbayes/heartbeat/service.py:71-34130 分钟一轮 + 每天一次独立跑失效条件复盘（_check_invalidation_conditions :248-288）：读失效条件 → 派 agent 重新取行情核对 → record_outcome，命中才通知用户。.last_judgment_review 日历日去重（重启安全）、按团队成员 scope 隔离。
校准finbayes/calibration.pycompute_calibration → 命中率 / Brier / ECE / 可靠性曲线，按把握度桶分层。映射 CONVICTION_PROB {high:.7,medium:.5,low:.3}、VERDICT_OUTCOME {correct:1,wrong:0,partly:.5}，indeterminate 不计入（诚实、不造精度）。build_calibration_context（:136-155）把校准成绩注入系统提示让 agent 看到自己历史准不准。CLI finbayes calibration 可查。

判断：§9 说「FinBayes 的 Bayes 落地就落在慢线」——这个闭环已经在转。这条线在阶段 1 的「切片」工作里建好（判断台账 + 心跳复盘 + 校准），ADR-025「mostly 未建」是相对当时、现已过时。

§2 要做什么：把慢线建到诚实、可信、健壮​

核心闭环在转，这一轮按四件事把它建扎实（按价值排序，对应 §3 的分刀）：

P0 · 冻结判断当时的行情快照 → 打分有诚实基准​

判断入账时，把它当时依赖的行情（标的现价 + 失效条件引用的读数）冻进台账。这样复盘和校准都对着「判断那一刻」的基准打分，而不是事后重新拉的最新数据——前视偏差从源头堵掉，校准成绩才可信。这是价值最高的一块（§9 金融 Agent 骨架：慢线全部难度就在打分诚不诚实）。→ §4。

P1 · 给失效条件结构化 → 机器能自动判定触发​

失效条件除自由文字外，再带一组结构化规则（标的 + 指标 + 比较符 + 阈值 + 时限）。心跳就能算术化地判「哪条触发了」，不必每轮靠 agent 重读理解文本。P0 冻的基线读数为「跌破 / 上穿」这类判定铺好底。→ §5。

P1 · 故障恢复 → 一次网络抖动不漏一条复盘​

复盘按成员各自记进度、失败下轮自动重试；台账写入失败有界重试 + 诚实上报。让自动复盘真的可靠。→ §5。

P2 · 校准分层 + 把回灌策略定死 → 成绩看得清、回灌按治理走​

校准从只按把握度桶，扩到按时间（季度演进）、资产类切片，成绩能按维度看（分层维度来源见 ADR-020 三判官）。同时把「校准要不要回去改 agent 行为」这条策略明确定死：默认只进看板、要翻开走显式门控（ADR-025 决策 4）。→ §6。

P3 · 看板 → 判断台账 / 失效条件 / 校准曲线看得见​

把这三样数据摆出来给人看的一层视图。→ §7（并进 fin-claw Web 集成线）。

§3 建议分刀顺序​

  1. 第 1 刀 = P0 快照冻结（价值最高、解锁诚实校准）+ 顺手给「成绩单注入」加开关、默认关。→ §4。
  2. 第 2 刀 = P1 失效条件结构化 + 故障恢复 + 通知目的地收口（让自动复盘真的可靠 + 收口 review 留的安全项）。→ §5。
  3. 第 3 刀 = P2 校准分层 + 回灌闸写死。→ §6。
  4. 第 4 刀 = P3 看板（可视化判断台账 / 失效条件状态 / 校准曲线）。→ §7（owner 2026-06-25 拍：整体并进 fin-claw Web 集成线、本刀只出设计存档、不实现）。

每刀独立可上、可验收；后刀依赖前刀（P1 自动判定依赖 P0 的基线读数）。

§4 第 1 刀详细设计：P0 快照冻结​

§4.1 P0 要做什么​

给每条判断入账时补上「当时的行情基线」。现状 record_confirmed（judgmentlog.py:40-59）只记 as_of 日期、不记当时的价 / 指标值，于是：(a) 没有「判断当时基线」，说不清失效条件当时离触发多近；(b) 校准只能拿事后（可能被修订的）最新数据打分，系统性偏；(c) 这份偏掉的校准还会经 build_calibration_context 注入回 agent。P0 把这个基线冻下来，三件事一起解决。

§4.2 冻结什么（只冻这条判断真正依赖的量）​

只冻这条判断真正依赖的量：

  • 标的现价（spot），带出处（venue + fetched_at）。
  • 失效条件引用项的当前值 = 失效条件的「基线读数」：条件说「跌破 500」就冻当前价；说「RSI 上穿 70」就冻当前 RSI。
  • 一个标准小 panel 的证据值（owner 2026-06-24 拍：不靠 agent 自报、固定冻一组——标的的几个标准指标 + 失效条件涉及的宏观值），有限几个、非全 panel；理由：简单、可靠、不依赖 agent 每次声明。
  • 每个值带 FetchResult / SourceRef 出处信封（venue / as_of / fetched_at），复用已有取数出处机制、不另造。

§4.3 存哪 + schema​

confirmed 行加一个可选字段 snapshot（嵌套 JSON）：

"snapshot": {
  "captured_at": "<ISO ts>",
  "spot": {"value": 540.2, "venue": "...", "fetched_at": "..."},
  "baseline": {"<失效条件引用项>": {"value": ..., "source": "..."}},
  "evidence": [{"name": "RSI_14", "value": 68.1, "source": "..."}]
}

append-only JSONL，无需 schema 迁移；旧行无 snapshot → 见 §4.6 兼容。

§4.4 何时抓（关键：propose 时，不是 confirm 时）​

判断的 as_of = agent 做出判断那一刻，即 propose_judgment（watchlist.py:416-445）。快照必须反映那一刻，不是用户稍后确认时。

  • propose_judgment 时抓快照，优先复用对话里 agent 刚取的数据（避免再取一次产生时间差）；取不到则就近取一次。随 pending 判断暂存。
  • confirm_judgment（watchlist.py:447-493）把它写进 confirmed 行。
  • 出处诚实：快照每个值标真实 fetched_at；若是 confirm 时补取则如实标，不假装是 propose 时。

§4.5 复盘 / 校准怎么用​

  • 复盘（心跳失效条件检查）：把冻结基线 + 当前值一起给判定逻辑——「当时 540、失效线 500、现在 480 → 已触发」。基线让触发与否可判，不靠 agent 凭空回忆当时多少。
  • 校准（calibration.py）：打分用 {冻结基线, 失效条件, outcome 行 price} 三者，不临时重拉最新数据 → 杜绝前视偏差。

§4.6 兼容 / 迁移​

  • 旧 confirmed 行无 snapshot：校准时标 unverifiable（或带 caveat 计入），不假装有基线。
  • 不动现有枚举 / 字段，只加可选 snapshot；旧代码读到忽略即可。

§4.7 连带：回灌闸（同刀做掉）​

给 build_calibration_context（calibration.py:136-155，把成绩单注入提示）加开关，P0 未全量验证前默认关——快照冻结落地前注入的校准可能已被前视偏差污染，等于喂 agent 错的自我评价。ADR-025「回灌默认关」在此落实。

§4.8 这一刀的范围​

  • 失效条件本刀仍是自由文字，但「基线读数」已冻、为 P1 的自动判定铺路（结构化 DSL 归 P1）。
  • 聚焦冻结基线这一件事：重试队列归 P1、分层归 P2、看板归 P3。
  • 校准数学公式不动——P0 只改「喂给它的数据从哪来」。

§4.9 验收（这刀算做完）​

  • 新判断 confirmed 行带 snapshot（spot + 基线 + 出处）；单测覆盖 propose→confirm 快照透传。
  • 复盘读冻结基线而非重拉；校准对冻结值打分；单测构造「数据被修订」场景，验证打分不漂移。
  • build_calibration_context 开关默认关，有测试。
  • 旧无快照行优雅降级（不崩、标 unverifiable）。

§5 第 2 刀详细设计：P1 失效条件结构化 + 故障恢复 + 通知目的地收口​

§5.1 这刀做三块 + 骨架原则​

按 §3 的刀序，第 2 刀让「自动复盘」从「每轮靠 agent 重读文字」升级到「机器能自动判定触发」。三块：失效条件结构化（§5.2–5.4）、故障恢复（§5.5）、心跳通知目的地收口（§5.6，原是 review 留的安全项 task_45649986，因同动心跳通知路径、一并做）。

骨架原则（与 P0 同构）：P0 是「值确定性取、判断归 agent」；P1 是「触发确定性判、判断归 agent」。失效有没有被触发是算术（基线、现值、阈值一比就有答案），交确定性评估器；触发意味着什么 / 要不要改判是判断，仍交 LLM 复盘。评估器在慢线（心跳）内、不碰快线 ReAct 主回路，只机械化「触发与否」、不替代判断——守 ADR-025 头号铁律「不在主回路外架控制墙」。

§5.2 失效条件结构化：schema + 谁产出​

失效条件除自由文字外，可带一组结构化规则（agent 在 propose 时产出，不解析自由文字——解析正是 P1 要逃离的脆弱点）：

"rules": [
  {"metric": "spot",   "op": "crosses_below", "threshold": 500, "horizon": "2026-09-30"},
  {"metric": "RSI_14", "op": ">",             "threshold": 70}
]
  • metric：标的现价 spot / 具名指标（RSI_14、EMA_50…）/ 具名宏观（US10Y…）——每个都映射到一次确定性取数（复用已上线的 ema / rsi / keylevels 与宏观 DH / FRED）。
  • op ∈ {<, >, <=, >=, crosses_below（跌破）, crosses_above（上穿）}。
  • threshold：数值；horizon：可选时限（ISO 日期）。

自由文字照留（人读 + 兜底）。结构化规则是机器数据，跟 P0 的 snapshot 一样走「暂存进 Pending → confirm 写进 confirmed 行」、存台账行（不是 WATCHLIST.md 散文），心跳从台账读。

基线冻结接 P0：propose 抓快照时，把规则引用指标的当时值冻进 P0 预留的 snapshot.evidence[]（judgment_snapshot.py:80 注释明写为此预留）。这样 crosses_below / crosses_above 这类需要「当时在哪边」的判定，有冻结基线可比，不靠重拉。

§5.3 确定性触发评估器​

心跳复盘先跑评估器：逐条规则取现值（带出处）→ 比阈值 / 基线 → 给每条一个确定性判读 ∈ {已触发 / 仍持有 / 判不了}：

  • 阈值类（< > <= >=）：现值与阈值直接比。
  • 跨越类（跌破 / 上穿）：用冻结基线 + 现值（如「基线 540 ≥ 500、现值 480 < 500」= 跌破已触发）；无基线 → 判不了。
  • 取数失败 / metric 不认识 → 判不了。

汇总后分流：

  • 全部仍持有（无触发、无判不了）→ 确定性记一条 watching、静默，不调 LLM（省 token，也不让 agent 误判平静局面）。
  • 有触发 → 交 LLM 复盘，把「触发的规则 + 冻结基线 + 现值」注入任务，让 agent 做判断（对论点意味着什么、要不要改判、要不要 propose 新判断）。
  • 无触发但有判不了 → 交 LLM 复盘（确定性兜不住，老实交给 agent），不假装 all-clear。

§5.4 向后兼容​

旧判断 / 无结构化规则的判断（只有自由文字）→ 评估器无规则可跑 → 直接退回现在的行为（整段文字交 LLM 复盘）。结构化是叠加层，不破坏老判断、不改自由文字这条路。

§5.5 故障恢复（owner 拍「最小」）​

  • 每个成员独立的复盘标记：现状全局一个 .last_judgment_review（heartbeat/service.py:49）→ 改成每个 scope 自己 workspace 下的标记（_workspace_for(scope) 已有按人目录）。一个成员复盘失败 → 不写它的标记 → 下轮自动重试；成功的成员有标记 → 不重跑（避免重复 record_outcome 污染校准）。重启安全。
  • 复盘有界重试：on_execute 超时 → 有界重试 + 退避（覆盖「一次网络抖动漏复盘」这个实际缺口）；仍失败 → 不写标记（下轮再来）+ 大声 log。
  • 台账写入兜底：record_confirmed / record_outcome 写失败 → 有界重试 + 大声上报（confirm 如实告诉用户「已写进 watchlist、但持久台账写入失败、校准可能漏这条」）。不做平行影子台账——同盘失败模式、还要对账，复杂度换不来等量真韧性。

§5.6 通知目的地收口（task_45649986）​

心跳复盘命中后 agent 用 message tool 通知用户；目的地当前由 agent 在 tool call 里自填。风险：watch data 里的 prompt-injection（即便已被 BEGIN/END 围栏 + 「data not instructions」削弱）若绕过，可能把通知导去别处。收口 = 心跳上下文里 message 的目的地钉死到被检查 scope 的主人（该 workspace 对应的 principal），不由 agent 选。实现时读 message tool + 渠道路由确认钉法。

§5.7 这一刀的范围​

  • 结构化规则由 agent 产出，自由文字仍是文字（不做自然语言解析器——解析正是 P1 要避开的脆弱点）。
  • 确定性首批锁 spot + 指标；宏观 metric 取数较重、首批先退 LLM 复盘，metric 取数可插拔、后续接不破接口。
  • 校准分层归 P2、看板归 P3；回灌闸已在 P0 §4.7 定死。校准数学公式不动。

§5.8 验收（这刀算做完）​

  • 带结构化规则的判断 propose→confirm，规则进 confirmed 行、指标基线进 snapshot.evidence[]；单测覆盖透传。
  • 评估器单测：跌破 / 上穿用冻结基线判定、阈值比较、未知 metric / 取数失败退 LLM；构造「全持有 → 静默不调 LLM」「有触发 → 交 LLM 注入」两分支。
  • 每个 scope 独立标记：构造一个成员复盘失败 → 下轮重试、成功成员不重跑（不重复 record_outcome）。
  • 台账写失败 → 重试 + 用户看到诚实上报，不静默丢。
  • 心跳 message 目的地钉死到 scope 主人，injection 改不了收件人；回归测试。
  • 旧无规则判断优雅退回 LLM 复盘，不崩。

§6 第 3 刀详细设计：P2 校准分层 + 回灌闸写死​

§6.1 这刀做两块 + 骨架定位​

按 §3 刀序，第 3 刀让慢线「看清楚」：P0 让打分诚实（冻基线）、P1 让触发可判（结构化规则），P2 让成绩能按维度看 + 把回灌行为这条闸的策略写死。两块：校准分层（§6.2）、回灌闸写死（§6.3）。不碰快线 ReAct 主回路、不改校准数学公式、不加台账字段——分层是对现有行的纯推导。

owner 2026-06-25 两处签字（照推荐）：(1) 回灌闸钉死关闭、显式门控（不是现在翻开）；(2) 分层第一刀只做时间 + 资产类，团队成员维度延后。

§6.2 校准分层：轴 + 谁产出​

现状 compute_calibration（calibration.py:87）只按把握度桶（high / medium / low）算可靠性曲线。P2 把分桶泛化成「按 key 函数切片」，新增两条轴：

  • 时间（季度演进）：从判断日 as_of 取季度键 YYYY-Qn（缺失 / 不可解析退回写入时间 ts）。
  • 资产类：复用已有分类器 symbol_class.classify（data/symbol_class.py:25）→ crypto / equity / a_share，不自造。

报告结构加 strata 字段，每条轴下每个切片报同一套 headline 指标（n / 命中率 / Brier / ECE）——同一套数学、只换喂进去的配对数据，不改公式。把握度可靠性曲线（现有 reliability）原样保留、老调用方不受影响。

成员维度留到有数据再切：成员分层要跨各人 scoped workspace 走目录聚合（判断台账按 principal 隔离在各自 workspace），且只有 P3 看板才看得到；现阶段本地基本单 principal（owner），切出来基本空。接口已留可插拔（key 函数与首批两轴同形），待多 principal 有数据即可补上。

先各轴独立切、暂不做交叉表：数据少时把握度 × 资产类 × 时间交叉表是噪音；每条轴独立切、各报 headline 指标即够，把握度可靠性曲线仍在顶层。

§6.3 回灌闸写死：两层闸​

ADR-025 决策 4「校准结果默认不自动回去改 agent 行为，先只进看板」。闸分两层，分开钉死：

  1. 算法层自动回灌（按成绩单自动微调 agent 的把握度映射 / 先验）：没建（对）。P2 立成不变量——CONVICTION_PROB（calibration.py:27）是固定设计常量、永不被战绩自动调；除非过治理决策、永不自建。靠文档 + 代码注释钉死，不靠运行时断言（那是表演）。
  2. 成绩单注入提示（build_calibration_context，让 agent 看到自己历史准不准）：现状主循环一句硬编码 inject_calibration=False（注释写「可信后在这翻开」）。P2 把它收成命名常量 CALIBRATION_PROMPT_INJECTION（calibration.py），策略 + 翻开门控写在定义处 = 单一事实源，不再「改一行字面量就静默变行为」。

翻开门控（三条件，全满足才翻）：(1) P3 校准看板已建；(2) owner 经看板看过真实已结算的校准数据；(3) 一份 ADR 记录这次翻开。在此之前战绩只喂人（看板 / CLI），不进提示——守 ADR-025「先只进看板」。无需新 ADR（ADR-025 已立此向）。

§6.4 向后兼容 + 输出去向​

  • 老台账行无 as_of / 异常 symbol：季度键退回 ts、资产类落 equity 兜底，切片照常、不崩。空台账 strata 为空对象，消费方无需特判。
  • 分层入报告结构供 P3 看板将来消费；CLI finbayes calibration 即时渲染（format_calibration_summary 加 show_strata 显式开关，默认关——心跳摘要等共享调用方不受扰）。空切片照实报样本量、不渲虚假精度（守实质而非表演）。
  • 诚实说明：现阶段已兑现判断数基本是 0（判断刚开始攒、未复盘兑现），分层现在建好、随判断兑现才显真数据——同 P1 评估器「建好、潜伏到有数据才激活」。

§6.5 这一刀的范围​

  • 分层首批做时间 + 资产类；团队成员维度待多 principal 有数据 + P3 看板（接口已留可插拔）。
  • 看板本身归 P3。
  • 回灌默认只进看板：不翻开注入、不建算法层自动回灌（按 ADR-025 决策 4，翻开走显式门控）。
  • 分层是对现有 symbol / as_of / conviction 的纯推导——不加台账字段、不改 Brier / ECE 公式、不碰快线。

§6.6 验收（这刀算做完）​

  • compute_calibration 出 strata，含资产类 + 季度两轴；单测构造 crypto 对 equity、Q1 对 Q2 切片，验证分桶正确 + 每片指标 = 该片单独算（分层不改数学）。
  • 季度键单测：as_of 解析 + ts 退回 + 都判不了返空。
  • 老顶层指标 + 可靠性曲线不变，全套回归绿。
  • CLI 渲染分层（show_strata 显式开），心跳摘要不受扰；空切片诚实降级。
  • 回灌闸：CALIBRATION_PROMPT_INJECTION 默认关、有测试钉死；策略 + 三条件门控写在常量定义处。

§7 第 4 刀：P3 看板（设计 → 实现并进 Web 集成线）​

§7.1 是什么 + 这一刀怎么落​

P3 看板 = 把慢线攒下的三样东西摆出来给人看的一层视图：判断台账、失效条件状态、校准曲线（含 P2 分层）。慢线一直在后台记判断、复盘、算校准；P3 让这些看得见——人能一眼看到「agent 做过哪些判断、现在哪些失效条件亮了、它的把握度到底准不准」。看板只读，照实反映慢线记下的，这是它的本分。

这一刀怎么落（owner 2026-06-25 拍）：P3 整体并进团队 fin-claw Web 集成线。 fin-claw 已有成熟的 React Web 看板；P3 三块数据正好当 FinBayes「对 Web（及以后桌面端）API 接口层」的第一批只读端点、由 fin-claw 前端渲染——一份看板由近亲前端落地，而不是在慢线里再造一个图形看板。本刀产出设计，实现交 Web 线（那条线见 FinBayes 仓 handoff-anchors/ 集成 scoping brief、走自己的 ADR 弧）。

§7.2 看板做成什么样（三块 + 数据源，都已建好）​

看板段数据源（现成接口）形状
校准曲线 + 分层calibration_report(workspace) → dict；format_calibration_summary(report, show_strata=True)顶层指标（命中率 / Brier / ECE）+ 把握度可靠性桶 + P2 分层（资产类 / 季度两轴）
判断台账JudgmentLog(workspace).read_all()；单标的渲染范例 build_symbol_judgment_history每条 confirmed 判断 + 最新 outcome + 冻结基线（P0 快照）+ 失效线
失效条件状态未结算 confirmed 行的 rules（P1）+ 最近 outcome 行每条未结算判断的失效条件：已触发 / 仍持有 / 待复盘 + 复盘时间

三块数据慢线已全部建好（P0 / P1 / P2 上线时一并落地），P3 是「读出来 + 渲染」。

§7.3 怎么做：失效条件「现在什么状态」取自最近复盘​

看板显示失效条件状态，直接用心跳复盘已记下的最近结论 + 复盘时间（从台账 outcome 行读）。好处：看板与慢线复盘同一个事实源、口径一致——复盘是失效状态的权威，看板照实呈现；还省掉看板自己实时取数重算这条更重的路（那会和复盘机制各算各的、还多一次取数失败面）。还没轮到复盘的判断标「待复盘」。

§7.4 怎么做：三块数据 = Web API 接口层首批只读端点​

P3 三块数据是 FinBayes Web API 接口层最自然的首刀——只读、数据现成、契约清晰：

  • 校准报告端点 ← calibration_report(workspace)（dict，含分层，直接序列化）。
  • 判断台账端点 ← JudgmentLog.read_all() 聚合（confirmed 配 outcome + 冻结基线）。
  • 失效条件状态端点 ← 未结算判断 + 最近复盘结论（§7.3 口径）。

按 principal 作用域读（Web 用户 = 新一类 principal，沿用 <channel>-<uid>）。这批端点是快照查询、不需要流式。端点形状 / 认证 / 部署归 Web 线细化，本节锁定数据源 + 口径 + 「P3 当 API 首批场景」这个定位。

§7.5 落地后解锁什么：回灌闸第一个条件​

P3 看板落地，会解锁 P2 回灌闸的翻开条件一「P3 校准看板已建」。慢线「把校准战绩回灌进 agent 提示」这一环，要 owner 经看板看过真实校准数据（条件二）+ 落一份 ADR（条件三）才翻——P3 看板是这条链的第一步。既然 P3 并进 Web 线，这一步就随 Web 线落地；在此之前回灌注入保持关闭（现状如此）。

§7.6 这一刀的产出​

本刀交付设计（实现随 Web 线）：三块数据接口清单 + 失效条件取数口径 + Web API 端点的数据源规格 + 回灌闸解锁点。Web 线接手时，§7.2 / §7.4 就是它 API 首批端点的数据源起点。慢线 P0 / P1 / P2 已上线 + P3 设计落档 = 这一轮设计 pass 收尾。

§8 开放决策 / 暂不做​

  • 要 owner 拍：(1) 已纠 ADR-025「慢线 mostly 未建」回写（本批做）；(2) 设计方向 = 补诚实 + 健壮缺口（非从零造）；(3) 先出 P0 详细设计（本文 §4）。—— owner 2026-06-24 三条均同意。
  • 已签：P1 三处架构选择（确定性触发闸 + LLM 判断 / 故障恢复最小 / 安全项一并，2026-06-25）+ P2 两处（回灌闸钉死关闭显式门控 / 分层只做时间 + 资产类、成员延后，2026-06-25）—— 均照推荐签、已落地（FinBayes 本地）；P3 形态（2026-06-25）= owner 拍整体并进 fin-claw Web 集成线、本刀只出设计存档不实现（§7），富图形看板 + API 端点归 Web 线。
  • 进度收口：P0 / P1 / P2 已落地（FinBayes 本地、已 live），P3 实现并进 Web 集成线（§7.1）→ 慢线这一轮设计 pass 收尾；「判断正确与否的诚实定义」（§9 命门）由 P0 的冻结基线 + P1 的结构化失效条件 + outcome price 三者共同支撑，留实现时收敛，可复用治理仓 14-case 校准研究当素材。
  • 架构站位：慢线是一条独立后台，经判断台账与快线松耦合——失效条件「有没有触发」由确定性评估器算，但「要不要改判」始终归 agent（这正是 ADR-025 头号铁律「判断不离主回路」的落地）。这是这条线的承重设计。

§9 关联​