2da4d34fec
合入期 4 整合 J1：双盲复算写业务日期加类型门槛（两边的时间列都在表结构里声明为日期 / 时间类型才写，原因说清是哪一列）；跟上 SQL 差异说明收尾的测试与预览夹具（time_range 改为兜底变体，新增 time_column）；按位置取自另一份快照遮罩列的输入判为无法复算；可验证报告里被改过、解析不出的口径卡按内容认遮罩
2026-10-06 16:23:26 +08:00
a7b8854dc4
双盲复算复核修正（第 1 轮）：业务日期只认带日期的类型、原因按哪一边说清；遮罩列在子查询或 WITH 里改了名不再收窄，交给盲算的分组取值按 SQL 认出取自遮罩列的；按位置取的格点名原因、认不出出处的不写进计算式、不再改变容器输入的判法
...
业务日期的类型门槛：只有时刻的 TIME / TIMETZ 不再算（一天里的几点几分不是日期，MySQL 还常拿它存时长；和 catalog.is_date_column 同一个口径，记成业务日期后 SQL 检查会对按真实日期列统计的查询一直报错误级），原因说「只有时刻，不含日期」。类型照表结构里记的说「类型是 X」（introspect 存的是 SQLAlchemy 反射出来的类型，SQLite 里写成 TIMESTAMPTZ 的反射成 NUMERIC），没写类型的列反射成「NULL」，按没有声明类型说。被采纳的一边有问题说「被采纳的盲算按时间筛的列……」，未被采纳的一边另说清为什么也要看它（两边都是日期列时，审核人选的才是业务日期按哪一列）。数据源还没有可用的表结构（未探查、探查失败）时说表结构不可用，不说这一列不在表结构里。上传表格建的数据源（origin=upload，节点认出后经候选的 uploaded 交给 derive）日期一律存成文字，原因说「来自上传的表格，表格里的日期一律按文字保存」，不说成用户声明了 TEXT；预告和真写逐字一致。
遮罩：收窄补等值条件、交给盲算的分组取值，都按 SQL 认出取值来自遮罩列的名字（复用审批质询的 inquiry._derived_hidden：起别名、套函数、经子查询或 WITH 转一道、写在列名表里的都认，解析不了又写着遮罩列的整份算）。以前外层按 area 分组、area 在子查询里由 region 改名而来时照常补上「area = '华东'」，差异说明还原成「region = '华东'」进了审批卡、对照工件和目录日志，「华东」也进了盲算的任务；和遮罩列无关的 WITH 照常收窄。按位置取自遮罩列的输入直接交回「输入 vars.res.rows[0][0] 取自设置了遮罩的列，不能用于复算」（同 cell() 的说法），「核对不了」改成「无法核对」。伸进查询结果的行、却认不出取自哪一列的（下标不是字面量、改过形状的结果没带快照 id 和数据源名）计算式里写成「其他输入」，不把卡上的值交给盲算。按位置取的格落在的快照只为认遮罩算遮罩，不再进重算的快照清单：以前同一个指标里装着它整份行的容器输入会对上它、被它的遮罩列挡下。
2026-10-06 13:42:51 +08:00
314dd1248a
双盲复算写业务日期加类型门槛：两边的时间列都得在表结构里声明为日期 / 时间类型才记
...
- dual_check_facts._business_date 收下 derive 交来的表结构：两边按时间筛的列都要声明为 DATE、DATETIME、
TIMESTAMP、TIMESTAMPTZ、TIME（带精度、带时区的写法也算，大小写不论）。文本（SQLite 常把日期存成文字）、
整数（Unix 秒、20260901 这类日期键）、表结构里查不到、没声明类型的都不记，原因说清是哪一边的哪一列。
差异说明认时间列只看列名和常量像不像日期，这道门槛补上 sql_semantics 模块说明里写明的约定。审批卡上的
预告和真写共用 derive，逐字跟着变。
- 测试的表结构和虚构库（dual_check_shop.build）把下单日、支付日声明成 DATE，另可建声明成文本的一份；补门槛
的正反例：各种日期 / 时间类型的写法、文本、整数、缺列、没有表结构、表结构里写成大写、预告同一套判断。
- 修两个已知失败：跨两张表的条件、同一列的时间范围，收尾版差异说明只给兜底，改成断言兜底且不写；derive 里
「只涉及一张表」那道检查从 SQL 走不到了，改用直接构造的差异说明单测；「其他方面」换成真能说出具体方面的
关联方式（LEFT JOIN 对内连接），断言不写、原因说清差在关联；表不在表结构里那条改用有效记录条件，仍走
derive 自己的认表检查。
2026-10-06 12:11:08 +08:00
d7f6b4d756
真实模型验收用的虚构零售库：60 天订单截止昨天，埋退款行、下单日和支付日错开、取消单三个口径陷阱，华南每周都高于华东（供反方审稿推翻错话），手机号列供遮罩验收；append_day 给定时任务验收制造「只数据变」；测试守住陷阱确实在、同一天生成的库一样
2026-10-06 11:44:58 +08:00
c549b15150
合入期 4 期 3 收尾：核查缺口分「核查未通过」「核查未完成」两组，时间线认得核查类日志代码；双盲复算写目录的预告和真写逐字一致（被目录挡下的那一边也说清原因，几个指标落到同一项时按组合预告）；反方审稿说清「根本没反查」和「到底降不降档」；字段叫法挪到 labels.py；记录页的核查工件有名字和说明
2026-10-06 11:31:11 +08:00
7a6a8283aa
合入 SQL 差异说明收尾：判等价只用保持语义的规范化（去掉依赖表约束的改写），解析保真守卫拦下已知会被读错的写法（MySQL 反斜杠转义、特殊数字写法、比较 / 按位 / 前缀 NOT 没加括号地混用、PostgreSQL 符号运算符与 || 混用等），具体说法只在简单形状上说四类，其余给兜底并附逐行对照；回归语料与执行比对守住等价结论
2026-10-06 09:18:35 +08:00
095cc4c8ab
SQL 差异说明收尾（第 2 轮）：PostgreSQL 符号运算符和 || 混用不判等价；条件写在聚合里、时间窗口、反连接、经主键定死的列不再说错
...
- 保真守卫（_misread）：PostgreSQL 写成符号、sqlglot 却当成 LIKE 那一级来读的运算符（~、~*、~~、~~*、@@、-|-、@> 等）
和别的二元运算混用时拦下（PostgreSQL 里它们和 ||、& 同级、从左往右，status ~ 'p' || 'x' 是 (status ~ 'p') || 'x'）；
另拦 PostgreSQL 的前缀 @、|/、||/、COLLATE 后面的 ::；不知道是哪种库时拦块注释里套着的 /*、紧跟着字的 --、#、双引号
括起来的名字（MySQL 默认的 sql_mode 里是字符串）。都只给兜底，附原文的逐行对照。
- 条件写在聚合的参数里（SUM(status = 'paid')、COUNT(… OR NULL)、COUNT(NULLIF(…))、SUM(amount * (1 - is_deleted))）
算作这一边对这一列有条件（_Usage 的 case），另一边多出同一列上的 WHERE 条件时不再说「这一边没有这个条件」，只给兜底。
- 时间：timed 认 BETWEEN 和时间列上 LIKE 像日期的模式（paid_at LIKE '2026-09%'），时间窗口不再被说成有效行过滤；
「另一边没有按时间筛选」之前看另一边可能是时间窗口的条件（聚合参数里的时间比较、date_key、stat_month 这类列、
20260901 / 202609 这类整数、上下界一对），有就不说；认不准是不是时间列的窗口（_window_like）不说成有效行过滤。
两边的时间列在不同的表上时写成「表.列」。
- 反连接：用到 LEFT JOIN 可空一侧的列的条件（WHERE r.id IS NULL、r.order_id IS NULL）不说成有效行过滤，时间列在
可空一侧时也不说按它筛时间。
- 给了表结构时，聚合参数所在的表的键在组里定死了（按 u.id 分组时的 u.city），MAX 对 MIN、AVG(DISTINCT) 对 AVG 不说。
- 另一边原文也 LEFT JOIN 了、规范化因为结果不怕重复去掉了的表，不说「另一边没有关联」。
- 回归语料：收尾第 1 轮之后复验报的全部 blocker / major 收进 sql_pairs（_DIFF_R5、_DIFF_TIME_R5、_SAME_HARD_R5、
_SAME_SCHEMA_R5 执行；REGRESSIONS_R5、EXPLAIN_TRAPS_R5 只查结论），新增对应的测试。
- 模块说明照实补上：新增的守卫、时间条件的认法、只给兜底的情况、收窄换来的代价、MySQL 按默认 sql_mode 读的假设。
认出等价的比例：语料（SQLite，给表结构）169 对里 157 对，和改动前一样；PostgreSQL、MySQL 也不变；不知道是哪种库时
少认 1 对（same:quoted-names，双引号括起来的名字）。
2026-10-06 08:10:41 +08:00
9eeb11d29e
双盲复算写目录的预告和真写逐字一致：被目录挡下（已确认、驳回过、和已有条件合不起来）的那一边也带上写到哪张表哪一项、本来要写什么和原因；几个指标落到同一项上时，preview_joint 按真写的办法（归拢、拿掉驳回的、对目录）把每种选择组合算一遍放进对照工件的 catalog_joint，组合太多的那一项不预告；真写的日志 written 带上写进去的值。对照工件里盲算的输入另带 rationale_doc（核查 agent 组装的理由文档，裸数字已标出）；补图级测试，按审批卡的认法断言预告与实际写入一致
2026-10-05 18:56:04 +08:00
6767b5f2fc
SQL 差异说明收尾（第 1 轮）：不靠约束改写、解析保真守卫、具体说法只在简单形状上说四类
...
- 去掉所有依赖表约束的改写：凭主键 / 唯一键去掉 LEFT JOIN、去掉 DISTINCT，COUNT(列) 当 COUNT(*)，凭 NOT NULL 去掉
IS NOT NULL（_unique_key_bound、_constraint_rewrites、_not_null_source 删掉）。SQLite 的类型亲和、COLLATE、部分唯一
索引、MySQL 的隐式转换都会让「唯一」不成立，宁可认不出；约束只拿来让说明少说（schema_cache 的外键也读进来）。
- 解析保真守卫（_misread，按方言切词、按括号深度分层）：MySQL / MariaDB / 不知道方言时字符串里的反斜杠转义、1_000 和
0o17 这类数字、挨着写的字符串常量、同一层里没加括号地混用比较运算和 IS / IN / LIKE / BETWEEN / 另一个比较、按位运算
（含 COLLATE）和别的二元运算混用、XOR、不知道方言时的 ||、MySQL 以外的 &&：不在语法树上判等价，只给兜底，text_diff
给原文的逐行对照；normalize_sql 逐词规范化时数字和紧跟着的名字算一个字面量。
- 具体说法重写（_Explainer）：只在两边都是简单形状（一段 SELECT、实表、普通连接，没有派生表、合并、窗口函数）时说，
只说四类——底层表上的时间列不同、一边多一个只涉及一张表的列和常量比的筛选条件（另一边对这些列没有任何条件、不是
被蕴含的、按取值逐段算过不是恒为真）、顶层聚合函数或去重不同、关联的表或关联类型不同（后面没有内连接引用可空一侧）；
每句先确认真会影响结果（条件恒为假、结果看不见行、参数在组里定死、只取一行、表结构的键 / 外键说明不起作用时不说），
别的一律兜底。
- 回归语料：第 3 轮补充之后的复验报的全部 blocker / major 收进 sql_pairs（_DIFF_R4、_SAME_HARD_R4、_SAME_SCHEMA_R4
执行；REGRESSIONS_R4、DIALECT_SAME_R4、CONSTRAINT_TRAPS_R4 只查结论，约束陷阱另造小库执行），执行比对复验者列的 9 个
改松后拦不住的反例也收进来；旧的具体说法测试按新规矩改写。
- 模块说明照实写：等价怎么判、不靠约束、保真守卫、只给兜底的情况、已知做不到的。
认出等价的比例（给表结构）：169 对里 163 → 157（96% → 93%），少的 6 对都是要靠约束才成立的；不给表结构 148 / 156 不变。
2026-10-05 17:35:51 +08:00
1491b5c7f3
双盲复算复核整改：指标自己的筛选范围不再写成有效记录条件，盲算不再看到原流程的列名，差异说明收窄到这一格
...
写数据目录（dual_check_facts.py）
- 有效记录条件只收「排除无效记录」的条件：被排除的取值是退款、作废、测试这类（或码值表里写着这类意思），
标记列只认留下有效记录的一边（is_test = 0、is_valid = 1、deleted_at IS NULL）；取值出现在指标名称、口径说明、
所在分组、运行输入里的，用到分组列的，一律不写，原因写明「可能是指标自己的筛选范围」。以前「华东销售额」的
region = '华东' 会被记成订单表人工确认过的有效记录条件，之后所有查订单表的工作流（含下一次盲算）都只看华东
- 目录里已有的有效记录条件被采纳的一边也按它筛了的，和新条件合起来写（已确认的不改，照实说）；没按它筛的不动。
以前整项替换，两边都用着的 is_test = 0 会被静默丢掉。推断的去重规则说法不同的也不替换
- 业务日期只在两边都按时间筛、按的列不同时才写；一边根本没按时间筛的不写
- 采纳了不去重的一边不写去重规则：那是指标自己的算法，写成「不去重」会把别的指标带偏
- 同一次裁决里几个指标对同一项给出矛盾的说法，整组都不写
节点（nodes/dual_check.py）
- 盲算任务里不再给原流程结果的列名和同一行的维度列名：分组的只给取值（日期说成「2026-09-02 这一天」），
原 SQL 写死的文字列连取值也不给；只有几项输入都来自查询又没写口径说明、列名看不出取舍时才给列名。
以前「order_date 为 2026-09-02」等于告诉盲算按下单日归属，下单日和支付日的陷阱正好漏掉
- 差异说明先把两条 SQL 收窄到这一格（只留算出这一列的那一项，分组的按这一行的分组值改成等值条件）再比，
多列查询、分组取一行时不再混进「选出的列」「分组」这类噪声，只差一个方面的也写得进目录
- 产出状态：全部一致才是 agreed，一个都没核成是 unchecked，核成一部分是 partial；产出和台账加 counts；
无法复算的指标发 dual_check_unchecked {metrics: [{id, name, reason}]}
- 共用一格的几个指标触顶时每个指标各发一条 dual_check_limit
- 查询次数刚好用完、交回的格子是真查出来的照常比对（时长、金额触顶仍按无法复算）
- 审核人没选或选了认不出的照实记「审核人没有对指标作出选择」，不再替人记成「两边都不对」
- 盲算先单独做第一个，其余最多 3 个同时进行，避免串行撞上运行单段的时长上限
配置
- 画布校验：双盲复算配了失败重试报错（重试会把盲算整轮重做、再问审核人一次）；enabled 用 is 判断，0、1 不再放过
- 发起时的核查设置快照：子工作流（按运行时的取法读）里有双盲复算、反方审稿节点时也快照
- 助手节点说明补一句不要给双盲复算配 retries
测试：补上遮罩两道防线、规范化后一致但值不同、两个输入都对不上、只复算配置的指标、原值为 0、摘要最多 3 条、
驳回、多列查询、分组取一行、指标筛选范围不写目录等用例；每条核心改动都做过去掉实现、测试变红的验证
2026-10-05 15:54:03 +08:00
87f0979a90
SQL 差异说明第 3 轮补充：NOT 按德摩根律往里推；结果看行出来先后的一段不拆 BETWEEN、不去 MIN / MAX 里的 DISTINCT
...
- NOT (p AND q) 写成 NOT p OR NOT q、NOT (p OR q) 写成 NOT p AND NOT q（p、q 是条件时，三值逻辑下照样成立），在
外连接改写、唯一键判断之前也做一遍。复验者的「意思一样却说了具体的不同」压测脚本在本轮的按主键去掉 LEFT JOIN
上找到了：ON 写成 NOT (NOT (s.id = o.store_id) OR NOT (s.region = 'east')) 时认不出按主键关联，说成「B 用 LEFT
JOIN 关联 stores 表，A 没有」；往里推之后两边一样。
- 结果看行出来先后的一段不拆 BETWEEN、不去掉 MIN / MAX 里的 DISTINCT、不按德摩根律改写（一个 BETWEEN 和两个比较
估算出的行数可能不同，换一种扫描的先后，GROUP_CONCAT 拼出来的先后就跟着变）。
- 测试：德摩根律的等价改写进 _SAME_R3，NOT (a AND b) 对 NOT a AND NOT b 进 _DIFF_R3；「排除」那条说法跟着往里推
之后的写法改。
2026-10-05 15:06:48 +08:00
f91615624d
SQL 差异说明第 3 轮补充：靠主键认出 COUNT(主键) 和带主键的 DISTINCT；结果看行出来先后的一段不再去重条件、去重排序键、换 COUNT
...
- 给了表结构时：这一段里一定不为空的列（主键、NOT NULL，不在 LEFT JOIN 可空的一侧）上的 COUNT(x) 就是 COUNT(*)；
只有一张表、选出来的列包含它的主键（或者每一列都不为空的唯一约束）时 DISTINCT 去掉（_constraint_rewrites）。
- 在真实的 MySQL 8.0 上压测时看到：GROUP_CONCAT 那一段同一个条件写两遍，MySQL 按条件估算的行数变了、换了关联的
先后，拼出来的先后就不同。结果看行出来先后的一段（见 _Sensitivity）不再去掉重复的条件、重复的排序键，不把 COUNT(x)
换成 COUNT(*)，外层条件不挪进这样的分组子查询的 HAVING；有 GROUP_CONCAT、窗口函数、既不分组也不聚合的列时不去掉
负数 LIMIT。差异说明里只差在重复写的分组键、排序键上的不说成不同。
- 测试：COUNT(主键)、带主键的 DISTINCT 进 _SAME_SCHEMA_R3；可空一侧的主键、不带主键的 DISTINCT 进 _DIFF_R3。
2026-10-05 14:45:39 +08:00
4557e72c8e
SQL 差异说明第 3 轮补充：按唯一键关联又没用到的 LEFT JOIN 去掉，解析时换了写法又没留位置的函数名不在语法树上判等价，说法照原文写列
...
- 按主键 / 唯一约束关联、关联进来的表在 ON 之外没用到的 LEFT JOIN（左边每一行正好关联上一行或补空）去掉，结果
怕不怕重复都一样；给了表结构时「按主键关联 users」和「user_id IN (SELECT id FROM users)」不再说成「A 关联了
users 表，B 没有关联它」（没给表结构时关联可能把行复制，这句话是对的，照说）。schema_cache 的 unique 也读进来。
- 原文写的函数名在重新生成时不见了、又没有哪个节点记下它（PostgreSQL 的 DATE_PART 解析成 EXTRACT、不留位置；
date_part 返回浮点数、EXTRACT 返回 numeric），这条语句不在语法树上判等价；CAST 一类（x::INT、MySQL 的
CONVERT(x, CHAR)）不算。
- 规范化按关联条件换成同一列之后，差异说明给人看原文写的那一列（「A 按 users.id 分组」不写成 orders.user_id）。
- 留着的 HAVING TRUE 不说成「分组后只保留 TRUE 的组」（读不懂、也没说到真正的不同），只给兜底。
- _finish 的说明按现在的先后重写。
测试：按主键关联的 LEFT JOIN 收进 _SAME_SCHEMA_R3（不是唯一键、后面还接着别的表的进 _DIFF_R3），DATE_PART 进
REGRESSIONS_R3，补「按主键关联对 IN 子查询」的说法测试。
2026-10-05 14:32:07 +08:00
77f3119cf9
双盲复算节点：按输入盲算、代回原式比对，不一致交人裁决，只差一个方面时写进数据目录
...
占位的直通桩换成真实现（engine/nodes/dual_check.py）：
- 按输入复算：口径卡上输入来自查询快照的指标，每个这样的输入另起一个看不到原 SQL 的只读 agent（verify_agent），只给它指标名、
口径说明、这个输入在计算式里是哪一项（「输入1」，不露取数节点和 cell() 的行列）、分组结果那一行的维度列、数据源的数据目录；
它交一个格子引用，由代码从它自己的快照取值。盲值用原式代入盲算的输入算（engine/recompute.py，取整同口径卡），按相对误差比，
原值为 0 时按绝对误差。两个指标用到同一格只盲算一次。合并查询、整段结果、遮罩列、文本输入不能单独复算，记「无法复算」、不花钱。
- 一致不挂起，产出 agreed；不一致时逐个对不上的输入用 explain_sql_diff 说清差在哪（规范化后一致却值不同的写「差在数据」），
完整对照落成 card_artifact 工件（避开审批 payload 的截断），按约定的 payload 用 ask() 挂起。审核人选 a 无缺口，选 b、都不对
写 issuance_gaps，on_reject 为 fail 时节点失败；明确驳回按人工驳回失败；没选的按「都不对」。触顶、核查模型不可用、交不出数的
指标记「无法复算」并写缺口，核查模型本身用不了时后面的盲算不再一个个去试。
- 设置读发起时的快照，没快照的读一次记进 checkpoint；读设置、盲算连同比对、差异说明连同工件、写目录各在一个 @task 里，审批恢复
重放时不再调用模型、不再计费、不再写，事件也只发一次。日志按约定的 code 和结构化字段发（dual_check_skipped / same_model /
agreed / disagreed / resolved / catalog / limit）。盲算的查询只发 tool.end（role: verify），台账只记一条 kind: dual_check，
报告的写作目录不含盲算的查询；用量计入节点。
选择写进数据目录（engine/dual_check_facts.py）：只在审核人选 a 或 b、差异只有一条具体条目、又对得上目录事实时写——时间列不同记
业务日期，一边多一个只涉及一张表的筛选条件记有效记录条件，聚合只差去不去重记去重规则，都按被采纳那一边的写法。照对话提案的
规矩核对，记为人工填写、已确认，备注写明运行、节点、指标；已是同样的已确认说法不再写，确认过的不同说法不覆盖、照实交回原因。
测试：虚构零售库埋了退款行、下单日对支付日两个陷阱，盲算模型是 MockChatModel 剧本，覆盖一致、不一致挂起与 payload / 工件形状、
三种选择与 on_reject、写目录与幂等、不覆盖、全局关闭与节点覆盖、发起时快照、重放不再执行盲算、写作目录不含盲算查询、用量、
同模型提示、触顶、不能单独复算的输入。占位节点的旧测试只留反方审稿。
2026-10-05 14:23:43 +08:00
08f75d4002
SQL 差异说明重做（第 3 轮）：堵上第 2 轮复验报的不保持语义的规范化，认出复验指出的等价改写，具体说法只说真会影响结果的不同
...
为什么：第 2 轮复验报了 14 个 blocker（判了等价、结果却不同）和 11 个 major（意思一样，却说了具体的不同；说法
自相矛盾）。等价判定的框架（两边各自规范化、语法树一字不差才算等价）不变，这一轮逐个查清是哪一步不保持语义、
哪一处说法没先确认「真的不同」，按类堵上，并在执行比对语料里收进全部反例。
等价判定（backend/app/data/sql_semantics.py）：
- 外连接改内连接（_rejects）分「一定是空值」和「一定不成立」两种：NOT 只能套前者，NOT IN 子查询、NOT IN ()、
x op ALL (…)、NOT (x = ANY …)（含解析成函数的 ALL (ARRAY[…])）、PostgreSQL 的 || 都留得下没关联上的行。
- 改列别名、EXISTS 写成 SELECT 1、去掉列名、CTE 的列改名之前，先看本段的 WHERE、ON、相关子查询还按名字引用不引用
这些别名（_alias_refs，SQLite 的 WHERE、ON、相关子查询都认列别名，真实的 SQLite 上试过）；qualify 遇到子查询引用
外层列别名时不走认列那一级。
- USING 的列和列别名同名不改写（ORDER BY 先认别名）；派生来源的列同名不走认列那一级（SQLite 认第一个）；没有
GROUP BY、别处也没有聚合的 HAVING TRUE 留着（PostgreSQL 里只出一行）。
- RANDOM() 这类不确定的函数轻量一级也不走；SQLite 双引号里的名字只看这条语句里看得见的表（_column_in_scope）；
子查询的别名遮住外层、又认不准是哪一个的不走规范化（SQLite 里层找不到列就往外层找）。
- MySQL：/*! … */ 会执行、! 比比较结合得紧，不在语法树上判等价；-- 后面不跟空白是两个减号，先拆开再解析；
BETWEEN 上下界类型不同或不是常量时不改写。
- 函数节点记下原文写的名字（_mark_surfaces）：SQLite 的 MOD() 和 %、PostgreSQL 的 LOG10(x) 和 LOG(10, x) 解析成
同一个节点，记下名字就不会判等价；同义写法按方言文档列在 _SAFE_RESPELLINGS。
- 自己压测找到的老问题：结果看行出来先后的一段（GROUP_CONCAT 等）按 WHERE 把 LEFT JOIN 改成内连接，SQLite 的
扫描先后真的会变（EXPLAIN QUERY PLAN 一个先扫 refunds、一个先扫 orders），这样的一段不再改写。
认出复验指出的等价改写（每一步都写了为什么保持语义，执行比对守门）：
- EXISTS 里的去重、分组、UNION / UNION ALL，IN 里不影响取值集合的 GROUP BY、DISTINCT、UNION；分组后 COUNT(*) >= 1。
- 不分组、只取可空一侧跳过空值的聚合时 LEFT JOIN 写成内连接（COALESCE(SUM(r.amount), 0) 等）；ON 之外没用到、
结果不怕重复的行的 LEFT JOIN 去掉；同一组 AND 里已经保证、或表结构里确定不为空（nullable、主键）的 IS NOT NULL
去掉；给了表结构、类型一样时按关联条件相等的两列换成同一列（分组、排序、选出来的列）。
- 一模一样的分组键、排序键；SQLite 的负数 LIMIT、PostgreSQL 的 LIMIT NULL、LIMIT 的整数算式。
具体说法：被关联条件定成相等的列、IN / EXISTS 里的去重分组、只取可空一侧的聚合、没用到又不怕重复的 LEFT JOIN、
各支自己已经去重的 UNION ALL、只出一行时的排序、自己关联自己的关联条件，都不再说成具体的不同（只给兜底）；
<>、NOT IN、NOT LIKE 照实说「和 X 为空的行」也筛掉了，NOT 套几个条件的说「只保留 NOT (…) 的行」。
normalize_sql：解析时会丢掉写法的（会执行的注释、!、MOD() 这类重新生成换了名字的函数）改按原文逐词规范化，
会执行的注释里的代码算结构；只改字面量的照旧同一个模板（补了测试）。
测试：fixtures/sql_pairs.py 收进第 3 轮的反例（执行的 _DIFF_R3 / _SAME_R3 / _SAME_TYPED_R3 / _SAME_SCHEMA_R3 /
_SAME_HARD_R3，只查结论的 REGRESSIONS_R3 / DIALECT_SAME_R3），schema_cache 带上 nullable 和 primary_key（和探查
出来的一样）；专挑写法差异的那组数据加了 'State'。
2026-10-05 14:19:55 +08:00
e626b205b6
合入 SQL 差异说明重做（阶段性）：先判等价再说差在哪——规范形式一字不差才算等价，具体说法只说有把握的，其余给兜底并附规范化后不同的行；等价结论用执行比对守住
2026-10-05 12:58:42 +08:00
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
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
3254744f6d
运行对比复核修正（第 2 轮）：行段相同、一边是整份结果的引用不再算同一处，默认设置的变化只落到会读它的节点上，上游 Agent 交出的结果不同时不再说变化来自上游数据
...
- Agent 两次引用同一段行，一边是整份结果、一边不是（这次多了北区，没引用的西区还在快照里）：判为无法比较，写明哪边引用了整份结果、另一边引用了哪几行、结果共几行；快照读不出来、核对不了是不是整份结果的同样不算同一处。以前按同一处算，西区被算成「数据没了」，占比超过 100%
- 图级默认设置的变化按「哪类节点运行时会读这一项」落到节点上（_CFG_KEYS，照各执行器经 NodeContext.cfg 读的配置项登记）：结论句裁判、结论句的处理只有报告节点读，不再把 Agent 记成配置变了；条件分支让模型分类、结构校验让模型修复、知识检索用模型重排时也读默认模型，同样落到它们身上。新测试按执行器源码核对这张表，执行器新读了一项没登记就失败
- 代码、数据整形这类节点的上游有 Agent、模型调用、人工审批等节点，两次交出的产出不同（工件按内容寻址，按工件 id 比；产出没落成工件的核对不了）：它交的数变了不再说变化来自上游数据，判为无法比较并点名是哪个节点
- 上游节点改了配置时说明里点名是哪个节点；默认设置那句拆短，写出跟着变的是哪几项（模型接入不写 provider）
- 补测试守住复核列出的未覆盖规则：容器运行输入还原不了、合并查询的输入追不下去、上游只有运行输入变了、审批默认设置、图里 SQL 只改格式（代码节点在下游）、跨节点先配字面量相同的、少了一次查询、只有一边落在快照上、查过库的写入节点改了配置、代码节点上游有节点改了配置、旧口径叶子的出处说不清时不拆、单格引用换了行；变异 99 处全部打红
2026-10-05 11:28:41 +08:00
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
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
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
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
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
0df5e7d4af
A2 模型起草一项都没写进去时不再算成功：认出没有 tables 外壳的单个表对象；结构化输出是空壳（只有表名、没有可用字段）时改走纯文本再问一次；某张表最终没有可用内容记 model_error「模型没有给出这张表的可用内容」；起草结果每张表多一个 model_items（模型给了几项可用内容），界面据此区分「和现有目录一致」与「模型没给内容」；「没有变化」改为只说起草出的内容与现有目录一致，另加「目录没有更新」一句；假模型能模拟空壳、单个对象、某条路不可用三种实测回复
2026-10-04 02:19:26 +08:00
b078d08ffe
数据目录 F1-A4：码值项加「已列全」标记（complete: true），只有人工明确勾选、或剖析整表统计（没有只看前若干行）得到的码值才有；码值不在码值表中的检查只认标了它的码值表，给模型的话改为提示核对取值，不再叫它照目录里的码值改。以前经对话只补了 status=9 表示作废，之后 status = 1 就被报提醒，模型还可能把对的 SQL 改错。提案补充码值时沿用原有的标记、自己不能标；目录页的码值编辑和填写含义弹窗加「已列出全部取值」勾选，表格里标「已列全」，检查脚本跟上
2026-10-04 01:13:13 +08:00
913ed9d2c4
命名推断认业务前缀、SQL 检查认兄弟关联：表名带业务前缀、列名只写词根时推不出关系，两张表各自指向同一张父表、彼此相连也被当成连错了列——改为直接对不上时按引用表共用的前缀找唯一一张，兄弟关联只提示行数可能成倍
2026-10-03 11:21:03 +08:00
e7b1510894
测试里建的数据源用完就删：留在共用测试库里的源会混进助手的数据源清单、触发挑表，别的用例的结果随执行顺序变
2026-10-03 11:09:09 +08:00
84bf484c08
合入数据目录阶段 2B：基于数据目录的 SQL 检查——七条规则按依据状态定级，接入助手自查、发布门禁和运行时，出错的来源查询使指标降档
...
# Conflicts:
# backend/app/api/evidence.py
2026-10-03 10:37:31 +08:00
98ebba384f
合入数据目录阶段 3：合并查询节点——跨库按键合并，截断输入拒绝，类型不一致与行数放大告警，证据可下钻到两边原始查询
2026-10-03 10:27:16 +08:00
8ed0bc23f7
数据目录阶段 2B：引入 sqlglot，SQL 检查的解析层——按数据源方言解析、认表和别名、解析不了一律跳过
2026-10-03 10:15:52 +08:00
44b63f78fc
数据目录阶段 1A：新增 /api/datasources/{id}/catalog 接口——表清单、单表、整份提交与单项审阅（乐观锁 409）、同步起草
2026-10-03 09:34:25 +08:00
e7646532c1
数据目录阶段 1A：探查补读外键和唯一约束（读不到就跳过、不写键），新增 50 张表的合成景区库夹具
2026-10-03 09:30:50 +08:00
1f8c180703
合并查询节点（一）：新增 merge 节点和执行器——几次查询的完整快照落进内存 SQLite 按键合并，结果存成同形的查询快照，截断的输入拒绝、键类型不一致和行数放大给警告，并记下逐格来历
2026-10-03 09:27:48 +08:00
e4f8ee5d08
Excel 导入改造期 4：证据下钻——报告里引用上传表格的数，点开能看到它来自原表格的哪一格；裁判核对时看得到来源、口径、接受理由和区域外文字
...
推断的来源（新 engine/direct_select、data/provenance、data/provenance_db；api/evidence 新增推断来源接口）
- 只对直接引用一列的查询下钻：受限文法用和执行时相同的 SQLite 分词读法，别名互换、自连接、表达式、聚合、子查询、集合运算（含藏在注释、字符串、方括号、转义、BOM 之后的）一律只给表级来历；再用 EXPLAIN 字节码和授权回调兜底
- 结果带齐主键、值非空，按主键参数化回查只读快照、类型和值严格一致才给格子；不一致时整份重算库哈希，哈希不符标红
- 从导入清单和溯源找回格子：宽表、交叉表逆透视的长表（日期取自表头格、年份取自统计期、行标签、分段标题）、列表、合计表、按期累积的并集（换算到所属那一期）；原文与规范写法不同时一并列出
- 清单读不到、登记哈希与清单不一致、快照已回收、遮罩列，都只给表级来历或不给，写明原因；原件已清除、接受已作废照实显示；未封存的运行照常推断并标明
- 相关核对：这一行、这一期的核对结论与接受理由
裁判摘录（engine/judge）
- 带期 4 标记的报告，上传表格的查询旁加来源行、口径行、接受理由、可见单元格里的区域外文字和人工录入的统计期；限定语写明这些数未经系统核对，长度有上限、截断时写明
- 隐藏行列里的区域外文字不送；设了遮罩的源只写条数
前端证据面板（run/EvidenceProvenance；ManifestBody 从版本页抽出复用）
- 「推断的来源」一节与已封存的证据分开标注：格子坐标、取自哪些格、年份来源、规范写法、回查、相关核对、数据版本与各期；标红与拒绝原因按状态显示
不变的部分
- 文档顶层加 provenance 标记，只有新报告走新路径；期 4 之前的运行、非上传源、手工源的面板、复核、裁判摘录逐字不变，由金样测试钉住
- 执行器给区域外文字记录是否在隐藏行列；不建「导入校验」系统表（D6）
2026-10-02 14:38:10 +08:00
2cdbf9a733
Excel 导入改造期 3：网格交互、自助修复、按期累积——每月的报表可以累积成一份跨月的表，漂移了点修复按钮就能接着导入，网格上框一块就能写进配方，版本页可以回滚、移除一期、清除原件
...
按期累积（新 recipe_accumulate；table_versions 扩展）
- 按统计期出的交叉表报表首次导入时默认「按期累积」，由人确认；一期一个构建，两期及以上物化成一份新的 SQLite 快照，不用视图
- 统计期完全相同要勾「替换该期」，部分重叠拒收，中间有空缺要确认；物化前逐期核对库哈希和行号，并集上另加行数守恒、主键唯一、日期落在所属统计期三条核对
- 配方演进分三档：新增列（早期各期为空值）、退役的列和表保留旧值（只在这次才退役时要勾）、不兼容变化只能显式「重新开始累积」
- 快照 id 在累积时含目标配方和模式；同样的输入物化两次库哈希相同，同一文件换名再传直接复用
- 说明按期合并，任何一期没核对过就不写「已核对」；各期维度取值不同、退役列、合计表都有提示，经过数字检查
修复按钮（新 recipe_fixes；执行器给问题带结构化参数）
- 加入标签、移除标签、声明为合计行、分段标题改名、编辑恒等式成员、按锚点忽略行/列/区域外文字、声明占位符、声明隐藏行处理、工作表改名
- 服务端算补丁，先预览新旧配方对照、再应用，可以撤销；补丁封闭，不引入正则、自由文本常量和写死坐标；修复进确认清单
- 只改分段标题、新标题仍含原来选的词时沿用已确认的常量，不算破坏性变更；修复后只查改动过的段的认领，没改的关系交给试运行核对
框选转锚点（新 recipe_select）
- 网格上框选（鼠标、键盘、区域输入），按八种用途换算成按文字认的锚点，立刻干跑比对；配方里不存坐标，泛化不了时列出原因
- 整张表挪位后同一配方照样认得；框进合计行、夹着小计、表下说明都有明确的处理
确认与对照（recipe_confirm、recipe_diff、新 recipe_compare）
- 改配方后确认清单只列有变化的项（同时按本期数据比较），不用每修一次重勾十来项；新旧配方对照界面；按规则重新起草并把名字对齐到现行配方
- 改配方后已体现在配方里的回答保留，矛盾的列出来请人重答
- 「排除的行」写进回执和导入清单：隐藏行、跳过的空行、按配方忽略的行、停止后的文字行、只核对不另存的合计行
版本页（新 source_versions、api/source_versions；前端 VersionsDialog）
- 快照与导入记录列表、启用旧版本（可写理由）、查看清单、移除一期、作废接受、清除原件；写操作带界面看到的当前版本，并发改动回 409，不静默丢期
- 除当前版本和被运行引用的版本外，再保留最近 3 个版本供回滚；遮罩列丢失要明确确认
期 1、期 2 遗留
- 重传撞上被改过的构建文件：能用本次上传恢复就隔离旧文件再恢复，否则回 409，不再是 500
- 跳过空行的列表不再把表下隔一行的说明读成数据；不像说明的单格行要人确认；受影响的配方构建换 id
- 版本存储加进程级文件锁：第二个进程拿不到锁时不清理、不回收，写操作回 503（部署本来就是单进程）
2026-10-02 07:38:44 +08:00
2d5e50fa88
Excel 导入改造期 2：配方引擎与确认向导——表从哪一行哪一列开始、哪些是合计、日期怎么补年份，都写进一份可校验的配方；首次导入经人确认，之后每期按配方重放并核对
...
配方语言（agentlab-recipe/2，新 recipe_types、recipe）
- 封闭、不含正则、保存时静态校验：常量只能从表里的候选文字里选，占位符只能映射成空值，单位从固定词表里取
- 交叉表和列表两种版式；分段各自定位、不依赖先后顺序；合计按标签语义区间核对，关系恒等式、口径不同的声明都写在配方里
- 固定的解析器集合（parsers/2）：全角、各类横线、千分位、月日写法宽容归一，规范写法存库、原文另记
执行器（新 xlsx_cells、recipe_engine）
- 两遍读取逐行对账，每个非空格都要有去向（格子账）；交叉表逆透视成长表，按统计期补年份并断言覆盖整期
- 合计行改作核对并另存一张表，不和明细混在一列；区域外文字、隐藏行列、合并单元格、空行之后的文字都单独报出
- STRICT 加主键写临时库；按锚点段记溯源，供后续证据下钻用；大表流式读取，扫描在 sheetData 处停止
校验与说明（新 recipe_checks、recipe_notes）
- SQL 核对分通过、不一致、无法核对三种结果，失败分结构、数据质量、需确认三类；结构类直接拒收
- 数据质量类可以写理由接受，接受不改库、只改状态和说明
- 表的说明按核对结果生成、不含数字，经过数字检查；没核对过的不写「已核对」
起草（新 recipe_suggest、recipe_ai）
- 先用规则起草：建议卡片加待确认问题（关系要不要登记、占位符表示什么）
- 规则起草不完整时才提示 AI 兜底：界面先展示要发出的全部文字，用户同意才发；只发结构，数字、隐藏行列、遮罩列不发，公式先脱敏；同意绑定模型和服务方；AI 只写配方，有限次修订，记 token 和费用；截断单独识别
- 无论规则还是 AI 起草，都必须人工确认才能启用
导入流程（新 recipe_imports、recipe_confirm、recipe_diff、api/table_imports）
- 暂存 → 起草 → 回答问题或改配方 → 试运行 → 勾确认项、写接受理由 → 确认并启用；接入期 1 的构建、导入记录、快照和运行固定版本
- 上传新一期按已确认的配方重放，不调用模型，出回执和差异卡，手动启用
- 改配方报破坏性变更（breaking:*）、单位变化、工作表改名的兜底，都要逐项勾选确认
前端导入向导（新 pages/import）
- 原始网格（行列号、去向着色）、建议卡片、配方面板（表单，不露正则）、试运行回执、确认清单、差异卡、AI 起草的同意对话框
2026-10-01 22:00:07 +08:00
ThearchyHelios