Thought Experiment バージョン 0.6.0 α — 厳格な障害シナリオ監査と修正
トリガー: 「thought experiment」というフレーズのみ。それ以外の類推表現は無効です。明示的な要求と明確な対象がなければ実行されません。これは意図的な設計であり、自律的な動作ではありません。
対象: 制限なし。単一ファイル、プロジェクト全体、設定ファイル、API契約、インフラストラクチャ設定など、自身の動作、構造、または依存する何かについて誤っている可能性のある主張を行うあらゆるもの。
通常のレビューとの違い: 2つあります。第一に、「この入力/この状態を考えると、ここで正確に何が壊れ、なぜ壊れるか」という具体的なシナリオを生成します。「これはもっとクリーンにできる」というような曖昧な提案ではありません。第二に、対象が自分自身の外部の何かがどのように動作するかについて行っている主張を特に探します。なぜなら、その種の主張は、対象自身のロジックを読むことで発見されるよりも、記憶に頼って静かに誤ったままになりやすいからです。
ラウンド前のコミット確認（安全レール）: ラウンドを開始する前に、未コミットの変更がある場合は、それをコミットまたはプッシュするよう厳しく求め、推奨します。事前のクリーンなチェックポイントにより、ラウンドで損害が発生した場合でも、常にその時点にロールバックできます。
プロセス
- 対象を新たに読み込む。 現在の実際の状態（ファイル、設定など）を取得します。対象に含まれるべきものについての以前のコンテキストに依存しません。
- その依存関係を列挙する。 対象が自身の外部の根拠として扱うものすべて：スクリプトの場合 — インポートされたライブラリ、呼び出されるAPI、CLIツールとそのフラグ、環境/設定の前提条件。サービスまたはクラウド設定の場合 — 通信する他のサービス、権限/IAM、DNS、証明書、サードパーティAPI、ネットワークパス。ドキュメントの場合 — 他の何かの動作について行うすべての事実主張。このリストを意図的に構築します — ステップ4で検証され、依存関係をスキップすると、実際のバグを見逃す可能性があります。対象が特にデプロイメントに向かっている場合は、以下もチェック：ロールバックの安全性、開発/本番設定のパリティ、シークレットハンドリング、記載された互換性ベースライン、および開発環境のみのテストでは必ずしも明らかにならない初回ロード/実環境でのパフォーマンス。ペアとなるドキュメント（READMEとそのSKILL.md、またはコード/設定とそれを説明するドキュメント）の場合、各ファイルがもう一方について述べている主張を検証する依存関係として扱います — そして別途、確立された書式規則（列挙値の太字/大文字小文字の扱い、見出しスタイル）が対象内およびその兄弟ファイル間で一貫して適用されているかどうかを確認します。ただし、そのような規則が実際に存在してチェックの対象となる場合のみ。
- 具体的な障害シナリオの思考実験を構築する。 特定の入力または状態が、特定の誤った出力、クラッシュ、またはセキュリティホールにつながるもの — 一般的な印象ではありません。シナリオ数を事前に固定しないでください。任意の数に達したからではなく、対象の実際のリスク表面をカバーしたと感じるまで生成し続けます。
- シナリオが依存するすべての依存関係の動作主張を、ライブまたは信頼できる情報源（実際のドキュメント、実際のAPI応答、ツールの実際の出力）に対して検証する — 記憶に頼らない。このステップが通常、最も価値の高い発見をもたらします。
- 修正の承認方法を、修正を適用する前に1回だけ尋ねる — CRUDオプション。読み取りは常に自由に許可され、決して制限されません。作成/更新/削除のみがゲートされます。包括的（確認されたすべての発見、それ以上の問い合わせなし）、プロセス毎（ラウンドごとに1回確認、ラウンド内のファイルごとではない）、ファイル毎（次のファイルの修正に移る前に確認）、またはCRUDステップ毎（個々の編集を確認）— ユーザーが選択したものが、その後の実行全体に適用されます。包括的は、日常的な確認済みの発見をカバーしますが、無条件のオーバーライドではありません。ユーザーが包括的許可を与えた時点で想定していたよりも本当に驚くべき、またはリスクの高い発見があった場合は、一時停止して確認を求めます。
- 確認された発見に対して修正を適用する、承認された粒度で。
- 修正された状態に対して、同じプロセスを再度実行する。 修正はそれ自体が新しい問題を引き起こす可能性があります — 正確性の修正が他の何かを矛盾させたり、修正された主張が別の前提を破ったりする可能性があります。パスで新しい問題が何も見つからなくなるまで、ループは終了しません。
- 報告する。 各シナリオの合格/不合格を平易に述べます。確認された失敗、または詳細が明示的に求められた場合にのみ、完全な詳細を提供します — クリーンな合格にエッセイを書く必要はありません。各失敗を、ブロッキング（出荷/デプロイ前に修正必須）または非ブロッキング（出荷しても問題ない、後で修正）としてタグ付けし、レポートが単なる発見リストではなく、GO/NO-GOの判断材料として機能するようにします。すべての実行を、プロセス全体に散在するシナリオごとの言及ではなく、1つの統合された列挙サマリーで締めくくります — スコープに応じてスケーリング：マルチターゲット実行（複数のファイル、複数のスキル）の場合はターゲットごとに1つのセクション。単一のクリーンなターゲットの場合は、飾り気のない1行の判定行。
新しい行で、すべてのレポートを thought experiment で締めくくります。