用途：编排 OpenEnv 仓库内嵌的部署工具，并记录 openenv 命名空间的规范化流程，把环境发布到 Hugging Face Spaces 并保持规范引用同步。
前提：hf CLI 已认证（hf auth login 或设置 HF_TOKEN）；本地构建依赖已安装，使 scripts/prepare_hf_deployment.sh 能暂存 Docker 上下文；可访问 scripts/manage_hf_collection.py。
主要流程：用 scripts/prepare_hf_deployment.sh 暂存环境，默认部署 envs/ 下所有可部署环境，--env <name> 指定子集。脚本解析 OpenEnv ref 重写依赖，把松散的 openenv-core[core]>=... 与 Dockerfile 直接安装改写为 git+https://github.com/meta-pytorch/OpenEnv.git@<resolved-ref>；构建含 src/、envs/<env>/ 与重写 Dockerfile 的暂存树；生成带 Hub 元数据的 README，强制 openenv/openenv-<version> 标签；用 hf repo create/hf upload 推送 Docker spaces。
命名与隐私：部署到私有空间 <env>-0.2.2（SPACE_SUFFIX=-0.2.2 或版本默认），--private 保持集合私有；此阶段只更新带版本的集合，不动全局标签集合。
运行时验证：私有空间通过已认证的 hf.space 域验证，用 scripts/verify_private_spaces.py --hf-namespace openenv --suffix -0.2.2，或 hf spaces info 与 runtime.raw.domains；用 hf spaces ls --expand=runtime 确认 RUNNING/SLEEPING。不要仅凭 /health 判断，本次扫描发现 /health 返回 200 但 /reset 返回 500 的假阳性。HTTP 环境最低可用门槛是已认证 POST /reset，简单 schema 再补 POST /step 探测；git_env、unity_env 等 20 秒探测可能超时，视为不确定。规范空间可能有多个 READY 域，需逐一探测直到某个返回可用数据。
规范更新决策：仅当私有 -0.2.2 候选构建并通过健康检查时，无后缀规范环境才指向 main；失败则保持规范引用不变，并把该环境 pyproject.toml 依赖固定为 <0.2.2。成功则用 scripts/manage_hf_collection.py --version 0.2.2 --collection-namespace openenv --skip-global-collection --space-id <space> 加入私有版本集合。注意仓库名不匹配：repl_env -> openenv/repl，tbench2_env -> openenv/tbench2，textarena_env 可能对应 openenv/sudoku、openenv/wordle 等产品化别名。
集合处理：以单一发布元组运行 manage_hf_collection.py，默认把发现的带标签空间加入版本集合，创建或复用 slug OpenEnv Environment Hub <version>；对每个成功重部署的带后缀空间显式提供 --space-id。
工具链提醒：始终在仓库根目录运行发布脚本；Docker 构建开始时保持 uv sync 分离；仅验证构建可用 --skip-collection；私有空间匿名请求返回 404，需用已认证头。若带后缀仓库已含修复但 HF 仍显示旧 BUILD_ERROR，可用 HfApi().restart_space(..., factory_reboot=True) 强制重建。暂存旧 Dockerfile 时注入 COPY src/openenv/ /app/src/openenv/ 并仅把 /app/src 放入 PYTHONPATH，避免遮蔽标准库 types 导致 ImportError。
环境特定修复：browsergym_env 尽量用固定 tarball 快照而非构建时克隆 MiniWoB++；websearch_env 构建镜像需先有 git；maze_env 与 snake_env 需调整 PYTHONPATH。
发布后清理：记录通过/失败环境，失败者保持固定在 0.2.2 以下；提升到规范发布后归档或删除测试后缀空间；保存 hf spaces info/health 输出作为发布简报依据。