/sdlc:implement — 實作

先讀 docs/agents/sdlc.md 與 CONTEXT.md。

⛔ 啟動閘門（違反是嚴重錯誤）

Status 停在 3.Plan Review 或更早 = 尚未批准 = 不准動任何程式碼。 停下來告訴使用者在等批准。 </hard-rule>

啟動前確認：

• story 的 Status 是 4.Execute？
• task 票已建好、都在 Project 板上、過了金魚閘門（/sdlc:ticket-check）？
• 要動手的那張 task Status 已設 4.Execute？
• 開工前先 git fetch origin main 看有沒有新東西——別的 session 也可能在推。 不只看「有沒有衝突」，要看「對方有沒有立新的政策（ADR）」。 等到合併才發現的代價是整段設計重做。

執行

用 tdd skill 在事先議定的 seam 寫測試——seam 應該已寫在 spec 的 Testing Decisions；沒有的話先跟批准者議定再寫。

命名一律用 CONTEXT.md 的領域詞彙；動到某區域時尊重該區域的 ADR。 typecheck 常跑、單檔測試常跑、整套測試最後跑一次。

每張 task 完成後的偏差確認（DWA）

• 產出仍對齊目標？
• 有沒有規範外的模糊地帶？
• 有沒有外部因素阻礙？（API 錯誤、資料未到、帳號未核准）

判定：

• Case A（主動停止）——違反 DWA、資源遺失、邏輯死結 → 停止，回報批准者
• Case B（繼續執行）——符合 DWA 但可能不合批准者主觀偏好 → 繼續，Review 時處理

偏離 Plan → 立即發 DEVIATION DETECTED，停止並回報。AC 增修也是偏離—— 發現「我正在做 AC 沒寫的事」就當場提出，不是等 review 來抓。 禁止順便優化、加新功能、改方向；計畫行不通就退回 Plan。

收尾

每張 task 收尾一律走 /sdlc:ship（它會驗證、commit、合併、留 comment、 更新 Status，並自動接下一張——不逐張回來請示）。

story 的全部 task 完成後，ship 會走「收尾是一串連續動作」推進到 Final Review。 Done 只有批准者能給，不可自宣。