prototype

プロトタイプ

プロトタイプとは疑問に答えるための使い捨てコードである。疑問が形を決める。

分岐を選ぶ

どの疑問に答えようとしているのかを特定する — ユーザーのプロンプトから、周辺のコードから、あるいはユーザーがいるなら尋ねて：

• 「このロジック / ステートモデルは妥当か？」 → LOGIC.md。紙の上では判断しづらいケースにステートマシンを通せる、小さな対話型ターミナルアプリを作る。
• 「これはどう見えるべきか？」 → UI.md。1 つのルート上に大胆に異なる複数の UI バリエーションを生成し、URL の検索パラメータとフローティングボトムバーで切り替えられるようにする。

2 つの分岐が生む成果物はまったく違う — ここを間違えるとプロトタイプ全体が無駄になる。疑問が本当に曖昧でユーザーにも連絡がつかない場合は、周辺のコードにより合う方をデフォルトにし（バックエンドのモジュール → ロジック、ページやコンポーネント → UI）、その前提をプロトタイプの先頭に明記する。

両分岐に共通のルール

1. 初日から使い捨てであり、そうと明記されていること。 プロトタイプのコードは実際に使われる場所の近く（プロトタイプ対象のモジュールやページの隣）に置いて文脈を分かりやすくする — ただし、通りすがりの読者にもプロトタイプであって本番コードではないと分かる名前を付ける。使い捨ての UI ルートには、プロジェクト既存のルーティング規約に従うこと。新しいトップレベル構造を発明しない。
2. 1 コマンドで実行できること。 プロジェクト既存のタスクランナーが使えるもの — pnpm <name>、python <path>、bun <path> など。ユーザーが何も考えずに起動できなければならない。
3. デフォルトで永続化なし。 状態はメモリに置く。永続化はプロトタイプが_検証する_対象であって、依存する対象ではない。疑問がデータベースを明示的に含む場合は、「PROTOTYPE — 消してよし」と分かる名前のスクラッチ DB かローカルファイルを使う。
4. 磨き込みはしない。 テストなし、プロトタイプを_動かす_のに必要な分を超えるエラーハンドリングなし、抽象化なし。要点は素早く何かを学んで、捨てることだ。
5. 状態を可視化する。 すべてのアクションの後（ロジック）またはバリアント切り替えのたび（UI）に、関連する状態の全体を出力・描画し、何が変わったかユーザーに見えるようにする。
6. 終わったら削除するか吸収する。 プロトタイプが疑問に答えたら、削除するか、検証済みの決定を本物のコードに畳み込む — リポジトリに放置して腐らせない。

完了したら

プロトタイプから残す価値があるのは_答え_だけだ。それが答えていた疑問とともに、永続的な場所（コミットメッセージ、ADR、Issue、あるいはプロトタイプの隣の NOTES.md）に記録する。ユーザーがいるなら、その記録は短い会話で済む。いないなら、プレースホルダーを残しておき、プロトタイプを削除する前に本人（または次のパスの自分）が結論を書き込めるようにする。