plugins/tea-sdlc
2
0
Fork 0
Code Issues 3 Pull Requests Actions Releases Activity

feat/sdlc-fix-accepts-issue/main #61

Merged
admin merged 4 commits from feat/sdlc-fix-accepts-issue/main into master 2026-09-18 00:52:00 +00:00
Conversation 1 Commits 4 Files Changed 10
+526 -22
jiantw83 commented 2026-09-18 00:42:45 +00:00
Member
Copy Link
Copy Source

摘要

/sdlc-fix 的輸入從「一個 PR 編號」放寬為「一個 PR 編號或議題編號」。收到議題時交棒給
/sdlc-feat，不把它的步驟重做一遍。

需求議題

#56

工作包議題

#60

變更內容

  • prompts/sdlc-fix.md：新增第 1 步「判定輸入是哪一種」與第 2 步「議題：交棒給 /sdlc-feat」，
    原本的 PR 流程順延為第 3～8 步，內容不變。邊界補三條。
  • scripts/wp-list.js（新）：列出一顆需求議題底下的工作包。
  • scripts/issue-body.js：新增 requirementIndex()，wp-extract 改用它。
  • prompts/sdlc-feat.md：輸入寫明也收得下 /sdlc-fix 交棒過來的編號。
  • prompts/sdlc-sync.md：接回那一段把 /sdlc-fix 也算進來。
  • README.md：指令表補上議題的走向。
  • test/wp-list.test.js（新）、test/sdlc-fix-assets.test.js、test/sdlc-feat-assets.test.js。

設計重點

判定沿用既有契約，沒有新判準。 PR 與議題的分界看 pr-comments 的 類型——每個 PR
都是議題、反過來不成立，所以只能從議題那一端問；先打 PR 端點對純議題會 404。兩種議題的
分界看 wp-extract 的 需求議題（母議題）欄位，解析得出編號就是工作包議題。

交棒而不是重做。 工作包議題直接照 prompts/sdlc-feat.md 走，留言整併也不先做——
/sdlc-feat 第一步自己會看 未處理留言數。抄過來就會有第二份正本，而使用者不會知道
自己讀到的是哪一份。測試直接釘住這件事：正本裡不得出現 claim.js、branch-prep.js、
timer.js、commit-split.js、pr-create.js。

需求議題先 sync 再選工作包。 那上面的留言絕大多數是決策討論，先過一次 /sdlc-sync
通常就清空了，選工作包那一步根本不會觸發。本來就沒有未整併留言時則直接進到選工作包——
沒有留言要整併不表示沒有事要做。

歸屬判準只有一份。 wp-list 與 wp-extract 共用 issue-body 的 requirementIndex()。
規則寫兩份，某天只會有一邊被改到，而分岔的樣子是「清單裡看得到、抽取卻說不是」。

wp-list 不把 PR 列進清單：pr-create 產出的 PR 描述本來就有「需求議題：#N」那一行。
清單逐頁讀完，讀不完寧可報錯——使用者會從缺了幾顆的清單裡挑，而且看不出缺的是哪幾顆。

解決的問題

要求改程式碼的意見不一定發在 PR 上，常常發在工作包議題或需求議題的留言裡。使用者手上
有一個議題編號、看得到有人說「這裡要改」，卻只能自己翻出對應的工作包、自己記得該跑
/sdlc-feat。

影響的功能

  • /sdlc-fix：輸入為 PR 時行為不變，只是判定型別時會先讀一次留言（唯讀，且第 4 步會沿用
    同一份，不重讀）。
  • wp-extract：輸出形狀不變，需求議題 欄位改由共用函式計算。
  • /sdlc-feat、/sdlc-sync：只有文字說明變動，步驟不變。
  • 議題 #1 的契約正本已補上 wp-list 的 flag 介面與 JSON 輸出形狀。

測試結果

npm test 全數通過：

ℹ tests 819
ℹ suites 0
ℹ pass 819
ℹ fail 0
ℹ cancelled 0
ℹ skipped 0
ℹ todo 0

新增 test/wp-list.test.js 12 則（歸屬判準、PR 不列入、排序、空清單、逐頁讀完、翻不完
時報錯、flag 契約）；test/sdlc-fix-assets.test.js 新增 13 則涵蓋三種輸入的判定與後續
走向；test/sdlc-feat-assets.test.js 新增 1 則釘住交棒入口。

另對真實 Gitea 做過唯讀煙霧測試：node scripts/wp-list.js --repo plugins/tea-sdlc --requirement 56（本 repo 的議題是手寫的、不是這組指令產出的，如預期回空清單）與
--dry-run 的請求預告。

🤖 Generated with Claude Code

## 摘要 `/sdlc-fix` 的輸入從「一個 PR 編號」放寬為「一個 PR 編號或議題編號」。收到議題時交棒給 `/sdlc-feat`，不把它的步驟重做一遍。 ## 需求議題 #56 ## 工作包議題 #60 ## 變更內容 - `prompts/sdlc-fix.md`：新增第 1 步「判定輸入是哪一種」與第 2 步「議題：交棒給 /sdlc-feat」， 原本的 PR 流程順延為第 3～8 步，內容不變。邊界補三條。 - `scripts/wp-list.js`（新）：列出一顆需求議題底下的工作包。 - `scripts/issue-body.js`：新增 `requirementIndex()`，`wp-extract` 改用它。 - `prompts/sdlc-feat.md`：輸入寫明也收得下 `/sdlc-fix` 交棒過來的編號。 - `prompts/sdlc-sync.md`：接回那一段把 `/sdlc-fix` 也算進來。 - `README.md`：指令表補上議題的走向。 - `test/wp-list.test.js`（新）、`test/sdlc-fix-assets.test.js`、`test/sdlc-feat-assets.test.js`。 ## 設計重點 **判定沿用既有契約，沒有新判準。** PR 與議題的分界看 `pr-comments` 的 `類型`——每個 PR 都是議題、反過來不成立，所以只能從議題那一端問；先打 PR 端點對純議題會 404。兩種議題的 分界看 `wp-extract` 的 `需求議題`（母議題）欄位，解析得出編號就是工作包議題。 **交棒而不是重做。** 工作包議題直接照 `prompts/sdlc-feat.md` 走，留言整併也不先做—— `/sdlc-feat` 第一步自己會看 `未處理留言數`。抄過來就會有第二份正本，而使用者不會知道 自己讀到的是哪一份。測試直接釘住這件事：正本裡不得出現 `claim.js`、`branch-prep.js`、 `timer.js`、`commit-split.js`、`pr-create.js`。 **需求議題先 sync 再選工作包。** 那上面的留言絕大多數是決策討論，先過一次 `/sdlc-sync` 通常就清空了，選工作包那一步根本不會觸發。本來就沒有未整併留言時則直接進到選工作包—— 沒有留言要整併不表示沒有事要做。 **歸屬判準只有一份。** `wp-list` 與 `wp-extract` 共用 `issue-body` 的 `requirementIndex()`。 規則寫兩份，某天只會有一邊被改到，而分岔的樣子是「清單裡看得到、抽取卻說不是」。 **`wp-list` 不把 PR 列進清單**：`pr-create` 產出的 PR 描述本來就有「需求議題：#N」那一行。 清單逐頁讀完，讀不完寧可報錯——使用者會從缺了幾顆的清單裡挑，而且看不出缺的是哪幾顆。 ## 解決的問題 要求改程式碼的意見不一定發在 PR 上，常常發在工作包議題或需求議題的留言裡。使用者手上 有一個議題編號、看得到有人說「這裡要改」，卻只能自己翻出對應的工作包、自己記得該跑 `/sdlc-feat`。 ## 影響的功能 - `/sdlc-fix`：輸入為 PR 時行為不變，只是判定型別時會先讀一次留言（唯讀，且第 4 步會沿用 同一份，不重讀）。 - `wp-extract`：輸出形狀不變，`需求議題` 欄位改由共用函式計算。 - `/sdlc-feat`、`/sdlc-sync`：只有文字說明變動，步驟不變。 - 議題 #1 的契約正本已補上 `wp-list` 的 flag 介面與 JSON 輸出形狀。 ## 測試結果 `npm test` 全數通過： ``` ℹ tests 819 ℹ suites 0 ℹ pass 819 ℹ fail 0 ℹ cancelled 0 ℹ skipped 0 ℹ todo 0 ``` 新增 `test/wp-list.test.js` 12 則（歸屬判準、PR 不列入、排序、空清單、逐頁讀完、翻不完 時報錯、flag 契約）；`test/sdlc-fix-assets.test.js` 新增 13 則涵蓋三種輸入的判定與後續 走向；`test/sdlc-feat-assets.test.js` 新增 1 則釘住交棒入口。 另對真實 Gitea 做過唯讀煙霧測試：`node scripts/wp-list.js --repo plugins/tea-sdlc --requirement 56`（本 repo 的議題是手寫的、不是這組指令產出的，如預期回空清單）與 `--dry-run` 的請求預告。 🤖 Generated with [Claude Code](https://claude.com/claude-code)
jiantw83 added 4 commits 2026-09-18 00:42:45 +00:00
feat(wp-list): 列出一顆需求議題底下的工作包 09d880e6f2 
歸屬判準沿用工作包抽取那一套（關聯段落的「需求議題：#N」），不另發明一套；
PR 的描述也有那一行，所以先擋掉 PR。清單逐頁讀完，讀不完寧可報錯——
使用者會從缺了幾顆的清單裡挑，而且看不出缺的是哪幾顆。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
feat(sdlc-fix): 輸入放寬為 PR 編號或議題編號 a5f36ed14c 
議題不自己重做一遍實作流程，而是交棒給 /sdlc-feat：工作包議題直接交棒，
需求議題先讓 /sdlc-sync 整併決策留言，剩下確實要改碼的才列出底下的工作包
讓使用者挑一顆。交棒複用 sdlc-sync 已經定好的接回機制，使用者不必重打指令。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
refactor(issue-body): 工作包的歸屬判準收成一個函式 03ce382220 
wp-extract 與 wp-list 都在問「這顆工作包掛在哪顆需求底下」。規則寫兩份，
某天只會有一邊被改到，而分岔的樣子是「清單裡看得到、抽取卻說不是」。
順手把測試裡兩種取段落的寫法統一，並刪掉沒有人傳過的參數。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
fix(sdlc-fix): 需求議題本來就沒有未整併留言時照樣列出工作包 a279591232 
原本只寫「未處理數大於 0 就先整併」，零則的入口從沒明寫，讀起來會變成
「沒有留言要處理就到此為止」，正好與「無未整併留言時要列出工作包」相反。
另把交棒的另一端補在 sdlc-feat 的輸入上——機制只有一邊寫得出來，
另一邊就只是散文承諾。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
admin approved these changes 2026-09-18 00:51:56 +00:00
admin merged commit c06c327104 into master 2026-09-18 00:52:00 +00:00
admin deleted branch feat/sdlc-fix-accepts-issue/main 2026-09-18 00:52:00 +00:00
Sign in to join this conversation.
Reviewers
No Reviewers
admin
Labels
Clear labels
ready-for-agent
規格已就緒可交由agent實作
 進行中
工作包正在實作
No labels
Milestone
No items
No Milestone
Assignees
Clear assignees
admin (系統管理員) jiantw83 (Jeffery)
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: plugins/tea-sdlc#61