32 Commits

Author	SHA1	Message	Date
ThearchyHelios	f774e42463	数据剖析可以同时剖析几张表：剖析设置加「同时剖析的表数」（table_concurrency，1–3，缺省 1，即以前的一张做完再做下一张；上限 3 是给这个源上的分析留出连接池的临时连接），每张表的查询仍一条一条发，所以同一时刻对业务库最多这么多条查询。剖析任务的执行改成按设置开几个执行者，按任务里的顺序一张结束就开始下一张；进度、发过的查询各落在自己那张表上（不再记「正在做的那一张」）。每张表开始前照旧重读数据源：停用、关掉剖析或止损后不再开始新的表，正在做的几张照常做完（止损时剩下的项记止损的原因），都结束后再把没开始的记停下；止损的连续失败、超时比例按几张表的查询合起来算。停止、关停时正在做的几张各自收尾，做完的项照常写进目录，都收完才往上交（等的时候又被停止也等完）；一张表让任务整体出错（快照被改动、数据源没了、记结果写库出错）时，另几张按停止收尾、原因写这一句，本进程续不上租约的不写。同时要估同一张表的行数时只估一次（按表加锁，先来的没估成后来的自己估）。同源已有剖析时的 409 说法从「第 x / y 张表」改成「已完成 x / y 张表」。界面：设置表单多一格（单位「张」，提示写明业务库同时要应付几条查询、和分析共用连接），风险说明、卡片悬停、开始前的醒目一句在大于 1 时写明「同时剖析 N 张表、每张表的查询一条一条地发」，预算多一行，这次最多用时按几轮算。测试：同一时刻在途查询不超过设置、每张表仍一条一条发（1/2/3 三种）、几张一起显示进行中并按顺序开始、同时停止各自写进目录、止损后不再开始新表、停用时正在做的做完、一张出错另几张按停止收尾、共享行数只估一次；check-catalog-profile 加一节（预算、估算、说法、两行进行中、表清单）。验收：后端全量 14979 通过；止损那条并发测试单独跑 30 遍、整个剖析任务测试文件并行跑 15 遍都没有偶发；tsc；check-catalog-profile 217 项、check-copy 28 项全过	2026-10-21 09:08:10 +08:00
ThearchyHelios	7f949cce92	取值观察：业务日期有未来值时不再误报量跌、缺天；「今天」统一按服务端所在时区 ... 验收复现：业务日期最晚到明天、今天只写了几行，记出一条 volume_drop。原因有两层： - 比较器 value_drift.daily() 取 last = max(days)，只在 last >= today 时退一天；max 落在明天时退到的是今天这个 还没写完的日子。改成最近一个整天 = min(有数据的最后一天, 昨天)。 - 按日行数的查询 day_volume_sql 只有下界，未来的日子也进了窗口。加上界：数到观察当天（含），第二天起不算 （< 第二天，时间列上当天的时分秒照样算进来，文字存的日期按字符串比同样成立）。签名改成必须传 until。 缺天同样的问题也修了：今天以后的空日子不算缺天；以前那次观察只看到它自己那天（data.until）为止，免得它 窗口里未来的空日子被当成「以前就有过缺天」，挡住这一次真缺的天。断档遇到未来值时离今天是负数，只会报不出、 不会误报，观察本身照实记最新业务日期（目录里也照实给人看），不截未来值，写进了模块说明。 「今天」：原来窗口用 UTC 日期、比较器用 now.date()（也是 UTC），业务日期是本地日期，东八区凌晨 0–8 点会差 一天。统一成服务端所在时区（catalog_profile_observe.local_today，和待办汇总 notify.digest_at 同一个口径）， 写进模块说明。 测试：test_value_drift 两条（未来值不算最近整天、未来空日子不算缺天且历史按 until 截）；test_catalog_observe 两条（SQLite 真跑剖析任务，明天的行不进窗口、不记量跌；local_today 按 TZ 取本地日期）。去掉修复回跑都挂。 金样（tests/fixtures/dialect/*.sql）的 day_volume 一行随上界更新；scripts/dialect_it.py 加了一条「只数到观察 当天」的真库核对。	2026-10-17 07:59:19 +08:00
ThearchyHelios	ed72ee68d6	W3-a 关联覆盖率下降、清理目录跨表、扩容器集成测试到对象索引和取值观察 ... - 剖析核对关联关系时，覆盖率从够有确证的线（95%）掉到线以下的记一条 coverage_drop（取值变化，warning）：剖析本身照旧 按规则降回推断（人工确认的只补上新的覆盖率），这里只把「覆盖率下降」留进变化记录。人点的剖析也记（变化记录全站一份）。 关系的发现里多带 previous_coverage。 - 处理动作「清理目录」逐表清：这张表上说到被删的列的项，加上别的表指向它的关联关系（表删了时尤其如此）；记这张表的 目录版本，别的表也动了的另记 catalog_versions。 - 剖析任务的逐表进度多一类 observe（取值观察的四类合成一组），前端「取值观察 N/M」用它。 - 定时维护补一条测试：AGENTLAB_SCHEDULER 关着时调度循环不起，到点的维护不触发、不建任务。 - scripts/dialect-it.sh / dialect_it.py 扩到第 2 波的对象索引字典查询（走字典查询不退回 Inspector、类型、表注释、行数 估算、Oracle 小写名的 quote）和这一波的取值观察（经剖析引擎只观察：行数、小表码值整表、大表 PG / Oracle 块采样、MySQL 前 N 行、最新业务日期排除无效日期，max_date_sql 直接跑）。夹具的订单表加了表注释。本机跑了一次四种库的容器 （postgres:16、mysql:8.4、mariadb:11、gvenzl/oracle-free:23-slim）：121 项全过、0 项不通过，跑完容器已删、镜像留着。 验证：后端全量 14046 通过（11 跳过、8 预期失败）。	2026-10-16 17:28:07 +08:00
ThearchyHelios	c95e5b4e84	W3-a 取值观察：剖析引擎的四类观察检查、比较器、撤销「已列全」（next-round 03 B2） ... 码值出现新取值、比例剧变、业务日期断档、某天没数据，以前都看不到：确认过的码值列不再取分布，大表只看物理顺序最老的 前 10 万行，「已列全」过期以后 SQL 检查还照它提示。现在： - 剖析引擎加四类观察检查（data/catalog_profile_observe.py）：rows（行数，用剖析开头那条估行数的结果）、codes_observe （所有码值列，包括人工确认过、标了已列全的）、freshness（已确认或已验证的业务日期的最新日期）、daily_volume（最近 35 天按天计数）。计入每张表的预算、止损和留痕，每条观察记口径 basis 和它出自哪几条查询；遮罩列不进任何观察查询。 - 大表口径照目录-D7：有确认的业务日期且该列打头有索引看 35 天窗口；PG / Oracle 没有就块采样（比例按表的大小取一档， 不跨档比）；MySQL / SQLite 没有就按存储顺序的前 N 行，照实写口径。最新业务日期、按日行数在大表上只在有索引时才查。 SqlDialect 加 max_date_sql（有效区间里的最大日期），方言金样跟着加了两条。 - data/value_drift.py 纯函数比较器：新码值（已列全的任何新值、没列全的要占 0.5% 以上且有历史）、PSI 剧变（≥0.25 warning、0.1–0.25 info，两次都要 1,000 行）、断档（超过 max(2×中位间隔, 3 天)）、缺天（以前的窗口没有过）、量跌 （不到前 28 天中位数的 30%）、行数跌 30% / 涨 3 倍（估算值要连续两次）。只和同口径的历史比。 - 观察记进 table_observations（每张表每种观察留最近 26 条），比出的取值变化进 source_changes，和这张表的剖析结果、目录在 同一个事务里。机器唯一写进目录的事：数据证明码值表不再列全时撤销「已列全」（目录版本 +1，署名「取值观察」，值、含义、 状态都不动），SQL 检查随之不再按旧码值表提示 unknown_code。 - 剖析任务的范围加 observe（观察到期的有目录的表，只观察）和 maintenance（定时维护：需要剖析的 + 观察到期的）；人点的 「需要剖析 / 全部 / 指定的表」照旧不观察。只观察的那一项不算「上次剖析」（不顶掉表清单的上次剖析和给助手的剖析事实）。 任务的设置快照里记 trigger / fire_at / schedule_id（剖析任务表没有这几列）。 - 观察结论（最新业务日期、更新的行数）经 last_facts → schema_view.profile_lines 和剖析事实同一节进 look、db_schema、 /schema、表助手（X7），遮罩在渲染那一刻再核。 测试：test_value_drift（阈值两侧、口径不同不比）、test_catalog_observe（四类观察与口径、撤销已列全与 SQL 检查、去重、 遮罩不进查询、大表窗口与前 N 行、PG / Oracle 采样 SQL、观察不算上次剖析、进表详情）。	2026-10-16 16:40:41 +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	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	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	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	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	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	7383877ee7	数据目录闭环第一步（后端 A）复核修正：模型提议的有效记录条件存整理过的写法——原文照旧（NOT IN、IS NOT NULL 不被改写），只把列换成表结构里的真名、不带表名、按数据源的方言要加引号的加引号，剖析核对的就是存下的这一条。以前存的是模型的原文，核对时却按真名加了引号：PostgreSQL 上混合大小写的列（"OrderStatus"）存成 orderstatus <> 'X'，一跑就报列不存在，SQL 检查还会让模型照抄。列名先照原样对表结构，只差大小写的几列写不清是哪一列的不收；加了引号超过 500 字的不收（写进去会让整张表写入失败）；不合规的说法用界面上的叫法「有效记录条件」	2026-10-14 09:59:52 +08:00
ThearchyHelios	447c66649c	数据目录闭环第一步（后端 A）：有效行过滤的校验和剖析核对 ... - sqlcheck.parse_valid_filter / valid_filter_problem：按数据源的方言用 sqlglot 把有效行过滤解析成一个条件，只能引用这张表的列（不带表名或带这张表的表名，不分大小写），不能有子查询、聚合、窗口函数、分号、注释、模板占位、参数占位、算术，只允许比较、IN（值的列表）、BETWEEN、LIKE、IS NULL、AND / OR / NOT 和 UPPER / LOWER / TRIM / COALESCE，不超过 500 字，至少用到一列；不认识的数据源类型不收 - sqlcheck.render_valid_filter：把条件按方言重新写出来，列换成表结构里的真名、按剖析查询的规矩加引号，拼进核对查询用 - catalog_profile.check_valid_filter：开了数据剖析的源经剖析的只读守卫（guard.check(readonly=True)、单条时限、查询次数上限）发一条查询，只取条件里的列、先取前 max(抽样键值数, 整表统计行数上限) 行，数出总行数和被排除的行数；排除 0% 或 100% 的不收，收下的写「剖析核对：排除 3.2% 的行（共 12,345 行）」，只数了前若干行的写明按前几行统计；没开剖析、数据源停用、条件里有遮罩的列、视图、取值拼不进查询、查询失败或超时照收，写明没有核对的原因	2026-10-14 08:30:14 +08:00
ThearchyHelios	706f715529	剖析也核实外键关系的基数：外键只保证被指向的键唯一，子表一侧一行还是多行看数据；以前跳过外键，扇出检查对外键来的一对多只能报警告，受管发布挡不住订单关联明细后对订单金额求和。来源、状态、覆盖率不动，只补基数和「用数据核实过」	2026-10-04 03:38:31 +08:00
ThearchyHelios	ab9d45c428	数据目录 F2b：剖析报告和目录页读结构化字段，不再从原话里认——服务端最小改动：码值候选的结论带 pending（还有几个含义待填写），关系的结论带 cardinality_checked；报告里「N 个含义待填写」读 pending，基数写「已用数据核实」或「子表一侧未核实」读 cardinality_checked，挑表时跳过的空表读 empty_tables 列出来；表详情的关联关系标出基数已核实；剖析说明不带日期后，码值弹窗的说明后面按这一项的 updated_at 写时间；补后端测试和检查脚本的断言（假答复的 summary 不再写待填写）	2026-10-04 03:06:14 +08:00
ThearchyHelios	5b3839f787	数据目录 F2b：剖析的 409、剖析设置的 422 带机读码，界面不再从原话里认是哪一种——服务端用 api/coded.CodedHTTPException：剖析开始不了的五种情况带 code（profile_disabled、datasource_inactive、schema_missing、profile_busy、snapshot_tampered），保存数据源时剖析设置不合规带 code=profile_settings_invalid 和出错的那一项 field（max_queries……），给人看的那句不变；CodedHTTPException 多一个可选的 field；前端 profileBlockOf、profileFieldOfRejection 只认 code 和 field，没带机读码的旧响应按通用提示处理；补后端测试和检查脚本的断言（伪造的 409、422 都带 code）	2026-10-04 03:03:23 +08:00
ThearchyHelios	88c63bfd41	合入集成分支 feat/data-catalog（d897981，含 F2a 的证据面板、时间线和服务端修复）：自动合并，没有冲突；catalog_profile._relation_finding 两边的改动（F2b 的 previous_status、F2a 的 cardinality_checked 写在关系上）互不重叠	2026-10-04 02:52:28 +08:00
ThearchyHelios	99ca98a87d	B1 服务端自动挑剖析表不再挑中一批空表：候选里还有待核实（推断）关系的表排在前面，再按使用次数、表结构顺序；挑表时先估行数，确知是空表的跳过并记进 empty_tables（最多估 30 张、最多用掉查询次数上限的一半），估行数的查询算进这张表的查询数；候选全是空表时说明写明是空表	2026-10-04 02:19:26 +08:00
ThearchyHelios	661f6a38d7	A7 剖析写进目录的说明不再写日期：以前写的是 UTC 日期（at[:10]），和界面上按本地时间显示的修改时间对不上；改为「数据剖析：…」，时间以这一项的 updated_at 为准。is_profile_note 同时认升级前带日期的「数据剖析（日期）：」；same_profile_note 继续兼容旧数据：只差日期、或一段带日期一段不带的同一结论都算相同，升级后重新剖析不会给每张表升版本	2026-10-04 02:19:26 +08:00
ThearchyHelios	46c3fd3093	A6 扇出检查只在一对多确有其事时报错误：关系人工确认过，或数据剖析在数据上核实过子表一侧的键不唯一（关系上记 cardinality_checked，子表太大没核对的不算）才给 error；只凭外键结构推出的一对多降为 warning，说法改成「可能重复计算」，下一步写确认关联表里每个键只有一行、或先汇总再关联；人工编辑提交里带的 cardinality_checked 不作数；级别说明「结果必然有误」改为不夸大的说法；2B、F1 的测试按新规则更新：外键 + verified → warning，剖析核实过 → error，人工确认 → error	2026-10-04 02:19:26 +08:00
ThearchyHelios	163f3b96b3	数据目录 F2b / B7：剖析报告里关系的结论按实际变化说——原本就是已验证、这次照样核实的写「仍为已验证，覆盖率 x」，从推断升上来的才写「升为已验证」，已验证降回推断的写「降为推断」；服务端最小改动：关系结论多带 previous_status（剖析前的状态），summary 同步写「仍为有确证」；补后端测试和检查脚本的断言	2026-10-04 02:09:47 +08:00
ThearchyHelios	d805f64195	数据目录 F1 一致性：日期列的判定抽成 catalog.is_date_column，数据剖析（唯一日期列提议业务日期）和 SQL 检查（按业务日期以外的时间列统计）共用，只有时刻的 TIME、整数存的时间戳两边都不算；表名匹配统一按 name_key（只把 ASCII 字母转小写），resolve_table_name 和 SQL 检查里认表名不再按 Unicode 转小写，和使用次数、影响面同一个口径；切词合并成 catalog.name_words，剖析不再另写一份；更新过时的说明（错误级检查已经上线、剖析预算的叫法跟设置界面）；码值比较不分大小写保留，注释写明是照顾 MySQL 默认排序规则、宁可漏报	2026-10-04 01:17:29 +08:00
ThearchyHelios	bf5bee9246	数据目录 F1-B2：剖析写的备注只是开头的日期变了、其余都没变时，保留旧的项、不升版本（人工确认过的关系也一样）。以前隔天重新剖析、数据没变，目录版本也加 1，发布时记下的目录版本就对不上，之后每次正式运行都误报目录有变化	2026-10-04 01:14:08 +08:00
ThearchyHelios	b078d08ffe	数据目录 F1-A4：码值项加「已列全」标记（complete: true），只有人工明确勾选、或剖析整表统计（没有只看前若干行）得到的码值才有；码值不在码值表中的检查只认标了它的码值表，给模型的话改为提示核对取值，不再叫它照目录里的码值改。以前经对话只补了 status=9 表示作废，之后 status = 1 就被报提醒，模型还可能把对的 SQL 改错。提案补充码值时沿用原有的标记、自己不能标；目录页的码值编辑和填写含义弹窗加「已列出全部取值」勾选，表格里标「已列全」，检查脚本跟上	2026-10-04 01:13:13 +08:00
ThearchyHelios	6fe21096af	数据剖析接口：POST /catalog/profile 同步剖析，未开启或同一数据源正在剖析时返回 409，返回每张表用的查询数、写入的发现和跳过的原因，记录署名	2026-10-03 11:05:47 +08:00
ThearchyHelios	b5ec0a5a96	数据剖析的码值与时间列：状态类低基数列取值分布写成码值候选（含义待人填写），被遮罩的列不取；日期类列取最小值和最大值，只有一个日期列时提议为业务日期	2026-10-03 11:01:04 +08:00
ThearchyHelios	fefb708757	数据剖析的关系验证：抽样键值去父表核对覆盖率，父键唯一且覆盖率够的升为有确证（来源记为数据剖析），覆盖率低的保持推断并写明原因，人工确认过的只补覆盖率和基数；撤销审阅回到剖析的结论	2026-10-03 10:56:08 +08:00
ThearchyHelios	32c3f4a180	数据剖析的查询与预算：各方言的剖析 SQL 和安全字面量，每条先按只读过守卫再走查询层，记查询次数、单条时限和总时长，行数先读统计信息、读不到只数到上限	2026-10-03 10:51:39 +08:00
ThearchyHelios	dc65004cd8	数据剖析设置：按数据源存在 options.catalog_profile 里，默认关闭；保存数据源时校验取值范围，拼连接串时摘掉	2026-10-03 10:48:10 +08:00