preview-offline-scope

共通の指示：shared-instructions.md — 最初にお読みください。

オフライン範囲のプレビュー

読み取り専用の診断です。「このプロファイルを今ユーザーに適用した場合、デバイスに何がダウンロードされ、どのくらいの頻度で再同期されるか」を確認できます。変更は行いません。

次の操作の前に役立ちます。

• /setup-offline-profile：最終確認
• /assign-offline-profile：ユーザーがデータ上限に予想外に達するのを防ぐため
• /edit-offline-profile：列リストの変更による影響を把握するため

プロジェクトの読み取りやコマンドの実行前に、 app-working-directory.mdを適用してください。 この直接呼び出し用に絶対パスのworking_dirを1つ解決するか、子呼び出しの場合はオーナーのルートを要求してください。すべてのシェル呼び出し、ファイル読み取り、再試行は、そのルートと同じ解決済み環境／テナントで行ってください。 <working_dir>/offline-profile.jsonを読み取ってください。指定されたプロファイル ID は、検証前にスナップショットと一致している必要があります。コンテキストが不足または競合している場合はNEEDS_CONTEXTです。

ワークフロー

1. プロジェクトを確認してプロファイルを特定 → 2. 検証を実行（ドリフト確認） → 3. テーブルごとの行数 → 4. キャッシュサイズを推定 → 5. 結果を報告

---

ステップ 1 — プロジェクトを確認してプロファイルを特定

/edit-offline-profileのステップ 1 と同じです。offline-profile.jsonまたは$ARGUMENTS --profile-idからprofileIdを読み取ってください。power.config.jsonからプロファイルのメタデータを読み取らないでください。これはpa app initが管理します。

cd -- '<working_dir>' || { echo "BLOCKED: cannot enter working_dir" >&2; exit 1; }
environment_id=$(node -p "require('./power.config.json').environmentId || ''") || {
  echo "BLOCKED: unreadable power.config.json" >&2; exit 1;
}
if [ -z "$environment_id" ]; then
  echo "NEEDS_CONTEXT: selected app has no environmentId" >&2; exit 1;
fi
node "${PLUGIN_ROOT}/scripts/resolve-environment.js" "$environment_id" --no-cache --require-tenant

<envUrl>と<tenantId>を取得し、オーナーの識別情報があれば一致することを確認してください。 検証、行数の取得、識別情報の読み取り、再試行では、そのテナントを明示的に指定してください。

ステップ 2 — 検証を実行

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

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

status: driftの場合は、ドリフトの一覧をそのまま提示してください。以降の推定にも意味はありますが、実際のプロファイルがoffline-profile.jsonと一致していないことを明記し、整合させるために/setup-offline-profileまたは/edit-offline-profileを再実行するよう推奨してください。

ステップ 3 — テーブルごとの行数（スコープ適用済みフィルターを使用）

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

プロファイル内の各テーブルについて、ランタイムが使用するものと同じフィルターを適用したcountクエリを実行してください。

recorddistributioncriteria	recordsownedby* フラグ	有効なフィルター
1（すべてのレコード）	該当なし	?$count=true&$top=0（テーブル全体）
2 + 自分	recordsownedbyme=true	?$count=true&$top=0&$filter=_ownerid_value eq <current-user-id>
2 + チーム	recordsownedbymyteam=true	概算：_ownerid_valueが（現在のユーザーのチーム所有 ID の）いずれか。推定にはteamroles_associationのチーム件数を使用
2 + ビジネスユニット	recordsownedbymybusinessunit=true	?$count=true&$top=0&$filter=_owningbusinessunit_value eq <current-bu-id>
0（関連レコードのみ）	該当なし	個別には推定できません。親レコードに依存します。~depends on parent countsと報告してください。

現在のユーザー／ビジネスユニットのフィルターでは、このスキル内でのみ、解決済みの<envUrl>に対して同じガード付きルートから--tenant-id "<tenantId>"を指定し、scripts/dataverse-request.js経由でDataverseのWhoAmIを呼び出して識別情報を解決してください。その呼び出しに失敗した場合は、プレビュー全体を中断せず、該当するスコープをunknown — current user/BU unavailableと報告してください。scripts/resolve-environment.jsまたはauth.config.json.environmentからUserId／BusinessUnitIdを取得できるとは想定しないでください。

各テーブルについて：

cd -- '<working_dir>' || { echo "BLOCKED: cannot enter working_dir" >&2; exit 1; }
node "${PLUGIN_ROOT}/scripts/dataverse-request.js" <envUrl> GET \
  "<entitysetname>?\$count=true&\$top=0&<scope-filter>" --tenant-id "<tenantId>"

上限は5000です（Dataverseの非集計カウント上限）。結果がちょうど5000の場合は、レポートで≥を先頭に付けてください。

ステップ 4 — キャッシュサイズの推定

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

1 行あたりのバイト数の概算値（設定可能です。実際の同期ベンチマークが得られたら、測定値に置き換えてください）：

列の型	バイト数
Uniqueidentifier	40
String（平均 80 文字）	100
Integer / Decimal	12
DateTime	28
Boolean / State / Status	4
Picklist（オプション値のみ）	8
Memo（平均 500 文字）	600
Lookup（FK のみ）	40
Image（URL とサムネイルのメタデータのみ — 画像全体のバイト数については以下の注記を参照）	200
File（URL と名前のメタデータ）	200

テーブルごとに、次のように計算します：estimatedBytesPerRow = sum(bytesForEach column in selectedcolumns)。次に、tableTotalBytes = rows × estimatedBytesPerRow。

テーブルごとの同期オーバーヘッド：各 syncintervalinminutes の間隔で差分クエリが実行されます → 通常の日には全行の約 20% が対象になると仮定します。dailyTransferBytes = (totalBytes × 0.20 × intervalsPerDay)。

ステップ 5 — レポート

═════════════════════════════════════════════════════════════
  Offline Scope Preview — <profileName>
═════════════════════════════════════════════════════════════

Drift status: ok | drift (see verify output)

Per-table breakdown:

| Table              | Scope          | Rows     | Cols | Est. bytes | Sync (min) |
|--------------------|----------------|----------|------|------------|------------|
| chnl_region        | All records    | 12       | 7    | 4 KB       | 60         |
| chnl_product       | All records    | 312      | 13   | 280 KB     | 60         |
| chnl_rmprofile     | Org+me         | 1        | 10   | 1 KB       | 10         |
| chnl_store         | Org+me         | 84       | 17   | 112 KB     | 10         |
| chnl_storevisit    | Org+me         | 412      | 13   | 220 KB     | 5          |
| chnl_order         | Org+me         | 156      | 14   | 95 KB      | 10         |
| chnl_orderline     | Related only   | ~depends | 11   | ~150 KB    | 10         |

Total initial download : ~860 KB (5000-rows cap not hit)
Daily transfer estimate: ~12 MB / device / day (assuming 20% delta rate)

Sync intervals per day:
  chnl_storevisit (5 min)  → 288 syncs/day  ⚠ high
  chnl_store      (10 min) → 144 syncs/day
  chnl_order      (10 min) → 144 syncs/day
  chnl_rmprofile  (10 min) → 144 syncs/day
  chnl_region     (60 min) → 24  syncs/day
  chnl_product    (60 min) → 24  syncs/day

Concerns:
  - chnl_storevisit at 5 min could exceed mobile data caps in low-signal areas
    (battery drain too). Consider 10 min unless 5 min is mission-critical.

Image / File bytes NOT counted by these heuristics. The metadata (URL +
thumbnail size) IS counted at 200 bytes/row, but the JPEG/file payload
itself transfers separately at runtime sync time. To estimate image
storage, multiply expected non-empty image rows × average JPEG size
(typically 10–500 KB per thumbnail).

ステータスコード（最終行）

• DONE — 推定完了、懸念事項なし
• DONE_WITH_CONCERNS: <list> — 推定は完了しましたが、項目にフラグが立ちました（同期率が高い、行数が上限に近い、ドリフトが検出されたなど）
• NEEDS_CONTEXT: <missing> — 推定対象のプロファイルがありません
• BLOCKED: <reason> — 認証またはクエリの失敗

注記

このスキルは、意図的に精密ではなく、概算を目的としています。バイト数の概算値は経験則です。実際のキャッシュサイズは、Dataverse のストレージレイアウト、JSON シリアル化、デバイスごとのキャッシュ圧縮によって異なります。これらの数値は、絶対的な容量計画ではなく、比較（あるスコープと別のスコープ、ある列リストと別の列リスト）に役立ちます。

正確な数値を得る唯一の情報源は、実行時の同期ログです。これは、アプリがデプロイされ、RM がサインインした後にのみ利用できます。