/sdlc:plan — 拆票（Plan 階段）

把 spec 拆成 tracer-bullet 垂直切片的 task，各自宣告 blocking edges。

先讀 docs/agents/sdlc.md。找不到就停下，請使用者先跑 /sdlc:init。

進入前：story Status → 3.Plan。 產出後：Status → 3.Plan Review，留 comment 請批准，停下來等。

發布 tickets 屬於 Execute 階段的第一個動作，只有批准之後才能執行。 批准前，發布那一步就停在「把清單列給批准者看」。

順序鐵律：批准 → 建票 → 掛 Project → 金魚閘門 → 才動手寫程式。不可先做再補。 </hard-rule>

拆票前的可行性預檢（DWA）：

• 執行路徑分哪幾步？
• 有沒有存取不到的節點？（客戶端資料、未申請的帳號、未到貨的硬體）
• 哪個環節最可能出錯？

切片規則

• 每張 task 切一條窄但完整的垂直路徑（schema、API、UI、測試全穿過）—— 不是某一層的水平切片
• 每張做完可以獨立 demo 或驗證
• 每張的大小塞得進一個全新的 context window
• prefactoring 先做（"Make the change easy, then make the easy change."）

寬 refactor 是垂直切片的例外：一個機械性變更（改欄位名、改共用型別） 爆炸半徑掃過整個 codebase 時，不要硬塞成 tracer bullet，改走 expand–contract： 先加新形式（誰都不壞）→ 分批遷移呼叫端（每批一張票、被 expand 擋住）→ 沒有呼叫端了才刪舊形式（被所有遷移批擋住）。

給批准者看的清單格式

每張 task 列：標題／Blocked by／它讓什麼 end-to-end 行為動起來。 問三件事：粒度對嗎？blocking edges 對嗎？有沒有該合併或再拆的？ 迭代到批准者同意為止。

批准後的發布（Execute 第一動作）

依相依順序發布（blocker 先），每張票四件事缺一不可：

1. gh issue create --repo <設定檔的 issue repo>（票模板見下）
2. 掛 parent——parent 是這批票所屬的 story，不是 Epic（sub-issue 指令見設定檔）
3. 走設定檔的「開票三步驟」加進 Project，Status = Todo
4. blocking edges 用原生 blocking 關係；沒有就在 body 的「Blocked by」段引用編號

卡在外部（客戶資料、審核、硬體）的依賴必須表達成 blocking edge 指向對應的追蹤票，不要只寫在 body 的散文裡—— 這是判斷「現在哪些能平行開發」的唯一依據。

發布完成後：跑 /sdlc:ticket-check（金魚閘門），過了才開始實作。

Task 票模板

## Parent
所屬 story，寫完整網址。

## What to build
這張票讓什麼 end-to-end 行為動起來（使用者視角，不是逐層實作）。

## Acceptance criteria
- [ ] …（每條可獨立驗證）

## 不做
AC 沒寫、且容易順手做下去的事。

## Blocked by
逐張引用，或「None — can start immediately」。

不寫檔案路徑與程式碼片段（會過期）。例外：prototype 產出的決策性片段 （state machine、schema、型別形狀）可以內嵌，註明來源，只留決策密度高的部分。