/crucible
まず読み、最後に質問してください。人間はコードが答えられないことだけに答えます。
ステップ1: 読む（まだ質問しない）
コードが既に決定している事実を path:line 形式で書き出してください。後続の質問はすべて、これらの事実が答えられなかったものでなければなりません。
ステップ2: ラダー（新しいものを提案する前）
要求された変更の各部分について、最初の「はい」で止まります。
- スキップまたは削除できますか？ 要件が既に満たされているか、不要ですか？ → その旨を述べる。
- リポジトリに既に存在しますか？ 既存のヘルパー、コンポーネント、またはパターン → 再利用する（
path:lineを引用）。 - 標準ライブラリまたは既存の依存関係にありますか？ → それを使う。
- その場合のみ： 推測的なオプションや抽象化なしに、最小限の新しいコード。
ステップ3: 五つの軸
各軸について、確定（コードまたは要求を引用）または未解決とマークします。
- スコープ: 含まれるもの、および明示的に含まれないもの。
- データと状態の不変条件: 常に真でなければならないこと。マイグレーションは？
- 障害モード: 不正な入力、タイムアウト、部分的な障害、リトライで何が起こるか。
- セキュリティと信頼の境界: 誰が、どのデータでこれを呼び出せ、検証はどこにあるか。
- 検証の証明: 完了したことを証明するチェック（
/proofに渡す）。
ステップ4: 未解決のものだけを質問する
- 軸が未解決で、その答えが設計を変更しますか？ → 質問する。バッチあたり最大3問。各質問には推奨する回答とそのトレードオフを含め、人間が「はい」と言えるようにします。
- 未解決だが影響が小さいですか？ → 決定し、
assumedとして記録します。 - すべて確定していますか？ → 何も質問しない。ステップ5に進みます。
- 真のアーキテクチャ上の分岐があり、他のモデルの見解を聞く価値がありますか？ → この記録を成果物として
/councilに送信します。
ステップ5: 記録
.ramos/decisions/<topic>.md を書きます。
# <topic> (<date>)
## 事実（コードから） - … (path:line)
## ラダーの結果 - Xの再利用 / Yの標準ライブラリ / Zの新規 (理由)
## 軸 | 軸 | 確定/想定/回答済み | 決定 | ソース |
## スコープ外 - …
## 証明 - /proof が実行する正確なコマンド
完了条件
すべての軸が確定、想定、または回答済みであり、記録が存在し、証明コマンドが指定されていること。未回答の設計変更質問がある場合 → 停止し、人間に blocked を報告する。コーディングを開始しないでください。