プロトタイプ

プロトタイプはある質問に答えるための一時的なコードです。質問の内容が成果物の形を決めます。

ブランチを選択する

ユーザーのプロンプト、周囲のコード、またはユーザーへの質問から、どの質問に答えているかを判断します：

• 「このロジック/状態モデルは正しく感じられるか？」 → LOGIC.md。紙上では推論しにくいケースを状態機械に通す、小さなインタラクティブなターミナルアプリを作成します。
• 「これはどのように見えるべきか？」 → UI.md。単一ルート上に複数の根本的に異なる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）に記録してください。ユーザーがいる場合は、その記録は素早い会話です。そうでない場合は、プロトタイプを削除する前に彼ら（またはあなた、次のパス時）が判定を入力できるようにプレースホルダーを残してください。