deploymentlisted

# Deployment Standards > 本规范聚焦**容器化部署修复的验证门**——适用于全栈 Docker Compose 化项目（典型架构 caddy + frontend + backend + worker + postgres + redis）。任何 `gh issue close` 涉及容器内代码 / 配置变更的 fix，必须满足本规范"容器/服务重建后 curl 实证修复生效"门槛。 **触发来源**：RolexOps 实战 issue audit（不随模板分发）Systemic Pattern 2 "Premature Close" — 修复代码已 commit 但容器未重建 → close 时修复实际未上线，后续 hot-fix 才含真正容器重建。本节是防同类 Premature Close 的强制门。 ## 1. 适用范围 | 类型 | 是否触发本规范 | 备注 | |---|---|---| | `backend/app/**` Python 代码 | ✅ 是 | uvicorn / taskiq worker 都在容器内跑 | | `frontend/src/**` TS/TSX 代码 | ✅ 是 | Vite build 产物烘焙进 caddy 容器 | | `alembic/versions/**` migration | ✅ 是 | upgrade 必须容器内 `alembic upgrade head` | | `models.toml` / `prompts/**` | ✅ 是 | 容器 image 内固化或 bind-mount 取决于配置 | | `docker-compose.yml` / `Dockerfile.*` | ✅ 是 | compose 配置变更必须 `up -d --build` 双验 | | `.claude/**` / `docs/**` / `progress/**` | ❌ 否 | 纯文档 / agent 配置，不入运行时容器 | | `e2e/**` Playwright 测试 | ❌ 否 | 宿主机跑，不打容器 image | **判定原则**：变更最终要进 docker image 或被容器 process 读取的，**必须**容器重建后实证；只动文档 / `.claude/` / 宿主机 dev 工具的不触发。 ## 2. P0 / P1 修复 Close 前的强制门 close `priority:P0` / `priority:P1` 的 bug fix issue 前，product-lead 必须完成以下 3 步并把证据写入 close 公告： ### Step 1: 容器重建 ```bash # 全栈重建（保险但慢） docker compose up -d --build # 或精确重建受影响服务（更快，确认服务清单后再用） docker compose up -d --build <service-name> # backend / worker / frontend / caddy ``` **禁止**：仅 `docker compose restart <service>`——restart 只重启 process 不重建 image，新代码不会进容器（**正是 #37 的失败模式**）。 ### Step 2: curl 实证 AC 边界（真实输出，非 dry-run） 对照 issue / PRD AC 边界跑真实