交付、上线与归档

开发完成与需求完成

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

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

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

后续状态：

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

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

G3

向用户提交：

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

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

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

# ST-XXX 验收与交付报告

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

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

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

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

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

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

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

逻辑归档

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

归档记录.md

归档文档汇总：

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

同时在 STATUS.md 追加：

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

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

后续维护

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

OpenSpec 适配

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

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

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

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

3.2 KiB Raw Blame History Unescape Escape