yilunjiang/AgentLab
1
0
Fork 0
mirror of https://github.com/ThearchyHelios/AgentLab.git synced 2026-11-15 04:01:58 +00:00
Code Issues Packages Projects Releases Wiki Activity
882 Commits 4 Branches 0 Tags
c8cd56c108304e9dce20a67b150f00093cf9f74f
Commit Graph

882 Commits

This Branch
This Branch
All Branches
Author SHA1 Message Date
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
ThearchyHelios defdb28e3f 合入 W3-b 口径账本闭环：caliber_from.nodes 改名映射；问数据的助手 use_caliber 选用已发布口径（服务端确定性内联实例化）；按口径正式出具（自动只给问数据的答案）与口径对账；认证队列、固化成口径草稿、发布后补比；账本统计补上对账与认证转化；使用者的原始运行记录只给问数据的运行 2026-10-16 18:45:45 +08:00
ThearchyHelios 9da3e518d7 合入 W3-a 表结构变化与取值观察（next-round 03 B1–B4）：结构前后差异、影响面、结构版本与 schema.drift；剖析引擎的四类取值观察、比较器与撤销「已列全」；关联覆盖率下降；变化记录的接口与处理；数据源定时维护；容器集成测试扩到对象索引和取值观察；观察写库出错各占保存点、不拖垮剖析；离线核对页认 schema.drift 2026-10-16 18:45:45 +08:00
ThearchyHelios 695f63f7ba W3-a 可验证报告离线核对页认 schema.drift：事件清单写「表结构变化」 
复核 L4：schema.drift 写在正式运行的封存范围里（和 catalog.drift 一样在发起时追加），可验证报告离线核对页的
EVENT_LABEL 里却没有它，事件清单直接显示原文「schema.drift」。照总方案 X10 的叫法（结构变化，和「数据目录变化」
分开）补上「表结构变化」。

复核顺带提的 ledger.matched 没加：它追加在封存之后、不在封存范围内，导出只带 seq ≤ manifest_seq 的事件
（bundle/build.py），离线核对页上不会出现它。

测试：test_schema_changes 加一条静态检查，读 verifier.js 的 EVENT_LABEL，catalog.drift、schema.drift 都有中文说法。
 2026-10-16 18:37:51 +08:00
ThearchyHelios c08b2d0d52 W3-a 取值观察写库出错不再拖垮剖析：每条观察、每条覆盖率下降各占一个保存点 
复核 L1：catalog_profile_observe.save 和 record_coverage_drops 与这张表的剖析结果、写进目录的结论共用一个事务，
只靠 try/except 记日志。flush 一出错（序列化不了的值、约束冲突）SQLAlchemy 就把整个事务回滚了，异常被吞掉，
外层 catalog_profile._record 提交时抛 PendingRollbackError，整个剖析任务记成「剖析任务出错」，剖析写的目录跟着
丢掉，和模块说明「辅助步骤失败不挡剖析」不符。复现：给一条观察带上序列化不了的值跑 maintenance，任务 failed。

改法：
- save：先把剖析这张表自己的写入 flush 下去（那里出错是剖析的事，照常往外抛）；读目录一个保存点；每条观察
  （落库、修剪、比较、撤销已列全、记变化）挪进 _save_one，各占一个保存点。一条出错只回滚它自己，连同它撤销的
  已列全一起回滚，不会只撤了已列全却没有那条变化；别的观察和剖析结果照常提交。
- record_coverage_drops：每条覆盖率下降一个保存点。sc.record 原本只给插入包了保存点，更新已有那一条的改动要到
  外层提交时才 flush，出错照样拖垮整个事务。
- _revoke_complete：从库里重读目录（populate_existing）再写，去掉同一事务里撞了重试的循环。catalog.write_entry
  乐观锁对不上时回滚的是整个会话、保存点挡不住；会话里握着保存点回滚前的目录对象时（只 refresh 过的干净对象，
  保存点回滚不让它过期），拿它的版本去写正好撞上这一条。重读之后别人提交不了新版本：这张表的结果在同一事务里
  已经写过，事务拿着 SQLite 的写锁。

测试（test_catalog_observe 新增四条，去掉修复都会失败）：观察 flush 报错时剖析结果、目录照常提交、别的观察照常
落库；前一条观察记变化出错时它的撤销一起回滚、后一条照常撤销；覆盖率下降更新出错只回滚它自己；会话握着旧目录
对象时撤销按库里的版本写。
 2026-10-16 18:37:51 +08:00
ThearchyHelios 38d9082994 使用者的原始运行记录只给问数据的运行，对账运行经证据接口读（复核 M3） 
复核发现：使用者（开登录后的 user 角色）发起的口径对账运行带 MASK_RESULTS、记在本人名下，run_events_readable 只看这两条，
于是他能经 /api/runs/{id}、/events、/graph 读到对账运行的原始图和事件，里面原样是口径取数节点的 SQL 模板。这一波正是以
「口径的 SQL 可能写着遮罩值」为由不让使用者在问数据里看口径、use_caliber，这条读法绕开了证据面板按遮罩换 SQL 的那一层。

做法：api/deps.run_events_readable 给 user 角色再加一条 origin_kind == "chat"——原始记录、事件、运行时的图、实时流只给他
自己的、查询结果在工具边界遮过的问数据运行（原来的说明里就写着「实际上满足的就是它自己的问数据运行」，这次照实收紧）。
对账运行他仍然能经账本和证据接口读（can_read_run 不变，那里展示的 SQL 按遮罩换过），对账的发起也不变。改了
api/deps.py 的这一个函数（没分给哪个包）和 ledger/reconcile 的模块说明。

测试：开账号密码登录，使用者对自己的问数据答案经接口发起对账，对账运行的 /api/runs/{id}、/events、/graph 都回 403，证据
接口 200；他自己的问数据运行这三样照旧 200。去掉这一条回跑，新用例失败；test_auth_access、test_personal_apps 照旧过。
 2026-10-16 18:25:43 +08:00
ThearchyHelios 37d0f0abf1 自动按口径出具只给问数据的答案（复核 M2） 
复核发现：自动出具对所有参与比对的探索来源都生效（问数据、画布试运行、蓝图试运行、个人应用刷新），而拍板 L1 和细案
做法 5 说的是「问数据的答案」。画布上反复试跑一份和受管口径等价的草图，每次都是新的来源运行，去重按来源运行算，于是每
试一次就自动发起一次正式运行（含报告撰写的模型费用），直到每日上限；个人应用刷新、蓝图试运行同样。

做法：plan_issue 算 auto_reason 时，设置开着之后先看来源，不是 chat 的写 AUTO_NOT_CHAT（「这次是画布试运行，不是问数据
的答案：自动出具只给问数据的答案，这里只给一键出具」），只给一键，一键照常发起。条件链改成逐条 if/elif，好读。

测试：equivalent_run 缺省改成问数据（origin_kind=chat），原来的自动出具用例照旧过；新加「画布试运行不自动、写明原因、
一键照常」。去掉来源这一条回跑，新用例失败。
 2026-10-16 18:25:33 +08:00
ThearchyHelios 72a45f3ef3 check-capabilities 跟上全局渠道推送的定时评测两个事件（复核 M1） 
W3-c 打开 eval.regressed、eval.failed 的全局渠道订阅时没改这项检查的期望，分支上「全局渠道：推给全局渠道的五项」和「登记了
还没推送的不列」两项就不过（复现：check-capabilities 63 通过、2 不过）。

- 全局渠道的期望改成 [...every, 'review.done', 'eval.regressed', 'eval.failed']，标题照 W3-d 的写法叫「推给全局渠道的几项」，
  合并时两边的期望并在一起即可；个人渠道、应用渠道的期望不变（这两个事件只推全局渠道）。
- 「登记了还没推送的不列」里去掉评测的两项；另加一项：全局渠道列出的叫法照实带「定时」（定时评测有退步、定时评测没有评完）。

check-capabilities 66 项、check-schedules 355 项全过。
 2026-10-16 18:23:03 +08:00
ThearchyHelios 9e33c0f801 评测的两个通知事件照实叫「定时评测有退步」「定时评测没有评完」（复核 L3） 
eval.regressed、eval.failed 只在定时发起的评测收尾时推（runner._conclude 只认 trigger == "schedule"），手动发起的那次人自己
在看、不推，这和细案 01 做法 15 把这两个事件放在定时一节里一致。可订阅时的叫法却是「评测有退步」「评测失败」，没写「定时」：
有人给全局渠道勾上「评测失败」、再手动发起一次评测并止损停下，渠道里收不到任何消息，界面上也没处说为什么。

- notify/service.EVENTS 和前端 NOTIFY_TEXT.eventLabel 同一句改成「定时评测有退步」「定时评测没有评完」（test_notify_events
  逐字对照两边）。eval.failed 不只是失败：到了上限、止损停下（partial）同样推，所以叫「没有评完」，和消息标题本来的说法一致。
- notify_eval 的消息标题也带上「定时」：定时评测「题集名」有退步 / 没有评完。
- 新测试：两个事件的叫法带「定时」；手动发起的评测止损停下，订阅了这两个事件的全局渠道收不到任何消息（去掉 trigger 的判断
  这一条就失败）。
- 模块说明、接口说明里引用旧叫法的几处一并改。
 2026-10-16 18:23:03 +08:00
ThearchyHelios e5003a1d46 W3-d 复核 L2：使用者列通知渠道时拿不到全局、应用邮件渠道的收件地址 
复核发现：GET /api/notify/channels 对使用者照样列全局、应用渠道（应用的通知里要挑渠道，只用名字和 id），而邮件渠道的
mail_to 给的是全部收件地址原文；channel_out 的说明却写着「搭建者以上才看得到」。Webhook 渠道只给主机名，邮件渠道多露了
一层：任何使用者都能拿到内部的收件名单。

做法：channel_out 加 recipients 参数，list_channels 按 _can_edit 的同一条规矩判（关登录时谁都能改，开了登录要搭建者
以上）：改得了的照原样给 mail_to（改地址要整份重填），改不了的只给条数 mail_count。个人渠道照旧写发到自己的账号邮箱。
建、改渠道的返回本来就只给能改的人，照旧。说明同步改；前端 typesApp 的 NotifyChannelRow 加 mail_count（设置页的
通知只给使用者列个人渠道，界面上用不上，不加入口）。

测试（tests/test_notify_mail.py）：开登录，使用者列渠道时全局、应用的邮件渠道照样在、没有 mail_to、只有条数，自己的个人
渠道照常；搭建者看得到地址。去掉修复回跑，这一项失败。
 2026-10-16 18:20:52 +08:00
ThearchyHelios 36c8f581cc W3-d 复核 H1：「最近一次封存」按来源白名单认，问数据按口径出具的正式运行不再顶替看板的数 
复核发现：问数据的答案按已治理口径正式出具的运行（origin_kind=ledger_issue，W3-b 加的自动出具缺省开）参数是从某人的
提问里绑出来的，而 apps/resolve.sealed_runs 只排除了补算（app_backfill）。于是 from=formal 的 latest_sealed 视图、
趋势、分享链接（latest，以及建 fixed 分享时取的那次）、视图数据接口、补算判断「新版本算过没有」都会换成那组参数的数，
而且没有任何提示。

做法：sealed_runs 的来源从黑名单改成白名单 SEALED_ORIGINS（定时、手动正式运行、应用入口和按需视图、入站钩子、直接调
接口，外加没有来源列之前的老运行）；不算的列在 NOT_SEALED_ORIGINS，逐条写明原因。上面这几处都经 sealed_runs，改一处都
跟上。按白名单认是为了以后再加来源时默认不算、要算得先登记，不会再悄悄漏进看板。

测试（tests/test_shares.py）：
- 先跑一次正常的正式运行，再跑一次更新的 ledger_issue 正式运行：应用页、趋势、视图数据接口、latest 和 fixed 两种分享
  都还是正常那次，分享的下载报告也不认出具的那次。去掉修复回跑，这一项失败；
- ORIGIN_KINDS 每种来源都要归进 SEALED_ORIGINS 或 NOT_SEALED_ORIGINS 之一，以后新加的来源没归类先失败。
 2026-10-16 18:20:52 +08:00
ThearchyHelios 7e8d3a9c49 口径比对的 drain（测试用）只等还没做完的任务，做完还留在登记里的顺手去掉 
为什么：并行跑全量测试时偶发过 drain 原地空转（faulthandler 抓到主线程一直在 drain 里，每轮 gather 都立刻返回），四次全量里挂了两次。这一波起整题等价的探索运行比完会接着自动出具，后台任务的进出更密。改成只 gather 没做完的、把做完的从登记里去掉之后，连跑两次全量都没再出现。drain 只给测试用，服务里不调它；没能在单进程里复现出根因，照实记进遗留。
 2026-10-16 17:46:20 +08:00
ThearchyHelios b1c585daf4 W3-a 结构变化的影响面：一批（一次刷新）只读一次目录 
后台探查每批读完、刷新对象索引发现真删除的表时，各张表的影响面以前每张都重读一遍整个源的目录（structure_impact 不给
notes_by_table 时自己读）。一批几十张表、几千张表的库删了一批表时，这一读就重复几十次。改成一批（一次刷新）读一次、
各表共用；已发布模板的图本来就按任务缓存。行为不变，test_schema_changes、test_introspect_jobs、test_source_changes 照过。
 2026-10-16 17:29:00 +08:00
ThearchyHelios 8181efe836 W3-a 前端跟上：运行里的结构变化提醒、剖析清单里取值观察的说法 
后端这一波新写的 schema.drift 事件、剖析任务里的取值观察检查，前端不跟上就是半截的：

- run/decode.ts 认 schema.drift：时间线里一行警告（运行未被拦截），展开逐表写发布时和现在的结构版本、表删了写「表已删除」，
  下面列出还没处理的结构变化；schemaDrift / schemaDriftLine 解析，和 catalog.drift 分开记、不混读版本号。
- 运行横幅（pages/runs/Banners.tsx）：和 catalog.drift 共用同一块横幅（data-run-banner 不变）。只有结构变了时标题按结构说；
  目录、结构都变了时结构另起一组带小标题；每张表给到数据目录的入口。RunDetailView 取最后一条 schema.drift 一并传进去。
- 剖析清单：取值观察的四类检查（行数、码值观察、最新业务日期、按日行数）在检查项、发过的查询、跳过的项里有中文叫法；
  逐表进度多一类「取值观察 N/M」（后端 checks_by_kind 加 observe 一组）。剖析的范围、任务的触发（定时维护建的）进类型。
- 文案进 lib/terms.ts（SCHEMA_DRIFT_TEXT：叫「结构变化」，和已有的「目录有变化」分开，X10）。
- 检查脚本：check-decode 加 schema.drift 一节（标题、警告级、逐表版本、表已删除、另有几条、形状不对不出行），check-runs
  加一节（只有结构变化、目录和结构都变了两种情形下的同一块横幅、入口链接、时间线一行、运行照常完成）。

验证：tsc、check-copy；decode 680、runs 327、catalog-profile 191、stream 461、publish 285 项全过。
 2026-10-16 17:28:07 +08:00