Shared instructions: shared-instructions.md — read first.

Preview Offline Scope

Read-only diagnostic. Tells you "if you pushed this profile to users right now, here's what their devices would download and how often it would re-sync." No mutations.

Useful before:

• /setup-offline-profile for a final sanity check
• /assign-offline-profile (so users don't get surprised by data caps)
• /edit-offline-profile to gauge impact of a column-list change

Before any project read or command, apply app-working-directory.md. Resolve one absolute working_dir for this direct invocation, or require the owner's root for a child. Keep all shell calls, file reads, and retries on that root and the same resolved environment/tenant. Read <working_dir>/offline-profile.json; a supplied profile ID must match the snapshot before verification. Missing or conflicting context is NEEDS_CONTEXT.

Workflow

1. Verify project + locate profile → 2. Run verify (drift check) → 3. Per-table row counts → 4. Cache-size estimate → 5. Report

Step 1 — Verify project + locate profile

Same as /edit-offline-profile Step 1. Read profileId from offline-profile.json or $ARGUMENTS --profile-id. Do not read profile metadata from power.config.json; it is owned by 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

Capture <envUrl> and <tenantId> and require them to match any owner identity. Pass that tenant explicitly on verification, row counts, identity reads, and retries.

Step 2 — Run verify

Telemetry checkpoint: 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>"

If status: drift, surface the drift list verbatim. The estimate that follows is still meaningful but flag that the live profile diverges from offline-profile.json — recommend re-running /setup-offline-profile or /edit-offline-profile to reconcile.

Step 3 — Per-table row counts (with scope-applied filter)

Telemetry checkpoint: count_offline_profile_rows

For each table in the profile, run a count query that applies the same filter the runtime would use:

For current-user/current-BU filters, resolve identity only inside this skill by calling Dataverse WhoAmI through scripts/dataverse-request.js against the resolved <envUrl> with --tenant-id "<tenantId>" from the same guarded root. If that call fails, report the affected scope as unknown — current user/BU unavailable instead of blocking the whole preview. Do not expect scripts/resolve-environment.js or auth.config.json.environment to provide UserId / BusinessUnitId.

For each table:

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>"

Cap at 5000 (Dataverse non-aggregate count cap). When the result is exactly 5000, prefix with ≥ in the report.

Step 4 — Cache-size estimate

Telemetry checkpoint: estimate_offline_cache_size

Rough byte-per-row heuristics (configurable; replace with measured values once we have a real sync benchmark):

For each table, compute: estimatedBytesPerRow = sum(bytesForEach column in selectedcolumns). Then tableTotalBytes = rows × estimatedBytesPerRow.

Per-table sync overhead: each syncintervalinminutes interval triggers a delta query → assume ~20% of total rows touched on a typical day. dailyTransferBytes = (totalBytes × 0.20 × intervalsPerDay).

Step 5 — Report

═════════════════════════════════════════════════════════════
  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).

Status code (final line)

• DONE — estimate produced, no concerns
• DONE_WITH_CONCERNS: <list> — estimate produced but flagged items (high sync rates, near-cap row counts, drift detected, etc.)
• NEEDS_CONTEXT: <missing> — no profile to estimate against
• BLOCKED: <reason> — auth or query failures

Notes

This skill is intentionally estimate-grade, not precise. The byte heuristics are rule-of-thumb; real cache size depends on Dataverse's storage layout + JSON serialization + per-device cache compression. The numbers are useful for comparative decisions (one scope vs another, one column list vs another), not for absolute capacity planning.

For precise figures, the only source of truth is the runtime sync log itself — only available once the app is deployed and an RM has signed in.