19 Commits

Author	SHA1	Message	Date
ThearchyHelios	358206312e	事件触发的规模：定时任务列表里每个事件触发任务「有几条在等」一次查齐（outbox.pending_for_many：待派发数一条 SQL 按任务分组算，窗口要看的事件一次读出），不再每行查一次；每一拍派发只读触发条件的事件种类、对象对得上的任务（SQLAlchemy 的通用 JSON 访问），保存时查环一层查一次、只顺着「上游工作流运行成功结束」的边找；选对象（trigger-options）按事件、关键字查、一页最多 100 个、more 说还有没有，当前选中的总在里面，编辑页一页没列完时多一个按名称查找。顺带修：等着的时候任务改了条件、最早那条不再合条件时，「什么时候合成触发」按剩下的最早一条算（列表上的时刻和真发起的一致）；一个窗口的结束时刻和这个任务已有的另一次触发撞在同一刻（别的期次早一拍发了）时往后挪，那几条事件照常发起，不再被记到已有的触发上	2026-10-19 09:46:47 +08:00
ThearchyHelios	656a550408	数据事件触发按复核意见修正：途经驳回、去抖积压、source.changed 补写、按期次分窗口、补算缺省不认、示例出口字段同一套过滤 ... M1 途经驳回（编排者已定）：outbox.stage_run_finished 收可选的 rejected_via（缺省 None 即没途经驳回），事件内容带 rejected 和 rejected_via，说法接「（途经驳回）」，模板有 {{ event.rejected }}（true / false）。触发条件缺省只认没途经驳回的，trigger 加 include_rejected（界面「也认途经驳回的」勾选，说明照实写）。runner._finalize 把 _rejected_via(state) 传进来那一下留给编排者 在合并时接（runner 的 _rejected_via 在 W1-b 的分支上）；测试直接调 stage_run_finished 传参覆盖。 C1 去抖积压：以前一拍只走一个窗口，积压时后面的越等越久、全过了宽限，而且每个窗口各记一条跳过，原因还说调度没在跑。 现在 _drain 按发生时刻把等着的事件切成窗口，一拍里把到点的处理完（最多 100 个窗口、5000 条）；排在前面已过补发宽限的合成 一条 skipped_misfire（合并了几次事件、几个窗口、时间跨度，上传表格另写合掉的期次），派给任务时已经晚于宽限才说「调度未运行」， 否则照实说积压；宽限内的照常发起（照重叠规则跳过的照实记）。 C3 source.changed：这一处确实没法和变化记录同一个事务（一次探查、剖析的变化分好几批落库，一批只触发一次要等任务结束才知道）， 改成说实话：models_triggers 的说明写清哪两种同事务、哪一种不是。trigger_events 加 dedupe_key（source.changed:<任务号>，唯一）， emit_source_changed 按它去重；调度的一拍（刚起的服务第一拍就补，之后每 10 分钟）由 backfill_source_changes 按任务号补写：2 天内 测到、还开着的要处理级变化，任务已结束却没有事件的补一条。分组在 Python 里做，不用各库写法不同的 JSON 取值。 C4 按期次分窗口：triggers.window_key 让上传表格按期次各自成窗口，9 月、10 月连着启用各有各的触发；同一期的重传照旧合并。 两个窗口结束在同一刻时后一个挪 1 微秒，fire_at 不撞唯一约束。 C5 应用补算：workflow.finished 缺省不认 app_backfill 发起的（升版补算连发好几条、各是某一期的历史输入），trigger 加 include_backfill（界面「也认应用补算的」），选了「只认应用补算」时本来就认；说法写「途经驳回、应用补算的不算」。 C6 示例出口字段：triggers.outputs_of 一处过滤「_」开头的键，真派发、预览、立即运行共用；示例事件也按 matches 跳过缺省不认的 途经驳回、应用补算，取合条件的最近一次。 测试：新加 test_schedule_events_review.py（11 项，先写、先看着失败；去掉 matches 的驳回判断、把每拍窗口数改回 1 回跑，对应用例 各自失败），test_schedule_events_api.py 加一项「也认」两项经接口存取和说法；check-schedules 加「上游工作流的请求体」一段、纯函数 几条、触发历史里合并跳过那一行的夹具。 验证：后端全量 14479 通过；tsc、check-copy；check-schedules 447 项、check-runs 327 项通过（拿锁、--stacks 1）。	2026-10-18 18:09:20 +08:00
ThearchyHelios	3f1eeff841	数据事件触发（界面）：定时页新建时选「定时 / 事件触发」、事件那一节、列表与详情的等待状态、触发历史和运行详情的「由事件触发」 ... 做了什么： - 新建定时任务（目标是工作流时）先选怎么触发：定时 / 事件触发（TriggerEditor 的 TriggerModePicker）；修改时只读地写出触发方式、 说明建好之后不能改。选了事件触发，频率那一节换成事件（EventSection）：三种事件、对象下拉（能选哪些、不能选的原因由新接口 GET /api/schedules/trigger-options 给，界面照着画、选不了的置灰并写原因）、上传表格的期次（只认新增的一期）、上游工作流的 只认应用 / 只认来源和触发链上限的说明、去抖、时区；换事件种类时对象和过滤清掉。 - 预览按一次事件渲染输入（对象最近一次的事件，没有时照实说是示例值），不列触发时间；变量按事件种类取（api.schedules.eventVariables）， 插得进 {{ event.* }}；请求体带 trigger_kind、trigger，cron 交空串；修改时只交改了的触发条件。model.ts 加 TriggerForm 与 triggerBody / switchEvent，表单问题里事件触发不查频率、要求选对象；服务端 422 指 trigger 时落到事件那一节。 - 列表、详情：「事件触发」标签，频率处写触发说明；下次运行写在等什么（去抖中收到几次、何时合成一次触发；有事件等待派发；调度 没开时照实说不会派发）。触发历史：类型「事件」，写「由事件触发：…」、合并了几次、第几层；立即运行按最近一次事件发起的写 「按事件：…」并标示例值。运行详情页头写「由事件触发：…（定时任务「X」）」（RunDetailView 只多传一个 trigger 属性），立即运行 按事件发起的写「立即运行定时任务「X」，按事件：…」，不说成由事件触发；应用页印章同样不算。 - 文案进 lib/termsTrigger.ts；SCHEDULE_TEXT 只补触发类型「事件」和「还需处理」里的「触发事件」。立即运行按示例事件的说法 不再在服务端加「（示例值）」后缀，是不是示例值看 real。 为什么：总方案 §4 要求定时页能建事件触发的任务、列表 / 详情 / 触发历史 / 记录页照实显示；能不能选、为什么由服务端判，界面不放逻辑。 验证：tsc、check-copy；check-schedules 加纯函数一段（表单 ⇄ 请求体）和三段页面（新建的请求体、列表 / 详情 / 触发历史、运行详情 页头，含 390px 浅色），假接口加了触发选项、事件预览、事件变量、事件触发任务的夹具，写请求断言请求体；原有各段照过；check-runs 照过。	2026-10-18 16:11:55 +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	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	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
ThearchyHelios	2fb16c2719	设置页加「通用」标签放对外访问地址；环境变量指定时显示「由环境变量指定」不可改，定时任务里的入口跟着认 ... 服务端已经只认一个对外访问地址（core/public_url.py），界面上这一项以前只在定时任务的 Webhook 一节里改得到，叫「服务 访问地址」，和设置接口、通知里的「对外访问地址」两种说法；环境变量设了时那里照样能改，改了也不生效。 - 新增「设置 → 通用」（pages/settings/GeneralTab.tsx）：写明它管哪几件事（通知和 Webhook 的链接、单点登录的回调、来源 核对）；管理员能改，保存前先重读 notify 一组、只换这一项，末尾的 / 去掉，带 ? 或 # 的当场标错；改了没保存离开先问； 环境变量指定了的只显示它、写明「由环境变量 AGENTLAB_PUBLIC_URL 指定」，不给输入框；搭建者只看。使用者看不到这一页 - 定时任务 Webhook 一节的快捷入口改叫「对外访问地址」，按 GET /api/settings 的 public_url 一组认：环境变量指定的只显示、 不给修改按钮，设置里存着的旧值不再冒充生效的那个；地址校验和「通用」同一个（lib/publicUrl.ts） - 文案进 lib/terms.ts（GENERAL_SETTING_TEXT，SCHEDULE_TEXT 的 linkBase 一组改说法） 检查：check-manage 加「设置 · 通用：对外访问地址」一节（标签、说明、校验、离开先问、只写 notify 一组、环境变量只读、 搭建者只读）；check-schedules 加「对外访问地址由环境变量指定」一节。check-manage、check-schedules 在隔离的一套后端 + vite 上全部通过，tsc、check-copy 通过。	2026-10-16 10:31:26 +08:00
ThearchyHelios	941723b17c	端到端验收修复与指标出具： ... - 身份与工具：登录页建第一个管理员（认人接口的 401 说明能不能建）；搭建者有只读的人和组名录，选人给候选并核对名字；授权三行带标题；端点请求头名校验（空名、非法名存不进、发不出时说清原因）；写入能力在工具页试运行一律演练、不发送，HTTP 状态照实说成败；写记忆不算只读、查询能力只能选同一端点上的只读能力；审批与遮罩的说法和实际规则一致；开登录时不要署名、导入和发布记登录的人；使用者不显示推演等只给搭建者的操作，403 按是否开登录说话；登录页只认一次人 - 流程与实例：图里用到的岗位（派给谁、超时升级给谁、发送确认派给谁）全部派生、没绑人的发布时报错；写外部系统的参数按能力声明的类型收拢后再算哈希和发送，收不成就不发；发起人的实例页只看这一步的状态，处理人才给待办卡；会签进度带登录核实和时间，升级后照实写规则；实例状态写流程的结论（已退回、未确认、等待核实写入结果），核实生效后不再挂失败原因；流程应用首页不派生最近封存运行的结果块，看板没数据时是安静的空态；样例⑩的金额带类型和下限、待办标题带金额，表单上下限前后端一起生效 - 看板与证据：定时任务模板加 ISO 周、上一 ISO 周、本月、上月；出处链穿过原样解析查询结果的整形节点，追不到原始数据的照实说停在哪里，样例⑨改用 cell()；应用首页和版本历史都能做成应用；指标块单位不重复；版本列表带退役说明；定时任务页头跟着刷新；删视图要确认、新视图能起名；编辑器属性用中文名、术语带解释 - 指标出具（用户 2026-10-15 拍板）：契约只写「指标来自」、上游没有报告撰写节点、成果里没有模型写的话时按指标出具——必需指标齐、指标输入追到原始数据、成果字段里的数回指得上才完整出具；受管级要求每个指标静态地追到原始数据（governed.metric_untraced）；出具横幅和应用印章写明按指标 - 受管工作流降为已发布只给管理员（Q8 顺延，服务端同样拦）；工作流接口带当前发布版的级别，画布上改过之后也认得出受管工作流	2026-10-15 07:15:37 +08:00
ThearchyHelios	df6b0dd3ae	M4：触发历史的翻页游标写成 Z 结尾，照原样拼进查询串也能翻页 ... next_before 原来是「2026-10-06T14:37:03.376320+00:00」，照接口说明「原样传回」拼进地址时「+」被查询串解成空格， 回 422「翻页位置需要是接口返回的 next_before」。界面用 URLSearchParams 编码不受影响，照说明写脚本、做集成的会撞上。 现在游标是 UTC 的 Z 结尾、精确到微秒（和运行列表的游标一个写法，放进地址不用编码）；解析时 Z、+00:00、被解成空格 的「 00:00」（老的游标照原样拼进地址时就是这样）都认，不是时间的照旧回 422。check-schedules 的假接口照服务端用记录 时间作游标，另加一节：老服务端给 +00:00 的游标时，页面编码成 %2B 传回、第二页接得上、不重复。	2026-10-07 00:02:15 +08:00
ThearchyHelios	53bb356fae	复核第 1 轮：对比入口预先问默认基准带 5 秒超时、问到没有默认基准时写「选择基准对比…」直接去对比页手动选、切回页面时再问一次；工件页签的悬停照实写，320px 时校验值和大小不再拆开 ... - 对比入口（pages/runs/compare/entry.tsx）：预先问 compare/base 卡着不回时 5 秒后按没问到算，叫法退回「与上一次对比」、可点，不再一直停在不可点的「正在查找」；问到没有默认基准（多为工作流的第一次运行）时写「选择基准对比…」，点了直接去只带本次的对比页手动选（对比页自己再找一次），不再写「与上一次对比」、点了再问一遍弹提示；切去别的标签页再切回来时再问一次，问的期间保留原来的叫法、可点，问到不一样才换，问不到不改；更正预先问那段注释的前提（compare/base 不回 409、422，不先问是因为这些入口本来不给点） - 运行详情「工件」页签头的悬停写上证据快照、核查记录和每个节点的产出三组（RUN_ARTIFACTS_TEXT.tabTitle，RunDetailView 只换这一处）；证据快照的悬停不再说「结论里的数字从这里来」，点明含核查、质询时执行的查询；核查记录的悬停用行上的种类名，指明其间执行的查询见「证据快照」；两句都在 45 字内 - 工件行的校验值和大小包在一起排、一起折行，这一栏窄于 22rem 时收起校验值：320px 下大小不再单独折到种类下面，每行仍是两行 - 对比页没带运行时的说明缩成 32 字，不逐个列菜单项的叫法 - 检查：check-compare 补预先问超时、没有默认基准、切回页面再问、点了才发现没有基准后叫法跟着改、工件页签悬停几节；check-verify 改两组悬停的断言、补 320px；check-schedules 的假 compare/base 补上 previous: false（和服务端一致），断言运行详情菜单项与触发历史链接的叫法一字不差	2026-10-06 18:25:35 +08:00
ThearchyHelios	1bee9b5100	触发历史不再给基准已过时的自动对比；对比页找不到默认基准时标题不再和「可在上方选择」打架，换基准的下拉和基准卡写明失败、取消的运行 ... - 中间失败的那次事后被接着运行成功之后，第 3 周存着的那份对比（比的是第 1 周，previous 为假）和运行详情「与上一次 对比」的默认基准（现在是第 2 周）又对不上，两处却都写「上一次成功的运行」。auto_compare.outdated 对基准当时就不是 紧挨着的上一次的那几份按 pick_base 现挑一遍，基准变了的算过时；api/schedules._fire_outs 对过时的给 null（不给链接、 不给旧计数），两个同名入口比的始终是同一对运行。基准没变的照旧给：中间那次还没结束、后来失败、被删掉都一样。紧挨着 的上一次不会过时（两次之间插不进新的运行），不核 - test_base_follows_launch_order_not_finish_time 补上：接着运行完之后第 3 周的触发记录不再带对比、任务列表的 last_fire 同样不带、运行详情的默认基准是第 2 周；另加一条基准仍是挑出来的那一次时照旧给出 - 对比页找不到默认基准：标题由「未找到可作为基准的运行」改为「没有默认基准」——失败、取消但封存了的运行不当默认基准， 却照样能在上方手动选；服务端的原因改成「没有找到上一次成功的运行：需要同一工作流、同一运行类别里比这次先发起、成功 结束并已封存的运行」，运行详情弹出的提示单独读也说得清 - 换基准的下拉给失败、已取消的运行写上状态，基准卡也标出来；下拉说明补一句默认基准只取成功结束的运行 - 运行详情「更多」的菜单项点之前不知道基准是哪一次，基准不是紧挨着的上一次时仍叫「与上一次对比」，和触发历史的叫法 不同：注释照实写明，留作后续	2026-10-06 13:33:40 +08:00
ThearchyHelios	a18b24ab6f	对比页与触发历史照实说「上一次成功的运行」：两个同名入口打开同一对运行、写同一句来历 ... 服务端的默认基准和自动对比已经共用一个挑法（只挑比本次先发起、成功结束并封存的运行），界面上的说法跟着改： - 对比页的「默认基准：…」改成「同一定时任务上一次成功的运行」「同一工作流、同一运行类别上一次成功的运行」；运行详情 查找基准时的提示、没带本次时的说明同样改成「上一次成功的运行」 - 触发历史的「与上一次对比」：基准不是紧挨着的上一次（previous 为 false）时，链接上看得见的字写「与上一次成功的运行 对比」，触屏、键盘聚焦都看得到，悬停照旧写是哪一次。两种都带上「同一定时任务」的来历：新的说法对这两种都成立， 对比页和从运行详情进去时一字不差 - check-compare：两种来历的说法；运行详情「更多」和触发历史两个入口打开同一对运行、写同一句来历、摘要一致 - check-schedules：previous 为 false 时看得见的字（含键盘聚焦、390px 窄屏）；两个入口拿同一个基准	2026-10-06 12:05:40 +08:00
ThearchyHelios	5e8d2c9c36	定时任务自动对比复核整改（前端）：页头的定时任务链接在窄窗口里不再被挤没、带日历图标、任务删了写纯文本；触发历史的对比入口改叫「与上一次对比」并写出有几个指标有变化 ... - 运行详情页头：元信息这一行改成可换行，定时任务链接至少留 7 个字宽。以前这一行不换行、只有链接能缩，820 宽的探索 运行只剩「由…」，768 宽为 0，Tab 停在看不见的链接上，「2 条事件」被压成竖排。链接前加和「定时」标记一样的日历 图标，平时看得出能点。取回的定时任务列表里没有这个任务（已删除）时写成纯文本「由定时任务「X」发起（已删除）」， 不再链到「不存在」页；列表取不到时不算删除 - 触发历史：「对比上一次」改成和运行详情「更多」菜单同一个叫法「与上一次对比」（复用 RUN_COMPARE_TEXT.menu），旁边 写「N 个指标有变化」，触屏和键盘也看得到变化的规模，悬停照旧写各类个数。基准不是紧挨着的上一次（服务端给 previous: false）时悬停写明是哪一次，也不再带「默认基准：同一定时任务的上一次运行」的来历 - 「通知中的运行链接」改成「通知中的链接」，说明里写清对比页链接也靠这个地址 - check-schedules：对比入口的叫法、计数、previous 为 false 时的悬停和来历；页头链接在 768、820 宽（含「提取为草稿」 的探索运行、署名的立即运行）写得下「由定时任务」且「条事件」不竖排、Tab 到时看得见；图标；定时任务删除后的纯文本 和列表取不到时照旧是链接；390 宽深浅色下计数在屏幕里、对比度够	2026-10-06 08:49:10 +08:00
ThearchyHelios	f8ac8dc1d6	定时任务自动对比收尾：基准那一次不在终态或被删时不给对比、对比工件读不出来时触发历史照常打开；检查脚本按实际底色量对比度 ... - 触发历史的 compare：以前只看这一次的运行在不在终态。基准那一次被强制删除、失败后被继续执行时，对比页比不了， 「对比上一次」链过去只会报错——基准一侧同样要在终态，否则给 null - 对比工件读不出来（权限、磁盘出错）时记一条警告、给 null：以前 OSError 直接抛出，整页触发历史回 500。被改过 （内容与哈希不符）的以前就给 null，这次补上用例 - check-schedules：页头的定时任务链接、触发历史的「对比上一次」改成量 WCAG 对比度（≥ 4.5），底色顺着祖先叠到 不透明为止。以前比的是「字色不等于页头的底色」，页头本身透明，那样比永远成立；深色也补上同样的检查。另加一项 署名的立即运行配长名字：署名照写、链接截断、页头不横向溢出	2026-10-06 07:43:01 +08:00
ThearchyHelios	863b0b2894	定时任务前端：触发历史加「对比上一次」，运行详情页头的「由定时任务「X」发起」改成键盘可达的链接 ... - 触发历史：服务端给了 compare 的那次触发，在运行链接前加「对比上一次」，链到对比页（本次是这次触发的运行、 基准是服务端自动对比时取的同一任务上一次），带上来历让对比页写「默认基准：同一定时任务的上一次运行」。悬停写 各类指标的个数，和 Webhook 通知那一行同一个写法（三类总写、其余有才写、两边都没有指标时不写一串 0 个），读屏 当说明念；只有个数。compare 为 null、老服务端不给时不显示 - 运行详情页头：定时任务发起的运行，「谁发起的」那一段换成到 /schedules/:id 的真链接（Tab 到得了、回车能开， 有焦点环）。到点发起的（署名是「定时任务：X」）整句换成「由定时任务「X」发起」，不再写两遍；有人署名点了 立即运行的，署名照写、后面接「来自定时任务「X」」。名字取定时任务现在的名字，取不到用署名里记的；长名字截断， 全名在悬停里。记录页「定时」标记的说明同步改成指向这里 - types.ts 定时任务那一段加 ScheduleFireCompare 和 ScheduleFire.compare；文案进 SCHEDULE_TEXT - check-schedules：触发历史的对比链接（地址、悬停的计数、只在有 compare 的行出现、Tab 到得了、回车打开对比页）、 运行详情页头的链接（现在的名字、真链接、不重复署名、Tab 到得了且有焦点环、回车去定时任务、署名的立即运行、 手动运行没有、长名字截断不撑宽、浅色可读），390px 深浅色下对比链接在屏幕里、看得清	2026-10-05 18:58:25 +08:00
ThearchyHelios	4b972b4f43	定时任务前端复核修正（第 2 轮）：错过已跳过的悬停不再替服务端认定是超出补发宽限，没有记原因时不指向不存在的原因 ... 服务端把两种没有补发的触发都记成 kind=misfire、status=skipped_misfire：一是超出补发宽限，二是在宽限内恢复时 积压的那几次（只发起最近一次，更早的不补）。触发类型「定时」的悬停却一律写「错过后已超出补发宽限」，积压那条的 原因写的是「积压的触发不补，只发起最近一次」，同一行给出两个互相矛盾的原因，而这条明明是在宽限以内被跳过的。 - 触发类型的悬停改成不点明原因：「按计划应在此时触发，错过后没有补发，原因见本条记录」；本条没有记原因时去掉 「原因见本条记录」。 - 结局悬停的兜底说明（本条没有记原因时用）一起改：错过已跳过不再写「超出补发宽限」，两种原因都适用；发起失败 不再写「到点」（手动立即运行也会发起失败），也不再写「原因见本条记录」（用到兜底时本条恰好没有原因）。 - check-schedules 的触发历史夹具按服务端的原话各放一条积压不补、超出宽限的跳过，外加错过已跳过、发起失败各一条 没有记原因的；断言整行连同各处悬停只说本条记的原因，不说另一种，不指向不存在的原因。修复前这几项红 5 项。	2026-10-05 11:05:42 +08:00
ThearchyHelios	defd118ea6	定时任务前端复核修正（第 1 轮）：时区检查改成真能拦住，服务端会拒的组合当场拦下，修几处时序问题 ... - check-schedules：浏览器本机时区改成 America/Los_Angeles，和夹具里的 Asia/Shanghai、America/New_York 都不同。列表的下次运行和上次触发、触发历史 20 行、预览 5 个时刻，都改为比对按定时任务时区写出的原文；假预览照真服务端那样按所选时区排时刻。把页面改成按本机时区显示的变异会让 6 项变红。原先恒为真的「只读」断言改为真正检查写请求。 - 测试消息的结果：服务端的 message 只是补充说明时接在结局后面，已经是整句时不再套一层，状态码只写一次（webhookTestText）。 - 正式运行 + 工作流没发布、必填输入没填、填了已发布版本里没有的字段：照服务端保存时的核对规则当场拦下（新建总查；修改只在改了工作流、运行类别或输入时查），说明写在对应那一项下面。保存被拒、服务端指明 run_class 或 misfire_grace_s 时，说明也写在那一项下面。 - 保存被 422 拒绝后，改了被指出的那一项，字段下的说明和底部的「保存失败」就收起；名称框的 aria-invalid 和 aria-describedby 也把服务端的说明算进去。 - 时序：列表和详情页在写操作成功时作废还在路上的读，晚到的刷新不再把开关盖回旧值。详情页先开触发历史再切到设置时，版本对齐到表单所基于的那一份。保存途中又改了别的字段时，只保留途中改的那几项，替换过的 Webhook 地址不再以明文留在输入框里。 - 其他：预览时间改用 parseServerTime 解析；换工作流时，自动填的名称跟着换；开关遇到 409 用前端自己的说明，服务端原话放进详情；错过且超出宽限、没有补发的触发，类型写「定时」而不是「补发」；记录页的「定时」标记让读屏念出是哪个定时任务发起的。 - 未达标：记录页的「定时」标记在整行的按钮里面，键盘到不了。键盘能到的入口要加在运行详情的页头，或者把整行改成「打开运行」按钮和链接并排的结构，这两处都不在本包的文件范围内，留给集成时处理。	2026-10-05 10:26:22 +08:00
ThearchyHelios	c77a7f38d5	check-schedules 换成真检查 ... 真页面走真的应用外壳，接口全部在浏览器层答掉：定时任务、触发历史、预览、变量、工作流列表是虚构的门店周报、库存日报，写请求照接口约定改这里的假状态（PATCH 核对版本、Webhook 地址省略即不改、空串即删除）；设置读真的、只换 notify 一组和主题，别的写请求一律拦成 503，不碰真实写接口。 查的是： - 纯函数（借 vite 转译 model.ts）：预设生成的 cron、cron 落回预设、按时区写时间和偏移（含夏令时）、距下次运行的取整、修改时只交改了的字段、Webhook 地址和密钥的省略与空串 - 列表：名字、工作流、频率说法、下次运行（相对加按时区的绝对时间、悬停看时区）、上次触发链到运行、暂停和跳过照实写；空态、老服务端 - 启用开关发 PATCH 且带版本、再点带新版本、409 说原话并重新载入、键盘空格切换 - 立即运行发 POST 并说结果（发起、跳过、被拒）、「查看运行」直达；删除先站内确认 - 新建「每周一 09:00」：工作流可搜索、默认勾周一、正式运行字段取已发布版本、点变量插入、预览 5 次触发和渲染结果、预览防抖，POST 的 cron、时区、输入模板、Webhook 逐项核对；创建后地址只显示 url_hint、页面和输入框里都没有完整地址 - 非法 cron、不认识的时区和变量：说明写在出错那一项下、标 aria-invalid、清掉旧的预览、不能保存；离开前确认 - 详情：只改事件时不带地址、替换地址、删除 Webhook、发送测试消息、运行链接地址写 notify 组；页头开关之后表单用新版本、别处改过时 409 给重新载入 - 触发历史分页（before 游标、去重、已全部加载）、各种类型和结局、原因和通知结果；直接打开触发历史不先请求表单的预览 - 记录页的定时标记：只标定时发起的、悬停写定时任务名、点了去定时任务不打开运行 - 390px 深浅色：列表、新建表单、触发历史都不横向溢出，按钮在屏幕里，窄屏预览排在频率下面 check-all 里 check-schedules 的耗时按实测改成 40 秒。	2026-10-05 09:02:02 +08:00
ThearchyHelios	6041073ef2	检查脚本骨架：check-all 另起的后端带 AGENTLAB_SCHEDULER=0，拷来的数据目录不会替原库到点发起运行、发出 webhook。新加 check-schedules、compare、verify、inquiry、bundle、whatif 六个占位检查（只打一行通过，输出格式和别的检查一样），登记进 ORDER 和 ESTIMATE，各工作包换成真检查	2026-10-04 23:40:20 +08:00