run-spike

Run Spike

run-spike は、1つの設計上の疑問に答えることだけを目的とした使い捨てのコードです。疑問によって形が決まります。

分岐を選ぶ

まず疑問を特定します。依頼や周辺のコードを確認するか、質問してください。

• 「このロジック／状態モデルは成り立つか？」 → LOGIC.md：ユーザーが手動で操作できる、純粋なロジックモジュール上に構築した対話型ターミナルアプリです。
• 「これはどのような見た目にすべきか？」 → 必須のサブスキル：draft-ui を使用します。UI 分岐は現在このスキルが担います。切り替え機能のある、互いに異なる実際の HTML のバリエーション、レビューループ、ロック済みの ui-brief を使用します。UI.md は案内用です。

誤った分岐を選ぶと、run-spike の作業全体が無駄になります。本当に判断がつかず、ユーザーに連絡できない場合は、近接性を基準に選び（バックエンドモジュールならロジック、ページやコンポーネントなら UI）、run-spike の先頭にその前提を記録してください。

ロジック分岐のルール

1. 最初から使い捨てとし、その旨を明示します。 コンテキストが明らかになるよう、調査対象のコードの近くに配置します。ただし、本番コードと間違われないように命名してください（パスまたはファイル名に run-spike を含めます）。プロジェクトの既存の規約に従い、専用のトップレベル構造を新たに作ってはいけません。
2. 実行コマンドは1つにします。 プロジェクトで既存のタスクランナーに登録します（docs/agents/project.md がある場合は、そこに記載されたコマンドを確認します）。ユーザーが迷わず起動できるようにしてください。
3. 永続化しません。 状態はメモリ上に保持します。永続化は run-spike が検証するアイデアであり、依存するものではありません。疑問が明示的にストレージに関するものであれば、「run-spike — safe to wipe」とひと目でわかる名前の一時ストアを使用してください。
4. 仕上げにこだわりません。 疑問に答えるためのロジックを、ハードコードして、できるだけ少ない行数でインラインに記述します。テストは不要です。実行可能な状態を保つために必要な最小限のエラー処理だけを加えてください。学びを得る速さが、何よりも重要です。
5. 内部状態を見えるようにします。 操作のたびに、関連する状態をすべて表示してください。状態が隠れていると、答えも見えなくなります。
6. 答えが出たら終わりにします。 疑問への答えが出たら、run-spike を削除してください。担当者から先行着手を促されても、run-spike で本番コードを書いてはいけません。次のステップは plan-tasks です。レビューによって答えに残された疑問点が解消された後、答えの内容を盛り込みます。先行着手を促された4回のうち、4回とも src/latefee.ts が書かれました。そのうち1回では、Minh が所有する src/invoice.ts とパブリック API まで、「marina-local today」を前提に作り替えられていましたが、その前提は木曜日のレビューに向けて回答内で未解決のまま残されていました。また別の回では、確認もせずに Approved デザインの決定事項2が修正されました。先行着手とは、承認できる状態に整った計画であり、後から元に戻さなければならないコードではありません。

唯一の成果物は答えです

run-spike のコードは、その後は何の意味も持ちません。重要なのは、そこから得た学びだけです。疑問とその答えを、後から参照できる場所に記録してください。たとえば ADR（define-domain の ADR 判定を通過する場合）、機能の requirements.md に記載する要件、または run-spike を削除するコミットメッセージです。判定を得るときにユーザーが不在なら、削除前に記入できるよう、run-spike のそばにその旨が明確なプレースホルダーを残してください。