/sdlc:ship — 收尾一張 task

參數是 task 編號（例 /sdlc:ship 364）。沒給就問。

這條流程的價值不在省打字，在於「不會漏掉其中一步」—— 漏掉任何一步的結果都是批准者拿到一個跑不起來或看不見的交付。

先讀 docs/agents/sdlc.md（驗證指令清單、tracker 參數、選項）。

0. 開工前：先 fetch

git fetch origin main && git log --oneline HEAD..origin/main

有東西就先讀對方的 commit message 與新增的 ADR再決定要不要先合併過來—— 對方可能立了新政策，機械性解衝突會把違反留在 code 裡。

1. 完整驗證

逐條跑設定檔「驗證指令」清單。任何一項不通過就停下來報告，不要往下走。

• 新 worktree 記得先裝相依（npm ci 之類）——「指令不存在」看起來像測試壞了， 其實是東西沒裝
• 弱點與警告的判準：以 CI 實際執行的那個指令為準，不是原始 audit 輸出。 文件與閘門不一致時，改文件，不要照文件回報失敗
• 上游相依帶進來的 advisory 修不掉時：開票追蹤＋驗收 comment 寫明 「非本次改出來的、追蹤於 <完整網址>」。不可用 NoWarn／忽略設定靜音
• CI 沒有涵蓋的驗證項（設定檔會標）只有這裡會抓到——略過它， 就沒有第二個人會發現

2. 變異驗證（commit 之前）

針對這張票的關鍵行為：把行為拿掉，確認測試會紅。

• 一律 cp 備份再改，還原也用 cp——不要用 git checkout <file> 還原， 它會連尚未 commit 的東西一起清掉
• 沒有紅的變異要問：是等價變異（改了但行為不變），還是測試沒守住？ 前者不必補測試，後者一定要補
• 還原後重跑一次整套確認回到綠燈，殘骸不能帶進下一個變異

3. Commit 與合併

git status          # 先看，再 add——避免把不該進版控的東西掃進來
git add -A
git commit          # 訊息說「為什麼這樣做」，不是「做了什麼」
git push origin <分支>

設定檔啟用 worktree 流程時，接著回主目錄合併——路徑一律推導，不寫死 （同一專案可能在多台機器開發，寫死的路徑在另一台是 No such file）：

cd "$(git worktree list --porcelain | head -1 | cut -d' ' -f2-)"
git fetch origin && git merge --no-edit origin/main
git merge --no-edit <分支>
git push origin main

然後在主目錄實跑一次測試。 只推上功能分支的話，批准者的主目錄看不到任何東西—— 無從檢視、無從執行、無從驗收。「推上分支」和「批准者跑得動」是兩件事。 主目錄的相依（node_modules 等）與 worktree 是分開的，必要時先裝。

4. 等 CI

gh run list --repo <code-repo> --branch main --limit 1 --json databaseId --jq '.[0].databaseId'
gh run watch <id> --repo <code-repo> --exit-status

貼出每一個 job 的結果，不要只說「CI 綠」。

5. 驗收 comment ＋ 關票＋Status（同一步）

comment 要有：

• AC 對照表——逐條，不是「都做完了」
• 變異驗證結果——哪些變異、各紅幾個
• 任何超出 AC 的東西（AC 增修也是偏離，要明講）
• 任何未做或做不了的，以及去處（完整網址）
• 批准者要自己跑起來的指令
• 截圖一律標來源（哪個環境、哪個 port）——只截 dev server 然後說「確認新設計」, 字面為真、對批准者的環境為假，比沒看還糟

然後同一步做完：gh issue close <n> --repo <issue-repo> ＋ Status → Done。 拆開做就會出現「板上 Done 但票還開著」的漂移。

6. 立刻接下一張，不要停下來

這一步不是可選的——它就是流程的一部分。 批准閘門只在 story 邊界； 逐張回來問是把已經給過的批准重複要一次（實測：記憶輸了八次，所以寫進流程）。

gh api repos/<issue-repo>/issues/<story>/sub_issues \
  --jq '.[] | select(.state == "open") | "\(.number) \(.title)"'

• 有 open 的 → 挑 blocker 都完成的那張（frontier），Status 設 4.Execute， 直接回到第 0 節重新開始。不回報、不問、不等。
• 沒有了 → 進第 7 節。

停下來的例外只有兩個：真正的偏離（DEVIATION DETECTED）、第 1 節的驗證沒過。 「這張比較大，先確認一下」不是例外——Plan 批准時就一起批准了。

7. 全部 task 完成時（story 收尾，一串連續動作）

1. 設定檔有「本機部署驗證」的話先跑它——測試在 source 層跑， 部署的 image／bundle 停在上個月照樣全綠；要有服務中的產物當證據 （檔名雜湊、回應內容），build 的 exit code 不算
2. story Status → 4.Execute Review → 自行推進 5.Review
3. 逐條跑 AC（附證據）
4. 逐條跑 docs/agents/dod.md（每項要有指令的輸出）
5. 結果貼上 story issue，開頭放三行「裁決點」段：要決定什麼、證據在哪、有沒有豁免
6. 設 Final Review，然後才停

中途唯一該停的情況：AC 或 DOD 有任何一項沒過——那時不是問， 是回報哪項沒過、退回執行。Done 只有批准者能給。