yilunjiang/AgentLab
1
0
Fork 0
mirror of https://github.com/ThearchyHelios/AgentLab.git synced 2026-11-15 00:51:59 +00:00
Code Issues Packages Projects Releases Wiki Activity
895 Commits 4 Branches 0 Tags
ccb2b2baa8d2a406ed5b4f65b187028107fc02a8
Commit Graph

895 Commits

This Branch
This Branch
All Branches
Author SHA1 Message Date
ThearchyHelios ccb2b2baa8 评测停止、中断、到了上限后的计数照实分开：没跑的题单独计 not_run，stop_reason 写停下的原因 
验收：评测停止或中断后，没跑的题计入 errors、done = total、stop_reason 为 null，读起来像全评完了、出了很多错。
原因：runner._counts 把 cancelled、skipped 都算进 done（TASK_DONE），cancelled 又算进 errors；停止、中断走 _close →
_conclude(status, None, error)，原因写进了 error、stop_reason 是 None；服务重启后的整理（startup、reconcile_stale）
和排队中就停掉（cancel_queued）只改了逐项状态，计数还是旧的、stop_reason 也没写。

改法：
- _counts：done 只算真的跑过的（ok、partial、failed）；停止、中断时没评完的（cancelled）和到了上限、止损之后没开评
  的（skipped）单独计 not_run；errors 只算 failed；skipped 只算评了、但期望算不出、不评分的（verdict），不再混进没开评
  的。done + not_run + running + pending = total。
- 停止、中断是「停下」不是「出错」：_close 把原因记进 stop_reason（STOPPED / INTERRUPTED），error 留空；整体出错照旧
  记 error。到了上限、止损本来就写 stop_reason，不变。还没备好几臂就停下的那一支（bare）同样写 stop_reason 并重算计数。
- core/job_runtime 的 close_job、cancel_queued 加一个可选的 finish：状态改好、提交之前在同一个事务里补一步。评测的
  startup、reconcile_stale、stop 用它记 stop_reason、按改好的逐项状态重算计数（_closing）。起草、剖析、探查不传，
  行为不变（它们的测试全过）。
- stats.summarize 的 not_run 也只算没跑的（cancelled、skipped），出错的另列 errors（以前 not_run 里混着出错的）。

前端：评测页总览「N 项没评（停止、中断，或者到了上限、止损之后没开评）」和「M 项出错」分两行；类型补上 not_run、
errors 的说明。停下的原因本来就照 stop_reason 显示。

测试（test_eval_runner）：停止之后 stop_reason 是「评测已停止」、error 为空，errors 为 0、done 是评完的题数、not_run
是其余，总表的 not_run、errors 同样分开；重启整理成 interrupted 时 stop_reason 是中断的说法、计数重算（not_run 1、
running 0）；新增一条排队中就停掉的：not_run 等于题数、pending 归零；到了金额上限没开评的那题记 not_run、不记跳过。
去掉修复回跑挂 4 条。check-evals 的停止夹具照服务端改，核对停下的原因、不当成出错、没评的单列。评测、起草、剖析、
探查、定时维护相关的测试 548 条全过；tsc、check-copy 通过，check-evals 103 项全过。
 2026-10-17 09:10:52 +08:00
ThearchyHelios a4486af90b check-evals：接住画布页起画布对话的 POST /conversations，免得偶发地漏到服务端 
「口径命中与重复度」一节点「提取模板」会去画布（/studio/wf-drafted），画布页随后给这张图起一段画布对话
（POST /conversations {kind: canvas}）。页面不关，这一下早晚不定：赶在最后那一节「写请求都在浏览器层拦下」之前
发出去就算漏到服务端。在 main 上连跑两次一次挂一次过，和这一轮的改动无关。照 check-ledger 的写法在假接口里接住
（交回一段空的画布对话），不进写请求的清单——不是评测页发的。改后连跑两次都过。
 2026-10-17 09:02:57 +08:00
ThearchyHelios eb6abffc61 评测逐题结果给出这一题实际问的问题，模板原文另放 question_template 
验收：评测结果列表里 question 是原始模板（带 {{ schedule.last_week_start }}），作答运行实际收到的问题已经渲染好了。
results 接口直接取的是 EvalCase.question。

改法：api/evals 的 _asked_questions 按执行时同一个算法、同一组输入渲染：题目模板 + 这次评测的截至时间（as_of，
建评测时就定下、重试不变）+ 题集时区 + 定时的 cron（runner._unit 交给 Driver 的就是这个）。题目在这次评测之后
改过（结果记的 case_hash 对不上现在的）时，现在的模板不一定是当时问的：改取作答运行输入里的 question，也没有
（反问、建图失败没有运行）就给 null，不拿现在的模板编一个。模板原文放 question_template。没有加库表的列：
渲染是确定的，不用另存。

前端：评测页逐题表的问法一格写实际问的问题；模板原文和它不同时（带变量，或题目改过）另起一行「题目原文：…」，
文案进 termsEval。类型补上 question_template。

测试：test_eval_runner 新增一条：带变量的题，结果的 question 和作答时 Driver 收到的一字不差、不含 {{，模板原文在
question_template；没有变量的题两者一样；题目改过、没有作答运行可取时 question 为 null、模板照给。去掉修复回跑挂。
check-evals 的夹具给带变量的那一题配上渲染好的 question 和模板原文，核对逐题表写的是实际问的、原文另起一行，
没有变量的题不多这一行。tsc、check-copy 通过，check-evals 102 项全过（漏到服务端的那个偶发问题另一次提交里修）。
 2026-10-17 09:02:57 +08:00
ThearchyHelios f5c9f0c13c 剖析任务接口收取值观察范围，对话框给出「取值观察」；定时维护挑不出要观察的表时把原因记进触发记录 
验收：取值观察只能经定时维护触发——POST /catalog/profile-jobs 的 scope 只收 needed、all，可剖析任务本来就支持
observe（只观察、不剖析）。另外 12 小时内观察过的表不再观察时，任务以 0 张表结束，原因只在剖析任务的 notice
里，从定时维护触发时触发记录（ScheduleFire.inputs）看不出来。

后端：
- ProfileJobIn.scope 加 observe（maintenance 是定时维护用的，接口照旧不收）。挑不出表时照旧 409 profile_nothing，
  说法是 NOTHING_TO_OBSERVE（「最近 12 小时内都观察过了」）。
- catalog_profile_jobs.nothing_reason：按此刻的表结构和目录一张表都挑不出来时交回 ProfileNothing 的原话；排在
  起草后面时说不准，返回 None。
- source_maintenance._start：建出 0 张表的剖析任务、这次触发又没有探查（开始时表结构不会变）、也没排在起草后面
  （目录不会变）时，判断得出任务会以 0 张表结束，把原因记进 inputs.skipped（同一套 NOT_RUN 说法进 reason）。
  任务照建、触发照旧是 started：每小时一次的维护不至于一天二十几次「没能发起」。同一次触发里有探查、或者排在
  起草后面时判断不了，保持现状，写进了模块说明。

前端：剖析对话框的范围里加「取值观察：有数据目录的 N 张表」（说法照维护设置里「取值观察」那一步：码值分布、
最新业务日期、按日行数和行数，和同口径的历史比出取值变化；最近 12 小时内观察过的这次不再观察），建任务带
scope: observe。张数按清单上有数据目录、不是视图的表算（isObservable，profile.ts），观察到期没有由服务端判，
所以是上限。挑不出表时说「没有要观察的表」和服务端原话，不给「改选全部表」（那是剖析，不是观察）。文案进
PROFILE_TEXT。

测试：test_catalog_observe 新增一条（接口建 observe 任务、只做观察检查，再建一次 409 profile_nothing，maintenance
422）；test_source_maintenance 新增一条（只选取值观察，12 小时内再触发：任务 0 张表，inputs.skipped 和 reason 写明
原因）。去掉修复回跑两条都挂。check-catalog-profile 跟上：范围多一项 observe:1，说法核对；新一节建取值观察任务
（请求体 {scope: observe}）、都观察过时的「没有要观察的表」且没有「改选全部表」。tsc、check-copy 通过，
check-catalog-profile 204 项全过。
 2026-10-17 08:51:51 +08:00
ThearchyHelios c3173909db 整理：前两次提交里超过 120 字的两行折行，absent_message 进 source_objects 的 __all__ 
只动排版和导出清单，不改行为。
 2026-10-17 08:42:26 +08:00
ThearchyHelios 9040289e1f 固化成口径草稿：口径卡用传入的名字、报告指令不写死代表那一轮的日期、指标名取目录中文名、已固化去重 
验收报告里 certify.freeze 的四处：
- 口径卡的 caliber 用的是代表问题的原文，没用传入的 name。改成 name（去首尾空白）优先，没传才用代表问题。
- 报告的 instructions 写死成「回答：<代表问题>」，问题里带着那一轮的日期（「上周（10月5日到11日）」「九月第一周」），
  参数化之后这句就错了。有入口参数时改写运行时渲染的参数（「这次的参数：p1 = {{ input.p1 }}，…；时间范围、筛选的
  取值以参数为准」），不写问题原文；没有参数时取数的字面量都是口径的常量，照旧写问题原文。
- 指标名直接用列名。现在能从数据目录取到中文名的用中文名：先看查询快照冻结的目录（schema_artifact，和口径比对用的
  同一份，ledger.match._frozen），老快照没冻结的看数据源现在的目录；只认列名本身就是目录里的一列（SELECT amount、
  SUM(amount) AS amount），gmv 这类算出来起的别名取不到，照旧用列名。
- 认证队列里 cluster 项的 frozen_into 把同一个工作流列了好几次：固化时同组的几次运行都记进 origin.sources，一项里
  的几次运行就各指一遍同一个工作流。shape 项同样会重。加 _frozen_of 按工作流去重（保持先后），三种项都用它。

测试（test_ledger_certify）：原来的固化用例改成断言指令里没有代表问题和日期、有 {{ input.p1 }} {{ input.p2 }}，
没传名字时口径卡照旧用代表问题，shape 和 cluster 两项的 frozen_into 都只有一个工作流；新增一条：传了名字的口径卡
用名字，目录里有中文名的列（amount → 金额）用中文名、取不到的照旧（n），没有参数时指令照旧写问题原文。去掉修复
回跑两条都挂。
 2026-10-17 08:35:57 +08:00
ThearchyHelios 3f75cb1d2e 恢复被驳回的运行：照 end_reason 说「被驳回」，和继续运行同一个错误码 run_rejected 
验收：对被驳回的运行调 POST /api/runs/{id}/resume，回的是「这次运行已取消，没有待处理的审批，无法恢复。已取消的
运行请重新发起」，/continue 却是对的（run_rejected）。resume 只看 status，cancelled 一律说「已取消」；存量的
failed + 驳回还会被说成「失败的运行可点继续运行」，而继续运行其实会被拒。

改法：runner 加 _resume_refused：cancelled + end_reason=rejected、以及加 end_reason 之前记成 failed 的驳回
（_rejected_before，同 continue_failed 的判断）抛 ContinueRefused(REJECTED_RESUME, code=RUN_REJECTED)，别的照
_cannot_resume。resume 开头的状态检查、等审批凑齐时发现运行已经不在 interrupted 两处都用它。/resume 接口像
/continue 一样把带机器码的拒绝回成 CodedHTTPException(409, …, code)。ContinueRefused 是 ValueError 的子类，
别的调用方（待办服务）照旧按 ValueError 接。

测试：test_run_rejected 新增一条：驳回的运行 /resume 回 409 + run_rejected、说「被驳回」；手动停止的照旧说
已取消、不带这个码；存量 failed + 驳回也回 run_rejected，不再叫人点「继续运行」。去掉修复回跑挂。
 2026-10-17 08:31:17 +08:00
ThearchyHelios c64c7a1062 目录接口对探查范围外的表照实说「在探查范围外」，不再说「可能已被删除或尚未探查结构」 
验收：GET /api/datasources/{id}/catalog/{表} 对「对象索引里有、但在探查范围外」的表回 404「数据源中没有表 …，可能
已被删除或尚未探查结构」，而 /schema 和 /catalog/search 都说对了。_table_key 一律写死这一句，没看 absent_reasons。

改法：source_objects 加 ABSENT_MESSAGE 和 absent_message()，给人看的五种「不在」（表已不在、全库对象清单里也没有、
在探查范围外、在范围里却读不到结构、老缓存说不清）一句一句，和界面的 CATALOG_ABSENT_TEXT、/schema 用的
schema_view.absent_detail 同一套原因。上传表格、记录表按版本走，没有对象索引又没截断过的老缓存认不出名字是不是
从来就没有过：这两种只说「数据源中没有表 …」，不说「已删除」。用到的三处都换成它：_table_key（表详情、审阅、
使用记录等十来个接口共用）、表助手开始前的 404、批量审阅逐条的 table_missing 错误。

测试：test_catalog_schema_truncated 新增一条（205 张表、规则只收 200 张的合成库）：范围外的表在表详情、表助手、
批量审阅里都说「探查范围外」，对象索引里也没有的说「没有表 …」。去掉修复回跑挂。
 2026-10-17 08:28:54 +08:00
ThearchyHelios 7db9760121 用量计量拿到调用时实际用的模型名：评测汇总里助手用量不再记成 unknown 
验收：评测汇总里助手用量的模型是 "unknown"，写作用量的模型却是对的。写作用量来自运行的 llm.end（节点配置里
就有模型名）；助手用量来自 providers/usage.Meter，它只从回调的 invocation_params 取 model / model_name，而演示
模型 MockChatModel 没有 _identifying_params，调用参数里只有 _type 和 stop，于是落到 UNKNOWN_MODEL。

改法两处：
- Meter：调用参数里取不到时，看 LangChain 照模型对象给回调的 metadata 里的 ls_model_name（调用时传的 model，
  否则对象上的 model / model_name），再取不到才看回复、才记 unknown。不认得调用参数的模型类也记得对。
- MockChatModel 补上 _identifying_params（model_name），和 OpenAI 兼容、Anthropic 一样在调用参数里报模型名。

测试（test_usage_meter）：调用参数里不报模型名的模型、演示模型都按对象上的名字记；三种接入（OpenAI 兼容、
Anthropic、演示模型）由 factory 建出来，照 LangChain 回调时给的参数喂给计量，记的都是接入里配的模型 id，
调用参数里本身也带着；评测作答（eval/answer.Driver）走演示模型时助手用量记在 mock-fast 名下。两处修复都
去掉回跑挂 3 条，只留计量那处时挂「调用参数里本身带着」那一条。
 2026-10-17 08:24:15 +08:00
ThearchyHelios caeab0fad6 SQL 差异说明认得同一列上的条件改写：说清「这次对 X 的条件是 …，口径是 …」 
验收：口径 status = 'paid'、这次 status IN ('paid', 'refunded')，explain_sql_diff 只给兜底「两条 SQL 的写法不同，
未能归纳成具体差异」。原因是差异说明只说四类，同一列上两边各写一套条件（等号对 IN、取值集合不同、范围端点不同）
不在其中：_extra_filters 看到另一边也用了这一列就放弃。

改法：_Explainer 加 _rewrites，排在 _times 之后、_extra_filters 之前。同一张实表的同一列两边 WHERE 里都有条件、
至少一边有没配上的，就说「A 对 X 的条件是 …，B 是 …」；两边都只是取值集合、又有共同的取值时补「（这次多了
'refunded'）」。两边都是时间条件时 aspect 是 time_range（FacetDiff 说明里早有这个方面、engine/compare 也按它
排序），否则是 filter 且 a、b 两边都有——dual_check_facts 对两边都有的 filter 本来就说「两边各有不同的筛选条件」
不写目录，ledger/stats、评测页的方面叫法都已认得这两个名字。

为了不说出不存在的不同，只在这些条件都满足时说：两边用到这一列的条件都只涉及这一列、比的是那一列本身；
按取值逐段算过两边留下的取值确实不同（_Range.compare 加 never_null：表结构里确定不为空的列不拿空值比；
x >= 100 AND x >= 50 对 x >= 100 这类冗余写法算出来一样，不说）；不在 LEFT JOIN 可空一侧；WHERE 之外（ON、
HAVING、CASE、聚合参数）都没用到这一列（SUM(CASE WHEN status = 'paid' …) 配上 IN 可能和只筛 paid 一样）；不是
认不准的时间窗口；没换表；有认不出列的条件时整段不说。

只改说明、不碰等价判定：说明只在已经判了不等价之后才跑。新测试把 _rewrites 换成什么都不做，逐对（语料全部
加几对改写、两种先后、给不给表结构）比等价与否和判定的级别，一字不差；IN 只有一个值、IN 列表去重排序照样判等价。
语料执行守门（意思一样的对不许说出具体不同）全过。

测试：test_sql_semantics 新增三组（各方言说两边、可能不影响结果的不说、等价判定不变）；原来断言这两类只给
兜底的用例改成「算出来的值上换了值」（LOWER(status)）仍只给兜底；test_sql_text_diff、test_dual_check_facts 跟上
（同一列上的时间范围现在是 time_range，照样不写目录；换了筛选的值不写目录）。去掉 _rewrites 的调用回跑，新测试
挂 5 条。

双盲复算的前端夹具 dual_check.json 里「说不清的」那个变体原来就是同一列上的时间范围，现在说得出了：换成套着
DATE() 的时间范围（认不出取值范围，仍只给兜底），test_dual_check_fixture 重新生成，check-verify 对应的说法和
高亮那一行的断言跟上。
 2026-10-17 08:17:12 +08:00
ThearchyHelios 7f949cce92 取值观察：业务日期有未来值时不再误报量跌、缺天；「今天」统一按服务端所在时区 
验收复现：业务日期最晚到明天、今天只写了几行，记出一条 volume_drop。原因有两层：
- 比较器 value_drift.daily() 取 last = max(days)，只在 last >= today 时退一天；max 落在明天时退到的是今天这个
  还没写完的日子。改成最近一个整天 = min(有数据的最后一天, 昨天)。
- 按日行数的查询 day_volume_sql 只有下界，未来的日子也进了窗口。加上界：数到观察当天（含），第二天起不算
  （< 第二天，时间列上当天的时分秒照样算进来，文字存的日期按字符串比同样成立）。签名改成必须传 until。

缺天同样的问题也修了：今天以后的空日子不算缺天；以前那次观察只看到它自己那天（data.until）为止，免得它
窗口里未来的空日子被当成「以前就有过缺天」，挡住这一次真缺的天。断档遇到未来值时离今天是负数，只会报不出、
不会误报，观察本身照实记最新业务日期（目录里也照实给人看），不截未来值，写进了模块说明。

「今天」：原来窗口用 UTC 日期、比较器用 now.date()（也是 UTC），业务日期是本地日期，东八区凌晨 0–8 点会差
一天。统一成服务端所在时区（catalog_profile_observe.local_today，和待办汇总 notify.digest_at 同一个口径），
写进模块说明。

测试：test_value_drift 两条（未来值不算最近整天、未来空日子不算缺天且历史按 until 截）；test_catalog_observe
两条（SQLite 真跑剖析任务，明天的行不进窗口、不记量跌；local_today 按 TZ 取本地日期）。去掉修复回跑都挂。
金样（tests/fixtures/dialect/*.sql）的 day_volume 一行随上界更新；scripts/dialect_it.py 加了一条「只数到观察
当天」的真库核对。
 2026-10-17 07:59:19 +08:00
ThearchyHelios adfd783a07 合入下一轮第 4 波（收口，docs/design/next-round）：口径召回（发布新版本后反查用过旧版的答案、按参数分组在同一份数据上重算两版之差、数变了才开召回待办、没变的只记账；目录事实与表结构变动标「依据有变」；版本用量与发布弹窗的召回预告、版本历史的召回批次）；评测前端（导航「评测」、题集与加题、发起与进度、结果、对比与 A/B、口径命中与重复度、目录快照；定时页选目标种类；设置里的评测一组）；口径账本前端（证据「口径」一步、问数据轮次摘要与出具 / 对账、对账反馈、可沉淀的问题、设置里的口径账本一组、比对结果轮询）；目录前端（「变化」视图与处理、数据源角标、表详情的变化一节、定时维护、后台任务条）；遗留：被驳回的那一步各处画「被驳回」、问数据建图用量不再是下限、比对结果实时、source.changed 与 ledger.recall 打开订阅。验收：后端全量 14284 通过；tsc、文案检查；本波相关的 21 项浏览器检查 7084 项全过；泄露扫描干净 2026-10-16 22:43:04 +08:00
ThearchyHelios ccf1fb21d2 check-all：第 4 波三项检查的耗时估计按实测改（只影响排队顺序） 2026-10-16 22:42:45 +08:00
ThearchyHelios c8cd56c108 README：第 4 波的升级说明（导航「评测」、口径召回、依据有变、被驳回的那一步、建图用量、两个新通知事件、后台任务条与定时维护）；核心能力加「回归评测」「口径账本」两行；新增「回归评测与口径账本」一节和数据目录下「结构变化、取值变化与定时维护」一节；单进程前提补上后台任务与锁；检查清单 43 项 2026-10-16 22:33:59 +08:00
ThearchyHelios cc51c98df3 文案：删掉起草、剖析在页头和旧进度条上的几条说法（第 4 波起进度只在目录页的后台任务条上，见 termsSource 的 JOB_STRIP_TEXT） 2026-10-16 22:31:18 +08:00
ThearchyHelios d4e68bd1a9 合入 W4-d 目录前端：数据目录的「变化」视图与处理动作、数据源角标、表详情「结构与取值变化」一节、数据源的定时维护（一条目标为数据源的定时任务）、后台任务条（探查、起草、剖析按服务端排队顺序）；打开 source.changed 订阅；指名数据源卡片统一用 #source-<id> 2026-10-16 22:30:09 +08:00
ThearchyHelios d17a08bafb 合入 W4-c 账本前端：证据「口径」一步与数字上的小标记、问数据轮次摘要与按口径出具 / 对账、对账视图与反馈、可沉淀的问题、设置里的口径账本一组、比对结果按退避轮询；被驳回的那一步 node.failed 带 reason=rejected，画布、航迹、时间线、问数据过程都画「被驳回」 2026-10-16 22:29:02 +08:00
ThearchyHelios 13bd021219 合入 W4-b 评测前端：顶级导航「评测」（搭建者以上、⌥0）、题集与四种加题、发起评测与预估花费、评测详情与逐题结果、对比与 A/B、口径命中与重复度、目录快照；定时页选目标种类、认得数据源维护的触发记录；记录页的评测来源；设置里的评测一组；问数据建图用量不再是下限（读完模型的流再关）；问题聚类的向量只取一次 2026-10-16 22:28:35 +08:00
ThearchyHelios c26f4f2d30 合入 W4-a 口径召回：发布新版本后反查用过旧版的答案（问数回答、正式运行、固定它的版本与应用、导出），按参数分组在同一份数据上重算两版之差（差值在召回卡里算），数真变了才开 recall 待办、没变的记「已按 vN 核对，不影响」；目录事实和表结构变动标「依据有变」；版本用量与发布弹窗的召回预告、版本历史里的召回批次与接着算、recall 待办卡；团队渠道一次召回只推一条；账本接口带召回标记，对账结果可以反馈；E4 2026-10-16 22:28:34 +08:00
ThearchyHelios 1195c4abcb 账本前端补两样：答案身上的召回标记写到问数据的轮次和证据面板「口径」一步；对账结果卡上问「说明有用 / 看不懂」 
复核 W4R-03（a×c）：召回在原答案的运行上追加 ledger.recalled、ledger.basis_changed，以前只在运行时间线（decode）里，问数据的
轮次底部、证据面板「口径」一步、账本接口都不带——使用者被标了「依据有变」、或者口径升版后「已按 v2 核对，不影响」，重开对话
什么也看不到，得点开「过程」才翻得出来，而使用者进不了记录页。W4-a 已在账本接口加上 recall（ledger/recall.answer_marks：
checked / basis / tasks，几种 state 都带），这边照它画：

- typesLedger：RunLedger.recall（LedgerRecallMarks）
- run/LedgerStep 新增 RecallMarks（问数据的轮次和「口径」一步共用）：「已按口径「X」vN 核对，不影响」（同一份口径核对过
  几次只写最近那一版，数变了的不在这里写）；依据有变按两类各一行——数据目录（catalog / values / catalog_edit）和表结构
  （structure），认不出的种类只说「答案的依据有变」不猜，项数相加，按新目录新出现错误级问题的写几条；看的人手上有说的是
  这个答案的召回待办时写一句（口径升到 vN、数变了 / 依据有变检查出新问题）并链到 /apps/inbox/{待办}
- LedgerTurn：比对过的卡里写在摘要下面；没比对、不比对的答案（state 不是 matched）只要带着标记就单独写一张小卡
- LedgerPart（证据面板「口径」一步）：有标签的写在脚注前；没标签但答案带着标记的，这一步只写标记

复核 W4R-10（多包）：细案 02 做法 10 的 E2「说明有用 / 看不懂」以前没有入口。W4-a 已加 POST /ledger/answers/{run}/reconcile/
{对账运行}/feedback（{verdict: useful | unclear}，记成对账运行上的封存后事件、统计 E2 数它），账本接口的 reconciled 每一项
带 feedback {mine, useful, unclear}。这边：

- api.caliberLedger.feedback；typesLedger 加 LedgerFeedback、LedgerFeedbackOut
- run/LedgerReconcile 的对账卡：做完的卡问一句「「差在哪」的说明有帮助吗？」，两个按钮，看的人选过的按下（aria-pressed），
  写各几个人（服务端给的数），可以改主意；交回来的反馈先画上，账本再取一次让别处挂着的同一张卡跟着变；回收站里只看不反馈；
  没做完的卡不问
- 问数据的轮次里卡片上方没有「差在哪」，卡里补写一份（showWhere），反馈问的就是它；证据面板里它本来就在卡片上方，不重复

检查（写请求都在浏览器层拦下）：
- check-evidence 新一段 ledger-recall：比对过的答案「口径」一步写核对过（只写最近那一版）、依据有变（项数相加、新问题条数）、
  链到待办；不比对的答案这一步只写依据有变
- check-chat 新一段 recall：轮次底部同上，另核对做完的对账卡写「差在哪」和反馈人数；不比对的答案单独一张小卡写表结构有变
- check-ledger 对账一段：没做完不问；点「看不懂」请求体只有 verdict、按下、写各几个人；改点「说明有用」再记一条、按下的换过来
- 共用夹具 ledger-fixtures 加 RECALL
把这几个文件的改动拿掉回跑：check-chat recall 6 项、check-evidence ledger-recall 4 项、check-ledger 对账反馈 2 项都不过；
放回去全过
 2026-10-16 22:21:11 +08:00
ThearchyHelios f72e1d4a65 问数据、画布右栏、运行详情的步骤时间线：被驳回的那一步画停止的剪影、行尾写「被驳回」，不再是绿色的完成勾 
复核 W4R-02：decode 已经给被驳回的那一步（node.failed 带 reason=rejected）记 status=rejected，但三处共用的步骤时间线
run/AssistantStream 不认它：BADGED 里没有 rejected，徽标落到「顶层节点画完成」那一支，被驳回的那一步成了一个绿勾；字色是
正文色，行尾 STOPPED 也没有这一项——副标题写着「张工 驳回：金额不对」，图标却说做完了。细案 5.3 要的是驳回之后各处都写
「被驳回」。

- BADGED 加 rejected：画 lib/status 里 rejected 那一套（停止的剪影、取消的中性色，和画布节点卡同一个）
- 这一行用次一级的中性字色（比取消、跳过的淡色重一档：运行就停在这一步），副标题（谁驳回、备注）用正体、不再是淡色斜体
- 行尾：STOPPED 加 rejected。被驳回的那一步带着耗时（node.failed 的 duration_ms），只写耗时的话停止的方块和取消分不开，
  写成「被驳回 · 900 ms」
- 长列表折起来时照样露出被驳回的那一行（notable 认 rejected）：运行停在这一步，不能收进「展开前面的 N 条」
- check-chat「被驳回」一段：run-rej2 的事件换成「查数」那一步 node.failed 带 reason=rejected，点开执行过程核对这一行的
  状态、剪影（stop，不是 square）、图标不是完成的绿色、副标题和行尾写「被驳回」、不写「失败」。改之前这三项不过（徽标是
  done、颜色是 --st-done 的绿），改之后深浅两套都过
 2026-10-16 22:18:44 +08:00
ThearchyHelios 464d1c0741 召回复核修正（前端）：召回待办的系统通知去待办页、使用者不给重新出具的记录页链接、旧版写不再接着算的原因、时间线认对账反馈 
- W4R-06：后台系统通知点开时，口径召回（不属于应用、挂在召回运行上）和使用者（进不了记录页）一律去 /apps/inbox/{id}。原来
  没有 app_id 的都去 /runs/{run_id}：使用者被送回应用首页，搭建者落到召回运行的详情页，那里没有这张待办卡。
- W4R-07：recall 待办里「重新出具的正式运行」只给搭建者链到记录页，使用者写「正式运行的记录由搭建者在记录页查看」（同问数据
  轮次下的出具结果）。
- W4R-12：版本历史里旧版还有没算的组却不能接着算时，照服务端给的 continue_reason 写「不再接着算：……」，不给按钮。
- decode 认 ledger.feedback（对账运行时间线上一条一行：谁给了哪一种反馈；认不出的不猜）。

检查：check-inbox 加使用者 / 搭建者看重新出具过的待办、系统通知点开去待办页两段（通知换成记录器，点它就是调 onclick）；
check-publish 加之后又发布了更新版本的旧版不给接着算；check-decode 加 ledger.feedback 一段。去掉修复回跑，新加的几项都不过；
加上修复 decode、inbox、publish 三项 1110 项全过。tsc、check-copy 通过。
 2026-10-16 22:16:58 +08:00
ThearchyHelios b3dcddb52e 召回复核修正（后端）：人工节点不再挡召回、读不出召回卡记失败、旧版不再接着算、团队渠道一次召回只推一条、目录核对按数据源合并排队；账本接口带上召回标记，对账结果可以反馈 
- W4R-01：召回只查新版图里会不会写外部系统（apps/backfill 抽出 graph_external_write，graph_side_effect 复用它）。召回图只有两版
  的取数和口径卡，图里别处的人工节点、按流程使用的问题碰不到它；口径卡上游的人工节点 derive 本来就认作数据部分不能复用。
  「按新版重新出具」走完整的正式运行，仍按 graph_side_effect 全套拒绝。原来带审批的口径升版后一组都不召回，L6 对它们失效。
- W4R-09：收尾时召回卡读不出、或缺了某个比较的旧值 / 新值，照实记重算失败（读不出召回卡），原答案一个不动。原来两边都是空，
  按渲染比被当成「没变」，给每个原答案永久盖上「已核对，不影响」，收过尾之后再也不核对。
- W4R-12：这一版已经不是当前发布版（之后又发布了更新的版本）时不再发起召回、不给接着算，批次里写 continue_reason，接着算的
  接口 409 带同一句。同启动时接着做只认当前发布版：新版本的召回覆盖更早的所有版本，再按旧版开「口径升到 vN」的待办只是添乱。
- W4R-13：开登录时一组答案几个主人就几条待办，全局渠道却按这一批（recall.batch_of_key：同一次召回、同一个来由）只在最早开的
  那条上推一次，答案、待办按这一批汇总，几条的链到待办箱；别的几条连 task.opened 也不再推全局渠道。个人渠道照旧每人一条。
- W4R-11：目录审阅之后的核对按数据源排队、批量审阅的几张表合成一遍（catalog_pass，同一数据源一把锁）；查询快照按数据源在库里
  筛、按运行结束时间分页、每张表凑够 BASIS_MAX_RUNS 次运行就停；冻结的表结构快照这一遍里按工件 id 只读一次。原来批量审阅
  几十张表就同时起几十个后台任务，每个都全表扫查询快照、反复读同一份几 MB 的表结构快照。
- W4R-03（本包那一半）：GET /api/runs/{id}/ledger 加 recall：checked（已按 vN 核对，不影响）、basis（依据有变：哪一种、几项、
  新出现几条错误级问题）、tasks（看的这个人手上说的是这个答案、还没处理的 recall 待办）。不放数、不放表名。几种状态都带。
- W4R-10（本包那一半）：新事件 ledger.feedback（对账运行上的封存后事件），POST /api/ledger/answers/{run}/reconcile/{rid}/feedback
  {verdict: useful | unclear} 记反馈，同一个人改主意只算最后一次（app/ledger/feedback.py）；账本接口的 reconciled 每一项带
  feedback {mine, useful, unclear}；统计 E2 的 feedback 数到它，去掉「第 4 波接上」的占位说法。离线核对页、封存后事件摘要
  都认得这个事件。

测试：test_ledger_recall 新增七个用例、改了人工节点那一个（召回照算、重新出具照实拒绝）；新增 test_ledger_feedback；
test_ledger_api 的 E2 断言跟上。每个修复都先写失败的测试、去掉修复回跑确认抓得住。后端全量 14237 通过。
 2026-10-16 22:16:58 +08:00
ThearchyHelios 9886e10be2 账本接口：刚跑完未封存答 pending 只限结束后两分钟内，早就结束、一直没封存的照实答「运行还没有封存」 
复核 W4R-08：上一次给 GET /api/runs/{id}/ledger 加的 pending 分支没有时间界限——成功结束、要比对、没封存的运行一律答
pending。它本来只为 runner 落库 run.finished 之后、封存之前的那一下（页面收到 run.finished 立刻来取）。封存出了错、或者是
封存这件事之前的老数据，会永远答 pending：每个轮次底部、证据面板都转两分钟「正在比对口径」，再取一次还是 pending；改之前
答的 ineligible「运行还没有封存，不比对」才是实情。

- ledger/view.py：新增 SEAL_GRACE_S = 120（和页面等比对结论的上限 store/ledger.ts 的两分钟同一个量级），_just_finished 看
  finished_at 在不在这段时间里（没记结束时间的不算；库里读回 naive 的按 UTC 算，同 db/base.UTCDateTime）。只有刚结束的才答
  pending，其余照旧走 ineligible（NOT_SEALED）；_stamp 里的局部 datetime 导入挪到模块顶上
- 测试：刚跑完的那条补上 finished_at=现在；新增一条结束已久、一直没封存的和一条没记结束时间的，都答 ineligible、原因是
  没封存、不排按需比对。去掉 _just_finished 回跑，新测试失败（答的是 pending）
 2026-10-16 22:13:52 +08:00
ThearchyHelios 7f5578c094 定时任务页认得数据源维护：触发历史列出建了的探查、剖析任务和没执行的步骤；「去数据源页设置」改链 #source-<id>（复核 W4R-05、W4R-04） 
W4R-05 为什么：数据源维护的一次触发建的是探查、剖析任务，没有运行；api/schedules._fire_outs 不交触发记录的 inputs，
FireRow 只认 run_id 和 eval_run_id，于是每一次建了任务的维护都写成「已发起 · 未发起运行」，和数据源页「定时维护」的
「最近一次」对不上；「立即运行」一次维护还弹「未能发起运行」。

- 后端 api/schedules._fire_outs：目标是数据源维护的触发另带 inputs（{steps, jobs, skipped}，app/data/source_maintenance
  记在触发上的那一份，和数据源页「定时维护」读的同一个形状）；别的目标给 null（工作流触发的 inputs 是按模板渲染的工作流
  输入，触发历史不列）。触发历史、页头「上次触发」、列表、立即运行的答复都走它。test_schedules_api 的 FIRE_KEYS 加 inputs。
- 前端 FireHistory：维护的那一行逐个列建了的任务（步骤、任务种类、编号、表数），探查链到数据源页那张卡片、剖析链到数据
  目录里那个任务的进度（?pjob=，同「最近一次」）；没执行的步骤逐条写原因，服务端连成一句的原因不再重复；没建任务写
  「没有建任务」（刚触发、任务还在建写「正在建维护任务」），不写「未发起运行」。
- 立即运行（parts.runNow）：维护开始了说「已开始维护」、详情逐行写建了什么；跳过照实说上一次维护还没做完；没开始说
  「没有开始维护」和原因。状态小标签的悬停同理。
- types.ts 加 ScheduleMaintenanceStep、ScheduleMaintenanceInputs（和 W4-d 的 MaintenanceFireInputs 结构一致，合并后
  交叉类型照样过 tsc）；叫法进 SCHEDULE_TEXT（步骤叫法同服务端 STEP_LABEL，测试逐个对上）。

W4R-04 为什么：维护定时详情里「去数据源页设置」链到 /data/databases?source=<id>，数据源页（W4-d）只认 #source-<id>
（目录页后台任务条「查看」的约定），点过去落在列表顶上。统一成 #source-<id>：链接都经 model.sourceCardPath 出，
探查任务的链接同用它。

检查：check-schedules 新增「纯函数：数据源维护链到哪里、建了什么怎么写」「数据源维护的触发历史」两段（假接口：四种
维护触发、立即运行开始与跳过），改「链到数据源页」的断言；394 项全过。去掉 FireRow 的维护分支、链接改回 ?source= 回跑：
4 项失败。后端新文件 tests/test_maintenance_fire_history.py（立即运行一次维护后触发历史、页头、列表都带 inputs；工作流
触发不列渲染的输入；步骤和叫法前后端对上）。
 2026-10-16 22:02:09 +08:00
ThearchyHelios d0082b4645 问题聚类的向量只取一次：评测页「口径命中与重复度」不再按窗口把问题重发给向量模型（复核 W4R-14） 
为什么：这个页签一次打开，/api/evals/signals 按窗口调 compute_stats（缺省 6 个窗口，每个都聚一次问题），页面另调
/api/ledger/stats，一共聚 8 遍；chat/questions.cluster_questions 每遍都把窗口里的问题原文整批发给 embed_texts，
一次里重复的问法也照发。配了远程向量模型时每打开一次就是几百到几千次向量调用，慢、花钱。复现：本地 3 句问题各问 3 次，
一次打开每句被取了 9 次向量。

做法（改在全站唯一的取问题、聚类处 app/chat/questions.py，不动 ledger/stats 的统计口径）：
- 问题原文 → 向量在进程里留一份（_vectors，最多 VECTOR_CACHE_MAX=1000 句、最近用到的留着），同一句话只取一次，
  一次里重复的问法去重后只发一句；/signals、/ledger/stats、认证队列、治理页的探索问题聚类都走它；
- 缓存认「哪一个 embedder、哪一个取向量的函数」算的：设置页换了向量模型（configure 换了对象）整份丢掉，不把两个
  向量空间的坐标混着比；取的这一会儿换了的，这一批照用、不留；
- 取向量按事件循环串行（每个循环一把锁，同项目里别处的写法）：页面并行取的两个接口不把同一批问题各发一遍。

测试：test_evals_ui_api 新增「一次打开每句问题只取一次向量、再打开一次都不取、两个接口并行也一样」；
新文件 tests/test_question_vectors.py（去重、换模型丢缓存、取到一半换模型、上限与最近使用、并行只发一批）。
去掉缓存回跑：每句 9 次；去掉换模型的核对：2 条失败；去掉共用的锁：并行那条失败。
 2026-10-16 21:41:30 +08:00
ThearchyHelios 034ac4b63b W4R-04 数据源页：指名一张卡片的地址全站只认 #source-<id>，带 &maintenance 打开它的定时维护 
复核 W4R-04：定时任务页上维护定时的「去数据源页设置」链的是 /data/databases?source=<id>，数据源页只认 #source-<id>（目录页
任务条上探查的「查看」用的写法），没人读 ?source，点了落在列表顶上，既不滚到那张卡片也不打开定时维护。

改法按复核意见统一到 #source-<id>，数据源页这边：
- 新的 lib/sourceAnchor.ts 管这个地址的拼和拆（sourceAnchor / parseSourceAnchor / sourceCardId），两边各写一遍的话改一边
  另一边就落空。目录页任务条上探查的「查看」改用它，拼出来的地址和原来一样。
- DataSourcesTab 按 useLocation 的 # 处理：列表载入后滚到那张卡片；带 &maintenance 的再打开那张卡片的「定时维护」（只有
  手工登记的库才开，上传表格、记录表照旧没有这个入口），标记用过就从地址里去掉，刷新不再弹（同目录页的 pjob / djob）。
- 指名的数据源已经不在了（维护定时比数据源活得久，删数据源不删它）：照实说「没找到这个数据源，可能已经删除」，不然只是
  落在列表顶上、什么也没发生。

定时任务页那边的链接（ScheduleDetail.tsx，W4-b 的文件）这里不动，要改成 /data/databases#source-<id>&maintenance
（或 sourceAnchor(id, 'maintenance')），check-schedules 的断言跟着改。

check-catalog-changes 加一节「链到一张卡片」：前面垫十张库让那张落在第一屏下（先有对照：不带地址时看不见）；带 &maintenance
打开那张卡片的定时维护、滚到眼前、地址里只剩 #source-<id>；刷新只滚不弹；源不在了照实说；导入表格的源不弹；只是打开没有
保存，没有写请求。先写这一节跑出 6 项失败；修完 115 项全过；把打开、去标记、照实说三处去掉回跑，4 项报错，已还原。
 2026-10-16 21:37:25 +08:00
ThearchyHelios 4a81ad25bf check-auth：导航从九项变十项（搭建者、关登录各一处） 
第 4 波加了顶级导航「评测」（搭建者以上可见，评测-D8）：check-auth 里「搭建者：导航九项」「关登录：导航九项」两处按数目断言，
跟着改成十项，搭建者那处另断言「评测」在里面；使用者那处（只有应用和设置）不变。check-auth 不在 check-all 的清单里，另起一套
后端 + vite 跑了「导航」「关登录」两段，全过。
 2026-10-16 20:55:22 +08:00
ThearchyHelios 78252fdfa2 测试：评测页的前端取值和服务端常量逐个对上（tests/test_frontend_eval_unions.py） 
typesEval.ts 的联合类型（状态、发起方式、题目种类、结论、作答路径、期望种类、期望答案来源、升版处置、试算结论、各期望的结论、
转移、归因、目录视图、E1/E3 档位）和 termsEval.ts 里对应的叫法表，直接读文件和 app/eval、app/core/job_runtime、api/evals 的常量比：
服务端加了一种（比如作答路径「被驳回」）前端没跟上，界面会写出英文原值；同 test_frontend_type_unions.py 的写法，另开一个文件
免得和别的包改同一个文件。
 2026-10-16 20:46:18 +08:00
ThearchyHelios badd610cd2 评测页补齐：工作流题、手动清理更早的明细、逐题明细里的作答经过和答案原文 
前三波的接口这一波都要有界面（收口）：
- 加题时「写 SQL 定期望」「选口径」两种可以选题目种类——问数据题（问法交给助手）或工作流题（固定一个已发布版本、按入口字段填
  输入模板，考的是这一版本身）；题目表里工作流题写工作流和版本。反问、从运行认定只对问数据题有意义，不给选。
- 评测记录页签加「清理更早的明细」（POST /suites/{id}/cleanup，先确认、写清后果；收尾时本来就按保留规则自动清，这里是手动再清一次）。
- 逐题表展开时读这一题的明细工件（GET …/results/{id}）：自动重来了几次、作答的经过、答案原文——答错的题能看到它当时答了什么。

check-evals 跟着加三处（工作流题的请求体、清理先确认再发、明细），101 项。
 2026-10-16 20:41:50 +08:00
ThearchyHelios 45c1ede402 评测前端：顶级导航「评测」、题集与加题、发起评测、评测详情、口径命中与重复度、目录快照；定时页选目标种类；记录页评测来源；设置里评测一组 
为什么：前三波评测只有接口，这一波是收口——每样能力都要有界面、能走通（细案 01 第 18 项、第 15 项定时的前端部分，评测-D8）。
界面层不放逻辑：比率、结论、趋势、分档、能不能做都由服务端给（上一次提交在 api/evals.py 补的 latest、trend、actions、
preview、signals、逐题花费），界面只显示。

- 导航：「评测」排在设置前面、⌥0，搭建者以上可见（使用者的页面表在 visiblePages 里收窄，手输地址被送回应用首页）。导航从 9 项
  变 10 项，在 600、520、480 像素高的窗口里重新量过：≤520px 那档的导航项从 32px 收到 30px（17px 图标 + 2px + 11px 字），
  不然 480 高时遥测点超出视口 12px；App.tsx 的说明跟着改。
- 评测页 pages/evals/*（类型 typesEval.ts、接口 api/evals.ts、文案 lib/termsEval.ts 的 EVAL_TEXT）：题集列表（最近一次、同一
  变体的趋势、定时，没有定时给「设定时」带着题集去新建）；新建、导入（先预览）、导出、归档、删除、题集设置（时区、默认变体——
  定时评测按它评、预算只填要改的项）；题目表（启用、试算、编辑、删除），口径升版待处置的顶部提示和三选一处置（叫法由服务端给，
  没有缺省）；加题四种方式：写 SQL 定期望（选数据源、写 SQL、预览、点选格 / 列 / 配对列、按维度找行、试算，遮罩列拒收的原话
  落在 SQL 下面）、选口径（工作流｜口径卡｜指标，不能复用的照列写原因，口径的输入按那一版的入口字段填）、从问数据运行认定
  （选运行、选查询、选取哪一列，用到遮罩列的查询不给认定）、期望没有数据或期望反问；可另加文字要点。数值期望不许人填：只点选
  取哪一格。
- 发起评测：评一次 / A/B 对照（两到三臂）/ 目录贡献对照（预设，可加「只用已核实和已确认的项」），变体有助手、写作模型、结论
  裁判、目录（当前 / 只用已核实的 / 关 / 快照）、重复次数；估算和发起是同一份请求体，项数、按上一次估的花费、生效的预算、今天
  已花照服务端写；可点名和哪一次比。
- 评测详情 /evals/runs/:id：进度和每题正在做什么、停止、只重试没做完的、按新规则重评、设为基线（按钮照服务端的 actions 摆）；
  总览卡片（准确率和可追溯准确率带区间、花费、逐题 E1）和各项分布（结论、作答路径、出具档位、复核、结论裁判、引用率、查看、
  耗时、按角色的用量）；逐题表（结论、期望和答案里的数、弱匹配、SQL 差在哪、查看、耗时、花费，展开看原因、去运行详情；
  ?case= 定位那道题）；和上一次比（换基准、指纹差异、转移和归因）；A/B 配对表（都对 / 只 A 对 / 只 B 对 / 都错、p 值）。
- 「口径命中与重复度」页签：E1、E3 这一窗口的值和档位、参考线、往前几个窗口的趋势（GET /api/evals/signals），明细直接调口径
  账本的 GET /api/ledger/stats（总方案 X2）；成员不少于 3 的问题类能加入题集（带着问法去加题）、提取模板（从最近一次的运行提取，
  去画布）。目录快照页签：拍当前目录、影子起草（先估算再开始，能停）。
- 定时页：新建时先选定时什么（工作流 / 评测题集；数据源维护在数据源页建），评测题集的表单（pages/schedules/TargetEditor.tsx：名称、题集、
  FreqPicker、补发宽限，建题集目标用 ScheduleTargetCreate），评测题集的定时在详情里能改名称、频率、时区、补发宽限（SchedulePatch，
  只交改了的、带版本）；数据源维护的定时只读、链到数据源页，第 3 波「只能查看，不能修改」那句改成说清在数据源页设置；触发历史里
  的评测链到评测详情。纯函数 targetFormOf / targetCreateBody / targetPatchBody / targetProblems 放 model.ts。
- 记录页：评测运行旁的「评测」标记写是哪一步（作答、算期望……），点了回到评测里那道题；运行详情页头有键盘到得了的链接
  （pages/runs/EvalSource.tsx）。
- 设置：偏好设置里「评测」一节（pages/EvalSettings.tsx，SettingsPage 里加一行）：四项预算缺省、保留几次、缺省开不开结论裁判、
  今天已花；自己存、只交 eval 一组，取值范围只在服务端判。
- 问数据用量（评测-D14 的界面一半）：复核慢过问数据页的等待上限时，答案照原样先交出去，复核那一次的用量晚到了照记进这一轮、
  再落一次库（以前直接丢掉）；开发期 window.__chatReviewWait 让检查脚本把上限调短。

检查：check-evals.mjs 换成真检查（假接口加夹具，写请求在浏览器层拦下并断言请求体，98 项）；check-shell 导航十项、⌥0、三种窗口高；
check-schedules 目标种类（纯函数和页面）；check-chat 用量那一段加复核晚到。
 2026-10-16 20:38:07 +08:00
ThearchyHelios 9ad6c035d0 口径账本的界面检查：check-ledger 换成真检查，check-evidence、check-chat 各加一段 
都用 page.route 假接口加夹具（scripts/ledger-fixtures.mjs：GET /api/runs/{id}/ledger 的形状照服务端 run_view，挂在可点击
证据的夹具 evidence-doc.json 上，只用通用名），写请求在浏览器层拦下、核对请求体，认不出的写请求一律记账、结束时必须为空。

- check-ledger（骨架里的占位换掉）：
  · 比对还没出结果：「口径」一步写「正在比对口径」、按退避再取（间隔越来越长），等满了照实说、给「再取一次」、不再取，
    点了重新取、比对过了就画出来，之后不再取（store/ledger 在开发构建里挂 window.__ledger，把等待起点挪到两分钟前）；
  · 三种情况：来自口径（口径、级别、怎么认的、参数、事后补比的说明）、相关口径（差在哪 + 看差多少）、这次的推理；
  · 对账：参数要核对时表单直接打开、照入口字段画 → 发起带核对过的参数（空着的不送）→ 409 带回的选项画「选择要对照的
    指标」、一组没选不发起 → 选好再发起带上对照 → 结果卡片先写进行中、再取一次后画出按你的问法 / 按口径 / 差值 / 相对差，
    点差值打开出处链；
  · 可沉淀的问题：工作流列表弹窗里的抽屉，三类来源分开写、各写怎么认出来的；聚类只按那一轮固化；「不是口径」不写理由
    不能确认、写了才记下并拿掉这一项；固化走 from-run 的 freeze（带同组的别的运行和来源轮次）、打开画布里的草稿；
  · 使用者：不能出具的照服务端的原因写「请搭建者出具」、不摆按钮，对账照样能用，出具过的正式运行不给链接、写由搭建者查看；
  · 设置里口径账本一组：显示生效的值，不合规的值写范围、不让存，保存条写改了哪几项，整组写 ledger。
- check-evidence「口径账本」一节：来自口径的数字挂「受管 / 已发布」小标记（紧跟数字、悬停写口径和认法、读屏念在数字上），
  相关口径、这次的推理、没比对的不挂；面板「口径」一步在出处链最上面，四种标签各写各的，不是数的片段不画；同一次运行只取
  一次账本。别的节的夹具一律答不比对，不落到真服务端。
- check-chat「口径账本」一节：交付了的轮次底部先写「正在比对口径」，按退避再取到比对出结果后写摘要、比完不再取；按口径正式
  出具、对账按钮照服务端的动作摆，出具的请求只说按哪份口径，出具过的正式运行挂在轮次下面（档位、打开运行）；对账请求带
  哪条查询、哪份口径、核对过的参数。
 2026-10-16 20:34:21 +08:00
ThearchyHelios e48b258449 W4-d 收尾：队列里的任务结束时重取变化计数和清单；定时维护里不给探查任务点了没用的「查看进度」 
- 目录页：后台任务条的队列里有任务走了（结束了）就重取变化的计数、「变化」视图重取一页；走的是探查任务时清单也重取（表结构
  变了）。起草、剖析结束时页面跟着的任务本来就会重取清单。
- 定时维护「最近一次」：剖析任务的「查看进度」到数据目录页打开那个剖析任务（pjob）；探查任务没有另外的进度页（进行中时
  进度就在这张数据源卡片上），不再给一个关上对话框就什么也看不到的按钮。check-catalog-changes 补上这两条。
 2026-10-16 20:14:12 +08:00
ThearchyHelios bbf6ebb79d 召回收尾：启动时只接着做当前发布版的自动批次、补测重启后从已有召回运行重算计划；时间线认不出的依据种类不猜 
- ledger/recall.resume：最近发布、之后又发布了更新版本的不再接着做（新版本的召回本来就覆盖更早的所有版本）
- 测试：重启前只发起了一组、也没收尾，重启后接着发完自动那一批、补上收尾照样开待办，再重启一次不再发起
- run/decode：ledger.basis_changed 认不出种类时写「答案的依据有变」，不当成目录事实变了；batches 的说明照实写参数原样给搭建者
 2026-10-16 20:11:46 +08:00
ThearchyHelios 9252e6bb0e W4-d 检查：check-catalog-changes 换成真检查；check-catalog、check-catalog-profile、check-catalog-loop、check-capabilities 跟上 
- check-catalog-changes（骨架里的占位换掉）：假接口加夹具（虚构的网店库），写请求在浏览器层拦下、断言请求体。守的是「变化」
  视图的分组（要处理 / 提醒 / 说明，组内照服务端的先后）、两种筛选进请求和地址、刷新后还在；一条变化的依据、前后、影响面
  （目录项现在的状态、「这条 SQL 现在会报列不存在」、模板链到编排页那个节点、有效记录条件）；动作照服务端给的 actions 画、做不了
  的写原因；清理先确认、加入码值带含义、知道了、误报的请求体，误报没写理由（含只填空白）按钮不能点；处理完写目录版本、建了的
  起草任务点得进进度；表详情一节（变化、撤销过的「已列全」、四种观察和口径、口径换过的提醒、断档的日子也在小柱图里）；数据源
  角标（读屏写全、点了到「变化」）；定时维护缺省关、开启时提示低峰时段、建（target_kind=source_maintenance）和改（PATCH 只带
  改了的和版本）、步骤走 PUT、最近一次建了哪个任务和哪几步没执行；后台任务条按服务端的两种先后、页头读屏不写数字、提醒在条上
  写全文、「查看」打开对应的对话框、探查的到数据源卡片；窄屏不撑宽页面。去掉排序、去掉「没写理由不能点」回跑，这几项都会报出来。
- check-catalog、check-catalog-profile：DraftStrip 的断言换成后台任务条（data-catalog-job-strip、data-catalog-job），页头的
  「起草」「数据剖析」只断言读屏写状态、不写数字；剖析的「最近查询多数超时」改在任务条上断言全文；check-catalog-profile 的假接口
  按建的先后给出队列，两种排法（起草在前 / 剖析在前）的文字都断言；窄屏下任务条看得见。三个目录检查都给变化、观察、后台任务、
  upkeep 配上空的假接口，不把假的源放行到服务端去查。
- check-catalog-loop.mjs 的 PROFILE_ON 换成 table_max_queries: 40、table_max_s: 60（和 check-catalog-profile 的 DEFAULTS 一致，
  05 (g)）。
- check-capabilities：全局渠道可订阅的事件里有了「数据源有变化要处理」（第 4 波打开了订阅），登记了还没推送的只剩召回。

本包相关的检查（catalog-changes、catalog、catalog-profile、catalog-loop、capabilities、manage）在另起的一套后端 + vite 上都过了。
 2026-10-16 20:05:43 +08:00
ThearchyHelios 35583ba1d8 口径召回前端（W4-a）：版本用量加问数回答和召回、发布弹窗预告召回规模、版本历史看召回批次、recall 待办卡、时间线认两个新事件 
为什么：前三波召回只有接口；这一波收口，口径升版之后谁的答案受影响、重算了几组、数变没变、怎么处置都要在界面上走得通。

- canvas/versionUsage：使用情况那一行加问数回答、导出、定时任务、召回（老服务端不给就不写）
- canvas/RecallPanel（新）：发布弹窗「召回」一行——旧版本被谁用过、按参数去重几组、发布后自动重算几组、超出上限几组（可在
  版本历史接着算）、上限为 0 时只列不算、不能重算的原因；版本历史展开一版——每组结论（数变了 / 没变 / 无法重算：原因 /
  重算失败 / 正在重算 / 未重算）、变了的指标、开了几条待办、召回运行链接，「另有 M 组未重算」+ 接着算
- run/RecallTask（新）+ TaskCard：recall 待办卡——旧口径、新口径、两版之差一行一个指标，每个数点得开召回卡的指标链；每个答案
  当时的值点得开（正式运行的口径卡、问数回答的查询快照），问数回答链回对话；「按新版重新出具」（不能时停用并写服务端给的
  原因）、「知道了」；遮罩值写已遮罩、点不开；目录有变、表结构变了两种只有「知道了」
- run/decode：ledger.recalled（已按 vN 核对，不影响；召回核对数变没变；试算结果）、ledger.basis_changed（依据有变、依据的
  表结构已变）；缺字段不猜
- 文案进 lib/termsRecall.ts；接口 api/recall.ts、形状 typesRecall.ts；TaskKind 加 recall
- 检查：check-inbox 加 recall 卡两段，check-publish 加召回预告和召回批次两段（版本历史、发布弹窗都在这里测；check-versions
  测的是上传表格的版本页，和召回无关），check-decode 加两个新事件的夹具，check-capabilities 的可订阅事件跟上 ledger.recall
 2026-10-16 20:05:24 +08:00
ThearchyHelios b24aabefcf 账本前端：证据「口径」一步、数字上的小标记、问数据轮次摘要与出具 / 对账、可沉淀的问题、设置里的口径账本一组 
第 2、3 波只有接口，这一波接上界面（docs/design/next-round/02-口径账本.md 做法 3–6、8 的界面、做法 11；总方案 X3、X10）。
界面层不放逻辑：标签、整题判断、能不能出具、能不能自动、不能的原因、要不要先核对参数都照 GET /api/runs/{id}/ledger 给的画。

- 比对结果不靠实时流（第 2 波遗留）：ledger.matched 在封存之后追加、事件总线已经关了，打开着的页面收不到。store/ledger
  按退避轮询（1、2、3、5、8、13 秒，之后每 15 秒），服务端答 pending 时写「正在比对口径」，等满 2 分钟还没结论照实说、
  给「再取一次」；要自动出具的再等出具的那一次出现，出具、对账的运行没结束的等它们结束。只在有组件看着时轮询，同一次
  运行的正文、面板、轮次摘要共用一份
- 证据正文（EvidenceDoc）：来自口径的数字后面挂一个小标记，写明受管 / 已发布，悬停写是哪一份口径、怎么认的；相关口径的
  数不加标记
- 证据面板出处链最上面加「口径」一步（run/LedgerStep）：来自口径——「X」v3（受管）· 参数 · 等价已证明 / 助手选用 ·
  按口径正式出具；相关口径——差在哪 + 看差多少；这次的推理——没有相关的已发布口径；没比对的写原因；脚注写「封存后比对，
  不在封存范围内」，事后补比的写按哪种口径回看
- 口径对账（run/LedgerReconcile）：核对参数（照动作里的入口字段画，推断的参数要先核对，遮罩值不回填）→ 发起（认不出列
  怎么配时照 409 带回的选项选对照的指标）→ 结果卡片：每组按你的问法、按口径、差值（附相对差）各自点得开出处链
  （apps/EvidenceDrawer，同应用页点数）
- 问数据轮次底部（run/LedgerTurn）：一行摘要（几个数来自口径「X」vN、几个是这次的推理、几个没有比对）、整题等价时按口径
  正式出具（能自动的写正在自动出具；不能的照写原因，使用者没有应用授权写「请搭建者出具」）、有相关口径时对账；出具过的
  正式运行挂在下面，档位写完整出具 / 降档出具 / 不予出具，搭建者点开去运行；回收站里的对话只看不发起
- 可沉淀的问题（pages/ledger/CertifyQueue）：工作流列表弹窗里的抽屉，确定性重复、问题聚类、被反复用的答案分开写；
  「固化成口径草稿」走 /copilot/from-run 的 freeze 并打开画布，聚类没有共同的 SQL、按人挑的那一轮固化；「不是口径」
  要写理由
- 设置（pages/settings/LedgerSettings，照 VerifySettings）：自动按口径正式出具、每日上限、比对时限、升版后每次最多重算几组，
  和其余偏好共用保存条、整组写 ledger
- 类型 typesLedger.ts、接口 api/caliberLedger.ts（挂 api.caliberLedger）、文案 lib/termsLedger.ts；types.ts 的证据片段
  答复加 ledger、rendered 两个键
 2026-10-16 20:02:08 +08:00
ThearchyHelios 77fc0efa10 口径召回后端（W4-a）：发布新版本后反查用过旧版的答案、按参数分组在同一份数据上重算两版之差，数真变了才开 recall 待办 
为什么：口径升版是被迫处置的事件（02 做法 7、拍板 L6），已交付的答案以前没人追；目录事实被驳回、表结构变了也没有地方标。

- ledger/uses.py（新）：反查旧版本被谁用过——比对工件里等价已证明的问数回答（含轮次、对话主人）、W 的正式运行（定时任务、
  应用各取最近 4 期）、固定了它的工作流版本发起的正式运行、固定这一版的应用、导出审计（导出人也是主人）；预告、召回、
  版本用量共用这一份
- ledger/recall.py（新）：计划按（旧版本、新版本、input_key）去重成组，从已有召回运行重算（幂等、不建任务表）；每组一次
  召回运行（origin_kind=recall，探索运行），派生图经 derive.recall_graph（新旧两版取数和口径卡带前缀、召回卡里算两版之差）；
  不能重算照实记原因（数据部分不能复用、新版没这张卡、入口参数不齐、图里有人工节点或写入）；每次发布最多 recall_limit 组，
  超出的手动接着算；收尾时按渲染的旧值新值判数变没变：变了开 recall 待办（开登录按主人各一条、关登录派给任何人）、推
  ledger.recall，没变在原答案上记 ledger.recalled；待办「按新版重新出具」走 issue.check_target 同一套判法、「知道了」
- 目录事实被驳回或修改（审阅、人工编辑、保存提案、批量审阅之后）：冻结目录里看得到这一项的探索运行记 ledger.basis_changed，
  按新目录多出错误级 SQL 检查问题的才开待办；表结构变动消费 source_changes（游标、处理时改了目录的当场交过去），标依据的
  表结构已变，受影响的口径试算一次，算不出来才通知发布人
- 发布钩子在 commit_publish 提交之后排队（自动的几样和调度循环同一个开关），GET /api/workflows/{id}/recall-preview 给发布
  弹窗预告；GET/POST /api/ledger/recall/{wf}/{v}[/continue] 给版本历史看批次、接着算；版本用量加问数回答、导出、召回
- ledger.recall 打开订阅（全局、个人渠道），同一渠道只推一次，消息不放数；新事件 ledger.recalled、ledger.basis_changed
  登记为封存后追加的事件，可验证报告离线核对页认得；E4 每次发布召回了几组、数变了的比例
- runner 收尾时召回运行在后台收尾，启动时接着做没发完的批次
 2026-10-16 19:52:03 +08:00
ThearchyHelios aa3bd65cfc W4-d 前端：数据目录页的「变化」视图、表详情「结构与取值变化」一节、后台任务条、数据源的角标和定时维护 
第 3 波的结构变化、取值观察、变化记录、定时维护都只有接口，这一提交给它们界面，能走通（收口）：

- 数据目录页左栏加第三个视图「变化」（view=changes）：按要处理 / 提醒 / 说明分组（组内照服务端排好的先后），能按开着的 /
  处理过的、结构变化 / 取值变化筛，筛选和打开的那一条记在地址里；视图标签上写几条要处理。点开一条，右栏写服务端的一句说法、
  依据（谁、经什么测到的；取值变化写观察口径，结构变化写比对的两版结构）、前后各是什么、影响面（说到这些列的目录项和它们
  现在的状态、写死了这张表的已发布模板、「这条 SQL 现在会报列不存在」、有效记录条件）、能做的处理。动作和做不了的原因都照
  服务端给的 actions 画；清理目录项先确认，加入码值可以先填含义，误报必须写理由（写之前按钮不能点，服务端也会拒）。处理完
  照实写结果：谁、什么时候、目录第几版、建了的任务（点得进起草、剖析的进度）。
- 表详情加「结构与取值变化」一节：这张表的变化（点「去处理」到「变化」视图里那一条）、撤销过的「已列全」、最近几次取值观察
  （行数、码值分布、最新业务日期、按日行数）和各自的口径，口径换过的说一句不互相比较；按日行数的小柱图只给眼睛看，数字写在
  字里和读屏名称里。
- 后台任务条（05 (g)）：页头的「起草」「数据剖析」改回纯入口（进行中转圈、排队中时钟，读屏名称写状态、不写数字）；DraftStrip
  换成 JobStrip，按服务端给的同源队先后列出探查、起草、剖析，每项一行加进度条和提醒（剖析的「最近查询多数超时」也挪到这里，
  窄屏、触屏看得见全文），「查看」打开对应的对话框，探查的到数据源卡片上（#source-<id> 滚过去）。
- 数据源卡片：要处理的变化条数的角标（读屏写全，点开到「变化」视图）；「定时维护」对话框（和「探查范围」一样是卡片上的
  独立对话框，不塞进编辑表单：两个保存混在一起出错时说不清哪一样没存上）：开关缺省关、开启时提示选低峰时段，选步骤（PUT
  /maintenance），频率用 components/FreqPicker，保存成一条 target_kind=source_maintenance 的定时任务（新建 ScheduleTargetCreate，
  改频率、开关 SchedulePatch 带版本）；照实写下一次什么时候、最近一次建了哪些任务、哪几步没执行和原因（触发记录的 inputs），
  剖析没开、调度没开时说到点会怎样。上传表格、记录表不给这一节。开着的维护在卡片上带一个标签写频率。
- 地址里带 pjob / djob 时打开那个剖析、起草任务的进度（定时维护的「最近一次」从数据源页链过来）。

新文件：typesSource.ts（接口约定）、api/sourceChanges.ts、lib/termsSource.ts（terms.ts 末尾转出）、pages/catalog/changes.ts、
ChangesQueue.tsx、ChangeDetail.tsx、TableChanges.tsx、JobStrip.tsx、pages/SourceMaintenanceDialog.tsx。变化的叫法和服务端逐字
一致，tests/test_source_change_terms.py 守着（维护步骤的叫法同样）。观察的按日行数服务端补上窗口里没数据的日子（不然小柱图
看不出断档）。
 2026-10-16 19:46:14 +08:00
ThearchyHelios a43224fd9a 账本接口补几样界面要画的东西：对账的入口字段、配列选项、对账卡的分组，刚跑完未封存时答 pending 
账本前端（第 4 波 W4-c）照「界面层不放逻辑」只照服务端给的画，这几样以前接口不给，界面只能自己猜：

- 「看差多少」那一项（reconcile.actions_of）带上口径的入口字段 fields（名字、必填、有没有缺省值，比对工件里记的那一份）：
  核对参数的表单照它画，缺的参数也写得出是哪一项
- 认不出列怎么配（409 ledger_reconcile_needs_pairs）另带 options：这次结果里是数、没遮罩的列，口径卡上的指标（id、名字、
  单位）；ReconcileRefused 加 extra，api/ledger 的对账接口把它并进返回体（CodedHTTPException 的 extra，改一行）
- 对过的账（reconciled_view）带 card 和 groups：每一组对照的这次 / 口径 / 差值 / 相对差各是哪个指标、这一组怎么称呼
  （从对账运行的图里读，不按命名规则拼），界面按 /evidence/metrics/{card}/{指标} 取值、三个数各自点得开
- GET /api/runs/{id}/ledger：runner 先发 run.finished、落库，再封存、再排比对，页面收到 run.finished 立刻来取时
  还没封存。成功结束、要比对的运行这时答 pending（不另排按需比对），不再说成「运行还没有封存，不比对」
- 测试：对账的三样（单行、多行），刚跑完未封存答 pending、不排按需比对，失败的照旧 ineligible
 2026-10-16 19:46:03 +08:00
ThearchyHelios 4c7c0cf283 驳回节点的画法（前端）：被驳回的那一步画成「被驳回」，不画成失败 
服务端给被驳回的那一步的 node.failed 带上了 reason=rejected（上一个提交）。界面上读 node.failed 的几处都认它
（05-已知遗留 (a)、总方案 X9：驳回是人的决定，不是故障），没有 reason 的老运行照旧画失败：

- run/decode：问数据过程、记录页、画布右栏的时间线里，这一步状态 rejected（StepStatus 加一种），副标题写谁驳回、
  备注（REJECTED_TEXT.step），原话放展开里；不是 error 级别，不当成出错
- run/trace、run/derive：NodeState 加 rejected；那一段收成 rejected，不记成「失败的节点」，下游是「未到达」不是
  「被阻断」；回放投影同样是 rejected
- 画布节点卡：rejected 一种读数（耗时 + 原话第一句，整句悬停），中性色、停止剪影，不挂失败红框、不抖动；小地图、
  运行胶囊的计数、时间轴泳道认得它；记录页航迹的节点卡写「被驳回：原话」
- check-decode、check-run-states 各加一段：新旧两种形状
 2026-10-16 19:42:11 +08:00
ThearchyHelios 56ca53ad35 问数据建图用量不再是下限；评测通知链到评测详情；评测接口补界面要的几样 
用量（第 1 波遗留）：查清楚了，丢的不是浏览器那边——问数据页一直读到 SSE 结束、usage 那一条收得到——而是服务端生成过程
（api/copilot_gen._iter_ops）读到 done、look、ask 那一行就关掉模型的流，流末尾那一段才报的用量（Anthropic 的输出 token、
OpenAI 兼容系的 stream_usage）一次都拿不到，每次建图都记成「估不出」，这一轮的花费多半是下限。改成交出那一行之后先把流读完
再关（_drain，内容丢掉）：照约定那一行就是最后一行，读完只多收用量那一段；模型在那一行之后还往下写超过 DRAIN_CHARS 字闲话的
当场关流、照实记成没报全（不为闲话付钱，也不当成报全了）。评测的作答（app/eval/answer.Driver）走同一个 answer_ops，
用量跟着报全，和问数据页同一个口径。test_usage_meter：原先断言「输出 token 为 0、记成估不出」的那条改成报全；另加 look 后、
闲话超限、评测和问数据页收到同一份用量三条；去掉修复回跑，三条都抓得住。providers/usage.py 的说明跟着改。

通知：notify_eval 的链接从定时任务的触发历史改成这次评测的详情页 /evals/runs/{id}（评测页这一波上线）；测试设上对外访问地址、
断言链接（原来的断言在没设地址时对空列表恒真）。

评测接口（只加不改，app/api/evals.py）：题集列表和详情带 latest（最近一次评测）、trend（同一变体最近几次评完的准确率，旧的
在前，换了模型、目录的不连成一条线）、schedules（目标是它的定时任务）；评测详情带 actions（停止、只重试没做完的、重新评分、
钉住 / 取消基线能不能做，和接口拒收的条件同一份）和没做完的项数；POST /suites/{id}/cases/preview 写 SQL 定期望的预览
（同期望的 SQL 探针，交回列和前 50 行，遮罩列照保存时那一道拒收、没过守卫的指明是哪一格，都不回 422）；GET /signals
「口径命中与重复度」的判据和分档、窗口趋势（数只出自 ledger/stats.compute_stats）、成员不少于 3 的问题类（只出自
chat/questions，评测运行不进）。为什么放服务端：界面层不放逻辑，统计、能不能做都由服务端给。tests/test_evals_ui_api.py。
 2026-10-16 19:41:57 +08:00
ThearchyHelios 238330b9c1 W4-d 后端：给目录前端的变化、观察、后台任务、定时维护接口补齐界面要的几样；打开 source.changed 的订阅 
第 3 波的变化接口只给了 agentlab-change/1 的原样，界面要的几样（能不能做、依据什么、现在怎样）如果让前端自己判，就违背
「界面层不放逻辑」。这一提交由服务端给出，界面只照写：

- 变化列表、单条、处理的回答里每条另带 category（结构 / 取值）、basis_text（依据的口径，照观察时记下的写整表、窗口、块采样、
  按存储顺序的前 N 行）、actions（现在能做哪几个处理动作，做不了的写原因：剖析没开、表结构里没有了、影响面里没有目录项）、
  job（处理时建的任务，界面能点进进度）、影响面里每个目录项现在的状态（清理过、改过的照实）。召回拉的 list_changes 不带这些。
- 列表能按 category 筛（和 kind 一起给时取交集，一种都对不上就是空的，不是不筛），能按 status=handled 看处理过的（最近测到的
  在前：处理过的不再按要不要先处理排）。
- GET /api/datasources/upkeep：数据源列表一次取齐各源要处理的变化条数（卡片角标）和指向它的维护定时（频率、开没开、下一次）。
- GET /{id}/observations：表详情「结构与取值变化」一节的最近几次观察，各带口径；码值的占比、按日行数的合计由服务端算；现在
  被遮罩的列（观察时还没遮的）整组不给，遮罩在读的那一刻再核。
- GET /{id}/background-jobs：这个源进行中和排队的探查、起草、剖析，按同源队的先后排好（05 (g)：排队顺序取服务端的，界面
  不自己排），各带 waiting_for。
- GET /{id}/maintenance：维护定时换成定时任务页同一个形状（改频率、开关照样带 version 走 PATCH），最近一次触发带 inputs
  （建了哪些任务、哪几步没执行和原因），另说调度开没开、这个源要不要维护（上传表格、记录表不要）。
- notify：source.changed 打开订阅（只推全局渠道，按源汇总不归哪个人），链接落到目录页的「变化」标签页。
  test_notify_events 里 W4-d 那一行加上；test_source_changes 里原先假设订阅没开的那句改成「没有渠道订阅时推不出去」。

data/source_changes.py（W4-a 的文件）只在末尾加了 available_actions、counts_by_source、list_handled 和 HANDLED；
data/catalog_profile_observe.py 末尾加了 key_text、recent。新测试 tests/test_source_upkeep.py。
 2026-10-16 19:31:21 +08:00
ThearchyHelios eb578cad34 驳回节点的画法（后端）：被驳回的那一步的 node.failed 带 reason=rejected 
第 1 波把人的驳回收成 cancelled + end_reason=rejected，但节点层仍只发一条和故障一模一样的 node.failed：
复核规则把它说成「执行失败」、还当成「重跑一次大概率能好」（重跑只会把同一件事再问一遍人），实例进度里
没开待办的驳回（工具调用审批、代码执行审批）落成「失败」（05-已知遗留 (a)、总方案 X9）。

- engine/compiler：NodeRejected 时照旧发 node.failed（时间线、实例进度按它收尾这一步），数据里多带
  reason=rejected（和 run.cancelled 同一个字段名）、kind、decision、actor、note；真的出错的 node.failed
  一字不变，没有这几个键
- engine/review：认 reason=rejected，记 node_rejected（DEGRADED，不进 RETRYABLE），说「被驳回」不说「执行失败」；
  没有 reason 的老运行照旧 node_failed
- apps/resolve 的实例进度：按 node.failed 上的 reason 画「被驳回」（结论写已驳回 / 超时驳回 / 未确认（被驳回）），
  老运行照旧按待办认
- 测试：六种关卡的 node.failed 都带上这几个键；普通失败没有；复核与实例进度的新旧两种形状（去掉修复回跑会失败）
 2026-10-16 19:30:47 +08:00
ThearchyHelios 45fab21072 第 4 波契约骨架：频率选择抽成公共组件 components/FreqPicker.tsx（频率与时区的纯函数搬到 lib/freq.ts，pages/schedules/model.ts 原样再导出），定时维护和定时任务共用；前端类型加 ScheduleTargetCreate（建评测题集、数据源维护这两种非工作流目标），api.schedules.create 收它；设置 ledger 一组加 recall_limit（口径升版后每次最多重算几组，缺省 50，0 表示不自动重算）；test_notify_events 的 PUSHED_THIS_ROUND 拆成一项一行、给 source.changed、ledger.recall 各留一个位置；check-all 预登记 catalog-changes、evals、ledger 三项检查（先放占位） 2026-10-16 19:09:47 +08:00
ThearchyHelios dd052f6d21 合入下一轮第 3 波（docs/design/next-round）：表结构变化与取值观察（结构版本与前后差异、影响面、正式运行的 schema.drift 提醒、剖析引擎的四类取值观察与同口径比较、撤销「已列全」、变化记录与处理、数据源定时维护）；口径账本闭环（caliber_from.nodes、问数据的 use_caliber 选用已发布口径、按口径正式出具（自动只给问数据的答案）与口径对账、认证队列与固化成口径草稿、发布后补比）；评测执行（后台评测与无头作答、评分与重评、统计、对比与 A/B、预算与止损、清理、定时评测与通知）；触达与分享（邮件渠道、每天的待办汇总、访问密钥到期提醒、分享链接与 /s 页、「最近一次封存」按来源白名单认）。验收：后端全量 14210 通过；tsc、文案检查；本波相关的 15 项浏览器检查 4431 项全过；四种库的方言容器测试全过；泄露扫描干净 2026-10-16 19:00:49 +08:00
ThearchyHelios 337513b83d check-publish：「版本列表标出已退役的版本」等列表取回再数（并行时打开那一刻列表还是空的，偶发不过） 2026-10-16 18:59:50 +08:00
ThearchyHelios 728d0c5d2a README：第 3 波的升级说明（结构变化与取值观察、定时维护、按口径自动出具、最近一次封存的来源白名单、使用者的原始运行记录、邮件与待办汇总、密钥到期提醒）；应用一节加「分享链接」（开关、两种模式、/s#key、到期与撤销、嵌入、留痕） 2026-10-16 18:51:02 +08:00
ThearchyHelios eb6e3c7ab7 合入 W3-d 邮件、待办汇总、分享链接：邮件渠道（SMTP 可选、口令加密、退信不追踪）；每天的待办汇总与访问密钥到期提醒；分享链接（只存哈希、必设到期、只显示定时出数的视图、/s 页不进外壳、下载报告）；「最近一次封存」按来源白名单认；使用者拿不到邮件渠道的收件地址；同站门户嵌整站的配置说明 2026-10-16 18:48:07 +08:00
ThearchyHelios 1c8ca4c3d7 合入 W3-c 评测执行：后台评测与无头作答、六种期望五种结论的评分、重评、结论裁判记评测账、统计（Wilson 区间、按角色用量）、对比与 A/B（McNemar）、目录贡献预设、预算与止损、清理；定时任务接题集目标，定时评测有退步 / 没有评完推全局渠道；定时页照实显示非工作流目标 2026-10-16 18:46:44 +08:00