---
name: soloforge-deployment
description: 生成可构建、可启动、可探活、可测试的容器化部署资产。
when: 容器化部署 / deployment / build 阶段
---

# 容器化部署资产

## 适用性

仅在项目声明 `deployment.method: docker_compose`，需要用 Compose 构建、启动并验证组合环境时使用。单容器由平台直接构建、Serverless、裸机或其他运行方式应明确不适用并使用真实资产，不为门禁创建无用 Docker/Compose 文件。

## 事实输入

- 实际工程目录、构建产物、启动命令、端口和健康检查。
- 依赖服务、数据初始化、环境变量、密钥来源和网络关系。
- 前端路由、后端 API、E2E 场景和目标平台限制。
- `examples.md` 的正反例。

## 关键决策

- 每个独立发布单元如何构建、启动、探活和停止。
- 镜像基础版本、非 root 用户、缓存、多阶段构建和运行时最小权限。
- E2E 是否适用以及所需种子数据和服务就绪条件。

## 产出方法

1. 为 Compose 中使用本地 build context 的真实发布单元提供 Dockerfile；使用远端镜像的服务不伪造 Dockerfile，共享库不单独容器化。
2. 用 compose 编排必要依赖，声明健康检查和依赖就绪条件。
3. 前端项目按实际静态托管方式提供路由回退和反向代理配置。
4. 沿用项目已选择的浏览器 E2E 工具和真实运行配置，不为通过门禁额外引入指定框架。
5. 在本地或等价环境实际执行构建、启动、探活、测试和清理。
6. **切片级交付纪律**：每个切片完成（非仅任务收尾）都须重建受影响镜像并启动验证——UI 渲染、核心交互、业务逻辑三层的端到端确认，不只依赖单测/IT 绿（测试绿 ≠ 部署能跑：Dockerfile/CQL/配置/健康检查问题只在真实容器暴露）。改前端必重建前端镜像（multi-stage COPY dist 非挂载，旧镜像含旧构建）。

- 部署链四环节逐一确认：代码提交→镜像构建部署→前端产物构建→客户端上传/刷新——用户实测前逐环节核对（产物特征 grep+时间戳定位法），任何一环旧产物都会造成假性「修复无效」。
- 构建生命周期钩子全环境矩阵验证：往构建链挂任何钩子前，枚举该生命周期全部触发环境（本地/CI 各步骤/Docker builder/服务器）逐环境核三问——文件在不在（Docker 只 COPY pom+src 时钩子文件不在镜像）/工具链有没有（builder 镜像可能无 python3/node）/语义该不该跑（CI 受控环境由前置步骤承担，镜像构建 -Dskip）。

## 禁止项

- 不得把密钥写入镜像、仓库或 compose 默认值。
- 不得用 sleep 代替健康检查，不得假设固定端口或服务名。
- 不得留下只能构建不能启动、只能启动不能探活的配置。
- 不得把 operate 域的发布方案文档与本运行资产混为同一产物。

## 交付自检

- 所有发布单元与架构和磁盘目录一致。
- 构建上下文、复制路径、启动命令和健康检查真实存在。
- 重复启动、失败退出和清理不会污染后续验证。
- E2E 使用真实 URL、数据和等待条件，没有硬编码假通过。

## 权威验证

调用 `sf_verify action="full" task_id="当前任务ID" artifact="deployment"`，执行当前声明可确定的 build、启动和 HTTP 探活。业务 E2E 若适用，应通过项目真实测试命令或测试报告另行留证；full 不会把未执行的 E2E 写成已通过。任一步失败都修复后重新完整验证。


## 交付前对抗审查

`sf_verify` 通过只证明结构/编译/测试层；语义质量（承接正确性、异常/并发/权限/边界是否可靠、是否含空话或无法证伪的承诺）须经独立对抗审查。advance/deliver 前用 `sf_review action="start" task_id="当前任务ID" artifact="<本产物 kind>"` 发起 per_artifact 审查，用**独立 session/subagent**（非产出本产物的同一会话）执行返回的 prompt、submit findings，按 next_step 完成 K 次独立采样与闭环。deliver 会阻断未完成/未闭环的审查；活跃豁免与被驳回 error 会被注入审查 focus 供独立复核。