ThearchyHelios 1e58862bf0 抽出数据目录后台任务的共用运行时，起草任务改用它：为剖析改成逐表的后台任务做准备 ...

data/catalog_job_runtime.py 从 catalog_jobs.py 抽出进程内任务的执行与停止（JobManager：start / stop(grace) / wait / running / shutdown；JobRun 把进队、等轮到自己、执行、按停止原因收尾、出队写一次）、同一任务的库写入一条一条来并 shield（SerialWriter）、启动时标中断（interrupt_on_startup、close_job）、状态词常量，以及每个源一条先来先到的队（SourceLanes：任务阻塞地占，同步写操作不阻塞地试占）。剖析和起草是同一类问题（关页面就没了、不能停、不留痕），生命周期各写一份迟早一边修了另一边没修；共用的是生命周期代码，表各建各的。

起草的行为不变（test_catalog_draft_jobs.py 一条不改全过），只是：ensure_idle 拆成「同种任务互斥」（ensure_draft_free，建起草任务、重试用，剖析任务不挡起草，起草任务排在它后面）和「同步写操作要求源空闲」（ensure_idle，同步起草、导入用，剖析任务也算）；同步起草、导入目录执行期间占着这个源的队，期间新建的任务排在后面；任务和清单顶上的进度带 waiting_for（起草排在剖析后面时为 profile）；排队中被停止的任务连同在队里等着的后台执行一起停掉、出队。

db/models.py 加 CatalogProfileJob、CatalogProfileTask 两张表（create_all 建，同源排队或进行中的部分唯一索引照起草的写法）；catalog_profile_jobs.py 先放剖析任务的忙碌判定，下一步补全。

2026-10-15 18:10:50 +08:00

..

__init__.py

数据源接入：MySQL / Oracle / PostgreSQL / SQLite

2026-09-17 10:39:23 +08:00

capability_review.py

应用平台集成（后端访问面）：开登录后使用者的问数据只能是探索运行、节点与工具白名单、查询结果在工具边界遮罩且数据源强制只读、记忆与知识库范围不能自选，运行流按运行判读权限；对话按建立人隔离（应用助手对话要 manage）；能力字段语义的审阅队列与批量审阅；按需视图每日上限登记为设置项；通用设置接口不再读写登录设置；运行带来源、按来源筛选，审批带待办 id（含统一复核后的修复）

2026-10-14 21:55:51 +08:00

catalog_assistant.py

目录修改提案的依据改存成目录项单独的字段 reason（界面上叫「确认时的依据」，最多 500 字，超了截成 499 字加「…」），不再拼进备注：拼进 note 之后，带依据保存的关联关系再剖析时测量的说法换不了新、和覆盖率那一栏对不上；改了值的关联关系旧依据叠在新依据后面、越存越长；值不变、保存即确认的项撤销审阅回到推断后「依据：使用者说……」还挂着，看起来像使用者确认过一条推断项。去留：值改了（关联关系也一样）换成这次的依据，没写就去掉旧的；值不变的确认换成这次的，不叠；单项确认、驳回留着，撤销审阅去掉；整份提交改了值的、状态改回推断的、双盲复算改写的去掉；剖析刷新关联关系的测量只动备注。校验认 reason（文字、最多 500 字），起草、剖析的合并不碰人工确认的项，导出导入时已确认、已驳回的项连依据一起带，推断、有确证的项不带。表助手背景里已有的依据写成「以前确认时的依据：……」，系统提示词和 propose_changes 的说明写清那不是这次对话里使用者说的话、引用时写「以前确认时的依据写着：……」，遮罩列的项不给。表详情里依据和说明分开写：表级的项在值下面另起一行，列的一格、关联关系另一个悬停图标（读屏念「确认时的依据：……」），状态弹层里也写，驳回的项只在弹层里写；check-catalog-loop 的假服务端照服务端记下依据，补依据和说明分开、弹层、驳回项的检查；README 表助手一行写上依据另存

2026-10-14 15:38:15 +08:00

catalog_draft.py

数据目录闭环第一步（后端 A）复核修正：没收下的有效记录条件不算失败，在起草任务逐表的 log 里记一句，接口看得到（以前只进服务端日志）——没通过校验的写原因（「有效记录条件里不能有子查询，模型提议的这一条没有收下：……」），剖析核对排除 0% 或 100% 的写数到了多少行；只在请模型写表级的项的那段里记，一张表最多 10 句。CatalogDraftTask 加 log 列（存量任务回填 NULL，接口给空列表）

2026-10-14 10:00:10 +08:00

catalog_impact.py

数据目录 F3 / B1 服务端：SQL 只写在 Agent 里的模板也提醒目录变化——发布记录分直接引用和可能涉及两组，Agent 和协作成员绑定了查询工具的源记下所有有目录的表，正式运行两组都比、每张表标明属于哪一组；只记了直接引用的旧记录照旧按直接引用比；哪些节点算写死的查询统一交给 tool_queries

2026-10-04 01:07:15 +08:00

catalog_job_runtime.py

抽出数据目录后台任务的共用运行时，起草任务改用它：为剖析改成逐表的后台任务做准备

2026-10-15 18:10:50 +08:00

catalog_jobs.py

抽出数据目录后台任务的共用运行时，起草任务改用它：为剖析改成逐表的后台任务做准备

2026-10-15 18:10:50 +08:00

catalog_profile_jobs.py

抽出数据目录后台任务的共用运行时，起草任务改用它：为剖析改成逐表的后台任务做准备

2026-10-15 18:10:50 +08:00

catalog_profile.py

剖析不改人确认过的外键关系的基数：值不变、保存即确认的外键关系来源仍是 fk，以前 _patch_fk 不看状态，数据核实出的基数不同就直接改写，确认时的依据还挂着，前后矛盾；现在同 _patch_confirmed，不改人定的基数、也不标用数据核实过，测量的说法照常写进备注

2026-10-14 16:11:04 +08:00

catalog_review.py

审阅队列与进度按约定改：field_label 写给人看的完整位置（「表的有效记录条件」「列 status 的码值」「指向 members 的关联关系」，和表助手提案、导入冲突的说法同一个函数），列级的项另带 column；排在这里的原因写「被 N 次运行用到」，数的是运行（同「用过这张表的运行」的 total），同一次运行里查了几次、使用次数比运行次数多时两个都写（「被 2 次运行用到，使用 5 次」），table_usage 和优先级照旧按使用次数（同目录清单的「使用 N 次」和排序）；进度里的常用 20 张表和起草的默认范围是同一批（使用次数从多到少，用到的不够 20 张时按表结构的顺序补齐），top 只给 tables、items_total、items_confirmed，all 只给约定的四项；表助手背景里写这张表被几次运行用到、查询几次

2026-10-14 09:51:49 +08:00

catalog_transfer.py

导入目录：推断、有确证的项在校验之前去掉确认时的依据，手改过的文件里依据不合规也不再把整项跳过（照常只填空缺）；已确认、已驳回的项依据不合规照旧跳过

2026-10-14 16:11:04 +08:00

catalog.py

目录修改提案的依据改存成目录项单独的字段 reason（界面上叫「确认时的依据」，最多 500 字，超了截成 499 字加「…」），不再拼进备注：拼进 note 之后，带依据保存的关联关系再剖析时测量的说法换不了新、和覆盖率那一栏对不上；改了值的关联关系旧依据叠在新依据后面、越存越长；值不变、保存即确认的项撤销审阅回到推断后「依据：使用者说……」还挂着，看起来像使用者确认过一条推断项。去留：值改了（关联关系也一样）换成这次的依据，没写就去掉旧的；值不变的确认换成这次的，不叠；单项确认、驳回留着，撤销审阅去掉；整份提交改了值的、状态改回推断的、双盲复算改写的去掉；剖析刷新关联关系的测量只动备注。校验认 reason（文字、最多 500 字），起草、剖析的合并不碰人工确认的项，导出导入时已确认、已驳回的项连依据一起带，推断、有确证的项不带。表助手背景里已有的依据写成「以前确认时的依据：……」，系统提示词和 propose_changes 的说明写清那不是这次对话里使用者说的话、引用时写「以前确认时的依据写着：……」，遮罩列的项不给。表详情里依据和说明分开写：表级的项在值下面另起一行，列的一格、关联关系另一个悬停图标（读屏念「确认时的依据：……」），状态弹层里也写，驳回的项只在弹层里写；check-catalog-loop 的假服务端照服务端记下依据，补依据和说明分开、弹层、驳回项的检查；README 表助手一行写上依据另存

2026-10-14 15:38:15 +08:00

draft_model.py

起草模型设置：新增设置组 catalog_draft（接入、模型），点名的接入不存在或已停用时保存回 422；数据目录起草和按配方导入的 AI 起草共用一处取模型（起草模型 > 助手的模型 > 默认接入），取自起草模型时报错照实说起草模型那一项；数据目录起草不再关思考，额度 32768，服务方嫌大时退回 8192（之后都用小额度），单次调用时限 420 秒交给 SDK；配方 AI 起草的额度、思考设置不动

2026-10-13 15:00:38 +08:00

engine.py

普通用户建应用集成收尾：

2026-10-15 13:55:19 +08:00

guard.py

普通用户建应用（后端）：

2026-10-15 12:09:29 +08:00

introspect.py

只探查了部分表时，查结构工具不再对没探查到的表说「没有」：说明不在已探查范围、无法判断，并给出查数据字典的办法

2026-10-04 01:31:16 +08:00

names.py

Excel 导入改造期 1：止血与版本底座——写错的列名不再静默得 0，导入不再悄悄读错，每次上传生成不可变的版本，运行固定发起时的数据版本

2026-10-01 13:42:04 +08:00

provenance_db.py

Excel 导入改造期 4：证据下钻——报告里引用上传表格的数，点开能看到它来自原表格的哪一格；裁判核对时看得到来源、口径、接受理由和区域外文字

2026-10-02 14:38:10 +08:00

provenance_types.py

合并查询节点（二）：证据面板展示合并的输入、合并 SQL 和警告，被引用的格沿逐格来历追到输入的那一格并接上输入的查询步骤；推断来源穿过合并下钻到原表格子，追不到的判为没有逐格来历；裁判摘录写明合并的输入并按底层数据源遮罩

2026-10-03 09:36:20 +08:00

provenance.py

Excel 导入改造期 4：证据下钻——报告里引用上传表格的数，点开能看到它来自原表格的哪一格；裁判核对时看得到来源、口径、接受理由和区域外文字

2026-10-02 14:38:10 +08:00

raw_store.py

普通用户建应用（后端）：

2026-10-15 12:09:29 +08:00

recipe_accumulate.py

Excel 导入改造期 3：网格交互、自助修复、按期累积——每月的报表可以累积成一份跨月的表，漂移了点修复按钮就能接着导入，网格上框一块就能写进配方，版本页可以回滚、移除一期、清除原件

2026-10-02 07:38:44 +08:00

recipe_ai.py

起草模型设置：新增设置组 catalog_draft（接入、模型），点名的接入不存在或已停用时保存回 422；数据目录起草和按配方导入的 AI 起草共用一处取模型（起草模型 > 助手的模型 > 默认接入），取自起草模型时报错照实说起草模型那一项；数据目录起草不再关思考，额度 32768，服务方嫌大时退回 8192（之后都用小额度），单次调用时限 420 秒交给 SDK；配方 AI 起草的额度、思考设置不动

2026-10-13 15:00:38 +08:00

recipe_checks.py

Excel 导入改造期 4：证据下钻——报告里引用上传表格的数，点开能看到它来自原表格的哪一格；裁判核对时看得到来源、口径、接受理由和区域外文字

2026-10-02 14:38:10 +08:00

recipe_compare.py

Excel 导入改造期 3：网格交互、自助修复、按期累积——每月的报表可以累积成一份跨月的表，漂移了点修复按钮就能接着导入，网格上框一块就能写进配方，版本页可以回滚、移除一期、清除原件

2026-10-02 07:38:44 +08:00

recipe_confirm.py

Excel 导入改造期 3：网格交互、自助修复、按期累积——每月的报表可以累积成一份跨月的表，漂移了点修复按钮就能接着导入，网格上框一块就能写进配方，版本页可以回滚、移除一期、清除原件

2026-10-02 07:38:44 +08:00

recipe_diff.py

Excel 导入改造期 3：网格交互、自助修复、按期累积——每月的报表可以累积成一份跨月的表，漂移了点修复按钮就能接着导入，网格上框一块就能写进配方，版本页可以回滚、移除一期、清除原件

2026-10-02 07:38:44 +08:00

recipe_engine.py

Excel 导入改造期 4：证据下钻——报告里引用上传表格的数，点开能看到它来自原表格的哪一格；裁判核对时看得到来源、口径、接受理由和区域外文字

2026-10-02 14:38:10 +08:00

recipe_fixes.py

Excel 导入改造期 3：网格交互、自助修复、按期累积——每月的报表可以累积成一份跨月的表，漂移了点修复按钮就能接着导入，网格上框一块就能写进配方，版本页可以回滚、移除一期、清除原件

2026-10-02 07:38:44 +08:00

recipe_imports.py

Excel 导入改造期 3：网格交互、自助修复、按期累积——每月的报表可以累积成一份跨月的表，漂移了点修复按钮就能接着导入，网格上框一块就能写进配方，版本页可以回滚、移除一期、清除原件

2026-10-02 07:38:44 +08:00

recipe_notes.py

Excel 导入改造期 3：网格交互、自助修复、按期累积——每月的报表可以累积成一份跨月的表，漂移了点修复按钮就能接着导入，网格上框一块就能写进配方，版本页可以回滚、移除一期、清除原件

2026-10-02 07:38:44 +08:00

recipe_parsers.py

Excel 导入改造期 2：配方引擎与确认向导——表从哪一行哪一列开始、哪些是合计、日期怎么补年份，都写进一份可校验的配方；首次导入经人确认，之后每期按配方重放并核对

2026-10-01 22:00:07 +08:00

recipe_select.py

Excel 导入改造期 3：网格交互、自助修复、按期累积——每月的报表可以累积成一份跨月的表，漂移了点修复按钮就能接着导入，网格上框一块就能写进配方，版本页可以回滚、移除一期、清除原件

2026-10-02 07:38:44 +08:00

recipe_suggest.py

Excel 导入改造期 3：网格交互、自助修复、按期累积——每月的报表可以累积成一份跨月的表，漂移了点修复按钮就能接着导入，网格上框一块就能写进配方，版本页可以回滚、移除一期、清除原件

2026-10-02 07:38:44 +08:00

recipe_types.py

Excel 导入改造期 4：证据下钻——报告里引用上传表格的数，点开能看到它来自原表格的哪一格；裁判核对时看得到来源、口径、接受理由和区域外文字

2026-10-02 14:38:10 +08:00

recipe.py

Excel 导入改造期 3：网格交互、自助修复、按期累积——每月的报表可以累积成一份跨月的表，漂移了点修复按钮就能接着导入，网格上框一块就能写进配方，版本页可以回滚、移除一期、清除原件

2026-10-02 07:38:44 +08:00

schema_view.py

应用平台 BE-4 助手：按需查看（默认只给数据源概览、look 行停下执行接着写、一次拿齐、每轮 3+1 次、系统代为查看、查看记录进历史），生成过程可插拔（Applier / Checker 注入、ask 结束本轮），查看对象按类型标记并实现表 / 能力 / 工作流版本三种（表详情与 db_schema__、/schema 共用并按遮罩规矩），应用润色接口 /copilot/app-stream，从运行提取模板记来源，演示模型走一次查看（含统一复核后的修复）

2026-10-14 20:05:23 +08:00

source_versions.py

Excel 导入改造期 3：网格交互、自助修复、按期累积——每月的报表可以累积成一份跨月的表，漂移了点修复按钮就能接着导入，网格上框一块就能写进配方，版本页可以回滚、移除一期、清除原件

2026-10-02 07:38:44 +08:00

sql_semantics.py

M4 复核修正：规范化后不同的行带上所在的子句，ON 挂在 JOIN 那一行的末尾

2026-10-07 01:34:59 +08:00

sqlcheck.py

数据目录闭环第一步（后端 A）复核修正：模型提议的有效记录条件存整理过的写法——原文照旧（NOT IN、IS NOT NULL 不被改写），只把列换成表结构里的真名、不带表名、按数据源的方言要加引号的加引号，剖析核对的就是存下的这一条。以前存的是模型的原文，核对时却按真名加了引号：PostgreSQL 上混合大小写的列（"OrderStatus"）存成 orderstatus <> 'X'，一跑就报列不存在，SQL 检查还会让模型照抄。列名先照原样对表结构，只差大小写的几列写不清是哪一列的不收；加了引号超过 500 字的不收（写进去会让整张表写入失败）；不合规的说法用界面上的叫法「有效记录条件」

2026-10-14 09:59:52 +08:00

table_versions.py

普通用户建应用（后端）：

2026-10-15 12:09:29 +08:00

tabular.py

Excel 导入改造期 2：配方引擎与确认向导——表从哪一行哪一列开始、哪些是合计、日期怎么补年份，都写进一份可校验的配方；首次导入经人确认，之后每期按配方重放并核对

2026-10-01 22:00:07 +08:00

xlsx_cells.py

Excel 导入改造期 2：配方引擎与确认向导——表从哪一行哪一列开始、哪些是合计、日期怎么补年份，都写进一份可校验的配方；首次导入经人确认，之后每期按配方重放并核对

2026-10-01 22:00:07 +08:00

xlsx_scan.py

Excel 导入改造期 2：配方引擎与确认向导——表从哪一行哪一列开始、哪些是合计、日期怎么补年份，都写进一份可校验的配方；首次导入经人确认，之后每期按配方重放并核对

2026-10-01 22:00:07 +08:00