2.3 KiB
name: sdlc-analyze description: 僅由 /sdlc-analyze 指令叫用。對一顆需求議題執行可行性檢查，逐題問到共識後產生工作包議題並排上時程。
sdlc-analyze
輸入
一個需求議題編號。先用 scripts/issue-extract.js 讀取結構化內容；先看 未處理留言數。若有留言，直接走 /sdlc-sync 的流程，完成後自動接回這裡；不要要求使用者重打指令。接回前重新抽取一次拿到更新後的描述；若使用者不整併，繼續並在摘要註明。
第一段：可行性分析
依序讀取並逐條對照：
references/feasibility-architecture.mdreferences/feasibility-logic.mdreferences/feasibility-data.mdreferences/feasibility-schedule.md
能從程式碼查證的事項自行查證；只有需要使用者決策的事項才提問。架構、邏輯、資料、時程四類依序完成，每次只問一題，每題提供建議與手動輸入。最後輸出共識摘要、變更假設、未決事項與人天估算；摘要只印終端，不寫入 Gitea。
使用者確認共識摘要後，先列出要交付或驗收的項目，逐項向使用者確認。使用者未確認或拒絕時，立即停止，不建立工作包、不排程、不寫入後續資料。
第二段：產生工作包
確認交付／驗收項目後，依共識切出可獨立完成的工作包，套用 templates/work-package-issue.md。每顆工作包的待辦與驗收都要可逐項勾選；對應已確認交付項目的待辦置於第一項。工作包整體也依交付優先排序，但不得違反先決關係。
每顆工作包先以 scripts/issue-create.js --dry-run 檢查，再移除旗標實跑。只使用既有標籤。建立後回報編號、標題與網址。
第三段：排程
以 startDate、days 與 depends 組成計畫檔，執行 scripts/schedule.js 計算截止日；依序用 issue-link.js、issue-update.js 與 project-add.js 補上既有相依、Milestone、看板、截止日與人天估算。各腳本先 dry-run，再實跑。日期與人天是排程資料，不是耗時統計。
邊界
- 不產生 HTML、SVG、manifest、截圖、附件或任何平台 preview。
- 不建立 Milestone 或專案看板。
- 不修改使用者專案檔案。
- 不關閉或刪除既有議題。
- 共識摘要與交付確認前不建立任何工作包。