QA 工作階段
執行互動式 QA 工作階段。使用者描述他們遇到的問題。您進行釐清、在背景探索程式碼庫以獲取上下文，然後建立耐用、以使用者為中心、並使用專案領域語言的 GitHub 議題。
針對使用者提出的每個問題
1. 傾聽並稍作釐清
讓使用者用自己的話描述問題。最多提出 2-3 個簡短的釐清問題，重點放在：
- 他們預期的結果 vs 實際發生的情況
- 重現步驟（如果不明顯）
- 問題是否為持續性還是間歇性
不要過度審問。 如果描述已經足夠清楚可以建立議題，就直接進行下一步。
2. 在背景探索程式碼庫
與使用者交談的同時，在背景啟動一個 Agent（subagent_type=Explore）來了解相關區域。目標不是找到修復方法——而是：
- 學習該區域使用的領域語言（檢查 UBIQUITOUS_LANGUAGE.md）
- 了解該功能預期要做什麼
- 識別使用者可見的行為邊界
這個上下文有助於您寫出更好的議題——但議題本身不應引用特定檔案、行號或內部實作細節。
3. 評估範圍：單一議題還是拆解？
在建立議題之前，決定這是一個單一議題，還是需要拆解成多個議題。
需要拆解的情況：
- 修復涉及多個獨立區域（例如：「表單驗證錯誤，而且成功訊息遺失，而且重新導向壞了」）
- 存在明顯可分離的關注點，不同的人可以平行處理
- 使用者描述的內容具有多種不同的失敗模式或症狀
保持單一議題的情況：
- 在單一位置有一個行為錯誤
- 所有症狀都是由相同的根本行為所導致
4. 建立 GitHub 議題
使用 gh issue create 建立議題。不要先要求使用者審查——直接建立並分享 URL。
議題必須耐用——即使在重大重構後仍應具有意義。從使用者的角度撰寫。
單一議題
使用此範本：
## 發生了什麼事
[以平實的語言描述使用者體驗到的實際行為]
## 我預期的結果
[描述預期的行為]
## 重現步驟
1. [具體、編號的步驟，開發人員可以遵循]
2. [使用來自程式碼庫的領域術語，而非內部模組名稱]
3. [包含相關的輸入、旗標或設定]
## 其他背景資訊
[來自使用者或程式碼庫探索的任何額外觀察，有助於界定問題——例如：「這只在使用 Docker 層時發生，而非檔案系統層」——使用領域語言，但不要引用檔案]
拆解（多個議題）
按照依賴順序建立議題（先建立阻斷者），這樣您就可以引用真實的議題編號。
對每個子議題使用此範本：
## 父議題
#<父議題編號>（如果您建立了追蹤議題）或「在 QA 工作階段期間回報」
## 什麼出了問題
[描述這個特定行為問題——僅此一部分，而非整個報告]
## 我預期的結果
[針對這個特定部分的預期行為]
## 重現步驟
1. [僅針對這個議題的步驟]
## 被阻斷者
- #<議題編號>（如果此議題必須等到其他議題解決後才能修復）
如果沒有阻斷者，則寫「無——可以立即開始」。
## 其他背景資訊
[與此部分相關的任何額外觀察]
在進行拆解時：
- 寧可有多個薄的議題，也不要少數幾個厚的議題——每個議題都應能獨立修復和驗證
- 誠實標記阻斷關係——如果議題 B 在議題 A 修復之前真的無法測試，就誠實標記。如果它們彼此獨立，則都標記為「無——可以立即開始」
- 按照依賴順序建立議題，這樣您就可以在「被阻斷者」中引用真實的議題編號
- 最大化平行處理——目標是讓多個人（或代理）可以同時處理不同的議題
所有議題內文的規則
- 沒有檔案路徑或行號——這些會過時
- 使用專案的領域語言（如果存在，請檢查 UBIQUITOUS_LANGUAGE.md）
- 描述行為，而非程式碼——例如「同步服務無法套用修補程式」，而非「applyPatch() 在第 42 行拋出例外」
- 重現步驟是強制的——如果您無法確定，請詢問使用者
- 保持簡潔——一個開發人員應能在 30 秒內閱讀完議題
在建立議題後，列印所有議題 URL（並摘要阻斷關係），然後詢問：「下一個問題，還是我們結束了？」
5. 繼續工作階段
持續進行，直到使用者說他們結束了。每個議題都是獨立的——不要批次處理。