39 Commits

Author	SHA1	Message	Date
ThearchyHelios	ba22b82b3d	复核 R-b9（Fenced 打到不该打的地方）：check() 续晚了谁问到都隔离，但只对绑定了世代的执行（运行的一段执行、后台任务）抛 Fenced，HTTP 处理、调度那一拍、进程间请求问到时只隔离不抛；调度循环、心跳、办进程间请求也接住 Fenced；续租的任务不再因为一下出错就退出——续租、隔离之后重新登记都包住，照实记日志、退避着重试（最长一个租约时长）。隔离时马上换身份（之后新建的行记新身份），新身份登记上之前心跳不争当班、不接手，新开始的运行、后台任务在 fence.ready() 上等（最多一个租约时长，等不到就不开始，那几行由别的进程按属主不在了处理，这边同时放弃这个一直没登记上的身份、再换一个）。日志写出新旧完整身份。补测试：没绑定的调用者只隔离不抛、绑定在隔离之前的抛、新身份登记上之前 ready 等着；调度循环被 Fenced 打到一拍之后照常；重新登记先被版本守卫拦、再碰上库连不上，续租任务都不退出，登记上之后照常续租	2026-10-19 14:33:45 +08:00
ThearchyHelios	4e3623885b	合入 W2-a 的复核修复（nr8/a：导入的 NOT NULL 补值与孤儿行、收尾 dispose、sslmode 换算、PostgreSQL 写入去 NUL、不分大小写搜索 contains_ci、json_eq 两库同语义、JSON 守卫、用户可见列表补决胜键、bubblewrap --clearenv、部署脚本与原子写的几处、README 连接数预算） ... # Conflicts: # backend/app/api/schedules.py # backend/app/main.py	2026-10-19 12:21:38 +08:00
ThearchyHelios	0d9f1d9339	用户看得到的列表补决胜键（复核 R-a9）：按名称、时间等可能并列的排序后面补上同一个模型的 id，并列时两种库排出来一样 ... - 实测 /api/evals/calibers、/api/schedules/trigger-options 按 Workflow.name 排序遇同名并列时 SQLite、PostgreSQL 顺序不同。用 AST 逐个过了一遍 order_by：最后一个排序键是 created_at / updated_at / last_active_at / at / name / 各种 *_at 之类、不唯一的列，又不带 DISTINCT、GROUP BY 的，补「, 模型.id」（降序补 id.desc()），共 104 处，分布在 api、apps、auth、blueprints、chat、data、engine、eval、ledger、look、memory、process、providers、scheduler（runs.py 里的三处在上一个提交里） - 按唯一列（seq、version、唯一的 name）排的不动；按聚合、coalesce 之类表达式排的说明见 db/postgres	2026-10-19 12:07:06 +08:00
ThearchyHelios	ae254b052e	合入遗留收口分支 nr8/l 的复核修复（变化记录先占住那一行再读改写、召回里行序不定的指标、事件触发列表按任务各取上限、选对象按名字查用 ilike、子工作流写入认旧键、几处测试的竞态） ... # Conflicts: # backend/app/ledger/recall.py	2026-10-19 12:05:19 +08:00
ThearchyHelios	c768c56fd7	多进程协调补齐几处：执行时长从拿到名额算起（排队等名额不算执行，墙钟本来就从开始执行算）；蓝图留痕、蓝图助手开轮先占住那一行再取最大值往下接；问数据等别的进程接着跑的运行时回库里等封存；按配方导入的 AI 起草、知识库重建索引另取跨进程的锁（多进程时重建进度记在设置表里，别的进程读得到、属主不在了照实说没做完）；调度循环一拍的间隔可配（AGENTLAB_SCHEDULER_TICK_S）	2026-10-19 11:51:29 +08:00
ThearchyHelios	4548e8bd25	列表上「有几条在等」按任务各取各的上限（复核 L4）：等着的事件按任务、还没派发的事件按（事件种类, 对象）用 ROW_NUMBER 各取前 N 条（同改前每个任务各读的那么多），不再所有任务合起来一个上限——积压多的任务会把别的挤掉，它们的 due_at 为空、未派发数少算。补测试	2026-10-19 11:45:55 +08:00
ThearchyHelios	87f0d62f9b	多进程协调（W2-b）第一步：新增 app/cluster——工作进程在库里登记、心跳续租约（属主随进程，进程没了它认领的行一起到期），调度当班的租约，发给属主进程的停止 / 记事件请求，PostgreSQL 的 LISTEN/NOTIFY 叫醒，跨进程的互斥锁（咨询锁），SQLite 单进程守卫（第二个进程拒绝启动）；运行、问数据一轮、起草 / 剖析 / 探查 / 评测 / 影子起草、文档、发布单记 owner，启动整理改成只接手属主不在了的行，当班进程隔一会儿再接手一次；运行的并发名额改成库里按交互 / 应用 / 定时 / 系统四类发（各有全站上限和优先级，设置里可调），替掉进程内的信号量；同源队记在库里；运行停止、记事件跨进程交给属主；运行事件、问数据事件跨进程转发（库里按 seq 追，不落库的流式增量和保活心跳只转给在看的进程）；每日花费账先占住那一行再读写；访问密钥限流、登录失败计数在 PostgreSQL 时记在库里；登录设置、对外地址、向量模型、能力快照、数据源连接池、应用页面缓存跨进程失效；上传版本库、记录表、按需探查、出具、召回、补算、按需视图、个人刷新、定时发起的锁换成跨进程的锁	2026-10-19 11:40:33 +08:00
ThearchyHelios	358206312e	事件触发的规模：定时任务列表里每个事件触发任务「有几条在等」一次查齐（outbox.pending_for_many：待派发数一条 SQL 按任务分组算，窗口要看的事件一次读出），不再每行查一次；每一拍派发只读触发条件的事件种类、对象对得上的任务（SQLAlchemy 的通用 JSON 访问），保存时查环一层查一次、只顺着「上游工作流运行成功结束」的边找；选对象（trigger-options）按事件、关键字查、一页最多 100 个、more 说还有没有，当前选中的总在里面，编辑页一页没列完时多一个按名称查找。顺带修：等着的时候任务改了条件、最早那条不再合条件时，「什么时候合成触发」按剩下的最早一条算（列表上的时刻和真发起的一致）；一个窗口的结束时刻和这个任务已有的另一次触发撞在同一刻（别的期次早一拍发了）时往后挪，那几条事件照常发起，不再被记到已有的触发上	2026-10-19 09:46:47 +08:00
ThearchyHelios	edde451d19	问数据事件日志：助手的心跳不落库、已结束的轮次按期清理。心跳（模型几秒没出声时的 heartbeat 操作）是纯保活，以前每 3 秒落一条库；现在只在本进程里记最近的一拍（chat/log.beat），流上发一条不带 seq 的，重连时流先补最近的那一拍，之后落了任何事件就作废；页面照收不带 seq 的心跳、不动收到的最后一个 seq。其余事件照落（第 2 波跨进程从库里按 seq 追）。已结束（成功、失败、取消、中断）超过 14 天的轮次整轮删事件日志（chat/log.purge，挂在调度循环的那一拍里，一小时最多一次）：重开已结束的一轮读的是 conversation_turns 那一行，不读事件日志；任务行留着，seq 接着发号。README 数据位置写明	2026-10-19 09:34:14 +08:00
ThearchyHelios	17e99cd76c	驳回出口之后，待办、通知、Webhook 照实说转到哪：中断内容带上驳回之后去哪（engine/replay.reject_route：接了驳回出口写转到哪几步，没接的写运行就此结束，审批没接、没设驳回即终止的写这一路到此为止），待办卡的提示、驳回按钮、驳回后的提示、处理过的「结果」照它说，不再一律写「转入驳回分支」「本次运行终止」；超时驳回不再露出英文结论码；双盲裁决、动作确认被驳回的提示同样照它说。子工作流里的关卡走驳回出口时，名字记成「子工作流 › x」（RunContext.global_label），走过的那几步交回父图的 trail，父运行的终态事件照实带上途经驳回，实例页、通知写「「子工作流 › 把关」被驳回，转到「子工作流 › 退回」」，不写内部 id、不写成已完成。定时任务的 Webhook：照驳回那条路成功结束的，标题、状态写途经驳回，另起一行写谁被驳回、转到哪一步	2026-10-19 08:59:15 +08:00
ThearchyHelios	ea28f02eeb	子工作流里那一步结束了运行时各处同一个名字：新增 apps/resolve.end_label（终态事件上记的「子工作流 › x」），定时任务的 Webhook 不再在找不到节点时什么都不写、发布单不再写内部 id「sub/x」；补测试	2026-10-18 18:28:17 +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	a1ab3247f9	数据事件触发（后端）：待派发事件表、调度循环派发与去抖、防环、{{ event.* }} 模板变量、接口收 trigger_kind / trigger ... 做了什么： - 新表 trigger_events（待派发事件）、trigger_deliveries（一个事件派给一个定时任务、等去抖），放在 db/models_triggers.py， models.py 末尾整模块导入。事件在发生处、和那件事同一个事务里写一行：上传表格按期累积的新一期启用（table_versions 的 publish_build / publish_snapshot 切指针那一下，移除、作废、回滚不算）、正式运行成功收尾（runner._finalize 写终态的事务里 加两行调用 outbox.stage_run_finished）、探查 / 剖析新记了要处理的变化（source_changes.notify_after_job，一个任务一条）。 发生处不发起运行：事务边界、重复与重启都在派发这边说清，也为第 2 波多进程做准备（认领靠条件 UPDATE）。 - scheduler/outbox.py：调度循环每一拍（fire_due 之后）派发：pending 事件条件 UPDATE 认领成 routed，同一事务里给合条件、启用着的 事件触发任务写 delivery；窗口从最早一条的发生时刻起算 debounce_s（缺省 60 秒），过了就合成一次触发，内容取最新的那条， fire_at 取窗口结束的时刻（同一窗口永远同一个时刻，触发记录唯一约束兜住重复派发）；照 fire_once 发起正式运行，ScheduleFire kind=event、inputs 写 {event: 事件说明, inputs: 渲染出的输入}；上一次没结束记 skipped_overlap；派发太晚（超出补发宽限） 记 skipped_misfire；任务停用、改了触发条件时等着的标 dropped。AGENTLAB_SCHEDULER 关着时没有这一拍，事件留着，接口照实说。 - scheduler/triggers.py：三种事件的触发条件（table.version 可选只认新增的一期；workflow.finished 可选只认某个应用 / 某种来源； source.changed）、核对对象（表格是按期累积的上传表格、上游工作流已发布、应用在）、说法、{{ event.* }} 变量（table、version、 period、activated_at；workflow_id、run_id、outputs.<字段>；source、counts）、示例事件（预览、立即运行用对象最近一次真实的事件）、 防环：保存时查 workflow.finished 串成的环（停用的也算，A→B→A、自己触发自己都拒，422 写出经过的工作流），运行时按 origin 里的 触发深度兜底（超过 5 层记未能发起）。 - service：fire_once / _fire_workflow 接事件（模板按事件种类校验、渲染 {{ event.* }}，运行来源 origin.trigger 带种类、对象、 事件 id、深度、经过的运行和一句说法）；check_template / render_inputs / variables 加可选的 event 参数，cron 任务一字不变。 - api/schedules.py：收 trigger_kind（cron 缺省）/ trigger，event 时目标只能是工作流、cron 存空串、下一次触发为空；返回带 trigger_kind、trigger、trigger_text（也是 description_text）、trigger_state（几条事件在等、去抖到何时、调度开没开）；触发 历史带 event；预览按示例事件渲染；变量清单按事件种类给；新增 GET /api/schedules/trigger-options（各事件能选的对象及不能选的 原因、来源、应用，界面不自己判）；立即运行按示例事件发起；触发方式建好之后不能改。Webhook 照旧可配，通知写「事件触发」那一行。 - 应用页印章的来源（apps/resolve._from_text）照实写「由事件触发：…」。 为什么：总方案 §4 已拍板接这三种事件、不接口径发布，一套定时机制（X4）；派发放在调度循环里而不是发生处，事务和重复都说得清。 测试：test_schedule_events.py（三种事件各触发一次、去抖合并与窗口外另起、重叠跳过、停用 / 改条件丢弃、调度关着时事件留着、 超出宽限、触发链深度与上限、模板校验与渲染、期次写法、通知、印章）、test_schedule_events_api.py（建、核对、防环、改、预览、 变量、立即运行、触发状态、可选对象）；test_schedules_api.py 的约定键集合补上新加的几项。	2026-10-18 15:53:08 +08:00
ThearchyHelios	eb6e3c7ab7	合入 W3-d 邮件、待办汇总、分享链接：邮件渠道（SMTP 可选、口令加密、退信不追踪）；每天的待办汇总与访问密钥到期提醒；分享链接（只存哈希、必设到期、只显示定时出数的视图、/s 页不进外壳、下载报告）；「最近一次封存」按来源白名单认；使用者拿不到邮件渠道的收件地址；同站门户嵌整站的配置说明	2026-10-16 18:48:07 +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	91cc150f17	下一轮第 3 波的契约骨架：工作流版本加表的结构版本；定时的非工作流目标按种类交给各自的模块（评测题集 app/eval/scheduled、数据源维护 app/data/source_maintenance，先放照实记「还不能发起」的占位）、record_fire 共用；分享链接、数据源变化记录、口径账本按答案出具与对账的路由先登记好权限	2026-10-16 15:51:33 +08:00
ThearchyHelios	19329c873e	访问密钥与服务账号的后端（下一轮第 2 波 W2-d，细案 04 A1–A6、总方案 X8） ... 外部系统（门户、OA、BI）和个人脚本要用一个身份调接口，以前只能拿个人会话 cookie 去模拟。这次加访问密钥： - 签发（A1）：users.kind 区分人和服务账号（svc- 开头、没有口令、不能登录、角色固定使用者，管理员建）；access_keys 只存 sha256 和开头一截，明文 agl_ 加 32 字节随机串只显示一次；到期必填（最长 365 天、缺省 90 天）、可撤销、可轮换（新钥 + 旧钥 24 小时后到期）；个人访问密钥由管理员开关 auth.personal_keys 管，缺省关，关掉时已有的个人密钥一并不认 - 认人与门禁（A2）：Principal 加 via / key_id / key_name / scopes / app_ids（全部带默认值）；中间件认 Bearer agl_…，不看 cookie、不查 CSRF、不看 X-Actor，认不出的各回 401 带各自的 code、绝不退回匿名；WebSocket 带密钥一律拒；关登录时 409 keys_need_login。KEY_ROUTES（方法 + 路由模板 → scope）一张表，FastAPI(dependencies=[Depends(key_gate)]) 挂一次；不在表里的 403 key_route_forbidden，缺 scope、限定应用、个人应用和试运行各有各的 403；每把密钥每分钟 120 次（429 + Retry-After） - 封顶（A3）：按密钥认出来的一律是使用者（拥有者现在的组），现有的使用者规则和遮罩全部自动生效，管理员的密钥也一样 - 写操作（A4）：发起入口、刷新视图必须带 Idempotency-Key，api_receipts 按（拥有者, 键）去重，轮换后照样认得出；状态机从 process/hooks.py 抽到 process/receipts.py，钩子和密钥共用（钩子现有测试原样通过），另按请求指纹拒掉同一个键办另一件事； 有文件控件的入口 422；回复待办只给个人密钥、只限审批 / 补充输入 / 编辑稿件；run.origin、task.responded 记 via=key、哪把密钥 - 视图数据（A5）：GET /api/apps/{id}/views/{view}/data（agentlab.viewdata/1），印章、清单哈希、口径卡指标原值和渲染文字， 遮罩的 value 为 null（和页面同一个判断），按需视图只读缓存、不发起运行，只给正式运行 - 留痕（A6）：建 / 撤销 / 轮换密钥、建 / 停用服务账号、开关个人密钥写审计；请求记录进程内缓冲、调度循环一拍里批量写、 保留 90 天；last_used_at 至少隔 1 分钟写一次；钩子收件记录接口（manage），验签失败只在进程内按钩子计数 - 名录与派单：服务账号在名录里标出，岗位绑定、选人候选、提交审核、改派里排除，应用授权照收；服务账号发起的实例里派给发起人 的待办交给任何人 - 接口说明（A7）：GET /api/access-keys/reference 从 KEY_ROUTES 生成（要登录） 测试：签发与各种 401、门禁合约（遍历全站路由）、CSRF 与身份来源、封顶（管理员密钥取工件也是遮过的）、幂等（含轮换后、 半路杀进程）、留痕、待办种类、视图数据（真跑的遮罩会员库）、限流、钩子收件记录。	2026-10-16 13:48:09 +08:00
ThearchyHelios	3f5cf79b26	合入 W1-d 集成底座：安全响应头（frame-ancestors 缺省 self、白名单、script-src 先只上报）；对外访问地址只留一个设置（环境变量优先）；开登录时收起 /docs；集成接口的错误一律带机读码	2026-10-16 12:51:43 +08:00
ThearchyHelios	696cd17a4a	合入 W1-b 已知遗留：人工驳回记成已取消 + end_reason=rejected（不重试、不被出错时继续吞掉），各处照实写「被驳回」；个人渠道「我发起的实例完成 / 失败」生效；导入清单如实记「是否认证」；使用者选人按候选池、开登录时服务端核对；自由形蓝图按导入的图列「谁来做」；tick 按 id 断言	2026-10-16 12:51:43 +08:00
ThearchyHelios	d8034ca71a	对外访问地址只留一个：core/public_url.py 的 public_base_url()，通知、Webhook 链接、OIDC 回调、来源核对都改用它 ... 以前有两个「对外地址」：环境变量 AGENTLAB_PUBLIC_URL 只管 OIDC 回调和 Origin 核对，设置里 notify.public_base_url 只管 通知里的链接。只配了环境变量的部署，通知里不带链接；只在设置里填了的，回调又按请求的 Host 拼——违背「一种说法」。 - 新增 core/public_url.py：环境变量优先，其次设置（沿用 notify.public_base_url 这个键），都没有是 None。设置的值缓存在 进程里（中间件按请求核对来源，不能每次查库）：启动时 refresh 一次，PUT /api/settings 写完库就 remember，不用重启； 通知、定时任务 Webhook 手里本来就有会话，用 refresh 取，顺手按库里的值对齐缓存 - 地址的形状检查和规范化只有一份（url_problem / normalize），设置接口的中文报错和环境变量的启动校验都用它；环境变量 写错了（没有 http:// 或 https://、带 ? 或 #）启动时就报错，不再拼出坏的回调地址 - GET /api/settings 另给只读的 public_url 一组 {value, env_locked}，设置页据此显示「由环境变量指定」；环境变量设了时 PUT 把这一项改成别的值回 409（public_url_env_locked，field 指到这一项），原样写回不算改；public_url 一组写不进库 - notify/service 取地址的那一处、scheduler/webhook 链接里的地址、api/auth 的 OIDC 回调、auth/middleware 的 Origin 核对 都改走 public_base_url；deploy/agentlab.env 把这个变量的说法改成全站唯一的对外访问地址 测试 tests/test_public_url.py：先后顺序（环境变量 > 设置 > 无）、规范化、启动校验、PUT 刷新缓存、环境变量锁定（409、 不挡原样写回）、只配环境变量时通知带链接、OIDC 回调和 Origin 核对认设置里的地址。去掉修复回跑，只配环境变量的通知 链接、按设置核对 Origin 两条都会失败。设置页把它挪到「通用」在后面的前端提交里。	2026-10-16 10:18:12 +08:00
ThearchyHelios	845809486a	驳回不再记成失败（后端）：人的驳回收成 cancelled + end_reason=rejected，消费方都读这一个字段 ... 为什么：动作确认、工具 / 代码审批、审批驳回即终止、填写 / 编辑被驳回、双盲裁决的驳回以前抛普通 NodeError，运行记成 failed。 通知推「实例失败」，定时推「运行失败」，发布单把驳回过的试运行说成「试运行失败了」并挡住发布，记录页还给「继续运行」 （接着跑只会读到同一个驳回答复、再停一次）。人的决定被说成故障，每个消费方各写一份映射，已经漏了四处（05-已知遗留 (a)、总方案 X9）。 做了什么： - engine/context 新增 NodeRejected(NodeError)，带 node_id、kind、decision（reject / expired_reject）、actor、note；六处驳回改抛它， 原话一字不变。待办超时驳回的答复带 expired，Decision.expired 据此记成 expired_reject。 - runner._drive 在通用 except 之前单独接住：status=cancelled、end_reason=rejected、error 写原话、error_node 写那一步， run.cancelled 带 reason/node_id/label/kind/decision/actor/note；关审批、回收沙箱、关流、封存走取消的那一套。手动停止 （执行中取消、放弃断点上的运行）写 end_reason=stopped，run.cancelled 带 reason=stopped。 - 继续运行：被驳回的 409 code=run_rejected「被驳回的运行不能接着跑：改好内容后重新发起」；存量 failed+驳回（失败那一步上 最近一条处理完的待办是驳回，和实例页同一份判断 resolve.legacy_rejected）也拒。RunOut 带 end_reason。 - apps/resolve.instance_state：cancelled+rejected 和存量 failed+驳回说同一句（「「付款」未确认（被驳回）」「「x」被驳回」）。 - notify_run：状态那一句取自 instance_state，被驳回的走「实例结束」、ok=False，走到「已退回」成果的不再写「已完成」； 手动停止照旧不推。顺带修 04-对外集成与触达 B1：发起人是认证身份（run.origin.actor_verified）时 users 传 [started_by]， 个人渠道订阅了实例完成 / 失败终于收得到；自报署名不算。 - 定时 webhook：cancelled+rejected 按「运行结束」推「未出具（被驳回）」、写驳回的那一步，不写备注和原话、不画成功色； 手动停止仍不推。 - 发布单：试运行被驳回不算 plan.trial_failed，记 warning plan.trial_rejected「最近一次试运行在「x」被驳回、没有走完」（带白话）。 - (h) 重启时排队中的运行改成 failed 时补发 run.failed（同一句原因），时间线里有了失败原因这一行；不写结束时间、不封存，同以前。 - (f) tasks.tick / actions.tick 交回这一拍处理过的 id 列表（调度循环只记条数），测试改成只断言自己造的待办；先加了预置 一条无关到期待办的 fixture，旧的按条数断言当场失败（3 == 1），改完通过。 已封存的老运行不改写。测试：新增 test_run_rejected（五种关卡参数化、超时驳回、继续运行拒绝含存量、手动停止、补发 run.failed、 instance_state 新老形状同一句）、test_notify_run（驳回走实例结束、手动停止不推、已退回不写已完成、个人渠道 B1 两条）； webhook、发布单、动作确认、双盲、审批的老断言跟上。去掉 runner 里接 NodeRejected 的分支回跑，新测试 8 条失败。	2026-10-16 10:14:27 +08:00
ThearchyHelios	e3d0fe618c	定时目标的底座（总方案 X4，细案 01 做法 15）：定时只有一套，目标种类在 scheduler/service 里一处封装 ... - service.target_of / target_columns：读写目标只经这里。workflow 目标 target_id 同 workflow_id；非工作流目标 workflow_id 存空串（老表的非空约束，只加不改的迁移放宽不了），这条规矩不散到别处 - fire_once 按目标种类分派：工作流那段原样搬进 _fire_workflow（重叠跳过、渲染输入、记触发、发起一字不变）；这一波别的种类照实记「未能发起」并写明是哪类目标，不发起运行、不把空串当工作流去跑 - 建任务、PATCH 改工作流经 target_columns 一起写两列；存量任务（target_id 为空）照旧按 workflow_id 发起 - 接口和界面这一波不暴露新种类（第 3 波开放），返回的形状不变 - 新增 tests/test_schedule_target.py	2026-10-16 10:07:15 +08:00
ThearchyHelios	277982ead3	普通用户建应用（后端）： ... - 蓝图：bp_* 操作和逐卡白名单、蓝图检查、留痕、按蓝图判权限；五个场景模板加自由形（骨架、关节、应用骨架、定时任务），实例化与骨架比对；BlueprintApplier / TemplateApplier（只收模板声明过的关节）与自查；look 新类别口径卡；蓝图对话和填关节两个流式接口，不同组的关节并行填、出错的组串行重试；模板列表 - 试运行与发布单：四种起点（对话、模板、问数据的一轮、已发布版本）；试运行是探索运行，草稿应用按这次运行解析、印章写试运行，流程类派给自己、不触发升级；发布单九步、预检只读、每步留痕、停下后接着做、核对卡片指纹和应用管理权、启动时整理中断的单；白话层覆盖全部问题编号 - 记录表与文件：平台托管只追加的记录表、按高水位固定数据、连接上的临时视图做行级可见、写入走动作（records_append）、表版本在发布时切换、草稿不影响线上、记录列表遮敏感列；文件按哈希存、两步上传、提交时绑定运行、下载按读权限、清理、file_text、按配方导入一期（table_import_period） - 个人应用：存成个人应用（问数据的约束）、刷新（遮罩、只读、每日上限）、只有拥有者看得见、提交审核与共享副本、开关下发到认人接口；页面编辑的候选；隐藏组件不下发；三条新检查	2026-10-15 12:09:29 +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	acdc9677a8	应用平台 BE-2 流程：待办服务（派给谁、any/all/quorum 汇总、条件 UPDATE 抢恢复、提醒升级超时驳回、审批接口改为垫片、存量补建），人工节点新配置与校验，写外部系统的动作流程（生效记录先写后发、确认卡哈希、结果未知挂起与核实、永不自动重发），重放豁免与升级安全测试，正式运行不许带图接着跑、接着跑不覆盖发起人（F2），运行来源，通知发送核心与渠道，入站签名钩子，process.* 检查，报销审批模板，假外部系统（含统一复核后的修复）	2026-10-14 20:05:23 +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	544d44bdc2	运行对比的默认基准和定时任务的自动对比共用一个挑法：失败、取消的不当基准，按发起先后取上一次成功的运行 ... 运行详情「更多」里的「与上一次对比」原先走 default_base：任何终态都算、按结束时间排，上一次失败时拿失败的那次当基准； 触发历史里同名的入口用的是自动对比的 _previous（同一定时任务里成功结束并封存的最近一次、按发起先后）。两处拿到的基准 不同，计数也对不上。 - api/compare.py 新增 pick_base：比这次先发起的运行里成功结束并封存的最近一次，同时给出是不是紧挨着的上一次。定时任务 发起的先找同一定时任务，没有再退回同一工作流、同一运行类别（同样只挑成功的、按发起先后）；schedule_only 时不退 - default_base 与自动对比（scheduler/auto_compare.py，原 _previous 删掉）都调它；找不到基准的说明改成「上一次成功的运行」 - 测试：上一次失败、取消时默认基准跳过它们，和自动对比挑的是同一次；按发起先后而非结束时间（含停在审批上的这次）； 之前没有成功的运行时回 404	2026-10-06 11:56:31 +08:00
ThearchyHelios	45fe01effe	定时任务自动对比复核整改（后端）：只比成功的运行、按发起先后挑上一次成功的基准、和两边的封存绑定，对比挪到认领之前在锁外做并限时限并发；失败通知的处理行不再重复原因 ... - 只比成功结束的运行，基准也只取成功的：失败、取消的运行指标不全，和上一次比只会得出「移除 N 个」，拿失败的那次当 基准每个指标都成了「新增」。基准改成自己查同一定时任务、同一工作流、比这次先发起的运行里成功并封存的最近一次， 不再用对比接口的 default_base（按结束时间挑：老的失败运行事后被接着跑完，会拿后一次触发当它的「上一次」）。 中间隔着失败、取消的运行时，通知写「与上一次成功的运行（#短编号，日期）相比」，Fire.compare 多一个 previous - 和封存绑定：运行的封存要盖住最后一条结束事件才算封存完（sealed_now）。runner 先写终态、再另起会话封存，失败后 接着跑完的运行在两步之间还带着失败时的清单哈希，以前这一拍会直接认领、按旧封存比、通知里写旧的清单哈希；现在 等新的封存，等不来就照常推送但不比、不写哈希。停在审批上的通知也不再写失败时留下的哈希。对比工件连同两边的清单 哈希一起存，触发历史发现任何一边不在终态或清单哈希变了就给 null；对比途中封存变了不记（条件写） - 时机和时限：锁里只挑出状态有变化的触发，认领挪到对比之后、锁外按条件 UPDATE 做。对比最多等 20 秒（含排队）， 同一时刻最多 2 个；超时只记警告，通知不带对比照常推送。停机时扫描在对比途中被取消，这次触发还没认领，下次照常 比、照常推（以前先认领、后比，这条通知会永远丢掉）。同一份封存已经比过的直接用记下的结果 - 失败通知：从没开始执行的，原因刚写过，处理行不再让人「查看原因」，任务在排期上写「下一次触发会照常发起」，停用 的写怎么重新发起；开始执行过的改成「请在 AgentLab 的「记录」中查看失败原因」，和挂起那句指向同一个导航入口 - 新增 test_scheduler_compare_guards.py（封存绑定、时限、取消、并发、复用），test_scheduler_compare.py 补真实缺 指标的失败运行、上一次失败、补跑老运行几种用例；去掉实现逐项验证过会变红	2026-10-06 08:48:56 +08:00
ThearchyHelios	f8ac8dc1d6	定时任务自动对比收尾：基准那一次不在终态或被删时不给对比、对比工件读不出来时触发历史照常打开；检查脚本按实际底色量对比度 ... - 触发历史的 compare：以前只看这一次的运行在不在终态。基准那一次被强制删除、失败后被继续执行时，对比页比不了， 「对比上一次」链过去只会报错——基准一侧同样要在终态，否则给 null - 对比工件读不出来（权限、磁盘出错）时记一条警告、给 null：以前 OSError 直接抛出，整页触发历史回 500。被改过 （内容与哈希不符）的以前就给 null，这次补上用例 - check-schedules：页头的定时任务链接、触发历史的「对比上一次」改成量 WCAG 对比度（≥ 4.5），底色顺着祖先叠到 不透明为止。以前比的是「字色不等于页头的底色」，页头本身透明，那样比永远成立；深色也补上同样的检查。另加一项 署名的立即运行配长名字：署名照写、链接截断、页头不横向溢出	2026-10-06 07:43:01 +08:00
ThearchyHelios	f0f1b99ead	定时运行结束后自动和同一定时任务的上一次对比：结果存成工件记在触发记录上，触发历史和通知只给计数摘要与对比页链接 ... - 新增 app/scheduler/auto_compare.py：通知扫描认领到运行进入终态（结束、失败、取消）的那一次之后、推送之前， 调运行对比接口的现成函数（default_base、compare_runs，不改它们）比一次。基准只取 default_base 的「同一定时 任务」那一档，退回「同一工作流」的不比——那不是这个任务的上一次。没封存的不比；比不了（基准封存核对不一致等） 记警告、意外异常记堆栈，都不影响通知。整份结果存成 run_compare 工件，不挂在运行名下（不进运行的工件列表）， 工件 id 写进 ScheduleFire.compare_artifact；再次进入终态（失败后继续执行）时按新的封存重新比、覆盖旧结果 - 接口：Fire 多一个 compare: {base_run_id, summary}（summary 同对比接口的计数）或 null。运行现在不在终态 （被继续执行）、工件读不出来时为 null；工件摘要按 id 缓存（内容寻址，不会过期），读盘在线程里 - 通知：结束、失败的通知多一行「与上一次相比：只数据变 3 个、口径与数据都变 1 个、SQL 结构变 0 个」（三类总写， 其余各类有才写，两边都没有指标时不写一串 0 个），配了对外访问地址时附对比页链接（/runs/compare?target=…&base=…）， 四种格式都带；通用格式多一个 compare 字段。只给个数，不放任何具体数字 - 没配 Webhook 的任务也比：触发历史里要用	2026-10-05 18:45:59 +08:00
ThearchyHelios	d62f921ed4	定时任务遗留问题：失败通知不再许诺能继续运行、30 天前的触发停在审批上照样推送、调度循环测试不再依赖整分边界 ... - 失败通知的「处理」行改成中性的「请在 AgentLab 的运行记录中查看原因」：服务重启时还在排队、从没开始执行的运行 没有断点，「修正后可继续运行」是错的；开始执行过的也可能续不了（执行第一个节点前就失败、系统升级后断点不兼容）， 能不能继续以记录页为准。没有开始时间的失败另写一行原因（没有可继续的进度），通用格式的 reason 字段同写；任务 还在排期上时补「下一次触发会照常发起」，和挂起（之后的触发都跳过）说清区别 - 通知扫描的 30 天窗口加两种例外：停在审批、有待审批的运行不受限制（创建 30 天以后才停到审批上的以前收不到 「等待审批」）；运行记录 30 天内有过变化的照扫（等了一个多月的审批批完、跑完，以前收不到「运行结束」）。早就 结束、多日没有变化的旧触发仍不扫 - test_loop_ticks_until_stopped 改成只看「发起了」和停下前后的条数差：建任务和第一拍之间跨过整分时会先记一条 错过的跳过，以前按总条数断言偶发失败。加一组把下一次放在上一个整分的用例，必然走到跨整分这一支	2026-10-05 18:39:10 +08:00
ThearchyHelios	a9d7cba884	定时任务复核修正（第 1 轮）：重启挂起的运行不再让任务静默停摆，格式选错、地址发不出去时照实报，整份回写不再丢掉到点的触发 ... - 挂起：上一次运行在服务重启时被挂起（interrupted、没有待审批）不会自己接着执行，之后每次触发都按重叠跳过，原因写 「还没有结束」，一条通知也不推，任务就此静默停摆。interrupted 照规格仍算没结束，但跳过原因按挡路的运行分三种写 （仍在进行中、正在等待审批、已挂起并请在「记录」中继续运行或放弃），运行编号写成界面上的 #前 6 位，去掉「按设置」； 挂起的那次按 failed 事件推一次，写明原因和处理办法，不是每次触发都推。停在审批时每停一个审批点推一次（已处理状态 带上第几段执行，以前第二个审批点不再推）；审批刚批完、还没接着执行（answered）不当挂起 - 没有结束时间的失败运行（服务重启时还在排队、被改成 failed）永远不会封存：等封存改按最后更新时间算，以前按「现在」 等，每一拍都等、永远不推 - 平台错误码按地址的主机认，不看所选格式：格式和地址对不上时，测试显示「已送达」、正式推送记成功，群里却收不到； 现在记失败并带上平台的错误码。群机器人的地址（飞书、企业微信、钉钉）保存时要配它平台的格式，否则 422；格式省略时 按地址认。只在地址或格式真改了时查，库里已有的旧设置不挡停用、改名 - 地址校验：端口不是 1 到 65535 的数字、夹着空格或不可见字符（零宽空格、控制字符）、httpx 建不了请求的（主机名不合 IDNA 规则）保存时就回 422 和中文说明；推送时另兜住 InvalidURL 和其他异常，测试接口不再回 500 或英文报错；端口写错 的地址也照样取出主机名 - PATCH 看值变没变，不看键在不在：整份表单回写不再重新校验没改的工作流（工作流删了也能停用），cron、时区、启用状态 真改了才重算下一次触发。启用着改 cron、时区时，从原来那个到点的时刻接着算，新表达式也覆盖那一刻就还发起这一次。 补两人同时保存的测试，证明条件 UPDATE 守住了乐观锁 - 发起中的占位：接口读到正在发起的触发按「已发起」给（run_id 为空），不再闪一次「未能发起：服务在发起运行前停止」； 库里仍先写占位，进程被强杀时照实说没有发起 - stop：先置停止标志再取任务，这一拍收尾不再新起通知扫描（以前会落下一个不在等待名单里的通知任务）；循环和通知两件 事并行等，宽限缩到 3 秒和 1.5 秒，给关停时的 run_manager.shutdown 留出 docker stop 的大半时间 - 通知正文：立即运行写「手动触发」，补发标明「错过后补发」；失败不再写「原因：运行失败，详情请查看运行记录」，改写 失败节点的名字和处理办法；状态叫法和界面一致（等待审批，已挂起，可继续运行）；「封存哈希」改叫「清单哈希」，运行 编号写 #前 6 位；测试消息只说收到它证明得了的事（企业微信、没配密钥时不提签名）。测试接口的 message 改成 ok、 http_status 之外的补充说明（送达时提醒去接收端确认，失败时是原因），前端接在「测试消息已送达（HTTP 200）」后面不再重复 - 422 文案：不回显 Python 的值（None 写「未填写」，列表不原样回显、点出不认识的那一项），格式、事件写中文名； copy-allow.json 为平台名「钉钉」加一条（和前端包为 terms.ts 加的那条并存，试合并不冲突） - test_loop_ticks_until_stopped：下一次放在整分上、只认发起的那一条，去掉约 1/60 的偶发失败 - 逐个做过变异，改回后对应测试都变红：挂起不推、跳过原因退回旧写法、没结束时间按现在等、错误码只看格式、去掉版本 条件、到点保留和值比较一起去掉、不屏蔽发起中的触发、stop 既不查停止标志也不兜底、answered 当挂起、审批状态不带段号、 不建请求校验地址、保存时不查格式	2026-10-05 10:00:25 +08:00
ThearchyHelios	b66eb955b5	定时任务小修：数字按 isdecimal 认，输入生成失败的原因不再说成模板写错 ... - 「²」这类字符 isdigit 为真、int() 却认不得：写进 cron 或每页条数时会冒出英文的 ValueError（被全局处理器 回成 400）。改按 isdecimal 认，照常回中文的 422 - 库里的 cron 或时区后来坏了时，立即运行记下的原因以前写「输入模板无法渲染」，其实模板没错：改成照实说 「无法生成这次运行的输入」，后面跟是哪一项	2026-10-05 08:50:57 +08:00
ThearchyHelios	bb176f6f9d	定时任务小修：输入模板的字段名去掉首尾空白再存，后台通知任务的异常记日志 ... - 「 stat_date」原样交给运行，入口节点认不出它、必填项照样报缺：保存时去掉首尾空白，去掉后重名的拦下 - 通知扫描是另起的后台任务、没人 await：出错时异常留在任务里，只会在回收时冒出一句「从未取回的异常」。 包一层，出错记日志，下一拍照常	2026-10-05 08:47:18 +08:00
ThearchyHelios	a2a19df9df	定时任务后台：三张表、输入模板、调度循环和 Webhook 推送，设置加「通知」一组 ... - 表：schedules（Webhook 地址和签名密钥加密存放、next_run_at 存 UTC、version 乐观锁）、schedule_fires（(任务, fire_at, kind) 唯一）、webhook_deliveries；新表由 create_all 建，不用迁移 - 输入模板：{{ schedule.yesterday }} 这类变量按计划触发时间在任务时区算（不按「现在」：补发晚了、零点前后立即 运行，「昨天」都是那次触发的昨天），上一次计划触发时间按 cron 往前找，同一次触发永远渲染出同一份输入；未知 变量、未知过滤器、{{ }} 不成对都拦下，声明了入口字段的工作流还对照字段名和必填项 - 调度循环：每 15 秒一拍，条件 UPDATE 认领到点的任务并推进到下一次，两拍并发只有一拍认领得到，触发记录的唯一 约束是第二道保险；上一次运行没结束（含停在审批、服务重启挂起的）记跳过；错过的只看最近一次，在宽限内补一次、 超出记跳过，积压不补；发起走 launch_run，拒绝的原话记成未能发起，别的异常记通用说明、详情进日志；stop 等手上 这一拍收尾，开关关着时 start 不起循环 - Webhook：通用 JSON（可选 HMAC 签名头）、飞书文本、企业微信 markdown、钉钉 markdown，按各平台算法签名；运行 结束、失败、确有待审批时按订阅推一次，结束的等封存好再推，没订阅、没配 Webhook 的也记下已处理，之后配上不会 补推旧的；10 秒超时、失败重试 3 次（4xx 不重试），每次推送记一条记录；通知里没有报告数字和原始报错，日志和 错误里只有主机名（httpx 自己的请求日志也换成主机名） - 设置 notify.public_base_url：通知里的运行链接 = 它 + /runs/{id}，只收 http(s) 地址，末尾的 / 去掉	2026-10-05 08:37:57 +08:00
ThearchyHelios	b51a686f53	定时任务 cron：自写五字段解析、下次 / 上次触发和中文描述，不加依赖 ... - 分 时 日 月 周五个字段，支持 *、列表、范围、步长和月份 / 星期的英文缩写，周日写 0 或 7；日、周都受限时取 「或」，有一边以 * 开头就只看另一边（和 Linux 系统的 cron 一致，同一个表达式在这里和服务器上意思相同） - 按任务时区的墙上时间匹配：夏令时跳过的本地时间那天不触发，拨回时重复的本地时间只在第一次出现时触发一次 - 写错的表达式给中文说明（哪个字段、允许的范围），所写日期在所写月份里不存在的（2 月 30 日）直接拦下 - 描述覆盖每天、每周、每月、每年、每 N 小时 / 分钟这些常见写法，说不清的写「按 cron 表达式 x」，后面带时区 - 时区名对照时区库换成规范名：不区分大小写的文件系统上 asia/shanghai 也打得开，换到 Linux 就打不开了	2026-10-05 08:27:35 +08:00
ThearchyHelios	a3058e7df8	复核套件骨架（后端）：先把后续几个工作包要用的位置占好，各包只改自己的文件。节点类型加双盲复算 dual_check、反方审稿 challenge，执行器是占位（记一条 info 日志后跳过，产出 skipped 和原因），校验按普通节点走，叫法进 labels，暂不写进助手的节点说明。出具契约留一个通用口子：成果节点上游任何节点产出里的 issuance_gaps（字符串列表）收进缺口，前面加上「节点类型「节点名」：」，出具随之降档、不会升档；只认这个成果的上游，写坏的条目跳过。路由先登记 schedules、compare、bundle、inquiry、whatif 五个空前缀，挂在 /api/runs 下的四个排在 runs.router 之前，以后加固定路径不会被 /{run_id} 吃掉。定时任务的调度先放空的 start / stop，AGENTLAB_SCHEDULER 默认开、0 / false / off 关，写进设置；启动时开着才 start，测试环境默认关	2026-10-04 23:40:20 +08:00