14 Commits

Author	SHA1	Message	Date
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	8c2ff49b50	use_caliber 的协议写清 card 填什么，写错了交回的原因能一次改对 ... 真实验收里模型第一次常把 card 写成自己起的 c1 被拒，之后才改对：协议示例写的是 "card":"口径卡节点 id"，紧接着又说 「口径卡（节点 id 就是 c1）」，两个 id 混在一起。 - api/copilot_context.USE_CALIBER_PROMPT：示例写 "card":"card"；说清 workflow_id、version、card 原样照抄，只改 id、metrics、 inputs；card 是那一版工作流图里口径卡的节点 id（查看结果的写法里写好了），id 是这次选用自己起的名字、生成的口径卡用它当 节点 id；add_edge c1 → report 里的 c1 是自己起的 id。 - look/calibers.DETAIL_COMPOSE_PROMPT：同样写明 card 原样照抄、id 自己起。 - ledger/compose：card 写错时说清 card 要填节点 id、可填的有哪几个（「节点 id」（口径卡「名字」）），写成了自己起的 id 的 另说一句「「c1」是你给这次选用起的 id，不是口径卡的节点 id」；几张卡要选时同样列节点 id。校验不放宽。 测试：tests/test_ledger_compose.py 新增两条（协议写清两个 id；card 写成自己的 id 被拒、原因说清该写什么，照着改成节点 id 就过）。改回原来的文字再跑，两条失败。	2026-10-17 12:17:21 +08:00
ThearchyHelios	4f4ad48ad7	组合式问数：问数据的助手可以 use_caliber 选用已发布口径，服务端确定性内联实例化（口径账本做法 4，拍板 L3） ... 为什么：问数据以前看不到口径，也没有组合机制；子图做骨架的路走不通（子图证据不交回父图、使用者用不了子工作流）。改成助手只选口径、填参数，取数节点由服务端按固定版本照抄，证据照常封存、比对照常复证。 做了什么： - 问数据的查看对象加 caliber（look/calibers 的 compose 模式）：另给每张卡的入口字段（类型、必填、可选值、格式、缺省值）和「能不能组合」（ledger/derive.load_pinned 同一个认法），能组合的写出 use_caliber 的写法；仍不给 SQL。只给搭建者及以上：使用者的图里看得到拷进来的取数 SQL。 - 新增 ledger/compose.py：use_caliber {id, workflow_id, version, card, metrics, inputs} 经 derive.caliber_block（扩了 card_id、inputs 两项）实例化——取数节点照抄、id 加前缀、模板按参数渲染成字面 SQL，口径卡 id 就是操作 id、caliber_from 带改名映射。参数按入口字段过 apps/forms 校验，写进 SQL 引号里的不能带引号、裸写的只能是数；只能选这一轮看到的那一版、能组合的卡、卡上的指标；不合规拒收。 - GraphApplier 落地 use_caliber：节点、连线记进 seen（兜底重放照样在），入口连到第一个取数节点；转给界面的只有那一条操作带 result；拒收的原因经自查交回模型（GraphChecker.issues）。 - 提示：协议多一段 USE_CALIBER_PROMPT；LOOK_WHEN 里问数据那一条按细案改写（只在能选用口径时换）。运行时写 SQL 的 Agent 不看口径（L2）。 - 比对器认出助手选用的查询（从封存的图里读 caliber_from.nodes）：证明了的标 composed「助手选用」，没能证明的照常是相关口径并说明；标签 how=composed，指标标签记取自哪几条查询；比对算法版本升到 2。 - 前端：问数据过程里 use_caliber 照实显示一行（选用了哪一版、生成几个节点；拒收写原因），节点数算进「新增几个步骤」；文案进 LEDGER_TEXT.use；check-decode 加一节。 测试：tests/test_ledger_compose.py（实例化确定性、各种拒收、查看文字不带 SQL、提示切换、落地与接线、拒收交回模型、剧本模型走一遍生成再真跑出 composed 标签、使用者不给口径）。	2026-10-16 16:35:28 +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	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	fcbf711941	按需求挑选不再总是「没挑出来，已把表目录交给助手」：挑选以为能关掉思考、只给 1024 的输出额度，可经 OpenAI 兼容接入的推理模型（DeepSeek、GLM、Kimi 这一类）收不到 thinking=off，想完就没额度写结果，回复是空的或 JSON 只写了一半，又被报成「不是约定的格式」。额度改成和证据裁判、核查同一档 16384，服务方嫌大时退回 4096（按接入和模型记在进程里、互相认），时限 20 秒放宽到 45 秒；结构化输出带原始回复，正文、工具调用参数里的 JSON 也认，<think> 里的草稿不算，正文里顺手写的 [1] 不算空结果；没成的原因照实分开说：被截断（带额度）、回复是空的、写了字却不是约定的格式，认不出的回复开头记进日志	2026-10-15 14:59:40 +08:00
ThearchyHelios	0f32b8335e	应用平台 BE-4 助手：按需查看（默认只给数据源概览、look 行停下执行接着写、一次拿齐、每轮 3+1 次、系统代为查看、查看记录进历史），生成过程可插拔（Applier / Checker 注入、ask 结束本轮），查看对象按类型标记并实现表 / 能力 / 工作流版本三种（表详情与 db_schema__、/schema 共用并按遮罩规矩），应用润色接口 /copilot/app-stream，从运行提取模板记来源，演示模型走一次查看（含统一复核后的修复）	2026-10-14 20:05:23 +08:00
ThearchyHelios	546d0e9326	没有数据目录的大库：助手「参考了 N 张表」那一行提示先起草目录。真实运行里的大库一张目录都没有，挑表和 SQL 检查都用不上目录，用户也不知道该先去起草。服务端 context 操作的每个数据源多带 source_id 和 catalog_tables（去掉驳回项后还有内容的表数）；前端 copilotContext 在要挑表的大库 catalog_tables 为 0 时给出下一步「这个数据源还没有数据目录，起草后挑表和 SQL 检查会更准」，入口直达 /data/catalog/:sourceId（几个库时点名，老服务端不给目录表数时不提示）。check-decode、check-stream、check-chat 补断言	2026-10-04 11:28:49 +08:00
ThearchyHelios	f4a9955cc3	助手写查库 SQL 时给结果列起中文别名：真实运行里报告表格的表头全是英文缩写的原始列名（[[table:]] 原样用查询结果的列名）。节点手册里 Agent 查库的说明和写 SQL 的硬性要求都加上一条：结果列用中文别名，按方言加标识符引号（MySQL / MariaDB 用反引号，PostgreSQL、Oracle、SQLite 用双引号，不用单引号），只给最外层 SELECT 起别名；自查的列名核对把带引号的中文标识符抹掉再判，不再因为有带引号的中文别名就整条放弃核对、把猜错的英文列名一起放过去	2026-10-04 11:13:12 +08:00
ThearchyHelios	52aaaaf945	数据目录 F3 / B4 服务端：没探查到的表说出来——目录清单返回 schema_truncated、schema_total；助手上下文的 total 用表结构缓存里的真实总数，截断时 context 操作带 explored，提示词写明还有几张没探查到、不认识的表名先查结构，挑表请求也写明只列了探查到的	2026-10-04 01:11:03 +08:00
ThearchyHelios	c12f0f2852	数据目录 F3 一致性：助手上下文里「现有工作流用到的表」改用 tool_queries 认节点（以 sqlcheck.tool_query 为准，换了类型的节点残留的查询不再算）；正式运行的目录变化事件改用 EventType.CATALOG_DRIFT；写明关系编号区分方向、有意不改	2026-10-04 01:07:41 +08:00
ThearchyHelios	1294095d1e	数据目录阶段 1B 前端：画布和问数据页的过程里显示「参考了 N 张表」，展开按数据源列出表名，挑表失败时写明只提供了表名及原因	2026-10-03 10:56:25 +08:00
ThearchyHelios	9e809bafe6	数据目录阶段 1B 流式输出：挑表后发 context 操作，说明这一轮参考了哪些表、怎么挑的、挑表用时，挑表失败时带上原因	2026-10-03 10:19:41 +08:00
ThearchyHelios	e74097a103	数据目录阶段 1B 服务端：大库按需求挑表、补连接路径，挑中的表给全字段、目录和连接条件，四个生成入口共用同一套组装	2026-10-03 10:18:50 +08:00