310 Commits

Author	SHA1	Message	Date
ThearchyHelios	a86991b57f	双盲复算：盲算触顶、按无法复算记时（_limit_text 那一路），把盲算交回的理由（渲染后的正文，已经过遮罩）截一段带进原因（「盲算已达每项最多查询次数（1 次）；盲算交回的理由：…」），审批卡、缺口说明上看得到它查到了什么，没有理由的照旧。原值所在的格子落在「查询区间里这张表没有数据」的列上时不派盲算、按无法复算记；盲算交回的格子落在这样的列上时不判一致、按无法复算记；原因都写「查询区间里这张表没有数据（…）」	2026-10-20 10:33:34 +08:00
ThearchyHelios	6fa2e297db	口径卡、报告、出具、复核认「查询区间里这张表没有数据」：口径卡按输入的快照 id + 列认（cell()、按位置取的格、Agent 经 cite_fields 交来的字段，按列，同一条查询里有数的列不受影响；转抄的指标照抄），给指标标 no_data 并写明原因，清单注明「这段时间表里没有数据：不要当成 0 解读」，发一条 metric_no_data；有出具契约的成果按缺口降档（契约收来的指标，和报告直接引用的这样的格）。写作目录里这样的指标、查询格子里这样的列都写清，写作规则加一句（目录里有这样的项才加）。证据面板的指标标「区间内无数据」并写明原因，查询步骤列出这几列。复核把 query_no_data、metric_no_data 记成缺口（DEGRADED），归进新的 REBUILD：是缺口、却值得换一张有这段数据的表重建一次，should_retry 和 chat/turn.retry_after_review 都认，问数据据此给出「按复核重来」的指示	2026-10-20 10:29:01 +08:00
ThearchyHelios	301bbd55f3	口径卡分母为 0 时算不出来就是空值，和「缺少输入」分开说；指标清单按格式渲染。助手节点手册讲口径卡的那段写明分母可能为 0 时写「… if 分母 else None」、不要写 else 0，附示例；画布校验加一条提醒 metrics.zero_for_undefined（按语法树认：条件表达式一边有除法、另一边是常量 0，两边对调、套在 round 里、嵌套的都认）。输入都齐、计算式自己交回空值的指标多记 undefined: true（状态仍是 missing_input，按状态认的地方和老运行不受影响），清单、写作目录、引用解析不了的原因、运行对比、证据面板都说「算不出来（这组输入下计算式没有值，比如分母为 0）」；推演把它当不带值的字段。指标清单（{{ nodes.卡.text }}）改用卡上渲染好的 rendered：比率 0.0007 显示成 0.07%、金额带千分位，和报告里 [[m:]] 一致；有值却显示不出来的照实说，不拼原值	2026-10-20 10:04:53 +08:00
ThearchyHelios	6b68961c65	助手把操作写成工具调用格式时照操作读；一个能落地的操作都没有时当场纠正一次；报错按诊断照实说 ... 部署上画布助手连着几轮报「助手本轮未完成：模型没有给出任何修改，也没有说明原因」，又试了一次才成。本地用同一网关、同一模型、同一底图和需求重放复现：模型思考里写着「先输出 look」，正文却是一段 DeepSeek 的 DSML 工具调用（invoke name="look"，参数 need、targets），意图和参数都对，只是不是约定的单行 JSON。读流只认 JSON 和原生工具调用，于是一个操作都没认出、整轮报错；画布不处理 next=retry，点重试原样再发，几率不变。提示词里「输出这一行就停下，系统把结果交回来」很像工具调用，却从没说这里没有工具调用接口。 - engine/toolcalls：take_leaked_calls 读写成文字的工具调用（DSML 竖线一到两个、带不带空格，<function_calls><invoke>，<tool_call>{name, arguments}，DeepSeek 特殊 token 两种排法），按出现先后交出已写完的调用和没写完的那一段；final 时参数写完整、只差结尾的补上结尾再读，写到一半的不硬读。_MARKUP 补认 DSML 结尾标签和 function_calls / tool_calls 包装（agent 节点的识别跟着受益）。has_markup 只认标记本身 - copilot_gen._iter_ops：从有标记的那一行起攒，一次调用写完就按名字读成操作（名字是操作名的才认，规矩同原生工具调用 _call_op；op 写在最前，接着写时交回模型的是约定写法），读到 look 照样停下去查看；读不出的记「工具调用标记的名字不认识 / 参数解析不了 / 没写完」；raw 交出正文开头一段 - Generation：起草时一次调用读完、到这时还没有能落地的操作（plan、look 不算——查看完接着写什么都没认出的整轮照样是空的），把原话交回去、附 StreamDiagnosis.correction 那句纠正，当场重写一次（FORMAT_NUDGE_PROMPT，每轮一次）；什么都没写的把纠正接在最后那条消息后面。诊断按次收（absorb），记 nudged。写成标记被读出、当场纠正都打 info 日志 - 报错说法：Generation.empty 默认用 StreamDiagnosis.headline（写成工具调用格式 / 只写了思考 / 什么都没有输出 / 格式不对 / 只说了打算），不再一律「也没有说明原因」；摘要注明当场纠正过 - 提示词：look 用法（四个入口共用）和画布、应用、蓝图的输出格式都写明这里没有工具调用接口 - 问数据失败原因 meta.cause（kind=copilot）带上 code、diagnostics 验证：本地真模型重放，修后 DSML 没再出现、都正常交付；把第一次调用换成读不出的 DSML 后交给真模型，都被当场纠正救回来（先 look 再出操作）；原先抓到的真实 DSML 原文离线读成 look。测试：新增 tests/test_copilot_markup_ops.py（各写法、流式切碎、和 JSON 行混写、读不出的诊断、DSML look 驱动真查看、说明文字 / 只写思考 / 只写 plan / 查看后空续写的纠正、只纠正一次、画布流不报错、报错说法、提示词）；空生成相关的旧测试按「一次生成先纠正一次」更新（基线夹具 no_ops 的说法）。后端全量通过。	2026-10-19 22:48:23 +08:00
ThearchyHelios	d6c22440df	名字里的数字涂白（_name_masks）先按数字串挡一道：名字一字不差出现、前后不紧挨着数字时，名字里的每一串数字在正文里都是完整的一串，正文里没有这串数字的名字不再逐个查找，快照行多时不拖慢组装和复核；放过的范围不变	2026-10-19 17:55:02 +08:00
ThearchyHelios	a92f590799	字段标记紧跟在同一张表名后面时只显示字段名（部署上的「取自 某表 的 某表.某列」）：[[c:表.列]] 前面紧挨着（隔空白、「的」「中的」「里的」）刚写过同一张表的名字——写成文字或 [[t:同一张表]] 都算，按 name_key 比，带库名的全名、末段都认，英文名前面还连着字母的不算——正文只显示列名，出处、证据标识照旧是那个字段，引用上记 short: true，复核照它核对显示的字；没有这一项的老文档照旧按全名核对。整篇组装、render_markers、流式渲染一致（流式渲染记着已放出正文的末尾一截）。写作规则（ENTITY_RULES）写一句	2026-10-19 17:55:02 +08:00
ThearchyHelios	ba4c604539	数字标记后面重复写的单字单位也去掉（部署上的「覆盖 8条 条产线」）：以前单字的单位后面紧跟着字时一律不动，现在只在它和后面的字连起来是一个更长的单位（人次、个月、台套、元/…，_LONGER_UNIT）时不动，让「人」对「人次」这样的不一致照旧露出来；「条产线」「人参加」照样去掉重复的那个字，流式渲染一致。写作规则加一条 UNIT_RULE（[[m:]]、[[v:]] 自带单位，后面不要再写一遍），助手节点手册讲 [[m:]] 的那一行也写明	2026-10-19 17:55:02 +08:00
ThearchyHelios	e9bb0afd4c	报告里标识列的数不分千位（产线编码 1203 不再写成「1,203」）：新增 engine/cell_format.plain_columns，按序看查询当时冻结的数据目录给源列标的度量类型（identifier / status / attribute 不分，flow / stock / ratio 分）、源列名像编码编号（CODE、ID、NO 整词或结尾、驼峰的 Id/No/Code、编码、编号、代码）、是分组键（列、别名、序号都认）而不是聚合；SUM、COUNT、AVG 这类聚合是量，MIN、MAX 按那一列判；判断不了的照旧分千位。只看查询快照和它指向的表结构快照（内容寻址），组装、流式渲染、写作目录、出口复核一致。单元格显示规则 3 版：真有格子因此改了写法的文档记 cell_display: 3、引用上记 plain；离线核对页认 3 版、照 plain 渲染（解析不了 SQL），老文档按记下的版本复核照旧分千位。样本里订单号（order_no）随之不分组，check-bundle 跟着改	2026-10-19 17:55:02 +08:00
ThearchyHelios	baf93ddfed	报告里照抄查询结果中文本格的名字（「冲压5线」「KX-205 线」）时，名字里的数字不再算裸数字：目录里每次查询的快照中、文本格里带数字的值（至少一个数字、至少一个不是数字的字，本身不是数也不是带单位的数），在正文里一字不差地出现、前后不紧挨着数字的那几段，查裸数字时涂白。组装和出口复核用同一条规则；只认快照里真有的值，不做模糊匹配，同一个数单独写出来照样要出处，数值格不受影响	2026-10-19 17:06:08 +08:00
ThearchyHelios	8f6a90c8c2	整表标记 rows= 的结束行越界、起始行在范围内时截到最后一行（不加注），只有起始行越界才算解析不了；行数上限按截完的行数算。单元格显示规则升到 3 版：截行只影响组装（截完照样展开成一格格的单元格引用、按格复核），复核 3 版以前的文档时没展开的整表标记照老规矩判，老文档里那句「没有第 N 行」不会被当成文档被改过。文档的 cell_display 改记渲染得出这些格子的最低一版（只有日期时间被改写的照旧记 2，离线核对页不受影响）	2026-10-19 17:00:32 +08:00
ThearchyHelios	41b350b87c	相对日期一律按运行当天算：助手节点手册的搭图规则（画布、问数据共用）加第 6 条——「今天、昨天、上周、本月、去年」按运行当天算，SQL 用方言里取当天的写法、agent 先调 current_time，不用 MAX(日期) 去推「上周」，要说数据最新到哪天就另取一列；报告写作规则加一条（period_rule），告诉写作者今天是哪天、上周是哪几天：数据没覆盖问的那段时间时先照实说、写明数据最新到哪天，最近一段的数可以给但写具体起止日期，不叫它「上周」「本月」	2026-10-19 16:53:46 +08:00
ThearchyHelios	5dfe2e7fd1	report.failed_queries 不再把「写错一条、下一条就改对了」当取数失败：同一个节点里，失败之后还有一条同一数据源的成功平台查询、读的表覆盖了失败那条的表（按 sql_semantics.facets 取表；失败那条解析不了就按同一数据源之后有成功的查询认），这次失败算已被替代，不进写作提示、不记 report_queries_failed；一次成功的都没有时照旧写「这次一次成功的查询都没有」	2026-10-19 16:47:07 +08:00
ThearchyHelios	1e87504e5c	复核把「首稿没过、重写后已通过」当缺口：report_repair、report_rewrite 这类「改过一次」的信号按同一个报告节点最后一次 report.checked 定档——最终通过的（没有违规；裁判摘要里不再有证据不支持的句子）不进复核的异常清单，复核模型被别的信号叫起来时，说明里另起一节「已经处理好的」写「报告「x」首稿有 N 处没过核对，重写后已全部通过」，不再写成「核对仍未全部通过、可能不准」；最终没过的照旧记缺口。report_repair、report_rewrite 的日志带上处数	2026-10-19 16:43:54 +08:00
ThearchyHelios	c0f7aae8ad	复核 R-b15（隔离后等不到重新登记的运行原因记错、任务没摘）：_drive 里 fence.ready() 等不到时照实收尾——排队中的（一步都没执行过）收成失败，写明「本进程隔离后没能重新登记，这次运行没有开始执行」并记 run.failed；要接着执行的（继续、批了审批）收成中断、断点完好可继续运行；条件更新，状态、属主变了（别的进程先接手）就不动；执行任务从 run_manager._tasks 里摘掉。补测试：隔离后新身份一直没登记上，新发起的运行收成失败、原因写对、run.failed 记下、任务摘掉	2026-10-19 15:08:39 +08:00
ThearchyHelios	1e6f0554fe	复核 R-b10（隔离换身份后旧身份的名额、请求没人收拾）：要名额时把当时的身份记在 holder 上，放的时候按它删，换了身份也删得到；新身份登记上之后收拾旧身份（tidy_retired）——它的执行都已停下、写不了了，不必等它的租约过期：删掉它的登记（发 gone，别的进程马上按属主不在了接手它认领的运行、任务）、它占着的运行名额和同源队的位置，交出它拿着的当班租约，发给它的请求转到新身份名下照办，照实记一条日志；停止请求对不在本进程执行的运行也照停止的规矩办（cancel 自己看属主：转给正在执行它的进程、属主不在了就接手放弃、停在断点上的收成 cancelled）。补测试：拿着名额时换了身份照样放得掉（改前的写法这条不过）；新身份登记上之后旧身份的登记、名额、队里的位置、当班租约都收拾掉，转过来的停止请求把停在断点上的那次运行收成 cancelled	2026-10-19 14:36:19 +08:00
ThearchyHelios	ba22b82b3d	复核 R-b9（Fenced 打到不该打的地方）：check() 续晚了谁问到都隔离，但只对绑定了世代的执行（运行的一段执行、后台任务）抛 Fenced，HTTP 处理、调度那一拍、进程间请求问到时只隔离不抛；调度循环、心跳、办进程间请求也接住 Fenced；续租的任务不再因为一下出错就退出——续租、隔离之后重新登记都包住，照实记日志、退避着重试（最长一个租约时长）。隔离时马上换身份（之后新建的行记新身份），新身份登记上之前心跳不争当班、不接手，新开始的运行、后台任务在 fence.ready() 上等（最多一个租约时长，等不到就不开始，那几行由别的进程按属主不在了处理，这边同时放弃这个一直没登记上的身份、再换一个）。日志写出新旧完整身份。补测试：没绑定的调用者只隔离不抛、绑定在隔离之前的抛、新身份登记上之前 ready 等着；调度循环被 Fenced 打到一拍之后照常；重新登记先被版本守卫拦、再碰上库连不上，续租任务都不退出，登记上之后照常续租	2026-10-19 14:33:45 +08:00
ThearchyHelios	d6ecaaa7a3	复核 R-b8（隔离时 asyncio 记一条回调异常）：断点写入的守卫改成协程包装、在协程里查 fence——LangGraph 在节点的完成回调里调 aput_writes 拿协程交给后台任务，以前同步包装在回调里就抛 Fenced，每次隔离都打一条「Exception in callback … FuturesDict.on_done」加 traceback；现在异常留在写断点的那个任务里，由 LangGraph 照常收走。补测试：卡住被接手那一条里 asyncio 不记回调异常、不记没人取的任务异常（改前的写法这条不过）	2026-10-19 14:29:12 +08:00
ThearchyHelios	35ab097b45	复核 R-b1（卡住但没死的进程被当成没了）：续租约挪到单独的任务、专用连接（不走连接池，不被同一拍别的活拖住）；进程间请求另起任务办，不在心跳里等收尾；新增 cluster/fence 自我隔离——离上次续上租约超过一个租约时长，或者这段执行属于上一次隔离之前，执行在写事件、写断点、开审批、发外部写入、后台任务写库之前就停手（Fenced 是 BaseException，节点里的 except Exception 拦不住），续租时发现续晚了就隔离：停掉手上的运行和后台任务、不写终态，换一个身份重新登记；运行收尾先占住那一行、属主不是自己就不写；别的进程按租约过期再多等一个租约时长才算不在了（两边中间留一段）；run_events 的 (run_id, seq) 改成唯一索引（存量库先数重复，有就照实记日志、这一次不建，不让启动失败）。补测试：卡住期间被接手之后不盖终态、不写事件、序号不重；被接手的那次在别处接着跑完只结束一次、后面那一步只跑一次；收尾按属主写；撞号被库拒绝；多进程端到端加 6b、6c（真 SIGSTOP / SIGCONT）	2026-10-19 13:15:56 +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	0e997eb968	copy-to-postgres 在真实开发数据上核对不过的几处（复核 R-a1、R-a2、R-a3、R-a8、R-a13） ... - R-a1 老库 NOT NULL 列为空：第一版补 schedules.trigger 时没带缺省值，存量定时任务这一列是 NULL，导入 PostgreSQL 撞 NOT NULL，连带触发记录、通知撞外键。迁移表里这一列改成带 DEFAULT '{}'；新增 _NOT_NULL_BACKFILLS，启动时按模型的缺省值把已经补过、留着 NULL 的填上（SQLite 这边也填，两种库存的一样；只更新这一列，不碰 updated_at）；导入时 _Fixer 遇到 NOT NULL、有缺省值的列的 NULL 也填缺省值，计入「转换」。迁移表里的 NOT NULL 列都过了一遍，只有这一列没带缺省值 - R-a2 孤儿行：导入前在快照上按模型外键扫（settle_orphans）：外键是 SET NULL、列可空的置空，计入转换；CASCADE / 不可空的从快照里拿掉、不导入，反复扫到没有为止，报告里单列「孤儿行（SQLite 当时没强制外键）」的表和条数，不算核对失败 - R-a3 停服务后 agentlab.db-wal 还在：lifespan 收尾 dispose 应用库引擎（只加了这几行），SQLite 最后一个连接关掉时并回、删掉 -wal，PostgreSQL 的池子也正常关 - R-a8 自增主键的序列取「目标表 MAX、快照 sqlite_sequence 的计数器、序列现值」三者最大，删过的号不复用（召回按 source_changes.seq 当游标） - R-a13 插不进的行的原因不再带「<class 'asyncpg.exceptions.…'>:」前缀（errors.first_line 两种写法都去）；设了 AGENTLAB_DATABASE_URL 却没装 [postgres] 时，应用库引擎和断点库都直接说要装什么 - 测试：DROP COLUMN 再按第一版迁移补回造老表、关着外键写孤儿行，迁移填值、快照上置空和拿掉、导入 PostgreSQL 核对通过且重跑一样；NULL 落回模型缺省值；端到端里删掉最后一条变化，导过去新变化从 3 编起；起停一次服务后数据目录里没有 -wal / -shm（去掉 dispose 这条测试就挂） - PostgreSQL 引擎上另挂了去掉文本参数里 NUL 的钩子（db/postgres.strip_nul，见下一个提交）	2026-10-19 12:06:31 +08:00
ThearchyHelios	ae254b052e	合入遗留收口分支 nr8/l 的复核修复（变化记录先占住那一行再读改写、召回里行序不定的指标、事件触发列表按任务各取上限、选对象按名字查用 ilike、子工作流写入认旧键、几处测试的竞态） ... # Conflicts: # backend/app/ledger/recall.py	2026-10-19 12:05:19 +08:00
ThearchyHelios	1acf960312	多进程端到端验收：scripts/test-multiprocess.sh 用本机 postgres:16 起临时库，tests/test_multiprocess_e2e.py（缺省跳过，AGENTLAB_MULTIPROCESS_E2E=1）在上面起两个 uvicorn 工作进程，用演示模型跑七个场景——两个进程都登记、一个当班；运行由接到请求的进程认领，另一个进程上的流收得到实时事件和流式增量，同一个审批决定同时发给两边只执行一次，两边事件流不重不漏、封存核对得上；跨进程停止；定时只触发一次；全站一个名额时评测的作答运行排着队，后来的问数据运行先拿到名额；两个进程同时记同一本每日账不越过上限；强杀一个进程后在跑的运行被照实标中断、停在审批上的照常在另一个进程上批完、当班交接。顺带修：等名额时被停止也照实收成已取消（以前停在排队中）；当班的本地余量不超过租约的四分之一（租约调短时一直不当班）；启动清理上传半成品时没有别的活着的进程就全清；文件锁守卫的几项测试只在 SQLite 跑；问数据事件日志清理那一拍不带时刻时按现在算	2026-10-19 12:03:35 +08:00
ThearchyHelios	c768c56fd7	多进程协调补齐几处：执行时长从拿到名额算起（排队等名额不算执行，墙钟本来就从开始执行算）；蓝图留痕、蓝图助手开轮先占住那一行再取最大值往下接；问数据等别的进程接着跑的运行时回库里等封存；按配方导入的 AI 起草、知识库重建索引另取跨进程的锁（多进程时重建进度记在设置表里，别的进程读得到、属主不在了照实说没做完）；调度循环一拍的间隔可配（AGENTLAB_SCHEDULER_TICK_S）	2026-10-19 11:51:29 +08:00
ThearchyHelios	c59b085922	子工作流里的写入跨升级认旧键时按事件和内容认是谁的、是哪一笔（复核 L1、L2）：升级前子图里的写入按子图里的 id 记键，和父图同名节点的键一样。以前父图有同名节点时一律不认旧键：子图里结果未知的那一笔核实为已生效后接着跑，用新键又发一笔；父图那个节点按自己的键找到子图那一笔、交回它的回执，自己那笔一直发不出去。现在一条记录是哪个节点写的按它的 action.* 事件上记的节点 id 认（认不出的按能力和内容指纹）：按自己的键找到别人那一笔的换一个只属于自己的键；认旧键时还要内容指纹是这一次的——跨升级的循环第二轮按老算法同样是第 1 次执行，找到的是第一轮那一笔，金额不同就照常发，不再记「已经生效」。去掉不再用的最外层节点 id 传递；改对两处过时的说明（审批恢复时子图从自己的断点接着跑；终态事件的途经驳回含子工作流里的）。补跨版本测试：同一个进程里先装成升级前的代码跑到挂起、再换回现在的代码接着跑	2026-10-19 11:43:41 +08:00
ThearchyHelios	87f0d62f9b	多进程协调（W2-b）第一步：新增 app/cluster——工作进程在库里登记、心跳续租约（属主随进程，进程没了它认领的行一起到期），调度当班的租约，发给属主进程的停止 / 记事件请求，PostgreSQL 的 LISTEN/NOTIFY 叫醒，跨进程的互斥锁（咨询锁），SQLite 单进程守卫（第二个进程拒绝启动）；运行、问数据一轮、起草 / 剖析 / 探查 / 评测 / 影子起草、文档、发布单记 owner，启动整理改成只接手属主不在了的行，当班进程隔一会儿再接手一次；运行的并发名额改成库里按交互 / 应用 / 定时 / 系统四类发（各有全站上限和优先级，设置里可调），替掉进程内的信号量；同源队记在库里；运行停止、记事件跨进程交给属主；运行事件、问数据事件跨进程转发（库里按 seq 追，不落库的流式增量和保活心跳只转给在看的进程）；每日花费账先占住那一行再读写；访问密钥限流、登录失败计数在 PostgreSQL 时记在库里；登录设置、对外地址、向量模型、能力快照、数据源连接池、应用页面缓存跨进程失效；上传版本库、记录表、按需探查、出具、召回、补算、按需视图、个人刷新、定时发起的锁换成跨进程的锁	2026-10-19 11:40:33 +08:00
ThearchyHelios	9a0d87aa6e	合入遗留收口分支 nr8/l（问数据心跳不落库与事件日志清理、续跑重新核对身份、事件触发批量查询与去抖边界、子图编号与驳回出口等），W2-b 在此之上做多进程协调	2026-10-19 10:46:34 +08:00
ThearchyHelios	5e6ba12678	断点库模块去掉没用上的 kind()；test-postgres.sh 的注释照现在的连接池写法改	2026-10-19 10:27:17 +08:00
ThearchyHelios	2e7d6103ea	应用库可移植到 PostgreSQL：AGENTLAB_DATABASE_URL 设成 postgresql+asyncpg://… 时整个应用库用 PostgreSQL，断点用官方的 langgraph-checkpoint-postgres（同一个库，AGENTLAB_CHECKPOINT_URL 可另给）；不设时照旧是数据目录里的 SQLite，行为不变 ... - 配置：database_url、checkpoint_url（启动时校验写法，只认 PostgreSQL）、连接池四项；启动日志写用的是哪种库（主机、库名、用户，不写密码） - 引擎（db/base.make_engine）：SQLite 照旧 WAL、外键、忙等；PostgreSQL 用连接池、探活、会话时区 UTC，装上方言调整（db/postgres.py）：建表时 String(n) 是不限长的 VARCHAR（SQLite 从不查长度，导过来的存量也可能超长）、ORDER BY 里可空列的 NULL 位置照 SQLite 补写（升序在前、降序在后，窗口函数里同样）；Integer 列在 PostgreSQL 上是 BIGINT（列挂到表上时换成 with_variant，绑定参数跟着列按 BIGINT 转换）；JSON 列两边都存原文（PostgreSQL 的 json，不用 JSONB：JSONB 重排对象里的键，快照的列序、表的先后读回来就变了）；JSON 里的 NaN 写成 null、NUL 去掉（PostgreSQL 不收） - 迁移按方言：已有的列和索引用 inspector 认；PostgreSQL 上补列的类型取模型里这一列的、缺省值取迁移表里的（布尔 0/1 换成 false/true），ADD COLUMN IF NOT EXISTS；去重语句里的布尔按方言写；部分唯一索引补 postgresql_where；init_db 在 PostgreSQL 上拿咨询锁（几个进程同时启动不撞） - 应用库上的 SQLite 专用写法改成按方言编译的表达式（db/portable.py）：json_extract 的十几处（口径召回、出具、对账、个人应用、幂等键、访问控制、数据源变化通知、剖析任务、待办超时）换成 json_eq / json_flag / json_text，json_type 换成 json_is_string（两种库同一套带类型的比较）；能力登记的 sqlite insert 换成按会话方言的 insert_ignore；能力使用次数的 json_each 按方言分支；附件「没绑记录」的条件不靠 json 的等号；按报错文字认唯一约束的地方换成 unique_violation（按表和列认，两种库的报错都认得） - 断点（engine/checkpoints.py）：PostgreSQL 时开 psycopg 连接池、在咨询锁里 setup；runner 只认 BaseCheckpointSaver，读断点仍只走 saver 的公开接口 - 依赖：新 extra postgres（asyncpg、psycopg[binary] 3、psycopg-pool、langgraph-checkpoint-postgres 3.1.2）；langgraph-checkpoint 卡在 <4.3（断点格式就在这个包里，postgres 包新版要 4.3，不动已装的 4.2.0）；锁文件补上新包 - 运行收尾：记 action.unknown、安排核实做完才把运行摘掉（以前先摘掉，等「不在跑了」再读事件的一方在库慢时读不到这一条） - 测试：AGENTLAB_TEST_DATABASE_URL 时跑在 PostgreSQL 上（每个 xdist 进程建自己的库、按事件循环分的连接池 tests/pgpool.py），不设时盖掉环境里的数据库地址照旧用 SQLite；scripts/test-postgres.sh 起临时的 postgres:16 容器跑全量；sqlite_only 标记；另开连接改库的几个竞态测试、触发器测试改成两种库都能跑（tests/appdb.py）；新增 test_db_portable 守着方言调整、JSON 键序、超长字符串、大整数、NULL 排序、时区、PostgreSQL 老库迁移	2026-10-19 09:52:09 +08:00
ThearchyHelios	8ba0b27097	同一个子工作流节点执行多次时子图里的节点分得开：子图这一次跑过的每一步交回父图的 trail（节点 id 接上前缀），下一次执行从那里接着数第几次执行（engine/evidence.next_exec），台账、证据面板不再几条都记第 1 次；写外部系统的幂等键按这次运行里的节点 id 算（「sub/pay」）。以前循环里第二轮的子图写入算出和第一轮同一个键，交回第一轮的回执、外部系统少收一笔，父图里同名的节点、套同一个工作流的两个子工作流节点也撞键。升级前停在子图里的运行恢复时照旧按子图里的 id 认出已经生效的那一笔、不重发（父图里有同名节点时不认）	2026-10-19 09:16:14 +08:00
ThearchyHelios	d1ad670fb3	复核规则对子工作流里失败的那一步只报一条：子图里那一步、子工作流节点各发一条原话相同的 node.failed，以前合成两条「执行失败」（驳回同理两条「被驳回」），问数据的复核提示里同一件事写两遍。现在保留更具体的那一步，名字一层层接上写清在哪个子工作流里（「复核子流程 › 算一下」），不写内部 id；子工作流节点自己失败、原话不同的照报	2026-10-19 09:10:27 +08:00
ThearchyHelios	04d80472f9	子工作流里的反方审稿按全局 id 记它审的报告：审稿记录和工件上的报告写这次运行里的 id（「sub/write」，同 report.checked、报告文档，第 1 波 B1 修过报告节点同样的问题），证据面板连子工作流里的审稿一起认（_Sealed.nodes_of nested），点开子图里那份报告的句子认得出审它的那次审稿；审批卡上的报告按全局 id 记，打开证据面板、审批质询对得上；单句面板的报告名写「子工作流 › 报告」，不写内部 id	2026-10-19 09:08:45 +08:00
ThearchyHelios	aa051b0a28	运行对比里子工作流的口径卡按卡所在那一层找产出：组装推演用的 Sources 时带上是哪张卡，节点产出、跑完的时刻按 engine/lineage.in_scope 换成卡那一层的 id（同推演 api/whatif._sources、证据面板 _InputMasks._output）。以前子图里的卡取值链写的是子图里的 id（nodes.parse），对比拿父图里同名的节点当它的产出，容器输入认到父图那次查询上；加一条子图卡的真跑对比测试	2026-10-19 09:03:37 +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	06286deefa	上游查库全失败时报告照实说没查到：报告节点写作前从上游 Agent 的调用记录里找出失败的平台查询（engine/nodes/report.failed_queries），写作提示里多一节「没有查到的数据」列出哪几次、原因第一行；一次成功的查询都没有时不许写单元格引用、照实写没查到和怎么排查，重写请求里同一句；记一条 report_queries_failed 提醒。以前写作者照着上游文字里的 SQL 和列名写出引用不存在的 Q1…，重写一次还是那样，答案里留着没填上的 ⟦?v:Q1…⟧	2026-10-19 08:23:29 +08:00
ThearchyHelios	4ca7d0c768	驳回出口接上数据事件触发：正式运行收尾时把途经的驳回（_rejected_via）交给 outbox.stage_run_finished，workflow.finished 照发并带上 rejected_via，缺省不认途经驳回的触发不派；补一条走驳回出口的正式运行与批准走完的对照测试	2026-10-18 18:25:24 +08:00
ThearchyHelios	c0739dfd5d	合入 W1-c 数据事件触发：定时任务加「事件触发」（上传表格出新一期、上游工作流正式运行成功结束、数据源有要处理的变化），事件在发生处写进待派发事件、调度循环去抖派发；保存时与运行时防环；{{ event.* }} 模板变量；途经驳回、应用补算的缺省不认（可勾选）；积压一拍处理完、过期的合成一条跳过；按期次分窗口；定时页可选「定时 / 事件触发」	2026-10-18 18:23:33 +08:00
ThearchyHelios	32dbfcfb52	复核修正（后端）：子图里的报告不再被判「疑似被修改」、驳回出口的双盲裁决照样降档、可验证报告与推演按卡所在的层找产出、子图那一步写名字 ... - B1 子工作流里有报告撰写节点时：它的 report.checked 进了父运行（节点 id「sub/write」），报告文档却记子图里的 id「write」， 证据接口、可验证报告、质询拿两边一比判「疑似被修改」，评测读答案也说答案不能当证据。 - nodes/report：报告文档、产出工件记这次运行里的节点 id（ctx.run.global_id），和事件同一个；nodes/io 子图自己的出具契约 按同一个 id 核对，_issuance.report.node_id 同样写这次运行里的 id - api/evidence：_reports 默认只认父图上的报告（子图的报告是子工作流那一步内部的东西，父图的答案是子工作流出口的值）， nested=True 连子图里的一起给；点名要子图报告的（?report=sub/write）照样点得开（_named_reports）；按成果挑报告的兜底 不再挑中子图的报告。成果上没有 _issuance 时退回最后一条 issuance 事件，子图成果节点的那条不认 - bundle：出具档位（_tier）同样不认子图成果节点的 issuance，verifier.js 同一个认法；子图报告的文档在引用链上照常核对 - B2 双盲裁决被驳回、走驳回出口接到出具成果时：节点产出换成 exit_payload，出具缺口和 dual_check 台账条目跟着丢了，审核人驳回的 那组数照样完整出具（比选「两边都不对」还宽）。NodeRejected 加 exit_updates（节点在驳回之前已算出的产出字段、台账、用量）， compiler._rejected_exit 并进去；双盲复算驳回时照记缺口「指标「X」两路结果不一致，审核人驳回了裁决」和一条结论为驳回的 dual_check。核对过别的关卡：人工节点、工具调用审批、动作确认、代码执行审批都在产出缺口、台账之前就被驳回，没有可丢的 - B4 子图里的卡转抄同一张子图里的卡、按位置取格：可验证报告（bundle/build._outputs_of）和推演（api/whatif._sources）按这次 运行里的 id 查产出，子图卡上记的是子图里的 id，查不到就整张遮住、推演不了；父图有同名节点时还拿父图那个当依据。改成按卡 所在那一层的 id 查（engine/lineage.in_scope / scoped_id，证据面板 _InputMasks 同一个认法），转抄的卡认不出时的兜底同样换层 - B6 子图里的一步出错、被驳回后 Run.error_node_id 是「sub/x」：实例页（apps/resolve）、通知（notify/service）照终态事件上记的 名字写「子工作流 › x」（run_node_label），不露出内部 id 测试：test_subgraph_evidence（子图含报告：证据图按父图、评测读答案不报被改、子图报告点得开、可验证报告核对通过且不写子图的 档位、子图自己的契约照常；子图卡在可验证报告里不被遮、推演还原得出、父图同名节点不当依据；子图那一步的名字）、 test_dual_check_node（驳回出口接到出具成果照样降档、台账照记、证据面板认得）。每条都去掉修复回跑过，确实失败	2026-10-18 18:15:37 +08:00
ThearchyHelios	3998e821dc	子工作流的证据交回父图（后端）：子图每一步进同一个运行、台账和口径卡交回、出口字段带出处、父图跨子图往下追 ... 调查时发现：run_subgraph 只设了节点 id 前缀（node_prefix）没用上，子图在父节点里用 ainvoke 跑，LangGraph 不把它的 custom 事件交给父图的流——子图里每一步在运行的事件里一条都没有，时间线看不到、封存也不含它查过的数。「事件本来就在同一个 运行里」此前并不成立（docs/design/orchestration-round/00-总方案.md §2）。 - engine/context + nodes/multi：子图拿到父运行的写入口（STREAM_KEY）和前缀（PREFIX_KEY），子图里的节点经它发事件，节点 id 「子工作流节点 id/…」，嵌套的一层层接上；工件按这次运行里的 id 记。子图里报的错（含被驳回）交回时节点 id 换成这一层的、 名字接上子工作流（runner 的 run.failed / run.cancelled 写「子工作流 › 那一步」），不再和父图里同名的节点混在一起 - nodes/multi：子图的台账条目加前缀并进父图 evidence（父图报告的目录据此收进子图里的查询和口径卡）；子图口径卡的产出以 「子工作流节点 id/卡」进父图 nodes；出口每个字段按出口模板认出处（模板整串就是一个取值链、渲染出来正是那个值的才认， 同口径卡认输入的那一套），出自子图运行输入的按子工作流节点的「输入」模板再往父图追一层，追不到的记 subgraph_input - engine/compiler：子工作流节点自己的 node.finished 不再重记交回来的台账条目（子图那几步自己的 node.finished 已经带着） - nodes/metrics：父图口径卡读 nodes.<子图>.output.<字段>（或 assign_to 变量的字段）时接上那个字段的出处，另记 subgraph、 field；经子图出口转抄子图口径卡的指标照样带上不完整、存疑；cell(nodes.<子图>.output.<原样交出的查询结果>, …) 按台账 认出子图里的那份快照 - engine/lineage：静态认法跨子图往下追（出口模板 → 子图里接着认；子图的运行输入按「输入」模板回父图认；最多 3 层）， 和运行时同一套；whole_ref 是两边共用的「整串一个取值链」判断。lint_process.load_subgraphs 往下读嵌套的子工作流， subgraph_spec 给静态认法取图；没读好放进来的照旧停在子工作流节点 - nodes/report：报告收证据的范围加上上游子工作流交回来的（evidence_from 写了子工作流节点的一并算） - nodes/io：指标出具的缺口里，停在子图里的说停在那个子工作流（和静态检查同一句） - api/evidence：卡上记的节点 id 按卡所在那一层认（_scoped：子图里的卡写子图里的 id），转抄、输入、追不到的那几步一路给到 子图里的那一格；子图里的节点按 node.started 记的名字接成「子工作流 › 节点」（node_label、subgraph_label）；双盲复算条目 里的卡 id 同样换成这次运行里的 - apps/resolve：实例进度不单列子图里的步骤 - 口径账本的 use_caliber 不改；比对读封存的查询，子图里的查询如今在封存范围里，照常认得出 测试：test_subgraph_evidence（子图每一步进运行、报错点名子图里那一步、实例进度、父图口径卡跨子图追到查询格并完整出具、 子图里追不到的父图降档、不是整串取值链的停在子工作流、运行输入往父图追、嵌套两层、静态检查与运行时一致（含两层和输入 模板）、父图报告引用子图里的查询和口径卡并一路点到那一格、封存与可验证报告、子图里的遮罩照父图的运行）。去掉「交写入口」 回跑，五条失败（快照不在封存范围里）。后端全量 14472 通过	2026-10-18 16:11:15 +08:00
ThearchyHelios	d57cdcaffc	驳回出口（后端）：审批、补充输入、编辑稿件、动作确认、代码和工具审批、双盲裁决接了「驳回」出口时沿它往下走 ... 以前这六类关卡被驳回一律抛 NodeRejected，运行收成 cancelled + end_reason=rejected，没有「驳回之后走另一条路」 （docs/design/orchestration-round/00-总方案.md §3）。现在画布上多一个可选的「驳回」出口（sourceHandle="rejected"，和 分支、审批同一套连线机制）： - engine/schema：GATE_TYPES（人工、调用工具、沙箱代码、双盲复算）、reject_targets（驳回出口连到哪几步）、approve_mode； 画布校验：别的节点接驳回出口报错（graph.reject_exit_invalid，条件分支的 case 标识可以叫 rejected，不算）；审批同时设了 「驳回即终止运行」和驳回边的给一条提示（human.stop_on_reject_exit） - engine/compiler：接了驳回出口的关卡按出口路由（驳回出口 / 其余是普通出口，连线没写 sourceHandle 的照样是普通出口）； NodeRejected 被接住时这一步正常结束：产出 NodeRejected.exit_payload()（rejected、decision、actor、note、kind、text， 审批另带 approved=false、「结果存为变量」照旧写 false），node.finished 带 outcome=rejected、哪种关卡、结论、谁、备注、 转到哪几步（to），trail 记 outcome=rejected；不重试、不被「出错时继续」接住，照旧 - engine/context：NodeRejected 加 stop（审批明说了驳回即终止的，驳回边照旧走不到）和 exit_payload；动作确认抛在发送之前， 走出口时什么都没发 - engine/runner：成功结束的运行途经驳回出口时，run.finished 带 rejected_via（在哪一步、谁、结论、转到哪），照实说「途经 驳回」；没有途经的终态事件一字不变 - engine/governance：发布检查各级都拦「驳回出口那条路走不到成果节点或结束」（reject_exit.no_end）；退回上游再问一次的放过 - engine/layout：驳回出口排在普通出口下面 - apps/resolve：实例进度写「被驳回，转到「X」」（动作确认写「未确认（被驳回），转到…」，超时驳回写「超时驳回，转到…」）； 实例状态（实例页头、列表、通知同一句）写「「x」被驳回，转到「y」」，走到另一个成果节点的照旧写那个成果节点；退回修改后 又批准了的按批准算；子工作流里的步骤不进实例进度 - 没接出口：行为一字不变（node.failed reason=rejected、运行 cancelled + rejected）；审批没设驳回即终止、没接驳回边的老规矩 照旧。接了驳回边的审批，实例进度那一步的说法从「已驳回」改成「被驳回，转到「已退回」」（test_app_instance_page 跟着改） 另：engine/context 的 RunContext 加 prefix / global_id、事件经 stream_writer 发（子工作流把父运行的写入口交下来）， 这一步本身不改变最外层的事件，下一个提交接上子工作流 测试：test_reject_exit（五类关卡接了出口各走一遍、批准走普通出口、超时驳回走出口、没接一字不变、驳回即终止优先、 重试和出错时继续不管驳回、退回修改再问一次、校验与发布检查、布局、实例进度）；test_process_actions（动作确认走出口 不发送）；test_dual_check_node（裁决走出口）	2026-10-18 15:56:29 +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	f520a88891	静态地认指标出处也跨卡往下追：转抄同一张图里另一张口径卡的指标，按那个指标的式子接着认（最多 MAX_COPY_DEPTH 层），受管级发布检查、应用检查和运行时、证据面板同一套说法；被抄的卡按 caliber_from 固定在别处版本的照旧停在那张卡	2026-10-17 12:31:13 +08:00
ThearchyHelios	d4f1ba8dd4	给评测留一个按引用的列投影的入口（referenced_of），顺手折行、补模块说明 ... - ledger/match.referenced_of(sealed)：这次运行封存的报告引用了哪条查询的哪几列，正好是 compare_queries 的 referenced。 评测逐题比 SQL（eval/score.sql_match，另一组在改）传它，就和账本一样按引用的列投影，不必自己再拼一遍。compute 和它 共用读指标集的那一段（_card_loader）。 - data/sql_semantics 模块说明的「几处共用这里」补上模板绑定、按引用的列投影、同一个形状三处。 - 本轮几处新代码折到 120 列以内（只换行，不改逻辑）。 测试：tests/test_ledger_projection.py 的整题等价那条另核 referenced_of 交回的就是被引用的那一列。	2026-10-17 12:22:48 +08:00
ThearchyHelios	c3123e3818	转抄口径卡指标的出处跨卡往下追，对账、召回运行按追到底的结果判档 ... 对账卡的「口径」、召回卡的「旧版 / 新版」写成 nodes.<口径卡>.metrics[i].value，出处停在「来自口径卡指标」，对账运行、 召回运行一律降档出具（「输入没追到原始数据」）；口径卡自己的指标明明追得到取数查询。 - engine/lineage：metric_copy 认出转抄一个指标的值的写法；traced() 对 via=metric 的输入看 upstream.traced； MAX_COPY_DEPTH = 8。 - engine/nodes/metrics：转抄的输入记 upstream {metric, artifact, depth, traced}——那张卡的指标集落了工件、那个指标的输入 都追到了原始数据（它自己转抄的已经一层层追过，记在它的输入上）、层数没超上限才算追到；超了就算没追到（防环：循环里 抄自己上一轮的卡每一轮多一层）。那个指标不完整、所依据的查询没通过 SQL 检查的，转抄出来的同样不完整、存疑，出具照样 降档：信任按追到底的结果给，不多给。 - api/evidence：转抄的输入后面接一步 upstream（那张卡的那个指标：值、原式、代入式、它的输入、追没追到，取值按同一套遮罩）， 转抄的转抄接着追（同一个指标只接一次、最多 8 层），它的输入落在查询快照上的照常给查询步骤；出处链里遮着的列把这几步 的输入也算上。reconcile.py、recall.py 生成的式子不用改。 - 前端证据面板：新的一节「转抄的口径卡指标」，输入来源里转抄的那一项写清追没追到、点一下跳到那一步，那一步的输入点一下 跳到口径的取数查询（文案进 lib/terms.ts）。check-ledger 加一段：对账结果里点「按口径」的数，一路点到口径的取数查询。 测试：tests/test_metric_copy_lineage.py（转抄、转抄的转抄完整出具；转抄没追到的照样停在那张卡；上游不完整的转抄也不完整； 层数上限；真跑对账、召回都完整出具，出处链接上口径卡那一步、给出口径的取数查询）。去掉 upstream 再跑，5 条失败。	2026-10-17 12:05:12 +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	d17a08bafb	合入 W4-c 账本前端：证据「口径」一步与数字上的小标记、问数据轮次摘要与按口径出具 / 对账、对账视图与反馈、可沉淀的问题、设置里的口径账本一组、比对结果按退避轮询；被驳回的那一步 node.failed 带 reason=rejected，画布、航迹、时间线、问数据过程都画「被驳回」	2026-10-16 22:29:02 +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	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	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