type-definition-creator

型定義の作成

ブランチ上で Datex Studio の型定義（configurationTypeId=22）を作成または変更します。これは、インターフェース（i_<name>）または列挙型（e_<name>）のいずれかを宣言する -customType.json ファイルです。どちらも同じコンポーネント型に属し、同じサフィックスを使用しますが、内部の構造は大きく異なります。型定義はプラットフォーム全体で使用されます。たとえば、フローの inParams／outParams、データソースの objectTypeDef、ほかの型定義、および（重要な制約が1つありますが）UI コンポーネントのパラメーターで使用されます。

参考資料

• ../datex-studio-shared/branch-setup.md — ブランチ／接続の選択（各スキルで共通）
• ../datex-studio-shared/context-navigation.md#discovering-custom-types-and-enum-members — dxs configuration nomenclature -b <id>（必要に応じて --package／--kind／--search を指定）：ブランチ上のすべての <Package>.<Type>（および各列挙型のメンバー）を一覧表示する、簡潔でフラットなカタログです。本文全体を取得せずに、型／列挙型がすでに存在するかどうかを確認し、正確な referenceName とメンバー名を把握するため、作成前に実行してください。
• references/type-definitions.md — 型定義に関する正式なリファレンス：ファイル構造、インターフェースの6種類のプロパティ記述子、列挙型の2種類の値記述子、自己参照の禁止とインライン化による深度制限への対処方法、UI コンポーネントにおける列挙型 FQN の制約とプリミティブ型＋キャストによる対処方法、型を厳格化すると利用側にも影響が波及するルール
• ../datex-studio-conventions/file-format.md — configurationTypeId の一覧表、JSON ファイルの配置場所
• ../datex-studio-conventions/naming-conventions.md — i_*／e_* のプレフィックス規則、-customType.json サフィックス、ファイル名のベース部分との一致
• ../datex-studio-conventions/defaults.md — accessModifier のデフォルト値（インターフェースと列挙型では明示的な選択が必要です。ゼロから作成する場合はユーザーに確認してください）

依存関係

• requirements-gathering スキル — 会話のコンテキストに要件概要がまだない場合、その作成のために呼び出されます
• impact-analysis スキル — 使用中の既存の型を厳格化する編集を行う前に、必ず呼び出されます。対象となる変更は、必須フィールドの追加、オプション項目の削除、プロパティを汎用の object から特定の構造に絞り込むこと、objectTypeDef を null から厳格な定義に書き換えること、プロパティ名の変更、型そのものの削除です。追跡対象は型の FQN（<Package>.<referenceName>）です。緩い構造を参照し、新しい構造で宣言されていないプロパティにアクセスしていた利用側はすべて、プラットフォームの厳格チェックでエラーになります。新規作成の型では、この手順は不要です

CLI のライフサイクル

型定義の作成には dxs configuration を使用します。これは、プラットフォームのあらゆる構成型に対応する汎用 CRUD プリミティブです。dxs customtype サブコマンドやフィールド単位のパッチ適用機能はありません。JSON 本文全体を構築する（または取得して抽出する）かたちで編集し、全体を再度プッシュします。CLI での型識別子は customtype（小文字。ConfigurationEndpoints.normalize_type の出力と一致）で、これは configurationTypeId: 22 に対応します。インターフェース（i_<name>）と列挙型（e_<name>）は、どちらも同じコンポーネント型を共有します。内部の type フィールド（"interface" または "enum"）で区別します。

新しい型定義を作成する場合：

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

既存の型定義を編集する場合：

# 1. Fetch — note the envelope wrapper
dxs configuration get customtype <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 customtype -b <branchId> -D body.json
# 5. Push
dxs configuration upsert customtype -b <branchId> -D body.json

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

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

型定義の本体は、他の設定タイプと比べて非常に簡素です。inParams ／ outParams ／ vars ／ events ／ flows のコンテンツスロットはありません（すべて null のままです）。本体は基本的に、コンポーネント識別情報のエンベロープに、インターフェースの場合は objectTypeDef[]、列挙型の場合は enumTypeDef[] のいずれかを加えたものです。ラウンドトリップの手順（取得 → jq で抽出 → 編集 → 検証 → プッシュ）は引き続き適用されます。本文のサイズにかかわらず、プラットフォームのインポート処理ではエンベロープを考慮した更新がすべて実行されます。型定義ファイルは、ディスク上では単一行の最小化された JSONでもあります（他のコンポーネントファイルとは異なるため、整形しないでください）。

ワークフロー

[Phase 1: Setup + Requirements]
Follow branch-setup.md for branch/connection selection
        |
[requirements brief in context?]
  +-----+-----+
  |            |
 YES          NO -> invoke `requirements-gathering`
  |            |
  +-----+------+
        |
[Phase 2: Decide interface vs enum vs nested]
Consult references/type-definitions.md:
  - shared shape that multiple components reference
    -> interface (i_<name>) — objectTypeDef[] with property
       descriptors; type:"interface"; enumTypeDef:null;
       isStringValue:null
  - fixed set of named values (string-valued kebab-case or
    number-valued stringified integer)
    -> enum (e_<name>) — enumTypeDef[] with value descriptors;
       type:"enum"; objectTypeDef:[] (empty array, NOT null);
       isStringValue:true (string) OR null (number)
  - anonymous nested structure used only inside one parent
    type, no separate FQN
    -> nested inline object on the parent's objectTypeDef[]
       (no separate -customType.json file)
        |
[Phase 3: Author type body]
Build body.json (single-line minified):
  - File basics: suffix -customType.json, configurationTypeId 22,
    referenceName and title both equal filename stem, description
    <= 100 chars, accessModifier set (confirmed with user)
  - Interface body: objectTypeDef[] array of property descriptors,
    each carrying id / type / isCollection / required / objectType /
    isSecured; the six property shapes (scalar, array of primitives,
    inline object, FQN reference, union, object collection)
  - Enum body: enumTypeDef[] array of value descriptors; ProperCase
    ids, kebab-case values by default for string-valued; number-valued
    entries carry description:null
  - References use FQN ("<Package>.<referenceName>") — never the
    referenceName alone
  - Self-reference prohibition: custom types cannot reference
    themselves by FQN — inline to a fixed maximum depth matching
    the producing engine's recursion cap; maintain via a generator
    script alongside the file
  - UI-component enum FQN constraint: if this type (or an enum from
    this package) will be used inside vars/inParams/outParams of an
    editor/form/selector/hub/grid, do NOT declare it as
    objectType:"<Package>.e_<enum>" in those param descriptors —
    declare as the underlying primitive and cast at use time;
    flow-tier components and other custom-type files can reference
    enums via FQN freely
  - Sibling slots stay null: inParams, outParams, vars, events all
    null — type definitions have no code strings of their own
        |
[Phase 4: Validate + push]
dxs configuration validate customtype -b <branchId> -D body.json
        |
   +----+----+
   |         |
  CREATE   MODIFY-EXISTING
   |         |
   |         use the corrected round-trip
   |         (get -O envelope -> jq .json -> body)
   |         |
   +----+----+
        |
        v
dxs configuration upsert customtype -b <branchId> -D body.json
   (upsert creates or updates by referenceName — one command for both)
        |
[Phase 5: (Optional) Impact analysis if tightening or removing]
For tightening edits on an existing type (adding required fields,
removing optionals, narrowing object -> specific shape, rewriting
objectTypeDef null -> strict, renames, removal), invoke the
`impact-analysis` skill with target <Package>.<referenceName>
to enumerate every reference site and audit each one against the
new shape. Net-new types skip this step.
        |
[invoke `post-edit-verification`; then `component-validator`]

フェーズの詳細

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

1. ブランチと接続の選択については、../datex-studio-shared/branch-setup.md に従ってください。ブランチ ID を決して決めつけず、ユーザーに確認してください。
2. 会話のコンテキストに要件の概要（requirements-gathering または別の呼び出し元スキルによって作成されたもの）がすでに存在するか確認してください。
   • 概要がある場合 — それを使用してください。概要には、その型が表すもの（複数のコンポーネントで共有するデータ構造、固定値の集合、または単一の親型に属する名前のないネスト構造）、それを参照するコンシューマー（フローパラメーター、データソースの構造、UI コンポーネント）、および accessModifier を public と private のどちらにするかが記載されている必要があります。
   • 概要がない場合 — まず requirements-gathering スキルを呼び出してください。インターフェース、列挙型、ネスト構造のどれにするかを最初に適切に決めておけば、コンシューマーがすでに参照を組み込んだ後に型を再構成せずに済みます。

フェーズ 2：インターフェース、列挙型、ネスト構造の選択

作成前に references/type-definitions.md を参照してください。この選択によって本体の構造が決まります。

インターフェース（i_<name>）— 複数のコンポーネントが参照する共有の構造です。type: "interface" を指定し、プロパティ記述子を含む objectTypeDef[] を本体とします。同じ構造が 2 か所以上（フローの inParams、データソースの outParams[].objectTypeDef、別のインターフェースのネスト参照など）に現れ、定義を一元化することで不整合を防げる場合に使用します。

列挙型（e_<name>）— 名前付きの値を固定した集合です。type: "enum" を指定し、値の記述子を含む enumTypeDef[] を本体とします。文字列値の列挙型には isStringValue: true を指定します（既定の value はケバブケースです）。数値値の列挙型には isStringValue: null を指定します（false ではありません）。各エントリーでは整数を文字列化した value と description: null を使用します。呼び出し元で、参照可能な定数を持つ選択肢の固定集合が必要な場合に使用します。

名前のないインラインネストオブジェクト — 構造が単一の親型の中にのみ存在し、独立した識別情報を持たない場合は、親の objectTypeDef[] に type: "object" のプロパティ記述子としてインラインで記述し、子の記述子を含むネストした objectTypeDef[] を指定します。個別の -customType.json ファイルは作成しません。構造が共有されず、名前を付けても利点がない場合に使用します。

判断に迷う場合は、次のように考えてください。「複数のコンポーネントが、同じ構造を名前で参照するか？」はい → インターフェースです。「構造は選択肢を固定した一覧にすぎないか？」はい → 列挙型です。それ以外 → インラインのネスト構造です。references/type-definitions.md → インターフェース、references/type-definitions.md → 列挙型を参照してください。

フェーズ 3：型本体の作成

スケルトンは references/type-definitions.md → Interfaces と → Enums を参考にして、body.json（1 行の最小化された JSON。整形しないでください）を作成します。重要な点：

1. ファイルの基本事項。 下記の 事前チェックリスト と ../datex-studio-conventions/universal-checklist.md に記載された -customType.json ファイルの形式に従います。作成時の型固有の設定として、accessModifier は "public" または "private" です。新規作成時は、どちらにするかユーザーに確認してください（共通チェックリストでは既定値を public としていますが、カスタム型では private が適していることがよくあります）。

2. インターフェースの本体。 トップレベルの定数：type: "interface"、baseTypes: null（現時点では継承をサポートしていません）、enumTypeDef: null、isStringValue: null、inParams: null、outParams: null、vars: null、events: null。本体は objectTypeDef[]（プロパティ記述子の配列）です。すべてのプロパティ（トップレベルおよびインラインオブジェクト内のネストされたもの）には、id / type / isCollection / required / objectType / isSecured: false を指定します。6 種類のプロパティ形式（スカラーのプリミティブ型、プリミティブ型の配列、インラインオブジェクト、別のインターフェースまたは列挙型への FQN 参照、oneOf[] を使ったユニオン、オブジェクトコレクション）については、references/type-definitions.md → Interfaces を参照してください。

3. 列挙型の本体。 トップレベルの定数：type: "enum"、objectTypeDef: []（空の配列。null ではありません）、baseTypes: null、inParams: null、outParams: null、vars: null、events: null。ファイルごとの設定：文字列値の列挙型では isStringValue: true、数値値の列挙型では isStringValue: null（false ではありません）。enumTypeDef[] は値記述子の配列です。値記述子の命名規則：id（参照キー）はスペースを含まない ProperCase にします（例：RoyalBlue、ForestGreen）。文字列値の列挙型の value は、特にユーザーから指定がない限り、既定で kebab-case にします（例：royal-blue、forest-green）。数値値の項目には、文字列化した整数（例："value":"0"）と description: null を指定します。

4. 参照には FQN を使います。 objectType は "<Package>.<referenceName>" です。referenceName のみではありません。インターフェース参照（"Allocations.i_preallocation_action"）と列挙型参照（"Allocations.e_allocation_replenishment_context"）は、どちらもこの形式に従います。インターフェース内で列挙型を参照する場合も、インターフェース参照と同じ {type:"object", objectType:"<Package>.<enum_referenceName>", ...} 形式を使います（列挙型の実行時の値は文字列型または数値型ですが、スキーマレベルの参照では type:"object" を使います）。

5. 自己参照はできません。 カスタム型から自身を再帰的に参照することはできません。objectType: "<Package>.<this_type>" による再帰の経路はありません。ツリーなど、任意の深さの children を含む子要素が必要な型では、構造を一定の最大深度まで インライン化 し、各階層でプロパティ記述子一式を繰り返します。ツリーを生成するエンジンに再帰の上限がある場合は、その上限に合わせて型のインライン化の深度を設定し、エンジンが出力可能なすべての値を型に適合させます。インライン化した各コピーは、ファイルとともに置くジェネレータースクリプトで管理してください。ある階層だけを手作業で編集し、ほかの階層を編集しないのは欠陥です。references/type-definitions.md → Custom Types Cannot Self-Reference を参照してください。

6. UI コンポーネントの enum FQN 制約。 UI コンポーネント（エディター、フォーム、セレクター、ハブ、グリッド）の vars、inParams、outParams では、プロパティ記述子に objectType: "<Package>.e_<enum>" の参照を使用できません。UI コンポーネントのパラメーター宣言に対するプラットフォームの TS 検証パスでは、カスタムの $types.* 名前空間が解決されないため、Cannot find namespace '_types'. Did you mean 'Type'? が発生します（_types トークンは、プラットフォームが $types を _types に書き換えることで生じるものです）。回避策：フィールドを基になるプリミティブ型（文字列値の enum なら string、数値なら number）として宣言し、フローコード内の使用箇所でキャストします（const v = $form.fields.x.control.value as $types.<Package>.e_<enum>;）。この制約が適用されるのは UI コンポーネントのみです。フローティアのコンポーネント（アクション、関数、フローデータソース）とカスタム型ファイル自体では、objectType: "<Package>.e_<enum>" の参照を自由に宣言できます。references/type-definitions.md → UI Components Cannot Reference Custom Enums in vars / inParams / outParams を参照してください。

7. 兄弟スロットは null のままにします。 型定義本体では、inParams、outParams、vars、events は常に null です。型定義には独自のコード文字列がありません。コードスロットを作らず、規約に従ってください。

フェーズ 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 customtype -b <branchId> -D body.json

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

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

検証では、必須フィールドの不足、プロパティ記述子または値記述子の形式の誤り、構造上のエラーをプッシュ前に検出します。ただし、自己参照の禁止（コンシューマーのコンパイル時に型ローダーの失敗として発生）、UI コンポーネントの enum FQN 制約（使用する UI コンポーネントで Cannot find namespace '_types' として発生）、またはコンシューマーへの変更の波及（以前は暗黙の any が適用されていたすべての参照箇所で、厳格なパスの型エラーとして発生）は検出しません。プッシュ前に、これらの問題を扱う references/type-definitions.md の各セクションを確認してください。

フェーズ 5：（任意）型を厳格化または削除する場合の影響分析

新規追加の型では、まだその型を参照するものがないため、このフェーズをスキップします。

すでに使用されている既存の型では、以下のいずれかがコンシューマーに波及する厳格化編集に該当します。

• 以前のパッチでは含まれていなかった必須フィールドを追加する。
• コンシューマーがまだ読み取る可能性のある任意フィールドを削除する。
• プロパティを汎用の type: "object" から、特定の FQN 参照または厳密なインライン形式に絞り込む。
• objectTypeDef を null（オープン形式）から、記述子の厳密な配列に書き換える。
• プロパティ名を変更する。古い名前にアクセスするすべてのコンシューマーが動作しなくなります。
• 型を完全に削除する。FQN を参照するすべての箇所が動作しなくなります。

これらのいずれかに該当する場合は、プッシュ前に対象を <Package>.<referenceName>（型の FQN）として impact-analysis スキルを呼び出してください。このスキルでは、コードベース全体からすべての参照箇所（フローの inParams / outParams、データソースの objectTypeDef、その他の型定義、objectType 参照を含む UI コンポーネントのパラメーター）が列挙されるため、同じ編集内で各箇所を新しい形式に照らして確認できます。以前は暗黙の any が適用され、新しい型で宣言されていないフィールドを読み取っていたコードは、プラットフォームの厳格なパスで動作しなくなります。親エージェントから呼び出し元をインラインで grep しないでください。複数ファイルのスキャンは専用スキルの役割です。references/type-definitions.md → Tightening a Previously-Loose Type Ripples to Consumers を参照してください。

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

プッシュする前に、references/type-definitions.mdの本文全体を確認してください。簡易版は次のとおりです。

1. ファイルの基本事項。 ファイル名の末尾が-customType.jsonであること、configurationTypeId: 22であること、新しいファイルではaccessModifierをユーザーに確認済みであることに加え、共通チェック（../datex-studio-conventions/universal-checklist.md）も確認します。
2. 型の区別が正しい。 インターフェースではtype: "interface"、enumTypeDef: null、isStringValue: null、objectTypeDef: [...]を使用します。列挙型ではtype: "enum"、objectTypeDef: []（空配列。nullではありません）、enumTypeDef: [...]、isStringValue: trueまたはnull（falseは不可）を使用します。
3. プロパティ記述子がすべてそろっている。 objectTypeDefの各エントリー（トップレベルおよびネストされたもの）に、id、type、isCollection、required、objectType、isSecuredがあります。インラインオブジェクトにはobjectTypeDefを、FQN参照にはobjectTypeを、ユニオンにはoneOf[]を指定します。
4. 列挙型のidはスペースのないProperCaseです。 valueは指定された大文字・小文字の形式に従います（文字列値の場合、デフォルトはケバブケースです）。数値値のエントリーには、文字列化した整数とdescription: nullを指定します。
5. 参照にはFQNを使用します。 objectTypeは"<Package>.<referenceName>"とします。referenceNameのみにはしません。
6. idのプレースホルダー。 作成時のid: 0は、ユーザーまたはインポート処理によって実際の値が割り当てられます。
7. 自己参照は使用しません。 型が自身をネストした子を必要とする場合は、生成元エンジンの再帰上限に合わせて固定の最大深度までインライン化し、ジェネレータースクリプトで維持します。
8. UIコンポーネントの列挙型FQN制約を守ります。 この型（またはこのパッケージの列挙型）を、エディター、フォーム、セレクター、ハブ、グリッドのvars、inParams、outParams内で使用する場合、それらの宣言にobjectType: "<Package>.e_<enum>"を記述しないでください。基になるプリミティブ型として宣言し、使用時にキャストします。
9. 兄弟スロットはnullのままにします。 inParams、outParams、vars、eventsはすべてnullのままにします。型定義自体にはコード文字列がありません。
10. 型の変更を厳格化する場合は、影響分析が必須です。 使用中の型に必須フィールドを追加する、任意フィールドを削除する、プロパティの範囲を狭める、objectTypeDefをnullから厳密な定義に変更する、プロパティ名を変更する、または型を削除する場合は、プッシュ前にその型のFQNに対してimpact-analysisスキルを実行します。新規型にはこの手順は不要です。

よくある間違い

間違い	修正方法
数値列挙型の isStringValue を null ではなく false に設定している	プラットフォームでは false と null は異なるものとして扱われます。数値列挙型には null が必要です（各エントリーには description: null と、整数を文字列化した value を設定します）。isStringValue: null を正確に設定してください。
列挙型の objectTypeDef を [] ではなく null に設定している	列挙型には objectTypeDef: []（空の配列）を使用します。null はインターフェースで使う形式です。プラットフォームのローダーはこのフィールドによって2つの形式を区別するため、null に設定すると列挙型の形式が崩れます。
列挙型の id にスペースや ProperCase 以外の文字が含まれている	id にスペースは使用できません。ProperCase を使用してください（例：RoyalBlue、ForestGreen）。
プロパティ記述子に isSecured: false がない	すべてのプロパティ（トップレベルとネストされたものの両方）に isSecured を設定します。各記述子に含め、セキュアプロパティ用の形式を使わない場合は false をデフォルトとして設定してください。
FQN ではなく、単なる referenceName を objectType に設定している	参照には "<Package>.<referenceName>" を使用します。i_thing や e_thing だけでは不十分です。プラットフォームは FQN で解決するため、名前だけでは解決できません。
自己参照（objectType: "<Package>.<this_type>" による再帰）を試みている	カスタム型は自身を参照できません。生成エンジンの再帰上限に合わせた固定の最大深度まで、ネストされた形状をインライン化してください。インライン化したコピーはジェネレータースクリプトで管理します。references/type-definitions.md → カスタム型は自己参照できませんを参照してください。
vars／inParams／outParams 内で objectType: "<Package>.e_<enum>" により列挙型を参照する UI コンポーネントで、Cannot find namespace '_types' エラーが発生する	UI コンポーネントのパラメーター宣言では、列挙型の FQN 参照を使用できません。基になるプリミティブ型（文字列値の列挙型には string、数値列挙型には number）として宣言し、フローコード内の使用箇所で as $types.<Package>.e_<enum> にキャストしてください。フローティアのコンポーネントやその他のカスタム型ファイルでは、列挙型を自由に参照できます。
影響分析を実行せずに使用中の型を厳格化したため、コンシューマーが strict-pass で失敗する	以前は暗黙の any を取得して新しい型に宣言されていないフィールドを読み取っていたコードは、プラットフォームの strict pass で失敗します。厳格化を元に戻し、その型の FQN に対して impact-analysis スキルを実行し、すべての参照箇所を監査したうえで、厳格化と同じ編集内ですべて更新してください。
使用中の型のプロパティ名を変更したが、コンシューマーを更新していない	古い名前を参照するすべての箇所で失敗します。まず <Package>.<referenceName> に対して impact-analysis スキルを実行し、同じ編集内ですべての該当箇所を更新してください。
JSON ファイルを整形した	型定義ファイルはディスク上では1行の最小化された JSONです。他のコンポーネントファイルとは異なり、この形式を使用します。整形しないでください。インポート処理では最小化された形式が想定されています。
類似の JSON を読んで、数値列挙型の isStringValue を明示的に false と推測した	規則は、文字列値の場合は true、数値の場合は null です。false は誤りです。
インターフェースのトップレベルの objectTypeDef を、開いた形状にするつもりで null として宣言した	インターフェースでは objectTypeDef: [...]（記述子の配列）を使用します。null 形式はインターフェースの enumTypeDef スロットであり、主要な本体ではありません。
description が100文字を超えている	SQL の列制限により、プッシュ時の検証に失敗します。短くしてください。
dxs configuration get -O envelope.json の出力を dxs configuration upsert -D envelope.json に直接パイプしている	設定内容が通知なく破壊されます。編集する前に、必ず jq .json envelope.json > body.json を実行してください。上記の「ラウンドトリップ規則」を参照してください。

編集後に post-edit-verification を実行して、説明文／JSON／スキーマ違反を検出してください。最終レビューでは component-validator を実行してください。