/sdlc:sprint-review — 事實盤點

回顧一個 sprint 的交付。跑完接著跑 /sdlc:retro（那個回顧的是流程）。 順序有意義：先確認事實，再檢討過程。 反過來會用印象去解釋事實。

先讀 docs/agents/sdlc.md。

鐵則：查，不要憑印象

這份報告批准者會拿去跟客戶談，也會據以決定下一步。 每一個數字、每一條相依，都要有指令的輸出。 憑印象最容易講錯的三類：相依方向、機制存不存在、設定的實際行為。

1. 撈事實

# 期間關掉的 issue
gh issue list --repo <issue-repo> --state closed --limit 100 \
  --json number,title,closedAt --jq '[.[] | select(.closedAt >= "<起日>")] | sort_by(.number) | .[] | "#\(.number)  \(.title)"'

# 每張 story 的 Status（不要只看 open/closed，Status 才是權威）——GraphQL 見設定檔

# 程式碼變動與測試數（worktree 流程的話在主目錄跑）
git log --since="<起日>" --oneline | wc -l
# 加上設定檔驗證指令裡的測試統計輸出

2. 報告要有這幾段

交付了什麼 — 以使用者做得到什麼描述，不是 issue 標題。 「行政人員終於能改自己的密碼」比「#342 完成」有用。

沒做完的，以及卡在誰身上 — 分清楚三種，解法完全不同：

品質數字 — 測試數、變異分數（逾時數要一起講——逾時被算成擊殺， 逾時愈多分數愈虛高）、CI 狀態。

這個 sprint 抓到什麼 — 假綠測試、規格漏洞、講錯又更正的事。 這一段不能省。 一份只有好消息的 review 沒有人會據以做決定。

等批准者的 — Final Review 的 story（各附三行裁決點）、待裁示的 Q。 卡最久的那張要點名——積壓的問題不是「積很多張」，常常是「積了最大的那張」。

上一輪 retro 的改善行動落地了沒 — 逐條 grep 驗證：改的是流程／CI／文件就 grep 那個檔案；開的是票就查它動了沒。用指令輸出，不用印象。

對外義務對照（設定檔有啟用時）— docs/obligations.md 逐列過一遍： 合約、SLA、給客戶的承諾，每項的實作現況。功能票全綠不代表義務有人做—— 義務通常不是功能，是備份、監控、手冊、訓練這種沒有票就不存在的東西。

3. 順帶檢查（看板衛生）

• 有沒有 story 卡在某個 Status 很久沒動？
• 有沒有「板上 Done 但 issue 還開著」或反過來的漂移？
• 有沒有票根本不在板上？
• 有沒有「已知但沒開票」的東西還躺在對話裡？開票，別留在對話。 對話會被壓縮，issue 不會。

4. 記錄

寫進 docs/sprints/<日期>-<主題>.md，接著跑 /sdlc:retro 補在同一份檔案。