ThearchyHelios 58a6759fe2 合入期 5 前置修复 K3：核查 agent 的查询结果在工具边界先遮——取自遮罩列的结果列（别名、函数、子查询、WITH、*、UNION、表值函数、整行引用都认）在交给模型的内容和落库的快照里都换成「已遮罩」，模型看不到遮罩值；按值遮降为第二道防线；换了写法的长号码（空格、连字符、点、括号、全角、国家码）在回答、理由、工件和最后一道关里都认得出；认遮罩列的共用部分挪到 engine/masking.py

2026-10-06 22:19:42 +08:00

..

nodes

合入期 5 前置修复 K3：核查 agent 的查询结果在工具边界先遮——取自遮罩列的结果列（别名、函数、子查询、WITH、*、UNION、表值函数、整行引用都认）在交给模型的内容和落库的快照里都换成「已遮罩」，模型看不到遮罩值；按值遮降为第二道防线；换了写法的长号码（空格、连字符、点、括号、全角、国家码）在回答、理由、工件和最后一道关里都认得出；认遮罩列的共用部分挪到 engine/masking.py

2026-10-06 22:19:42 +08:00

__init__.py

…

approval.py

…

autofix.py

模型接入报错收尾（第 1 轮复核，后端）：交给设置的核查、裁判落到演示模型照实说；给不出修复时说卡在哪里；接入名恰好是模型名那句按这一处检查器里有哪几栏写；修复规划只重算被改的节点；助手栏那一格另给一份说法；几处措辞对齐

2026-10-06 19:43:44 +08:00

compare.py

运行对比加固（收尾）：区域等维度列设了遮罩时照样拿它核对两次引用的是不是同一批行，说明只写行号、不写值，挤出引用行段的和真的少了分得清，没挪的照常是数据变化；补单格反方向、归因维度按两边各自引用的行认、写入者改了配置时不严格拆分、并行支路查询四处守护用例

2026-10-05 16:41:59 +08:00

compiler.py

…

context.py

…

deadline.py

核查因运行时长上限将至没核成的，时间线另起一条并带上原因（cause: run_deadline）；收紧过的核查 agent 触顶时也改说时长上限将至；给下游留的余量看下游还有几个要调模型的节点，时长上限调短时余量跟着缩小

2026-10-06 14:25:38 +08:00

direct_select.py

…

dual_check_facts.py

双盲复算写业务日期：真写按写入时的版本重读上传表格导入时认作日期的列，几个列表块写同一张表时每一块都记为日期才算

2026-10-06 18:03:12 +08:00

evidence.py

compose_doc 的说明对上 K5：doc["source"] 是调用方交来的原文（报告节点交来前去掉了整篇外层围栏，见 report._unfenced），不再说是模型的原文；只改说明，文档字段和内容哈希不变

2026-10-06 17:01:45 +08:00

expressions.py

…

governance.py

模型接入报错的说法与修复候选收尾（后端）：修复规划只否决这次改动造成的失败、问题只认自己那一处的修复、没有修复时提示不指到发布前检查、落到演示类接入照实说；各处说法对齐

2026-10-06 17:29:18 +08:00

guards.py

…

inquiry.py

K3 复核修正（第 3 轮）：写了库名的表按「库名.表名」查表结构；UNION 第一支按表结构数出的列名要和后面每一支一样宽才用；整行引用、函数参数里的 *、表的列名表、TABLE x、PIVOT 这类认得出

2026-10-06 21:50:48 +08:00

issuance.py

…

judge.py

模型接入报错收尾（第 1 轮复核，后端）：交给设置的核查、裁判落到演示模型照实说；给不出修复时说卡在哪里；接入名恰好是模型名那句按这一处检查器里有哪几栏写；修复规划只重算被改的节点；助手栏那一格另给一份说法；几处措辞对齐

2026-10-06 19:43:44 +08:00

labels.py

双盲复算、反方审稿的字段与取值叫法挪到 labels.py：field_label、option_label 按节点类型说「盲算模型」「结论被推翻时」「只标注」这些检查器上的叫法，发布门禁、升级预览不再说成通用的「模型」「启用」；schema.py 照旧再导出，校验和执行器的报错取同一份

2026-10-05 18:45:44 +08:00

launch.py

双盲复算复核整改：指标自己的筛选范围不再写成有效记录条件，盲算不再看到原流程的列名，差异说明收窄到这一格

2026-10-05 15:54:03 +08:00

layout.py

…

masking.py

K3 复核修正（第 3 轮）：写了库名的表按「库名.表名」查表结构；UNION 第一支按表结构数出的列名要和后面每一支一样宽才用；整行引用、函数参数里的 *、表的列名表、TABLE x、PIVOT 这类认得出

2026-10-06 21:50:48 +08:00

merge_query.py

…

provider_refs.py

模型接入报错收尾（第 1 轮复核，后端）：交给设置的核查、裁判落到演示模型照实说；给不出修复时说卡在哪里；接入名恰好是模型名那句按这一处检查器里有哪几栏写；修复规划只重算被改的节点；助手栏那一格另给一份说法；几处措辞对齐

2026-10-06 19:43:44 +08:00

recompute.py

证据接口复核整改（后端）：反方审稿带整份报告的真实计数、跑停运行的审稿照样认得，双盲复算的跳过原因按指标说，遮罩核对不了的宁可多遮

2026-10-06 09:20:09 +08:00

replay.py

…

review.py

证据裁判截断的回复整批不采信，截断另记 judge_truncated，时间线的下一步指到换模型

2026-10-06 14:30:15 +08:00

run_append.py

追加事件收紧几处，封存后追加的质询不计进运行用量。复核提出：停在审批时追加只看运行还停着，关于第一张审批卡的质询问完时运行可能已经批过它、停到了第二张上，问答照样写进去；没有终态事件的老封存运行追加之后 verify 由一致变成不一致；返回给调用方的事件 id 和库里的不一样；测试证明不了先落库再广播；封存后追加的质询平时不计用量，继续运行之后又被计进去。

2026-10-05 01:18:03 +08:00

runner.py

runner 把这一段执行的截止时刻交给节点：进入 asyncio.timeout(max_run_seconds) 时放进 ContextVar（engine/deadline.py），退出时清掉，节点、节点里的 @task、子工作流都看得到；没有上限时为 None，节点照旧

2026-10-06 12:59:49 +08:00

schema.py

模型接入报错的说法与修复候选收尾（后端）：修复规划只否决这次改动造成的失败、问题只认自己那一处的修复、没有修复时提示不指到发布前检查、落到演示类接入照实说；各处说法对齐

2026-10-06 17:29:18 +08:00

spend.py

核查花费账：engine/spend.py 照结论句裁判的每日计数做一本核查用的每日账（设置表 verify_spend 一行，按本地日期滚动）。调用前按估算预留，加上这笔会超过每日上限就不记、返回 None，上限为 None 表示不限；调用后按实际用量找补，跨了天不找补；价格目录里没有的模型只计次数。和裁判分开记：核查一次要查好几轮库、花得多，记在同一本账上会把当天的裁判挤到判不了、让报告出具无故降档。读改写按事件循环各持一把锁，并发预留不会一起越过上限

2026-10-05 00:06:03 +08:00

sql_problems.py

…

state.py

…

toolcalls.py

…

upgrade.py

…

variables.py

…

verify_agent.py

K3 复核修正（第 2 轮）：* 把遮罩列带进别的列名时按展开落到的位置遮；函数参数里的 JSON 箭头认作遮罩列；agent 查到的遮罩值和报告里的分开记，上限收满也不丢

2026-10-06 20:29:58 +08:00