yilunjiang/AgentLab
1
0
Fork 0
mirror of https://github.com/ThearchyHelios/AgentLab.git synced 2026-11-15 04:21:57 +00:00
Code Issues Packages Projects Releases Wiki Activity
1,295 Commits 4 Branches 0 Tags
eddeded2a45e2dbb3b5744bbd40e2a668f8c0ce4
Commit Graph

225 Commits

Author SHA1 Message Date
ThearchyHelios eddeded2a4 全栈安全加固、性能提速与架构演进：连接池与沙箱止血、双路混合检索、多版本归档及前端分包治理 
- 第一批（安全加固与生命周期止血）：隔离测试宿主机密钥与 .env 泄漏；修复 SQLite 取消查询挂死、:memory: 连接池报错与 EngineCache 世代竞态；补齐运行与评测删除时的 Checkpointer 线程、Artifact 磁盘文件与无主附件回收；加固三套沙箱路径越界、进程组清理与 Seatbelt 数据目录隔离，封堵 SSRF IPv4-mapped IPv6 元数据绕过与响应体 OOM；修复推理模型多轮 reasoning_content、结构化输出 Token 漏计与缓存折扣计费
- 第二批（数据库/集群/问数提速与首屏分包）：补齐核心表索引与 SQLite WAL 调优，列表接口按需 defer 大列，收敛启动扫描并打通跨进程 slot 槽位唤醒；优化跨源全局选表、哈希桶数字绑定、流式 CSV 导入及多方言分析算子；剥离首屏静态引入的 @xyflow/react 与全局样式（首屏主包降至 461.59 kB），补充流式 rAF 攒批、Store 精细订阅与表单无障碍绑定
- 第三批（架构演进与工程自动化闭环）：记录库超挂接阈值历史版本自动增量归档至单库多表（解除 SQLite 10 库 ATTACH 硬上限）；重构知识库为词面 BM25 与全集合归一化向量矩阵真·双路独立召回并支持游标分批重建；升级多方言感知 SQL 模板词法分析（E'...' / $$...$$ / q'[...]' / # / 嵌套注释）与 Decimal / bool / NaN 参数校验，消除 ledger 层对 api 路由层的反向依赖；拆分 3101 行 CaliberDrafts 页面为 7 个领域子模块，消除检查脚本本机路径硬编码并新增 GitHub Actions CI 门禁与三批回归测试套件
 2026-11-13 14:51:36 +08:00
ThearchyHelios 09949fc8ac 快速直查通用提速与证据精准绑定：跨网关关闭深度思考、关联维表统计探查与零误报核验 
- 模型接入：支持跨 Anthropic / OpenAI 兼容网关显式关闭深度思考（thinking=off / effort=low），对不识别推理参数的网关自动剥离重发并做进程级记忆
- 快速直查：收敛直查图推理预算（max_steps=4），杜绝长思维链与多轮现场盲探
- 语义指标与预命中：Oracle / PostgreSQL 分组聚合补充 DESC NULLS LAST；基于关系图、逆表频共享键与低基数统计（1..20 distinct）实现零硬编码的通用关联维表发现、分类列抽样及全空分组折叠诊断
- 零延迟数字证据：支持纯数字文本编码（含前导零）无损回绑、多表同行实体键与列序号消歧，结合上下文事实白名单与冲突守卫消除误报并保留防编造拦截
 2026-11-12 14:40:00 +08:00
ThearchyHelios f144ef16d2 独立语义指标库与文档一键拆解：支持多表参数化 SQL 模板、后台进度与 Oracle 方言 
- 新增独立语义指标模型（SemanticMetric）与 metric_query 内置工具，同时支持单表聚合表达式（expression）与跨表 JOIN / CTE 参数化模板（sql_template）
- 新增后台口径文档一键拆解任务（SemanticDecomposeJob），支持实时阶段进度、转后台执行、中途取消，串联知识库红线归档、盲列数据目录补丁、指标试算与标准实体绑定四层资产一键落库
- 完善多数据库方言确定性编译（重点补齐 Oracle 顶层 WITH + ROWNUM 限流、标识符引号规整、DATE 字面量与 TO_CHAR 时间粒度转换）
 2026-11-12 12:58:24 +08:00
ThearchyHelios 8d9a712eae 业务本体与标准实体：跨源键值对齐、对账共变算子、健康证据链与实体助手 
- 新增标准业务实体（CanonicalEntity）模型、确定性跨源编码翻译、后台候选实体扫描与文档驱动实体智能助手
- 新增指标本体图谱（factor / reconciles_with / upstream_driver）、DAG 防环校验以及 ontology_neighbors / source_health 内置工具
- 新增跨源对账（analysis_reconcile）与滞后共变（analysis_cochange）分析算子，打通 [[h:H1]] 数据源健康证据链、报告导出与本体消融评测
- 数据目录新增「标准业务实体」视图与候选审阅工作台，口径页集成指标本体拓扑面板与端到端浏览器检查
 2026-11-12 12:57:53 +08:00
ThearchyHelios 2f90f0eb3a 口径台账：固定执行、验证审阅发布与增量重导入 
- QueryCore 固定执行（K09）：按已发布的不可变口径跑一次，交回类型化标量、发布/manifest 引用与逐查询证据
- 依赖闭包（K08）：按选中的指标算出要拷的取数节点、要的入口字段，接进 derive / compose / metrics
- SQL 模板参数完整性（K01）：试跑、组合问数、派生图、运行时取数共用一套语义，缺参数在渲染前就拒
- 受限字段变更服务（K03）与口径领域边界（K01）：改动打在整图深拷贝上，身份与证据归属不可改
- 版本化受控模板绑定（K04）：业务口径按显式绑定落到 SQL，对不上就报 unsupported / needs_update
- 验证记录（K05）与最小审阅：样例匹配不等于正式批准，审批人只从服务端身份取
- 发布依据清单（K07）：发布时按不可变图物化内容寻址清单，正式用途按它判
- 增量重导入（K11）与 B/L/R 三方合并、受限自然语言修改提案（K12）：只产候选，落图仍走既有写路径
- 接口与前端：口径草稿页接上字段变更、绑定状态、验证与重导入，新增 caliber-drafts / studio 检查脚本

验证：前端 tsc -b 通过。
 2026-11-10 15:05:18 +08:00
ThearchyHelios 9d8b41430e 完善口径管理、主动调查与后台任务，修复通用问题 
- 完善口径编辑、只读试运行、统一质量验证与执行语义指纹
- 增加可执行指标约束、有预算的主动调查和过程评测
- 提取发布检查、证据读取与起草服务，支持任务停止、重试和检查点恢复
- 增加版本传递影响分析，修复并发覆盖、敏感值遮罩、异常评分及页面状态问题
- 修复 SQLite 复合查询追溯和 microVM 可选依赖缺失处理
- 纳入当前设计文档及部署配置调整

验证：相关主回归 3822 项通过，4 项跳过、8 项预期失败；补充回归通过。
前端构建、文案检查及 git diff --check 通过。
全量检查仍有环境权限、PostgreSQL 可选依赖和既有部署配置、SQLite 文件基线差异导致的未通过项。
 2026-11-06 17:14:45 +08:00
ThearchyHelios 753c35918d 复盘修正：试运行不计入统计、评估标签遮罩、规则/评估卡可组合 2026-11-03 21:23:08 +08:00
ThearchyHelios 4bf9e56979 支持评估型指标：rubric 加权评分、等级与 assessed 标签 2026-11-03 20:52:29 +08:00
ThearchyHelios e1d63e7389 规则 DSL 编译成只读 SQL，并用 fixture 验证 2026-11-03 20:50:06 +08:00
ThearchyHelios 6e7f2a5ce8 支持规则型指标：单元格条件确定性求值与 derived 标签 2026-11-03 20:36:04 +08:00
ThearchyHelios 37657e24c3 支持外部常量指标：来源、生效日期、过期降档与 external 标签 2026-11-03 20:32:55 +08:00
ThearchyHelios 174375c6c7 新设遮罩列时清理目录里的码值、含义与备注 2026-11-03 18:53:39 +08:00
ThearchyHelios 90597d5540 口径增加内容指纹：指标集与账本候选记录定义哈希 2026-11-03 18:47:32 +08:00
ThearchyHelios ce2f68a373 口径取数 SQL 增加书写 lint：取整、补 0 在画布提示并在受管发布时拦截 2026-11-03 18:36:26 +08:00
ThearchyHelios 010e74b006 Merge branch 'an/w1' into an1/c 2026-10-21 13:13:04 +08:00
ThearchyHelios 7e6d52004c 分析算子的输入、目录事实、期次与现查：inputs.py（按名字取快照、拆「名字.r行.列」、列名不分大小写、遮罩列与非数值是调用错误）；facts.py（按 SQL 认结果列取自哪张表的哪一列，读目录的度量类型、叫法、业务日期，只有确认过的度量类型才拿来判调用错误；查过的记进 params，复算不读目录）；periods.py（日期、YYYY-MM、YYYY-Www、YYYY-Qn、整数序号，粒度按值推断）；probe.py（make_prober 走 data/coverage 的只读探查：遮罩列不探、总时限、5 分钟缓存、退回剖析事实，另在库里算按运行当天现算的界；Book 先登记、查完再算，结论只记真用到的）；data/coverage.py 加几个公开的小函数（parse_sql、as_day、literal_bound、window_of、column_range、bound_values、facts_range），_fallback 的读法抽成 _facts_range、行为不变；契约补几项可选字段（InputSnapshot 的 dialect / checks / no_data / mask_columns / masked_at_query，AnalysisInput 的 dialect，Probe 的 expr / value） 2026-10-21 13:03:35 +08:00
ThearchyHelios 3009a43cee 分析能力入口（三）：分析卡（节点类型 analysis，和口径卡平级，engine/nodes/analysis.py）。配置 items: [{id, op, mode, from, params, hypothesis}] 和阈值覆盖 overrides；画图时校验（schema.analysis_issues，执行前同一套再过一遍）：至少一项、标识合法且不重复、分析方法和模式是契约里的、输入（from，或两份查询的 base_query / target_query，总数两格落在的节点）指向上游的调用工具 / 合并查询节点（Agent、不产出查询的节点、不在上游的报错，调用别的工具的只提醒）、参数和 agent 工具同一份定义且不能写阈值、下钻指向同卡排在前面的变化拆解、阈值覆盖按 contract.settings_problem。执行照合并查询的做法从 state.nodes 取上游的查询快照 id、复验哈希，只认台账里 kind query 的快照，遮罩列同证据面板；参数里的 {{ }} 先渲染；阈值是缺省 ← 发起时的快照 ← 卡上的覆盖；每项的结论落成工件、台账记一条带 item 的 kind analysis、发一条 analysis.end；产出 nodes.<卡>.results.<项> = {status, verdict, direction, values, phrase, artifact}，条件分支能按判定走、成果能取判定语。一项算不了照实记（analysis_refused），不让卡失败；调用写错让卡失败并说清是哪一项、怎么改。登记：事件 analysis.end、叫法「分析卡」「分析项」「阈值覆盖」和分析方法、模式的叫法，编译器，治理（分析卡算可追溯的节点；受管级别分析卡的输入要是数据库查询或合并查询 governed.analysis_input，画布那条同义的提醒不再重复列；口径卡读分析卡的结果给提示 governed.caliber_analysis_input，输入按 via analysis 记、追不到原始数据），升级提醒的证据类节点，变量表（每项的结论、对上游节点的引用），数据目录影响面（同合并查询经由输入），助手查看的工作流说明，两条新编号的白话 2026-10-21 13:03:00 +08:00
ThearchyHelios 2714890d0d 文档重新梳理：README 精简成介绍和索引，细节按主题拆进 docs/zh-CN 与 docs/en（17 篇一一对应），英文文档不含中文 
README.zh-CN.md / README.md 只留：这是什么、为什么用它、主要功能（按领域一行一条，链到文档）、快速开始、部署、文档索引、
开发与测试、许可（原文不动）。原来的每一节按读者和任务分到 17 篇主题文档：ask-data、workflows、evidence、
data-sources（新增：接入数据库、只读保证、上传表格、跨库合并、遮罩列）、data-catalog、tools（新增：工具、审批档位、
能力登记、端点、网络规则——它们管所有工作流，不只应用）、apps、evaluation-and-ledger、schedules（含通知）、deployment、
configuration、postgresql-and-scaling、identity-and-security、architecture、development、upgrade-notes（按时间倒序，
每波先写要做的事）、faq。删掉的只有模块名（api/copilot_gen.py、chat/drive.py、data/schema_view.py）、重复的话和
「以前…现在…」的叙述；操作步骤、命令、配置名、限制、权限边界都有归宿。中文是原文，英文按新的中文写；英文里界面文字
只写英文名，开头注明界面目前只有简体中文，中文占位符换成英文占位符，中文数字的例子改成不依赖中文的说法。
数据剖析可以同时剖析 2–3 张表（baf23998）收进 data-catalog。
新增 scripts/check-docs.py：英文文档（README.md、docs/en/**）不许有中日韩字符和全角符号（代码块也算），
README、docs/**、deploy/README.md 的相对链接和锚点都要通，docs/zh-CN 与 docs/en 文件一一对应、标题层级相同。
中文提示里指向 README 章节的地方改指新文档：cluster/guard.py、cluster/version.py、db/base.py 两处报错，
data/schema_view.py 文档串，.env.example 三处，scripts/prod.sh、scripts/test-postgres.sh，terms.ts 两处、
DataSourcesTab.tsx、check-manage.mjs 注释，deploy/README.md 三处链接。deploy/agentlab.env 未动。
验收：check-docs 0 问题（英文文档 18 个 0 处中文，相对链接 369 条 0 断链，18 对标题层级一致）；相关后端测试
117 通过、7 跳过；tsc -b、check-copy 通过。
 2026-10-21 10:23:26 +08:00
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 9e1ff11278 交叉表支持按文字导入的指标（如「高峰时段」一行写着「18-19」），堵上占位符陷阱：配方的 measures 分段加 text_measures（标签 → text / hour_range），落成文字列（时段存规范写法），空格、公式、占位符照块的取值规则，数字、日期、解析不了的时段报 value_not_text / value_not_hour_range；规则起草遇到无标题指标块里整行是文字的行（标签不带词表单位）按文字指标起草，并出卡片和问题要人确认（「不是」就去掉，回到按数字导入、试运行拒收），确认清单加 text_measure 项，前后对照报类型和存法变化；数值区不合格的格一行合成一条起草失败（不再一行 30 条）。陷阱：以前照「请添加占位符」把「18-19」加成占位符，整格静默存成空值、干跑照样通过——静态校验拒收含数字的占位符（placeholder_digits，重放和沿用现行配方的放行），value_not_number 的下一步按格子情况写：整行文字的提示改「指标类型」并给修复按钮 declare_text_measure，含数字的不再提示加占位符；标签带单位的拒按文字导入（text_measure_unit），文字列不能写单位（unit_on_text）。配方面板每个指标多一个「指标类型」下拉（数字 / 时段 / 文字）。默认值不进规范形式，已存配方的哈希不变。测试 tests/test_recipe_text_measures.py（合成夹具，假名）；check-manage 加指标类型三项 2026-10-20 11:41:28 +08:00
ThearchyHelios 680ea4ecf8 覆盖检查：现查没成功（大表全表 MIN / MAX 超时、库一时连不上）也记 LIVE_TTL_S，期间同一张表直接退回剖析、取值观察，不再每次白等 PROBE_TIMEOUT_S 秒（测试 test_a_failed_probe_is_not_retried_for_a_while）；方言容器集成测试（scripts/dialect_it.py）加一段覆盖检查：只存当天的滚动表（DATE 列，MySQL / MariaDB 另有按文字 'YYYYMMDD' 存的），按运行当天现算的上周区间判成没有数据、区间包含当天只是别的条件筛空的不报，查询后和助手自查两个入口都核——PostgreSQL 16、MySQL 8.4、MariaDB 11、Oracle Free 23 全过 2026-10-20 10:58:20 +08:00
ThearchyHelios b0556e36d6 覆盖检查现查到的表的范围在进程里记 5 分钟（按数据源、上传表格的快照、表、列认）：一张图里几个取数节点、助手自查几轮查同一张表，不再每次全表 MIN / MAX；查不成的、退回剖析的不记，过期了重新现查 2026-10-20 10:40:57 +08:00
ThearchyHelios f87b07694d 助手搭图时就发现「查的区间里表里没有数据」：自查（GraphChecker）对工具节点写死的 SQL 按今天跑一遍覆盖检查（data/coverage.sql_gaps：不跑原 SQL，只跑算界和现查范围的两条小查询，SQL 里所有带时间谓词的表都查，按表去重、限时，异步查库，带模板的 SQL 不查）；完全不重叠的作为一条 sql_no_data 问题交回模型改一轮（换有这段数据的表，没有就在 done 的说明里照实告诉用户数据只到哪天），修正后仍在的不挡运行，作为提醒留在检查结果和交付的问题清单里（问数据流式、画布非流式都是）。look / db_schema 的剖析信息在日期范围最早和最晚是同一天时加一句「剖析时这张表的 X 只有一天的数据，可能每天整表重灌：算历史周期请换有历史的表」；助手节点手册写明按周期取数前先看表的日期范围，只有一天、最新日期早于要查的区间的表不能用来算这段时间 2026-10-20 10:38:30 +08:00
ThearchyHelios 8ba95c0252 查询区间里这张表没有数据时，查询结果里照实说（新增 data/coverage.py，接在数据源查询工具上）：结果里有整列是 0 或空的数值列时，把 SQL 收窄到算出这一列的那一项（去掉别的选择项、分组、HAVING、排序、取行数，只分析不执行），认出它用到的实表和时间谓词；界是字面量的直接解析，按运行当天现算的（不含列的表达式）用同一个数据源跑一条 SELECT 界1, 界2…（Oracle 加 FROM DUAL）算出来；这一列在表里的实际范围现查 SELECT MIN(列), MAX(列)（每条 10 秒），超时或失败退回剖析、取值观察记下的范围并照实标「按 X 日的剖析」，都没有就不判。日期按常见写法归一（DATE / DATETIME、'YYYY-MM-DD'、'YYYYMMDD'、8 位整数），文本列对文本界写法要一样，认不出就不判；区间和范围完全不重叠才算没有数据，一列用到几段区间时每段都不重叠才算。探查走同一道只读守卫，遮罩列不探查不报值，总耗时有上限，出错不影响查询本身。结果和快照多一项 no_data（columns、table、column、window、data_range、basis、message），运行事件记一条 query_no_data；没查出问题不加这个键，快照和以前一字不差。可验证报告认得这个键 2026-10-20 10:28:49 +08:00
ThearchyHelios 4e3623885b 合入 W2-a 的复核修复（nr8/a：导入的 NOT NULL 补值与孤儿行、收尾 dispose、sslmode 换算、PostgreSQL 写入去 NUL、不分大小写搜索 contains_ci、json_eq 两库同语义、JSON 守卫、用户可见列表补决胜键、bubblewrap --clearenv、部署脚本与原子写的几处、README 连接数预算） 
# Conflicts:
#	backend/app/api/schedules.py
#	backend/app/main.py
 2026-10-19 12:21:38 +08:00
ThearchyHelios 0d9f1d9339 用户看得到的列表补决胜键（复核 R-a9）：按名称、时间等可能并列的排序后面补上同一个模型的 id，并列时两种库排出来一样 
- 实测 /api/evals/calibers、/api/schedules/trigger-options 按 Workflow.name 排序遇同名并列时 SQLite、PostgreSQL 顺序不同。用 AST 逐个过了一遍 order_by：最后一个排序键是 created_at / updated_at / last_active_at / at / name / 各种 *_at 之类、不唯一的列，又不带 DISTINCT、GROUP BY 的，补「, 模型.id」（降序补 id.desc()），共 104 处，分布在 api、apps、auth、blueprints、chat、data、engine、eval、ledger、look、memory、process、providers、scheduler（runs.py 里的三处在上一个提交里）
- 按唯一列（seq、version、唯一的 name）排的不动；按聚合、coalesce 之类表达式排的说明见 db/postgres
 2026-10-19 12:07:06 +08:00
ThearchyHelios 7febf2bcdb 两种库行为再对齐一轮（复核 NUL、R-a4、R-a6、R-a7、R-a10） 
- 编排者的决定：PostgreSQL 下文本列写入时去掉 NUL 字符（before_cursor_execute 钩子，只装在应用库引擎上，看所有字符串参数，没有 NUL 的原样交回），SQLite 不变；同 JSON 列的处理
- R-a4 应用库地址里的 sslmode= 换成 asyncpg 的 ssl=（取值同一套），sslrootcert 等证书参数、application_name 这类 asyncpg 不收的参数启动时就报错并说怎么写（证书用 PGSSLROOTCERT 等环境变量）；断点库连接串换回 sslmode=
- R-a6 不分大小写的搜索换成 db/portable.contains_ci：SQLite 上同 ilike（lower LIKE lower），PostgreSQL 上模式带 COLLATE "default"（列是 COLLATE "C"，列上的 ILIKE 只认 ASCII，É/é、Ж/ж、全角Ａ/ａ 匹配不上）；运行列表按名字、对象索引按注释两处都改；改正 db/postgres 里那句说明
- R-a7 JSON 守卫改成编译层：tests/jsonguard 挂在应用库编译器上（conftest，两种库、跑全量时一直生效），整个 JSON 值出现在 = / != / IN / IS DISTINCT FROM / 大小比较、SELECT DISTINCT、GROUP BY、ORDER BY、UNION（去重的几种）里就报错；按类型认，变量别名、跨行 order_by、select(Run.origin).distinct()、JSON 下标的比较都抓得到，测试拿这些反例证明，json_eq、IS NULL、UNION ALL 不受影响。原来的逐行正则测试删掉
- R-a10 json_eq 两种库同一语义、按 JSON 类型比：字符串只等于字符串，数只等于数（1 等于 1.0），True / False 只等于 JSON 的 true / false（SQLite 上用 json_type 分开，以前 1 能匹配 true）；非标量 TypeError。json_text 两种库都是「字符串取本身、别的取 JSON 写法」（SQLite 上同 PostgreSQL 的 ->>），数 1 的 json_text 两边都是 '1'
- db/postgres 说明里写清 NULL 排序补写的范围（只认直接按列排的）
 2026-10-19 12:06:31 +08:00
ThearchyHelios ae254b052e 合入遗留收口分支 nr8/l 的复核修复（变化记录先占住那一行再读改写、召回里行序不定的指标、事件触发列表按任务各取上限、选对象按名字查用 ilike、子工作流写入认旧键、几处测试的竞态） 
# Conflicts:
#	backend/app/ledger/recall.py
 2026-10-19 12:05:19 +08:00
ThearchyHelios 1acf960312 多进程端到端验收：scripts/test-multiprocess.sh 用本机 postgres:16 起临时库，tests/test_multiprocess_e2e.py（缺省跳过，AGENTLAB_MULTIPROCESS_E2E=1）在上面起两个 uvicorn 工作进程，用演示模型跑七个场景——两个进程都登记、一个当班；运行由接到请求的进程认领，另一个进程上的流收得到实时事件和流式增量，同一个审批决定同时发给两边只执行一次，两边事件流不重不漏、封存核对得上；跨进程停止；定时只触发一次；全站一个名额时评测的作答运行排着队，后来的问数据运行先拿到名额；两个进程同时记同一本每日账不越过上限；强杀一个进程后在跑的运行被照实标中断、停在审批上的照常在另一个进程上批完、当班交接。顺带修：等名额时被停止也照实收成已取消（以前停在排队中）；当班的本地余量不超过租约的四分之一（租约调短时一直不当班）；启动清理上传半成品时没有别的活着的进程就全清；文件锁守卫的几项测试只在 SQLite 跑；问数据事件日志清理那一拍不带时刻时按现在算 2026-10-19 12:03:35 +08:00
ThearchyHelios c768c56fd7 多进程协调补齐几处：执行时长从拿到名额算起（排队等名额不算执行，墙钟本来就从开始执行算）；蓝图留痕、蓝图助手开轮先占住那一行再取最大值往下接；问数据等别的进程接着跑的运行时回库里等封存；按配方导入的 AI 起草、知识库重建索引另取跨进程的锁（多进程时重建进度记在设置表里，别的进程读得到、属主不在了照实说没做完）；调度循环一拍的间隔可配（AGENTLAB_SCHEDULER_TICK_S） 2026-10-19 11:51:29 +08:00
ThearchyHelios 4ffd9ad431 变化记录的 affects 先占住那一行再读改写（复核 L5）：口径试算记没试算的那几版（ledger/recall._probe_skipped）和探查刷新影响面（data/source_changes.record）以前都是先读再整份写，交错时互相盖掉。现在两处都先发一句按条件的 UPDATE（record 顺手记又见到一次，SQLite 上拿到写锁、PostgreSQL 上锁住这一行），再读出来改。补并发测试（六版口径同时记、探查同时刷新，一条不丢） 2026-10-19 11:48:43 +08:00
ThearchyHelios 87f0d62f9b 多进程协调（W2-b）第一步：新增 app/cluster——工作进程在库里登记、心跳续租约（属主随进程，进程没了它认领的行一起到期），调度当班的租约，发给属主进程的停止 / 记事件请求，PostgreSQL 的 LISTEN/NOTIFY 叫醒，跨进程的互斥锁（咨询锁），SQLite 单进程守卫（第二个进程拒绝启动）；运行、问数据一轮、起草 / 剖析 / 探查 / 评测 / 影子起草、文档、发布单记 owner，启动整理改成只接手属主不在了的行，当班进程隔一会儿再接手一次；运行的并发名额改成库里按交互 / 应用 / 定时 / 系统四类发（各有全站上限和优先级，设置里可调），替掉进程内的信号量；同源队记在库里；运行停止、记事件跨进程交给属主；运行事件、问数据事件跨进程转发（库里按 seq 追，不落库的流式增量和保活心跳只转给在看的进程）；每日花费账先占住那一行再读写；访问密钥限流、登录失败计数在 PostgreSQL 时记在库里；登录设置、对外地址、向量模型、能力快照、数据源连接池、应用页面缓存跨进程失效；上传版本库、记录表、按需探查、出具、召回、补算、按需视图、个人刷新、定时发起的锁换成跨进程的锁 2026-10-19 11:40:33 +08:00
ThearchyHelios 9a0d87aa6e 合入遗留收口分支 nr8/l（问数据心跳不落库与事件日志清理、续跑重新核对身份、事件触发批量查询与去抖边界、子图编号与驳回出口等），W2-b 在此之上做多进程协调 2026-10-19 10:46:34 +08:00
ThearchyHelios 2d108d116f 表结构变了之后口径凑不齐参数时照实记下：以前不试算、也不记日志，一声不响地跳过。现在记一条日志写缺哪几个参数（必填、没给值也没有缺省值的入口字段）和参数本来从哪来，同时写进变化记录的 affects.probes（同一版只记一条），变化页的「影响」一块写「「x」v3：缺少参数 start、end，没有试算」；同一条变化再被探查到时这份记录不丢。变化接口给的 affects 缺的几项补上空的 2026-10-19 10:10:38 +08:00
ThearchyHelios f63d037b2c PostgreSQL 上和 SQLite 一致的两处：知识库统计的 sum 转成整数（PostgreSQL 的 sum 交回 numeric，驱动给 Decimal）；对象索引按注释搜索不分大小写（SQLite 的 LIKE 对 ASCII 本来就不分，PostgreSQL 分，改用 icontains） 2026-10-19 10:01:20 +08:00
ThearchyHelios aee237f457 按行号取多行查询里的一格，重跑、核对时行序不定的照实标出来：sql_semantics.ordered / row_stable 认这一行重跑时还是不是同一行（最外层带 ORDER BY 的按位置认，一定只出一行的第 0 行认得住，别的行序不定）。口径账本的比对记下 ordered、one_row，指标标签按「同一行」认来自口径只在行认得住时成立，行序不定的标相关、写明原因；口径召回里两版都按行号取一格、查询又没有 ORDER BY 的指标记行序不定（changed 为空），召回待办上写「行序不定」，不按位置硬比；对账的多行对齐每一组先核对那一行的维度就是它，重跑时缺了一行、多出一行错位的记空值，不拿别的维度的数冒充 2026-10-19 10:01:05 +08:00
ThearchyHelios 2e7d6103ea 应用库可移植到 PostgreSQL：AGENTLAB_DATABASE_URL 设成 postgresql+asyncpg://… 时整个应用库用 PostgreSQL，断点用官方的 langgraph-checkpoint-postgres（同一个库，AGENTLAB_CHECKPOINT_URL 可另给）；不设时照旧是数据目录里的 SQLite，行为不变 
- 配置：database_url、checkpoint_url（启动时校验写法，只认 PostgreSQL）、连接池四项；启动日志写用的是哪种库（主机、库名、用户，不写密码）
- 引擎（db/base.make_engine）：SQLite 照旧 WAL、外键、忙等；PostgreSQL 用连接池、探活、会话时区 UTC，装上方言调整（db/postgres.py）：建表时 String(n) 是不限长的 VARCHAR（SQLite 从不查长度，导过来的存量也可能超长）、ORDER BY 里可空列的 NULL 位置照 SQLite 补写（升序在前、降序在后，窗口函数里同样）；Integer 列在 PostgreSQL 上是 BIGINT（列挂到表上时换成 with_variant，绑定参数跟着列按 BIGINT 转换）；JSON 列两边都存原文（PostgreSQL 的 json，不用 JSONB：JSONB 重排对象里的键，快照的列序、表的先后读回来就变了）；JSON 里的 NaN 写成 null、NUL 去掉（PostgreSQL 不收）
- 迁移按方言：已有的列和索引用 inspector 认；PostgreSQL 上补列的类型取模型里这一列的、缺省值取迁移表里的（布尔 0/1 换成 false/true），ADD COLUMN IF NOT EXISTS；去重语句里的布尔按方言写；部分唯一索引补 postgresql_where；init_db 在 PostgreSQL 上拿咨询锁（几个进程同时启动不撞）
- 应用库上的 SQLite 专用写法改成按方言编译的表达式（db/portable.py）：json_extract 的十几处（口径召回、出具、对账、个人应用、幂等键、访问控制、数据源变化通知、剖析任务、待办超时）换成 json_eq / json_flag / json_text，json_type 换成 json_is_string（两种库同一套带类型的比较）；能力登记的 sqlite insert 换成按会话方言的 insert_ignore；能力使用次数的 json_each 按方言分支；附件「没绑记录」的条件不靠 json 的等号；按报错文字认唯一约束的地方换成 unique_violation（按表和列认，两种库的报错都认得）
- 断点（engine/checkpoints.py）：PostgreSQL 时开 psycopg 连接池、在咨询锁里 setup；runner 只认 BaseCheckpointSaver，读断点仍只走 saver 的公开接口
- 依赖：新 extra postgres（asyncpg、psycopg[binary] 3、psycopg-pool、langgraph-checkpoint-postgres 3.1.2）；langgraph-checkpoint 卡在 <4.3（断点格式就在这个包里，postgres 包新版要 4.3，不动已装的 4.2.0）；锁文件补上新包
- 运行收尾：记 action.unknown、安排核实做完才把运行摘掉（以前先摘掉，等「不在跑了」再读事件的一方在库慢时读不到这一条）
- 测试：AGENTLAB_TEST_DATABASE_URL 时跑在 PostgreSQL 上（每个 xdist 进程建自己的库、按事件循环分的连接池 tests/pgpool.py），不设时盖掉环境里的数据库地址照旧用 SQLite；scripts/test-postgres.sh 起临时的 postgres:16 容器跑全量；sqlite_only 标记；另开连接改库的几个竞态测试、触发器测试改成两种库都能跑（tests/appdb.py）；新增 test_db_portable 守着方言调整、JSON 键序、超长字符串、大整数、NULL 排序、时区、PostgreSQL 老库迁移
 2026-10-19 09:52:09 +08:00
ThearchyHelios 0ca8243587 数据源的探查范围、定时维护不再被拼进连接串：data/engine._NON_DRIVER_OPTIONS 补上 introspect_scope、catalog_maintenance。以前漏在名单外，设过探查范围（运行时按需把范围外的表加进来时也会自动写）或定时维护的 MySQL / PostgreSQL / Oracle 数据源，驱动 connect() 收到不认识的关键字参数，每一条查询都失败；加守卫测试，把 app/data 下所有 *_OPTION 常量扫出来逐个核对都不进连接串 2026-10-19 08:08:51 +08:00
ThearchyHelios a1ab3247f9 数据事件触发（后端）：待派发事件表、调度循环派发与去抖、防环、{{ event.* }} 模板变量、接口收 trigger_kind / trigger 
做了什么：
- 新表 trigger_events（待派发事件）、trigger_deliveries（一个事件派给一个定时任务、等去抖），放在 db/models_triggers.py，
  models.py 末尾整模块导入。事件在发生处、和那件事同一个事务里写一行：上传表格按期累积的新一期启用（table_versions 的
  publish_build / publish_snapshot 切指针那一下，移除、作废、回滚不算）、正式运行成功收尾（runner._finalize 写终态的事务里
  加两行调用 outbox.stage_run_finished）、探查 / 剖析新记了要处理的变化（source_changes.notify_after_job，一个任务一条）。
  发生处不发起运行：事务边界、重复与重启都在派发这边说清，也为第 2 波多进程做准备（认领靠条件 UPDATE）。
- scheduler/outbox.py：调度循环每一拍（fire_due 之后）派发：pending 事件条件 UPDATE 认领成 routed，同一事务里给合条件、启用着的
  事件触发任务写 delivery；窗口从最早一条的发生时刻起算 debounce_s（缺省 60 秒），过了就合成一次触发，内容取最新的那条，
  fire_at 取窗口结束的时刻（同一窗口永远同一个时刻，触发记录唯一约束兜住重复派发）；照 fire_once 发起正式运行，ScheduleFire
  kind=event、inputs 写 {event: 事件说明, inputs: 渲染出的输入}；上一次没结束记 skipped_overlap；派发太晚（超出补发宽限）
  记 skipped_misfire；任务停用、改了触发条件时等着的标 dropped。AGENTLAB_SCHEDULER 关着时没有这一拍，事件留着，接口照实说。
- scheduler/triggers.py：三种事件的触发条件（table.version 可选只认新增的一期；workflow.finished 可选只认某个应用 / 某种来源；
  source.changed）、核对对象（表格是按期累积的上传表格、上游工作流已发布、应用在）、说法、{{ event.* }} 变量（table、version、
  period、activated_at；workflow_id、run_id、outputs.<字段>；source、counts）、示例事件（预览、立即运行用对象最近一次真实的事件）、
  防环：保存时查 workflow.finished 串成的环（停用的也算，A→B→A、自己触发自己都拒，422 写出经过的工作流），运行时按 origin 里的
  触发深度兜底（超过 5 层记未能发起）。
- service：fire_once / _fire_workflow 接事件（模板按事件种类校验、渲染 {{ event.* }}，运行来源 origin.trigger 带种类、对象、
  事件 id、深度、经过的运行和一句说法）；check_template / render_inputs / variables 加可选的 event 参数，cron 任务一字不变。
- api/schedules.py：收 trigger_kind（cron 缺省）/ trigger，event 时目标只能是工作流、cron 存空串、下一次触发为空；返回带
  trigger_kind、trigger、trigger_text（也是 description_text）、trigger_state（几条事件在等、去抖到何时、调度开没开）；触发
  历史带 event；预览按示例事件渲染；变量清单按事件种类给；新增 GET /api/schedules/trigger-options（各事件能选的对象及不能选的
  原因、来源、应用，界面不自己判）；立即运行按示例事件发起；触发方式建好之后不能改。Webhook 照旧可配，通知写「事件触发」那一行。
- 应用页印章的来源（apps/resolve._from_text）照实写「由事件触发：…」。

为什么：总方案 §4 已拍板接这三种事件、不接口径发布，一套定时机制（X4）；派发放在调度循环里而不是发生处，事务和重复都说得清。

测试：test_schedule_events.py（三种事件各触发一次、去抖合并与窗口外另起、重叠跳过、停用 / 改条件丢弃、调度关着时事件留着、
超出宽限、触发链深度与上限、模板校验与渲染、期次写法、通知、印章）、test_schedule_events_api.py（建、核对、防环、改、预览、
变量、立即运行、触发状态、可选对象）；test_schedules_api.py 的约定键集合补上新加的几项。
 2026-10-18 15:53:08 +08:00
ThearchyHelios 9627953445 差异说明认得一边套了 ROUND：说「X 套了 ROUND(…, 2)：保留 2 位小数，另一边没有取整」，只陈述写法、不断言值不同，判等价照旧不等价；零售样例题集的期望 SQL 去掉 ROUND(…, 2)（取整交给展示，评分本来按容差比数），评测逐题比 SQL 不再因为期望里的取整一律对不上 2026-10-17 13:31:25 +08:00
ThearchyHelios 39b89fd36b 差异说明在投影之后也说得清：COALESCE 套聚合、按当天现算的日期、取不到参数 
逐格投影之后两边只剩一列，差别常常就在这一列的写法上，以前照样整段兜底。只改说明，判定一个不变（这几种本来就不等价）：

- _Explainer._coalesced：同一位置上一边是 COALESCE(聚合, 常量)（IFNULL 也读成它）、另一边就是那个聚合，说「这次的销售额
  套了 COALESCE(…, 0)：没有符合条件的行、或者 amount 都为空时这次是 0、口径是空」；参数那一列表结构里一定不为空时只说
  「没有符合条件的行时」；分组时说「某一组的 amount 都为空时」，参数一定不为空时两边一样、不说。只认会得出空值的
  SUM / AVG / MIN / MAX，COUNT 套 COALESCE 两边其实一样，不说成不同。列名从原文取（规范形式去掉了外层别名）。
- _Explainer._relative：同一列上一边按运行当天现算（CURRENT_DATE、now()、SQLite 的 date('now', …)，_now_based）、另一边写定
  的常量，说「这次对 paid_date 的条件是 …，按运行当天现算（换一天运行，范围随之改变）；口径写定的是 …」，要求同 _rewrites。
- match_template：口径有入口字段取不到值、又没有缺省值时，以前拿空值渲染出「paid_date >= ''」去比，说明里就出现不存在的
  写法；改成一律说取不到参数，这次在那里写的是现算日期的逐个说清（_now_slots 按列和比较的方向认，只是说明）。解析不了的
  照旧只说解析不了。评测逐题比 SQL 用的是同一个函数，跟着说得清。

测试：tests/test_ledger_cells.py 新增三条（COALESCE 那一格仍然不等价、说明先说多查了几列再说 COALESCE；在虚构库上没有行时
两边确实不同，COUNT 套 COALESCE 不说成不同；按当天现算的日期逐格比时说清取不到参数、和写定日期的 SQL 直接比时说清一边现算
一边写定）。去掉这三处再跑，三条失败；判等价的语料和执行守门照旧全过。
 2026-10-17 13:09:55 +08:00
ThearchyHelios 271bc6e782 口径标签逐格判：引用了好几列的查询，每个数按它自己那一格标 
真实模型下问「上周的销售额是多少」，助手写 SUM(amount) AS 销售额, COUNT(*) AS 订单数, MIN / MAX(paid_date) AS 区间首日 /
末日，报告四列都引用了，口径「周销售」只取 SUM(amount)。按「全部引用列」投影后还是 4 列，对不上口径的 1 列，整条比、
四个数都标相关口径，说明整段兜底。

- ledger/match._cells / _cell（algo 4）：整条（含按全部引用列投影）没证明、又引用了这条查询两列以上的，被引用的每一列单独
  投影到那一列，和每份口径的每个指标读的那一列（card_reads；口径版本没有口径卡的按取数的每一列）逐个比，仍只走
  match_template / explain_sql_diff，上次的投影规则照用：投影不了（分组列、DISTINCT……）、过了时限、不可比的格照用整条
  查询的那一个候选。结果记在 queries[].cells {列名: {status, candidates}}，另记 one_row（sql_semantics.one_row：不分组的
  聚合，一定只出一行）。整条这一层的结论、候选一字不改；老工件没有 cells，照旧按整条读。
- ledger/labels：单元格按它那一格的结论标（_view）；指标用了同一条查询的好几格时，只有那条查询一定只出一行才把逐格的
  结论合起来用（多行的结果里每一列各自对得上，不等于每一行的几列一起对得上）。整题照拍板 L1 不变：每个数都证明来自
  同一份口径才等价；一格证明了、别的格只是相关的整题不等价，原因写「有的数和相关口径不一致，不来自口径」（以前一律说
  「这次的推理」）。出具入口照 ledger/issue 现有判法只在整题等价时给，没有放宽。
- 逐格证明了的口径各处都算上（labels.candidates_of）：工件 meta 的 calibers（召回按旧版本反查）、ledger/uses 的使用记录、
  召回时找原答案对应的那一格、E4；E1 另数各种结论各几格（cells），E2 的兜底比例按标签上给人看的那一份说明数。
- GET /runs/{id}/ledger 的 queries 带上逐格的 cells（遮罩同候选）；证据片段的 ledger 键、轮次摘要的计数本来就按每个数的
  标签，数据变了、形状不变。前端只补类型；check-ledger 加一段：同一条查询一格来自口径（正文挂小标记）、一格相关（差在哪
  先说多查了几列），整题不等价不给出具。
- 评测逐题比 SQL（eval/score.sql_match）取和期望配上的那一格（score.matched_cells：评分时配上的格），没给时取逐格证明了
  的那一格；结果带 column。runner、rescore 传它。

测试：tests/test_ledger_cells.py（同一条查询一列等价、一列不等价各自标对；两份口径只证明了一份标那一份；口径多个指标按列
配对；指标跨两格只在一行的查询上用逐格结论；分组列、DISTINCT 逐格也不投影；照真实例子造的虚构库真跑一遍：销售额标等价
已证明，订单数、首末日标相关，整题不等价、不给出具、不自动出具，证据片段的 ledger 键一致；评测取配上的那一格）。去掉逐格
再跑，10 条失败；去掉「一行才合起来用」、去掉评测取格，各 1 条失败。
 2026-10-17 13:07:19 +08:00
ThearchyHelios f8d89e780c 合入 nr6/b：评测「期望没有数据」只认数值格和叙述里的数、逐题 E1 比产出答案的那条查询、判错时给配对上的那一格、估不出金额时不写 0、没做完的模型调用也计一次、助手只给思考不给操作时自动重来一次（问数据与评测同一个决定）、目录两种计数照实说、自由形应用入口与岗位显示名；评分规则升到第 2 版 2026-10-17 12:28:04 +08:00
ThearchyHelios d4f1ba8dd4 给评测留一个按引用的列投影的入口（referenced_of），顺手折行、补模块说明 
- ledger/match.referenced_of(sealed)：这次运行封存的报告引用了哪条查询的哪几列，正好是 compare_queries 的 referenced。
  评测逐题比 SQL（eval/score.sql_match，另一组在改）传它，就和账本一样按引用的列投影，不必自己再拼一遍。compute 和它
  共用读指标集的那一段（_card_loader）。
- data/sql_semantics 模块说明的「几处共用这里」补上模板绑定、按引用的列投影、同一个形状三处。
- 本轮几处新代码折到 120 列以内（只换行，不改逻辑）。

测试：tests/test_ledger_projection.py 的整题等价那条另核 referenced_of 交回的就是被引用的那一列。
 2026-10-17 12:22:48 +08:00
ThearchyHelios 72d9d2770c 认证队列的确定性重复按规范形分组：条件换序、AND 两边换位的进同一组 
以前按 normalize_sql 的规范文本分组，WHERE 的条件照原文的先后，同一个形状换了条件顺序就拆成两组，凑不够门槛进不了队。

- sql_semantics.sql_shape：在判等价同一套不认列的规范形式（_light）上把字面量抹成只看类型（字还是数）的占位，再把交换律
  成立的地方按抹掉之后的写法重排——AND / OR 的各项、IN 列表、= / <> / + / * 的两边、比大小的两边（换边时大于小于跟着
  换）；抹掉之后一样的几项按原值排，同一组里字面量的位置对得上。不另写解析器。认不出的（解析不了、sqlglot 会读错的写法、
  字面量对不回 normalize_sql 的）为 None，照旧按规范文本分组（只会分得细）。positions 把规范形里的字面量对回 normalize_sql
  的位置，固化成模板时用。
- ledger/certify：Shape 加 key / canonical / positions；队列按（数据源、规范形）分组，跨轮变了的位置按规范形对齐，再换回
  代表那条的位置；固化时同组的别的运行也按规范形认、按同样的对齐认参数。这一项的 id 按规范形算；以前按规范文本记的
  「不是口径」照样认（组里任何一条的规范文本对得上就算）。

测试：tests/test_ledger_certify.py 新增四条——三种换序写法同一个形状、字面量位置对得上；七种真不同（换列、OR、少条件、
换运算符、数对字、IN 列表、换聚合）不是同一个形状；真跑三轮换序的问数据进同一组、多筛一个地区的不进，固化出两个日期
参数；按旧 id 记的「不是口径」照样生效。把分组改回按文本再跑，换序那条失败。
 2026-10-17 12:09:58 +08:00
ThearchyHelios 78e9b0c6da 目录的「使用次数」和「用过这张表的运行」口径照实写：一个按查询计、一个按运行计 
验收时同一张表「使用 4 次」、「共 3 次运行」对不上，接口说明（GET /catalog/{table}/usage、catalog_review.table_runs）
却写「取法同使用次数」，看着该是同一个数。两者数的确实是同一批查询快照（catalog.query_snapshot_tables），但使用次数按
查询计（同一次运行里查了两次算两次），用过这张表的运行按运行去重，前者可能比后者大——数没错，说明错了。

改了接口说明、table_runs 的说明和 catalog_review 模块说明里那一条，写清两种计法和为什么会不一样；表清单上「使用 N 次」的
悬停说明写明「按查询算」，并点出下面「用过这张表的运行」按运行算（运行列表那边的悬停说明本来就写清了，没动）。

测试：test_catalog_review_queue.py::test_usage_counts_queries_and_the_runs_list_counts_runs（同一次运行查两次：清单 4、
运行 3；接口说明不再写「取法同使用次数」、写明按运行和按查询）。去掉修复回跑失败。
 2026-10-17 11:55:53 +08:00
ThearchyHelios 0488965352 探查范围外、没有注释的表中文需求命不中：照实写进模块说明，加一条测试钉住 
真实模型验收里，范围外又没有注释的表只按英文名检索，中文需求命不中（data/schema_view 的 _outside_text 只放名字、拆出的词、
注释）。先查了有没有现成的英中业务词对照可以给拆出的词补上中文说法：命名推断只拆词、不翻译，catalog.name_words 也一样，仓库
里没有这样一份对照。按约定不临时编一份大词表（编出来的覆盖不全，还会把不相干的表抬上来），改成在模块说明里照实写清这个限制、
影响多大（真库多半有注释，注释照常参与检索；范围内的表另有目录中文名、列名）和怎么绕过去（按英文名点名查看会按需加入，或者
请管理员加进探查范围、补注释或目录中文名）。

测试：test_look_large.py::test_out_of_scope_objects_without_a_comment_match_only_their_english_name 钉住现在的行为
（英文名命中、中文需求命不中没注释的表、有注释的按注释命中），以后接了词表要跟着改。这一项只改说明、不改行为，没有
「去掉修复回跑」。
 2026-10-17 11:53:54 +08:00
ThearchyHelios 12439b5305 差异说明投影之后再说；日期条件写在 LEFT JOIN 的 ON 里的说清楚 
选择的列不同时，差异说明整段退回「两条 SQL 的写法不同，未能归纳成具体差异」（真实验收 E2 的兜底比例 45%）：只差在选择
列表上时一条具体说法都没有；多选的列里有 sqlglot 不认识的函数（SQLite 的 printf 这类）时整段不算简单形状，WHERE 里
真实的差别也不写。

- ledger/match：按引用的列投影过、仍没证明的候选，差在哪用投影之后那次比较的结果；答案多选了列的，在最前面写一句
  「这次多查了 N 列，不影响这个数」（aspect=projection），然后照常说条件、时间、聚合上的不同。E1 的差异类型不数这一句。
- sql_semantics 的 _Explainer._left_on_times：两边来源一样、只差在一个 LEFT JOIN 的 ON 里的时间条件时，说「这次用 LEFT
  JOIN 关联 orders 表时只关联 … 的行，口径没有这个条件」「…时对 paid_at 的条件是 …，口径是 …」「…时按 paid_at 筛时间，
  口径按 created_at」。说得准才说：差的每个条件都是只涉及可空一侧那张表的时间条件、那张表只出现在结果里（WHERE、
  HAVING、别的连接没用到，SELECT 列表用到了）、同一列的按取值算过确实不同、单边的不是恒为真；套着日期函数认不准的、
  反连接、结果里没用到可空一侧的、不是时间条件的照实兜底。aspect 写 join（说的是关联条件），双盲复算不会把它当业务日期
  写进数据目录。只改说明，判等价不变。

测试：tests/test_ledger_projection.py（没证明时先说多查了几列、再说少了 status 条件，不再兜底）、
tests/test_sql_left_on_times.py（四种说得清的、在虚构库上结果确实不同；四种说不清的照实兜底；判等价的结论不变）。
去掉这两处改动再跑，各自的用例失败（2 条、8 条）。
 2026-10-17 11:49:31 +08:00
ThearchyHelios 2a4086ab73 认口径按答案引用的那几列比：整条比不等价时先投影再交现有的绑定和判等价 
真实助手的 SQL 总会多选几列（订单数、日期常量、MIN / MAX、COALESCE），报告只引用其中一列，口径的取数也只选它的指标要的
那几列。以前整条比，「上周的销售额是多少」3/3 只标相关口径、从不自动出具。

做法：sql_semantics 新增 project_select / project_template / output_names。按方言切词、按括号深度认出最外层 SELECT
列表每一项在原文里的起止，只把留下的几项原样拼回去（选择列表前后一字不动，保真守卫照样看得到原文），拼完重新解析、
语法树要和「原树换成留下的几项」一模一样。只在确定去掉不影响时投影，否则照实给原因、照旧整条比：DISTINCT / DISTINCT ON、
出现在 GROUP BY 里、被 ORDER BY / HAVING / QUALIFY / 窗口用到（按别名、同样的写法、按位置）、有 LIMIT / OFFSET 又不是
只出一行的聚合、集合运算、*、可能改变行数或不认识的函数、去掉仅有的聚合、留下按任意一行取值的列、调换先后时引用别的
选择项的名字，一律不去。

ledger/match：整条比不等价时，答案一侧按报告引用了这条查询的哪几列（labels.referenced_columns）投影，口径一侧按口径卡
上每个指标读了这个取数节点的哪几列（labels.card_reads）投影，投影后照样交 match_template（不另开给信任的路）。被引用的
列两边怎么对上写进模块说明：答案按列名在快照结果列里找位置、口径按 cell() 里的列名在输出名里找位置，投影后按位置配对，
答案留下两三列时另试调换先后，每份口径取数最多试 12 种。证明了的候选记 projection；没投影可试的逐对和以前一字不差。
算法版本升到 3；E1 另数 proven_projected；对账按投影后留下的列配对（不用人选）。

测试：tests/test_sql_projection.py（该去的、不该去的各一组，语料里 305 种投影在虚构库上执行守门）、
tests/test_ledger_projection.py（多选一列 / 多几个聚合 / 日期常量列能证明；多一个分组列、DISTINCT、按别的列排序加
LIMIT、HAVING 用到多出来的聚合仍然证明不了且和不投影时一字不差；口径一侧投影、调换先后；真跑一次整题等价；对账配对）。
去掉投影再跑，7 条失败。
 2026-10-17 11:47:26 +08:00
ThearchyHelios f5c9f0c13c 剖析任务接口收取值观察范围，对话框给出「取值观察」；定时维护挑不出要观察的表时把原因记进触发记录 
验收：取值观察只能经定时维护触发——POST /catalog/profile-jobs 的 scope 只收 needed、all，可剖析任务本来就支持
observe（只观察、不剖析）。另外 12 小时内观察过的表不再观察时，任务以 0 张表结束，原因只在剖析任务的 notice
里，从定时维护触发时触发记录（ScheduleFire.inputs）看不出来。

后端：
- ProfileJobIn.scope 加 observe（maintenance 是定时维护用的，接口照旧不收）。挑不出表时照旧 409 profile_nothing，
  说法是 NOTHING_TO_OBSERVE（「最近 12 小时内都观察过了」）。
- catalog_profile_jobs.nothing_reason：按此刻的表结构和目录一张表都挑不出来时交回 ProfileNothing 的原话；排在
  起草后面时说不准，返回 None。
- source_maintenance._start：建出 0 张表的剖析任务、这次触发又没有探查（开始时表结构不会变）、也没排在起草后面
  （目录不会变）时，判断得出任务会以 0 张表结束，把原因记进 inputs.skipped（同一套 NOT_RUN 说法进 reason）。
  任务照建、触发照旧是 started：每小时一次的维护不至于一天二十几次「没能发起」。同一次触发里有探查、或者排在
  起草后面时判断不了，保持现状，写进了模块说明。

前端：剖析对话框的范围里加「取值观察：有数据目录的 N 张表」（说法照维护设置里「取值观察」那一步：码值分布、
最新业务日期、按日行数和行数，和同口径的历史比出取值变化；最近 12 小时内观察过的这次不再观察），建任务带
scope: observe。张数按清单上有数据目录、不是视图的表算（isObservable，profile.ts），观察到期没有由服务端判，
所以是上限。挑不出表时说「没有要观察的表」和服务端原话，不给「改选全部表」（那是剖析，不是观察）。文案进
PROFILE_TEXT。

测试：test_catalog_observe 新增一条（接口建 observe 任务、只做观察检查，再建一次 409 profile_nothing，maintenance
422）；test_source_maintenance 新增一条（只选取值观察，12 小时内再触发：任务 0 张表，inputs.skipped 和 reason 写明
原因）。去掉修复回跑两条都挂。check-catalog-profile 跟上：范围多一项 observe:1，说法核对；新一节建取值观察任务
（请求体 {scope: observe}）、都观察过时的「没有要观察的表」且没有「改选全部表」。tsc、check-copy 通过，
check-catalog-profile 204 项全过。
 2026-10-17 08:51:51 +08:00