Feature Lifecycle Sample

下面用一个虚构 feature feat-12-user-billing-reconciliation 演示统一规范下的完整生命周期。

1. Draft

创建目录：

planning/backlog/active/feat-12-user-billing-reconciliation/
  PRD.md
  execution-plan.md
  acceptance-checklist.md

此时建议：

• PRD.md 状态写为 Draft
• execution-plan.md 先建立基本推进骨架
• acceptance-checklist.md 先建立验收结果框架

2. Ready

当问题定义、目标、非目标和主要验收方向已经稳定后：

• PRD.md 状态切到 Ready
• execution-plan.md 写清本轮实施范围与阶段拆分
• acceptance-checklist.md 填入关键结果项

此时 feature 仍在 active/

3. Active

当 feature 进入正式推进窗口后：

• 主文档状态切到 Active
• execution-plan.md 开始按阶段推进
• 若出现局部决策争议，可新增 decision-<topic>.md

4. Implemented

当主要实现已经进入主线，但文档、索引、验证或收尾还没完全追平时：

• PRD.md 状态切到 Implemented
• feature 继续留在 active/
• active/README.md 应显式写明它是“已实现但未验收完成”
• 若只剩窄范围收尾，可新增 handoff-<topic>.md

这是统一规范里很重要的中间状态，用于真实反映项目现场。

5. Accepted

只有在以下事项都完成后，才把目录整体迁移到 accepted/：

• PRD.md 状态切到 Accepted
• execution-plan.md 写明收尾结论
• acceptance-checklist.md 已追平当前现实
• backlog 索引已同步

迁移前：

planning/backlog/active/feat-12-user-billing-reconciliation/

迁移后：

planning/backlog/accepted/feat-12-user-billing-reconciliation/

6. Archived

如果这条 feature 后续只需要保留历史参考，不想继续混在现行已完成列表里，可以再迁入：

planning/backlog/archive/feat-12-user-billing-reconciliation/

这表示历史层级变化，不表示需求语义重新打开。

7. Superseded Decision

如果 feature 内出现一个局部提案，例如 decision-naming-guardrail.md，后续证明它不成立：

• 不新开新编号
• 直接在原目录中把该文件状态标为 Superseded
• 在主 PRD.md 或当前实施文档中明确它不再作为有效决策真源