 ThearchyHelios
|
d5e9ef39ae
|
SQL 语义复核修正（第 2 轮）：CTE、子查询起的名字不再进比较，条件里的子查询选出来的列名也不算；派生来源按位置编号，编号错开时再按不写编号的写法配一遍
上一轮只去掉了条件里子查询的表别名，子查询整段写进外层条件的 key 时还带着各自起的名字：标量子查询、IN 子查询给选出来的列起的名字（AVG(amount) AS avg_amount），子查询里 FROM 的子查询别名（s 换成 agg），以及外层引用 CTE、FROM 里的子查询算出来的列时的来源名（派生来源的 key 就是别名）。CTE 改个名，外层的 total > 100 就被报成两边各有一个、互相矛盾的条件；双盲复算里盲算的名字本来就是自己起的，会被说成换了口径。
现在派生来源（引用 CTE 的表、FROM / JOIN 里的子查询和 LATERAL 子查询）按位置编号作比较用的 key：从外往里一层一层地编，CTE 在第一次用到的地方编号，写成 CTE 还是 FROM 里的子查询、CTE 定义的先后都不影响；给人看的写法照写名字。不拿里面那段查询的写法作 key：里面差一个条件，外层按它的列写的条件就全跟着变，同一处不同会报好几遍。条件里的子查询写进外层 key 时，引用 CTE 的表、子查询（含 LATERAL）、子查询自带的 CTE 定义都换成编号，只看取值的子查询（IN、EXISTS、标量子查询）去掉选出来的列名；FROM 里的子查询、CTE 定义选出来的列名留着，外层按名字引用它们。LATERAL 的别名原来没登记成来源，按「别名写错了」照写，一并改成派生来源。
编号只看位置：一边多出一个排在前面的 CTE（比如盲算先关联一个筛 VIP 的 CTE），后面的编号就错开了，同名的 CTE 反倒比原来按名字比时多报出两条自相矛盾的话。Part 加 anon（派生来源一律写「@」、不写编号），diff_facets 每个方面先按编号比，比不上的再按 anon 一对一地配，配上的不算不同；比较两边的先后先按 anon 排、分不出再按编号；连接先配完全一样的再按关联的表配，免得错开的两个 CTE 被配成一对、说成关联条件不同。编号对得上时照样分得清是哪个 CTE 的同名列（p.total > r.total 写反成 r.total > p.total 照报）。筛选条件配对改按列的比较写法（Part.column_keys，CTE、子查询的列写「@.列」），CTE 名不同、阈值不同时说成「按 total > 100 筛选，盲算按 total > 200 筛选」，不再拆成两条各说各的。
仍按名字比的只有 CTE、子查询选出来、外层按名字引用的列（一边叫 total、一边叫 sum_amt），写进了模块说明。
|
2026-10-05 02:37:33 +08:00 |
|
|
ThearchyHelios
|
a427b53874
|
SQL 语义复核修正：同一个口径不再因为子查询里的别名、HAVING 里的别名被报成不同；取哪几行逐段比，连同 OFFSET 和取前几行时的排序
条件里套着的子查询（EXISTS、IN (SELECT …)）原来按外层的来源整个照抄进外层那个条件，别名原样留着：带别名和不带别名的同一条 NOT EXISTS 被报成两处筛选不同，双盲复算就会说盲算换了口径。现在每段 SELECT 在语法树上记段号（复制出来的子查询靠它找回原树上那一段算好的来源，相关子查询照样到外层找），改写时每一列按它所在那一段认，子查询里的表去掉别名；比较两边排序时也按那一段的来源排。HAVING 引用 SELECT 别名（HAVING s > 100）换成别名指的表达式，和 GROUP BY 别名一个读法，聚合函数里的同名列不换。
取哪几行原来只看最外层 LIMIT 的行数：CTE 里 LIMIT 10 和 LIMIT 100、OFFSET 0 和 OFFSET 10、取前 10 行时降序和升序都报成没有不同，取到的却是不同的行。Facets 加 limits，逐段收集（最外层、CTE、FROM 里的子查询；条件里的子查询已经整个写在条件里，不单算，免得报两遍）行数、跳过的行数，以及这一段的排序（ORDER BY 1、别名换成 SELECT 里的表达式）；OFFSET 0 算没写，排序只在限了行的段里比。原来的 limit（最外层行数）照旧保留。
|
2026-10-05 01:46:55 +08:00 |
|
|
ThearchyHelios
|
f1c068d6a9
|
核查工具箱收尾：连接的方面补上另一侧（关联条件里出现的别的表，CROSS JOIN 写它之前的来源），双盲复算对照数据目录里的关系时用得上；只读 agent 收尾前先拿到收尾用的模型再预留金额，模型拿不到时不在每日账上白记一次调用；收尾消息的参数改名 limit_words，说清是哪个上限的说法
|
2026-10-05 00:42:02 +08:00 |
|
|
ThearchyHelios
|
031aae9343
|
SQL 语义：data/sql_semantics.py 给双盲复算、运行对比、反方审稿共用。normalize_sql 按方言解析、重新生成（去注释、统一关键字和空白、按方言转换不加引号的名字），再把字符串和数字换成占位符：只改了字面量的两条 SQL 规范文本相同（定时运行每期日期不同，不算模板变了），字面量按规范文本里的先后列出；解析不了退回逐词规范化，照样认得出只改了字面量。facets 把查询拆成表、连接（类型 / 关联进来的表 / ON 条件）、WHERE 合取式、时间条件（列 / 运算符 / 取值）、分组、聚合（函数 / 参数 / 去重）、HAVING、LIMIT：别名换成真实表名，比较两边排好顺序，GROUP BY 1 和别名换成表达式，CTE、子查询逐段收集，只透出一张表的 CTE 换回那张表的列，逗号连接写在 WHERE 里的等式算关联条件，相关子查询到外层找别名；解析不了带 parse_error，从不抛。diff_facets 每处不同给一句中文（「A 按支付时间 paid_at 筛时间，B 按下单时间 created_at」「A 排除了 is_deleted = 1 的行，B 没有」「A 对 order_id 去重计数，B 没去重」），两边叫法可以换成「原流程」「盲算」，列的中文名可以用 catalog_labels 从数据目录取；只换了一张表时说一次「查的是哪张表」，其余按不写表名的写法比。复用 sqlcheck 的 dialect_of、_conjuncts、_bare_column、_unparen
|
2026-10-05 00:22:51 +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
|
0df5e7d4af
|
A2 模型起草一项都没写进去时不再算成功：认出没有 tables 外壳的单个表对象；结构化输出是空壳（只有表名、没有可用字段）时改走纯文本再问一次；某张表最终没有可用内容记 model_error「模型没有给出这张表的可用内容」；起草结果每张表多一个 model_items（模型给了几项可用内容），界面据此区分「和现有目录一致」与「模型没给内容」；「没有变化」改为只说起草出的内容与现有目录一致，另加「目录没有更新」一句；假模型能模拟空壳、单个对象、某条路不可用三种实测回复
|
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
|
c133967bf9
|
冻结的数据目录有了读取方：证据接口的查询步骤带上表结构快照 id 和这条查询用到的表当时的目录版本，证据面板写「数据目录：订单 第 3 版」；冻结时保留被驳回关系的编号和状态（不放内容），新增按冻结的那份重建 SQL 检查器的 frozen_checker，驳回过的外键关系不会被推回来
|
2026-10-04 02:00:17 +08:00 |
|
|
ThearchyHelios
|
0f537a9cad
|
只探查了部分表时，查结构工具不再对没探查到的表说「没有」：说明不在已探查范围、无法判断，并给出查数据字典的办法
|
2026-10-04 01:31:16 +08:00 |
|
|
ThearchyHelios
|
37d2f1d1d4
|
合入完整性修复 F3：Agent 查库的模板也记目录版本并提醒「可能涉及」，只探查了部分表时清单、目录页和助手上下文都说明，升级入口接上 SQL 检查，截断判定和工具节点遍历各收成一处
|
2026-10-04 01:28:59 +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
|
4c7cfa62b2
|
数据目录 F3 一致性：查询结果的截断判定抽成 data/engine.py 的 RowCollector，查询层和合并查询都调它，不再各写一遍
|
2026-10-04 01:08:42 +08:00 |
|
|
ThearchyHelios
|
fd3ec43662
|
数据目录 F1-A2：在目录页去掉外键约束、命名推断、数据剖析、模型起草得出的关联关系改为驳回、保留编号，只有人工添加的才真正删除；改了两端的旧关系同样驳回。以前删掉的推断关系下次起草又加回来，关系图按表结构现推也会带回来，照样驱动 SQL 检查和助手挑表。表结构推得出的人工关系（人工改过基数的外键关系）去掉时也只驳回。编辑界面上这类关系不给「删除」只给「驳回」（保存时等同单项驳回，可撤销），检查脚本跟上
|
2026-10-04 01:07:35 +08:00 |
|
|
ThearchyHelios
|
327c551bdb
|
数据目录 F3 / B1 服务端：SQL 只写在 Agent 里的模板也提醒目录变化——发布记录分直接引用和可能涉及两组，Agent 和协作成员绑定了查询工具的源记下所有有目录的表，正式运行两组都比、每张表标明属于哪一组；只记了直接引用的旧记录照旧按直接引用比；哪些节点算写死的查询统一交给 tool_queries
|
2026-10-04 01:07:15 +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
|
958e096e56
|
数据目录阶段 4A 影响面：新增接口列出引用某张表的已发布和受管模板，区分直接引用和可能涉及、合并查询按输入追溯，表详情和保存纠正后都显示
|
2026-10-03 11:52:49 +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
|
e4898b7402
|
合入数据目录阶段 2A：数据剖析——默认关闭、按源开启，查询次数和时限有上限，抽样核实推断的关联关系并补基数与覆盖率，状态列给出码值候选，遮罩列不取样
|
2026-10-03 11:09:20 +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 |
|
|
ThearchyHelios
|
84bf484c08
|
合入数据目录阶段 2B：基于数据目录的 SQL 检查——七条规则按依据状态定级，接入助手自查、发布门禁和运行时，出错的来源查询使指标降档
# Conflicts:
# backend/app/api/evidence.py
|
2026-10-03 10:37:31 +08:00 |
|
|
ThearchyHelios
|
98ebba384f
|
合入数据目录阶段 3：合并查询节点——跨库按键合并，截断输入拒绝，类型不一致与行数放大告警，证据可下钻到两边原始查询
|
2026-10-03 10:27:16 +08:00 |
|
|
ThearchyHelios
|
8d31164a8b
|
数据目录阶段 2B：助手自查接上 SQL 检查——工具节点里写死的 SQL 查出 error 进修正轮，warning 和 info 留在交付的问题清单
|
2026-10-03 10:19:48 +08:00 |
|
|
ThearchyHelios
|
0e689c1b18
|
数据目录阶段 2B：SQL 检查的七条规则——一对多重复计算、存量跨期求和、关联对不上目录、比率求和、漏筛有效记录、码值不在表里、用错时间列，级别随依据的状态变化
|
2026-10-03 10:16:12 +08:00 |
|
|
ThearchyHelios
|
8ed0bc23f7
|
数据目录阶段 2B：引入 sqlglot，SQL 检查的解析层——按数据源方言解析、认表和别名、解析不了一律跳过
|
2026-10-03 10:15:52 +08:00 |
|
|
ThearchyHelios
|
c6818f12bf
|
合入数据目录阶段 1A：目录存储、接口、外键与命名推断、起草、冻结进快照、db_schema 带目录
|
2026-10-03 09:46:29 +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
|
785660e60d
|
数据目录阶段 1A：db_schema 输出附上数据目录，查询时目录随表结构快照冻结进证据，查询快照记下用到的表供使用次数统计
|
2026-10-03 09:40:16 +08:00 |
|
|
ThearchyHelios
|
8f75849a1c
|
合并查询节点（二）：证据面板展示合并的输入、合并 SQL 和警告，被引用的格沿逐格来历追到输入的那一格并接上输入的查询步骤；推断来源穿过合并下钻到原表格子，追不到的判为没有逐格来历；裁判摘录写明合并的输入并按底层数据源遮罩
|
2026-10-03 09:36:20 +08:00 |
|
|
ThearchyHelios
|
e7646532c1
|
数据目录阶段 1A：探查补读外键和唯一约束（读不到就跳过、不写键），新增 50 张表的合成景区库夹具
|
2026-10-03 09:30:50 +08:00 |
|
|
ThearchyHelios
|
1f8c180703
|
合并查询节点（一）：新增 merge 节点和执行器——几次查询的完整快照落进内存 SQLite 按键合并，结果存成同形的查询快照，截断的输入拒绝、键类型不一致和行数放大给警告，并记下逐格来历
|
2026-10-03 09:27:48 +08:00 |
|
|
ThearchyHelios
|
6f6798153e
|
数据目录阶段 1A：catalog.py 补齐合并与审阅、注释 / 外键 / 命名推断 / 模型起草、渲染、关系图、使用次数和冻结内容
|
2026-10-03 09:27:25 +08:00 |
|
|
ThearchyHelios
|
3e1f8b2591
|
数据目录阶段 0：截断的查询结果整组拿来算的指标标为不完整、出具降档，报告整表带截断说明，恰好取满不再误报截断
|
2026-10-03 09:26:22 +08:00 |
|
|
ThearchyHelios
|
bb5a1b43cd
|
数据目录阶段 1A：新增 catalog_notes 表与按表的乐观锁存取，目录只认固定字段、不放公式
|
2026-10-03 09:08:44 +08:00 |
|