沿用既有接縫:子行程執行、stub server 錄下每一筆請求。涵蓋標籤名稱解析、
未知標籤中止、不碰 labels 的寫入端點、同標題不重建、前後空白視為同一顆,
以及寫入型腳本一樣跑滿前置檢查。
試跑的部分特別驗「預覽要忠實」:預覽的 body 必須看得出標籤會被貼上、標籤
錯字在試跑就該擋下、同名議題已存在時預覽不得預告要建立議題,且全程不發出
任何寫入請求。
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
admin
approved these changes 2026-09-17 04:50:59 +00:00
admin
merged commit 9c3ba425e0 into master2026-09-17 04:51:03 +00:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
摘要
讓使用者丟進一段口語需求,最後在 Gitea 看到一顆結構完整的需求議題。本 PR 交付流程正本、輸出模板與寫入用的
issue-create腳本。需求議題
#1 — tea-sdlc:以 tea 驅動 SDLC 全流程的跨平台指令組
工作包議題
#4 — 以 sdlc-plan 把口語需求轉成結構化需求議題
變更內容
prompts/sdlc-plan.md— 流程正本。三種輸入來源、一次問一題、九個段落的填法、流程圖上限、標籤來源、寫入前先試跑。templates/requirement-issue.md— 需求議題的九個段落與順序。scripts/issue-create.js— 建立議題:標籤限既有、以標題查重、--dry-run。scripts/lib.js— 新增listLabels,與labels-list共用。設計重點
--dry-run不寫入,但會讀。 這是本 PR 修掉的一個實質缺陷:原本的試跑零請求,於是預覽的 body 永遠不含labels,標籤錯字也要等實跑才爆。現在試跑會先解析標籤、先查重,因此預覽忠實反映將送出的請求;同名議題已存在時requests為空陣列並附上既有議題編號,如實顯示「實跑會是 no-op」。試跑不跑前置檢查——那一層擋的是寫入能力與時間追蹤,而試跑本來就不寫。issue-extract解析得到什麼,正本的平台中立性決定轉接檔能不能一份寫到底——這兩件事靠人記不牢。解決的問題
需求寫成散文、下游每次都要人重讀一遍再口述給 agent。有了固定模板與正本,議題本身就是可機讀的輸入。
影響的功能
新增。
labels-list改用lib.listLabels,行為不變,既有測試全數通過。測試結果
npm test:六顆 commit 逐一 checkout 後跑測試,每一顆都是綠的(50/50/50/50/64/81)。
對真實 Gitea 的手動驗證(三種試跑情境,皆未寫入):
實跑路徑未在真實 repo 上執行——該 repo 的時間追蹤仍關著,第四層前置檢查會擋下;建立議題的行為由 stub server 測試覆蓋。
待確認
沿用上一個 PR 未回覆的兩點:讀取型腳本是否該跑滿四層前置檢查,以及直接打 REST API 而非
tea子指令。本 PR 依既有實作繼續。🤖 Generated with Claude Code