first commit

vibe-coding-governance/references/09-交付与归档.md

@@ -0,0 +1,128 @@
+# 交付、上线与归档
+
+## 开发完成与需求完成
+
+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 的引入不得改变前置开发流程、文档编号、需求追溯和状态历史。