makeui

makeui

apps/ui で Make App のフロントエンド UI を作成する際に、このスキルを使用します。デフォルトのスタックは React + Vite + React Router ですが、makeui が担当するのは UI の構造とプレゼンテーションに関する判断のみです。

makeui は、アプリシェルのレイアウト、ナビゲーションのレイアウト、一覧ページのレイアウト、ツールバーの配置、現在のユーザー向け UI、コンポーネントライブラリの使用、フィールドコントロールの表示、新規作成／編集／詳細のレイアウト、ユーザー／部門セレクターの UI 動作、レスポンシブな View の構成、視覚状態、UI の仕上げを担当します。共有モバイル表示プリミティブには @qfei-design/make-app-mobile を使用し、ビジネスコントローラーはホスト側に残します。認証／ログイン、フロントエンドのビルドまたは公開ルール、Service のランタイム構造、ビジネス API／データの契約、権限ロジック、永続化、ビジネスモデリング、ドメインマッピング、canvas-table の内部実装、高度なフィルターパッケージの内部実装は担当しません。生成された Make App では、このスキルと make-app-permission を併用してください。権限ゲートを任意の UI 仕上げとして扱わないでください。

クイックスタート

要件と実装方針を確認した後、Make App を新規作成または更新する際は、まず make-app-approval に従って、「我的审批」入口を生成するか再利用するかを判断してください。承認の新規作成フィールド、保存後の初回申請、プロセス状態フィールド、詳細タイトルの Tag は、このスキルが主に担当します。以下の createFields の新規作成ルールは、通常の有効な承認設定がない場合にのみ適用されます。既存レコードの通常編集では、従来の IAM 経路を維持してください。プロセスが紐付いていないためにナビゲーションが漏れることのないようにし、ナビゲーションがあるからといって、すべてのフォームのフィールド権限を切り替えないでください。

1. 既存の UI スタック、ルート、シェル、コンポーネントライブラリ、スタイルシステム、ページレイアウトの規約を確認します。既定のライブラリが定まっておらず、ユーザーからの指定もない新規プロジェクトでは、references/component-usage.md にある3つの選択肢から選べる UI を使用します。互換性のある React ライブラリを独自に選択できるようにし、ユーザーが選択しない場合に限り Ant Design をデフォルトにします。
2. ホストプロジェクトのデータと認証の動作を維持します。このスキルでは、ログイン、トークン、業務 API ルート、Service のオーケストレーション、デプロイ、ビルド出力を設計しないでください。
3. UI の描画には、ホストが提供するオブジェクト／フィールドのメタデータを使用します。業務フィールドや API 契約を独自に作成しないでください。
4. モバイル対応は、すべての新規 Make App におけるデフォルトの納品要件であり、任意の拡張機能ではありません。凍結済みの製品契約である references/mobile-product-baseline.md を読み、続けて references/mobile-defaults.md、references/mobile-visual-standard.md、references/mobile-form-controls.md を読みます。ユーザーがモバイル対応を明示的に無効にするか、独自のモバイルデザインを求めない限り、@qfei-design/make-app-mobile を使用します。スマートフォンでは、File を除く作成／編集／詳細フィールドは、左にラベル、右に右揃えの値を置く同一行のレイアウトにします。TextArea は2行から開始して伸長し、複数値は右側の領域内で折り返します。Number／Currency／Percent は、共通の精度検証を維持したまま、ステッパーのないプレーンな制御対象テキスト入力を使用します。File のみ全幅の縦積みレイアウトを使用できます。ID フィールドと添付ファイルフィールドには、ホスト独自の見た目を模倣した実装ではなく、パッケージの /fields コンポーネントを使用します。詳細タブは詳細コンテンツと同じ水平ガターを共有します。デスクトップのグリッドを縮小してスマートフォンのフィールドレイアウトを導出しないでください。作成／編集時の保存には、右揃えでアイコンのないフォームフッターを使用し、デスクトップ／タブレットの動作は維持します。既存の App でも、モバイルまたはレスポンシブ動作が対象範囲に含まれる場合は、これらのリファレンスを読みます。デスクトップ／モバイルの View の上には、共通の業務 Controller を1つだけ配置します。
5. デフォルトでは、オブジェクト管理向けの高密度なデスクトップレイアウトを使用します。左ナビゲーション、フラットなワークスペースヘッダー、テーブルの直上に配置したローカルツールバーを使い、リストタイトル用のカードは追加しません。サイドバーの色はプロジェクトのテーマに合わせます。スマートフォンでは、mobile-defaults.md のパッケージ連携モバイルシェルとタスクページのデフォルトを使用します。現在表示されている業務オブジェクトから下部タブを導出し、その数が5つ以上の場合にのみワークベンチタブを表示します。数が5つ未満の場合も、その直接ルートは引き続き利用可能にします。
6. オブジェクトルートは、ローディング、空状態、エラー、アクセス拒否、セッション期限切れ、ページ未検出、再試行、レンダーエラーのフォールバックなど、ユーザーに見える UI 状態でラップします。make-app-observability が共通のリクエストエラーカードを提供する場合は、権限、Schema、ルートの成否に依存せず、グローバルエラーアウトレットを永続的なアプリルートにマウントしたままにします。0.1.8+ のビューポートがデスクトップとスマートフォンのポータル位置を管理します。Shell がマウント済みの場合、ホストが所有する再試行ボタンはメインコンテンツ領域の中央に配置します。Shell のマウント前は、永続的なアプリルートのフォールバック内で中央に配置し、プロジェクト既存のボタンコンポーネントを使用します。マウント、オーバーレイ、再試行ボタンの配置に関する契約については、references/app-shell-layout.md を読みます。
7. 表示する前に、認証／現在のコンテキストから得た ID を正規化します。{ userId, avatar, name } のようなレスポンスも対象です。デスクトップでは、現在ログイン中のユーザー表示を上部ヘッダーの右側に配置し、厳密に32pxのアバターと装飾のない表示名を使用します。モバイルでは左上にアバターのみを表示し、パッケージのアカウントドロワーを開きます。テナント名とログアウトの表示については、mobile-defaults.md を読みます。
8. 新規 Make App UI では、デフォルトでプラットフォームのコンポーネント分割済みソースツリーを使用します。src/pages、src/components、src/hooks、src/lib/service-api、src/router、src/types を使用し、複雑なテーブル／ワークフローコンポーネントは config、editing、editors、hooks、renderers、types の各モジュールに分割します。
9. 新規 Make App UI では、ホスト側でフォーム、詳細、テーブル表示、セルエディターの動作を実装する前に、apps/ui/src/lib/make-field-types.ts またはホストプロジェクトで定められた同等の場所に、共通の Make フィールド型レジストリを作成します。このレジストリは、現在のすべての Make.Field.* 型を網羅し、表示グループ、レンダー種別、デフォルト幅、配置、複数値かどうか、コントロール／表示ヒント、UI コントロールに必要な正規化済み field.properties を公開する必要があります。対象には format、precision、decimalPlaces、maxCount、begin、end、symbol が含まれます。高度なフィルターの演算子と値エディターはパッケージ側が管理します。また、デスクトップ／タブレットのフィールド名とフィールド選択リストには、フィールド型アイコンのデフォルト契約を適用します。スマートフォンでは通常のフィールドラベルを使用します。アイコンを別途要求されるのを待たず、すべての新規 Make App で実施します。
10. デスクトップ／タブレットの作成、編集、詳細には、右側の Drawer と2列グリッドを使用します。スマートフォンでは、パッケージ連携の全画面・1列タスクルートを使用し、references/mobile-form-controls.md を読みます。スマートフォンのタスクページでは、デスクトップのポップアップをそのまま再利用せず、フィールド表示アダプターを切り替えます。
11. カスタムフォームフィールドコントロールは、ホストフォームに制御されたアダプターでなければなりません。ホストフォーム層から value/onChange/onBlur/id/disabled を受け取り、引き渡す必要があります。また、送信／検証時に参照されるフォーム値は、画面に表示される選択内容と一致させます。これは UI ライブラリに依存しない要件であり、Ant Design、Arco、shadcn のいずれも必須ではありません。スマートフォンとデスクトップでアダプターの見た目が異なってもかまいませんが、送信値の契約は同一に保ちます。
12. 詳細値は、フィールド型の表示アダプターを通して描画します。フィールド型に安定した Make 表示形式がある場合、生のオブジェクト、配列、JSON ラッパーのテキストを表示しないでください。
13. 生成された Make App UI では、必須の権限ゲートとフィールドセットの引き渡しに make-app-permission を使用します。通常の新規作成では、権限から導出された createFields／作成フィールドセットを使用します。承認申請の新規作成では、make-app-approval が定義する、許可された開始設定のフィールドを使用します。編集では、表示可能フィールドと編集可能フィールドセットを使用します。ルート／アクションのチェック、ペイロードのフィルタリング、更新は Permission が担当し、makeui は許可済みの結果のみを描画します。
14. 書き込み可能な Make レコードリストでは、レコード操作を make-app-actions に委譲します。デスクトップ／タブレットでは、CanvasTable の複数選択、下部アクションバー、単一編集／削除、複数レコード編集を使用します。スマートフォンでは、カードリストと、make-app-actions のヘッドレスコアを通じた、選択したレコードの編集／削除を使用します。また、権限で制御された詳細アクションバーを使用します。CanvasTable、レコード選択、複数レコード操作は表示しません。make-app-actions を読み込み、その mobile-card-actions.md リファレンスを読みます。makeui は選択済みのコンポーネントライブラリを維持し、パッケージのモーダルのためだけに AntD を混在させてはいけません。
15. スマートフォンのツールバーでは、検索をデフォルトの項目にします。search-only モードでキーワード検索に filter.expression を使用する場合は、フィルタープリセット、Controller、パネル、スマートフォン用フィルタートリガーを使わず、make-app-filter の compileListFilter を使用します。高度なフィルタリング（明示的な絞り込み、テーブルフィルタリング、ヘッダーフィルタリングの要件を含む）が要求済み、またはすでに存在する場合は、advanced-filter モードを使用し、動作を make-app-filter に委譲します。そのうえで makeui は、mobile-defaults.md の説明に従い、デスクトップ／タブレットのツールバーと CanvasTable の連携に加えて、スマートフォンでは検索の横に独立した中サイズのフィルター項目を配置します。スマートフォンではリストのプルダウン更新を使用し、独立した更新コントロールは設置しません。また、advanced-filter モードに限り、デスクトップのフィルター Popover ではなく、モバイルパッケージの MobileFilterSheet を使用します。
16. レコードのグループ化、複数階層のグループ化、ドラッグによる優先順位設定、グループ化された CanvasTable、record-groups、groupFilter が要求済み、またはすでに存在する場合は、統合動作を make-app-group に委譲します。makeui はそのトリガーをデスクトップ／タブレットのみに配置します。標準のスマートフォン用ツールバーではグループ化を非表示にします。
17. レコードの並べ替え、複数フィールドでの並べ替え、ドラッグによる優先順位設定、テーブルヘッダーの昇順／降順が要求済み、またはすでに存在する場合は、統合動作を make-app-sort に委譲します。makeui はそのトリガーをデスクトップ／タブレットのみに配置します。標準のスマートフォン用ツールバーでは並べ替えを非表示にします。
18. デスクトップ／タブレットの Make レコードテーブルでセル編集が要求済み、またはすでに存在する場合は、テーブルに canvas-table-integration の Track C を Make 表示のベースとして使用し、Track B を編集機能の拡張として使用します。makeui はテーブルホストを配置できますが、ページコンポーネントに独自のセルエディターを実装してはいけません。スマートフォンのカードではセル編集を提供しません。標準外の CanvasTable セルエディターは準備完了／納品の阻害要因です。UI を準備完了、完了、または納品済みとして報告しないでください。
19. タスクに 助手、AI助手、MakeAI AI 助手、Make AI 助手、AI 对话框、SSE、Agent Gateway、@qfei-design/make-ai-assistant、MakeAiTheme、maxDrawerWidth のいずれかが含まれる場合は、まずプラットフォームの make-ai-assistant Skill がインストールされ、読み取り可能であることを確認します。その後、パッケージ、通信、パッケージのテーマ、内部アシスタント UI／スタイル、レスポンシブ対応にその Skill を使用します。その Skill がない、または利用できない場合は、make-env-setup を使って Make プラットフォーム Skills をインストール／更新するか、必要な読み込み手順を報告し、Skill が利用可能になるまでアシスタントの実装を中止します。プロジェクトの履歴や既存プロジェクトからアシスタントの動作を推測しないでください。連携方法がその Skill によって定義された後、makeui が担当するのは周囲のレイアウト、配置、外部コンテナーの制約のみです。AI アシスタントとの対話を明示的に対象としない一般的なダイアログは、通常の UI 作業です。
20. コンポーネント分割が不十分な場合、新規 Make App UI と重要な UI 変更では、準備完了の阻害要因として扱います。準備完了または完了を報告する前に、App.tsx とルート／ページファイルがオーケストレーションのみを担っていること、実装ロジックがページ、シェル、機能コンポーネント、hooks、lib/service-api、フィールド表示／設定アダプター、テーブルホスト、ツールバー、Drawer の各モジュールに分割されていることを確認します。
21. 以下のマップから、必要なリファレンスファイルのみを読みます。 モバイルへの配信では、インストール後にscripts/verify-mobile-package-surface.mjsを使って、実際にインストールされたパッケージを検証してください。最小の公開 API は0.1.7ですが、一般的なビジュアル配信の基準は、固定された48pxの添付ファイルアップロードエントリーを含む0.1.9です。電話での高度なフィルタリングには、make-app-filterで指定されているとおり、モバイル0.1.11+とフィルター1.1.0+も必要です。検証に失敗した場合はパッケージのブロッカーであり、ホスト側でパッケージ内部のスタイルを上書きしてよいという意味ではありません。インストールと検証の境界については、references/mobile-defaults.mdに従ってください。

トピック別リファレンスマップ

タスク／トピック	参照先
UI の範囲、境界、シェルのデフォルト、動的ルート	references/principles.md
固定された電話向け製品基準と、後続の提案に対する優先順位	references/mobile-product-baseline.md
モバイルのデフォルト、デスクトップ／モバイル間のスムーズな切り替え、モバイルシェル／ナビゲーション／ワークベンチ／タスクページ／ピッカー／リストの最終状態	references/mobile-defaults.md
電話の作成／編集／詳細フィールドアダプター、日付／時刻／選択／検索／ファイルのコントロール、タスクのフッター、オーバーレイの収まり	references/mobile-form-controls.md
インストール済みモバイルパッケージの iOS 入力、ピンチズーム、添付ファイルのレンダリング、48px のアップロードエントリー	scripts/verify-mobile-package-surface.mjs
コンポーネント構造、モジュール境界、ページ分割	references/component-structure.md
アプリシェル、サイドバー、上部ヘッダー、ビューポートの高さの連鎖	references/app-shell-layout.md
オブジェクトリストページ、ツールバーの配置、デフォルトアクション	references/list-page-layout.md
作成／編集／詳細のドロワー、ドロワーのスタック、マスクを閉じる操作、ヘッダーアクション	references/drawer-layout.md
ルートベースの作成／編集／詳細ページ、または URL で指定可能な状態	references/page-route-layout.md
コンポーネントライブラリの選択、フィールドタイプの UI コントロール、詳細値の表示	references/component-usage.md
デフォルトの Lucide フィールドタイプ対応表、デスクトップ／タブレットでのラベルとフィールド選択アイコンの網羅、電話での除外	references/field-type-icons.md
間隔、密度、レスポンシブレイアウト、読み込み／空／エラー状態	references/styling-and-responsive.md
レコードテーブルの表示またはセル編集を実装する	canvas-table-integrationを使用
レコード選択、下部アクションバー、編集／削除／一括編集、行の事前選択を実装する	make-app-actionsを使用
高度なフィルターパネル、条件ビルダー、フィルター式、ヘッダーフィールドフィルター	make-app-filterを使用
レコードのグループ化、ドラッグによる優先順位、プリセットグループ、record-groups、グループ化されたテーブルのフロー	make-app-groupを使用
レコードの並べ替え、ドラッグによる優先順位、プリセット順、テーブルヘッダーの昇順／降順	make-app-sortを使用
Make AI 助手、AI助手、MakeAI AI 助手、AI 对话框、SSE、Agent Gateway、make-ai-assistant package、MakeAiTheme、maxDrawerWidth	make-ai-assistantを使用。パッケージが内部 UI／スタイルを所有し、makeuiがランチャー／パネルの配置、シェルへの適合、外部コンテナーの制約を所有します
単一アプリの権限、ルートガード、操作ボタン、フィールドの編集可否、権限を再読み込みする更新処理	make-app-permissionを使用
認証、ログイン、ログアウトハンドラー、トークン、セッションの動作	make-app-authを使用。makeuiが所有するのは、現在のユーザーメニューの表示領域と配置のみです
ビルド出力、Service の実行時動作、パッケージ化、公開準備	make-app-runtimeを使用。makeuiは実行時の契約を所有しません

厳守事項

範囲の境界

• makeuiでは、認証／ログイン、トークン、OAuth、Cookie、ログアウトの動作、セッションの仕組み、/api/make/**、ドメイン、ゲートウェイ、デプロイ、Docker/K8s、Node ランタイム、パッケージマネージャー、ビルド出力、Service ランタイムのルールを追加または変更しないでください。references/mobile-defaults.mdでは、プレゼンテーションパッケージの互換性事前チェックが必要になる場合がありますが、ホストのランタイム／パッケージマネージャーを選択または移行してはいけません。互換性がない場合はmake-app-runtimeに引き継いでください。
• makeuiでは、ビジネス API パス、Service コントラクト、データ永続化、権限ロジック、承認フロー、環境マッピングを定義しないでください。ここで許可されているエンドポイントに関するガイダンスは、UI セレクターのユーザー／部門候補ソースのデフォルト動作のみです。ホストのドキュメントで異なるトランスポートが指定されている場合は、ルート名よりホストプロジェクトのドキュメントと担当する Service/API スキルを優先してください。
• ユーザーが権限を明示的に不要と指定した場合を除き、make-app-permissionで必要とされる単一アプリの権限ゲートを実装しない限り、生成した Make App UI を完成したものとして報告してはいけません。
• 書き込み可能な Make レコードリストでは、デフォルトでmake-app-actionsを使用してください。デスクトップ／タブレットでは、複数選択と標準アクションバーを CanvasTable が担います。スマートフォンではカードを使用し、パッケージのヘッドレスな単一レコードアクションモデルのみを再利用してください。スマートフォンには CanvasTable、レコードチェックボックス、すべて選択、選択アクションバー、一括編集、その他の一括操作を表示しないでください。makeuiはカード／アクションの配置を担いますが、アクションの権限モデルや Service の事前チェックのライフサイクルを複製してはいけません。
• タスクに認証／ログイン／ログアウト／セッションの動作が必要な場合は、make-app-authを使用してください。ビルド出力、Service ランタイム、パッケージング、公開準備のルールが必要な場合は、make-app-runtimeを使用してください。
• タスクにフィルタリング、高度なフィルタリング、テーブルフィルタリング、フィルタービルダー、filter.expression、ヘッダーの「このフィールドでフィルタリング」が必要な場合は、make-app-filterを使用してください。makeuiで@qfei-design/make-app-filterのロジックを実装またはフォークしてはいけません。デスクトップ／タブレットのフィルタリングでは、make-app-filterとcanvas-table-integrationが連携する CanvasTable ヘッダーとのリンクを担います。スマートフォンでは、トップレベルの検索／フィルターの入口のみを使用し、ヘッダーとのリンクだけを目的として非表示の CanvasTable をマウントしてはいけません。
• タスクにグループ化、多段階グループ化、ドラッグによる優先順位、プリセットグループ、record-groups、groupFilter、グループ化された CanvasTable のレンダリングが必要な場合は、make-app-groupを使用してください。makeuiはグループモデル、dnd-kit の動作、プリセットのタイミング、Service ペイロード、groupFilter の合成、グループ化されたリーフのページネーションを担ってはいけません。
• タスクに並べ替え、複数フィールドでの並べ替え、ドラッグによる優先順位、プリセットの並べ替え、ヘッダーの昇順／降順が必要な場合は、make-app-sortを使用してください。makeuiは並べ替えモデル、dnd-kit の動作、プリセットのタイミング、Service ペイロード、テーブルヘッダーコントローラーとの連携を担ってはいけません。
• タスクに Make AI アシスタント、AI アシスタント、MakeAI AI アシスタント、AI ダイアログ、SSE、Agent Gateway、make-ai-assistant パッケージの統合、MakeAiTheme、maxDrawerWidthが必要な場合は、make-ai-assistantを使用してください。アシスタント内部の UI とスタイルはパッケージが担います。makeuiはアシスタントのトランスポート、履歴の復元、Service ゲートウェイのルート／オリジンルール、パッケージのテーマ変数、ヘッダー／タスクリスト／入力欄の動作、全画面制御、パッケージのコンテナークエリの動作を担ってはいけません。
• makeuiは、ホストから提供されるオブジェクト／フィールドのメタデータを UI のレンダリングに使用できますが、そのメタデータをどのように取得、保存、認証、デプロイするかを決定してはいけません。
• 新しい Make App やモバイル／レスポンシブ対応の変更では、試作用プロジェクトのコンポーネントをコピーせず、公開されている@qfei-design/make-app-mobileのエクスポートを使用してください。モバイルのプレゼンテーションとオーバーレイの仕組みはパッケージが担い、ビジネス状態、データ、権限、ルート、認証、環境検出はホストが担います。ユーザーから明示的な要望があれば、デフォルトのプレゼンテーションを変更できます。
• スマートフォンのユーザー／部門フィールドでは、デフォルトでパッケージの/fieldsエントリからMobileIdentityFieldを使用し、スマートフォンの編集画面の添付ファイルにはMobileAttachmentFieldを使用してください。トリガータグ、ID マーク、添付ファイルカード、削除確認、アップロードの入口をホスト側で再構築してはいけません。候補 API、ID の正規化、アップロード／削除／再試行リクエスト、レコードの識別情報、権限、永続化、フォーム検証は引き続きホストが担います。
• デスクトップのビューだけを実装した状態で、新しい Make App UI の準備が整ったと報告してはいけません。ユーザーが明示的に不要と指定した場合、または別のモバイルデザインを要望した場合を除き、references/mobile-defaults.mdに記載されたパッケージを使用したスマートフォン用シェル、ナビゲーション／ワークベンチ、リストとタスクページの構成、制御されたピッカーの動作、ブレークポイントの検証を提供してください。

UI メタデータと状態

• 生成された UI は、ホストから提供される正規化済みのオブジェクト／フィールドメタデータを使用します。バックエンドの生のスキーマバリアントを、テーブル、フォーム、詳細、ルート、シェルの各コンポーネントに直接渡さないでください。
• 作成フォームと編集フォームでは、ホストから提供される異なる権限判定結果を使用します。通常の新規作成では、許可された createFields／作成フィールドセットのみを表示します。承認付き新規作成では、make-app-approval の許可された起動設定フィールドを表示し、通常のフィールドとの積集合を再適用しません。編集では、まず表示可能なフィールドを表示し、その後、編集可能なフィールドセットを適用して、書き込み可能か読み取り専用かを切り替えます。makeui は IAM アクセスを再計算したり、不足している作成フィールドの代わりに表示可能なフィールドを使ったり、バックエンドの editableFields を直接使用したりしてはなりません。
• 必須バリデーションは、現在のモードで実際に表示される許可済みフィールドにのみ適用します。非表示または未許可の必須フィールドによって、作成／編集の送信をブロックしてはなりません。
• 新しい Make App UI では、ホストが管理するフィールド型のセマンティクスを apps/ui/src/lib/make-field-types.ts または同等の共有レジストリに集約する必要があります。フォームコントロール、詳細表示、CanvasTable の列／レンダラーの振り分け、テーブルのセルエディターでは、Make.Field.* の文字列配列を重複して定義したり、場当たり的な switch 文を使ったりせず、このレジストリを使用します。レジストリには、正規化済みの field.properties をフィールド型のヒントとともに保持し、生成されたコンポーネントがスキーマ固有の format、precision、decimalPlaces、maxCount、begin、end、symbol、useGrouping を使用できるようにする必要があります。レジストリが公開するのは、正規化済みのフィールドメタデータと表示のヒントのみです。ホストのフォーム／セルのバリデーションは、別個の純粋なヘルパーに分離してください。高度なフィルターの演算子、デフォルト値、バリデーション、値エディターの種類は、このレジストリではなく、@qfei-design/make-app-filter の公開 API から取得します。
• apps/dsl はモデリング成果物であり、UI ランタイムの依存関係ではありません。生成された UI は、フィールドの情報源として apps/dsl/**、/dsl/**、またはコピーされた *.yaml ファイルを読み取ってはなりません。
• オブジェクト／フィールドのメタデータが欠落または不整合の場合は、UI の依存関係エラー状態を表示し、不足している依存関係を報告します。makeui で業務 API のパスを作り出したり、ローカルの DSL を解析したり、偽のユーザー／部門／業務フォールバックデータを作成したりしてはなりません。
• スキーマ、データ、ルート、レンダリングの各エラーは、読み込み中、空、エラー、アクセス禁止、セッション期限切れ、再試行、見つからない、レンダリングエラーのいずれかの、ユーザーに見えるオブジェクトシェルの状態に解決してください。例外によってページが真っ白にならないようにしてください。
• Make.Field.Number、Make.Field.Currency、Make.Field.Percent のフォームアダプターでは、送信前にスキーマの小数桁数制限を適用する必要があります。対象は Number.precision、Currency.decimalPlaces、Percent.decimalPlaces です。小数桁数を検証する前に、入力された生の小数表記テキストを保持して解析してください。その後にのみ、有限の数値またはバックエンドで許可された純粋な数値文字列を生成します。小数桁数の超過は、フィールドレベルの 最多保留 N 位小数 エラーを表示し、その無効な送信と永続化リクエストをブロックする必要があります。これとは無関係な読み取り専用メタデータや候補のリクエストは引き続き利用可能にしてください。ホストプロジェクトで丸めの方針が明示的に文書化されていない限り、暗黙に丸めてはなりません。
• 数値フォームコントロールでは、IME の変換中に無効なテキストが挿入された場合も、最後に確定した数字を保持する必要があります。一時的な変換中の入力を解析して、値を短くしてはなりません。デスクトップ／タブレットのコントロールとスマートフォンのテキスト入力については、references/component-usage.md の「数値入力と IME 変換」にある動作と検証のガイダンスに従ってください。

フォームフィールドの制御契約

• これは MakeUI カスタムフォームフィールドコントロールにおける、厳守すべきルールであり、対応準備のブロッカーです。作成／編集用ドロワーフォームまたはルートフォーム内で使用するカスタムフィールドコンポーネントは、ホストフォームによって制御されるアダプターでなければなりません。ホストフォーム層から渡される value/onChange/onBlur/id/disabled を受け取り、引き渡す必要があります。また、ホストフォームから提供される場合は、name、ref、検証ステータス、アクセシビリティ用プロパティも引き渡す必要があります。
• 画面に表示される選択内容は、送信、保存、リゾルバー、または検証でフォームストアから読み取られる値と同じでなければなりません。ユーザー、部署、ルックアップ、選択、日付、ファイル、またはカスタムセレクターに選択内容が表示されていても、ホストフォームの値が空または古いままであれば、UI はリリースできる状態ではありません。
• カスタムセレクターコンポーネントでは、一時的な検索テキスト、ポップアップの開閉状態、取得済みオプションのキャッシュをローカルに保持してもかまいませんが、選択値だけを内部状態に保持してはなりません。onChange は、選択が確定するたびに正規化された送信値をホストフォームに書き戻し、必須項目の検証と操作済み状態が正しく機能するよう onBlur も引き渡す必要があります。
• このルールは特定のコンポーネントライブラリに依存しません。Ant Design、Arco、shadcn、または特定の Form.Item／Select の使用を必須にして問題を修正してはなりません。選択したプロジェクトのコンポーネントライブラリまたはプロジェクト独自のコントロールを使用しつつ、ホストフォームの制御契約を維持してください。

コンポーネント構成とモジュール化

• これは MakeUI のコンポーネント分割／モジュール化に関する必須ルールであり、準備完了の判定を妨げる要因です。新しく生成する Make App UI と、規模の大きい apps/ui の生成コード／リファクタリング済みコードは、ページ全体をひとつのコンポーネントとして実装するのではなく、責務ごとに分割してください。この分割が完了するまで、UI を準備完了、完成、または納品済みと報告してはいけません。
• 新しい Make App UI プロジェクトでは、プラットフォームのコンポーネント化されたディレクトリ構成を標準とします。ルートページには apps/ui/src/pages、シェルと機能コンポーネントには apps/ui/src/components、再利用可能な状態／データフックには apps/ui/src/hooks、UI から Service への呼び出しには apps/ui/src/lib/service-api、ルート登録には apps/ui/src/router、共有 UI 型には apps/ui/src/types を使用してください。複雑なテーブルまたはワークフローのコンポーネントには、config、editing、editors、hooks、renderers、types などのネストしたモジュールを追加してください。
• App.tsx に、データ取得、スキーマ正規化、テーブル列の構築、フォーム／詳細のマッピング、Drawer の状態管理、行アクションの動作、フィールドのレンダリングなどのビジネスロジックを持たせてはいけません。プロバイダー、ルーターのマウント、アプリレベルのシェル構成に限定してください。
• ルート／ページファイルの役割は、レイアウトの調整、ルートパラメーターの読み取り、機能モジュールの構成、最小限のページ状態の橋渡しに限ります。データ取得、フィールドメタデータの正規化、テーブル列の構築、フォームフィールドのマッピング、Drawer の状態管理、行アクション、レンダリングの詳細をすべてひとつのルート／ページコンポーネントにまとめてはいけません。
• 規模の大きい UI は、ルートページ、機能モジュール、再利用可能なコンポーネント、フック、データ／API アダプター、構成ビルダーに分割してください。まず、ホストプロジェクトに既存の components、features、hooks、services、api、utils、adapters、pages、routes などのフォルダー構成に従ってください。
• フラットな apps/ui/src の構成や、シェル、ルーティング、データ読み込み、テーブル構成、フォーム、ドロワー、行アクション、表示アダプターをひとつの App.tsx／ルートファイルに持たせる構成は、生成する Make App の準備上の欠陥です。UI を完成として報告する前に分割してください。
• 単一ファイルにロジックを詰め込まないでください。ページに複数の UI 領域、再利用可能な動作、複雑な状態管理、Make フィールドへの適応、テーブル構成、作成／編集／詳細の各画面がある場合は、変更を完了する前に、それらの責務を名前付きのモジュールに切り出してください。
• ごく小規模なローカル編集は、変更対象のコンポーネントの近くにとどめてもかまいません。ただし、既存の巨大なファイルをさらに大きくしたり、無関係な責務を混在させたりしてはいけません。この例外は、新しい Make App のスキャフォールド生成、明示的なモジュール化／リファクタリング、複数領域のオブジェクトページ、テーブル構成、フォーム／詳細ワークフロー、再利用可能な Make フィールド適応処理、その他の複合的な責務を追加する変更には適用されません。無関係な小規模編集で既存の巨大なファイルに触れる場合は、その編集によって責務の混在が悪化するのでなければ、大規模な分割は避け、後続のリファクタリングとして報告してください。

UI のデフォルト設定

• デフォルトのデスクトップ／タブレットのオブジェクトリストレイアウト：ナビゲーション、タイトルのみを表示するフラットなワークスペースヘッダー、ローカルツールバー、続いてcanvas-tableを配置します。スマートフォンレイアウトはreferences/mobile-defaults.mdに従います。スマートフォン用ツールバーとカードリストはビジネスControllerを共有しますが、デスクトップのツールバーやテーブルの断片を再利用したり、レンダリングしたりしません。
• サイドバーにはブランド領域、セクションラベル、1行のオブジェクト項目、明確なアクティブ状態を設けます。背景色はプロジェクトのテーマに合わせ、デフォルトで暗色にしないでください。
• サイドバーのアクティブ項目のハイライトは、サイドバーのコンテンツガター内で中央に配置し、左右のインセットを一定に保ち、サイドバーの端まで溢れないようにします。
• ユーザーから求められない限り、サイドバーの項目やワークスペースヘッダーのタイトルにサブタイトル、説明、補助行、スキーマの概要、概要文を追加しないでください。
• デスクトップのトップヘッダーにある現在のユーザーのトリガーは、references/app-shell-layout.mdに従う必要があります。正規化されたID、固定サイズ32pxのアバターと装飾のない表示名を使い、ピル型やカード型の枠は使いません。クリックすると、退出を含むドロップダウンを開きます。モバイルヘッダーにはアバターのみを表示し、references/mobile-defaults.mdの左側アカウントドロワーを開きます。makeuiが担当するのはビジュアル面のみで、ID、実行環境の検出、アクションハンドラーはmake-app-authが提供します。
• デスクトップ／タブレットでは、ローカルツールバーをテーブルの上に配置します。左側に検索／フィルター／更新、右側に作成／新規を配置します。更新をグローバルヘッダー、オブジェクトタイトルのヘッダー、テーブルのヘッダー行、canvas-tableのヘッダー領域、列ヘッダー領域に配置しないでください。このルールによって、スマートフォンのカードリスト用ツールバーに更新コントロールが追加されることはありません。
• デフォルトのオブジェクトリストでは、ワークスペースヘッダーとテーブルの間にサマリー／タイトルカードを挿入しないでください。
• 要求されない限り、ページネーション、ビュー、インポート／エクスポート、グループ化、並べ替え、列設定、カンバン／分割ビューを追加しないでください。複数選択は、make-app-actionsを使用する書き込み可能なMakeレコードリストではデフォルトで有効にする例外です。それ以外ではオプトインのままにしてください。
• Makeレコードテーブルには、canvas-table-integration経由で@qfei-design/canvas-tableを使用してください。UIライブラリのテーブルで置き換えないでください。
• 新たに生成するMake Appのアイコンは、ユーザーが別のアイコンライブラリを明示的に要求しない限り、すべてLucideを使用します。このアイコンライブラリのデフォルト設定は、React UIコンポーネントライブラリを選択または制限するものではありません。デスクトップ／タブレットのMakeフィールド名表示では、デフォルトでreferences/field-type-icons.mdの型マッピング、適用範囲、ビジュアル基準に従います。アイコンは名前の左側に一定の間隔で配置し、垂直方向に揃え、色を統一します。アイコンライブラリが明示的に上書きされた場合も、同等のアイコンを使用して、フィールドの種類と配置は維持します。CanvasTableのテーブルヘッダーもこの要件の対象です。スマートフォンのフィールドラベルとフィールド選択リストはテキストのみとします。
• Makeのフィルタリングには、make-app-filter経由で@qfei-design/make-app-filterを使用してください。makeuiでローカルのフィルターモデルヘルパー、演算子マトリックス、バリデーター、CELコンパイラー／パーサー、カスタムの高度なフィルターパネルを生成しないでください。
• フィルタリングが対象に含まれる場合、makeuiが担当するのはツールバーの配置のみです。search-onlyモードでは、スマートフォンのツールバーに中サイズの検索を配置し、フィルタートリガー、Controller、パネルは配置しません。advanced-filterモードでは、デスクトップ／タブレットでは検索／フィルター／更新をまとめて配置し、CanvasTableのヘッダーと連携させます。スマートフォンでは、中サイズの検索とフィルターコントロールを専用のコンパクトなツールバーに配置します。スマートフォンでは、独立した更新アイコン／ボタンではなくリストのプルツーリフレッシュを使用し、デスクトップのlistToolbarやPopoverのレンダリング断片を再利用しません。モバイルのフィルターパネルの仕様はmake-app-filterが担当します。
• グループ化が対象に含まれる場合、デスクトップ／タブレットでは、そのトリガーをフィルターの後、並べ替えの前に配置します。標準のスマートフォン用ツールバーにはグループ化を表示しません。グループ化のUI／モデル、Presetの永続化、record-groups、groupFilterの構成、CanvasTableでのグループ表示、グループ化されたリーフのページネーションはmake-app-groupが担当します。
• 並べ替えが対象に含まれる場合、デスクトップ／タブレットでは、そのトリガーをグループ化の後、更新の前に配置します。標準のスマートフォン用ツールバーには並べ替えを表示しません。並べ替えのUI／モデル、Presetの永続化、recordsリクエストのタイミング、CanvasTableヘッダーとの連携はmake-app-sortが担当します。
• 生成されるMake Appのシェルとオブジェクトリストページでは、bodyレベルまたはページ全体のスクロールを発生させないでください。ルートシェルはビューポートの高さに固定し、オーバーフローはそれぞれの領域内で処理します。長いサイドバーナビゲーションはサイドバー内のみ、テーブルデータはCanvasTable／テーブル領域内のみ、DrawerのコンテンツはDrawerの本文内のみ、ルートページのコンテンツはコンテンツ領域内のみでスクロールさせます。通常のオブジェクトリスト閲覧で、body、アプリのルート、シェル、リストページをスクロールコンテナーにしないでください。
• 権限またはSchemaの読み込みに失敗した場合も、グローバルなmake-app-observabilityのエラー表示領域をマウントしたままにしてください。0.1.8+では、デスクトップとスマートフォンのMakeAppErrorNoticeViewportはマウント後にdocument.bodyへポータル表示されます。キューの配置はパッケージに任せ、古いホスト側のposition／inset／paddingの上書きを削除してください。公開されているzIndexプロパティでカードを関連するオーバーレイより上に表示し、100vh + overflow: hiddenを使用するものも含め、実際のShellですべてのコンテンツを確認してください。
• デスクトップ／タブレットでは、CanvasTableのラッパーとホストが利用可能なコンテンツ幅と残りの高さをすべて使うようにします。テーブルの寸法を固定するのではなく、flexによる高さの連鎖、または正確なcalc()の代替手段を使用してください。
• デスクトップ／タブレットのCanvasTableでは、ユーザーがテーブルに不要だと明示しない限り、デフォルトでshowSNによる通し番号と、bodyRowHeadSuffixOptionsによるホバー時に表示される行ヘッドの詳細アイコンを使用します。
• デスクトップ／タブレットのCanvasTableのセルエディターはcanvas-table-integrationが担当します。Makeのスキーマ編集可能テーブルではTrack CとTrack Bを併用してください。新しいMake App UIでテーブルセル内に独自の入力ボックスを実装しないでください。スマートフォンのカードはセルエディターではありません。フィールドエディターはホストのコンポーネントライブラリを再利用し、セル内の枠線はCanvasTable独自のアクティブ編集枠線のみとします。
• デスクトップ／タブレットの作成／編集／詳細表示には、デフォルトのMakeオブジェクトCRUD用として右側のDrawer形式の画面を使用します。スマートフォンの作成／編集／詳細表示には、references/mobile-defaults.mdの全画面ルートタスクページのパターンを使用し、CRUDをボトムシートにしないでください。ユーザーから明示的な要求がある場合は、別の画面形式を選択できます。
• デスクトップの作成／編集／詳細レイアウトは、デフォルトで2列にします。ユーザーから明示的に要求された場合、またはビューポートが狭すぎる場合を除き、すべてのフィールドを1列の全幅で表示しないでください。
• デスクトップ／タブレットの作成／編集フィールドは、デフォルトでラベルを縦に配置した2列グリッドにします。一般的なフィールドは1列に配置し、TextArea、URL／リンク、File、Lookup／関連レコード選択、長文、リッチコントロールなどの幅広のフィールドは行全体に広げます。このデスクトップ／タブレット用グリッドはスマートフォン用レイアウトではありません。スマートフォンのフィールドはreferences/mobile-form-controls.mdに従い、このグリッドを折りたたんでスマートフォン用レイアウトにしないでください。
• デスクトップ／タブレットの詳細ビューは、デフォルトでコンパクトな2列のラベル／値グリッドにします。一般的なフィールドは1列に配置し、長文、TextArea、リッチな値を含むURL／リンク、File、Lookup／関連レコード値、添付ファイルが多い値、リッチコンテンツは行全体に広げます。スマートフォンの詳細表示はreferences/mobile-form-controls.mdに従い、通常のラベル／値の行では、値を右端に揃えます。
• 詳細表示の値は、レンダリング前にMakeのフィールド型に応じて正規化する必要があります。{ begin, end }などの日付範囲オブジェクトや[begin, end]などの配列は、生のJSONではなく書式設定された範囲として表示します。選択肢／ユーザー／部署／ファイル／ルックアップの値には、それぞれの型に対応した読み取り専用レンダラーを使用します。空の値は薄い色の-で表示します。
• 詳細Drawer／ページのタイトルには、スペースが許す限り、選択したオブジェクトまたはレコードのタイトル全体を表示します。タイトル領域には柔軟な幅を与え、実際にはみ出す場合に限り省略記号を使用します。完全なタイトルはツールチップまたはアクセシブルなタイトルから確認できるようにしてください。本来表示できるタイトルが切れるような、小さなタイトル枠を作らないでください。
• 作成／編集フォームでは、型に適したコントロールを使用します。日付、選択肢、ユーザー、部署、ファイル、ルックアップの各フィールドを、警告なくプレーンテキスト入力に置き換えてはいけません。アップロードに既存レコードのIDが必要な場合、作成モードではファイルアップロードを省略します。
• 作成／編集用のカスタムフォームフィールドコントロールは、component-usage.mdに記載されたホストフォームのcontrolled契約に従う必要があります。value/onChange/onBlur/id/disabledを引き継ぎ、ビジュアル上の選択状態とフォームストアを同期させます。ローカルだけで管理される選択状態が残っている場合は、リリースを阻止してください。
• スマートフォンでの作成／編集／詳細表示は、references/mobile-form-controls.mdに従う必要があります。全画面ルートと1列のCSSだけでモバイル対応が完了したとみなし、デスクトップと変わらないDatePicker、RangePicker、Select、Lookup、Upload、無効化されたフォームの詳細表示、その他ビューポートに適さないコントロールを表示しないでください。
• 作成権限がある一方で、許可された作成フィールドがない場合は、作成画面を明示的にしてください。暂无可新建字段（またはホスト側の同等の表示）をレンダリングし、送信を無効にします。表示／編集可能なフィールドからフィールドを捏造しないでください。
• 作成、編集、詳細表示では、権限とホスト機能によるフィルタリング後に、モードごとにレンダリング可能なフィールドコレクションを算出します。そのコレクションが空の場合は、利用可能なコンテンツ領域の中央に明示的な空状態のみをレンダリングしてください。フィールドグリッド、フォーム／詳細パネル、セクションパネル／カード、プレースホルダーのForm.Item、枠線、影、固定の最小高さを持つラッパーはレンダリングしないでください。読み取り専用フィールドが表示されたままの場合、編集可能なフィールドが0件でも、この空状態にはしません。ヘッダー／閉じる操作は引き続き使用可能にし、送信を無効にして暂无可新建字段を表示するのは作成時のみです。
• Modal、Drawer、スクロール領域内のSelect、DatePicker、Popover、ID選択コントロールなどのポップアップコントロールは、component-usage.mdとstyling-and-responsive.mdに記載されたオーバーレイのポータル契約に従う必要があります。オーバーフローによってクリッピングされる祖先要素の外側にマウントし、表示先の画面より上に配置してください。クリッピングされるパネル内でz-indexを上げても、有効な解決にはなりません。
• ユーザーおよび部署の選択UIは、ホストの候補APIを使用し、references/component-usage.mdの標準マッピングに従う必要があります。スマートフォンでは、references/mobile-defaults.mdに記載されたcontrolled形式のパッケージピッカー契約に従います。ホストプロジェクトのドキュメントが、生成されるMake Appのデフォルトの通信方式に優先します。
• ユーザー／部署セレクターの信頼できるデータソースとして、フィールドスキーマのoptions、ローカルのデモ配列、行のサンプル、ハードコードされた名前、古いクライアント側のリストを使用しないでください。実際の候補APIの読み込み中または一時的に空の場合に限り、既存の選択内容を表示するために現在のレコード値を候補に加えることはできます。セレクターが高度なフィルターまたはCanvasTableのセル編集内に表示される場合は、候補データソースに関するこの契約を維持しながら、make-app-filterまたはcanvas-table-integrationを使ってその画面を実装してください。
• /objects/:objectKeyなどの動的なオブジェクトルートを使用してください。オブジェクトごとにハードコードされたルートコンポーネントを1つずつ生成しないでください。

対象外

• 認証、ログイン、トークン、ログアウトの動作、セッションの仕組み、または SDK の統合
• フロントエンドのビルド出力、パッケージスクリプト、公開、デプロイ、Docker、K8s、または実行時の準備状況
• Service の構造、Service の設定、Service のポート、API プロキシ、または API オーケストレーション
• ビジネス項目または項目の意味
• クエリ／保存 API の設計
• ビジネスポリシーに関連するバリデーションルール
• 権限チェックおよび承認フロー
• ビジネスデータのモデリングまたは DSL の変更
• @qfei-design/canvas-table の実装またはセル編集のライフサイクル
• @qfei-design/make-app-filter の実装、演算子マトリックス、バリデーター、CEL コンパイラー／パーサー、またはパネルの内部実装