ThearchyHelios 2c2672cc04 时间线认得核查模型的输出被截断（verify_truncated）：标题说「核查模型的输出达到上限（N token）被截断」，副标题说这次核查未能完成或已按截断前查到的结果收尾，下一步指到换不带推理的模型，入口落到节点的模型 ...

decode.ts 按结构化字段（max_tokens、delivered）解读，不从原话里认，缺字段时只给不带数的标题；文案放在 terms.ts 新的 VERIFY_TRUNCATED_TEXT。check-decode 加一节：先核对 verify_agent.py 还是这么发的，再核对三种取值（没交出结果、退回 4096 后交了结果、缺字段）的标题、副标题、下一步、入口和原话。

跑完之后的复核层（engine/review.py 的 WARN_CODES）登记 verify_truncated：同 verify_limit 记成它自己的 kind、degraded，不落成笼统的 warn，也不触发「重跑一次大概率能好」。

2026-10-06 13:06:18 +08:00

..

nodes

合入期 4 期 3 收尾：核查缺口分「核查未通过」「核查未完成」两组，时间线认得核查类日志代码；双盲复算写目录的预告和真写逐字一致（被目录挡下的那一边也说清原因，几个指标落到同一项时按组合预告）；反方审稿说清「根本没反查」和「到底降不降档」；字段叫法挪到 labels.py；记录页的核查工件有名字和说明

2026-10-06 11:31:11 +08:00

__init__.py

AgentLab：可视化 Agent 编排实验台

2026-09-13 17:27:00 +08:00

approval.py

工具审批三档、智能体护栏取代固定 12 步、检查脚本分道并行

2026-09-28 11:47:45 +08:00

autofix.py

数据目录阶段 2B：发布门禁接上 SQL 检查——受管级别被 error 挡住、warning 进提示，发布前检查、自动修复和发布同一个口径

2026-10-03 10:31:19 +08:00

compare.py

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

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

compiler.py

复核套件骨架（后端）：先把后续几个工作包要用的位置占好，各包只改自己的文件。节点类型加双盲复算 dual_check、反方审稿 challenge，执行器是占位（记一条 info 日志后跳过，产出 skipped 和原因），校验按普通节点走，叫法进 labels，暂不写进助手的节点说明。出具契约留一个通用口子：成果节点上游任何节点产出里的 issuance_gaps（字符串列表）收进缺口，前面加上「节点类型「节点名」：」，出具随之降档、不会升档；只认这个成果的上游，写坏的条目跳过。路由先登记 schedules、compare、bundle、inquiry、whatif 五个空前缀，挂在 /api/runs 下的四个排在 runs.router 之前，以后加固定路径不会被 /{run_id} 吃掉。定时任务的调度先放空的 start / stop，AGENTLAB_SCHEDULER 默认开、0 / false / off 关，写进设置；启动时开着才 start，测试环境默认关

2026-10-04 23:40:20 +08:00

context.py

模型不在价格目录里时运行金额写「金额无法估算」，不写 $0：真实运行里 token 记到了上百万，金额却是 $0，看着像没花钱。llm.end 发出时，用了 token、模型却不在价格目录里的标 unpriced（目录里标 0 价的本地模型不算）；运行用量按 llm.end 数出 unpriced_calls，成功的运行也补上（状态里的用量分不出 0 是免费还是没价）。运行详情、画布运行面板、航迹的金额：一分都没估出来写「金额无法估算」，估出一部分写「≥ $x」，悬停说几次调用不在价格目录中。check-trace 补断言；流式用量测试和注释里的真实调用次数换成概括说法

2026-10-04 12:27:38 +08:00

direct_select.py

Excel 导入改造期 4：证据下钻——报告里引用上传表格的数，点开能看到它来自原表格的哪一格；裁判核对时看得到来源、口径、接受理由和区域外文字

2026-10-02 14:38:10 +08:00

dual_check_facts.py

期 4 复核修正（第 1 轮，后端）：预告组合先算个数再列、上限按每项算，核查 agent 的两个日志代码归类，未能反查的句数守住不多于无法判断

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

evidence.py

证据目录的省略警告照实说省略了什么：放不下不一定省略了查询。真实运行里查询全部列出、只是有的只列前几行，警告却写「0 次只列编号和摘要（）。写作模型看不到这些查询的明细」。现在分三种写：有查询只列编号和摘要的照旧；查询都列出、有的只列前几行的写「N 次查询都列出了数据，其中 M 次只列前 3 行」并按来源列次数；只省略了表和字段说明的照实说。事件多带 compact、compact_rows，各来源带 compact；时间线按同样三种写标题。另外把测试夹具、注释和 check-decode 里沿用的那次运行的真实查询次数换成虚构的次数或概括说法

2026-10-04 12:28:07 +08:00

expressions.py

截断跟踪：改正不继承 list 的理由说明

2026-10-03 09:36:40 +08:00

governance.py

数据目录 F2b / B3 跟进：合入 F2a 之后一对多关联后重复计算也可能只是提醒级（只凭外键推出的一对多），发布前检查不能再按规则编号认级别——服务端最小改动：门禁里 SQL 检查的问题带上检查本来的级别 sql_level（别的问题不带、序列化时不出现），界面按它写「错误 / 提醒」和拦不拦；老服务端不给时按受管档的 level 认；补后端测试和检查脚本

2026-10-04 02:52:43 +08:00

guards.py

界面文案整改：口语改书面、术语统一、不再露出实现细节；修掉几处说错的提示；新增文案检查防回潮

2026-09-30 08:05:15 +08:00

inquiry.py

审批质询复核修正（第 3 轮，后端）：SQL 里的字面量按语法树认用在哪，数字照原样留着的只有没夹住某一个值的范围边界和 LIMIT 行数；SQL 里留着的阈值只在回答正文里不遮，格子照旧按值遮；质询工件的免遮接线补上端到端核对

2026-10-06 11:02:10 +08:00

issuance.py

降档时报告页顶部写明出具档位和原因（B5）：出具声明和 issuance 事件另带结构化的 sql_checks（哪次查询、问题、受影响的引用、对应的缺口），证据页签在报告上方放出具横幅，SQL 检查导致的降档单列一块写在显眼处、不在其余缺口里重复；不是完整出具时「N 个数字都有出处」不再画成绿色

2026-10-04 02:33:15 +08:00

judge.py

证据裁判按 16384 的额度判、服务方嫌大时退回 4096，判定写到一半到了上限的记未裁判（truncated），照实说是输出额度

2026-10-06 13:02:24 +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

汇合节点只跑一次：长短支路不再把它触发两遍，循环的 done 出口也不再被提前放行

2026-09-25 14:33:56 +08:00

merge_query.py

合并查询的警告带上结构化字段：键类型不一致带 keys、detail，行数放大带 rows、input、input_rows、duplicates，结果截断带 rows、max_rows，随运行日志一起发出，界面读字段，不再从中文原话里解析

2026-10-04 02:17:32 +08:00

recompute.py

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

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

replay.py

第三波前两批：六个「看着成功其实没干活」的平台漏洞堵上，记录页能回放，管理页与画布收尾

2026-09-27 10:16:32 +08:00

review.py

时间线认得核查模型的输出被截断（verify_truncated）：标题说「核查模型的输出达到上限（N token）被截断」，副标题说这次核查未能完成或已按截断前查到的结果收尾，下一步指到换不带推理的模型，入口落到节点的模型

2026-10-06 13:06:18 +08:00

run_append.py

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

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

runner.py

发起时就定下的事件和运行记录同一个事务写进事件流：受管级别那条日志、目录变化、口径升版处置以前在 run_manager.start 返回之后另外写，这时运行已经建好、执行任务已经起了。其中任何一次写失败（库被锁超过等待时长之类），launch_run 抛出普通异常，运行却在执行；定时任务按「LaunchRefused 以外的异常记未能发起」会把一次正在执行的正式运行记成未能发起，封存范围里也少了受管级别那条日志（governed_formal 找不到它就退回看工作流现在的 status，中途改过画布的会按已发布级别出具）。另外这几条和执行抢先后，运行结束得快时可能落到封存之后。

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

schema.py

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

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

spend.py

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

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

sql_problems.py

运行时间线看得到单条查询的 SQL 检查：调用工具节点、Agent 和协作团队里的查库调用，tool.end 事件单独带上这次查询的检查结果（只留给人看的字段）；preview 只有结果的前一截，检查结果以前通常被截掉

2026-10-04 02:17:32 +08:00

state.py

可点击证据第一期：报告里的每个数字都点得开出处

2026-09-28 11:47:23 +08:00

toolcalls.py

界面文案整改：口语改书面、术语统一、不再露出实现细节；修掉几处说错的提示；新增文案检查防回潮

2026-09-30 08:05:15 +08:00

upgrade.py

合并查询节点（一）：新增 merge 节点和执行器——几次查询的完整快照落进内存 SQLite 按键合并，结果存成同形的查询快照，截断的输入拒绝、键类型不一致和行数放大给警告，并记下逐格来历

2026-10-03 09:27:48 +08:00

variables.py

合并查询节点（一）：新增 merge 节点和执行器——几次查询的完整快照落进内存 SQLite 按键合并，结果存成同形的查询快照，截断的输入拒绝、键类型不一致和行数放大给警告，并记下逐格来历

2026-10-03 09:27:48 +08:00

verify_agent.py

核查模型的输出额度改为 16384、服务方嫌大时退回 4096，截断照实说：工具循环、收尾的每次调用都看有没有到了上限被截断

2026-10-06 12:58:37 +08:00