setup-datamodel

プラグインの確認：node "${PLUGIN_ROOT}/scripts/check-version.js" を実行します。メッセージが出力された場合は、続行する前にユーザーに提示してください。

📋 共通の指示：shared-instructions.md — まずお読みください。

データモデルとコネクタのセットアップ

エントリールーティング： 以下のワークフローを始める前に、共通の アプリ機能のエントリーポイント の事前確認を使用してください。

呼び出しスコープ： プロジェクトの読み取りや以下のワークフローを始める前に、データソースの呼び出しスコープ に従ってください。

この独立したデータ専用ワークフローでは、アプリ全体の計画は必要ありません。 現在のスキーマ／コネクタの差分のみを提案して承認を得ます。アプリ全体の計画や画面の生成は実行せず、既存のアプリセクションを維持してください。 オーナーから呼び出された場合は、明示された現在のリクエスト、絶対パスのルート、フェーズ、スコープを保持し、提案または検証済みの結果をそのオーナーに返してください。

独立したデータソース計画用の統合オーケストレーターです。Dataverse スキーマを設計し、コネクタを計画して、両方の承認を得た後、実行を /add-dataverse と /add-connector に委任します。

次の場合はこのスキルを使用	次の場合は /add-dataverse を直接使用
独立したスキーマとコネクタの設計（初期化済みアプリ。データ計画は任意）	計画がすでに存在し、テーブルの適用とサービスの生成のみが必要
インポートする既存の ER 図（画像／Mermaid／テキスト）がある	/create-mobile-app が承認済みのスコープ付きコンテキストでサブステップとして呼び出している
プロジェクト途中でスキーマまたはコネクタを再計画する	追加するテーブルが 1 つ、またはコネクタが 1 つのみ

ワークフロー

1. プロジェクトルートの解決と認証の確認 → 2. データモデルの設計 → 3. コネクタの計画 → 4. 統合承認 → 5. 追加／更新の実行 → 6. コネクタの実行 → 6.25 承認済みバインディングの廃止 → 6.5 オフラインプロファイルの調整 → 7. インベントリの調整と要約

---

フェーズ 1 — プロジェクトと認証の確認

プロジェクトファイルの読み取りや環境の検出を行う前に、絶対パスの working_dir を 1 つ解決してください。

• ネストされた呼び出しの場合、オーナーの絶対パス working_dir を引き継ぎます。--working-dir も指定されている場合は、両方が同じディレクトリを指す必要があります。一致しない場合は、プロジェクトやクラウドの処理を行う前に NEEDS_CONTEXT を返します。
• 直接呼び出す場合は、明示された --working-dir を呼び出し元のディレクトリを基準に解決します。オーバーライドのない直接呼び出しに限り、その呼び出し元のディレクトリをプロジェクトルートとして使用できます。
• 選択したディレクトリが存在することを確認し、単一の絶対パスに正規化して、この呼び出しの間保持します。ネストされた呼び出しでオーナーのパスが見つからない場合はエラーです。シェルの現在のディレクトリにフォールバックしたり、近隣のアプリを検索したりしないでください。

以下に示す diagram 入力、native-app-plan.md、_dm_section.md、.datamodel-manifest.json、offline-profile.json、memory-bank.md を含む、すべての相対アプリパスは、後続のツールの cwd ではなく、解決済みのルートを基準とします。ファイルツールでは絶対パスを使用してください。アプリ内ファイルを読み書きするすべてのシェル呼び出しは、単一引用符で囲んだ fail-closed のアプリルートガードから開始してください。シェルの状態はツール呼び出しをまたいで引き継がれません。

選択したルートが Power Apps モバイルアプリであることを確認してください。

--plan-only または計画フェーズからの引き継ぎの場合、ファイルと環境の確認は読み取り専用で行い、共通の提案専用環境コンテキストルールを使用してください。通常の呼び出しでも、承認の前に同じ非永続的な検索を使用します。コンテキストが不完全または矛盾している場合は、読み取り専用の復旧を行った後に NEEDS_CONTEXT を返してください。安全フラグなしで再試行したり、アプリ構成にリダイレクトしたりしないでください。

cd -- '<working_dir>' || { echo "BLOCKED: cannot enter working_dir" >&2; exit 1; }
if [ ! -f power.config.json ] || [ ! -f app.config.js ]; then
  printf '%s\n' 'ERROR: selected working directory is not an initialized mobile app' >&2
  exit 1
fi
environment_id="$(node -p "require('./power.config.json').environmentId || ''")" || exit 1
if [ -z "$environment_id" ]; then
  printf '%s\n' 'ERROR: selected app has no environmentId' >&2
  exit 1
fi
node "${PLUGIN_ROOT}/scripts/resolve-environment.js" "$environment_id" --no-cache --require-tenant

失敗した場合は停止してください。ディレクトリを切り替えたり、再スキャフォールドしたりしないでください。フェーズ 5 で使用するため、このルートの 環境 URL、環境 ID、テナント ID を取得してください。すべてのプランナー／スキルへの引き継ぎと再試行で、同じ絶対パスのルートを渡してください。

フェーズ 2 — データモデルの設計

テレメトリのチェックポイント：design_dataverse_schema

まず、リクエストに Dataverse スキーマが必要か確認します。コネクタのみのリクエストは Path C に進みます。それ以外の場合は、図のヒント（*.png、*.jpg、erDiagram、||--o{）がないか $ARGUMENTS を確認します。ヒントがあれば Path A に進みます。Dataverse の要件がすでに提示されている場合は、読み取り専用の提案を行う Path B に進みます。選択がまだ不明な場合は、次のように質問します。

「データモデルをどのように定義しますか？」

オプション	内容
既存の ER 図をアップロードする	PNG/JPG のパス、Mermaid ブロック、またはテキストによる説明を提示します
データモデルアーキテクトに提案してもらう（デフォルト）	data-model-architect エージェントを起動し、要件から推測します
スキップ — Dataverse テーブルは不要	フェーズ 3 に進みます

Dataverse スキーマが必要な場合に限り、「アーキテクトに提案してもらう」を推奨します。コネクタのみの要件は、Dataverse テーブルを作り出さずに Path C に進みます。空の入力やキャンセルは選択の承認にはなりません。回答を待つか、停止してください。

Path A と Path B では、 dataverse-change-planning.md を読み、実行してください。 前景の処理が、対象を絞った調査、簡潔なエビデンスの検証、復旧を担当します。アーキテクトには Dataverse planning mode: required を渡し、従来のライブ調査パスは使わないでください。引き継ぎのたびに、現在のリクエスト、絶対パスのルート、提案のみのモードを維持してください。Path C、削除のみの作業、保持サービスのみの更新では、スキーマ計画とその成果物を省略します。

PDF と署名の成果物の保存ルール

要件に署名、承認、インク、図面、生成 PDF、エクスポートされたレポート、エビデンスパケット、または保持文書が含まれる場合は、承認前に保存先を ## Data Model で明示してください。

ユーザーの意図	Dataverse モデルへの影響
「署名を取得する」、「承認する」、「承認署名」、「インク」	保持が必要か確認します。Dataverse での保持が選択された場合に限り、Image/File 列または子 Evidence/Signature テーブルを再利用または提案します
「PDF を生成する」、「レポートをエクスポートする」、「エビデンスパケット」、「証明書 PDF」	生成した PDF を保持するか確認します。保持する場合は、通常、親レコードまたは子 Evidence/Attachment テーブルに Dataverse File 列を使用します。保持しない場合は、デバイス上のみ／共有のみの動作を記載し、列は追加しません。
「PDF をアップロードする」、「ファイルを添付する」、「文書をインポートする」	親へのルックアップを持つ File 列または子 Attachment テーブルを使用します
「PDF を表示する」	アプリに永続的なソースがある場合は、HTTPS URL を保存または参照します。ネイティブ PDF ビューアー 0.2.9+ はローカルの file:// URI もサポートしますが、content://、blob:、http:// は引き続きサポートされません。

PDF の内容を長文テキストや base64 テキストとしてモデル化してはいけません。保持する PDF には Dataverse File 列を使用してください。生成サービスが画像ペイロードに対応している場合、署名 PNG には Image 列を使用できます。添付ファイルとして扱う必要がある場合は、File 列または子 Evidence 行を使用してください。

Path A — ユーザー提供の図を解析する

PNG/JPG（表示には Read を使用）、Mermaid 構文（チャットに貼り付け）、またはテキストによる説明を受け付けます。テーブル、列、リレーションシップを、意図された内容として解析します。共有の簡潔なエビデンスワークフローを使用して _dm_section.md と正規化された .tmp/dataverse-schema-contract.json を作成します。図の名前だけでは、既存のスキーマの証拠になりません。統合されたフェーズ 4 の承認前に、Path B と同じ判断検証を実行してください。まだライブプランは更新しないでください。

Path B — data-model-architect を起動する

Task: mobile-app:data-model-architect

Prompt:
  You are the data-model-architect agent for a Power Apps mobile app.
  Requirements: <$ARGUMENTS or ask the user what the app does>
  Working directory: <working_dir>
  Output proposal: <working_dir>/_dm_section.md
  Plugin root: ${PLUGIN_ROOT}
  Phase: planning
  Proposal only: <true for --plan-only or a planning-phase caller>
  Dataverse planning mode: required
  Normalized Dataverse foreground planning snapshot (validator input only): <SNAPSHOT_PATH>
  Compact Dataverse architect evidence: <ARCHITECT_EVIDENCE_PATH>
  Structured schema contract output: <working_dir>/.tmp/dataverse-schema-contract.json
  Scope: <current requested delta and necessary dependencies; unrelated rows are context only>
  Native capabilities and connector ownership: <retained approved constraints>

  Follow your snapshot-only path. Return a ## Data Model section with Mermaid ER diagram,
  reuse/extend/create table, and dependency-tier ordering. If requirements mention
  signatures, pen/ink, generated PDFs, report exports, evidence packets, or uploaded
  documents, include the artifact storage target: on-device/share-only, Dataverse
  Image column, Dataverse File column, or child Evidence/Attachment table. Retained
  PDF content must use a File column, not long text/base64.

構造化された Dataverse のシグナルは、汎用の AGENTS.md 戻りプロトコルより先に、共有の計画復旧プロセスで処理してください。セクションと正規化されたコントラクトの両方を必須とし、DONE／DONE_WITH_CONCERNS の場合も共有の判断ゲートを実行してください。エージェントを利用できない場合は、同じ簡潔なエビデンスから両方の成果物をインラインで作成し、同じ検証を実行してください。結果はフェーズ 4 に向けた提案として扱います。未解決のブロッカーがある場合は、提案を承認済みとして扱わずに停止してください。

パス C — Dataverse なし

Dataverse の変更は提案しません。既存の Data Model セクションがあれば保持し、プロジェクトに Dataverse モデルがない場合に限り、「None — no Dataverse tables needed」を使用します。 プランを上書きせずにフェーズ 3 に進みます。

フェーズ 3 — コネクタを計画する

テレメトリチェックポイント：plan_connector_integrations

shared/references/connector-planning.md に従います。

1. 推測する — $ARGUMENTS にアプリの機能が記載されている場合は、コネクタ関連のキーワードをスキャンします。候補リストを作成します。
2. 確認する — AskUserQuestion を使って提示します。ユーザーが追加、削除、または確認できるようにします。
3. 記録する — ## Connectors セクションを作成します。

ユーザーから要件のコンテキストが提供されていない場合は、次のように質問します。

「アプリは何に接続する必要がありますか？（例：SharePoint、Teams、メール、Excel、OneDrive、Azure DevOps — またはなし）」

フェーズ 4 — まとめて承認

テレメトリチェックポイント：approve_data_model_and_connectors

既存のデータのみのプランでは、書き込む前に現在のバインディングと提案を比較します。data-source-removal.md を適用して、削除を分類し、明示的に承認します。省略されたテーブルは自動的に削除されるわけではありません。既存のコンシューマーが必要とするものはすべて保持します。それらに必要な変更は別途報告します。ユーザーはコンシューマーの作業に既存の /edit-app を依頼できますが、このワークフローが自動的に呼び出すことはありません。

どのパスからの Dataverse 提案でも、このゲートに進む前に、現在の正規化済みコントラクトとスナップショットが validate-dataverse-planning-decisions.js を通過し、終了コード 0 になる必要があります。改訂時は検証を繰り返します。広範な探索や、承認手続きの再実施は行いません。コネクタのみ、廃止のみ、更新のみの提案は、それぞれ独自のチェックを維持し、古いスキーマ計画アーティファクトを再利用してはいけません。

提案のみで終了： --plan-only が指定されている場合、または呼び出し元のフェーズが計画段階である場合は、提案する Data Model、Connectors、および廃止／オフラインの影響を提示してから、呼び出し元に戻り、以下の実行承認に進む前に停止します。native-app-plan.md を保存したり、承認レシートを発行したり、マテリアライズ済みマニフェストを更新したり、フェーズ 5～7 を実行したりしてはいけません。作業用の提案は適用済みプランではありません。提案をレビューする承認があっても、--plan-only が無効になるわけではありません。実装には、このフラグを付けない別の依頼と、正確な差分への承認が必要です。

このデータソース差分の完全なプラン（データモデルとコネクタ）を、1 つの EnterPlanMode ブロックにまとめて提示します。保持するコンテキストと、追加、更新、明示的に承認された廃止を区別します。現在の実装フェーズの担当者が正確なデータ承認を提示することもできます。その場合は、それがこの提案と一致することを検証し、書き込む前にスコープの変更を担当者に戻します。保存済みプランまたは --skip-planning だけでは承認になりません。

## Plan: Data Sources

### Data Model
[reuse/extend/create table]
[Mermaid ER diagram]
[creation order tiers]

### Connectors
[connector table or "None"]

Approve both to proceed with execution?

• 承認 → 承認された両方のセクションを native-app-plan.md に保存し、無関係なセクションを保持してから、フェーズ 5 に進みます。これはアーキテクトの出力やコネクタのみのプランを含む、フェーズ 2 のすべてのパスに適用されます。
• データモデルを変更 → そのセクションのみについてフェーズ 2 に戻り、その後フェーズ 4 を再提示します。
• コネクタを変更 → フェーズ 3 に戻り、その後フェーズ 4 を再提示します。
• キャンセル → 提案されたプランやデータソースの変更を適用せずに停止します。

受け入れた提案を <working_dir>/native-app-plan.md に保存します。作業用の _dm_section.md は、第二の信頼できる情報源ではありません。以前のプランに紐付いた操作マニフェストや承認レシートを再利用してはいけません。検証済みのマテリアライズ済みマニフェストは、提案行をコピーして更新するのではなく、実行／検証後に更新します。承認済みの Dataverse 実装では、共有の計画パスを維持し、受け入れた contract_sha256 と保存済みの plan_sha256 を approved_scope に固定します。これは作成フローのレシートではなく、無関係なネイティブ、コネクタ、または画面の承認を与えるものでもありません。

フェーズ 5 — データモデルの実行

テレメトリチェックポイント：apply_dataverse_schema

--skip-planning を指定して /add-dataverse を実行し、承認済みの計画を直接読み込ませます。再度プロンプトを表示させないでください。

ここでは追加／更新のみを適用します。削除のみの差分の場合は、このフェーズをスキップしてください。承認済みの廃止には、フェーズ 6.25 で専用の引き継ぎを行います。

登録済みテーブルをサービスのみ更新する場合は、リーフの --refresh --data-source-name "<registered-name>" ブランチを使用し、その正確な登録済み ID を approved_scope に渡してください。その行について、以下のスキーマ追加の引き継ぎは実行しないでください。スキーマ変更の場合は、通常の以下の引き継ぎを使用してください。

Invoke skill: /add-dataverse

Context:
  MOBILE_APP_ORCHESTRATING=1
  orchestrator: setup-datamodel
  working_dir: <working_dir>
  phase: implementation
  offline_reconciliation_owner: setup-datamodel
  planning_snapshot: <SNAPSHOT_PATH>
  architect_evidence: <ARCHITECT_EVIDENCE_PATH>
  schema_contract: <working_dir>/.tmp/dataverse-schema-contract.json
  approved_scope: <approved Data Model delta and answers, contract_sha256, plan_sha256>

Arguments:
  --working-dir '<working_dir>'
  --plan-section '<working_dir>/native-app-plan.md#data-model'
  --skip-planning

/add-dataverse は、このスコープ内で階層順にテーブルを作成し、承認済みの不足しているバインディングの追加、または承認済みの保持対象サービスの更新のみを行い、必要に応じてカスタマイズを公開し、.datamodel-manifest.json を書き込み、型チェックを実行します。スコープ指定された計画コンテキストを検証し、最新のライブリコンシリエーションを実行します。部分的な作成専用の高速パスフラグは送信しないでください。フェーズ 6 に進む前に、完了するまで待ってください。

画面計画からのエンティティ間読み取り — 承認済みの ### Cross-entity Reads サブセクションには、書式設定済みのルックアップ、上限付きの連鎖フェッチ、または external-projection-required ブロッカーが含まれます。/add-dataverse がコードを通じて計算列／数式列の定義を合成することはありません。ユーザーが指定し、メーカーが作成した計算列は、再利用する前にリコンシリエーションで既存の依存関係として検証されます。

フェーズ 2 でパス C（Dataverse なし）を選択した場合はスキップしてください。

フェーズ 6 — コネクタの実行

テレメトリチェックポイント：generate_connector_data_sources

native-app-plan.md の ## Connectors を読み取ります。承認済みの追加／更新対象のコネクタ行（保持対象または廃止対象の行は除く）ごとに、/add-connector を実行します。

ディスパッチの前に操作を切り分けます。追加対象の行には通常の引き継ぎを使用し、更新対象の行には --refresh --data-source-name "<registered-name>" を追加して、検証済みの API／データセット／接続の ID を approved_scope に含めます。登録名をコネクタの表示ラベルから推測しないでください。更新ブランチは、接続の作成や add-data-source を行わずに完了する必要があります。

追加ソースのみ：

Invoke skill: /add-connector

Context:
  MOBILE_APP_ORCHESTRATING=1
  orchestrator: setup-datamodel
  working_dir: <working_dir>
  phase: implementation
  approved_scope: <approved connector row and answers>

Arguments:
  --working-dir '<working_dir>'
  --connector <api-name>

保持ソースの更新のみ： この専用の引き継ぎを使用してください。追加用のブロックは使用しないでください。

Invoke skill: /add-connector

Context:
  MOBILE_APP_ORCHESTRATING=1
  orchestrator: setup-datamodel
  working_dir: <working_dir>
  phase: implementation
  approved_scope: <refresh operation, exact registered name, verified API/dataset/resource and connection ID/reference>

Arguments:
  --working-dir '<working_dir>'
  --connector <verified-api-id>
  --refresh
  --data-source-name "<registered-name>"

順番に実行してください。## Connectors が「None」の場合はスキップしてください。

フェーズ 6.25 — 未使用のアプリバインディングを廃止する

明示的に承認された廃止ごとに、一致するリーフを --remove、MOBILE_APP_ORCHESTRATING=1、orchestrator: setup-datamodel、phase: implementation、working_dir: <working_dir>、引数 --working-dir '<working_dir>'、および approved_scope を指定して実行します。 data-source-removal.md に従ってください。 この独立したデータ専用フローではコンシューマーを編集しません。残っているコンシューマーがある場合は、それらを破損させるのではなく、統合作業についてユーザーまたは現在の担当者に報告し、停止してください。ユーザーは別途 /edit-app をリクエストできます。自動的にそちらへ誘導しないでください。 CLI のクリーンアップを検証し、サマリーの前に、実際に残っている生成済みサービスのスナップショットとアプリマニフェストをリコンシリエーションしてください。廃止対象がない場合はスキップしてください。 共有の削除コントラクトに記載された、各リーフの offlineRetirement の結果を保持してください。これには、以前の試行で memory-bank に記録された未解決の結果も含まれます。 アプリバインディングのクリーンアップとオフラインプロファイルの移行は、それぞれ別の完了状態です。

フェーズ 6.5 — オフラインプロファイルの調整

テレメトリチェックポイント：reconcile_offline_profile

フェーズ 5 で Dataverse テーブルを作成または拡張した場合、既存のモバイルオフラインプロファイルにそれらのテーブルや列が不足している可能性があります。フェーズ 5 は offline_reconciliation_owner: setup-datamodel を含む完全なスコープ指定の引き継ぎ情報を渡します。これに --skip-planning を組み合わせることで、リーフのステップ 8.5 のチェックを二重に実行せず、このオーケストレーターが担当します。このフラグだけでは不十分です。フェーズ 2 でパス C（Dataverse なし）が選択された場合は追加チェックをスキップしますが、記録済みの offlineRetirement の結果は決して破棄しないでください。

ネットワークを使用しないローカルの差分チェックを実行します。

cd -- '<working_dir>' || { echo "BLOCKED: cannot enter working_dir" >&2; exit 1; }
node "${PLUGIN_ROOT}/scripts/offline-profile-delta.js" --project-root '<working_dir>'

終了ステータスと stdout／stderr を記録します。ステータスの振り分けやフェーズ 7 の概要表示の前に、終了コードが 0 以外、status: error、JSON の欠落または形式不正、あるいは未知のステータスがあった場合は、offline-profile-reconciliation.md に従って失敗処理を行います。エラーを提示し、既存の廃止結果を保持したまま offline_reconciliation: failed を記録し、変更用ヘルパーをスキップして、データ変更がすでに適用されている場合は DONE_WITH_CONCERNS（そうでない場合は BLOCKED）を返します。調整が完了したと主張したり、問題のない成功時の概要表示を続けたりしてはいけません。

有効なチェックが成功した場合は、JSON の status に応じて分岐します。no-manifest／no-profile／in-sync は追加作業が不要であることを意味します。既存の offlineRetirement の結果を変更せず（プロファイルが存在しない場合に催促しないで）、フェーズ 7 に進みます。delta の場合は、オフライン更新の承認を得てから、参照資料の Scoped helper handoffs を使用します。その際、orchestrator: setup-datamodel、working_dir: <working_dir>、phase: implementation と、承認された環境／プロファイル／テーブル／フィルターまたは列の正確なスコープを指定します。missingTables[] には add-table-to-offline-profile に --working-dir '<working_dir>' --table <logicalName> を渡します。tablesWithNewColumns[] には同じ引数に加えて --columns "add:<newColumns>" を edit-offline-profile に渡します。同じ失敗処理を適用しながら、再チェックで in-sync になることを確認します。追加作業が拒否された場合や未完了の場合は、別個の懸念事項として扱います。

これらのオフラインヘルパーにも同じ絶対パスの working_dir を渡します。調整中に新たなルート検出を行ってはいけません。

フェーズ 7 — 概要

成功とする前に、影響を受けた各計画セクションを、このプロジェクトで検証済みの出力と照合し、Generated Services のスナップショットを更新します。Dataverse の変更については、.datamodel-manifest.json も照合し、最後の Dataverse バインディングを削除した後も、有効な空のインベントリを保持します。Dataverse を使わないコネクターのみの作業では、Dataverse マニフェストは不要であり、作成もしません。部分的な実行や未解決の削除は memory-bank に記録し、計画がすべて適用されたと主張するのではなく、成功以外のステータスを返します。

例にある可能性のある成果物ではなく、検証済みの結果から概要を作成します。Dataverse インベントリがないコネクターのみの作業では、Data Model と Manifest を not applicable として報告し、存在しないマニフェストのパスを表示しないでください。検証済みのインベントリがすでに存在し、変更されていない場合は、unchanged と表示します。

影響を受けたすべてのテーブルの offlineRetirement ステータスを、memory-bank と最終応答の両方に含めます。pending の場合は、問題のない DONE ではなく DONE_WITH_CONCERNS を返します。 "アプリの変更は完了しました。オフラインプロファイルには引き続き Orders が含まれています。このデータ範囲を維持するか削除するかは未決定です。" 実際のテーブル名と検証済みのアプリの結果を使用します。アプリのクリーンアップに失敗した場合は、完了したと主張するのではなく、その失敗を報告します。retained では承認済みの理由を報告します。reconciled とするには、in-sync の結果ではなく、プロファイルの移行が検証されている必要があります。

✅ Data sources set up
─────────────────────────────────────────────
Data model:
  Tables reused  : <list>
  Tables extended: <list>
  Tables created : <list>
  Manifest      : <verified manifest path and updated/unchanged status, or "not applicable">

Connectors:
  <list of added connectors, or "None">

Generated services:
  src/generated/services/ × <N>
  src/generated/models/   × <N>

Type-check: PASS

Next steps:
  /add-datasource   — add more data sources
  /add-native       — add device capabilities
  /edit-app         — separately request consumer/screen changes if needed
─────────────────────────────────────────────

参考資料

• shared/references/connector-planning.md — コネクタの推論と確認のロジック
• shared/references/offline-profile-reconciliation.md — Phase 6.5 のオフライン差分チェックと調整のフロー
• skills/add-dataverse/SKILL.md — データモデルの実行ワークフロー全体
• agents/data-model-architect.md — 読み取り専用のアーキテクトエージェント