Thought Experiment ver 0.6.0 alpha — 嚴謹的失敗場景審計與修復
觸發詞：「thought experiment」，且僅限該短詞—不推斷同義詞。未經明確要求且沒有明確目標，絕不執行—這是故意為之，非自主執行。
範圍： 目標無關。單一檔案、整個專案、設定、API 合約、基礎設施設定—任何可能包含錯誤聲明（關於其自身行為、結構或其所依賴的事物）的目標。
這與一般審查有何不同： 兩點。首先，它會產出具體場景—「給定此輸入/此狀態，這是確切會出錯的地方及原因」—而不是模糊的「這可以更乾淨」的建議。其次，它特別追查目標對其外部事物行為的聲明，因為這類聲明最可能因為依賴記憶而非閱讀目標自身的邏輯而被悄悄忽略。
回合前的提交檢查（安全機制）： 在開始一個回合前，強烈要求並建議對任何現有未提交的變更進行提交/推送。事先有一個乾淨的檢查點，意味著該回合本身總是可以回滾到該檢查點（如果造成任何損害）。
流程
- 重新讀取目標。 拉取其當前、真實的狀態—檔案、設定，無論其包含什麼—不要依賴先前關於它應該包含什麼的上下文。
- 列舉其依賴項。 目標視為外部事實來源的任何事物：對於腳本—已導入的函式庫、被呼叫的 API、CLI 工具及其旗標、環境/設定假設；對於服務或雲端設定—其通訊的其他服務、權限/IAM、DNS、憑證、第三方 API、網路路徑；對於文件—它對其他事物行為所做的每一項事實性聲明。刻意建立此列表—步驟 4 將驗證它，而跳過的依賴項就是錯過捕捉真實錯誤的機會。當目標特別是要部署時，也需檢查：回滾安全性、開發/生產環境設定一致性、秘密處理、聲明的相容性基準，以及首次載入/真實條件下的效能表現與僅開發測試的比較—這些並不總是能從純粹的通用依賴項掃描中浮現。對於配對的文件（README 及其 SKILL.md，或文件及其描述的程式碼/設定），將每個檔案關於對方所說或所做內容的聲明視為待驗證的依賴項—並且，另外檢查建立的格式化慣例（列舉值的粗體/大小寫處理、標題風格）是否在目標內及其同級檔案間一致應用，僅在確實存在可核對的慣例時才進行檢查。
- 建構具體的失敗場景思想實驗。 導致特定錯誤輸出、崩潰或安全漏洞的特定輸入或狀態—而非一般性印象。不要預先設定場景數量；持續產生它們，直到目標的實際風險面感覺已被覆蓋，而不是達到一個任意數字。
- 驗證每個場景所依賴的每個依賴項行為聲明，對照即時或權威來源—真實文件、實際 API 回應、工具的真實輸出—而不是信任記憶。此步驟通常是最有價值發現的所在。
- 詢問修復應如何授權，一次，在應用任何修復之前 — CRUD 選項。 讀取操作始終自由授予，永不設限；僅有建立/更新/刪除需要授權。全面授權（每個已確認的發現，無需進一步詢問）、按流程（每回合確認一次，而非該回合內的每個檔案）、按檔案（在繼續到下一個檔案的修復前確認）、或按每個 CRUD 步驟（確認每次單獨的編輯）—用戶選擇的方式將適用於本次執行的剩餘部分。全面授權涵蓋常規的已確認發現，不是無條件覆寫：一個真正出乎意料或風險高於用戶在授予時所預期的發現，仍然會暫停並詢問。
- 應用修復 針對已確認的發現，以授權的粒度進行。
- 針對已修復的狀態重新執行此相同流程。 一個修復可能引入其自身的新問題—一個精確性修復導致其他事物不一致，一個修正後的聲明破壞了其他地方的不同假設。這個循環不會結束，直到某次通過沒有發現任何新問題。
- 報告。 清楚地說明每個場景的通過/失敗。僅對已確認的失敗或當明確要求細節時提供完整細節—一個乾淨的通過不需要為其撰寫一篇論文。將每個失敗標記為阻擋性（必須在部署/發佈前修復）或非阻擋性（可安全發佈，事後修復），以便報告不僅作為發現清單，也同時作為「可行/不可行」的輸入。每次執行以一個合併的列舉摘要結束，而非僅是散佈在流程中各個場景的提及—根據範圍調整規模：一個多目標執行（數個檔案、數個技能）會為每個目標提供一個章節；一個單一乾淨的目標則提供一行樸素的判決，而非冗長的儀式。
新的一行，每份報告都以 thought experiment 結尾。