前言

規格確認完了，下一步不是開始寫程式，而是決定：第一個可以交付的東西到底要切多大？

昨天說到

昨天完成最後一次規格自檢。

Spec 告訴我「要做什麼」，但真正開始實作前，還需要回答另一個問題：我要怎麼把這些規格變成可以執行、可以 review、可以交付的工作？

這就是今天 plan 要處理的事情。

Plan 不是第二份 Spec

拆規格那天講過，plan 和 tasks 不算規格——規格是交給開發的合約，它們是為了達成合約而寫的工作文件。三者分工：

這個區分很重要。

如果 plan 又開始描述需求，最後就會出現兩份 Spec；如果 tasks 又重新定義驗收條件，最後就會出現兩份 Acceptance Criteria。

所以我現在對 Plan 的理解比較簡單：Plan 不是把規格寫得更詳細，而是把規格轉成「可以開始施工的結構」。

/speckit-plan

我沒有從空白 plan.md 開始。使用 /speckit-plan 先讀現有規格，產生基本架構：

Summary
Technical Context
Constitution Check            ← 逐條原則對照
Project Structure
Complexity Tracking
Post-Design Constitution Re-Check   ← 設計產出之後再檢一次

其中我特別留下兩個部分。

1. Constitution Check
它會把設計跟既有規則逐條對照：

### II. 時間一律 UTC + ISO 8601 — PASS
### III. 自建認證（NON-NEGOTIABLE） — PASS
### V. 資料存取只走 ORM — PASS（需審查者留意）

把說過的規則跟這次準備怎麼做放在同一張表上。

2. Complexity Tracking
另一個我覺得值得留下的是 Complexity Tracking，它要求只有在違反既有原則時，才需要解釋：

• 為什麼需要這個複雜度？
• 為什麼更簡單的方法不行？

Fill ONLY if Constitution Check has violations that must be justified

/speckit-plan 範本裡沒有「開發順序」

/speckit-plan 產出的那六節全部在回答「技術上長什麼樣」—— 技術背景、目錄結構、原則有沒有被違反，但它不會幫我決定開發順序，因為這不是純技術問題，而是產品問題。

所以我自己補了一節：交付順序，我補的內容：

依賴順序，不等於交付順序

「開發順序」底下其實藏著兩種順序。

例如：Backend API 要先完成，Frontend 才能串接，是依賴順序。但先完成「寫記錄並送出」，讓使用者可以開始使用，則是交付順序。

兩者很容易被寫成同一件事，可以用一個很簡單的方法檢查：這個階段完成之後，誰的手上多了什麼？

如果答案是：「下一個工程師可以開始做下一層」那很可能只是依賴順序。如果答案是：「使用者現在多了一件原本做不到的事」，這才是交付單位。

切成工作單元

六個功能先保留完整全貌，但實際上不一次拆到最細。

前三個後端已經完成，反而讓我看到原本 Plan 裡的一個問題：我把「後端先做」誤當成了「功能先交付」，這兩個概念其實不一樣。

一張 Issue 到底應該多大？

我不會用一張 Issue 要幾個 Task 來決定大小。而是：「這張 Issue 關掉之後，有沒有人因此多了一件原本做不到的事？」，Issue 應該要是一個可以 review、測試，甚至交付的工作單元。

Task 是施工步驟，Issue 是交付單位。

小結

• 規格確認之後，要用什麼大小的單位開始實作。

• 用一句話區分三個東西：Spec 定義「要交付什麼」；Plan 決定「怎麼組織實作」；Task 描述「實際要做哪些步驟」。
• Issue 則是把它們包成一個可以被驗證、review，最後真正交付出去的單位。

明天：工作單元切好了，第一張要動手。但在寫任何一行畫面之前，先寫測試——而前端的「測試」跟後端不是同一回事。