Atlas-KK/prd-lifecycle

PRD Lifecycle

将原本分散的 PRD 创建、补全、评审和执行规划能力统一到一个入口，同时保留各阶段不同的权限边界和确认门禁。

模式路由

先判断用户当前拥有的材料与期望产物，只进入必要模式，不强迫用户从头走完整流程。

模式	典型输入	主要产物	关键边界
create 创建	功能构想 + 现有仓库	现状报告、确认基线、版本化 PRD	先取证、逐轮确认，未批准基线前不生成 PRD
refine 补全	PRD/需求草稿	分步修订稿、版本历史、可选 .docx	每步先审阅，确认后才写入和升版
review 红队评审	指定 PRD + 可选基线/仓库	分级问题、证据、修订建议	只评审，不改文档、不实现代码
execute 执行规划	已批准 PRD + 现有仓库	就绪审计、开发执行文档、追踪矩阵、控制提示词	只规划，不修改 PRD、不实现代码

路由规则：

• 只有构想，且希望结合现有项目形成 PRD：使用 create。
• 已有草稿，目标是补全、修订、精修或产出定稿：使用 refine。
• 目标是找矛盾、风险、遗漏或不可验收项，不要求代改：使用 review。
• 已有明确批准版本，目标是交给 Codex 分阶段开发：使用 execute。
• 用户要求端到端处理时，从最早适用阶段开始；每到下述门禁都停下等待授权，不自动跨阶段。
• “审一下”若同时可能表示评审或代改，优先采用只读的 review，并说明评审结果可在用户另行授权后进入 refine。
• 用户只想评估并实施现有仓库中的局部代码、UI、交互、重构或架构改动，使用 repo-grounded-change；不要强制先写 PRD。

共享约束

权威顺序

除非用户另行指定，按以下顺序处理冲突：

1. 用户当前明确指令。
2. 当前任务中已明确确认的决定。
3. 指定的已批准需求基线与 PRD。
4. 当前代码和测试所证明的既有行为。
5. 当前产品文档。
6. 历史草稿、评审记录和建议。

目标 PRD 不是天然正确的；出现冲突时展示冲突、影响和所需决定，不静默选边。代码用于证明现状，不能否定已经批准的新需求。

事实与建议标签

在结论可能被混淆时使用：已确认、代码事实、文档事实、产品假设、技术建议、待确认、本期不实现。

授权边界

• 不臆造业务规则、状态、阈值、权限、优先级、依赖、外部集成或验收标准。
• 不把阶段完成、评审通过或计划生成视为实现授权。
• 不修改业务代码，不提交、推送、部署，不调用外部生产系统。
• 检查工作树并保护用户已有修改；无法安全避让时停止并说明重叠区域。
• 只执行用户请求的当前模式。进入下一模式必须有明确请求或确认。

create：仓库取证后创建 PRD

1. 读取 project-discovery.md，检查仓库、产品资料、测试和工作树，输出当前状态报告。除非用户明确要求合并流程，否则停下等待现状确认。
2. 读取 clarification-rounds.md，根据证据缺口规划主题。每轮只讨论一个主题，提出 1–3 个互斥选择题；推荐项在前并说明影响。
3. 用户回答后先总结本轮已确认项、未确认项、冲突和下游影响，再等待本轮总结确认。未确认不得进入下一主题。
4. 所有相关主题确认后，读取 baseline-and-prd.md，生成需求确认基线并停止。
5. 只有用户明确批准基线并要求生成 PRD 后，才创建版本化 PRD；搜索已有版本并递增，不静默覆盖。

完成标准：PRD 与确认决定一致，范围和非目标明确，需求与验收可追踪，仓库影响有证据，未决事项没有伪装成最终要求。

refine：分步补全与版本化修订

1. 读取完整原文，保留原意并建立工作基线。若需要新建 Markdown 工作文档，使用 scripts/prd_doc.py init 建立 v1.0 和章节骨架。
2. 读取 refinement-steps.md 当前步骤的小节。默认骨架为：
   • 需求澄清与用户故事；
   • 功能方案；
   • 边界条件；
   • 验收标准。
3. 一次只做当前步骤。先在对话中呈现待审阅内容，不提前写入文件。
4. 用户要求修改或补充时留在当前步骤，不升版。只有用户明确确认后才写入文档，并按 versioning.md 执行 minor 升版和修订记录。
5. 需要指标、依赖排期、风险回滚、合规或评审意见回填时，可插入扩展步骤；同样执行“产出 → 审阅 → 确认 → 写入 → 升版”门禁。
6. 全部步骤确认后，整稿合并并执行 major 升版。用户要求 .docx 时使用 scripts/prd_doc.py export，并按可用文档工具完成版式验证。

每步内容既要补全，也要指出原文中的空泛、矛盾、不可验证项和易漏场景。用户故事、功能、边界和验收之间必须可回溯；验收项应包含明确条件和可观测结果。

完成修订不等于 PRD 已获业务批准，也不自动进入 review 或 execute。

review：证据化红队评审

1. 读取 review-protocol.md，确认目标版本、评审范围、权威来源、仓库证据和缺失材料。完整阅读目标 PRD。
2. 提取范围、类型、状态、阈值、权限、数据、时间、优先级和验收不变量。
3. 读取 finding-taxonomy.md，分别检查基线回归、内部一致性、生命周期、数据历史、接口幂等、权限审计、原型边界、NFR、可执行性和 FR/AC 追踪。
4. 去重后仅保留有证据、有后果、可修正的问题。不要为了显得全面而制造发现。
5. 读取 review-report.md，给出 Pass、Pass with changes、Blocked 或 Limited review，并按严重度输出发现、证据、影响与最小修正建议。

评审默认只读。即使发现明显问题，也不得直接修改 PRD；用户授权修订后再进入 refine。

execute：转为 Codex 开发执行文档

前提是存在可识别版本的已批准 PRD。修订完成或红队通过本身不等于批准。

1. 读取 readiness-audit.md，核对 PRD 版本、确认基线、目标发布范围、未决事项、当前仓库和测试，形成差距表与就绪结论。
2. 若产品行为无法唯一确定、权威冲突、验收不可观察或需要未经授权的依赖/集成/迁移，结论为 BLOCKED 并停止，不把问题藏进技术假设。
3. 读取 execution-document.md，定义满足 PRD 的最小架构边界、所有权、状态、数据、接口、持久化、时钟、降级和既有系统保护。
4. 从只读 Phase 0 开始，创建依赖有序、独立可审阅的阶段。每阶段写明 FR/AC、文件范围、禁止事项、测试、验收证据、质量门禁和停止门禁。
5. 读取 traceability-and-gates.md，映射每个范围内 FR/AC 到阶段、代码区域、测试和证据，识别孤儿需求与越权工作。
6. 读取 codex-control-prompt.md，生成总控提示词和单阶段提示词。提示词必须保留版本、权威顺序、真实测试、用户改动保护和逐阶段授权。

完成标准：另一个 Codex 实例能从只读审计开始，只执行一个获批阶段，以真实命令验证、报告追踪结果并停止；文档明确假设、排除项、阻断项、延期项和受保护行为。

阶段衔接门禁

• create → refine：仅在用户认为已生成 PRD 仍需补全或修订时进入。
• create/refine → review：必须由用户明确要求评审；评审不自动代改。
• review → refine：用户明确授权处理指定发现后进入，逐项保留发现 ID 与修订映射。
• create/refine/review → execute：必须明确指定“已批准”的 PRD 版本和目标发布范围。
• execute → implementation：执行文档只提供控制计划；实际实施必须由用户在后续任务中单独授权。

反馈学习

工作流开始时读取 feedback-learning.md 和 learned-guidance.md。反馈先应用于当前任务；只有用户明确要求记住并确认具体规则与作用域后，才允许持久化。学习规则不能覆盖当前指令、阶段门禁、事实核验、版本管理或授权边界。