makepad-2.0-design-judgment

Makepad 2.0 デザイン判断スキル

役割： Makepad 2.0 の開発における、初級者向けの振り分けとデザイン判断の指針です。 他のスキルとの関係： このスキルは解放レイヤー（释放层）です。 他の 13 個の Makepad 2.0 スキルは準拠レイヤー（服从层）であり、DSL の構文、API のパターン、ウィジェットの一覧を提供します。これらに異議を唱えず、従ってください。 このスキルは、唯一の正解がないデザイン判断のための概念的な指針を提供します。

このスキルの仕組み

このスキルは品質弁（质量阀门）として機能し、次の 2 つの役割を同時に果たします。

• 制約（约束）：構文／API に関する質問を、適切な準拠レイヤーのスキルに振り分けます
• 解放（释放）：デザイン判断に関する質問に、適切な概念的な指針を適用します

重要な原則： 概念的な指針は、創発のための境界条件を定めます。 モデルに何を出力するかを指示するのではなく、良い出力が生まれる空間を形作ります。ルールは「X をしてはいけない」と伝えます。指針は「Y のように考える」と伝えます。

---

ステップ 1：準拠レイヤーに振り分ける

Makepad に関する質問では、まず一緒に読み込む準拠スキルを特定してください。

質問の領域	一緒に読み込むスキル
アプリのセットアップ、Cargo.toml、ホットリロード、app_main!	makepad-2.0-app-structure
DSL 構文、script_mod!、プロパティシステム	makepad-2.0-dsl
幅、高さ、Flow、Fill、Fit、間隔	makepad-2.0-layout
ウィジェット一覧、View、Button、Label、PortalList	makepad-2.0-widgets
イベント、アクション、on_click、handle_event	makepad-2.0-events
Animator、ホバー、押下、状態遷移	makepad-2.0-animation
draw_bg、Sdf2d、pixel fn、GPU シェーダー	makepad-2.0-shaders
Splash のスクリプト、script_mod!、ホットリロード	makepad-2.0-splash
テーマカラー、フォント、ダーク／ライトモード	makepad-2.0-theme
ベクターグラフィックス、SVG、グラデーション、tween	makepad-2.0-vector
パフォーマンス、GC、描画のバッチ処理、プロファイリング	makepad-2.0-performance
エラー、バグ、ウィジェットが表示されない、FAQ	makepad-2.0-troubleshooting
1.x から 2.0 への移行	makepad-2.0-migration

必ず少なくとも 1 つの準拠スキルを一緒に読み込んでください。 このスキルだけでは不十分です。構文ではなく、判断の指針を提供します。

---

ステップ 2：デザイン判断の指針を適用する

質問が、単にどの構文を使うかではなく、どのように整理、構成、設計するかに関わる場合は、以下の概念的な指針を適用してください。各指針は、モデル内の補助的な認識領域を活性化します。判断を要するタスクでは、統合を自然に進め、思考の連鎖を無理に引き出さないでください。

指針 1：データフロー — Elm アーキテクチャ（Evan Czaplicki）

• 状態は一元管理します。UI は状態の投影です。イベントが更新を引き起こします。
• Makepad の MatchEvent::handle_actions は、Elm の update 関数に相当します。
• 判断の目安： 互いを意識する必要のある複数のコンポーネントに状態が分散している場合は、作業を止めてください。状態を共通の祖先に移してください。
• ポップアップに関する補足： ローカルウィジェットの境界を越えて表示する必要があるメニュー、ツールチップ、言語選択メニューは、共通の祖先またはオーバーレイの所有者が持つようにしてください。トリガーとなるウィジェット内の通常の子要素として埋め込まないでください。
• 従うべき外部仕様： Makepad のイベントシステムが基準です。 Cx::post_action と SignalToUI が、非同期処理から UI への標準的な橋渡しです。 独自の代替手段を考案しないでください。

指針 2：コンポーネントの分割 — Dan Abramov（表示コンポーネントとコンテナーコンポーネント）

• 表示コンポーネント： ライブプロパティのみを受け取ります。状態は持たず、副作用もありません。 Makepad では、#[live] フィールドと #[deref] view: View の委譲を持つウィジェットです。
• コンテナーコンポーネント： 状態を持ち、イベントを処理し、子要素を調整します。 Makepad では、ビジネス状態を保持する #[rust] フィールドを持つウィジェットです。
• 判断の目安： ウィジェットが複雑な UI の描画とビジネスロジックの管理を両方担っている場合は、分割してください。#[deref] による委譲パターンは、まさにそのためにあります。

アンカー 3：レンダリングのメンタルモデル — Casey Muratori（Handmade Hero）

• これは DOM ではありません。GPU サーフェスを毎フレーム再描画します。
• 「ノードを変更する」と考えないでください。「次のフレームで何を描画するか」と考えてください。
• redraw(cx) は「ノードをダーティとしてマークする」のではなく、GPU にこの領域を再描画するよう指示します。
• 判断のヒューリスティック： React／DOM のメンタルモデルから来たパターン（仮想差分、調整、コンポーネントのライフサイクル）を使おうとしているなら、立ち止まって考え直してください。常に問うべきなのは、「次のフレームはどのように見えるか」です。

アンカー 4：レイアウト — CSS Flexbox（ただし、よりシンプルで自己完結型）

• Flow.Down ＝ flex-direction: column。Flow.Right ＝ flex-direction: row。
• align、spacing、padding、margin の意味は CSS と同じです。
• 重要な違い： Makepad にはカスケードもスタイルの継承もありません。各コンポーネントのスタイルは自己完結型です。これは制約ではなく、強みです。
• 判断のヒューリスティック： カスケードで適用される「グローバルスタイルシステム」を構築しようとしているなら、フレームワークに逆らっています。代わりにテーマ（mod.themes）を使ってください。

アンカー 5：シェーダーとアニメーション — Shadertoy コミュニティ（「すべては数学」）

• draw_bg／draw_text は CSS プロパティではなく、実際の GPU シェーダーです。
• Sdf2d は符号付き距離場です。ビットマップではなく、数学で形状を表現します。
• アニメーションは、CSS トランジションではなく、時間の経過とともに変化するシェーダーのユニフォームです。
• 判断のヒューリスティック：「角丸ボタンを作るには？」→ 答えは SDF 関数であり、border-radius ではありません。「不透明度をアニメーションさせるには？」→ 答えはシェーダー内で 0.0 から 1.0 の間を補間するユニフォームであり、CSS アニメーションではありません。

アンカー 6：クロスプラットフォーム — Flutter（「すべてのピクセルを自分で制御する」）

• Makepad はすべてを自ら描画します。プラットフォームネイティブのコントロールはありません。
• 利点：ピクセル単位で正確な、クロスプラットフォームの一貫性。
• 代償：アクセシビリティは既知の弱点です。
• 判断のヒューリスティック： ネイティブコントロールの外観を模倣しようとしないでください。Makepad 独自のデザイン言語を受け入れてください。アクセシビリティが必須要件なら、このギャップが存在しないふりをせず、率直に認めてください。

---

ステップ 3：コンプライアンスと解放のワークフロー

1. READ the user's question
2. ROUTE to compliance skill(s) — confirm DSL syntax and API patterns
3. APPLY judgment anchors — for architecture and design decisions
4. WHEN WRITING CODE: obey compliance skills for syntax, use anchors for structure
5. WHEN ANCHORS CONFLICT WITH API: compliance wins — the API is external reality

コンプライアンス層は、ポランニーのいう「外部実在」（外部实在）です。 ユーザーの好みではなく、コンプライアンス層に従ってください。ユーザーが Makepad の実際の API の動作と矛盾することを求めてきたら、その旨を伝えてください。迎合してはいけません。

---

迎合防止プロトコル

Makepad の設計に関する質問に答えるときは、次の点を守ってください。

• 問題を指摘する前に「素晴らしいアプローチですね！」と書かないでください。
• 「Makepad では動作しません」を「いくつか課題があるかもしれません」とぼかさないでください。
• 外部の現実に基づいて説明してください：「Makepad のイベントシステムでは X が必要なので、Y というアプローチは機能しません。API に照らして確認済みの、代わりに機能する方法はこちらです。」
• 不足点は率直に認めてください：「Makepad 2.0 には、これを実現する組み込みソリューションがありません。回避策と、それぞれのトレードオフを紹介します。」

---

品質チェック：予測できない深さ

回答を生成した後、次の点を自分で確認してください。

「ユーザーは質問だけから、この出力を正確に予測できたでしょうか？」

• はい → 制約をかけすぎています。単なる検索・置換ツールになっています。アンカーによって副次的な気づきを引き出し、ユーザーが明示的には求めていない設計上の判断を導き出すべきです。
• いいえ。ただし、ユーザーはそれが良いかどうか判断できる → バランスが適切です。適切に定められた境界条件の中で、新たな発想が生まれています。

---

参考：スキルエコシステム

このスキルは、14 個のスキルからなるスタックの最上位に位置します。

┌─────────────────────────────────────────┐
│  makepad-2.0-design-judgment (this)     │  ← Liberation layer: WHY & HOW to design
├─────────────────────────────────────────┤
│  makepad-2.0-app-structure              │
│  makepad-2.0-dsl                        │
│  makepad-2.0-layout                     │
│  makepad-2.0-widgets                    │
│  makepad-2.0-events                     │  ← Compliance layer: WHAT syntax to use
│  makepad-2.0-animation                  │
│  makepad-2.0-shaders                    │
│  makepad-2.0-splash                     │
│  makepad-2.0-theme                      │
│  makepad-2.0-vector                     │
│  makepad-2.0-performance                │
│  makepad-2.0-troubleshooting            │
│  makepad-2.0-migration                  │
└─────────────────────────────────────────┘

迷ったときは、コンプライアンススキルは「API は何をするか？」に答えます。このスキルは「それを使って何を作るべきか？」に答えます。