editor-creator

Name: editor-creator
Author: datex

github.com/datex開発92 回インストール

リポジトリ

editor-creator について

Datex Studioのブランチ上でエディター設定を作成・変更するスキルです。単一エンティティの表示・編集画面を対象とし、フィールドのバインド、表示モードの切り替え、CRUDアクションを呼ぶ関数経由の保存を扱います。

主な機能

01エディター設定の作成・変更
02単一エンティティへのフィールド紐付け
03読み取り専用・編集モードの設定
04ラッパー関数経由のCRUDアクション呼び出し
05検証後のブランチへの書き込み

活用シーン

011件のレコード向け詳細・編集画面の作成
02エンティティ属性に合わせたフィールド設定
03既存設定の保存・編集動作の変更

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/datex/skills --skill editor-creator

インストール後、Claude Code で/editor-creatorを入力して読み込まれたか確認します。

同梱ファイルevals/evals.jsonreferences/editors.md

詳細

エディター作成ツール

ブランチ上で Datex Studio のエディター（configurationTypeId=4）を作成または変更します。エディターは、1つのレコードを読み込む単一エンティティの表示・編集画面で、フィールドをプロパティに1対1でバインドし、読み取り専用モードと編集モードを切り替え、CRUD アクションを呼び出すラッパー関数を通じて変更を保存します。

参考資料

../datex-studio-shared/branch-setup.md — ブランチ／接続の選択（スキル間で共通）
references/editors.md — エディター作成の正式なリファレンス：ファイル構造、ランタイムグローバル、呼び出し契約、一般的なパターン、事前チェックリスト
../datex-studio-conventions/file-format.md — configurationTypeId の表と TypeScript 式のエンコード規則
../datex-studio-conventions/naming-conventions.md — _editor 接尾辞、ファイル名のステムの一致、表示名の規則
../datex-studio-runtime/runtime-globals.md — エディターコードで利用できるプラットフォーム注入のグローバル変数（$editor、$flows、$shell、$utils など）
../datex-studio-runtime/calling-conventions.md — UI 層の呼び出し規則（関数を呼び出し、アクションは呼び出さないこと。CRUD は $apis.<Package>.FootprintApi.extendedActions.<action_name> 経由）
../form-creator/references/forms.md — 一時的な入力収集を行う関連コンポーネント（エディターとフォームのどちらを選ぶか）
../grid-creator/references/grids.md — 行クリック／行アクションのフローを介してエディターを表示する一般的なホスト
../datasource-creator/references/flow-datasources.md — エディターのバックエンドデータソースに必要な単一結果の形式
../component-wiring-check/references/component-wiring.md — ホスト参照の契約、vars を宣言する規則、moduleId の規則

依存関係

requirements-gathering スキル — 会話コンテキストに要件概要がまだない場合、その作成のために呼び出されます
form-creator／grid-creator スキル — 要件が単一エンティティの詳細画面ではなく、一時的な入力収集（フォーム）または複数レコードの一覧（グリッド）に該当する場合に呼び出されます
datasource-creator スキル — エディターのバックエンドとなる単一結果のフローデータソースを独立した設定として作成する必要がある場合に呼び出されます（まれなケースです。通常は埋め込みプライベートデータソースを使用します）。埋め込みデータソースを作成するには、../datasource-creator/references/datasources.md → 所有データソースの作成に従ってください。generate-flow --single --get-flow はエディターに必要な形式をすでに出力するため、変更するのはエンベロープの差分だけです。
component-wiring-check スキル — プッシュ前に、エディターのホスト（ハブタブ／グリッド行アクション／フォーム）の configParameters と対象の inParams の契約を監査するために呼び出されます
type-definition-creator スキル — エディターがバインドするエンティティのインターフェースまたは関連する型定義を作成・拡張する必要がある場合に呼び出されます（例：エディターで新たなバインディングを追加するため、スキーマにフィールドを追加する場合）
tailoring-overlay スキル — エディターに対する顧客固有の拡張（フィールドの追加、バインディングの変更）を基本設定ではなくテーラリングオーバーレイに含める必要がある場合に呼び出されます

CLI のライフサイクル

エディターの作成・編集には dxs configuration を使用します。これは、すべてのプラットフォーム設定タイプに対応する汎用 CRUD プリミティブです。dxs editor サブコマンドや、フィールド単位のパッチ処理はありません。JSON 本文全体を作成する（または取得して抽出する）必要があり、編集後に全体をプッシュします。CLI でのタイプ識別子は editor（小文字。ConfigurationEndpoints.normalize_type の出力と一致）で、configurationTypeId: 4 にマッピングされます。

新しいエディターを作成する：

# 1. Build body.json from scratch (see references/editors.md → Minimal Valid Skeleton)
# 2. Validate — gates the push. Exit 1 = errors found (read validation_errors, fix, re-run), not a broken CLI
dxs configuration validate editor -b <branchId> -D body.json
# 3. Create
dxs configuration upsert editor -b <branchId> -D body.json

既存のエディターを編集する：

# 1. Fetch — note the envelope wrapper
dxs configuration get editor <configId> -b <branchId> -O envelope.json
# 2. EXTRACT THE INNER BODY (round-trip footgun guard — see "Round-trip rule" below)
jq .json envelope.json > body.json
# 3. Edit body.json
# 4. Validate — gates the push. Exit 1 = errors found (read validation_errors, fix, re-run), not a broken CLI
dxs configuration validate editor -b <branchId> -D body.json
# 5. Push
dxs configuration upsert editor -b <branchId> -D body.json

ラウンドトリップのルール（重要）

既存の設定を編集する際、envelope.json を直接 dxs configuration upsert にパイプしてはいけません。設定内容が気付かないうちに破損します。上記の修正済み手順（編集前に jq で内部の .json を抽出する）は、ラウンドトリップのたびに必須です。正しいラウンドトリップの手順と根本的なバグについては、../datex-studio-shared/configuration-roundtrip.md を参照してください。

エディターは内容が密です。本文には toolbar、fieldsets、flows、datasourceConfig、datasources がかなり充実した状態で含まれ、埋め込みフローにはすべて code フィールドがあります。このように大量の JSON を部分的に編集するのはエラーが起きやすいため、ラウンドトリップの手順（取得 → jq で抽出 → 編集 → 検証 → プッシュ）を必ず守ってください。

ワークフロー

[Phase 1: Setup + Requirements]
Follow branch-setup.md for branch/connection selection
        |
[requirements brief in context?]
  +-----+-----+
  |            |
 YES          NO -> invoke `requirements-gathering`
  |            |
  +-----+------+
        |
[Phase 2: Editor vs Form vs Grid decision]
Consult references/editors.md → "Purpose & When to Use":
  - single hydrated entity, view/edit toggle, persist via CRUD -> editor
  - transient input collection, returns outParams, no entity -> form
  - multi-record tabular view -> grid
If form -> invoke `form-creator` instead and stop here.
If grid -> invoke `grid-creator` instead and stop here.
Create-only dialogs are usually forms, not editors.
        |
[Phase 3: Author editor body]
Build body.json:
  - File shape (configurationTypeId=4, *-editor.json suffix,
    referenceName ends _editor)
  - Embedded single-result private datasource in datasources[]
    (configurationTypeId=6, type=flows, accessModifier=private,
    getFlow populated; getListFlow/getByKeysFlow null;
    resultIsCollection=false; outParams[0].isCollection=false)
  - Flow shape: getFlow populated; getListFlow and getByKeysFlow null
    (editors call .get() — code left in getListFlow silently breaks hydration)
  - Entity shape mirrored: datasources[0].outParams[0].objectTypeDef
    == datasourceConfig.configOutParameters.result.objectTypeDef
  - onInitFlowConfig (pre-hydration; no $editor.entity reads)
    vs onDataLoadedFlowConfig (post-hydration; entity-derived defaults)
  - View/edit toggle via $editor.vars.edit_mode (declared in vars[])
  - Save branches on $editor.entity.isNew (crud_create vs crud_update)
  - onFormValidateFlowConfig gates $editor.toolbar.<save>.control.readOnly
  - EditorFields parity: every entity-interface field has a binding
    (stub with removed:true when UX isn't ready)
  - Invoke `datasource-creator` if a standalone datasource is missing
  - Invoke `component-wiring-check` to audit host's configParameters
        |
[Phase 4: Validate + push]
dxs configuration validate editor -b <branchId> -D body.json
        |
   +----+----+
   |         |
  CREATE   MODIFY-EXISTING
   |         |
   |         use the corrected round-trip
   |         (get -O envelope -> jq .json -> body)
   |         |
   +----+----+
        |
        v
dxs configuration upsert editor -b <branchId> -D body.json
   (upsert creates or updates by referenceName — one command for both)
        |
[Phase 5: Verify in Studio (optional)]
Open the editor as a dialog (from its host hub/grid); confirm
hydration, toggle into edit mode, save commits, cancel restores
        |
[invoke `post-edit-verification`; then `component-validator`]

フェーズの詳細

フェーズ 1：セットアップと要件

ブランチと接続の選択については、../datex-studio-shared/branch-setup.md に従ってください。ブランチ ID を決めつけてはいけません。ユーザーに確認してください。
会話のコンテキストに要件概要がすでに存在するか確認してください（requirements-gathering または別の呼び出し元のスキルによって作成されたもの）。
- 概要がある場合 — それを使用します。概要には、編集対象のエンティティ（ホストから渡されるキーを含む）、表示・編集可能なフィールド、閲覧専用モードと編集モードの動作、保存の仕様（変更を永続化する CRUD アクション）、および同じエディターで作成モードも扱うかどうかを明記する必要があります。
- 概要がない場合 — まず requirements-gathering スキルを呼び出してください。エンティティの形状と保存の仕様を最初に正しく把握しておけば、その後の密度の高いラウンドトリップを避けられます。

フェーズ 2：エディター、フォーム、グリッドの判断

作成を始める前に、references/editors.md → 用途と使用場面を確認してください。この選択は見た目の問題ではありません。エディター、フォーム、グリッドにはそれぞれ異なる役割があり、互換性はありません。

次の場合はエディターを選びます。

ユーザーがキーで識別される単一のエンティティを表示または変更する。
フィールド単位の入力が、そのエンティティのプロパティに 1 対 1 で対応する。
UX で、閲覧モード（読み取り専用）と編集モード（入力が有効になり、保存が可能）の切り替えを明確に設ける。
フローが CRUD アクション（crud_create_entity / crud_update_entity）を通じて変更を永続化する。

次の場合は、代わりにフォームを選びます。

作業が一時的な入力の収集であり、保存済みレコードに対応しない。
ダイアログが呼び出し元に outParams を返し、暗黙的に永続化されるものはない。
ダイアログが作成専用で、データを読み込む対象のエンティティがまだ存在しない。

次の場合は、代わりにグリッドを選びます。

ユーザーが表形式のレイアウトで複数のレコードを表示または操作する。

フォームが適切な場合は、そこで作業を止めて form-creator を呼び出してください。グリッドが適切な場合は、そこで作業を止めて grid-creator を呼び出してください。エディターは $editor.entity.isNew を使って作成モードに対応できますが、この方法が適切なのは、同じコンポーネントで同じエンティティタイプの作成と編集の両方を扱う場合に限られます。作成専用のダイアログには、通常フォームのほうが適しています。

フェーズ 3：エディター本文の作成

references/editors.md → 最小限の有効なスケルトンのスケルトンを基に body.json を作成します。要点は以下のとおりです。

ファイルの基本事項。 下記の事前チェックリストと ../datex-studio-conventions/universal-checklist.md に従ってください。-editor.json ファイルの形式については、references/editors.md → ファイルの場所と命名を参照してください。
埋め込み型の単一結果データソース。 各エディターは、datasources[] にプライベートな単一結果フローデータソースを ちょうど1つ 埋め込みます。必須の形状は、configurationTypeId: 6、type: "flows"、accessModifier: "private"、getFlow が設定済み、getListFlow: null、getByKeysFlow: null、resultIsCollection: false、outParams[0].isCollection: false です。コレクションを返すデータソースではエディターの参照が壊れます。リストから $editor.entity をハイドレートすることは datasourceConfig.get({...}) ではできません。references/editors.md → 埋め込みプライベートデータソースと ../datasource-creator/references/flow-datasources.md → 単一結果の形状を参照してください。デフォルトでは所有します。上書きが適用されない限りデータソースを埋め込みとして作成し、同じクエリを本当に必要とする2つ目の利用者ができた場合にのみ、独立したデータソースに昇格させます（上書き条件の全リストについては、../datasource-creator/references/datasources.md → デフォルトでは所有を参照してください）。該当する場合は、datasource-creator を呼び出して独立したバージョンを作成します。ブランチのサーバー側利用ゲートは、コントラクト検証時にこれを個別に強制します。エディターのデータソースが、コレクションではない単一結果に対する get を実装していない場合、公開をブロックします。
エンティティ形状の一致。 datasources[0].outParams[0].objectTypeDef（データソース側）は、datasourceConfig.configOutParameters.result.objectTypeDef（エディターの利用側）とフィールド単位で一致している必要があります。エンティティ形状を変更する場合は、同じ編集で 両方の箇所 を変更します。datasourceConfig の datasourceKeyDef は、埋め込みデータソースの keyDef と完全に一致し、ホストが渡す inParams の形状とも一致します。
onInitFlowConfig と onDataLoadedFlowConfig の違い。 エディターで最もよくあるバグは、この2つを取り違えることです。onInit はデータソースの解決前に実行されるため、$editor.entity は まだ設定されていません。これを読み取ると undefined が返されます。onInit は、変数の設定、isNew 時の edit_mode のデフォルト設定、エンティティデータに依存しないロジックに使用します。onDataLoaded はエンティティのハイドレート後に実行されます。エンティティに基づくデフォルト設定、編集前のスナップショットの保存、エンティティのフィールドからの UI 専用状態の設定に使用します。references/editors.md → onInitFlowConfig と onDataLoadedFlowConfig の違いを参照してください。
表示／編集モードの切り替え。 edit_mode はトップレベルの vars[] で宣言します（フローコードで書き込むすべての $editor.vars.<id> を宣言する必要があります。../component-wiring-check/references/component-wiring.md を参照してください）。編集ボタンは !edit_mode のときに表示し、保存＋キャンセルは edit_mode のときに表示します。フィールドの readOnly は !edit_mode にバインドします（または、一部のフィールドをロックしたままにする場合はフィールドごとに計算します）。キャンセル時には元のエンティティ値を復元します。データソースを再呼び出しするか、onDataLoaded 中に編集前の値を $editor.vars に保存してください。
保存処理を $editor.entity.isNew で分岐します。 新規の場合は crud_create_entity（または関数でラップした同等の作成アクション）を呼び出し、既存の場合は crud_update_entity を呼び出します。どちらの分岐もハードコードしません。UI 層の呼び出しルールが適用されます。エディターコードは $flows.<Package>.<fn> 経由で関数を呼び出し、その関数が $apis.<Package>.FootprintApi.extendedActions.<action_name>({...}) として CRUD アクションの呼び出しをラップします。../datex-studio-runtime/calling-conventions.md を参照してください。
検証によって保存ボタンを制御します。 onFormValidateFlowConfig は、フィールドが変更されるたびに実行されます。フィールドの値から is_valid を計算し（必須文字列には、多くの場合 $utils.isDefinedTrimmed を使用します）、$editor.toolbar.<save_button>.control.readOnly = !is_valid を設定します。必要に応じて、フィールドごとのメッセージを control.validationMessage に設定します。references/editors.md → onFormValidateFlowConfig による保存ボタンの制御を参照してください。
EditorFields との整合性。 プラットフォームは、バインドされたエンティティのインターフェースから EditorFields TypeScript 型を自動生成します。エディターでは、そのインターフェースにあるすべてのフィールドについて、controlConfig を持つバインディングを宣言する必要があります。ネストしたパスは __ でフラット化されます（例：replenishments.rules → フィールド ID replenishments__rules）。バインディングが欠けていると、インポートに失敗します。スキーマにフィールドが追加されたら、同じ編集でエディターにもバインディングを追加します。実際の UX がまだ用意できていない場合は、removed: true を設定したスタブバインディングでもかまいません。オブジェクト配列のサブツリーには、ボタン + $editor.vars.<var> + set_config マージパターンを使用します。references/editors.md → EditorFields ではすべてのスキーマフィールドにバインディングが必要と、ラッパーエンティティの場合はシリアライズされた設定 JSON のセクションを参照してください。
宣言的な文字列スロットにはすべて TypeScript 式のエンコードを適用します。 すべての tooltip、placeholder、value、format、ボタンの label（var にバインドされている場合）は、生成される TS にそのままインライン化されます。表示テキストはバッククォートで囲み（"`Manage rules…`"）、通常の文字列リテラルは TS の引用符で囲み（"'MM/DD/YYYY'"）、生の式はそのままにします（"$editor.vars.foo"）。引用符で囲まれていない "Manage rules." のようなツールチップは、裸の TS トークンとしてコンパイルされ、ビルドを壊します。../datex-studio-conventions/file-format.md → 宣言的な文字列値は TypeScript 式ですを参照してください。
vars / inParams / outParams にカスタム列挙型の FQN を使用しません。 エディターは、パラメーター宣言内の $types.<Package>.e_<enum> を解決できません。これらのフィールドはプリミティブ型として宣言し（文字列値の列挙型には string、数値の列挙型には number）、フローコード内の使用箇所でキャストします。
カスタマイズフックが明示的に必要な場合を除き、onCustomization* スロットは null のままにします。 これらは通常のエディター設定ではなく、カスタマイズされたオーバーレイ（tailoring-overlay）向けのプラットフォーム拡張ポイントです。
ホスト契約の監査。 このエディターをダイアログとして開くハブタブ、グリッド行のアクション、またはフォームでは、完全な configParameters 契約を宣言する必要があります。エディターが宣言するすべての inParam について、未使用のものも含め、ホスト側に value: null のエントリを用意します。プッシュする前に component-wiring-check を実行し、参照契約を監査します。../component-wiring-check/references/component-wiring.mdを参照してください。

フェーズ 4：検証してプッシュ

# Validate the body locally against the branch. Exit 1 = validation found errors
# (read validation_errors, fix body.json, re-run) — not a broken CLI. Do not push on exit 1.
dxs configuration validate editor -b <branchId> -D body.json

# For a new editor
dxs configuration upsert editor -b <branchId> -D body.json

# For modify-existing (round-trip — never skip the jq extract)
dxs configuration get editor <configId> -b <branchId> -O envelope.json
jq .json envelope.json > body.json
# ... edit body.json ...
dxs configuration upsert editor -b <branchId> -D body.json

検証では、必須フィールドの欠落、不正なパラメーター記述子の形式、EditorFields との整合性違反、参照エラーが検出されます。ただし、onInit と onDataLoaded の切り替えミス、宣言されていない $editor.vars.<id> への書き込み、引用符で囲まれていない TypeScript 式スロットは検出されません。これらは動作に関する問題であり、実行時にのみ表面化します。プッシュする前に、references/editors.md → プッシュ前チェックリストを確認してください。

フェーズ 5：Studio で確認する（任意）

通常の呼び出し経路（ハブタブのツールバーボタン、グリッド行のアクション、またはエディターにつなぐフォーム）から、エディターをダイアログとして開きます。

ハイドレーションが成功する — onDataLoaded の実行時に $editor.entity が設定され、フィールドに読み込まれた値が表示されます。
編集モードへの切り替えが機能する — 編集ボタンを押すと edit_mode = true になり、保存とキャンセルが表示され、フィールドが編集可能になります。
保存が反映される — $editor.entity.isNew に応じて正しく分岐し、ラップする CRUD アクションが成功して、ダイアログが閉じるか読み取り専用に戻ります。
キャンセルで元の値に戻る — 編集前のスナップショットが保持されるか、データソースが問題なく再取得されます。
作成モード（isNew: true）では、埋め込みデータソースが空のエンティティを生成し、保存処理が作成分岐に進みます。
onFormValidateFlowConfig が is_valid を報告するまで、保存ボタンが無効のままになります。

実行中のアプリを利用できない場合は、設定を再取得し（修正済みの jq .json 抽出パターンを使用）、body.json と差分を取ってプッシュが反映されたことを確認します。

プッシュ前チェックリスト

プッシュする前に、references/editors.md → プッシュ前チェックリストの全項目を確認します。簡易版は次のとおりです。

ファイルの基本項目。 configurationTypeId: 4、サフィックスが -editor.json、referenceName が _editor で終わること — および共通チェック（../datex-studio-conventions/universal-checklist.md）。
埋め込みデータソースが正確に 1 つ — accessModifier: "private"、type: "flows"、単一結果の形式（getFlow が設定済み、getListFlow と getByKeysFlow が null、resultIsCollection: false、outParams[0].isCollection: false）。
エンティティの形状を一致させる — datasourceConfig.configOutParameters.result.objectTypeDef の各フィールドが datasources[0].outParams[0].objectTypeDef と一致すること。datasourceKeyDef が埋め込みデータソースの keyDef およびホストの inParams の形状と一致すること。
初期化フックの分担が正しい — onInitFlowConfig で $editor.entity を読み取らないこと。エンティティに依存するデフォルト値と編集前のスナップショットは onDataLoadedFlowConfig に置くこと。
保存処理が $editor.entity.isNew に応じて分岐する — 新規の場合は crud_create_entity、既存の場合は crud_update_entity を使用すること。どちらの分岐もハードコードされていないこと。
onFormValidateFlowConfig が、フィールドの有効性に基づいて $editor.toolbar.<save>.control.readOnly を制御する。
$editor.vars が宣言されている — フローコードで書き込むすべての変数（edit_mode、スナップショット、処理中の配列）がトップレベルの vars[] に含まれていること。
EditorFields の整合性 — エンティティインターフェースの各フィールドにバインディングがあること（UX の準備ができていない場合はスタブに removed: true を設定）。オブジェクト配列のサブツリーでは、ボタン + $editor.vars + set_config のマージパターンを使用すること。
呼び出し階層への準拠 — エディターコードは $flows.<Package>.<fn> 経由で関数を呼び出すこと。その関数が $apis.<Package>.FootprintApi.extendedActions.<action_name>({...}) 経由で CRUD アクションをラップすること。エディターからアクションを直接呼び出さないこと。
TypeScript 式文字列を正しくラップする — 表示テキストはバッククォートで囲み、生の式は囲まず、通常のリテラルは引用符で囲むこと。
カスタマイズを意図していない限り、onCustomization* スロットは null にする。
vars／inParams／outParams で $types.<Package>.e_<enum> を使用しない — パラメーター層ではプリミティブ型のみを使用し、使用箇所でキャストすること。
ホストに完全な configParameters 契約を持たせる — エディターが宣言するすべての inParam にエントリーがあること。未使用のものは value: null にすること。component-wiring-check で監査します。

よくある間違い

間違い	修正方法
`onInitFlowConfig` 内で `$editor.entity` を読み取る	エンティティはまだハイドレートされていないため、`undefined` が返されます。エンティティから導出するデフォルト値と編集前のスナップショットは、`onDataLoadedFlowConfig` に移してください。
埋め込みデータソースがコレクションを返す（`resultIsCollection: true` または `outParams[0].isCollection: true`）	エディターはリストから `$editor.entity` をハイドレートできません。単一結果の形式に切り替え、`getFlow` を設定し、`getListFlow`／`getByKeysFlow` を `null` にしてください。
`datasources[0].outParams[0].objectTypeDef` と `datasourceConfig.configOutParameters.result.objectTypeDef` の内容が食い違う	エディターの参照が実行時に壊れます。両者は同じ内容を反映するため、エンティティの形状を変更する場合は両方を変更してください。
保存先が `crud_update_entity`（または `crud_create_entity`）にハードコードされている	もう一方のモードで動作しなくなります。`$editor.entity.isNew` に基づいて分岐してください。
フローコードで `$editor.vars.edit_mode = true` を設定しているが、トップレベルの `vars[]` で `edit_mode` を宣言していない	変数が未宣言のため、書き込みが無言で失敗するか、実行時エラーになります。すべての変数を宣言してください。
新しいスキーマフィールドのバインディングがない	`EditorFields` の型エラーが発生します。`Property 'foo__bar' is missing... but required in type 'EditorFields'`。同じ編集内でバインディングを追加してください。UX の準備ができていない場合は、`removed: true` を指定したスタブにしてください。
エンティティがシリアライズ済み設定のラッパーであるにもかかわらず、`$editor.entity.<field>` を直接変更する	型エラーになります。`entity` が公開するのは解析済み設定ではなくラッパーです。`set_state` 内で `JSON.parse($editor.entity.config)` を使って解析し、`set_config` で再構成してから、CRUD アクション経由で `$editor.vars.new_config` を送信してください。
オブジェクトの配列であるサブツリーを、フラットなフィールドバインディングとして記述する	`id__path` によるフラット化は配列に適しません。ボタン＋`$editor.vars.<array_var>`＋`set_config` でマージするパターンを使ってください（または、上級者向けの管理ツールには `codeBox` を使ってください）。
エディターコードからアクションを直接呼び出す	UI 層のルールでは、エディターから呼び出せるのは関数だけです。関数内で `$apis.<Package>.FootprintApi.extendedActions.<action_name>({...})` を使ってアクションをラップしてください。
宣言的文字列のスロットがラップされていない（"`Manage rules.`" ではなく `"Manage rules."`）	生成された TS にそのままインライン展開されるため、裸のトークンはビルドを壊します。表示テキストにはバッククォート、プレーンなリテラルには引用符、式にはラップなしを使用してください。
`vars`／`inParams`／`outParams` 内で `$types.<Package>.e_<enum>` を使う	パラメーター層ではカスタム列挙型の FQN を解決できません。プリミティブ型（`string`／`number`）として宣言し、フローコード内で使用するときにキャストしてください。
`datasourceConfig.configOutParameters` をパラメーター名をキーとするオブジェクト（`{"result": {...}}`）として記述する	これは埋め込みデータソースの `outParams` を反映するパラメーター記述子の配列です。`[{"id":"result","type":"object","objectTypeDef":[...],"isCollection":false}]` のように記述してください。オブジェクト形式は検証に失敗し、フィールド名を示さない生の `Cannot deserialize ... into type 'IList<VarConfig>'` ダンプが出力されます。
埋め込みデータソースの `datasourceConfig` に `isOwned: true` がない	参照先を別アプリケーションから検索せずに、埋め込みの `datasources[]` に解決するための条件は `isOwned` だけです。これがない場合、プラットフォームは他のアプリケーションで `configId` と `moduleId` を検索し、失敗すると `Invalid contract. Referenced configuration <name> does not exist or has been renamed` を報告します。`isOwned: true` を設定してください。`moduleId` を削除しても解決しません。所有された参照では `moduleId` は読み取られません。../datasource-creator/references/datasources.md → 所有された参照の解決を参照してください。
埋め込みデータソースに `hasKey`／`hasResult`／`queryOptionsObjectTypeDef` がない	3つすべてが必須です。`queryOptionsObjectTypeDef` はエンティティの形状（`outParams[0].objectTypeDef` と同じ配列）を繰り返し定義するもので、エンティティ形状を定義する5番目の箇所です。最も見落とされやすい箇所でもあります。これを省略すると、診断情報のない `Entity definition is required` というメッセージがそのまま表示され、処理に失敗します。
`dxs configuration get -O envelope.json` の出力を、そのまま `dxs configuration upsert -D envelope.json` に渡す	設定内容が無言で破損します。編集前に必ず `jq .json envelope.json > body.json` を実行してください。上記の「往復ルール」を参照してください。
`description` が100文字を超えている	SQL の列の上限を超えるため、プッシュ時の検証に失敗します。短くしてください。
`referenceName` が `_editor` で終わっていない、またはファイル名のベース名と一致しない	インポート／検索が失敗します。スネークケースを使い、`_editor` サフィックスを付け、ファイル名のベース名と一致させてください。
ホスト側の参照に指定された `moduleId` が、エディターではなくホストのパッケージを指している	コンポーネント間参照のルールでは、`moduleId` は常に参照先のパッケージを指定します。`../component-wiring-check/references/component-wiring.md` を参照してください。
編集後、`post-edit-verification` を実行して、説明文／JSON／スキーマの違反を検出してください。最終確認では、`component-validator` を実行してください。

Markdown 対応

ログインしてコメント

基本情報

作者: datex
リポジトリ: datex/skills
カテゴリ: 開発
インストール数: 92

問題を報告