yilunjiang/AgentLab
1
0
Fork 0
mirror of https://github.com/ThearchyHelios/AgentLab.git synced 2026-11-15 01:11:59 +00:00
Code Issues Packages Projects Releases Wiki Activity
784 Commits 4 Branches 0 Tags
68ea3a7f4792e233e0ff5ad69d56a288ed8bf840
Commit Graph

784 Commits

This Branch
This Branch
All Branches
Author SHA1 Message Date
ThearchyHelios 68ea3a7f47 口径账本内核第一步：sql_semantics 加参数绑定与等价证明（bind_template / match_template） 
为什么：口径账本要认出「这次执行的 SQL 是不是某一版口径的取数」。只比 normalize_sql 的文本会错给信任（status = 'paid'
和 'refunded' 文本相同），拿模板原文直接比 explain_sql_diff 又永远不等价（参数不同）。做法照 next-round 02 做法 1：

- 绑定只是启发：模板里的 {{ input.<字段> }}（可带 trim / compact）按位置换成哨兵，依次在 optimizer、light、parsed 三级
  规范形式上抹掉字面量的值比结构，结构一样就按位置配字面量（半截字面量按正则取，写死的常量必须相等，同一槽位取同一个值）；
  三级都配不上时退回「同一列、同一运算符」的启发式配对（只给说明和预填）。
- 等价只由按绑定 render_template（运行时同一个渲染器）渲染出的口径 SQL 交给 explain_sql_diff 判；有槽位既没取到值又没有
  缺省值时不证明（渲染出 EXISTS (SELECT  FROM …) 这种口径实际不会执行的 SQL，sqlglot 照样能解析）。
- 不可比照实给原因：引用 vars. / nodes. / file_text、参数写在名字里、别的过滤器。
- 等价时按位置给列映射（外层别名不计、列先后计，SELECT * 按表结构展开）。

测试：新增 test_sql_binding.py（认得出、不错给信任、不可比、列映射）；test_sql_equivalence.py 加「口径模板」一节，语料里
每一对把 B 的头两个字面量换成槽位当模板拿 A 比，判了等价的在虚构库上执行结果必须一致、explain_sql_diff 也必须判等价。
去掉「槽位没值不证明」那一道回跑，这一节抓到 11 对执行报错。
 2026-10-16 13:39:15 +08:00
ThearchyHelios 301a599e9c 骨架补上口径账本的包 app/ledger（账本内核和评测的派生图都要往里写） 2026-10-16 13:09:07 +08:00
ThearchyHelios 898e95a3ef 下一轮第 2 波的契约骨架：用户加 kind（服务账号）、剖析任务加上传表格的快照 id、工件按种类的索引；新模型文件 models_sources、models_eval（整模块导入）；评测、访问密钥的路由模块和口径账本按运行读的路由先登记好权限（评测只给搭建者，访问密钥登录即可，账本按运行读的和证据同一道门） 2026-10-16 13:07:40 +08:00
ThearchyHelios 6854909dcd 合入下一轮第 1 波（docs/design/next-round）：评测底座（后台任务运行时上移、系统运行不进使用统计、全站唯一的问题聚类、目录视图接缝、问数据生成过程 answer_ops 与用量计量、问数据的决定下沉后端、每日账泛化、定时目标底座、通知事件登记表）；已知遗留（人工驳回记为被驳回不算失败、个人渠道「我发起的实例」生效、导入清单如实记认证、使用者选人按候选池核对、自由形蓝图「谁来做」、tick 按 id 断言）；目录方言与 Excel 期 5（剖析方言修正与金样、本机四库容器集成测试、列表按期累积、穿插小计、表格对象起草、CSV 走配方）；集成底座（安全响应头、对外访问地址只留一个、开登录时收起 /docs、集成接口错误码）。验收：后端全量 13463 通过；tsc、文案检查；本波相关的 15 项浏览器检查 4939 项全过；四种数据库容器集成测试全过；泄露扫描干净 2026-10-16 13:01:47 +08:00
ThearchyHelios 853a130c93 README：第 1 波的行为变化与升级说明（驳回记为被驳回、选人按候选池核对、安全响应头、对外访问地址只留一个、/docs 收起、列类型完整写法与重新探查、剖析设置改名）；核心能力的人工介入、表格入库、追踪与成本三行；安全边界补安全头、错误码、系统运行不进统计 2026-10-16 12:54:13 +08:00
ThearchyHelios 736b031282 SQL 检查认时间列时带上 ENUM 的取值列表：PG 里类型名带 DATE 的枚举列，剖析不认是日期列、SQL 检查却认，两边对不上 2026-10-16 12:53:07 +08:00
ThearchyHelios 3f5cf79b26 合入 W1-d 集成底座：安全响应头（frame-ancestors 缺省 self、白名单、script-src 先只上报）；对外访问地址只留一个设置（环境变量优先）；开登录时收起 /docs；集成接口的错误一律带机读码 2026-10-16 12:51:43 +08:00
ThearchyHelios 02abede047 合入 W1-c 目录方言与 Excel 期 5：剖析方言修正（IN 两边类型族、列类型存方言完整写法与 ENUM 码值、Oracle 小写引号名、统计过期复核、无效日期、按存储顺序取前 N 行的说法）、方言金样与 sqlglot 校验、本机容器集成脚本；Excel 列表按期累积、穿插小计、表格对象起草、CSV 走配方 2026-10-16 12:51:43 +08:00
ThearchyHelios 696cd17a4a 合入 W1-b 已知遗留：人工驳回记成已取消 + end_reason=rejected（不重试、不被出错时继续吞掉），各处照实写「被驳回」；个人渠道「我发起的实例完成 / 失败」生效；导入清单如实记「是否认证」；使用者选人按候选池、开登录时服务端核对；自由形蓝图按导入的图列「谁来做」；tick 按 id 断言 2026-10-16 12:51:43 +08:00
ThearchyHelios e17c93ad9b 合入 W1-a 评测底座：后台任务运行时上移 core/job_runtime.py；系统派生的运行（评测、对账、召回）不进使用统计，全站唯一的问题聚类；目录视图接缝；问数据的生成过程抽成 answer_ops、计量助手建图和复核的用量、这一轮的花费；问数据的决定下沉到 chat/turn.py；每日账泛化成 Ledger；定时目标的底座；通知事件改成登记表（六个新事件登记、还没推送的不能订阅） 2026-10-16 12:51:06 +08:00
ThearchyHelios e96b0180d9 可验证报告、报告导出写「被驳回」：元信息带 end_reason，核对仍按运行取消 
为什么：被驳回的运行导出后，可验证报告的运行结果写「已取消」，报告导出的运行状态也写「已取消」，和系统里「被驳回」两种
说法。封存里被驳回和手动停止是同一种结束事件（运行取消），分开它们的原因在那条事件的内容里，而运行取消的内容不随文件
附带（里面有驳回人和备注）——光看封存分不出来。

做了什么：
- 两种导出的元信息都带 end_reason（bundle/build、report_export/build、对应的接口）。
- verifier.js：运行结果按运行记录写「被驳回」，核对的仍是「最后一条结束类事件是运行取消」，旁边写「已核对运行取消，被驳回
  取自运行记录」，原因里写明这一半要去系统里对照；手动停止、老运行照旧「已取消」；文件里写被驳回、事件却是运行结束的照旧
  不通过。runtime.js 的运行状态照 end_reason 写「被驳回」。
- 样本页加一份 rejected（check-bundle 样本数 17 → 18），断言写被驳回、写明取自运行记录、不提重新封存。

测试：test_bundle_rejected 用 node 载入 verifier.js 核运行信息（被驳回、手动停止、老运行、伪造）；test_bundle_build 核
元信息和样本页；test_bundle_api 核两种导出接口都带 end_reason。把实现退回去回跑，被驳回、伪造两条和元信息、样本页、
接口的断言都失败（手动停止、老运行两条守的是原样，照旧通过）；改完通过。
 2026-10-16 12:46:48 +08:00
ThearchyHelios b6cb5816db 问数据：被驳回的那次尝试不写「已手动停止」，会话列表标「被驳回」 
为什么：一轮的运行被审批人驳回之后点「重新运行本轮」，「之前的尝试」那一行写「已手动停止」，用户其实没有停过它。会话
列表的 last_status 把被驳回的一轮归成 cancelled，左栏不标——在等审批的那一问被驳回之后，看起来像是答完了（以前驳回
记成失败，左栏标的是「失败」）。

做了什么：
- store/chat 的 attemptOf：被驳回的那次记 outcome=rejected，摘要写「被驳回：张工 驳回了「查数」：…」；老留档里记成
  cancelled 的不改写。ChatPage 的尝试徽标认 rejected。
- api/conversations 的 last_status：前端落库时 meta 里记着 rejected 的、页面关掉没落库而运行是 cancelled +
  end_reason=rejected 的，都记 rejected；手动停止照旧 cancelled。types 的 last_status 加上 rejected。
- 左栏：打开过的看最后一轮（相位 cancelled 且带着驳回），没打开过的看 last_status，都标「被驳回」（不画异常色）。

测试：test_conversation_status 加一条（两种认法的被驳回、两种手动停止），改之前失败；check-chat 加一节被驳回（刷新后
认得出、补救区的话、左栏两种、重新运行之后的尝试记录），把前端改动退回去回跑，那一节 4 项不通过，改完通过。
 2026-10-16 12:46:36 +08:00
ThearchyHelios 58c26baa33 记录页、画布上找得到被驳回的运行：分段、计数、搜索词、遥测、缩略条、运行胶囊 
为什么：被驳回的显示码 rejected 不在 RUN_STATUS_ORDER 里，也不在计数的 COUNTED 里，搜索词表里没有「驳回」。点「已取消」
分段时服务端交回了它，前端按显示码一筛又筛掉了；以前它算在「失败」里，现在哪个计数里都没有；搜「驳回」不当状态词认；
详情的状态格没有副标题，缩略条没有结束标记。画布的运行胶囊更糟：相位是 cancelled，写「已取消」，一句话写「张工 取消了
本次运行 · 停在「研究协作团队」」——驳回的人并没有停过它。

做了什么：
- lib/status：RUN_STATUS_ORDER 在已取消后面加上 rejected（分段、搜索词表都从它生成），查询时照旧换回 cancelled。
- 计数加上被驳回；搜索词另认「驳回」「已驳回」；缩略条和已取消共用一个结束标记（同一个剪影和颜色）。
- 遥测的状态格：副标题写谁在哪一步驳回、备注（REJECTED_TEXT.sub，和时间线那一行同一句）；run.cancelled 还没取到时
  按驳回的那一步说。
- 运行胶囊：run.cancelled 带 reason=rejected 或运行记录 end_reason=rejected 时，状态写「被驳回」，一句话写
  「张工 驳回了「主管审批」：口径不对」，不再接「停在…」；回放到中途照旧说那一刻的相位。手动停止照旧。

检查：check-runs 加一节（伪造被驳回、手动停止、失败各一条）：分段和计数里有被驳回、已取消和失败的计数都不含它、点被驳回
只留它、点已取消只留手动停止、搜「驳回」「被驳回」都筛得出、失败页签里没有它、详情显示码和状态格。check-canvas-fx 加
一节被驳回的胶囊。把这几处改动退回去回跑，check-runs 4 项、check-canvas-fx 3 项不通过；改完都通过。
 2026-10-16 12:46:35 +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 80fcf27732 配方导入只把 .csv / .tsv 当 CSV 读；网页、XML 冒充的 Excel 照旧拒收并说清楚 
复核发现（C-csv-sniff-any-text）：配方导入的扫描入口 scan_any 只看内容，不是 zip、不是 OLE、前 64KB 没有 NUL
就当 CSV 读，不看扩展名。企业系统常见的「HTML 表格冒充 .xls」、误传的文本文件，会被拆成一张叫「CSV」的工作表去
起草、核对；给已有 xlsx 配方传新一期时还会报找不到工作表、给出 rename_sheet 修复，都误导用户。

改法：
- 和简单导入（tabular._CSV）一样按扩展名定：scan_any(原件, 文件名) 只把 .csv / .tsv（且内容是文字）按 CSV 读，
  别的照旧交给 xlsx_scan 拒收。内容以「<」开头的（网页、Excel 2003 的 XML 表格，含带 BOM 的 UTF-8 / UTF-16）另给
  一句「它其实是网页或 XML 格式……请用 Excel 打开后另存为 .xlsx 或 .csv」。扩展名是 CSV、内容却不是文字的（图片
  改了扩展名）照实说；内容其实是 xlsx 的照工作簿读。
- .tsv 一律按制表符分隔（同 tabular）：每行逗号、制表符个数都一样时，csv.Sniffer 优先挑逗号，会把 TSV 拆错。
- 扫描时定下的分隔符记进工作表的 path（"csv:," / "csv:\t"），读格子（xlsx_cells.sheet_rows）用同一个，重放、
  试运行不再各嗅各的；这一版之前只有「csv:」的照旧再嗅一次。
- Pipeline.scan 改成 (原件, 文件名)，recipe_imports 的四处调用都传上暂存区记下的文件名。

测试：test_csv_grid 加 .txt 的 CSV 内容拒收、四种网页 / XML 冒充 .xls 的拒收说法、.csv 扩展名的图片、TSV 按制表符
并且分隔符经扫描 JSON 往返后读格子照用、老暂存区的 path；改回只看内容回跑两条失败。
 2026-10-16 12:23:19 +08:00
ThearchyHelios 70c5a006d2 像小计的行只认夹在明细中间的；可以在配方里声明「没有小计行」，不再每期确认 
复核发现（C-subtotal-suspect-false-positive）：没配小计时，_suspect_word 对只有「标签文字列 + 数字列」的列表
不加限制，「其余文字列为空」自然成立，首列以 合计/总计/小计/汇总/累计 开头的普通数据行都被报 subtotal_suspect，
最后一行也报（说明却写「夹在明细中间」）。这是必勾的确认项：存量配方（「累计充值」「累计消费」这类键值清单）
升级后每一期导入都多一项，工作流里「按配方导入一期」直接被 files/imports._needs_people 挡下；确认又记不住，
只能用 declare_subtotals 把真数据改成小计。

改法：
- 执行器（recipe_engine._watch_suspect / _settle_suspects）：这一行本身像小计（首列以合计字样开头、其余文字和
  日期列空着、有数）之外，还要上一行明细在某个文字或日期列上有值、这一行那一列空着，并且下一行明细在同一列上
  也有值（或者下面紧跟着合计行——最后一组的小计也在列表里面）。候选先挂着，等下一行明细再定；列表到头了还挂着的
  不报。两列的键值清单因此不会报；上下明细那一列本来就空着的也不报。
- 配方新增 ListRows.no_subtotals（缺省 false，规范化时省略，存量配方的哈希不变）：人确认过这张列表没有小计行，
  以合计字样开头的行照常是数据，执行器不再报 subtotal_suspect。它是放宽，出确认项 no_subtotals:<块>，签名只看
  这个开关，配上（或改过）的那一次确认一次，之后各期不再出。和 subtotals 二选一，同时配了报 subtotals_conflict。
- 配方面板「小计行」里没勾「有小计行」时多一个勾选框「没有小计行（以合计字样开头的行也是数据，不再提醒）」；
  勾上「有小计行」时自动去掉它。subtotal_suspect 的说明改成「上下明细都有值的文字列在这一行空着」，并说明以后
  不想再确认去哪里勾。
- check-manage 加一步：勾选「没有小计行」发 PUT，no_subtotals 为 true。

测试：test_recipe_p5 加复核的两列反例（门票收入 / 累计收入 / 汇总调整 / 餐饮收入；最后一行「合计调整项」）、
最后一行和上下明细那一列空着的反例、夹在中间和紧跟合计行的正例、no_subtotals 的导入、确认项、签名和冲突校验；
去掉「要有下文」的条件回跑两条失败。
 2026-10-16 12:17:33 +08:00
ThearchyHelios 479cec0af7 通知事件一次登记（总方案 X6、5.1）：六个新事件进 notify/service.EVENTS，推给哪几条路也登记在那一处 
复核指出 X6 漏做：第 2、3 波的数据源变化、口径召回、评测、触达四块都要往 EVENTS、EVENT_LABEL 和前端设置页的事件列表里
加东西，正是 X6 要避免的同一处多方冲突；消息里能放什么也没有一处先定好。

做了什么：
- EVENTS 改成登记表：每个事件一行，叫法 + 推给哪几条路（scopes：global 全局渠道自己订阅、user 相关的人自己的个人渠道、
  app 应用版本 spec.notify 的订阅）。本轮新登记 source.changed、ledger.recall、eval.regressed、eval.failed、task.digest、
  key.expiring，scopes 都是空的——登记了、还没有推送。实现推送的那一块只改自己那一行的 scopes（各行之间隔着说明行，几块并行
  改也不会挨着冲突），前端叫法表不用再动。EVENT_LABEL 从登记表派生，老的 import 不变。
- 模块说明写清消息结构：标题、状态、条数、链接，加编号和搭建时起的名字；不放报告和答案里的数、表名、列名、取值、SQL、
  按运行数据渲染出来的句子。
- _channels 只走事件登记了的路；没登记的事件直接报错（推送之前先登记）。现有五个事件登记的路照现在的做法，行为不变。
- 接口：订阅按登记核对（subscribe_problem）：没推送的「还没有推送，暂时不能订阅」，范围不对的「不推给范围是「应用」的
  渠道」。只核对这次新勾的：以前存下的照旧，开关、改名不会因此 422。GET /api/notify/events 多给 scopes（空的照实给）。
- 前端：terms.ts 的 eventLabel 和 EVENTS 一一对应、逐字一致，六个新事件先有叫法；设置页的渠道编辑框、应用的通知改按
  GET /api/notify/events 列（这种范围收得到的才列，已经勾着的照样列出来能取消；取不到时照实说）。

顺带修掉的（就在要改的那张列表上）：设置页以前按前端叫法表的键列事件，里面有五个服务端从来不认的（待办升级、待办超时、
待办处理完、动作失败、动作已生效），一勾保存就 422；改派、升级、催办只在投递记录里出现，另起 deliveryEventLabel（加上测试
消息），记录里照实写是哪一种。服务端 EVENT_LABEL 的四句老叫法（有待办派给我、实例完成、实例失败、写入结果未知）改成和界面
同一句，界面上看到的字不变。

验证：新增 test_notify_events（登记表、前后端逐字对照、接口拒收、只走登记了的路），去掉 _channels 的按路过滤或「只核对新勾
的」回跑各有一项失败；check-capabilities 加一段「可订阅的事件照服务端登记列」，把列表改回按叫法表的键列，四项失败。
 2026-10-16 12:12:14 +08:00
ThearchyHelios 53d510357a ENUM / SET 只认 MySQL 带括号的写法；PostgreSQL 的域记底下的类型 
复核发现（C-enum-prefix-match）：类型写法改成按方言编译以后，PostgreSQL 的枚举、域编译出来就是类型名本身，
而 _type_family、is_date_column、_is_enum 和码值检查里的 is_set 都按前缀 startswith(("ENUM", "SET")) 认：
- 叫 setup_status 的 PG 枚举被当成 MySQL 的 SET，列定义里这次没出现的取值不写进码值；
- 叫 settlement_amount 的数值域被认成文字，又被当成码值候选。

改法：
- catalog._MYSQL_ENUM 只认 ENUM( / SET(（_mysql_enum_kind），四处都改用它；PG 的枚举一律靠探查记下的
  enum_values 认（column_family、_is_enum 本来就看它）。
- is_date_column 加 enum_values 参数：有取值列表的不算日期列。PG 枚举的类型名里碰巧带 DATE（update_reason）
  以前会被认成日期列；剖析这边（catalog_profile._is_date_column）已经传上。sqlcheck 里那一处归 W1-a，没动，
  不传时行为和原来一样。
- 探查（introspect.type_text、_enum_values）遇到 PG 的域（DOMAIN）记它底下的类型（域套域一路往下找）：域名
  看不出存的是数字还是文字，名字里的词还会让类型大类、日期列、码值候选认错，模型照着写 SQL 也要知道底下是
  NUMERIC(12, 2) 还是 DATE。套在域里的枚举照样记下取值列表。升级前存的是 str(类型) 即「DOMAIN」，同样认不出。

测试：test_profile_dialect_units 加以 set、enum 开头的 PG 类型名、带取值列表的 PG 枚举码值、DOMAIN 编译成底下
类型的单测；改动前 8 条失败。
 2026-10-16 12:06:24 +08:00
ThearchyHelios ad1092900c 剖析的关系覆盖率把对不上类型的键算作没对上；升级前旧说法的剖析备注不再让目录升版本 
复核发现两处（C-relation-coverage-inflated、C-profile-note-rewording-bumps-catalog）：

一、覆盖率虚高。key_literals 把父列是数字、子列取到的不是整数写法的文字（'WALKIN'、'GUEST0'）从覆盖率的
分母里拿掉了：散客代号占九成的一列只剩 1 个整数写法的键对上，就测成覆盖率 100%、升为「已核实」，模型的
db_schema、自查、冻结快照都会照这条错的关系写 join。基线上同一份数据是 proposed、覆盖率 3.1%。
- 整数主键里永远没有这些文字，它们照样是子表的键值，算作没对上、留在分母里：
  覆盖率 = 对上的 / (拼进 IN 的 + 按类型就对不上的)。全都不是整数写法时不发父表的核对查询，覆盖率 0%、
  「可能不是这条关系」，不再整条判「无法核对」。
- key_literals 改回 KeyLiterals(literals, unmatchable, unsafe)：不能安全拼进 SQL 的值单独计数，不再用
  「取到的 − 拼进的 − 不同类型的」倒推（'0012' 和 '12' 写成同一个字面量时会被错说成「类型不支持核对」）。
- 被指向列是日期时间的关系整条跳过，并且在发子表取值查询之前就跳过、不占这张表的查询预算；说明改成
  「各库的时间写法和精度不同，不核对这种关系的覆盖率」——子表一侧也是时间时，以前写的「两端类型不同」不照实。
- 备注里「另有 N 个键值和被指向列的类型不同，未计入」改成「其中 N 个不是整数写法，被指向列是数字，算作没对上」。
- 报告里覆盖率不足的那句「抽样覆盖率 N，保持推断」也改成「覆盖率 N」，和备注一种说法。

二、升级后第一次重新剖析，数据没变也给每张有剖析结论的表升一个版本。剖析备注改了四处说法（抽样覆盖率→
覆盖率、子表抽样→子表取了、（只看前→（按存储顺序只看前、按前 N 行统计→按存储顺序取前 N 行统计），
catalog.same_profile_note 没认成同一句，已发布工作流记下的目录版本对不上，之后每次正式运行都报
catalog.drift。
- same_profile_note 比较前先把这四处固定句式的旧写法换成现在的写法（_LEGACY_PROFILE_WORDING，句式带着前后文
  匹配，不会误换人写的原话）；算相同时保留目录里的旧备注，旧说法等结论真变了、重写备注时才换掉。
- 起草时核对有效行过滤写在模型依据后面的那句「剖析核对：按前 N 行统计」同样只认那一句的旧写法。
- MySQL / MariaDB 上新加的排序规则说明、ENUM 列定义里没出现的取值、无效日期个数是新信息，这些备注照常
  升一次版本，要写进发版说明。

测试：test_catalog_profile 加文字键指向整数主键的端到端用例（去掉修复回跑：测成 verified、覆盖率 100%）；
test_profile_dialect_units 加覆盖率分母、时间键不发查询、unsafe 计数的单测；test_catalog_semantics 加跨版本
用例（把剖析备注改回旧说法写进目录、同样的数据重新剖析，版本号和目录都不变；去掉规整回跑两条失败）。
 2026-10-16 12:02:41 +08:00
ThearchyHelios 881c8ef65b 列表中间像小计的行：照常导入、要人确认，带「改作小计核对」的修复按钮 
为什么：配方没配小计的列表（期 4 起草的、或者某一期才开始出现小计的文件），首列写着「小计」、其余文字列空着的行
以前静默当数据导入，对金额列求和就把小计重复算了进去，核对也看不出来（H2）。细案 E 的复用里列了「recipe_fixes
加一个小计修复按钮」，这里补上它的触发。

- 执行器：没配 subtotals 时，首列以合计字样开头、其余文字和日期列为空、至少一格有数的行，照常按数据导入，收尾时
  合成一条 subtotal_suspect（需确认类，不拒收：确实是数据的，勾确认项照常导入）；首列以「累计」开头、别的文字列有字
  的商品名这类数据行不算。
- 修复按钮 declare_subtotals（FIX_KINDS 末尾新增）：给这个列表加 rows.subtotals（标签列、开头词取自文件里的合计
  字样），可选只核对或另存成「{表}_小计」；块已配小计、开头词含数字时不提议。
- 确认项 subtotal_suspect:<块>；前端修复按钮文字「改作小计核对」。
 2026-10-16 11:16:33 +08:00
ThearchyHelios a137182145 Excel 期 5：列表按期累积、穿插的小计、表格对象起草、CSV 走配方（E） 
为什么：每月一份的明细导出是最常见的场景，期 4 之前列表只能每期替换；夹在中间的小计会让规则起草失败；
表格对象这个现成的边界信号没用上；CSV 不能走配方。四项都复用现有的执行器、核对、累积、溯源，不另起一套。

- 列表按期累积：ListBlock.period 二选一——{column, check: within_context} 按日期列分期，试运行多一条结构类核对
  D（每行的日期都在本期统计期内，空着也不行）；{synthesize: 统计期} 每行加「统计期起」「统计期止」两列，列表在
  统计期定下来之前就抽完了，这两格先放占位、写库时换成真值。accumulate_blockers 放行绑定了统计期的列表；合计行、
  小计行另存的表各期主键分不开，照旧不能累积；同一订单两期都出现由并集的主键核对拒收。U3 按列表的分期方式核对。
  说明里「按哪一列筛选」用分期列，加的两列有列说明；空行之后文字行的说法补了并集版本（列表能累积以后要用到）。
- 穿插的小计：ListRows.subtotals {label_column, pick, scope: since_previous | group_column, group_column, keep_as}。
  小计行不进数据，每个数字格一条合计格（分段键是块 id + ·小计），核对模块按它所管那组明细的 rowid 区间用 SQL
  求和比对（新 T 编号，标题「小计行按各组明细求和」），整行记进排除的行（reason=subtotal），可以另存成
  reported_total 表（小计项、分组取值、各数字列）；数字格全空报 subtotal_blank（结构类）；合计行的公式引用了小计格
  时按它管的明细换算。静态校验：标签列、分组列要在列里，按组小计要给分组列，小计和合计的开头词不能互为前缀。
  规则起草把第一列同一个合计字样、下面还有明细的行提议成小计（以前记 stray_totals 失败），框选同一条规则。
- 表格对象起草：工作表有表格对象时按它出列表块：表头行、列范围、数据行、汇总行（映射成 total_row，标签取汇总行
  第一列的文字）都由表格对象给，锚点仍按表头文字、不记坐标；表名优先用表格对象的名字（含数字的不用）。不调用 AI。
- CSV 走配方：新增 csv_grid，按内容认出 CSV（不是 zip、不是 OLE、开头没有 NUL），编码和分隔符复用 tabular 读 CSV
  的那一段，适配成一张名为「CSV」的工作表（SheetScan.path=csv:，WorkbookScan.format=csv）；只有写法毫无歧义的
  整数、小数转成数，千分位、前导零、日期写法一律留作文字交给配方的规则。坐标沿用「工作表!A1」（偏离细案的
  R{行}C{列}，理由见 csv_grid 的模块说明）。CSV 不做稀疏判定。导入向导和简单上传的结构提示都放行 CSV。
- 每个列表一道题「每期怎么更新」（q_list_period）：每期替换 / 按期累积并按某个日期列核对 / 按期累积并加统计期
  起止两列，后两种同时把导入模式改成按期累积、缺统计期的工作表一并配上（问题集合按草稿生成、回答时不变，草稿里
  的列表还不符合累积资格，q_mode 不会出现，所以并成一道题）。确认项新增 subtotals:<块>、list_period:<块>。
- 前端配方面板：列表块多「小计行」（标签列、开头词、管哪些明细、分组列、另存）和「按期累积时每一行属于哪一期」；
  回执「排除的行」认 subtotal。

验证：新增 tests/test_csv_grid.py、test_recipe_p5.py（执行器、核对、校验、资格、并集物化、起草）、
test_recipe_p5_e2e.py（经接口：三份月度 CSV 累积、部分重叠拒收、同一期替换要确认；带穿插小计的 Excel 起草、
核对、提交）。去掉小计识别、统计期回填、D 核对分别回跑，新测试 10 条失败。旧测试里「夹在中间的小计一律失败」
「列表只能每期替换」的断言按新行为改写。
 2026-10-16 11:09:39 +08:00
ThearchyHelios 74909191f7 judge.py：每日计数一节的函数前补一个空行 2026-10-16 11:08:25 +08:00
ThearchyHelios a56c405c9a check-ui-kit：存量驳回的另三种原话都归成「人工审批驳回」、不给继续运行 
为什么：lib/explain 的正则只留给存量 failed+驳回（新的驳回结束在 cancelled，界面按 end_reason 说），以前只认「人工驳回」一种，
动作确认、工具调用审批、代码执行审批的驳回原话落到兜底、给出注定再失败的「继续运行」（05-已知遗留 (a)）。这三种要有检查守着。

做了什么：失败归类的样本加三对（「「付款」未确认（被驳回），没有发送：…」「工具 x 的调用已被驳回：…」「代码执行已被驳回：…」），
期望标题「人工审批驳回，运行终止」、continuable=false；「片段还在后端源码里」那一项加上 tools.py 里这三处原话。
验证：check-all --stacks 1 ui-kit 497 项通过。
 2026-10-16 11:07:17 +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 335dc99c3e 检查脚本跟上：驳回、使用者选人、自由形「谁来做」 
为什么：前几个提交改了驳回的终态、选人控件的候选、自由形蓝图的「谁来做」，浏览器检查里的伪造数据和断言要守住新说法
（05-已知遗留 (a)(b)(d)）。check-decode 的一节已在驳回前端那个提交里。

做了什么：
- check-apps：伪造接口加 /api/directory/candidates（按段里给的池答）和 /api/directory（使用者 403）；新段「入口：使用者选人」
  ——边输入边按入口和字段取候选、列表里是池里的人、不去取整份名录、不在池里当场说清、选中的写显示名悬停给用户名；新段「实例页：
  被驳回」——状态照服务端写「「付款」未确认（被驳回）」、不写失败、那一步写未确认（被驳回）。
- check-inbox：新待办「指定复核人」（补充输入里有选人控件）；按 task_id 和字段问候选、不取整份名录；服务端 422 code=principal
  挂回选人字段。
- check-personal：提交审核选人按 purpose=review 取候选，不是搭建者的名字当场说清。
- check-blueprint：自由形模板的 cards 加 people；新段「自由形：谁来做」——按 derived_people 摆三行（岗位、核实人、只读的发起人）、
  没绑的标缺、问题归在这张卡片上、只读行没有修改、不能加减步骤、选人发 bp_set 到那一行的 path。

验证：check-all --stacks 1 跑 decode、apps、inbox、personal、blueprint（1030 项）和 ui-kit、chat、runs、stream（1982 项），全部通过。
 2026-10-16 11:04:28 +08:00
ThearchyHelios ee6e07959b 问数据一轮的「决定」下沉到后端 chat/turn.py，问数据页照后端给的走（细案 01 做法 1，总方案 2.1）；这一轮的花费 = 助手 + 运行 + 复核 
- chat/turn.py：next_step（有 error 级问题时自查过就判失败、没自查过的老服务端才重来一次；autorun=false 只建不跑；reply、只有反问直接收尾；其余运行）、fill_input（规则同 chat.ts 的 fillInput）、retry_after_review（retry、broken、这一轮还没试满）、retry_instruction（两种措辞原样搬过来）
- answer_ops 的 final（含只问不改那条）带 next（run | ready | fail）；/copilot/review 的结果带 retry_instruction（ReviewIn.attempt 按这一轮试过几次判，要重来是那句话，不重来是 null）
- 前端 store/chat.ts：final 照 next 走，复核照 retry_instruction 走（原样交回给助手），launch / watch / settle 把 attempt 带到复核；老后端没有这两个字段时退回原来的规则（常量和措辞留在 retryInstruction 里，和后端逐字对照）
- 这一轮的用量：usage 操作累加进 copilot，复核结果的 usage 累加进 review，自动重来和用户点重试换下来的运行并进 earlier，当前运行的抄进 run，一起随 meta.usage 落库；问数据页轮次头部写这一轮的花费（runCostText：估不出的写「≥」或「金额无法估算」），悬停分得清助手建图、运行、复核，文案在 lib/terms.ts 的 TURN_COST_TEXT；ReviewResult 类型补 retry_instruction、usage
- 新增 tests/test_chat_turn_policy.py（各条决定的分支；前后端对照 MAX_ATTEMPTS、认问题字段的正则、两种重来措辞——改一个字回跑会失败；复核按 attempt 给不给 retry_instruction）；test_copilot_answer_ops 的基线比对改成「final 只多一个 next」
- check-chat 补一段「新服务端」：照 next=ready 不发起、照 retry_instruction 原样重来、第二次复核带 attempt=1、meta.usage 四份都记下、头部写 $0.067 且悬停分得清三部分
 2026-10-16 10:59:15 +08:00
ThearchyHelios 7e4c3c58a0 自由形蓝图（前端）：「谁来做」卡片按服务端的 derived_people 摆，只定每一步由谁做 
为什么：服务端已按导入的图列出「谁来做」（自由形蓝图后端那个提交），卡片要照那一份摆出来，发布摘要里「你来定」才指得到一张
真实存在的卡片（05-已知遗留 (d)）。

做了什么：Blueprint 带 derived_people（typesBlueprint.DerivedPerson）。BlueprintCards 的 people 卡片对自由形按它一行一行画：
行名、每处用途只读；岗位行和「写入结果不明时谁去核实」一行复用 ItemRow 的人或组编辑（改了发 bp_set 到那一行的 path）；发起人、
表达式、外部系统回调的步骤只读；不能加减步骤、不改会签和时限（卡片上写明在画布上改）。卡片上的问题按那几行的 path 归进来。
termsBlueprint 加四句。服务端 blueprint_out 对没有 graph 属性的对象（契约测试里的替身）按没有图算。
 2026-10-16 10:54:30 +08:00
ThearchyHelios b334f58009 导入清单的「是否认证」界面照记下的说：登录身份 / 未认证署名 
为什么：服务端开始如实记「是否认证」之后（导入清单那个提交），界面上的清单、导入记录、接受理由还一律写「署名（未认证）」，
开了登录、署名就是登录的人时说错了（05-已知遗留 (c)）。

做了什么：导入记录接口带上 signed_by_verified（按这一期导入清单里记下的；旧清单记的是 false，照记下的说，不改写；简单导入
没有清单按未认证）。ManifestBody 的文件署名、接受理由的署名，VersionsDialog 的导入记录、快照里各期、接受理由的署名，都按记下
的值写「登录身份：x」或「署名（未认证）：x」，和确认框里那一行（signerLine）同一套说法。接受理由由提交这一期的人写：署名和
清单（导入记录）的一样时才算认证。统计期、修改记录的署名是暂存时记的，没有记是否认证，照旧写「署名（未认证）」。

测试：test_signer_verified 加一句：开登录导入后导入记录的 signed_by_verified 为真。
 2026-10-16 10:54:30 +08:00
ThearchyHelios fbb671a96b 使用者选人（前端）：选人控件按池边输入边取候选；个人渠道的实例事件改叫「我发起的实例完成 / 失败」 
为什么：使用者读不到名录，选人控件只能凭记忆手填用户名，填错了服务端以前也照收（05-已知遗留 (b)）。服务端已按用途给候选池、
开登录时按同一个池核对（上上个提交），前端要把候选给到人手上。另外个人渠道勾「实例完成 / 失败」以前永远收不到，服务端修好之后
（驳回那个提交里的 notify_run），名字要照实写成只推自己发起的实例（04-对外集成与触达 B1）。

做了什么：
- PrincipalPicker 加 source（CandidateSource：form 带 app_id+entry 或 task_id 和 field，review）。搭建者及以上照旧用整份名录；
  使用者开了登录、给了 source 时边输入边按开头取候选（250 毫秒防抖），列表里显示显示名、标签悬停给用户名；加的时候按同一个池
  问一次服务端，不在池里的当场说「「x」不在可选的人里」（问不到就先收下，提交时由服务端判）；池要先输开头才列、列不全时照实提示。
- SchemaForm 按表单用在哪（入口、待办，同上传文件的上下文）给选人控件 source；个人应用提交审核用 purpose=review。
- typesApp：CandidateSource、Candidates、FormField 的 x-principal、FormError 的 principal 码（和服务端 FORM_ERROR_CODES 同序）。
- api.identity.candidates。termsApp 的 PRINCIPAL_TEXT 加三句。
- 设置 → 通知：范围是「仅自己」的渠道，run.finished / run.failed 写「我发起的实例完成 / 失败」（termsApp.NOTIFY_PERSONAL_EVENT_LABEL）。
- 服务端 x-principal 写法不对时的说法改成不带半角冒号接中文的写法（check-copy）。
 2026-10-16 10:54:30 +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 ba28dee1f0 生成过程抽成 answer_ops、复核抽成 review_of_run，助手建图和复核的用量也记下（细案 01 做法 2、3）：评测和问数据页走同一条生成路径，这一轮的花费不再低报 
- api/copilot.py：event_stream 原样搬成 async generator answer_ops(payload, *, catalog_view=None)，交出的 op dict 不变；开流前的准备（数据源、目录检查器、助手模型、历史、查看服务）用自己的短会话，在第一条操作之前做完。SSE 路由只包一层：先取第一条，开流前的拒绝（模型没配好、限定的数据源都不在）照旧是 HTTP 错误
- catalog_view 一路传给查看服务和自查的 SQL 检查器（目录视图接缝的「生成过程从参数读」）
- providers/usage.py：Meter 是一个 LangChain 回调，和 get_usage_metadata_callback 同一个机制（登记过的上下文变量），按模型累计 tokens、次数，金额按价格目录；估不出的记 unpriced_calls。没直接用 get_usage_metadata_callback：with 块跨 yield 会把变量留在调用方上下文里，调用方随后发起的运行会继承它、被重复计一遍；metered 只在每一步 __anext__ 期间挂上，嵌套时并进外层
- 生成过程读到 done / look / ask 就关模型的流（后面的闲话不要），流末尾才报的用量拿不到：这一次照样计次数和已报的 token，记成估不出，不悄悄少算（遗留：真实接入上建图那几次多半是下限）
- providers/budget.py：BudgetFallback.astream 用 aclosing 包住里面那条流——以前调用方关流时里面那条要等垃圾回收才关，模型那次调用的收尾（用量回调）落在算完账之后；测试去掉它回跑会少计一次
- answer_ops 末尾多一条 {op: usage, by_model, input_tokens, output_tokens, calls, cost_usd, unpriced_calls}；/copilot/review 拆出 review_of_run（问数据页、评测共用），结果带 usage（没调模型时全 0）和 retry_instruction（要不要带着原图重来、说什么，按 chat/turn.py 的决定算；ReviewIn 多一个 attempt）
- 新增 app/chat/turn.py（问数据一轮的决定，复核这边先用上；final.next、对照测试、前端照做在下一个提交）；新增 tests/test_copilot_answer_ops.py（八种结局的 SSE 输出和抽出来之前录下的 fixtures/copilot_answer_ops_baseline.json 逐条相同，末尾多一条 usage；直接迭代和 SSE 同一串；开流前的拒绝仍是 HTTP 错误）、tests/test_usage_meter.py；读 SSE 的十一个测试文件的收流帮手跳过末尾那条 usage
 2026-10-16 10:45:45 +08:00
ThearchyHelios 3293ac0b58 自由形蓝图（后端）：按导入的图列出「谁来做」，只定由谁做；没绑时 bp.people_unbound 指向那张卡片 
为什么：自由形的骨架就是导入的图，图里派给岗位的人工节点、没登记查询的写入在应用里都要绑人，可蓝图上没有「谁来做」卡片。
第一次发布挡在 app.slot_unbound / app.reconciler_unbound 上，白话叫人「在「谁来做」里给这一步选人」，卡片却不存在；这时
应用还没建，也没法去应用编辑器绑，只能绕开蓝图（05-已知遗留 (d)）。

做了什么：
- freeform 的 cards 加 people（「可选：只定每一步由谁做；会签、时限、超时在画布上改」）。freeform.people_rows 按 tree.slot_refs
  列岗位行（同一个岗位用在几处合成一行，label 用节点标题拼、detail 写全每一处用途，path 是 /people/<i>/who）；写入能力没登记
  查询时加一行「写入结果不明时谁去核实」（path /writeback/reconciler）；发起人、表达式、外部系统回调的步骤列成只读行。
  blueprint_out 给出 derived_people，界面照这一份画。
- 存储复用现有路径：岗位绑定存在 spec.people[]（id 就是岗位名、只写 who），_common.slot_of / bindings_of 原样生效；核实人存在
  /writeback/reconciler。needs_reconciler 对自由形按图里的写入算（with_graph 把蓝图存的图带给模板函数）。
- bp_set 对自由形的 people 只收 who（只收人和组，只由用户定），改会签、时限、超时、加减步骤报 bp.template_mismatch「在画布上
  改」。apply_bp_op / blueprint_issues 新增 graph 参数，卡片接口、蓝图检查、试运行、实例化、蓝图助手都把蓝图存的图传下去。
- 检查：派生岗位、核实人没绑报 bp.people_unbound（试运行 warning、发布 error），路径就是那一行，带 slot；图里已经没有的岗位、
  卡片上还留着的绑定报 warning，不静默删除。发布单照核实人的办法，去掉同一件事的 app.slot_unbound（slots.<slot>）和
  app.reconciler_unbound。

偏离：岗位行不让助手代填（同「结果不明时谁去核实」，派活给谁是人的决定）。

测试：test_publish_plan 新增「财务审批（岗位）+ 写回（没登记查询）」建自由形蓝图一条（两行、不选人时只有 bp.people_unbound、
改会签被拒、选好人后绑到 finance 和核实岗位、发布单不再挡）；老的两条按新说法改；test_blueprint_templates 新增 people_rows
的合并、升级岗位、只读行、残留绑定提醒。
 2026-10-16 10:34:18 +08:00
ThearchyHelios d14fc97da7 应用入口、按需视图的表单没通过校验也带 code（form_invalid），和待办回复、入站钩子同一个码 
api/apps.py 里这两处直接回 JSONResponse（detail + errors），上一次补错误码时只查了 HTTPException，漏了它们：外部系统发起
实例时表单不对，仍然只能按中文句子认。detail 和 errors 不变。

tests/test_integration_errors.py 的静态检查跟着扩：这几个模块里直接回的 JSONResponse 错误，内容里也要有 code（改之前
这条检查报出了这两处）。
 2026-10-16 10:33:41 +08:00
ThearchyHelios 2fb16c2719 设置页加「通用」标签放对外访问地址；环境变量指定时显示「由环境变量指定」不可改，定时任务里的入口跟着认 
服务端已经只认一个对外访问地址（core/public_url.py），界面上这一项以前只在定时任务的 Webhook 一节里改得到，叫「服务
访问地址」，和设置接口、通知里的「对外访问地址」两种说法；环境变量设了时那里照样能改，改了也不生效。

- 新增「设置 → 通用」（pages/settings/GeneralTab.tsx）：写明它管哪几件事（通知和 Webhook 的链接、单点登录的回调、来源
  核对）；管理员能改，保存前先重读 notify 一组、只换这一项，末尾的 / 去掉，带 ? 或 # 的当场标错；改了没保存离开先问；
  环境变量指定了的只显示它、写明「由环境变量 AGENTLAB_PUBLIC_URL 指定」，不给输入框；搭建者只看。使用者看不到这一页
- 定时任务 Webhook 一节的快捷入口改叫「对外访问地址」，按 GET /api/settings 的 public_url 一组认：环境变量指定的只显示、
  不给修改按钮，设置里存着的旧值不再冒充生效的那个；地址校验和「通用」同一个（lib/publicUrl.ts）
- 文案进 lib/terms.ts（GENERAL_SETTING_TEXT，SCHEDULE_TEXT 的 linkBase 一组改说法）

检查：check-manage 加「设置 · 通用：对外访问地址」一节（标签、说明、校验、离开先问、只写 notify 一组、环境变量只读、
搭建者只读）；check-schedules 加「对外访问地址由环境变量指定」一节。check-manage、check-schedules 在隔离的一套后端 +
vite 上全部通过，tsc、check-copy 通过。
 2026-10-16 10:31:26 +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 ee7b8b2f97 剖析与探查的方言修正（C1）和没有真库时的方言验证（C2） 
为什么：剖析是全站唯一主动查业务库的地方，以前只在守卫放行和字符串片段两层上测过，从没在真库上跑过。
本机四个容器（PG 16、MySQL 8.4、MariaDB 11、Oracle Free 23）实测，旧的 IN 列表写法在 PostgreSQL 上整数子列
对文字主键直接报 operator does not exist: character varying = integer，关系一条都核对不了。

C1 方言修正：
- IN 列表的字面量按被指向列的类型族写（key_literals）：父列文字写 '12'，父列数字只收整数写法的值，父列是时间、
  对不上的不拼并在备注里写「两端类型不同」；子表是 CHAR(n) 时去掉补齐的尾随空格。
- 列类型改存按方言编译的完整写法（VARCHAR2(20 CHAR)、NUMBER(10, 0)、ENUM('a','b')、TIMESTAMP WITH TIME ZONE），
  编译不了退回 str()。SQLAlchemy 把 Oracle 的 VARCHAR2 反射成通用 VARCHAR（容器实测），照数据字典写成 VARCHAR2。
  ENUM / SET 另记 enum_values；Oracle 小写带引号的表和列记 quote_name；各索引（含主键）的首列记进
  index_first_columns（下一波取值观察判断能不能对大表发窗口查询）。新探查的快照哈希会变，旧运行封存的不受影响。
- catalog._type_family 认 ENUM / SET 是文字、INTERVAL 不是数字，去掉引号里的取值再认；新增 column_family
  （有 enum_values 的是文字，PostgreSQL 枚举编译出来只有类型名）；is_date_column 不再把 ENUM('date') 认成日期列。
- 码值候选：ENUM / SET 不看列名直接算候选，ENUM 列定义里这次没出现的取值也写进码值（含义待填）；VARCHAR2(20 CHAR)
  的长度按 20 算；CHAR 码值去尾随空格；MySQL 上写明按排序规则分组、比较（可能不分大小写）。
- 统计信息估出的行数不超过整表统计上限时再跑一次有上限的计数确认，统计过期的大表不再被当成小表做整表统计。
- 日期列的最小值、最大值只看 0001-01-02 到 9999-12-31 之间的值，零日期、占位日期、PG 的 ±infinity 不计入，
  照实写「另有 N 个无效日期未计入」，日期范围里带 invalid 个数（界面显示）。
- 新增取值观察用的方言方法 date_literal / day_trunc / sample_from，以及按日行数、时间窗口里的取值分布、块采样三类
  查询的拼法（窗口上端截在 9999-12-31 之前，不让 infinity 多出一天）。
- 说明文字不再说「抽样」：大表看的是「按存储顺序取前 N 行」；设置项「抽样键值数」改叫「核对键值数」。

C2 验证：
- tests/test_profile_dialect_golden.py：五种方言 × 全部剖析和观察查询的完整 SQL 钉在 tests/fixtures/dialect/，
  sqlglot 逐条解析、过只读守卫，再用 qualify + annotate_types 核对 IN 两边类型族一致（附旧写法的对照）。
- scripts/dialect-it.sh（不进 CI）：本机起四个容器，建虚构夹具（保留字列、Oracle 小写带引号的表、CHAR 码值、
  MySQL ENUM、零日期 / infinity / 占位日期、做旧的统计信息、超上限的大表、带索引的日期列），用 AgentLab 自己的
  探查和剖析代码跑全部查询，断言零报错、结论和手算一致。四种库都通过；MariaDB 插入时自己更新行数估算，统计信息
  做不旧，照实打印。把 IN 列表改回旧写法回跑，PG 上照样报出上面那条错误。跑完删容器、留镜像。
 2026-10-16 10:25:28 +08:00
ThearchyHelios a59409cc85 使用者选人（后端）：按用途给候选池，开登录时入口表单、待办表单的选人控件按同一个池核对 
为什么：使用者在选人控件里没有候选（名录只给搭建者），服务端也不核对。填错的名字原样派下去，待办给了一个不存在的人，
没人能处理、也不报错（05-已知遗留 (b)）。名录又不能整份放开给使用者（只读与最小可见）。

做了什么：
- auth/directory 新增候选池：form 用途缺省是「能用这个应用的人」——使用及以上的授权（人；组列出组本身并展开成员），
  加上管理它的人（管理员、建应用的人）；应用授权给了所有人时池是全部启用的人（open），不带前缀 q 不列（needs_query）。
  字段可以声明 x-principal: {pool: app | group:<组> | slot:<岗位>}（slot 按这次用到的应用版本的 bindings 展开）。
  review 用途是启用的搭建者和管理员（同 personal._review_targets）。停用的人一律不列。
- GET /api/directory/candidates（任何登录的人；main.py 路由清单只加一行）：purpose=form 带 app_id+entry 或 task_id、field，
  调用的人不能用这个应用 403；只回 {users:[{username, display_name}], groups, truncated, needs_query?}，不给停用、角色、
  邮箱、组成员；q 按用户名或显示名开头筛，limit 最多 50。/api/directory 仍只给搭建者。
- 开了登录时 start_entry 和待办表单提交按同一个池核对，不在池里 422，errors 的 code=principal（FORM_ERROR_CODES 加一项），
  话写成「「x」不在可选的人里，请从候选中选择」（单点登录另说要先登录一次才进名录）。直接生效（遗留-Q4 按推荐）。
  关登录照旧手填、不核对；不属于应用的待办（试运行、画布）没有池，不核对。
- apps/forms：x-principal 进 _FIELD_KEYS，validate_form_schema 查写法（只能写在选人控件上、只能是三种池）。

搭建者没有授权时按 apps/access 只能「查看全部实例」，不算池里的人——池按「能用」算，这一点写进了 app_pool 的说明。

测试：test_directory_candidates（只给名字、停用的不列、前缀筛、没使用权 403、名录仍 403；授权给所有人要前缀、截断；review
只出搭建者和管理员；入口表单不在池 422、停用的 422、组名和池里的人放行；待办表单同一个池；声明 group:<组> 收窄；关登录
任何名字照收；x-principal 写法校验）。
 2026-10-16 10:24:22 +08:00
ThearchyHelios e82d7fa55d 集成接口补齐错误码，开登录时收起 /docs、/redoc、/openapi.json（要搭建者登录） 
外部系统只能按中文句子认是哪种错，文案一改就悄悄失灵；开了登录，接口说明仍然不用登录就能读，全部接口的结构对匿名的人
敞开（中间件只拦 /api/ 开头的路径）。

错误码（detail 文字一字不改，老前端照常显示；码都登记在 api/coded.py）：
- api/apps.py 13 处：应用不存在（app_not_found，同入口发起时的码；没有授权的人也回它）、版本、实例不存在，钩子没声明、
  没生成密钥，岗位绑定、个人应用草稿、授权、页面参数不合规；派生时工作流、版本不存在（apps/derive.py 的
  DeriveRefused 带上码）；视图、入口、补算的拒绝原样带码，只有引擎不发起运行（LaunchRefused）没带码的几种补上
  run_launch_refused
- api/tasks.py 3 处：待办不存在、查看全部要搭建者（role_required）；服务层没带码的拒绝按状态补上同一类的码
  （404 task_not_found、403 task_forbidden、409 task_closed、422 task_invalid），没改 process/tasks.py
- api/artifacts.py 5 处：没有权限、这类原文只给搭建者、不存在、内容和哈希对不上
- api/deps.py 的 _forbidden（run_forbidden）、运行和证据接口的角色拒绝（role_required）、个人运行只给拥有者
  （run_private）、问数据（chat_forbidden）；ensure_role / 路由级依赖走 auth.require，抽出 auth.refusal 一处判断，
  没登录 401 auth_required、角色不够 403 role_required

/docs：开登录时中间件把 /docs（含子路径）、/redoc、/openapi.json 当成 /api 一样拦，和路由级依赖用同一个 auth.refusal：
匿名 401，不到搭建者 403。关登录照旧（test_provenance_contract.py 的断言不受影响）。

测试 tests/test_integration_errors.py：这五个模块里不许再直接抛 HTTPException（静态检查）；应用、待办、工件、角色、运行
拒绝逐类核对 code 和原 detail；/docs 关登录照旧 200，开登录匿名 401、使用者 403、搭建者 200。去掉中间件的改动回跑，
开登录时匿名打开 /docs 是 200，测试失败。
 2026-10-16 10:19:50 +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 d8034ca71a 对外访问地址只留一个：core/public_url.py 的 public_base_url()，通知、Webhook 链接、OIDC 回调、来源核对都改用它 
以前有两个「对外地址」：环境变量 AGENTLAB_PUBLIC_URL 只管 OIDC 回调和 Origin 核对，设置里 notify.public_base_url 只管
通知里的链接。只配了环境变量的部署，通知里不带链接；只在设置里填了的，回调又按请求的 Host 拼——违背「一种说法」。

- 新增 core/public_url.py：环境变量优先，其次设置（沿用 notify.public_base_url 这个键），都没有是 None。设置的值缓存在
  进程里（中间件按请求核对来源，不能每次查库）：启动时 refresh 一次，PUT /api/settings 写完库就 remember，不用重启；
  通知、定时任务 Webhook 手里本来就有会话，用 refresh 取，顺手按库里的值对齐缓存
- 地址的形状检查和规范化只有一份（url_problem / normalize），设置接口的中文报错和环境变量的启动校验都用它；环境变量
  写错了（没有 http:// 或 https://、带 ? 或 #）启动时就报错，不再拼出坏的回调地址
- GET /api/settings 另给只读的 public_url 一组 {value, env_locked}，设置页据此显示「由环境变量指定」；环境变量设了时
  PUT 把这一项改成别的值回 409（public_url_env_locked，field 指到这一项），原样写回不算改；public_url 一组写不进库
- notify/service 取地址的那一处、scheduler/webhook 链接里的地址、api/auth 的 OIDC 回调、auth/middleware 的 Origin 核对
  都改走 public_base_url；deploy/agentlab.env 把这个变量的说法改成全站唯一的对外访问地址

测试 tests/test_public_url.py：先后顺序（环境变量 > 设置 > 无）、规范化、启动校验、PUT 刷新缓存、环境变量锁定（409、
不挡原样写回）、只配环境变量时通知带链接、OIDC 回调和 Origin 核对认设置里的地址。去掉修复回跑，只配环境变量的通知
链接、按设置核对 Origin 两条都会失败。设置页把它挪到「通用」在后面的前端提交里。
 2026-10-16 10:18:12 +08:00
ThearchyHelios a05efbf27a 安全响应头：所有 HTTP 响应补 nosniff、Referrer-Policy 和 CSP frame-ancestors，页面只上报严格的 script-src 
以前服务端一个安全头都不发，任何站点都能把 AgentLab 嵌进 iframe：同站门户（Lax 会话 cookie 会随请求带上）和关登录的部署
都有被点击劫持的可能，也没有「允许谁嵌」的白名单可配。

- 新增 app/web_security.py，纯 ASGI 中间件，main.py 里加在最外层：CORS 预检、登录检查自己回的 401 / 403 也带上；
  WebSocket 不经过它；接口自己设过的同名头（文件下载的 nosniff）不覆盖、不重复
- frame-ancestors 缺省只有 'self'，这时另加 X-Frame-Options: SAMEORIGIN；AGENTLAB_FRAME_ANCESTORS 配了同站门户的白名单时
  只发 CSP（XFO 写不了白名单，两个都发会让只认 XFO 的老浏览器把门户也拦掉）
- 分享页 /s 只认 AGENTLAB_EMBED_ORIGINS、Referrer-Policy 用 no-referrer。分享链接第 3 波才加，这一波先把配置读进来、
  头的规则写好
- 严格的 script-src 先只发 Content-Security-Policy-Report-Only：mount_web 启动时给构建产物 index.html 里的内联主题
  脚本算 sha256，只在页面响应上发；接口返回的 HTML（导出的报告自带 meta CSP）不发、不动。观察一个版本没有误报再强制执行
- HSTS 交给终结 https 的反向代理
- 两个白名单只收「协议://主机[:端口]」（可以 *. 开头），带路径、裸 *、没写协议的启动时就报错；deploy/agentlab.env 写明
  两个变量和缺省行为

测试 tests/test_web_security.py：页面、/api、中间件自己的 401、CORS 预检都带头；白名单生效时不发 XFO；/s 的规则；
上报策略只在页面上、哈希对得上；已有的头不重复；WebSocket 不受影响；白名单写错启动报错；子进程起真实的 app.main 核对
环境变量接线。
 2026-10-16 10:17:37 +08:00
ThearchyHelios ec5d9398b5 导入清单、累积快照清单、作废记录、清除原件记录如实写「是否认证」 
为什么：这四处的 signed_by.verified / signed_by_verified 写死 False。开了登录时署名就是登录的人，封存证据里却记着
「未认证」，和审计表、待办派单、run.origin 的 verified 口径对不上——留痕记错了事实（05-已知遗留 (c)）。

做了什么：api/deps 新增 signer_verified()（开了登录、这次请求的身份认证过时为真；关登录、不在请求里为假），和 signer_of
配对。表格导入提交、按期移除 / 作废接受、清除原件三个写接口在请求那一刻算好，和 signed_by 一起往下传到
recipe_imports._manifest、source_versions.manifest_doc / _revoked_record、table_versions.purge_import_raw；没有署名的
（退回暂存区上记的那个）照实记未认证。新参数都带默认值 False：运行里按配方导入一期（files/imports.py，署名取动作确认人
或发起人）没有请求身份，照旧记未认证。已封存的旧清单不改写，读取复验照旧。

测试：test_signer_verified（signer_verified 跟请求身份走；作废记录照给的写；开登录首次导入的清单 verified=True、清除原件
记录 signed_by 是登录的人且 verified=True，请求体里填的名字不看）。关登录的老断言（False）照旧通过。
 2026-10-16 10:14:43 +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 e3d0fe618c 定时目标的底座（总方案 X4，细案 01 做法 15）：定时只有一套，目标种类在 scheduler/service 里一处封装 
- service.target_of / target_columns：读写目标只经这里。workflow 目标 target_id 同 workflow_id；非工作流目标 workflow_id 存空串（老表的非空约束，只加不改的迁移放宽不了），这条规矩不散到别处
- fire_once 按目标种类分派：工作流那段原样搬进 _fire_workflow（重叠跳过、渲染输入、记触发、发起一字不变）；这一波别的种类照实记「未能发起」并写明是哪类目标，不发起运行、不把空串当工作流去跑
- 建任务、PATCH 改工作流经 target_columns 一起写两列；存量任务（target_id 为空）照旧按 workflow_id 发起
- 接口和界面这一波不暴露新种类（第 3 波开放），返回的形状不变
- 新增 tests/test_schedule_target.py
 2026-10-16 10:07:15 +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 3565227748 后台任务运行时上移到 core/job_runtime.py（总方案 X5）：评测、后台探查都要用它，从 data 包里导入一个「数据目录的」运行时说不通 
- data/catalog_job_runtime.py 只留一个老路径：sys.modules 指向 core.job_runtime，同一个模块对象、同一条队，起草、剖析和测试里的 import 一个字不用改
- 同源队里的事做成开放的：运行时不再认具体几种，各模块 register_lane_kind 登记（起草这边 draft / sync_draft / import，剖析 profile），进队只核对登记过；第 2 波的后台探查登记一行就排进同一条队，拼错的 kind 当场报错
- JobRun 多一个 lane_of 钩子（缺省 job.source_id）：以后不占源的任务（评测）返回 None 就不进队，现有起草、剖析行为不变
- 新增 tests/test_job_runtime.py
 2026-10-16 09:59:44 +08:00
ThearchyHelios 4819b21269 下一轮第 1 波的契约骨架：运行加 end_reason（人工驳回 / 手动停止），定时任务加目标种类和 id、触发记录加评测 id（定时只有一套），运行来源登记 eval、ledger_issue、reconcile、recall（都只能由服务端写）；迁移只加不改 2026-10-16 09:43:08 +08:00
ThearchyHelios d135a17f72 合入数据剖析逐表后台任务：剖析从一次同步请求改成逐表的后台任务，每张表看得到检查项进度、查询数、用时和正在核对哪一项，关掉对话框照常进行，可以停止、只重试没做完的表，服务重启标中断不续跑；预算按表算（缺省每张表 40 条查询、60 秒，用完只停这张表），整次不设上限，靠连续 3 条失败、最近 10 条 7 条超时两条止损和手动停止；同一个数据源上起草和剖析排队串行，范围在开始剖析时按当时的目录定（起草完接着剖析不再漏掉只靠关系才有检查项的表）；缺省剖析「需要剖析的表」（从没剖析过、上次没做完、之后又有待核实关系或新的码值、日期列）；发过的每条查询留痕（取值换成「?」，遮罩列不进查询）；表清单「剖析」一列、表详情「数据剖析」一节；起草和剖析共用抽出的后台任务运行时（起草行为不变）；去掉同步剖析接口，设置的两项旧预算启动时删掉、换成按表的两项；停止刚被认领的任务不再 500（起草一并修）。验收：后端全量测试、check-catalog-profile / catalog / catalog-loop、真实后端用虚构店铺库走完排队、预算、停止重试、强杀重启、设置迁移 2026-10-15 20:13:30 +08:00
ThearchyHelios 68f521c000 README：数据剖析一行按逐表后台任务重写（按表预算、止损、排队、留痕、开始时定范围），导入在剖析时也不行；check-all 改成 38 项，补上 catalog-profile 和此前没列上的 blueprint、personal、records、files 2026-10-15 19:50:14 +08:00
ThearchyHelios fa9739d0d8 行数的来源分清「逐行数出来的准数」和「数到整表统计行数上限为止」：以前没超过上限、已经数全的表也写「数到上限为止」，读着像被截断了 2026-10-15 19:48:11 +08:00