392 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
ThearchyHelios	45fe01effe	定时任务自动对比复核整改（后端）：只比成功的运行、按发起先后挑上一次成功的基准、和两边的封存绑定，对比挪到认领之前在锁外做并限时限并发；失败通知的处理行不再重复原因 ... - 只比成功结束的运行，基准也只取成功的：失败、取消的运行指标不全，和上一次比只会得出「移除 N 个」，拿失败的那次当 基准每个指标都成了「新增」。基准改成自己查同一定时任务、同一工作流、比这次先发起的运行里成功并封存的最近一次， 不再用对比接口的 default_base（按结束时间挑：老的失败运行事后被接着跑完，会拿后一次触发当它的「上一次」）。 中间隔着失败、取消的运行时，通知写「与上一次成功的运行（#短编号，日期）相比」，Fire.compare 多一个 previous - 和封存绑定：运行的封存要盖住最后一条结束事件才算封存完（sealed_now）。runner 先写终态、再另起会话封存，失败后 接着跑完的运行在两步之间还带着失败时的清单哈希，以前这一拍会直接认领、按旧封存比、通知里写旧的清单哈希；现在 等新的封存，等不来就照常推送但不比、不写哈希。停在审批上的通知也不再写失败时留下的哈希。对比工件连同两边的清单 哈希一起存，触发历史发现任何一边不在终态或清单哈希变了就给 null；对比途中封存变了不记（条件写） - 时机和时限：锁里只挑出状态有变化的触发，认领挪到对比之后、锁外按条件 UPDATE 做。对比最多等 20 秒（含排队）， 同一时刻最多 2 个；超时只记警告，通知不带对比照常推送。停机时扫描在对比途中被取消，这次触发还没认领，下次照常 比、照常推（以前先认领、后比，这条通知会永远丢掉）。同一份封存已经比过的直接用记下的结果 - 失败通知：从没开始执行的，原因刚写过，处理行不再让人「查看原因」，任务在排期上写「下一次触发会照常发起」，停用 的写怎么重新发起；开始执行过的改成「请在 AgentLab 的「记录」中查看失败原因」，和挂起那句指向同一个导航入口 - 新增 test_scheduler_compare_guards.py（封存绑定、时限、取消、并发、复用），test_scheduler_compare.py 补真实缺 指标的失败运行、上一次失败、补跑老运行几种用例；去掉实现逐项验证过会变红	2026-10-06 08:48:56 +08:00
ThearchyHelios	f8ac8dc1d6	定时任务自动对比收尾：基准那一次不在终态或被删时不给对比、对比工件读不出来时触发历史照常打开；检查脚本按实际底色量对比度 ... - 触发历史的 compare：以前只看这一次的运行在不在终态。基准那一次被强制删除、失败后被继续执行时，对比页比不了， 「对比上一次」链过去只会报错——基准一侧同样要在终态，否则给 null - 对比工件读不出来（权限、磁盘出错）时记一条警告、给 null：以前 OSError 直接抛出，整页触发历史回 500。被改过 （内容与哈希不符）的以前就给 null，这次补上用例 - check-schedules：页头的定时任务链接、触发历史的「对比上一次」改成量 WCAG 对比度（≥ 4.5），底色顺着祖先叠到 不透明为止。以前比的是「字色不等于页头的底色」，页头本身透明，那样比永远成立；深色也补上同样的检查。另加一项 署名的立即运行配长名字：署名照写、链接截断、页头不横向溢出	2026-10-06 07:43:01 +08:00
ThearchyHelios	863b0b2894	定时任务前端：触发历史加「对比上一次」，运行详情页头的「由定时任务「X」发起」改成键盘可达的链接 ... - 触发历史：服务端给了 compare 的那次触发，在运行链接前加「对比上一次」，链到对比页（本次是这次触发的运行、 基准是服务端自动对比时取的同一任务上一次），带上来历让对比页写「默认基准：同一定时任务的上一次运行」。悬停写 各类指标的个数，和 Webhook 通知那一行同一个写法（三类总写、其余有才写、两边都没有指标时不写一串 0 个），读屏 当说明念；只有个数。compare 为 null、老服务端不给时不显示 - 运行详情页头：定时任务发起的运行，「谁发起的」那一段换成到 /schedules/:id 的真链接（Tab 到得了、回车能开， 有焦点环）。到点发起的（署名是「定时任务：X」）整句换成「由定时任务「X」发起」，不再写两遍；有人署名点了 立即运行的，署名照写、后面接「来自定时任务「X」」。名字取定时任务现在的名字，取不到用署名里记的；长名字截断， 全名在悬停里。记录页「定时」标记的说明同步改成指向这里 - types.ts 定时任务那一段加 ScheduleFireCompare 和 ScheduleFire.compare；文案进 SCHEDULE_TEXT - check-schedules：触发历史的对比链接（地址、悬停的计数、只在有 compare 的行出现、Tab 到得了、回车打开对比页）、 运行详情页头的链接（现在的名字、真链接、不重复署名、Tab 到得了且有焦点环、回车去定时任务、署名的立即运行、 手动运行没有、长名字截断不撑宽、浅色可读），390px 深浅色下对比链接在屏幕里、看得清	2026-10-05 18:58:25 +08:00
ThearchyHelios	f0f1b99ead	定时运行结束后自动和同一定时任务的上一次对比：结果存成工件记在触发记录上，触发历史和通知只给计数摘要与对比页链接 ... - 新增 app/scheduler/auto_compare.py：通知扫描认领到运行进入终态（结束、失败、取消）的那一次之后、推送之前， 调运行对比接口的现成函数（default_base、compare_runs，不改它们）比一次。基准只取 default_base 的「同一定时 任务」那一档，退回「同一工作流」的不比——那不是这个任务的上一次。没封存的不比；比不了（基准封存核对不一致等） 记警告、意外异常记堆栈，都不影响通知。整份结果存成 run_compare 工件，不挂在运行名下（不进运行的工件列表）， 工件 id 写进 ScheduleFire.compare_artifact；再次进入终态（失败后继续执行）时按新的封存重新比、覆盖旧结果 - 接口：Fire 多一个 compare: {base_run_id, summary}（summary 同对比接口的计数）或 null。运行现在不在终态 （被继续执行）、工件读不出来时为 null；工件摘要按 id 缓存（内容寻址，不会过期），读盘在线程里 - 通知：结束、失败的通知多一行「与上一次相比：只数据变 3 个、口径与数据都变 1 个、SQL 结构变 0 个」（三类总写， 其余各类有才写，两边都没有指标时不写一串 0 个），配了对外访问地址时附对比页链接（/runs/compare?target=…&base=…）， 四种格式都带；通用格式多一个 compare 字段。只给个数，不放任何具体数字 - 没配 Webhook 的任务也比：触发历史里要用	2026-10-05 18:45:59 +08:00
ThearchyHelios	d62f921ed4	定时任务遗留问题：失败通知不再许诺能继续运行、30 天前的触发停在审批上照样推送、调度循环测试不再依赖整分边界 ... - 失败通知的「处理」行改成中性的「请在 AgentLab 的运行记录中查看原因」：服务重启时还在排队、从没开始执行的运行 没有断点，「修正后可继续运行」是错的；开始执行过的也可能续不了（执行第一个节点前就失败、系统升级后断点不兼容）， 能不能继续以记录页为准。没有开始时间的失败另写一行原因（没有可继续的进度），通用格式的 reason 字段同写；任务 还在排期上时补「下一次触发会照常发起」，和挂起（之后的触发都跳过）说清区别 - 通知扫描的 30 天窗口加两种例外：停在审批、有待审批的运行不受限制（创建 30 天以后才停到审批上的以前收不到 「等待审批」）；运行记录 30 天内有过变化的照扫（等了一个多月的审批批完、跑完，以前收不到「运行结束」）。早就 结束、多日没有变化的旧触发仍不扫 - test_loop_ticks_until_stopped 改成只看「发起了」和停下前后的条数差：建任务和第一拍之间跨过整分时会先记一条 错过的跳过，以前按总条数断言偶发失败。加一组把下一次放在上一个整分的用例，必然走到跨整分这一支	2026-10-05 18:39:10 +08:00
ThearchyHelios	14dcbe19bb	合入期 3 反方审稿（前端）：审批卡与证据里的反方审稿概况、逐句判断与理由、检查器 ... # Conflicts: # frontend/src/canvas/nodeDefs.ts # frontend/src/types.ts	2026-10-05 18:10:06 +08:00
ThearchyHelios	a122b98dd3	合入期 3 双盲复算与核查设置（前端）：双盲审批卡（并排对照、差异说明、三选一与写目录预告）、检查器与节点卡片钩子、设置页「核查」一节、时间线解读双盲和反方审稿的日志	2026-10-05 18:08:39 +08:00
ThearchyHelios	e9cf74748f	合入期 3 反方审稿（后端）：报告里的关键结论各派只读 agent 主动找反例，给出经受住、被削弱、被推翻、无法判断和有出处的理由；被推翻的计入出具缺口；审批卡附反方审稿概况 ... # Conflicts: # backend/tests/test_issuance_upstream_gaps.py	2026-10-05 18:08:39 +08:00
ThearchyHelios	bee24cf79a	合入期 3 双盲复算（后端）：口径卡上来自查询的输入另起看不到原 SQL 的只读 agent 独立复算，代回原式按误差比对；不一致时挂起交审核人三选一，选择只在差一个方面、且是排除无效记录这类数据事实时写进数据目录；发起时快照核查设置	2026-10-05 18:08:03 +08:00
ThearchyHelios	bcad199e0f	双盲复算前端复核修正（第 3 轮）：同一次裁决里几个指标落到数据目录的同一项上时，卡上按其余指标当前的选择说——说法不同的改说都不记，有效记录条件说合成一句 ... 问题：服务端写目录前把同一次裁决里落到同一张表同一项上的说法归拢（dual_check_facts._merged）：业务日期、去重规则只要说法不同就一项都不写，有效记录条件用 AND 合成一句写。审批卡上的预告是每个指标单独算的，卡上不看别的指标选了什么：一个指标采用原流程（paid_at）、另一个采用盲算（created_at），两块里各自加粗说「记为……」，服务端一项都不写；两个指标都采用去重的一边、去重的列不同，也是这样。结尾只说按发起审批时的数据目录预告，看不出选择的组合也会让写入作废。审核人可能为了不让同一张表出现两个业务日期，把本该分开的选择改成一致。 审批卡（run/DualCheckApproval.tsx） - 按其余指标当前的选择，给每个指标的两种选择各找出落到同一数据源、同一张表、同一项上的指标（peersOf）。只看预告会写的一边：选「两边都不对」、还没选的，服务端不会并进来。说法照服务端的 _same_fact 比：业务日期只看哪一列，其余压掉多余的空白比。 - 业务日期、去重规则说法不同时，那一句改说「……与「退款率」的选择说法不同，都不记」，不再算作会写。有效记录条件在「记为……」后面补一句「与「退款率」采用的条件用 AND 合成一句」。 - 选择一变，各块的说法跟着变。没选中的那几句也按别的指标当前的选择说，审核人改选之前就看得出这一选会不会让整项作废。 - 结尾改成「写入的项记为人工确认的事实；以上按发起审批时的数据目录和各指标当前的选择预告……」。原来是「两边都不对时不记。记为人工确认的事实」，读起来像在说不记的那一项。 - 没有预告时的结尾同样改。时间列、去重两句补上「同一次裁决里几个指标给同一张表记的业务日期（去重规则）不同时都不记」。 夹具与检查 - 夹具加 peers 和 merges。peers 换掉「退款率」对不上的那个输入，和「销售额」落到 orders 的业务日期、去重规则、有效记录条件上。merges 是四种组合：业务日期分开选、选同一列、去重的列不同、有效记录条件不同。 - peers 的差异说明和预告是服务端的真实输出。merges 的 written 是 record_choices 在空目录上真写一遍的结果。 - test_dual_check_fixture.py 新增两项。一项不依赖服务端，查每种组合真的落到同一项上。另一项在服务端合入后建临时数据源真写一遍，逐项比对。 - 在 vs/f1a 的 f7d1a2e 和 233afd1 上都跑过：8 项全过，regenerate 逐字节不变。 - 预览用例 dual-check-approval 认 peer 参数。 - check-verify 新增一节： - 分开选时，两边加粗的那一句都说都不记，写明哪张表的哪一项、和哪个指标说法不同。 - 没选中的那一句按别的指标当前的选择说；一个指标改选两边都不对后，另一个回到「记为」。 - 选同一列照常记；去重的列不同都不记；有效记录条件说合成一句。 - 390px 下深浅色都不横向溢出。 - check-verify 没有预告的一节补两项：「人工确认」说的是写入的项；说法不同时都不记。 - 变红验证：去掉实现（peersOf 返回空），check-verify 变红 6 项；把有效记录条件也当成说法不同，变红 1 项；把还没选、两边都不对也当成采用了一边，变红 2 项。 - 改动后 297 项全部通过（原来 274 项）。check-all 里 check-verify 的耗时估计按实测改成 71 秒。	2026-10-05 17:47:21 +08:00
ThearchyHelios	233afd16ee	双盲复算复核整改（第 3 轮）：驳回过的有效记录条件不再借着同一次裁决里的合并写回，合起来写时已有的段只写一次，补改名后分组的遮罩列用例 ... - 同一次裁决里几个指标落到有效记录条件上、要合成一句时，驳回检查原来只拿合起来的整句和驳回的说法比：「status <> 'refunded'」和「is_test = 0」AND 在一起就不再等于驳回的那句，被写成人工确认，和审批卡上「不写」的预告正相反。现在合并前按每个指标自己的说法过一遍驳回检查（_screen）：带回驳回说法的指标拿出来不写，原因和它的预告是同一句话，其余的照写，备注只列真写进去的指标；合起来以后又包含了驳回的整句的也不写。有效记录条件的驳回检查改按段比，!= 和 <>、列名大小写、先后不同都认得出。 - 合起来的条件再和目录里已有的条件合写时，原来拿并好的整句去接，和已有条件部分重叠的整句原样接上，写出「status <> 'refunded' AND status <> 'refunded' AND is_test = 0」。现在接的是每个指标各自的条件，_and_join 只接还没出现过的段；已有条件是人工确认过的，原因里只说另外多出的那几段。最外层是 OR 的条件只在接了别的条件时加括号。 - Fact.also（其余几个指标）改成 members（并进来的每一个，各带自己的说法）：并好的整句不再顶掉第一个指标自己的说法。 - 补用例：合并时驳回的条件拿出来、其余照写（facts 级和图级，真写和预告一字不差）；驳回的整句由几个指标拼回来时不写；驳回时写法不同也认得出；合写不重复、已确认时只说多出的段；_and_join 的段级去重和括号；遮罩列改了名再分组（region AS area）时不收窄。	2026-10-05 17:23:17 +08:00
ThearchyHelios	b206665856	双盲复算前端复核修正（第 2 轮）：「记入数据目录」不再说得比服务端宽——有服务端预告时照预告说，没有时只说必要条件、不写的几种照实说 ... 问题：审批卡上那句「记入数据目录」的提示是照 vs/f1a 早先的规则写的。F1a 在 1491b5c 把写目录的规则收紧以后，有三种常见情况卡上说会记入，服务端却都不写： - 只有一边按时间筛：卡上写「两边只差在按哪一列筛时间」，和正上方那条差异「盲算没有按时间筛选」自相矛盾 - 只多一个指标自己范围的条件（channel = 'web'）：服务端只把排除退款、作废、测试这类无效记录的条件记成有效记录条件 - 只差去不去重，而审核人采用的是不去重的一边：服务端不写 审核人可能为了不让目录被写错，避开本来正确的原流程，结果出具降档；节点设为「判为失败」时运行还会终止。 审批卡（run/DualCheckApproval.tsx） - 服务端在摘要里另带预告（payload.summary[].catalog，F1a 在 f7d1a2e 加的，约定之外另带）时照它说：三个选择各说一句，会写的写明哪张表的哪一项记成什么，不写的写「不记」。两边都不写就不提数据目录。审核人当前选中的那一句加重，选完一眼就能看出这一选会写什么。预告跟着摘要一起来，完整对照还没到或取不到时也照样能说。预告的形状认不出时整份不用，回到有条件的说法。 - 没有预告时（老服务端、升级前挂起的审批），三句改成只说必要条件（「仅当……才」），并把不写的几种照实写出来：只有一边按时间筛时不记；多出的条件得只在一边、并且是在排除无效记录，只看某个地区、某个渠道这类条件不记；采用不去重的一边时不记。 - payload 带了实际生效的「未采用原流程时」（同样是 f7d1a2e 加的）就照它说，不再去取图快照。子工作流里的节点在图快照里找不到，有了它也能说准；值认不出时仍回到图快照。 夹具与检查 - 夹具新增两个变体：只有一边按时间筛、只多一个渠道条件，差异说明都是 explain_sql_diff 的真实输出。每个指标、每个变体都附上服务端预告的真实输出（catalog_preview、variants[].catalog）。backend/tests/test_dual_check_fixture.py 有两项检查：一项不依赖服务端，查预告的形状和写目录的门槛；另一项在服务端模块合入后，逐项比对夹具和 dual_check_facts.preview。regenerate 也会一并重新生成预告。 - 预览用例 dual-check-approval 认地址参数 variant / catalog / on_reject，不带参数时 payload 只有约定里的几项。 - check-verify 按服务端的预告核对两种说法：没有预告的一节，在三种情况下都要以「仅当」开头，并照实说出不写；只差去不去重时，两种选择各断言一次。有预告的一节，核对两边写什么或不记、两边都不写时不提、选中那一句加重（去重的两种选择分别看）、认不出时回到有条件的说法、取不到完整对照时照样说，以及 390px 下深浅色的对比度。payload 的 on_reject 那一节核对：照它说、不取图快照、子工作流也说准、认不出时回到图快照。 - 去掉实现以后，检查脚本在这三种情况、预告和 on_reject 上共有 13 项变红。改动后为 274 项全部通过（原来 218 项）。check-all 里 check-verify 的耗时估计按实测改成 65 秒。	2026-10-05 16:56:05 +08:00
ThearchyHelios	0cd96fe327	合入运行对比加固：一个维度值占几行时按维度值数两边各引用了几行，部分行挤出引用的行段、单格换了同一维度的另一行都判说不清；维度列设了遮罩时照样核对、说明只写行号；补齐循环回边、写入者措辞、严格拆分范围、单边遮罩等守护用例	2026-10-05 16:44:22 +08:00
ThearchyHelios	f7d1a2ecba	双盲复算复核整改（第 2 轮）：遮罩的分组列不收窄，收窄时去掉 HAVING，审批卡带上处置和写目录的预告，同一次裁决里的有效记录条件合起来写 ... 节点（nodes/dual_check.py） - 差异说明收窄到这一格时，分组键的结果列或它用到的列设了遮罩，就不收窄、照整条比。原流程、盲算各按自己那份快照 的遮罩（查询当时记下的加数据源现在设的）判断。以前按这一行的分组值补等值条件，「region = '华东'」这样的遮罩列 取值会跟着差异说明进审批 payload、human.requested 事件、对照工件和 dual_check_catalog 日志 - 按行收窄时连 HAVING 一起去掉：这一行既然在结果里，它所在的组就满足 HAVING。留着会多出一条「分组后的筛选」， 还会占掉「只差一个方面」的名额，真正的差异（比如时间列）就写不进目录 - 审批 payload 在约定的几项之外带上实际生效的 on_reject。摘要里每个指标另带 catalog：选 a、选 b 时，按发起审批 时的目录各会往数据目录里写什么（{write: true, source, table, item, value}），不写的给出原因（{write: false, reason}）。审核人要看得出不采用原流程会不会让运行失败、某个选择会不会被记成人工确认的目录项 （on_reject 以前只能从图快照里读，子工作流里的节点读不到） 写数据目录（dual_check_facts.py） - 写入的判断拆成不读库的 _plan：真写（_write）和审批卡上的预告（preview）用同一套判断，不会说一套写一套 - 同一次裁决里落到同一项上的几个说法合成一项（_merged）： - 说法一样的只写一次，备注列出每个指标 - 有效记录条件用 AND 合成一句。derive 只收排除无效记录的条件，「排除退款」和「排除测试单」并不矛盾，以前两条 都被丢掉，原因还写成「互相矛盾」 - 业务日期、去重规则说法不同的仍然都不写，原因改为「给出了不同的说法」 - 合并后再和目录里已有的推断条件合起来写时，要求每个被采纳的一边都按已有条件筛过；有一个没按它筛，就不动并说明 是哪个指标 测试 - 遮罩分组列（原流程侧、盲算侧）的取值不出现在 payload、对照工件、节点产出和节点事件里 - HAVING 收窄后只剩时间列一处差异，并写进目录 - payload 的 on_reject、摘要里的预告（一致、已确认不覆盖、指标自己的范围几种情形） - 有效记录条件合并（含和已有推断条件合写、有一个被采纳的一边没用已有条件时不动），同一说法只写一次 - 补上复核指出的三处接线缺口，各有一条图级用例： - 带取舍的列名（gmv_by_order_date、paid_orders）不交给盲算 - 取值在运行输入里的排除条件不写目录 - 分组列上的 is_test = 0 不写目录 - 13 处变异（遮罩判断两侧、HAVING、上面三处接线、合并、预告、on_reject 等）去掉后，相关测试都会变红	2026-10-05 16:43:14 +08:00
ThearchyHelios	5f48f8727e	运行对比加固（收尾）：区域等维度列设了遮罩时照样拿它核对两次引用的是不是同一批行，说明只写行号、不写值，挤出引用行段的和真的少了分得清，没挪的照常是数据变化；补单格反方向、归因维度按两边各自引用的行认、写入者改了配置时不严格拆分、并行支路查询四处守护用例	2026-10-05 16:41:59 +08:00
ThearchyHelios	52baa0d65c	双盲复算前端复核修正（第 1 轮）：高亮按服务端真实的差异输出做，「记入数据目录」只在服务端真会写时有条件地说，后果和提示按节点的处置说 ... 审批卡 - 对照两条 SQL：text_diff 是规范化之后的行（列名带表名、条件并成一行），和原文逐行对不上，原来按「两边逐行相等」高亮在真实输出上一处都标不出。改成两段原文按行做一次 LCS（不看空白、大小写和行尾逗号分号）高亮不同的行，一行都对不上时不乱标；text_diff 分原流程、盲算两栏，每行高亮（窄栏上下排）。 - 「只差一个方面、会记入数据目录」：照服务端 dual_check_facts 的门槛收紧——不等价、没用兜底、差异恰好一条（几个输入都对不上时合并后至少两条，所以也就是只有一个输入对不上），且是时间列、筛选条件或聚合；按这三种分别有条件地说会记成哪一项，选「两边都不对」不记、已有人工确认的不覆盖、以时间线为准。时间范围、两条筛选、关联、解析失败、多个输入合并都不再说。 - 后果和提交后的提示：payload 不带 on_reject，从这次运行的图快照里按节点 id 读「未采用原流程时」；判为失败时写明采用盲算或都不对会终止运行、提示也照实说，缺省时不再挂那句，读不到时有条件地说、提示不下结论。 - 只有解析失败时和摘要阶段一样按兜底说（固定那句 + 解析的原话），默认展开对照；兜底的原话另有原因（比较超时）时附在下面，一边没有 SQL 时不说「两条 SQL 的写法不同」。 - 认不出任何指标时留一个「驳回并终止」（approved 为假），运行不再一直挂着。 时间线 - dual_check_catalog 的 item 是目录项的键（business_date 等），按数据目录的叫法写成「「orders」（shop）的业务日期」，认不出的键不显示。 - dual_check_limit 的 metric 是指标 ID，不再当名字加引号。 - challenge_skipped 的 no_report 是报告文档读不出来（报告节点找不到时节点直接报错），说法和下一步改成去查报告节点有没有执行成功、在不在执行到的分支上。 检查器 - 字段名和服务端校验报错的叫法（schema.py 的 DUAL_CHECK_FIELD_LABEL）对齐，处置选项以服务端的短说法开头；check-verify 在服务端合入后逐项比对。 - 盲算模型移出高级选项：时间线「模型相同」的定位要找得到它。 - 上游有几张口径卡时写明必须选（服务端校验会挡住发起运行），不再说「建议指定」。 - 「跟随设置」的当前值每次打开检查器都重取，改了设置回到画布不再是旧值。 测试 - 夹具里的差异说明换成 explain_sql_diff 对同一对 SQL 的真实输出，新增几对 SQL 的变体；backend/tests/test_dual_check_fixture.py 核对夹具和真实输出一致，并可重新生成。 - check-verify 补真实形状下的高亮、各种差异下「记入数据目录」说不说、只有解析失败和兜底原因、按处置说后果和提示、认不出指标时的驳回、叫法比对、多张口径卡、设置重取；check-decode 改用服务端真实的日志形状。check-verify 的耗时估计按实测改成 45 秒。	2026-10-05 16:10:55 +08:00
ThearchyHelios	1491b5c7f3	双盲复算复核整改：指标自己的筛选范围不再写成有效记录条件，盲算不再看到原流程的列名，差异说明收窄到这一格 ... 写数据目录（dual_check_facts.py） - 有效记录条件只收「排除无效记录」的条件：被排除的取值是退款、作废、测试这类（或码值表里写着这类意思）， 标记列只认留下有效记录的一边（is_test = 0、is_valid = 1、deleted_at IS NULL）；取值出现在指标名称、口径说明、 所在分组、运行输入里的，用到分组列的，一律不写，原因写明「可能是指标自己的筛选范围」。以前「华东销售额」的 region = '华东' 会被记成订单表人工确认过的有效记录条件，之后所有查订单表的工作流（含下一次盲算）都只看华东 - 目录里已有的有效记录条件被采纳的一边也按它筛了的，和新条件合起来写（已确认的不改，照实说）；没按它筛的不动。 以前整项替换，两边都用着的 is_test = 0 会被静默丢掉。推断的去重规则说法不同的也不替换 - 业务日期只在两边都按时间筛、按的列不同时才写；一边根本没按时间筛的不写 - 采纳了不去重的一边不写去重规则：那是指标自己的算法，写成「不去重」会把别的指标带偏 - 同一次裁决里几个指标对同一项给出矛盾的说法，整组都不写 节点（nodes/dual_check.py） - 盲算任务里不再给原流程结果的列名和同一行的维度列名：分组的只给取值（日期说成「2026-09-02 这一天」）， 原 SQL 写死的文字列连取值也不给；只有几项输入都来自查询又没写口径说明、列名看不出取舍时才给列名。 以前「order_date 为 2026-09-02」等于告诉盲算按下单日归属，下单日和支付日的陷阱正好漏掉 - 差异说明先把两条 SQL 收窄到这一格（只留算出这一列的那一项，分组的按这一行的分组值改成等值条件）再比， 多列查询、分组取一行时不再混进「选出的列」「分组」这类噪声，只差一个方面的也写得进目录 - 产出状态：全部一致才是 agreed，一个都没核成是 unchecked，核成一部分是 partial；产出和台账加 counts； 无法复算的指标发 dual_check_unchecked {metrics: [{id, name, reason}]} - 共用一格的几个指标触顶时每个指标各发一条 dual_check_limit - 查询次数刚好用完、交回的格子是真查出来的照常比对（时长、金额触顶仍按无法复算） - 审核人没选或选了认不出的照实记「审核人没有对指标作出选择」，不再替人记成「两边都不对」 - 盲算先单独做第一个，其余最多 3 个同时进行，避免串行撞上运行单段的时长上限 配置 - 画布校验：双盲复算配了失败重试报错（重试会把盲算整轮重做、再问审核人一次）；enabled 用 is 判断，0、1 不再放过 - 发起时的核查设置快照：子工作流（按运行时的取法读）里有双盲复算、反方审稿节点时也快照 - 助手节点说明补一句不要给双盲复算配 retries 测试：补上遮罩两道防线、规范化后一致但值不同、两个输入都对不上、只复算配置的指标、原值为 0、摘要最多 3 条、 驳回、多列查询、分组取一行、指标筛选范围不写目录等用例；每条核心改动都做过去掉实现、测试变红的验证	2026-10-05 15:54:03 +08:00
ThearchyHelios	eea098e975	运行对比加固（第 3 轮）：单格要是同一个区域的同一行；归因按哪组维度说就按哪组维度核对；快照里行和列对不上的说不清；补单格反方向、行段只差最后一行、精确性一侧等变红测试 ... - 单格（数组字段的一个元素）引用的那一行两次是同一个区域，还要是它同样的那一行：按查询结果的先后，排在这一行前面的、它的行数两边一样。区域 × 日期的结果东区少了一天，第 3 行从南区的第一天变成第二天，原来报成只数据变、南区少了 5（同一天的南区其实多了 10，正负号反了），同一处引用换成一行的行段却说不清；按金额排的第 2 行从东区第二高的那天变成最高的那天、取第二个元素的也一样。只比排在前面的行数，不比外面还有没有它的行：东区两天还是一天、第 1 行都是东区第一天的照常是数据变化 - 行段核对引用的是不是同一批维度值时，按两边整份结果认出的维度核对一遍，再按归因用的维度（引用的那段行上认出的）核对一遍，两组都切在同一处才算同一处。渠道在引用的行里两边都只有「线上」、归因按区域说：南区第二天走了线下、挤到第 5 行，原来只按（区域, 渠道）核对，报成只数据变、南区 -100%，和「南区真的只有一天」一字不差，反方向也是；区域 × 渠道取前 2 行、南区新开的线下排第 3，归因 300 → 280，快照里南区是 300 → 480。只按归因用的那组也不够（只引用一行的认不出维度；引用的行两边都只有东区、只有整份结果分得出区域的也要核对）。取行的规则抽成 _attributed_rows，归因和核对共用 - 快照里有的行和列对不上、认不出各行是哪个维度值：原来退回按行号认、报成只数据变，现在和快照读不出来一样说不清，说清是哪一边 - 新测试：单格同一区域换了一行（两个方向、按金额排、取第二个元素、排在前面 2 行对 1 行、只有一行的行段同样说不清、同一行的对照）；按归因用的维度核对（渠道挤出、反方向、新开线下，各带对照，占比之和为 1；只引用一行时仍按整份结果的维度核对）；行和列对不上（两个方向）；单格反方向（这次取的区域在基准运行里，只是不在这一行）；行段只差最后一行；精确性一侧（第 4 名每周不同、后面剩的行数不同，仍是数据变化）；排在前面的行数 2 对 1、位置说明里的行数、两边都只引用一部分但行数不同、基准一行都没引用时说哪一边；引用的行两边都只有东区时按整份结果认区域；金额列存成文本时也不当维度；只在一次运行的图里有的下游节点；不归因时整体说明照样提遮罩 - test_an_element_only_needs_the_same_region_on_its_row 改名 test_an_element_does_not_mind_other_rows_of_its_region：单格不再只看区域，原名和说明都不对了	2026-10-05 15:52:51 +08:00
ThearchyHelios	4d364d385b	反方审稿复核修正（第 2 轮）：照录的理由不露内部标记、裸数字注明无出处，只停用了部分数据源时理由和时间线写明没查哪几个，撞上每日金额上限的几句同一种说法 ... - 不采信时照录反方的理由改成纯文字：解析不了的引用（⟦?v:…⟧）换成「（引用无效）」，裸数字后面注明「（无出处）」。 这种句子没有理由文档，界面按文字显示，以前内部的占位标记会原样露在审批卡上，裸数字也不标 - 一句该查的数据源只停用了一部分时照常反查，理由末尾由系统注明哪几个没查（写进理由文档：界面按文档画理由， 写法和把说明写进原文再组装出来的一模一样），时间线另记一条 challenge_sources_lost。以前只写进给 agent 的任务， 审稿记录和审批卡上的「经受住」看着就像每个源都查过了。没挂依据的句子按整份报告用到的源查，任务、理由里不再说 「这句引用的」 - 当天的核查金额用完时，派出去就撞上上限、一次模型都没调用的那句，和后面不再派出的句子用同一种说法 「已达上限（…），这句未反查」，不再一句「反查未完成：…没能交结果」、一句「这句未反查」 - 判失败的报错只推翻一句时说「请核对这句结论」 没有改的：被推翻的出具缺口读成「反方审稿「反方审稿」：反方审稿推翻了…」并归在「校验不完整」下，审批卡和节点产出 分不出根本没反查，challenge_unreviewed / challenge_sources_lost 不在期 3 约定的日志代码表里——这几处要改约定或 别的包的文件（io.py、decode.ts、NodeCard.tsx、EvidencePane.tsx、ChallengeSummary），留给编排者定	2026-10-05 15:50:20 +08:00
ThearchyHelios	12dc47b976	期 3 反方审稿（前端）复核修正：要审的报告按服务端的认法定，校验报过的不再重复，补齐降档提示的反例检查和运行类别取不到时的说明，修好显示全部的焦点与去重，处理审稿记录没存上的情况 ... 检查器 - 「要审的报告」留空时，照服务端 schema.challenge_report 的认法：先看直接连着的报告撰写节点，恰好一个就审它；不是一个时，整个上游只有一个才取那一个。以前只认第二步，「初稿 → 终稿 → 反方审稿」这种接法下会误报「上游有 2 个，请选择」，同模型提醒也不出。现在留空项写出实际会审的那份（「未选择：审上游的「终稿」」），同模型提醒也按同一套认法判断。 - 认法写成 nodePickField / upstreamModel 的 rule 选项。缺省是 'upstream'（只看整个上游），和 F1a 的 dual_check_card 一致，双盲复算以后也能直接用。 - 选中的节点在上游、类型却不对（例如输入节点），以前写成「不在上游」，现在照实写「不是报告撰写节点」，提示里说清它是哪类节点。判断顺序和服务端一致：先看存不存在，再看类型，最后看在不在上游。 - 画布校验已经在 report / model 字段上报过问题时，不再画本地那句提示，避免同一件事一琥珀一红说两遍。判断哪些问题属于本字段，用和 Inspector 挂字段时相同的 fieldOfIssue；下拉里照实标出的那一项保留。 - 文案里的设置入口统一写成「设置 → 偏好设置 → 核查」，和设置页的真实标签、双盲复算、证据裁判的写法一致。 审批卡 - 降档的原因改为常显在概况下面，不再只放在悬停提示和读屏文字里。 - 运行类别取不到时，不再悄悄不写降档：照实写「暂时无法确认运行类别；如为正式运行，被推翻的结论会使出具降档」，并给出重试按钮；窗口重新拿到焦点时也会再取一次。 - 「显示全部」补句时按 unit 去重：两边都有 unit 时只比 unit，有一边缺 unit 才比原文。以前原文相同、unit 不同的一句会被吞掉，被吞的可能正是被推翻的那句。条目缺 unit 时不再补假的 #i。 - 键盘按「显示全部」、补句那一行的重试、一句详情里的重试、运行类别的重试之后，焦点都会接到新出现的内容上，不再掉到 body。焦点已经被用户移到别处时不抢。 - 审稿记录没存上（artifact 为 null）时，每句只列判断，不能点开，整块说一句「反方审稿记录未保存，无法查看理由和查询」；「另有 N 句未列出」照常显示，只是不给「显示全部」。 检查（check-challenge 共 153 项） - 新增预览用例：正式运行且没有被推翻的结论（降档 / 只标注）、探索运行配只标注、运行类别取不到、原文相同而 unit 不同、审稿记录没存上、链式接法的检查器。 - 「只标注、探索运行、没有反方审稿」拆成各自独立的段，一段出错不会遮住其余几段。 - 新增的检查项包括：降档原因常显、取不到运行类别时的说明和重试（含窗口重新拿到焦点后再取）、显示全部和各处重试后的焦点、按 unit 去重、审稿记录没存上、链式接法、类型不对的节点、校验报过就不重复说，以及窄屏和深浅色下新增几行说明的对比度。 - 复核时用来证明检查不够的两个变异，M1（正式运行一律写降档）和 M10（探索运行也写只标注说明），连同本次各项修正的变异，都已逐一确认会被检查发现。	2026-10-05 15:35:01 +08:00
ThearchyHelios	4ceac6b74c	反方审稿复核修正：没有出处的结论不采信，推荐接法下审批卡有报告，重试和接着跑不重审、不拿旧审稿冒充 ... - 出处：一条查询都没执行成功的判什么都记为无法判断，判「被推翻」的理由里还得引用到自己的查询结果——零查询的推翻能让 正式出具降档，零查询的「经受住」会给审批人假安心。系统写明原因，反方原本的结论和理由照录。这句引用的数据源都已 停用时不派 agent；核查模型本身用不了时后面的句子照同一个原因记，不再逐句去建模型 - 时间线：有句子没能反查时另记一条 challenge_unreviewed（带第一条原因），challenge_done 的说法分开写查过的和没查成的 - 审批卡：「报告 → 反方审稿 → 人工审批」时审批说明不引用正文也认得出这份报告（reviewed_report_ids 穿过直接连着的 反方审稿，reviewed_by_human 同步），审稿概况附得上 - 重试与接着跑：同一次执行里的重试沿用已经审完的结果，不再多花一份钱、也不会把「被推翻」重审掉；审稿结果带输入指纹 （报告、文档、反方模型、上限、遮罩），接着跑时只改「结论被推翻时」沿用，改了审稿本身就重审 - 处置：产出和审批卡里的 on_refuted 写实际生效的 degrade / flag；「报错并停止运行」配「出错时：记录错误并继续」画布 校验挡住，跳过校验的旧图执行时改按出具降档；反方审稿不在带出具契约的成果节点上游时画布给警告（降档不会发生） - 摘录里指向原报告查询的写法（指标取自查询 Qn、查询 Qn 的 SQL、出现在查询 Qn）都标成「原报告 Qn」，和反查 agent 自己的 Q1 分开 - 选项叫法和检查器下拉一致：出具降档 / 只标注 / 报错并停止运行，「启用」写跟随设置；助手手册同步 - 补测试：快照里的反方模型和每日上限、裁判判成不是结论的句子不审、审批卡只给被审的那份报告挂概况	2026-10-05 15:08:53 +08:00
ThearchyHelios	44e4597037	运行对比加固（第 2 轮）：行段要把引用过的每个区域切在同一处——一边整个被引用、另一边只引用了一部分的，引用的行数没变少也说不清；只在一边有的区域那一边算整个被引用；引用的行不从第 1 行开始时还要是它同样的那几行；单格只看那一行是不是同一个区域 ... - 一个区域在一边整个被引用、另一边只引用了一部分（其余的行还在快照里）：上一轮只在「有行在外面的那一边引用得少」时判说不清，南区这次多了一天、引用的行只盖住前两天（行数没变少，甚至更多）照样报成只数据变，归因和「真的只有这几天」的对照一字不差，反方向连正负号都反了；现在按切法比：两边都整个被引用，或者都只引用了它同样的那几行，才是同一组数 - 只在一边的快照里有的区域，没有它的那一边算整个被引用：北区这次新出现、三天只引用了两天，基准运行南区只引用了一天、这次南区没了，都说不清；新出现、没有了的区域整个被引用的照常是数据变化 - 引用的行不从第 1 行开始时，按「排在引用的行前面的行数、引用的行数」认引用的是它的哪几行：两边都只引用了东区一行，基准是它金额第二高的那天、这次是最高的那天，说不清，说明里写出两边排在前面的行数 - 单格（数组元素）只看引用的那一行两次是不是同一个区域，不套行段的切法：东区两天还是一天，第 1 行都是东区的第一天；第 1 行的东区真的没有了照常比 - 说明说引用的行外面有它的那一边，两边都有的说引用得少的那一边；几个区域切法都不同时说基准运行引用的行里先出现的那个 - 截断的快照仍按取回的行比（和引用整份结果一致，挤到截断点后面的行看不到，不做归因），写进文档 - 新测试：一边整个一边部分（这次多一天、这次引用得更多、反方向，各带真的只有这几天的对照，占比之和为 1）、切在同一处（两边都只引用南区第一天仍是数据变化）、行数不同两个方向的说明、几个区域都不同时说哪一个、排在前面的行数不同、只在一边有的区域（新出现、没有了）、两列维度一起认（含一边只有一个值的区域列）、单格只看那一行、挤出两行时的行号和行数（两个方向）、正好 3 行不写「等」、两个 Agent 都交得不同时点名画布上靠前的、单边遮罩时整体说明提到遮罩	2026-10-05 14:47:05 +08:00
ThearchyHelios	8096c44626	节点卡片：摘要钩子拿到的配置兜底成空对象 ... 画布上的节点配置正常都有（toFlow 补了 {}），兜一下是为了一个坏节点不至于让钩子在选择器里抛错、带垮整张卡片	2026-10-05 14:46:02 +08:00
ThearchyHelios	f2e854842c	check-all：check-verify 的耗时估计按实测改成 25 秒 ... 占位时登记的是 1 秒；换成真检查后单独一遍约 20 秒、四道并行时约 20 秒，按略宽的数排队	2026-10-05 14:44:31 +08:00
ThearchyHelios	5093e98c49	双盲复算前端（四）：设置页「核查」一节 ... - pages/VerifySettings.tsx（新）：核查模型（照证据裁判的写法：两项都空时醒目提示将使用证据裁判的模型，只填模型时写明 按模型名用哪个接入）；双盲复算（启用、允许的相对误差、每项最多查询次数、时长上限）；反方审稿（启用、每份报告最多 审几句、每句最多查询次数、时长上限）；审批质询（启用、每次最多查询次数、时长上限）；每日金额上限（可不限）和今日 核查花费（GET /api/settings/verify/spend）。上限照 LimitField 的写法：勾「不限」框变灰、写明还受什么约束，勾掉填回 原来的数；只校验改过的项；字段名就是服务端 VERIFY_SETTING_LABEL 的叫法，422 的报错对得上 - SettingsPage：PrefsTab 另持一份核查草稿，和其余设置共用保存条（改动计数、项名、放弃、校验都算上），保存时整组写 verify（不限存 null），存完再取一次今日花费；老服务端没有 verify 一组时不显示 - check-verify 加设置页读回各项、叫法逐项比对、整组写的请求体、错了不让存、422 照实说、老服务端不显示、 390px 不溢出、对比度	2026-10-05 14:31:16 +08:00
ThearchyHelios	e353706498	双盲复算写目录：人工驳回过的同一说法不再写回；节点说明补上盲算 agent 看得到什么 ... - 数据目录里这一项以前被人明确驳回、驳回的正是这次要写的说法：两次人工判断对不上，不替人拿主意，不写并照实说原因；驳回的是 别的说法时照写。业务日期只按哪一列比，规则、时区是补充。 - 节点模块说明和盲算的系统提示补上：结果分了组的另给那一行的维度，统计期看本次运行的输入。	2026-10-05 14:31:15 +08:00
ThearchyHelios	ce19b074cf	双盲复算：盲算 agent 的任务里带上本次运行的输入参数 ... 原流程的 SQL 常常是拿运行输入拼出来的（统计期的起止、地区），盲算 agent 只看口径说明不知道算哪一期，就算不出同一个数。任务里 加一行本次运行输入里的标量参数（最多 12 项、每项截到 40 字），只给参数、不给 SQL。分组结果的测试顺带核对任务里有统计期参数、 没有原流程算出的数。	2026-10-05 14:27:19 +08:00
ThearchyHelios	fb6f5c0ff9	check-all：check-challenge 的耗时估计按实测改成 17 秒（只影响排队顺序）	2026-10-05 14:26:15 +08:00
ThearchyHelios	77f3119cf9	双盲复算节点：按输入盲算、代回原式比对，不一致交人裁决，只差一个方面时写进数据目录 ... 占位的直通桩换成真实现（engine/nodes/dual_check.py）： - 按输入复算：口径卡上输入来自查询快照的指标，每个这样的输入另起一个看不到原 SQL 的只读 agent（verify_agent），只给它指标名、 口径说明、这个输入在计算式里是哪一项（「输入1」，不露取数节点和 cell() 的行列）、分组结果那一行的维度列、数据源的数据目录； 它交一个格子引用，由代码从它自己的快照取值。盲值用原式代入盲算的输入算（engine/recompute.py，取整同口径卡），按相对误差比， 原值为 0 时按绝对误差。两个指标用到同一格只盲算一次。合并查询、整段结果、遮罩列、文本输入不能单独复算，记「无法复算」、不花钱。 - 一致不挂起，产出 agreed；不一致时逐个对不上的输入用 explain_sql_diff 说清差在哪（规范化后一致却值不同的写「差在数据」）， 完整对照落成 card_artifact 工件（避开审批 payload 的截断），按约定的 payload 用 ask() 挂起。审核人选 a 无缺口，选 b、都不对 写 issuance_gaps，on_reject 为 fail 时节点失败；明确驳回按人工驳回失败；没选的按「都不对」。触顶、核查模型不可用、交不出数的 指标记「无法复算」并写缺口，核查模型本身用不了时后面的盲算不再一个个去试。 - 设置读发起时的快照，没快照的读一次记进 checkpoint；读设置、盲算连同比对、差异说明连同工件、写目录各在一个 @task 里，审批恢复 重放时不再调用模型、不再计费、不再写，事件也只发一次。日志按约定的 code 和结构化字段发（dual_check_skipped / same_model / agreed / disagreed / resolved / catalog / limit）。盲算的查询只发 tool.end（role: verify），台账只记一条 kind: dual_check， 报告的写作目录不含盲算的查询；用量计入节点。 选择写进数据目录（engine/dual_check_facts.py）：只在审核人选 a 或 b、差异只有一条具体条目、又对得上目录事实时写——时间列不同记 业务日期，一边多一个只涉及一张表的筛选条件记有效记录条件，聚合只差去不去重记去重规则，都按被采纳那一边的写法。照对话提案的 规矩核对，记为人工填写、已确认，备注写明运行、节点、指标；已是同样的已确认说法不再写，确认过的不同说法不覆盖、照实交回原因。 测试：虚构零售库埋了退款行、下单日对支付日两个陷阱，盲算模型是 MockChatModel 剧本，覆盖一致、不一致挂起与 payload / 工件形状、 三种选择与 on_reject、写目录与幂等、不覆盖、全局关闭与节点覆盖、发起时快照、重放不再执行盲算、写作目录不含盲算查询、用量、 同模型提示、触顶、不能单独复算的输入。占位节点的旧测试只留反方审稿。	2026-10-05 14:23:43 +08:00
ThearchyHelios	7a9dc93dde	双盲复算前端（三）：检查器字段、节点卡片摘要，以及检查器与节点卡片的钩子 ... - nodeDefs：照约定一字不差地加 FieldDef.render 与 FieldRenderProps；NodeDef 加可选的 summary(ctx) 钩子 （ctx：id、config、画布上的 nodes 与 edges，只返回字符串）；dual_check 换成真字段：要复算的口径卡、复算的指标、 口径说明、启用、审核人不采用原流程的结果时（基本），盲算模型的接入与模型、允许的相对误差（高级） - Inspector：照约定一字不差地在 FieldInput 的 switch 前交给 field.render - canvas/DualCheckFields.tsx（新）：口径卡下拉分上游、其余两组，不在上游或不在画布上照实提醒；指标逐个勾， 全勾回到缺省不写、最后一个不让取消；口径说明逐个指标写，被取消的指标上已写的说明列出来可删；盲算模型照「结论句 裁判」的写法（只填模型时写明按模型名用哪个接入）；相对误差的占位写出设置里的值；启用三态，跟随设置不留 null。 每个控件只写自己的键，留空写回 undefined - NodeCard：用只返回字符串的 studio 选择器调摘要钩子，有就用、没有照旧 summarize；摘要写「复算「卡名」 · N 个指标」， 关闭时标出；去掉 dual_check 的占位 case - 预览用例加检查器（小画布用真的节点卡片 + 360px 检查器），check-verify 加检查器写配置、摘要跟着变、窄屏和对比度 - 去掉 nodeDefs 里已经不成立的「下面两种还是占位」注释	2026-10-05 14:23:17 +08:00
ThearchyHelios	ff23c6a8ad	双盲复算的配置与发起时的设置快照：画布校验、核查设置快照进运行选项、助手节点说明 ... - 画布校验（engine/schema.py）：「口径卡」必须是上游的口径卡，没写时上游只能有一张（dual_check_card，节点执行也用这一个认法）； 「复算的指标」「口径说明」的键必须是那张卡上的指标 ID（引用自别的工作流的口径卡画图时查不出，不查）；开关、允许的相对误差、 未采用原流程时的取值。报错写检查器上的中文叫法，叫法暂放在 DUAL_CHECK_FIELD_LABEL（labels.py 不归这个工作包）。 - 发起（engine/launch.py）：图里有双盲复算或反方审稿节点时，把核查设置快照进 options["verify"]。这两种节点在运行中途读设置， 审批停下期间改了设置，恢复后的那一段就会按另一套规则走；发起时定下来，重放和正式运行才可复现。没有这两种节点时 options 原样不动，run.started 和以前逐字相同；调用方已经给了 options["verify"] 的照它的。 - 助手的节点说明（NODE_REFERENCE）加 dual_check 一条：要正式出具、口径卡上的指标来自查询时接在口径卡之后、报告之前，各配置项 怎么写（口径说明按业务写、盲算模型默认不写）。	2026-10-05 14:23:00 +08:00
ThearchyHelios	c5a187ab7d	期 3 反方审稿（前端）：审批卡上的反方审稿——概况、降档提示、逐句判断，点开看理由和反方的查询 ... ChallengeSummary 从空插槽换成真组件，读 payload.reports[i].challenge： - 一行概况：经受住、被削弱、被推翻、无法判断各几句。有被推翻的、正式运行、按降档处理（on_refuted 为 degrade 或没给）时 醒目提示「出具会降档」；只标注时不写降档，写明只做标注；探索运行不出具，不说任何和出具有关的话。运行类别按运行 id 从证据 store 取（loadRunClass），取到之前不下结论 - 逐句列出结论原文和判断标签（颜色照结论句裁判，经受住也不用确定性的绿；标签不铺底色，浅色主题下小字对比度够 4.5）， 整块写明判断由反方模型给出、并非系统核对 - 点开一句才按 challenge_artifact 取工件（GET /api/artifacts/{id}），一张卡各句共用这一次，取到的按 id 缓存，出错的 不缓存、可重试。理由按理由文档画：有出处的数字照证据的样子画实线、后面挂查询编号，点一下跳到那次查询并描边； 裸数字画点状线、句末挂「无证据」。理由文档在工件里直接给、或给的是另一个工件 id 都认；都没有时显示渲染后的正文 - 反方执行的查询：数据源、SQL（可复制）、行数、结果是否截断 - 条目最多十句：计数更多时写明另有几句，「显示全部」从工件里补齐 - 审的报告都没有经过反方审稿时什么都不画、不发请求	2026-10-05 14:10:32 +08:00
ThearchyHelios	504bb9ad93	期 3 反方审稿（前端）：检查器与节点卡片——可配置要审的报告、句数与查询上限、反方模型、被推翻时的处理、启用 ... - nodeDefs、Inspector 加约定里的字段渲染钩子（FieldDef.render、FieldRenderProps，FieldInput 里给了 render 就交给它画）， 代码照约定一字不差，双盲复算的工作包会加同样的代码 - 新增 canvas/verifyFields.tsx，三样通用控件写成双盲复算也能直接用的样子，文案全由调用方传入： - 选画布上的节点：只列本节点上游的某一类节点（下游的运行到这里还没有产出）；留空写回 undefined，按缺省取上游的那一个； 上游没有、有好几个又没选、选中的被删掉或挪到下游，都在下面照实提醒，选中项照实列出，不像「未选择」 - 三态开关：跟随设置 / 开启 / 关闭，对应配置里没有这一项 / true / false；单选组，方向键在组内移动 - 核查模型：接入加模型，写法同结论句裁判的模型选择（只填模型时说明按模型名会用哪个接入、和被核查的模型相同时提醒） - challenge 节点去掉「功能开发中」，检查器字段：要审的报告、最多审几句、反方模型（接入、模型）、结论被推翻时 （出具降档（默认）/ 只标注 / 报错并停止运行）、启用；每句最多查询次数、每句时长上限放在高级选项。上限都可以不写， 按「设置 → 核查」取，不往配置里落默认值 - 节点卡片摘要按配置写：审哪份报告（节点 id，没选时写审上游报告）、最多审几句（没写时写句数跟随设置），关掉的写已关闭 - terms.ts 的 CHALLENGE_TEXT：判断统一叫经受住、被削弱、被推翻、无法判断；检查器、卡片摘要和审批卡的文案都在这一块	2026-10-05 14:10:17 +08:00
ThearchyHelios	b58321f6b8	期 3 反方审稿（前端）：先写检查——类型、预览用例与 check-challenge ... - types.ts 末尾加反方审稿的类型（约定里的审批概况 payload.reports[i].challenge、challenge_artifact 工件）， ApprovalReport 用声明合并补上 challenge 一项，不动前面的定义 - 预览用例 dev/fixtures/challenge.tsx：审批卡七种情形（正式运行默认降档、只标注、探索运行、没有反方审稿、 超过十句、工件取不到、360px 右栏）和检查器（两个上游报告、一个下游报告的虚构图，旁边是节点卡片和实时配置） - 夹具 challenge.json 与检查脚本共用；理由文档是后端 run_verify_agent + compose_doc 真跑出来的，库、表名、 地名、数字都是虚构的 - check-challenge.mjs：概况计数、被推翻时的降档提示（只标注、探索运行不写）、逐句标签、点开后取工件并显示 理由（数字的出处、裸数字）与查询、工件取不到可重试、超过十句显示全部、检查器字段写进节点配置、卡片摘要、 390px 不横向溢出、深浅色对比度；登记进 check-all 此时还没有实现，检查全部不通过（7 段都超时），下两个提交补上	2026-10-05 14:09:45 +08:00
ThearchyHelios	cac34c90dd	双盲复算前端（二）：两路对不上时的审批卡，三选一裁决 ... - run/DualCheckApproval.tsx：期 0 的空插槽换成真组件。先按 payload.summary 画两个值、相差比例、摘要里的差异， 完整对照（card_artifact）到了再补盲算模型、全部具体差异和「对照两条 SQL」；只有兜底说明时写明未能归纳成具体差异 并默认展开对照；对照区先列每个输入两边各取到多少，只对照不同的输入，两条 SQL 按卡片宽度左右并排或上下排， text_diff 里有的行在原文中高亮，规范化后对不上原文的不乱标、另列规范化后不同的行；只差一个方面时说明选择会记入 数据目录；每个指标三选一（原生单选，键盘可操作），缺一个都不能提交，回复走审批接口，value 为 {choices, note}； 后果按运行类别说，写明「采用盲算」不替换报告里的数，探索运行不提出具；完整对照取不到时按摘要照样能裁决 - RunPanel：payload.kind 为 dual_check 时不画通用的输入框、备注和「提交 / 驳回并终止」，署名那行保留， onResolved 交给 DualCheckApproval；其他审批卡不变 - 预览用例 dev/fixtures/dual_check.tsx（夹具 dual_check.json 与检查脚本共用，数据虚构） - check-verify：期 0 的占位换成真检查——核查设置的叫法和服务端逐项比对，审批卡的摘要与补全、具体差异、只有兜底、 并排与高亮、不选全不能提交、请求体、取不到完整对照、探索运行、390px 与右栏不溢出、深浅色对比度	2026-10-05 14:07:57 +08:00
ThearchyHelios	dbf7b994d7	反方审稿：校验找不到报告时给一句实在的话（不留空串），节点说明写清「启用」的取值规则	2026-10-05 14:03:37 +08:00
ThearchyHelios	69b40c0b43	反方审稿测试补两处：摘录按数据源当前的遮罩也要遮，撞上每日金额上限之后不再派 agent ... 去掉实现逐项验证时发现两处测不出来：遮罩只测了查询当时就设好的情况（快照里自带遮罩列，不传当前遮罩也遮得住）， 改成同时测运行中途才给数据源设上遮罩；每日上限只看了结果（后面的句子反正也会被拒），补上「只派了一次」的断言。	2026-10-05 14:00:59 +08:00
ThearchyHelios	fe2f81c1c0	助手的节点手册加反方审稿：多个来源汇总的分析报告、要正式出具的报告加这个节点，接在报告之后 ... 写清什么时候加、接在哪里（report → challenge → human 或 output，审批节点的说明里引用报告正文才会附上审稿结果）、 各配置项（要审的报告、三个上限、反方模型、结论被推翻时怎么办、启用）和默认：上限一般不写、取设置里的默认，不替人 把核查的花费写死；反方模型建议和写作模型不同。测试拿画布校验认的配置项和取值来对手册	2026-10-05 13:57:49 +08:00
ThearchyHelios	dc5a113e29	反方审稿节点（后端）：报告写完后挑几句关键结论，各派一个只读 agent 站在反方写查询找反例，被推翻的让出具降档 ... 结论句裁判只看写作者挂的证据，可证据本身就可能挑过（只查了含退款的销售额）。反方审稿换个方向，自己查库去证伪： - 选句照裁判的预筛（judge.candidates）：挂了依据的、带比较或因果的在前，取前「最多审几句」句，裁判判成不是结论的不审 - 每句一个核查 agent（verify_agent.run_verify_agent）：工具只给这句引用的查询所在的数据源（指标按输入取自的查询、合并查询 按它合并的源算；没挂依据的在整份报告引用的源里查）；任务给这句结论和它挂的证据摘录（judge.prepare，遮罩照旧，编号改成 「原报告 Qn」免得和 agent 自己的 Q1 混淆）；理由里的数字只能引用自己的查询格子，裸数字被标出 - 审稿记录 challenge_artifact 按约定的形状随运行封存；台账只记 kind challenge，查询不进任何报告的写作目录 - on_refuted：degrade（默认）写 issuance_gaps 让出具降档，fail 判节点失败，flag 只记录；产出带实际的 on_refuted - 上限：句数、每句查询数、每句时长、全局每日金额，都按发起时快照的核查设置（run.options["verify"]，没有快照按设置当前值）， 节点上写了的盖过它；全局关闭、报告没有可审的结论句、报告文档读不到时直通并记 challenge_skipped - 日志按约定的 code 带结构化字段：challenge_skipped / challenge_same_model / challenge_limit / challenge_done / challenge_refuted - 整个反查（连同存记录、发日志）放在一个 @task 里：接着跑时不重复查库、不重复记账、时间线不重发 - 审批卡：human 的 _reviewed_reports 给被审的报告附上 challenge 概况（counts、最多 10 条 items、artifact、on_refuted）， 没审过就不加这个键 - 画布校验：要审的报告必须是上游的报告撰写节点（不写时取直接连着的那份或上游唯一的一份，多份要人选）；各项配置写错报中文、 执行时报同一句；反方模型和写作模型写成同一个给警告 - 占位期的直通测试只留双盲复算（反方审稿的直通行为改由 test_challenge_node.py 覆盖）	2026-10-05 13:57:38 +08:00
ThearchyHelios	4d29b67cef	双盲复算前端（一）：时间线解读双盲复算和反方审稿的全部日志代码，补类型和文案 ... - decode.ts：约定里的 12 个日志代码（dual_check_* 7 个、challenge_* 5 个）按 code 和结构化字段说成标题、副标题和下一步， 不从原话里认；后端发成 info 的（一致、裁决、记入数据目录、审稿完成）也上时间线，否则这两种节点在时间线上什么都不说； 有缺口、有推翻时用提醒色，完整对照和审稿记录的工件可下钻；老日志缺字段、类型不对时不崩、不瞎填数 - check-decode：每个代码一条断言，另有换一种取值和缺字段两组 - types.ts 末尾加双盲复算的审批 payload、对照工件、节点配置和设置里核查一组的类型 - terms.ts：DUAL_CHECK_TEXT 写全检查器、节点摘要、审批卡、时间线的文案（反方审稿日志的说法暂放 challengeLog）； VERIFY_SETTING_TEXT 顶层和服务端 VERIFY_SETTING_LABEL 的键和叫法一字不差，其余放 section - 去掉双盲复算节点说明里的「功能开发中」和节点卡片上的占位摘要	2026-10-05 13:54:45 +08:00
ThearchyHelios	36848f0a1e	运行对比加固（第 1 轮）：一个维度值占几行时按维度值数两边各引用了几行，有一部分挤出引用的行也判说不清；单格引用的快照读不出来时和行段一样说不清；补循环回边、写入者不知道时的措辞、严格拆分的范围、单边遮罩四处测试 ... - 区域 × 日期这类结果（日期不当维度），东区多了一天把南区的第二天挤到引用的行外面、仍在快照里：原来只记每个维度键在引用的行里外各自第一次出现的位置，两边都引用过南区就查不出，报成只数据变、南区少了一半；现在某个键在一边引用的行更少、那一边快照里引用的行外面还有它的行，判说不清，说明写「南区这次有 1 行在查询结果第 5 行，不在引用的行里」，两个方向都查；真的少了一天的照常是数据变化、占比之和为 1 - 遮罩列仍不当维度：只用没遮的列认，说明里只写没遮的列的值和行号；整个挪出去的维度值列出全部行号（最多 3 个，多的写「等」） - 单格（数组元素）引用、一边快照读不出来时原来退回按行号认、报成只数据变，现在和行段一样说不清，说清是哪一边 - 新测试：循环回边上的节点算口径卡之前、写入者不知道时并行支路只说「节点」且不说「它的上游节点」、严格拆分不被口径卡自己和下游挡住、只有一边遮了区域列（两个方向）时说明、归因、整体说明里都不出现区域名	2026-10-05 13:14:41 +08:00
ThearchyHelios	e626b205b6	合入 SQL 差异说明重做（阶段性）：先判等价再说差在哪——规范形式一字不差才算等价，具体说法只说有把握的，其余给兜底并附规范化后不同的行；等价结论用执行比对守住	2026-10-05 12:58:42 +08:00
ThearchyHelios	8ed74bbe97	合入期 2 变化三分法（前端）：运行对比页（摘要、指标表、效应拆分、维度归因、查询与模板差异），运行详情加「与上一次对比」 ... # Conflicts: # frontend/src/types.ts # scripts/check-all.mjs	2026-10-05 12:50:04 +08:00
ThearchyHelios	77b5509cf1	合入期 2 变化三分法（后端）：同一工作流两次运行的指标变化拆成数据、口径、模板与 SQL，口径与数据都变时能严格拆分两种效应，数据变化按维度归因，每项追到两边的查询快照；基准优先取同一定时任务的上一次	2026-10-05 12:49:30 +08:00
ThearchyHelios	190b36ad91	合入期 2 定时任务（前端）：定时任务列表、创建编辑（频率预设、实时预览、输入模板变量、Webhook 设置与测试）、触发历史，运行列表标出定时来源	2026-10-05 12:49:19 +08:00
ThearchyHelios	b6b5229f2a	合入期 2 定时任务（后端）：自写五字段 cron（夏令时、日周取或、中文描述与报错）、输入模板变量按触发时刻算、15 秒一拍的调度循环（条件认领、重叠跳过、宽限内补一次）、Webhook 推送（通用 / 飞书 / 企业微信 / 钉钉，签名、重试、日志脱敏）、定时任务接口与通知设置	2026-10-05 12:49:19 +08:00
ThearchyHelios	36569e1fa4	运行对比复核修正（第 3 轮）：行号相同的引用还要引用同一批维度值，记不出写入者时只看口径卡之前的节点，默认设置的登记按节点类型逐类核对 ... - Agent 两次引用的行号相同、都不是整份结果时，一边引用了的维度值（区域……）在另一边的快照里却没被引用（按区域排序多了北区、按金额取前 3 名名次变了），判为说不清，说明写出是哪个维度值、在第几行；不再把还在快照里的区域算成「数据没了」、给出远超 100% 的占比。另一边快照里真的没有了的照常是数据变化。数组字段里的单个元素同样核对。维度按两边整份结果认，遮罩列不拿来认，分不出维度的仍按行号认 - 两边都记不出写入者时，范围从整张图改为口径卡之前可能执行过的节点（它的上游加并行支路）：口径卡自己、只在它下游的写周报写不了它读到的值，不再被点名成来源；并行支路上的节点不说成「上游」 - 「整份结果」统一按引用了哪几行判断，容器一支不再单列 - 默认设置登记表的核对测试改为按节点类型：从各执行器出发顺着用到的函数（含就地 import、回调、类）找 cfg 读法，在字面量元组上循环读的键名认得出，认不出的变量键名直接失败；核对节点模块里每个读配置的函数都走到了，登记了不读的也算错。据此补登记成果节点出具契约读的报告节点三项（evidence_from、metrics_from、entities） - 补测试守住上一轮的几条规则：Agent 交的不同而代码节点的数没变是没变，只有这次运行的快照读不出来时说这次，默认设置同时改了结论句裁判时 Agent 只写模型，调不调模型由默认设置决定，报告节点在代码节点上游，改了几个节点时点名画布上靠前的	2026-10-05 12:28:38 +08:00
ThearchyHelios	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
ThearchyHelios	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
ThearchyHelios	3254744f6d	运行对比复核修正（第 2 轮）：行段相同、一边是整份结果的引用不再算同一处，默认设置的变化只落到会读它的节点上，上游 Agent 交出的结果不同时不再说变化来自上游数据 ... - Agent 两次引用同一段行，一边是整份结果、一边不是（这次多了北区，没引用的西区还在快照里）：判为无法比较，写明哪边引用了整份结果、另一边引用了哪几行、结果共几行；快照读不出来、核对不了是不是整份结果的同样不算同一处。以前按同一处算，西区被算成「数据没了」，占比超过 100% - 图级默认设置的变化按「哪类节点运行时会读这一项」落到节点上（_CFG_KEYS，照各执行器经 NodeContext.cfg 读的配置项登记）：结论句裁判、结论句的处理只有报告节点读，不再把 Agent 记成配置变了；条件分支让模型分类、结构校验让模型修复、知识检索用模型重排时也读默认模型，同样落到它们身上。新测试按执行器源码核对这张表，执行器新读了一项没登记就失败 - 代码、数据整形这类节点的上游有 Agent、模型调用、人工审批等节点，两次交出的产出不同（工件按内容寻址，按工件 id 比；产出没落成工件的核对不了）：它交的数变了不再说变化来自上游数据，判为无法比较并点名是哪个节点 - 上游节点改了配置时说明里点名是哪个节点；默认设置那句拆短，写出跟着变的是哪几项（模型接入不写 provider） - 补测试守住复核列出的未覆盖规则：容器运行输入还原不了、合并查询的输入追不下去、上游只有运行输入变了、审批默认设置、图里 SQL 只改格式（代码节点在下游）、跨节点先配字面量相同的、少了一次查询、只有一边落在快照上、查过库的写入节点改了配置、代码节点上游有节点改了配置、旧口径叶子的出处说不清时不拆、单格引用换了行；变异 99 处全部打红	2026-10-05 11:28:41 +08:00