156 Commits

Author	SHA1	Message	Date
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	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	a02dc41424	合入复核修复（说法核对）：结论句判定回到原来的词表（扩充的判断词只给裁判排先后）、表格正文不核、补因果与来源的口子、说法表按样本调整（96 句样本表）、连续按末尾方向核、复核认三种日志且只写说明、分析结论算可引用的来源、自动修复对认不出的取值照 claims 做、候选维度写明只认码值表、scan 加只按词认	2026-10-21 17:12:18 +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	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	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	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	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	aa62393edb	出口认分析结论的引用：报告引用的判定语、具名标量、当依据的分析结论按结论工件记进「引用的查询」（结果表的格原来就会走到），顺着结论的输入找到查询，输入查询没通过 SQL 检查的照样计入缺口（受影响的引用写「A1（判定语）」「A1「top_share」」「A1（结论依据）」）；逐个数字的出处里具名标量照实记成分析结论（analysis: A1.top_share），不再记成空的运行输入	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	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	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	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	ba4c604539	数字标记后面重复写的单字单位也去掉（部署上的「覆盖 8条 条产线」）：以前单字的单位后面紧跟着字时一律不动，现在只在它和后面的字连起来是一个更长的单位（人次、个月、台套、元/…，_LONGER_UNIT）时不动，让「人」对「人次」这样的不一致照旧露出来；「条产线」「人参加」照样去掉重复的那个字，流式渲染一致。写作规则加一条 UNIT_RULE（[[m:]]、[[v:]] 自带单位，后面不要再写一遍），助手节点手册讲 [[m:]] 的那一行也写明	2026-10-19 17:55:02 +08:00
ThearchyHelios	41b350b87c	相对日期一律按运行当天算：助手节点手册的搭图规则（画布、问数据共用）加第 6 条——「今天、昨天、上周、本月、去年」按运行当天算，SQL 用方言里取当天的写法、agent 先调 current_time，不用 MAX(日期) 去推「上周」，要说数据最新到哪天就另取一列；报告写作规则加一条（period_rule），告诉写作者今天是哪天、上周是哪几天：数据没覆盖问的那段时间时先照实说、写明数据最新到哪天，最近一段的数可以给但写具体起止日期，不叫它「上周」「本月」	2026-10-19 16:53:46 +08:00
ThearchyHelios	5dfe2e7fd1	report.failed_queries 不再把「写错一条、下一条就改对了」当取数失败：同一个节点里，失败之后还有一条同一数据源的成功平台查询、读的表覆盖了失败那条的表（按 sql_semantics.facets 取表；失败那条解析不了就按同一数据源之后有成功的查询认），这次失败算已被替代，不进写作提示、不记 report_queries_failed；一次成功的都没有时照旧写「这次一次成功的查询都没有」	2026-10-19 16:47:07 +08:00
ThearchyHelios	1e87504e5c	复核把「首稿没过、重写后已通过」当缺口：report_repair、report_rewrite 这类「改过一次」的信号按同一个报告节点最后一次 report.checked 定档——最终通过的（没有违规；裁判摘要里不再有证据不支持的句子）不进复核的异常清单，复核模型被别的信号叫起来时，说明里另起一节「已经处理好的」写「报告「x」首稿有 N 处没过核对，重写后已全部通过」，不再写成「核对仍未全部通过、可能不准」；最终没过的照旧记缺口。report_repair、report_rewrite 的日志带上处数	2026-10-19 16:43:54 +08:00
ThearchyHelios	4e3623885b	合入 W2-a 的复核修复（nr8/a：导入的 NOT NULL 补值与孤儿行、收尾 dispose、sslmode 换算、PostgreSQL 写入去 NUL、不分大小写搜索 contains_ci、json_eq 两库同语义、JSON 守卫、用户可见列表补决胜键、bubblewrap --clearenv、部署脚本与原子写的几处、README 连接数预算） ... # Conflicts: # backend/app/api/schedules.py # backend/app/main.py	2026-10-19 12:21:38 +08:00
ThearchyHelios	0d9f1d9339	用户看得到的列表补决胜键（复核 R-a9）：按名称、时间等可能并列的排序后面补上同一个模型的 id，并列时两种库排出来一样 ... - 实测 /api/evals/calibers、/api/schedules/trigger-options 按 Workflow.name 排序遇同名并列时 SQLite、PostgreSQL 顺序不同。用 AST 逐个过了一遍 order_by：最后一个排序键是 created_at / updated_at / last_active_at / at / name / 各种 *_at 之类、不唯一的列，又不带 DISTINCT、GROUP BY 的，补「, 模型.id」（降序补 id.desc()），共 104 处，分布在 api、apps、auth、blueprints、chat、data、engine、eval、ledger、look、memory、process、providers、scheduler（runs.py 里的三处在上一个提交里） - 按唯一列（seq、version、唯一的 name）排的不动；按聚合、coalesce 之类表达式排的说明见 db/postgres	2026-10-19 12:07:06 +08:00
ThearchyHelios	c59b085922	子工作流里的写入跨升级认旧键时按事件和内容认是谁的、是哪一笔（复核 L1、L2）：升级前子图里的写入按子图里的 id 记键，和父图同名节点的键一样。以前父图有同名节点时一律不认旧键：子图里结果未知的那一笔核实为已生效后接着跑，用新键又发一笔；父图那个节点按自己的键找到子图那一笔、交回它的回执，自己那笔一直发不出去。现在一条记录是哪个节点写的按它的 action.* 事件上记的节点 id 认（认不出的按能力和内容指纹）：按自己的键找到别人那一笔的换一个只属于自己的键；认旧键时还要内容指纹是这一次的——跨升级的循环第二轮按老算法同样是第 1 次执行，找到的是第一轮那一笔，金额不同就照常发，不再记「已经生效」。去掉不再用的最外层节点 id 传递；改对两处过时的说明（审批恢复时子图从自己的断点接着跑；终态事件的途经驳回含子工作流里的）。补跨版本测试：同一个进程里先装成升级前的代码跑到挂起、再换回现在的代码接着跑	2026-10-19 11:43:41 +08:00
ThearchyHelios	8ba0b27097	同一个子工作流节点执行多次时子图里的节点分得开：子图这一次跑过的每一步交回父图的 trail（节点 id 接上前缀），下一次执行从那里接着数第几次执行（engine/evidence.next_exec），台账、证据面板不再几条都记第 1 次；写外部系统的幂等键按这次运行里的节点 id 算（「sub/pay」）。以前循环里第二轮的子图写入算出和第一轮同一个键，交回第一轮的回执、外部系统少收一笔，父图里同名的节点、套同一个工作流的两个子工作流节点也撞键。升级前停在子图里的运行恢复时照旧按子图里的 id 认出已经生效的那一笔、不重发（父图里有同名节点时不认）	2026-10-19 09:16:14 +08:00
ThearchyHelios	04d80472f9	子工作流里的反方审稿按全局 id 记它审的报告：审稿记录和工件上的报告写这次运行里的 id（「sub/write」，同 report.checked、报告文档，第 1 波 B1 修过报告节点同样的问题），证据面板连子工作流里的审稿一起认（_Sealed.nodes_of nested），点开子图里那份报告的句子认得出审它的那次审稿；审批卡上的报告按全局 id 记，打开证据面板、审批质询对得上；单句面板的报告名写「子工作流 › 报告」，不写内部 id	2026-10-19 09:08:45 +08:00
ThearchyHelios	17e99cd76c	驳回出口之后，待办、通知、Webhook 照实说转到哪：中断内容带上驳回之后去哪（engine/replay.reject_route：接了驳回出口写转到哪几步，没接的写运行就此结束，审批没接、没设驳回即终止的写这一路到此为止），待办卡的提示、驳回按钮、驳回后的提示、处理过的「结果」照它说，不再一律写「转入驳回分支」「本次运行终止」；超时驳回不再露出英文结论码；双盲裁决、动作确认被驳回的提示同样照它说。子工作流里的关卡走驳回出口时，名字记成「子工作流 › x」（RunContext.global_label），走过的那几步交回父图的 trail，父运行的终态事件照实带上途经驳回，实例页、通知写「「子工作流 › 把关」被驳回，转到「子工作流 › 退回」」，不写内部 id、不写成已完成。定时任务的 Webhook：照驳回那条路成功结束的，标题、状态写途经驳回，另起一行写谁被驳回、转到哪一步	2026-10-19 08:59:15 +08:00
ThearchyHelios	06286deefa	上游查库全失败时报告照实说没查到：报告节点写作前从上游 Agent 的调用记录里找出失败的平台查询（engine/nodes/report.failed_queries），写作提示里多一节「没有查到的数据」列出哪几次、原因第一行；一次成功的查询都没有时不许写单元格引用、照实写没查到和怎么排查，重写请求里同一句；记一条 report_queries_failed 提醒。以前写作者照着上游文字里的 SQL 和列名写出引用不存在的 Q1…，重写一次还是那样，答案里留着没填上的 ⟦?v:Q1…⟧	2026-10-19 08:23:29 +08:00
ThearchyHelios	32dbfcfb52	复核修正（后端）：子图里的报告不再被判「疑似被修改」、驳回出口的双盲裁决照样降档、可验证报告与推演按卡所在的层找产出、子图那一步写名字 ... - B1 子工作流里有报告撰写节点时：它的 report.checked 进了父运行（节点 id「sub/write」），报告文档却记子图里的 id「write」， 证据接口、可验证报告、质询拿两边一比判「疑似被修改」，评测读答案也说答案不能当证据。 - nodes/report：报告文档、产出工件记这次运行里的节点 id（ctx.run.global_id），和事件同一个；nodes/io 子图自己的出具契约 按同一个 id 核对，_issuance.report.node_id 同样写这次运行里的 id - api/evidence：_reports 默认只认父图上的报告（子图的报告是子工作流那一步内部的东西，父图的答案是子工作流出口的值）， nested=True 连子图里的一起给；点名要子图报告的（?report=sub/write）照样点得开（_named_reports）；按成果挑报告的兜底 不再挑中子图的报告。成果上没有 _issuance 时退回最后一条 issuance 事件，子图成果节点的那条不认 - bundle：出具档位（_tier）同样不认子图成果节点的 issuance，verifier.js 同一个认法；子图报告的文档在引用链上照常核对 - B2 双盲裁决被驳回、走驳回出口接到出具成果时：节点产出换成 exit_payload，出具缺口和 dual_check 台账条目跟着丢了，审核人驳回的 那组数照样完整出具（比选「两边都不对」还宽）。NodeRejected 加 exit_updates（节点在驳回之前已算出的产出字段、台账、用量）， compiler._rejected_exit 并进去；双盲复算驳回时照记缺口「指标「X」两路结果不一致，审核人驳回了裁决」和一条结论为驳回的 dual_check。核对过别的关卡：人工节点、工具调用审批、动作确认、代码执行审批都在产出缺口、台账之前就被驳回，没有可丢的 - B4 子图里的卡转抄同一张子图里的卡、按位置取格：可验证报告（bundle/build._outputs_of）和推演（api/whatif._sources）按这次 运行里的 id 查产出，子图卡上记的是子图里的 id，查不到就整张遮住、推演不了；父图有同名节点时还拿父图那个当依据。改成按卡 所在那一层的 id 查（engine/lineage.in_scope / scoped_id，证据面板 _InputMasks 同一个认法），转抄的卡认不出时的兜底同样换层 - B6 子图里的一步出错、被驳回后 Run.error_node_id 是「sub/x」：实例页（apps/resolve）、通知（notify/service）照终态事件上记的 名字写「子工作流 › x」（run_node_label），不露出内部 id 测试：test_subgraph_evidence（子图含报告：证据图按父图、评测读答案不报被改、子图报告点得开、可验证报告核对通过且不写子图的 档位、子图自己的契约照常；子图卡在可验证报告里不被遮、推演还原得出、父图同名节点不当依据；子图那一步的名字）、 test_dual_check_node（驳回出口接到出具成果照样降档、台账照记、证据面板认得）。每条都去掉修复回跑过，确实失败	2026-10-18 18:15:37 +08:00
ThearchyHelios	3998e821dc	子工作流的证据交回父图（后端）：子图每一步进同一个运行、台账和口径卡交回、出口字段带出处、父图跨子图往下追 ... 调查时发现：run_subgraph 只设了节点 id 前缀（node_prefix）没用上，子图在父节点里用 ainvoke 跑，LangGraph 不把它的 custom 事件交给父图的流——子图里每一步在运行的事件里一条都没有，时间线看不到、封存也不含它查过的数。「事件本来就在同一个 运行里」此前并不成立（docs/design/orchestration-round/00-总方案.md §2）。 - engine/context + nodes/multi：子图拿到父运行的写入口（STREAM_KEY）和前缀（PREFIX_KEY），子图里的节点经它发事件，节点 id 「子工作流节点 id/…」，嵌套的一层层接上；工件按这次运行里的 id 记。子图里报的错（含被驳回）交回时节点 id 换成这一层的、 名字接上子工作流（runner 的 run.failed / run.cancelled 写「子工作流 › 那一步」），不再和父图里同名的节点混在一起 - nodes/multi：子图的台账条目加前缀并进父图 evidence（父图报告的目录据此收进子图里的查询和口径卡）；子图口径卡的产出以 「子工作流节点 id/卡」进父图 nodes；出口每个字段按出口模板认出处（模板整串就是一个取值链、渲染出来正是那个值的才认， 同口径卡认输入的那一套），出自子图运行输入的按子工作流节点的「输入」模板再往父图追一层，追不到的记 subgraph_input - engine/compiler：子工作流节点自己的 node.finished 不再重记交回来的台账条目（子图那几步自己的 node.finished 已经带着） - nodes/metrics：父图口径卡读 nodes.<子图>.output.<字段>（或 assign_to 变量的字段）时接上那个字段的出处，另记 subgraph、 field；经子图出口转抄子图口径卡的指标照样带上不完整、存疑；cell(nodes.<子图>.output.<原样交出的查询结果>, …) 按台账 认出子图里的那份快照 - engine/lineage：静态认法跨子图往下追（出口模板 → 子图里接着认；子图的运行输入按「输入」模板回父图认；最多 3 层）， 和运行时同一套；whole_ref 是两边共用的「整串一个取值链」判断。lint_process.load_subgraphs 往下读嵌套的子工作流， subgraph_spec 给静态认法取图；没读好放进来的照旧停在子工作流节点 - nodes/report：报告收证据的范围加上上游子工作流交回来的（evidence_from 写了子工作流节点的一并算） - nodes/io：指标出具的缺口里，停在子图里的说停在那个子工作流（和静态检查同一句） - api/evidence：卡上记的节点 id 按卡所在那一层认（_scoped：子图里的卡写子图里的 id），转抄、输入、追不到的那几步一路给到 子图里的那一格；子图里的节点按 node.started 记的名字接成「子工作流 › 节点」（node_label、subgraph_label）；双盲复算条目 里的卡 id 同样换成这次运行里的 - apps/resolve：实例进度不单列子图里的步骤 - 口径账本的 use_caliber 不改；比对读封存的查询，子图里的查询如今在封存范围里，照常认得出 测试：test_subgraph_evidence（子图每一步进运行、报错点名子图里那一步、实例进度、父图口径卡跨子图追到查询格并完整出具、 子图里追不到的父图降档、不是整串取值链的停在子工作流、运行输入往父图追、嵌套两层、静态检查与运行时一致（含两层和输入 模板）、父图报告引用子图里的查询和口径卡并一路点到那一格、封存与可验证报告、子图里的遮罩照父图的运行）。去掉「交写入口」 回跑，五条失败（快照不在封存范围里）。后端全量 14472 通过	2026-10-18 16:11:15 +08:00
ThearchyHelios	d57cdcaffc	驳回出口（后端）：审批、补充输入、编辑稿件、动作确认、代码和工具审批、双盲裁决接了「驳回」出口时沿它往下走 ... 以前这六类关卡被驳回一律抛 NodeRejected，运行收成 cancelled + end_reason=rejected，没有「驳回之后走另一条路」 （docs/design/orchestration-round/00-总方案.md §3）。现在画布上多一个可选的「驳回」出口（sourceHandle="rejected"，和 分支、审批同一套连线机制）： - engine/schema：GATE_TYPES（人工、调用工具、沙箱代码、双盲复算）、reject_targets（驳回出口连到哪几步）、approve_mode； 画布校验：别的节点接驳回出口报错（graph.reject_exit_invalid，条件分支的 case 标识可以叫 rejected，不算）；审批同时设了 「驳回即终止运行」和驳回边的给一条提示（human.stop_on_reject_exit） - engine/compiler：接了驳回出口的关卡按出口路由（驳回出口 / 其余是普通出口，连线没写 sourceHandle 的照样是普通出口）； NodeRejected 被接住时这一步正常结束：产出 NodeRejected.exit_payload()（rejected、decision、actor、note、kind、text， 审批另带 approved=false、「结果存为变量」照旧写 false），node.finished 带 outcome=rejected、哪种关卡、结论、谁、备注、 转到哪几步（to），trail 记 outcome=rejected；不重试、不被「出错时继续」接住，照旧 - engine/context：NodeRejected 加 stop（审批明说了驳回即终止的，驳回边照旧走不到）和 exit_payload；动作确认抛在发送之前， 走出口时什么都没发 - engine/runner：成功结束的运行途经驳回出口时，run.finished 带 rejected_via（在哪一步、谁、结论、转到哪），照实说「途经 驳回」；没有途经的终态事件一字不变 - engine/governance：发布检查各级都拦「驳回出口那条路走不到成果节点或结束」（reject_exit.no_end）；退回上游再问一次的放过 - engine/layout：驳回出口排在普通出口下面 - apps/resolve：实例进度写「被驳回，转到「X」」（动作确认写「未确认（被驳回），转到…」，超时驳回写「超时驳回，转到…」）； 实例状态（实例页头、列表、通知同一句）写「「x」被驳回，转到「y」」，走到另一个成果节点的照旧写那个成果节点；退回修改后 又批准了的按批准算；子工作流里的步骤不进实例进度 - 没接出口：行为一字不变（node.failed reason=rejected、运行 cancelled + rejected）；审批没设驳回即终止、没接驳回边的老规矩 照旧。接了驳回边的审批，实例进度那一步的说法从「已驳回」改成「被驳回，转到「已退回」」（test_app_instance_page 跟着改） 另：engine/context 的 RunContext 加 prefix / global_id、事件经 stream_writer 发（子工作流把父运行的写入口交下来）， 这一步本身不改变最外层的事件，下一个提交接上子工作流 测试：test_reject_exit（五类关卡接了出口各走一遍、批准走普通出口、超时驳回走出口、没接一字不变、驳回即终止优先、 重试和出错时继续不管驳回、退回修改再问一次、校验与发布检查、布局、实例进度）；test_process_actions（动作确认走出口 不发送）；test_dual_check_node（裁决走出口）	2026-10-18 15:56:29 +08:00
ThearchyHelios	d4f1ba8dd4	给评测留一个按引用的列投影的入口（referenced_of），顺手折行、补模块说明 ... - ledger/match.referenced_of(sealed)：这次运行封存的报告引用了哪条查询的哪几列，正好是 compare_queries 的 referenced。 评测逐题比 SQL（eval/score.sql_match，另一组在改）传它，就和账本一样按引用的列投影，不必自己再拼一遍。compute 和它 共用读指标集的那一段（_card_loader）。 - data/sql_semantics 模块说明的「几处共用这里」补上模板绑定、按引用的列投影、同一个形状三处。 - 本轮几处新代码折到 120 列以内（只换行，不改逻辑）。 测试：tests/test_ledger_projection.py 的整题等价那条另核 referenced_of 交回的就是被引用的那一列。	2026-10-17 12:22:48 +08:00
ThearchyHelios	c3123e3818	转抄口径卡指标的出处跨卡往下追，对账、召回运行按追到底的结果判档 ... 对账卡的「口径」、召回卡的「旧版 / 新版」写成 nodes.<口径卡>.metrics[i].value，出处停在「来自口径卡指标」，对账运行、 召回运行一律降档出具（「输入没追到原始数据」）；口径卡自己的指标明明追得到取数查询。 - engine/lineage：metric_copy 认出转抄一个指标的值的写法；traced() 对 via=metric 的输入看 upstream.traced； MAX_COPY_DEPTH = 8。 - engine/nodes/metrics：转抄的输入记 upstream {metric, artifact, depth, traced}——那张卡的指标集落了工件、那个指标的输入 都追到了原始数据（它自己转抄的已经一层层追过，记在它的输入上）、层数没超上限才算追到；超了就算没追到（防环：循环里 抄自己上一轮的卡每一轮多一层）。那个指标不完整、所依据的查询没通过 SQL 检查的，转抄出来的同样不完整、存疑，出具照样 降档：信任按追到底的结果给，不多给。 - api/evidence：转抄的输入后面接一步 upstream（那张卡的那个指标：值、原式、代入式、它的输入、追没追到，取值按同一套遮罩）， 转抄的转抄接着追（同一个指标只接一次、最多 8 层），它的输入落在查询快照上的照常给查询步骤；出处链里遮着的列把这几步 的输入也算上。reconcile.py、recall.py 生成的式子不用改。 - 前端证据面板：新的一节「转抄的口径卡指标」，输入来源里转抄的那一项写清追没追到、点一下跳到那一步，那一步的输入点一下 跳到口径的取数查询（文案进 lib/terms.ts）。check-ledger 加一段：对账结果里点「按口径」的数，一路点到口径的取数查询。 测试：tests/test_metric_copy_lineage.py（转抄、转抄的转抄完整出具；转抄没追到的照样停在那张卡；上游不完整的转抄也不完整； 层数上限；真跑对账、召回都完整出具，出处链接上口径卡那一步、给出口径的取数查询）。去掉 upstream 再跑，5 条失败。	2026-10-17 12:05:12 +08:00
ThearchyHelios	1c8ca4c3d7	合入 W3-c 评测执行：后台评测与无头作答、六种期望五种结论的评分、重评、结论裁判记评测账、统计（Wilson 区间、按角色用量）、对比与 A/B（McNemar）、目录贡献预设、预算与止损、清理；定时任务接题集目标，定时评测有退步 / 没有评完推全局渠道；定时页照实显示非工作流目标	2026-10-16 18:46:44 +08:00
ThearchyHelios	2371e75f17	评测执行的主干：后台评测、无头作答、评分、统计、对比与 A/B、清理（下一轮第 3 波 W3-c 第一段） ... 为什么：第 2 波只有题集和期望答案的来源，评测本身跑不起来。这一段把细案 01 做法 9–12、16、17 的后端接上， 量的是用户在问数据页拿到的同一轮，而不是另抄一份编排。 - eval/answer.py：无头作答，串起 answer_ops → chat/turn 的决定 → launch_run(origin=eval，带目录视图、只读、遮罩) → 等终态（停在审批的取消、记「评测不代批」；驳回记路径「被驳回」）→ review_of_run → 按同一规则重来一次； 工作流题按钉住版本的图跑探索运行（不发正式运行，免得被 pick_base 和应用视图取到）。用量按角色记 - eval/runner.py：用 core/job_runtime，一次评测一个任务，题 × 重复 × 臂一项；A/B 几臂共用期望、同一题同时开跑； 开评拍目录快照、记上传表格版本和表结构哈希的前后；并发不超过 max_parallel 和全局并发的四分之一；每题时限； 评测单独一本账（开跑前估算、每题预留后找补、触顶不再开新题）；止损；能停、只重试没做完的、重启标中断不续跑 - eval/score.py：六种期望、五种结论（量纲不同单列）、维度配对与弱匹配、路径不对直接不通过、口径 dual 两版都报； 逐题 E1 用口径账本的 compare_queries（总方案 X2，不另写 signals）；SCORER_VERSION 可重评（eval/rescore.py，只读封存） - eval/judging.py：结论裁判走按需裁判同一条路（evidence._judge_now），文字要点由裁判判、单列不计准确率；花费经 judge.charged_to 记在评测那本账上（engine/judge.py 只加了一个上下文变量和取账本的一处） - eval/stats.py、eval/compare.py：准确率与可追溯准确率 + Wilson 区间、各项分布、P50/P90、按角色成本、引用率、逐题 E1； 选基准、逐题转移与归因、指纹差异、A/B 配对表与精确 McNemar；「目录贡献」预设对照（当前 vs 关，可加只用已核实） - eval/cleanup.py + core/artifact_store.forget：保留最近 N 次 + 钉住的基线 + A/B 另几臂，删结果、明细工件、底下的运行和 引用行，工件文件一条引用都不剩才删；总表永久保留 - engine/tolerance.py：双盲复算的 _agree / _delta_pct 原样搬来共用（dual_check 改 import，行为不变） - 设置加 eval 一组（builder 读、admin 写）和 GET /api/settings/eval/spend；题集预算在全站缺省上覆盖，每日上限只能往下收 - api/evals.py：发起（单臂 / A/B / 目录贡献预设）、估算、进度、逐题、停止、重试、重评、钉基线、和上一次比、配对表、清理 - main.py 的 lifespan：影子起草和评测的启动整理、关停（评测先于运行停，停时取消自己发起的运行） - 测试：test_eval_e2e（dual_check_shop + 剧本模型：按支付日 330 通过且 SQL 等价，按下单日 310 不通过、差在 time； 目录对照 1:0；和上一次比找到退步、归因做法变）；通知事件、定时接口形状的老测试按新事件和新字段更新	2026-10-16 16:38:09 +08:00
ThearchyHelios	1f8250699c	口径卡来源支持节点改名映射 caliber_from.nodes（口径账本做法 4 ③） ... 为什么：组合式问数、对账、召回要把一份口径的取数节点拷进另一张图，同一张图里放两份口径时节点 id 会撞，拷过来的取数节点得改名（c1_fetch）。以前 caliber_from 只认同名的取数节点，改了名口径卡就取不到输入。 做了什么： - metrics._pinned_caliber 认 caliber_from.nodes {原 id: 新 id}：按语法树把式子里 nodes.<原 id>（含 cell(nodes.X, …) 的第一个参数、nodes['X']）的根换成新 id 再算，字符串字面量里的字不动；指标集的 source 照记映射。映射形状不对节点失败并说清哪一处。 - 画布校验 _caliber_from_issues：映射的形状和运行时同一个判断（rename_problem），改名后的节点要在图里、在口径卡上游。 - 升版检查照常挡、照常记事件，事件带上 caliber_nodes；证据的 _caliber_source / _caliber_upgrade 照带映射。 - 运行对比按映射把式子换回那一版里的写法再比：同一份口径换了节点名不算口径变了。推演按卡上记的改名后的式子原样重算。 - 没写 nodes 的老图一字不差：式子不经 unparse、来源只有三项、升版事件没有新键（单独测）。 测试：tests/test_caliber_from_nodes.py（改写规则、运行时取值、证据链、推演、校验、升版检查、对比、老图不变）。	2026-10-16 16:20:25 +08:00
ThearchyHelios	696cd17a4a	合入 W1-b 已知遗留：人工驳回记成已取消 + end_reason=rejected（不重试、不被出错时继续吞掉），各处照实写「被驳回」；个人渠道「我发起的实例完成 / 失败」生效；导入清单如实记「是否认证」；使用者选人按候选池、开登录时服务端核对；自由形蓝图按导入的图列「谁来做」；tick 按 id 断言	2026-10-16 12:51:43 +08:00
ThearchyHelios	4c0e83bc80	目录视图接缝 data/catalog_view.py（细案 01 做法 5，总方案 X7）：读目录的四处统一经它，「开目录 / 关目录 / 只用已核实的项 / 目录快照」的对照才做得了 ... - CatalogView{mode: live | snapshot | off, statuses: all | reviewed, snapshot}：缺省 live + all，行为和以前一样；reviewed 只留已核实、已确认的项（驳回的项原样留着交给各处，照旧经 visible_notes 去掉，冻结快照和 SQL 检查靠驳回的关系编号认出不该现推的关系——为此在 catalog.py 加 restrict_notes，没给 visible_notes 加参数） - 视图从哪来：运行从 Run.options['catalog_view'] 读（catalog_view.of_run：RunContext.extra 里的发起快照，审批恢复、续跑沿用），ToolContext 多一个 catalog_view，节点（调用工具、llm/agent、多 agent）构造时带上；生成过程从参数读（下一个提交接 answer_ops） - 四处消费一律经它：运行时 db_schema / db_query（tools/datasource._catalog_of，冻结进表结构快照的也是这一份）、look 表详情（TableKind.load、copilot_context.look_service 收 catalog_view）、自查的 SQL 检查器（sqlcheck.load_checkers 收 catalog_view，改用 catalog.read_catalogs 一次读出）、双盲复算（_Sources 带视图，交给盲算的目录和比较 SQL 用的中文名都按它；核查 agent、反方审稿的 db_schema 也按这次运行的视图） - 冻结快照：不是缺省视图的在引用 meta 里记下 catalog_view（不进内容哈希，缺省视图不记，快照和以前一字不差），证据面板据此写得出「本次运行目录：关」 - snapshot 模式只定读法（kind=eval_catalog_snapshot 的工件，{sources: {源 id: {tables: {表: {version, notes}}}}}），内容由第 2 波的题集包写；快照不在了照实报错（CatalogSnapshotMissing），不悄悄退回当前目录 - 新增 tests/test_catalog_view.py：四种视图在四处给的是同一份、缺省等于当前目录、运行从 options 读且冻结 meta 记下、lint（消费模块不许直接 read_catalog / read_entry / 查 CatalogNote）；去掉 _catalog_of 里的视图回跑两项失败	2026-10-16 10:28:01 +08:00
ThearchyHelios	845809486a	驳回不再记成失败（后端）：人的驳回收成 cancelled + end_reason=rejected，消费方都读这一个字段 ... 为什么：动作确认、工具 / 代码审批、审批驳回即终止、填写 / 编辑被驳回、双盲裁决的驳回以前抛普通 NodeError，运行记成 failed。 通知推「实例失败」，定时推「运行失败」，发布单把驳回过的试运行说成「试运行失败了」并挡住发布，记录页还给「继续运行」 （接着跑只会读到同一个驳回答复、再停一次）。人的决定被说成故障，每个消费方各写一份映射，已经漏了四处（05-已知遗留 (a)、总方案 X9）。 做了什么： - engine/context 新增 NodeRejected(NodeError)，带 node_id、kind、decision（reject / expired_reject）、actor、note；六处驳回改抛它， 原话一字不变。待办超时驳回的答复带 expired，Decision.expired 据此记成 expired_reject。 - runner._drive 在通用 except 之前单独接住：status=cancelled、end_reason=rejected、error 写原话、error_node 写那一步， run.cancelled 带 reason/node_id/label/kind/decision/actor/note；关审批、回收沙箱、关流、封存走取消的那一套。手动停止 （执行中取消、放弃断点上的运行）写 end_reason=stopped，run.cancelled 带 reason=stopped。 - 继续运行：被驳回的 409 code=run_rejected「被驳回的运行不能接着跑：改好内容后重新发起」；存量 failed+驳回（失败那一步上 最近一条处理完的待办是驳回，和实例页同一份判断 resolve.legacy_rejected）也拒。RunOut 带 end_reason。 - apps/resolve.instance_state：cancelled+rejected 和存量 failed+驳回说同一句（「「付款」未确认（被驳回）」「「x」被驳回」）。 - notify_run：状态那一句取自 instance_state，被驳回的走「实例结束」、ok=False，走到「已退回」成果的不再写「已完成」； 手动停止照旧不推。顺带修 04-对外集成与触达 B1：发起人是认证身份（run.origin.actor_verified）时 users 传 [started_by]， 个人渠道订阅了实例完成 / 失败终于收得到；自报署名不算。 - 定时 webhook：cancelled+rejected 按「运行结束」推「未出具（被驳回）」、写驳回的那一步，不写备注和原话、不画成功色； 手动停止仍不推。 - 发布单：试运行被驳回不算 plan.trial_failed，记 warning plan.trial_rejected「最近一次试运行在「x」被驳回、没有走完」（带白话）。 - (h) 重启时排队中的运行改成 failed 时补发 run.failed（同一句原因），时间线里有了失败原因这一行；不写结束时间、不封存，同以前。 - (f) tasks.tick / actions.tick 交回这一拍处理过的 id 列表（调度循环只记条数），测试改成只断言自己造的待办；先加了预置 一条无关到期待办的 fixture，旧的按条数断言当场失败（3 == 1），改完通过。 已封存的老运行不改写。测试：新增 test_run_rejected（五种关卡参数化、超时驳回、继续运行拒绝含存量、手动停止、补发 run.failed、 instance_state 新老形状同一句）、test_notify_run（驳回走实例结束、手动停止不推、已退回不写已完成、个人渠道 B1 两条）； webhook、发布单、动作确认、双盲、审批的老断言跟上。去掉 runner 里接 NodeRejected 的分支回跑，新测试 8 条失败。	2026-10-16 10:14:27 +08:00
ThearchyHelios	7739340607	普通用户建应用集成收尾： ... - 问数据和个人应用的图放行绑定只读查询等合规工具的调用工具节点，只读和遮罩在这条路径上生效；被治理成写入的工具在只读运行里直接拒；知识库范围在工具层固定（图级默认值、参数名纠错、Agent 都改不了） - 个人应用的刷新和个人蓝图的试运行只有拥有者能读：运行、事件、证据、工件、文件、运行与审批列表、对比、可验证报告、质询、假设分析、提取工作流一并收紧；个人蓝图的试运行不论谁发起都按个人应用约束 - 共享蓝图只给拥有者、对应应用的管理者、管理员，看不到的一律 404；审核副本归审核人；管理员看别人的个人应用只有元数据、可以归档 - 记录表跨版本汇总（只读挂载旧版本、按当前列 UNION ALL、各版本各自固定高水位，缺的版本照实写进印章）；停用前发起的运行可以继续写旧版本；更正沿用原提交人、更正人记审计 - 约定收口：待办种类 review、事件 file.extracted、表单错误 file、模板定义带示例与预置；前端类型一次补齐、去掉临时的局部类型；审核待办卡不再给打不开的链接；读附件事件有中文说法；检查脚本补断言	2026-10-15 13:55:19 +08:00
ThearchyHelios	941723b17c	端到端验收修复与指标出具： ... - 身份与工具：登录页建第一个管理员（认人接口的 401 说明能不能建）；搭建者有只读的人和组名录，选人给候选并核对名字；授权三行带标题；端点请求头名校验（空名、非法名存不进、发不出时说清原因）；写入能力在工具页试运行一律演练、不发送，HTTP 状态照实说成败；写记忆不算只读、查询能力只能选同一端点上的只读能力；审批与遮罩的说法和实际规则一致；开登录时不要署名、导入和发布记登录的人；使用者不显示推演等只给搭建者的操作，403 按是否开登录说话；登录页只认一次人 - 流程与实例：图里用到的岗位（派给谁、超时升级给谁、发送确认派给谁）全部派生、没绑人的发布时报错；写外部系统的参数按能力声明的类型收拢后再算哈希和发送，收不成就不发；发起人的实例页只看这一步的状态，处理人才给待办卡；会签进度带登录核实和时间，升级后照实写规则；实例状态写流程的结论（已退回、未确认、等待核实写入结果），核实生效后不再挂失败原因；流程应用首页不派生最近封存运行的结果块，看板没数据时是安静的空态；样例⑩的金额带类型和下限、待办标题带金额，表单上下限前后端一起生效 - 看板与证据：定时任务模板加 ISO 周、上一 ISO 周、本月、上月；出处链穿过原样解析查询结果的整形节点，追不到原始数据的照实说停在哪里，样例⑨改用 cell()；应用首页和版本历史都能做成应用；指标块单位不重复；版本列表带退役说明；定时任务页头跟着刷新；删视图要确认、新视图能起名；编辑器属性用中文名、术语带解释 - 指标出具（用户 2026-10-15 拍板）：契约只写「指标来自」、上游没有报告撰写节点、成果里没有模型写的话时按指标出具——必需指标齐、指标输入追到原始数据、成果字段里的数回指得上才完整出具；受管级要求每个指标静态地追到原始数据（governed.metric_untraced）；出具横幅和应用印章写明按指标 - 受管工作流降为已发布只给管理员（Q8 顺延，服务端同样拦）；工作流接口带当前发布版的级别，画布上改过之后也认得出受管工作流	2026-10-15 07:15:37 +08:00
ThearchyHelios	d67349562a	应用平台集成（后端应用与流程）：身份断言 sub 为发起人、确认人进 act；应用助手对话（取或建、带历史）与助手润色只能改呈现；按新口径补算（只对无副作用的视图、加锁、同一输入只补一次）；钩子按名字关联、入站按发布版声明认；应用详情只对 manage 给草稿与岗位绑定；删工作流的阻挡算上已退役版本；待办恢复失败退回待处理；调用工具节点作证核对快照归属；子图固定版本须已发布且未退役（发起与发布检查都查）；视图里端点快照按能力的遮罩字段遮（含统一复核后的修复）	2026-10-14 21:55:51 +08:00
ThearchyHelios	acdc9677a8	应用平台 BE-2 流程：待办服务（派给谁、any/all/quorum 汇总、条件 UPDATE 抢恢复、提醒升级超时驳回、审批接口改为垫片、存量补建），人工节点新配置与校验，写外部系统的动作流程（生效记录先写后发、确认卡哈希、结果未知挂起与核实、永不自动重发），重放豁免与升级安全测试，正式运行不许带图接着跑、接着跑不覆盖发起人（F2），运行来源，通知发送核心与渠道，入站签名钩子，process.* 检查，报销审批模板，假外部系统（含统一复核后的修复）	2026-10-14 20:05:23 +08:00
ThearchyHelios	00bd51b9a5	应用平台 BE-3 应用：「已发布且未退役」的唯一判定与版本退役，正式运行接受固定的已发布版本并核对 expect_hash（F1），口径升版只看已发布版本（F3），有应用固定或生效记录时拒绝删除工作流（F4）；表达式的根名字与禁止算术参数，表单子集校验与输入节点字段转换，应用对象、发布、版本、授权、页面解析与视图模型（三种来源、缓存、印章、证据指针、遮罩）、入口发起实例、应用操作、app.* 检查、确定性派生、账本只读接口、指标证据链接口（含统一复核后的修复）	2026-10-14 20:05:23 +08:00