/enable-tables-offline

name: enable-tables-offline
description: Internal mobile-app workflow read and executed only by /setup-offline-profile to enable Dataverse table prerequisites for a Mobile Offline Profile.
user-invocable: false
disable-model-invocation: true
allowed-tools: Read, Edit, Write, Grep, Glob, Bash, AskUserQuestion, EnterPlanMode, ExitPlanMode
model: sonnet

**Shared instructions: [shared-instructions.md](${PLUGIN_ROOT}/shared/shared-instructions.md)** — read first.

**References:**

• [offline-profile-schema.md](${PLUGIN_ROOT}/shared/references/offline-profile-schema.md) — entity field map (`IsAvailableOffline`, `ChangeTrackingEnabled`)

Enable Tables Offline

Flip `IsAvailableOffline=true` AND `ChangeTrackingEnabled=true` on the `EntityMetadata` of one or more Dataverse tables, then publish customizations. This is the prerequisite shown in Image 4 of the maker portal ("Can be taken offline" + "Track changes") — without both, a table CANNOT be added to a Mobile Offline Profile.

Sequential (Dataverse metadata lock) and idempotent: re-running on an already-enabled table is a no-op.

Invocation context and root binding

This internal helper is always a **child invocation**. Before any project read or command, execute [app-working-directory.md](${PLUGIN_ROOT}/shared/references/app-working-directory.md). Require the owner's absolute `working_dir`; `--working-dir`, when supplied, must identify that same native-canonical root. Missing, relative, or conflicting root context returns `NEEDS_CONTEXT` before project access; an inaccessible directory is `BLOCKED`. Never use the launch cwd or introduce another root resolver.

Receive `MOBILE_APP_ORCHESTRATING=1`, `orchestrator: setup-offline-profile`, `working_dir`, `phase`, `approved_scope`, and supplied answers. Preserve the selected environment ID/URL/tenant and exact table/prerequisite/publication allowlist. The marker is not approval. Reuse only matching current offline approval; a missing or changed scope returns `NEEDS_CONTEXT` to the owner. For `--plan-only` or a planning-phase handoff, return the proposed prerequisite changes after permitted read-only inspection, before PUT, publication, or artifact writes. A gate response cannot lift proposal-only mode.

Apply the canonical root contract to **every shell call and file tool**. Re-supply the absolute `PLUGIN_ROOT` and invocation context on each call; no prior `cd`, export, or shell variable persists. Missing values return `NEEDS_CONTEXT`; never execute an unresolved placeholder. All linked recovery commands, re-GET verification, and retries use the same root, environment, and explicit tenant. Read only absolute app-local paths, including `<working_dir>/power.config.json`, `<working_dir>/memory-bank.md`, and the manifest locations below.

Workflow

1. Verify project & auth → 2. Resolve table list → 3. Inspect current state → Gate → 4. PUT EntityMetadata per table → 5. Publish → 6. Verify → 7. Summary

---

Step 1 — Verify project & auth

cd -- '<working_dir>' || { echo "BLOCKED: cannot enter working_dir" >&2; exit 1; }
if [ ! -f power.config.json ] || [ ! -f app.config.js ]; then
  echo "BLOCKED: working_dir is not an initialized app" >&2
  exit 1
fi

Require the app's `environmentId` to match the owner's selected environment before any discovery or mutation. Use this non-persisting lookup from the same root:

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" ] || [ "$environment_id" != "<selected-environment-id>" ]; then
  echo "NEEDS_CONTEXT: selected environment does not match working_dir" >&2
  exit 1
fi
node "${PLUGIN_ROOT}/scripts/resolve-environment.js" "$environment_id" --no-cache --require-tenant

Capture the **Environment URL** and **Tenant ID** from the resolver for `<envUrl>` and `<tenantId>`. Pass this tenant explicitly on every helper call and retry below; missing or conflicting tenant context is `NEEDS_CONTEXT`. Require the ID, URL, and tenant to match the owner; never switch accounts or environments to recover. STOP if not authenticated.

Step 2 — Resolve table list

Use only the exact table allowlist in the owner's `approved_scope`. The comma- or space-separated table list in `$ARGUMENTS` must match it; `--working-dir` is root context, not a table name. Missing or conflicting table selection returns `NEEDS_CONTEXT`; an explicitly empty approved list is a verified no-op.

Inspect `<working_dir>/.datamodel-manifest.json`, or `<working_dir>/docs/plan-artifacts/.datamodel-manifest.json` for newer apps, only to verify those selected tables. The manifest is not permission to enable every row. Do not discover another app's manifest or expand the allowlist silently.

Step 3 — Inspect current state

**Print before starting:** > "→ Querying current IsAvailableOffline + ChangeTrackingEnabled for <N> table(s)…"

For each table, in sequence:

cd -- '<working_dir>' || { echo "BLOCKED: cannot enter working_dir" >&2; exit 1; }
node "${PLUGIN_ROOT}/scripts/dataverse-request.js" "<envUrl>" GET \
  "EntityDefinitions(LogicalName='<table>')?\$select=LogicalName,DisplayName,IsAvailableOffline,ChangeTrackingEnabled,IsCustomizable" \
  --tenant-id "<tenantId>"

Build a status table:

| Table              | IsAvailableOffline | ChangeTrackingEnabled | IsCustomizable | Needs change? |
|--------------------|--------------------|-----------------------|----------------|---------------|
| cr123_note         | false              | false                 | true           | YES (both)    |
| cr123_visit        | true               | false                 | true           | YES (track)   |
| contact            | true               | true                  | true           | NO            |

**Hard rule:** if `IsCustomizable.Value=false` on