 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
|
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
|
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
|
cf1cc568d6
|
分析范围的候选维度写明只认码值表：剖析目前不记每列的取值数（码值列另有取值分布的观察、键列只核唯一），方案 §3.6 的「剖析的取值数 ≤ 50」等剖析记了每列取值数再补，没有码值表的属性列不进候选（第 1 波复核 R34，记为偏离）。只改注释
|
2026-10-21 16:09:00 +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 |
|
|
ThearchyHelios
|
41d95721ce
|
分析入口的测试补真算子：test_analysis_e2e 加 agent 调波动基线（本周明显超出常规波动、历史新低，本期完不完整按现查的表范围判）、趋势、差异检验（逐行明细，华东的单笔金额高于华南）、可比性检查（两份查询各一周）各一次的端到端，台账、交回模型的那一段、复算逐字段相同都核；分析卡以合并查询为输入跑一次（输入写明 sqlite 方言、工件就是合并查询的快照）。test_analysis_card 的下钻样例 DRILL 原来 by 和 period 是同一列、真算子下会报错：shop 加渠道列（各地区两周的合计不变），DRILL 改成读华东按渠道的那次查询（drill_graph），另用真算子跑一遍下钻（闭合、主要来自线上、parent 是上一项的结论工件、复算一致）；夹具改用 scratch_source。过时的说明照实改：替身的用途、口径卡可比性挂钩里「还没有算子」的说法
|
2026-10-21 16:06:40 +08:00 |
|
|
ThearchyHelios
|
6503b095cb
|
报告撰写节点的「上游没有可引用的来源」认分析结论（_CITABLE 加分析结论，_no_evidence 照 00-总方案 D10）：「证据来自」只选了分析卡时不再误报没有可引用的来源；分析卡做的结论总能引用，受管级别的正式出具没开「单元格引用」、上游有分析卡结论时也不再报「只有查询结果…无法引用单元格」；Agent 现场做的分析和它查的格同一个规矩，没开单元格引用时照报，说法写明「只有查询结果和 Agent 现场做的分析…无法引用单元格和这些分析结论」，只有查询时一字不变。测试：只有分析卡结论（开没开单元格引用都不报）、Agent 的分析按单元格引用的规矩、什么都没有时点名分析结论
|
2026-10-21 16:04:42 +08:00 |
|
|
ThearchyHelios
|
99b1406f8b
|
复核认分析能力一轮的三种日志：report_analysis_claims（判断词没挂对分析结论、原因没依据，重写后仍有）、analysis_refused（一份分析算不了）、metric_comparability_skipped（口径卡指标的两期没做成可比性检查）登记进 WARN_CODES，按自己的 kind 记、都是缺口（DEGRADED），照 00-总方案 §3.7 只写说明、不自动重来：不进 RETRYABLE / REBUILD，一次运行的信号全是这几种（NOTE_ONLY）时复核不叫模型，说明照信号原话写——以前没登记一律按笼统的 warn 叫一次复核模型。「改过一次」的 report_repair 按最后一次核对定档时，只剩只重写一次、留在报告里标注的违规（check 下的分析说法，和同一类的缺失断言 absence_claim）也算改好了：它们各有自己的信号，以前 report.checked 的 ok 为 False 就判没改好、多报一条；复核被别的信号叫起来时照实说「重写后只剩已标出的 1 处分析说法」，一处都没改掉的不说改好了。strict 下的分析说法是出具缺口、带满 20 条的可能还有别的，照旧判没改好。测试：三种信号的 kind 与级别、只有这几种信号时不叫模型（复核接口也是）、和别的信号一起时照常叫、check 与缺失断言的剩余算改好、strict / 还有别的违规 / 带满 20 条照旧
|
2026-10-21 16:02:46 +08:00 |
|
|
ThearchyHelios
|
f05dd9e21c
|
「连续」按趋势结论记的末尾连续同向核（values 的 run_direction、run_length），不再先要整体判定是上升或下降：算子修复后趋势判定语在方向相反时写「，但最近已连续 N 期上升」，句子照它写「最近已连续 4 周上升」要对得上，整体没有明显趋势、末尾连续下降的也能说连续。句子写了期数的（「连续 5 周上升」「三连降」「十二连涨」，阿拉伯数字、全角数字、一到九十九的中文数字）要 run_length 不少于它，没写的至少 3 期；方向对不上照旧报相反；没记 run_direction 的老结论按整体的趋势方向。测试：期数不够、整体下降而末尾连续上升、没有明显趋势而末尾连续下降、老结论，和各种写法认出的期数
|
2026-10-21 15:56:49 +08:00 |
|
|
ThearchyHelios
|
3fd5d1309c
|
说法核对按复核调整（说法表 v1，还没有线上文档，不升版本）。来源和因果的口子：「主要由」不再吃掉「由于」（主要由(?!于)，「主要源于」归来源类）；原因按因果词的那一边认（「由于、因为、原因是、源于、得益于」后面，「导致、造成、引起、所致、是…的主要原因」前面、「由华东造成」在「由」和「造成」之间，「受…影响」中间），挂了拆解、原因点名的是它的段才按来源核，否则按因果核——「华东下降主要由于促销结束」「下降主要由促销结束造成」不再通过；没挂拆解的，原因不是目录里拆解的段时另报，认不出时照旧并进同一分句的来源判断；原因只是指代（「以上是下降的主要原因」）不核。来源类判断要点名拆解里的段：「主要来自」「集中在」「以…为主」看判断词后面，「主导」「贡献最大」看前面（同一分句没点名的往前找最近点了名的分句），拖累拉动带动照旧看整个分句；挂了拆解却没点名任何一段（「下降主要来自线上渠道」挂按地区的拆解、「主要来自新客流失」）判对不上，同一分句引用了判定语、比率拆解说「结构变化」「自身变化」的不用点名。误报去掉：来源、集中、分散、主导、拉动带动要这句话到这个分句为止说了变化才核（构成不核）；建议、计划、预测、假设的分句不核（「建议」「下周」「避免」管到后面的分句）；「异常」前面是订单、物流、支付、门店、营业、库存、设备、账号的是业务状态（后面跟着涨跌的照核），「异常的 + 名词」不核；「无异常」「未见异常」主语要是指标或波动；「来源于」不是「源于」；「表结构变化」不是结构变化；「相当」只认比几组、几样的，比上期的不核。漏报补上：「是…的主要原因」「主要原因是」、「近七成 / 超过一半 / 大部分的降幅来自」、「主要靠 / 在 / 体现在」、「以…为主」、「创」和「新高」之间 0–4 个字、「显著 + 涨跌」、「趋势向好」「波动较大」「三连降」「远高于往常」「异动」「一涨一跌」。写作规则补一句「写来源要点名是哪一段」，异常类的说法带上「显著上升或下降」。样本表 tests/test_analysis_claims_lexicon.py：复核的 70 句加这次看清楚的 26 句，每句期望的类或不核，以后改说法表都过这张表；和复核标记不一样的只有「退款主要集中在生鲜品类」（说的是构成，不核）；绑定测试补上复核列的几个口子
|
2026-10-21 15:56:30 +08:00 |
|
|
ThearchyHelios
|
9339facf9a
|
运行对比里的分析卡只认做完了的那次执行：analysis.end 先按卡记在这一次执行里，见到这张卡的 node.finished 才算数（新的 node.started 清掉上一次没做完的）。分析卡执行到一半失败时前几项已经发了 analysis.end，以前运行对比会把这次失败执行的判定当成结果列出来、也算进执行次数。测试：中途失败的那次不列、不算次数，失败后重来做完的按做完的那次对比
|
2026-10-21 15:50:15 +08:00 |
|
|
ThearchyHelios
|
6e38df4fbf
|
分析卡里随数据变化的调用错误记成算不了的一项，不让卡失败（复核 R6）：analysis.run 加参数 refuse_data_errors（缺省假），为真时 DATA_ERRORS 里的调用错误——上一层没做成 parent_refused、下钻的段这期没有 parent_key_missing、期次这期没有 period_not_found（变化拆解、波动基线的本期、差异检验按期比、可比性检查）、总数那一格越界或为空 row_out_of_range / headline_empty、要比的组这期没有 unknown_group / too_few_groups、要用的那一格这期为空 empty_cell（乘积拆解的乘积和因子；差异检验的计数为空原来报的是 not_count，改报 empty_cell）——记成 status refused 的结论：契约 REASONS 加 parent_refused、input_unavailable，CallError 加 reason（照实说是哪一项、哪个值，不带改法），判定语「{叫法}没有做成：原因」；params 照调用原样（label 照样消毒），取过还没记用法的快照都记进输入（Inputs.settle，角色照第一次取时的），上一层在核对它做没做成之前就记进输入，复算按它们走到同一处；阈值和判定标准同各算子自己算不了时那一份（各模块的 USED / refusal_basis，算子本身也改用它）。recompute 一律按真复现；结构性的调用错误照旧抛。分析卡运行器传真，agent 工具不传。顺手：段数不够的原因里维度叫法和汉字之间照 say 的规矩补空格
|
2026-10-21 15:47:30 +08:00 |
|
|
ThearchyHelios
|
fa33b98fef
|
写作目录有省略时，分析结论一段最多占预算的一半（_PROMPT_ANALYSIS_SHARE）：每条结论四种样子从全到简（ANALYSIS_LEVELS：full 连同结果表的前几段、compact 结果表只写一句、brief 只留判定语和具名的数、head 只列编号那一行），先都按 compact 列，超了按结论的先后从后往前降成 brief、再降成 head；结果表的段照旧先于查询的行补，但这一段补完也不超过上限。开头那句照实写各样子各有几条，以及没列的照样能引用（判定语写 [[a:编号]]、结果表写整表引用、没列出的具名的数不要编造）；只是结果表没列各段的照旧那一句。以前这一段没有上限，40 份结论、每份 1000 段时在 51.2k 的预算里占 50.6k，查询只剩一行摘要；现在占 25.6k 以内，那次查询列满 20 行。测试：20 份结论截到 compact + brief、80 份截到 brief + head，这一段不超过一半、越往后越简、编号都在、查询照样展开
|
2026-10-21 15:47:00 +08:00 |
|
|
ThearchyHelios
|
83c5c04d76
|
关键数的代入式找判定点名的那一段，维度值按算子写段的同一个函数比（_decompose_row 用 app.analysis.phrases.key_text：空值写「（空）」、布尔写「是 / 否」，两列用「·」连），段的叫法也照它写。以前拿原值的 str 去比 subjects，空值、布尔维度的段对不上，代入式退回结果表第一行，写成了反方向变化最大的那一段。测试：点名的段是空值、布尔、又不在第一行时，代入式写的是点名的那段
|
2026-10-21 15:41:38 +08:00 |
|
|
ThearchyHelios
|
2e57c401e6
|
说法核对不核表格正文的格（原来只跳过表头）：一格是一个值不是一句话，写作者表格里状态列的「异常」、说明列的「主要来自线上」「持续增长」每一格都单独报没挂分析结论；裁判的预筛 judge.claim_priority 本来就不送表格的格。测试：表格九格都不报，表格外的列表照核，组装和复核一样
|
2026-10-21 15:38:54 +08:00 |
|
|
ThearchyHelios
|
7e2ee912b3
|
结论句的判定回到原来的方向词、因果词（evidence._DIRECTIONAL 照 main 原样）：W1-d 为了让裁判优先判判断句把「主要、集中、异常、偏离、持续、趋势、显著、大幅、新高、新低、抵消、分散」等加进了 _DIRECTIONAL，可 _classify 用同一个正则认结论句，没有数字、没有引用的「下面是主要渠道的表现。」「促销期间活动效果显著。」「整体运行平稳，未见异常。」就成了结论句，结论句策略要求挂依据（模板 ⑨ 和已发布的受管版本都这么写）时计入缺口、出具降档，改了已发布版本的档位；出口的 io._concluding 也照它认代码块里的正文。扩充的判断词挪到 judge._JUDGEMENT，只给 claim_priority 排送判的先后（结论句里有它们的排第二）。测试：判断词让结论句先送判、不让连接性的话变成结论句；结论句要挂依据、出口带契约的周报多写这三句，档位照旧 formal、没挂依据的结论 0 句
|
2026-10-21 15:37:41 +08:00 |
|
|
ThearchyHelios
|
8a62826034
|
证据接口重新渲染分析结论的引用改用组装、出口复核同一个函数：_analysis_rendered 按封存的结论走 evidence.resolve_ref（resolve_ref 加 display，按文档记下的单元格显示规则），结果表的格照结果表记的列类型、显示规则、标识列渲染，和组装时的 _resolve_cell 一致。以前不看列类型和显示规则，文本码值「1203」重渲染成「1,203」、ISO 日期时间带着 T，render_ok 为假，证据面板和导出页报假的「与按结论渲染的结果不一致」。片段上没记引用的（口径卡指标上的可比性、分析范围的编号）照旧按判定语渲染。测试：门店码、时段两种格在片段接口和导出页数据块里都 render_ok
|
2026-10-21 15:32:21 +08:00 |
|
|
ThearchyHelios
|
3b06202b15
|
口径卡的可比性挂钩只在两期之间做：两份同形 SQL 不同的字面量里至少有一对两边都是日期或期次（_dated_pairs：data/coverage 认出的时间条件的界，含 yr = 2026、month = '2026-09'、week = '2026-W41'、按运行当天现算的 date('now', '-7 days')，加上别处认得出的真正的日期，和可比性算子「同口径」一项同一套认法）才查；只差地区、门店号这类字面量的（华东对华南的倍数、门店 1203 对 1204）是两段不是两期，不查、不记日志，带契约的出口不再因此判两期不可比、降档。日期和地区都不同的照查，真算子判不可比。基期、本期的先后只按日期、期次排（_period_key：真正的日期按那一天，月、周、季、年按同一种写法的先后），去掉会把门店号、偏移量当期次的 [\dW\-/Qq]+ 那条；排不出的照旧是表达式里先出现的那份算本期。读查询快照放进线程（asyncio.to_thread），不占着事件循环。测试：只差地区、只差门店号不查，日期和地区都不同照查且按日期定基期，各种写法认不认得出、先后怎么排，真算子下华东对华南的倍数照常正式出具、日期和地区都不同的判不可比降档
|
2026-10-21 15:28:59 +08:00 |
|
|
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 |
|
|
ThearchyHelios
|
a81a0a66ac
|
合入 W1-d 说法核对：说法表与绑定、check / strict / off、出口独立复核与文档版本、分析范围、血缘口子、G3
|
2026-10-21 14:00:07 +08:00 |
|
|
ThearchyHelios
|
4afe8e6f4f
|
合入 W1-c 入口：五个分析工具与方法注入、分析卡、口径卡可比性、运行对比按项对齐、设置与快照、使用者白名单
|
2026-10-21 13:59:06 +08:00 |
|
|
ThearchyHelios
|
cb2fdd860f
|
证据接入按 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 |
|
|
ThearchyHelios
|
aa62393edb
|
出口认分析结论的引用：报告引用的判定语、具名标量、当依据的分析结论按结论工件记进「引用的查询」（结果表的格原来就会走到），顺着结论的输入找到查询，输入查询没通过 SQL 检查的照样计入缺口（受影响的引用写「A1（判定语）」「A1「top_share」」「A1（结论依据）」）；逐个数字的出处里具名标量照实记成分析结论（analysis: A1.top_share），不再记成空的运行输入
|
2026-10-21 13:29:23 +08:00 |
|
|
ThearchyHelios
|
472115c817
|
说法核对接上证据接入（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 |
|
|
ThearchyHelios
|
71dc16bc1a
|
分析能力入口（七）：按 W1-a 算子库的实际接口对齐。工具参数名以算子为准：差异检验的均值是 mean / sd / n 或 sum / sumsq / n，逐行是 value，可选 pairs / reference；可比性检查另收可选的 measure、grain（不收 label）；分析卡的参数校验用同一份定义，运行当天、目录事实、下钻层数由算子自己记，分析项里写了不收。交给算子的输入是工件库里那份查询快照原样（含 SQL 检查结果 checks、「查询区间里这张表没有数据」no_data、查询当时记下的遮罩），加上出处和遮罩列（数据源设的、按 SQL 认出改了名字的、遮罩运行里查询时就遮掉的），合并查询写明 sqlite 方言；agent 的容器在分析前把每份换成完整快照（每份只取回一次）。探查器改用 analysis.make_prober(数据源名 → 按运行固定版本解析出的源，coverage.Cache 一个节点里共用)，剖析事实一律用 analysis.probe.profile_facts（查询工具的覆盖检查也改用它，原来那段同样的取法删掉）。分析次数用完交回 analysis.exhausted 的那句；口径卡的可比性写成 {工件, 判定码, 判定语, analysis.comparable_reasons 拆出的原因}，删掉自己拆原因的那段。加真算子的端到端测试：agent 变化拆解并下钻（父结论按内容哈希认）、审批恢复重放不再算、分析卡的波动基线和变化拆解（本期完整按现查的表范围判）、口径卡跑真可比性检查（可比、有条件可比带原因），每份结论都按封存的工件复算、逐字段相同
|
2026-10-21 13:27:12 +08:00 |
|
|
ThearchyHelios
|
9f014560fe
|
Merge branch 'an1/b' into an1/d
|
2026-10-21 13:19:10 +08:00 |
|
|
ThearchyHelios
|
bea1119a6c
|
说法核对按算子的真实结论形状对齐：点名的段只认拆解的维度列（params.by，乘积拆解是因子叫法）和差异检验的 a、b 两组，别的算子没有段；比率拆解的 n_base、n_target 是度量列；「抵消」除了 offset 也认判定为基本持平、各段有涨有跌的（持平的判定语本身说了此消彼长）
|
2026-10-21 13:16:48 +08:00 |
|
|
ThearchyHelios
|
a690b5c571
|
门禁 G3 加一条：受管级别的报告撰写节点要把「分析说法核对」设为严格（REPORT_POLICY 加 analysis_claims: strict，没写时运行时是 check、只标注）。受管级别挡住发布、已发布级别只警告，写错的值交给校验；已经发布的版本照常运行（按缺省的 check 核），下次发布才按新规则查。同一份要求自动跟到自动修复（一键写明）、一键升级成受管、按口径出具起草的报告节点；自动修复「不许放宽」的判断认这一项（从严格改回去算放宽）；白话补一句分析说法；模板 ⑨ 的报告节点补上这一项，拿来照旧能发布成受管。各处「受管要求都满足」的图（测试夹具）跟着补上这一项
|
2026-10-21 13:13:04 +08:00 |
|
|
ThearchyHelios
|
8a5f96be4b
|
出口契约：分析说法出口独立复核、指标可比性、引用模式的血缘口子。引用模式下 verify_doc 按文档记下的那一项再核一遍分析说法：处置取文档和报告节点产出里更严的那个，strict 有违规记一条缺口（降档），报告节点报上来的同一条不重复收，check 只写进出具声明（analysis_claims，counted 为 false），要求 strict 却没有核对记录的照实记缺口，老文档不核。口径卡指标上的可比性（MetricComparability）：报告引用了的（引用模式按文档，别的按数字回指）和契约必需的指标两期不可比记缺口，有条件可比的只写进出具声明（comparability）。血缘（D15）：收齐报告引用的指标（[[m:]] 片段和句末依据里的 m:），按卡上记的输入认追不到原始数据的，受管级别的正式运行记缺口，其余写进出具声明的 untraced（counted 为 false）；_untraced_gaps 拆出可传子集的 _untraced。现有受管正式运行的两条用例（裁判判档）档位不变、缺口里多一条血缘，断言不涉及缺口列表，不用改
|
2026-10-21 13:12:24 +08:00 |
|
|
ThearchyHelios
|
767b1ac07a
|
报告撰写节点加「分析说法核对」（analysis_claims：off / check / strict，缺省 check）和「分析范围」（analysis_scope：auto / off，缺省 auto），画布校验和执行时报同一句话（report.analysis_claims_invalid / analysis_scope_invalid），界面叫法进 labels，运行对比登记这两项。check：判断词没挂对分析结论、原因没有依据的句子交回写作者重写一次（不按最多重写次数反复），仍有的标在报告里、写一条日志 report_analysis_claims，不影响档位；strict：按最多重写次数重写，仍有的写进产出的 issuance_gaps（另记 analysis_gap）；两种都不让节点失败（不挡生成）；off 不核、写作规则和文档一字不变；升级前发起的运行照旧。写作者角色改成「挑重点、组织结构、说清变化；有分析结论时说清变化来自哪里；原因只按证据写」，写作规则按目录里有没有分析结论各加一段判断词规则，重写请求列出违规和修法；这次有分析结论、取值 auto 时每一稿文档都带系统写的 analysis_scope。产出和 report.checked 记下处置。几个测裁判、结论句策略、审计表的用例写作者那句「增长主要来自新客」没有拆解可挂，把分析说法核对关掉
|
2026-10-21 13:12:15 +08:00 |
|
|
ThearchyHelios
|
a6f7572a9e
|
报告文档里系统写的「分析范围」（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 |
|
|
ThearchyHelios
|
7acee0faed
|
分析说法核对的说法表与绑定（engine/analysis_claims）：判断词分来源、分散、抵消、结构、异常、新高新低、正常、趋势、无趋势、差异、无差异、因果几类，一处定义、带版本（LEXICON_VERSION 1）；只收强判断词（「持续」要跟着涨跌、「异常」后面是订单数据这类名词或前面是数据系统的不算、「相当」只认句读前的，「大幅」按细案收进异常类、要跟着涨跌动词）；否定（前 4 个字以内、跳过「出现」「明显」这类填充词，「不但」「不少」「无论」不算）翻到反面类；来源与因果分界（因果词所在分句点名的是拆解的段或因子按来源核），推测说法、同句的知识库原话和运行输入豁免因果，说的是数据本身的原因不算；不扫判定语（a:）、知识库原话（q:）、别的引用渲染出来的字、标题、代码块、表头。绑定：一句的分析依据按这次重新解析的引用算，A 条目经 contract.catalog_result 读，核判定、点名的段（全半角归一）、拖累拉动的方向、新高新低、连续的期数，挂了算不了的结论算对不上；违规三种（analysis_claim_uncited / analysis_claim_mismatch / causal_unsupported），每条带判断词、句子、类、要的 op、这句挂的 A、给人看的和交回写作者的各一句，同一分句同一类只报一处。挂点：compose_doc 收 analysis_claims（check / strict）时文档顶层记下处置和说法表版本，verify_doc 只核记了这一项的文档（按记下的版本，认不出的记 bad_schema），老文档复核结果和统计一字不变；_DIRECTIONAL 补主要、集中、异常、偏离、持续、趋势、显著、明显高于 / 低于等预筛词（列提纲、建议、引出图表的写法除外），裁判优先判这类句子
|
2026-10-21 13:11:56 +08:00 |
|
|
ThearchyHelios
|
7e95703a94
|
结论句裁判与口径账本认分析结论：引用了分析结论的句子，裁判摘录里给方法与版本、判定语、判定标准、关键数、附带说明、结果表（被引用的行先给）、输入取自哪几个 Q 用了哪几列和它们的 SQL、下钻自哪个 A（核查 agent 的摘录照旧分段遮）；摘录里有分析结论时裁判规则另加一条（判定是系统算的，只判句子说法和判定是否一致，分析说明不了原因），没有分析结论的报告规则一字不差。口径账本不给分析结论里的数（判定语、具名标量、结果表的格）标口径、不按它们投影比对、不进整题判断的计数，也不算成没比对
|
2026-10-21 13:07:36 +08:00 |
|
|
ThearchyHelios
|
855a559300
|
分析结论进证据链（引擎）：台账 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 |
|
|
ThearchyHelios
|
6a96083dcb
|
分析能力入口（六）：口径卡的可比性挂钩（engine/nodes/metrics.py 的 _comparability）：一个指标的输入里取自查询快照的格（cell() 取的格、按位置取的格、Agent 按出处交来的字段）恰好落在两份不同的快照上，两份 SQL 按规范化（data/sql_semantics.normalize_sql，按数据源的方言）同形、只差字面量、查的是同一个数据源时（本周对上周），口径卡执行时调分析算子 comparable（早的那期作基期：第一处不同的字面量是日期或同样写法的期次的按先后，认不出的表达式里先出现的那份算本期），结论落成工件，指标上记 comparability（contract.MetricComparability：工件、判定、判定语、fail / warn 的原因，原因先按结论表的 status 一列取，没有再按判定语拆）。SQL 结构不同（退款额 / 销售额）、两次是同一条 SQL、数据源不同的不是同一个量的两期，不查也不记日志；同一对快照一张卡里只查一次。快照读不出来、探查失败、算子出错、算不了、还没有算子（第 1 波的 run 抛 NotImplementedError）都不挡口径卡，照实记一条 metric_comparability_skipped，这个指标不写 comparability
|
2026-10-21 13:03:38 +08:00 |
|
|
ThearchyHelios
|
e079e0ba88
|
分析能力入口（五）：运行对比里两次运行的分析卡按节点和项的标识对齐（engine/compare.py 的 analyses，最小可用）：按封存范围内每项一条的 analysis.end 认，循环里执行了几次的取最后一次（照实写进说明）；每项列出两次的状态、判定、方向、判定语和结论工件，change 写 same / verdict（状态或判定变了）/ phrase（判定一样、判定语里的数变了）/ added / removed，不拆变化来源
|
2026-10-21 13:03:29 +08:00 |
|
|
ThearchyHelios
|
fc6d4bd92d
|
分析能力入口（四）：发起运行时把分析设置快照进 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 |
|
|
ThearchyHelios
|
3009a43cee
|
分析能力入口（三）：分析卡（节点类型 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 |
|
|
ThearchyHelios
|
601b84918d
|
分析能力入口（二）：五个 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 |
|
|
ThearchyHelios
|
a86991b57f
|
双盲复算：盲算触顶、按无法复算记时（_limit_text 那一路），把盲算交回的理由（渲染后的正文，已经过遮罩）截一段带进原因（「盲算已达每项最多查询次数（1 次）；盲算交回的理由：…」），审批卡、缺口说明上看得到它查到了什么，没有理由的照旧。原值所在的格子落在「查询区间里这张表没有数据」的列上时不派盲算、按无法复算记；盲算交回的格子落在这样的列上时不判一致、按无法复算记；原因都写「查询区间里这张表没有数据（…）」
|
2026-10-20 10:33:34 +08:00 |
|
|
ThearchyHelios
|
6fa2e297db
|
口径卡、报告、出具、复核认「查询区间里这张表没有数据」：口径卡按输入的快照 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 |
|
|
ThearchyHelios
|
301bbd55f3
|
口径卡分母为 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 |
|
|
ThearchyHelios
|
6b68961c65
|
助手把操作写成工具调用格式时照操作读；一个能落地的操作都没有时当场纠正一次；报错按诊断照实说
部署上画布助手连着几轮报「助手本轮未完成：模型没有给出任何修改，也没有说明原因」，又试了一次才成。本地用同一网关、同一模型、同一底图和需求重放复现：模型思考里写着「先输出 look」，正文却是一段 DeepSeek 的 DSML 工具调用（invoke name="look"，参数 need、targets），意图和参数都对，只是不是约定的单行 JSON。读流只认 JSON 和原生工具调用，于是一个操作都没认出、整轮报错；画布不处理 next=retry，点重试原样再发，几率不变。提示词里「输出这一行就停下，系统把结果交回来」很像工具调用，却从没说这里没有工具调用接口。
- engine/toolcalls：take_leaked_calls 读写成文字的工具调用（DSML 竖线一到两个、带不带空格，<function_calls><invoke>，<tool_call>{name, arguments}，DeepSeek 特殊 token 两种排法），按出现先后交出已写完的调用和没写完的那一段；final 时参数写完整、只差结尾的补上结尾再读，写到一半的不硬读。_MARKUP 补认 DSML 结尾标签和 function_calls / tool_calls 包装（agent 节点的识别跟着受益）。has_markup 只认标记本身
- copilot_gen._iter_ops：从有标记的那一行起攒，一次调用写完就按名字读成操作（名字是操作名的才认，规矩同原生工具调用 _call_op；op 写在最前，接着写时交回模型的是约定写法），读到 look 照样停下去查看；读不出的记「工具调用标记的名字不认识 / 参数解析不了 / 没写完」；raw 交出正文开头一段
- Generation：起草时一次调用读完、到这时还没有能落地的操作（plan、look 不算——查看完接着写什么都没认出的整轮照样是空的），把原话交回去、附 StreamDiagnosis.correction 那句纠正，当场重写一次（FORMAT_NUDGE_PROMPT，每轮一次）；什么都没写的把纠正接在最后那条消息后面。诊断按次收（absorb），记 nudged。写成标记被读出、当场纠正都打 info 日志
- 报错说法：Generation.empty 默认用 StreamDiagnosis.headline（写成工具调用格式 / 只写了思考 / 什么都没有输出 / 格式不对 / 只说了打算），不再一律「也没有说明原因」；摘要注明当场纠正过
- 提示词：look 用法（四个入口共用）和画布、应用、蓝图的输出格式都写明这里没有工具调用接口
- 问数据失败原因 meta.cause（kind=copilot）带上 code、diagnostics
验证：本地真模型重放，修后 DSML 没再出现、都正常交付；把第一次调用换成读不出的 DSML 后交给真模型，都被当场纠正救回来（先 look 再出操作）；原先抓到的真实 DSML 原文离线读成 look。测试：新增 tests/test_copilot_markup_ops.py（各写法、流式切碎、和 JSON 行混写、读不出的诊断、DSML look 驱动真查看、说明文字 / 只写思考 / 只写 plan / 查看后空续写的纠正、只纠正一次、画布流不报错、报错说法、提示词）；空生成相关的旧测试按「一次生成先纠正一次」更新（基线夹具 no_ops 的说法）。后端全量通过。
|
2026-10-19 22:48:23 +08:00 |
|
|
ThearchyHelios
|
d6c22440df
|
名字里的数字涂白（_name_masks）先按数字串挡一道：名字一字不差出现、前后不紧挨着数字时，名字里的每一串数字在正文里都是完整的一串，正文里没有这串数字的名字不再逐个查找，快照行多时不拖慢组装和复核；放过的范围不变
|
2026-10-19 17:55:02 +08:00 |
|
|
ThearchyHelios
|
a92f590799
|
字段标记紧跟在同一张表名后面时只显示字段名（部署上的「取自 某表 的 某表.某列」）：[[c:表.列]] 前面紧挨着（隔空白、「的」「中的」「里的」）刚写过同一张表的名字——写成文字或 [[t:同一张表]] 都算，按 name_key 比，带库名的全名、末段都认，英文名前面还连着字母的不算——正文只显示列名，出处、证据标识照旧是那个字段，引用上记 short: true，复核照它核对显示的字；没有这一项的老文档照旧按全名核对。整篇组装、render_markers、流式渲染一致（流式渲染记着已放出正文的末尾一截）。写作规则（ENTITY_RULES）写一句
|
2026-10-19 17:55:02 +08:00 |
|
|
ThearchyHelios
|
ba4c604539
|
数字标记后面重复写的单字单位也去掉（部署上的「覆盖 8条 条产线」）：以前单字的单位后面紧跟着字时一律不动，现在只在它和后面的字连起来是一个更长的单位（人次、个月、台套、元/…，_LONGER_UNIT）时不动，让「人」对「人次」这样的不一致照旧露出来；「条产线」「人参加」照样去掉重复的那个字，流式渲染一致。写作规则加一条 UNIT_RULE（[[m:]]、[[v:]] 自带单位，后面不要再写一遍），助手节点手册讲 [[m:]] 的那一行也写明
|
2026-10-19 17:55:02 +08:00 |
|
|
ThearchyHelios
|
e9bb0afd4c
|
报告里标识列的数不分千位（产线编码 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 |
|