109 Commits

Author	SHA1	Message	Date
ThearchyHelios	86e52192a9	运行对比后端（变化三分法）：两次运行按指标拆清是数据变了、口径变了还是模板 / SQL 变了，数据变化按维度归因 ... GET /api/runs/{id}/compare/base 找默认基准：定时任务发起的先找同一定时任务更早结束的一次，否则同一工作流、 同一运行类别；只挑封存过的终态运行，找不到 404。GET /api/runs/{id}/compare?base= 对比两次运行：两次都要 已结束、封存且核对一致（照搬证据接口的封存判定），否则 409；不是同一个工作流、同一次运行 422。只读，不追加 事件、不落工件。 engine/compare.py 是纯函数： - 查询按「节点 + 第几次 + 工具」配对，配不上再按规范化 SQL 配；normalize_sql 判 same / params_only / changed，结构变了的用 diff_facets 写出差在哪（时间范围排在最后）；核查类查询不参与 - 口径卡同一节点按指标 id 配对，表达式、口径版本、小数位、单位、显示格式不同算口径变了 - 每个指标按 added/removed → 口径 → SQL 或上游配置 → 说不清 → 只参数 → 数据 的次序分类；输入落在快照上 的直接比两边快照的 SQL，不落在快照上的看写它的节点和画布上游 - 口径变了时严格拆分：旧表达式配这次的输入用推演重算的还原和求值算 f_old(x_new)，十进制精确相减，两效应之和 逐位等于总变化；SQL 也变了、用到遮罩列、单位不同、旧叶子没记录的不拆并说明 - 维度归因按维度键配对两边的行、取变化最大的 10 个；度量之和等于输入的值（含合计行那一格）才给占比；截断、 度量列遮罩照实写；遮罩列、日期列、每期都不同的列不当维度	2026-10-05 08:49:52 +08:00
ThearchyHelios	c8d0e5d18b	数字推演复核修正（第 3 轮）：决定取哪一格的容器不再给可勾的行段，包着它的引用给了新值时不再说不准 ... - cell(nodes.q, len(vars.res.rows) - 5, …) 里的 vars.res.rows 这种决定取哪一格的数组字段、整份结果，第 2 轮起排除它的行 只回「说不准」，可 row_span 照给：界面让人勾 10 行，勾了推演不出来，「不支持推演的输入」里又说它不能用。现在这种容器 不给行段；决定取哪一格的单格照给（勾掉它确定是排除后无法计算）。前端 row_span 的类型说明跟着补上这一条 - 第 2 轮加的「说不准」不看包着它的引用有没有给新值：那一格改成 100、再排除别的行，以前能算出 100，第 2 轮起回说不准。 _refs 现在记下每个嵌在里面的引用归哪个最外层引用（嵌几层都记最外层）；最外层引用都给了新值时，只嵌在里面的输入无关 紧要（_Plan.moot）：它那一行排除了不再报排除后无法计算，对不上快照的也不再说不准。它自己也是最外层引用的照常拿值， 只是取哪一格不再说不准 - 补测试：选取用的容器不给行段、只有那一格那一行勾了有确定结果（单元和真跑）；那一格给了新值后排除任何行都照常算； 既数行数又选取的容器；嵌在下标里的单格、对不上快照的下标（含嵌两层）、两个引用共用一个下标要都给新值；碰到了却没变 时 maybe_changed 为假、下游口径卡不标（单元和真跑）；嵌在下标里的遮罩格让整个指标推演不了（BLOCKED 加一例）；读不出来 的快照上嵌在里面的那一格不给行段（原先守它的测试被这次的选取判断盖住了） - 逐个做过变异，全部变红：选取容器给行段、moot 不过滤、说不准不看 settled、_doubt 不看 moot、只记直接上一层、settled 用 any、moot 含最外层引用，以及复核点名的 maybe_changed 只看碰没碰到、遮罩只看最外层。第 2 轮的两份变异单重放后也都 变红，只有「row_span 只看快照读不读得出」成了等价变异：完整值找不回来的容器在最外层时整个指标推演不了，嵌在里面时 又是选取用的，两头都已不给行段	2026-10-05 07:37:02 +08:00
ThearchyHelios	bfc0e88e9a	数字推演复核修正（第 2 轮，后端）：整个指标推演不了的不改动也照实说，完整值找不回来的数组排除行后不再报「无变化」 ... - 用到了遮罩列、最外层输入还原不了（容器的完整值找不回来、所在的查询快照读不出来）、卡上没记全输入的指标，以前不改动时 报 unchanged（界面写「无变化」），输入照样可改、行照样可勾，改了、勾了才说推演不了。现在不论有没有改动都交回 unsupported / masked 和原因，所有输入 editable 为假、不给 row_span，unsupported 里另有一条 input 为空的（界面据此只写 原因），之后只列卡住它的输入。同一格既遮着、快照又读不出来时说遮罩 - 下游口径卡改看重算新给的 maybe_changed（改动碰到了某个指标，它又变了或说不准）：推演不了的指标 changed 一律为空， 只看 changed 分不出「什么都没改」，一打开就会把下游标成可能受影响 - agent 数组字段的完整值找不回来（节点产出不在、被改过，另存的完整值读不出来）时，排除它行段里的行以前因为值为空被忽略， 指标报「无变化」、报告引用处报「不受影响」。现在算碰到了它（excluded_rows 照记，输入 changed 为真、new 为空）， 完整值找不回来的输入一律不给行段 - 决定取哪一格的容器（cell(nodes.q, len(vars.res.rows) - 1, …) 里的 vars.res.rows）少了行时，以前拿卡上记的那一格算出 「无变化」，现在说不准（unsupported） - 补测试：四类整个推演不了的指标不改动、改动后都照实说（单元和真跑）；数组完整值找不回来时排除行段内一行（单元和真跑， 含报告引用处）；查询当时记下、跑完又从数据源去掉的遮罩（推演和勾行接口）；写输入的节点和快照在同一条事件里交回 （合并查询的边界）；给了新值的输入不再说不准；数组只认行段内被排除的行；同一份快照交回两次按第一次；读得出来却不是 查询结果的快照；嵌在里面、读不出来的那一格不进代入式。逐个做过变异：复核列出的四处、第 1 轮漏掉的三处和这次新加的 判断改掉后都变红	2026-10-05 06:49:33 +08:00
ThearchyHelios	09237a4c99	数字推演复核修正（第 1 轮，后端）：排除行时说不准的指标不再报「无变化」，快照读不出来时不给值，遮罩按用到的快照在线程里算 ... - 排除了行，指标却有输入对不上任何快照（老运行没存完整值的容器、加工过的结果、按位置从整份结果里取的一格、由查询结果 算出来的数）：以前一律报「无变化」、报告引用处报「不受影响」，或者拿原值算出一个不对应任何一份数据的数。现在回 unsupported 并写明是哪个输入说不准；写它的节点在那份快照交回之前就跑完的影响不到它，照常不算（按事件序号比先后）。 卡上没记全输入的指标，有任何改动都标 unsupported - 查询快照文件不在、内容与哈希不一致时，落在它上面的 cell()、agent 字段不给值、不能改、不给代入式，用到它的指标推演 不了；遮罩照样按台账记的数据源算，不再因为快照坏了就失效 - 遮罩改成用到哪份快照才算哪份：读快照放进重算的工作线程，查库交回事件循环。以前每次请求都在事件循环里把这次运行的 全部快照读一遍、复验一遍哈希 - 输入带 row_span（实际用到的快照行）；新增 GET …/evidence/whatif/rows，按页取封存范围内一份快照的行（遮罩列写 「已遮罩」，只读）。界面据此给整份结果勾行、只让用到的行可勾 - 不能改、也没有行可勾的输入（对不上快照的列表、文本）列进「不支持推演的输入」并写明原因 - 下游口径卡顺着画布的边找，经中间节点用到卡上值的也标；改动碰到了指标、它却推演不了时也标「可能受影响」 - 超大整数不再让接口 500：新值超出可计算范围回 422，算出浮点放不下的整数按「不是有限的数值」说明；非法值的说明不露出 None、单引号这些 Python 写法 - 补测试并逐个做过变异：封存核对没过、事后加的遮罩、合并查询的遮罩、指标集被改（409）、两份报告、循环里先算卡后算 产出、手写事件核对取哪次执行和边界、重算的几处保护、勾行接口。取整和口径卡逐个对拍（含二进制半中间的数、负小数位）： metrics.py 只许加 value_artifact，取整没法抽成共用函数，先用对拍守着	2026-10-05 05:43:17 +08:00
ThearchyHelios	24fc21cb56	数字推演：算出无穷大、非数时说清算不出来，不让接口在 JSON 编码时 500 ... 改了输入之后溢出成无穷大（或算出非数），以前照 ok 交回，Starlette 编 JSON 时拒收这种浮点数，整个请求 500。 现在按计算出错处理（status: error，写明原因）；老卡上本来就记着无穷大的值和输入，交回时换成 null（口径卡渲染成「—」）。	2026-10-05 04:14:56 +08:00
ThearchyHelios	cb141cea88	数字推演：用到遮罩列的指标不给代入式；真卡上核对还原是否忠实、封存后插进来的卡不认 ... - 代入式里代进去的就是遮罩列的那一格：用到遮罩列的指标，推演结果里的 substituted 一律为空（输入值本来就不给） - 测试：真跑出来的每张卡（cell() 取数、整份查询结果、nodes.* 容器、agent 数组字段的两种引用、下游口径卡），什么都不改 强制重算，值和卡上记的一模一样 - 测试：封存之后插进来的 node.finished 指向一张伪造的指标集，推演照旧用封存范围内的那张	2026-10-05 04:13:33 +08:00
ThearchyHelios	fb15805ead	数字推演的重算（engine/recompute.py）：改输入、排除快照行，按口径卡同一套规则算出新值 ... 纯函数，不读库、不写工件。口径卡怎么算的这里就怎么算：同一条原式、同一个求值器，浮点按卡上的小数位 round，渲染走 render_metric。重算前先还原每个输入当时的值： - 标量（含 cell() 的格、agent 的单格字段和数组元素）用卡上记的值；它们落在快照的哪一行记在 locator 里，排除了那一行 就当缺失，指标标「排除后无法计算」 - 容器只记了「[12 项]」：agent 数组字段从节点产出的 data 还原、按 locator.rows 去掉被排除的行；nodes.* / input.* 从 口径卡执行前那个节点的产出还原；vars.* 只认 value_artifact，老运行照实说当时没有保存完整值；和某份快照 rows 一样 的容器（整份查询结果赋给了变量）排除行就去掉那几行 - 遮罩列取来的输入不给值、不能改、它的指标不重算：新值和原值一比就能算出遮住的那一格 - 嵌在下标、cell() 行列里的引用决定取哪一格，不能直接改 只重算碰到改动的指标；不合法的改动（路径不存在、值不是数、行号越界、快照不在封存范围、改容器或文本）抛 WhatIfError。 另有报告里引用这些指标的片段会写成什么（按片段自己的换算渲染）、引用了这张卡的下游口径卡（只标不重算）。 比率、百分数的变化量写「个百分点」。	2026-10-05 03:44:29 +08:00
ThearchyHelios	60cd5a47bb	口径卡给容器型 vars 输入另存完整值（value_artifact），供数字推演重算 ... 卡里的输入对列表、字典只记「[12 项]」这样的大概，事后要排除几行、改一个数再算一遍，手里没有完整的值。 nodes.*、input.* 的完整值在那个节点封存的产出工件里，agent 字段能按出处从查询快照还原；vars 是谁写的、 写进去的是不是节点产出本身说不准，只能在口径卡算的那一刻存下。 - 此后容器型 vars.* 输入落一份 metric_input 工件 {path, value}（put_json，随运行封存），输入里记下 value_artifact； id 写在内容寻址的指标集里，不另起台账条目 - 大过 4 MB 的不存，写失败也不存：口径卡照常算出来，只是这个输入以后推演不了 - 金样测试（改动之前的代码真跑出来的工件）：只有标量输入的卡逐字节相同、工件 id 不变；带容器型 vars 输入的卡 去掉新键后和以前一字不差	2026-10-05 03:26:43 +08:00
ThearchyHelios	19d7fd7162	合入期 0 核查工具箱：SQL 语义（规范化、方面、差异说明）、只读核查 agent、核查每日花费账、核查设置组、数据源查询工具的强制只读	2026-10-05 02:52:16 +08:00
ThearchyHelios	132d126c6f	核查 agent 复核修正：数值字段的各种写法都换成格子引用、认不出的结构下的数不采信；退回普通调用时把结构写进消息，没交的字段不再算「查不到」；收尾的钱按最贵的样子留、留过的不再被上限拦；永远不抛 ... 数只认格子：原来只认 type: number / integer，可为 null 的数（anyOf，Pydantic 的 Optional[float] 就这么写）、$ref 引用进来的、allOf 包着的数值字段都没换成格子引用，模型写的数原样收下。现在先展开本地 $ref、并掉 allOf，anyOf / oneOf 里有一支能放数就整个算数值字段；取值时按值的形状挑分支。认不出的结构（没写类型、文本字段、没写 items 的数组、没写属性的对象）下模型写的数一律丢掉、照记下来，码值里的数照收。嵌套的引用、数组写成一段 JSON 文本的照样认，还不是数组的照实记下格式不对。数值字段引用到日期、名称这类不是数的格子，记成 unresolved，不拿去和原流程的数比。 退回普通调用：原来消息里只有「按给定结构填写」，结构却不在请求里，模型猜不到字段名，交回来对不上的字段全成了 missing，双盲复算会说盲算什么也没查到。现在把结构（JSON Schema）写进消息；没交的字段记 unresolved（模型没有交这个字段），交了 null 才是 missing；一个要求的字段都没交就是没按结构交结果，照错误交回。模型建结构化输出就报错的，直接走普通调用，不白算一次调用。 上限与金额：一条查询自己的时限到了（ToolTimeout 也是 TimeoutError）原来被当成整个核查的时长到了，现在先认 ToolTimeout，原因交回模型、核查照常往下走。收尾要把查到的结果交给模型，原来留钱按眼下的消息估，最后一条查询的大段结果一进来就不够，查完了付不起收尾、结果白查；现在按收尾最贵的样子留（查询结果按 _digest 的上限、最后的说明截到 2000 字、结构也算），留过钱的收尾不再被上限拦下，实际用量超出估算或并行的核查先用掉当天余额时，最多超出一次收尾调用的钱。每日上限缺省按设置里的「核查每日金额上限」，明确传 None 才是不限，质询接口不必各自记得去读。 永远不抛：每日账写不进去、建工具出错这类意外原来会直接抛出，节点失败、质询接口回 500；现在整段包住，按已经攒下的用量、查询照实交回。	2026-10-05 01:46:55 +08:00
ThearchyHelios	c8363206bd	发起时就定下的事件和运行记录同一个事务写进事件流：受管级别那条日志、目录变化、口径升版处置以前在 run_manager.start 返回之后另外写，这时运行已经建好、执行任务已经起了。其中任何一次写失败（库被锁超过等待时长之类），launch_run 抛出普通异常，运行却在执行；定时任务按「LaunchRefused 以外的异常记未能发起」会把一次正在执行的正式运行记成未能发起，封存范围里也少了受管级别那条日志（governed_formal 找不到它就退回看工作流现在的 status，中途改过画布的会按已发布级别出具）。另外这几条和执行抢先后，运行结束得快时可能落到封存之后。 ... - run_manager.start 加 notes：(类型, node_id, 数据) 的列表，先 flush 拿到运行的 id，和运行记录同一个事务提交，提交之后广播，最后才建执行任务。写不进去就不建运行，launch_run 抛出的任何异常都说明运行没有开始执行 - launch_run 在发起前把这几条事件备好交给 start，不再事后用 run_manager.note 写。顺序和以前实际落库的一样（日志、目录变化、口径升版处置，然后 run.started），现在是确定的 - 没有 notes 的发起（探索运行、问数据）和以前完全相同 没有照复核建议的「写失败就记日志、照常返回运行」：那样正式运行会在缺了受管级别记录的情况下照常出具，可能悄悄降成已发布级别。 测试：用触发器让口径升版处置那条写不进去，launch_run 抛出 IntegrityError、库里没有多出运行（旧代码留下一条正在执行的运行，这条变红）；服务发起的正式运行里，受管级别日志和口径升版处置排在 run.started 前面，都在封存范围里	2026-10-05 01:18:43 +08:00
ThearchyHelios	fc57ed0e32	追加事件收紧几处，封存后追加的质询不计进运行用量。复核提出：停在审批时追加只看运行还停着，关于第一张审批卡的质询问完时运行可能已经批过它、停到了第二张上，问答照样写进去；没有终态事件的老封存运行追加之后 verify 由一致变成不一致；返回给调用方的事件 id 和库里的不一样；测试证明不了先落库再广播；封存后追加的质询平时不计用量，继续运行之后又被计进去。 ... - append_events 加 approval_id（只用于 interrupted）：问的是哪张审批卡，那张卡仍待审批才写。核对放在和其余条件同一次条件更新里（EXISTS 待审批的那条），批过了、不是这次运行的卡都不写、返回 None。条件更新写明不同步会话里的运行：条件里带了 EXISTS 时 SQLAlchemy 会悄悄换一种同步办法、给语句加上 RETURNING - manifest_seq 为空的老封存运行，封到哪一条是 verify_manifest 按事件类型推出来的：有终态事件的封到最后一条终态事件，追加在后面不碍事，照旧追加；没有终态事件的封到最后一行，追加一条范围就挪到它身上，我们自己写的批注被当成篡改，现在不追加 - _stage 落库时用事件自己的 id：广播出去的、交回给调用方的和库里的是同一个 id - 运行用量不计数据带 post_seal 的质询：运行用量是这次运行自己花的，结束时就定下了、写进了终态事件；封存后的批注另有自己的账，同按需裁判的判定。继续运行之后它落进新的封存范围，照样不计 测试：两道审批的运行批过第一道、停在第二道，钉住第一道的质询不写、钉住第二道的写，读完运行之后那张卡被批了也不写，返回的 id 和序号与落库的一致；广播时查库，每条都已落库，落空的一条都不广播（把广播挪到条件更新之前这条就变红，以前的测试照样通过）；老封存三种（无终态、run.finished、run.failed）追加前后 verify 都一致，无终态的不写；失败封存的运行追加 post_seal 质询后继续运行，运行用量里没有它。去掉审批卡的核对、改回老封存一律追加、改回计 post_seal、去掉落库 id，对应的测试各自变红	2026-10-05 01:18:03 +08:00
ThearchyHelios	f8b2857630	进程重启后接号不再撞上已有的序号：以前恢复、继续运行、放弃、启动时补日志都只按 run.last_seq 接号，而 last_seq 会被写小。按需裁判记判定（api/evidence.py 的 _append_judged）的条件更新不带 last_seq 条件：它取了号还没写，封存后追加（run_append）抢先提交了，它再提交时把 last_seq 写回自己那个更小的号。同一进程里序号计数只增不减，不碍事；重启后计数从 0 起，继续运行写出的 run.resumed 就和封存后追加的事件同号，重新封存时两条同号的事件一起进了清单，而清单按序号排序算哈希。 ... - runner 加 _seq_floor：接号起点取 last_seq 和库里实际最大序号中大的那个。恢复、继续运行、放弃都改用它，run_append 原来手写的同一段兜底也换成它 - 启动时（setup）先把落后的 last_seq 按库里实际的最后一条改正，再处理上次留下的运行中记录。_append_judged 规格不许改，它重启后也只按 last_seq 接号，不改正的话它第一次追加就撞号；有 (run_id, seq) 索引，五千次运行、一百五十万条事件实测约 7 毫秒。updated_at 不动，这是补记录，不是运行有了变化 - _stage 不带运行对象时的更新只往大里改：另开会话记的事件和执行任务同时在写，号大的先提交、号小的后提交，以前会把 last_seq 写小 测试：last_seq 写小、清掉本进程计数之后继续运行、恢复、放弃都接在实际的最后一条后面，全流无重复序号、verify 通过；_stage 先提交大号再提交小号，last_seq 不变；按真实的交错（裁判停在条件更新之前，封存后追加先提交）把 last_seq 写小，重启（shutdown、清计数、setup）后 last_seq 改正、别的运行原样不动，再裁判、继续运行都不撞号。去掉启动时的改正，只有裁判那条变红；去掉 _seq_floor，继续运行、恢复、放弃三条变红；_stage 改回无条件写，对应那条变红	2026-10-05 01:17:18 +08:00
ThearchyHelios	f1c068d6a9	核查工具箱收尾：连接的方面补上另一侧（关联条件里出现的别的表，CROSS JOIN 写它之前的来源），双盲复算对照数据目录里的关系时用得上；只读 agent 收尾前先拿到收尾用的模型再预留金额，模型拿不到时不在每日账上白记一次调用；收尾消息的参数改名 limit_words，说清是哪个上限的说法	2026-10-05 00:42:02 +08:00
ThearchyHelios	1efa5f7b20	核查用的只读 agent：engine/verify_agent.py 的 run_verify_agent 给双盲复算、反方审稿、审批质询共用。工具只建给定数据源的 db_schema / db_query，一律 force_readonly；自己管工具调用循环（不依赖 NodeContext / @task），查询次数、时长、金额（这一次、全局每日）任何一项到顶就停止查询、按已有结果收尾，收尾那次时长到顶另给宽限，金额每一轮都给它留出钱；模型不在价格目录里时金额上限无效，照裁判的说法记一条说明；每次调用记进核查的每日账。成功的查询按本 agent 自己的顺序编 Q1、Q2…，给了 emit 才发 llm / tool 事件（role: verify，查询的 tool.end 带 query_artifact，随运行封存、能下钻），绝不往证据台账写 kind: query，免得进了报告的写作目录。最后按调用方的结构交结果：数值字段换成格子引用 {alias, row, column}，由代码从快照取值，模型自己写的数字不采信、取不到是 None；理由里的数字写成 [[v:Qn.rX.列]]，用本 agent 自己的台账 build_catalog + compose_doc 组装，裸数字会被标出；结构化输出失败退回普通调用抠 JSON。上传表格按调用方给的数据版本查。永远不抛，模型没配好、调用失败、触顶都落在返回值里	2026-10-05 00:34:17 +08:00
ThearchyHelios	6b272de6f9	审批质询的用量计进运行用量：质询不在图里执行、不发 llm.end，花的 token 和金额写在 approval.inquiry 事件数据的 usage 里（input_tokens、output_tokens、cost_usd、calls，可带 unpriced_calls），以前运行用量只认图的状态和 llm.end，质询花的钱在运行页上看不见。_usage_of_events 把质询的用量单独加总放在 inquiry 下：llm.end 这本账要和状态那本比大小，质询花的两本里都没有，混进去比会被状态那本盖掉。_finalize 照旧算出图的用量（成功取状态，其余两本取大）后再加上质询的，明细另记在运行用量的 inquiry 下；停在审批时被放弃的运行，放弃时补上这次停下期间的质询。停过两次、两次都问过的，按上次记下的 inquiry 先减后加，每次质询只计一遍。没有质询的运行用量和以前逐字相同	2026-10-05 00:18:22 +08:00
ThearchyHelios	3dbd69b561	往停下的运行里追加事件统一走 engine/run_append.py 的 append_events(run_id, items, *, require, seal=None)：审批质询要在运行停在审批时把问答写进运行、随运行结束一起封存，探索运行封存之后还要能追加批注。事件流是封存的依据，清单按 seq 排序、run_events 的 (run_id, seq) 又不唯一，撞号会让封存核对时对时不对，所以照 _append_judged 的做法：同一运行在进程内排队，读 last_seq 后从 bus 接号（另取库里实际的最大序号兜底，last_seq 被别处写小了也不撞号），写事件和条件更新 last_seq 在同一事务里——interrupted 要求运行仍停在审批，sealed 要求仍是终态且封存没变，任一条落空就回滚、返回 None，调用方据此说明未写入运行记录；提交之后才广播。sealed 的事件带 post_seal: true；运行记录上的封存若早于最后一条结束事件（继续运行后又结束、还没重新封存的那一下），不算现在的封存，不追加，免得事件被接下来的封存收进去；调用方可传 seal 固定开始时看到的封存。事件类型加 approval.inquiry。测试用人工审批停住的运行：追加两条后批准、封存，verify 通过且改动追加的事件 verify 就对不上；恢复、继续运行、重新封存、别处写入抢在中间时都不写、last_seq 不动；连续和并发追加序号严格递增、全流无重复；恢复后前面的节点不重复执行，Agent 里批过的工具不重复执行（含升级前写下的断点）	2026-10-05 00:14:40 +08:00
ThearchyHelios	0eaaf71346	运行记下选项快照和来源：runs 加 options（JSON，默认 {}）和 schedule_id（可空，建索引）两列。后面的核查设置要在发起时定下、整次运行沿用，审批停下期间改了设置，恢复和重放仍按发起时的（同 approval_default 的道理）；定时任务要能找回自己发起的运行。RunManager.start 收 options、schedule_id 并落库，选项先深拷一份，调用方之后改自己的 dict 不影响快照；选项非空时写进每一段的 run.started（进封存范围），为空时 run.started 和以前逐字相同；恢复、继续运行照运行记录沿用，节点从 RunContext.extra 的 run_options 读同一份拷贝。RunOut 带 schedule_id，GET /api/runs 可按 schedule_id 筛，launch_run 原样往下交。旧库走 _COLUMN_MIGRATIONS 补列，存量运行回填 {} 和 NULL；create_all 不碰已有的表，新列的索引另由 _INDEX_MIGRATIONS 补建，索引名和新库 create_all 建出来的相同	2026-10-05 00:07:07 +08:00
ThearchyHelios	b459c3bb58	核查花费账：engine/spend.py 照结论句裁判的每日计数做一本核查用的每日账（设置表 verify_spend 一行，按本地日期滚动）。调用前按估算预留，加上这笔会超过每日上限就不记、返回 None，上限为 None 表示不限；调用后按实际用量找补，跨了天不找补；价格目录里没有的模型只计次数。和裁判分开记：核查一次要查好几轮库、花得多，记在同一本账上会把当天的裁判挤到判不了、让报告出具无故降档。读改写按事件循环各持一把锁，并发预留不会一起越过上限	2026-10-05 00:06:03 +08:00
ThearchyHelios	7820556ab6	发起运行的规则抽成 engine/launch.py 的 launch_run：以前全写在 api/runs.py 的 start_run 里、只认 HTTP 请求，后面的定时任务要用同一套规则发起正式运行，另抄一份迟早走样。正式运行只能从当前发布版本发起、口径升版未声明策略就拦、绑定的工具不存在就拦、发起后记受管级别那条日志和目录变化、口径升版处置，全部搬进服务；拒绝时抛 LaunchRefused(status_code, message, code)，start_run 只剩一层包装，把它换回和以前逐字相同的响应（带机器码的仍回 {detail, code}）。正式运行的快照图不成形，以前由 main.py 的 ValueError 兜底回 400，现在在服务里换成同样的 400 拒绝，调度器也拿得到明确的拒绝。node_setting、tool_bindings、missing_tools 跟着搬过去，runs.py 再导出，旧的导入路径照旧可用；runner 固定数据版本取绑定时改从 engine/launch 导入，不再依赖接口层。新测试先把 HTTP 的 17 种拒绝（含工具缺失的数据、工具、混合、超过 8 处四种说法）按原话写死、在旧代码上通过，再逐条比对直接调 launch_run 的结果；另测服务发起的正式运行照样写治理事件	2026-10-05 00:03:24 +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
ThearchyHelios	536c9de116	证据目录的省略警告照实说省略了什么：放不下不一定省略了查询。真实运行里查询全部列出、只是有的只列前几行，警告却写「0 次只列编号和摘要（）。写作模型看不到这些查询的明细」。现在分三种写：有查询只列编号和摘要的照旧；查询都列出、有的只列前几行的写「N 次查询都列出了数据，其中 M 次只列前 3 行」并按来源列次数；只省略了表和字段说明的照实说。事件多带 compact、compact_rows，各来源带 compact；时间线按同样三种写标题。另外把测试夹具、注释和 check-decode 里沿用的那次运行的真实查询次数换成虚构的次数或概括说法	2026-10-04 12:28:07 +08:00
ThearchyHelios	46330dfd96	模型不在价格目录里时运行金额写「金额无法估算」，不写 $0：真实运行里 token 记到了上百万，金额却是 $0，看着像没花钱。llm.end 发出时，用了 token、模型却不在价格目录里的标 unpriced（目录里标 0 价的本地模型不算）；运行用量按 llm.end 数出 unpriced_calls，成功的运行也补上（状态里的用量分不出 0 是免费还是没价）。运行详情、画布运行面板、航迹的金额：一分都没估出来写「金额无法估算」，估出一部分写「≥ $x」，悬停说几次调用不在价格目录中。check-trace 补断言；流式用量测试和注释里的真实调用次数换成概括说法	2026-10-04 12:27:38 +08:00
ThearchyHelios	720f842b82	结论句裁判小批分波地问：一次调用最多 8 句（原来 40 句），第一批单独问、之后每波最多 4 批同时问，几批共用剩下的时长；超时只丢没回来的那几批，回来的判定照样留下。真实运行里推理模型拿着 40 句的摘录在 30 秒的时长上限内没回来，交给审批的报告一句都没判成，审批卡只能写全部未裁判；同一个模型 5 句一批 3 秒多就回来了。金额上限按已花的加这一波已定下的估算算；第一批调不通（鉴权、网关挂了）时只撞这一次，后面的统一记未裁判	2026-10-04 12:27:38 +08:00
ThearchyHelios	fa842a7bec	交给人工审批的报告，探索运行也在节点里裁判结论句：审批人批准前就能看到判了几句、几句证据相矛盾。按需裁判要等运行封存之后才能判，封存前放开会动证据清单的完整性约束，所以这种报告改在节点里当场判，和正式运行同一条路；没有审批的探索运行照旧按需判，不在节点里花钱。审批节点审哪几份报告的认法抽成 reviewed_report_ids，审批卡和报告节点共用，两边说的「要人审」对得上。审批卡上没开裁判的探索报告改写「这份报告没有开启结论句裁判……开启后，交给审批的报告会在批准前判完」；开了裁判却没在节点里判的老运行另给一句。助手指引、出口契约注释、前端类型注释同步；审批暂停时按需裁判仍拒绝，测试改成只看点击不多一次调用	2026-10-04 12:03:14 +08:00
ThearchyHelios	ee0700eca6	合入 FA：结构化抽取截断重试、写作清单按模型窗口定预算并按来源均衡、缺失断言交回重写、日期时间按可读格式显示	2026-10-04 11:43:21 +08:00
ThearchyHelios	470f8b6641	报告里单元格的 ISO 日期时间显示成「2026-06-30 08:21:39」，只改显示 ... 报告表格里的时间以前照快照原样显示成 2026-06-30T08:21:39，读起来费劲。[[v:]] 和 [[table:]] 渲染出来的 ISO 日期时间改成用空格隔开（小数秒、时区照留），写作目录和流式输出同一套写法。快照里的值、引用记下的 value、eid、证据下钻都不变。 复核按文档生成时的规则：老文档存的是带 T 的字，拿新规则重新渲染会对不上、被当成文档被改过。所以显示规则也记版本：新文档里真有日期时间被改写时在顶层记 cell_display: 2（参与内容哈希），没有被改写的文档和以前一字不差；没有这个字段的按 1 版（原样）复核，记了认不出的值报 bad_schema。出口复核、期 4 的金样（test_provenance_unchanged）都照旧通过；裁判摘录是给模型看的，不改	2026-10-04 11:33:09 +08:00
ThearchyHelios	4e1adec205	审批卡标明运行类别、附上审的报告的核对概况：真实运行里审批说明写着「批准后才会正式出具」，那却是一次探索运行；报告里一句结论和证据相矛盾，审批人批准时完全不知道。人工审批的卡上加一行运行类别和批了会怎样（探索运行写「批准后输出，这是探索运行，不是正式出具」，正式运行写从已发布版本发起）；human 节点挂起时，上游直接连着的、或标题和说明里引用了正文（nodes.<id> 或报告的 assign_to）的报告撰写节点各带一份核对概况（payload.reports：同 report.checked 的 stats、结论句策略、裁判摘要、报告文档工件 id），卡上写「N 个数字都有出处」和结论句的核对状态（节点里判过的写判了几句、几句证据相矛盾；没开裁判或探索运行写「结论句尚未核对」），并给查看逐段证据的入口，点数字打开证据面板。check-stream 补断言	2026-10-04 11:29:04 +08:00
ThearchyHelios	799c80b97e	清单有省略时不许断言「没有数据」：写作规则加一条，核对认出缺失断言交回重写一次，仍有的只标注 ... 一次真实运行里写作者只看到上百次查询里的前二十来次，却写出「某类数据缺失、本轮没有查到任何结果」这样的断言，可那个 Agent 实际查到了上百条记录。 - 写作规则：清单有省略、或有来源的结构化结论为空时，不得断言没有查到、不存在、缺失、没有数据，只能写「本报告未覆盖」并说明依据不足 - 组装文档：清单有省略时按一组明确的说法认出缺失断言（没有查到、未查询到、查不到、没有任何记录、数据为空、数据缺失、不存在相关记录、暂无数据等；「不存在明显差异」「不代表没有数据」这类不算，代码块不查），记新违规 absence_claim，带 span、所在片段和原句 - 和句中的 [[see:]] 一样归入 REWRITE_ONLY：交回重写一次，重写后仍有的只标注、不判失败；只剩这几类时不再按最多重写次数反复重写。仍有时报告节点发 report_absence_claim（带 count、texts），运行复核算作缺口 - 证据面板的违规清单标「缺失断言」并写明为什么依据不足，时间线给 report_absence_claim 专门的一行，文案在 terms.ts；check-decode、check-evidence 补断言 - 没展开的查询的摘要在没有表结构快照时从查询快照里的 SQL 认表名 - 回归测试：合成的门店、会员、卡券、活动库真跑「4 个 Agent 并行查库 → 报告」（查询次数虚构、分布悬殊），覆盖抽取截断重试、两次截断记空值、清单均衡和缺失断言的重写	2026-10-04 11:28:23 +08:00
ThearchyHelios	4e876ff9d8	写作者的出处清单按写作模型的窗口定篇幅，放不下时分优先级、按来源均衡，省略了什么照实说 ... 一次真实运行里证据台账有上百次查询（4 个 Agent 查询次数悬殊），清单写死 12000 字，十万字以上的目录被截到一万两千字以内，只有前二十来次查询进了写作者的视野；查询按编号排，前面的 Agent 占满了预算，有的 Agent 一次都没露面。 - 预算：写作模型上下文窗口的 40%（字数按 1 字约 1 token 保守算），窗口先看模型接入里给这个模型登记的 context，再看模型目录；拿不到按 128K（和 Agent 护栏同一个保守值），即 51200 字；下限 12000、上限 160000 - 第一优先：各 Agent 经按出处核对交来的结构化字段（换成报告目录里的全局编号，值按单元格引用的渲染规则写，给出可照抄的引用标记）、口径卡指标和运行输入，一律列出；结构化结论为空的来源写明不代表没有数据 - 查询按产出它的节点分组、轮流展开：字段引用到的查询先展开，再给每次查询列前 3 行，有余量再补到 20 行；表和字段、知识库检索最多占预算的四分之一 - 没展开的查询列出编号和一行摘要（表、行数）；约定只能在句末写 [[see:Qn]] 作依据，不猜行列、不凭摘要写数，数字照样逐字核对 - 清单开头明说目录有省略、各来源各省略了几次；报告节点发 report_catalog_trimmed 警告（带 queries、omitted、nodes），时间线给它专门的标题和下一步，运行复核算作缺口 - 放得下时清单和以前一字不差（多出的只有结构化字段那一节）	2026-10-04 11:17:13 +08:00
ThearchyHelios	bf98ce16b8	运行复核把 agent_field_truncated 算作缺口（degraded），和 agent_field_unverified 同一档：字段都记空值、答案能用，缺口是输出额度在推理阶段用完了	2026-10-04 11:14:41 +08:00
ThearchyHelios	a43c530fb8	结构化抽取被截断时加大额度重试，仍截断就照实说是额度在推理阶段用完了 ... 一次真实运行里 4 个开了按出处核对字段的 Agent 抽取全部失败：抽取关掉思考、额度 4096，可经 OpenAI 兼容接口接入的推理模型关不掉思考，额度在推理阶段就用完了（openai 抛 LengthFinishReasonError）；日志却叫人「稍后重试、去设置测试该模型」，两样都不解决问题。 - 额度默认至少 16384，节点配了更大的用节点的 - 认出输出被截断：openai 的 length limit 类错误、finish_reason=length、Anthropic 的 stop_reason=max_tokens；被截断时额度翻倍（最多 32768）重试一次，每次调用各记一行，被截断那次的用量照样记账 - 服务方嫌额度太大（400，报错里有 max_tokens 一类字样）时退回 8192、4096，不能因为额度提高反而抽不成 - 两次都截断：新日志 code agent_field_truncated（带 fields、max_tokens），原话说清额度在推理阶段用完、结构化结论没能写出来，下一步是换非推理模型或调大最大输出 token；字段照旧记空值、不以 0 代替。非截断类的失败照旧是 agent_field_unverified - 时间线给 agent_field_truncated 专门的标题、副标题和下一步，入口落到该 Agent 的最大输出 token；check-decode 补断言	2026-10-04 11:02:06 +08:00
ThearchyHelios	7cd52a24bf	数据目录 F2b / B3 跟进：合入 F2a 之后一对多关联后重复计算也可能只是提醒级（只凭外键推出的一对多），发布前检查不能再按规则编号认级别——服务端最小改动：门禁里 SQL 检查的问题带上检查本来的级别 sql_level（别的问题不带、序列化时不出现），界面按它写「错误 / 提醒」和拦不拦；老服务端不给时按受管档的 level 认；补后端测试和检查脚本	2026-10-04 02:52:43 +08:00
ThearchyHelios	6263725c2a	降档时报告页顶部写明出具档位和原因（B5）：出具声明和 issuance 事件另带结构化的 sql_checks（哪次查询、问题、受影响的引用、对应的缺口），证据页签在报告上方放出具横幅，SQL 检查导致的降档单列一块写在显眼处、不在其余缺口里重复；不是完整出具时「N 个数字都有出处」不再画成绿色	2026-10-04 02:33:15 +08:00
ThearchyHelios	31531925a9	写作指引说清 [[see:]] 只放句末、码值写含义（A4、B4）：写作规则后面加两条，依据标记渲染后不显示，写进句子中间会留下「以 为依据」这样的断句；涉及码值时写含义（「作废记录」），不写码值本身，数字核对不放宽。组装报告时认出拿得准的句中写法（「以 [[see:…]] 为」「根据、按照、基于、参见、详见 [[see:…]]」）记 inline_see，交回写作者重写，重写不好也不判失败；助手写报告节点的指引同样写明这两条	2026-10-04 02:24:49 +08:00
ThearchyHelios	9c8bed2f1b	合并查询的警告带上结构化字段：键类型不一致带 keys、detail，行数放大带 rows、input、input_rows、duplicates，结果截断带 rows、max_rows，随运行日志一起发出，界面读字段，不再从中文原话里解析	2026-10-04 02:17:32 +08:00
ThearchyHelios	2c160f0ac9	运行时间线看得到单条查询的 SQL 检查：调用工具节点、Agent 和协作团队里的查库调用，tool.end 事件单独带上这次查询的检查结果（只留给人看的字段）；preview 只有结果的前一截，检查结果以前通常被截掉	2026-10-04 02:17:32 +08:00
ThearchyHelios	f1d4582d4f	报告直接引用没通过 SQL 检查的查询时出具降档：报告里引用的查询格子、表格和依据（含合并查询的输入）有错误级检查就记缺口；按出问题的那条查询归并，同一条查询算出几个指标、又被引用时只记一句并列出受影响的引用；运行日志也按查询归并成一行，带上受影响的指标、问题、检查结果、来源节点和要改的栏；写作目录里给这些查询标「存疑」	2026-10-04 01:52:24 +08:00
ThearchyHelios	4c7cfa62b2	数据目录 F3 一致性：查询结果的截断判定抽成 data/engine.py 的 RowCollector，查询层和合并查询都调它，不再各写一遍	2026-10-04 01:08:42 +08:00
ThearchyHelios	787b2304dc	指标经过合并查询也认得出来源查询的 SQL 检查问题：合并快照没有自己的 checks，顺着 inputs 往下找，源库一对多重复计算的数不再经一次合并就完整出具	2026-10-03 10:40:47 +08:00
ThearchyHelios	84bf484c08	合入数据目录阶段 2B：基于数据目录的 SQL 检查——七条规则按依据状态定级，接入助手自查、发布门禁和运行时，出错的来源查询使指标降档 ... # Conflicts: # backend/app/api/evidence.py	2026-10-03 10:37:31 +08:00
ThearchyHelios	7f07fc370a	数据目录阶段 2B：运行时接上 SQL 检查——查询结果和快照带 checks、证据接口的查询步骤带上，契约指标的来源查询有 error 时出具降档	2026-10-03 10:32:54 +08:00
ThearchyHelios	8682324a6f	数据目录阶段 2B：发布门禁接上 SQL 检查——受管级别被 error 挡住、warning 进提示，发布前检查、自动修复和发布同一个口径	2026-10-03 10:31:19 +08:00
ThearchyHelios	ab1f42d2ce	合并查询的截断口径对齐查询层：取满上限之后确实还有下一行才算截断，恰好取满的完整结果不再被下游拒收	2026-10-03 10:28:59 +08:00
ThearchyHelios	98ebba384f	合入数据目录阶段 3：合并查询节点——跨库按键合并，截断输入拒绝，类型不一致与行数放大告警，证据可下钻到两边原始查询	2026-10-03 10:27:16 +08:00
ThearchyHelios	0d887efab5	合并查询节点：裁判摘录的标题写明是合并查询的结果，不再写成「数据源 合并查询」	2026-10-03 10:25:50 +08:00
ThearchyHelios	61cd2f7bd0	合并查询节点（三）：画图时校验输入（不存在、不是查询、不在上游、Agent 的结果）、别名和合并 SQL；助手的节点说明和搭图规则写清合并查询的使用时机	2026-10-03 09:39:15 +08:00
ThearchyHelios	b0c36b5880	截断跟踪：改正不继承 list 的理由说明	2026-10-03 09:36:40 +08:00
ThearchyHelios	8f75849a1c	合并查询节点（二）：证据面板展示合并的输入、合并 SQL 和警告，被引用的格沿逐格来历追到输入的那一格并接上输入的查询步骤；推断来源穿过合并下钻到原表格子，追不到的判为没有逐格来历；裁判摘录写明合并的输入并按底层数据源遮罩	2026-10-03 09:36:20 +08:00
ThearchyHelios	1f8c180703	合并查询节点（一）：新增 merge 节点和执行器——几次查询的完整快照落进内存 SQLite 按键合并，结果存成同形的查询快照，截断的输入拒绝、键类型不一致和行数放大给警告，并记下逐格来历	2026-10-03 09:27:48 +08:00