open-design-game-ui-handoff

Open Design ゲーム UI の引き継ぎ

変更を依頼する前に、ゲームがすでに実現している内容をパッケージにまとめます。スタンドアロン版で実行時の情報が省略されていても、未指定として扱い、簡略化してよいという許可だと解釈してはなりません。

証拠を収集する前に、docs/hard-rules/ui-adaptation-upgrade-only-contract.md と preservation-contract.md をお読みください。

パッケージ内容の基準 = claude-design-handoff-generate（オーナーのベンチマーク）

実績のある claude-design-handoff-generate スキルは、すべての Open Design 引き継ぎにおける内容の基準です。Open Design には、Claude Design セッションに渡すものと同じパッケージに、Open Design 向けの差分を追加して渡します。より簡素なブリーフを新たに作らないでください。

VFX／スキル／武器／敵／ボス／RIG パッケージは、まず claude-design-handoff-generate を使ってパッケージを作成してください（または、それを使って作成済みの .handoff/*.zip を再利用してください）。パッケージには、Owner Summary Matrix を含む README、承認済みのメカニクスを記載したブリーフ、ビジュアルの直交性テーブル（デザインで既存のどのアイデンティティにも見えてはならないかを示し、それらの近似デザインの参考スクリーンショットを添付）、タイミング／ビートのシーケンス、実機の #game WebP 証拠状態 5 件以上、reference/ 契約（オーナーの決定事項、ランタイムの抜粋、パフォーマンス予算と注釈テンプレート、レビュー契約、オンボーディングチェックリスト、シナリオ JSON）、密度 0-100 と 100/80/50/30/0% の基準、ファンアウト／テクスチャのテーブル、アイコン要件、レベルアップカードのコピー入力を含めてください。直交性テーブルのないブリーフでは、リリース済みのアイデンティティと衝突するデザインが生まれます（実測例：テーブルを省いた結果、2 つのエンジンがそれぞれ独立して、リリース済みの镇魂瓮のティール色の薬瓶というアイデンティティを再発明しました）。

既存の Claude Design 引き継ぎ zip を Open Design に渡す場合：そのまま解凍し、中身は一切変更せず、Open Design 向けの差分ファイルのみを追加してください。

• DESIGN.md — アイデンティティ、クラフトの基準、目指す美しさを示す、創造性を優先した導入ページ。対象範囲については元の README／ブリーフ を、クラフトの資料については以下のドキュメントを参照させます。
• darkbone-visual-language.md + exemplar-craft.html（open-design-game-ui-concept/references/ から取得）— Open Design のエンジンには、Claude Design 製品に組み込まれているクラフトの足場が必要です。
• 想定される成果物の名前を付けたプレースホルダー成果物ファイル。
• 生成契約（codex / gpt-5.6-sol / ultra / override なし）を記載した source-manifest.json。
• インタラクティブな VFX ラボの場合：スクリプトから操作できるレビュー API（window.DARKBONE_VFX_LAB: playBeat/playCycle/ setDensity/setFloor/setTargets/setSpeed/state。すべてのメソッドが truthy を返すこと）を必須とし、各ビートの受け入れ確認を操作・記録できるようにしてください。

キックオフメッセージでは、次の順序で読むよう指示します：DESIGN.md → クラフト資料 → 元の README／ブリーフ → 参考契約。 UI サーフェスには、以下の保存契約ワークフローも引き続き適用されます。

VFX／スキルのパッケージを作成する正式な手順は、 references/vfx-handoff-recipe.md です。オーナー承認済みの手順であり、実際の巫毒魂瓶の引き継ぎで 2026-07-19 に実証済みです（ブラインド評価 91/100、オーナーが選好）。内容に忠実に従ってください。パッケージ構成、DESIGN.md のカバーテンプレート、起動／キックオフの文面、エンジンのデフォルト設定、操作して行う動画での受け入れ確認、takeover への引き渡しを含みます。

ワークフロー

0. 画面の種類ごとに分岐します。 UI 画面（#home/mapselect/talent/masks/fusion/victory/steam-title/HUD）は、以下の完全な保持契約ワークフロー（手順 1～9）に従います。VFX／スキル／武器／RIG／敵／ボスのパッケージは保持契約を省略し、代わりに上記のコンテンツ標準（claude-design-handoff-generate パッケージ＋Open Design 差分）に従います。検証には Open Design パッケージャーではなく、CD チェッカーを使用します。

   make claude-design-check ARGS="validate-handoff .handoff/<id>.zip --kind=skill_vfx"
   

Open Design パッケージャー（package_open_design_handoff.mjs）は保持契約と UI 契約プロファイルを必須とします。UI の引き継ぎのみを対象とするゲートです。VFX パッケージには、od-source-manifest.json の生成契約と、DESIGN.md の DARKBONE_VFX_LAB API 要件が引き続き含まれます。

1. 対象となる画面と、それぞれの画面でプレイヤーが行うことを明記します。open-design-game-ui-concept/references/darkbone-visual-language.md と exemplar-craft.html を引き継ぎフォルダーにコピーし、DESIGN.md は理想像を最初に示す構成にします：1 ページ目には、アイデンティティ、クラフトの基準（「見本に合わせる」）、この画面で目指す美しさを記載します。保持や権限に関する説明はその後に続けます。制約を先に示すブリーフでは、堅苦しい Web ダッシュボードのような出力になりがちです。

2. 現行のオーナーソースを読みます。アイデンティティ、モーション、インタラクション、コピー、データについて、検索可能なソースアンカーを記録します。

3. 対象となるすべてのビューポートと言語環境で、現在のランタイムをキャプチャします。アップグレードまたは再設計する画面ごとに、少なくとも 2 つの状態を使用します。 まったく新しい画面に限り、steam-title 契約プロファイルの場合のみ、baselinePolicy: new-surface-no-runtime を使用できます。この場合、baselineStills は空のままにし、実際の Home の contextStills を少なくとも 2 つ指定する必要があります。この例外は既存のランタイム画面には適用できません。

4. モーションが重要な動作を、実際のランタイム動画とタイムスタンプ付きキーフレームでキャプチャします。Home、Talent への投資、Fusion の演出、Victory／settlement の演出は、デフォルトでモーションが重要です。

5. preservation-contract.json を作成します。各コンポーネントに 1 つの処理（preserve、upgrade、redesign、untouched）を割り当て、layout、identity、motion、interaction、copy、data の権限を指定します。changeScope を明示的に宣言し、権限が runtime ではない軸と完全に一致させる必要があります。changeScope の範囲外の軸は、スタンドアロンで省略されたり静的に代理表現されたりしても、すべて固定されます。data はランタイム所有のままにする必要があります。また、standaloneMotionPolicy、runtimeMotionImplementation、具体的な runtimeOwnerAnchors も記録します。ランタイム所有のモーションには、placeholder-only-preserve-runtime と reuse-existing-runtime を使用する必要があります。スタンドアロンは配置を示すものであり、動作を置き換えるものではありません。

6. 維持する必要があるシグネチャ、禁止されるリグレッション、変更しない詳細、および対象ビューポート、言語環境、状態、モーション状態、必須の演出を含む、実行可能なレンダリング比較計画を記載します。

7. 参照するすべてのエビデンスを、単一の .handoff/<timestamp>-<feature>/ フォルダー内にまとめます。契約から絶対ローカルパスを参照してはいけません。source-manifest.json には、上書きできない次の生成契約を正確に含める必要があります { "agentId": "codex", "model": "gpt-5.6-sol", "reasoning": "ultra", "allowOverride": false }。

8. Open Design にインポートする前に検証します：

   node .agents/skills/open-design-game-ui-handoff/scripts/validate_preservation_contract.mjs \
     --contract=.handoff/<timestamp>-<feature>/preservation-contract.json
   

9. 親の引き継ぎパッケージャーを実行します。親パッケージャーは同じセマンティックバリデーターを呼び出す必要があります。この手順を経ずに作成された zip は、有効な引き継ぎではありません。

エビデンスのルール

• 再構成した HTML やソースコードの確認だけではなく、実際に動作しているアプリを使用します。
• 開発サーバーでのキャプチャの前提条件（キャプチャのゲートでは、コンソールエラーと画像の読み込み失敗があると処理がブロックされます）： index.html は /sw.js を登録しますが、これはビルド成果物です。vite dev でキャプチャする前に、コミット対象外の何もしないスタブを apps/game-runtime/public/sw.js に配置してください。そうしないと、すべてのシナリオで未対応の MIME タイプに関するコンソールエラーが発生します。/masks/mask-*.webp として参照されるマスク画像は R2 でホストされています。data/artifact-manifest.json の publicUrl エントリをもとに、コミット対象外の apps/game-runtime/public/masks/ に配置してください。配置しないと、Home／Masks／Fusion の画像アサーションが失敗します。
• スクリーンショットとキーフレームは圧縮 WebP で保存します。モーションは WebM または MP4 で保存します。
• 最低限、セットアップ、ピーク／変形、安定後／結果の各ビートをキャプチャします。意味がある場合は、操作と復帰のビートも追加します。
• 再生中のアニメーション名や実行時ソースのアンカーは補足エビデンスとして記録し、動画の代わりにはしません。
• コンポーネントにモーション低減時の分岐がある場合は、モーション低減時の状態も個別にキャプチャします。
• 担当者から明示的にアーカイブを依頼されない限り、成果物はローカルに保管し、Git の追跡対象外にします。

拒否条件

以下のいずれかに該当する場合、引き継ぎを拒否します。

• フォルダーに darkbone-visual-language.md または exemplar-craft.html がない、あるいは DESIGN.md の冒頭がクリエイティブディレクションではなく制約や権限について記述している。
• 再設計するサーフェスに、現在のランタイムを使った静止画が 2 枚未満しかない。
• モーションが重要なサーフェスに動画がない、またはタイムスタンプ付きキーフレームが 3 枚未満しかない。
• コンポーネントに Open Design の権限を暗黙的に付与している。
• changeScope がない、割り当てられた権限より範囲が広い、または狭い。
• レイアウトのみを扱うタスクに、Open Design のアイデンティティ、モーション、インタラクション、コピー、データに関する権限が付与されている。
• ランタイムが所有するモーションが、既存のランタイム実装に裏付けられたプレースホルダー専用の単独表現として明示されていない。
• Home、Talent、Fusion、Victory のいずれかで、既知の保護対象ランタイムコンポーネントが契約から漏れている。
• ソースアンカー、エビデンスファイル、必ず保持するシグネチャ、または禁止されているリグレッションが欠けている。
• 単独では描画できないことを理由に、既存の動的コンポーネントを破棄可能なものとしてブリーフに記載している。
• 比較計画で、ビューポート／状態／ビートごとに、現在、単独、将来の統合後の各レンダーを揃えられない。

成果物は、検証済みの保持契約と自己完結した引き継ぎ資料です。ランタイムコードではありません。