652576bab3
验收第二轮的两处说法：审批质询整理回答那一步超时时，不再建议「缩小问题范围」（问题再小也要整理），改说调大时长上限或换用更快的核查模型，查询中途触顶的那句另补上可调大上限；反方判「被推翻」却没给理由时一句话说清「但没有给出理由」，不再先说「理由没有引用到任何查询结果」再接「反方没有给出理由」，固定的那句补上句号
2026-10-12 15:55:19 +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
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
79c9559079
K3b：质询模块说明的遮罩一节补上派生来源里分档、外层分组的标签列不算
2026-10-06 23:25:59 +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
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
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
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
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
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
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
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
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
898bd8a276
审批质询遮罩收口：模块说明和取质询工件的说明写上 SQL 检查结果的片段照 SQL 换
...
上一处改动（f0e97f6）只在接口说明和 _masked_checks 里写了，模块说明的「读取」一条和 inquiry_artifact 的说明补上，免得读的人以为工件里的 checks 原样给。
2026-10-06 12:34:55 +08:00
8ca750d7ee
审批质询遮罩收口：说明跟上实现——「夹住」越过的连接词含异或、条件长到细看不过来时多遮几个阈值写进已知局限
...
- 模块说明的已知局限补一句：条件长到细看不过来（PIN_WORK）时，两边都隔开的一律按夹住算，会多遮几个阈值
- 测试说明对齐：同一个条件里夹住的那组用例越过的连接词含异或（XOR 用例），HAVING 的用例已挪到自己那条测试；年龄段那条
补上说明
2026-10-06 12:32:48 +08:00
f0e97f614f
审批质询遮罩收口（后端）：质询工件里的 SQL 检查结果字段照证据面板，片段里的遮罩值照 SQL 换掉
...
做项 3 时发现的同一类缺口：agent 的查询快照带着 SQL 检查结果（数据源查询工具对照数据目录查出的问题，checks），质询工件接口
原样带出——sql_excerpt 是从这条 SQL 摘的片段（按遮罩列筛选的那个条件，例如 buyer_phone = '13900000001'），for_model 是给模型
的改法、也照抄了片段。事件和工件里的 content.sql 已经换掉遮罩值，旁边的片段没换，等于从旁边把值露出来；证据面板对报告快照
本来就只给约定的几个字段、不给 for_model。
- inquiry_artifact 里的 checks 经 _masked_checks：字段照证据面板的 _query_checks（不交 for_model），sql_excerpt 照查询清单的
SQL 换（_scrub_sql，和遮罩列做等值比较的短的数、日期这样的字也认得出）
- 界面不读 checks，只是接口上不再带原值
- 补单元测试和端到端测试（把 SQL 检查换成会摘出遮罩值片段的假检查）。做过去掉实现、测试变红的验证
2026-10-06 12:30:52 +08:00
32c3119086
审批质询遮罩收口（后端）：质询工件里文字格夹着的遮罩值按子串换掉，回答一路照旧整份不交
...
第 1 轮起留着的缺口：备注列（没设遮罩）一格写着「客户13900000001来电改址」，手机号设了遮罩、被报告取数选中。agent 引用这一格，
回答被正确拦下（「回答中含有设了遮罩的值……已不予展示」），可事件的 inquiry_artifacts 照样记着这份快照，
GET /api/runs/{id}/inquiries/artifacts/{artifact_id} 返回原样的格子、masked 为空，等于在「不予展示」旁边一点就能看到原值。
- _masked_view 加 embedded：没设遮罩的列里，一格文字（JSON 列按界面画出来的样子）夹着按值认得出的遮罩值，把那一截换成
「已遮罩」，这一格别的字、别的格子照原样；门槛同整格（_Secrets.scrub：够长的数、两个字以上的文字，提问人自己写的、报告
列出的指标和运行输入的值不换）。这一列不记进 masked：界面把记进去的列整列画成「已遮罩」，这一列在数据源里也没设遮罩
- 只有取质询工件这一路按子串换，而且只换要取的那一份（_plan 的 embedded 是工件 id 的集合）；回答一路不动，渲染出来露了
照旧整份不交
- 接口说明写清 masked 的含义：有格子整格被遮掉的列；一格文字里夹着的只换那一截，列不记进去
- 补单元测试（文字格、字典形状的行、JSON 列、整格照旧整格换、回答一路照旧）和端到端测试（回答整份不交，工件里那一格变成
「客户已遮罩来电改址」、其余格子照原样、masked 为空）。做过去掉实现、测试变红的验证
2026-10-06 12:25:48 +08:00
4690063f5d
审批质询遮罩收口（后端）：「夹住某一个值」只在同一个条件里、按条件合起来的真假认；阈值只在同一个数在这条 SQL 别处确实换掉时才不留
...
复验留下的两条多遮回归（遮得太多，不漏）：
- _pinned 收全句所有范围比较一起配对，列名认不出的（SUM(amount)、函数）还和哪一列都配：分档的两个 WHEN 分支、两个选出列、
UNION 两支、WHERE 和 HAVING 各写一边，共用的边界被当成「夹住了某一笔」遮掉，回答里「以 20000 元为界」也跟着遮。改成从每个
比较往上只越过且、或、非、异或、括号，走到同一个条件根的才放在一起看；同一个条件里两边都被隔开了，再按条件合起来的真假看
是不是真只认这一个值（条件里别的部分当成不知道真假，有一种取法夹住就算）。BETWEEN v AND v、>= v AND <= v、> v OR < v、
整数的半开区间照旧认得出；age > 31 AND age <= 25 AND 25 < age AND age NOT BETWEEN 25 AND 31 这种谁也找不着的不算，第 2 轮的
原输入恢复并通过。列名认不出的只和写得一样的表达式配
- 夹住的值另记下来：两头都不是那个值的整数开区间（age > 24 AND age < 26）按夹住的 25 换，不再留着 24、26 等于写出 25
- 几百个条件连成一长串：条件改成不递归地算（以前上千层会超过递归深度，退回按词认，短的数就漏了）；细看夹没夹住按步数设了
上限（PIN_WORK），看不过来的两边都隔开就按夹住算
- _literals 的「别处出现过同一个数」从所有非保留字面量里抽数字片段，日期里的 31、天数修饰里的 30、标签里的 30、没设遮罩的
列上的 amount = 30 都算，阈值就改记成等值遮掉，可那些地方一个字没换，回答正文又照样写着它。改成和真去换的同一套判断
（_swap_literal，_scrub_sql 也照它换）：只有同一个数在这条 SQL 别处确实被换掉了（等值、别处的长数整个换掉，字符串里按值
换掉的遮罩数）才不留；换掉的是文字标签不牵连阈值。查询之间的正文免遮（_shown_literals）同理，按查询各自认遮罩列的比较
- 模块说明补上已知局限：按值认的门槛两头都有误差（短的数在正文里遮不住、5 位以上的数会误遮巧合的数）、遮罩数值列的
SUM/AVG/MIN/MAX 和按遮罩列分档的 CASE 标签算派生值（产品取舍，保持现状）、「夹住」只在同一个条件里认（拆进子查询或 CTE 的
认不出）、遮罩值收集有上限
- 补单元测试和端到端测试：重叠的分档边界（两个 WHEN 分支、两个选出列、UNION 两支、年龄段）、日期、天数、标签、未遮罩列的
等值照原样封存、正文不遮；同一条件里夹住一个值的几种写法（旁边有别的条件、CASE WHEN、HAVING 里同一个汇总值、整数开区间、
XOR）和别处确实换掉的同一个数照旧遮。每处改动都做过去掉实现、测试变红的验证
2026-10-06 12:24:54 +08:00
a17c822d57
审批质询复核修正（第 3 轮，后端）：SQL 里的字面量按语法树认用在哪，数字照原样留着的只有没夹住某一个值的范围边界和 LIMIT 行数；SQL 里留着的阈值只在回答正文里不遮，格子照旧按值遮；质询工件的免遮接线补上端到端核对
...
复核提出的问题和改法：
- 第 2 轮为了不误遮阈值，把范围边界、字符串的范围边界和选出列、函数参数里的数从正文和格子的按值遮里一并免掉；而按词认用法时，
简单 CASE 的 WHEN、IN (VALUES …)、行值、= ANY(ARRAY[…])、IS NOT DISTINCT FROM、套了括号的值这几种在找某一个值的写法被当成「别处」，
两头相同的范围（BETWEEN v AND v、>= v AND <= v）被当成阈值，遮罩值就留在封存的 SQL、回答正文和质询工件里，最后一道关也放行：
- 字面量改按语法树认用在哪：越过括号、负号、CAST、行值、VALUES、ARRAY、ANY / ALL 这些外壳再看上一层，上面几种都认作在找某一个值，
被比较的是哪一列也认得出（短的数照旧只在和遮罩列比较时换）
- 同一列上同一个值两边都被隔开的范围按在找这个值换：BETWEEN v AND v、>= v AND <= v、> v OR < v、整数的 >= v AND < v + 1，一头是几个数
算出来的（13900000002 - 1）也算；只从一边隔开的（>= v，或按 v 分成两段）照旧是阈值
- 数字照原样留着的只剩没夹住某一个值的范围边界和 LIMIT / OFFSET 的行数，而且同一个数在这条 SQL 别的字面量里没被换掉；选出列、函数参数、
算式里够长的遮罩值照第 1 轮换；字符串的范围边界照第 1 轮按值换。名字、注释里写着阈值不牵连阈值本身（AS 超过30000的笔数）
- SQL 里照原样留着的数只在回答正文里不遮，格子、列名、SQL 里照旧按值遮；同一个数在别的查询里被换掉了，正文里也遮。组装后的最后一道关
只放过正文里的这些数，渲染进单元格引用里的照旧拦下
- SQL 解析不了时认不准哪个数是阈值，一律不免，只按词认简单的等值比较
- 质询工件里两处免遮接线没有测试守住：报告指标、运行输入的值那一处，单笔目标那条端到端测试补上取质询工件，核对别的列里正好是这个数的
格子在回答、工件里都照常显示；SQL 里阈值那一处随上面的改法拿掉了（格子不再免阈值），补上「格子正好等于阈值」的端到端测试，核对回答和
工件里这一格一样遮住、两边对得上；阈值那条端到端测试补上取等值查询的质询工件，核对 SQL 和事件里一字不差
- 上面每种写法都补了单元测试和端到端测试（手机号存成整数、文字两种），另补开头带换行的 SQL 位置对得上、名字里的阈值不牵连阈值的测试。
查询清单的 SQL 现在要解析，改在线程里换（同 _plan）。每处改动都在副本上做过去掉实现、测试变红的验证
2026-10-06 11:02:10 +08:00
a641bf5fb9
审批质询复核修正（第 2 轮，后端）：和 * 写在一起、子查询里没起别名的遮罩列表达式认得出；SQL 只换在找某一个值的字面量，范围比较的边界、LIMIT 照原样；报告口径卡里的指标、SQL 里留着的阈值不当遮罩值；带前缀的字符串、名字、列名里的遮罩值也换
...
复核提出的问题和改法：
- 遮罩列的表达式和 SELECT * 写在同一支里、又没起别名（SELECT *, SUBSTR(buyer_phone, 4)），原值的一截出现在回答正文和质询工件里：
按位置认，* 前面的从头数、最后一个 * 后面的从结果末尾倒着数（结果的列一个不少、按顺序，重名也照留）。同一个根子的几种也一起补上：
子查询、WITH 里没起别名的表达式（外层的 * 原样带出来，列名各数据库起法不同）、两个 * 之间的项认不出落在哪一列，整份快照遮掉；
派生来源里 UNION 的另一支、带列名表的 UNION 按位置对上第一支或列名表的名字；LATERAL、多套几层括号照样认
- 和遮罩列做范围比较时的阈值、5 位以上的数不看上下文就被换成「已遮罩」，封存的 SQL 不是实际执行的那条：SQL 只换在找某一个值的
字面量（等值、不等、IN、LIKE、SQLite 的 IS）——和遮罩列比较的是遮罩值就换，和别的列比较的够长的遮罩值也换；范围比较的边界、
BETWEEN、LIMIT / OFFSET、选出列和算式里的数照原样（字符串的范围边界同样）
- 回答正文里复述 SQL 里照原样留着的阈值（「金额不低于 30000 元」）被遮：这些值本来就随 SQL 摆在读者眼前，正文、快照按值遮时免掉
（只免按值认的，SQL 里和遮罩列做等值比较的照旧换）
- 报告口径卡里的指标恰好是遮罩值时（单笔目标 20000），引用它的回答整份交不出去、换个问法也绕不过：报告列出的指标和运行输入的值
像问题里的数一样不当遮罩值，回答时和取质询工件时一样
- 带前缀的字符串（N''、E''、U&''、$$…$$）、带引号和不带引号的名字（AS "13900000001 的单"、张伟的单数）里的遮罩值原样封存：所有
字符串类的词只换引号里的内容，名字按值换；快照的列名、回答文档目录里的列名同样换，引用原列名的标记里的列名跟着换，正好对上
- 回答原文的标记里写着遮罩值时，单元格引用「Q1.r0.」后面的长号码会被当成小数的一截认不出来：标记按段换，单元格引用只换列名那一截；
遮罩值在组装之前就换掉，不再组装两遍，组装出来还认得出遮罩值的照旧不交出去
- 新加的接线没有测试守住：补上问题里写了遮罩列的短数时 SQL 原样保留、质询工件按报告快照里的遮罩值遮别的列，以及上面每一种情形
的单元测试和端到端测试。每处改动都做过去掉实现、测试变红的验证
2026-10-06 09:52:47 +08:00
778fb8b83e
审批质询复核修正（第 1 轮，后端）：遮罩改按 SQL 认出改了名字的遮罩列、再按值遮，按值认有门槛、SQL 只换字面量；没写进记录的回答照样点得开；数据源核对是不是运行用过的那一个；报错和回答末尾的说明给提问人看得懂
...
复核提出的问题和改法：
- 遮罩列起了别名（本仓库查询的惯例是中文别名）、套了函数、经子查询或 CTE 转一道，原值会出现在回答正文、事件和质询工件里，第二遍组装也拦不住：按 SQL 认出改了名字的遮罩列（COUNT 只数个数、窗口的分区键只决定次序，不算；解析不了又写着遮罩列的，整份快照遮掉），快照另按值遮（别的列里写着遮罩值的格子）；组装两遍之后正文里还认得出遮罩值的回答不交出去；提示词写明遮罩列不要选出原值、不要起别名
- 按值遮罩范围过宽：年龄这类短的遮罩值会把阈值、天数、日期、LIMIT 换成「已遮罩」，封存的查询清单不再是实际执行的 SQL。纯数字至少 5 位才按值认，日期、小数、时间、千分位里的一截不算；SQL 只换字面量和注释里的值，短的数只在直接和遮罩列（含别名）比较时才换；问题、选中原文里提问人自己写的值不换
- 提问人写的阈值在回答里被标「无出处」：问题、选中原文里的数作为 allow_numbers 交给两遍组装
- 同一条 SQL 事件里遮了、质询工件接口里没遮：工件接口直接用事件里记下的那条，遮罩值照回答时收（含报告自己的查询快照）
- 没写进运行记录的回答交回了工件 id，质询工件接口却一律 404：这样的回答在进程里留一小时（最多 200 条），这段时间里照样认它引用的工件
- 回答里引用的报告指标（m:）点不开：质询工件接口认回答文档目录里的口径卡
- 遮罩值上万个时每次回答、每次取工件都在事件循环里编一个上万分支的正则，卡住进程一秒上下：先按词、按开头几个字和长短筛出正文里真有的几个值再编；收值、解析 SQL、逐格比对放进线程
- 按名字认源：同名重建的源会被当成运行用过的去查，没固定版本的上传表格还会被悄悄补固定进已封存的运行。按运行里查询快照记的源 id、运行固定的版本核对，对不上的、没固定过的不交给 agent
- 封存之后的追问查的是现在的数据，读者分不清是口径差异还是数据更新：任务里给报告生成的时间，回答末尾注明
- 模型轮数用完被说成查询次数到顶，引用一个都解析不了照样算回答完成：轮数用完 limit 记 null；轮数用完、查询执行失败、引用解析不了都在回答末尾注明
- 报错透出核查 agent 的内部说法（「交结果」「按结构」、裸写的字段名）：按情形换成发生了什么加下一步，原话只进日志
- 运行在执行时的说法对正式运行不成立、对过时的审批卡也没说清：带着审批卡来的叫人刷新，没带的按运行类别说什么时候能问
- 回答文档的工件引用 meta 记下问题的前 40 字，运行的工件列表据此认得出是哪个问题的回答
- 测试补上证明接线的用例：两道审批的竞态（approval_id 守卫）、上传表格按运行固定的版本查、设置里的上限和 data_versions 交到 agent 手里、开放途中运行被继续了、报告文档不属于这次运行；新增遮罩的单元测试。每条都做过去掉实现、测试变红的验证
2026-10-06 08:52:16 +08:00
2db83a69e8
审批质询：只有空串算没指明句子、审批卡，0、false 这类照样报格式不对；结果相同的两次查询共用一份快照，引用列表里只记一次
2026-10-05 18:58:41 +08:00
e6dfe18c83
审批质询自查修正：封存后的追问不一定来自审批人，提示词改成中性的「提问人」；告诉 agent 哪几列设了遮罩；组装回答出错照样记一条
...
- 任务里列出可查询的数据源现在设了遮罩的列，让 agent 不写出原值（系统的替换仍兜底）
- 回答原文没能组装成文档时不交出原文（引用没换成值、遮罩没做），记成失败，查过的和用量照记
- 第二次读状态时运行已被继续：不按旧封存追加，回 409
- 不指明句子、不在审批卡上问时，unit / approval_id 写空串等同于 null
- 只列有值的报告指标和运行输入：没有值的引用了也解析不了
2026-10-05 18:54:54 +08:00
7df224106d
审批质询（后端）：运行停在审批时，审批人针对报告里的一句话提问，只读 agent 现查现答，问答写进运行、随运行封存
...
- engine/inquiry.py：开放条件（停在审批且问的是待处理的那张卡；或已封存、核对一致的探索运行，追加在封存之后；
正式运行封存后、设置关闭、还在执行一律 409）；同一运行同时只答一条（进程内登记）；回答交给 run_verify_agent
（不传 emit，数据版本取运行记录，上限和模型按核查设置），任务里给被问的那句、照 judge.prepare 取的证据摘录
（遮罩照旧、原报告编号标明）、选中的原文和问题，数据源取这次运行用过的查询工具；回答由 compose_doc 组装成文档
落工件，数字可以引用自己的查询格子或报告已有的指标、运行输入，裸数字被标出；引用到遮罩列的格子渲染成「已遮罩」，
回答正文和查询清单里出现的遮罩列的值换成「已遮罩」；写入走 append_events，运行在回答期间变了就不写、照实说明，
触顶和失败照样记一条
- api/inquiry.py：POST 提问、GET 列表（按报告、句子筛选）、GET 质询工件（只认质询引用过的，遮罩照证据面板）；
输入不合法回 {detail, field}
- api/runs.py：质询正在回答时，审批回复（批准 / 驳回）和继续运行回 409 inquiry_busy，拦在记签批人之前
2026-10-05 18:51:51 +08:00
ThearchyHelios