tracer-prototype

プロトタイプ

プロトタイプとは、問いに答えるための使い捨てコードです。問いによって形が決まります。

分岐を選ぶ

どの問いに答えるのかを特定します。ユーザーのプロンプトや周辺のコードから判断するか、ユーザーに連絡が取れる場合は尋ねてください。

• 「このロジック／状態モデルは適切だろうか？」 → LOGIC.md。紙上では推論しにくいケースでステートマシンを動かせる、小さなインタラクティブなターミナルアプリを作成します。
• 「これはどのような見た目にすべきだろうか？」 → UI.md。1 つのルートに複数の大きく異なる UI バリエーションを生成し、URL の検索パラメーターと画面下部のフローティングバーで切り替えられるようにします。

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

両方に適用されるルール

1. 初日から使い捨てとし、そのことを明確に示します。 プロトタイプのコードは、実際に使用される場所の近く（プロトタイプ対象のモジュールやページの隣）に配置し、文脈が明らかになるようにします。ただし、一般の読者が本番用コードではなくプロトタイプだと分かる名前を付けてください。使い捨ての UI ルートでは、プロジェクトがすでに採用しているルーティング規則に従い、新しいトップレベル構造を作らないでください。
2. 実行コマンドは 1 つにします。 pnpm <name>、python <path>、bun <path> など、プロジェクトで既存のタスクランナーがサポートするものを使います。ユーザーが迷わず起動できるようにしてください。
3. デフォルトでは永続化しません。 状態はメモリ上に保持します。プロトタイプで検証するのは永続化そのものであり、永続化に依存させるべきではありません。問いでデータベースが明示的に必要な場合は、一時的なデータベースか、「PROTOTYPE — wipe me」という明確な名前のローカルファイルを使用します。
4. 仕上げにこだわりすぎないでください。 テスト、プロトタイプを 実行可能にする ために必要な範囲を超えるエラー処理、抽象化は不要です。目的はすばやく学ぶことです。
5. 状態を見えるようにします。 ロジックの場合はアクションのたびに、UI の場合はバリエーションの切り替えごとに、関連する状態全体を出力または表示し、何が変わったかをユーザーが確認できるようにしてください。
6. 完了したら記録します。 問いを提示したワークフローに、検証済みの判断を記録します。ビルドのワークフローなら実装コード／仕様に、/tracer-wayfinder なら起点となった判断チケットに記録します。プロトタイプ自体は、メインブランチの外にある使い捨てブランチで一次情報源として保存し、起点となった issue またはチケットに参照先を残してください。結論と、そこで解決した問いも記録します。プロトタイプで計画上の問いに答えられたというだけで、Wayfinder のプロトタイプを本番コードにすることは決して避けてください。