Scope engine image builds and verification by release target

README.md

@@ -4,8 +4,9 @@
 的方式：标签触发 `.gitea/workflows/docker-build-push.yml`，runner 检查元数据、构建并推送镜像，
 最后调用 ModelHub 的 `image-verify` 接口注册验证。
 
-当前为 A100 参考端、寒武纪 MLU370 x4/x8、沐曦 C500 和 Vastai VA16
-构建四个镜像，五个 GPU 共用 `vllm_qwen25_compat` 框架名。基础镜像均来自
+支持 A100 参考端、寒武纪 MLU370 x4/x8、沐曦 C500 和 Vastai VA16；
+一次显式全量发布构建四个镜像，五个 GPU 共用 `vllm_qwen25_compat` 框架名。
+寒武纪 x4/x8 共用一个镜像，但仍分别进行平台验证。基础镜像均来自
 平台已有验证任务使用的版本；A100 沿用示例仓库的基础镜像。每个 GPU 的注册
 与可用性仍以平台镜像验证结果和 `frameworks` 接口回读为准。
 
@@ -52,14 +53,21 @@ docker build --build-arg BASE_IMAGE=harbor.4pd.io/modelhubxc/sunruoxi/enginex-va
 
 ## 用 runner 发布
 
-1. 源码在公开仓库 `a4913994/enginex-qwen25-compat` 的 `main`；`v0.1.0`
-   已完成 A100/寒武纪镜像构建并提交镜像验证，验证结果须单独回读。
+1. 源码在公开仓库 `a4913994/enginex-qwen25-compat` 的 `main`。推送源码不会构建镜像；
+   只有带目标后缀的版本标签才触发 runner。历史 `v0.1.0` 和 `v0.2.1` 的镜像验证
+   结果仍须单独回读。
 2. runner 使用 `DOCKER_REGISTRY`、`DOCKER_USERNAME`、`DOCKER_PASSWORD`、
    `FIXED_TOKEN`；不要把凭证写进仓库。
-3. 推送新的 `v*` 标签后，工作流依次跑单元测试、验证 GPU/任务元数据、构建与推送
-   镜像，并为五个 GPU 各发起一次镜像验证；接口业务码也会被检查。
-4. 在“我的驱动列表”确认五个镜像验证通过，并检查新框架出现在对应 GPU 的
-   `frameworks` 接口中，再用少量已知缺陷模型做对照验证。
+3. 选择本次确实需要更新的镜像目标，推送 `vX.Y.Z-nvidia-a100`、
+   `vX.Y.Z-cambricon-mlu370`、`vX.Y.Z-metax-c500` 或 `vX.Y.Z-vastai-va16`。
+   例如 `v0.3.0-metax-c500` 只构建一份沐曦镜像并验证沐曦 C500；寒武纪标签
+   构建一份镜像并分别验证 x4/x8。只有明确使用 `vX.Y.Z-all` 才构建四份镜像、
+   发起五项验证。普通 `vX.Y.Z` 标签不触发工作流，也不会隐式全量发布。
+4. 工作流先跑单元测试和目标 GPU 元数据校验，再构建、推送选定镜像并检查平台
+   `image-verify` 接口业务码。通过本目录的 `python release_plan.py v0.3.0-metax-c500`
+   可以在打标签前预览将构建与验证的目标。
+5. 回读平台镜像验证记录，并检查新框架出现在目标 GPU 的 `frameworks` 接口中，
+   再用少量已知缺陷模型做对照验证。`pending` 不代表镜像已经可用。
 
 只有平台确认新框架可选且 A100 参考端实际使用新镜像后，才应让 `xc-agent` 把
 列表型 `extra_special_tokens` 的模型路由到此框架。当前智能体继续预检并跳过它们。