feat/sdlc-analyze-feasibility/main #23

2026-09-17T05:11:52Z

jiantw83 commented

2026-09-17 05:11:52 +00:00

摘要

對一顆需求議題執行可行性檢查，把疑點一題一題問到共識，最後輸出摘要。這一段完全不寫入 Gitea。

需求議題

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

工作包議題

#6 — 以 sdlc-analyze 逐題問到共識並輸出摘要

變更內容

references/feasibility-{architecture,logic,data,schedule}.md — 四份可行性檢查清單。
prompts/sdlc-analyze.md — 流程正本。
test/helpers/prompt-doc.js — 流程正本的共用檢查，sdlc-plan 的測試一併改用。
測試 123 個案例（本 PR 新增 14 個）。

設計重點

這一顆沒有腳本。 交付的是文件本身，所以測試驗的是文件結構：四份清單各有足夠的檢查項與提問指引、正本逐一指名它們且順序正確、一次一題、兩個固定選項、共識摘要只印不寫。
每份清單都有「問題怎麼問」。 檢查項只說要查什麼，不說怎麼把它變成一句能收斂的提問——後者才是實際卡住的地方。四份各自點出一條最該先問的：邏輯的「既有功能是不是已經做過同一件事」能整個取消這次工作；資料的 schema 與遷移答案通常不在議題裡；時程的「未知數最大的一項」決定整體估算的可信度。
能自己查證的就不要拿去問使用者。 正本明令先查程式碼再提問，把問題留給只有人能回答的事。
未整併留言是硬性關卡。 不是提一句就算，而是先停下來、講清楚有幾則、建議先跑 /sdlc-sync；使用者堅持要繼續就繼續，但要在共識摘要裡註明「分析基於未整併留言前的描述」。
第二份流程正本出現時就把共用檢查抽出來，而不是再抄一次 description 前綴、無 frontmatter、平台字樣三項檢查。

解決的問題

可行性疑點原本靠人記得要問、憑印象問，不同人問出來的東西不一樣。四份清單把該問的固定下來，一次一題的協定則讓使用者能看著前一題的答案回答下一題，而不是被丟一整包問題。

影響的功能

新增。sdlc-plan 的測試改用共用檢查，斷言沒有減少（反而多了 .codex 進黑名單），既有測試全數通過。

測試結果

npm test：

ℹ tests 123
ℹ suites 0
ℹ pass 123
ℹ fail 0

六顆 commit 逐一 checkout 後跑測試，每一顆都是綠的（110／110／109／122／122／123）。

手動驗證：grep 確認正本指名的每一個路徑與欄位名都真實存在——四份 references/feasibility-*.md 都在，scripts/issue-extract.js 存在，正本提到的 未處理留言數 與該腳本實際輸出的鍵名一字不差。

本階段不寫入 Gitea，因此沒有需要對真實 repo 驗證的寫入路徑；正本裡唯一被叫用的腳本 issue-extract 是唯讀的。

Code review 修掉的兩處

時程清單的第一條預設了一份工作拆法，但分析階段還沒有工作包可依，照著問會問不出東西。補上：這個階段要先拉一份暫定拆法，它同時是下一段開工作包的草稿；拆不出來本身就是一個要問使用者的問題。
架構清單多了一段與自己「問題怎麼問」重複的中間文字，也讓它成為四份裡唯一結構不同的一份，已移除。

🤖 Generated with Claude Code

## 摘要對一顆需求議題執行可行性檢查，把疑點一題一題問到共識，最後輸出摘要。這一段完全不寫入 Gitea。 ## 需求議題 #1 — tea-sdlc：以 tea 驅動 SDLC 全流程的跨平台指令組 ## 工作包議題 #6 — 以 sdlc-analyze 逐題問到共識並輸出摘要 ## 變更內容 - `references/feasibility-{architecture,logic,data,schedule}.md` — 四份可行性檢查清單。 - `prompts/sdlc-analyze.md` — 流程正本。 - `test/helpers/prompt-doc.js` — 流程正本的共用檢查，`sdlc-plan` 的測試一併改用。 - 測試 123 個案例（本 PR 新增 14 個）。 ## 設計重點 - **這一顆沒有腳本。** 交付的是文件本身，所以測試驗的是文件結構：四份清單各有足夠的檢查項與提問指引、正本逐一指名它們且順序正確、一次一題、兩個固定選項、共識摘要只印不寫。 - **每份清單都有「問題怎麼問」。** 檢查項只說要查什麼，不說怎麼把它變成一句能收斂的提問——後者才是實際卡住的地方。四份各自點出一條最該先問的：邏輯的「既有功能是不是已經做過同一件事」能整個取消這次工作；資料的 schema 與遷移答案通常不在議題裡；時程的「未知數最大的一項」決定整體估算的可信度。 - **能自己查證的就不要拿去問使用者。** 正本明令先查程式碼再提問，把問題留給只有人能回答的事。 - **未整併留言是硬性關卡。** 不是提一句就算，而是先停下來、講清楚有幾則、建議先跑 `/sdlc-sync`；使用者堅持要繼續就繼續，但要在共識摘要裡註明「分析基於未整併留言前的描述」。 - **第二份流程正本出現時就把共用檢查抽出來**，而不是再抄一次 description 前綴、無 frontmatter、平台字樣三項檢查。 ## 解決的問題可行性疑點原本靠人記得要問、憑印象問，不同人問出來的東西不一樣。四份清單把該問的固定下來，一次一題的協定則讓使用者能看著前一題的答案回答下一題，而不是被丟一整包問題。 ## 影響的功能新增。`sdlc-plan` 的測試改用共用檢查，斷言沒有減少（反而多了 `.codex` 進黑名單），既有測試全數通過。 ## 測試結果 `npm test`： ``` ℹ tests 123 ℹ suites 0 ℹ pass 123 ℹ fail 0 ``` 六顆 commit 逐一 checkout 後跑測試，每一顆都是綠的（110／110／109／122／122／123）。手動驗證：`grep` 確認正本指名的每一個路徑與欄位名都真實存在——四份 `references/feasibility-*.md` 都在，`scripts/issue-extract.js` 存在，正本提到的 `未處理留言數` 與該腳本實際輸出的鍵名一字不差。本階段不寫入 Gitea，因此沒有需要對真實 repo 驗證的寫入路徑；正本裡唯一被叫用的腳本 `issue-extract` 是唯讀的。 ## Code review 修掉的兩處 - **時程清單的第一條預設了一份工作拆法**，但分析階段還沒有工作包可依，照著問會問不出東西。補上：這個階段要先拉一份暫定拆法，它同時是下一段開工作包的草稿；拆不出來本身就是一個要問使用者的問題。 - **架構清單多了一段與自己「問題怎麼問」重複的中間文字**，也讓它成為四份裡唯一結構不同的一份，已移除。 --- 🤖 Generated with [Claude Code](https://claude.com/claude-code)

jiantw83 added 6 commits 2026-09-17 05:11:52 +00:00

feat(可行性檢查): 新增架構、邏輯、資料、時程四份檢查清單 549bd29313

四份規則正本，各自列出要對著需求議題回答的檢查項，回答不出來的就是一個要問
使用者的問題。每份末尾都交代「問題怎麼問」——檢查項只說要查什麼，不說怎麼把
它變成一句能收斂的提問，那才是實際卡住的地方。

四份各自點出一個最該先問的：架構問落點與循環相依，邏輯問既有功能是不是已經
做過同一件事（這條能整個取消工作），資料問 schema 與遷移（答案通常不在議題裡），
時程問未知數最大的一項（它決定整體估算的可信度）。

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

feat(sdlc-analyze): 新增可行性分析的流程正本 775909bd3d

一次問一題、依架構→邏輯→資料→時程清空、每題固定給「建議（含理由）」與
「手動輸入」兩個選項、最後輸出共識摘要。摘要只印在終端，這一段完全不寫入
Gitea——把工作包開出去是下一段的事。

開頭先看 issue-extract 回傳的未處理留言數：不是 0 就代表描述可能是過期的，
先提示使用者以 sdlc-sync 整併回描述再回來，堅持要繼續就在摘要裡註明。

明令「能在程式碼裡查證的就自己去查」，把問題留給只有人能回答的事。

Closes #6

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

refactor(測試): 正本的共用檢查抽到 helpers 930270f545

description 前綴、沒有 frontmatter、不出現平台專屬字樣——這三件事每一份流程
正本都要驗，第二份正本出現時就該抽出來，而不是再抄一次。順帶把讀正本、讀規則
正本、讀模板三個路徑組合也收在同一處。

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

test(sdlc-analyze): 釘住四份清單與正本的結構 2b06dfd663

這一顆沒有腳本，交付的就是文件本身，所以驗的是文件的結構：四份清單各有足夠
的檢查項與提問指引、正本逐一指名它們且順序為架構→邏輯→資料→時程、一次一題、
兩個固定選項、共識摘要只印不寫，以及「不對 Gitea 寫入」有被寫成明確邊界。

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

fix(可行性檢查): 補上時程估算的前提，並讓四份清單結構一致 b79c68613a

時程清單的「相依鏈最長路徑」預設了一份工作拆法，但分析階段還沒有工作包可依，
照著問會問不出東西。補上說明：這個階段要先拉一份暫定拆法，它同時是下一段開
工作包的草稿；拆不出來本身就是一個要問使用者的問題。

架構清單原本在開頭多了一段中間文字，內容與自己的「問題怎麼問」重複，也讓它
成為四份裡唯一結構不同的一份，移除。

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

test(sdlc-analyze): 覆蓋時程清單的估算前提 8a405de189

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

admin approved these changes 2026-09-17 05:35:02 +00:00

admin merged commit 2608da2b45 into master

2026-09-17 05:35:05 +00:00

admin deleted branch feat/sdlc-analyze-feasibility/main

2026-09-17 05:35:05 +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#23