build-prototypelisted

入力は案件プランと PoC コード。不足値だけを一度に尋ねる。 ## 手順 1. プランファイルの `## 申し送り (PoC → プロトタイプ)` を読む。受け取る項目は 採用方式 / 確定した事実と棄却した候補 / 操作性の知見と棄却した配置・導線 / やらなかったこと / PoC コードの所在 / 実装対象リポジトリ。節が無ければ同じ項目を 自分で整理してから始める。探索順はプランの他節 (星取表・検証メモ・保留欄) → PoC 成果物 → 会話。整理結果は別見出しでプランに残す 2. PRD の正本が gdocs なら、/build-poc の凍結スナップショット手順でこの時点の版を 取り直す (本実装設計はこの版が凍結基準になる)。取得不能でも停止せず、参照できた版・実体の有無、代替証拠、未検証範囲、DD 前の解消条件を申し送りに残す。PoC 開始時の版が実在するときだけ、それを凍結基準にする。申し送りの `DD正本` は最新の取得成功スナップショットの絶対パス、次に実在するPoC開始時版、どちらも無ければ `未取得` とする 3. 実装対象パスと Git root を確定してから repo コマンドを実行する。類似機能の配置・命名・レイヤ構造・テストの 書き方を実ファイルで確認し、従う対象を宣言する (会話で述べ、手順 7 の申し送りにも残す) 4. 手順 1 の項目を設計に反映する。棄却された候補・配置・導線を再採用しない。やら���かったことは設計に含めるか後続へ送る 5. 開発基準ブランチから新ブランチを切り、PoC の知見を使って慣習準拠で実装し直す (機構は書き直す。PoC で確定した振る舞いは保つ)。確定した振る舞いを固定するテストを repo のテスト慣習に合わせて追加する。設計の分岐点が出たら /review-design を使う 6. テスト・lint (repo が使っているもの。無ければ代替手段と理由を申し送りに 1 行残す) を 通し、変更をコミットしてから /create-pr で draft PR を作る。PR が作れないときはブランチ名と commit hash を申し送りの参照先にする 7. プランファイル末尾に `## 申し送り (プロトタイプ → DD)` 節を追記する (見出し完全一致)。内容 — プロトタイプ PR・ブランチ / 従った既存慣習と配置 / 設計判断と根拠 (採らなかった案も) / PoC から変えた点 / スコープ外にしたことと残ったリスク / `DD正本: <絶対パス / 未取得>` / `DD前の解消条件: <条件 / なし>`