# 部署配置

> **事实纪律**:只列真实存在或本次明确新增的环境、服务、变量和能力。未知项写“待确认”；合法不适用项写 `N/A（原因）`，不得预填通用拓扑。

> **产物定位**:operate 能力域必出。把环境、依赖、部署方式、健康检查、回滚定清楚。
> **核心纪律**:部署失败后可恢复到已知安全状态；敏感配置由目标平台的密钥机制注入，不进入代码或制品。
> **反退化纪律**:环境变量/依赖服务/监控告警/恢复方案等表格须逐条填写真实值,禁止空单元格、禁止「…」占位。

## 1. 环境规划
| 环境 | 用途 | 访问范围 | 数据来源 | 配置差异 |
|------|------|---------|---------|---------|

## 2. 环境变量与密钥
| 变量名 | 用途 | 是否敏感 | 默认值 | 各环境取值来源 |
|--------|------|---------|--------|--------------|

> 敏感变量必须走密钥管理或平台注入，禁止写入镜像、制品或代码。

## 3. 部署架构与制品

> 部署单元来自架构中的 `release_unit`，共享库不单独发布。运行方式可以是 Compose、Dockerfile、平台构建、Serverless、裸机或其他真实方式；只记录当前项目实际采用的资产。使用 Compose 时，Dockerfile 放对应工程目录，编排文件和反向代理位置以 project map 与仓库事实为准。

| 部署单元（工程） | 运行/发布方式 | 制品或入口 | 编排/平台对象 | 对外暴露 |
|----------------|--------------|-----------|--------------|---------|
| | | | | |

> `intent.yaml` 明确声明 `deployment.method: docker_compose` 时，`deploy_config` 的完整验证要求文档结构与 Compose 声明一致；build 能力域的 `deployment` 产物再负责可构建、可启动和 HTTP 探活。业务 E2E 若适用，必须引用项目实际执行证据，不能由文档或容器存在性代替。其他部署方式不得为过门禁伪造容器资产。

## 4. 依赖服务
| 服务 | 用途 | 版本 | 访问方式 | SLA/可用性要求 | 失败降级 |
|------|------|------|---------|--------------|---------|

## 5. 部署方式
- 部署形态及选择依据:
- 镜像/制品/包来源:
- 当前平台的实际发布流程:

### 多端部署矩阵（涉及前端 FE-* 时填；无前端写 `N/A（原因）`，不得据此推断只有一个部署单元）

| 端(FE-*) | 部署方式 | 制品来源 | 域名/入口 | 与后端依赖 |
|-----------|---------|---------|----------|-----------|
| | | | | |

> 是否独立发布以架构中的发布单元为准；端间依赖和流量入口必须显式声明。

## 6. 健康检查与资源
| 项 | 配置 |
|----|------|
| 健康检查端点 | |
| 就绪检查 | |
| 存活检查 | |
| CPU/内存限制 | |
| 副本数/扩缩容策略 | |

## 7. 监控告警
| 指标 | 告警阈值 | 处理动作 |
|------|---------|---------|

## 8. 回滚与恢复方案(必填)
| 场景 | 恢复方式 | 目标时长 | 验证方法 | 触发条件 |
|------|---------|---------|---------|---------|

> 恢复目标与演练时限必须来自业务 SLO 和实测能力；没有预发环境时使用与生产风险等价的隔离环境，并明确差异。

## 完成判定

- [ ] 所有真实环境及其差异已记录；不存在的环境未被虚构
- [ ] 敏感变量标注并走密钥管理(无硬编码)
- [ ] 依赖服务列出失败降级
- [ ] 每个运行单元有适合其平台的健康/完成信号；不支持就绪或存活探针时写明替代判据
- [ ] 监控告警覆盖当前服务真正可观察的技术与业务失败；不强制不存在的错误率、延迟或资源指标
- [ ] 回滚、前向修复或备份恢复路径与变更风险匹配且可演练
- [ ] 各配置表格逐条填真实值,无空单元格/无「…」占位