prototype

プロトタイプ

Prototype は問いに答えるための使い捨てコードです。形は問いによって決まります。

分岐の選択

まず、どの問いに答えようとしているのかを特定します。問いはユーザーの prompt や周辺のコードから把握するか、ユーザーがオンラインの場合は直接確認してください。

• 「このロジック／状態モデルでよさそうですか？」 → LOGIC.md。単一の共有可能な HTML ファイル（自由に操作できるボタンと、タブ付きのガイド付きウォークスルー）を作成し、紙の上では推論しにくいケースで state machine を動かします。開発者以外でも操作できるようにしてください。
• 「どのような見た目にするべきですか？」 → UI.md。単一のルート上に大きく異なる UI のバリエーションをいくつか生成し、URL の検索パラメーターとフローティングボトムバーで切り替えられるようにします。

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

どちらの分岐にも共通するルール

1. 最初から使い捨てとして扱い、明確に示します。 プロトタイプコードは、実際に使う場所の近く（プロトタイプの対象となるモジュールまたはページの隣）に置き、文脈を明確にします。ただし、コードをざっと読んだ人にも本番用ではなくプロトタイプだとわかる名前を付けてください。使い捨ての UI ルートには、プロジェクト既存のルーティング規約に従います。新たなトップレベル構造を作らないでください。
2. 手間なく実行できるようにします。 UI プロトタイプは、プロジェクトのタスクランナーから 1 つのコマンド（pnpm <name>、python <path>、bun <path> など）で起動できるようにします。ロジックのデモは、ユーザーがダブルクリックするだけで開ける単一の HTML ファイルにします。どちらも、起動に頭を使わなくて済むようにしてください。
3. 永続化はデフォルトで行いません。 状態はメモリーに保持します。永続化はプロトタイプで_検証_する対象であり、依存要素にしてはいけません。問いでデータベースが明示的に扱われる場合は、スクラッチ DB または「PROTOTYPE, wipe me」というわかりやすい名前を付けたローカルファイルを使います。
4. 仕上げに時間をかけません。 テストは書かず、「動かす」ために必要な範囲を超えるエラーハンドリングや抽象化も行いません。目的は、すばやく学びを得ることです。
5. 状態を見えるようにします。 アクション（ロジックの場合）やバリエーションの切り替え（UI の場合）のたびに、関連する状態全体を出力または描画し、何が変わったかユーザーにわかるようにします。
6. 完了後に記録します。 検証済みの判断を実際のコードに反映したうえで、プロトタイプ自体を一次情報源として保存します。main 以外の使い捨てブランチにコミットし、実装 issue にそのブランチへのコンテキストポインターを残してください。また、issue またはコミットに、判断と解決した問いという答えを記録します。main ブランチには検証済みの判断だけを残します。