feat(交付與共識): 交付工作包獨立為 WP-01、新增交付內容型別與共識判定規則

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

references/consensus.md

@@ -0,0 +1,38 @@
+# 共識判定 — 規劃與分析階段的提問規則
+
+`plan` 與 `analyze` 都靠提問把需求問清楚。兩個階段共用本規則，各自不再重寫一份。
+
+## 一輪不算問完
+
+- **每個回答都要生出下一個問題**：從使用者的答案往下推，找出它新暴露的未知，繼續問。答完一輪就收工是最常見的失敗。
+- 問題一次只問一件事，選項一律標明影響範圍（依 `jsc-ask:ask`）。
+- 問過的別再問：先查 wiki 的 `QUESTION_CONTENTS` 與 `QUESTION_{HASH}`，已答的直接沿用。
+
+## 達成共識的兩個條件
+
+同時滿足才算共識，缺一不可：
+
+1. **沒有未知會改變產出**——任何還沒問清楚的細節，都不足以改變使用者故事、工作包切分或工時估算。
+2. **使用者明確確認**——把整理過的結論讀回去，使用者明確表示同意。
+
+## 每輪都要讓共識可見
+
+提問前先攤開現況，不要讓使用者自己記：
+
+| 區塊 | 內容 |
+| --- | --- |
+| 已達成共識 | 已確認的項目與結論 |
+| 尚未釐清 | 還開著的項目，以及它會影響什麼 |
+| 本輪要問 | 這一輪要解決哪一項 |
+
+## 不可以做的事
+
+- **不得用自己的假設補洞**。缺資訊就問，不能先寫下去再說。
+- **不得把沉默或「都可以」當成答案**——只要該項會改變範圍或切分，就要追問到具體選項。
+- **不得在還有開著的項目時往下走**（規劃不得產出使用者故事，分析不得開始 WBS）。
+- 使用者確實不想決定時：把它當**未決項**寫進頁面，註明影響與預設處理方式，並問使用者要不要接受那個預設值。未決項不得靜默消失。
+
+## 收尾
+
+- 共識達成後，把「問了什麼、答了什麼」依 `jsc-ask:ask` 規則回存 wiki，讓下一階段不必重問。
+- 頁面上的未決項要能追：誰要決定、什麼時候決定、不決定會怎樣。

references/deliver-formats.md

@@ -0,0 +1,58 @@
+# 交付內容型別
+
+交付／交接工作包開工時，先跟使用者確認這份交付要產出什麼內容。預設選項固定兩個，其餘由使用者輸入。
+
+| 選項 | 內容 |
+| --- | --- |
+| 1. API 文件 | 端點路徑、輸入參數（**全部**）、輸出參數（**全部**）；見下節 |
+| 2. 由使用者輸入 | 使用者自己講要什麼內容；照使用者說的做，不套 API 文件格式 |
+
+選項一律依 `jsc-ask:ask` 規則呈現，並標明影響範圍。**不得自行預設，也不得跳過詢問。**
+
+## API 文件
+
+### 必備欄位
+
+| 區塊 | 要求 |
+| --- | --- |
+| 端點路徑 | 方法與完整路徑（例 `GET /v1/members/{id}`），含版本前綴 |
+| 輸入參數 | **列出全部**——路徑、查詢字串、標頭、請求主體逐層列，不可只列「主要的幾個」 |
+| 輸出參數 | **列出全部**——回應主體逐層列，含錯誤回應的結構與狀態碼 |
+
+每個參數都要有：名稱、型別、必填與否、範例、資料來源、新舊狀態。
+
+### 參數範例：真實資料優先
+
+1. 先找真實來源：資料庫欄位與實際資料列、實際 API 回應、既有設定檔或 fixture、日誌。標成 `真實：{來源}`。
+2. 找不到來源才由邏輯推理，標成 `推論：無來源`，讓接手者知道那個值還沒被驗證。
+3. **不得**編一個看起來合理的值當成真實資料。
+4. 範例只保留**結構與格式**。個資一律遮蔽或改寫成格式描述，不把真實個資寫進交付文件。
+
+### 既有端點：新舊參數必須明顯區分
+
+改的是既有端點時，接手者最需要知道「哪些是這次動到的」。用兩種標示，兩者都要：
+
+**一、參數表加狀態欄**
+
+| 狀態 | 標示 | 意義 |
+| --- | --- | --- |
+| 新增 | 🆕 **新增** | 這次新增的參數 |
+| 變更 | ⚠️ **變更** | 既有參數改了型別、必填性、預設值或語意 |
+| 既有 | （留空） | 這次沒動 |
+| 移除 | ❌ **移除** | 這次移除，含淘汰時程 |
+
+**二、差異區塊用 `diff` 語法標色**
+
+Gitea 與 GitHub 的 markdown 都會替 `diff` 程式碼區塊上色，`+` 綠、`-` 紅，是最可靠的「顏色」做法（HTML 的 `style` 屬性會被 wiki 過濾掉，不要用）：
+
+````markdown
+```diff
+  GET /v1/members/{id}
+    id            string   必填
++   include_tags  boolean  選填  預設 false（本次新增）
+-   legacy_flag   boolean  選填  （本次移除，2026-12-31 前相容）
+!   status        string   必填  列舉值新增 suspended（本次變更）
+```
+````
+
+新端點不需要狀態欄與差異區塊，但要註明「本次新增端點」。