52 Commits

Author	SHA1	Message	Date
ThearchyHelios	77fc0efa10	口径召回后端（W4-a）：发布新版本后反查用过旧版的答案、按参数分组在同一份数据上重算两版之差，数真变了才开 recall 待办 ... 为什么：口径升版是被迫处置的事件（02 做法 7、拍板 L6），已交付的答案以前没人追；目录事实被驳回、表结构变了也没有地方标。 - ledger/uses.py（新）：反查旧版本被谁用过——比对工件里等价已证明的问数回答（含轮次、对话主人）、W 的正式运行（定时任务、 应用各取最近 4 期）、固定了它的工作流版本发起的正式运行、固定这一版的应用、导出审计（导出人也是主人）；预告、召回、 版本用量共用这一份 - ledger/recall.py（新）：计划按（旧版本、新版本、input_key）去重成组，从已有召回运行重算（幂等、不建任务表）；每组一次 召回运行（origin_kind=recall，探索运行），派生图经 derive.recall_graph（新旧两版取数和口径卡带前缀、召回卡里算两版之差）； 不能重算照实记原因（数据部分不能复用、新版没这张卡、入口参数不齐、图里有人工节点或写入）；每次发布最多 recall_limit 组， 超出的手动接着算；收尾时按渲染的旧值新值判数变没变：变了开 recall 待办（开登录按主人各一条、关登录派给任何人）、推 ledger.recall，没变在原答案上记 ledger.recalled；待办「按新版重新出具」走 issue.check_target 同一套判法、「知道了」 - 目录事实被驳回或修改（审阅、人工编辑、保存提案、批量审阅之后）：冻结目录里看得到这一项的探索运行记 ledger.basis_changed， 按新目录多出错误级 SQL 检查问题的才开待办；表结构变动消费 source_changes（游标、处理时改了目录的当场交过去），标依据的 表结构已变，受影响的口径试算一次，算不出来才通知发布人 - 发布钩子在 commit_publish 提交之后排队（自动的几样和调度循环同一个开关），GET /api/workflows/{id}/recall-preview 给发布 弹窗预告；GET/POST /api/ledger/recall/{wf}/{v}[/continue] 给版本历史看批次、接着算；版本用量加问数回答、导出、召回 - ledger.recall 打开订阅（全局、个人渠道），同一渠道只推一次，消息不放数；新事件 ledger.recalled、ledger.basis_changed 登记为封存后追加的事件，可验证报告离线核对页认得；E4 每次发布召回了几组、数变了的比例 - runner 收尾时召回运行在后台收尾，启动时接着做没发完的批次	2026-10-16 19:52:03 +08:00
ThearchyHelios	9e687114f7	合入 W2-c 评测题集与期望答案：题集、题目、评测、结果的数据模型；三种期望来源（SQL、口径、从运行认定），每次以评测来源的探索运行重算，遮罩列拒收；口径升版的三种处置；全站唯一的派生图生成器 ledger/derive.py；目录快照与影子起草（不碰线上目录、不查业务库）；题集导出导入；零售样例题集	2026-10-16 15:38:11 +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	02abede047	合入 W1-c 目录方言与 Excel 期 5：剖析方言修正（IN 两边类型族、列类型存方言完整写法与 ENUM 码值、Oracle 小写引号名、统计过期复核、无效日期、按存储顺序取前 N 行的说法）、方言金样与 sqlglot 校验、本机容器集成脚本；Excel 列表按期累积、穿插小计、表格对象起草、CSV 走配方	2026-10-16 12:51:43 +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	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	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	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	20bef14520	保存目录修改提案时依据随项保存：表助手、助手流里「建议更新数据目录」的提案经 /catalog/{table}/patch 保存，写了依据的项备注记成「依据：……」（超出目录文字项的上限 500 字截断），没写依据的照旧；值不变、保存即确认的项和沿用了测量备注的关联关系，依据写在原来的备注前面（关联关系的剖析备注再剖析时整段换掉，放在前面才留得住）。表详情里人工确认的项有备注时也看得到：表级的项写在值下面（同有效记录条件的说明），列的一格、关联关系悬停看；check-catalog-loop 的假服务端照服务端记下依据，补保存后看得到依据、人工确认项的说明两处检查	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	4647fc9ff3	数据目录闭环第一步（后端 A）：防错事实的提议——起草时提议有效行过滤和去重规则 ... - 提示词：表级的项多要两项，valid_filter（有效行过滤，condition 写一段 SQL 条件、只用这张表的列，函数只用 UPPER、LOWER、TRIM、COALESCE）和 dedup（去重规则，rule 写一句话），各附一句 reason；写清只在表结构、注释、码值能看出来时才写，拿不准、没有就不写；业务日期照旧。结构化输出的约定、纯文本那条路的格式说明、只写表级的项那一行都带上这两项 - catalog._from_model：两项记模型起草、推断，依据写进 note（「依据：……」）；有效行过滤按数据源的方言解析（sqlcheck.parse_valid_filter），不过就丢掉、日志记一条，不算这张表失败；只写了一段文字的也认 - 起草引擎：表级那段写完核对有效行过滤。开了数据剖析的源经剖析的只读守卫数排除比例（catalog_profile.check_valid_filter），排除 0% 或 100% 的不收，收下的 note 写上「剖析核对：排除 3.2% 的行（共 12,345 行）」；没开剖析、连不上的照收，写明没有核对的原因；目录里人工确认、驳回过的不再查库 - 开了数据剖析的源：目录里记下的码值（剖析取过的取值和已知含义）交给模型做背景，要写表级的项的给全部列的、只写几列的给这几列的，遮罩的列、驳回的码值不给，已确认的不重复 - 测试核一遍 SQL 检查的规矩：起草来的有效行过滤是推断，漏了它只是提示；人工确认以后才是警告，驳回以后不报	2026-10-14 08:32:44 +08:00
ThearchyHelios	7c3484adba	数据目录闭环第一步（后端 A）：起草遗留——宽表逐段落盘、按比例止损、块进度、停止后的说法、同步起草与任务互斥 ... - 宽表逐段落盘：每写出一段（表级那段、每个列分段）就把这张表到这时拿到的内容并入目录（catalog_jobs.write_part，这一次合并不删任何东西）；整张表写完（ok、partial 都一样）再按完整覆盖的规则收尾一次，只删已经不在表结构里的列的模型项（write_draft 对 partial 也照删）。停止、服务重启时已经写进去的段留着；写过段的表照旧记 cancelled，model_error 写「已停止：已写进目录 N 段，剩下 M 段没起草」（中断写「已中断：…」）。新增、更新、删除的计数是各次写入的合计 - CatalogDraftTask 加 parts_written（已写进目录的段数）、chunks_total / chunks_done（这张表实际分成的块数和已结束的块数，段被缩小的上限分开、拆成两半后会变多；不用模型时为 null），升级时补列 - 止损按比例：这次起草最近 10 次调用有 7 次以上没写出来时，之后的段不再拆小、每块只问一次（不补问漏掉的列、截断后不再补剩下的、空壳不再原样再问，拆出来还没问的块也不再问），直到比例降下去；去掉会被偶尔一次成功清零的「连续 2 段」「接连超时」两条。结构化输出只给空壳的，这次起草还没换纯文本问过的照旧问一次；额度被拒、结构化输出不支持、网络错误这些通信上的重来照旧 - 同一张表接连 3 个原始段都一项没写出来：剩下没开始的段跳过不问，原因写「这张表接连 3 段都没写出来，剩下的 N 段已跳过，可以换一个起草模型后只重试这张表」 - 原因里「已拆小重试仍没写出」只跟在真拆过的那几段后面说：说到的段只有一部分拆过时写「其中第 3 段已拆小重试仍没写出」 - 目录清单的 last_draft 加 blank_columns_from（最近一次结束于 ok / partial 的用模型起草记下的留空列数；之后有起草写进了新内容时为 null）和 parts_written - 同步起草和后台任务双向互斥：同步起草进行期间同一个源建任务、重试、导入（ensure_idle）、再开一次同步起草都 409 catalog_draft_busy（进程内登记）	2026-10-14 08:31:35 +08:00
ThearchyHelios	65369b8a6e	表助手：SDK 不再自己重试（同起草，网络错误、429、5xx 只由表助手在还没输出时重试，退避 3、10 秒）；测试补上取模型的规格（起草设置、保留思考、额度 32768 / 8192、单次时限、不重试）和两个工具在 OpenAI 兼容、Anthropic 模型上都绑得上；query_snapshot_tables 不进 catalog 的 __all__（按模块属性取用，少和起草那边的改动撞在一起）	2026-10-14 08:23:08 +08:00
ThearchyHelios	a5d9ee0a16	表助手：表详情页里和使用者对话完善一张表的数据目录（POST /catalog/{table}/assistant，SSE：正文增量、只读查询、修改提案、完成、出错）；交给模型表结构、目录现状（每项的来源和状态）、关联关系（含别的表指过来的）、剖析结论、起草要求、使用次数、最近一次起草留空的列和界面上待保存的修改，遮罩列只给列名；提案按 plan_patch 核对（公式不收、列名必须在表结构里、遮罩列不给码值、已确认的同值不提），待保存修改里的码值并进新提的码值，只交给界面不写目录；只读查询只在开了数据剖析的源上给，经剖析的只读守卫和单条时限、每次请求最多 5 条、50 行交给模型，结果和报错先遮再交；模型取法、说法同起草（用不了 409），保留思考、额度 32768 可退回 8192、单次时限同起草，还没输出时网络错误和 429、5xx 重试，等待时发 SSE 注释保活，停止时正在进行的调用跟着停；PATCH 一次最多 200 项（预览和保存）	2026-10-14 08:20:02 +08:00
ThearchyHelios	adc56da6cf	数据目录审阅队列：推断的项按「使用次数权重 × 风险权重 × 来源权重」排好（有效记录条件、去重规则、业务日期、关联关系最高，模型起草、命名推断比库注释优先），带排在这里的理由，可按影响数字的项 / 名称和说明、按表筛选和分页；批量确认、驳回、撤销审阅逐表按版本乐观锁，同一张表的几条一次写入，一张表冲突不影响别的表；表被哪些运行用过（新的在前，取法同使用次数，抽出 query_snapshot_tables 共用）；审阅进度（常用 20 张表、全部、影响数字的项）	2026-10-14 07:59:51 +08:00
ThearchyHelios	7bc7fc685f	起草按复核修正：读回复出错也记进用量；补问时列出了、字段留空不算没写出来；留空的列看目录里已有的；一项都没写出来的宽表逐段写范围；提醒照约定的说法 ... - 读回复时出了意料之外的错：这次调用照样记进用量（算一次出错），再交给 _guarded 记这一块没写出来；以前 _take 抛异常 时这次调用不进 calls、token、failed_calls，也不进提醒的窗口。校验（catalog._from_model）里该是文字的地方写成了 数组、对象的（列名、表类型、业务日期的列、度量类型，columns 不是数组的）直接丢掉、不抛异常：实测列名写成数组时 抛 TypeError，整张表记「起草这张表时出错」。 - 补问时请写的列都列出来了、字段留空：表上算拿不准（记留空），用量和提醒里也不再算一次「只给空壳」没写出来；以前 提醒会因此劝人换模型，真正该做的是补充起草要求。 - 留空的列不算目录里已经有中文名或含义的（不论来源：以前模型起草、按「重新起草不丢内容」留下的，库注释，人工；驳回 的不算有）；写入时（write_draft）再按并入目录之后的结果筛一遍，起草进行中有人填了的同样不算。以前照界面的建议补了 起草要求再起草，模型这次没再给的老列又被说成「拿不准、留空了」，提示一直消不掉。 - 一项都没写出来的宽表同样逐段写上列的范围：「这张表 95 列，分 4 段起草，第 1 段（表级的项）、第 2 段（c001 到 c032，共 32 列）……都没写出来：原因」；只有一段的表照旧只写原因（这一段就是整张表）。 - 提醒照约定写「建议在「设置 → 偏好设置」的「起草模型」换一个模型、缩小起草范围，或者停止这次起草」。	2026-10-13 21:25:59 +08:00
ThearchyHelios	84405977b6	起草引擎按复核修正：每个原始段连同分开的各块一共 8 次；一直超时的模型几轮就停；止损后纯文本不再原样再问 ... - 封顶管到原始段：段大小减半以后，新开始的段按上限分开的各块（窄表重新拼成的各组、单表均分的各块）共用这一段的 调用次数（_Budget 在 _work 里按原始段建，_start、_guarded 接过去），不再每块各有 8 次。以前上限缩到 10 列后一直 只给空壳，4 张窄表拼成的 40 列段调用 20 次，最坏是「段列数 / 上限 × 8」。止损的计数（连续几段没写出来）同样按 原始段数。 - 超时的两半同时问：带表级项的前一半不再先写完才问后一半（一次超时就是一个时限，40 → 20 → 10 串着问要好几个时限）； 额度用完、只给空壳的照旧先写前一半、后一半拿它做背景。 - 超时另有一条止损：拆到每段 10 列（MODEL_MIN_PART_COLUMNS）的调用接连超时 2 次（MODEL_GIVE_UP_AFTER），超时就和 段大小无关了，后面超时的不再拆小，超时拆出来、等名额时还没问的块也不再问（次数退回）；有一次调用写出来就恢复。 只管超时：额度用完、只给空壳照旧拆小。原因后面补「拆到每段 10 列仍然超时，已停止拆小重试，建议更换起草模型」。 用假模型量：每次都超时的 40 列表从 8 次调用、约 7 轮（420 秒时约 49 分钟）降到 6 次、3 轮；首轮同时起草的 3 段从 24 次、约 8 轮降到 12 次、4 轮；40、20 列超时而 10 列写得完的照旧拆到 10 列全部写出。 - 止损以后本来能拆小的段只给空壳：已经走纯文本的不再原样再问（约定只对拆不开的段再问一次）；结构化输出的照旧换 纯文本问一次。 - resolve_draft_model 的说明照实写：超时不由引擎重试，当作这一段太大、拆小再问。 - 止损的说明改成文字（_Why.halted），两种止损各说一次。	2026-10-13 21:25:27 +08:00
ThearchyHelios	975dde1146	起草引擎按验收修正：列分段均分、超时拆小、段大小随模型减半、每段 8 次封顶、提醒、超时与没写出来的计数、模型留空的列、不插队、原因写清哪几段哪几列 ... - 均分：超过 40 列的表，列分段数是列数除以 40 向上取整，各段列数平均（相差不超过 1），不再留下 2 到 8 列的尾段（实测 会思考的模型常对这种小段只给空壳）；表级那段、窄表拼段、parts_total 不变。 - 拆不开的段（不到 10 列）只给空壳：再问一次，结构化输出换纯文本，已经走纯文本的原样再问，仍是空壳才记没写出来。 - 超时当作这一段太大：不再原样重试同样大小的段，按额度用完的办法拆小再问；网络错误、429、5xx 仍原样退避重试。 - 段大小随模型调整：一次起草里额度用完或超时累计 2 次，之后新开始的段列数上限减半（40 → 20 → 10，最低 10），新开始 的段超过上限就先按上限均分开（多表的段按表重新拼）；任务记当前的上限 part_columns。 - 封顶：一段（连同它拆出来的、补问的、重试的）最多调用 8 次，到了次数还没写完的记没写出来、原因写清。止损照旧。 - 提醒：最近 6 次调用有 4 次以上没写出来（额度用完、超时、空壳、出错），任务的 notice 写一句提醒（次数、原因，建议在 「设置 → 偏好设置」的「起草模型」换一个模型、减少表或停止）；之后最近 6 次里少于 2 次就清掉。 - 用量：进度回调 usage 换成 call_done（CallReport：用量、没写出来的原因种类、当前的提醒和列数上限），任务的用量加 timeouts、failed_calls；超时的调用 token 照实记 0。 - 留空的列：请模型写了、模型也列出了，中文名和含义却都没给（或者给的都没通过校验）的列记在 ModelOutcome.blank，逐表 记 blank_columns 和最多 5 个列名 blank_sample，任务上是合计，目录清单的 last_draft 也带列数；表的状态不因此变。已确认 的、库注释已经说清的列不算。补问时把漏的列列出来、字段却留空的，算留空，不再记成「漏了这些列」。 - 公平排队：宽表的表级那段写完，它的列分段排到已经排着的段后面（先来先服务），不再插到队首让窄表一直等。 - 原因：几段因为同一个原因没写出来时说「这几段」，同一段拆出来的几块仍是「这一段」；只有真拆小过才补「已拆小重试仍 没写出」（截断后只补剩下的不算）；每段写上列的范围，例如「第 5 段（列名 到 列名，共 33 列）」，窄表写出是哪几列。 - 库：catalog_draft_jobs 加 timeouts、failed_calls、part_columns、notice，catalog_draft_tasks 加 blank_columns、 blank_sample，旧库启动时补列（存量回填 0 和空）。假模型加 hang（头几次调用一直不回，用来模拟超时）。	2026-10-13 20:30:02 +08:00
ThearchyHelios	645064fe47	数据目录重新起草不丢内容；库注释就是名字本身或标识符写法的不当中文名 ... - 合并（merge_notes）只改模型起草这一个来源的「覆盖即删」：模型这次对某一项没给值（留空，或者给的值没通过校验、在 _from_model 里就丢掉了），以前模型起草的项留着，只有给了合格的新值才替换。只有这一轮完整起草过（covered 含 llm）、 而这一项说的列已经不在表结构里（列级的项看列名，业务主键、业务日期看它们指着的列）才删；write_draft 把表结构里的 列名交给合并。注释、外键、命名推断、剖析各自的规矩不变，人工确认、驳回的不动。删除数因此只在真删时才有。 以前整库重跑一次，模型这次没给的几百项全被删掉，有的表覆盖率从八成多掉到五成，表仍记「已完成」。 - 库注释（comment_role）：和表名（列注释和列名）相同（忽略大小写、下划线、连字符、空白，表名带 schema 前缀的也比 不带前缀的），或者是标识符写法（只有字母、数字、下划线、点，不带空格），不当中文名、也不当说明，不记进目录；交给 模型的表结构里照旧有这条注释。以前这种注释短、不带句读就当中文名，库注释的级别又高于模型起草，模型起草的中文名 永远进不了目录。已有目录不另做迁移：起草到那张表时，旧的那条随这一轮的注释删掉，模型起草的中文名就能进来。	2026-10-13 20:30:02 +08:00
ThearchyHelios	4857c578f6	起草的止损和公平：连续 2 段（MODEL_GIVE_UP_AFTER）拆到底仍一项没写出来，这次起草后面的段不再拆小重试，没写出来就直接记下，原因后面补「模型连续 2 段都没写出来，已停止拆小重试，建议更换起草模型」；有一段写出来就恢复拆小。每次起草同时只起草 3 段（MODEL_CONCURRENCY），一段连同拆小、补缺做完再取下一段，宽表的表级那段写完，它的列分段排到最前面一段一段起草；同时在等全进程名额的调用每次起草最多 3 个，几次起草（不同数据源的任务、同步起草）交替排队，后开始的不再等前一个排着的上百段全部调完。实测一直只给空壳的 294 列宽表从 168 次调用降到 81 次，20 张 120 列的宽表一直用完额度从约 900 次降到 122 次	2026-10-13 16:46:52 +08:00
ThearchyHelios	ec6838dc10	起草模型的 SDK 不再自己重试：ModelSpec 加 max_retries，build_chat_model 一直传到 SDK 客户端（Bearer 鉴权换上的 Anthropic 客户端也带上）；数据目录起草建的大、小两个模型都是 max_retries=0，429、5xx、网络错误、超时只由起草引擎按失败原因重试（最多 2 次）。以前 openai、anthropic 的 SDK 各自先重试 2 次，叠在引擎的重试上，一段最多发 9 次请求，报错却写「已重试 2 次」，网关限流时还放大流量。不写 max_retries 的调用照 SDK 默认，配方 AI 起草不动	2026-10-13 16:40:07 +08:00
ThearchyHelios	b988a5ae18	起草引擎和后台任务的几处收紧：提示词要求请写的每一列都列出来（拿不准的字段留空、列不漏），免得模型留空的列再被补问；纯文本那条路的格式示例改用「表类型」「度量类型」占位，不让模型照抄示例值；从正文取 JSON 时依次试多个括号作开头，说明文字里带括号、外面多包一层都认得；用量记在单次调用的时限之外，落库慢了不会把已经回来的调用算成超时；后台任务收尾写库出错只记日志；补上从正文取 JSON、任务开始时模型已用不了（整体 failed）的测试	2026-10-13 15:36:24 +08:00
ThearchyHelios	6b1f63a9dc	数据目录模型起草换成分段、按失败原因处理的引擎（data/catalog_draft.py）：每次最多 4 张表、40 列，窄表按顺序拼段，宽表拆成「表级一段 + 每 40 列一段」，列分段带着表注释和表级起草结果做背景，最后合并照旧逐项校验；思考和输出用完额度、只给空壳时拆成两半再问（最少 5 列、最多 3 层），拆不开的空壳换纯文本问一次，写出来了后面都走纯文本；被截断的 JSON 先捡回已完整的表和列、只补剩下的；缺了的表和列只补缺的、补一次；服务方嫌额度大时退回 8192、结构化输出不支持时改走纯文本，都管到这次起草结束；网络错误、429、5xx、超时退避重试最多 2 次；单次调用 420 秒；全进程最多 3 个调用同时进行；报错写原因和办法（第几段、共几列没写出来、可以只重试这张表）；提示词加上起草要求一段（数据源说明、起草要求、本次说明，规矩在前、冲突以规矩为准）和「思考时不必逐列草拟」；同步起草改用新引擎，写入抽成每张表一结束就能调的 write_draft	2026-10-13 15:19:06 +08:00
ThearchyHelios	b940b27e24	起草模型设置：新增设置组 catalog_draft（接入、模型），点名的接入不存在或已停用时保存回 422；数据目录起草和按配方导入的 AI 起草共用一处取模型（起草模型 > 助手的模型 > 默认接入），取自起草模型时报错照实说起草模型那一项；数据目录起草不再关思考，额度 32768，服务方嫌大时退回 8192（之后都用小额度），单次调用时限 420 秒交给 SDK；配方 AI 起草的额度、思考设置不动	2026-10-13 15:00:38 +08:00
ThearchyHelios	3c51c40e9d	点名的模型接入：发布前检查给每一处配修复，提示指到界面上真能改的地方，复核发现的几处漏查、误查补齐 ... 多数节点（模型调用、Agent、报告撰写、多 Agent 协作、条件分支、结构校验、知识检索）、协作成员和全图默认的接入在检查器里没有下拉框，以前点名的接入坏了只能去设置里建一个同名接入。现在门禁接受接入表（governance.lint_for_publish 的 providers，接口层读好传进来，同数据目录 SQL 检查器），点名接入的问题成了门禁的一部分，自动修复给每一处一条要人选的修复：改用一个启用的接入，或不指定接入；选的接入不提供这一处写着的模型时模型一并去掉。一处一条（修复 id 带字段，复核只认那个字段），协作节点自己的接入和成员的接入各修各的。校验和发布检查的提示按位置写：有下拉框的说「在节点中换一个接入」，别处说「在发布前检查中改用其他接入」；剩下的只有接入问题时交给助手的说明也改成指向这些修复。 复核发现一并修：核查节点自己的开关关着、结构校验不许重试时不再查（执行时根本不取模型，以前会挡住发布）；报告没写裁判配置时查全图默认里的那一份（以前放行，正式运行却全部未裁判）；接入名不是字符串时查助手模型的接口不再 500，设置接口对门控、助手两组的这类值回 422 带字段；助手、表格导入、数据目录起草用的模型点名的接入不存在或已停用时照实说是哪个接入、去哪里改（以前说「尚未配置完成」，停用接入的下一步丢了），删掉两处已走不到的分支。 测试补齐：结构校验让模型修复、知识检索让模型重排、按需裁判各路径的不存在与已停用，助手、定时正式运行、裁判的两种情况，反方审稿节点上点名的接入；修复的候选、应用、拒收和图级默认。	2026-10-06 15:14: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	0df5e7d4af	A2 模型起草一项都没写进去时不再算成功：认出没有 tables 外壳的单个表对象；结构化输出是空壳（只有表名、没有可用字段）时改走纯文本再问一次；某张表最终没有可用内容记 model_error「模型没有给出这张表的可用内容」；起草结果每张表多一个 model_items（模型给了几项可用内容），界面据此区分「和现有目录一致」与「模型没给内容」；「没有变化」改为只说起草出的内容与现有目录一致，另加「目录没有更新」一句；假模型能模拟空壳、单个对象、某条路不可用三种实测回复	2026-10-04 02:19:26 +08:00
ThearchyHelios	c133967bf9	冻结的数据目录有了读取方：证据接口的查询步骤带上表结构快照 id 和这条查询用到的表当时的目录版本，证据面板写「数据目录：订单 第 3 版」；冻结时保留被驳回关系的编号和状态（不放内容），新增按冻结的那份重建 SQL 检查器的 frozen_checker，驳回过的外键关系不会被推回来	2026-10-04 02:00:17 +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	f5e8a436f1	数据目录 F1-B3：计算公式在人工整份提交和模型起草两条路径上也拦下——人工提交里改动过的文字项像公式就整份不收（422，说明公式写进口径卡），模型起草出的公式项丢掉；和对话提案同一套判断。只查改动过的项、不进结构校验：库里已有的含公式的项不会挡住这张表的写入	2026-10-04 01:15:05 +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	fd3ec43662	数据目录 F1-A2：在目录页去掉外键约束、命名推断、数据剖析、模型起草得出的关联关系改为驳回、保留编号，只有人工添加的才真正删除；改了两端的旧关系同样驳回。以前删掉的推断关系下次起草又加回来，关系图按表结构现推也会带回来，照样驱动 SQL 检查和助手挑表。表结构推得出的人工关系（人工改过基数的外键关系）去掉时也只驳回。编辑界面上这类关系不给「删除」只给「驳回」（保存时等同单项驳回，可撤销），检查脚本跟上	2026-10-04 01:07:35 +08:00
ThearchyHelios	0fa498ac18	数据目录 F1-A1：对话提案确认关联关系时不再抹掉基数和覆盖率——覆盖率是剖析测得的，一律沿用；基数没写时沿用已有的，新增的按目标表的主键或唯一约束推算，推算不了留空并在提案这一项上说明（PatchChange.note）。以前剖析测得多对一的关系经提案确认后基数变空，一对多关联后重复计算的检查静默失效	2026-10-04 01:03:32 +08:00
ThearchyHelios	cece781b5a	合入集成分支（阶段 2A 数据剖析、4B 剖析与 SQL 检查界面及修正）到 4A：两边功能都保留 ... 冲突的解法： - 后端 api/catalog.py：同时导入 catalog_impact 和 catalog_profile、SnapshotTampered；data/catalog.py：__all__ 取两边的并集重排。 - 2A 放宽了码值校验（含义可以为空，剖析写进来的是「含义待填写」）：目录修改提案的码值补充改为含义为空的码不覆盖已有含义、 只在原来没有这个码时加进去，补了测试；卡片和过程里的码值把空含义写成「含义待填写」，和目录页同一个说法。 - 前端 types.ts、terms.ts：两边各在同一处追加了新段落，按顺序都留下（提案、影响面、目录版本在前，剖析、码值、SQL 检查在后）， 没有重复的键；client.ts、decode.ts、CatalogPage.tsx、TableDetail.tsx 的导入取并集。 - check-catalog.mjs：影响面和剖析、保存数据源三条假路由都留下，各节和最后核对真库数量的逻辑不变。 - 4A 的测试数据源改用 tests/fixtures/sources.py 的 drop_source 删除，顺带作废连接池。	2026-10-03 12:35:47 +08:00
ThearchyHelios	25e444ca3f	数据目录阶段 4A 术语：服务端上界面的目录校验报错改用界面的叫法，表类型写明细表、度量类型写可累加、关联关系两端写本表字段和目标表，给模型看的说法不变	2026-10-03 12:14:17 +08:00
ThearchyHelios	913ed9d2c4	命名推断认业务前缀、SQL 检查认兄弟关联：表名带业务前缀、列名只写词根时推不出关系，两张表各自指向同一张父表、彼此相连也被当成连错了列——改为直接对不上时按引用表共用的前缀找唯一一张，兄弟关联只提示行数可能成倍	2026-10-03 11:21:03 +08:00
ThearchyHelios	1a760726f7	数据目录阶段 4A：助手协议新增目录修改提案 catalog_patch，服务端核对数据源、表、路径和取值后附版本与改前改后转出、绝不自动写入，新增提案预览与保存接口	2026-10-03 11:19:44 +08:00
ThearchyHelios	b5ec0a5a96	数据剖析的码值与时间列：状态类低基数列取值分布写成码值候选（含义待人填写），被遮罩的列不取；日期类列取最小值和最大值，只有一个日期列时提议为业务日期	2026-10-03 11:01:04 +08:00
ThearchyHelios	fefb708757	数据剖析的关系验证：抽样键值去父表核对覆盖率，父键唯一且覆盖率够的升为有确证（来源记为数据剖析），覆盖率低的保持推断并写明原因，人工确认过的只补覆盖率和基数；撤销审阅回到剖析的结论	2026-10-03 10:56:08 +08:00
ThearchyHelios	f4ee261aec	数据目录阶段 1A：建工具时用单独的会话读目录，查询快照的 meta 解析失败不连累快照落盘	2026-10-03 09:44:45 +08:00
ThearchyHelios	a340d968fa	数据目录阶段 1A：结构化输出报错时退回纯文本起草，关联关系的校验说明补上空格和修改时间的检查	2026-10-03 09:42:48 +08:00