prototype

プロトタイプ

プロトタイプとは、疑問に答えるための使い捨てコードです。形は、答えるべき疑問によって決まります。

分岐を選ぶ

ユーザーのプロンプト、周辺のコード、またはユーザーが連絡可能であれば質問して、どの疑問に答えるのかを特定します。

• 「このロジック／状態モデルは適切でしょうか？」 → LOGIC.md。紙上では考えにくいケースで状態機械を動かせる、小さな対話型ターミナルアプリを作ります。
• 「これはどのような見た目にすべきでしょうか？」 → UI.md。1 つのルートで大きく異なる UI バリエーションをいくつか生成し、URL の検索パラメーターと画面下部のフローティングバーで切り替えられるようにします。

2 つの分岐でできあがるものは大きく異なります。間違えると、プロトタイプ全体が無駄になります。疑問が本当に曖昧でユーザーに連絡できない場合は、周辺のコードに合う分岐を選びます（バックエンドモジュールならロジック、ページやコンポーネントなら UI）。そして、プロトタイプの冒頭にその前提を明記します。

両方に適用されるルール

1. 初日から使い捨てとし、そのことを明確に示します。 プロトタイプのコードは、実際に使われる場所の近く（プロトタイプ対象のモジュールやページの隣）に配置して、文脈を分かりやすくします。ただし、通りがかりの読者にも本番コードではなくプロトタイプだと分かる名前を付けます。使い捨て UI ルートでは、プロジェクトで既に使われているルーティング規則に従い、新しい最上位の構造を作らないでください。
2. 実行コマンドは 1 つにします。 プロジェクトで既存のタスクランナーがサポートする方法なら何でも構いません（pnpm <name>、python <path>、bun <path> など）。ユーザーが迷わず起動できるようにします。
3. デフォルトでは永続化しません。 状態はメモリ内に保持します。永続化は、プロトタイプが検証する対象であり、プロトタイプが依存するものではありません。疑問にデータベースが明示的に関わる場合は、一時的なデータベースか、名前に「PROTOTYPE — wipe me」と明記したローカルファイルを使います。
4. 作り込みは省きます。 テストは作成せず、エラー処理はプロトタイプを_実行可能にする_ために必要な範囲にとどめ、抽象化もしません。目的は、すばやく学びを得て、プロトタイプを削除することです。
5. 状態を見えるようにします。 ロジックではアクションのたびに、UI ではバリエーションを切り替えるたびに、関連する状態全体を出力または表示して、何が変わったかをユーザーが確認できるようにします。
6. 完了したら削除するか、取り込みます。 プロトタイプが疑問に答えたら、削除するか、検証済みの判断を実際のコードに反映します。リポジトリに放置しないでください。

完了したら

プロトタイプから残す価値があるのは、_答え_だけです。答えた疑問とともに、後から確認できる場所（コミットメッセージ、ADR、issue、またはプロトタイプの隣に置く NOTES.md）に記録します。ユーザーに連絡できる場合は、記録の内容を短く話し合います。連絡できない場合は、ユーザー（または次回のあなた）がプロトタイプを削除する前に結論を記入できるよう、記入欄を残します。