Merge pull request 'feat(analyze): 明確產生 TDD 測試計畫' (#41) from feat/analysis/tdd-test-plan into develop

Reviewed-on: #41

.claude-plugin/plugin.json

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

.codex-plugin/plugin.json

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

plugin.json

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

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 todos with **Test-Driven Development (TDD)**, formatted `[ ]` (open) / `[x]` (done). Each todo is one vertical slice: one seam, one test, one minimal implementation. Seams and anti-patterns: `references/tdd.md`. Completion condition: every work package carries at least one `[ ]` todo, and every todo names its seam and the behaviour its test asserts.
+9. Split every work package into the **測試計畫（TDD）** section, formatted `[ ]` (open) / `[x]` (done). 每個待辦都是一個垂直切片：一個接縫、一個紅燈測試、一個最小實作，以及測試通過後最小的重構驗證。接縫與反模式見 `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,16 +56,19 @@ gantt
   WP-02 {名稱} :crit, wp02, after wp01, {h}h
 ```
 
-## 待辦事項（TDD）
+## 測試計畫（TDD）
+
+每個實作工作包都要列出紅燈測試、最小實作、綠燈驗證。每個待辦都要寫出受測接縫與測試斷言的行為。
+交付、交接工作包也要列出規格審查、範例資料驗證、相依工作包可用性證據。
 
 ### WP-01 {交付、交接工作包名稱}
 
-- [ ] 盤點端點與參數：{對象}
-- [ ] 產出規格與範例資料（標明真實、推論）
-- [ ] 與使用者確認交付內容並產出交付文件
+- [ ] 規格接縫：盤點 {對象} 的端點、參數、回應與錯誤狀態
+- [ ] 範例資料驗證：產出真實與推論來源標籤，確認相依工作包能直接使用
+- [ ] 交付證據：與使用者確認交付內容並產出交付文件
 
 ### WP-02 {工作包名稱}
 
-- [ ] 撰寫 {對象} 的測試：{預期行為}
-- [ ] 實作 {對象} 使測試通過
-- [ ] 重構 {對象} 並保持測試綠燈
+- [ ] 紅燈測試：在 {接縫} 撰寫測試，斷言 {預期行為}
+- [ ] 最小實作：讓 {接縫} 通過該測試
+- [ ] 綠燈驗證：重跑相關測試，確認 {預期行為} 維持通過