spike

スパイク

実現可能性を調べるための使い捨て実験です。変更に、未検証の手法、外部 API、「これは可能なのか？」という未解決の疑問など、未検証の技術的リスクが伴う場合は、OpenSpec の成果物を書く前にスパイクを実施します。目的は、リスクの高い疑問への答えをスクリプト程度のコストで得て、実現できないアイデアを安価に見切ることです。

基本原則： コードは使い捨てです。後片付けが必要なスパイクは作り込みすぎです。残るのは結論だけです。

使用するタイミング

必須ではなく、リスクに応じて判断します。実現可能性が本当に不明な場合にのみスパイクを実施します。手法が明らかに実現可能なら、そのまま計画に進んでください。手法を選ぶのに必要な範囲で調査し、最もリスクの高い未知の要素からスパイクします。難所が機能しないのであれば、簡単な部分を試作しても意味がありません。

プロセス

1. 分解する — 具体的な実現可能性の確認事項を 2～5 件、Given／When／Then 形式で整理し、リスクの高い順に並べます。最も危険な未知の要素を最初に扱います。
2. すり合わせる — 確認事項と計画を提示し、コードを書く前にユーザーに調整してもらいます。
3. 最小限に作る — スクラッチ用の場所（/tmp、REPL、単発の curl など）に、動作する最小限のものを書きます。変更の作業ツリー内には決して作成しません。すべてハードコードします。パッケージ化、Docker、設定、ビルドツールは不要です。これはスパイクです。
4. 観察する — 実行し、実際の出力を記録します。観察できる結果がなければ、スパイクで何も証明していません。
5. 結論を出す — 次のうち 1 つだけを選び、その理由を 1 文で添えて完了します。
   • VALIDATED — 手法は機能します。変更の計画に進んでください。
   • PARTIAL — 一部だけが機能します。その範囲に絞ってから計画してください。
   • INVALIDATED — 手法は機能しません。変更を作成しないでください。

スパイクの後

スクラッチコードを破棄します。結論を呼び出し元に返します。spec-driven-tdd の Plan フェーズでは、これによって /opsx:propose を実行するかどうかが決まります。