prototype

プロトタイプ

1つの問いに答える、使い捨てのプロトタイプを作成します。プロトタイプ自体は機能ではなく、残す必要がある成果物はその答えだけです。

プロトタイプのメモまたは最終回答の冒頭に、次の内容を記載します。

• 答える問い。
• ブランチ：ロジックまたは UI。
• ブランチが曖昧だった場合の前提。
• どのような結果が得られれば、プロトタイプが役に立つか。

ブランチを選ぶ

ブランチによって成果物は異なります。選択を誤ると、プロトタイプが無駄になります。

• ロジックブランチ：ステートマシン、ドメインモデル、アルゴリズム、API の形状、解析、バリデーション、永続化の動作、ビジネスルールに使用します。
• UI ブランチ：画面、コンポーネント、視覚的な階層、インタラクションモデル、コンテンツのレイアウト、プロダクトのフロー比較に使用します。

問いが本当に曖昧で、ユーザーに連絡できない場合は、周辺のコードに合うブランチを選びます。バックエンドやモジュールに関する問いにはロジックを、ページやコンポーネントに関する問いには UI を使用します。構築を始める前に、前提を明記します。

共通ルール

• リポジトリのスクラッチ／プロトタイプ用の規約に従い、作業を分離します。そのような規約がない場合は、docs/prototypes/<slug>/、prototype/<slug>/、または使い捨てであることが明確なローカルフォルダーを優先します。
• 問いに答えるために実際のアプリシェル内で作業する必要がない限り、本番用パスは編集しません。本番用パスに触れる必要がある場合は、差分を簡単に削除できる状態にします。
• 可能な限り、既存のランタイムとタスクランナーを使用します。
• 1つのコマンドで実行できるプロトタイプにします。
• 問いが永続化に関するものでない限り、状態はメモリ上に保持します。永続化が問いに含まれる場合は、スクラッチデータベースまたはローカルファイルを使用し、PROTOTYPE-wipe-me という名前を明確に付けます。
• 大規模な新規依存関係の追加は避けます。問いに直接答えるために必要で、簡単に削除できる場合に限り、依存関係を追加します。
• 答えを、最終回答、親チケット、親仕様書、ADR、またはプロトタイプと同じ場所にある NOTES.md など、後から確認できる場所に記録します。

ロジックブランチ

動作を表す、実行可能な最小限のモデルを作成します。

• ターミナルスクリプト、ユニットテスト形式のハーネス、REPL コマンド、フィクスチャーランナー、または小規模なローカルサービスを使用します。
• 重要な状態、遷移、不変条件、失敗ケースを、プロトタイプ内に直接記述します。
• 現実的なサンプルデータを使いますが、規模は小さく、ローカルに保ちます。
• 問いに答えるシナリオを出力またはアサートします。
• モデルによって設計の妥当性が証明または否定されたら終了します。周囲に UI を作る必要はありません。

ロジックブランチでは、見えにくい動作を可視化します。洗練された見せ方より、明確な実行記録やテスト出力を優先します。

UI ブランチ

洗練されたモックを1つ作るのではなく、意味のある違いがある複数のバリエーションを作成します。

• バリエーションは、1つのルート、ページ、またはローカルプレビュー画面に配置します。
• タブ、トグル、クエリパラメーター、またはセグメントコントロールを使い、バリエーションを切り替えられるようにします。
• 問いがライブデータの動作に関するものでない限り、モックデータをローカルで用意します。
• 比較に役立つ場合は、アプリの既存のコンポーネント、スタイリングトークン、レイアウト規約を再利用します。
• 利用可能であれば、ブラウザーまたはプレビュー環境でプロトタイプを検証します。

UI ブランチでは、トレードオフをすぐに明らかにします。細かな見た目の調整より、デザイン上の問いに答える異なる案を優先します。

出力

次の内容を報告します。

• プロトタイプのパスと実行コマンド。
• 使用したブランチとその理由。
• プロトタイプから得られた答え。
• 維持するもの、破棄するもの、本番作業に移すもの。
• 残っている不確実な点。

探索から実装へ移るようユーザーから指示された場合は、プロトタイプを削除するか、使い捨てであることを明示します。