7bc7fc685f
起草按复核修正：读回复出错也记进用量；补问时列出了、字段留空不算没写出来；留空的列看目录里已有的；一项都没写出来的宽表逐段写范围；提醒照约定的说法
...
- 读回复时出了意料之外的错：这次调用照样记进用量（算一次出错），再交给 _guarded 记这一块没写出来；以前 _take 抛异常
时这次调用不进 calls、token、failed_calls，也不进提醒的窗口。校验（catalog._from_model）里该是文字的地方写成了
数组、对象的（列名、表类型、业务日期的列、度量类型，columns 不是数组的）直接丢掉、不抛异常：实测列名写成数组时
抛 TypeError，整张表记「起草这张表时出错」。
- 补问时请写的列都列出来了、字段留空：表上算拿不准（记留空），用量和提醒里也不再算一次「只给空壳」没写出来；以前
提醒会因此劝人换模型，真正该做的是补充起草要求。
- 留空的列不算目录里已经有中文名或含义的（不论来源：以前模型起草、按「重新起草不丢内容」留下的，库注释，人工；驳回
的不算有）；写入时（write_draft）再按并入目录之后的结果筛一遍，起草进行中有人填了的同样不算。以前照界面的建议补了
起草要求再起草，模型这次没再给的老列又被说成「拿不准、留空了」，提示一直消不掉。
- 一项都没写出来的宽表同样逐段写上列的范围：「这张表 95 列，分 4 段起草，第 1 段（表级的项）、第 2 段（c001 到
c032，共 32 列）……都没写出来：原因」；只有一段的表照旧只写原因（这一段就是整张表）。
- 提醒照约定写「建议在「设置 → 偏好设置」的「起草模型」换一个模型、缩小起草范围，或者停止这次起草」。
2026-10-13 21:25:59 +08:00
84405977b6
起草引擎按复核修正：每个原始段连同分开的各块一共 8 次；一直超时的模型几轮就停；止损后纯文本不再原样再问
...
- 封顶管到原始段：段大小减半以后，新开始的段按上限分开的各块（窄表重新拼成的各组、单表均分的各块）共用这一段的
调用次数（_Budget 在 _work 里按原始段建，_start、_guarded 接过去），不再每块各有 8 次。以前上限缩到 10 列后一直
只给空壳，4 张窄表拼成的 40 列段调用 20 次，最坏是「段列数 / 上限 × 8」。止损的计数（连续几段没写出来）同样按
原始段数。
- 超时的两半同时问：带表级项的前一半不再先写完才问后一半（一次超时就是一个时限，40 → 20 → 10 串着问要好几个时限）；
额度用完、只给空壳的照旧先写前一半、后一半拿它做背景。
- 超时另有一条止损：拆到每段 10 列（MODEL_MIN_PART_COLUMNS）的调用接连超时 2 次（MODEL_GIVE_UP_AFTER），超时就和
段大小无关了，后面超时的不再拆小，超时拆出来、等名额时还没问的块也不再问（次数退回）；有一次调用写出来就恢复。
只管超时：额度用完、只给空壳照旧拆小。原因后面补「拆到每段 10 列仍然超时，已停止拆小重试，建议更换起草模型」。
用假模型量：每次都超时的 40 列表从 8 次调用、约 7 轮（420 秒时约 49 分钟）降到 6 次、3 轮；首轮同时起草的 3 段从
24 次、约 8 轮降到 12 次、4 轮；40、20 列超时而 10 列写得完的照旧拆到 10 列全部写出。
- 止损以后本来能拆小的段只给空壳：已经走纯文本的不再原样再问（约定只对拆不开的段再问一次）；结构化输出的照旧换
纯文本问一次。
- resolve_draft_model 的说明照实写：超时不由引擎重试，当作这一段太大、拆小再问。
- 止损的说明改成文字（_Why.halted），两种止损各说一次。
2026-10-13 21:25:27 +08:00
1e1aa3f64a
起草引擎：提醒第一次出现时记一条日志（最近几次调用有几次没写出来、原因）；模块说明补上补问时才列出、字段留空的列也算拿不准
2026-10-13 20:30:02 +08:00
975dde1146
起草引擎按验收修正：列分段均分、超时拆小、段大小随模型减半、每段 8 次封顶、提醒、超时与没写出来的计数、模型留空的列、不插队、原因写清哪几段哪几列
...
- 均分：超过 40 列的表，列分段数是列数除以 40 向上取整，各段列数平均（相差不超过 1），不再留下 2 到 8 列的尾段（实测
会思考的模型常对这种小段只给空壳）；表级那段、窄表拼段、parts_total 不变。
- 拆不开的段（不到 10 列）只给空壳：再问一次，结构化输出换纯文本，已经走纯文本的原样再问，仍是空壳才记没写出来。
- 超时当作这一段太大：不再原样重试同样大小的段，按额度用完的办法拆小再问；网络错误、429、5xx 仍原样退避重试。
- 段大小随模型调整：一次起草里额度用完或超时累计 2 次，之后新开始的段列数上限减半（40 → 20 → 10，最低 10），新开始
的段超过上限就先按上限均分开（多表的段按表重新拼）；任务记当前的上限 part_columns。
- 封顶：一段（连同它拆出来的、补问的、重试的）最多调用 8 次，到了次数还没写完的记没写出来、原因写清。止损照旧。
- 提醒：最近 6 次调用有 4 次以上没写出来（额度用完、超时、空壳、出错），任务的 notice 写一句提醒（次数、原因，建议在
「设置 → 偏好设置」的「起草模型」换一个模型、减少表或停止）；之后最近 6 次里少于 2 次就清掉。
- 用量：进度回调 usage 换成 call_done（CallReport：用量、没写出来的原因种类、当前的提醒和列数上限），任务的用量加
timeouts、failed_calls；超时的调用 token 照实记 0。
- 留空的列：请模型写了、模型也列出了，中文名和含义却都没给（或者给的都没通过校验）的列记在 ModelOutcome.blank，逐表
记 blank_columns 和最多 5 个列名 blank_sample，任务上是合计，目录清单的 last_draft 也带列数；表的状态不因此变。已确认
的、库注释已经说清的列不算。补问时把漏的列列出来、字段却留空的，算留空，不再记成「漏了这些列」。
- 公平排队：宽表的表级那段写完，它的列分段排到已经排着的段后面（先来先服务），不再插到队首让窄表一直等。
- 原因：几段因为同一个原因没写出来时说「这几段」，同一段拆出来的几块仍是「这一段」；只有真拆小过才补「已拆小重试仍
没写出」（截断后只补剩下的不算）；每段写上列的范围，例如「第 5 段（列名 到 列名，共 33 列）」，窄表写出是哪几列。
- 库：catalog_draft_jobs 加 timeouts、failed_calls、part_columns、notice，catalog_draft_tasks 加 blank_columns、
blank_sample，旧库启动时补列（存量回填 0 和空）。假模型加 hang（头几次调用一直不回，用来模拟超时）。
2026-10-13 20:30:02 +08:00
645064fe47
数据目录重新起草不丢内容；库注释就是名字本身或标识符写法的不当中文名
...
- 合并（merge_notes）只改模型起草这一个来源的「覆盖即删」：模型这次对某一项没给值（留空，或者给的值没通过校验、在
_from_model 里就丢掉了），以前模型起草的项留着，只有给了合格的新值才替换。只有这一轮完整起草过（covered 含 llm）、
而这一项说的列已经不在表结构里（列级的项看列名，业务主键、业务日期看它们指着的列）才删；write_draft 把表结构里的
列名交给合并。注释、外键、命名推断、剖析各自的规矩不变，人工确认、驳回的不动。删除数因此只在真删时才有。
以前整库重跑一次，模型这次没给的几百项全被删掉，有的表覆盖率从八成多掉到五成，表仍记「已完成」。
- 库注释（comment_role）：和表名（列注释和列名）相同（忽略大小写、下划线、连字符、空白，表名带 schema 前缀的也比
不带前缀的），或者是标识符写法（只有字母、数字、下划线、点，不带空格），不当中文名、也不当说明，不记进目录；交给
模型的表结构里照旧有这条注释。以前这种注释短、不带句读就当中文名，库注释的级别又高于模型起草，模型起草的中文名
永远进不了目录。已有目录不另做迁移：起草到那张表时，旧的那条随这一轮的注释删掉，模型起草的中文名就能进来。
2026-10-13 20:30:02 +08:00
4857c578f6
起草的止损和公平：连续 2 段（MODEL_GIVE_UP_AFTER）拆到底仍一项没写出来，这次起草后面的段不再拆小重试，没写出来就直接记下，原因后面补「模型连续 2 段都没写出来，已停止拆小重试，建议更换起草模型」；有一段写出来就恢复拆小。每次起草同时只起草 3 段（MODEL_CONCURRENCY），一段连同拆小、补缺做完再取下一段，宽表的表级那段写完，它的列分段排到最前面一段一段起草；同时在等全进程名额的调用每次起草最多 3 个，几次起草（不同数据源的任务、同步起草）交替排队，后开始的不再等前一个排着的上百段全部调完。实测一直只给空壳的 294 列宽表从 168 次调用降到 81 次，20 张 120 列的宽表一直用完额度从约 900 次降到 122 次
2026-10-13 16:46:52 +08:00
c3105bba4f
起草引擎按失败原因处理的三处修正：结构化输出回了一段说明文字（不是 JSON、也没停在额度上，例如网关接受了 response_format 却没照做）不再因为带着思考就当成额度用完去拆，也不直接判失败，这次起草后面改走纯文本、这一段换纯文本问一次（纯文本另带格式说明）；只有停在额度上、或者正文为空而有思考才算额度用完。补问之后整列没列出来的列记没写出来（「模型的回复里漏了这些列，补问一次仍没有给出」），表是 partial、covered 不含 llm，以前起草过的待确认模型项不再被删（以前补问只给空壳也记 ok，还把这一轮没给的旧项删掉）；列出了、字段留空的照旧算拿不准；补问时整张表还一项都没有的，照只给空壳的规矩拆小、换纯文本，不直接记失败。几处没写出来的原因按基础原因去重，拆小重试过的在最后补一句，不再出现同一句说两遍。假模型照提示词把请写的列都列出来（字段留空是拿不准），要模拟漏列的传 list_all=False
2026-10-13 16:42:45 +08:00
ec6838dc10
起草模型的 SDK 不再自己重试：ModelSpec 加 max_retries，build_chat_model 一直传到 SDK 客户端（Bearer 鉴权换上的 Anthropic 客户端也带上）；数据目录起草建的大、小两个模型都是 max_retries=0，429、5xx、网络错误、超时只由起草引擎按失败原因重试（最多 2 次）。以前 openai、anthropic 的 SDK 各自先重试 2 次，叠在引擎的重试上，一段最多发 9 次请求，报错却写「已重试 2 次」，网关限流时还放大流量。不写 max_retries 的调用照 SDK 默认，配方 AI 起草不动
2026-10-13 16:40:07 +08:00
bf0619a03c
目录清单的 last_draft 改在库里挑：每张表最近一次起草任务里的那一项用窗口函数取，起草进行中清单页反复刷新时不再把最近一百个任务的逐表记录全读出来
2026-10-13 15:38:27 +08:00
b988a5ae18
起草引擎和后台任务的几处收紧：提示词要求请写的每一列都列出来（拿不准的字段留空、列不漏），免得模型留空的列再被补问；纯文本那条路的格式示例改用「表类型」「度量类型」占位，不让模型照抄示例值；从正文取 JSON 时依次试多个括号作开头，说明文字里带括号、外面多包一层都认得；用量记在单次调用的时限之外，落库慢了不会把已经回来的调用算成超时；后台任务收尾写库出错只记日志；补上从正文取 JSON、任务开始时模型已用不了（整体 failed）的测试
2026-10-13 15:36:24 +08:00
c1a70ecf38
数据目录起草改成后台任务：新表 catalog_draft_jobs、catalog_draft_tasks 存任务和逐表状态，同一个源同时只有一个排队或进行中的任务（接口先查、部分唯一索引兜底）；POST /catalog/draft-jobs 建任务（202），GET /draft-jobs/active、/latest、/{id} 读任务，/cancel 停止（排队的直接停，进行中的停掉正在进行的模型调用，已写进目录的不回滚），/retry 只重试失败、只写出一部分、停止了的表；同源 409 catalog_draft_busy、起草模型用不了 409 catalog_draft_model_unavailable、已结束 409 catalog_draft_finished；每张表一结束就并入目录，进度、计数、用量随时落库；服务启动时把没做完的任务标成中断、不自动续跑，关停时同样；目录清单每行加 last_draft，顶层加 guidance、active_job；数据源级的起草要求存在 options 里，经 PUT /catalog/guidance 维护（最多 2000 字，表名恰好叫 guidance 的整份提交照旧），数据源接口不显示、整份回写 options 时留着，拼连接串时摘掉；本次说明最多 1000 字，任务记下起草要求和本次说明的快照，同步起草也带上数据源的起草要求
2026-10-13 15:33:00 +08:00
6b1f63a9dc
数据目录模型起草换成分段、按失败原因处理的引擎（data/catalog_draft.py）：每次最多 4 张表、40 列，窄表按顺序拼段，宽表拆成「表级一段 + 每 40 列一段」，列分段带着表注释和表级起草结果做背景，最后合并照旧逐项校验；思考和输出用完额度、只给空壳时拆成两半再问（最少 5 列、最多 3 层），拆不开的空壳换纯文本问一次，写出来了后面都走纯文本；被截断的 JSON 先捡回已完整的表和列、只补剩下的；缺了的表和列只补缺的、补一次；服务方嫌额度大时退回 8192、结构化输出不支持时改走纯文本，都管到这次起草结束；网络错误、429、5xx、超时退避重试最多 2 次；单次调用 420 秒；全进程最多 3 个调用同时进行；报错写原因和办法（第几段、共几列没写出来、可以只重试这张表）；提示词加上起草要求一段（数据源说明、起草要求、本次说明，规矩在前、冲突以规矩为准）和「思考时不必逐列草拟」；同步起草改用新引擎，写入抽成每张表一结束就能调的 write_draft
2026-10-13 15:19:06 +08:00
b940b27e24
起草模型设置：新增设置组 catalog_draft（接入、模型），点名的接入不存在或已停用时保存回 422；数据目录起草和按配方导入的 AI 起草共用一处取模型（起草模型 > 助手的模型 > 默认接入），取自起草模型时报错照实说起草模型那一项；数据目录起草不再关思考，额度 32768，服务方嫌大时退回 8192（之后都用小额度），单次调用时限 420 秒交给 SDK；配方 AI 起草的额度、思考设置不动
2026-10-13 15:00:38 +08:00
6d4f452f36
M4 复核修正：规范化后不同的行带上所在的子句，ON 挂在 JOIN 那一行的末尾
...
复核发现上一版把 ON 单独排成一行后，「规范化后不同的行」丢了关联条件的上下文：只差一个关联条件时那一栏只剩
「AND refunds.state = 'done'」，有两个 LEFT JOIN 时看不出是哪个 JOIN 的，也看不出是关联条件还是筛选条件；两边 JOIN
的表不同时，两边都有的那一行「ON」被 difflib 当成相同的行吃掉，表名下面直接跟条件；关联子查询换成两张表时也一样。
这几种都只给兜底说明，审核人全靠这一栏逐行对照。
- sql_semantics：ON 挂在 JOIN 那一行的末尾（表名、子查询的右括号后面），条件各占一行缩在下面，仍比 WHERE 的条件
深一级（ON 里和 WHERE 里的同一个条件不当成同一行）。text_diff 里不同的行前面带上它的各级上级行（排在前面、缩进比
它浅的最近一行，一层层数到顶格），以「 」开头、两边相同，只为标出不同的行在哪个 WHERE、哪个 JOIN 的 ON、哪层
子查询里；截到 40 行时末尾落单的上级行不留。只动排版：拿测试里的 SQL 语料（990 对，4 种方言、有无表结构、两个
方向）逐对比过，equivalent、items、fallback、level 和改之前完全一致，有没有不同的行也一致，不再有单独一行的 ON。
- SqlDiff 的约定多一条：「 」开头的是上下文行，只跟着不同的行出现。test_sql_semantics 的 check_shape 原来只认
「- 」「+ 」，改成也认「 」、并要求最后一行是不同的行（374 个用例只因这一行断言变红，判定和说明都没变）。
- 审批卡（DualCheckApproval）：两栏各自只放用得着的上级行（这一边不同的行往上数，缩进更浅的最近一行，一层层往上），
只有另一边用得着的不放；上级行不高亮、用淡一级的字色（同原文栏里没标的行），标题后面说明「淡色的行两边相同，标出
所在的子句」，悬停也是这句；这一边没有不同的行时照旧说没有，老工件没有上级行，照旧。lineDiff 注释里「条件并成
一行」的旧说法改正。
- 测试：test_sql_text_diff 里 ON 那条的期望改成带 JOIN 的上级行，补两个 LEFT JOIN 只差一个关联条件（两个方向）、
两边 JOIN 的表不同、关联子查询换成两张表、同一个条件在 ON 和 WHERE 里、顶格的行不带上下文、40 行截断几条；去掉
上级行、去掉「ON 挂在行末」、去掉截断后的清理，各自让对应的用例变红。
- 夹具 dual_check.json 按 test_dual_check_fixture 的办法重新生成（只变 text_diff），另加 join_condition 变体（只差
一个关联条件、只给兜底）；check-verify 查两栏的上级行（WHERE）列在不同的行前面、不高亮、标题有说明，join_condition
下原流程一栏是带 ON 的 JOIN 加缩进的条件、盲算一栏不画只有原流程用得着的上级行，深浅色对比度、390px 不溢出。
2026-10-07 01:34:59 +08:00
5b18eab310
M4：双盲复算「规范化后不同的行」每个条件一行，两边相同的条件不再被标成差异
...
验收时审批卡把两边完全相同的日期区间标成了差异：_text_diff 逐行比两边 sqlglot pretty 的输出，pretty 按宽度决定
换不换行，两个合取的 WHERE 排成一行、三个的拆成三行，同一个条件在两边落在不同的行上。原文 SQL 都是单行时原文栏
一行都不标，这一栏是唯一逐行指出差在哪的地方，审核人会以为统计期也不一样。
现在逐行比之前两边按同一套排版写（_diff_lines / _line_generator，按方言给 sqlglot 的生成器加一处改动）：WHERE、
HAVING、ON 的合取式每个条件一行，各层子查询里的也一样；条件本身是 OR 连起来的一律加括号（单独一个和与别的并列时
写法一样）；ON 照 WHERE 的样子单独一行、条件缩进在下面（ON 里和 WHERE 里的同一个条件不当成同一行）。比的时候
不看条件前面的 AND（一边多出来的条件排在最前面时，另一边同一个条件只差在有没有 AND），列出来的仍是各自原样的行。
只动排版：判不判等价、差异说明不变（拿测试里的 SQL 对照语料按三种方言、有无表结构逐对比过，items、equivalent、
fallback、level 全部一致），sql_semantics、sql_equivalence 原有测试全过。
前端夹具 dual_check.json 里的 text_diff 是服务端的真实输出，按 test_dual_check_fixture 的办法重新生成（只变了
text_diff）；check-verify 的对照行一节另查「只差结束日期时开始日期不标」「多出的两个条件各占一行」。
2026-10-07 00:12:31 +08:00
3c51c40e9d
点名的模型接入：发布前检查给每一处配修复，提示指到界面上真能改的地方，复核发现的几处漏查、误查补齐
...
多数节点（模型调用、Agent、报告撰写、多 Agent 协作、条件分支、结构校验、知识检索）、协作成员和全图默认的接入在检查器里没有下拉框，以前点名的接入坏了只能去设置里建一个同名接入。现在门禁接受接入表（governance.lint_for_publish 的 providers，接口层读好传进来，同数据目录 SQL 检查器），点名接入的问题成了门禁的一部分，自动修复给每一处一条要人选的修复：改用一个启用的接入，或不指定接入；选的接入不提供这一处写着的模型时模型一并去掉。一处一条（修复 id 带字段，复核只认那个字段），协作节点自己的接入和成员的接入各修各的。校验和发布检查的提示按位置写：有下拉框的说「在节点中换一个接入」，别处说「在发布前检查中改用其他接入」；剩下的只有接入问题时交给助手的说明也改成指向这些修复。
复核发现一并修：核查节点自己的开关关着、结构校验不许重试时不再查（执行时根本不取模型，以前会挡住发布）；报告没写裁判配置时查全图默认里的那一份（以前放行，正式运行却全部未裁判）；接入名不是字符串时查助手模型的接口不再 500，设置接口对门控、助手两组的这类值回 422 带字段；助手、表格导入、数据目录起草用的模型点名的接入不存在或已停用时照实说是哪个接入、去哪里改（以前说「尚未配置完成」，停用接入的下一步丢了），删掉两处已走不到的分支。
测试补齐：结构校验让模型修复、知识检索让模型重排、按需裁判各路径的不存在与已停用，助手、定时正式运行、裁判的两种情况，反方审稿节点上点名的接入；修复的候选、应用、拒收和图级默认。
2026-10-06 15:14:26 +08:00
2eddd8236a
SQL 差异说明收尾：前缀的 NOT 后面同一段里既有谓词、又有算术 / 拼接 / 按位运算时（NOT status IN (…) * amount），SQLite 里 NOT 最松、sqlglot 读成 (NOT …) * amount，不在语法树上判等价、只给兜底；48 种组合两种方言都不再判等价，常见的 NOT … IN、NOT … = 照样认得出等价改写。模块说明照实列出仍做不到的几类说明准确度问题（Unix 秒的时间列、带 time 的时长列、被函数定死的列）
2026-10-06 09:18:10 +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
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
3e5fc7bc84
SQL 语义：去掉 _Usage._bases 里没用到的 import（pyflakes 报的，第 2 轮就留下的）
2026-10-05 15:14:03 +08:00
c38177aea6
SQL 差异说明第 3 轮补充：只在一边被去掉、被按内连接比的 LEFT JOIN 不说成「另一边没有」「用 INNER JOIN」
...
规范化在一边认出了「这次 LEFT JOIN 有没有都一样」（去重之后不怕重复、按主键关联、只取可空一侧跳过空值的聚合），另一边
写法不同没认出来时，两边的规范形式一个有关联、一个没有（或者一个内连接、一个 LEFT JOIN），以前会照规范形式说「A 没有
关联 refunds 表」「A 用 INNER JOIN」，可原文两边都写着 LEFT JOIN。现在去掉的关联记在那一段上（_DROPPED_JOINS）、按内
连接比的记在那张表上（_NULL_BLIND），差异说明碰到就不说；表结构里有唯一键、又没用到的那张表，ON 写得认不出是不是按
唯一键关联（s.id IN (o.store_id)）时也不说。补了三种写法在三种方言、给不给表结构下的测试。
2026-10-05 15:09:10 +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
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
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
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
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
2026-10-05 06:11:40 +08:00
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
2026-10-05 04:58:17 +08:00
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
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
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
f1c068d6a9
核查工具箱收尾：连接的方面补上另一侧（关联条件里出现的别的表，CROSS JOIN 写它之前的来源），双盲复算对照数据目录里的关系时用得上；只读 agent 收尾前先拿到收尾用的模型再预留金额，模型拿不到时不在每日账上白记一次调用；收尾消息的参数改名 limit_words，说清是哪个上限的说法
2026-10-05 00:42:02 +08:00
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
706f715529
剖析也核实外键关系的基数：外键只保证被指向的键唯一，子表一侧一行还是多行看数据；以前跳过外键，扇出检查对外键来的一对多只能报警告，受管发布挡不住订单关联明细后对订单金额求和。来源、状态、覆盖率不动，只补基数和「用数据核实过」
2026-10-04 03:38:31 +08:00
ab9d45c428
数据目录 F2b：剖析报告和目录页读结构化字段，不再从原话里认——服务端最小改动：码值候选的结论带 pending（还有几个含义待填写），关系的结论带 cardinality_checked；报告里「N 个含义待填写」读 pending，基数写「已用数据核实」或「子表一侧未核实」读 cardinality_checked，挑表时跳过的空表读 empty_tables 列出来；表详情的关联关系标出基数已核实；剖析说明不带日期后，码值弹窗的说明后面按这一项的 updated_at 写时间；补后端测试和检查脚本的断言（假答复的 summary 不再写待填写）
2026-10-04 03:06:14 +08:00
5b3839f787
数据目录 F2b：剖析的 409、剖析设置的 422 带机读码，界面不再从原话里认是哪一种——服务端用 api/coded.CodedHTTPException：剖析开始不了的五种情况带 code（profile_disabled、datasource_inactive、schema_missing、profile_busy、snapshot_tampered），保存数据源时剖析设置不合规带 code=profile_settings_invalid 和出错的那一项 field（max_queries……），给人看的那句不变；CodedHTTPException 多一个可选的 field；前端 profileBlockOf、profileFieldOfRejection 只认 code 和 field，没带机读码的旧响应按通用提示处理；补后端测试和检查脚本的断言（伪造的 409、422 都带 code）
2026-10-04 03:03:23 +08:00
88c63bfd41
合入集成分支 feat/data-catalog（d897981，含 F2a 的证据面板、时间线和服务端修复）：自动合并，没有冲突；catalog_profile._relation_finding 两边的改动（F2b 的 previous_status、F2a 的 cardinality_checked 写在关系上）互不重叠
2026-10-04 02:52:28 +08:00
99ca98a87d
B1 服务端自动挑剖析表不再挑中一批空表：候选里还有待核实（推断）关系的表排在前面，再按使用次数、表结构顺序；挑表时先估行数，确知是空表的跳过并记进 empty_tables（最多估 30 张、最多用掉查询次数上限的一半），估行数的查询算进这张表的查询数；候选全是空表时说明写明是空表
2026-10-04 02:19:26 +08:00
661f6a38d7
A7 剖析写进目录的说明不再写日期：以前写的是 UTC 日期（at[:10]），和界面上按本地时间显示的修改时间对不上；改为「数据剖析：…」，时间以这一项的 updated_at 为准。is_profile_note 同时认升级前带日期的「数据剖析（日期）：」；same_profile_note 继续兼容旧数据：只差日期、或一段带日期一段不带的同一结论都算相同，升级后重新剖析不会给每张表升版本
2026-10-04 02:19:26 +08:00
46c3fd3093
A6 扇出检查只在一对多确有其事时报错误：关系人工确认过，或数据剖析在数据上核实过子表一侧的键不唯一（关系上记 cardinality_checked，子表太大没核对的不算）才给 error；只凭外键结构推出的一对多降为 warning，说法改成「可能重复计算」，下一步写确认关联表里每个键只有一行、或先汇总再关联；人工编辑提交里带的 cardinality_checked 不作数；级别说明「结果必然有误」改为不夸大的说法；2B、F1 的测试按新规则更新：外键 + verified → warning，剖析核实过 → error，人工确认 → error
2026-10-04 02:19:26 +08:00
0df5e7d4af
A2 模型起草一项都没写进去时不再算成功：认出没有 tables 外壳的单个表对象；结构化输出是空壳（只有表名、没有可用字段）时改走纯文本再问一次；某张表最终没有可用内容记 model_error「模型没有给出这张表的可用内容」；起草结果每张表多一个 model_items（模型给了几项可用内容），界面据此区分「和现有目录一致」与「模型没给内容」；「没有变化」改为只说起草出的内容与现有目录一致，另加「目录没有更新」一句；假模型能模拟空壳、单个对象、某条路不可用三种实测回复
2026-10-04 02:19:26 +08:00
163f3b96b3
数据目录 F2b / B7：剖析报告里关系的结论按实际变化说——原本就是已验证、这次照样核实的写「仍为已验证，覆盖率 x」，从推断升上来的才写「升为已验证」，已验证降回推断的写「降为推断」；服务端最小改动：关系结论多带 previous_status（剖析前的状态），summary 同步写「仍为有确证」；补后端测试和检查脚本的断言
2026-10-04 02:09:47 +08:00
c133967bf9
冻结的数据目录有了读取方：证据接口的查询步骤带上表结构快照 id 和这条查询用到的表当时的目录版本，证据面板写「数据目录：订单 第 3 版」；冻结时保留被驳回关系的编号和状态（不放内容），新增按冻结的那份重建 SQL 检查器的 frozen_checker，驳回过的外键关系不会被推回来
2026-10-04 02:00:17 +08:00
0f537a9cad
只探查了部分表时，查结构工具不再对没探查到的表说「没有」：说明不在已探查范围、无法判断，并给出查数据字典的办法
2026-10-04 01:31:16 +08:00
37d2f1d1d4
合入完整性修复 F3：Agent 查库的模板也记目录版本并提醒「可能涉及」，只探查了部分表时清单、目录页和助手上下文都说明，升级入口接上 SQL 检查，截断判定和工具节点遍历各收成一处
2026-10-04 01:28:59 +08:00
d805f64195
数据目录 F1 一致性：日期列的判定抽成 catalog.is_date_column，数据剖析（唯一日期列提议业务日期）和 SQL 检查（按业务日期以外的时间列统计）共用，只有时刻的 TIME、整数存的时间戳两边都不算；表名匹配统一按 name_key（只把 ASCII 字母转小写），resolve_table_name 和 SQL 检查里认表名不再按 Unicode 转小写，和使用次数、影响面同一个口径；切词合并成 catalog.name_words，剖析不再另写一份；更新过时的说明（错误级检查已经上线、剖析预算的叫法跟设置界面）；码值比较不分大小写保留，注释写明是照顾 MySQL 默认排序规则、宁可漏报
2026-10-04 01:17:29 +08:00
f5e8a436f1
数据目录 F1-B3：计算公式在人工整份提交和模型起草两条路径上也拦下——人工提交里改动过的文字项像公式就整份不收（422，说明公式写进口径卡），模型起草出的公式项丢掉；和对话提案同一套判断。只查改动过的项、不进结构校验：库里已有的含公式的项不会挡住这张表的写入
2026-10-04 01:15:05 +08:00
bf5bee9246
数据目录 F1-B2：剖析写的备注只是开头的日期变了、其余都没变时，保留旧的项、不升版本（人工确认过的关系也一样）。以前隔天重新剖析、数据没变，目录版本也加 1，发布时记下的目录版本就对不上，之后每次正式运行都误报目录有变化
2026-10-04 01:14:08 +08:00
ThearchyHelios