fquiz/.hermes/plans/2026-06-11_210918-fquiz-atp-minio-redesign.md

fquiz ATP 目录化模型管理改造方案

For Hermes: 后续若按此方案实施，优先按阶段拆分为独立任务执行；每阶段完成后先做接口/数据契约核对，再进入下一阶段。

Goal: 把当前基于单个 atp_text 文本的 ATP 模型管理，升级为“按电压等级 / 塔型 / 场景 / 工况目录管理的 ATP 资料包管理系统”，由 MinIO 承载完整目录树，最终在运行时将指定资料包同步到本地 Wine 允许运行根目录，再调用 tpbig.exe / rjtzl.exe 等程序执行。

Architecture: 复用现有 file_storage（VFS/S3-MinIO）作为对象存储底座，新增 ATP 资料包元数据层、导入任务层、运行物化层三层模型。管理端不再把 ATP 模型等价为一段 atp_text，而是把它视为“一个可索引、可发布、可运行的目录包”；运行时通过 Celery 任务将目录包物化到 wine_allowed_root 下，再按规则调用 Wine/ATP 程序并回收结果。

Tech Stack: FastAPI + SQLAlchemy + PostgreSQL + MinIO(S3) + Celery + Wine + Ant Design + 现有文件管理模块。

---

1. 背景与现状判断

1.1 真实业务目标

用户期望的 ATP 模型管理，不是现在这种：

• 一个模型
• 对应若干版本
• 每个版本核心是一段 atp_text

而是类似真实目录 /mnt/d/fl/解压目录/ATP 的管理方式：

• 按电压等级：35/66/110/220/330/500/750/800/1000
• 按塔型/线路类型：ganzi/guxing/jiubei/maotou/sihuita/...
• 按场景：fanji/raoji1/raoji2/raoji3
• 按避雷器/工况组合：M1/M12/M123/M13/M2/M23/M3/noM/...
• 目录内混合存在：
  • work.atp
  • *.lis/*.pl4/*.log/*.dbg
  • *.lib/*.dat/*.pch
  • EGM 输入/结果
  • exe
  • py 预处理/后处理脚本
  • txt/docx/zip 说明与归档

1.2 fquiz 当前 ATP 模块的主要问题

当前文件：

• api/app/models/atp_model.py
• api/app/services/atp_model_service.py
• api/app/api/v1/atp_models.py
• web/src/app/admin/power-lines/atp-viewer/page.tsx

现状特征：

1. AtpModelVersion 的核心字段是：
   • atp_text
   • graph_json
   • artifact_manifest_json
2. 运行逻辑 _build_run_command() 也是把 version.atp_text 写到本地文件后直接执行。
3. 这套设计只能覆盖“单文件 ATP 文本模板”，不适合覆盖真实目录资料包。
4. 当前没有把：
   • 电压等级
   • 塔型
   • 场景
   • 工况组合
   • EGM/ATP 双运行器 纳入一等公民模型。

1.3 可直接复用的基础设施

当前仓库已经具备以下可复用能力：

对象存储与文件索引

• api/app/models/file_storage.py
• api/app/services/storage_driver.py
• api/app/services/file_service.py

已支持：

• VFS / S3(MinIO)
• mount 抽象
• 目录列举
• 上传/下载
• 重命名/移动/删除
• index entry 同步

MinIO 环境

• .env
• deploy/dev-deploy/compose.yml
• deploy/pro-deploy/compose.yml
• seed_service.py

已支持：

• files.s3.default
• bucket 自动初始化
• main mount 默认挂载

Wine 执行能力

• api/app/services/wine_service.py

已支持：

• 在 wine_allowed_root 下执行 exe
• Celery 异步任务
• 日志/退出码记录

legacy ATP 目录执行样板

• api/app/services/legacy_atp_adapter.py

已支持：

• 解析模板目录
• 复制模板目录到运行目录
• 对目录内模型文件做特征绑定
• 运行 tpbig.exe / rjtzl.exe
• 回读文本结果

大文件/目录导入异步样板

• api/app/services/elevation_service.py

已支持成熟链路：

• 上传到对象存储暂存区
• 记录 import job
• Celery 异步解压/整理/导入
• 结果落库

结论： 本方案不需要重造存储、任务、执行底座，只需要把 ATP 模型层升级成“目录包元数据 + 目录包导入/发布/运行编排”。

---

2. 目标架构

2.1 三层模型

A. ATP 资料包主表（业务维度）

用于表达“一个业务上的 ATP 模型族”。

示例：

• 220kV 四回塔 绕击3
• 500kV 干字塔 反击
• 330kV 酒杯塔 无避雷器

这个层级只关心业务分类与检索，不关心实际目录文件细节。

B. ATP 场景版本表（发布维度）

用于表达“一个可执行的具体版本/场景”。

一个版本会绑定：

• 电压等级
• 塔型
• 场景
• 工况组合
• 运行器类型（ATP / EGM / HYBRID）
• 存储中的目录根路径
• 入口文件
• 可选结果文件规则
• 可选预处理/后处理脚本

这个层级才是真正供运行选择的对象。

C. ATP 工件清单表（文件维度）

用于表达一个场景版本内有哪些关键文件。

典型包括：

• work.atp
• work.lis
• rjtzl.exe
• tpbig.exe
• EGM/*.txt
• delete_others.py
• 说明.docx

这个层级负责：

• 展示
• 校验
• 关键文件定位
• 运行时解析入口

D. ATP 导入任务表（流程维度）

用于表达一个 zip/目录包从上传到发布的过程。

---

2.2 运行时链路

目标运行链路：

1. 管理端在 MinIO 中维护 ATP 资料包目录树
2. 用户在后台选择一个“ATP 场景版本”发起运行
3. API 创建 run 记录
4. Celery 任务：
   • 从 MinIO 读取该版本目录树
   • 物化到本地 wine_allowed_root 下的运行目录
   • 如有预处理脚本则执行
   • 调用 wine tpbig.exe 或 wine rjtzl.exe
   • 回收结果文件 / stdout / stderr
   • 如有后处理脚本则执行
   • 写回 run 结果与产物索引
5. 前端查看运行结果、下载关键输出文件

---

3. 数据模型设计

3.1 新表设计

3.1.1 atp_asset

表示 ATP 业务模型族。

建议字段：

• id varchar(32) pk
• code varchar(64) unique
• name varchar(255)
• description text
• status varchar(20) draft/enabled/disabled/archived
• voltage_level varchar(16) 可选冗余主标签，如 220/500
• tower_type varchar(64) 可选冗余主标签，如 sihuita/ganzi
• scene_type varchar(32) 可选冗余主标签，如 fanji/raoji3
• tags_json json
• create_date/create_user/update_date/update_user

说明：

• atp_model 可保留兼容，但长期建议新建 atp_asset，避免语义继续混乱。
• 如果不想新建表，也可将现 atp_model 语义提升为 asset，但字段命名会继续误导开发者。

3.1.2 atp_asset_release

表示一个可执行发布版本。

建议字段：

• id varchar(32) pk
• asset_id fk -> atp_asset.id
• release_no int
• release_tag varchar(64)
• status varchar(20) draft/released/archived
• voltage_level varchar(16) 非空
• tower_type varchar(64) 非空
• scene_type varchar(32) 非空
• scenario_code varchar(64) 如 M1/noM/M123
• runner_kind varchar(20) atp/egm/hybrid/wine_script
• storage_mount_code varchar(64) 默认 main
• storage_root_path varchar(2048) 目录包根路径
• entry_file varchar(255) 如 work.atp
• result_file varchar(255) 可空
• egm_subdir varchar(255) 可空
• egm_result_file varchar(255) 可空
• preprocess_script varchar(255) 可空，如 1 delete_others.py
• postprocess_script varchar(255) 可空
• manifest_json json
• validation_json json
• content_hash varchar(64)
• is_active bool
• create_date/create_user/update_date/update_user

说明：

• storage_root_path 指向 MinIO 挂载中的目录根，例如：
  • /atp-library/220/sihuita/raoji3/M1
• manifest_json 保存导入扫描结果：
  • 文件总数
  • 关键文件是否存在
  • 子目录结构
  • 可执行文件定位

3.1.3 atp_asset_file

表示一个发布版本的关键文件索引。

建议字段：

• id bigint pk
• release_id fk -> atp_asset_release.id
• relative_path varchar(2048)
• name varchar(255)
• file_role varchar(32)
  • entry_atp
  • result_text
  • exe_tpbig
  • exe_rjtzl
  • preprocess_script
  • postprocess_script
  • library
  • doc
  • binary
  • other
• mime_type varchar(255)
• size bigint
• etag varchar(255)
• storage_key varchar(2048)
• is_required bool
• create_date/update_date

3.1.4 atp_asset_import_job

表示导入任务。

建议字段：

• id varchar(32) pk
• asset_id fk 可空
• release_id fk 可空
• mount_code varchar(64)
• stage_path varchar(2048)
• source_filename varchar(255)
• status varchar(20)
  • pending/queued/importing/validating/completed/failed/cancelled
• uploaded_file_count int
• extracted_file_count int
• warning_count int
• warnings_json json
• staged_files_json json
• manifest_json json
• task_id varchar(128)
• error_message text
• create_date/create_user/update_date/update_user

3.1.5 atp_asset_run

建议替代或扩展现有 atp_simulation_run。

如果保留现有表，建议至少新增：

• release_id
• storage_mount_code
• storage_root_path
• materialized_root_path
• runner_kind
• preprocess_status
• postprocess_status
• output_manifest_json
• result_summary_json

说明：

• 现有 version_id 更像文本版本语义，不够表达目录包。

---

4. 存储设计（MinIO）

4.1 目标目录布局

建议在 main mount 下单独规划 ATP 资料根：

• /atp-library/imports/：上传暂存区
• /atp-library/releases/：正式发布区
• /atp-library/runs/：运行结果归档（可选）

推荐正式目录格式：

• /atp-library/releases/{asset_code}/r{release_no}/...原始目录内容...

例如：

• /atp-library/releases/atp-220-sihuita-raoji3/r1/220/sihuita/raoji3/M1/...

或者更扁平一点：

• /atp-library/releases/atp-220-sihuita-raoji3/r1/...

建议选择扁平方案，即导入时把用户上传目录整体挂到该 release 根下，不强依赖固定内部第一层路径名。

4.2 为什么不要直接把原始 ATP 总目录一比一挂到运行配置

因为运行时真正需要的是：

• 一个明确可执行的 release 根
• 明确入口文件
• 明确结果文件
• 明确 runner 类型

而不是整个海量总库。总库适合归档，不适合直接供运行任务临时扫描。

---

5. 导入流程设计

5.1 导入入口

后台提供两种导入方式：

1. 上传 zip
2. 从文件管理已有路径选择目录并注册

优先建议先做 zip 导入，因为最容易闭环。

5.2 zip 导入流程

Step 1: 上传到对象存储暂存区

复用 elevation_service 的 staging 模式：

• driver.write_file() 到 /atp-library/imports/{job_id}/source.zip

Step 2: Celery 异步解压

任务：

• 读出 zip
• 解压到 /atp-library/imports/{job_id}/expanded/...
• 统计文件数、目录数、关键文件

Step 3: 自动校验

校验规则：

• 是否存在 work.atp 或配置指定入口
• 是否存在 tpbig.exe / rjtzl.exe 或可通过系统默认路径补足
• 是否存在 EGM 子目录（若 runner_kind=egm/hybrid）
• 是否存在 *.lis / 结果文本（若声明需要）
• 是否存在预处理脚本
• 是否包含潜在危险脚本（例如 .bat/.cmd/.ps1）

Step 4: 写 release 记录

生成：

• atp_asset
• atp_asset_release
• atp_asset_file
• manifest_json

Step 5: 发布到正式区

将暂存目录移动或复制到：

• /atp-library/releases/{asset_code}/r{release_no}/

Step 6: 前端展示导入报告

包括：

• 识别出的电压等级/塔型/场景/工况
• 关键文件清单
• 告警项
• 是否允许激活

---

6. 运行流程设计

6.1 物化策略

MinIO 不能直接供 Wine exe 当本地目录运行，因此必须“物化”到本地：

• 本地根：settings.wine_allowed_root
• ATP 运行根建议新增子目录：
  • ./data/wine/atp-runtime/releases/...
  • ./data/wine/atp-runtime/runs/{run_id}/...

运行前动作

1. 根据 release.storage_root_path 枚举 MinIO 下文件
2. 全量同步到：
   • wine_allowed_root/atp-runtime/runs/{run_id}/payload/
3. 校验入口文件存在
4. 如配置了 preprocess_script，先执行该脚本
5. 调用对应运行器

6.2 运行器策略

runner_kind = atp

• 调 tpbig.exe
• 输入：entry_file
• 工作目录：release 物化目录

runner_kind = egm

• 调 rjtzl.exe
• 工作目录：egm_subdir
• 结果文件按 egm_result_file

runner_kind = hybrid

• 先跑 egm
• 再按配置决定是否跑 atp
• 或按 legacy adapter 的 contract 合并结果

runner_kind = wine_script

• 允许指定一个 exe + 参数模板
• 仅作为扩展位，第一期不必开放 UI

6.3 后处理

如果有：

• postprocess_script

则运行结束后执行，用于：

• 清理参数块
• 汇总结果文件
• 生成前端展示摘要

6.4 结果回收

回收内容：

• stdout/stderr
• exit_code
• 关键结果文件列表
• 输出目录 manifest
• 结果摘要 json

可选增强：

• 将结果目录再回传到 MinIO：
  • /atp-library/runs/{run_id}/...

这样可支持：

• 后台下载结果
• 历史运行审计
• 二次分析

---

7. API 改造方案

7.1 保留现接口但升级语义（不推荐）

当前 /api/v1/atp/models 的命名会继续误导为“单文本模型”。

7.2 新接口（推荐）

建议新增一组目录化接口：

资料包主资源

• GET /api/v1/atp/assets
• POST /api/v1/atp/assets
• GET /api/v1/atp/assets/{id}
• PATCH /api/v1/atp/assets/{id}
• DELETE /api/v1/atp/assets/{id}

release 资源

• GET /api/v1/atp/assets/{id}/releases
• POST /api/v1/atp/assets/{id}/releases/import
• GET /api/v1/atp/releases/{release_id}
• PATCH /api/v1/atp/releases/{release_id}
• POST /api/v1/atp/releases/{release_id}/activate
• GET /api/v1/atp/releases/{release_id}/files
• GET /api/v1/atp/releases/{release_id}/preview

import job

• GET /api/v1/atp/import-jobs
• GET /api/v1/atp/import-jobs/{job_id}

run

• POST /api/v1/atp/releases/{release_id}/runs
• GET /api/v1/atp/releases/{release_id}/runs
• GET /api/v1/atp/runs/{run_id}
• GET /api/v1/atp/runs/{run_id}/outputs
• GET /api/v1/atp/runs/{run_id}/outputs/download

engine

• GET /api/v1/atp/engine/status

7.3 兼容策略

第一期可保留旧接口 /api/v1/atp/models，但：

• 页面入口迁到新资源
• 旧接口标记为 legacy
• 若必须兼容，则让旧 AtpModelSummary 映射到新 asset 的摘要视图

---

8. 前端改造方案

8.1 页面定位

当前页面：

• web/src/app/admin/power-lines/atp-viewer/page.tsx

它现在混合承载：

• 模型台账
• 模板文本编辑
• 仿真运行
• ATP 文本可视化

这不适合目录化模型管理。

8.2 拆页建议

建议拆成 4 个页面：

A. ATP 资料包管理页

路由：/admin/atp-models

展示：

• 资料包列表
• 电压等级筛选
• 塔型筛选
• 场景筛选
• 状态筛选
• 当前激活 release

B. ATP Release 详情页

路由：/admin/atp-models/[assetId]

展示：

• release 列表
• 关键元数据
• 文件清单
• 校验结果
• 激活/归档按钮

C. ATP 导入页/抽屉

功能：

• 上传 zip
• 选择 mount 中现有目录
• 填写：电压等级/塔型/场景/工况/runner
• 显示导入校验报告

D. ATP 运行页

路由可继续沿用子面板或独立页

展示：

• 选择 release
• 运行参数
• 任务状态
• 结果摘要
• 输出文件下载

8.3 ATP 文本预览功能保留方式

现有“ATP 文本转换与预览”不应删除，但应降级为工具页：

• 输入：从 release 文件清单中选择 work.atp
• 读取后本地渲染
• 不再承担“模型主编辑器”角色

---

9. 分阶段实施计划

Phase 1：目录化元数据落库（最小闭环）

Objective: 能在后台录入 ATP 资料包和 release 元数据，但先不做 zip 自动导入。

Files:

• Create: api/app/models/atp_asset.py
• Create: api/app/schemas/atp_asset.py
• Create: api/app/services/atp_asset_service.py
• Create: api/app/api/v1/atp_assets.py
• Modify: api/app/api/router.py
• Modify: api/app/services/seed_service.py
• Create: web/src/app/admin/atp-models/page.tsx
• Create: web/src/app/admin/atp-models/[id]/page.tsx

Deliverables:

• 资料包 CRUD
• release CRUD
• release 激活
• 文件清单只存元数据，不自动导入

Acceptance:

• 能录入一个 release，指向 MinIO 中某目录
• 能在前端展示该 release
• 能激活切换 release

Phase 2：zip 导入 + manifest 扫描

Objective: 能上传 zip 到 MinIO，异步解压并生成 release。

Files:

• Create: api/app/tasks/atp_asset_tasks.py
• Create: api/app/services/atp_asset_import_service.py
• Modify: api/app/services/storage_driver.py（如需补目录递归遍历辅助）
• Modify: api/app/services/file_service.py（如需复用目录打包逻辑）
• Create: web/src/components/atp-asset-import-modal.tsx

Deliverables:

• upload zip
• import job
• manifest
• 关键文件识别

Acceptance:

• 能导入一个 ATP 目录 zip
• 能识别 work.atp / EGM / exe / 说明文件
• 能生成 release + file 清单

Phase 3：运行时物化到 Wine 根目录

Objective: 运行时不再依赖 atp_text，改为从 MinIO 物化目录后执行。

Files:

• Modify: api/app/services/atp_model_service.py（或拆分为新 atp_run_service.py）
• Create: api/app/services/atp_runtime_materializer.py
• Modify: api/app/services/wine_service.py（如需复用执行封装）
• Modify: api/app/services/legacy_atp_adapter.py

Deliverables:

• release -> local runtime dir
• preprocess -> run -> postprocess
• result harvest

Acceptance:

• 指定 release 可成功同步到本地运行目录
• 调用 tpbig.exe 或 rjtzl.exe
• run 记录中能看到目录来源、工作目录、结果清单

Phase 4：结果产物回写与下载

Objective: 支持结果文件长期归档与下载。

Files:

• Modify: api/app/services/atp_asset_service.py
• Modify: api/app/api/v1/atp_assets.py
• Modify: web/src/app/admin/atp-models/[id]/page.tsx

Deliverables:

• 结果同步回 MinIO
• 结果文件清单下载
• 历史运行追溯

Acceptance:

• 后台能下载某次 run 的关键输出文件
• 结果可回溯到 release 版本

Phase 5：迁移旧 ATP 文本模型

Objective: 把现有 atp_model/atp_model_version 迁移到新体系或降级为 legacy。

策略：

• 短期保留旧表
• 新页面只读 legacy 数据或不展示
• 如确实有价值，把旧 atp_text 版本导出成目录包（单文件场景）迁入新 release

---

10. 关键实现细节

10.1 目录递归枚举能力

当前 storage_driver 公开的是 list_dir(path)，如果要做 release manifest 扫描，需要补一个服务层递归工具：

• walk_virtual_tree(driver, root_path)

要求：

• 返回相对路径列表
• 限制最大文件数/最大深度，避免超大目录拖垮任务

10.2 本地物化安全边界

运行物化目录必须严格限制在：

• settings.wine_allowed_root

例如：

• ./data/wine/atp-runtime/runs/{run_id}

所有同步、脚本执行、exe 调用都只能在这个根内进行，防止目录穿越与任意执行。

10.3 脚本执行白名单

真实 ATP 目录里可能带：

• .py
• .bat
• .cmd

为了安全，第一期建议：

• 仅允许执行 .py
• 且脚本路径必须位于 release 根目录内
• 且必须在 release 元数据里显式配置为 preprocess_script/postprocess_script
• 默认不自动执行任意发现到的脚本

.bat/.cmd/.ps1 第一阶段不要自动执行。

10.4 入口文件发现规则

导入时的默认入口发现：

优先级：

1. 用户手工指定
2. 根目录下 work.atp
3. 唯一的 *.atp
4. 未发现则标记需人工补充

EGM 结果文件类似：

1. 用户手工指定
2. result.txt
3. 唯一的 *_result*.txt

10.5 分类字段规范化

建议新增枚举/规范字典：

• voltage_level: 35/66/110/220/330/500/750/800/1000
• scene_type: fanji/raoji1/raoji2/raoji3/other
• runner_kind: atp/egm/hybrid

tower_type 和 scenario_code 先保持字符串自由录入，避免第一期过度建模。

---

11. 与当前 legacy ATP 适配器的关系

11.1 短期

不要删除 legacy_atp_adapter.py。

应改造为：

• 既能吃老配置
• 也能吃新 release 解析结果

让它从“配置驱动目录执行器”，演进为“目录包运行引擎适配层”。

11.2 中期

把以下逻辑上提为公共运行层：

• 运行目录准备
• 模板目录复制
• 脚本执行
• 结果解析

让 legacy_atp_adapter.py 只保留：

• 特征绑定逻辑
• EGM/ATP 结果合并逻辑

---

12. 风险与影响

风险 1：对象存储目录大、文件多，导入慢

应对：

• 走 import job 异步链路
• 限制单次导入 zip 大小、文件数
• manifest 预扫描超限直接失败

风险 2：Wine 运行依赖本地目录语义，MinIO 无法直跑

应对：

• 明确采用“本地物化后再执行”
• 运行完成后可选回写产物

风险 3：目录内脚本存在安全风险

应对：

• 第一阶段仅白名单 .py
• 必须显式配置
• 严格限制在 wine_allowed_root

风险 4：旧 ATP 文本模型与新目录包模型并存，前后端易混淆

应对：

• 新接口使用 assets/releases 命名
• 旧 models 标记 legacy
• UI 迁移后默认只展示新模型

风险 5：真实 ATP 目录结构不完全统一

应对：

• release 允许手工修正：
  • entry_file
  • result_file
  • egm_subdir
  • preprocess_script
• 不强依赖固定目录模板

---

13. 推荐落地顺序（最务实）

如果要最快闭环，建议按以下顺序推进：

1. 先不上来推翻旧 ATP 模块
2. 先新建 atp assets/releases 模型与接口
3. 先支持“手工录入 storage_root_path”的目录化 release
4. 打通“从 MinIO 目录 -> 本地物化 -> Wine 执行”
5. 跑通后再补 zip 导入/manifest 自动识别
6. 最后再考虑迁移旧 atp_text

这样可以最快得到一个能用版本，而不是一上来做完整导入系统导致战线过长。

---

14. 最小可交付版本（MVP）定义

MVP 应满足：

1. 后台可创建 ATP 资料包
2. 后台可为资料包创建一个 release
3. release 可绑定 MinIO 中一个目录根路径
4. 可手工配置：
   • runner_kind
   • entry_file
   • result_file / egm_subdir
   • preprocess_script
5. 发起运行时：
   • 能把整个目录同步到本地
   • 能运行 Wine + exe
   • 能回收 stdout/stderr/exit_code
6. 后台能看到运行记录

MVP 不要求：

• 自动识别所有目录分类
• 自动解析所有结果格式
• 完整图形化编辑 ATP 文本
• 完整历史迁移旧模型

---

15. 本方案对应的仓库改造重点

后端新增重点

• atp_asset / atp_asset_release / atp_asset_file / atp_asset_import_job
• 目录递归扫描
• MinIO -> 本地物化
• release 运行器
• import job

前端新增重点

• 资料包列表页
• release 详情页
• 导入弹窗
• 运行记录与结果下载

现有代码复用重点

• 文件存储驱动
• MinIO 部署
• Wine 执行
• legacy ATP 目录执行逻辑
• elevation 异步导入样板

---

16. 验收标准

功能验收

• 能上传或绑定一个 ATP 目录包到 MinIO
• 能在后台按电压/塔型/场景检索 release
• 能运行指定 release
• 能拿到运行结果
• 能查看和下载关键输出

架构验收

• 不再要求核心执行必须依赖 atp_text
• 目录包是系统一等公民
• MinIO 是资料包权威存储
• Wine 只消费本地物化运行目录

可维护性验收

• API 命名明确区分 asset/release/run
• legacy 与新体系边界清晰
• 关键目录路径、入口文件、运行器类型可配置

---

17. 一句话结论

推荐把 fquiz 的 ATP 模型管理，从“单 ATP 文本文档管理”升级为“MinIO 承载的目录化 ATP 资料包管理 + 本地物化执行架构”；复用现有文件存储、MinIO、Wine、Celery、legacy ATP 适配器与高程导入链路，按 asset -> release -> file -> import_job -> run 五层模型落地。