make-app-permission

make-app-permission

直接 URL 和运行时资源拒绝遵循 references/scoped-route-feedback.md：应用守卫位于 Shell 外部，对象／固定路由守卫位于 Shell 内部。拒否时应替换整个被拒绝的业务内容，而不只是表格行；保留已授权的导航和全局身份标题。必须提供已渲染树和零拒绝请求回归测试。React 通过 makeui/references/permission-feedback.md 渲染已验证的软件包；此 Skill 决定作用范围和访问生命周期，而非组件样式。若需查找当前应用的人员联系信息，请阅读 make-app-auth/references/access-help.md，但不要发送被拒绝的业务请求。

当请求创建、更改、审查或调试 Make App 单应用权限强制机制时，请使用此 Skill。对于每个生成或重构的 Make App，默认必须启用。即使请求重点在 UI、Service、Schema 或运行时工作，也不得省略 IAM 代理、路由守卫、权限感知 Schema 或权限审计。

此 Skill 负责权限语义。登录／会话请使用 make-app-auth，Service 和 Schema 传输请使用 make-app-service，渲染请使用 makeui，单元格编辑器机制请使用 canvas-table-integration，打包／运行时请使用 make-app-runtime。

クイックスタート

1. 確認 apps/docs/api.md、Service／UI Schema アダプターと型、プリンシパル権限コード、プロバイダー、ルーター、オブジェクトページ、新規作成／編集フォーム、送信ビルダー、更新フロー和测试。
2. 作用范围、permissionKey、Schema 集合或字段访问状态を選択する前に、references/permission-boundaries.md を読んでください。
3. /principal/permission を変更する前、または IAM fieldAccess を解釈する前に、references/service-principal-permission.md を読んでください。
4. 路由／操作的门控、新建／读取／更新字段集、载荷过滤或更新を変更する前に、references/ui-permission-runtime.md を読んでください。
5. ID／审计新建或编辑能力を实现する前に、references/system-field-contract.md を読んでください。
6. 实装前和报告完成前に、references/testing-and-audit.md を読んでください。
7. まずテストを実装し、その後 Service／Schema 境界、権限の純粋モデル、ルート／操作ゲート、フィールドセット利用箇所、送信許可リスト、更新時の無効化を実装してください。
8. ホストテスト、動作適合性スイート、および node skills/make-app-permission/scripts/audit-make-app-permission.mjs <project-root> を実行してください。両方の権限チェックをホストのデフォルトテスト、CI、または公開ゲートに組み込んでください。ローカルで一度実行するだけでは、継続的なゲートになりません。
9. この Skill を公開またはインストールする際は、ソースとインストール先のディレクトリを明示して check-installed-skill-sync.mjs を実行してください。リリースによって Make の共有レスポンス／認証／権限ガイダンスが変更される場合は、プラットフォームパッケージを公開し、npx skills update qfeius/make-platform-skills を実行してから、ソースとインストール済み Skill のルートを明示して、リポジトリ全体の check-installed-make-platform-skills-sync.mjs を実行してください。これらのローカルリリースチェックを、移植可能なホスト CI に含めないでください。

必須契約

本節の createFields ∩ meta.field.read ルールは、通常の新規作成に適用されます。有効な bpmDefinitionKey を持つオブジェクトでは、まず make-app-approval に従って承認新規作成ブランチを選択してください。UI と Service の両方で、通常の IAM フィールド集合との積集合ではなく、起動設定で許可されたフィールドを基準とします。アプリ、オブジェクト、新規作成操作の権限は引き続き適用されます。この例外は通常の既存レコード編集には拡張されず、「自分の承認」の固定ナビゲーションを業務オブジェクトのメニュー権限項目として扱うこともありません。詳細な契約については、承認新規作成フィールド を参照してください。

• /api/make/app/principal/permission を公開し、Service が App スコープと MakeService.GetResource、確立済みのログインコンテキストを使用して /api/make/iam/v1/principal/permission を呼び出すようにします。これは Make の直接プロキシです。完了した IAM レスポンスは、2xx／4xx／5xx のステータス、Content-Type、本文を含め、すべて変更せずに返します。テナントルートスコープや上流のプラットフォーム権限フィルターを要求してはいけません。厳密な正規化の前に、references/permission-boundaries.md に従って行を分類します。明らかに無関係な行のみを無視し、選択された行や分類不能な行はすべてフェイルクローズにします。
• 現在のコンテキストに基づくテナント解決は、make-app-auth/references/service-fronted-mode.md#current-context-consumption に従います。プリンシパル権限の結果となるのは、実際の App スコープ IAM レスポンスのみであり、認証に関する互換性の主張は含みません。
• IAM ワイヤー上の成功レスポンスは {code:200,data:{principal,scope,permissions}} であり、認証 ID のみの形式とは異なります。Service はこの形式を維持します。UI リクエストアダプターは code を確認し、権限の正規化前に data を一度だけ展開します。DTO のみを対象とする純粋モデルだけでなく、本番 UI のローダー境界も検証します。references/testing-and-audit.md を参照してください。
• 完全一致、ワイルドカード、親、App、エンティティ、IAM 名前空間ワイルドカードの App リソース、および deny を正しく処理します。最も具体的な allow フィールド範囲を使用し、deny を優先します。
• 作成、表示、編集のフィールドセット判定を分離します。
  • 作成フォーム：createFields ∩ meta.field.read fieldAccess(creatable|readonly|editable|partialMask|fullMask|*)；
  • リスト／詳細／フィルター：fields ∩ meta.field.read fieldAccess(readable states)；
  • 編集／セル編集：表示可能な fields ∩ meta.field.update fieldAccess(editable|*)。
• エンティティ、フィールド、レコードの認可は独立させます。meta.entity.read は、Schema に存在するエンティティがナビゲーションに表示され、オブジェクトルートにアクセスできるかを制御します。この権限がない場合、ナビゲーションと動的ルートの両方でエンティティへのアクセスを拒否する必要があります。meta.field.read は、業務コンテンツを表示する際に認可された列／テーブルヘッダーを制御します。data.record.read は、レコード／詳細のリクエストと値を制御します。レコード読み取りが拒否または取り消されても、メタデータによって認可されたナビゲーションを削除したり、フィールド権限を変更したりしてはいけません。その代わり、現在のレコード読み取りに関する業務コンテンツ全体をリソースフィードバックに置き換えます。タイトル、ツールバー、ヘッダー、データ、ダイアログをアンマウントし、拒否されたリクエストはスキップして、キャッシュされた値と古い処理を無効化します。フィードバックの周囲に空のテーブルシェルを残してはいけません。
• フィールドに対して返されたアクセス状態をすべて保持します。現在の IAM レスポンスでは、["creatable", "readonly"] のような配列やスカラー文字列が使われる場合があります。サポート対象のスカラー文字列は 1 要素の配列に正規化し、ある権限ディメンションで許可されている状態が 1 つでもあれば、そのディメンションを認可します。配列を String(value) やテンプレート補間で文字列に変換してはいけません。
• createFields がない場合は空として扱います。fields にフォールバックしてはいけません。また、現在の編集動作で editableFields を使用してはいけません。
• 作成の開始操作と送信操作は data.record.create で制御します。普通新建では、照合された meta.field.read 行と createFields からフィールドを導出します。审批新建では、make-app-approval の認可済み启动配置フィールドを使用します。meta.field.create はプラットフォーム権限ポイントではないため、必須としたり、推測したり、出力したりしてはいけません。操作ゲートによってフィールドアクセスが許可されることはありません。普通新建では従来のフィールド積集合を維持し、审批新建では Workflow の個別フィールド認可を維持します。更新／削除／一括更新は、それぞれ独立した操作キーで制御します。
• 送信前に最新の作成／編集許可リストを再計算し、それに基づいてペイロードを構築します。保護対象の変更処理でフォームストア全体をスプレッドしてはいけません。
• ID とシステム監査フィールドは作成可能な対象から除外します。既存の監査フィールド編集機能は、そのフィールドが表示可能で、更新権限があり、ホストエディターが対応している場合に維持します。
• 作成専用の非表示フィールドは、作成モードでのみ使用できるようにします。creatable アクセス状態は、読み取りや編集を許可するものではありません。
• App／オブジェクト／固定ルートのガードを追加します。メニューやボタンを隠すだけでは認可になりません。読み取りと変更の前にハンドラーで再確認します。
• データを更新する前に、同じアクセス世代で権限と権限によって絞り込まれた Schema を更新します。古い権限、Schema、フォーム、レコードの処理を無効化します。レコード読み取りの拒否によって、独立した作成ルートの権限を取り消してはいけません。置き換えられる業務コンテンツの子孫はアンマウントします。操作のみが拒否された場合、許可された入力はそのまま維持します。
• 権限または Schema の取得に失敗した場合はフェイルクローズにします。行単位の dataCondition 適用はバックエンド API に委ねます。
• 権限および Schema のリクエスト失敗では、共有リクエストアダプターの安全な構造化情報 kind/status/title/description/traceId を、Provider の状態からエラーアウトレットまで保持します。リクエストエラーの分類とカード表示には make-app-observability を使用します。これらの失敗を単なる文字列にしたり、上流の生のエラーを公開したりしてはいけません。権限拒否の結果は引き続き forbidden 状態として扱い、リクエスト失敗を捏造してはいけません。
• Service／Schema、権限モデル、ルート／ページ、ペイロード、特殊フィールド、更新、および否定的な監査テストを追加します。

リファレンスマップ

タスク	参照先
Platform と App の適用範囲、フィールドの作成／読み取り／更新の各サーフェス、Schema コレクション、照合	references/permission-boundaries.md
サービスエンドポイント、IAM リクエスト／レスポンス、meta.field.read.fieldAccess	references/service-principal-permission.md
プロバイダー、ヘルパー、ルート、作成／編集フロー、ペイロード、更新、Lookup	references/ui-permission-runtime.md
ID／監査フィールドの作成時の厳密な除外と編集時の互換性	references/system-field-contract.md
必須テスト、監査シグナル、完了を妨げる問題	references/testing-and-audit.md
認証／セッション	make-app-auth を使用
Schema／API の転送とキャッシュ	make-app-service を使用
フォーム／空の状態の表示	makeui を使用
テーブル／セルエディターの仕組み	canvas-table-integration を使用
選択、行の事前チェック、一括アクション	make-app-actions を使用
ランタイムゲートウェイとパッケージング	make-app-runtime を使用

監査

node skills/make-app-permission/scripts/audit-make-app-permission.mjs <project-root>

失敗はブロッカーとして、警告はレビュー項目として扱ってください。監査はヒューリスティックであり、ランタイムテストに代わるものではありません。 正規化の出力または権限評価に影響する場合、String(...)、テキストヘルパー、テンプレート補間、.toString()、.join() による fieldAccess 状態配列の明らかな文字列変換を拒否します。これには、制御フロー条件での直接使用も含まれます。診断のみを目的とするログ、コメント、および名前付き正規化ヘルパー内の文字列リテラルは、パラメーター名が汎用名か fieldAccess 固有の名前かを問わず、監査で失敗にしてはなりません。実行可能な動作コントラクトが引き続き優先されます。

また、薄いホストアダプターを用意し、実行可能な動作コントラクトを実行してください。

node skills/make-app-permission/scripts/permission-conformance-suite.mjs <host-adapter-module>

また、薄いアダプターを介して、本番 UI 権限ローダーに対するワイヤーレスポンスコントラクトを実行してください。

node skills/make-app-permission/scripts/principal-response-conformance-suite.mjs <host-loader-adapter-module>

これにより、ビジネスコードの検証、一度限りのアンラップ、空の IAM 権限付与、拒否連絡先の保持が保護されます。既存の純粋モデルスイートでは SDK のレスポンスデコードをテストしません。アダプターコントラクトとホストゲートの手順については、references/testing-and-audit.md を参照してください。

アダプターが TypeScript の場合、ホストに既存の TypeScript ランナーを使って同じコマンドを実行してください。このチェックのためだけにランタイム依存関係を追加しないでください。アダプターは本番の権限ヘルパーと作成機能ガードに処理を委譲する必要があります。テスト内でそれらを再実装してはなりません。 監査と適合性ランナーはプロジェクト内に置くか、ホストゲートにする前にバージョン付きの依存関係としてインストールしてください。移植可能な CI に、別のワークスペースのチェックアウト先や開発者のホームディレクトリにある Skill のパスをハードコードしないでください。

ローカルでの Skill のインストール／リリース確認では、ソースディレクトリとインストール先ディレクトリ全体を比較してください。

node skills/make-app-permission/scripts/check-installed-skill-sync.mjs \
  skills/make-app-permission <installed-skill-dir>

チェッカーは、ソース側のみ、インストール先のみ、および内容が一致しないファイルを報告します。インストール先ディレクトリを明示してください。Skill やホスト CI に開発者のホームディレクトリのパスを埋め込まないでください。

共通の Service／認証／権限コントラクトを変更するリリースでは、まずインストール済みのプラットフォームパッケージを更新し、その後、影響を受けるすべての Make App Skill を検証してください。

npx skills update qfeius/make-platform-skills
node scripts/check-installed-make-platform-skills-sync.mjs \
  skills <installed-skills-dir>

ソースリビジョンがプラットフォームの Skill リリースフローを通じて公開された後にのみ実行してください。これはローカルでのリリース確認であり、移植可能なホスト CI ではありません。