89a4bc8cfc
合入期 5 验收修复 M1：核查 agent 正文里的依据标记不再断句——只装着依据的括号（含【】［］〔〕[]）连同里面的停顿标点一起去掉，去掉之后按真正挨上的两个字补空格，两个数不再并成一个；核查 agent 的提示词改成依据写在句末；收尾超时照实记 timeout_s；没给理由时照实说没有给出理由
2026-10-12 13:12:20 +08:00
60be16a0bb
M1 复核修正（第 3 轮）：依据两边什么都没有时也判粘连，两个数不再并成一个；只装着依据的括号认【】［］〔〕[]；右边紧贴着下文的半角逗号后面补空格
...
渲染（evidence._tidy）：
- 上一轮只沿着去掉的字往两边找粘连：依据前后没有空白、括号、标点时没有切口，「华东 [[v:Q1.r0.销售额]][[see:Q1]]
[[v:Q1.r0.订单数]] 笔」渲染、组装都是「4,919.5212 笔」，「[[v:…]][[see:Q1]]2 月」是「4,919.52 月」，「**华东 [[v:…]]**
[[see:Q1]]2 月」组装出「华东 4,919.52 月」，verify_doc 都不报。现在每个依据（连着写的一串、只装着依据的括号都算）
两边都判（_glue 看所有不显示的字，不只看切口），会读成一串的补一个空格：这一片有去掉的字的照旧换掉头一个，没有的
插在头一个依据前面（粗体收尾的星号外面）
- 只装着依据的括号认【】、［］（全角半角混用也算）、〔〕、[]，和（）一样连括号去掉，外面悬着的停顿标点照原规则收拾；
依据在这些括号开头、末尾紧挨着分隔标点的，同（）一样收拾。核查 agent 拿到的查询结果以「【证据 Qn】」开头，模型照着
写成「【[[see:Q1]]】」，以前渲染成「【】」
- 右边是写作者紧贴着下文写的半角逗号的（「1,200（[[see:Q1]]）,900」去掉括号读成「1,200,900」），空格补在逗号后面
（同「212,[[see:Q1]],5」→「212, 5」）。上一轮把这一类当成可以不管的「）,5」写法；和基线 58a6759
2026-10-12 12:24:14 +08:00
45987748ef
K3b 复核修正（第 3 轮）：VALUES 当一张表用又读到遮罩列的整份遮，列名按方言认；sys 库读 performance_schema 的 ps_* 函数进认不全的名单
...
- VALUES（复核 major，基线就有）：_function_columns 按 Postgres、SQLite 的习惯把 VALUES 的列记成 column1…，MySQL 8.0
实际叫 column_0、column_1…（真库实测），派生表、CTE、LATERAL 里的 VALUES ROW 取了号码，外层按名字取、照原名带出时
对不上，号码原样交给模型、落库；MariaDB 拿第一行的值当列名，同样对不上。现在 VALUES 当一张表用（FROM、JOIN、
LATERAL 里的，WITH 里的一段，UNION 的一支，整条就是它，_values_table）又读到遮罩列（含派生出来的名字）的，不论哪个
库、列怎么起名，整份遮。套了括号的 VALUES（整条、UNION 的一支）解析器原样挂在树上、不在任何 SELECT 的 FROM 里，以前
哪个库都没认（Postgres 也漏），一并收口。IN / ANY / EXISTS、标量子查询里的 VALUES 不算：值经外层的表达式带出，或者
只用来筛行
- 列名按方言认（_values_names，_function_columns 用同一套）：Postgres、SQLite 叫 column1…，MySQL 叫 column_0…（一行
ROW(…) 摊开数列），写了列名表的按列名表（Postgres 的列名表只改前几列），MariaDB、Oracle 认不准记 None。整份遮时只收
值取自遮罩列的那几列的值（_values_taken 按位置）：以前 VALUES 按表值函数认，出的每一列（连同 key、value、别名）都算，
同一行里没碰遮罩列的区域收成遮罩值，在同一次核查里处处被换掉
- 行为变化：Postgres、SQLite 的 LATERAL VALUES 读到遮罩列，以前只遮那几列，现在整份遮（多遮，同一份里的编号也遮）；
原来「VALUES 里直接写遮罩列只遮那一列」的用例改成整份遮
- sys 库（复核 minor）：INDIRECT_NAMES 的 sys 规则补上按 sys.ps_ 开头认的函数（ps_thread_trx_info 交回线程的事务里执行
过的语句原文，ps_thread_stack 同类；只交回编号、开关的 ps_thread_id、ps_is_* 一并算，多遮；不写 sys. 的要默认库就是
sys 才执行得了，不认，同 sys 的视图）。工具边界和可验证报告共用这一份名单，报告不再判它没碰遮罩列、照常附带快照
- 质询模块说明的已知局限同步
补测试：VALUES 当一张表用 × MySQL（派生表、LATERAL、CTE、外层改名、JOIN LATERAL、LATERAL 子查询、标量子查询、派生
出来的名字、UNION 第一支、整条套括号、派生表里 UNION 的一支）、MariaDB 两种、Postgres 三种、SQLite 一种；三种没读到
遮罩列的对照；四种写法的收值（号码收、区域不收）和 (表达式).* 之后不按位置收；_function_columns 四种列名、两种认不准；
核查 agent 真实查询工具上的端到端（复核点名的三条 MySQL 写法）；sys.ps_* 六种写法、三种不该误伤的对照、可验证报告
两种、端到端一条。逐项去掉实现（整份遮、MySQL 的起名、按位置收值、当一张表用的位置、整条就是 VALUES、VALUES 不按表值
函数认、摊开 ROW、列名表、_function_columns 的起名、(表达式).* 之后停、MariaDB / Oracle 认不准、sys.ps_），对应的测试
都变红。另在 MySQL 8.0.46、Postgres 18 临时实例上经核查 agent 的真实查询工具复跑 28 条（MySQL 的 VALUES 14 条、对照
4 条、sys 函数 4 条，Postgres 的 VALUES 6 条）：交给模型的、落库的、通用工件接口给的都没有号码；2b5989e 上其中 16 条漏
号码（sys.ps_thread_stack 在只读事务里执行不了，前后一样）。
2026-10-12 12:18:34 +08:00
2b5989ef00
K3b 复核修正（第 2 轮）：VALUES、行构造器里的 (表达式).* 和交回复合类型的表值函数整份遮；记着别的会话 SQL 的视图、不只读表结构的 SHOW 和 EXPLAIN 整份遮
...
- VALUES 里的 (表达式).*（基线就有）：Postgres 在 VALUES 里同样把复合类型、记录展开成好几列，LATERAL VALUES 按表值
函数认时一个元组项只算一列，column2 起的号码原样交给模型、落库。现在 (表达式).* 不只看选出项：树上任何位置的（VALUES、
行构造器、函数参数里的），以及 VALUES 里的 s.*、(s.*)，读到遮罩列就整份遮。(表达式).* 的值只按那个表达式认，不再把 *
当成展开 FROM 的来源（没设遮罩的复合类型 (p.address).* 以前因此被整列遮）
- 同一类、复核没点到的：Postgres 里 FROM 中交回复合类型的表值函数。unnest 的数组元素是复合类型时展开成各个字段
（unnest(ARRAY[p.card]) 出 addr、tel，写了列名表也只改前几列的名字），不认得的函数只写了列名、没写类型的列名表
（jsonb_populate_record(NULL::contact, …) AS r(a) 后面的字段照原名出），读到遮罩列的整份遮（_spreads_record）；拆普通
数组的 unnest 也一样（元素类型 SQL 里看不出，多遮）。写了带类型列定义的照写的认
- Oracle 的 JSON 点号、对象类型的属性（t.profile.tel，解析器读成库、表、列）：前面几段也算列，以前只认 tel，号码原样交出
- 记着别的会话 SQL 原文、被锁那一行的值的来源补进 INDIRECT_NAMES（工具边界和可验证报告共用一份）：MySQL 的 INNODB_TRX、
OPTIMIZER_TRACE，MariaDB 的 INNODB_LOCKS、QUERY_CACHE_INFO，Oracle 的 V$ / GV$ / X$ 一律算、AWR 历史、SQL 调优集和
调优顾问、固定的执行计划和 SQL Profile、闪回事务，DBMS_XPLAN、DBMS_SQLTUNE 这类出报告的包
- 不是查询的语句（_reads_beyond）：只读表结构的 SHOW（表、列、索引、库、表状态、建库语句）、DESCRIBE / EXPLAIN 一张表
照常，别的 SHOW（ENGINE INNODB STATUS、BINLOG / RELAYLOG EVENTS、REPLICA STATUS、WARNINGS、PROFILES、CREATE TABLE /
VIEW、TRIGGERS……）、EXPLAIN 一条语句（MySQL 把只有一行的表的值代进计划里的条件，8.0 实测）不逐个认，一律整份遮。
SHOW CREATE TABLE 不算只读表结构：对视图交回的是视图定义（WHERE 里写死的号码，8.0 实测），以前因为写着 TABLE x 本来
就整份遮，照旧；SHOW TABLE STATUS 以前同样因此整份遮，现在照常
- 质询模块说明的已知局限同步；补一条：视图、函数、约束定义里写死的字面量（information_schema.views、pg_views、
pg_get_viewdef()……）不认，照常交给 agent
补测试：VALUES × LATERAL / JOIN LATERAL / CTE / FROM / 匿名 ROW / 整行 / 表和子查询的 *，函数参数里的 (表达式).*，
没碰遮罩列的对照；交回复合类型的表值函数九种写法和三种照旧按名字认的对照；Oracle 点号四种和两种对照；十九种视图和包、
十三种 SHOW、九种 EXPLAIN、十二种只读表结构的对照；核查 agent 真实查询工具上的端到端（Postgres 的 VALUES 展开、MySQL
的 INNODB_TRX 和 SHOW ENGINE INNODB STATUS）。逐项去掉实现（(表达式).* 的取值、树上的 Dot、VALUES 里的 *、新名字、
_reads_beyond、只读表结构的豁免、SHOW CREATE TABLE、unnest、只写列名的列名表、三段名），对应的测试都变红。另在
Postgres 18、MySQL 8.0 临时实例上经核查 agent 的真实查询工具复跑复核的复现和上面这些写法（44 条），交给模型的、落库的、
通用工件接口给的都没有号码；169c500 上其中 23 条漏号码。
2026-10-12 10:50:40 +08:00
3d85a43301
M1 复核修正（第 2 轮）：去掉依据之后按真正挨上的两个字判粘连——两个只装着依据的括号连着写、数字包着粗体时，两边的数不再并成一个；依据标记的「]」不当数字；一片里只补一个空格
...
渲染（evidence._tidy）：
- 上一轮判粘连只看原文里紧挨着括号的两个字（往后只越过 [[see:]]）。两个只装着依据的括号连着写（「[[v:Q1.r0.销售额]]
（[[see:Q1]]）（[[see:m:gmv]]）2 月」）、数字包着粗体（「**[[v:…]]**（[[see:Q1]]）2 月」，组装文档时星号又被去掉）
时，去掉之后真正挨上的是两边的数，读者看到「4,919.52 月」「212212 笔」，compose_doc、verify_doc 都不报。现在先把依据
标记和只装着依据的括号（套着的、几个连着写的都算）认成渲染出来什么都没有的一段（_voids），连着写的几个并成一组，外面的
停顿标点、空白照原规矩收拾；所有切口去掉之后，再往两边越过去掉的字、依据、粗体斜体的星号和下划线，找真正挨上的两个看得
见的字，会读成一串的补回一个空格（_glue）
- 依据标记的「]」越过去、不当数字：「华南居首。[[see:Q1]]（[[see:Q2]]）2 月」不再多出空格，「[[see:Q1]]（[[see:Q1]]）
2 月」不再以空格开头
- 同一片里最多补一个空格：「212,[[see:Q1]],[[see:m:gmv]],5」→「212, 5」（上一轮是两个空格）；挨上的是写作者自己留着的
空白的，不补
- 半角标点后面补空格并进同一条规则：只在下文是数字、字母或渲染出字的标记时补（「a,[[see:Q1]],b」→「a, b」），下文是中文
的照写作者原样
- 流式渲染把末尾的星号、下划线也攒到后面的字来了再放，和整篇渲染判得一样
- 粗体把括号包在里面时（「**[[v:…]]（[[see:Q1]]）**2 月」）空格落在收尾的星号前面：前端行内 Markdown 照样认这对星号，
组装出的文档去掉了包着标记的星号，读者看到的一样；挪到星号外面得先知道这对星号从哪开始，流式渲染的一块里不一定有。
测试里用严格的 xfail 写明这条已知限制
测试：两个括号连着写（全角半角混用、套着的）、粗体在括号前、后、里面、下划线和单个星号、依据的「]」、一片只补一个的用例；
结构化组合（数、依据、只装依据的括号、空白、星号、标点）逐份查写作者隔开了的两边没有挨上、没多出连着的两个空格，逐字和
每 4 个字分块渲染都等于整篇渲染；审批质询、核查 agent、反方审稿、双盲复算各补一个端到端用例。11 处改动逐一去掉实现，
相关测试都变红。另在测试之外抽查：结构化组合 15.9 万份和基线 58a6759
2026-10-12 10:35:13 +08:00
c97390511e
M1 复核修正（第 1 轮）：去掉只装着依据的括号不再把两边的数字粘成另一个数；括号去掉之后外面照一个依据再收拾；换行不算句末；核查 agent 的理由按渲染后的正文判有没有给；反方审稿收尾超时按时长上限说
...
渲染（evidence._see_cuts）：
- 括号是两边唯一的分隔、去掉之后数字字母会粘成一串的（「[[v:Q1.r0.销售额]]（[[see:Q1]]）2 月」渲染成「4,919.52 月」，片段
本身没错、月份不算裸数字，哪项核对都查不出来），括号换成一个空格；半角逗号夹着依据、去掉后一个之后同理（「212,5」→
「212, 5」）。切口可以带替换串，连成一片的按并集换
- 只装着依据的括号去掉之后，整对括号当一个依据看外面：括号前悬着的停顿标点（「华南居首，（[[see:Q1]]）。」）、到句末只隔着
的空白、夹在两个分隔标点中间的后一个，和不带括号的写法收拾得一样
- 依据后面到句末标点只隔着空白的，空白一起去掉（「华南居首 [[see:Q1]] 。」不再剩「华南居首 。」）
- 换行不再算句末：列表项末尾的「；」、软换行处连着两个分句的「，」是写作者自己的，依据挂在它后面正合规矩，照旧留着（上一轮
把它们删了）
- 没有依据的文档渲染、内容哈希不变（随机两万份和基线逐份比过）；流式分块输出仍等于整篇渲染
- 依据写在「依据」「见」「取自」「来源」这类引出语后面时引出语悬空，渲染时去不掉（引出语在依据前面，流式渲染得攒住每个可能
是引出语的字）：测试里改成严格的 xfail 写明已知限制，不再把验收里的缺陷钉成预期；核查 agent 遇到这种写法记一条日志
核查 agent（verify_agent）：
- 有没有给理由按渲染出来的正文判：只写了依据（[[see:Q1]]、「（[[see:Q1]]）」）显示出来是空的，占位词后面挂着依据的显示出来
只剩占位词，都算没给。以前按原文判，标记里的字也算，理由文档照样交回：审批卡画出一片空白，判「被推翻」的因为引用到了 Q1
被当成有出处、出具降档；封存之后的质询回答只剩系统说明却记成回答成功
- 「无」「暂无」「none」只在理由是另一个结果的说明时（双盲复算、反方审稿）算没给；结构里只有理由一项（审批质询）时理由就是
回答，「无。」是一个回答，不再报「模型没有给出回答内容」让提问人重问、再花一次钱
- 收尾超时的原话收成常量 SETTLE_TIMEOUT，调用方据此换成自己的说法
反方审稿：交结论那次超过时长上限的句子，理由写「反查未完成：已达上限（每句时长上限 N 秒）」（收紧过的说运行时长上限将至），
和时间线上的 challenge_limit 一致，不再把核查 agent 的内部原话摆上审批卡。
测试：补节点级用例钉住收尾超时之后两个节点对外的说法（challenge_limit 的 limit、claims_skipped、cause，双盲复算的无法复算
原因和 dual_check_limit，收紧过的两种）；理由只有依据、占位词挂依据、「无。」作为回答的各层用例。每处改动都做过去掉实现、
测试变红的验证。
2026-10-07 01:19:26 +08:00
169c500526
K3b 复核修正（第 1 轮）：数值格按位置认、(表达式).* 带外括号也整份遮、同名 CTE 按作用域认、认不全的写法名单合一、整份遮不再把每一格收成遮罩值、证据摘录分段遮、反方最后一道关只看正文
...
- 同名列（回退）：column_types 按列名记，同名的几列只留得下后一列的类型，文字的备注被当成数值列，号码不再按值换、
原样交给模型并落库。现在只在列名唯一时按列类型认数值列（_typed_numbers），同名的按格子本身认：整数、小数才算数，
写成字符串的数按文字照换、记进 masked_cells；列名唯一、列类型是 number 的 NUMERIC / DECIMAL 字符串照原样
- (表达式).* 外面套了括号、起了别名（((p.card).*)、(p.card).* AS x，Postgres 实测照样展开）：以前只遮第一列。选出项
先去掉外括号、别名再认（_unwrapped），(s).*、(s.*) AS x 照旧当 s.*
- WITH 里和数据源里的表同名的一段（WITH sales AS (SELECT * FROM sales WHERE …)）：不带 RECURSIVE 的一段看不见它自己和
排在后面的段（_scoped_cte），同名的按数据源里的表认；以前认成它自己，* 展开什么都不带出，整行引用的号码原样交出
- 认不全的写法：和可验证报告合成一份名单（masking 的 OPAQUE_SQL、INDIRECT_FUNCTIONS、INDIRECT_NAMES，bundle 引用后另加
系统 schema），补上 MySQL 会执行的注释、U&"…"、pg_stat_get_activity、逻辑解码、MySQL 的 column_statistics /
general_log / PROCESSLIST / performance_schema、MariaDB 的 column_stats、Oracle 的直方图 / *_tab_columns / V$SQL 一族；
去掉注释再认一遍（函数名和括号之间夹注释）；去掉 DuckDB、SQL Server 的函数（query 误伤同名 CTE、字符串）；没有 * 的
一支选出项和结果列数对不上的、Postgres 解析不了的整份遮
- 整份遮只收确定取自遮罩列的那几列的值（_derived_masks 的 collect，报告快照收值同一规则）：以前每一格都收，区域名、
列名在同一次核查里处处被换掉，封存的 SQL 也被改写。快照另记 masked_whole，格子引用照实说写法认不全
- 证据摘录分段遮（inquiry.ExcerptMask，judge.prepare 的 mask 取代 kinds）：SQL 照封存 SQL 的办法换，范围阈值、LIMIT 照
原样，和遮罩列做等值、IN、LIKE 比较的字面量不论收没收到都换；格子逐格遮，数值格照原样；质询把被问的那句（连同表格）
当作已经摆在眼前，摘录、查询工具、回答里都不换
- 反方审稿：理由文档的目录列名照快照换（同质询的 _renamed_entry），agent 自己 SQL 里照原样留着的阈值、行数在正文里
不换（_shown），最后一道关只看正文和原文，不再把 agent 起的列名、阈值当成露了遮罩值整句改判
补测试：同名列一文一数、DECIMAL 字符串（含端到端引用取值），外括号 × 复合类型 / 记录函数 / 匿名 ROW × 最外层 /
UNION 前后支 / 和 * 写在一起，同名 CTE 四种写法和 RECURSIVE 对照，十七种认不全的写法和三种不该误伤的写法，整份遮后的
收值与封存 SQL，Postgres 解析不了的整行引用，摘录的阈值、数值格、IN / NOT IN 字面量、被问那句（反方、质询各端到端），
反方别名里的阈值（经受住、被推翻各一条）、找某个值的别名、正文里的阈值。逐项去掉实现，对应的测试都变红。
改了文件所有权以外的 bundle/build.py：_OPAQUE_SQL、_INDIRECT_READS 改为引用 masking 的同一份名单（另加系统 schema，
覆盖面不小于原来）。
2026-10-07 01:09:36 +08:00
7de4aa1550
收尾超时一律记时长上限：循环里先查满了次数、再在交结果时超时的，limit 也是 timeout_s
...
上一个提交在模型自己停了查询时补上了 timeout_s，但循环里先撞上别的上限（查询次数、轮数）、交结果那次又超时的，仍记
先撞上的那个：质询会显示「未能回答（已达查询次数上限）：回答超过时长上限…」，自相矛盾；双盲复算会说盲算查满了次数、
反方审稿说「每句最多查询 N 次」——查满了照样能交结果，没交成是因为超时。现在交结果那次超时一律记 timeout_s，和报错
原因一致（运行时长上限将至、时长被收紧过的，双盲复算、反方审稿照旧按 timeout_s 说成运行时长上限将至）。金额被拒的
收尾不变，仍报循环里先撞上的那个（test_verify_truncation 钉着它，原因见那里）。
2026-10-07 00:09:46 +08:00
735dc32052
核查 agent 的依据照写作者的规矩挂在句末；收尾超时照实记时长上限；占位词不当理由
...
- 交结果的提示（VERIFY_FINAL_PROMPT，双盲复算、反方审稿、审批质询共用）以前写「提到某次查询时写 [[see:Q1]]」，模型就
把它写进括号、句中；反方审稿的系统提示自己也把它写在括号里（「（[[v:Qn.rX.列名]] 或 [[see:Qn]]）」）。改成和写作者
一致：依据挂在句末（「……结果一致。[[see:Q3]]」），说明它渲染后不显示，不要放进括号、句中或「依据」「见」「取自」
后面。已经写进括号的由上一个提交的渲染收拾干净
- 模型自己停了查询、收尾那次调用超过时长上限时，limit 以前是 None：质询的报错写着「回答超过时长上限（180 秒）」，
answer.limit 却是 null，界面少了「已达时长上限」；双盲复算、反方审稿把它当成别的原因，审批卡上照出内部原话。
现在记 timeout_s；循环里先撞上的上限照旧优先（同金额被拒的收尾），结构化输出、退回普通调用两条路都一样
- 交回的理由是空的、只有标点，或者只是一个占位词（验收里盲算交了字面的「placeholder」，审批卡照着显示）：当没给
理由，不组装理由文档。反方审稿的记录里理由为空，审批卡照旧写「反方没有给出理由」；质询照「模型没有给出回答内容」
报错；双盲复算的对照工件里说明为空
测试：交给模型的提示（含三处调用方的系统提示、任务）里不再示范括号里的依据；写进括号的依据在理由文档里渲染干净、
仍挂在句子上；审批质询的回答、反方审稿的理由、双盲复算的说明端到端都没有空括号；收尾超时 limit 为 timeout_s（核查
agent 和质询接口、事件里都是）；占位词的理由三处都不当理由。
2026-10-07 00:05:17 +08:00
d0e9c6d1e7
依据标记写进括号、夹在标点中间时渲染不再断句：_tidy 把依据周围留下的括号、标点一起收拾掉
...
真实模型验收里，核查 agent 把 [[see:Qn]] 写进括号、句中（「结果一致（[[see:Q3]]，原报告 SQL 未按 status 过滤）」
「合计 [[v:Q1.r1.金额合计]]（[[see:Q1]]）」），see 渲染成空，正文留下「（，原报告…）」「（）」，审批质询的回答、反方审稿和
双盲复算的理由都这样，正式运行里随封存永久留着。_tidy 以前只去掉 see 前面的空白。
- 括号（全角、半角，一对里混用也算）里只有依据的，连括号一起去掉，括号前的空白照依据前的空白处理
- 依据在括号开头、后面跟着「，」「、」「；」「：」的，标点一起去掉；在括号末尾、前面紧挨着标点的同理
- 后面就到句末（句末标点、换行、全文结尾）、前面或几个依据之间有停顿标点的，去掉这些停顿标点（冒号不动：它引出的
可能是下一行的表格）；依据夹在两个分隔标点中间的，去掉后一个；依据后面、句末前面的标点是写作者自己的，不动
- 两边都是字时，依据之间的分隔标点可能就是分句的标点，按它断开、照旧处理
- 依据标记本身留在原文里：句子照旧挂着那条依据（unit.see、cites 不变），只是周围的字不显示
- 流式渲染把末尾的括号、分隔标点也攒到后面的字来了再放（_TRAILING_SEE），分块输出拼起来仍等于整篇渲染
不含依据的括号、没有依据的文档一个字不动：两份文档的内容哈希和改动之前（58a6759）一致，对照基线随机渲染 6 万段，
改了的都是依据挨着括号、分隔标点的，不含依据的 2 万段逐字相同。封存过的文档复核不重新收拾原文，照旧通过。
2026-10-07 00:04:41 +08:00
79c9559079
K3b：质询模块说明的遮罩一节补上派生来源里分档、外层分组的标签列不算
2026-10-06 23:25:59 +08:00
6ba4d9f099
K3b：反方审稿查数据源类型时直接用整份报告用到的源，不再逐件取工件
...
claim_sources 已经认全了查询的、合并查询合并的、指标输入取自的、表和字段的数据源，_kinds 不必再把目录里每件工件都取一遍。
2026-10-06 23:23:40 +08:00
4b461e86e6
K3b：说明写清工具边界不按值换数值格的取舍；LATERAL 的 ON 条件里看得见它自己连的来源
...
整行引用找列时，在连接的来源本身里（LATERAL）只看得见前面的来源，在 ON 条件里连这个来源自己也看得见（_visible_sources），和 Postgres 的作用域一致。质询的已知局限补上：没设遮罩的列里存成数的号码工具边界不按值换、agent 看得到，要遮就在那个数据源上把那一列也设成遮罩；mask_query_result、模块说明按这一轮的改动重写，长行重新折好。
2026-10-06 23:17:15 +08:00
888f746d31
K3b：交给核查 agent 的证据摘录先遮；反方审稿的理由过最后一道关
...
- 摘录由 judge.prepare 生成，以前 _hidden 只按列名遮：报告取数把遮罩列改了名字选出来（buyer_phone AS 手机号），质询、反方 agent 的任务里四个号码都在，模型照抄进理由。现在 prepare 收 kinds（{数据源名: 类型}，只有核查 agent 的摘录给），查询摘录、指标输入按 masking._derived_hidden 认出改了名字的遮罩列（和工具边界同一套规则，表结构按快照冻结的那份），认的过程出了意外整份的列都不给；结论句裁判自己的摘录不给 kinds，和以前逐字相同、复用键不变。反方审稿、审批质询再把摘录里别的列、SQL 里写着的遮罩值按值换成「已遮罩」（换了写法的号码也认），值同交给查询工具的那一份（报告快照里的，反方去掉这句结论原文里写着的）；解析 SQL、按值换放进线程。
- 反方审稿的理由按值遮之后，正文、理由文档（正文、原文、目录里的列名）里还认得出遮罩值的，这句记为无法判断、理由换成系统说明、不存理由文档（_kept，同审批质询的 _leaked），遮不住的「被推翻」不再让出具降档。
补测试：质询、反方各一条端到端（任务里的摘录没有号码，手机号列不给，SQL 里的号码、备注里换了写法的号码换掉），反方理由里 agent 自己查出的号码换着写法也换掉，最后一道关；分别去掉按 SQL 认列、两处按值换、agent 查到的值、最后一道关，对应的测试都变红。
2026-10-06 23:11:22 +08:00
6ba7babdf0
K3b：认不全的 SQL 写法整份遮——(表达式).* 展开、表名和 SQL 写在字符串里的函数、分析出意外或超出工作量上限；LATERAL 看不见它自己；一长串 CTE 不再卡住
...
- (表达式).* 展开（复合类型的列 (p.profile).*、记录函数 (jsonb_each_text(pj)).*、(jsonb_populate_record(…)).*、子查询里的匿名 ROW (q.r).*）以前被改写成对不上来源的 *，最外层、UNION 第一支、没写列名表的派生来源里按「照原名带出」认，字段名对不上遮罩列，号码原样交给模型、落库（K3 第 3 轮引入的回退，15 条新漏）。现在 _normalized 只把 (s).*、s 是这一层 FROM 里的来源时改写成 s.*，别的先记下表达式的值取自哪些列（整行引用已改写），读到遮罩列的整份遮。
- query_to_xml、table_to_xml、cursor_to_xml、schema_to_xml、database_to_xml 这一族、dblink、crosstab、DBMS_XMLGEN、DuckDB 的 query、OPENQUERY，按页按文件读原始数据的，pg_stats、sqlite_stat4、pg_stat_statements 这类存着值的统计、会话视图：按名字认出整份遮（_INDIRECT），解析不了的也一样。
- 整行引用由里往外找列时，LATERAL 里只看排在它前面的来源（_visible_sources），它自己的结果列碰巧叫 s 也不把整行 s 当成列。
- 一次分析里记下派生来源对应的那块查询和一项的值取自哪些列（_analysis，按线程分开），250 段一段套一段地整行引用的 CTE 从二十几秒降到零点几秒；超出工作量上限（ANALYSIS_STEPS）的整份遮。解析之后的分析出了意外也整份遮，不再退回只看文字（没写遮罩列、没有 * 的整行引用以前就放过去了）。
补测试：三种展开 × 最外层、子查询、CTE、LATERAL，端到端经核查 agent 的查询工具，九种函数和视图，LATERAL 自身，工作量上限、分析意外、长 CTE 的耗时；分别去掉每一处实现，对应的测试都变红。
2026-10-06 23:03:35 +08:00
8c229c3d1a
K3b：分档写在派生来源里、外层按它分组的标签列照常显示，和当分组键的 CASE 一样
...
以前分档写在子查询、WITH 里（SELECT *, CASE … END AS 档位 FROM sales），外层再按档位分组，工具边界把档位整列遮成「已遮罩」，模型分不清哪个数属于哪一档，质询回答成了「已遮罩有 3 笔，已遮罩有 2 笔」。现在 _derived_hidden 认出只装着标签（_label_columns）、又一档一行的结果列（这一层或派生来源里那一层的 GROUP BY 键，按位置、别名、照原样写都算，_grouped_labels），不算取自遮罩列：格子里只有标签、和遮罩列不同名才算，认不出的照旧整列遮；SQL 里照旧认得出它取自金额。工具边界、质询回答、质询工件用的是同一套。* 展开的表在冻结的表结构里查得到、没有同名列时标签照常认（原来就有），不知道表结构时照旧当它带得出（多遮）。测试 test_inquiry_masking 里「外层再分组照旧算」的两个用例按新规则改；补六种写法的工具边界用例、逐行和混了别的值的反例、质询端到端用例，去掉豁免后全部变红。_tainted 多交回一个「认不出、整份都算」的标记，整份遮时不豁免。
2026-10-06 22:52:28 +08:00
3ced800cde
K3b：工具边界的按值遮只换文字格，换过的格子记进快照；占位的短词不当遮罩值
...
以前工具边界按值遮扩到没设遮罩的数值列：访问次数正好等于某一笔被遮的金额，交给模型的、落库的都成了「已遮罩」，column_types 仍是 number、快照不留记录，盲算引用到时说成「不是数值」，存下的证据被改写。现在 _masked_view 在工具边界不按值换数值格（数、列类型记成 number 的格子），只换文字格（整格就是遮罩值的、文字里夹着的那一截），换过的格子随快照存下（masked_cells：[行, 列号]，不交给模型），核查 agent 的格子引用指到它们时照实说是遮罩。回答、质询工件里的按值遮（第二道防线）照旧。遮罩列里占位的写法（未知、暂无、N/A……）不收进遮罩值，没设遮罩的区域、备注里的同一个词不再被换掉。补测试，分别去掉数值格的豁免、masked_cells 的记录、引用时的判断、占位词的过滤，对应的测试都变红。
2026-10-06 22:44:48 +08:00
03209d7db5
K3b：工具边界的遮罩分析出了意外时整份遮，兜底不再经逐格换值那一步
...
mask_query_result 的兜底原来又调一遍 _masked_view：出意外的正是它时兜底跟着出意外，结果交不出去，模块说明里「分析出意外就整份遮」也没有测试证明。改成 _masked_whole 直接把每一格换成「已遮罩」、类型记成文本，masked_at_query 记全部的列。补测试：认遮罩列、认标签列、逐格换值三处各自出意外时，交给模型的工具结果、落库的快照、通用工件接口都只有「已遮罩」，格子引用照实说是遮罩列；把兜底改回原样放行，这几项全部变红。
2026-10-06 22:38:15 +08:00
58a6759fe2
合入期 5 前置修复 K3：核查 agent 的查询结果在工具边界先遮——取自遮罩列的结果列（别名、函数、子查询、WITH、*、UNION、表值函数、整行引用都认）在交给模型的内容和落库的快照里都换成「已遮罩」，模型看不到遮罩值；按值遮降为第二道防线；换了写法的长号码（空格、连字符、点、括号、全角、国家码）在回答、理由、工件和最后一道关里都认得出；认遮罩列的共用部分挪到 engine/masking.py
2026-10-06 22:19:42 +08:00
39b4b6d608
合入期 5 前置修复 L1：上传表格建的数据源按导入配方里的逻辑类型认日期列，双盲复算的选择能写成业务日期；报告的结论句策略要求核对、正文却写在代码块里（结论句为 0）时，出口契约记一条缺口、不再判完整出具；compose_doc 的说明照实写 source 来自调用方
2026-10-06 22:19:34 +08:00
b0fdf56eed
K3 复核修正（第 3 轮）：写了库名的表按「库名.表名」查表结构；UNION 第一支按表结构数出的列名要和后面每一支一样宽才用；整行引用、函数参数里的 *、表的列名表、TABLE x、PIVOT 这类认得出
...
- 写了库名的表（复核 major 1）：表结构以前按表名查，查询写的是另一个库里的同名表（archive.sales，列序不同）时照探查
的那张数位置，号码原样交给模型、落库。现在表结构另按「库名.表名」记一份（库名取探查时记下的 schema、qualified 的
前缀，masking._schema_keys），写了库名的引用按它查（_table_key），查不到的按数不清整段遮；探查时没设 schema、查询又
写了库名的也查不到（多遮）。数位置（_star_columns、_branch_names）、认标签列（_table_lacks）都照这个查法
- 过期的表结构（复核 major 2，对 099473c
2026-10-06 21:50:48 +08:00
6a7e51b81b
K3 复核修正（第 2 轮）：* 把遮罩列带进别的列名时按展开落到的位置遮；函数参数里的 JSON 箭头认作遮罩列；agent 查到的遮罩值和报告里的分开记，上限收满也不丢
...
- * 改名（复核点名的 blocker）：WITH t(a, b, …) AS (SELECT * …) 这类列名表、UNION 后一支的 *、FROM 子查询或 LATERAL
的列名表、标量子查询和 ARRAY 子查询里的 *，以前 * 本身不算取自哪一列，原值原样交给核查 agent、落库，第二道防线也
认不出。现在 * 带出遮罩列的值时，它展开落到的那几列都算（masking._star_places）：只展开一个来源、每一列都数得清的
按位置只遮取自遮罩列的那几列——子查询按选出项数，数据源里的表按查询当时冻结的表结构数（_schema_columns；工具边界
用数据源的 schema_cache，事后按快照的 schema_artifact，是同一份），几张列一样的月度表 SELECT * 连起来汇总，金额照常；
数不清的（没有表结构、列数对不上、几个来源）整段遮。表结构只用来数位置，不用来断定表里没有遮罩列。标量子查询里的 *
按 _value_columns 展开（展开数据源里的表一律算），EXISTS 里的 * 不算；递归的 CTE 不会绕不出来；带 EXCLUDE / REPLACE
的 * 不按位置数
- JSON 箭头：函数参数里没写表名的 col->'path' 被 sqlglot 解析成以 col 为参数的 lambda，_value_columns 把 lambda 的
参数名照列名收。SQLite json_each(profile->'$.tels')、Postgres jsonb_array_elements_text(profile->'tels')、MySQL
JSON_UNQUOTE(profile->'$.tel') 这几种拆开、取出来的值在工具边界就遮
- 上限：run_verify_agent 以前先把调用方交进来的报告快照值并进 seen，收满 SECRETS_MAX 之后 agent 查到的值并不进去，后面
的查询、回答时的第二道防线都认不出。现在两份分开记（masking.SeenValues：given / found），查询工具按值遮、交回调用方
（VerifyOutcome.masked_values）时合起来，agent 查到的在前；反方审稿理由的按值遮也改成 agent 查到的先收
- 已知局限写进 inquiry 模块说明：表结构过期、列数没变却换了次序或改了名时可能数错；EXCEPT 后一支照 UNION 算（多遮）
测试：新增 test_masking_star_renames（真跑 SQLite 的各种 * 改名、按表结构数位置、表结构对不上、快照记着的表结构），
工具边界（交给模型的、落库的、通用工件接口）和审批质询端到端的 * 改名、JSON 箭头、上限收满；每处实现都做过去掉之后
测试变红的验证。
2026-10-06 20:29:58 +08:00
6d9d31395b
出口契约认藏在代码块里的正文改为逐行标出代码：写明是文字的块不再因为一行 SQL、一行像 YAML 的键或 + / - 要点就整块当代码，公式、JSON、目录树这类像数据的行照代码看
...
上一轮先判整块：只要有一行以 SQL / Python 关键字或小写键开头，或者每行都以 + - 空格 @ 开头，整块就当代码，只认去掉
注释、字符串之后还成句的行。写成 markdown、text 的块里，+ / - 开头的正负面要点、正文后面另嵌的 ~~~sql、缩进的 select、
一行「- note: …」都让不带句读的结论认不出，藏进代码块反倒完整出具。反过来，写明是文字的块不去字符串，六字连写、结论词
又对公式、JSON、目录树、print、流程箭头这些行生效：结论句为 0 的报告贴一段带「占比」的公式就降档，缺口还说正文写在
代码块里。
- 逐行标出代码（_code_lines），不再整块判：块里再嵌、收得了的代码块（~~~sql、````，开了没收的那一行照普通的行看）；
SQL / Python 语句从开头那一行到这一段结束，续行也算；整段是 YAML 的（第一行是小写键，其余是键或缩进的行；写明是
文字的块里另要有值为空的键，一行一个「- note: 一句话」是正文里的标签）；像数据、公式的行（前面有字的等号和箭头、
画目录树的制表符、JSON 的开头和「"键":」、函数调用、文件名、逗号隔开的表头）。代码的行只认去掉注释、字符串之后
成句的，别的行照旧：写明是文字的按 _written，信息串为空的按 _prose_line
- diff：写明是文字的块里 + - 后面空一格的是列表项，紧挨着字写的才是 diff；信息串为空的块里第一个改动行是 + 的是
正负面要点（diff 先列删掉的行），有 @@ 块头的照旧是 diff
- 一段到空行为止，只写着块注释的行不算空行；写明是文字的块里顶格的标题另起一段。块注释、三个引号括起的多行字符串
涂成空格，行数不变
- SQL 关键字只认全小写、全大写，def / class 要写成定义的样子：「From 数据看……」「class A 门店……」是正文。代码的行里
-- // 紧挨着前面的字也算注释
- 取舍写进 _fenced_body 的说明：一块里只要有一行在写正文就记缺口，拿不准的行宁可当代码，藏起来的正文总有别的行认得出
测试：复核里的写法逐一补上：+ / - 要点（markdown、text、信息串为空）、嵌 ~~~sql、缩进的 select、小写键的标签，正式
运行降档并只带这条缺口；带「占比」「增长率」的公式、写成 text 的 JSON 和目录树，在结论句为 0 的报告里照常完整出具。
单元参数另补 print、groupby、流程箭头、文件名、逗号表头、JSON 数组、多行 SQL 夹块注释、docstring、嵌套的 YAML、开了
没收和收尾更长的嵌套围栏、行首箭头、首字母大写的关键字、先列 + 的带 @@ diff，并钉住两条取舍：写成 text 又空一格的
diff 照列表看；信息串为空、整段都是小写键的照 YAML 看。长行耗时用例扩到七种长行、两种多行围栏、两种信息串。逐一去掉
36 处规则（diff、嵌套围栏、语句、关键字大小写、def / class、YAML、分段、像数据的七种写法、注释、块注释、多行字符串、
正文判法、结构片段、挂钩），各有用例变红。
2026-10-06 19:51:29 +08:00
7255ae98a5
模型接入报错收尾（第 1 轮复核，后端）：交给设置的核查、裁判落到演示模型照实说；给不出修复时说卡在哪里；接入名恰好是模型名那句按这一处检查器里有哪几栏写；修复规划只重算被改的节点；助手栏那一格另给一份说法；几处措辞对齐
...
- 「不指定接入」交给设置（核查模型、裁判模型）时：启用的接入全是演示类，设置这一级不管写的是什么，执行时落到的都是
演示模型，说明照实带上「（演示用，不调用真实模型）」、候选带 demo 标记；一个启用的接入都没有时不算落得稳（同别处
「换成内置演示模型」不算）。以前 land() 在判演示之前就把交给设置的一处当成落稳返回了；
- 检查器里没有下拉框、发布前检查又给不出修复时，提示末尾补「无法改用其他接入：」加第一处落不稳的地方（Landing.why，
比如「成员「研究员」指定的模型「小模型」所属的模型接入「旧接入」已停用」），不再只剩「核对名称」让人去设置里找一个
找不到的名字；
- 点名的接入名恰好是某个启用接入的模型：画布、发布前检查按这一处在检查器里有哪几栏写（provider_refs._model_note）——
模型调用一类在节点的「模型」中选择它，接入在发布前检查里改用这个接入或选择「不指定接入」（修复里有哪项说哪项）；
协作成员、全图默认只说可在发布前检查里改用；核查节点、报告自己的结论句裁判两栏都在，照设置页写这两栏的叫法。
不再叫人去一个没有的「接入」栏留空。运行时报错不分节点类型，「填写」改为「选择它」；
- 修复候选修完以后落到演示类接入的带 demo 标记，发布弹窗据此在选项名旁加醒目的标签；
- 性能：改一个节点的配置只影响它自己取模型的那几处，修复规划（autofix._ProviderPlan）每试一个候选只重算这个节点
（provider_refs.node_uses），不再深拷贝、重算整张图；问题提示只问给不给得出（provider_fixable，找到第一个落得稳的
就停）；接入问题的引用整张图只算一遍。60 个节点都点名同一个停用接入时，画布校验里这一部分约 0.35 秒降到约 0.002 秒，
发布前检查约 0.72 秒降到约 0.01 秒，一次应用 30 条修复约 2.7 秒降到约 0.09 秒；
- 助手：GET /api/copilot/model 另给 panel_error（写在助手栏「助手使用的模型」那一格下面，去向写「上方」，不把人指回这个
下拉框本身）；接入名恰好是模型名时并成一句，不再两次提「助手使用的模型」；PUT /api/settings 里助手那一项的 422 用
助手报错那一句（那里只有一个选模型的下拉框，没有「换一个接入」的地方）；
- 裁判设置的格式检查写「留空表示跟随助手的模型」，同设置页空选项（engine/judge.py 一行，同核查那条的改法）；「交给助手」
后只剩接入问题时写「助手无法处理」，有修复时另起半句「也可在各条问题下方选择改用的模型接入」。
测试：test_provider_ref_wording 加演示落在设置上、demo 标记、给不出修复时卡在哪里（含一个启用接入都没有）、各处的
接入名恰好是模型名、助手栏那一格的说法、助手那一项的 422、裁判格式检查、规划开销随节点数线性增长（数试算时算了多少处
取模型的地方）；其余几个文件跟上新说法。新加的核心用例都做过去掉实现、测试变红的验证。
2026-10-06 19:43:44 +08:00
099473cd6d
K3 复核修正（第 1 轮）：后面的查询按此前遮掉的值遮、质询工件照回答时记下的位置重放；表值函数拆开遮罩列也认；汇总遮罩列的指标不派盲算；反方理由按值遮
...
复核发现质询工件接口相对基线回退：agent 自己的查询快照在工具边界遮好之后，事后取质询工件收不到它另一次查询里的号码，
没设遮罩的备注、联系方式列原样给出。另有几处模型照样看得到遮罩值、或者遮多了的地方。
- 工具边界（tools/datasource、engine/masking.mask_query_result）：此前已经认出的遮罩值（这个 agent 前面的查询遮掉的、
调用方交进来的）也用来按值遮后面的结果，数据源没设遮罩的也一样。审批质询、反方审稿在派 agent 之前把报告快照里的
遮罩值交进来（inquiry.snapshot_secrets，run_verify_agent 的 masked_values），模型从第一条查询起就看不到。已经摆在
读者眼前的值（提问人写的、报告指标、被审的结论原文）跟着并进来的值一起免遮（_Secrets.protected）；这份结果自己写
的分档标签不按前面收的值换。
- 先查备注、后查出号码的：回答时只靠内存里的值才换掉的地方按快照记成位置（不含值，masking.view_edits），写进质询
事件的 masked_cells，质询工件接口先照着重放（replay_edits）再按原来的办法遮。工具边界按值换掉的整格照样画成遮罩列。
agent 查到的值先收、报告快照的后收：上限收满时不丢 agent 自己查到的。
- _derived_hidden 认 FROM、JOIN、LATERAL 里拆开遮罩列的表值函数（json_each、json_tree、unnest、jsonb_each_text、
regexp_split_to_table、JSON_TABLE、LATERAL VALUES）：按出列名认，不认得的函数又没写列名表的整份遮。
- 汇总里的 CASE 只在条件里用到遮罩列的不算取自遮罩列（同写在 WHERE 里）。双盲复算按同一套认法认出指标取自遮罩列
（SUM(amount)、amount 设了遮罩）时，派盲算之前就记为无法复算并说清原因，不白花一次盲算（nodes/dual_check 的
_query_input，改动在文件所有权之外，只加这一处判断）。
- 反方审稿：理由正文和理由文档按值换掉遮罩值（换了写法的也认），这句结论原文里写着的不换；重新组装时引用到的格子按
遮好的快照渲染。
- 换了写法的号码另认不换行空格、窄空格、细空格、制表符、减号，最多四个分隔符；SQL 的字符串、带引号的名字、注释里
也认（不带引号的数照旧是算式），字符串里换掉的号码同一条 SQL 里写成阈值的也不留；列名同样认。
- 查询失败时报错原话里的值换掉（mask_error_text：引号里、不带引号的长数，SQL 里写着的照留）。
- 快照的 mask_columns 只记数据源设的列名，改了名字的结果列只在 masked_at_query：证据面板并各份快照的这一项从表的
字段清单里去列，混进别名会误藏同源别的表里同名的真实字段。
- * 展开数据源里的表时按冻结的表结构认它带不带同名列，没有的照常认分档标签（J2 收紧之后的多遮）。
- 格子引用指到按值换掉的格子时照实说；上万个值的合并、免遮放进线程。
测试：质询 agent 先查号码后查备注、先查备注后查号码、另一张表的号码列两种先后，质询工件、通用工件接口、事件都没有
原值；报告快照里的值在第一条查询就遮；表值函数（SQLite、Postgres、MySQL 的写法）、汇总里 CASE 的条件、* 连着的表按
表结构认标签、新的分隔符、SQL 字符串和注释和列名、报错原话、mask_columns 不混别名、遮罩列汇总的指标不派盲算、反方
理由按值遮且免遮结论原文、上限收满时 agent 的值先收。逐处去掉实现（24 处）对应的用例都会变红。
2026-10-06 19:11:14 +08:00
46403a0aac
出口契约认藏在代码块里的正文改为逐行看字、不看列表标记；信息串为空的块里 YAML、diff 不再当成正文
...
上一轮按列表标记认不带句读的行，只认 - * + • 和「1.」「1)」：中文报告常见的「1、」「一、」「（1）」、· ● 开头的行和
不带标记的行藏进代码块仍是 0 句、完整出具，不包反倒降档。同一条规则对信息串为空的块都生效，结论句为 0 的报告里贴一段
写着中文列名的 YAML 或改口径的 diff 会降档，缺口还说正文写在代码块里。
- 不再按标记认：标记写法太多，补一种漏一种。一行按正文的规矩会算一句结论（evidence._classify 认文字结论的那条：
方向词、因果词，又不只是在下定义，且有两个以上汉字）就算在写正文，不论标记，与不包代码块时的判法一致
- 信息串写明是文字（markdown、text 这类）、里面也看不出是代码的块：另认一行里连着六个以上汉字的（表格的列名、
门店名这类标签多在五个字以内）；不当代码看，# -- 和半角引号都是正文里的符号；标题不算（正文里的标题也从不算结论）
- 块里看得出是代码（SQL、Python 开头的行，小写开头的 YAML 键，整块是 diff），不论信息串写的是什么，只认去掉注释、
字符串之后成句的：值里、别名里的「最高」「占比」这类词不算；正文里首字母大写的「Note:」是标签，不算 YAML 的键
- 信息串为空、看不出是代码的块：去掉注释、字符串之后成句，或按正文的规矩会算结论；不带句读也不像结论的列名不算
- 围栏那两行是挂在代码块上的结构片段，判断时只看块里写的内容
测试：1、 一、 （1） · ● 和不带标记的写法藏进代码块（另有信息串为空的一种）正式运行降档并只带这条缺口；YAML 列表、
diff 在结论句为 0 的报告里照常完整出具；单元参数补上引用块、表格、粗体、短结论、正文里的 # -- 引号，以及 YAML 键、
diff、SQL 别名、写成 text / markdown 的代码、不到六个字的标签、只有标题。逐一去掉六字连写、两处结论词、代码判断
（YAML、diff 各一次）、不当代码看、结构片段过滤、小写键、标题跳过、挂钩，以及换回按标记认的旧规则，各有用例变红。
2026-10-06 18:44:21 +08:00
b7da8a9af9
出口契约认藏在代码块里的正文：只挂 [[see:]] 依据的、不带句读的列表项也认，代码里的注释和字符串不算句子，英文句子改成线性扫描
...
上一轮只看片段里的引用和带全角句读的行，几种写法仍会让正文藏在代码块里照样完整出具，另有几种代码被当成正文：
- [[see:]] 记在句子的 see 上、不在片段里：只用 see 挂依据的列表现在也认
- 中文报告的列表项常不带句读：以 - * + • 或「1.」「1)」开头、后面有两个以上汉字的行算成句；信息串为空、看得出是
SQL / Python 的块里（有 SELECT、FROM、def、import 这类开头的行），以 * + - 开头的是运算的续行，不当列表项
- 信息串写成 plaintext、txt、plain 的和 text 一样算写文字的代码块
- 判句之前去掉字符串字面量（可带 f、r、b、u、N 前缀；英文的 it's 这类不动）和行尾注释（-- // #），# 开头的行、
跨行的 /* … */ 块注释都不算：SQL 行尾的中文注释、print 里带全角标点的字符串不再让 0 句的报告降档
- 认英文句子的正则对很长、不带句末标点的一行是平方级回溯（出口复核在事件循环上同步执行），改成按词串逐个数单词，
耗时随行长线性增长
check-decode 补一项：从 io.py 读出 GAP_FENCED_BODY，钉住它归「校验不完整」、不进核查的两组。补参数化用例和端到端
用例：只挂 see 的列表、不带句读的列表、plaintext 包住正文的正式运行降档并带这条缺口；带行尾注释的 SQL 照常完整出具；
四万多字的长行一秒内判完。
2026-10-06 18:03:12 +08:00
04606cfe94
双盲复算写业务日期：真写按写入时的版本重读上传表格导入时认作日期的列，几个列表块写同一张表时每一块都记为日期才算
...
record_choices 的表结构是写入时现读的，候选里的 upload_dates 却是发起审批时读的：审批停着时上传源换了版本、把日期列
改成文字，两份拼在一起会写出一条哪个版本单独看都不会给出的人工确认。现在候选里带 upload_dates 的，真写在读数据源的
同一个会话里按当前版本重读、覆盖候选里的那份，和表结构出自同一个版本，版本没变时预告和真写仍一字不差；候选里没有
这一项的是升级前发起的审批，卡上预告的是不写，照旧不认。
recipe_dates 以前只要有一个列表块把某列记为日期就算日期列：两个工作表的列表块写同一张表、同一列一个日期一个文字时，
表形状一样（都存成 TEXT），配方校验不拦，按文字导入的那一块存的是单元格原文。现在写这一列的块都记为日期才算。
补测试：审批停着时修改配方把支付日期改成文字，裁决后照实说按文字保存、不写；没有 upload_dates 的老候选不重读、照旧
不写，带着的按写入时的版本重读后照写；两块类型不一致的列不算日期。
2026-10-06 18:03:12 +08:00
450758185d
K3：核查 agent 看到的查询结果先遮、存下的快照也遮
...
双盲复算、反方审稿、审批质询共用的 engine/verify_agent.py 以前把查询结果原样交给模型（db_query 自己落快照，ToolMessage
里是原样的结果），遮罩全靠审批质询事后按值认，期 4 起六轮复核每轮都找到新的漏法；运行详情「工件」页签走的通用接口
GET /api/artifacts/{id} 还把核查的查询快照原样给出。根本的修法是不让模型看到遮罩值。
- tools/datasource：查询工具加遮罩开关 mask_results（缺省关，Agent 节点、调用工具节点照旧）。打开时数据源设了遮罩的，
先按 engine/masking.py 的 mask_query_result 遮好再交给模型、再落快照：列名直接对上的、按 SQL 认出取自遮罩列的
（别名、函数、子查询、WITH、SELECT *，复用 _derived_hidden；SQL 解析不了又写着遮罩列的，整份结果的列都遮）整列
换成「已遮罩」、类型记成文本；同一份结果里别的格子整格是遮罩值的换掉，文字格里夹着的那一截换掉（换了写法的号码
也认）；列名不换。结果里一列都没取自遮罩列的（数值的汇总、只数个数、只在条件里用到）原样。快照里 mask_columns
另记下查询时遮了的、改了名字的结果列（证据面板、质询工件据此画成遮罩列），masked_at_query 记下查询时就整列遮掉的列。
这一次遮掉的值并进 ToolContext.extra[MASKED_VALUES_KEY]，只在内存里。
- verify_agent：建查询工具时和 force_readonly 一样打开遮罩开关；格子引用指到查询时就遮了的列，照实说是遮罩列、不采信；
遮掉的值经 VerifyOutcome.masked_values 交回调用方（不进 as_dict、不往外交）；系统提示补一句「已遮罩」是什么。
- 审批质询：按值遮降为第二道防线。agent 自己的快照查询时就遮好了，收不到遮罩值，改由 masked_values 并进来（_plan 的
seen），回答、查询清单照旧按值遮；「已遮罩」本身不收成遮罩值。事后取质询工件时内存里的值已经不在，SQL 检查结果的
片段、说明照事件里记下的那条 SQL 换（_recorded_swaps：逐词对出回答时换掉的字面量和 LIKE 里换掉的那一截）。
- 双盲复算取盲算值、反方审稿的引用、证据面板、可验证报告（带遮罩的快照只给哈希，照旧）、推演、运行对比（不收核查的
查询）都按快照里已经是「已遮罩」照常工作，文件不用改。
测试：核查 agent 选出遮罩列（直接、别名、函数、子查询、WITH、SELECT *）时交给假模型的 ToolMessage、落库的快照、通用
工件接口、tool.end 预览、收尾交给模型的查询结果里都是「已遮罩」；没碰遮罩列的聚合查询原样、照常取值；文字格夹着的
号码换掉那一截；引用遮罩格子不采信；SQL 认不出时整份遮；开关缺省关、没设遮罩的源快照一字不差；列名不改；审批质询、
反方审稿、双盲复算各补一条端到端；质询工件的检查片段照记下的 SQL 换。逐处去掉实现（开关、并进内存的值、照记下的
SQL 换、跳过「已遮罩」、遮罩格子的说法、记下改了名字的列、文字格按子串换、不改列名）对应的用例都会变红。
2026-10-06 17:36:55 +08:00
4673e51bb8
模型接入报错的说法与修复候选收尾（后端）：修复规划只否决这次改动造成的失败、问题只认自己那一处的修复、没有修复时提示不指到发布前检查、落到演示类接入照实说；各处说法对齐
...
修复规划（autofix.provider_choice，原 _plan_provider 的主体，provider_refs 也用它判断给不给得出修复）：
- 改动波及的一处，要是点名的接入没变、而那个接入本来就不存在或已停用，它落不稳不是这次改动造成的，不再拿它否决候选。
以前两处互相牵连（节点点名的接入写错、模型取全图默认里停用接入的模型）时两条问题都没有修复，规划器自己卡住；
- 点名的模型接入一处一条修复，annotate 只认（编号、节点、字段）都对得上的那一条，认不出就是没有，不再退到同节点、
同编号别处的修复（以前全图默认那条的 fix 会指到某个节点的修复上）；
- 一个候选都落不稳时，问题提示不再写「或在「发布前检查」中改用其他接入」，只说去设置里核对、启用；
- 修完以后落到演示类接入（kind 为 mock）时，「不指定接入」的说明写明「演示用，不调用真实模型」，和「改用演示接入」
那一项一致——K1 要防的就是悄悄换成演示模型。
说法：
- 双盲复算、反方审稿的问题写「……的「盲算模型 · 接入」指定的模型接入」，不说「盲算模型指定的接入」（修复标题仍按角色说）；
- 点名的接入名恰好是某个启用接入的模型时，运行时报错、画布问题、保存设置的 422、助手的报错都补一句这是哪个接入的
模型、怎么用它（factory.model_note；设置页写那一组模型、接入两栏的叫法），免得照「启用它」去启用那条旧接入；
- 保存设置 422：下拉框选的写「指定的」，不写「填写的」；去掉和设置页空选项对不上的留空半句；助手那一项叫「助手使用的
模型」；核查的格式检查写「留空表示跟随证据裁判模型」，同设置页；
- 「交给助手」后只剩接入问题时的说明：一句一个意思、不再带冒号（界面上前面已有「助手：」），「核对名称」有宾语，不说
「节点」；有一条带修复时才指到各条问题的修复；
- 助手的模型取不到时，提示指到真正能改的地方：「编排」页助手栏的「助手使用的模型」（设置页没有这一项）；
- 节点点名了接入、没写模型时校验说「将使用接入「X」的默认模型」（编号 model.unset）；X 本身不存在或已停用时画布校验、
发布一类都去掉这一条，只留接入那条，不再一条说照常执行、一条说会失败。
2026-10-06 17:29:18 +08:00
1136b2d09d
K3：换了写法的号码在回答正文、质询工件的文字格和最后一道关里也认得出
...
验收准备时复现过：模型把号码写成 199-1474-2785、199 1474 2785、199.1474.2785、(199)1474-2785、+8619914742785、
全角数字，回答正文、事件、回答文档原样带着，最后一道关 _leaked 也拦不住，正式运行里永久封存。
engine/masking.py 的 _Secrets 新加 loose_spans：在正文里找允许夹分隔符的数字串（数字含全角，之间夹一到三个空格、
连字符、点、括号，含全角；开头可带 + 和括号），从每一截起往后拼，规范化（全角转半角、去分隔符、去 0086 / 86 国家码）
之后在「遮罩值的纯数字写法」集合里查——集合查找，不现编正则，两万个遮罩值照样不卡。拼出来的要是完整的号码：和别的
数字只隔着一个连字符或点连着的（13900000001-2、日期）、只有两截中间一个点的（小数）不算，同原来按词认的边界。
括号配成对：(199)1474-2785 整个换掉，「（电话 199-1474-2785）」两个括号留着。存的值本身带分隔符或国家码的，也按
纯数字写法认。
- scrub：正文（prose）缺省这样认，文字格（质询工件里夹着的、整格就是号码的）也认；SQL 里不认，199-1474-2785 在
SQL 里是一个算式。
- protect：提问人换着写法写进问题的号码照样免遮；SQL 里照原样留着的阈值换了写法也只在正文里不遮。
- inquiry._leaked：组装之后还认得出换了写法的号码，整份不交。
反方审稿的理由正文目前没有按值遮这一步（理由里只引用反方自己的查询格子，查询结果在核查 agent 的工具边界先遮，见
下一个提交），这里不另加。补单元测试（18 种写法 × 三种存法、不误伤日期小数编号、文字格、最后一道关、提问人写的、
阈值、两万个值的耗时）和端到端测试（11 种写法写进回答都换成「已遮罩」，事件、回答文档里也没有；备注里夹着换了
写法的号码时回答整份不交、质询工件只换那一截）。去掉实现后这些用例都会变红。
2026-10-06 17:11:00 +08:00
7f7b690307
upload_dates 直接取现行配方（current_recipe_id）：发布、启用旧版本时它和当前快照、表结构一起换，不必再经快照和最后一期导入去找；补测试：修改配方把支付日期改成文字后只剩下单日期，回滚到旧版本两列又都是日期
2026-10-06 17:04:42 +08:00
f1e6716d84
compose_doc 的说明对上 K5：doc["source"] 是调用方交来的原文（报告节点交来前去掉了整篇外层围栏，见 report._unfenced），不再说是模型的原文；只改说明，文档字段和内容哈希不变
2026-10-06 17:01:45 +08:00
3e02446542
出口契约：报告的正文仍写在代码块里、一句结论都没切出来时记出具缺口，不再完整出具
...
K5 让报告节点去掉整篇外层的 markdown 围栏，规格有意不去的写法（围栏外有前言、只有开头没有收尾、信息串写成 text）仍会让整段正文落在代码块里：结论句 0 句，裁判不调用、反方审稿记 no_claims，没挂依据的、证据相矛盾的都数出 0 句，正式运行照样完整出具，读的人以为结论都核对过。
- nodes/io.py 的 _fenced_body：文档里一句结论都没有，却有信息串为空 / markdown / md / text 的代码块，里面是成句的文字（一行里有汉字又有中文句读，或五个以上英文单词以句末标点收尾）或者写着引用标记，就是正文被藏进了代码块。信息串为空的代码块里也常是 SQL：看内容，代码注释行（--、//、/* */）里的中文句子不算；sql、python、json 这类信息串不看
- _claims 在结论句策略为 judge 或 require_citation（报告节点的或出具契约自己写的）时，碰到这样的报告记一条缺口 GAP_FENCED_BODY「报告「X」的正文写在代码块里，结论句未能核对」，出具降档。缺口不带核查节点的前缀，时间线写在「校验不完整」下、出具横幅归「校验未全部完成」（run/decode.ts 的 splitIssuanceGaps，报告标题像核查节点名的也一样，界面不用改）
- 行为不变：有正常结论句的、代码块是代码的、结论句策略为 off 的
测试（新文件 test_contract_fenced_body）：认得出的几种（前言、没收尾、text、无信息串、大写 MD、英文、只有列表但写着引用）与认不出的几种（sql、python、json、无信息串的 SQL、SQL 注释里的中文句子、数字表、外面有结论句、没有代码块）；正式运行（裁判 + 反方审稿 + 出具契约）里前言、没收尾、text 三种降档并只带这一条缺口，以前是完整出具；正常报告、整篇外层围栏被去掉的、带 SQL 代码块的照常完整出具；require_citation 写在报告节点或契约上同样记，off 不管。去掉挂钩、去掉 0 句前提、去掉注释行排除、去掉信息串过滤、去掉引用信号、去掉句读要求各做过一次，测试变红。
2026-10-06 17:01:44 +08:00
8c76f91ca9
K3：分档标签列在派生来源里被同名的遮罩列挡住时不再按标签认（J2 第 3 轮复验的缺口）
...
SQLite 让派生来源里同名的几列都留着，外层按名字取的是排在最前面的那一列。以前认标签列只看起了这个名字的选出项，
SELECT vip_level AS 档 FROM (SELECT *, CASE WHEN amount > 1000 THEN 1 ELSE 0 END AS vip_level FROM sales) t 交回的是
真实等级，却被当成只装着标签：等级 1、2、3 撞上 THEN 1 ELSE 0 不收进遮罩值，之后 WHERE vip_level = 1 在查询清单、
事件、质询工件里都照原样封存。
按复核建议保守处理（engine/masking.py）：
- _block_label_of（单支、多支的第一支）：第一个同名项前面有 * 带得出这一列（_star_label 不是 _ABSENT），或者有没起
别名、去掉括号和 COLLATE 后同名的项（(vip_level)、vip_level COLLATE NOCASE，SQLite 给子查询的结果列起名时去掉
它们），都不算只装着标签；
- _star_label：没写表名的 * 展开了数据源里的表（或 VALUES、函数这类说不清出哪些列的来源）为 None——* 把表里的同名列
照样带出来，不像直接写列名那样会报列名有歧义。
补单元和端到端测试：* 在前、t.* 在前、CTE 里 * 在前、JOIN 子查询 * 在前、(col) / ((col)) / COLLATE 在前、多支的
第一支，以及标签排在 * 前面、* 只带出派生来源里的标签时照旧算标签列。三条规则各自去掉，对应的用例都会变红。
另把「SQLite 里带小数的取模先取整」写进已知局限。
2026-10-06 17:00:48 +08:00
0772b42bfd
K3 第一步：把认遮罩列、遮罩值的共用部分原样挪到 engine/masking.py
...
按 SQL 认出取自遮罩列的结果列（_derived_hidden 一套，含分档标签列 _label_columns）、按值认遮罩值（_Secrets）、
快照遮好的样子（_masked_view），连同它们用到的写死值的算法，从 engine/inquiry.py 原样挪到新的 engine/masking.py，
一个字没改。接下来核查 agent 的查询工具要在交给模型之前先遮，工具这一层不该反过来依赖审批质询的模块。
inquiry 照旧按原名导出这些名字（nodes/dual_check 按 inquiry._derived_hidden 引用，测试按 inquiry 的名字引用），
行为不变：质询、双盲复算、反方审稿的相关测试全过。
2026-10-06 16:55:29 +08:00
50f15b40c4
合入期 5 前置修复 K1：点名的模型接入不存在或已停用时照实报错，不再悄悄换成演示模型——各条用到模型的路径照实失败或记为核查不可用；保存设置时 422、画布校验给警告、发布与发布前检查挡住并给修复候选（不指定模型、改用启用的接入），只写模型而提供它的接入已停用也查得出
2026-10-06 16:55:27 +08:00
2cf329648d
上传表格的日期列按导入时配方里的逻辑类型认：双盲复算选了时间列不同的一边时，上传源也能写业务日期
...
J1 给业务日期加了类型门槛（两边的时间列都在表结构里声明为日期 / 时间类型才写），而上传表格导入时日期一律按文字保存、表结构里总是 TEXT，上传源因此永远写不了业务日期。导入时配方里其实记着每一列的逻辑类型（导入确认时界面上标的「日期」）：列表块里类型为 DATE 的列、交叉表的日期轴。查过别处：构建回执里只有存储类型（列表的 DATE 列和文字列一样记 TEXT、role 都是 text），简单导入的回执只有 INTEGER / REAL / TEXT，所以只按配方认。
- dual_check_facts.recipe_dates：一份配方里逻辑类型是日期的列（{表: [列]}），表和列按 recipe_types.derive_tables 推，和建表同一份；日期轴写进它各分段的表，列表合计行另存的表不带日期列；类型按 _DATED_TYPE 认，只有时刻的不算
- dual_check_facts.upload_dates：只读，按数据源当前快照找配方（source_versions.snapshot_recipe_id，期 3 之前的快照取最后一期导入的），和 schema_cache 出自同一个版本；手工源、简单导入、快照或配方记录不在、配方解析不了一律给空
- 节点的 _source_info 带上 upload_dates，放进候选：审批卡的预告（preview / preview_joint）和裁决后的真写认的是发起审批时读的同一份，逐字一致；旧的 checkpoint 里没有这一项，照旧不写
- _dated_problem：上传源里按文字保存的列在 upload_dates 里的算日期列（按表结构认出的表名、列名去对，大小写不论）；不在的、读不出配方的照现在的原因说「来自上传的表格，表格里的日期一律按文字保存」；声明成别的类型的、只有时刻的照旧
测试：derive 一级补导入认作日期的写、只有一边是日期 / 读不出配方 / 记在别的表上的照旧说按文字保存、手工源不认 upload_dates、按表结构的名字对、preview_joint 同样认；新文件 test_dual_check_upload 经真实导入接口建上传源（暂存 → 改配方 → 试运行 → 提交、简单导入），配方里两列都是日期的审核人选盲算后业务日期记「支付日期」（人工确认、备注写运行），支付日期是文字的选哪边都不写、预告和跳过原因一字不差，配方记录改坏了的照旧不写；去掉认日期、去掉候选里的 upload_dates、去掉日期轴各做过一次，测试变红。
2026-10-06 16:54:30 +08:00
0a690a599b
发布前修复点名的模型接入：按执行时的取法算修完落到哪里，只写了模型而接入已停用的也拦下
...
- 「不指定接入」以前只去掉接入、留下同一处写着的模型，复核又只查点名的接入：按模型名落回停用的接入，或者成员跟随节点、节点跟随全图默认，拿别家的接入去调这个模型。检查、发布都通过，正式运行在那一处照样失败
- 现在每个候选（不指定、改用某个启用的接入）先在副本上改，按执行器的取法（成员先看自己、再看节点、再看全图默认；节点看全图默认；都没写按模型名找；核查和裁判整组交给设置）算出改动波及的每一处用哪个接入、哪个模型。落到的接入不提供那一处的模型、按模型名落到停用接入或认不出的模型、落到内置演示模型的，连同一级写着的模型一并去掉再算，还落不稳的候选不给；候选说明写清执行时改用哪里、模型去没去掉、换上的接入实际用哪个模型
- 门禁把哪一级都没写接入、只写了模型而提供它的接入已停用的那一处也记成 provider.disabled（落在写模型的字段，原因和运行时同一句）：复核拒得掉这类修复，检查器里只能选模型的节点发布前也查得出来；这一处配「不指定模型」或改用一个启用接入的修复
- 按模型名找接入、没写时退回哪个接入抽成 factory.provider_for_model、fallback_provider，运行时和门禁共用一份
- 问题面板、修复预览写得出「模型」「成员「x」的模型」；check-publish 的伪造门禁跟上新的候选，补只写模型的一段
- 测试：复核发现的几种形状逐一钉住（含发布前检查修好、保存、发布后正式运行成功的端到端一条）；依赖旧做法的两条测试改成新的正确行为
2026-10-06 16:31:06 +08:00
3f17fd3c71
合入期 5 前置修复 K4：运行把这一段执行的截止时刻交给节点（engine/deadline.py），反方审稿与双盲复算开始每一项前看剩余时间，按剩余时间收紧每项时长、给下游留出余量，来不及的记为未能反查 / 无法复算并写明「运行时限将至」，整次运行不再被时长上限中止；继续运行取 checkpoint 里的结果不重复反查
2026-10-06 16:26:45 +08:00
4314a7fc44
合入期 5 前置修复 K2：核查与裁判模型的输出额度提到 16384，服务方嫌大时退回 4096（和助手共用 providers/budget.py）；每次调用认截断，因推理占满额度没交出结果时照实说（verify_truncated、judge_truncated），不再说成盲算没查到、没按结构交结果
2026-10-06 16:26:37 +08:00
54ab06d615
合入期 5 前置修复 K5：写作模型把整篇报告包在 markdown 代码块里时去掉外层围栏（重写的几轮同样处理），结论句照常可审、裁判和反方审稿有句子可看；别的语言的代码块、围栏外有文字、多个代码块、开闭不配对的原样不动
2026-10-06 16:26:37 +08:00
39068c9636
合入期 4 整合 J2：审批质询遮罩收口——阈值只在同一个数在别处确实被换掉时才遮、夹住某一个值的边界按条件与作用域认、质询工件里未遮罩文字格夹着的遮罩值按值换掉；算式边界、分档标签列、CAST 类型参数等变体照实处理，已知局限写进模块说明
2026-10-06 16:23:26 +08:00
76b485a0ca
审批质询遮罩收口（第 3 轮复核）：标签列按作用域认取自哪个来源，UNION 另一支、子查询里的遮罩列流进标签列照收；取模、整除、整数相除按算出来的值认；CAST 的类型参数不当边界换
...
复核留下的一条 major（第 2 轮只修了一部分）和两条次要问题：
- 分档标签列：以前按名字认，从「所有名字都只装着标签」起往下剔。遮罩列原样选出（SELECT vip_level）时名字就是它自己，
永远剔不掉；结果的 UNION 按位置那一遍只往里加标签，另一支取的是遮罩列也不剔；派生来源里的 UNION 根本不按位置看。
于是标签在前、遮罩列在后（不起别名、别名不同、外层再套子查询、CTE 里的标签再 UNION），遮罩列经按原名选出的子查询、
以标签的别名传出，或者两个子查询 JOIN 起来同名，等级 1 撞上 THEN 1 都不收，WHERE vip_level = 1 在查询清单、事件、
质询工件里照原样封存（对基线是回退）。现在 _label_columns 按作用域认每一项取自哪个来源：结果的这一列在 UNION 的
每一支里都要是结果全为写死常量的 CASE / IIF，或者取自子查询、CTE、LATERAL 里只装着标签的一列（派生来源里的 UNION
也按位置看每一支，写了列名表的按列名表）；取自数据源里的表的一律不算，哪怕和标签同名。没写表名的列，派生来源出
这一列的就是它（SQL 执行过，别的来源就没有同名的列，不然报列名有歧义），按这一列 USING、NATURAL 合成的除外；递归的
CTE、UNION 里落在某一支 * 里的列认不准，照收（多遮）
- 取模、整除：_arithmetic、_worked_out 补上 %、MOD、DIV、//（往零取整，同 SQL）。顺带 / 照数据源的算法算：SQLite、
Postgres 里两个写成整数的数相除只留整数部分（sqlglot 记在 typed 上），以前一律按小数算，age >= 25 AND age < 53 / 2
在 SQLite 里夹住了 25 却认不出；写成小数的（53.0 / 2）、MySQL、DuckDB 照小数算
- CAST 的类型参数（第 2 轮引入，只多遮）：_halves 只收往上走得到这一边的字面量（_lifts），CAST(30000 AS DECIMAL(10, 2))
的 10、2 不再当成算出边界的数换掉，SQL 检查结果的片段里别处的 10、2 也不跟着换；_wraps 里 CAST 只算被转换的那个值，
Oracle 的 CAST … DEFAULT 0 ON CONVERSION ERROR 里的 0 照原样
- 模块说明的已知局限照实更新：标签列认得出、认不准的几种写法；认得出的算式补上取模、整除和整数相除，认不出的补上
位运算、POWER、CAST 改了值的
测试：单元补标签在前、遮罩列在后的八种写法（不起别名、别名不同、子查询里的 UNION、写了列名表的 CTE、CTE 里的标签再
UNION、经按原名选出的子查询传出、两个子查询 JOIN 同名、RIGHT JOIN USING 同名列），按作用域仍认得出的五种标签（外层连上
数据源里的表不写表名、按别的列 USING、两层子查询写了表名、UNION 两支、派生来源的 UNION 经 * 带出）；取模、整除、整数
相除的六种写法和照小数算的三种；CAST 的类型参数和 DEFAULT。端到端补 UNION 标签在前的两种写法、取模和整数相除算出来的
边界。每处实现都逐个去掉验证过测试变红（十一个变异全红）
2026-10-06 16:01:28 +08:00
3c51c40e9d
点名的模型接入：发布前检查给每一处配修复，提示指到界面上真能改的地方，复核发现的几处漏查、误查补齐
...
多数节点（模型调用、Agent、报告撰写、多 Agent 协作、条件分支、结构校验、知识检索）、协作成员和全图默认的接入在检查器里没有下拉框，以前点名的接入坏了只能去设置里建一个同名接入。现在门禁接受接入表（governance.lint_for_publish 的 providers，接口层读好传进来，同数据目录 SQL 检查器），点名接入的问题成了门禁的一部分，自动修复给每一处一条要人选的修复：改用一个启用的接入，或不指定接入；选的接入不提供这一处写着的模型时模型一并去掉。一处一条（修复 id 带字段，复核只认那个字段），协作节点自己的接入和成员的接入各修各的。校验和发布检查的提示按位置写：有下拉框的说「在节点中换一个接入」，别处说「在发布前检查中改用其他接入」；剩下的只有接入问题时交给助手的说明也改成指向这些修复。
复核发现一并修：核查节点自己的开关关着、结构校验不许重试时不再查（执行时根本不取模型，以前会挡住发布）；报告没写裁判配置时查全图默认里的那一份（以前放行，正式运行却全部未裁判）；接入名不是字符串时查助手模型的接口不再 500，设置接口对门控、助手两组的这类值回 422 带字段；助手、表格导入、数据目录起草用的模型点名的接入不存在或已停用时照实说是哪个接入、去哪里改（以前说「尚未配置完成」，停用接入的下一步丢了），删掉两处已走不到的分支。
测试补齐：结构校验让模型修复、知识检索让模型重排、按需裁判各路径的不存在与已停用，助手、定时正式运行、裁判的两种情况，反方审稿节点上点名的接入；修复的候选、应用、拒收和图级默认。
2026-10-06 15:14:26 +08:00
5d4d1fdc15
审批质询遮罩收口（第 2 轮复核）：算式边界、套了 CAST / 汇总的列、换个写法的数、两头不是整数、范围再排除一头都认得出；只装着标签的列才不收标签；截断片段整段去掉
...
复核留下的三条 major 和两条次要问题：
- 范围的一头是算式（age <= 25 + 0、buyer_phone BETWEEN 13900000000 + 1 AND 13900000009 - 8）：夹住的值认得出，算式里的数
却照原样留着，一算就是那个号码。现在几个写死的数的加减乘除按算出来的那一个值认（_lifts）：夹住某一个值的边界、等值、
IN 里的算式，里面的数都换；选出列里算出来的号码按值换；没夹住的算式阈值和写成一个数的阈值一样照原样，正文里复述它
（连同算出来的值）不遮，算出来的值在别处换掉了也不留。原有两条用例（BETWEEN 13900000001 AND 13900000002 - 1、
… AND 13900000001 + 0）的期望随之改成算式里的数都换（多换一个 1、0，号码照样不露）
- 几种找值写法以前认不出：被比较的一边套了 CAST、汇总（CAST(age AS INTEGER) = 25、HAVING MAX(age) BETWEEN 25 AND 25）
改按它的值取自哪些列认（_columns_of）；同一个数换个写法（25.0、025、2.5e1、013900000001）按规范写法和遮罩值比
（_canonical）；两头不是整数的范围（age > 24.5 AND age < 25.5、BETWEEN 25 AND 25.9）在整数上隔开紧挨着的两个整数；
范围再用不等、NOT IN 去掉一头（buyer_phone >= 13900000001 AND buyer_phone <= 13900000002 AND buyer_phone <> 13900000002，
以前号码被当成阈值、回答正文跟着不遮）：等值一类只在同一个条件里和范围合起来看，整数上紧挨着的被排除的数越过去接着
看（age <= 30 时 27 照样成立，不算夹住），跨条件配对仍只看范围比较，不等、IN 单拿出来不当「写出了这个值」
- 算式求值改成不递归（_constants）：visits <= 1+1+…写到 1500 项时以前超过递归深度，整条 SQL 退回按词认，同一句里夹住的
年龄照原样封存
- 分档标签不收进遮罩值的规则太宽（第 1 轮引入）：改了名字的遮罩列（vip_level AS 等级）的 1、2、3 撞上同一条 SQL 里按
条件数个数的 THEN 1 ELSE 0，1 就不算遮罩值，WHERE vip_level = 1 照原样封存。现在只跳过只装着标签的列的格子
（_label_columns：选出项本身是结果全为常量的 CASE / IIF，或者经别名、子查询、CTE 原样传下去的，没起别名的按位置认；
同一个名字在哪一处装着别的就照收）
- SQL 检查结果的说明：码值表里的码值和别的字一样按值换，说明照实写（多遮，不漏），补测试钉住
- 截断的片段停在带空格的遮罩文字值中间（地址）：以前只去掉最后一段，前半截还留着；现在从没闭合的引号、注释起整个去掉
- 模块说明的已知局限照实更新：两个产品取舍保持；夹住的认法补上不等、NOT IN、两头不是整数和越过排除数的规则；新增一条
列出认得出的找值写法和仍认不出的（值藏进和列一起算的算式、拼接、函数拼出来的值）
测试：单元补算式边界、套了 CAST / 汇总、换个写法、两头不是整数、排除一头、不该夹住的几种（范围加不等仍不只一个值、
IN 列表旁的阈值、选出列里的等值和 WHERE 的范围）、上千项连加、改了名字的遮罩列撞上标签、标签列经子查询 / CTE / 没起
别名、截断片段、码值表；端到端补长号码的五种写法（算出来的边界、算出来的等值、两头不是整数、范围再排除一头、补零）、
年龄的六种写法和改了名字的等级列。每处实现都逐个去掉验证过测试变红
2026-10-06 15:08:56 +08:00
48f656f362
证据裁判截断的回复整批不采信，截断另记 judge_truncated，时间线的下一步指到换模型
...
复核第 1 轮的发现：
- 有的网关把截断的强制工具调用解析成半截清单：第一条判定写完、第二条只写了编号。_ask 拿到清单就交出去，不再看截断，于是记成一句支持、一句格式不对、两句未给出判定，llm.end 也不标截断。现在回复被截断就整批记 truncated（最后一条可能只写了一半，也可能判定写完、理由写到一半，分不清哪条完整），纯文本调用同理
- 截断的那一批原来只发 llm.end（时间线标题「结论句裁判未能执行」）和 judge_failed（下一步「检查裁判模型的接入后重新运行」）：截断时接入是好的，同一个模型重新运行多半还是截断。现在另发 judge_truncated（max_tokens、unjudged），judge_failed 不再带截断；时间线上调用那一行说「裁判模型的输出达到上限（N token）被截断」，judge_truncated 那一行的下一步指到在报告撰写节点的「结论句裁判」或设置里换不带推理的裁判模型，入口落到节点的结论句裁判；check-decode 加一节
- 复核层（review.py）认得 judge_truncated：是缺口，记成它自己的 kind
- 退回小额度按 budget_refused 认，和核查同一种记法记在进程里：之后每份报告、每次点击直接用小的
测试补上半截清单（剧本和真实 ChatAnthropic）、纯文本清单后面还在写、截断和格式不对各记各的日志、跨报告记住被嫌大、自建服务的 max_new_tokens
2026-10-06 14:30:15 +08:00
4905de728c
核查截断的回复一律不采信，触顶原因的先后照旧，截断的建议按模型从哪来的说
...
复核第 1 轮的发现（主要一条）：Anthropic 的工具调用写到一半到了上限时，回复照样带着 tool_use（input 是空的，有的网关给半截对象）。工具循环只在没有工具调用时才看截断，于是一轮轮执行空参数的查询，撞到步数上限，最后记成「没有按结构交结果」；收尾的强制工具调用截在半路时解析出空对象或半截对象，空对象记成没按结构交，反方审稿的半截对象（结论写完、理由写到一半）被当成「经受住」，质询把半句话当成回答。
- 工具循环：回复被截断就停，带着的工具调用不执行（半截的 SQL 查出来的数是错的），也不收尾
- 截断前查到过东西的也不再按查到的收尾：截断前查到的不一定是要的那个数，交出去的结果只在 notes 里写一句「可能不完整」，审批卡、反方结论、质询回答都看不到，残缺的结果还照常参与比对和处置。同时长到点一样算半路被掐断，原因照截断说，查过的照记；TRUNCATED_SETTLED 和日志里的 delivered 字段去掉
- 收尾：回复被截断时，解析出来的、从回复里抠出来的都不采信（结构化、普通调用都是），也不退回普通调用
- 上一轮的 give_up 把触顶原因的先后从「先 stopped」换成了「先 refused」：去掉 give_up，收尾被上限拦下时照旧报先撞上的那个（双盲复算按它写无法复算的原因，反方审稿按每日上限决定还派不派后面的句子）
- 截断的原因开头只说「未能给出结果」（质询里提问人看到的就是这句，不说「核查未能完成」）；建议在节点里说「在节点上指定不带推理的模型，或在设置里更换核查模型」（节点上的模型优先于设置，和时间线上的下一步一致），质询只说设置
- 退回小额度按 budget_refused 认，按 (接入, 模型, 额度) 记在进程里
- 时间线：verify_truncated 的副标题固定说「这次核查未能给出结果」，check-decode 跟上；review.py 里 verify_truncated 的注释跟上
测试补上真实 ChatAnthropic（只有 HTTP 层是假的）的循环截断、收尾截断（空对象、半截对象），真实 ChatOpenAI 写到一半的工具调用参数，Bearer 鉴权下 SDK 在本地拒绝时退回 4096，自建服务的 max_new_tokens，跨次核查记住被嫌大，触顶原因的先后
2026-10-06 14:30:03 +08:00
e3f5d566d0
核查因运行时长上限将至没核成的，时间线另起一条并带上原因（cause: run_deadline）；收紧过的核查 agent 触顶时也改说时长上限将至；给下游留的余量看下游还有几个要调模型的节点，时长上限调短时余量跟着缩小
...
为什么（复核第 1 轮）：没开始的句子、指标和收紧后到点的，以前和别的原因记在同一条日志里，没有可机读的字段，界面只能照旧叫人调高每句、每项的上限（调高了只会更快撞线），或去查核查模型和数据源（它们本来就没问题）；前面有一句因别的原因没审时，运行时长上限这个原因还被藏进「等」里。双盲复算只给下游留 60 秒，惯常接法「双盲复算 → 写报告 → 反方审稿 → 成果」里写报告一慢，运行照样在写报告时被中止；时长上限调到 180 秒左右时，固定的 60 秒余量又让核查一项都开始不了。
- 反方审稿：没开始的句子另发一条 challenge_unreviewed，带 cause、run_seconds，不混进别的原因；收紧后到点的那条 challenge_limit 照记 timeout_s（老界面认得），另带 cause、run_seconds 和触顶的句数 claims，同一节点里有句子触了自己的上限时两条分得开。产出的 unreviewed 照算
- 双盲复算：没开始、收紧后到点的盲算结果带 cause、run_seconds，_compare 记无法复算时一并带上（只这一行），dual_check_unchecked 按有无 cause 分两条发，时限将至的那条另带 cause、run_seconds，原话列指标名（最多 5 个）
- deadline.relabel 包住交给核查 agent 的 emit：收紧过的那一项到点时，verify_limit 改说「本次运行即将达到 600 秒的时长上限，时长已按剩余时间收紧到 52.3 秒」，带 cause；别的事件、别的上限原样转发，没收紧时原样交回
- 余量按份算：一份取 60 秒和这一段的 10% 中大的，这一段不到 240 秒时按 25%；下游这一段里（到人工审批为止）每个还要调模型的节点（模型、Agent、协作、子工作流、写报告、双盲复算、反方审稿）各再加一份，合计不超过这一段的一半。默认 600 秒的一段、下游只有成果节点时和以前一样
- 没有截止时刻时一切照旧；决定都还在原来的 @task 里，接着运行取 checkpoint
测试：反方审稿、双盲复算各补一条「另一个原因 + 时限将至」两条分开说、带不带 cause 的用例，反方审稿补一条触了自己上限和收紧后到点分得开的用例；原有用例补上 cause、run_seconds、原话的断言。假的钟钉住下游有写报告时第 3 项只查 40～50 秒（没有时 100～110 秒）；真的钟用 10 秒一段、盲算查到时长用完、写报告要 3 秒，以前在写报告时被中止，现在运行成功。单元测试钉住短时长的余量、下游每个节点加一份和一半的上限、数下游节点（人工审批之后不算、汇合只算一次、环回自己不算）、relabel 改什么不改什么。去掉下游余量、去掉 relabel 后对应用例都变红。
2026-10-06 14:25:38 +08:00
dde0927460
审批质询遮罩收口（第 1 轮复核）：「夹住某一个值」在整条 SQL 里认，只有分档的几种写法各算各的；分档标签不当遮罩值；SQL 检查结果的片段、说明照整条 SQL 换
...
- 夹住：上一轮只在同一个条件里配对，把找值拆到 ON 和 WHERE、WHERE 和 HAVING、INTERSECT / EXCEPT 两支、包在 CASE / 函数 / 算式里、子查询和 CTE 里，完整手机号就照原样封存、回答正文也跟着不遮。现在整条 SQL 里配对，只有 CASE 的不同分支、IIF 的真假两支、SELECT 里不筛行的不同项（选出列、GROUP BY、ORDER BY）、UNION 的不同支各算各的（_apart，看最近公共祖先）；同一个条件里照旧按合起来的真假细看。整数上 <= v、>= v 也隔开相邻的整数（age <= 24 OR age >= 26 就是 age <> 25）；BETWEEN v AND v、>= v AND <= v、> v OR < v 条件里哪一层这样写都算（被更宽的范围吸收、旁边有矛盾的条件、隔着别的条件写也认得出），整数的半开区间仍只看整个条件，成百个相邻分档照旧不遮。条件的各层摊开一次反复用，600 档的耗时和上一轮相当
- 分档标签：CASE / IIF 结果全是写死常量的，标签文字是 agent 写在 SQL 里的，不收进遮罩值，规格原句的 SQL、回答里的档名照原样；当分组键（每一档一行）或套在汇总里按条件数个数（SUM(CASE … THEN 1 ELSE 0 END)）不算派生值，格子照常显示，分得清哪一档几笔；逐行的标签列、汇总遮罩列本身的值照旧整列遮
- 质询工件的 SQL 检查结果：片段是检查器重新写出的表达式，单拿出来认不出在找哪一个值，改为按整条 SQL 里整个换掉的字面量换（简单 CASE、行值、BETWEEN v AND v 里的短的数也换掉，阈值照原样）；说明里照引的取值（「没有码值「3」」）一样换；截断处半截的号码去掉
- 同一个短的数在别处换掉时，别的列上的阈值、LIMIT 照原样：一律换会回退第 2 轮起的「age = 25 AND amount > 25 … LIMIT 25」，写进已知局限并补测试钉住
- 模块说明的已知局限照实改写（分档拆进两个 CTE / FROM 子查询、同一选出列里两档汇总相除会多遮，拆进 CASE 分支 / 不同选出列认不出，运行详情的工件页签不经这里的遮罩）
- 测试：端到端改回规格原句（文字档位、SUM(CASE …)、年龄段 CASE），补 ON/WHERE、WHERE/HAVING、INTERSECT、包在 CASE 里、CTE、相邻整数的端到端用例，单元补拆分写法、被吸收的 BETWEEN v AND v、分组标签、检查结果片段与说明；每处去掉实现都验证过变红
2026-10-06 14:05:52 +08:00
ThearchyHelios