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。反饋先應用於當前任務；只有用戶明確要求記住並確認具體規則與作用域後，才允許持久化。學習規則不能覆蓋當前指令、階段門禁、事實核驗、版本管理或授權邊界。