270 Commits

Author	SHA1	Message	Date
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	f520a88891	静态地认指标出处也跨卡往下追：转抄同一张图里另一张口径卡的指标，按那个指标的式子接着认（最多 MAX_COPY_DEPTH 层），受管级发布检查、应用检查和运行时、证据面板同一套说法；被抄的卡按 caliber_from 固定在别处版本的照旧停在那张卡	2026-10-17 12:31:13 +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	3f75cb1d2e	恢复被驳回的运行：照 end_reason 说「被驳回」，和继续运行同一个错误码 run_rejected ... 验收：对被驳回的运行调 POST /api/runs/{id}/resume，回的是「这次运行已取消，没有待处理的审批，无法恢复。已取消的 运行请重新发起」，/continue 却是对的（run_rejected）。resume 只看 status，cancelled 一律说「已取消」；存量的 failed + 驳回还会被说成「失败的运行可点继续运行」，而继续运行其实会被拒。 改法：runner 加 _resume_refused：cancelled + end_reason=rejected、以及加 end_reason 之前记成 failed 的驳回 （_rejected_before，同 continue_failed 的判断）抛 ContinueRefused(REJECTED_RESUME, code=RUN_REJECTED)，别的照 _cannot_resume。resume 开头的状态检查、等审批凑齐时发现运行已经不在 interrupted 两处都用它。/resume 接口像 /continue 一样把带机器码的拒绝回成 CodedHTTPException(409, …, code)。ContinueRefused 是 ValueError 的子类， 别的调用方（待办服务）照旧按 ValueError 接。 测试：test_run_rejected 新增一条：驳回的运行 /resume 回 409 + run_rejected、说「被驳回」；手动停止的照旧说 已取消、不带这个码；存量 failed + 驳回也回 run_rejected，不再叫人点「继续运行」。去掉修复回跑挂。	2026-10-17 08:31:17 +08:00
ThearchyHelios	d17a08bafb	合入 W4-c 账本前端：证据「口径」一步与数字上的小标记、问数据轮次摘要与按口径出具 / 对账、对账视图与反馈、可沉淀的问题、设置里的口径账本一组、比对结果按退避轮询；被驳回的那一步 node.failed 带 reason=rejected，画布、航迹、时间线、问数据过程都画「被驳回」	2026-10-16 22:29:02 +08:00
ThearchyHelios	77fc0efa10	口径召回后端（W4-a）：发布新版本后反查用过旧版的答案、按参数分组在同一份数据上重算两版之差，数真变了才开 recall 待办 ... 为什么：口径升版是被迫处置的事件（02 做法 7、拍板 L6），已交付的答案以前没人追；目录事实被驳回、表结构变了也没有地方标。 - ledger/uses.py（新）：反查旧版本被谁用过——比对工件里等价已证明的问数回答（含轮次、对话主人）、W 的正式运行（定时任务、 应用各取最近 4 期）、固定了它的工作流版本发起的正式运行、固定这一版的应用、导出审计（导出人也是主人）；预告、召回、 版本用量共用这一份 - ledger/recall.py（新）：计划按（旧版本、新版本、input_key）去重成组，从已有召回运行重算（幂等、不建任务表）；每组一次 召回运行（origin_kind=recall，探索运行），派生图经 derive.recall_graph（新旧两版取数和口径卡带前缀、召回卡里算两版之差）； 不能重算照实记原因（数据部分不能复用、新版没这张卡、入口参数不齐、图里有人工节点或写入）；每次发布最多 recall_limit 组， 超出的手动接着算；收尾时按渲染的旧值新值判数变没变：变了开 recall 待办（开登录按主人各一条、关登录派给任何人）、推 ledger.recall，没变在原答案上记 ledger.recalled；待办「按新版重新出具」走 issue.check_target 同一套判法、「知道了」 - 目录事实被驳回或修改（审阅、人工编辑、保存提案、批量审阅之后）：冻结目录里看得到这一项的探索运行记 ledger.basis_changed， 按新目录多出错误级 SQL 检查问题的才开待办；表结构变动消费 source_changes（游标、处理时改了目录的当场交过去），标依据的 表结构已变，受影响的口径试算一次，算不出来才通知发布人 - 发布钩子在 commit_publish 提交之后排队（自动的几样和调度循环同一个开关），GET /api/workflows/{id}/recall-preview 给发布 弹窗预告；GET/POST /api/ledger/recall/{wf}/{v}[/continue] 给版本历史看批次、接着算；版本用量加问数回答、导出、召回 - ledger.recall 打开订阅（全局、个人渠道），同一渠道只推一次，消息不放数；新事件 ledger.recalled、ledger.basis_changed 登记为封存后追加的事件，可验证报告离线核对页认得；E4 每次发布召回了几组、数变了的比例 - runner 收尾时召回运行在后台收尾，启动时接着做没发完的批次	2026-10-16 19:52:03 +08:00
ThearchyHelios	eb578cad34	驳回节点的画法（后端）：被驳回的那一步的 node.failed 带 reason=rejected ... 第 1 波把人的驳回收成 cancelled + end_reason=rejected，但节点层仍只发一条和故障一模一样的 node.failed： 复核规则把它说成「执行失败」、还当成「重跑一次大概率能好」（重跑只会把同一件事再问一遍人），实例进度里 没开待办的驳回（工具调用审批、代码执行审批）落成「失败」（05-已知遗留 (a)、总方案 X9）。 - engine/compiler：NodeRejected 时照旧发 node.failed（时间线、实例进度按它收尾这一步），数据里多带 reason=rejected（和 run.cancelled 同一个字段名）、kind、decision、actor、note；真的出错的 node.failed 一字不变，没有这几个键 - engine/review：认 reason=rejected，记 node_rejected（DEGRADED，不进 RETRYABLE），说「被驳回」不说「执行失败」； 没有 reason 的老运行照旧 node_failed - apps/resolve 的实例进度：按 node.failed 上的 reason 画「被驳回」（结论写已驳回 / 超时驳回 / 未确认（被驳回））， 老运行照旧按待办认 - 测试：六种关卡的 node.failed 都带上这几个键；普通失败没有；复核与实例进度的新旧两种形状（去掉修复回跑会失败）	2026-10-16 19:30:47 +08:00
ThearchyHelios	1c8ca4c3d7	合入 W3-c 评测执行：后台评测与无头作答、六种期望五种结论的评分、重评、结论裁判记评测账、统计（Wilson 区间、按角色用量）、对比与 A/B（McNemar）、目录贡献预设、预算与止损、清理；定时任务接题集目标，定时评测有退步 / 没有评完推全局渠道；定时页照实显示非工作流目标	2026-10-16 18:46:44 +08:00
ThearchyHelios	defdb28e3f	合入 W3-b 口径账本闭环：caliber_from.nodes 改名映射；问数据的助手 use_caliber 选用已发布口径（服务端确定性内联实例化）；按口径正式出具（自动只给问数据的答案）与口径对账；认证队列、固化成口径草稿、发布后补比；账本统计补上对账与认证转化；使用者的原始运行记录只给问数据的运行	2026-10-16 18:45:45 +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	8d59ca1581	W3-a 表结构变化：前后差异、影响面、结构版本与 schema.drift（next-round 03 B1） ... 以前重新探查是整份替换表结构、不比前后：删了一列，那一列上人工确认过的目录项、写死这一列的已发布模板都收不到提醒， 正式运行要到查询那一步才报错。现在： - data/schema_diff.py：纯函数，同一张表前后两次的结构比出变化（加列、删列、类型、可空、注释、主键与唯一约束、外键）； 疑似改名（类型相同、夹在同样两列之间、只有一对）只说「可能」；读不到唯一约束、外键的一边不比；升级后第一次读到 （结构版本 0）只建基线，不把通用写法换成方言完整写法说成类型变了。 - 后台探查顺带记变化（data/introspect_jobs.py）：刷新对象索引记新出现的表、真删除的表（第一次建索引只建基线）；开始 执行时记离开范围的有目录的表、范围规则和上一次不同；逐批读完拿上一次的结构比，读不到结构的记 table_reflect_failed。 离开范围、读不到结构不算删除。记变化出错只记日志，不挡探查。 - 变化记录 source_changes（db/models_sources.py 的 SourceChange，格式 agentlab-change/1，seq 自增不复用、按指纹去重）， 记录与读取在 data/source_changes.py；取值观察的表 TableObservation 同文件建好。 - 影响面（data/catalog_impact.structure_impact）：目录里说到被删、被改的列的项（列级项、业务主键、业务日期、有效记录条件 按 parse_valid_filter 取列、两端的关联关系）带状态，人工确认过的升为要处理；已发布模板写死的 SQL 换上新结构再跑 sql_unknown_columns，说得出「这条 SQL 现在会报列不存在」。sql_unknown_columns 从 api/copilot.py 挪到 data/sqlcheck_columns.py 共用，copilot 那边只改 import。 - 发布时记 WorkflowVersion.schema_versions（只记直接引用、结构版本大于 0 的表）；正式运行发起时比对，变了写 schema.drift （core/events.py 登记，只提醒、不拦）；版本详情给出 schema_versions、schema_changes；发布前检查把这一版直接引用的表上 还没处理的结构变化列成警告（schema.change_open），不拦发布。 测试：test_schema_diff（纯函数）、test_schema_changes（SQLite 夹具 ALTER 前后、影响面、去重、真删除与离开范围、 schema.drift、发布前检查、升级后基线）。	2026-10-16 16:26:11 +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	5b4bd91476	口径账本内核：运行封存后在后台比对已发布口径、逐个数标口径、按运行读的账本接口、来源链和导出留痕、统计 E1–E4 ... 为什么：问数据的答案要和已治理口径接起来（next-round 02 做法 2、3、9、10；总方案 X1、X2、X3、X12，拍板 L2、L4、L8）。 - 比对（ledger/match.py）：探索运行（chat、canvas、trial、personal_app）成功结束、封存完、有查询快照时，在 runner 封存之后和 notify_run 同一个位置放到后台；候选口径是每个工作流最新的已发布未退役版本里查库的调用工具节点（受管、已发布都算），按数据源 和表预筛；逐个用 match_template 比，schema 用查询当时冻结的表结构、列名取同一份快照里冻结的数据目录。每次运行限时 8 秒、在 线程里、同时最多 2 个；超时、快照被改过或读不出、SQL 解析不了照实记 skipped。启动时（run_manager.setup，和调度循环同一个开关） 补比最近 7 天封存了却没比过的运行，只读工件和版本表。 - 记法（ledger/store.py，拍板 L8）：内容寻址工件 kind=caliber_match（agentlab.caliber_match/1）+ run_append 的 sealed 方式追加 ledger.matched（core/events.py 登记）；工件里不放时间和工作流名，同一份封存再比一次哈希一样；meta 记 calibers / related / counts。 - 标签（ledger/labels.py）：单元格按查询的比对状态；指标要每个输入都等价于同一份口径同一版、绑定一致，式子按「哪个取数节点、 第几行、哪一列」换完和口径卡上的一字不差。caliber（how：independent 等价已证明；composed 助手选用留给第 3 波）/ related / reasoning / unknown；整题判断附还缺的入口字段。 - 读（ledger/view.py）：GET /api/runs/{id}/ledger（ledger_api.runs_router，和证据同一道门），没比对过、能比的按需排上；证据 片段接口加 ledger 键（没比对过的运行没有这个键，返回一字不差）；报告导出的面板最上面多「口径」一步并写明「封存后比对，不在 封存范围内」。遮罩按读的那一刻重滤：绑定的值是这次运行查到过的遮罩值时不给值，差异条目和逐行对照走 _Shown。 - 来源链：POST /api/runs 加 origin_ref（只在 origin=chat 时收，服务端核对对话访问权和轮次归属，写进 Run.origin 和封存的 run.origin）；WorkflowIn 加 origin（run_id、conversation_id、turn_id，核对规则同 from-run）；报告导出和可验证报告下载各记一条 审计 report.exported。可验证报告列封存后追加的事件时给 ledger.matched 一句只有条数的说明。 - 统计（ledger/stats.py）：E1–E4 从工件、运行、查询快照、审计现算，GET /api/ledger/stats（搭建者）；E3 用 app/chat/questions 的聚类加按（数据源、normalize_sql 文本）的确定性重复；评测直接调 compute_stats（可点名 run_ids）。对账反馈、认证转化、按发布 的召回在后面几波，照实写没有数据。 测试：test_ledger_match.py（真跑探索运行：等价、相关、没有相关口径、写死的码值、非探索运行、超时、快照被改、解析失败、预筛、 指标两种、级别、只认最新版、补比）、test_ledger_api.py（账本接口、按需比、遮罩、证据片段、导出、审计、统计）、 test_run_origin_ref.py（origin_ref 与画布来源的核对）。	2026-10-16 14:02:55 +08:00
ThearchyHelios	696cd17a4a	合入 W1-b 已知遗留：人工驳回记成已取消 + end_reason=rejected（不重试、不被出错时继续吞掉），各处照实写「被驳回」；个人渠道「我发起的实例完成 / 失败」生效；导入清单如实记「是否认证」；使用者选人按候选池、开登录时服务端核对；自由形蓝图按导入的图列「谁来做」；tick 按 id 断言	2026-10-16 12:51:43 +08:00
ThearchyHelios	5c34ac6bc5	驳回不重试、不被「出错时继续」吞掉：人的决定照总方案 X9 收成被驳回 ... 为什么：NodeRejected 是 NodeError 的子类，compiler._execute 的通用 except 照常接住它。节点配了失败重试的，驳回之后 会重试这个节点——再开一次待办、把同一件事再问一遍人；配了 on_error=continue 的，驳回被当成节点失败吞掉，图接着往下 走，最后以 succeeded 结束，通知、定时推送、发布单都看不到这次驳回。这和 X9 定下的「驳回 = cancelled + end_reason= rejected」直接矛盾。「失败重试」「出错时继续」是给故障准备的，驳回不是故障。 做了什么： - _execute 在通用 except 之前单独接住 NodeRejected：不重试，直接跳出；容错分支多一条「不是驳回」才走。节点这一步 照旧记一条 node.failed（实例进度、时间线、存量判断都按它收尾这一步），再原样交给 runner 收成被驳回。 - NodeRejected 的说明改成现在的样子（以前写的是 on_error=continue 照旧认它）。 原有行为变了：配了重试或出错时继续的关卡，驳回后不再重问、不再接着走。发布说明里要写明。 测试：test_run_rejected 加五种关卡 ×（出错时继续、失败重试）的参数化，断言终态是 cancelled + rejected、没有重试日志、 驳回之后没往下走、节点只有一条 node.failed。先跑：出错时继续的五条以 succeeded 结束，失败重试的五条又停回 interrupted （重问了人），10 条失败；改完通过。	2026-10-16 12:46:35 +08:00
ThearchyHelios	74909191f7	judge.py：每日计数一节的函数前补一个空行	2026-10-16 11:08:25 +08:00
ThearchyHelios	96af448fc5	全量回归抓到的两处：裁判那本账留回 judge._today 这个日历名字；冻结表结构快照时 ctx 不一定带目录视图 ... - engine/judge.py：裁判的测试（test_judge_settings、test_verify_spend）换 judge._today 来模拟裁判这边跨天。上一版把它去掉、让三本账都只认 spend._today，等于改了这些测试的前提。改成裁判那本 Ledger 实例放在 judge.py（judge_spend，键不变，日历是 judge._today，它缺省就是 spend._today）；spend.py 只放核查、评测两本。test_evidence_judge 恢复原样，test_spend_ledger 跟着改：换 spend._today 三本一起滚，换 judge._today 只动裁判那本 - tools/datasource._store_schema：按 getattr 取 ctx.catalog_view——几处测试（和以后的调用方）直接拿一个只有 run_id / node_id 的对象调它，没有这个属性就是缺省视图	2026-10-16 11:04:41 +08:00
ThearchyHelios	2fa2db3ea0	驳回不再记成失败（前端）：终态按 end_reason 写「被驳回」，副标题写谁、在哪一步、备注 ... 为什么：服务端已把人的驳回收成 cancelled + end_reason=rejected（上一个提交）。前端以前靠正则解析报错原文认驳回，而且只认 「人工驳回」一种，动作确认、工具调用审批、代码执行审批的三种原话都落到兜底、给出注定再失败的「继续运行」（05-已知遗留 (a)）。 做了什么： - types.ts：Run.end_reason（rejected / stopped）。 - lib/status：新增状态 rejected（「被驳回」，同取消的剪影、不画红、终态），resolveStatus 按 endReason 区分；记录页列表、详情、 航迹的终点按它写「被驳回 · 原话」。 - run/decode：run.cancelled 带 reason=rejected 时标题写「被驳回」，副标题「张工 驳回了「付款」：金额不对」（超时驳回写按设置 驳回、不重复备注），指向那一步；手动停止、老事件照旧「已取消」。 - store/chat + ChatPage：终态里被驳回的一轮照 cancelled 收（不给继续运行），徽标写「被驳回」，补救区说明这是审批人的决定、 副标题写谁和备注；刷新之后从 meta.rejected 恢复；核对状态时按运行的 end_reason 认。 - lib/explain：正则只留给存量 failed+驳回，补上「未确认（被驳回）」「的调用已被驳回」「代码执行已被驳回」三种原话，一律不给继续运行。 - 继续运行被拒的说法改成「被驳回的运行不能继续运行：改好内容后重新发起」（check-copy 不收「接着跑」）。 - check-decode 加一节：reason=rejected 的标题、副标题、没署名没备注、超时驳回、相位、手动停止和老事件。 偏离：问数据的「之前的尝试」（retry 留档，W1-a 的地盘）里被驳回的那一次仍写「已手动停止」，没动。	2026-10-16 10:54:02 +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	dd00234622	系统派生的运行不进使用统计（总方案 X1、X2，细案 01 做法 4）：评测一跑，聚类、白名单、目录使用热度都会被刷高 ... - engine/origin.py：SYSTEM_ORIGINS = (eval, reconcile, recall) 和 counted_runs()（写法同 hidden_runs，coalesce 防 NULL：来源为空的老运行、外连接没对上运行的行照常计入）；ledger_issue 是替用户正式出具，照常计入 - 取问题、聚类全站只留一份：新增 app/chat/questions.py（recent_questions / cluster_questions）。只取问题原文、不取整份输入（以前把含 history 的 input JSON 拿去聚，同一段对话里的不同问题会聚成一类）；问数据按轮次一轮一条（conversation_turns.question），同一轮里的自动重来只是换了挂着的运行，不多算；别的探索运行取 input.question；排除系统运行和别人的私有运行。/governance/exploratory-clusters 改用它，多给 turn_ids 和 embedder（本地哈希向量的结果只是下限） - 工具白名单衰减、目录的使用次数和「被哪些运行用过」、审阅队列的使用权重（都走 catalog.query_snapshot_tables）只算 counted_runs 圈进来的运行 - 记录页：没按来源筛时默认不列这三类，按来源点名就列；新增 GET /api/runs/unlisted（同一份筛选，_filtered 和列表共用）照实给出没列出几次、各是哪种来源。界面在列表底下（空列表时也写）写「另有 N 次系统运行未列出（评测 2 次、口径对账 1 次）」，来源下拉的「全部」改说「全部来源（不含系统运行）」；文案进 lib/terms.ts 的 SYSTEM_RUNS_TEXT；check-runs 补一段 - test_personal_apps 里代表「别的探索运行」的两条运行改成画布试跑：问数据的问题按轮次取，没挂在任何一轮上的问数据运行不单独算 - 新增 tests/test_eval_origin.py（去掉 counted_runs 的过滤回跑，5 项都会失败）	2026-10-16 10:18:12 +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	0ce272e94b	每日账泛化成 Ledger(key)（细案 01 做法 17）：核查、裁判以前各写一份一模一样的预留、找补、按日滚动，评测再抄就是第三份 ... - engine/spend.py：Ledger(key) 一套代码，三个实例各记各的键——verify_spend（核查）、judge_spend（裁判）、eval_spend（评测，预留，设置和接口第 3 波加）；锁按（事件循环, 键）各一把，一本触顶不挤占另外两本 - 核查的模块函数（SPEND_KEY、daily_spend、charge、settle）照旧，委托给 verify_spend - engine/judge.py：_charge / _settle 和它自己那份 _today、_spend_of、模块级锁去掉，改用 spend.judge_spend；SPEND_KEY、daily_spend 照旧，裁判的预留、找补、上限行为不变 - 三本账按同一个本地日期滚动（spend._today）：test_evidence_judge 里模拟跨天改成换 spend._today（以前换的是裁判自己那份时钟，已经不在了） - 新增 tests/test_spend_ledger.py（三本账三个键、预留找补与上限、跨天、互不挤占、同一个时钟）	2026-10-16 10:02:53 +08:00
ThearchyHelios	4819b21269	下一轮第 1 波的契约骨架：运行加 end_reason（人工驳回 / 手动停止），定时任务加目标种类和 id、触发记录加评测 id（定时只有一套），运行来源登记 eval、ledger_issue、reconcile、recall（都只能由服务端写）；迁移只加不改	2026-10-16 09:43:08 +08:00
ThearchyHelios	7739340607	普通用户建应用集成收尾： ... - 问数据和个人应用的图放行绑定只读查询等合规工具的调用工具节点，只读和遮罩在这条路径上生效；被治理成写入的工具在只读运行里直接拒；知识库范围在工具层固定（图级默认值、参数名纠错、Agent 都改不了） - 个人应用的刷新和个人蓝图的试运行只有拥有者能读：运行、事件、证据、工件、文件、运行与审批列表、对比、可验证报告、质询、假设分析、提取工作流一并收紧；个人蓝图的试运行不论谁发起都按个人应用约束 - 共享蓝图只给拥有者、对应应用的管理者、管理员，看不到的一律 404；审核副本归审核人；管理员看别人的个人应用只有元数据、可以归档 - 记录表跨版本汇总（只读挂载旧版本、按当前列 UNION ALL、各版本各自固定高水位，缺的版本照实写进印章）；停用前发起的运行可以继续写旧版本；更正沿用原提交人、更正人记审计 - 约定收口：待办种类 review、事件 file.extracted、表单错误 file、模板定义带示例与预置；前端类型一次补齐、去掉临时的局部类型；审核待办卡不再给打不开的链接；读附件事件有中文说法；检查脚本补断言	2026-10-15 13:55:19 +08:00
ThearchyHelios	277982ead3	普通用户建应用（后端）： ... - 蓝图：bp_* 操作和逐卡白名单、蓝图检查、留痕、按蓝图判权限；五个场景模板加自由形（骨架、关节、应用骨架、定时任务），实例化与骨架比对；BlueprintApplier / TemplateApplier（只收模板声明过的关节）与自查；look 新类别口径卡；蓝图对话和填关节两个流式接口，不同组的关节并行填、出错的组串行重试；模板列表 - 试运行与发布单：四种起点（对话、模板、问数据的一轮、已发布版本）；试运行是探索运行，草稿应用按这次运行解析、印章写试运行，流程类派给自己、不触发升级；发布单九步、预检只读、每步留痕、停下后接着做、核对卡片指纹和应用管理权、启动时整理中断的单；白话层覆盖全部问题编号 - 记录表与文件：平台托管只追加的记录表、按高水位固定数据、连接上的临时视图做行级可见、写入走动作（records_append）、表版本在发布时切换、草稿不影响线上、记录列表遮敏感列；文件按哈希存、两步上传、提交时绑定运行、下载按读权限、清理、file_text、按配方导入一期（table_import_period） - 个人应用：存成个人应用（问数据的约束）、刷新（遮罩、只读、每日上限）、只有拥有者看得见、提交审核与共享副本、开关下发到认人接口；页面编辑的候选；隐藏组件不下发；三条新检查	2026-10-15 12:09:29 +08:00
ThearchyHelios	7088f4557e	普通用户建应用的契约骨架（docs/design/normal-user-apps.md 第五部分）：蓝图、蓝图留痕、发布单、文件、记录表的模型和迁移，应用的 scope / owner / blueprint_id；运行来源加 trial、personal_app；应用描述的固定版本可以没有版本号（试运行派生的草稿）或改钉蓝图（个人应用），视图来源加 exploratory，组件加 hidden，表单加文件控件；agentlab.blueprint/1 与 bp_* 操作、agentlab.template/1 与关节类型的定义；实例化、试运行、发布单、个人应用、记录表、文件、白话层的接口签名；蓝图、模板、文件、个人应用、蓝图助手的路由桩（501）；前端约定 typesBlueprint.ts、接口桩、新建应用与蓝图页的占位路由、termsBlueprint.ts	2026-10-15 09:49:45 +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	bff3062a97	集成收尾：前端约定写入后端实际返回的形状（应用详情只对 manage 给草稿、补算计划与结果、按名字的钩子行、能力字段审阅），去掉多种字段名都认的兼容解析；钩子按（应用, 名字）、应用助手对话按（应用, 建立人）加唯一索引，迁移前去重，插入改在保存点里、撞上就改用已有的那一行；口径卡固定的版本也须已发布且未退役，记级别之前有正式运行凭据的老版本启动时补记为已发布；证据面板和应用视图按列名遮端点快照（同一个函数），不再整张表遮掉；待办计数带上最新一条的时间，新待办通知不再漏；非管理员的搭建者不出模型接入的改动按钮	2026-10-14 22:08:33 +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
ThearchyHelios	5dba66c2b6	应用平台 BE-1 治理底座：身份三种模式（off 默认 / local / oidc）、会话与 CSRF、中间件写入身份、角色与组与审计、按权限矩阵挂路由级依赖、运行与工件的读权限和 user 角色遮罩、reset-admin 找回；能力登记（同步、治理与乐观锁、发起快照、发布版本、作证判定）、登记的端点与平台执行器（分环境、演练、幂等头、身份断言、端点快照作证）、密钥加密与掩码、MCP 的 SSRF 与认证头、写入能力只进调用工具节点、正式运行里只读免审批的能力直接执行、四条 action.* 发布检查（含统一复核后的修复）	2026-10-14 20:05:23 +08:00
ThearchyHelios	8f64853bf6	契约骨架补充：launch_run 和 run_manager.start 接收运行来源（origin_kind、origin、app_id、app_version）和 expect_hash，来源记在运行上、run.origin 事件放进发起时的 notes（在封存范围内）	2026-10-14 17:54:58 +08:00
ThearchyHelios	220fd0e365	应用平台契约骨架：新表（身份、能力与端点、应用、待办与生效记录、通知）与迁移（补列、多列索引），运行来源与新事件类型，「人」的唯一入口 api/deps.py（关登录时行为不变），应用描述与表单的形状、受信组件目录 v1，各包跨包函数的签名桩，新路由登记，发布门禁的扩展钩子 EXTRA_LINTS；前端接口约定 typesApp.ts、各接口文件、SchemaForm / TaskCard 的 props 与最简实现、应用相关路由与占位页	2026-10-14 17:53:40 +08:00
ThearchyHelios	49f00c589a	目录修改提案的依据改存成目录项单独的字段 reason（界面上叫「确认时的依据」，最多 500 字，超了截成 499 字加「…」），不再拼进备注：拼进 note 之后，带依据保存的关联关系再剖析时测量的说法换不了新、和覆盖率那一栏对不上；改了值的关联关系旧依据叠在新依据后面、越存越长；值不变、保存即确认的项撤销审阅回到推断后「依据：使用者说……」还挂着，看起来像使用者确认过一条推断项。去留：值改了（关联关系也一样）换成这次的依据，没写就去掉旧的；值不变的确认换成这次的，不叠；单项确认、驳回留着，撤销审阅去掉；整份提交改了值的、状态改回推断的、双盲复算改写的去掉；剖析刷新关联关系的测量只动备注。校验认 reason（文字、最多 500 字），起草、剖析的合并不碰人工确认的项，导出导入时已确认、已驳回的项连依据一起带，推断、有确证的项不带。表助手背景里已有的依据写成「以前确认时的依据：……」，系统提示词和 propose_changes 的说明写清那不是这次对话里使用者说的话、引用时写「以前确认时的依据写着：……」，遮罩列的项不给。表详情里依据和说明分开写：表级的项在值下面另起一行，列的一格、关联关系另一个悬停图标（读屏念「确认时的依据：……」），状态弹层里也写，驳回的项只在弹层里写；check-catalog-loop 的假服务端照服务端记下依据，补依据和说明分开、弹层、驳回项的检查；README 表助手一行写上依据另存	2026-10-14 15:38:15 +08:00
ThearchyHelios	20bef14520	保存目录修改提案时依据随项保存：表助手、助手流里「建议更新数据目录」的提案经 /catalog/{table}/patch 保存，写了依据的项备注记成「依据：……」（超出目录文字项的上限 500 字截断），没写依据的照旧；值不变、保存即确认的项和沿用了测量备注的关联关系，依据写在原来的备注前面（关联关系的剖析备注再剖析时整段换掉，放在前面才留得住）。表详情里人工确认的项有备注时也看得到：表级的项写在值下面（同有效记录条件的说明），列的一格、关联关系悬停看；check-catalog-loop 的假服务端照服务端记下依据，补保存后看得到依据、人工确认项的说明两处检查	2026-10-14 14:07:14 +08:00
ThearchyHelios	7589c350bd	期 5 验收修复 N1 第 4 轮：转抄上游口径卡按整张卡、每一次执行认（保守规则）；显示文字白名单收紧复核点名的几类，软换行和金额符号不再误伤 ... 复核第 3 轮（91aa34d）找到三处 major、两处 minor：循环里卡转抄自己上一轮、更早一轮取过号码（SQL 带模板）时，写作目录只看 运行状态里最后一次的产出，号码进了报告正文和成果，自查通过、正式运行成功，封存之后的面板才写「已遮罩」；整张卡、清单文字、 下标不是字面量的转抄只按值认，由遮罩格算出来的年薪（月薪 × 12）在写作目录、报告、成果、证据面板、可验证报告里照给；显示 文字的白名单里还收着易混字（’ 当千分位、刂 当竖线、×10⁴ / T / bn / m 改量级、en dash 当负号），伪造页总览照样是绿色的 「全部通过」；先起别名再套没起别名的表达式、+phone 这类 SQL 写法认不出遮罩列；段内软换行紧挨着数字、数字前的 ￥ ¥ 被判 无法核对，原样导出的正常报告总览变成中性。 转抄的保守规则（recompute.masked_closure 的 CopyEdge.card；写作目录、报告自查、证据面板、推演、可验证报告同一个判断） - 卡上的输入转抄上游口径卡（字面量下标、下标不是字面量、整张卡、清单文字、整份指标列表都算），只要那张卡在这次运行的任何 一次执行里有一个指标不给，转抄出来的就不给（masked，整张卡转抄不再降成 table 按值认）；那张卡一个不给的指标都没有时照常， 没设遮罩的工作流、循环里累加自己上一轮的卡照给（第 3 轮修好的那条不回退）。最小不动点上按卡汇总：每张卡「有指标不给」 只从无到有、遮罩列只增不减，变一次只重认转抄它的那几个，工作量仍和边数成正比 - 每一次执行的指标集按台账认：写作目录（withheld_metrics）把运行状态里台账的 metric_set 条目交给 _CopyGraph（_executions， 连同它们的输入先在线程里读好），封存之后按封存范围内的台账；可验证报告（_Store._executions）按 node.finished 的台账条目 - 转抄的是哪张卡按读到的产出上记着的指标集认（经数据整形赋给变量的也认得出是哪张卡），认不出的按取值链上的节点 - 推演（recompute._copied）、证据面板（_copied_held）随之去掉整张卡转抄的 table 一档 - 行为变化：转抄了带遮罩指标的卡的普通指标（客户数、数指标个数、清单字数）也写「已遮罩」、推演不让改，正式运行引用它判 失败；那张卡自己的普通指标照给。test_report_masked_card_copies、test_report_masked_copy_closure 里按老规则写的期望相应改了 显示文字核对（verifier.js） - 弯撇号（U+2018、U+2019）移出常见写法的名单；偏旁形的汉字（刂冫氵亻阝扌忄犭礻衤讠钅饣纟丬）、康熙部首、部首补充、扩展 B 区以后的字不算常见写法：紧挨着数字判无法核对 - 数字后面紧接 ×、*、^ 再接数字判无法核对（新原因「后面紧接着乘号或乘方和数字」），后面那个数本身也核对过的（两个数相乘） 不算 - 数字后面紧接着、或隔着空白和左括号的英文量级写法（T、G、m、b，bn、mn、tn，thousand、million、billion、trillion）按整串 字母认，判无法核对；ms、GB 这类别的单位不算 - en dash 归入像负号的短横：紧挨在数字前面判无法核对（不判不通过），前面是数字、字母的区间照常 - 段内的换行（页面上显示成一个空格）、金额前面的「￥」「¥」收进名单 - 「（单位：万元）」、x10 这类隔着几个字或换了写法的认不出：名单只是兜底，bundle/build.py 的模块说明写明真伪以封存哈希为准 已知局限不再加规则：api/evidence.py、bundle/build.py 的模块说明写明遮罩只减少暴露、不是安全边界，列出认不出的 SQL 写法 （先起别名再套没起别名的表达式、+phone、Postgres 给没起别名的表达式起的列名、视图、自己建的函数、数据整形取出来的号码）。 验证 - 新增 tests/test_report_masked_copy_any_run.py（20 项）：纯函数上的边规则（四种写法、循环三轮、之前认好的指标、读到的产出 读不出来）；循环里转抄更早一轮的号码（护栏写法、只按字面量下标两种）写作目录写「已遮罩」、正式运行判失败，标注时文档、 成果、面板、可验证报告都没有号码；循环之后的卡转抄最后一轮，写作目录、面板、推演、可验证报告同一个判断，可验证报告自己 （没有报告的运行、老文档）也认；经数据整形转抄的按卡本身认；年薪的五种转抄写法写作目录都写「已遮罩」，标注时文件里没有 年薪；没碰号码列的循环、卡上没有遮罩指标的照常 - test_bundle_shown：复核点名的几类各自判无法核对、写明原因、总览中性；软换行、￥ ¥、两个核对过的数相乘、en dash 区间、 ms / GB 照常通过；PROSE 样本去掉 en dash，加上软换行和 ￥ ¥，17 处全部通过 - check-bundle 补弯撇号、刂、扩展 B 区、×10⁴、bn、billion、en dash 七种篡改（各自判无法核对、点名、总览中性），prose 样本 17 处全绿 - 复核者探针：test_probe_r3a、test_probe_r3c 的写法都拦住；test_probe_n1c（没设遮罩的循环自引用）照常；layout_probe 的 108 种写法里点名的几类都判无法核对，￥ ¥ 照常通过；Chrome 断网打开 forge3、forge4 的伪造页，点名的几类都不是绿的、提示 都显示 - 开发数据 39 份报告 1591 处、验收数据 58 份 1695 处引用按新规则扫过，判不通过和无法核对都是 0 - 每处改动都做了「去掉实现、测试变红」：17 个定点变异（不看整张卡、不读每一次执行、写作目录不交台账、可验证报告不读每一次 执行、整张卡退回按值认、推演不认、按取值链上的节点认卡两处；弯撇号、偏旁、扩展 B 区、乘号乘方、英文量级、en dash、软换行、 ￥ ¥、两数相乘豁免）全部变红	2026-10-12 23:01:09 +08:00
ThearchyHelios	91aa34d014	期 5 验收修复 N1 第 3 轮：转抄上游口径卡的遮罩改在指标依赖图上一次算出最小不动点；显示文字核对紧挨着的字改成白名单 ... 复核第 2 轮（ce71f7d）找到两处 major、两处 minor：转抄的识别逐个往上递归、追够八层（CARD_DEPTH）就按遮罩算——没设任何遮罩 的工作流里，循环里累加自己上一轮产出的口径卡在写作目录里指回自己，一直追到八层，写成「已遮罩」，正式运行判失败、报错说 「取自设置了遮罩的列」；每个指标的护栏 nodes.acc 选中整张卡的全部指标，递归次数约为（指标数 + 1）的八次方，四个指标四十秒、 卡住事件循环；封存之后循环超过八轮的，证据面板写「已遮罩」，可验证报告把文档整份只给哈希。紧挨着改字仍是黑名单：西里尔、 希腊的 I、O、M、K，汉字「丨」，换行、制表、各种宽度的空格后接「万」，「（万元）」，负号前面放一个别的文字系统里长得像撇号的 字母，都还是绿色的「全部通过」、提示也不显示。另有：* 展开派生表、WITH 里没起别名的 UPPER(phone) 认不出是确定取自遮罩列， 号码进了写作目录和文档；上游卡的节点产出读不出来时转抄当作认不出出处，号码随卡 2 的节点完成事件出去了。 转抄的遮罩在指标依赖图上一次认（recompute.masked_closure，写作目录、证据面板、推演、可验证报告共用） - 先按转抄以外的输入认每个指标（写作目录、可验证报告认老文档只按确定取自遮罩列的 sure；证据面板、推演宁可多遮），再沿转抄的 边（nodes.<卡>.metrics[i].value、vars.<assign_to>.metrics[i]、整张卡 / 清单文字 / 整份指标列表 / 下标不是字面量的连到那张卡 的全部指标）往下游传，直到不再变化。从「都照给」起往上收：环（循环里抄自己上一轮、几张卡互相转抄）本身不带来遮罩，环上有 一个指标别的输入取自遮罩格，整个环都不给。每个指标的结论只往严里变，工作量和边数成正比；删掉 CARD_DEPTH、CARD_TOO_DEEP 和逐层递归（_InputMasks._copied、_Store._copied_kind），可验证报告的缓存不再按 (卡, 指标) 混着深度记 - api/evidence.py 的 _CopyGraph（按请求记在 _Masks 上，键是 (指标集工件, 指标在卡上的位置)）：写作目录只有最后一次的产出， 抄自己上一轮的卡是一个环；封存之后按每次执行认（_card_outputs，同一次执行只找一次），一次一次往回连到第一轮。bundle/build.py 的 _Store.metric_word 按同样的键各认法一张图 - 推演（api/whatif.py → copied_inputs）的转抄输入按证据面板同一张图认：转抄的是不给的指标就不给值、不能改（原因「转抄的口径卡 指标取自设置了遮罩的列」），核对不了的不给、不推演。以前只按值认，转抄来的三位数余数照给、还能改 - 上游卡当时的产出读不出来（文件不在、与哈希不一致）、卡上又记着这个输入出自口径卡、转抄来了值的，转抄核对不了（同按位置取的 一格取值链上的产出读不出来），可验证报告里卡 2 只给哈希；第一轮还没有上一轮（转抄来的是空值）的不算 - 可验证报告附带口径卡另看卡上记着的转抄值（_copies_masked）：转抄的是不给、核对不了的指标，或者整张卡、清单文字转抄来的值里 写着号码（len(nodes.card.text) 的输入就是整段清单文字），卡只给 id。指标的值照给时以前照常附带 - 确定取自遮罩列（_sure）在整份算的快照里另按列名认（_named_from_masks）：SQLite、MySQL 拿没起别名的表达式原文当列名，* 展开 派生表、WITH、UNION 一支时原样带出；按列名拼一条只选这一项的 SQL 交给同一套认，COUNT(phone)、FILTER、分档标签照旧不算。 单元格引用的自查、收遮罩值、裁判摘录跟着收紧 显示文字核对（verifier.js）：紧挨着数字头尾的那一个字改成白名单（COMMON） - 名单：汉字（含「一」，去掉丨、丶、丿这类笔画字）、中文标点、半角和全角空格、ASCII 字母、常用半角标点和 = + / ~ * # < > 等 算式符号、× ÷ ≈ ≤ ≥、上一轮放行的破折号写法（——、—、–、―、﹘、ー、─、〜、〰）；逗号、句点、连字符看上下文（句点在数字头 前面只认 NO. 这种字母缩写）。名单以外的（别的文字系统的字母、制表换行和各种宽度的空格、零宽字符、全角拉丁字母、表情）判 无法核对，原因「紧挨着这个数的字不在常见写法里，无法确认读者看到的数」，总览随之不是绿的、显示去系统里核对的提示 - 像数字的字母另收 o、竖线一类（|、｜、丨、竖排破折号、制表符竖线、拉丁 / 西里尔 / 希腊里长得像 l、I 的）和圆圈一类（西里尔、 希腊的 O、空心圆）；量级单位另收十、拾、佰、仟和当「万」用的 w、W，前面隔着的改成任何空白和左括号、左引号（「（万元）」） - 负号前面的「编号」例外只认 ASCII 字母数字；后面接 e 和数字（科学记数法）同紧挨着数字，判不通过 - 开发数据 39 份报告 1591 处、验收数据 58 份报告 1695 处引用按新规则扫过，没有一处判不通过或无法核对；prose、formats 样本原样 导出全绿，别的样本页总览和第 2 轮一字不差；复核者的 42 种伪造写法（forge.py、forge2.py）全部不是绿色、提示都显示 测试 - 新增 tests/test_report_masked_copy_closure.py：没设遮罩的循环自引用照常显示、正式运行成功（复核者的探针）；循环三轮、十轮的 老文档照常附带；两张卡互相转抄照给；环上一个输入取自号码列整个环都不给、同循环里不相干的卡照给；上游产出读不出来三种转抄 写法都不漏号码；卡上记着转抄清单文字的卡不附带；推演按同一张图认转抄输入；* 展开里没起别名的号码表达式八种写法算确定取自 遮罩列、只数个数和分档标签的不算；纯函数的环、整张卡转抄、读不出来、两千个指标线性；写作目录和可验证报告在三张卡各 8 个 指标、循环十轮时各一秒以内（写作目录每个指标只认一次），另有真跑两张卡各 8 个指标十轮的计时 - test_report_masked_card_copies：认转抄补读不出来的几种；「追不到头按遮罩」改成环上认（没别的输入照给、有号码输入整个环不给） - test_bundle_shown：名单以外的字、像数字的字母、隔着各种空白和左括号的量级单位、别的文字系统字母后的负号、科学记数法各自判 无法核对或不通过、总览不是绿的；常见半角标点、算式符号照常通过；表情紧挨着数字改判无法核对（隔一个空格照常通过） - check-bundle 补长得像 I、M 的西里尔字母、汉字「丨」、数学粗体 l、隔着细空格的一位数、开尔文符号、隔着换行和 em 空格的「万」、 「（万元）」判无法核对，撇号字母后的负号、e3 判不通过，各自点名、总览不是绿的 - 每处改动都做了「去掉实现、测试变红」：整套退回第 2 轮（27 项红、写作目录计时十秒没认完、可验证报告长循环把文档只给哈希）； 环按遮罩算、不沿边往下游传、读不出来当认不出出处、不看卡上的转抄值、不按列名认、推演不用依赖图、每个指标各建一张图；名单 不判、名单去掉等号、不去笔画字、像数字的字母不扩、量级单位前只隔空格、负号例外按文字区、科学记数法不算、单位不收十和 w、 句点不看前面是不是字母	2026-10-12 21:12:57 +08:00
ThearchyHelios	ce71f7d5c1	期 5 验收修复 N1 第 2 轮：取自遮罩格的指标只按确定取自遮罩列的认、转抄上游口径卡的也认；显示文字核对不误判正常写法，总览有一项无法核对就不给绿色的通过 ... 复核第 1 轮（abb2707）找到四处：写作目录按证据面板宁可多遮的那一套认指标出处，SQL 认不准时没碰号码列的销售额也成了 「已遮罩」，正式运行引用它就判失败（相对基线回退）；「紧挨着负号」连破折号「——」「—」和汉字「一」都算，「运费统一10元」 「合计——7,036.50元」原样导出变红（相对基线回退）；紧挨着改字只堵住了数字、负号、小数点，接「万」、画删除线、从右往左 书写的字母、l / I / O 照样全绿，根子在总览把无法核对的项也给绿色；第二张口径卡转抄遮罩指标（nodes.<卡>.metrics[0].value、 vars.<assign_to>.metrics[0].value、nodes.<卡>.text）时号码照样进写作目录、文档证据目录和可验证报告。 取自遮罩格的指标只按确定的那一套认（写作目录、报告自查、可验证报告同一个判断） - 写作目录（api/evidence.py 的 withheld_metrics）认指标出处时遮罩列只认确定取自遮罩列的（_InputMasks 的 sure：读得出来的 快照按单元格引用自查的 _cited_masks，读不出来的按数据源现在设的列名），和 [[v:…]] 引用同一格的自查同一个口径：WITH 写了 列名表、VALUES 当表、子查询里有没起别名的号码表达式、只装着分档标签的列，指标照常显示、照常引用；改了名字、套了函数的 号码列照旧「已遮罩」。证据面板、推演照旧宁可多遮。报告自查按目录里记的 masked 认，跟着同一个判断 - 可验证报告认老文档（证据目录里还写着原值，整份只给哈希）按同一个判断：api/bundle.py 先按证据面板的那一套认好每份查询 快照里确定取自遮罩列的列和这次运行查到过的遮罩值（certain_masks），交给 build_bundle（sure_columns、sure_secrets）， _Store.metric_word 的 sure 按它们认。认口径卡能不能随文件附带照旧宁可多遮（卡上记着输入的值），SQL 认不准的卡同基线只给 id 转抄上游口径卡的指标按上游那个指标认 - recompute.card_input 认出输入转抄了哪张卡的哪几个指标：nodes.<卡>.metrics[i].value、vars.<卡的 assign_to>.metrics[i]、 整个指标、输入、渲染算转抄那个指标；整张卡、清单文字、整份指标列表、下标不是字面量的同整份查询结果（值里有遮罩值才不给， 数指标个数的照给）；只取名称、单位、口径名的不算 - 证据面板 / 写作目录（_InputMasks._copied）、可验证报告（_Store._copied_kind）都用同一个 _metric_masks / metric_word 往上追， 上游取自遮罩格，转抄的也不给；追了 CARD_DEPTH（8）张还没追到头（循环里抄自己上一轮的产出）的宁可多遮 - 写作目录读快照前把运行状态里每张口径卡的输入一并读好，不在事件循环里读盘 显示文字核对（verifier.js） - 判不通过只剩紧挨着的数字、小数点，和真当负号用的三个（半角连字符减号、数学减号、全角减号）紧挨着数字开头、前面又不是 字母数字时（「SKU-12」「A-3」的连字符是编号的一部分）。破折号（——、—、–、―，小号的、竖排的）、波浪线、汉字「一」、 假名长音、制表符横线这些易混字当普通的字。连字符、不断行连字符、上下标负号、粗减号这类平时不当负号用的短横紧挨着数字 开头判无法核对（以前判不通过；基线也是无法核对） - 判无法核对（带原因）：后面接着量级单位（万、亿、千、百、兆、萬、億、%、‰、‱、k、K、M、B 及全角，中间隔着空格也算； 核对过的字以「万」「亿」结尾再接一个也算），核对过的字画着删除线或紧挨着画了删除线的字，紧挨着长得像数字的字母和数字 符号（l、I、O、上下标数字、圈码、罗马数字、汉字〇），从右往左书写的字母和方向控制字符（照旧） - 总览（overallOf）：一项无法核对都没有、每份报告都核对上才是绿色的「全部通过」；有无法核对的写中性的「可核对的项全部通过， 另有 N 项无法核对」，下面醒目地写明这个文件判断不了真伪，要在系统中核对封存（运行 ID、GET /api/runs/<id>/verify、定时任务 通知里的清单哈希前 12 位）。以前无法核对的项照样给绿色，伪造者只要让读者看到的那个数落进无法核对就行 - 交出 layoutOf 给 node 里逐条核排法；开发数据 39 份报告 1591 处、验收数据 58 份报告 1695 处引用按新规则扫过，没有一处判 不通过或无法核对 测试 - 新增 tests/test_report_masked_metric_sure.py（四种 SQL 认不准的销售额、分档标签照给照引、确定取自号码列的照旧遮、老文档 照常附带、写作目录和可验证报告逐个指标同一个判断）、tests/test_report_masked_card_copies.py（三种转抄写法在写作目录、文档、 自查、证据面板、可验证报告里都不给号码，没有报告的运行、老文档，转抄普通指标照给，认转抄的各种写法，追不到头的宁可多遮）、 tests/test_bundle_prose_export.py（「统一」「——」「—」「SKU-」「共…家」「–」真跑报告撰写节点、从接口导出，全部通过、总览绿） - test_bundle_shown：负号只认三个、前面是汉字的照判不通过；像负号的短横、量级单位、删除线、长得像数字的字母各自判无法核对、 总览中性；正常写法原样导出全绿；总览只在一项无法核对都没有时是绿的 - 样本页新增 prose（写作者自己写在引用旁边的普通文字，原样导出全绿）；check-bundle 补数学减号、紧挨着汉字加负号判不通过， 接万（隔空格）、接亿元、接 %、接 k、订单号接万、画删除线另写一个数、前面加小写 L、后面接大写 O、长得像负号的连字符判无法 核对，各自点名原因、总览中性并写明去系统里核对；有无法核对项的样本页（base、legacy、continued、missing-card、masked-card、 masked-source、nan）总览改断言中性，从右往左书写的字母那条不再断言总览是绿的 - 每处改动都做了「去掉实现、测试变红」：写作目录不用 sure、老文档不用 sure、sure 列不用、转抄认不出（三处各自）、追不到头 按核对不了、负号的字母数字例外、负号恢复成 \p{Pd} 全部、数学减号全角减号不算、量级单位、隔空格、以万结尾、删除线、像数字 的字母、像负号的短横、总览有无法核对照样绿	2026-10-12 19:09:50 +08:00
ThearchyHelios	abb2707904	期 5 验收修复 N1：取自遮罩格的口径卡指标不进报告文档和可验证报告；显示文字核对堵住紧挨着改字的绕过 ... 验收第二轮发现：口径卡 phone_raw = cell(q_cust, 0, 'phone') 被 [[m:phone_raw]] 引用时自查不拦，号码写进正文；写作目录、 文档的证据目录收着上游口径卡的全部指标和原值；可验证报告里口径卡的节点完成事件（预览逐条写着「指标（名称）= 值」）一律 附规范串，没有报告的运行也照样带出号码；另外只改紧挨着被引用数字的普通正文（前面补一位数、加负号、后面接「0 万」）、重算 全部哈希，读者看到的是另一个数，核对页只标无法核对，总览仍是绿的。 报告撰写节点 - 写作之前按证据面板指标步骤的那一套认出值取自遮罩格的指标（api/evidence.py 的 withheld_metrics → _metric_masks， recompute.withheld_value）：cell() 取的遮罩格、改了名字的遮罩列、按位置取的一格一行、整份结果里带着遮罩值的。写作 目录、存进文档的证据目录里这些指标的值、渲染、标签都写「已遮罩」并记 masked（evidence.withhold_metrics，没被引用的 也一样），写作目录另说不要引用 - 只按出处认（by_value=False）：认不出出处、值碰巧等于遮罩列某一格的普通指标（写死的目标 20000）不算，不然它在报告里 成了「已遮罩」、引用它的正式运行判失败、写作者也改不掉（自查第 3 轮去掉按值认是同一个道理）；证据面板展示上照旧多遮 - 引用这类指标照样解析、正文写「已遮罩」（换算不再算），自查记 masked_cell（evidence.masked_metrics），和引用遮罩格同一 套处置：交回重写，仍不改按「违规处置」办；缺口、日志、判失败的下一步说「指标」 - 写成「已遮罩」的别名记进节点产出（masked_metrics），出口契约复核按同一份重建目录（report_catalog），正文里的「已遮罩」 对得上，不说文档被改过；写作时按上游状态建目录，循环里重跑不沿用上一次记下的那份 - 证据面板点开这一处：值、渲染都是「已遮罩」，按文档写的比渲染，不报渲染不一致 可验证报告（bundle/build.py、verifier.js） - 口径卡的节点完成事件：卡只给 id（有输入取自遮罩列，或者有指标的值不给）的只给哈希，和报告引不引用无关；没有台账的 老运行按预览里的 artifact、节点产出工件认，都读不出来的按运行里有没有带遮罩的快照 - 卡只给 id 的判断另按指标认（_Store.metric_word，和写作目录同一个判断）：整行、下标不是字面量的一格、整份结果转成的 文字，以前只认字面量下标的一格，卡原样嵌了进去 - 证据目录里还写着这类原值的老文档（升级前生成的，或者生成之后数据源才设的遮罩）整份只给哈希、不附带它引用的工件， 报告节点的完成事件也只给哈希；快照读不出来时按它的数据源现在设的遮罩认，卡读不出来时按这次运行查到过的遮罩值认。 核对页照实说明原因（中性色），这份报告算未能核对，总览不是绿的；文档里写成「已遮罩」的指标所在的卡一律只给 id - 被引用的数字紧挨着（中间没有空白、标点）数字、负号、小数点判不通过，点名「正文里紧挨着这个数的字改变了读者看到的 数」；排在看不见、改变方向的字前面判，同一句里再放一个这种字也降不成无法核对。服务端组装的文档两个数之间补了空格， 原样导出照旧全绿（开发数据里 39 份报告、505 处引用，没有一处紧挨着） 测试 - 新增 tests/test_report_masked_metrics.py（目录、自查、重写、标注 / 失败、出口契约、证据面板、循环）、 tests/test_bundle_masked_metrics.py（没有报告的运行、新文档、老文档连同核对页、普通卡、和写作目录同一个判断、手搭的 几条分支）；样本页 masked-card 改成现在的报告撰写节点写的文档，新增 masked-old-doc；check-bundle 补数字前加数字、加 负号、后面接「0 万」三种篡改，各自变红、点名，原有的紧挨着补位、连字符两条改成不通过，报告文档标成遮罩那条改成总览 不是绿的 - test_report_masked_values 的 [[m:phone_raw]] 改成按出处拦、写死的热线号码照常引用；几处按旧的报告正文（「13位」 「11位」「26位」）找片段的测试改成按引用找（test_evidence_metric_masks、test_evidence_masked_aliases、 test_whatif_masked_values），断言照新的正文写	2026-10-12 17:23:27 +08:00
ThearchyHelios	652576bab3	验收第二轮的两处说法：审批质询整理回答那一步超时时，不再建议「缩小问题范围」（问题再小也要整理），改说调大时长上限或换用更快的核查模型，查询中途触顶的那句另补上可调大上限；反方判「被推翻」却没给理由时一句话说清「但没有给出理由」，不再先说「理由没有引用到任何查询结果」再接「反方没有给出理由」，固定的那句补上句号	2026-10-12 15:55:19 +08:00
ThearchyHelios	7cec3079f0	合入期 5 验收修复 M2：证据面板与推演按 SQL 认出改了名字的遮罩列；推演里取自遮罩格的指标不露原值；报告自查拦下引用遮罩列的格子（按列名对整个数据源生效，和证据面板同一个口径）；结论句裁判的摘录按快照逐份遮确定取自遮罩列的列；片段接口在没开结论句裁判时照实说；遮罩分析按快照工件 id 缓存	2026-10-12 14:17:45 +08:00
ThearchyHelios	1cfa5a524d	M2 复核第 4 轮：报告自查认遮罩列和证据面板同一个口径，哪张表（含视图）里叫这个名字的列都算；结论句裁判的摘录按快照逐份遮确定取自遮罩列的列；没起别名、盖住全部结果列的表达式算确定取自遮罩列，值照收 ... 第 3 轮的「遮罩表」推断和退回的裁判摘录各开了一个口子，收值时又把按位置认得出的列丢了： - 报告自查去掉「遮罩表」推断（_mask_owners）。数据源的 mask_columns 只认列名、不支持写成「表.列」，按列名在整个数据源上 生效：引用的那一格按 SQL 认出取自任何一张表里叫这个名字的列就记 masked_cell，视图（customer_spend.name）、没有第二个 遮罩列的表（employees.name）、门店名（stores.name）都算，和证据面板的遮法一致。以前经视图引用客户姓名、引用店员姓名， 正式运行照常成功，姓名写进了报告。SQL 血缘只用来点名出处，和排除值确实取自普通表别的列的（SELECT region AS phone FROM stores）；视图、表结构里没有的表、写了别的库名的表、没标 is_view 的老表结构、没有冻结表结构的快照看不出列的出处， 照算（_frozen_schema 只把 is_view 明写为 false 的表当普通表）。违规说明照实写取自哪张表的哪一列：「列「store」按 SQL 认出取自 stores.name，数据源对列名「name」设置了遮罩（按列名对所有表生效）」 - 交给结论句裁判的摘录按快照逐份遮（api/evidence.py 的 _judge_loader）：每份快照里确定取自遮罩列的列（_mask_sets 的 sure）并进交给 judge.prepare 的那一份快照的 mask_columns（工件本身不动），裁判照它自己的办法遮掉，judge.py 不用改。 c.phone AS tel 的号码不再进摘录；不按数据源名合并（另一份快照里同名、取自门店热线的列照给），不用宁可多遮的 hidden （整份遮的快照、只数个数的列照给）。按需裁判和报告撰写节点里当场裁判同一个函数。摘录变了的句子复用键随之变，此前 判过的会重判一次 - 收「这次运行查到过的遮罩值」：_sure 以前凡是要遮的列盖住了全部结果列、名字又对不上，就当认不准、整份算， SELECT UPPER(phone) FROM customers 一个值都收不到，证据面板之后照原样显示 SQL 里写着的号码。现在结果后面垫一列再认一遍 （_whole），垫的那一列也算进来的才是整份算的；按位置认得出的照收，整份遮的照旧只遮显示、不收值 测试：test_report_masked_owners.py 改名 test_report_masked_any_table.py 并按新口径改写（经视图改名 / 不改名、店员、门店名、 客户名真跑判失败且成果里没有值；* 展开、WITH、UNION、视图里改成遮罩列名字的列、没有表结构、没标 is_view、表结构里没有的 表、写了库名的表）；新增 test_judge_excerpt_masks.py（按需、当场两条路的摘录都不给改了名字的号码列，同名的门店热线照给； 没起别名的 UPPER(phone) 摘录也不给）；test_evidence_mask_memo.py 加没起别名的表达式照收值；违规说明的断言跟着改	2026-10-12 13:50:31 +08:00
ThearchyHelios	10653ffd3e	认不全写法的名单补上 Postgres 扩展里记着别的会话 SQL 的视图：pg_stat_monitor（语句原文）、pg_qualstats（条件里的常量）、pg_store_plans（执行计划），交回的就是带号码的原文，和 pg_stat_statements 同一类，工具边界整份遮、可验证报告只给哈希（K3b 统一复核留下的一条）	2026-10-12 13:14:36 +08:00
ThearchyHelios	89a4bc8cfc	合入期 5 验收修复 M1：核查 agent 正文里的依据标记不再断句——只装着依据的括号（含【】［］〔〕[]）连同里面的停顿标点一起去掉，去掉之后按真正挨上的两个字补空格，两个数不再并成一个；核查 agent 的提示词改成依据写在句末；收尾超时照实记 timeout_s；没给理由时照实说没有给出理由	2026-10-12 13:12:20 +08:00
ThearchyHelios	65d6a1e63c	M2 复核第 3 轮：报告自查只查引用、别的表里同名的列不算；裁判摘录退回只按数据源设的遮罩列；收遮罩值只收确定取自遮罩列的值；遮罩分析和收到的值按快照工件记在进程里 ... 第 2 轮的按值自查和面板那套宁可多遮的认法带进了误判，正式运行因此失败，代价远大于收益，这一轮回到规格原意： - 报告自查去掉按值在正文里找遮罩值（engine/evidence.py 的 masked_values、report.py 的收值）：两个字的姓名会撞上「销售 高峰」这类常用词，同名列的值会撞上门店名；照抄成正文的号码本来就会被「数字没有出处」拦下。时间线日志 report_masked_cell 不再带 written，decode.ts、terms.ts、证据审计的 CSV 回到「引用了遮罩列」一种说法，check-decode 同步 - 自查认引用时从 _mask_sets 的 sure 起，再按 SQL 血缘（sqlglot.lineage，按快照里冻结的表结构）核一遍值取自哪张表的哪一列 （api/evidence.py 的 _cited_masks / _owned_columns）：遮罩列不带表名，同名的列在几张表里都有、其中有的表另有别的遮罩列时 （customers 有 name 和 phone，stores 只有 name），只认那几张表，门店名不算客户姓名；值根本不取自遮罩列的（region AS phone）也不算。认不出出处的照算，没探查过表结构的照列名认。违规说明点名它取自的那一列遮罩列 - 交给裁判的摘录退回 M2 之前的做法，只按数据源设的列名遮（删掉 _judge_masks）：并进面板那套宁可多遮的列后，整份遮的快照、 只数个数的列从摘录里消失，被引用的金额、人数裁判看不到。按需裁判和节点里当场裁判都改回 - 证据面板、推演收「这次运行查到过的遮罩值」只收 sure 的列（_snapshot_secrets，同 masking 收值的口径）：SQL 认不准、整份 遮的快照只遮显示，里面的区域名、金额不再收成遮罩值 - 按快照工件 id 在进程里记下遮罩分析和收到的值（_SnapshotMemo，键里带数据源现在设的遮罩、在不在、类型，设置改了不拿旧的； 只记读得出来的快照，存取加锁，分析结果冻结、交出去的值另抄一份）：之后点开片段、推演都不再把全部快照读盘、复验、分析， 只读这一步要显示的那一份。30 份 500 行的快照，第一次约 0.7 秒，之后不到 1 毫秒 测试：新增 test_report_masked_owners.py（高峰、门店名写成文字照常出具，照抄号码由数字核对拦下，引用门店名不算、引用客户名算， 同一条查询里两张表的同名列、只设 name、* 展开、WITH、UNION、没有表结构、表值函数）、test_evidence_mask_memo.py（整份遮 的快照不收值、只读一次只分析一次、设置改了重新收、推演共用、再点开片段只读本步快照）；裁判摘录改测被引用的金额和计数 都在摘录里；按值自查的用例改成不按值认的回归	2026-10-12 12:33:32 +08:00
ThearchyHelios	60be16a0bb	M1 复核修正（第 3 轮）：依据两边什么都没有时也判粘连，两个数不再并成一个；只装着依据的括号认【】［］〔〕[]；右边紧贴着下文的半角逗号后面补空格 ... 渲染（evidence._tidy）： - 上一轮只沿着去掉的字往两边找粘连：依据前后没有空白、括号、标点时没有切口，「华东 [[v:Q1.r0.销售额]][[see:Q1]] [[v:Q1.r0.订单数]] 笔」渲染、组装都是「4,919.5212 笔」，「[[v:…]][[see:Q1]]2 月」是「4,919.52 月」，「**华东 [[v:…]]** [[see:Q1]]2 月」组装出「华东 4,919.52 月」，verify_doc 都不报。现在每个依据（连着写的一串、只装着依据的括号都算） 两边都判（_glue 看所有不显示的字，不只看切口），会读成一串的补一个空格：这一片有去掉的字的照旧换掉头一个，没有的 插在头一个依据前面（粗体收尾的星号外面） - 只装着依据的括号认【】、［］（全角半角混用也算）、〔〕、[]，和（）一样连括号去掉，外面悬着的停顿标点照原规则收拾； 依据在这些括号开头、末尾紧挨着分隔标点的，同（）一样收拾。核查 agent 拿到的查询结果以「【证据 Qn】」开头，模型照着 写成「【[[see:Q1]]】」，以前渲染成「【】」 - 右边是写作者紧贴着下文写的半角逗号的（「1,200（[[see:Q1]]）,900」去掉括号读成「1,200,900」），空格补在逗号后面 （同「212,[[see:Q1]],5」→「212, 5」）。上一轮把这一类当成可以不管的「）,5」写法；和基线 58a6759 逐份比，结构化组合里 有 2481 份是上一轮去掉括号之后才并成一个数的（「增长 12（[[see:Q1]]）,212 笔」→「增长 12,212 笔」），现在都隔开了 - 找挨上的字时也越过删除线的两个波浪线：前端照样画出删去的数，挨着后面的数读 - 流式渲染把这几种括号、半角方括号、波浪线也攒到后面的字来了再放；半角「]」攒着时，标记收尾的「]]」和标记里末尾的 空白不算，标记整个放出去，从它后面攒起 不含依据的文档渲染结果、内容哈希逐字不变：随机 1.6 万份不含依据的文档和基线逐份比过，BEFORE 两份哈希照旧。 测试：依据两边什么都没有（数、标记、粗体、斜体、删除线、连着写的一串）、几种括号（只装着依据、全角半角混用、套着、 和别的括号连着写、开头末尾带标点、不含依据的不动）、半角逗号的用例；结构化组合加上两种括号，中间只有依据的也算；流式 渲染、随机语料加上几种括号和波浪线；审批质询、核查 agent、反方审稿、双盲复算各补一个端到端用例。15 处改动逐一去掉实现， 相关测试都变红（第 2 轮的 7 处也重跑过，照样变红）。另在测试之外：复核用的抽查脚本 6000 份 × 6 个种子只剩写作者自己 写成「212,,2」的一份；结构化组合 29.4 万份、随机含依据的 1.6 万份和基线比没有新并成的数，流式逐字、随机分块都等于整篇 渲染。	2026-10-12 12:24:14 +08:00
ThearchyHelios	45987748ef	K3b 复核修正（第 3 轮）：VALUES 当一张表用又读到遮罩列的整份遮，列名按方言认；sys 库读 performance_schema 的 ps_* 函数进认不全的名单 ... - VALUES（复核 major，基线就有）：_function_columns 按 Postgres、SQLite 的习惯把 VALUES 的列记成 column1…，MySQL 8.0 实际叫 column_0、column_1…（真库实测），派生表、CTE、LATERAL 里的 VALUES ROW 取了号码，外层按名字取、照原名带出时 对不上，号码原样交给模型、落库；MariaDB 拿第一行的值当列名，同样对不上。现在 VALUES 当一张表用（FROM、JOIN、 LATERAL 里的，WITH 里的一段，UNION 的一支，整条就是它，_values_table）又读到遮罩列（含派生出来的名字）的，不论哪个 库、列怎么起名，整份遮。套了括号的 VALUES（整条、UNION 的一支）解析器原样挂在树上、不在任何 SELECT 的 FROM 里，以前 哪个库都没认（Postgres 也漏），一并收口。IN / ANY / EXISTS、标量子查询里的 VALUES 不算：值经外层的表达式带出，或者 只用来筛行 - 列名按方言认（_values_names，_function_columns 用同一套）：Postgres、SQLite 叫 column1…，MySQL 叫 column_0…（一行 ROW(…) 摊开数列），写了列名表的按列名表（Postgres 的列名表只改前几列），MariaDB、Oracle 认不准记 None。整份遮时只收 值取自遮罩列的那几列的值（_values_taken 按位置）：以前 VALUES 按表值函数认，出的每一列（连同 key、value、别名）都算， 同一行里没碰遮罩列的区域收成遮罩值，在同一次核查里处处被换掉 - 行为变化：Postgres、SQLite 的 LATERAL VALUES 读到遮罩列，以前只遮那几列，现在整份遮（多遮，同一份里的编号也遮）； 原来「VALUES 里直接写遮罩列只遮那一列」的用例改成整份遮 - sys 库（复核 minor）：INDIRECT_NAMES 的 sys 规则补上按 sys.ps_ 开头认的函数（ps_thread_trx_info 交回线程的事务里执行 过的语句原文，ps_thread_stack 同类；只交回编号、开关的 ps_thread_id、ps_is_* 一并算，多遮；不写 sys. 的要默认库就是 sys 才执行得了，不认，同 sys 的视图）。工具边界和可验证报告共用这一份名单，报告不再判它没碰遮罩列、照常附带快照 - 质询模块说明的已知局限同步 补测试：VALUES 当一张表用 × MySQL（派生表、LATERAL、CTE、外层改名、JOIN LATERAL、LATERAL 子查询、标量子查询、派生 出来的名字、UNION 第一支、整条套括号、派生表里 UNION 的一支）、MariaDB 两种、Postgres 三种、SQLite 一种；三种没读到 遮罩列的对照；四种写法的收值（号码收、区域不收）和 (表达式).* 之后不按位置收；_function_columns 四种列名、两种认不准； 核查 agent 真实查询工具上的端到端（复核点名的三条 MySQL 写法）；sys.ps_* 六种写法、三种不该误伤的对照、可验证报告 两种、端到端一条。逐项去掉实现（整份遮、MySQL 的起名、按位置收值、当一张表用的位置、整条就是 VALUES、VALUES 不按表值 函数认、摊开 ROW、列名表、_function_columns 的起名、(表达式).* 之后停、MariaDB / Oracle 认不准、sys.ps_），对应的测试 都变红。另在 MySQL 8.0.46、Postgres 18 临时实例上经核查 agent 的真实查询工具复跑 28 条（MySQL 的 VALUES 14 条、对照 4 条、sys 函数 4 条，Postgres 的 VALUES 6 条）：交给模型的、落库的、通用工件接口给的都没有号码；2b5989e 上其中 16 条漏 号码（sys.ps_thread_stack 在只读事务里执行不了，前后一样）。	2026-10-12 12:18:34 +08:00
ThearchyHelios	2b5989ef00	K3b 复核修正（第 2 轮）：VALUES、行构造器里的 (表达式).* 和交回复合类型的表值函数整份遮；记着别的会话 SQL 的视图、不只读表结构的 SHOW 和 EXPLAIN 整份遮 ... - VALUES 里的 (表达式).*（基线就有）：Postgres 在 VALUES 里同样把复合类型、记录展开成好几列，LATERAL VALUES 按表值 函数认时一个元组项只算一列，column2 起的号码原样交给模型、落库。现在 (表达式).* 不只看选出项：树上任何位置的（VALUES、 行构造器、函数参数里的），以及 VALUES 里的 s.*、(s.*)，读到遮罩列就整份遮。(表达式).* 的值只按那个表达式认，不再把 * 当成展开 FROM 的来源（没设遮罩的复合类型 (p.address).* 以前因此被整列遮） - 同一类、复核没点到的：Postgres 里 FROM 中交回复合类型的表值函数。unnest 的数组元素是复合类型时展开成各个字段 （unnest(ARRAY[p.card]) 出 addr、tel，写了列名表也只改前几列的名字），不认得的函数只写了列名、没写类型的列名表 （jsonb_populate_record(NULL::contact, …) AS r(a) 后面的字段照原名出），读到遮罩列的整份遮（_spreads_record）；拆普通 数组的 unnest 也一样（元素类型 SQL 里看不出，多遮）。写了带类型列定义的照写的认 - Oracle 的 JSON 点号、对象类型的属性（t.profile.tel，解析器读成库、表、列）：前面几段也算列，以前只认 tel，号码原样交出 - 记着别的会话 SQL 原文、被锁那一行的值的来源补进 INDIRECT_NAMES（工具边界和可验证报告共用一份）：MySQL 的 INNODB_TRX、 OPTIMIZER_TRACE，MariaDB 的 INNODB_LOCKS、QUERY_CACHE_INFO，Oracle 的 V$ / GV$ / X$ 一律算、AWR 历史、SQL 调优集和 调优顾问、固定的执行计划和 SQL Profile、闪回事务，DBMS_XPLAN、DBMS_SQLTUNE 这类出报告的包 - 不是查询的语句（_reads_beyond）：只读表结构的 SHOW（表、列、索引、库、表状态、建库语句）、DESCRIBE / EXPLAIN 一张表 照常，别的 SHOW（ENGINE INNODB STATUS、BINLOG / RELAYLOG EVENTS、REPLICA STATUS、WARNINGS、PROFILES、CREATE TABLE / VIEW、TRIGGERS……）、EXPLAIN 一条语句（MySQL 把只有一行的表的值代进计划里的条件，8.0 实测）不逐个认，一律整份遮。 SHOW CREATE TABLE 不算只读表结构：对视图交回的是视图定义（WHERE 里写死的号码，8.0 实测），以前因为写着 TABLE x 本来 就整份遮，照旧；SHOW TABLE STATUS 以前同样因此整份遮，现在照常 - 质询模块说明的已知局限同步；补一条：视图、函数、约束定义里写死的字面量（information_schema.views、pg_views、 pg_get_viewdef()……）不认，照常交给 agent 补测试：VALUES × LATERAL / JOIN LATERAL / CTE / FROM / 匿名 ROW / 整行 / 表和子查询的 *，函数参数里的 (表达式).*， 没碰遮罩列的对照；交回复合类型的表值函数九种写法和三种照旧按名字认的对照；Oracle 点号四种和两种对照；十九种视图和包、 十三种 SHOW、九种 EXPLAIN、十二种只读表结构的对照；核查 agent 真实查询工具上的端到端（Postgres 的 VALUES 展开、MySQL 的 INNODB_TRX 和 SHOW ENGINE INNODB STATUS）。逐项去掉实现（(表达式).* 的取值、树上的 Dot、VALUES 里的 *、新名字、 _reads_beyond、只读表结构的豁免、SHOW CREATE TABLE、unnest、只写列名的列名表、三段名），对应的测试都变红。另在 Postgres 18、MySQL 8.0 临时实例上经核查 agent 的真实查询工具复跑复核的复现和上面这些写法（44 条），交给模型的、落库的、 通用工件接口给的都没有号码；169c500 上其中 23 条漏号码。	2026-10-12 10:50:40 +08:00