 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 |
|
|
ThearchyHelios
|
6f6798153e
|
数据目录阶段 1A：catalog.py 补齐合并与审阅、注释 / 外键 / 命名推断 / 模型起草、渲染、关系图、使用次数和冻结内容
|
2026-10-03 09:27:25 +08:00 |
|
|
ThearchyHelios
|
bb5a1b43cd
|
数据目录阶段 1A：新增 catalog_notes 表与按表的乐观锁存取，目录只认固定字段、不放公式
|
2026-10-03 09:08:44 +08:00 |
|