規格先行的七步開發流程
在兩個不可動搖的前提下（開發前一定先產 spec、只寫 unit/integration test 不寫 E2E）收斂出來的流程。一句話：以 SDD 為主幹，把 BDD 當 spec 的強制審查關卡，把 TDD 的 test skeleton 當「准許平行展開」的最後一道門。
要解的兩個痛點：規格細節常沒想清楚、實作到一半才回頭補；補完 spec 後已平行展開的多條線因為互相相依而連鎖修改。
七步
- 寫 spec 骨架 — 目標／非目標、Glossary、User Stories、初版 contract 草稿
- 場景審查（強制關卡） — BDD checklist 專門找規格沒寫到的維度 逐條掃；每條需求強迫產出「1 成功 ＋ ≥2 失敗」場景；掃不過標
[NEEDS CLARIFICATION]。場景常駐 spec 的驗收準則章節，每條掛唯一 AC id - Test skeleton 閘門 — 每條 AC 一個測試名 ＋「輸入／預期輸出／錯誤路徑」，標 unit 或 integration、跨哪條線。三個通過條件見 契約凍結是通過 test skeleton 的結果，不是前提
- 契約凍結 — OpenAPI／schema／錯誤碼表／狀態轉移表／單位時區全齊，版本化並 pin SHA
- 檢查 DoR 才展開多線 — 平行展開前要過 Definition of Ready；沒過先跑一條薄線打穿主流程
- 平行實作（TDD 節奏） — skeleton 逐條填實斷言 → 紅 → 綠 → 重構；測試分兩層：綁契約的是資產，綁實作的是拋棄式；consumer-driven contract test 取代 E2E 驗串接
- 規格變更走 SOP — semantic diff 判 BREAKING → 影響半徑分析 → 停線判定 → 更新 spec/場景/AC/skeleton → 重新凍結 pin 新 SHA → consumer contract test 為復工驗收（見 語意變更不能 additive-first，一律當 breaking）
分層的理由：SDD、BDD、TDD 是三個層級不是三個選項。
每個痛點被哪一步擋掉
| 痛點 | 擋在哪 |
|---|---|
| 規格細節沒想清楚 | 步驟 2 checklist 找「沒寫到的維度」 |
| 寫了但不夠具體（假具體） | 步驟 3 skeleton 逼出具體值 |
| 做到一半回頭補 spec | 步驟 3〜5 的閘門把紅燈從週級提前到小時級 |
| 平行線連鎖修改 | 步驟 4 契約凍結 ＋ 步驟 5 DoR ＋ 步驟 7 影響半徑分析 |
| 改規格不知道影響誰 | grep AC-id ＋ contract 反查消費端 |
| 不寫 E2E 仍要驗串接 | 步驟 6 consumer-driven contract test |
如果只能先做兩件事
- 在 spec 定稿與平行展開之間插入「場景審查 ＋ skeleton」兩個 pass，不通過就不准開多線 — 這一刀直接命中痛點（已做成 grill-spec：把規格審查做成四個 pass）
- 導入 AC id 追溯鏈讓改規格的影響變成一個 grep — 成本極低，立刻讓「改規格會影響誰」變成一個 grep
拿別人的 spec 時的差異：拿別人的 spec 時要把問題分成三堆。所有靠紀律的部分都該機械化：規格檢查要機械化進 CI，不能靠紀律。