QA 計畫
透過蘇格拉底式檢驗，為用戶故事推導基準測試計畫：包含具有已宣告設計技術的測試條件、僅在規格支援時才斷言的預期結果，以及針對能夠解決其餘問題的人提出的問題。你不需要問「這個故事寫得好嗎？」，那是 /refine-story 的工作。你需要回答：什麼會出錯？我如何證明它能運作？為了執行這個證明，必須存在什麼？
中階 QA 工程師應能直接從此產出物實作測試；資深 QA 工程師應同意其優先順序。
US：$ARGUMENTS
三層邊界
推導未明寫的條件是 QA 的本質，前提是它遵循既定的方法。因此，這裡的邊界在三層之間運作；基礎仍然是 requirements-rigor。計畫中的每個條件都恰好屬於一個層次：
[SPECIFIED: excerpt]：條件和預期結果直接來自文字。請引用來源。[DERIVED: technique]：條件來自應用於已指定內容的測試設計技術。務必命名該技術；沒有宣告技術的條件即為猜測，不得納入。預期結果僅在邏輯上從規格推導得出時才能斷言。[UNDEFINED -> Question n]：一個合理的條件，但其預期結果未在規格中定義。條件會納入矩陣；結果則成為一個編號問題。
快速測試：「哪個技術產生了這個條件，它源自哪個摘錄？」如果其中任何一個問題無法回答，則將其從計畫中排除。
開始之前
讀取工作區中的 docs/agents/refinement.md：它定義了操作模式（有或無程式碼）、語言（en-US 或 pt-BR，預設為 en-US）以及發布路徑。模式決定了誰來回答架構問題：有程式碼時，你透過檢查程式碼庫來解決它們；無程式碼時，工程團隊透過問卷調查來解決。蘇格拉底式檢驗和 QA 計畫使用設定的語言撰寫。如果檔案遺失，請求 /configure-refinement 並停止。
步驟
-
載入。 讀取 US、
CONTEXT.md、領域 ADR、TEST-DESIGN.md，並為requirements-rigor調用技能工具。如果來自/refine-story的.scratch/<slug>/spec.md存在，則從它開始：該工作階段的決策已回答了許多問題。沒有這個檔案，則將 US 視為未精煉，即使Status:顯示為 READY。 完成條件：可測試性分類在一行中陳述：TESTABLE（每個預期結果都有一個觀察點，且沒有待確認的依賴項）、TESTABLE WITH RESERVATIONS（可以推導條件，但至少一個結果缺少觀察點或依賴於未確認的依賴項）或 NOT TESTABLE。 -
分類。 NOT TESTABLE（標準未能描述可觀察行為：純粹為任務，或所有標準中未附指標的主觀術語）：解釋缺少什麼，列出 3 到 5 個最小問題，並建議
/refine-story。在此停止；分析不可測試的資料會產生表面計畫。如果 US 尚未經過精煉，請說明此情況並繼續進行，並指出許多問題將由/refine-story解決。 完成條件：已宣告分類。 -
推導條件。 對於每個標準，套用來自 TEST-DESIGN.md 的適用技術，避免強行使用不適用的技術，並審查遺漏的面向，僅報告適用的部分。建立矩陣：條件、來源、預期結果或
[UNDEFINED -> Question n]、優先級、層次。未定義的條件保留在矩陣中：可見的未來覆蓋率遠優於隱藏的缺口。在 PO 和 DEV 之間以單一序列為問題編號，以便[UNDEFINED -> Question n]能夠明確解析。優先級理由（每個條件半行）放在風險分析部分內的清單中，而不是表格內。 完成條件：每個條件都有一個已宣告的來源，且每個[UNDEFINED]都有一個分配的問 題編號。 -
在提問前搜尋事實。 按收件人區分問題。PO：未定義的業務行為。DEV：架構、可觀察性、測試層次、外部依賴隔離、時間控制、測試資料供應、API 錯誤回應、失敗後的永續性、技術冪等性。在程式碼模式中，派遣一個子代理來通過閱讀程式碼來回答 DEV 問題：通知是同步還是非同步？批准上是否有鎖？外部系統是否存在模擬物件？找到的事實成為預期結果或定義的層次，並附上來源引用。在無程式碼模式中，搜尋限制在工作區檔案內，沒有子代理；如果找不到任何內容，則在第一輪頂部用一行說明。 完成條件：每個問題都被標記為已由來源回答或保持開放，並分配了收件人。
-
檢驗 PO。 為
socratic-examination調用技能工具。問題回合伴隨著當前的矩陣，因為問題引用特定的條件。前線由 PO 問題組成，首先是阻塞性項目（那些解鎖 P1 條件的項目），每個問題都帶有推薦答案（當規格提供基礎時）；當缺乏時，提供「無推薦」（或 pt-BR 的 "sem recomendação"）和選項。PO 的回答會立即更新矩陣。根據詞彙表挑戰術語，但僅將 PO 解決的內容記錄在CONTEXT.md中。 完成條件：PO 問題前線為空，或 PO 要求結束。 -
綜合。 按照 TEMPLATE.md 編寫計畫：矩陣、風險分析、帶有自我審計的 Gherkin P1 場景、自動化審計、僅基於現有系統文件（沒有上下文時，為 DEV 列出影響問題）的迴歸影響、按收件人劃分的剩餘問題、覆蓋率判決。 完成條件：檔案存在於由
docs/agents/refinement.md定義的路徑，並包含最終免責聲明。 -
路由未解決項目。 在無程式碼模式中開放的 DEV 問題和無法回答的開放 PO 問題：按照
requirements-rigor中的QUESTIONNAIRE.md，為每個收件人撰寫一份問卷，與計畫一起，並從開放問題連結檔案。 完成條件：沒有開放問題保留而沒有收件人或問卷。 -
報告。 判決、計畫發布位置、可執行的 P1 條件數量，以及每個問卷解鎖的內容。
最終通知
⚠️ 此輸出提供測試計畫的分析基準，而非最終測試計畫。關於覆蓋率、優先順序和投入的決策屬於 QA 團隊，並需經過 PO（未定義行為）和 Dev（架構和層次）的驗證。