prototype

プロトタイプ

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

分岐を選ぶ

ユーザーのプロンプトや周辺のコードから、あるいはユーザーに確認して、どの疑問に答えるのかを特定します。

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

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

両方に適用されるルール

1. 最初から使い捨てとし、そのことを明確に示します。 プロトタイプ対象のモジュールやページの近くにコードを置き、文脈が分かりやすいようにします。ただし、ぱっと見で本番用ではなくプロトタイプだと分かる名前を付けます。使い捨ての UI ルートには、プロジェクトで既に使われているルーティング規約に従います。新しいトップレベルの構成は作りません。
2. 実行コマンドは 1 つにします。 pnpm <name>、python <path>、bun <path> など、プロジェクトで既存のタスクランナーがサポートしている方法を使います。ユーザーが迷わず起動できるようにします。
3. デフォルトでは永続化しません。 状態はメモリ上に保持します。永続化はプロトタイプで確認する対象であり、プロトタイプが依存すべきものではありません。疑問にデータベースが明示的に関係する場合は、一時的な DB、または「PROTOTYPE — wipe me」という名前が明確なローカルファイルを使用します。
4. 仕上げに時間をかけません。 使い捨ての足場作りでは、テスト基盤や仕上げは省略します。それでも、プロトタイプで答えるべき疑問は必ず確認します。本番用に昇格させるロジックには、プロジェクトで通常使われているテストとエラー処理が必要です。目的は素早く学び、その後に削除することです。
5. 状態を見えるようにします。 ロジックでは操作のたびに、UI ではバリエーションを切り替えるたびに、関連する状態全体を出力または描画し、何が変わったかユーザーが確認できるようにします。
6. 完了したら削除するか取り込みます。 ユーザーが結果を確認した後、プロトタイプを削除するか、検証済みの判断を実際のコードに取り込むかを相談します。リポジトリに放置して腐らせてはいけません。

完了したら

プロトタイプから残す価値があるのは、その答えだけです。答えを、回答した疑問とともに、コミットメッセージ、ADR、イシュー、またはプロトタイプの隣に置く NOTES.md など、後から確認できる場所に記録します。ユーザーに連絡できる場合は、簡単な会話で記録します。連絡できない場合は、ユーザー（または次回作業する自分）がプロトタイプを削除する前に結論を記入できるよう、プレースホルダーを残します。