feat/work-package-issues/main #24

2026-09-17T05:44:18Z

jiantw83 commented

2026-09-17 05:44:18 +00:00

摘要

把分析階段的共識變成一批開發者拿了就能動手的工作包議題。交付工作包模板，並把 sdlc-analyze 正本擴充成兩段式。

需求議題

#1 — tea-sdlc：以 tea 驅動 SDLC 全流程的跨平台指令組

工作包議題

#7 — 從共識摘要產生工作包議題

變更內容

templates/work-package-issue.md — 工作包議題的九個段落與順序。
prompts/sdlc-analyze.md — 擴充為兩段式：第一段可行性分析（不寫入），第二段產生工作包。
test/helpers/prompt-doc.js — 模板結構的三項共用斷言，兩份模板測試一併改用。
測試 141 個案例（本 PR 新增 18 個）。

設計重點

兩段式，中間有一道人為關卡。 第一段到共識摘要為止完全不寫入；使用者點頭之後才進第二段建立議題。邊界條文跟著改寫成「共識摘要之前不對 Gitea 產生任何寫入」，並新增一條斷言：第一段的文字裡不得出現任何寫入型腳本的名字。
第二段明列它不做的事：不建相依、不掛 Milestone、不加看板、不寫人天估算。那些是 #8 的工作，寫在這裡會讓兩顆工作包互相踩。
待辦的巢狀寫法附可照抄的範例。 上層是待辦、縮排一層是該項的驗收，不再往下巢狀——這個格式決定 #9 的 wp-extract 解析得到什麼、也決定實作階段勾得到哪一行。
標題禁止流水編號，而且舉出被禁止的寫法（WP-01、任務三、第一階段），不是只說「不要用編號」。
issue-create 不必改。 冪等查重與 --dry-run 在 #3／#4 就做好了，這一顆只需要把模板與規則補上。

解決的問題

工作包原本憑印象拆、格式各憑喜好。固定模板讓開發者打開任何一顆都看得到同樣的九件事，範圍邊界那一段則是專門用來抵抗範圍蔓延的。

影響的功能

新增。sdlc-plan 的測試改用共用斷言，斷言沒有減少；sdlc-plan 正本的「不畫圖」條件同步收緊（見下）。

測試結果

npm test：

ℹ tests 141
ℹ suites 0
ℹ pass 141
ℹ fail 0

六顆 commit 逐一 checkout 後跑測試，每一顆都是綠的（123／124／140／140／140／141）。

真實 Gitea 的端到端驗證（未寫入）：依模板組出一顆完整的工作包 body，確認沒有殘留佔位，再餵給 issue-create --dry-run：

existing: None | labels: ['ready-for-agent']
將送出: POST /repos/plugins/tea-sdlc/issues | label ids: [55]
body 段落: ['這個工作包在做什麼', '描述', '架構圖', '範圍邊界', '介面契約',
           '待辦', '整體驗收', 'repo 列表', '關聯']

再用 issue-body 解析器把同一份 body 讀回來，範圍邊界、關聯、待辦都解析得動。

給 #9 的線索（已寫進程式碼註解）

issue-body.js 的 tableSection 只處理兩欄，直接拿去解介面契約會無聲丟掉第三、四欄（消費者／形狀）。這不是本 PR 的缺陷——目前沒有任何腳本對工作包呼叫它——但 wp-extract 需要一個保留全部欄位的版本。已把這個限制寫在函式註解上，免得接手的人踩一次才發現。

Code review 修掉的一處

兩份正本原本都寫「不畫：一行說明為什麼不畫」，讀起來像是隨時可以跳過畫圖。議題 #1 的原意是「超過上限即拆圖或不畫」——退路是給畫不下的情況用的。改成只在超過上限拆不開、或畫了不會比文字更清楚時才選，兩份正本一起改。

🤖 Generated with Claude Code

## 摘要把分析階段的共識變成一批開發者拿了就能動手的工作包議題。交付工作包模板，並把 `sdlc-analyze` 正本擴充成兩段式。 ## 需求議題 #1 — tea-sdlc：以 tea 驅動 SDLC 全流程的跨平台指令組 ## 工作包議題 #7 — 從共識摘要產生工作包議題 ## 變更內容 - `templates/work-package-issue.md` — 工作包議題的九個段落與順序。 - `prompts/sdlc-analyze.md` — 擴充為兩段式：第一段可行性分析（不寫入），第二段產生工作包。 - `test/helpers/prompt-doc.js` — 模板結構的三項共用斷言，兩份模板測試一併改用。 - 測試 141 個案例（本 PR 新增 18 個）。 ## 設計重點 - **兩段式，中間有一道人為關卡。** 第一段到共識摘要為止完全不寫入；使用者點頭之後才進第二段建立議題。邊界條文跟著改寫成「共識摘要之前不對 Gitea 產生任何寫入」，並新增一條斷言：第一段的文字裡不得出現任何寫入型腳本的名字。 - **第二段明列它不做的事**：不建相依、不掛 Milestone、不加看板、不寫人天估算。那些是 #8 的工作，寫在這裡會讓兩顆工作包互相踩。 - **待辦的巢狀寫法附可照抄的範例。** 上層是待辦、縮排一層是該項的驗收，不再往下巢狀——這個格式決定 #9 的 `wp-extract` 解析得到什麼、也決定實作階段勾得到哪一行。 - **標題禁止流水編號**，而且舉出被禁止的寫法（`WP-01`、`任務三`、`第一階段`），不是只說「不要用編號」。 - **`issue-create` 不必改。** 冪等查重與 `--dry-run` 在 #3／#4 就做好了，這一顆只需要把模板與規則補上。 ## 解決的問題工作包原本憑印象拆、格式各憑喜好。固定模板讓開發者打開任何一顆都看得到同樣的九件事，範圍邊界那一段則是專門用來抵抗範圍蔓延的。 ## 影響的功能新增。`sdlc-plan` 的測試改用共用斷言，斷言沒有減少；`sdlc-plan` 正本的「不畫圖」條件同步收緊（見下）。 ## 測試結果 `npm test`： ``` ℹ tests 141 ℹ suites 0 ℹ pass 141 ℹ fail 0 ``` 六顆 commit 逐一 checkout 後跑測試，每一顆都是綠的（123／124／140／140／140／141）。真實 Gitea 的端到端驗證（未寫入）：依模板組出一顆完整的工作包 body，確認沒有殘留佔位，再餵給 `issue-create --dry-run`： ``` existing: None | labels: ['ready-for-agent'] 將送出: POST /repos/plugins/tea-sdlc/issues | label ids: [55] body 段落: ['這個工作包在做什麼', '描述', '架構圖', '範圍邊界', '介面契約', '待辦', '整體驗收', 'repo 列表', '關聯'] ``` 再用 `issue-body` 解析器把同一份 body 讀回來，範圍邊界、關聯、待辦都解析得動。 ## 給 #9 的線索（已寫進程式碼註解） `issue-body.js` 的 `tableSection` 只處理兩欄，直接拿去解介面契約會**無聲丟掉第三、四欄**（消費者／形狀）。這不是本 PR 的缺陷——目前沒有任何腳本對工作包呼叫它——但 `wp-extract` 需要一個保留全部欄位的版本。已把這個限制寫在函式註解上，免得接手的人踩一次才發現。 ## Code review 修掉的一處兩份正本原本都寫「不畫：一行說明為什麼不畫」，讀起來像是隨時可以跳過畫圖。議題 #1 的原意是「超過上限即拆圖或不畫」——退路是給畫不下的情況用的。改成只在超過上限拆不開、或畫了不會比文字更清楚時才選，兩份正本一起改。 --- 🤖 Generated with [Claude Code](https://claude.com/claude-code)

jiantw83 added 6 commits 2026-09-17 05:44:18 +00:00

feat(工作包): 新增工作包議題模板 35bafcc928

九個段落與順序：這個工作包在做什麼／描述／架構圖／範圍邊界／介面契約／待辦／
整體驗收／repo 列表／關聯。段落順序即下游 wp-extract 的解析依據。

介面契約是四欄表格（介面／產出者／消費者／形狀）並帶分隔列，讓解析有明確的
資料列起點。架構圖同樣不寫死 mermaid 圍欄——正本允許不畫，圍欄寫死時不畫會在
議題頁留下一塊渲染失敗的空區塊。

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

feat(sdlc-analyze): 擴充為兩段式，第二段把共識變成工作包議題 0cd25d49d4

第一段到共識摘要為止仍然完全不寫入；使用者點頭之後才進入第二段建立議題。
邊界條文隨之改寫成「共識摘要之前不對 Gitea 產生任何寫入」，並明列第二段
不做的事：不建相依、不掛 Milestone、不加看板、不寫人天估算——那些是後續
流程的工作，寫在這裡會讓兩顆工作包互相踩。

工作包的切法、標題規則（動詞加名詞、禁止 WP-01 這類流水編號）、待辦與驗收
的巢狀寫法（附可照抄的範例）、架構圖依性質三選一，都在這一段定下來。

邊界的斷言跟著條文一起改，因為條文換了語意；分開成兩顆 commit 的話中間那顆
會是紅的。另補一條斷言：第一段不得出現任何寫入型腳本的名字。

Closes #7

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

test(工作包): 釘住模板與「產生工作包」那一段的規則 f0beb1ff64

模板的段落順序決定 wp-extract 解析得到什麼，待辦的巢狀寫法決定實作階段勾得到
哪一行——這兩件事寫死在測試裡，改動時才會被逼著一起改。

巢狀範例的斷言不比對固定縮排量，而是比對「最深的一層比最淺的深」，這樣重排
外層清單的縮排不會弄壞測試。

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

docs(議題解析): 標明 tableSection 只處理兩欄 7b54d566e2

工作包的介面契約是四欄（介面／產出者／消費者／形狀），直接沿用這一支會無聲
丟掉第三、四欄。把限制寫在函式註解上，讓接手 wp-extract 的人一眼看到，而不是
自己踩一次才發現。

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

fix(流程正本): 「不畫圖」綁回上限，不是免死金牌 9a67c8074f

兩份正本原本都只寫「不畫：一行說明為什麼不畫」，讀起來像是隨時可以跳過。
議題 #1 的原意是「超過上限即拆圖或不畫」——退路是給畫不下的情況用的。
改成只在超過上限拆不開、或畫了不會比文字更清楚時才選，兩份正本一起改，
免得兩邊講法不同。

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

refactor(測試): 模板結構的三項檢查抽到共用斷言 6457d68874

段落順序、正本的編號清單、圖表段落不寫死圍欄——這三件事需求議題與工作包議題
都要驗，第二份模板出現時就該抽出來。兩份測試原本各抄一份，其中佔位數的斷言
還悄悄長成不同寫法（一邊 >=、一邊 ==）；抽出來之後這種分歧會被逼著講清楚。

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

admin approved these changes 2026-09-17 05:46:16 +00:00

admin merged commit fa2540457f into master

2026-09-17 05:46:20 +00:00

admin deleted branch feat/work-package-issues/main

2026-09-17 05:46:20 +00:00

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: plugins/tea-sdlc#24