ThearchyHelios 078c2c4d97 评测的模块说明补分析期望：judgements.py 管什么、有分析期望的题集开评时拍一份分析设置（算期望、作答都按它，记进指纹，别的题集不拍）

2026-10-21 18:23:57 +08:00

..

analysis

叫法消毒按词认判断词（scan bare）：说法核对修复后 scan 缺省按整句规矩认（没说变化的「主要来自」不算判断），叫法是一个名字不是一句话，「主要来自华东的销售额」这样的叫法要整个不要

2026-10-21 17:12:48 +08:00

api

合入复核修复（证据接入与入口）：跨段指标不当两期查、证据接口重渲染与组装同一个函数、一次请求同一份结论只复算一次、比率闭合核对、代入式按点名的段、写作目录分析段限额、核对页写方法叫法、运行对比只认做完的执行、读快照进线程、四个工具与合并查询的真算子测试、夹具清源

2026-10-21 16:58:45 +08:00

apps

分析能力入口（三）：分析卡（节点类型 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

auth

分析能力入口（二）：五个 agent 分析工具（analysis_decompose / baseline / trend / differ / comparable，名字取 contract.TOOL_NAMES），参数只有「算什么」（引用本节点查过的结果 Q3、列的角色、期次、总数 headline、下钻 parent、度量叫法、在验证什么），没有阈值参数；五个工具共用一份「分析方法」说明（ToolSpec 新增 guide：方法说明 + 去重用的 id，register / build_tools 透传进工具的 metadata），Agent 节点、协作成员绑了任一分析工具就接在 Skill 后面注入 system，同一份只注入一次，模型调用节点不注入。Agent 建工具时经 ToolContext.extra 交一个本节点的分析容器（app/tools/analysis.py 的 AnalysisScope），每次查询记台账时往里放一份输入快照（编号和「【证据 Qn】」同一个），分析结论落成 analysis_result 工件、台账记 contract.ledger_entry（带 call_id），交回模型「【分析 An】」加判定语、判定标准、关键数、附带说明、算不了的原因、结果表前几段；tool.end 带 analysis_artifact；下钻按 An 取本节点的结论；调用写错（contract.CallError，含这个节点的分析次数用完 max_calls）作为工具错误交回、不记台账、不占编号；算不了照样记结论并发一条 analysis_refused。编号只在记台账时放进容器，审批恢复重放时分析不再执行、编号不错位。遮罩列按证据面板同一个函数认（数据源设的、按 SQL 认出改了名字的），遮罩运行交给算子的是遮过的快照。阈值读发起时的快照，没有就现读设置；运行期依赖给运行当天、按运行目录视图读的目录、剖析事实、现查表范围的探查（W1-a 的 make_prober，还没有时不给）。协作成员同样注入方法、同样编号（协作节点不记台账）。使用者问数据的白名单加上五个分析工具和分析卡；调用工具节点调分析工具在画布上就报错（analysis.tool_node）。能力登记不把它们当查询（is_platform_query 不认）

2026-10-21 13:02:30 +08:00

blueprints

…

bundle

可验证报告的核对页给分析结论的方法写上中文叫法：服务端在随文件附带的分析结论条目上带 method_label（contract.method_label，和导出页同一份），verifier.js 的数字详情、指标上的可比性两处「方法与版本」照导出页写「变化拆解（可加） · decompose.additive@1」，页面只显示、不另起叫法；条目上没带叫法的只写 id。以前只显示方法 id。测试：分析结论、口径卡指标上的可比性两种条目都带叫法

2026-10-21 15:49:06 +08:00

capabilities

…

chat

口径卡、报告、出具、复核认「查询区间里这张表没有数据」：口径卡按输入的快照 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

cluster

文档重新梳理：README 精简成介绍和索引，细节按主题拆进 docs/zh-CN 与 docs/en（17 篇一一对应），英文文档不含中文

2026-10-21 10:23:26 +08:00

core

分析能力入口（三）：分析卡（节点类型 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

data

Merge branch 'an/w1' into an1/c

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

db

文档重新梳理：README 精简成介绍和索引，细节按主题拆进 docs/zh-CN 与 docs/en（17 篇一一对应），英文文档不含中文

2026-10-21 10:23:26 +08:00

engine

合入复核修复（说法核对）：结论句判定回到原来的词表（扩充的判断词只给裁判排先后）、表格正文不核、补因果与来源的口子、说法表按样本调整（96 句样本表）、连续按末尾方向核、复核认三种日志且只写说明、分析结论算可引用的来源、自动修复对认不出的取值照 claims 做、候选维度写明只认码值表、scan 加只按词认

2026-10-21 17:12:18 +08:00

eval

评测的模块说明补分析期望：judgements.py 管什么、有分析期望的题集开评时拍一份分析设置（算期望、作答都按它，记进指纹，别的题集不拍）

2026-10-21 18:23:57 +08:00

files

…

ledger

结论句裁判与口径账本认分析结论：引用了分析结论的句子，裁判摘录里给方法与版本、判定语、判定标准、关键数、附带说明、结果表（被引用的行先给）、输入取自哪几个 Q 用了哪几列和它们的 SQL、下钻自哪个 A（核查 agent 的摘录照旧分段遮）；摘录里有分析结论时裁判规则另加一条（判定是系统算的，只判句子说法和判定是否一致，分析说明不了原因），没有分析结论的报告规则一字不差。口径账本不给分析结论里的数（判定语、具名标量、结果表的格）标口径、不按它们投影比对、不进整题判断的计数，也不算成没比对

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

look

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

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

memory

…

notify

…

process

…

providers

…

records

…

report_export

比率拆解的总数闭合核对：证据面板的输入一步按拆解的模式认 headline 对着哪个数（_HEADLINE_TOTALS 分可加、比率两套：可加对各段之和 base_total / target_total，比率对整体比率即各段分子之和 ÷ 分母之和 r_base_total / r_target_total），closure 带上 mode；比率拆解的两格角色写「基期整体比率」「本期整体比率」。以前只认 base_total / target_total，比率的 headline 在证据面板不显示闭合核对。导出页（report_export/runtime.js）比率的写「整体比率 x 与各段分子之和 ÷ 分母之和 y 闭合 / 对不上」、那一格叫「整体比率那一格」，可加的照旧。测试：可加拆解的 closure 带 mode、角色叫法不变，比率拆解两格各自闭合、复算一致

2026-10-21 15:37:20 +08:00

sandbox

…

scheduler

…

tools

agent 分析时按本节点查询认表，同一条 SQL 一个节点里只解析一次：context_of 加 tables_cache（SQL → 用到的表），AnalysisScope 带一份、分析工具每次调用交进去。以前每次分析调用都把本节点全部查询的 SQL 从头解析一遍（目录、剖析事实、探查都按表给）。测试：两条查询、三次分析，每条 SQL 只解析一次

2026-10-21 15:53:07 +08:00

__init__.py

…

main.py

…

ops.py

复核 R-d4（升级前的 SQLite 备份只拷了应用库和断点库）：填报的记录表 records/**/*.db 也用 SQLite 的备份接口拷进同一份备份，相对路径照旧，目录 0700、文件 0600；库在 PostgreSQL 时不做这份（记录表跟着整目录备份）。deploy/README 写清这份备份含什么、不含什么（上传原件和版本库、工件库、附件、知识库、沙箱工作区、.secret_key 要整目录备份），恢复步骤加上记录表

2026-10-19 16:12:07 +08:00

plain.py

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

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

seed.py

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

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

web_security.py

…

web.py

…