# 交付、上线与归档

## 开发完成与需求完成

Review、逻辑验证和冒烟通过后，子任务可标记：

```text
逻辑验证：已完成
子任务：开发完成 / 待提测
```

这不等于需求已测试、上线或归档。

后续状态：

```text
开发完成 → 待提测 → 测试中 → 测试通过
→ 待发布 → 已上线 → 上线验证通过 → 已归档
```

测试失败时返回实现阶段，完成修复、Review、验证和重新提测，并追加状态历史。

## G3

向用户提交：

- `04.技术实现记录.md`；
- `05.代码Review报告.md`；
- 已填写执行结果的 `03.冒烟与逻辑验证.md`；
- 功能完成与未完成项；
- 验证证据；
- 遗留问题和风险；
- 是否具备提测条件。

用户确认后将 G3 标记为通过，进入测试人员提测流程。

## `06.验收与交付报告.md`

```markdown
# ST-XXX 验收与交付报告

## 1. 交付信息
- 需求版本：
- 涉及工程：
- 开发分支：
- 发布分支或 Tag：
- 发布 Commit：

## 2. 开发交付内容
## 3. 测试结果
- 测试环境：
- 测试时间：
- 测试人员：
- 测试结论：
- 缺陷及处理：
- 测试报告：

## 4. 发布记录
- 发布时间：
- 发布环境：
- 发布版本：
- 发布工程：
- 数据脚本：
- 配置变化：
- 实际顺序：

## 5. 上线验证
- 核心主流程：
- 关键接口：
- 数据库：
- Redis：
- Elasticsearch：
- 消息和任务：
- 日志和监控：

## 6. 遗留问题
## 7. 最终结论
```

外部测试报告可以保存链接、编号或副本，不必重复全文。

`git add`、`git commit`、`git push` 均由用户执行。Agent 可以读取并记录用户完成后的发布分支、Tag 和 Commit。

## 逻辑归档

归档不移动大需求目录。测试通过、上线并完成上线验证后，在大需求根目录维护一份：

```text
归档记录.md
```

归档文档汇总：

- 基本信息、最终需求版本和时间；
- 最终范围、延期或取消内容、需求变化；
- 子任务完成情况；
- 各工程发布分支、Tag、Commit 和时间；
- 数据库、Redis、ES、配置和迁移；
- Review、冒烟与逻辑验证、测试和上线结论；
- 关键文档相对链接；
- 遗留问题、风险和后续维护建议；
- 最终归档结论。

同时在 `STATUS.md` 追加：

```text
已上线 → 上线验证通过 → 已归档
```

目录、原始需求版本和历史状态不得删除。`code/` 副本即使以后继续更新，归档文档也必须保留本次实际发布的 Tag 和 Commit。

## 后续维护

归档事实记录原则上不直接改写。后续优化或修复建立新需求或维护任务，关联原 PM、最终需求版本和上线 Commit。

## OpenSpec 适配

默认归档载体为 `归档记录.md`。项目启用 OpenSpec 时，将其作为可替换归档后端：

```text
management 过程文档
→ 字段映射或转换
→ OpenSpec 归档
```

初期保持 management 文档为过程事实来源，避免人工双写。项目级适配规则应规定字段映射、归档命令、幂等、失败回退、状态同步和后续维护。

OpenSpec 的引入不得改变前置开发流程、文档编号、需求追溯和状态历史。