# 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` 五层模型落地。**