契約 breaking 又沒有分流時，前後端不能分開部署
主張：改造既有 endpoint 時，每一個 endpoint 都要問「舊客戶端打過來會怎樣」。只要有一個沒有保留舊行為的分流，前後端就綁死成一次部署。
這次的形狀
同一批改動裡，submit 與 export 都按 Content-Type 分流——JSON 走舊的同步路徑、octet-stream 走新的 artifact 路徑，程式碼註解甚至寫明「沒有這個分支，部署這個功能會弄壞 production」。
但 validate 沒有這個分支：它被就地改成無條件回 202 + workflowId，不再同步驗證。舊前端打過去會拿到一個 workflowId、沒有任何驗證結果，畫面直接壞掉。
結論：後端不能先於前端部署，兩邊必須同時上線。
兩個容易誤解的地方
- 「舊程式碼還留著」不等於可以回退。保留為
*Legacy的檔案是原始碼層面的回退素材，不是 runtime feature flag——線上壞掉時它不會自動接管。要真的能回退就得有開關。 - 契約破壞不只在 response：query 參數變多、request body 從 JSON 變二進位、header 語意改變、回應欄位被移除，任何一項都算。
檢查清單
- 列出所有被改到的 endpoint，逐一標記「舊客戶端會怎樣」
- 有沒有一條路徑是就地改而非新增的？那條就是部署順序的枷鎖
- 要能各自部署，需要的是分流或 feature flag，不是「保留舊檔案」
- 部署順序寫進 MR 描述，並且要有人在 merge 前擋