# 需求補全規則

這份文件是 `/sdlc-plan` 判斷需求內容是否足夠清楚、可驗收的規則正本。

## 需求的四個必要維度

每個需要實作的需求都要能回答：

1. **角色** — 誰需要這個結果，或誰執行這個行為？
2. **情境** — 在什麼觸發條件、前置條件或使用情境下發生？
3. **行為** — 角色做了什麼，或系統需要處理什麼？
4. **可觀察結果** — 外部使用者、呼叫端或驗收者能觀察到什麼結果？

只寫功能名稱、畫面名稱、API 名稱或實作方法，不足以視為完成。

## 情境覆蓋

- 至少確認主要成功情境。
- 若需求有權限、取消、重試、空值、重複執行、並行、極大量或外部來源失敗等可能性，逐一確認適用的失敗或邊界情境。
- 不適用的情境必須由使用者明確確認「不適用」，並說明原因；agent 不得自行判定。

## 提問格式

一次只問一個最高價值的缺口。每題依序提供：

- **目前理解**：根據輸入與已確認回答整理的一句話。
- **缺少內容**：指出哪個必要維度或情境仍不清楚。
- **為什麼需要**：說明它會影響哪個目標、範圍或驗收結果。
- **建議回答**：提供具體選項或短範例。
- **自由回答**：明確允許使用者改寫或提供其他答案。

建議選項是協助理解，不是替使用者做決策。

## 查證與提問邊界

- 能從輸入、既有議題或可取得的 repo 內容查證的事項，先自行查證。
- 只有需要需求擁有者決策的事項才提問。
- 不把架構、資料表、模組或其他實作方案當成需求答案；這些交給 `/sdlc-analyze`。
- 不把 agent 的推測寫成使用者已確認的需求。

## 回答狀態

- 具體回答可填入工作稿，並重新檢查所有必要維度與情境。
- 使用者明確確認「不適用」且提供原因，可標記該項已完成。
- 未回答、拒絕回答、「不知道」或「尚未決定」都仍是缺口，不得填成已確認。
- 仍有缺口時不得建立需求議題；應繼續一次問一題。

## 建立前完整性閘門

建立需求議題前必須確認：

- 九個段落都有實質內容，或使用者已確認不適用並說明原因。
- 需求的角色、情境、行為與可觀察結果完整。
- 主要成功情境已確認；適用的失敗與邊界情境已確認。
- 沒有未回答或「尚未決定」的阻塞缺口。
- 驗收標準描述外部可觀察結果，不綁定不必要的實作細節。
- 內容前後一致，且非目標足以限制範圍。

通過閘門後才可套用需求議題模板、查標籤與建立議題。