Merge pull request 'feat(analyze): 依使用者故事產生 TDD 驗收計畫' (#42) from feat/analysis/tdd-test-plan into develop

Reviewed-on: #42
Reviewed-by: 系統管理員 <1+admin@noreply.localhost>

.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "jsc-sdlc",
-  "version": "0.2.3",
+  "version": "0.2.5",
   "description": "開發生命週期：規劃、分析、實作、維護（wiki 追蹤）",
   "skills": "./skills",
   "author": {

.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "jsc-sdlc",
-  "version": "0.2.3",
+  "version": "0.2.5",
   "description": "開發生命週期：規劃、分析、實作、維護（wiki 追蹤）",
   "skills": "./skills",
   "jsc": {

plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "jsc-sdlc",
-  "version": "0.2.3",
+  "version": "0.2.5",
   "description": "開發生命週期：規劃、分析、實作、維護（wiki 追蹤）",
   "skills": "./skills/",
   "jsc": {

references/tdd.md

@@ -8,7 +8,7 @@
 
 1. **先紅後綠**：先寫會失敗的測試，再寫剛好通過的實作；不預寫未來的測試、不加投機功能。
 2. **一次一片（vertical slice）**：一個接縫、一個測試、一個最小實作為一個循環；下一片依上一片學到的調整。
-3. **重構不在循環內**：重構屬於審查階段（`jsc-review:code-review`），不混入紅綠循環。
+3. **綠燈後重構**：測試通過後才能重構；重構只改善設計，不改變可觀察行為，並且要重跑同一組測試保持綠燈。
 4. **註解只寫原因**：一個待辦要算完成，該次 diff 的註解不得夾帶追蹤編號與文件位置。完整清單與白名單見 `jsc-review` 的 `references/comment-scope.md`。
 
 ## 反模式（發現即重寫該測試）

skills/analyze/SKILL.md

@@ -32,7 +32,7 @@ All wiki reads and writes go through `jsc-gitea:wiki`.
 6. Run a **Work Breakdown Structure (WBS)**: split the user stories into work packages, number them sequentially (`WP-01`, `WP-02`, ...) and mark dependencies. Completion condition: every user story on the plan page maps to at least one numbered work package, and every dependency edge is recorded in the WBS table's 相依 column.
 7. **`WP-01` is always the delivery/handover work package** — see "Delivery package is WP-01" below. It stands alone, never merged into an implementation package, and every implementation package that consumes its spec depends on it. Completion condition: `WP-01` is marked 交付 `是` and holds only spec-shaped items, and every implementation package that consumes its spec names `WP-01` in its 相依 column — or the no-handover case below is confirmed with the user and its reason is written on the page.
 8. Estimate every work package's effort in hours and days with the **Critical Path Method (CPM)**, and mark the critical path. Draw the critical path as a mermaid gantt chart per `references/cpm-chart.md` — its date/duration rules are mandatory, not a suggestion; skipping them is how the `Invalid date` rendering failure happens. Completion condition: every work package carries an hours figure and a days figure, the critical path plus its total days are written on the page, and the gantt chart follows `references/cpm-chart.md` exactly (integer-hour durations, `after` chaining, no `dateFormat X`).
-9. Split every work package into the **測試計畫（TDD）** section, formatted `[ ]` (open) / `[x]` (done). 每個待辦都是一個垂直切片：一個接縫、一個紅燈測試、一個最小實作，以及測試通過後最小的重構驗證。接縫與反模式見 `references/tdd.md`。完成條件：每個工作包都在 `## 測試計畫（TDD）` 下有自己的小節；每個實作工作包至少有一個測試先行的 `[ ]` 待辦；每個待辦都寫出接縫與測試斷言的行為。純交付工作包可以寫文件驗證或範例資料驗證待辦，但仍要寫出能證明規格可用的測試證據或審查證據。
+9. 在 TDD 待辦前先產生 **使用者故事驗收計畫**，再把每個工作包拆進 **測試計畫（TDD）** 區塊，格式用 `[ ]`（未完成）與 `[x]`（完成）。每個使用者故事都要有驗收情境，並標明驗收方式是 `真實資料` 或 `邏輯推論`。簡單故事至少 1 個情境；中等故事至少 2 個情境，含 1 個主要流程與 1 個邊界或錯誤流程；複雜故事至少 3 個情境，含主要流程、邊界流程與失敗流程。每個情境都要寫出輸入、預期結果、資料來源與對應工作包。每個 TDD 待辦都是一個完整循環：一個接縫、一個先失敗的測試、一個最小實作、一次綠燈驗證，以及必要時的綠燈後重構。不要把紅燈測試、最小實作、綠燈驗證拆成不同待辦。接縫與反模式見 `references/tdd.md`。完成條件：每個使用者故事都在 `## 使用者故事驗收計畫` 有情境；每個情境都有明確驗收方式與資料來源；情境數量符合複雜度；每個工作包都在 `## 測試計畫（TDD）` 下有自己的小節；每個實作工作包至少有一個測試先行的 `[ ]` 待辦；每個待辦都寫出接縫、驗收情境、測試斷言行為、最小實作範圍與綠燈驗證方式。純交付工作包可以寫文件驗證或範例資料驗證待辦，但仍要寫出能證明規格可用的測試證據或審查證據。
 10. Apply `templates/analyze-page.md` to create or update the analysis page and write it back via `jsc-gitea:wiki`. The page content is Traditional Chinese, exactly as the template dictates. Completion condition: the page is saved on the wiki and carries every section the template dictates, including the source branch, the head sha and the 未決項 section (「無」 when there is none).
 11. If the analysis page is new: add it to `ANALYZE_CONTENTS` per `templates/analyze-contents.md`, and flip the plan's status in `PLAN_CONTENTS` to the literal 「已分析」. Completion condition: `ANALYZE_CONTENTS` shows the new row and `PLAN_CONTENTS` shows the literal 「已分析」, both saved on the wiki.
 12. **Stage report — the last thing this stage does, including every early stop** (the model gate blocked, the working tree did not match `origin/{source-branch}`, no plan was selectable). Run `tools/stage-report.sh analyze` with one `--page TYPE:{page}` per wiki page this run wrote — `ANALYZE_{HASH}`, `ANALYZE_CONTENTS`, `PLAN_CONTENTS`, and `REPO_{HASH}` plus `REPO_CONTENTS` when a re-inventory happened — plus `--worklog` and `--worklog-heading` when a work log entry exists. No work log yet: write this stage's log content to a file and pass `--pending-file {file} --log-hash {HASH}` so it is held for the next `jsc-log:worklog` run. Rules and exit codes: `references/stage-report.md`. Exit 1 is a warning, never a block. Completion condition: the script's output is reported to the user verbatim, and every wiki page this run wrote appears in it.

templates/analyze-page.md

@@ -56,19 +56,30 @@ gantt
   WP-02 {名稱} :crit, wp02, after wp01, {h}h
 ```
 
+## 使用者故事驗收計畫
+
+每個使用者故事都要列出驗收情境。驗收方式只能填 `真實資料` 或 `邏輯推論`。
+簡單故事至少 1 個情境；中等故事至少 2 個情境，含主要流程與邊界或錯誤流程；複雜故事至少 3 個情境，含主要流程、邊界流程與失敗流程。
+資料來源要寫可查證來源；沒有外部來源時填 `邏輯推論：{推論依據}`。
+
+| 使用者故事 | 複雜度 | 情境 | 驗收方式 | 輸入 | 預期結果 | 資料來源 | 對應工作包 |
+| --- | --- | --- | --- | --- | --- | --- | --- |
+| {故事名稱} | 簡單 | 主要流程：{情境名稱} | 真實資料 | {輸入資料} | {可驗收結果} | 真實資料：{來源} | WP-02 |
+| {故事名稱} | 中等 | 邊界流程：{情境名稱} | 邏輯推論 | {輸入資料} | {可驗收結果} | 邏輯推論：{推論依據} | WP-02 |
+| {故事名稱} | 複雜 | 失敗流程：{情境名稱} | 邏輯推論 | {輸入資料} | {錯誤狀態或拒絕原因} | 邏輯推論：{推論依據} | WP-03 |
+
 ## 測試計畫（TDD）
 
-每個實作工作包都要列出紅燈測試、最小實作、綠燈驗證。每個待辦都要寫出受測接縫與測試斷言的行為。
+每個實作工作包都要列出完整 TDD 循環。每個待辦都要寫出受測接縫、對應驗收情境、測試斷言行為、最小實作範圍、綠燈驗證方式。
+不要把紅燈測試、最小實作、綠燈驗證拆成不同待辦。
 交付、交接工作包也要列出規格審查、範例資料驗證、相依工作包可用性證據。
 
 ### WP-01 {交付、交接工作包名稱}
 
-- [ ] 規格接縫：盤點 {對象} 的端點、參數、回應與錯誤狀態
+- [ ] 規格接縫：盤點 {對象} 的端點、參數、回應與錯誤狀態，覆蓋驗收情境 {情境名稱}
 - [ ] 範例資料驗證：產出真實與推論來源標籤，確認相依工作包能直接使用
 - [ ] 交付證據：與使用者確認交付內容並產出交付文件
 
 ### WP-02 {工作包名稱}
 
-- [ ] 紅燈測試：在 {接縫} 撰寫測試，斷言 {預期行為}
-- [ ] 最小實作：讓 {接縫} 通過該測試
-- [ ] 綠燈驗證：重跑相關測試，確認 {預期行為} 維持通過
+- [ ] TDD 循環：驗收情境 {情境名稱}；接縫 {接縫}；先寫會失敗的測試，斷言 {預期行為}；最小實作範圍 {實作範圍}；重跑 {測試指令或測試集合} 確認綠燈；必要時重構並保持綠燈