docs: clarify gateway rollout verification

README.md

@@ -213,12 +213,15 @@ node ./scripts/run-profile.mjs --prefer-state-profile
 
 这个服务会改写目标用户的 Codex `base_url`，属于当前操作链路上的高风险本地网关。后续变更默认按“先对侧宿主、再当前宿主”发布。
 
+`pc` 与 `a100` 的模型都显式设置了 `systemd_unit_manage_state: false`。因此下面的主干 playbook 只负责同步源码、安装 npm 依赖、构建 UI 和渲染 unit，不会自动 restart 或收敛 gateway 的运行状态；playbook 成功不代表新代码已经由当前进程加载。每台宿主完成同步和构建后，必须由操作者在目标服务用户的 user systemd 中显式重启 `codex-retry-gateway.service`，再开始验证。
+
 推荐顺序：
 
-1. 先部署 `a100` 上的 `codex-retry-gateway`。
-2. 在对侧机器的目标用户环境里发起真实 Codex 冒烟请求，不要先改当前正在依赖本机 `4610` 的会话。
-3. 确认健康检查、响应完整性与关键重试行为正常。
-4. 通过后再部署本机，例如 `pc`。
+1. 先部署 `a100` 上的 `codex-retry-gateway`，然后以 `zhouyunyao` 用户显式重启 `codex-retry-gateway.service`。
+2. 确认重启后的 unit 为 `active`，再检查 health 和管理 API，避免对仍在运行的旧进程做出错误判断。
+3. 在对侧机器的目标用户环境里发起真实 Codex 冒烟请求，不要先改当前正在依赖本机 `4610` 的会话。
+4. 确认健康检查、管理 API、响应完整性与关键重试行为正常。
+5. 通过后再以相同顺序部署 `pc`：同步和构建、以 `shujakuin` 用户显式重启、验证 unit 与 API、最后做真实 Codex 冒烟。
 
 推荐部署命令：
 
@@ -226,12 +229,26 @@ node ./scripts/run-profile.mjs --prefer-state-profile
 uv run ansible-playbook playbooks/deploy_managed_systemd_apps.yml -i inventory/hosts.yml --limit a100 -e managed_systemd_apps_selected_names=codex-retry-gateway
 ```
 
+同步和构建完成后，在 `a100` 的 `zhouyunyao` 用户会话中执行：
+
+```bash
+systemctl --user restart codex-retry-gateway.service
+systemctl --user is-active codex-retry-gateway.service
+```
+
 验证通过后，再切到本机：
 
 ```bash
 uv run ansible-playbook playbooks/deploy_managed_systemd_apps.yml -i inventory/hosts.yml --limit pc -e managed_systemd_apps_selected_names=codex-retry-gateway
 ```
 
+随后在 `pc` 的 `shujakuin` 用户会话中执行同样的受控重启和状态检查：
+
+```bash
+systemctl --user restart codex-retry-gateway.service
+systemctl --user is-active codex-retry-gateway.service
+```
+
 真实 Codex 网关冒烟固定显式使用 `gpt-5.6-terra`，不再使用 `gpt-5.4`：
 
 ```bash
@@ -241,10 +258,15 @@ codex --dangerously-bypass-approvals-and-sandbox -c model="gpt-5.6-terra" hello
 建议同时检查：
 
 - `curl http://<listen-host>:4610/__codex_retry_gateway/health`
+- `/__codex_retry_gateway/api/profiles` 等本次变更涉及的管理 API 能正常返回，且当前文本 / 图片 profile 没有被意外切换
 - `/responses` 成功流能完整结束，不会卡 pending；`response.created` 必须带真实 response ID，随后依次可见 `response.in_progress`、输出 delta 与 `response.completed`
 - 容量错误 `Selected model is at capacity. Please try a different model.` 仍能按网关策略自动重试
 
-如果当前对话依赖本机 `4610`，不要把本机作为首个发布目标；先在另一台已接管相同 profile 的机器验证，再回到本机切换。
+通过标准是重启后的 unit 保持 `active`、health 和相关管理 API 正常、真实 Codex 请求完整结束且关键重试行为未回归。任一检查失败都停止后续滚动，不要继续处理 `pc`；应先恢复上一版源码或修复问题，并重新从 `a100` 试点。
+
+R2 `--check --diff` 不安装依赖、不构建 UI、也不重启 unit，只验证目标宿主当前已有源码、依赖、构建产物和运行前置是否满足模型声明。它不能替代上述发布后的运行验证，也不能证明新提交已经被目标进程加载。
+
+如果当前对话依赖本机 `4610`，不要把本机作为首个发布目标；先在另一台已接管相同 profile 的机器验证，再回到本机切换，且 `pc` 必须是最后一个处理的宿主。
 
 ## 如何恢复