208 Commits

Author	SHA1	Message	Date
ThearchyHelios	298e52bd69	按复核意见修后台探查的三处退化（A-1、A-2、A-3） ... A-1 升级后第一次后台探查中途停下，表结构缩成已读完的那几批： schema_cache 只从对象索引物化，老缓存（升级前同步探查写的，没有 scope 摘要）里的表结构却从没进过对象索引。 于是第一次探查只要停止、连接断开、服务重启，或者排队时有人按需加入、探查失败要记一笔，物化出来的就只剩已读完的表， 老缓存里还没重读的表静默消失，skipped 里也没有。先在探查范围面板刷新过对象索引、再探查却连不上时更糟：表结构清成空的。 现在这个 schema 的对象索引第一次建起来时（refresh_index 的 legacy，source_objects.legacy_seed），把老缓存里的表结构 接进对应的行：在范围里、算规则命中，带老结构和它的指纹，结构版本记 0（第一次真读到记 1，不把反射格式的差异当成 结构变化）；老缓存里读不到结构的照样记成读不到。缓存的 schema 和配置对不上的不接，对象索引里没有的不接。第一次 任务开始时照规则重圈，没重读到的沿用老结构，和以后每次探查中途停下一样。 A-2 schema 填错、一个对象都没有时不再给候选 schema： PostgreSQL、Oracle 的 schema 写错时字典查询只回 0 行，不抛错，新路径就只物化出 tables={} 并盖上同步时间， available_schemas 没了：卡片上「该服务器上还有……」、助手摘要里「数据可能在这些 schema」都给不出。现在 prepare 拿到 0 个对象时照旧用 list_schemas 拿候选，记在任务的 scope 里，物化时由 rebuild_schema_cache 写进 available_schemas （不置 failed：这不是一次失败）；有了对象再探查就不再挂着。 A-3 排队中「加入范围」的表在任务开始时被移出： _apply 只保留建任务时圈好的表和所有 on_demand 的行，目录页显式加入（explicit）的表被当成离开范围、清掉结构。 现在保留 added_at 不早于建任务时刻的行（按需加入、显式加入都算），原因按 pinned > 显式 > 规则 > 按需取高的； 建任务之前就按需加入、又被显式移出的不再一律留着，照规则移出（以前「留着所有 on_demand」会让显式移出不生效）。 测试（tests/test_introspect_jobs.py）：60 张表的老缓存，第一批读完后停止 / 第二批连接出错 / 重启标中断 / dry_run 后探查失败，表数都不减少，再探查一次结构版本全是 1；别的 schema 的老缓存不接；空库和替身模拟的 0 对象 schema 带上 候选、DataSourceOut 和助手摘要都看得到；排队中显式加入、按需加入的表任务跑完仍在范围里。去掉三处修复各自回跑， 对应的测试都失败。	2026-10-16 15:36:21 +08:00
ThearchyHelios	f9f5338ec6	数据源不可用时的 db_schema 替身也收 keyword；重读范围内读不到结构的表不记成按需加入；起草、剖析排在探查后面的测试 ... - tools/datasource._unavailable_tool：db_schema__ 多了可选的 keyword，固定的版本不在了时的替身也要收这个参数（调用工具节点按 参数模型的全部字段传参，不收就报「不接受名为 keyword 的参数」，全量测试里 test_run_data_versions 抓到的）。 - source_objects.add_to_scope：本来就在范围里、只是上次没读到结构的表（pinned、规则命中的）这次重读一遍，不改原因、不记留痕， 不算进「每次运行最多按需加入 8 张」，也不出现在面板的「按需加入的表」里。 - tests/test_introspect_jobs.py：起草、剖析任务排在同源的探查任务后面时 waiting_for 是 introspect。	2026-10-16 14:53:41 +08:00
ThearchyHelios	f4755056e6	前端跟上后台探查：数据源卡片上的进度、停止、结果，探查范围面板；目录清单的几种「不在」、分批显示、搜索范围外的表并加入范围 ... 为什么：探查改成了后台任务（POST /introspect 回 202 和任务），界面不能再等同步结果；几千张表的库要能设范围、看命中数， 目录清单要说清表为什么不在，范围外的表要找得到、加得进来。这一波直接进 main，不能有半截的功能。 - 数据源卡片：「探查结构」开始后台任务，进行中每秒取一次进度（进度条、正在读哪张、排在谁后面），「停止」停在当前一批之后； 结束时换上任务带回的数据源、说一句结果；最近一次没做完（部分读不到、停止、中断、失败）常驻一行，读不到的表可展开。 规则命中超过上限时照实说命中数并给「调整探查范围」；已有任务时跟上那一个；对象清单拿不到时重取卡片显示原因。 有范围外的表时写「探查范围 400 / 3,000」。换 schema 后的重新探查、按配置重新探查、新建后的探查都走任务。 - 探查范围面板（IntrospectScopeDialog）：全部对象 / 按规则，包含、排除（排除优先）、显式列出、显式移出、包含视图、上限； 边改边数命中（停手 400 毫秒问服务端，不连库），超上限写明会被拒绝、「保存并探查」点不了；一律在范围内的表说明和举例； 按需加入的留痕；没有对象索引时「刷新对象索引」（dry_run）。界面不算命中，规则只在服务端一处。 - 数据目录：表清单一次画 200 行、「显示更多」；表结构里没有的按 absent_reason 分开说（只有真删除说「表已不在」），老服务端 不给原因时照旧；有范围外的表时搜索词同时在对象索引里找，命中列在清单下面、「加入范围」后清单重取；顶部说明按探查范围写 （老缓存照旧说只探查了前 N 张、请重新探查）；表详情按原因说；起草、剖析排在探查后面时写明。 - 运行面板的查看记录读 added_to_scope，展开区写「按需加入探查范围」。 - 类型、接口、文案各写各的块（types.ts / typesApp.ts 末尾、client.ts 的 datasources 和 dataCatalog、terms.ts 的 INTROSPECT_TEXT / INTROSPECT_SCOPE_TEXT / CATALOG_ABSENT_TEXT / CATALOG_SCOPE_TEXT），SCHEMA_PARTIAL_TEXT 改成按探查范围说。 - 检查：check-manage 的假探查改回 202 和任务、加「数据 · 后台探查与探查范围」一节（超上限、刷新对象索引、边改边数、 保存并探查、进度、停止、结果）；check-catalog 的「只探查了一部分表」改成老缓存的说法，加「探查范围：三种不在、分批显示、 加入范围」一节。两项检查 1,135 项全过。 - introspect_jobs 的一句报错不用「连不上」（check-copy）。	2026-10-16 14:46:58 +08:00
ThearchyHelios	4ba4a21b2c	大库的 look 预筛与按需加入、剖析事实四处一致、有效记录条件按 quote_name 加引号的测试；对象索引批量更新改走按表的 executemany ... 为什么：A2 和遗留 e 的行为要有脚本化的验收，且能证明测试抓得住回归（去掉遮罩重滤、去掉 quote_name 强制引号后对应用例都失败， 已回跑确认）。 - tests/test_look_large.py：3,000 张表的合成库，探查范围 300 张 + 5 张有目录的表，其余只在对象索引里（注释写进索引，模拟 MySQL / PG 的表注释）。10 条脚本化需求挑中 ≥ 9 条、挑选提示词 < 20,000 字（挑选用按字面重合打分的假模型，只看得到交给它的 那份目录）；挑中范围外的表按需加入、记 added_to_scope 和留痕；点名的每次查看最多 4 张、超了照实说；db_schema__ 的 keyword、 只列前 50 张、每次运行最多 8 张；查询照实列「未按目录检查的表」；目录搜索和「加入范围」；剖析的关系指向范围外时不说 「表结构里没有」。 - tests/test_profile_facts.py：look、运行时 db_schema、/schema、表助手四处同一段剖析事实和固定提示；剖析之后加遮罩，那一列 的范围不出现；没有剖析结果时表详情一字不差；上传表格快照不一致（含没记快照的）不给；剖析任务开始一张表时记下快照； 「上次剖析」取真正开始过的那一次。 - tests/test_valid_filter_quote.py：存进目录的写法和剖析核对查询都按 quote_name 给 Oracle 小写列加引号。 - source_objects.refresh_index：注释、类型、行数估算有变的行改用按表的 executemany（ORM 的按主键批量更新要求参数里写主键 列名，3,000 张表的库第二次刷新索引时报错）。 - db_schema__ 不传 table 时说清没列出的里有几张在探查范围外。	2026-10-16 14:26:04 +08:00
ThearchyHelios	1a6082f033	大库的对象索引、探查范围和后台探查（next-round 03 A1），schema_view 预筛与按需加入、剖析事实的后端（A2、遗留 e 的底座） ... 为什么：几千张表的库以前用不了——探查每个源最多取 200 个对象、按数据库列出的顺序截断，同步请求、整份替换、不排队； 落在窗口外的表在目录、look、剖析里被说成「表已不在」。 做了什么： - db/models_sources.py：source_objects（对象索引一行一个对象：范围、原因、结构指纹与 struct_version、first_seen / last_seen / removed_at、reflected_at、按需加入的留痕）、introspect_jobs / introspect_tasks（后台探查任务与逐表状态）。 - data/source_objects.py：每种方言一条字典查询建对象索引（失败退回 Inspector，上限 5 万，截断时不判删除）；探查范围规则 （options.introspect_scope：通配、按 name_key、排除优先、显式列出 / 移出；有目录的表、已发布模板写死 SQL 用到的表 pinned； 命中超上限拒绝并说出命中数）；唯一的 rebuild_schema_cache 从范围内已反射的行物化 schema_cache（形状不变，另加 scope 摘要）； 三种「不在」分开说（removed / missing / out_of_scope / reflect_failed）；按需加入（当场只读反射、落盘、留痕、进程内按源加锁）。 - data/introspect_jobs.py：探查改成后台任务（core/job_runtime，lane kind introspect，和同源起草、剖析串行；按批反射、逐表记状态、 可停止、读完的照样物化；重启标中断不续跑）。 - api/datasources.py：POST /introspect 返回 202 和任务，dry_run 同步只刷新索引、返回命中数；/introspect-jobs 读任务、停止； /introspect-scope 读、预览、保存规则；/schema?table= 带剖析事实、说清三种「不在」；DataSourceOut 加 schema_scope、introspect_job。 - schema_view：search_tables（BM25 倒排，遮罩列只用列名，范围外只按名字和注释、权重低一档）、profile_lines（剖析事实一节， 附「只供写查询参考」，遮罩按渲染那一刻重滤，上传表格快照不一致时不给）、absent_detail。 - look：候选超过 PREFILTER_LIMIT 时只给预筛结果 + 已用到的表 + 一跳关联；点名或挑中范围外的表按需加入（每次查看最多 4 张）， look 记录加 added_to_scope、prefiltered；表详情带剖析事实。 - tools/datasource：db_schema__ 加 keyword、不传 table 时只列前 50 张；点名范围外的表按需加入（每次运行最多 8 张）；查询结果 照实列「未按目录检查的表」（unchecked_tables，不新增检查规则）；建工具时读剖析事实。 - 剖析：_relation_ends 分清「范围外，可以加入」和「表结构里没有」；任务记上传表格的 snapshot_id；last_facts。表助手、/schema 用同一段剖析事实。 - 目录接口：清单只列范围内，absent_reason 分开说；GET /catalog/search 查对象索引，POST /catalog/scope/add 加入范围。 - 第 1 波留下的一处：check_valid_filter 和 stored_valid_filter 拼有效记录条件时按 quote_name 强制加引号。 - 工具参数纠错：空着的可选参数不止一个时，只认拼写明显接近的那一个（db_schema 多了 keyword 以后 tabel 仍能纠成 table）。 - 测试：3,000 张表的合成库（对象索引、缺省范围超上限拒绝、规则圈 400 张后台读完、停止、重启标中断、和剖析排队、同步起草 409）、删除与结构版本、Inspector 回退、截断不判删除、范围规则、pinned、方言金样；改了同步探查的老测试改为等任务做完。	2026-10-16 14:17:06 +08:00
ThearchyHelios	2b9dcc55e3	评测题集与期望答案（第 2 波 W2-c）第一步：模型、派生图、期望的三种来源、目录快照与影子起草 ... - db/models_eval.py：EvalSuite、EvalCase、EvalRun、EvalResult 一次定全（第 3 波的执行、评分直接用），另加 EvalCatalogSnapshot 登记目录快照（谁、何时、来源、影子起草的进度和用量）。EvalResult.job_id 是 eval_run_id 的 别名：后台任务运行时的收尾按 task_model.job_id 认逐项。预算缺省按评测-D9（同时 2 题、每题 900 秒、单次 2 美元、 每日 5 美元），这一波只定字段。 - app/ledger/derive.py：全站唯一的「从钉住版本派生只读图」的生成器（总方案 X3）。这一波实现口径探针：拷出口径卡读 的取数节点（id、配置、图级 defaults 原样）+ caliber_from 固定到那一版的口径卡；只认可复用的源头卡，取数节点只许 引用入口字段，别的照实拒收。对账（这次的取数 + 口径 + 对账卡）、召回（新旧两版带前缀、caliber_from.nodes 改名 映射）的扩展点写在模块说明里，assemble / caliber_block 直接可用。 - app/eval/cases.py、suites.py：题目和题集的形状与校验。数值期望不许人填（评测-D4，写了 value 一类的键一律拒收）， 文字要点单列、不计入准确率；只做单轮（评测-D12，history 必须为空）；变量只认定时任务那份 {{ schedule.* }}； 题目指纹去掉确认人、出处运行、升版处置这些记录项。 - app/eval/gold.py：SQL 题、口径题、从运行认定三种期望。每次都以来源 eval、只读 + 遮罩的探索运行重算，期望值取封存的 查询快照（或口径卡的指标集）；只读守卫拒写语句、用到遮罩列的拒收（认法同证据面板的派生遮罩）、取不到值 / 失败 / 超时 / 停在人工确认上各写各的原因。口径升版用和正式运行同一个 unresolved_caliber_upgrades 判、退役按 subgraph_pin_problems 判，待处置就跳过；recompute / dual / incomparable 三选一、没有缺省。作答前后各算一次 （bracket / settle）给第 3 波的执行调。 - app/eval/snapshots.py：目录快照存成 kind=eval_catalog_snapshot 的内容寻址工件（读法即 data/catalog_view.py 定的 那一种）；影子起草是不占数据源队的后台任务，起草写进内存里的目录副本，不调 write_entry、不碰线上目录、不查业务库， 只起草题集用得到的表，开始前估算花费；停止、出错的不出快照。 - data/catalog_draft.py 只加入口 run_shadow_draft（同一个起草引擎，唯一不同是不去业务库数有效行过滤的排除比例）； data/catalog.py 把写库前的并入抽成纯函数 merge_draft、建起草模型抽成 build_draft_model（行为不变，影子起草和写库 用同一套并入规矩、同一个模型建法）。	2026-10-16 13:49:53 +08:00
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	736b031282	SQL 检查认时间列时带上 ENUM 的取值列表：PG 里类型名带 DATE 的枚举列，剖析不认是日期列、SQL 检查却认，两边对不上	2026-10-16 12:53:07 +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	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	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	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	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	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	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	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	ff278afd7e	剖析的范围在开始时定：排在起草后面的剖析任务，开始时按起草后的目录重挑要剖析的表 ... 真实后端验收里「起草完接着剖析」这条主路走不通：剖析任务建的那一刻就按当时的目录定了表单，可它排在起草后面，起草还没提出 关系，只靠关系才有检查项的表（链接表、明细表）一张都挑不进来，起草写完关系后剖析照旧跳过它们。 - 开始剖析时（_ProfileRun._rescope）按那一刻的目录重定：需要剖析的表、全部表整份重挑（这个任务的表都还没开始）；指定的表里 建任务时判为「没有可剖析的项」的再看一次，现在有了就排上。 - 排在起草后面时挑不出表也照建，不再 409（起草多半会提出关系）；开始时还挑不出来，任务以 0 张表结束，提醒里写明为什么。 - 界面：排队时写明要剖析哪些表开始时按起草后的目录再定，开始前的张数是按现在的目录算的。 - 新测试在去掉重挑的代码上两条都失败。	2026-10-15 19:43:29 +08:00
ThearchyHelios	4c4fa8e4e9	「需要剖析」多认一种：上次剖析之后多出了码值、日期检查（new_checks）；停止排队任务时不再读过期的 job（起草、剖析两处） ... - 以前只认从没剖析过、上次没做完、又冒出了待核实关系三种：上次剖析时没有可剖析的项（指定了表、记为跳过），后来有人把一列 记成状态类，或者日期列变了，「需要剖析的表」永远漏掉它。现在按当前要做的检查对上次剖析的检查项（kind、target），多出了 码值、日期检查就要剖析，原因 new_checks；上次是空表而跳过的仍不算（不发查询不知道有没有数据），界面和 409 的说法写明。 due_reason 改收 plan_checks 列出的检查，没人用的 profile_checks 去掉。 - 停止一个排队中的任务时，排队那一步没停成（刚被后台认领）要回滚，回滚让读到的 job 属性全部过期，再读 job.id 就在异步会话里 同步加载（MissingGreenlet），接口 500。起草的 cancel 在 main 上就是这样写的，剖析照抄了；两处都先把 id、状态取出来。 新测试在旧代码上复现了这个 500。	2026-10-15 19:28:17 +08:00
ThearchyHelios	4f0b60df03	导入、同步起草撞上剖析、起草任务时，说法按这次要做的事说下一步 ... 复核 R3。导入目录、同步起草撞上剖析任务回 409 profile_busy 时，原话来自 busy_message，结尾固定是「请等这次剖析结束 （或先停止它）再开始新的剖析」；使用者这时是在导入、起草，不是要开始新的剖析，导入对话框原样显示这句。导入撞上起草 任务时同样说「再开始新的起草」（这是改造前就有的，同一类问题一起改了）。 - catalog_profile_jobs.busy_message / ensure_free 加 then（缺省 THEN_PROFILE「再开始新的剖析」，建剖析任务、重试照旧）。 - catalog_jobs.busy_message / sync_busy_message / ensure_draft_free 同样加 then（缺省 THEN_DRAFT「再开始新的起草」）； ensure_idle 和 _lane_busy 按这次要做的事（kind）选：导入撞上什么都是「再导入」；同步起草撞上剖析是「再起草」，撞上 起草仍是「再开始新的起草」（和建起草任务同一句话，test_catalog_draft_jobs 钉着这一点，没动那个文件）。 - 导入接口的说明补上撞上剖析任务回 profile_busy。 测试：剖析时导入、同步起草、再建剖析任务三句结尾各自对得上；队被剖析占着时（任务刚好在收尾）同样按这次要做的事说。	2026-10-15 19:12:48 +08:00
ThearchyHelios	7ee820f0f5	表的「上次剖析」取真正开始过的那一次：没开始就停了的、还排着的不再挡掉上一次真正剖析，保留也不清它 ... 复核 R2。以前每张表的「最近一次剖析」只按任务的建立先后取，没开始就结束了的那一项（停在前面的表上、任务止损或整体 出错后没轮到）、排队中还没轮到的那一项也算。于是表详情、表清单的上次剖析变成一条没有行数、没有发过的查询的「已停止」； prune 只保护排第一的那一项，上一次真正剖析所在的任务就会被清掉——行数估算、日期范围、发过的查询只存在剖析任务里 （设计文档 §5 否决了写进目录），删了就找不回来，和 §4.8「表详情的上次剖析永远有」相抵。建一个排队任务时顺手的 prune 就能清掉它。 - _ranked（替代 _latest_per_table）一个子查询给两个排名：shown 是真正开始过（started_at 有值；收过尾的表都有）的最近 一项，一次都没开始过才退回最近一项；latest 是最近一项，只用来看这张表是不是已经排在进行中的任务里。 - last_profiles、last_detail、prune 的保护都按 shown。表还排在进行中的任务里时，表详情给的是上一次真正剖析的明细， 排队、在做由页面跟着的任务说（前端 profileCell / ProfileSection 的 live 本来就这样）。 - due_reason 也按 shown（加上 queued：已经排在进行中的任务里不算要剖析），不照复核建议看最新一项：不然表清单一边显示 「上次剖析：完成」，一边说「上次剖析没做完」。真正没剖析完整的表照样 due——上次真正剖析是 partial 的仍是 unfinished， 从没开始过的退回最近一项（cancelled）仍是 unfinished，剖析之后冒出的待核实关系仍是 new_relations。 测试：新增先剖析 channels、再在 [visits, channels] 停在 visits 上——channels 的上次剖析仍是第一次（行数、发过的查询 都在），不算要剖析；prune(keep=1) 不删；保留数为 0 时再建一个排队任务也不删。	2026-10-15 19:11:59 +08:00
ThearchyHelios	35c83d3001	剖析收尾照实说：没写进目录的检查项不再标「完成」，目录和表的剖析结果同一个事务提交 ... 复核 R1。目录只在一张表结束时由 _record 写一次，进程被杀（启动时标中断）、任务整体出错（剖析到一半快照被改动）时， 正在剖析的那张表没走到这一步，可它已经做完的检查项仍记 done：检查清单上标着完成，findings 是空的，目录里那几条关系 还是推断。_close_tasks 只改 pending / running，于是把没写进去的结论说成了做完。 - _close_tasks：还没结束的表上 done 的检查项也记为跳过，原因同这张表（中断 cancelled、出错 error），说明是 「{原因}，查完了但结论没有写进数据目录」，算进 unfinished，重试时带上这张表；这张表的 error 写明「已查完的 N 项 没有写进数据目录，剩下 M 项没查」。跳过的项按检查项列全：进行中的表只随时落了检查项，按规则不查的（遮罩……）以前 收尾时不进跳过的项。优雅停止、关停不走这条路，正在剖析的那张表做完的项照常写进目录（error 说「照常写进了数据目录」）， 前端可以据此分开说。 - 目录和这张表的剖析结果改成同一个事务：catalog.write_entry 加 commit=False（只写进事务、冲突照样回滚）， catalog_profile._record 写目录不提交，recorded（_save_table）也不提交，最后一起提交。以前是两次提交，进程在中间没了 会出现目录写了、剖析记录却说没写的情形，上面那句「没写进目录」就不照实。 - 不改成每项做完就写目录：每写一次目录升一个版本，表结构快照的哈希跟着变，和人工编辑撞乐观锁的机会也成倍增加； 设计文档定的是整张表结束时并一次。 测试：启动标中断那条改断言（查完的码值记 skipped / cancelled、error 带「已查完的 1 项」）；新增剖析到一半快照被改动 （4 条关系查过了、全记 skipped / error、目录不动、重试带上 visits）；新增记结果那一步出错时目录跟着回滚（换回两次提交 这条就挂）。	2026-10-15 19:11:28 +08:00
ThearchyHelios	f375101c5e	补齐剖析任务的测试（设计文档 §7 后端那一串），顺手改掉几处过时的说明 ... 新增 tests/test_catalog_profile_jobs.py，用很小的 SQLite 夹具和假的查询层让超时、失败、停在哪一条都可控： - 同源排队：起草在跑时剖析建成 queued、waiting_for = draft，起草结束后自动开始；剖析在跑时建起草任务不 409、排在后面（waiting_for = profile），同种任务照旧 409；停掉排队中的剖析任务（在队里等着的一起停掉，检查项不留「排队」）；导入目录、同步起草在剖析时 409 profile_busy；同步起草、导入期间建的剖析任务排在它后面，导入期间再导入一次 409 - 停止：停在 visits 的码值上，做完的 4 项照常写进目录、没做的记 cancelled 且目录不动，后面的表 cancelled，正在等的那条查询留痕写明没等结果；已结束的再停 409 catalog_profile_finished - 关停标中断、启动标中断不续跑（进行中那张表的检查项转成跳过）；重试只带没做完的表、设置取当前的，没有可重试的 422，正忙 409 - 任务级止损：连续 3 条失败（error 带驱动报错第一行）、最近 10 条 7 条超时（停下、后面的表带同一句原因）；提醒在好转后清掉，成功一条重置连续失败数 - 每张表开始前重读数据源：停用、关掉剖析就停；遮罩按最新的设置 - 范围：全部 / 需要剖析 / 指定（视图、表结构里没有、没有可剖析的项建成 skipped），有待核实关系的在前；profile_due 的 never / unfinished / new_relations；挑不出表 409 profile_nothing；超 500 张 422；空表一条查询记 skipped - 留痕：IN 列表里抽到的键值（文字键）不出现在库里的 query_log；表清单、表详情带上次剖析 - 设置迁移：启动时删掉旧键，老页面带旧键保存只摘掉；保留：超过保留数删旧的，不删某张表最近一次剖析所在的任务，建任务时顺手清 剖析停在一张表中途时，那张表的 error 改说「已做完的 N 项照常写进了数据目录」；engine.py、catalog_transfer.py、catalog_jobs.py 里还写着查询次数上限、只看起草任务的几处说明跟上。	2026-10-15 18:40:19 +08:00
ThearchyHelios	6b3c737fb8	数据剖析改成逐表的后台任务：引擎改编排、剖析任务、接口、设置换新键 ... 以前剖析是一次同步长请求，预算按整次算（max_queries 60、max_total_s 120），选 50 张表只做得完前两三张，其余整张记「查询次数用完」；不能停，关掉页面报告就没了，对业务库查了什么无从查。 - data/catalog_profile.py：检查逻辑和 _apply 并入规则原样保留，只换编排。公开的逐表入口 profile_table：先列全检查项（plan_checks，纯函数，范围的 profile_checks、建任务时列的检查项、执行用同一份；遮罩、多列、不在表结构里、指向视图的关系在这里就列成按规则跳过），第一条查询估行数（确知空表整张表跳过），逐项执行、进度回调，整张表结束写目录并和回调在同一次库操作里；停止时做完的项照常写、没做的记 cancelled 保留旧结论。_Runner 拆成整个任务一个的 SourceRunner（只读守卫、单条时限、任务级止损：连续 3 条失败、最近 10 条 7 条超时；最近 6 条 4 条超时提醒；每条查询留痕，SQL 经 normalize_sql 去掉字面量）和每张表一个的 TableBudget（用完只停这张表）。删掉同步的 profile_catalog、挑表前批量估行数（_skip_empty、PROFILE_DEFAULT_TABLES、PROFILE_PROBE_TABLES）和进程内 _RUNNING。设置换成 table_max_queries（1–200，缺省 40）、table_max_s（10–600，缺省 60），旧键 max_queries、max_total_s 启动时从库里删掉（migrate_settings，不折算：旧值按整次算，含义不同），保存时只摘掉不报错（without_legacy）。表助手的 run_query 和起草时核对有效记录条件改走单条查询入口 run_single_query，行为不变。 - data/catalog_profile_jobs.py：剖析任务的建（selected / needed / all 三种范围，排序同前：有待核实关系的在前、使用次数、表结构顺序；挑出 0 张 ProfileNothing）、排队（和同源起草按建立先后串行，waiting_for）、执行（每张表开始前重读数据源：停用或关掉剖析就停下；遮罩按最新设置）、停止、重试、启动标中断不续跑、保留最近 50 个结束的任务（某张表最近一次剖析所在的不删）、last_profile / profile_due 的查询、任务和逐表的接口形状。 - api/catalog.py：加 /profile-jobs（建、active、latest、{job_id}、tasks/{seq}、cancel、retry），登记在 /{table} 前面；删掉 POST /catalog/profile；清单每行加 last_profile、profile_due、profile_due_reason、profile_checks，顶层加 active_profile_job；单表加 last_profile；导入目录、同步起草遇到剖析任务 409 profile_busy。api/coded.py 加 profile_nothing、catalog_profile_finished；api/datasources.py 保存时摘掉旧键；main.py 启动时标中断加设置迁移，关停时停掉进行中的剖析。 - 测试：test_catalog_profile.py、test_catalog_profile_units.py、test_catalog_semantics.py 里打同步接口和旧设置键的改走任务和新键，检查逻辑的断言保留；同步接口的整次总量上限一条改成逐表次数、逐表时长两条。	2026-10-15 18:30:48 +08:00
ThearchyHelios	1e58862bf0	抽出数据目录后台任务的共用运行时，起草任务改用它：为剖析改成逐表的后台任务做准备 ... data/catalog_job_runtime.py 从 catalog_jobs.py 抽出进程内任务的执行与停止（JobManager：start / stop(grace) / wait / running / shutdown；JobRun 把进队、等轮到自己、执行、按停止原因收尾、出队写一次）、同一任务的库写入一条一条来并 shield（SerialWriter）、启动时标中断（interrupt_on_startup、close_job）、状态词常量，以及每个源一条先来先到的队（SourceLanes：任务阻塞地占，同步写操作不阻塞地试占）。剖析和起草是同一类问题（关页面就没了、不能停、不留痕），生命周期各写一份迟早一边修了另一边没修；共用的是生命周期代码，表各建各的。 起草的行为不变（test_catalog_draft_jobs.py 一条不改全过），只是：ensure_idle 拆成「同种任务互斥」（ensure_draft_free，建起草任务、重试用，剖析任务不挡起草，起草任务排在它后面）和「同步写操作要求源空闲」（ensure_idle，同步起草、导入用，剖析任务也算）；同步起草、导入目录执行期间占着这个源的队，期间新建的任务排在后面；任务和清单顶上的进度带 waiting_for（起草排在剖析后面时为 profile）；排队中被停止的任务连同在队里等着的后台执行一起停掉、出队。 db/models.py 加 CatalogProfileJob、CatalogProfileTask 两张表（create_all 建，同源排队或进行中的部分唯一索引照起草的写法）；catalog_profile_jobs.py 先放剖析任务的忙碌判定，下一步补全。	2026-10-15 18:10:50 +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	acb9ae1774	应用平台集成（后端访问面）：开登录后使用者的问数据只能是探索运行、节点与工具白名单、查询结果在工具边界遮罩且数据源强制只读、记忆与知识库范围不能自选，运行流按运行判读权限；对话按建立人隔离（应用助手对话要 manage）；能力字段语义的审阅队列与批量审阅；按需视图每日上限登记为设置项；通用设置接口不再读写登录设置；运行带来源、按来源筛选，审批带待办 id（含统一复核后的修复）	2026-10-14 21:55:51 +08:00
ThearchyHelios	0f32b8335e	应用平台 BE-4 助手：按需查看（默认只给数据源概览、look 行停下执行接着写、一次拿齐、每轮 3+1 次、系统代为查看、查看记录进历史），生成过程可插拔（Applier / Checker 注入、ask 结束本轮），查看对象按类型标记并实现表 / 能力 / 工作流版本三种（表详情与 db_schema__、/schema 共用并按遮罩规矩），应用润色接口 /copilot/app-stream，从运行提取模板记来源，演示模型走一次查看（含统一复核后的修复）	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	b149351960	导入目录：推断、有确证的项在校验之前去掉确认时的依据，手改过的文件里依据不合规也不再把整项跳过（照常只填空缺）；已确认、已驳回的项依据不合规照旧跳过	2026-10-14 16:11:04 +08:00
ThearchyHelios	a88fd93376	剖析不改人确认过的外键关系的基数：值不变、保存即确认的外键关系来源仍是 fk，以前 _patch_fk 不看状态，数据核实出的基数不同就直接改写，确认时的依据还挂着，前后矛盾；现在同 _patch_confirmed，不改人定的基数、也不标用数据核实过，测量的说法照常写进备注	2026-10-14 16:11:04 +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	a78affa2f1	目录修改提案落在已驳回的项上时，改前写出被驳回的原值：plan_patch 交回的 before 带上驳回的值、before_status 写 rejected（只改给人看的信息，算改后、算状态照旧按没有这一项，保存时照旧换成人工确认的新值）；助手流的提案卡片、表助手的提案卡片和待保存的修改写「已驳回：<原值>」，和导入预览「目标里这一项已经驳回」一致；check-catalog-loop、check-stream 补对应检查	2026-10-14 14:07:15 +08:00
ThearchyHelios	eb8d73b6da	表助手不再把数据源的起草要求当成使用者的原话：交给模型的背景里起草要求标明「不是这次对话里使用者说的话」，系统提示词和 propose_changes 的说明写清 reason 里引用的原话只能是这次对话里使用者的消息，依据来自起草要求时写「起草要求写着：……」	2026-10-14 14:07:15 +08:00
ThearchyHelios	20bef14520	保存目录修改提案时依据随项保存：表助手、助手流里「建议更新数据目录」的提案经 /catalog/{table}/patch 保存，写了依据的项备注记成「依据：……」（超出目录文字项的上限 500 字截断），没写依据的照旧；值不变、保存即确认的项和沿用了测量备注的关联关系，依据写在原来的备注前面（关联关系的剖析备注再剖析时整段换掉，放在前面才留得住）。表详情里人工确认的项有备注时也看得到：表级的项写在值下面（同有效记录条件的说明），列的一格、关联关系悬停看；check-catalog-loop 的假服务端照服务端记下依据，补保存后看得到依据、人工确认项的说明两处检查	2026-10-14 14:07:14 +08:00
ThearchyHelios	fc25c6367c	起草任务写进目录的项，修改时间取那一次写入的时间：宽表逐段落盘的每一段、整张表收尾各取一次当时的时间，不再整个任务都记成开始的那一刻（以前只在任务开始时取一次、截到秒，比任务的开始时间还早，也看不出哪一段是什么时候写进去的）；补一条用假时钟逐段核对的测试	2026-10-14 14:07:14 +08:00
ThearchyHelios	6baebe821a	合入数据目录闭环第一步（后端 B）：表助手（表详情页对话，流式返回，成批提出经校验的修改提案，只在开了剖析的源上经只读守卫跑查询、结果先遮）；审阅队列（按使用次数、风险、来源排序，批量确认驳回逐表乐观锁，表被哪些运行用过，审阅进度）；数据目录导出导入（先预览，确认和驳回的照带、冲突保留目标、推断只填空缺、对不上的跳过并写原因）；一次修改上限提到 200 项	2026-10-14 10:16:53 +08:00
ThearchyHelios	d3bd80211a	数据目录闭环第一步（后端 A）复核修正：没收下的有效记录条件不算失败，在起草任务逐表的 log 里记一句，接口看得到（以前只进服务端日志）——没通过校验的写原因（「有效记录条件里不能有子查询，模型提议的这一条没有收下：……」），剖析核对排除 0% 或 100% 的写数到了多少行；只在请模型写表级的项的那段里记，一张表最多 10 句。CatalogDraftTask 加 log 列（存量任务回填 NULL，接口给空列表）	2026-10-14 10:00:10 +08:00
ThearchyHelios	7383877ee7	数据目录闭环第一步（后端 A）复核修正：模型提议的有效记录条件存整理过的写法——原文照旧（NOT IN、IS NOT NULL 不被改写），只把列换成表结构里的真名、不带表名、按数据源的方言要加引号的加引号，剖析核对的就是存下的这一条。以前存的是模型的原文，核对时却按真名加了引号：PostgreSQL 上混合大小写的列（"OrderStatus"）存成 orderstatus <> 'X'，一跑就报列不存在，SQL 检查还会让模型照抄。列名先照原样对表结构，只差大小写的几列写不清是哪一列的不收；加了引号超过 500 字的不收（写进去会让整张表写入失败）；不合规的说法用界面上的叫法「有效记录条件」	2026-10-14 09:59:52 +08:00
ThearchyHelios	9c30bf0307	数据目录闭环第一步（后端 A）复核修正：起草提示里「已确认的目录项」不再带遮罩列的码值，人工确认过的也不给（码值就是这一列的取值），开没开剖析都一样；这一列别的确认过的项照给。和新加的码值背景、表助手的背景、导入目录的口径一致	2026-10-14 09:59:35 +08:00
ThearchyHelios	a490365bcf	数据目录闭环第一步（后端 A）复核修正：按比例止损只看每次调用的最终结局。服务方嫌额度太大退回 8192、结构化输出不支持或回了说明文字改走纯文本、429 / 5xx 退避重试之前的那次照旧记进用量和提醒，不进止损的窗口——它不花额度，也说明不了模型写不出来；重试用完仍出错的那一次照常算。以前额度上限 8192、不支持 json_schema 的 OpenAI 兼容网关上，并发的头几次调用全是这种重来，第一次额度用完就凑满 10 次里 7 次，那一段直接记没写出来、不再拆小	2026-10-14 09:59:19 +08:00
ThearchyHelios	813522ec7b	表助手：待保存的修改不设上限、有效记录条件按起草的规矩核对。宽表上逐列补中文名、含义，几轮下来待保存的修改常常超过一次保存的 200 项，以前请求里超过 200 项就 422、对话用不了；现在交多少都收，背景里只列最近的 200 项（界面上新的提案接在后面）并写明另有几项，码值照全部待保存的修改合并。模型提的有效记录条件是 SQL：按 sqlcheck.valid_filter_problem 核对（一个条件、只用这张表的列、不能有子查询、聚合、窗口、分号，只能用几个函数），sqlcheck 里还没有这条规矩时至少核对用到的列都是这张表的、都在表结构里、没有子查询，不过的不交给界面、原因交回模型；系统提示里先写明这几条写法	2026-10-14 09:52:37 +08:00
ThearchyHelios	9b4663afa8	导入核对有效记录条件用到的列：有效记录条件是表级的一项、却写着列名，按列跳过的规矩拦不住它。按目标数据源的方言解析出条件里用到的列，不在目标的表结构里、是别的表的列、带子查询（没法核对子查询用到的表和列）、解析不了或不止一句的跳过并写原因；人工写的条件不限函数，列名大小写和目标不同、带本表表名（文件里的写法、目标的写法都认）的照带。核对用的 filter_columns_problem 放在 catalog_transfer，表助手在没有起草的校验规矩时也用它	2026-10-14 09:52:13 +08:00
ThearchyHelios	864e63dadd	审阅队列与进度按约定改：field_label 写给人看的完整位置（「表的有效记录条件」「列 status 的码值」「指向 members 的关联关系」，和表助手提案、导入冲突的说法同一个函数），列级的项另带 column；排在这里的原因写「被 N 次运行用到」，数的是运行（同「用过这张表的运行」的 total），同一次运行里查了几次、使用次数比运行次数多时两个都写（「被 2 次运行用到，使用 5 次」），table_usage 和优先级照旧按使用次数（同目录清单的「使用 N 次」和排序）；进度里的常用 20 张表和起草的默认范围是同一批（使用次数从多到少，用到的不够 20 张时按表结构的顺序补齐），top 只给 tables、items_total、items_confirmed，all 只给约定的四项；表助手背景里写这张表被几次运行用到、查询几次	2026-10-14 09:51:49 +08:00