ThearchyHelios d529e5f694 算子的叫法只留契约一份：contract.OP_LABELS / MODE_LABELS 是唯一来源，趋势定为「趋势判断」；engine/labels 的 ANALYSIS_OP_LABEL 直接引用 OP_LABELS、ANALYSIS_MODE_LABEL 按 MODES 从 MODE_LABELS 分到各算子（分析卡校验、应用说明、前端表单照它），phrases 去掉 OP_NAMES，「{叫法}没有做成」的判定语和算子的调用错误都用契约的叫法

2026-10-21 14:08:56 +08:00

..

nodes

合入 W1-d 说法核对：说法表与绑定、check / strict / off、出口独立复核与文档版本、分析范围、血缘口子、G3

2026-10-21 14:00:07 +08:00

__init__.py

…

analysis_claims.py

说法核对接上证据接入（W1-b）和真算子（W1-a）：一句的分析依据按引用的编号认（A 开头、目录条目 kind analysis），判定语 [[a:A1]]、具名标量 [[a:A1.键]] 整段不扫，[[see:A1]]、[[see:A1.r0]]、[[see:a:A1]] 都当依据；目录条目只带摘要的（存进文档的那份）复核时按工件取回整份结论（_Snapshots.analysis）。算子、模式的叫法从契约取（OP_LABELS、method_label）。比率拆解的结构为主、各段自身为主（判定语就说「主要来自…」）也能挂来源类判断；ASCII 的段名认整词时，挨着的汉字不算连着。去掉测试里代为解析 [[see:A…]] 的替身；新增挂真算子结论的绑定测试：可加拆解的主要来源与拖累带动、分散、持平带抵消、比率拆解的结构变化、乘积拆解的因子、波动基线的方向和新高新低与正常波动、趋势的方向和连续期数、差异检验两组的先后、算不了的基线，以及经组装和复核时判定语、具名标量不扫

2026-10-21 13:29:23 +08:00

analysis_scope.py

报告文档里系统写的「分析范围」（engine/analysis_scope，契约 ScopeBlock）：按写作目录里的 A 条目照实写现象（可比性、基线、趋势）、拆过（按下钻链，上一层在前）、排除（分散的拆解、差异可能只是样本波动的检验）、算不了（带原因）、检验次数；agent 写的假设不进这一段。没拆的候选维度确定地从数据目录算：拆解所用查询 SQL 里的事实表（目录标了 fact / log，没标且只读一张表时就是它）上标成属性、状态、不遮罩（数据源设置和查询当时记下的遮罩列）、取值不多（码值表不超过 50 个取值或已列全）的列，加上关联的维度表（标了 dimension 或多对一）上同样的列；拆解按的列对不上目录、读不到目录、源还没有目录、取不回查询、认不出事实表的，not_decomposed 为 None、note 照实写核对不了。目录经这次运行的目录视图读（data/catalog_view，关掉的当核对不了），出错不挡报告。契约的 ScopeBlock 加一项 corrected（检验之间有没有校正：只做一次为 true、不止一次为 false、没做为 None）

2026-10-21 13:12:05 +08:00

approval.py

驳回不再记成失败（后端）：人的驳回收成 cancelled + end_reason=rejected，消费方都读这一个字段

2026-10-16 10:14:27 +08:00

autofix.py

门禁 G3 加一条：受管级别的报告撰写节点要把「分析说法核对」设为严格（REPORT_POLICY 加 analysis_claims: strict，没写时运行时是 check、只标注）。受管级别挡住发布、已发布级别只警告，写错的值交给校验；已经发布的版本照常运行（按缺省的 check 核），下次发布才按新规则查。同一份要求自动跟到自动修复（一键写明）、一键升级成受管、按口径出具起草的报告节点；自动修复「不许放宽」的判断认这一项（从严格改回去算放宽）；白话补一句分析说法；模板 ⑨ 的报告节点补上这一项，拿来照旧能发布成受管。各处「受管要求都满足」的图（测试夹具）跟着补上这一项

2026-10-21 13:13:04 +08:00

cell_format.py

报告里标识列的数不分千位（产线编码 1203 不再写成「1,203」）：新增 engine/cell_format.plain_columns，按序看查询当时冻结的数据目录给源列标的度量类型（identifier / status / attribute 不分，flow / stock / ratio 分）、源列名像编码编号（CODE、ID、NO 整词或结尾、驼峰的 Id/No/Code、编码、编号、代码）、是分组键（列、别名、序号都认）而不是聚合；SUM、COUNT、AVG 这类聚合是量，MIN、MAX 按那一列判；判断不了的照旧分千位。只看查询快照和它指向的表结构快照（内容寻址），组装、流式渲染、写作目录、出口复核一致。单元格显示规则 3 版：真有格子因此改了写法的文档记 cell_display: 3、引用上记 plain；离线核对页认 3 版、照 plain 渲染（解析不了 SQL），老文档按记下的版本复核照旧分千位。样本里订单号（order_no）随之不分组，check-bundle 跟着改

2026-10-19 17:55:02 +08:00

checkpoints.py

copy-to-postgres 在真实开发数据上核对不过的几处（复核 R-a1、R-a2、R-a3、R-a8、R-a13）

2026-10-19 12:06:31 +08:00

compare.py

合入 W1-d 说法核对：说法表与绑定、check / strict / off、出口独立复核与文档版本、分析范围、血缘口子、G3

2026-10-21 14:00:07 +08:00

compiler.py

分析能力入口（三）：分析卡（节点类型 analysis，和口径卡平级，engine/nodes/analysis.py）。配置 items: [{id, op, mode, from, params, hypothesis}] 和阈值覆盖 overrides；画图时校验（schema.analysis_issues，执行前同一套再过一遍）：至少一项、标识合法且不重复、分析方法和模式是契约里的、输入（from，或两份查询的 base_query / target_query，总数两格落在的节点）指向上游的调用工具 / 合并查询节点（Agent、不产出查询的节点、不在上游的报错，调用别的工具的只提醒）、参数和 agent 工具同一份定义且不能写阈值、下钻指向同卡排在前面的变化拆解、阈值覆盖按 contract.settings_problem。执行照合并查询的做法从 state.nodes 取上游的查询快照 id、复验哈希，只认台账里 kind query 的快照，遮罩列同证据面板；参数里的 {{ }} 先渲染；阈值是缺省 ← 发起时的快照 ← 卡上的覆盖；每项的结论落成工件、台账记一条带 item 的 kind analysis、发一条 analysis.end；产出 nodes.<卡>.results.<项> = {status, verdict, direction, values, phrase, artifact}，条件分支能按判定走、成果能取判定语。一项算不了照实记（analysis_refused），不让卡失败；调用写错让卡失败并说清是哪一项、怎么改。登记：事件 analysis.end、叫法「分析卡」「分析项」「阈值覆盖」和分析方法、模式的叫法，编译器，治理（分析卡算可追溯的节点；受管级别分析卡的输入要是数据库查询或合并查询 governed.analysis_input，画布那条同义的提醒不再重复列；口径卡读分析卡的结果给提示 governed.caliber_analysis_input，输入按 via analysis 记、追不到原始数据），升级提醒的证据类节点，变量表（每项的结论、对上游节点的引用），数据目录影响面（同合并查询经由输入），助手查看的工作流说明，两条新编号的白话

2026-10-21 13:03:00 +08:00

context.py

子工作流里的写入跨升级认旧键时按事件和内容认是谁的、是哪一笔（复核 L1、L2）：升级前子图里的写入按子图里的 id 记键，和父图同名节点的键一样。以前父图有同名节点时一律不认旧键：子图里结果未知的那一笔核实为已生效后接着跑，用新键又发一笔；父图那个节点按自己的键找到子图那一笔、交回它的回执，自己那笔一直发不出去。现在一条记录是哪个节点写的按它的 action.* 事件上记的节点 id 认（认不出的按能力和内容指纹）：按自己的键找到别人那一笔的换一个只属于自己的键；认旧键时还要内容指纹是这一次的——跨升级的循环第二轮按老算法同样是第 1 次执行，找到的是第一轮那一笔，金额不同就照常发，不再记「已经生效」。去掉不再用的最外层节点 id 传递；改对两处过时的说明（审批恢复时子图从自己的断点接着跑；终态事件的途经驳回含子工作流里的）。补跨版本测试：同一个进程里先装成升级前的代码跑到挂起、再换回现在的代码接着跑

2026-10-19 11:43:41 +08:00

deadline.py

…

direct_select.py

…

dual_check_facts.py

…

evidence.py

合入 W1-d 说法核对：说法表与绑定、check / strict / off、出口独立复核与文档版本、分析范围、血缘口子、G3

2026-10-21 14:00:07 +08:00

expressions.py

普通用户建应用（后端）：

2026-10-15 12:09:29 +08:00

governance.py

合入 W1-d 说法核对：说法表与绑定、check / strict / off、出口独立复核与文档版本、分析范围、血缘口子、G3

2026-10-21 14:00:07 +08:00

guards.py

…

inquiry.py

普通用户建应用（后端）：

2026-10-15 12:09:29 +08:00

issuance.py

口径卡、报告、出具、复核认「查询区间里这张表没有数据」：口径卡按输入的快照 id + 列认（cell()、按位置取的格、Agent 经 cite_fields 交来的字段，按列，同一条查询里有数的列不受影响；转抄的指标照抄），给指标标 no_data 并写明原因，清单注明「这段时间表里没有数据：不要当成 0 解读」，发一条 metric_no_data；有出具契约的成果按缺口降档（契约收来的指标，和报告直接引用的这样的格）。写作目录里这样的指标、查询格子里这样的列都写清，写作规则加一句（目录里有这样的项才加）。证据面板的指标标「区间内无数据」并写明原因，查询步骤列出这几列。复核把 query_no_data、metric_no_data 记成缺口（DEGRADED），归进新的 REBUILD：是缺口、却值得换一张有这段数据的表重建一次，should_retry 和 chat/turn.retry_after_review 都认，问数据据此给出「按复核重来」的指示

2026-10-20 10:29:01 +08:00

judge.py

证据接入按 W1-a、W1-c 的实际接口对齐：复算就是真的 app.analysis.recompute——load 交查询快照工件的原内容、load_result 交上一层结论（只认封存范围内交回过的查询、台账记过的结论，取不回照实说取不回哪一份），方法升没升版按结论里的 method 和现在的 contract.METHODS 比（升了版、复算成立的写结果同不同，现在的方法复算不了的写明原因），去掉为算子没落地准备的那一套；关键数的代入式按真的具名的数写（乘积拆解补上，波动基线按变化率比的按百分比写，负数加括号）。口径卡指标上的可比性结论（不进台账、只从卡上引用）点得开：证据面板的指标步骤带它整条出处链（判定 → 方法 → 计算 → 输入 → 复算 → 封存，封存按卡上记的 sha256 认），报告导出收在一个可展开的块里，可验证报告随附带的卡一起附上、④ 按已核对的卡认它、数字详情里展示各项检查和服务端复算；裁判的指标摘录、写作目录照卡上记的判定语写。现查结果分清按运行当天现算的界、一列一个值都没有、表的范围；可验证报告里分析工具的 tool.end、分析卡的 analysis.end 和结论同一个认法才带内容，输入的角色写叫法。测试改用真算的结论（run 交的输入照分析入口的写法，复算交工件原内容），下钻、总数闭合、方法升版、可比性端到端都过真的复算

2026-10-21 13:49:09 +08:00

labels.py

算子的叫法只留契约一份：contract.OP_LABELS / MODE_LABELS 是唯一来源，趋势定为「趋势判断」；engine/labels 的 ANALYSIS_OP_LABEL 直接引用 OP_LABELS、ANALYSIS_MODE_LABEL 按 MODES 从 MODE_LABELS 分到各算子（分析卡校验、应用说明、前端表单照它），phrases 去掉 OP_NAMES，「{叫法}没有做成」的判定语和算子的调用错误都用契约的叫法

2026-10-21 14:08:56 +08:00

launch.py

分析能力入口（四）：发起运行时把分析设置快照进 run.options["analysis"]（engine/launch.py 的 _with_analysis_snapshot，照核查设置的 _with_verify_snapshot）：只在图（含一层层套着的子工作流，同一个工作流的同一版只读一次）里有分析卡、或 Agent / 协作成员（节点上没写就取图级 defaults）绑了任一分析工具时写，调用方已经给了这一组的照它的；别的图 options 原样不动，run.started 一字不变。runner 本来就把整份运行选项放进 RunContext.extra，分析工具、分析卡、口径卡的可比性检查都只读这一份，没有快照的现读设置。子工作流的遍历抽成 _any_graph，核查设置的判断照旧

2026-10-21 13:03:23 +08:00

layout.py

驳回出口（后端）：审批、补充输入、编辑稿件、动作确认、代码和工具审批、双盲裁决接了「驳回」出口时沿它往下走

2026-10-18 15:56:29 +08:00

lineage.py

复核修正（后端）：子图里的报告不再被判「疑似被修改」、驳回出口的双盲裁决照样降档、可验证报告与推演按卡所在的层找产出、子图那一步写名字

2026-10-18 18:15:37 +08:00

lint_capabilities.py

…

lint_process.py

子工作流的证据交回父图（后端）：子图每一步进同一个运行、台账和口径卡交回、出口字段带出处、父图跨子图往下追

2026-10-18 16:11:15 +08:00

masking.py

…

merge_query.py

…

origin.py

系统派生的运行不进使用统计（总方案 X1、X2，细案 01 做法 4）：评测一跑，聚类、白名单、目录使用热度都会被刷高

2026-10-16 10:18:12 +08:00

provider_refs.py

…

recompute.py

口径卡分母为 0 时算不出来就是空值，和「缺少输入」分开说；指标清单按格式渲染。助手节点手册讲口径卡的那段写明分母可能为 0 时写「… if 分母 else None」、不要写 else 0，附示例；画布校验加一条提醒 metrics.zero_for_undefined（按语法树认：条件表达式一边有除法、另一边是常量 0，两边对调、套在 round 里、嵌套的都认）。输入都齐、计算式自己交回空值的指标多记 undefined: true（状态仍是 missing_input，按状态认的地方和老运行不受影响），清单、写作目录、引用解析不了的原因、运行对比、证据面板都说「算不出来（这组输入下计算式没有值，比如分母为 0）」；推演把它当不带值的字段。指标清单（{{ nodes.卡.text }}）改用卡上渲染好的 rendered：比率 0.0007 显示成 0.07%、金额带千分位，和报告里 [[m:]] 一致；有值却显示不出来的照实说，不拼原值

2026-10-20 10:04:53 +08:00

replay.py

驳回出口之后，待办、通知、Webhook 照实说转到哪：中断内容带上驳回之后去哪（engine/replay.reject_route：接了驳回出口写转到哪几步，没接的写运行就此结束，审批没接、没设驳回即终止的写这一路到此为止），待办卡的提示、驳回按钮、驳回后的提示、处理过的「结果」照它说，不再一律写「转入驳回分支」「本次运行终止」；超时驳回不再露出英文结论码；双盲裁决、动作确认被驳回的提示同样照它说。子工作流里的关卡走驳回出口时，名字记成「子工作流 › x」（RunContext.global_label），走过的那几步交回父图的 trail，父运行的终态事件照实带上途经驳回，实例页、通知写「「子工作流 › 把关」被驳回，转到「子工作流 › 退回」」，不写内部 id、不写成已完成。定时任务的 Webhook：照驳回那条路成功结束的，标题、状态写途经驳回，另起一行写谁被驳回、转到哪一步

2026-10-19 08:59:15 +08:00

review.py

口径卡、报告、出具、复核认「查询区间里这张表没有数据」：口径卡按输入的快照 id + 列认（cell()、按位置取的格、Agent 经 cite_fields 交来的字段，按列，同一条查询里有数的列不受影响；转抄的指标照抄），给指标标 no_data 并写明原因，清单注明「这段时间表里没有数据：不要当成 0 解读」，发一条 metric_no_data；有出具契约的成果按缺口降档（契约收来的指标，和报告直接引用的这样的格）。写作目录里这样的指标、查询格子里这样的列都写清，写作规则加一句（目录里有这样的项才加）。证据面板的指标标「区间内无数据」并写明原因，查询步骤列出这几列。复核把 query_no_data、metric_no_data 记成缺口（DEGRADED），归进新的 REBUILD：是缺口、却值得换一张有这段数据的表重建一次，should_retry 和 chat/turn.retry_after_review 都认，问数据据此给出「按复核重来」的指示

2026-10-20 10:29:01 +08:00

run_append.py

…

runner.py

复核 R-b15（隔离后等不到重新登记的运行原因记错、任务没摘）：_drive 里 fence.ready() 等不到时照实收尾——排队中的（一步都没执行过）收成失败，写明「本进程隔离后没能重新登记，这次运行没有开始执行」并记 run.failed；要接着执行的（继续、批了审批）收成中断、断点完好可继续运行；条件更新，状态、属主变了（别的进程先接手）就不动；执行任务从 run_manager._tasks 里摘掉。补测试：隔离后新身份一直没登记上，新发起的运行收成失败、原因写对、run.failed 记下、任务摘掉

2026-10-19 15:08:39 +08:00

schema.py

合入 W1-d 说法核对：说法表与绑定、check / strict / off、出口独立复核与文档版本、分析范围、血缘口子、G3

2026-10-21 14:00:07 +08:00

spend.py

合入 W2-a 的复核修复（nr8/a：导入的 NOT NULL 补值与孤儿行、收尾 dispose、sslmode 换算、PostgreSQL 写入去 NUL、不分大小写搜索 contains_ci、json_eq 两库同语义、JSON 守卫、用户可见列表补决胜键、bubblewrap --clearenv、部署脚本与原子写的几处、README 连接数预算）

2026-10-19 12:21:38 +08:00

sql_problems.py

分析结论进证据链（引擎）：台账 kind analysis 的条目在写作目录里按台账先后编 A1、A2……（只收报告祖先里的，报告节点的「证据来自」按做它的节点过滤），条目照 catalog_result 的约定带着从工件取回、复验过哈希的整份结论，取不回、哈希不符的记明原因；存进报告文档的目录只留摘要，整份结论按工件取回。引用：[[a:A3]] 渲染判定语（一个片段，种类 analysis，整段涂白、不算裸数字），[[a:A3.键|换算]] 渲染具名标量（换算同指标），[[v:A3.r0.列]]、[[table:A3 …]] 取结果表（表头写结果表的列名，表头里的数不算裸数字），[[see:A3]]、[[see:A3.r0]] 当依据；写错的编号、键、越界的行、判定语加换算都照实说为什么。受管级别的正式出具、契约没开「单元格引用」时，Agent 现场做的分析和它查的格同一个规矩，分析卡做的照常引用。写作目录加「分析结论」一段（判定语、判定标准、具名的数、结果表前 table_top_k 段与其余几段、附带说明、算不了的原因、来自哪几个 Q、下钻自哪个 A、输入查询的 SQL 检查问题，外加引用写法一句），放不下时判定和具名的数一律列出、结果表排在查询的行前面补、最后才退；口径卡指标上的可比性（有条件可比、不可比）照实写出原因。SQL 问题顺着分析结论的输入往下找。另有复算（analysis_recheck：算子没落地、调用写错、出意外都照实写「复算失败：原因」，方法升版写明前后两版）、复算用的输入快照、关键数的代入式，证据面板、导出、可验证报告共用

2026-10-21 13:07:36 +08:00

state.py

…

tolerance.py

评测执行的主干：后台评测、无头作答、评分、统计、对比与 A/B、清理（下一轮第 3 波 W3-c 第一段）

2026-10-16 16:38:09 +08:00

toolcalls.py

助手把操作写成工具调用格式时照操作读；一个能落地的操作都没有时当场纠正一次；报错按诊断照实说

2026-10-19 22:48:23 +08:00

upgrade.py

分析能力入口（三）：分析卡（节点类型 analysis，和口径卡平级，engine/nodes/analysis.py）。配置 items: [{id, op, mode, from, params, hypothesis}] 和阈值覆盖 overrides；画图时校验（schema.analysis_issues，执行前同一套再过一遍）：至少一项、标识合法且不重复、分析方法和模式是契约里的、输入（from，或两份查询的 base_query / target_query，总数两格落在的节点）指向上游的调用工具 / 合并查询节点（Agent、不产出查询的节点、不在上游的报错，调用别的工具的只提醒）、参数和 agent 工具同一份定义且不能写阈值、下钻指向同卡排在前面的变化拆解、阈值覆盖按 contract.settings_problem。执行照合并查询的做法从 state.nodes 取上游的查询快照 id、复验哈希，只认台账里 kind query 的快照，遮罩列同证据面板；参数里的 {{ }} 先渲染；阈值是缺省 ← 发起时的快照 ← 卡上的覆盖；每项的结论落成工件、台账记一条带 item 的 kind analysis、发一条 analysis.end；产出 nodes.<卡>.results.<项> = {status, verdict, direction, values, phrase, artifact}，条件分支能按判定走、成果能取判定语。一项算不了照实记（analysis_refused），不让卡失败；调用写错让卡失败并说清是哪一项、怎么改。登记：事件 analysis.end、叫法「分析卡」「分析项」「阈值覆盖」和分析方法、模式的叫法，编译器，治理（分析卡算可追溯的节点；受管级别分析卡的输入要是数据库查询或合并查询 governed.analysis_input，画布那条同义的提醒不再重复列；口径卡读分析卡的结果给提示 governed.caliber_analysis_input，输入按 via analysis 记、追不到原始数据），升级提醒的证据类节点，变量表（每项的结论、对上游节点的引用），数据目录影响面（同合并查询经由输入），助手查看的工作流说明，两条新编号的白话

2026-10-21 13:03:00 +08:00

variables.py

分析能力入口（三）：分析卡（节点类型 analysis，和口径卡平级，engine/nodes/analysis.py）。配置 items: [{id, op, mode, from, params, hypothesis}] 和阈值覆盖 overrides；画图时校验（schema.analysis_issues，执行前同一套再过一遍）：至少一项、标识合法且不重复、分析方法和模式是契约里的、输入（from，或两份查询的 base_query / target_query，总数两格落在的节点）指向上游的调用工具 / 合并查询节点（Agent、不产出查询的节点、不在上游的报错，调用别的工具的只提醒）、参数和 agent 工具同一份定义且不能写阈值、下钻指向同卡排在前面的变化拆解、阈值覆盖按 contract.settings_problem。执行照合并查询的做法从 state.nodes 取上游的查询快照 id、复验哈希，只认台账里 kind query 的快照，遮罩列同证据面板；参数里的 {{ }} 先渲染；阈值是缺省 ← 发起时的快照 ← 卡上的覆盖；每项的结论落成工件、台账记一条带 item 的 kind analysis、发一条 analysis.end；产出 nodes.<卡>.results.<项> = {status, verdict, direction, values, phrase, artifact}，条件分支能按判定走、成果能取判定语。一项算不了照实记（analysis_refused），不让卡失败；调用写错让卡失败并说清是哪一项、怎么改。登记：事件 analysis.end、叫法「分析卡」「分析项」「阈值覆盖」和分析方法、模式的叫法，编译器，治理（分析卡算可追溯的节点；受管级别分析卡的输入要是数据库查询或合并查询 governed.analysis_input，画布那条同义的提醒不再重复列；口径卡读分析卡的结果给提示 governed.caliber_analysis_input，输入按 via analysis 记、追不到原始数据），升级提醒的证据类节点，变量表（每项的结论、对上游节点的引用），数据目录影响面（同合并查询经由输入），助手查看的工作流说明，两条新编号的白话

2026-10-21 13:03:00 +08:00

verify_agent.py

目录视图接缝 data/catalog_view.py（细案 01 做法 5，总方案 X7）：读目录的四处统一经它，「开目录 / 关目录 / 只用已核实的项 / 目录快照」的对照才做得了

2026-10-16 10:28:01 +08:00