principle-attack-the-premise | 先驗證共同前提

本頁以 pstack-claude 0.9.126 為基準。原文標示 user-invocable: false，通常由 poteto-mode 按需讀取。這是推進除錯的原則，不是獨立命令。下文以自然語言要求代理套用。

定位與適用情境

當兩次以上修正都依賴同一個前提，卻仍在同一個驗收關卡失敗，不要立刻提出第三個同類補丁。先把共同相信的事寫成一句可被推翻的敘述。

例如匯出工作偶爾漏資料。團隊先延長逾時，再增加重試，仍無法讓所有輸入通過完整性檢查。兩個修正都假設「漏資料是因為網路太慢」。本原則要先檢驗這個假設，而不是再調一次逾時。

這與為新需求重做架構不同。這裡質疑的是現有設計一直當成事實的前提。

準備

收集兩次失敗修正的差異、同一個驗收關卡及可重現的輸入。
準備可在測試環境觀察的請求紀錄、回應狀態與逐筆資料識別碼。
同時保留成功與失敗案例。除了漏掉多少資料，也要知道哪些資料在什麼條件下失敗。
先限定可修改的測試檔與診斷工具位置，不碰正式資料。

操作步驟

寫出共同前提。 把延長逾時與重試所依賴的推論列在一起，確認兩者確實都假設網路延遲是原因。若失敗其實不同，不要硬湊成同一個問題。
設計能區分真假的觀察。 在相同匯出輸入下，對照請求是否逾時、回應是否完整、最終輸出缺哪些識別碼。若完整回應已含有後來遺失的資料，網路逾時就不能解釋該次遺失。
把觀察做成可重跑檢查。 保存測試輸入與逐筆比對工具，讓下一位維護者能重現相同判定。依案例條件分組檢查失敗分布，不只看總遺失量。
依證據換方向。 若前提被推翻，追查失敗案例真正共有的條件，例如只發生在轉換後的輸出。若前提得到支持，繼續追問為何延遲會造成遺失，不能把支持前提誤當已找到根因。
消除造成失敗的條件並重驗。 在證據指向的第一個錯誤處修正，重跑原關卡與成功案例。能移除錯誤條件，就不要留下每次執行都要補救的機制。

可直接使用的提示詞

套用 principle-attack-the-premise。
同一個匯出完整性測試在延長逾時、增加重試後仍失敗。
輸入是這兩份修正差異、成功與失敗的測試資料、請求紀錄。
請先寫出兩次修正共有的前提，不要直接提第三個補丁。
設計一個前提為假時會得到不同結果的觀察，並保存可重跑的逐筆比對檢查。
同時比較失敗分布與總量。若證據不足，列出缺少的觀察。
只在核准的測試環境操作。驗證前提後，再提出根因修正方向。

預期結果與驗收

讀者應取得一份包含「共同前提、可區分的預測、實際觀察、後續決策」的紀錄，以及能重跑的檢查。第三次修正應出現在前提驗證之後。

驗收時，請另一位維護者使用相同輸入重跑，確認能得到相同的逐筆差異與案例分類。若工具只能輸出「仍失敗」，卻無法判斷前提是否成立，這次檢驗還不夠具體。

常見誤用是把前提改寫得無法反駁，例如「系統某處不穩」。另一種是看到一次成功就宣告前提正確。需要保留反例與觀察條件，沒有反例不等於已證實因果。

限制與權限

原則不保證一次就能找到根因。紀錄缺漏時應回報未能確認，不能把推測寫成已證實原因。新增診斷也應避免記錄憑證與個人資料。

測試、修改及資料存取仍受專案授權限制。不要為了驗證前提直接調整正式服務、刪除快取或重送有外部副作用的工作。

延伸閱讀與來源

匯出案例與操作順序是本頁教學示例，不代表上游回報過這個缺陷。