prototype-ui

仕様書からのUIプロトタイプ

このスキルは、仕様書プロジェクト（スキル specs-ui）をもとに、クリック可能なプロトタイプを作成します。画面とアイデンティティはそのままに、主要なユーザーフローが動作します。画面を移動し、フォームに入力すると、リストが変化し、状態が順に遷移します。すべてブラウザー内でシミュレーションされます。ユーザーテスト（ガイド付きシナリオ、管理された初期データ、観察）やデモに利用できます。これはアプリケーションではなく、仕様書が引き続き正式な基準です。

インターフェースのテキスト、シナリオ、やり取りはフランス語です。コード（スクリプト、属性、変数、アクション、識別子）は英語です。コメントはフランス語でもかまいません。

<skill> はこのスキルのディレクトリを指します。スクリプトは、specs/（仕様書用の specs/ui とプロトタイプ用の specs/prototype）を含むプロジェクトのルートディレクトリから、node <skill>/scripts/… で実行します。旧レイアウトのプロジェクト（ルートディレクトリに specs-ui/ と prototype-ui/ がある場合）は、まずスキル specs-ui の migrate-layout.mjs を使って整理します。

トークンを節約する（最初に読む）

プロトタイプのページは35～70 Ko（10,000～20,000トークン）、shells.html は150 Koを超えます。「ざっと見る」ためにファイル全体を読むのが、最も大きな無駄の原因です。次のルールに従ってください。

1. specs/prototype/PROTOTYPE.md がメモリです：作業を再開するときは最初に読み、できる限りこれだけで済ませてください。各ステップの最後に更新し、150行未満に保ちます。specs/ui/CONTEXTE.md を読むのは、要件を整理するステップ1だけです。その後は、data.js に進行中のストーリーの事実が記録されています。
2. 読む前に要約する：outline.mjs specs/prototype e3 e4 は、各ページの状態を行番号付きで要約します（HTMLの約12分の1の長さです）。outline.mjs specs/prototype --shells は、シェルについて同様に要約します。その後、必要な行だけ（offset / limit）を読んでください。site/ は絶対に読まず、shells.html も全体を読まないでください。
3. 配線メモを specs/prototype/fiches/eN.md に保存します（テンプレートは templates/fiche.md）。メモは一度作成し、その後はイテレーションのたびに更新します。ライターには長いメッセージではなく、メモのパスを伝えてください。
4. ライターは簡潔に：alpine.md 全体ではなく、短い指示書である references/redacteur.md を読みます。担当ページは分割して読み、再読せずに対象を絞って変更し、最後に一度だけ build と check を実行します。テスト用スクリプトは作成せず、スクリーンショットも読みません。
5. 見る前に確認する：まず check.mjs のテキストを確認し、次にシナリオの一覧（--scenarios、各ステップにつき画像1枚）を確認します。ページ一覧は疑問がある場合に限り確認します。まずデスクトップ版を確認し、モバイル対応が完了している画面だけモバイル版の一覧を確認してください。
6. 選択したフローだけを配線します。 配線されていないページにコストはかかりません。モックを表示し、?state= で各状態を確認できます。
7. 変更されたものだけを公開します：基盤（proto.js）とデータ（data.js）はページとは別なので、パネルまたはデータの修正時に送信するのはファイル1つだけです。修正はまとめてから公開してください。

役割	モデル	タスク
設計	メインモデル	要件整理、データモデル、プリセット、actions.js、共通部分の配線（shells.html、nav）、メモ、シナリオ、一覧のレビュー、PROTOTYPE.md、公開
ライティング	sonnet	メモをもとに、フロー内のページを配線する
機械的な実行	haiku	スクリプトを実行して結果を報告する。指摘されたリンクまたはアイコンを修正する

ページの配線には、モックを理解し、壊さずに動作するようにする必要があります。これはライティングの作業です（Sonnet）。2人のライターが同じページを編集することはありません。また、data.js、actions.js、prototype.json、shells.html を変更するのはメインモデルだけです。

タスク	読むもの
メモの作成、共通部分の配線	PROTOTYPE.md、outline.mjs の出力、references/alpine.md（関連するセクション）
ページの配線（ライター）	担当ページのメモ、references/redacteur.md
シナリオ、テストセッション、デモ	references/scenarios.md

ステップ 0 · 前提条件

最新の specs-ui プロジェクト（sources/site.json、1つ以上のバッチ、CONTEXTE.md）が必要です。ない場合は、まず specs-ui スキルを使って仕様の作成を提案してください。specs/prototype/PROTOTYPE.md が存在する場合は、作業の再開です。メモを読んで、必要なステップに進んでください。

ステップ 1 · 要件整理

specs/ui/CONTEXTE.md（フロー、ペルソナ、進行中のストーリーの事実、一覧）を読みます。仕様から選択肢を用意し、AskUserQuestion で次の点を尋ねてください。

• 配線するフロー。通常は2～4つです。初回利用、主なタスク、重要なエラーケースを含めます。
• 用途：ユーザーテスト、デモ、またはその両方。
• 開始時の状況：初回利用、データが入力済みのアカウント、エラーケース。

未解決の質問は「要確認」として PROTOTYPE.md にも記録してください。会話の中だけに残してはいけません。

ステップ 2 · プロトタイプを準備する

node <skill>/scripts/scaffold.mjs --specs specs/ui --out specs/prototype
(cd specs/prototype && npm install)          # une fois : Tailwind compilé, Alpine et Lucide servis localement
node <skill>/scripts/build.mjs specs/prototype
node <skill>/scripts/drift.mjs specs/prototype --mark   # point de départ du suivi des specs

スキャフォールドで次のファイルが作成されます。

• src/pages/eN.html：デスクトップとモバイルの各画面状態を、仕様書のシェルなしで記述します。各状態は ?state=<id> で表示され、ページが接続されていない間はルートに data-proto-static が付与されます。
• src/shells.html：仕様書の共通シェルと共有ブロックです。
• src/data.js、src/actions.js、src/prototype.json（提案された nav テーブルを含みます。references/alpine.md §10 を確認してください）、PROTOTYPE.md、package.json。

npm install を実行しない場合、ビルドでは CDN（ブラウザー用 Tailwind）にフォールバックするため、画面ごとにわずかな遅延が発生します。後からスキャフォールドを再実行しても、接続済みのページや shells.html は変更されません。それらの仕様書版は src/_from-specs/ に保存されます。

ステップ 3 · データとアクション

メインモデルが、接続作業を始める前にこれらを記述します。これが各ページで共有する契約です。

• src/data.js → window.PROTO_DATA：ユーザー経路の業務オブジェクトを、一貫したシナリオの正確な値と安定した識別子（s-1042）とともに記述します。対象は、ユーザー経路で表示または変更されるものだけです。
• window.PROTO_PRESETS：シナリオの開始時の状況と、各ステップで保証される状態です（上書きせずに補完します）。
• src/actions.js → window.PROTO_ACTIONS：各操作に対するアクションを記述します（this.data、this.notify()、this.later(ms, fn)）。自動的に保存され、ページから遷移する必要がある場合は作成されたオブジェクトを返します。

これらを PROTOTYPE.md に記録します。

ステップ 4 · 接続する

1. 共有部分はメインモデルが担当します：nav を確認してから、データに応じて変化する部分（サイドバー、ヘッダー）を shells.html で接続します。対象となるテンプレートの行だけを読み取ります（outline.mjs --shells）。
2. ページごとに仕様書を作成します：outline.mjs で fiches/eN.md を準備し、状態と条件、データ、操作、パラメーター、静的な部分、使用可能なテキストを記載します。
3. ライター（sonnet、互いに重複しないページを担当）には、担当する仕様書、references/redacteur.md、PROTOTYPE.md を渡します。

ルール：

• モックアップを維持し、動作のみを追加します。
• デスクトップとモバイルの両方を接続します。
• 仕様書にないものは追加しません。ただし、ユーザー経路上避けられない派生状態は除きます。派生状態は隣接するモックアップと組み合わせ、alpine.md §2 に従って PROTOTYPE.md に記録します。
• プロトタイプ内で作成されたオブジェクトには fresh を付けます。

作業の完了後、報告内容を反映します。要求されたアクション、新しいテキスト、差異は PROTOTYPE.md と各仕様書に記録します。

ステップ 5 · シナリオ

prototype.json → scenarios には、id、title、persona、goal、start、preset と、典型的なシナリオを順にたどる steps を記述します。各ステップは { "text", "page", "preset" } の形式です。「次へ」と「前へ」を押すと、そのステップの画面が対応するデータとともに開きます。形式、パネル、観察事項、テストセッション、デモについては references/scenarios.md を参照してください。

ステップ 6 · ビルド、確認、レビュー

node <skill>/scripts/build.mjs specs/prototype
node <skill>/scripts/check.mjs specs/prototype --scenarios   # --sheet pour les planches de pages

check.mjs は、次の問題を報告します。

• リンクの欠落、存在しないプリセットやステップ
• 仕様書のシェルの残り
• JS または Alpine のエラー、未知のアイコン、組み立てられていないブロック
• デスクトップおよびモバイルでの横方向のはみ出し

各シナリオの各ステップは、その画面上で再構成された状態とともに確認されます（?scenario=<id>&scenario-step=<n>）。--pages e2,e13 で確認対象を絞り込めます（ステップのみ確認する場合は --pages scenarios）。シナリオの画面一覧を確認し、適切な画面と状態になっているか、ストーリーがつながっているかをチェックします。

ステップ 7 · 公開する

node <skill>/scripts/prepare-publish.mjs specs/prototype <scratchpad>/prototype-publish

Artifact ツールを使って公開します。

• file_path：メインページ
• files：指定されたリスト。変更されたファイルに限定します（新しい Artifact の場合、つまり初回公開または別のアカウントの Artifact の場合は --all）。
• url：更新の場合は Artifact の URL

次に prepare-publish.mjs specs/prototype --confirm を実行し、URL を PROTOTYPE.md と prototype.json → artifact に記録します。訪問者ごとに個別のデータがあり、それぞれのブラウザーに保存されます。prepare-publish.mjs specs/prototype --check を実行すると、準備を行わずに Artifact がローカルサイトより古いかどうかを確認できます。

git リポジトリでは、src/、fiches/、PROTOTYPE.md、ビルド済みサイト、site/.published.json、src/specs-sync.json をコミットします。node_modules/、.check/、.build-tmp/ はリポジトリに含めません。

specs を追跡する

drift.mjs specs/prototype を実行すると、前回の反映以降に specs で変更された画面（src/specs-sync.json 内のフィンガープリント）と、共通のアイデンティティや誤字がわかります。配線後に specs が変更された場合は scaffold.mjs を再実行し、specs のバージョンを src/_from-specs/ に配置します。両方のページを読んで比較するのではなく、outline.mjs specs/prototype eN --specs で比較し、変更を配線済みのページとそのフィッシュに反映した後、src/_from-specs/ を削除して drift.mjs specs/prototype --mark eN を実行します。--pages e7,e8 --force を使うと、まだ配線されていないページのみを再生成できます（その後、該当画面に対して --mark を実行します）。

開発中のメンテナンス

アプリケーションの構築中も、プロトタイプはユーザーテストとデモのためのツールとしての役割を維持します。コードではなく、specs に追従します。

• 配線済みページ：対象ページに関わる specs の変更があるたびに（drift.mjs）、上記の手順で変更を反映します。可能であれば、specs の変更と同じ変更に含めます。
• 未配線ページ：再生成して（scaffold.mjs --pages eN --force）、その後 --mark を実行します。
• 古くなったフロー：リリース済みのアプリケーションでフローがカバーされたら（specs のステータスが「リリース済み」）、ユーザーテストはアプリケーションで行います。引き続きメンテナンスするのではなく、フローを「凍結」として PROTOTYPE.md に記録します。
• 変更したファイルを再ビルド、確認、再公開し、specs と一緒にコミットします。