/crucible
先閱讀，最後再問。人類只回答程式碼無法回答的問題。
步驟 1：閱讀（先不發問）
以 path:line 的格式寫下程式碼已經決定的事實。之後的每個問題都必須是這些事實無法回答的事項。
步驟 2：階梯（在提出任何新方案之前）
針對請求變更的每個部分，在第一個「是」的地方停下來：
- 我們可以跳過或刪除它嗎？ 需求是否已經滿足，或根本不需要？ → 說出來。
- 它是否已經在儲存庫中？ 現有的輔助函式、元件或模式 → 重複使用（引用
path:line）。 - 它是否在標準函式庫或現有的依賴項中？ → 使用它。
- 只有在那之後： 最小化的新程式碼，不要有推測性的選項或抽象化。
步驟 3：五個軸線
針對每個軸線，標記為已確定（引用程式碼或請求）或未確定：
- 範圍：包含什麼，以及明確排除什麼。
- 資料與狀態不變量：必須永遠為真的事項。需要遷移嗎？
- 失敗模式：當遇到錯誤輸入、超時、部分失敗、重試時會發生什麼。
- 安全與信任邊界：誰可以呼叫此功能，可以傳入什麼資料，以及驗證邏輯在哪裡。
- 驗證證明：哪個檢查可以證明它已完成（饋送給
/proof）。
步驟 4：只詢問未確定的問題
- 是否有軸線未確定，且答案會改變設計？ → 發問。每批最多 3 個問題。每個問題都要提供你建議的答案及其取捨，這樣人類只需說「是」。
- 軸線未確定但風險低？ → 自行決定，並記錄為
assumed。 - 所有軸線都已確定？ → 不要發問。直接前往步驟 5。
- 是否存在真正的架構分歧，值得聽取其他模型的意見？ → 使用此記錄作為工件，召開
/council。
步驟 5：記錄
撰寫 .ramos/decisions/<topic>.md：
# <主題> (<日期>)
## 事實（來自程式碼） - … (path:line)
## 階梯結果 - 重用 X / 標準庫 Y / 新增 Z (原因)
## 軸線 | 軸線 | 已確定/假設/已回答 | 決定 | 來源 |
## 排除範圍 - …
## 證明 - /proof 將執行的確切命令
完成條件
所有軸線都已確定、假設或回答，記錄已存在，且證明命令已命名。未回答的、會改變設計的問題 → 停止並向人類回報 blocked。不要開始寫程式。