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

..

nodes

报告撰写节点的「上游没有可引用的来源」认分析结论（_CITABLE 加分析结论，_no_evidence 照 00-总方案 D10）：「证据来自」只选了分析卡时不再误报没有可引用的来源；分析卡做的结论总能引用，受管级别的正式出具没开「单元格引用」、上游有分析卡结论时也不再报「只有查询结果…无法引用单元格」；Agent 现场做的分析和它查的格同一个规矩，没开单元格引用时照报，说法写明「只有查询结果和 Agent 现场做的分析…无法引用单元格和这些分析结论」，只有查询时一字不变。测试：只有分析卡结论（开没开单元格引用都不报）、Agent 的分析按单元格引用的规矩、什么都没有时点名分析结论

2026-10-21 16:04:42 +08:00

__init__.py

…

analysis_claims.py

「连续」按趋势结论记的末尾连续同向核（values 的 run_direction、run_length），不再先要整体判定是上升或下降：算子修复后趋势判定语在方向相反时写「，但最近已连续 N 期上升」，句子照它写「最近已连续 4 周上升」要对得上，整体没有明显趋势、末尾连续下降的也能说连续。句子写了期数的（「连续 5 周上升」「三连降」「十二连涨」，阿拉伯数字、全角数字、一到九十九的中文数字）要 run_length 不少于它，没写的至少 3 期；方向对不上照旧报相反；没记 run_direction 的老结论按整体的趋势方向。测试：期数不够、整体下降而末尾连续上升、没有明显趋势而末尾连续下降、老结论，和各种写法认出的期数

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

analysis_scope.py

报告文档里系统写的「分析范围」（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

approval.py

驳回不再记成失败（后端）：人的驳回收成 cancelled + end_reason=rejected，消费方都读这一个字段

2026-10-16 10:14:27 +08:00

autofix.py

自动修复和门禁对 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

cell_format.py

报告里标识列的数不分千位（产线编码 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

checkpoints.py

copy-to-postgres 在真实开发数据上核对不过的几处（复核 R-a1、R-a2、R-a3、R-a8、R-a13）

2026-10-19 12:06:31 +08:00

compare.py

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

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

compiler.py

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

context.py

子工作流里的写入跨升级认旧键时按事件和内容认是谁的、是哪一笔（复核 L1、L2）：升级前子图里的写入按子图里的 id 记键，和父图同名节点的键一样。以前父图有同名节点时一律不认旧键：子图里结果未知的那一笔核实为已生效后接着跑，用新键又发一笔；父图那个节点按自己的键找到子图那一笔、交回它的回执，自己那笔一直发不出去。现在一条记录是哪个节点写的按它的 action.* 事件上记的节点 id 认（认不出的按能力和内容指纹）：按自己的键找到别人那一笔的换一个只属于自己的键；认旧键时还要内容指纹是这一次的——跨升级的循环第二轮按老算法同样是第 1 次执行，找到的是第一轮那一笔，金额不同就照常发，不再记「已经生效」。去掉不再用的最外层节点 id 传递；改对两处过时的说明（审批恢复时子图从自己的断点接着跑；终态事件的途经驳回含子工作流里的）。补跨版本测试：同一个进程里先装成升级前的代码跑到挂起、再换回现在的代码接着跑

2026-10-19 11:43:41 +08:00

deadline.py

…

direct_select.py

…

dual_check_facts.py

…

evidence.py

结论句的判定回到原来的方向词、因果词（evidence._DIRECTIONAL 照 main 原样）：W1-d 为了让裁判优先判判断句把「主要、集中、异常、偏离、持续、趋势、显著、大幅、新高、新低、抵消、分散」等加进了 _DIRECTIONAL，可 _classify 用同一个正则认结论句，没有数字、没有引用的「下面是主要渠道的表现。」「促销期间活动效果显著。」「整体运行平稳，未见异常。」就成了结论句，结论句策略要求挂依据（模板 ⑨ 和已发布的受管版本都这么写）时计入缺口、出具降档，改了已发布版本的档位；出口的 io._concluding 也照它认代码块里的正文。扩充的判断词挪到 judge._JUDGEMENT，只给 claim_priority 排送判的先后（结论句里有它们的排第二）。测试：判断词让结论句先送判、不让连接性的话变成结论句；结论句要挂依据、出口带契约的周报多写这三句，档位照旧 formal、没挂依据的结论 0 句

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

expressions.py

普通用户建应用（后端）：

2026-10-15 12:09:29 +08:00

governance.py

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

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

guards.py

…

inquiry.py

普通用户建应用（后端）：

2026-10-15 12:09:29 +08:00

issuance.py

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

judge.py

结论句的判定回到原来的方向词、因果词（evidence._DIRECTIONAL 照 main 原样）：W1-d 为了让裁判优先判判断句把「主要、集中、异常、偏离、持续、趋势、显著、大幅、新高、新低、抵消、分散」等加进了 _DIRECTIONAL，可 _classify 用同一个正则认结论句，没有数字、没有引用的「下面是主要渠道的表现。」「促销期间活动效果显著。」「整体运行平稳，未见异常。」就成了结论句，结论句策略要求挂依据（模板 ⑨ 和已发布的受管版本都这么写）时计入缺口、出具降档，改了已发布版本的档位；出口的 io._concluding 也照它认代码块里的正文。扩充的判断词挪到 judge._JUDGEMENT，只给 claim_priority 排送判的先后（结论句里有它们的排第二）。测试：判断词让结论句先送判、不让连接性的话变成结论句；结论句要挂依据、出口带契约的周报多写这三句，档位照旧 formal、没挂依据的结论 0 句

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

labels.py

算子的叫法只留契约一份：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

launch.py

分析能力入口（四）：发起运行时把分析设置快照进 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

layout.py

驳回出口（后端）：审批、补充输入、编辑稿件、动作确认、代码和工具审批、双盲裁决接了「驳回」出口时沿它往下走

2026-10-18 15:56:29 +08:00

lineage.py

复核修正（后端）：子图里的报告不再被判「疑似被修改」、驳回出口的双盲裁决照样降档、可验证报告与推演按卡所在的层找产出、子图那一步写名字

2026-10-18 18:15:37 +08:00

lint_capabilities.py

…

lint_process.py

子工作流的证据交回父图（后端）：子图每一步进同一个运行、台账和口径卡交回、出口字段带出处、父图跨子图往下追

2026-10-18 16:11:15 +08:00

masking.py

…

merge_query.py

…

origin.py

系统派生的运行不进使用统计（总方案 X1、X2，细案 01 做法 4）：评测一跑，聚类、白名单、目录使用热度都会被刷高

2026-10-16 10:18:12 +08:00

provider_refs.py

…

recompute.py

口径卡分母为 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

replay.py

驳回出口之后，待办、通知、Webhook 照实说转到哪：中断内容带上驳回之后去哪（engine/replay.reject_route：接了驳回出口写转到哪几步，没接的写运行就此结束，审批没接、没设驳回即终止的写这一路到此为止），待办卡的提示、驳回按钮、驳回后的提示、处理过的「结果」照它说，不再一律写「转入驳回分支」「本次运行终止」；超时驳回不再露出英文结论码；双盲裁决、动作确认被驳回的提示同样照它说。子工作流里的关卡走驳回出口时，名字记成「子工作流 › x」（RunContext.global_label），走过的那几步交回父图的 trail，父运行的终态事件照实带上途经驳回，实例页、通知写「「子工作流 › 把关」被驳回，转到「子工作流 › 退回」」，不写内部 id、不写成已完成。定时任务的 Webhook：照驳回那条路成功结束的，标题、状态写途经驳回，另起一行写谁被驳回、转到哪一步

2026-10-19 08:59:15 +08:00

review.py

复核认分析能力一轮的三种日志：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

run_append.py

…

runner.py

复核 R-b15（隔离后等不到重新登记的运行原因记错、任务没摘）：_drive 里 fence.ready() 等不到时照实收尾——排队中的（一步都没执行过）收成失败，写明「本进程隔离后没能重新登记，这次运行没有开始执行」并记 run.failed；要接着执行的（继续、批了审批）收成中断、断点完好可继续运行；条件更新，状态、属主变了（别的进程先接手）就不动；执行任务从 run_manager._tasks 里摘掉。补测试：隔离后新身份一直没登记上，新发起的运行收成失败、原因写对、run.failed 记下、任务摘掉

2026-10-19 15:08:39 +08:00

schema.py

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

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

spend.py

合入 W2-a 的复核修复（nr8/a：导入的 NOT NULL 补值与孤儿行、收尾 dispose、sslmode 换算、PostgreSQL 写入去 NUL、不分大小写搜索 contains_ci、json_eq 两库同语义、JSON 守卫、用户可见列表补决胜键、bubblewrap --clearenv、部署脚本与原子写的几处、README 连接数预算）

2026-10-19 12:21:38 +08:00

sql_problems.py

分析结论进证据链（引擎）：台账 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

state.py

…

tolerance.py

评测执行的主干：后台评测、无头作答、评分、统计、对比与 A/B、清理（下一轮第 3 波 W3-c 第一段）

2026-10-16 16:38:09 +08:00

toolcalls.py

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

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

upgrade.py

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

variables.py

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

verify_agent.py

目录视图接缝 data/catalog_view.py（细案 01 做法 5，总方案 X7）：读目录的四处统一经它，「开目录 / 关目录 / 只用已核实的项 / 目录快照」的对照才做得了

2026-10-16 10:28:01 +08:00