design-studio

デザインスタジオ

役割の境界

役割	ソース	以前のスコア	担当範囲
プランナー	あり	なし	スコープと成功基準
ビジュアルディレクター	なし	なし	ビジュアルの方向性と選定されたビジュアルコントラクト
ビルダー	あり	なし	実装の忠実度
評価者	なし	なし	レンダリング結果の観察とスコア
オーケストレーター	必要に応じて	あり	SELECT / REFINE / PIVOT / SHIP / ESCALATE / HALT

• ビジュアルディレクターには、HTML、CSS、JSX、セレクター、実装の差分、ドキュメントのソース／レンダラーのメタデータ、または無人割り当てインデックスを決して渡しません。
• 評価者には、ソース、実装にかかった労力、デザインの全説明、または以前のスコアを決して渡しません。ドキュメント評価では、レンダラーの識別情報／ビルドメタデータも除外します。
• ビルダーは選定された方向性を実装します。より安全な方向性に黙って置き換えてはなりません。
• 唯一の意思決定者はオーケストレーターです。評価者／レビュー担当者は根拠を提示しますが、ワークフロー上の決定は行いません。

読み込みとルーティング

Studio、Review、Document のリクエストの場合：

1. invocation.md、design-intent-contract.json、references/design-intent.md、runtime-contract.md、references/context.md、references/runtime-integrity.md を読み込みます。これらは、レーン別の手順ではなく、あらゆるレーンに適用される入力、権限、ソース／エビデンス、復旧、縮退、受け入れに関するガードです。
2. ホスト入力と現在の権限エビデンスを1つの Design Intent に対応付け、workflow.yaml、Review／Document の手順、または専門家向けリーフを読み込む前に検証します。分類が無効な場合は、レーンの読み込みも実行もブロックされます。
3. 検証済みの結果を既存の task、surface、interaction、evidence シグナルに対応付けてから、method-router.json を読み込みます。タスクシグナルは選択されたレーンと現在のステージの範囲内に保ちます。補助的なコピーまたはエビデンスのシグナルによって、そのレーンが変わることはありません。
4. 専門家向けのルートに一致しない場合も、正規の selectedProcedures を解決します。ルート上に設定された各シグナルの次元は、すべて必須です。読み込み前に、一致したすべてのルートの procedure が Design Intent と一致することを確認します。シグナルが競合する場合は、修正されるまでブロックします。その後、選択された手順と、一致する leaves の和集合を読み込み、パスの重複を除きます。
5. 必要なコンテキストを読み込んでから、選択された手順を実行します。手順は必要に応じて、ステージ固有の役割指示と参照を提示します。デフォルトで専門家向けカタログ全体を読み込んではなりません。

method-router.json はルーティングデータであり、手法の権威ではありません。その coreAuthorities は、すべてのレーンで共有される共通セットです。リポジトリの ADR／権限マップのパスは、出所を示すメタデータにすぎません。インストール済み環境での実行は、リポジトリのドキュメントに依存しません。ホストアダプターは、この読み込みコントラクトに従い、別の読み込みグラフを使用しません。

必須の参照資料

• invocation.md
• design-intent-contract.json
• references/design-intent.md
• runtime-contract.md
• method-router.json
• references/context.md
• references/runtime-integrity.md
• 条件付きの Studio 手順：workflow.yaml
• 条件付きの Review 手順：references/review/polish.md
• 条件付きの Document 手順：references/document/document.md
• 条件付きの承認済みシステム境界：references/design-authority/lifecycle.md

最初の7項目とこのインデックスを合わせたものが、あらゆるレーンに共通するホットパスです。レーンの手順と手法は条件付きです。パスを記載しても、それらが読み込まれるわけではありません。

レーン

レーン／アクション	トリガー	分岐の決定権
Studio	インタラクティブな画面を作成、拡張、または全面刷新する	選択した workflow.yaml。ステージに対応する direction／extend／build／overhaul のリーフ
Review	インタラクティブなビジュアル世界を保ちながら監査／磨き上げる	選択した references/review/polish.md。対応する読み取り専用のレビュー観点
Document	見積書、請求書、SOW、提案書、レポート、ブリーフ、印刷物／PDF、またはその他のページ分割された成果物	選択した references/document/document.md。階層／具体性と、ページ評価の観点
Design system	承認済みのシステムを体系化する	承認済みレーンの体系化に関する決定権
Meta	Design Studio を改善する	振り分け先の references/meta.md

Design Intent が Studio／Review／Document の振り分けを担います。Meta の保守では既存の meta／method-intake のルートを直接使用します。体系化では新しいインテントではなく、承認済みレーンの結果を使用します。インタラクティブなレポートは、PDF にエクスポートできる場合でも Studio／Review の対象です。範囲の狭いコンポーネント／CSS の修正に Studio は必要ありません。

Studio

検証済みの Studio インテントでは、workflow.yaml を最初から最後まで実行します。計画、事前確定された無人割り当て、ソースを参照しない方向性の決定、ソースを考慮したビルド、機械的なエビデンス、ブラインド評価、変更不可の反復、体系化の前の最終ツリー承認を担います。専門家向けのリーフは有効化時にすべて読み込むのではなく、現在のステージに応じて読み込みます。extend では、振り分け先の references/extend.md を使用します。承認済みの決定権を引き継ぎ、ローカルな追加部分のみを検討します。ローカルでの完了によって決定権を維持し、再利用可能な差分は references/design-authority/lifecycle.md を通じて、別途承認されるシステム体系化に移します。Create と overhaul では、方向性を分岐させて検討します。

Document

検証済みの Document インテントでは、Studio のワークフローを読み込まずに references/document/document.md を実行します。物理的なページシステムの方向性、レンダリング済みページ全体の順序に沿った評価、ページネーション／表／ページ装飾／印刷の観点、および承認済みの document-visual-contract.json の公開を担います。これらの観点を読み込むのはページ評価時であり、インタラクティブなリクエストではありません。

Design Studio は、ビジュアルなページシステムのインテントとレンダリング済みページの評価を担います。トランスクリプトの解釈、ビジネス上の文体、会計上の正確性、拘束力のある商業／法律上の条件、レンダラー／ジェネレーターは担いません。

Review

Review では Studio の作成ループを実行せず、そのワークフローも読み込みません。選択した references/review/polish.md を実行し、対応する観点のみを追加します。レビュアーはまずエビデンスを報告し、実装には範囲を限定した修正計画を1つ渡します。レンダリング済みのエビデンスがない場合、判定は問題なしではなく unverified です。

エビデンスと機能低下

• roots.json／capabilities.json は運用上の事実、events.jsonl は追記専用の復旧用記録です。
• PRODUCT.md には確認済みの製品情報、COPY.md には永続的な文言ルール、DESIGN.md には実証済みの承認済みビジュアル権限のみを保存します。
• 機械的なスナップショットは、現在の状態を網羅するエビデンスです。エビデンスがない場合は明示し、合格扱いにはしません。
• 権限を証明するのは承認であり、ディレクトリの存在や高いスコアではありません。

すべての作成レーンでファイル I/O、シェル、隔離されたロールが必要です。インタラクティブなビジュアルに関する判断では、さらに実行可能なターゲット／ブラウザーが必要です。Document に関する判断では、既存の成果物またはホスト提供のレンダラーから、レンダリング済みページ全体のエビデンスを得る必要があります。

• Studio でブラウザーがない場合：ビルドと機械的なエビデンスの取得を1回行い、その後、勝者を決定せずに停止します。
• Review でインタラクティブなビューポートがない場合：部分的なエビデンスのみとし、ビジュアルのステータスは未検証とします。
• Document でページ全体のエビデンスがない場合：ソースから品質を推測せず、Document の失敗時の契約に従います。
• ユーザーの回答を得る仕組みがない場合：事前確定された決定的な割り当てを使用します。
• 画像を生成できない場合：同等の仕様を持つテキストの方向性を使用します。
• 失敗または欠落した操作はすべて、正確な理由とともに記録します。

メソッドの所有権

Design Studio には、上流のデザイン手法ランタイムへの依存関係はありません。採用した外部のアイデアは、出典を明記したローカルメソッドとしてルーティングします。観察や却下の記録は、研究上の根拠にのみ使用します。他のコマンド分類体系、プロンプトライブラリ、フォールバックランタイムはインポートしないでください。

Growth Arsenal はこのメソッドカーネルの外部にとどまり、合成境界を通じて、承認済みの役割別オファー／コピー成果物を提供できます。新しいメソッドでは、再利用可能なギャップを明示し、権限に適合するか、その根拠を示し、関連する場合は外部ソースとライセンスを固定し、整合性のある最小限の部分を適応させ、評価／契約／実地利用の結果によって効果を実証する必要があります。