 ThearchyHelios
|
d4e68bd1a9
|
合入 W4-d 目录前端：数据目录的「变化」视图与处理动作、数据源角标、表详情「结构与取值变化」一节、数据源的定时维护（一条目标为数据源的定时任务）、后台任务条（探查、起草、剖析按服务端排队顺序）；打开 source.changed 订阅；指名数据源卡片统一用 #source-<id>
|
2026-10-16 22:30:09 +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
|
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
|
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
|
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
|
2371e75f17
|
评测执行的主干：后台评测、无头作答、评分、统计、对比与 A/B、清理（下一轮第 3 波 W3-c 第一段）
为什么：第 2 波只有题集和期望答案的来源，评测本身跑不起来。这一段把细案 01 做法 9–12、16、17 的后端接上，
量的是用户在问数据页拿到的同一轮，而不是另抄一份编排。
- eval/answer.py：无头作答，串起 answer_ops → chat/turn 的决定 → launch_run(origin=eval，带目录视图、只读、遮罩)
→ 等终态（停在审批的取消、记「评测不代批」；驳回记路径「被驳回」）→ review_of_run → 按同一规则重来一次；
工作流题按钉住版本的图跑探索运行（不发正式运行，免得被 pick_base 和应用视图取到）。用量按角色记
- eval/runner.py：用 core/job_runtime，一次评测一个任务，题 × 重复 × 臂一项；A/B 几臂共用期望、同一题同时开跑；
开评拍目录快照、记上传表格版本和表结构哈希的前后；并发不超过 max_parallel 和全局并发的四分之一；每题时限；
评测单独一本账（开跑前估算、每题预留后找补、触顶不再开新题）；止损；能停、只重试没做完的、重启标中断不续跑
- eval/score.py：六种期望、五种结论（量纲不同单列）、维度配对与弱匹配、路径不对直接不通过、口径 dual 两版都报；
逐题 E1 用口径账本的 compare_queries（总方案 X2，不另写 signals）；SCORER_VERSION 可重评（eval/rescore.py，只读封存）
- eval/judging.py：结论裁判走按需裁判同一条路（evidence._judge_now），文字要点由裁判判、单列不计准确率；花费经
judge.charged_to 记在评测那本账上（engine/judge.py 只加了一个上下文变量和取账本的一处）
- eval/stats.py、eval/compare.py：准确率与可追溯准确率 + Wilson 区间、各项分布、P50/P90、按角色成本、引用率、逐题 E1；
选基准、逐题转移与归因、指纹差异、A/B 配对表与精确 McNemar；「目录贡献」预设对照（当前 vs 关，可加只用已核实）
- eval/cleanup.py + core/artifact_store.forget：保留最近 N 次 + 钉住的基线 + A/B 另几臂，删结果、明细工件、底下的运行和
引用行，工件文件一条引用都不剩才删；总表永久保留
- engine/tolerance.py：双盲复算的 _agree / _delta_pct 原样搬来共用（dual_check 改 import，行为不变）
- 设置加 eval 一组（builder 读、admin 写）和 GET /api/settings/eval/spend；题集预算在全站缺省上覆盖，每日上限只能往下收
- api/evals.py：发起（单臂 / A/B / 目录贡献预设）、估算、进度、逐题、停止、重试、重评、钉基线、和上一次比、配对表、清理
- main.py 的 lifespan：影子起草和评测的启动整理、关停（评测先于运行停，停时取消自己发起的运行）
- 测试：test_eval_e2e（dual_check_shop + 剧本模型：按支付日 330 通过且 SQL 等价，按下单日 310 不通过、差在 time；
目录对照 1:0；和上一次比找到退步、归因做法变）；通知事件、定时接口形状的老测试按新事件和新字段更新
|
2026-10-16 16:38:09 +08:00 |
|
|
ThearchyHelios
|
86d2840e41
|
W3-d 邮件渠道、待办汇总、访问密钥到期提醒（后端）
邮件（04 细案 B2，集成-I4 / I5，改写应用平台 Q6）：
- notify/mail.py：标准库 smtplib 放进 asyncio.to_thread，单次超时 10 秒；4xx 和连不上按 1/2/4 秒重试，5xx 不重试；
报错只写主机名和服务器回话，口令一律抹掉；纯文本 + 转义过的 HTML，带 List-Unsubscribe 和 Auto-Submitted；测试可换假的
SMTP 工厂。模块说明写清改写 Q6 的理由：SMTP 是可选配置、退信不追踪照实说「已交给邮件服务器」
- 通知渠道多一种格式「邮件」（core.CHANNEL_FORMATS；定时任务的 Webhook 只会发 HTTP，FORMATS 不加，免得定时任务能选
邮件）：个人邮件渠道不收地址，只发到名录里的账号邮箱，没有邮箱记一条失败投递并写明去「设置 → 身份」填；全局、应用的填
固定地址，最多 20 个；邮件服务没启用时不收新的邮件渠道；渠道列表另给 mail（启没启用、本人的账号邮箱），投递记录带格式
- 设置的 mail 一组（只有管理员能改）：口令用 core/crypto 加密，读的时候只说配没配；启用时要配全；发件人名称、主机不许
换行；「发测试邮件」只发到管理员自己的账号邮箱，关登录、没有邮箱时 422 说清怎么办
- mail.default_for_assignees（缺省关）：开了之后第一次派到待办的人自动有一个个人邮件渠道（订阅待办打开、动作结果未知、
审核有结果），本人删了不再建回来；关登录时不建
待办汇总与密钥到期（04 细案 B3）：
- notify/digest.py 接进调度循环的步骤列表：每天到 notify.digest_at（缺省 09:00，服务端时区）给订阅了 task.digest 的
个人渠道发汇总（条数、最早时限、最多 5 条节点名、去待办箱的链接，没有待办不发）；按日期在 settings 表里插一行认领，
重启不重发；认领行和自动建邮件渠道的名单是通知自己记的账，设置接口不列不收
- key.expiring：到期前 7 天、1 天各推一次，个人密钥推本人的个人渠道、服务账号的推全局渠道，推之前记审计、按审计去重；
轮换下来的旧密钥、撤销了的、建的时候就在这一档里的不推
- 两个事件推送实现了，才在 notify/service.EVENTS 打开它们的订阅范围
设置的 notify 一组加 digest_at；只给一部分时补上存着的另几项；环境变量锁住对外访问地址时只核对那一项，汇总时间照常能改。
apps 一组加 share_links（分享链接的开关，缺省关，下一个提交用）。测试：假 SMTP 工厂下的收件人、失败投递、重试、口令、
设置与权限、自动建渠道；汇总按时、只发一次、重启不重发；密钥两档、谁收、不该推的几种。
|
2026-10-16 16:21:41 +08:00 |
|
|
ThearchyHelios
|
479cec0af7
|
通知事件一次登记（总方案 X6、5.1）：六个新事件进 notify/service.EVENTS，推给哪几条路也登记在那一处
复核指出 X6 漏做：第 2、3 波的数据源变化、口径召回、评测、触达四块都要往 EVENTS、EVENT_LABEL 和前端设置页的事件列表里
加东西，正是 X6 要避免的同一处多方冲突；消息里能放什么也没有一处先定好。
做了什么：
- EVENTS 改成登记表：每个事件一行，叫法 + 推给哪几条路（scopes：global 全局渠道自己订阅、user 相关的人自己的个人渠道、
app 应用版本 spec.notify 的订阅）。本轮新登记 source.changed、ledger.recall、eval.regressed、eval.failed、task.digest、
key.expiring，scopes 都是空的——登记了、还没有推送。实现推送的那一块只改自己那一行的 scopes（各行之间隔着说明行，几块并行
改也不会挨着冲突），前端叫法表不用再动。EVENT_LABEL 从登记表派生，老的 import 不变。
- 模块说明写清消息结构：标题、状态、条数、链接，加编号和搭建时起的名字；不放报告和答案里的数、表名、列名、取值、SQL、
按运行数据渲染出来的句子。
- _channels 只走事件登记了的路；没登记的事件直接报错（推送之前先登记）。现有五个事件登记的路照现在的做法，行为不变。
- 接口：订阅按登记核对（subscribe_problem）：没推送的「还没有推送，暂时不能订阅」，范围不对的「不推给范围是「应用」的
渠道」。只核对这次新勾的：以前存下的照旧，开关、改名不会因此 422。GET /api/notify/events 多给 scopes（空的照实给）。
- 前端：terms.ts 的 eventLabel 和 EVENTS 一一对应、逐字一致，六个新事件先有叫法；设置页的渠道编辑框、应用的通知改按
GET /api/notify/events 列（这种范围收得到的才列，已经勾着的照样列出来能取消；取不到时照实说）。
顺带修掉的（就在要改的那张列表上）：设置页以前按前端叫法表的键列事件，里面有五个服务端从来不认的（待办升级、待办超时、
待办处理完、动作失败、动作已生效），一勾保存就 422；改派、升级、催办只在投递记录里出现，另起 deliveryEventLabel（加上测试
消息），记录里照实写是哪一种。服务端 EVENT_LABEL 的四句老叫法（有待办派给我、实例完成、实例失败、写入结果未知）改成和界面
同一句，界面上看到的字不变。
验证：新增 test_notify_events（登记表、前后端逐字对照、接口拒收、只走登记了的路），去掉 _channels 的按路过滤或「只核对新勾
的」回跑各有一项失败；check-capabilities 加一段「可订阅的事件照服务端登记列」，把列表改回按叫法表的键列，四项失败。
|
2026-10-16 12:12:14 +08:00 |
|