 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 |
|