626 Commits

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	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	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	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	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	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	bbf6ebb79d	召回收尾：启动时只接着做当前发布版的自动批次、补测重启后从已有召回运行重算计划；时间线认不出的依据种类不猜 ... - ledger/recall.resume：最近发布、之后又发布了更新版本的不再接着做（新版本的召回本来就覆盖更早的所有版本） - 测试：重启前只发起了一组、也没收尾，重启后接着发完自动那一批、补上收尾照样开待办，再重启一次不再发起 - run/decode：ledger.basis_changed 认不出种类时写「答案的依据有变」，不当成目录事实变了；batches 的说明照实写参数原样给搭建者	2026-10-16 20:11:46 +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	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	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	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	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	ed72ee68d6	W3-a 关联覆盖率下降、清理目录跨表、扩容器集成测试到对象索引和取值观察 ... - 剖析核对关联关系时，覆盖率从够有确证的线（95%）掉到线以下的记一条 coverage_drop（取值变化，warning）：剖析本身照旧 按规则降回推断（人工确认的只补上新的覆盖率），这里只把「覆盖率下降」留进变化记录。人点的剖析也记（变化记录全站一份）。 关系的发现里多带 previous_coverage。 - 处理动作「清理目录」逐表清：这张表上说到被删的列的项，加上别的表指向它的关联关系（表删了时尤其如此）；记这张表的 目录版本，别的表也动了的另记 catalog_versions。 - 剖析任务的逐表进度多一类 observe（取值观察的四类合成一组），前端「取值观察 N/M」用它。 - 定时维护补一条测试：AGENTLAB_SCHEDULER 关着时调度循环不起，到点的维护不触发、不建任务。 - scripts/dialect-it.sh / dialect_it.py 扩到第 2 波的对象索引字典查询（走字典查询不退回 Inspector、类型、表注释、行数 估算、Oracle 小写名的 quote）和这一波的取值观察（经剖析引擎只观察：行数、小表码值整表、大表 PG / Oracle 块采样、MySQL 前 N 行、最新业务日期排除无效日期，max_date_sql 直接跑）。夹具的订单表加了表注释。本机跑了一次四种库的容器 （postgres:16、mysql:8.4、mariadb:11、gvenzl/oracle-free:23-slim）：121 项全过、0 项不通过，跑完容器已删、镜像留着。 验证：后端全量 14046 通过（11 跳过、8 预期失败）。	2026-10-16 17:28:07 +08:00
ThearchyHelios	e65ac3e619	助手的节点手册：子工作流补上 workflow_version（口径账本做法 4 ⑤） ... 为什么：手册里子工作流只写了 {workflow_id, input}，模型不知道能固定版本。补上写法，并说明问数据里不要拿子工作流去拼已发布的口径——子工作流里的数报告引用不到，组合口径走 use_caliber 的内联实例化。	2026-10-16 17:18:37 +08:00
ThearchyHelios	ced7234180	按口径出具也按 SQL 里参数的位置校验绑定值；去掉 certify 没用到的导入 ... 为什么：出具用的参数来自比对时的绑定，运行时要渲染进口径的 SQL 模板。写在引号里的值带着引号、裸写的值不是数，渲染出来就不是那一版口径的 SQL 了。组合时校验助手给的参数用的是同一个判断（ledger/compose.slot_contexts / value_problem），这里共用；那张图里别的节点引用运行时变量的不归出具管，跳过不报。宁可少出具，照实说为什么不代填。	2026-10-16 17:17:48 +08:00
ThearchyHelios	fd1ec6f75d	测试：开登录时自动按口径出具按提问人的权限判 ... 为什么：自动出具在后台跑，没有请求里的身份，要按这次运行的发起人取（ledger/issue._starter）。补一条用例：使用者没有应用授权时不自动出具，应用固定了这一版、授给他使用之后才出具，正式运行记在他名下、origin 标自动。	2026-10-16 17:15:50 +08:00
ThearchyHelios	40daf37107	评测发起后立刻交给后台再读回；补「复核要重来」的测试 ... 为什么：发起评测时提交之后、交给后台之前还 await 了几次读回，这中间别的请求读到「排队中、却没在这个进程里跑」会把它 当成服务重启留下的、标中断。改成提交之后立刻交给后台，再读回。 - test_eval_runner：复核给了 retry_instruction 时带着这次运行的图、照那句话重来一次，第二次复核（attempt=1）不再要重来， 两次作答运行都记在这一题名下	2026-10-16 17:15:17 +08:00
ThearchyHelios	5e9413e080	账本：按来源运行找出具过的正式运行、对过的账改在 SQL 里按 origin.source_run 筛 ... 为什么：GET 账本每次都要列这两样，原来把全部 ledger_issue / reconcile 运行读出来在 Python 里筛，出具多了就是整表扫。改成 origin_kind（有索引）加 json_extract(origin, "$.source_run")，写法同 auth/keys 认幂等键。	2026-10-16 17:11:55 +08:00
ThearchyHelios	fc9b31ecfe	W3-d 收尾：关登录时不发汇总和到期提醒、分享页不下发入口表单、邮件标题去换行；测试互不干扰 ... - notify/digest：关登录时「派给我的」认不出是谁、访问密钥也不生效，待办汇总和密钥到期提醒一概不发，也不认领当天 - resolve_page 的分享旁路不下发入口的表单（分享链接里不能发起） - 邮件标题里的换行合成空格：应用名、节点名是人起的，邮件头里有换行就是头注入 - 邮件、汇总的测试前后各清一遍渠道、投递记录和 notify 一组，对外访问地址的缓存跟着清；汇总测试只删自己建的待办。 全量并行跑时不再被同一进程里别的测试留下的行带偏	2026-10-16 17:11:54 +08:00
ThearchyHelios	a0cdb16617	重评时把评分规则版本记进指纹；去掉几处没用的导入 ... 为什么：按新规则重评之后，和别的评测比时「评分规则」那一项要照实标出变了；总表上另记重评的时间。	2026-10-16 17:11:09 +08:00
ThearchyHelios	88e219eabc	评测总表照实列出没开评的题、按评完的题估每题花费；对比测试单独成文件，补超时止损的测试 ... 为什么：总表里「没开评、停下、出错」的题以前只体现在计数里，准确率旁边看不出来；下一次开跑前的估算按每题平均花费算， 把没开评的题也摊进去会估低。 - stats.summarize 加 not_run；per_case_cost_usd 只按评完了的题平均 - test_eval_compare.py：逐题转移与归因、指纹差异、A/B 配对表、选基准（从 test_eval_stats 拆出来，对上细案的测试清单） - test_eval_runner：最近 10 题里 7 题超时就止损	2026-10-16 17:08:29 +08:00
ThearchyHelios	538799e70d	沉淀：认证队列、固化成口径草稿、发布后补比；账本统计补上对账与认证队列的转化（口径账本做法 8、10，拍板 L9） ... 为什么：同一类问题被反复问、Agent 反复写出同一个形状的 SQL，就该沉淀成一份口径；以前 from-run 保留 Agent，沉淀出的模板没有固定 SQL，以后永远比对不上。第 2 波的统计在 E2 反馈、E3 认证队列上照实写了「目前没有数据」，这一波补上能补的。 做了什么（新增 ledger/certify.py）： - GET /api/ledger/certify-queue（搭建者）：确定性重复（问数据运行里被报告引用、没对上口径的查询，按数据源 + normalize_sql 文本分组，≥3 次运行且来自 ≥2 段对话；跨运行变化的字面量是参数候选，展示的形状不带取值）、问题聚类（app/chat/questions 全站唯一的那份）、被反复用的答案（导出 ≥2 次用第 2 波的 report.exported 审计、做成过应用看蓝图来源、在画布里打开或提取过看工作流 origin）。每项给代表问题、轮次、相关口径、是否已固化。 - POST /api/ledger/certify-queue/dismiss：「不是口径」写审计 ledger.certify.dismiss，之后不再进队。 - 固化成口径草稿（from-run 加 freeze、peers 后转调 certify.freeze）：报告引用的查询变成固定 SQL 的取数节点，跨轮变化的字面量换成 '{{ input.pN }}'（缺省值取代表运行的），单行结果的数值列成口径卡指标，报告核对规则按受管要求写、契约 report_from + metrics_from + required（多行加 cells）；过 validate_graph 和受管门禁。新工作流 origin.sources 记来源问题。 - 发布之后补比：api/workflows.commit_publish 提交后调 certify.after_publish，来源运行按新口径补比一次（新的 trigger=certified，界面写「按之后发布的口径回看」，时间线和账本接口同一句）。 - 统计：E2 加对过账的答案数、参数经人核对的、指标由人选的次数（反馈照实写第 4 波）；E3 认证队列的转化（固化、发布、不是口径）。 测试：tests/test_ledger_certify.py（参数推断与模板、三种信号进队、门槛、不是口径、固化草稿过受管门禁、发布后来源运行补比成等价已证明并出队、再问标等价已证明、统计）。	2026-10-16 17:06:41 +08:00
ThearchyHelios	df6c3ce10d	定时页照实显示非工作流目标；评测停止时几臂一起收尾；工作流题的测试 ... 为什么：这一波后端开始接受评测题集、数据源维护这两种定时目标（总方案 X4），定时页要能把它们照实列出来、点进去 不报错；界面上不能有点了没用的入口。 - 定时页列表：非工作流目标写种类（评测题集 / 数据源维护）和目标名，不标运行类别，「编辑」写成「查看」 - 详情：非工作流目标的设置只读地列出名称、目标、频率、时区、补发宽限，不出工作流那张表单（选工作流、输入模板、 Webhook 对它们不适用）；页头的启用、立即运行、删除和触发历史照常 - 立即运行发起的是一次评测时说「已发起一次评测」（以前会落到「未能发起运行」）；触发历史写评测的编号 - types.ts：Schedule 加 target_kind / target_id / target_label / target_name / target_exists，触发记录加 eval_run_id； 文案进 SCHEDULE_TEXT - check-schedules 加一段「目标不是工作流的定时任务」 - runner：还没准备好就被停下、出错时，按 pair_id 找全几臂一起收尾 - 测试：工作流题按钉住版本跑探索运行（不发正式运行、不建图）；钉住基线的接口 - 后端几句给人看的话按文案规范改（不用「跑」「钉」）	2026-10-16 17:04:05 +08:00