827 Commits

Author	SHA1	Message	Date
ThearchyHelios	cf30f999f6	验收复核查出的三处：有量纲比率的效应值（结构效应、自身效应、合计影响、变化）照原值显示，不再乘一百说成百分点（客单价影响 -11.12 元 / 单以前显示 -1,112.1 个百分点）；只读一张表、目录还没维护时分析范围照实说目录没维护，不说成对不上目录里的列；写作规则补一条不写重复判定语开头的引言	2026-10-21 18:08:59 +00:00
ThearchyHelios	9219df8190	真实模型验收查出的五条修正：①比率拆解里比率本身是有量纲的比率（客单价，元 / 单）时不套百分数，以前 160.76 显示成 16,076.0%，各段分子都不超过分母（退款率这类占比）照旧按百分数；②写作规则补两条——判定语一句只引用一份结论、不把几份判定语用逗号拼成一句，「核对不了」是系统的核对说明不是结论；③说法核对的来源判断看整个分句（主来源写在判断词后面的「主要由订单量放大带来」也能认），点名的段按去掉结尾量词的词根兜底（订单量 认 订单数）；④数据目录还没维护时候选维度照实说目录没维护、提示怎么补，不说成认不出事实表；⑤评测估不出每题花费时金额照 0 记但记成未计价，账本上看得出；金额上限照旧按累计金额判	2026-10-21 17:33:49 +00:00
ThearchyHelios	30423a0686	可验证报告那条新测试按列名找结果表的格：S8 起出处面板写结果表记的列名（占变化的比重），不把列 id（share）当叫法	2026-10-21 16:27:43 +00:00
ThearchyHelios	7b47ce1724	合入第 2 波复核修复 S1：分析结论的占比、变化率、比率之差按百分数 / 百分点显示——结果表带每列的显示格式、具名的数带格式，证据渲染、整表、写作目录、证据面板、导出、可验证报告都按它；显示规则 4 版，老文档按记下的版本复核；空格写「—」 ... # Conflicts: # backend/tests/test_analysis_pages.py	2026-10-21 16:23:39 +00:00
ThearchyHelios	709a50208a	合入第 2 波复核修复 S2、S5、S6：关分析工具那一臂挡分析卡与用了分析的子工作流、节点手册里不再出现分析；问题意图词表与自查那句进评测的提示词指纹；问题意图不把问构成当来源、不把问数据质量当异常	2026-10-21 16:22:21 +00:00
ThearchyHelios	eade5aab5d	关分析工具那一臂挡分析卡：图里有分析卡、嵌套的子工作流里有分析卡或分析工具都挡回去改；关掉时节点手册里不再出现分析卡、分析工具和分析相关的配置（改写与整段去掉）；问题意图词表版本与自查交回的那句进评测的提示词指纹；问题意图不把「哪个贡献最多」当来源、不把「数据是否正常」当异常；评测「关」那一臂的替身改成照样试着加分析卡、靠真代码挡	2026-10-21 16:19:49 +00:00
ThearchyHelios	316863b2e0	零售样例题集的试算：退款金额两边都按两位小数比（SQLite 的 ROUND(SUM(amount), 2) 出来是浮点，6448.19 存成 6448.1900000000005，逐字比会随数据变而失败；main 上同样失败）	2026-10-21 16:19:28 +00:00
ThearchyHelios	e225fcdd2c	合入第 2 波复核修复 S3、S7、S8、S10、P1：分析卡上写在验证什么的那句照实说是模板作者写的、分析步骤的编号写明是哪一层、证据面板的格写列名与总数按服务端渲染、注释归位、窄屏收起工具栏的改名图标	2026-10-21 16:17:20 +00:00
ThearchyHelios	28e7b0e12b	测试：占比、变化率、权重按百分数显示（第 2 波 S1）——每种实测情况一条断言：正文引用 [[a:A1.top_share]]、[[v:A1.r0.share]]、[[v:A1.r0.pct]] 没写换算时取结论记的格式（61.9%、-14.6%），写了换算的照写作者的；整表按格式展开；写作目录的具名的数与结果表按格式写；证据面板接口的具名的数、结果表的格、整体比率那一格（空格写「—」）；导出页与可验证报告照引用渲染；老文档（3 版）照原样、复核不判对不上，按新规则重渲染才判对不上。另钉住各算子填了哪些列、pct 与 pp 的写法、同输入两次 run 逐字节相同、复算逐字段相同	2026-10-21 15:55:51 +00:00
ThearchyHelios	c54196326f	证据面板的分析结论：结果表的格写列名，总数那一格的值按服务端的写法显示。①「这一处引用的是 结果表第 1 行『share』」原来写的是列 id，现在服务端在 cited 上另给 column_label（结果表记的 labels，如「占变化的比重」），目录条目也带上 labels，证据面板、读屏的出处、导出页、可验证报告都照列名写；② 输入里「总数那一格 … = 159175.18」和同一节的闭合核对「159,175.18」两个写法并排，现在服务端另给 value_rendered（render_cell，千分位、NULL 写「—」，和闭合核对同一个写法），三处界面照原样显示。结果表数的换算（比率、空格）不在这次改动里	2026-10-21 15:53:27 +00:00
ThearchyHelios	b919890b7b	问数据时间线的分析一步、协作成员的分析：编号照实说是哪一层。Agent 工具那一步标题写「变化拆解（可加） · 本节点 A1」——编号是这份 Agent 自己的分析容器里的（交回模型的「【分析 A1】」），报告目录里的 A1 按整次运行的台账编，图里还有分析卡时就不是同一个，不再冒充报告里的编号；分析卡的一项照旧写这一项的标识。协作成员的分析不带编号（成员的结论还进不了台账，照它写「· A1」会和报告里点名的结论对不上），event_view 交回 alias=None。check-decode、check-stream、协作成员那条测试照新写法改	2026-10-21 15:52:58 +00:00
ThearchyHelios	9461c03a63	分析结论的「在验证什么」照实说谁写的：分析卡上那一条是模板作者写的，标「分析卡上写的『在验证什么』」；Agent 现场做的照旧「Agent 写的假设」（台账条目带 item 的是分析卡、带 call_id 的是 Agent）。服务端按 origin 给 hypothesis_label、hypothesis_note 两句，证据面板、导出页、可验证报告都照原样显示，不自己拼。测试：证据接口两种都测，分析卡的链、导出页、核对页各加一条断言	2026-10-21 15:52:19 +00:00
ThearchyHelios	b0b8d3ef04	评测页分析期望的参数格和分析卡用同一份：CaseEditor 原来自抄的 PARAM_FIELDS 去掉，改用 canvas/analysisItems.paramSpecs（差异检验的比率、均值、逐行三模式也带上期次三格了，和服务器参数模型一致）；参数叫法只剩 lib/termsAnalysis 一份（EVAL_TEXT.analysis.param/basis/grain 引用 ANALYSIS_TEXT.node），格子的取值转换也用 paramText/paramValue，期次格保留 {{ }} 时间变量 ... - 参数格：basis、grain 两份下拉带上空着的缺省项（和分析卡同两行），逐行的值列、只比这几对等叫法跟分析卡一致 - test_frontend_eval_unions.py 新增一条：paramSpecs（含 PERIODS）的参数名和服务端各参数模型的交集/并集逐个对得上、评测页引用的是 paramSpecs、三张叫法表引用 ANALYSIS_TEXT.node	2026-10-21 14:57:12 +00:00
ThearchyHelios	454e82e211	分析测试的「今天」按题集的时区取，不看本机时区：题集里的期次（上周、本周）按 suite.timezone 算，生成虚构库、判今天是不是周一也照它，本机在别的时区（或跨午夜那几个钟头）时两边不是同一天 ... - test_eval_analysis_runs.py：TZ 从题集读，新增 now()（datetime.now(ZoneInfo(TZ))），生成库用 now().date()，原来写死的 Asia/Shanghai 去掉 - test_eval_analysis_suite.py：从题集内容取时区算今天，判周一也按它 - test_evals_api.py：零售样例题集的「今天」同样从题集取时区	2026-10-21 14:57:06 +00:00
ThearchyHelios	d211d2fac8	评测页的分析方法、模式叫法改为引用 lib/termsAnalysis 那一份（原来 termsEval 另抄了一份 OP_LABELS / MODE_LABELS）：EVAL_TEXT.analysis.op / mode 直接用 ANALYSIS_OP_LABEL、ANALYSIS_MODE_LABEL，字一样、界面不变。tests/test_frontend_eval_unions.py 改成读 termsAnalysis.ts 的两张表和契约逐项对，并守住评测页引用的是这一份	2026-10-21 20:03:54 +08:00
ThearchyHelios	28c538a72f	趋势判断工具的说明开头改成契约的叫法「趋势判断：」（原来写「趋势：」，另外四个工具都以 OP_LABELS 的叫法开头）；测试补一条：五个分析工具的说明都以契约里这种分析的叫法加「：」开头，助手的工具清单、证据面板、评测写的是同一种说法	2026-10-21 20:02:41 +08:00
ThearchyHelios	03cedbaf1d	合入 W2-c 前端：分析卡节点与分析项编辑器、报告节点两个新字段、设置「分析」一节、问数据时间线的分析步骤与出具横幅三项、运行对比的分析卡一区、证据面板与正文接上分析结论（六步出处链、闭合核对、两期可比性、说法违规标注、分析范围）、可验证报告核对页与分析样本页、口径账本摘要防 NaN；服务端补分析工具事件里的判定与分析结论的单独出处接口 ... # Conflicts: # backend/tests/test_eval_schedule.py	2026-10-21 19:34:24 +08:00
ThearchyHelios	de1bfaee9e	定时评测的测试不依赖同进程里的数据源个数（同 843be9a5 给 test_eval_runner 的做法）：这里的题没有限定数据源，评测按进程里全部的数据源拍目录快照，别的测试留下的数据源超过 app/eval/snapshots.MAX_SOURCES 时整次评测按设计失败（「这次评测用到的数据源超过 20 个」），断言的 partial 就成了 failed；后端全量并行时分到同一个进程就复现。这里不测这个上限，测试里把上限放大	2026-10-21 19:32:40 +08:00
ThearchyHelios	cc2c7a00fb	可比性期望认正文里「两期不能直接比」的说法：说法表（engine/analysis_claims）照旧不加可比 / 不可比一类，说法核对不打回「本周数据不完整，不能直接比」这种谨慎的提醒；评分在 eval/judgements 另用一张只给自己用的小词表（_INCOMPARABLE：不能直接比、不可比、不具可比性、本期数据不完整、还没过完、只有几天、差几天、不满一周、天数不同、口径不同……；「无法比拟」「比不上」、不带「直接」的「没法比」不算）。期望是不可比、正文明确这么说了的，按「对但没引用」算；同一分句里前面有否定的、句子里前面有假设或疑问的、问句都不算；期望是可比的只能靠引用。读答案时有这类说法的句子也留下（sentences_of_doc、sentences_of_text）。测试：几种说法算对但没引用、找到的那一处照实写；假设、疑问、否定、差得远、无关的「不完整」算错；期望可比的正文怎么写都不算；说法表照旧不认这类说法。test_doing_nothing_and_saying_nothing_is_wrong 里原先「本周还没过完，两周不能直接比」算错的那条断言按新规则移到新测试里，改成算对但没引用	2026-10-21 19:32:38 +08:00
ThearchyHelios	bf89269c11	评测前端：变体里能选「分析工具」开 / 关，发起评测多一种「分析工具贡献对照」。typesEval 加 EvalAnalysisTools、EvalPreset，EvalVariant 多 analysis；termsEval 加分析工具的叫法、提示和这种对照的说明，对比「都没变」那句带上分析工具。StartDialog：ArmFields 多一格分析工具（题集的默认变体同一张表单），预设对照里由预设定的那一项不摆（目录贡献不摆目录、分析工具贡献不摆分析工具）；分析工具贡献对照交 {preset: analysis_tools, variant}，变体里不带分析工具和名字，缺省每题 3 次。结果页、对比页、A/B 照服务端的变体那一句和指纹差异显示。check-evals：发起时评一次选「关」、两种预设的请求体和估算的两臂，对比写「分析工具：开 → 关」，分析工具贡献对照的两臂和详情页头；test_frontend_eval_unions 对上分析工具的取值、叫法和预设对照	2026-10-21 19:32:38 +08:00
ThearchyHelios	8a6ad0e7a2	评测变体加「分析工具」开 / 关（缺省开）和「分析工具贡献」预设对照：eval/variants 的变体多一项 analysis {tools: on | off}，只认这两个值、缺省开，不合规的照实拒（eval_variant_invalid，落到 variant.analysis）；analysis_tools(变体) 读开关，加这一项之前存下的变体按开。eval/answer.TurnContext 加 analysis_tools，Driver 透传给 chat/drive.TurnDriver（再到 api/copilot.answer_ops）：关的那一臂建图时工具清单不列分析工具、节点手册不讲分析卡；工作流题不建图，不受影响。同一变体（variant_key）认分析工具：开着时不写进去，和加这一项之前算出来的一样，以前的评测照样当基准、趋势线不断；关着时不同。指纹记 analysis_tools，对比的指纹差异写「分析工具：开 → 关」（老指纹里没有这一项的按开）；变体那一句写「分析工具开 / 关」，结果页、A/B、估算照它显示。api/evals 的预设对照加 analysis_tools（variants.analysis_tools_preset：开、关两臂，名字「分析工具开」「分析工具关」，别的项照 variant 或题集的缺省）。测试：变体规范化、拒收、同一变体指纹、变体那一句、预设两臂和 Driver 拿到的开关、估算与 A/B 拒收（test_eval_runner）；指纹差异的开、关和老指纹（test_eval_compare）；真运行的「分析工具贡献」对照（test_eval_analysis_runs：关的那一臂助手看到的 system 里没有分析工具和分析卡、作答运行里没有分析结论、算错，开的那一臂对且可追溯，两臂共用期望、指纹和同一变体都不同）	2026-10-21 19:32:38 +08:00
ThearchyHelios	017cbee5aa	可验证报告样本页加异动周报（analysis，分析能力一轮）：Agent 在虚构零售库 shop 上查两周的总数和按地区两周的销售额，做按地区的变化拆解（带总数核对）、波动基线（两周历史不够，算不了）、两期可比性检查，结论按快照真算（app.analysis.run，目录事实按虚构的数据目录给），Agent 节点的 tool.end 照分析工具真实的写法带结论工件和判定那一段；报告引用拆解的判定语、具名的数、结果表的格和整张结果表，正文后面是 engine/analysis_scope 按虚构的数据目录算出的分析范围（没拆的是渠道）。check-bundle：样本页 19 份；异动周报原样导出全部通过——③ 三份结论和两份输入快照随文件附带，④ 输入快照按「已核对的分析结论的输入」认，⑤ 分开数判定语，点开判定语看得到判定标准、方法与版本、附带说明、Agent 写的假设、输入和导出时的复算，具名的数、结果表的格写对出处，分析范围的编号点得开（正文没引用的 A2 也随文件附带）、范围里的编号不核正文显示，390 宽不溢出；只改判定语、具名的数的显示并重算全部哈希各自变红并点名。另：「查询快照以外的工件标成遮罩」的原因照第 1 波改过的说法（只有查询快照、口径卡、分析结论和报告文档……），原来的断言没跟着改。test_bundle_build 的样本页清单加上它、核对它的形状	2026-10-21 19:09:21 +08:00
ThearchyHelios	887d086261	合入 W2-a 想 + 文档：问题意图词表、分析方法定稿（analysis.method@2）、助手建图认分析卡与分析工具（分析类问题的形状、自查只挡一轮、关分析工具的开关）、复核信号并成一条只写说明、内置模板 ⑪「异动分析（可追溯）」、中英文档（新增 analysis 一篇、七对文档与升级说明、README）	2026-10-21 18:54:50 +08:00
ThearchyHelios	5a02d17bf2	助手建图加「关掉分析工具」的开关，给评测的「分析工具开、关」对照用：api/copilot.answer_ops 加关键字参数 analysis_tools（缺省真，和以前一字不差）。为假时给助手的工具清单不列五个分析工具（_tool_catalog），节点手册去掉只讲分析能力的三段（agent 段里分析类问题绑分析工具那一条、分析卡一整条、搭图规则第 7 条；报告段的引用写法和分析说法核对照留，node_reference），问数据的包装不给分析类问题那一条形状（ANALYSIS_SHAPE_PROMPT 抽成常量），问题意图那条自查不提；图里照样绑了分析工具的（Agent、协作成员、调用工具节点）按「绑定的工具不存在」挡（analysis_tools_off，交回模型去掉，改不好就不运行）。chat/drive.TurnDriver 加同名参数和属性 analysis_tools（缺省真），_generate 透传给 answer_ops；问数据页不暴露，eval/answer.Driver 之后按变体设。测试：关着时工具清单、手册、包装都没有分析，绑了被挡、改掉就运行；开着时绑了照常运行；没碰分析工具的一轮开、关交出的操作逐条一样；TurnDriver 透传	2026-10-21 18:47:10 +08:00
ThearchyHelios	f9be394a99	撤回上一条（定时评测测试放大数据源上限）：评测包 an2/b 的 5d53ed73 做了同一处修改，留着合并时会撞同一个夹具；这里撤回，合并后照 an2/b 那一份	2026-10-21 18:40:30 +08:00
ThearchyHelios	f293904cdd	定时评测的测试不依赖同进程里的数据源个数（同 843be9a5 对评测执行测试的做法）：别的测试留下的数据源超过评测拍目录快照的上限时，评测在作答前就按设计失败，「连续 3 题止损、部分完成」那两条就判不出；加了几个测试文件、测试分进程的方式变了以后，全量时这两条稳定复现（把上限压到 0 也能复现）。这里的评测不测这个上限，夹具里把上限放大	2026-10-21 18:33:17 +08:00
ThearchyHelios	5d53ed7332	题集定时的测试不依赖同进程里的数据源个数（同 843be9a5 对评测执行测试的做法）：题目是不限数据源的问数据题，评测按全部启用的数据源拍目录快照，别的测试留下的数据源超过上限时整次评测按设计失败，状态成了 failed 而不是 partial（全量并行时分到同一个进程复现）；这里不测这个上限，把上限放大	2026-10-21 18:30:08 +08:00
ThearchyHelios	94a6eb9c64	分析期望的两处小修：期望 SQL 只返回两期时补上的基期、本期写成文字交给分析工具的参数（期次是数的也认，算子按写出来的样子比）；参数和结果对不上的原因前面写「第 n 个期望（贡献）算不出期望」，不再叠两个「的」。测试补逐题 E1 顺着下钻找到两层的查询	2026-10-21 18:30:08 +08:00
ThearchyHelios	ab65b6032d	问题意图：「变化大不大」「变化大吗」归到波动一类（问的是这次变化大不大，不是变化从哪来），自查那条问题照「问题问的是波动大不大」说；来源一类只留「怎么变了 / 有什么变化 / 变化在哪」。测试加一个正例	2026-10-21 18:27:05 +08:00
ThearchyHelios	9358d9ec48	评测前端认两种分析期望：题目编辑器在预览之后选贡献或判定（分析方法、模式、按哪几列、期次、点名前几段），试算写出服务端算的判定和判定语；结果页逐题写期望和答案的判定，点开写判定语、引用了哪一份结论或正文那一句；总览按期望的种类分开写结论 ... - typesEval.ts：期望种类加 contribution、verdict，期望带 op、mode、params；EvalAnalysisOp、EvalAnalysisMode、EvalJudgement（同服务端契约和 judgements.JUDGEMENTS）；期望值、评分带判定类、点名的段、方向、判定语；总表加 outcomes_by_kind - termsEval.ts：贡献、判定的叫法；分析方法、模式的叫法和契约的 OP_LABELS、MODE_LABELS 一字不差（test_frontend_eval_unions 逐个对照，连同判定类）；判定类、方向、参数的叫法；指纹差异一句补上分析设置 - parts.tsx：期望写成「变化拆解（可加） · 按地区 · 销售额」；判定写成「主要来源：华东（下降）」「超出常规波动（上升）」「差异站得住（西南高于华东）」，算不了的照实写原因；判定类、段、方向都是服务端给的，界面只套叫法 - CaseEditor.tsx：分析期望的表单按分析方法列参数（参数名同分析工具，列从预览结果里选），换方法、模式只留新方法还认的参数；编辑配了几个期望的题时另外的期望列出来、保存时照旧带上（以前只留第一个，第二个期望会丢） - EvaluationPage.tsx：逐题表、展开的明细、总览按种类 - scripts/check-evals.mjs：夹具补分析期望（加题选算子、试算、保存的请求体不带来源方向判定，编辑保留另外的期望；结果页四种结论、点开的明细、总览按种类），共 130 项	2026-10-21 18:23:57 +08:00
ThearchyHelios	83cd5da72e	虚构库 retail_trends 与分析题集：26 周的零售订单（截止昨天、固定种子），相对上一个整周埋了八个效应；题集 analysis_suite.json 每个效应一题，期望由平台的分析方法在期望 SQL 上算 ... - tests/fixtures/acceptance/retail_trends.py（python -m tests.fixtures.acceptance.retail_trends <db> [--today]，数据源名 retail_trends，不动 retail.py）：华东线下客单价降到七成带来的销售额下降（主要来自华东）；三成线下订单转到线上造成的退款率辛普森（各渠道都降、整体升，结构为主）；订单数的常规波动；取消单激增；线上销售额连涨十周以上；线上销售额的变化来自订单数；西南一家小店的退款率看着高但样本太少；本周没过完（和上周不可比，周一时本周还没有数据、那一题期望算不了）。订单数按店按周定好、金额在窄区间随机、退款按渠道比例挑，各效应不靠运气 - tests/fixtures/eval/analysis_suite.json：八道题，问法用使用者的说法（上周销售额为什么下降？退款率为什么上升了？上周订单数下降算不算异常？……），各配一个贡献或判定期望，订单数、取消单两题另配一个不必需的「一个数」 - 测试：同一个今天逐字节相同；四个不同的今天（周三、周日、周六、跨年）上用 app.analysis.run 按题集的期望 SQL 核对八个效应；周一那一题照实算不了；走接口导入题集、逐题试算，分析期望都算得出、判定和埋的效应一致；真运行的算期望（作答前后对得上、阈值按设置快照、参数对不上照实说）、读作答运行里的分析结论和引用、重评老结果、从头到尾评一题（助手剧本搭查库 → 分析卡 → 报告，对且可追溯、逐题 E1 等价已证明）	2026-10-21 18:12:12 +08:00
ThearchyHelios	7794794278	评测的两种分析期望（贡献、判定）：期望 SQL 的探针快照上用平台的算子（app.analysis.run，随数据变化的调用错误记成算不了）算出期望的判定，评分沿用五种结论 ... - 题目（cases.py）：contribution 贡献恒为变化拆解（可加、比率、乘积）、另写 top_n（期望点名主要来源的前几段，缺省 1）；verdict 判定是波动基线、趋势判断、差异检验、可比性检查。参数同分析工具（不写输入、总数、下钻，不写阈值），文字参数可以带 {{ schedule.* }}；来源、方向、判定不许人填（HUMAN_VALUE_KEYS 加 segment、subjects、direction、verdict 等）；口径题、期望反问的题配不了 - 算期望（gold.py、judgements.py）：遮罩列、目录事实、现查表的日期范围和分析工具同一套取法；阈值用这次评测的分析设置快照（Context.analysis），试算时现读设置；期望 SQL 只返回两期时可以不写基期、本期；算不了的这一项照实记（评分时不能评分），参数和结果对不上的整题没有可用的值；截断的快照照旧拒收。作答前后两次期望、和上一次比的「数据变了」都不比运行当天、现查时刻、输入快照的工件（stable_sets） - 评分（score.py、judgements.py，SCORER_VERSION 3）：判定码归到同一套判定类再比；答案引用了（判定语、具名的数、结果表的格、句末依据）判定对得上的分析结论是对且可追溯，引用它的那句却写反了不算；没引用但正文按说法表（engine/analysis_claims 同一个 scan、同一套绑定规则）写对了是对但没引用；判定、来源、方向对不上或写成相反、根本没做也没说是错。答案的分析结论从作答运行的台账读、引用从报告文档读，有判断词的句子一并读出；逐题 E1 引用分析结论时按它的输入查询比（下钻顺着上一层找）；判定语不再当成答案里的数；老结果的明细里没有这两项按空读 - 执行（runner.py、answer.py）：有分析期望的题集开评时拍一份分析设置，算期望、各臂作答的运行（Run.options 的 analysis）都按它，记进指纹（compare 的「分析设置」一项），重试沿用；别的题集的指纹、作答运行的选项不变。助手提示词的指纹加上分析方法（guide 的 id 和全文）、写作者的分析规则和说法表版本 - 总表（stats.py）：各期望的结论另按期望的种类各一份（outcomes_by_kind）	2026-10-21 18:11:57 +08:00
ThearchyHelios	690e855ea5	内置模板 ⑪「异动分析（可追溯）」：两个调用工具节点取数（整体按周 26 周、按地区两周，期次在 SQL 里按每周第一天的日期算出来、整体按周倒序排），分析卡固定做两项（本周的变化放回历史看的波动基线、按地区的可加变化拆解，总数取整体按周的第 0、1 行核对闭合；阈值不写死、取设置），报告撰写节点按受管级别写明最严的几项（含分析说法核对严格），出口按报告来自 + 单元格引用的契约出具。拿来就能按受管级别发布。界面文案白名单加一条：模板 SQL 里中文列别名按 SQLite 加的双引号是 SQL 语法。测试：画布校验、受管发布检查没有错误（模板 ⑨ 一并核）、接一份虚构的四地区 26 周零售库从头运行，两项都做成（明显超出常规波动、主要来自华东）、完整出具	2026-10-21 18:08:59 +08:00
ThearchyHelios	97a37d4bd2	复核信号认分析能力一轮的缺口：一次运行里算不了的几次分析并成一条「有 n 次分析没做成」，点名是哪一项、为什么（叫法取契约的 OP_LABELS，不再写 analysis_baseline 这样的工具名；老事件没带这几项的照日志原话），排在第一次出现的位置；分析调用写错（tool.error 带 call_error）后来同一个分析工具做成了是 Agent 照说明改对了，不再报 tool_args_fixed、为它叫一次复核模型，一直没做成的并成一条 analysis_call_failed（缺口，只写说明），不再落成 tool_error（严重、可重来，一次写错的分析会让整轮问数据重来）；判断词核对重写后仍有的照报告节点原话说处数和重写次数。核对过第 1 波新增的日志代码：report_analysis_claims、analysis_refused、metric_comparability_skipped 三种，都已登记、都是缺口、都在只写说明的一组，RETRYABLE / REBUILD 不加。改了一条旧测试：test_analysis_signals_are_registered_as_gaps_that_only_need_a_note 原来断言三种日志正好等于 NOTE_ONLY，NOTE_ONLY 多了 analysis_call_failed 这种不是日志代码的信号，改成比去掉它之后的	2026-10-21 18:08:48 +08:00
ThearchyHelios	8a81fa767e	助手建图认分析能力：节点手册加分析卡一段（用途是模板里固定要做的分析，items / overrides，输入只认调用数据库查询工具的调用工具节点和合并查询，产出 nodes.<id>.results.<项> 可按判定分支，结果不进口径卡）、agent 段补五个分析工具（分析类问题绑，绑了平台注入分析方法，只绑给查库的 agent）、报告段补分析结论的引用写法（a:An、a:An.键、v:An.r0.列、table:An、句末 see:An）和分析说法核对（check 缺省、strict、off，只能往严里改）、分析范围，受管指引和发布前修复的硬性约定写明分析说法核对要严格；搭图规则加一条。问数据的包装加「分析类问题」的形状（input → agent 绑查询、表结构和分析工具 → report 按分析结论写、引用判定语 → output）。报告的证据来源认分析卡。自查：GenerateIn 加 question（问数据的一轮把原问题带上，重来时 instruction 是带着原因的那段话），问题是分析类、查库的 Agent 没绑分析工具、图里也没有分析卡时提一条问题（analysis_tools_missing，带 for_model），照 coverage 只交回模型改一轮，改过一轮仍在的不挡运行、收尾时留作提醒。测试：手册里的引用写法交给真解析器、分析卡与工具的叫法取契约、包装的分析形状、自查只挡一轮与几种不提的情形、重来按原问题判	2026-10-21 18:08:37 +08:00
ThearchyHelios	5617deb80b	分析方法定稿（ANALYSIS_METHOD_PROMPT，guide id 升到 analysis.method@2）：在第一版六条上写清按问题选基期（环比比上一个整期、同比比去年同期并写 lag、和目标比要库里有目标，没说就比上一个整期，本期取最近一个过完的整期）；周序列的期次在 SQL 里由日期列算出来，写每周第一天的日期（附 SQLite 写法）或 ISO 周，SQLite 的 %W、MySQL 的 %u 不是 ISO 周，直接取现成的周号文本本期齐不齐核对不了；先可比性与基线、趋势，再拆因子与结构、按维度由粗到细，找到主要来源再下钻一层；每次写明在验证什么，拆了不集中也是结论；不作因果断言；阈值不由模型定、算不了照实说、调用写错照说明改；最后交给写作者的文字里列出做过的分析（An）和判定原话。测试守这几件事都在、点名的工具是那五个、五个工具共用这一份	2026-10-21 18:08:25 +08:00
ThearchyHelios	040040d23a	问题意图（app/analysis/intent.py）：确定的词表判一句问题是不是分析类问题（原因、变化从哪来、是否异常、波动、趋势、差异站不站得住六类），带版本 INTENT_VERSION 1，给助手搭问数据的图时自查用。只收明确的问法、宁可漏判：问原因的词要和涨跌、高低的说法在同一句（「为什么报错」不算），「原因」要是变化的原因（「退款原因有哪些」是字段不算），「异常」后面是订单、记录这类名词的是业务状态，「系统正常吗」「表结构有什么变化」问的不是数，「持续」前后要有涨跌；按句子认、逗号不分句；英文只收几种明确问法。和说法核对的说法表不共用词表：意图判用户的问题，不判写作者的句子。测试：43 个正例、26 个反例、分句、引文截短	2026-10-21 18:08:16 +08:00
ThearchyHelios	998ab23bae	报告末尾「分析范围」里的编号点得开：证据接口加 GET /runs/{id}/evidence/analyses/{alias}（?report= 同片段接口），交回那份分析结论的出处链（判定 → 方法 → 计算 → 输入 → 复算 → 封存，和点开正文里它的判定语同一条，按导出页已有的 _scope_chain），正文没引用的结论（算不了的、可比性检查）也点得开；只认这份报告证据目录里的分析结论，没有的 404（evidence_analysis_not_found）。选报告、文档完好与否的几种错误挪进 _open_report，片段接口和它共用同一套错误码。测试：同一条链、算不了的照实给原因、目录里没有的和不是分析结论的 404、文档被改过 409	2026-10-21 18:02:34 +08:00
ThearchyHelios	5f61661625	分析工具的 tool.end 另带一小段判定（tools/analysis.event_view：编号、算子、模式、状态、判定码、方向、判定语、算不了的原因码）：preview 只是结论 JSON 的前一截（截到 2000 个字符），可加拆解、可比性检查的判定语都在截掉的那段里，问数据时间线照这一段显示，不从 preview 里拼。编号和交回模型的「【分析 An】」同一个（AnalysisScope.next_alias，记台账时 add_result 紧接着按它编），写错的调用不带这一段、不占编号；协作成员按自己的分析容器编号；Agent 写的假设不带。测试：编号与交回模型的一致、判定语只在这一段里、算不了的带原因码、成员自己编号	2026-10-21 17:53:56 +08:00
ThearchyHelios	843be9a556	评测执行的测试不依赖同进程里的数据源个数、等待都有时限：别的测试建的数据源超过评测拍目录快照的上限时，作答运行在排队前就失败，原来的等待循环永远等不到、整次测试卡死（上传源测试和评测测试分到同一个进程时复现）；这里的评测不测这个上限，测试里把上限放大，等待改成 30 秒等不到就失败并说清在等什么	2026-10-21 17:17:02 +08:00
ThearchyHelios	24b5aebae4	叫法消毒按词认判断词（scan bare）：说法核对修复后 scan 缺省按整句规矩认（没说变化的「主要来自」不算判断），叫法是一个名字不是一句话，「主要来自华东的销售额」这样的叫法要整个不要	2026-10-21 17:12:48 +08:00
ThearchyHelios	a02dc41424	合入复核修复（说法核对）：结论句判定回到原来的词表（扩充的判断词只给裁判排先后）、表格正文不核、补因果与来源的口子、说法表按样本调整（96 句样本表）、连续按末尾方向核、复核认三种日志且只写说明、分析结论算可引用的来源、自动修复对认不出的取值照 claims 做、候选维度写明只认码值表、scan 加只按词认	2026-10-21 17:12:18 +08:00
ThearchyHelios	2d616d01e8	说法表的 scan 加 bare=True：只按词认、不看上下文（构成、建议计划、业务状态、「相当」的比法、「未见异常」的主语这些只对整句话成立的规矩都不用），给认叫法（度量的叫法、因子名）里夹带的判断词用——叫法是一个名字不是一句话，「主要来自华东的销售额」照样认出来源；缺省照旧按整句的规矩。原因只是指代的那条注释改准。测试：几个叫法按词认、按整句不认	2026-10-21 17:10:43 +08:00
ThearchyHelios	41ad3a1c05	合入复核修复（证据接入与入口）：跨段指标不当两期查、证据接口重渲染与组装同一个函数、一次请求同一份结论只复算一次、比率闭合核对、代入式按点名的段、写作目录分析段限额、核对页写方法叫法、运行对比只认做完的执行、读快照进线程、四个工具与合并查询的真算子测试、夹具清源	2026-10-21 16:58:45 +08:00
ThearchyHelios	2efea2b753	周号超出任何算法（W54 以上）的认不出、算起止超出日期范围的当这一周没有（复核 R3 补）：认不出算法时原来按周号排先后，「2026-W99」也会当一周收下，现在周号大于 53 的不当周号写法，原因里照实举它；按算法算起止时日子超出日期能表示的范围（公元 9999 年末）交回没有这一周，不抛异常	2026-10-21 16:56:48 +08:00
ThearchyHelios	f5e6e77ea9	测试用的假结论按各算子的形状给（复核 R31）：testing.fake_result 不再一律拿可加拆解的结果表——波动基线（期次、value、change、role）、趋势（期次、value、change）、差异检验（a、b、a_value……p_adj、flag）、可比性检查（check、status、base、target、note）各给自己形状的结果表（带列类型）、具名标量、参数和输入（可比性检查是基期、本期两份），数是编的、和判定语对得上；差异检验没写模式时按比率。变化拆解那一份照旧。测试对着真算子核对列和具名标量的键	2026-10-21 16:16:40 +08:00
ThearchyHelios	19bdcf55d8	分析卡运行时对合并后的阈值再核一遍（复核 R28）：画图时阈值覆盖只能对着缺省值校验（schema 不改），发起时的设置快照合进来以后可能冲突——管理员把「超出常规波动」调到 3、卡上把「明显超出」覆盖成 2.5，就永远判不出超出。卡上写了覆盖时，运行时对缺省 ← 快照 ← 覆盖合并后的阈值跑一次 contract.settings_problem，有问题让卡失败并说清「阈值覆盖和这次运行的分析设置冲突：…。请改分析卡上的阈值覆盖」（配置错误，不是数据问题，一项都不算）	2026-10-21 16:11:00 +08:00
ThearchyHelios	d5836eb845	写作目录省略说明里分析结论那几句改成给模型看的常量（ANALYSIS_TABLES_OMITTED_PROMPT、ANALYSIS_TRIMMED_PROMPT、ANALYSIS_LEVEL_PROMPT_WORDS），和别的写作规则同一个认法，界面文案检查不再把它们当界面上的字；「没列出的照样能引用」改成「没列出的也能引用」	2026-10-21 16:10:01 +08:00
ThearchyHelios	f7a09eb108	一份快照按期次分组的变化拆解也核本期齐不齐（复核 R20）：可加、比率、乘积三种模式用波动基线同一套完整性检查（comparable.period_complete：不到整周、没过完、数据没到、SQL 截掉一部分），本期不齐算不了（partial_target，「本期数据只到 2026-10-20，还差 5 天，和完整的周比没有意义」），核对不了（查不到表的范围、周号认不出算法、期次不是日期）附一句说明，只在证据面板、不进判定语（两份快照时可比性结论照旧进判定语）；结论的 params 记下运行当天。期次按 periods.parse_compared 认：周号按 SQL 认算法；快照里往往只有比的两期，值都是日期、推断成按周、期次列又是直接取的日期列（原样、date(列)、DATE(列)、CAST 成日期）时按天认——昨天对上周同一天正好隔 7 天，光看值分不出是两天还是两周。可比性检查按期次分组、没给粒度时同样按它认。证据接口的一条测试（tests/test_analysis_evidence_api.py）跟着补上这一句说明的种类	2026-10-21 16:09:21 +08:00
ThearchyHelios	9817830d4a	自动修复和门禁对 analysis_claims 写了认不出的值（如 loose）对齐 claims 的做法：G3 那一条修复（_plan_report_policy）不再顺手改成 strict（门禁跳过它、交给校验报），认不出的取值由校验那条 report.analysis_claims_invalid 自己的修复管——受管级别改成 strict（G3 只认它，答案唯一），别的级别不核对、重写一次后标出、重写后仍有的计入缺口三档要人选，不给建议（同 claims_invalid 的 _plan_claims）；跳过认不出的取值统一按门禁的 _POLICY_PROBLEMS 判。测试：受管级别 G3 修复只改 numbers、认不出的取值另有一条改成 strict，一起应用后通过；已发布级别三档候选、选了照写	2026-10-21 16:08:22 +08:00