prototype

プロトタイプ

プロトタイプは、設計上の疑問に答えることだけを目的とした、使い捨てのコードです。疑問によって形が決まります。

ブランチを選ぶ

まず疑問を特定します。依頼や周辺のコードから判断するか、次のように尋ねてください。

• 「このロジック／状態モデルは妥当ですか？」 → LOGIC.md：ユーザーが手動で操作できる、純粋なロジックモジュール上の対話型ターミナルアプリです。
• 「これはどのような見た目にすべきですか？」 → UI.md：ブラウザーで切り替えられる、構造の異なる同一画面の複数のバリエーションです。

誤ったブランチを選ぶと、プロトタイプ全体が無駄になります。本当に判断がつかず、ユーザーに連絡できない場合は、近いほうを選びます（バックエンドモジュールならロジック、ページやコンポーネントならUI）。その場合は、前提をプロトタイプの冒頭に記録してください。

両方のブランチに共通するルール

1. 初日から使い捨てとして作り、そのことを明示します。 周辺のコードが分かりやすい場所に配置しつつ、本番コードと誤認されないように命名します（パスまたはファイル名に prototype を含めます）。プロジェクトの既存の規約に従い、プロトタイプのために新しいトップレベルの構造を作らないでください。
2. 実行コマンドは1つにします。 プロジェクト既存のタスクランナーに登録します（docs/agents/project.md がある場合は、そこに記載されたコマンドを確認します）。ユーザーが迷わず起動できるようにしてください。
3. 永続化しません。 状態はメモリ上に保持します。永続化はプロトタイプが検証する対象であり、依存するものではありません。疑問が明示的にストレージに関するものであれば、誰が見ても「prototype — safe to wipe」と分かる名前の一時ストアを使います。
4. 仕上げにこだわりません。 疑問に答えられる最小限の行数で、ロジックはインラインにハードコードして記述します。テストは不要で、エラーハンドリングも実行可能に保てる程度にとどめます。学びを得る速さがすべてです。
5. 内部状態を表示します。 操作またはバリエーションの切り替えごとに、関連する状態をすべて表示します。隠れた状態があると、答えが見えなくなります。
6. 完了したら削除するか、取り込みます。 疑問に答えが出たら、プロトタイプを削除するか、検証済みの部分を実際のコードに取り込みます。本番コードとして再実装する際は、必須のサブスキルとして tdd を使用してください。プロトタイプのロジックは参考であり、テスト済みのコードではありません。

答えだけを成果物にする

その後、プロトタイプのコード自体は重要ではありません。重要なのは、そこから得られた知見だけです。疑問と答えを、後から参照できる場所に記録します（domain-modeling のADR基準を満たす場合はADR、機能の requirements.md の要件、またはプロトタイプを削除／取り込むコミットメッセージ）。ユーザーに判断を仰げない場合は、削除前に記入できるよう、プロトタイプの隣に明確なプレースホルダーを残してください。