209 Commits

Author	SHA1	Message	Date
ThearchyHelios	dc5a113e29	反方审稿节点（后端）：报告写完后挑几句关键结论，各派一个只读 agent 站在反方写查询找反例，被推翻的让出具降档 ... 结论句裁判只看写作者挂的证据，可证据本身就可能挑过（只查了含退款的销售额）。反方审稿换个方向，自己查库去证伪： - 选句照裁判的预筛（judge.candidates）：挂了依据的、带比较或因果的在前，取前「最多审几句」句，裁判判成不是结论的不审 - 每句一个核查 agent（verify_agent.run_verify_agent）：工具只给这句引用的查询所在的数据源（指标按输入取自的查询、合并查询 按它合并的源算；没挂依据的在整份报告引用的源里查）；任务给这句结论和它挂的证据摘录（judge.prepare，遮罩照旧，编号改成 「原报告 Qn」免得和 agent 自己的 Q1 混淆）；理由里的数字只能引用自己的查询格子，裸数字被标出 - 审稿记录 challenge_artifact 按约定的形状随运行封存；台账只记 kind challenge，查询不进任何报告的写作目录 - on_refuted：degrade（默认）写 issuance_gaps 让出具降档，fail 判节点失败，flag 只记录；产出带实际的 on_refuted - 上限：句数、每句查询数、每句时长、全局每日金额，都按发起时快照的核查设置（run.options["verify"]，没有快照按设置当前值）， 节点上写了的盖过它；全局关闭、报告没有可审的结论句、报告文档读不到时直通并记 challenge_skipped - 日志按约定的 code 带结构化字段：challenge_skipped / challenge_same_model / challenge_limit / challenge_done / challenge_refuted - 整个反查（连同存记录、发日志）放在一个 @task 里：接着跑时不重复查库、不重复记账、时间线不重发 - 审批卡：human 的 _reviewed_reports 给被审的报告附上 challenge 概况（counts、最多 10 条 items、artifact、on_refuted）， 没审过就不加这个键 - 画布校验：要审的报告必须是上游的报告撰写节点（不写时取直接连着的那份或上游唯一的一份，多份要人选）；各项配置写错报中文、 执行时报同一句；反方模型和写作模型写成同一个给警告 - 占位期的直通测试只留双盲复算（反方审稿的直通行为改由 test_challenge_node.py 覆盖）	2026-10-05 13:57:38 +08:00
ThearchyHelios	e626b205b6	合入 SQL 差异说明重做（阶段性）：先判等价再说差在哪——规范形式一字不差才算等价，具体说法只说有把握的，其余给兜底并附规范化后不同的行；等价结论用执行比对守住	2026-10-05 12:58:42 +08:00
ThearchyHelios	77b5509cf1	合入期 2 变化三分法（后端）：同一工作流两次运行的指标变化拆成数据、口径、模板与 SQL，口径与数据都变时能严格拆分两种效应，数据变化按维度归因，每项追到两边的查询快照；基准优先取同一定时任务的上一次	2026-10-05 12:49:30 +08:00
ThearchyHelios	36569e1fa4	运行对比复核修正（第 3 轮）：行号相同的引用还要引用同一批维度值，记不出写入者时只看口径卡之前的节点，默认设置的登记按节点类型逐类核对 ... - Agent 两次引用的行号相同、都不是整份结果时，一边引用了的维度值（区域……）在另一边的快照里却没被引用（按区域排序多了北区、按金额取前 3 名名次变了），判为说不清，说明写出是哪个维度值、在第几行；不再把还在快照里的区域算成「数据没了」、给出远超 100% 的占比。另一边快照里真的没有了的照常是数据变化。数组字段里的单个元素同样核对。维度按两边整份结果认，遮罩列不拿来认，分不出维度的仍按行号认 - 两边都记不出写入者时，范围从整张图改为口径卡之前可能执行过的节点（它的上游加并行支路）：口径卡自己、只在它下游的写周报写不了它读到的值，不再被点名成来源；并行支路上的节点不说成「上游」 - 「整份结果」统一按引用了哪几行判断，容器一支不再单列 - 默认设置登记表的核对测试改为按节点类型：从各执行器出发顺着用到的函数（含就地 import、回调、类）找 cfg 读法，在字面量元组上循环读的键名认得出，认不出的变量键名直接失败；核对节点模块里每个读配置的函数都走到了，登记了不读的也算错。据此补登记成果节点出具契约读的报告节点三项（evidence_from、metrics_from、entities） - 补测试守住上一轮的几条规则：Agent 交的不同而代码节点的数没变是没变，只有这次运行的快照读不出来时说这次，默认设置同时改了结论句裁判时 Agent 只写模型，调不调模型由默认设置决定，报告节点在代码节点上游，改了几个节点时点名画布上靠前的	2026-10-05 12:28:38 +08:00
ThearchyHelios	02b08f9ad4	SQL 差异说明重做（第 2 轮补充）：在真实的 PostgreSQL / MySQL 上复查，浮点数求和的一段不调换先后、外层条件只把聚合结果和「相等就是一样」的分组键挪进 HAVING；排列数先算再展开 ... 为什么：第 2 轮的主体提交只在 SQLite 上执行比对。这次私起了 PostgreSQL 18 和 MySQL 8.0（复验者语料的那份数据）， 拿复验者的全部语料和自己针对新改写造的 22 对重跑，抓到两处在真实的库上结果不同、却判了等价的： - 套在子查询里的 UNION ALL 调换各支，外面 SUM：浮点数加的先后变了，1902.2 对 1902.2000000000003（PG、MySQL）。 - 外层 WHERE BINARY t.city = 'SH' 挪进分组子查询的 HAVING：MySQL 自己会把外层只涉及分组键的条件推进子查询的 WHERE 先筛行，不分大小写时和 HAVING 结果不同。 做了什么（backend/app/data/sql_semantics.py）： - _Sensitivity：PostgreSQL、MySQL 里对不知道是不是精确数（整数、定点小数）的值 SUM / AVG / STDDEV / VARIANCE，这一段 算「结果看行出来的先后」，连同给它供行的子查询、CTE 不调换来源、不排分组键、不并子查询。SQLite 不算（它用 Kahan-Babuska-Neumaier 求和，关联先后也不跟着 FROM 变；语料 120 对在 7 组数据上按精确值比没有差别）。 - 外连接按 WHERE 变成内连接、内连接的条件挪进 WHERE：三种库的优化器自己也做，执行先后不变，看先后的一段也照做； 只有 SQLite 写了 CROSS JOIN 的不挪。 - 外层 WHERE 挪进分组子查询的 HAVING 只挪聚合结果和「相等就是一样」的分组键上的条件；引用了好几次的简单 CTE 有 一处在看先后的一段里就不拆开（PostgreSQL 会先把它算出来存着）。只筛行选列的子查询照样并进求浮点数和的外层：三种库 自己也会并（PostgreSQL 的 subquery pull-up、MySQL 的 derived_merge、SQLite 的 flattening），执行先后一样（在两个 库上核对过结果一字不差）。 - 同名来源的排列先算个数再展开：十几个同名表时以前先把十几的阶乘个排列都列出来（一条 12 张表自连接的语句跑了两分钟 以上），现在超了上限直接按排好的先后。 - 模块说明照实写清上面几条和 SQLite 求和的假设。 测试：REGRESSIONS_R2 补这两处（PG、MySQL 的 UNION ALL 求和、MySQL 的分组键条件）；DIALECT_SAME 里两对需要在求和的 一段调换关联先后的 PG / MySQL 改写移到 KNOWN_UNRECOGNIZED（只给兜底说明）。 验证（最终代码）：tests/test_sql_semantics.py + tests/test_verify_agent.py 601 passed，tests/test_sql_equivalence.py 375 passed，全量 -n 8：7856 passed、11 skipped。等价改写 124 对认出 120 对（97%），不给表结构 117 对（94%）。复验者 vsadv 全部语料（928 次判定，SQLite / PG / MySQL 执行）无 blocker、判等价的没有一对执行结果不同，自己针对新改写的 32 对 同样；advfp 180 对等价对上具体说法 0 条；vsprobe 变异压测（种子 9、10）约 1.6 万对无误判等价、无异常；自己的压测 约 1.65 万条可执行，规范形式相同的组执行结果全一致。	2026-10-05 12:16:20 +08:00
ThearchyHelios	f16860f704	SQL 差异说明重做（第 2 轮）：规范化只留能讲清为什么保持语义的几步，结果看行出来先后的一段不动来源；具体说法先确认两边真的不同、另一边真的没有，其余给兜底 ... 为什么：第 2 轮复验抓到第 1 版规范化里一批不保持语义的改写（15 个 blocker），说明里一批假话、矛盾话（10 多个 major）。根子是借用了 sqlglot simplify 等现成改写、又把「相等」当成「一样」、没管结果看行出来先后的查询；说明这边 是先改名再比、只看这一段有没有那个条件。这一轮把改写收窄到每一步都讲得清为什么保持语义，说明这边每句话都先验证。 规范化（backend/app/data/sql_semantics.py）： - 去掉 sqlglot 的 simplify（Decimal 折叠 0.1 + 0.2、-(-x) 化成 x、三项加乘拍平合常量、BETWEEN SYMMETRIC 丢了 SYMMETRIC）、pushdown_projections、HAVING 挪进 WHERE（MySQL 不分大小写时同组的值各不一样）、只有一列的 IN 列表 写成 =（SQLite 里 a IN (b) 是 a = +b）。只留自己写的几步：AND / OR、比较两边、一个节点的加乘两边排序，NOT 套 比较翻过来，BETWEEN 拆开，IN 常量列表去重排序，COUNT(1)、MIN/MAX(DISTINCT)、IIF / IF 写成 CASE、CASE ELSE NULL、 恒真的 1 = 1 去掉，IS NOT NULL / NOT LIKE 各方言统一成 NOT (…)。 - 新增 _Sensitivity：取行（含有 ORDER BY 并列）、DISTINCT ON、窗口函数、GROUP_CONCAT 这类聚合、聚合里的散列、当成标量 的子查询，以及去重、分组、MIN/MAX 留下的值「相等却不一样」（MySQL 字符串、PG numeric、算出来的表达式）的一段， 连同给它供行的子查询、CTE，都不调换来源、不排 GROUP BY 键、不改 DISTINCT、不并子查询。SQLite 的逗号连接和 CROSS JOIN 按原文分开（SQLite 不调换 CROSS JOIN 两边）。 - 列名表（CTE、子查询）写进里面那段的别名，实表别名带列名、递归 CTE（含 SQLite 不写 RECURSIVE、CTE 引用自己或后面的）、 BETWEEN SYMMETRIC、FETCH WITH TIES 不走规范化；FETCH FIRST 写成 LIMIT；USING 只在简单写法下写成 ON。 - EXISTS 改写前先查聚合（含 ORDER BY 里的）和 OFFSET；合并只调换最外层不取行的 UNION ALL（PG/MySQL 另加按位置排序、 各支列名一样的嵌套）；后面有 RIGHT / FULL JOIN 时内连接不挪进 WHERE、开头的来源不调换。 - 子查询并进外层自己写（_merge_derived：只并内连接一侧、只筛行选列的），引用多次的简单 CTE 每处写回一份后整条语句 的别名重新改成互不相同的（压测撞到的：同一个 CTE 并进外层和相关子查询两处，里层别名遮住外层）；外层 WHERE 只挪进 分组子查询的 HAVING（同一个值）。几个来源的 SELECT * 先写成各来源的 t.*（sqlglot 展开 * 时把实表排在子查询前面）。 - 解析丢了写法的不在语法树上判等价：0x10 和 x'10' 这类字面量、换了名字的类型名（SQLite 的 STRING 是数值亲和）； SQLite 不带表名、带双引号、表结构里没有的列名保留大小写和引号（找不到这一列时被当成字符串）。 差异说明： - 换了表的一边照它自己的表说（以前把 B 改名成 A 的表，中文名、detail 归错表）。 - 新增 _Range：同一个对象只和常量比的条件按取值逐段算，留下的行一样的不说（IN 和 OR、冗余 IS NOT NULL、拆成两段的 时间、COUNT(*) > 1 和 >= 2）；关联条件比相等关系的分组；聚合只在参数是列时说。 - 新增 _Usage：说「另一边没有这个条件 / 没有按时间筛选」之前，看另一边整条语句（含相关子查询、CTE、CASE、判空时连 聚合参数）是否用这一列筛选；条件子查询里不带表名的列没给表结构时不拿来说具体的。 - 子查询要外面写法一模一样（含 NOT、IN 左边的列）才配对，位置照实说「id NOT IN 的子查询」；EXCEPT 按先后逐支比； order 只在最外层、没取行、没 DISTINCT ON / 窗口函数时说；LEFT 对 INNER 只在最外层、可空一侧没进 WHERE、结果不只是 可空一侧的聚合时说；DISTINCT 对同列 GROUP BY、MySQL 表名只差大小写不说成不同；互相矛盾的一对不说。 测试：tests/fixtures/sql_pairs.py 加 nums 表和一组专挑写法差异的数据（0.1 + 0.2、像数字的文本、'SH' / 'sh'）， 第 2 轮反例收进语料（_SAME_HARD 20 对、_SAME_R2 11 对、_DIFF_R2 36 对进执行比对；REGRESSIONS_R2 21 对、 DIALECT_SAME_R2 6 对、KNOWN_UNRECOGNIZED 4 对各方言只查结论）；执行比对共 7 组数据、372 对，标 same 而没认出的 不许有具体说法；test_sql_semantics.py 补第 2 轮的说法用例和 normalize_sql「只改参数」的用例。这些新用例在上一版 上有 109 处失败。 验证：test_sql_semantics + test_verify_agent + test_sql_equivalence 973 passed；全量 -n 8：7853 passed、11 skipped。 等价改写 124 对认出 120 对（97%），不给表结构 117 对（94%）。复验者的脚本：vsprobe 变异压测 6 个种子约 4.3 万对无 误判等价；在私起的 PostgreSQL 18、MySQL 8.0 上重跑 vsadv 全部语料无 blocker；advfp 的 180 对等价对上具体说法 0 条； 自己的压测 3 个种子各约 1.5 万条可执行，规范形式相同的组执行结果全一致。	2026-10-05 12:01:08 +08:00
ThearchyHelios	3254744f6d	运行对比复核修正（第 2 轮）：行段相同、一边是整份结果的引用不再算同一处，默认设置的变化只落到会读它的节点上，上游 Agent 交出的结果不同时不再说变化来自上游数据 ... - Agent 两次引用同一段行，一边是整份结果、一边不是（这次多了北区，没引用的西区还在快照里）：判为无法比较，写明哪边引用了整份结果、另一边引用了哪几行、结果共几行；快照读不出来、核对不了是不是整份结果的同样不算同一处。以前按同一处算，西区被算成「数据没了」，占比超过 100% - 图级默认设置的变化按「哪类节点运行时会读这一项」落到节点上（_CFG_KEYS，照各执行器经 NodeContext.cfg 读的配置项登记）：结论句裁判、结论句的处理只有报告节点读，不再把 Agent 记成配置变了；条件分支让模型分类、结构校验让模型修复、知识检索用模型重排时也读默认模型，同样落到它们身上。新测试按执行器源码核对这张表，执行器新读了一项没登记就失败 - 代码、数据整形这类节点的上游有 Agent、模型调用、人工审批等节点，两次交出的产出不同（工件按内容寻址，按工件 id 比；产出没落成工件的核对不了）：它交的数变了不再说变化来自上游数据，判为无法比较并点名是哪个节点 - 上游节点改了配置时说明里点名是哪个节点；默认设置那句拆短，写出跟着变的是哪几项（模型接入不写 provider） - 补测试守住复核列出的未覆盖规则：容器运行输入还原不了、合并查询的输入追不下去、上游只有运行输入变了、审批默认设置、图里 SQL 只改格式（代码节点在下游）、跨节点先配字面量相同的、少了一次查询、只有一边落在快照上、查过库的写入节点改了配置、代码节点上游有节点改了配置、旧口径叶子的出处说不清时不拆、单格引用换了行；变异 99 处全部打红	2026-10-05 11:28:41 +08:00
ThearchyHelios	d176ff77ff	运行对比复核修正（第 1 轮）：输入的出处追到合并查询的上游、Agent 引用的列和行段，没出处的数、数据没变数却变了的不再报成数据变化 ... 出处判定（每个指标的分类靠它）： - 合并查询：读合并结果的指标按别名一路追到喂它的每一份上游快照（嵌套的合并也追），上游 SQL 结构变了是 sql_changed， 不拆、不归因；合并节点多接、少接了输入也算结构变化 - 图里写死的字面量改了（'paid' 改成 'refunded'、系数、LIMIT）：执行的 SQL 只差字面量，但图里的 SQL 改过，算模板变化； 图里一字未改（定时运行代入的日期）才是参数。图里的 SQL 只改了空白、大小写的不算改过 - Agent 按出处交来的字段：还要引用同一列、同一行（段），两边都引用整份结果的不算换了；换了列、换了行段的说不清 （incomparable），不再把没引用的区域算成「数据没了」去归因 - 模型、人直接交出的值（Agent 没按出处交、模型调用、人工审批……）：值变了说不清是数据还是模型本身，判 incomparable； 它自己查的库结构变了、配置变了照常标出 - 代码等确定性节点：上游的查询结果两次一模一样、交出的值却变了的，判 incomparable，不再说「变化来自上游数据」； 上游只有运行输入变了的算参数 - 图级变化落到节点上：连线有增删的终点节点、默认设置改了且没有自行设置这几项的模型类节点，都算改了配置； 「模板和取数的 SQL 都没有变化」只在整张图都没变时说 - 运行输入是列表、对象的，按还原出来的完整值比，长度不变、内容变了的是参数变化 - 同一节点按 SQL 配对时先配字面量也相同的：Agent 换了先后查东区、南区，两条各自配上自己，不再配成两条「只有参数不同」 - 一边记不出输入是哪个节点写的，说清是哪一边没记录（不再写出「None」） 口径与数值： - 口径变了的指标，喂它的取数也变了、说不清的照样写进说明（只在一边才有的输入是改表达式带来的，不重复说）； 分类次序写进 compare() 的说明 - 千分位和不分组互换只影响显示，写进说明、不算口径变化；比率与否不同才算 - 升级前的口径卡没记小数位、显示格式：按那次运行图里的指标定义核对，定义也没有就不比，不再误报「小数位由 未设置 改为 1」 - 百分比：基准极小、这次很大时十进制量化放不下，退回浮点算，不再整个对比报 500 - 没设小数位的指标拆分：三个数按同一精度量化（最多 15 位有效数字），转成浮点交出去后两效应之和仍逐位等于总变化 - 维度归因标出用的是哪个输入、两边各自哪份快照（path、base_artifact、target_artifact） 接口：已经结束、只是没有封存清单的运行，409 说「没有封存清单，不能用于对比」，不再说「运行结束后才能对比」。 测试：补上复核指出的必测项（只一边对得上不给占比、只截断基准一侧、换了数据源、按旧口径小数位取整、写它的节点多查一次、 口径和 SQL 一起变不归因、小数位和比率变化、日期类型和常量列不当维度、合计行浮点误差、只改名称、结束过又接着运行的不当 基准），以及上面每一处修正的用例。32 处变异逐条打红验证，全部被测试抓到。	2026-10-05 10:20:29 +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	c55b1983f6	SQL 差异说明重做（第 1 轮）：先判等价、再说差在哪——规范形式一字不差才算等价，具体说法只说有把握的，其余给兜底并附规范化后不同的行；等价结论拿 SQLite 执行比对守门 ... 为什么重做：过去五轮按方面归纳任意 SQL，每轮修好一批又冒出一批（第 5 轮还回退过「只在 IN / EXISTS / 标量子查询里用到的 CTE 里的不同」），收不拢。改成先判两条 SQL 是不是一回事，不是的话只说有把握的不同。 做了什么（backend/app/data/sql_semantics.py）： - 新增 explain_sql_diff(a, b, dialect=None, *, schema=None, names=None, labels=("A", "B")) -> SqlDiff （equivalent、items、fallback、text_diff、level）。两边各自规范化，每一步只做保持语义的变换；同一级的两个 规范形式语法树逐节点一样才算等价（不比生成的 SQL：sqlglot 生成 SQLite 时把 CAST(x AS DATE) 写成 DATE(x)）， 否则一律不等价、条目一定不为空。三级：optimizer（sqlglot 的 qualify、eliminate_subqueries、merge_subqueries、 eliminate_ctes、pushdown_projections、simplify，给了数据源的 schema_cache 就按它认列、展开 SELECT *）、 light（不认列）、parsed（只统一大小写、空白、引号）。 - 不用的 sqlglot 规则：unnest_subqueries（OR 里的标量子查询改成 CROSS JOIN，子查询没有行时整条都没了）、 canonicalize（日期比较加 CAST，SQLite 里 CAST(… AS DATE) 取的是数字）、normalize（合取范式人读不懂）； simplify 去掉同一列上比较的合并、字符串常量比较、等式移项、DATE_TRUNC 改区间（取决于列类型、排序规则、方言）； merge_subqueries 不并外连接可空一侧算出来的列。 - 本模块自己的几步：去括号、ASC、OFFSET 0，COUNT(1)→COUNT(*)，IN 列表去重排序，EXISTS 写成 SELECT 1， DISTINCT↔GROUP BY，原样透列的子查询换掉，RIGHT JOIN→LEFT JOIN，WHERE 筛掉了没关联上的行的外连接写成内连接， 内连接写成逗号连接，起规范的名字（CTE 叫 cte1…、CTE 的列叫 c1…、别名按表名和层数，同名来源排列着试）， 交换律成立的地方排序。 - 具体说法的门槛：两段读的来源对得上（一样，或只差一处说得清的）才逐项比时间列、筛选条件、聚合与去重计数、 选出来的列、分组键、HAVING、取行和排序、UNION 还是 UNION ALL；条件里的子查询两边各一个、外面一样的往里比 （第 5 轮回退的 IN-CTE 反例在这里说出来）；原文是 LEFT / RIGHT JOIN、规范化成内连接或调了方向的照原文说； 牵涉 CTE 算出来的列、自己关联自己、说不准的子查询的不说具体的；两边给人看一样的不说。 - 兜底：一条具体说法都没有时给 aspect="other"「两条 SQL 的写法不同，未能归纳成具体差异，请对照原文」，只覆盖 一部分时追加「另有未能归纳的差异，请对照原文」，fallback 为真；text_diff 是 difflib 比两边 sqlglot pretty 的输出，最多 40 行。 - diff_facets 签名不变，交给 explain_sql_diff 比两份 facets 记下的原文，返回它的 items。normalize_sql 判 「只有参数不同」不变，补了测试。 守门（tests/test_sql_equivalence.py、tests/fixtures/sql_pairs.py）：虚构库（users、stores、orders、 orders_archive、order_items、refunds、payments、shipments）上 5 组固定种子的数据加 1 组极端数据（空值、重复、 边界值、悬空外键、空表）。305 对 SQL（113 对已知等价、192 对不许判等价，含复验者以前造的、在这几组数据上结果 不同的 91 对）在不给和给表结构两种情况下各判一次：结果不同的绝不判等价，标 diff 的不判等价，换个先后问结论 一样。旧测试五轮复核里报过不同的 234 对、意思一样的 56 对（SQLite / PostgreSQL / MySQL）原样收进来只查结论。 压测（变异 + 等价改写，每个种子约 1.87 万条）时找到、已经堵上的不保持语义的改写： - merge_subqueries 把外连接可空一侧的常量列并进外层；merge 时同一个 CTE 并进外层和相关子查询两处互相遮住； - 没给表结构时 qualify 把 WHERE / GROUP BY / HAVING 里和列别名同名的名字当成别名（SQLite 先认列），把 SELECT 列表里和前面别名同名的名字展开（库里不认 SELECT 列表里的别名）：这时不出 optimizer 这一级； - UNION（去重）、INTERSECT 调换各支：去重留先出现的值（SQLite 里 2 和 2.0、MySQL 不分大小写时 'SH' 和 'sh'）； UNION ALL 带 LIMIT、按名字 ORDER BY 的也要看哪支在前，SQLite 合并结果的排序规则取最左一支：现在只在调换 不改变结果时排；SQLite 从子查询读 UNION 的类型亲和； - 一元加号在 SQLite 里去掉类型亲和、解析时却丢了；ORDER BY 别名换成表达式后撞上另一个别名； - 没有 ORDER BY 的 LIMIT、聚合里既不分组也不聚合的列：调换来源、DISTINCT 写成 GROUP BY、RIGHT 写成 LEFT 都会改变实际取到的行，这样的一段不做；两边都写了 COLLATE 的比较不对调。 验证：tests/test_sql_semantics.py + tests/test_verify_agent.py 519 passed，tests/test_sql_equivalence.py 307 passed，全量 -n 8：7706 passed、11 skipped。已知等价的 113 对认出 111 对（98%），不给表结构时 109 对 （96%）。压测 4 个种子各约 1.5 万条可执行：规范形式相同的组执行结果全一致，能执行的规范形式结果和原文一致 （带 CAST 的不比：生成 SQLite 时写法变了），生成的等价改写认出 2113/2115；复验者留下的 1201 对里可执行的 440 对没有误判等价，结果相同的 302 对认出 276 对。 仍做不到的（只给兜底或认不出等价）见模块说明：IN 子查询和 EXISTS 互换、窗口函数前后按分区键筛、三项以上的 加乘换结合、和方言有关的同义写法、SQLite 里套一层子查询的 UNION、去重 UNION 调换各支、LATERAL、递归 CTE、 没给表结构时别名和列同名的。假设列没有声明非默认的排序规则（SQLite 比较两列取左边那列的，表结构里看不到）。	2026-10-05 09:28:08 +08:00
ThearchyHelios	1e90a5a502	运行对比：结果里不出现非数和无穷大，维度列的非数当文字配对 ... 接口按 allow_nan=False 写 JSON，结果里混进一个 NaN 或 Infinity 就是 500。指标值、输入值、十进制相减原本就只出 有限的数；剩下两处补上：维度列里的非数（float NaN）写成文字再当键，度量加起来、占比算出来超出浮点范围的给空。	2026-10-05 08:58:18 +08:00
ThearchyHelios	467f9599fd	运行对比：补合并查询、循环里多次执行的配对测试，口径卡读不出来时的说法补上「的」 ... 合并查询只记在节点台账里、SQL 另在 merge.end 里，快照文件不在了照样比得了 SQL；循环里同一个节点执行几次的按先后 一一配上，多出来的一次标「删除」。口径卡指标集读不出来、被改过时的说明改成「口径卡「X」的指标集与哈希不一致」。	2026-10-05 08:55:57 +08:00
ThearchyHelios	c89aaba10c	运行对比：Agent 换了查询先后时按 SQL 配对，Agent 改了配置时按出处交来的字段不再报成数据变化 ... 查询配对改成一轮比一轮宽：同一节点、同一工具里规范化 SQL 相同的先配上，剩下的再按「第几次」配，最后跨节点按 SQL 配。以前严格按第几次配，Agent 这次换了查询的先后，两条都被配成「结构变了」，没按出处交的字段跟着被判成 SQL 变了。 Agent 按出处交来的字段：SQL 没变而 Agent 自己的配置（提示词、工具）变了时，它可能换了取哪一格，归为模板变化 （sql_changed）并写明是哪个 Agent；调用工具节点的格子由口径卡的 cell() 定，不受影响。	2026-10-05 08:52:04 +08:00
ThearchyHelios	b66eb955b5	定时任务小修：数字按 isdecimal 认，输入生成失败的原因不再说成模板写错 ... - 「²」这类字符 isdigit 为真、int() 却认不得：写进 cron 或每页条数时会冒出英文的 ValueError（被全局处理器 回成 400）。改按 isdecimal 认，照常回中文的 422 - 库里的 cron 或时区后来坏了时，立即运行记下的原因以前写「输入模板无法渲染」，其实模板没错：改成照实说 「无法生成这次运行的输入」，后面跟是哪一项	2026-10-05 08:50:57 +08:00
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	bb176f6f9d	定时任务小修：输入模板的字段名去掉首尾空白再存，后台通知任务的异常记日志 ... - 「 stat_date」原样交给运行，入口节点认不出它、必填项照样报缺：保存时去掉首尾空白，去掉后重名的拦下 - 通知扫描是另起的后台任务、没人 await：出错时异常留在任务里，只会在回收时冒出一句「从未取回的异常」。 包一层，出错记日志，下一拍照常	2026-10-05 08:47:18 +08:00
ThearchyHelios	6d11145a39	定时任务接口：增删改查、预览、变量清单、立即运行、触发历史和测试 Webhook ... - 按前后端约定的 Schedule / Fire 形状返回；Webhook 地址和签名密钥加密存放，接口只给主机和末 4 位、有没有密钥 - 创建、修改时校验名称、cron、时区、工作流存在、正式运行要有发布版本（没有就说明原因、建议改探索运行）、输入 模板和入口字段；不对回 422 {detail（中文）, field}，请求体自己解析，连 JSON 写坏了也回中文 - PATCH 带 version，条件 UPDATE 做乐观锁，对不上回 409；webhook.url 省略表示不改、空串或 null 表示删除，secret 省略不改、空串去掉；只停用、改名不重新校验工作流——工作流撤了发布也要能先把任务停下来 - 预览给下几次触发（UTC）和按下一次触发渲染的输入，带工作流时只查字段名、不查缺的必填项（用户还在填） - 立即运行和到点触发同一套规则（重叠跳过、正式运行只从当前发布版本发起），运行记在点按钮的人名下；触发时间 取到秒，同一秒连点交回同一条，不会发起两次 - 触发历史按创建时间倒序翻页，Fire 带运行现在的状态和推送记录；删除任务连同触发历史和推送记录，发起过的运行留着	2026-10-05 08:43:44 +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	26595b70f7	合入期 1 数字推演沙盘：证据面板里改口径卡的输入、排除查询结果的行，即时看指标和报告引用处的新值；推演只读、不写运行记录，醒目标注推演非出具；口径卡的容器型输入此后另存完整值 ... # Conflicts: # scripts/check-all.mjs	2026-10-05 07:53:42 +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	007a13d72b	SQL 语义复核修正（第 5 轮）：读同一张表的派生来源不再透成一张表、相关子查询分内外层、条件分组连接聚合按层计数，去重、UNION、最后出几行进比较 ... 上一轮（3e0ab05）之后复验清单里还有一批用例返回空列表（A24 只报了一半）。最初的问题 1–3（paid / refunded 两个 CTE 换用哪一个的漏报、多一个 vip CTE 时配错、内连接换先后报出自相矛盾的两句）在第 3、4 轮已经修好，这次仍失败的是另外几类，根因各不相同： 读同一张表的几个派生来源：两个原样透出的 CTE（已付、未付，SELECT * FROM orders WHERE …）透过去，p.amount、o.amount 都成了 orders.amount，SUM、WHERE、时间列、ORDER BY、GROUP BY、关联条件、派生列的定义里用的是哪一份都分不出来（CTE 链、子查询套子查询同样）；CTE 和它自己读的 orders 关联（父单、子单）也一样；同一个 CTE 关联两次时 _roles 设的 role 透过去就丢了。现在算完一段的来源后看各来源一路透过「只读一个来源」的派生来源最后读的是谁（_base），同一段里有几个读到同一个来源的，其中的派生来源标 opaque（_seal）：through、时间列都不透过去，照写两边按结构配好的共同编号（已付配已付、未付配未付），给人看写名字（paid.amount），单看一条语句「只用到一张实表」时也照样写出是哪一份。时间条件给调用方对照数据目录的 detail 另一直换到实表（TimePredicate.table）。只有一个来源读那张表时照旧透过去。 相关子查询读外层那张表：EXISTS、标量子查询、LATERAL 里 c.parent_id = o.id 和 c.id = o.parent_id 都写成 orders.id = orders.parent_id（有子单还是有父单、之前还是之后有过订单分不出）。现在比较用的写法里外层的列在列名后面带「^」（_depth，往外几层带几个；带在列名上，排比较两边的先后只在两边表名一样时才受影响），给人看时内外读同一个来源的照写别名、留着表别名；两边各剩一个 EXISTS（NOT EXISTS）时配成一对说。 按整条语句去重：各段的条件、分组键、连接、聚合原来去重成一个集合，外层的 status = 'paid' 和 IN / EXISTS 子查询、关联进来的汇总 CTE、UNION 另一支里的同一个条件合成了一个，外层少了它报不出来（分组键、连接、聚合同理；聚合去重后只剩「多算了 SUM」一句，算出来的列又被压掉）。现在每一项记下在哪一层（Part / JoinFacet / Aggregate 的 scope，见 _layers：最外层、UNION 第几支、派生来源的共同编号、条件子查询「?」；只筛行的 CTE 和用到它的那一段同层，读同一张表的几个同段 CTE 各算各的层），按（层, key）去重；比的时候同一项在一边出现在几层算几个（_Compare.leftovers）：同一层的先配，剩下的不管层也配（条件挪一层常是同一个口径），配不完的才报，另一边也有、只是层少了的说清是哪一层（「原流程在外层也只保留 status = 'paid' 的行，盲算在外层没有这个条件」）。条件子查询那一层多出来的不单说：外层那个条件已经报了，原来还会多出一句读起来像外层也这么筛的「只保留 state = 'done' 的行」。时间条件在列、范围都一样时也按层数比。 去重、合并、最后出几行：DISTINCT、UNION / UNION ALL 原来不进任何一面，分组键挪一层也看不出来。SELECT DISTINCT（这一段没有分组、聚合时）当这一段的分组键收：和按同几列 GROUP BY 一样的不报，一边在子查询里先去重报「去重」；各段的 UNION / INTERSECT / EXCEPT 记下合并方式和支数（SetOpFacet，同层的先配，挪了层的同样写法也配上）；最后出来的行按什么分（Facets.grain：分组键 / 只出一行 / 逐行）在分组键都配得上、两边都汇总了时比（先在子查询里按用户分组、外层数用户数，对外层按用户分组）。 说清楚：自己关联自己、关联的方向反了，两边都写 a.amount 时说清各自的 a 是关联条件里出哪一列的那个（Part.roles，实表自连接同样）。 模块说明、Part / JoinFacet / TimePredicate / Aggregate / Facets / FacetDiff、unmatched / leftovers / joins / render 的文档按现在的做法改写，做不到的照实列出：读同一张表的几个派生来源同段时只认配好的编号（一边两个 CTE、另一边把其中一个换成关联实表再在 WHERE 里筛，算不同；同一个 CTE 关联两次对定义成两个一样的 CTE 也算不同）；挪了层又多一层时挑哪一个说成多出来的有顺序约定；条件子查询那一层多出来的不单说；UNION 各支按位置配；不加表前缀引用外层的列认不出；LATERAL 里的相关条件两边各说一句；最后出几行只在两边都汇总时比；COUNT(DISTINCT x) 对数 DISTINCT 子查询行数照报不同（有空值时确实不一样）。 测试：复验清单里的用例逐个补成测试（三个方言，CTE 和子查询写法），另加意思一样、不该报的反例（关联换先后、改名、单个透出的 CTE、自连接换别名、相关子查询换别名、两边都两层、条件挪进汇总 CTE、分组写在 CTE 里、GROUP BY 对 DISTINCT、一样的 UNION、最外层 UNION 对包一层）。新加 132 项，其中 119 项在 3e0ab05 上失败，其余 13 项防误报的两边都通过；原有 192 项和 test_verify_agent 照旧通过，全量 7245 项通过。另拿测试里出现过的每条 SQL 在三个方言下和自己比（1051 次），都没有不同。复验清单最后一条只到「b_s」就截断了，看不到全文，按开头补了 DISTINCT 子查询对不去重、对 COUNT(DISTINCT) 的对照。	2026-10-05 06:11:40 +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	e7c8d2a1f3	可验证报告复核修正（第 1 轮）：运行信息拿已核对的事件对照，报告徽标连同数字一起算，遮罩判定宁严勿宽，各分支在浏览器里有确定的检查 ... - 页面核对加 ⑥ 运行信息：运行结果看封存范围内最后一条结束类事件的类型，运行类别看运行开始事件记下的运行参数， 出具档位认最后一条出具判定（不再信元信息指的那一条）；页面显示事件里的值，元信息写得不一样算不通过、计入总览。 工作流名、版本、起止时间、节点名称绑不进封存，单列一组写明取自运行记录，封存说明里也写明要到系统里一并对照 - 报告标题旁的徽标连同正文里的数字一起算，旁边写分项：重算全部哈希的伪造只在 ⑤ 露馅，徽标不能还写着通过。 分块条目多时不通过和无法核对的都列在外面，有无法核对的显示「部分无法核对」和分项计数；⑤ 改叫「数字与取值」并分开数， 读屏分别读作数字、取值，「显示格式由服务端渲染」只附在带出处的数字上；无出处数字的说法改成未使用引用标记 - 服务端不会给出的状态算不通过：被引用的工件不在清单里、非查询快照标着遮罩、工件既没内容也没说明；报告文档导出时 已不在服务端，总览不再是绿色的通过，写「有 N 份报告未能核对」，报告处写明是服务端已没有这份文档 - 认 json.dumps 写出的裸 NaN / Infinity，没被改过的文件不再误判不通过；哈希对得上但读不懂的照实写「无法核对」， 和哈希不一致分开说 - 宽屏打开出处面板时正文让出右边一栏，表格里右对齐的数字不再被面板盖住；补上斜体（不用后行断言，较早的 Safari 也能执行） - 封存哈希、运行 ID、工作流名直接写进页面，不执行脚本时写「尚未核对」而不是一直「正在核对」；脚本挪进 head， 执行后核一遍页面顶部写出的封存哈希和数据里核对用的一致 - 成果节点和运行结束事件的规范字符串，只在封存范围内每次数据源查询都对得上无遮罩的快照（或确实没交回数据）时才给： 升级前的运行从工具快照认出查询快照，协作团队成员的查询认不出就按带遮罩算，数据源现在设了遮罩的按工具名就挡 - 封存核对不一致的 409 改成一句固定的话，不再叠冒号、让人去本来就在的记录页；失败结束的运行在页面封存说明和导出提示里 写明之后继续运行会重新封存；记录页上左边写着「已封存」却不能导出时，原因写在屏幕上 - tests/bundle_samples.py 用虚构数据真实生成九份样本页（遮罩快照、两份报告、早期运行、失败结束、两条出具判定、 服务端缺文件、裸 NaN、别的运行的文档），check-bundle 断网打开逐项断言，在上面篡改引用链、运行信息、拿掉被引用的口径卡， 量宽屏面板，看不执行脚本的样子；把核对改成恒通过、徽标不看数字等七种改坏法都会变红。pytest 补遮罩判定的三种形状、 事后设遮罩（去掉接线即变红）、页面静态内容和样本页本身	2026-10-05 05:30:50 +08:00
ThearchyHelios	3e0ab059b1	SQL 语义复核修正（第 4 轮）：外连接按主表比、算出来的列按定义比、时间列透过 CTE 认、筛的先后照报、没用到的 CTE 不算，同名却不是同一个的派生来源说清各是什么 ... 上一轮（db91c9e）给派生来源加了结构标识、按结构配对之后，复验还有一批用例返回空列表或者报得自相矛盾。按根因分几类改： 外连接：joins 第二遍按涉及的来源配对、不分方向，orders LEFT JOIN refunds 和 refunds LEFT JOIN orders 配成一对后类型、条件都一样，一句不说（db91c9e 引入的回归），RIGHT JOIN 对调、两个 CTE 对调、子查询写法同样漏。现在 JoinFacet 记下主表（keep）和可空那一侧（nullable），LEFT / RIGHT 按主表比：对调了报「原流程以 orders 为主表外连接 refunds，盲算以 refunds 为主表外连接 orders」，LEFT JOIN 和两边对调的 RIGHT JOIN 是同一回事、不再报成类型不同（原来列为做不到）。同一段 WHERE 里拿可空那一侧的列比较、IN、LIKE、BETWEEN、IS NOT NULL 的（JoinFacet.rejects），这次外连接按内连接比：盲算把可空一侧的条件写进 WHERE、LEFT JOIN 实际成了内连接的照报；IS NULL、OR、套在 COALESCE / CASE 里的不认。 算出来的列（Computed，新的 expression 一面）：聚合只按去重后的 (函数, 参数) 集合比，SUM(p.total) - SUM(r.total) 对反过来、退款率分子分母对调报不出；派生来源里不是聚合的列不进任何方面，net.v 谁减谁、x.total 取的是付款还是退款合计、amount * 0.9 对 0.8、CASE 的口径、窗口函数的分区和排序、RANK 对 ROW_NUMBER 都是空列表。现在最外层选出来的列（先剥掉 ROUND、CAST、COALESCE 给默认值这类外壳）按算法比，用到的聚合一样、位置换了照报；派生来源里被外面用到、又不是原样透出一列的列按定义比。只差在聚合上、聚合那一面已经报了的，按透过去的那一列筛时间、时间那一面已经报了的，不再报第二遍。比较时加法、乘法的两项排好先后，DATE()、CAST(… AS DATE)、::date 统一成一种写法，免得写法不同被报成算法不同。 时间：时间条件的列透过「同一列套着日期函数、CAST、MIN / MAX」算出来的派生列，一直换到实表（TimePredicate.via 记下路过的列）：日期表达式写在 CTE 里，按支付时间还是下单时间筛照样报出来，带上表名、列名给调用方对照数据目录（三个方言的 DATE()、CAST … BETWEEN、两个同名 CTE 对调后的 MAX(paid_at) 对 MAX(refunded_at)）。 结构标识和配对：_Derived 里往里套着的派生来源原来一律写「@」，net 是 paid.total - refunded.total 还是反过来写出来一样。现在按结构写的 shape 写法里引用派生来源的地方写它自己的结构标识（里面那段按 shape 写出来再取摘要），配对之前比较的两边也按结构标识排先后；配对之后仍按共同编号排（配成一对的两个派生来源里面稍有不同时结构标识就不同，按它排会把同一个比较排成两个方向）。_align 同一级先看条件重合、再看名字：两边都叫 paid、一边筛已付一边筛未付时不再按名字配反。配成一对的派生来源里两边起名不同的列按定义配成同一列（total 对 sum_amt，原来列为做不到；_renamed），两边各剩一列时也配上，定义的不同照报。 筛的先后：派生来源取前几行（LIMIT、OFFSET）或算了窗口函数（这一列又不是分区键，含 DISTINCT ON）时，外面的条件不再透成里面那张表的条件；Part 另记一路透到底的写法（pierce）和挡住它的是什么（stage），两边只差在这里时报「原流程先算 t 的窗口函数、再按 status = 'paid' 筛选，盲算先按 status = 'paid' 筛选、再算 t 的窗口函数」「先取 t 的前 10 行、再筛」，时间条件同样。 没用到的 CTE：原来逐段收集连定义了没用的 CTE 里的条件也收，盲算定义了只筛已付的 CTE 却直接查 orders 报不出来，没用的 CTE 里多一个条件又会被报成多筛了一遍。现在只收从最外层一路引用到的段（_Statement._enliven）；例外是两边都定义了同一个 CTE、一边把它关联进来一边没用到，没用到的那边照样收它，免得它里面的聚合、分组被说成一边独有（连接那一面已经说了关联了它）。 说清楚：两边同名的派生来源其实不是同一个时（t1 / t2、a / b 定义对调），「按 t1.total > 100 筛选」两边写法一模一样，读起来自相矛盾。Part 记下用到的派生来源各列的来历（origins，一直换到实表的列），给人看的写法依次退到一律写表名、带上来历（t1.total 即 SUM(orders.amount)）、来历也一样（两个 CTE 只差里面的条件）时说「盲算的 paid 对应原流程的 open」。 自己关联自己：同一个 CTE、同一张表在一段里出现两次，两个别名按各自在关联条件里出的列区分（_Source.role），b1.total > b2.total 写反了报得出来，换了别名、换了关联先后不报（原来列为做不到）。CTE、子查询自己写了列名的（WITH t(n) AS …，递归 CTE 常这么写）按写的列名认列。 模块说明、Part / JoinFacet / TimePredicate / Computed / Facets / FacetDiff、unmatched、joins 的文档按现在的做法改写，做不到的照实列出：两边起名不同、各多出不止一列且定义都不同的列仍算两列；全换了的派生来源不配对；条件改得一个都不重合又各起了名字的同形派生来源只能按先后配；自连接两个别名在关联条件里出的列一样时分不出；三项以上的加法乘法换序、括号展开算不同算法；QUALIFY、GROUP BY 之后才筛的先后不认；外连接链里连带变成内连接的、套在函数里或写在外层 WHERE 的不认；不是 facets 算出来的 Facets 只能按位置编号比。 测试：复验清单里的用例逐个补成测试（各方言、CTE 和子查询写法），另加意思一样、不该报的反例（LEFT / RIGHT 对调、WHERE 筛主表、外连接链换序、0.9 * amount、DATE 对 CAST、按分区键在窗口前后筛、两边都先取前 10 行、列起名不同、自连接换别名换先后、没用到的 CTE）。新加 64 项，其中 48 项在 db91c9e 上失败，其余是防误报的，两边都通过；原有 128 项和 test_verify_agent 照旧通过，全量 7113 项通过。复验清单最后一条只到「WITH base AS (SE」就截断了，看不到全文，按开头和已知缺口一并处理了 CTE 自连接。	2026-10-05 04:58: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	a0016493de	可验证报告服务端：GET /api/runs/{id}/bundle.html 把已封存运行的报告导出成自包含的 HTML，浏览器断网也能核对 ... - bundle/build.py（纯函数）：封存范围内每条事件带 seq、类型、节点和 data_sha256（与 runner 封存同一算法），浏览器据此重算清单； 白名单事件（运行开始、报告自查、口径卡升版、出具判定、报告和口径卡的节点完成、数据源没有遮罩的查询返回）另带规范字符串， 运行里有带遮罩的快照时，成果节点和运行结束事件的预览可能带出查询结果，也只给哈希；报告文档和它引用的口径卡、查询快照按原字节 base64 嵌入，遮罩快照（查询时记下的或数据源现在设的）只给 id；封存之后追加的事件单列、不进清单 - template.html + verifier.js：样式和脚本内联、零外链，内容安全策略按哈希只放行核对脚本；数据块转义 < > & 和 U+2028/2029。 浏览器逐项核对事件内容、封存清单、工件哈希、引用链、报告里每个数字（照搬 cell_value / same_value 判等）， crypto.subtle 拿不到时用自检过的纯 JS SHA-256；醒目写出封存哈希，并写明只证明内部一致、真伪要去系统里对照 - 接口复用证据接口的封存判定：未封存、或运行还没结束（接着跑的运行留着旧封存，跑完会换掉清单哈希）回 409，封存核对不一致回 409； 附件名「<运行名>-可验证报告.html」按 RFC 5987 编码；只读，不追加事件 - artifact_store 加 read_bytes：原样取回工件字节，默认复验哈希，verify=False 交给浏览器去核	2026-10-05 03:58:02 +08:00
ThearchyHelios	9852e4d33a	数字推演接口 POST /api/runs/{run_id}/evidence/whatif ... 证据面板点开口径卡上的一个数，改输入的值、排除它背后查询结果的几行，看指标和报告里引用它的地方会变成多少。 推演不是出具：不追加事件（last_seq 不变）、不落工件、不改报告。 - 只认这次运行封存范围内的工件：沿用证据接口的 _sealed / _sealed_loader 白名单，另加封存的节点产出和封存的指标集 里写着的 value_artifact；排除行只认封存范围内的查询快照 - 口径卡按台账（一期以前按节点产出）找，循环里算过几次的取报告引用的那一份；nodes.* 按口径卡那次执行之前的产出还原 - 遮罩和证据面板查询步骤同一套：查询当时记下的加数据源现在设的，合并查询按它合并的数据源算 - 未封存（停在审批、还在跑）的运行也能推演，sealed 为假；封存核对没过的同样标出 - 请求形状不对回 422 whatif_bad_request，改动不合法回 422 whatif_bad_input（中文说明），卡、指标、报告不存在回 404 - 只在确有指标变化时列出引用了这张卡的下游口径卡	2026-10-05 03:44:29 +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	db91c9eaf6	SQL 语义复核修正（第 3 轮）：两边的 CTE、子查询先按结构配好对再比，不再拿「不写编号」的写法补配 ... 上一轮给派生来源（CTE、FROM 里的子查询）只编了位置编号，编号错开时再按不写编号的写法（派生来源一律写「@」）补配一遍。复验发现三处问题，根因相同：派生来源没有结构上的标识。一是漏报：两个 CTE 都算出 total（付款合计、退款合计），编号一致时 SUM(p.total) 对 SUM(r.total)、WHERE p.total > 100 对 r.total > 100、ORDER BY、HAVING、差值写反，都被补配吞掉、返回空列表。二是误报：盲算多一个排在前面的 CTE（vip），原流程的 t（@1）按编号配给了盲算的 vip（@1），报出「关联 t 表的条件是 orders.user_id = users.id，盲算是 users.id = users.id」「盲算关联了 t 表」。三是误报：内连接换了先后（FROM paid JOIN refunded 换成 FROM refunded JOIN paid），编号跟着对调，比较的两边按编号排成两个方向，报出两条自相矛盾的话。 现在 diff_facets 先给两边每个派生来源算一份结构标识（_Derived）：里面读到的实表（FROM / JOIN，往里套着的也算）、选出来的各列规范化后的定义式（total 是 SUM(orders.amount)）、分组键、里面的条件、整段规范化后的写法和起的名字；按从严到宽几级一对一地配：整段一样，表和各列定义、分组一样，表和列名一样，表和名字一样，最后三级只在两边各剩一个时才配（只是表一样、只是名字一样、只是列名一样）；同一级几对都配得上时先配同名的、再配条件重合多的、最后看先后，哪一级都配不上的不配，没用到的 CTE 也参加配对。配好之后第二条 SQL 的派生来源改用第一条里对应的编号（配不上的另起编号），facets 记下原文（Facets._origin，不进比较和 as_dict），按共同的编号重新分析一遍再比：比较两边谁在前、关联条件的先后都按共同编号排，不再受位置编号左右。_Compare 去掉了不写编号的补配（删掉 Part.anon），loose 里派生来源的编号照写，筛选按同一列配对时列也带编号。 连接：内连接、CROSS JOIN 按涉及的来源和条件比（JoinFacet.sides），不按哪一侧是关联进来的，实表的内连接换了先后也不再报；配成一对的两边名字不同时两个名字都说；一边独有的内连接、关联进来的那一侧另一边也有时，报它接上的另一头（FROM stores JOIN orders、另一边只查 orders：多出来的是 stores，不是 orders；Facets.sources 记各段 FROM / JOIN 的来源拿来对照，条件里子查询的来源不算），已经说了「关联了」的表不再另说一遍「用到了」。取行：CTE、子查询里的取行按所属派生来源配好的编号（LimitFacet.scope_key）配对，一边多一个限了行数的 CTE 不再和另一边的 CTE 凑对；LATERAL 子查询照写它的别名。筛选、HAVING：两边各自独有、读起来却一样的条件（p.total > 100 和 r.total > 100 都只读得出 total > 100）配成一对、改用带来源名字的写法说，不再各说一句。 模块说明、Part / JoinFacet / LimitFacet / Facets、unmatched、joins 的文档按现在的做法改写，做不到的照实列出（外层按名字引用的列两边起名不同算两列；读同一张表、各列定义一样的两个派生来源两边都改了条件又改了名时可能配反；全换了的两个派生来源不配对；自连接分不出两个别名；LEFT JOIN 对调成 RIGHT JOIN、内连接的单表条件写在 ON 还是 WHERE、三张以上不带条件的表换先后仍算不同）。测试补上三处问题的反例（CTE、FROM 子查询、改名又改先后的写法）和上面各项，原有 99 项照旧通过。	2026-10-05 03:36:12 +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	d5e9ef39ae	SQL 语义复核修正（第 2 轮）：CTE、子查询起的名字不再进比较，条件里的子查询选出来的列名也不算；派生来源按位置编号，编号错开时再按不写编号的写法配一遍 ... 上一轮只去掉了条件里子查询的表别名，子查询整段写进外层条件的 key 时还带着各自起的名字：标量子查询、IN 子查询给选出来的列起的名字（AVG(amount) AS avg_amount），子查询里 FROM 的子查询别名（s 换成 agg），以及外层引用 CTE、FROM 里的子查询算出来的列时的来源名（派生来源的 key 就是别名）。CTE 改个名，外层的 total > 100 就被报成两边各有一个、互相矛盾的条件；双盲复算里盲算的名字本来就是自己起的，会被说成换了口径。 现在派生来源（引用 CTE 的表、FROM / JOIN 里的子查询和 LATERAL 子查询）按位置编号作比较用的 key：从外往里一层一层地编，CTE 在第一次用到的地方编号，写成 CTE 还是 FROM 里的子查询、CTE 定义的先后都不影响；给人看的写法照写名字。不拿里面那段查询的写法作 key：里面差一个条件，外层按它的列写的条件就全跟着变，同一处不同会报好几遍。条件里的子查询写进外层 key 时，引用 CTE 的表、子查询（含 LATERAL）、子查询自带的 CTE 定义都换成编号，只看取值的子查询（IN、EXISTS、标量子查询）去掉选出来的列名；FROM 里的子查询、CTE 定义选出来的列名留着，外层按名字引用它们。LATERAL 的别名原来没登记成来源，按「别名写错了」照写，一并改成派生来源。 编号只看位置：一边多出一个排在前面的 CTE（比如盲算先关联一个筛 VIP 的 CTE），后面的编号就错开了，同名的 CTE 反倒比原来按名字比时多报出两条自相矛盾的话。Part 加 anon（派生来源一律写「@」、不写编号），diff_facets 每个方面先按编号比，比不上的再按 anon 一对一地配，配上的不算不同；比较两边的先后先按 anon 排、分不出再按编号；连接先配完全一样的再按关联的表配，免得错开的两个 CTE 被配成一对、说成关联条件不同。编号对得上时照样分得清是哪个 CTE 的同名列（p.total > r.total 写反成 r.total > p.total 照报）。筛选条件配对改按列的比较写法（Part.column_keys，CTE、子查询的列写「@.列」），CTE 名不同、阈值不同时说成「按 total > 100 筛选，盲算按 total > 200 筛选」，不再拆成两条各说各的。 仍按名字比的只有 CTE、子查询选出来、外层按名字引用的列（一边叫 total、一边叫 sum_amt），写进了模块说明。	2026-10-05 02:37:33 +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	a427b53874	SQL 语义复核修正：同一个口径不再因为子查询里的别名、HAVING 里的别名被报成不同；取哪几行逐段比，连同 OFFSET 和取前几行时的排序 ... 条件里套着的子查询（EXISTS、IN (SELECT …)）原来按外层的来源整个照抄进外层那个条件，别名原样留着：带别名和不带别名的同一条 NOT EXISTS 被报成两处筛选不同，双盲复算就会说盲算换了口径。现在每段 SELECT 在语法树上记段号（复制出来的子查询靠它找回原树上那一段算好的来源，相关子查询照样到外层找），改写时每一列按它所在那一段认，子查询里的表去掉别名；比较两边排序时也按那一段的来源排。HAVING 引用 SELECT 别名（HAVING s > 100）换成别名指的表达式，和 GROUP BY 别名一个读法，聚合函数里的同名列不换。 取哪几行原来只看最外层 LIMIT 的行数：CTE 里 LIMIT 10 和 LIMIT 100、OFFSET 0 和 OFFSET 10、取前 10 行时降序和升序都报成没有不同，取到的却是不同的行。Facets 加 limits，逐段收集（最外层、CTE、FROM 里的子查询；条件里的子查询已经整个写在条件里，不单算，免得报两遍）行数、跳过的行数，以及这一段的排序（ORDER BY 1、别名换成 SELECT 里的表达式）；OFFSET 0 算没写，排序只在限了行的段里比。原来的 limit（最外层行数）照旧保留。	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	e46ff55fd4	数据源查询工具加 force_readonly：核查的 agent 另起一路、没有审批关卡兜底，要查的源却可能可写。开了就不管源可不可写，一律按只读守卫检查：先过一遍和 run_query 相同的检查（多条语句、结构变更照原来的说法拒），再按只读判，写语句交回「这次查询只允许读取数据」、不执行，数据原样；查询照常落查询快照。工具描述跟着写「只读」，审批判定也不再把写语句当危险调用。只靠守卫这一道：连接池按源缓存、不分只读与否，不能为此另起一个只读池（缓存键相同，会把这个源平时用的可写连接换成只读）。build_datasource_tools 透传这个参数，不传时一切照旧	2026-10-05 00:26:04 +08:00
ThearchyHelios	031aae9343	SQL 语义：data/sql_semantics.py 给双盲复算、运行对比、反方审稿共用。normalize_sql 按方言解析、重新生成（去注释、统一关键字和空白、按方言转换不加引号的名字），再把字符串和数字换成占位符：只改了字面量的两条 SQL 规范文本相同（定时运行每期日期不同，不算模板变了），字面量按规范文本里的先后列出；解析不了退回逐词规范化，照样认得出只改了字面量。facets 把查询拆成表、连接（类型 / 关联进来的表 / ON 条件）、WHERE 合取式、时间条件（列 / 运算符 / 取值）、分组、聚合（函数 / 参数 / 去重）、HAVING、LIMIT：别名换成真实表名，比较两边排好顺序，GROUP BY 1 和别名换成表达式，CTE、子查询逐段收集，只透出一张表的 CTE 换回那张表的列，逗号连接写在 WHERE 里的等式算关联条件，相关子查询到外层找别名；解析不了带 parse_error，从不抛。diff_facets 每处不同给一句中文（「A 按支付时间 paid_at 筛时间，B 按下单时间 created_at」「A 排除了 is_deleted = 1 的行，B 没有」「A 对 order_id 去重计数，B 没去重」），两边叫法可以换成「原流程」「盲算」，列的中文名可以用 catalog_labels 从数据目录取；只换了一张表时说一次「查的是哪张表」，其余按不写表名的写法比。复用 sqlcheck 的 dialect_of、_conjuncts、_bare_column、_unparen	2026-10-05 00:22:51 +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	aa828021d7	核查设置：设置里加 verify 一组，双盲复算、反方审稿、审批质询共用。核查模型（接入、模型）空着沿用证据裁判模型的取值链；双盲复算 {启用, 允许的相对误差默认 1e-6, 查询次数, 时长}、反方审稿 {启用, 每份报告最多审几句, 每句查询次数, 时长}、审批质询 {启用, 每次查询次数, 时长}，另有核查每日金额上限，上限存 null 表示不限。写法照裁判一组：PUT 先查后写，有一项不对整个请求回 422、说明写设置页上的叫法；库里存坏的项读出来按默认，三项各自那一组逐项补。verify_settings(session) 给节点和质询接口读，verify_model_spec(session, node_config) 按节点 → 设置 → judge_model_spec 取模型，整组取一级、不跨级拼。核查的每日计数不从设置接口进出，另加只读的 GET /api/settings/verify/spend 给设置页看今天花了多少	2026-10-05 00:06:03 +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