@metabase/cli 0.4.1-alpha.release-65-integration-branch.5cbe297 → 0.5.0

package/dist/{wait-DCgCJBqX.mjs → wait-D6Tw4ZxO.mjs}

@@ -1,9 +1,9 @@
-import { J as outputFlags, U as connectionFlags, Y as profileFlag, p as renderSummary } from "./cli.mjs";
-import { t as defineMetabaseCommand } from "./runtime-X6hVzSMW.mjs";
-import { n as DEFAULT_TIMEOUT_MS, t as DEFAULT_INTERVAL_MS } from "./poll-DFZRtTA_.mjs";
-import { r as parseWaitSchedule } from "./wait-flags-aRQHTjwg.mjs";
-import { u as syncTaskView } from "./git-sync-DspFahwV.mjs";
-import { a as throwIfFailedTask, i as taskPollOptions, n as formatSyncTask, r as syncTaskIdleView, t as SyncTaskOrIdle } from "./sync-task-BAMOf6_t.mjs";
+import { c as renderSummary, ct as profileFlag, nt as connectionFlags, st as outputFlags } from "./cli.mjs";
+import { t as defineMetabaseCommand } from "./runtime-C5Ha6Ou8.mjs";
+import { n as DEFAULT_TIMEOUT_MS, t as DEFAULT_INTERVAL_MS } from "./poll-BKo5dK0l.mjs";
+import { r as parseWaitSchedule } from "./wait-flags-BRUzMI6S.mjs";
+import { u as syncTaskView } from "./git-sync-Ch1V1fEK.mjs";
+import { a as throwIfFailedTask, i as taskPollOptions, n as formatSyncTask, r as syncTaskIdleView, t as SyncTaskOrIdle } from "./sync-task-a1zyF1Qb.mjs";
 //#region src/commands/git-sync/wait.ts
 const WaitResult = SyncTaskOrIdle;
 var wait_default = defineMetabaseCommand({

package/dist/{wait-flags-aRQHTjwg.mjs → wait-flags-BRUzMI6S.mjs}

@@ -1,6 +1,6 @@
 import { t as interruptSignal } from "./cli.mjs";
-import { t as parseId } from "./parse-id-CxHp2akh.mjs";
-import { n as DEFAULT_TIMEOUT_MS, t as DEFAULT_INTERVAL_MS } from "./poll-DFZRtTA_.mjs";
+import { t as parseId } from "./parse-id-oCbmouCn.mjs";
+import { n as DEFAULT_TIMEOUT_MS, t as DEFAULT_INTERVAL_MS } from "./poll-BKo5dK0l.mjs";
 //#region src/commands/wait-flags.ts
 const waitScheduleFlags = {
 	timeout: {

package/dist/{window-2ybHqui2.mjs → window-BqMFpWMh.mjs}

@@ -1,4 +1,4 @@
-import { x as projectForList } from "./cli.mjs";
+import { h as projectForList } from "./cli.mjs";
 //#region src/output/window.ts
 const MAX_REQUEST_PAGE_SIZE = 200;
 function windowList(items, range, serverTotal) {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@metabase/cli",
-  "version": "0.4.1-alpha.release-65-integration-branch.5cbe297",
+  "version": "0.5.0",
   "description": "Metabase CLI",
   "license": "AGPL-3.0",
   "repository": {

package/skill-data/core/SKILL.md

@@ -12,7 +12,7 @@ Top-level command groups (run `mb <group> --help` to discover verbs):
 
 ```
 auth | db | table | field | upload | content-translation | query | card | dashboard | snippet | segment | measure | collection | library
-document | glossary | timeline | timeline-event | transform | transform-job | transform-tag | transform-test | alert | subscription | setting
+document | glossary | timeline | timeline-event | transform | transform-job | transform-tag | alert | subscription | setting
 search | dependency | git-sync | setup | eid | uuid | upgrade | skills
 ```
 
@@ -142,8 +142,11 @@ Routine verb shapes (list / get / create / update), every flag, and output schem
 - **alert / subscription are two unrelated systems.** `alert` watches one **card** and fires on a send condition (`/api/notification`: a cron string, `channel/email`-prefixed handlers, typed recipients); `subscription` delivers one **dashboard** on a schedule (`/api/pulse`: structured `schedule_type` + hour/day/frame, bare `email` channels, `{id}|{email}` recipients). The bodies are not interchangeable. Both silently deliver nowhere if the server has no SMTP / Slack app — check `mb setting get 'email-configured?'` (quote it; the `?` is a shell glob) before creating either. Their list-valued fields (`handlers`/`subscriptions`, `channels`/`cards`) **replace wholesale** on update, so adding one recipient is a read-modify-write. `mb card alerts <id>` and `mb dashboard subscriptions <id>` list what's already attached to a card/dashboard; `archive` deactivates rather than deletes. Load the `notification` skill before authoring either body.
 - **snippet `--archived` is a swap, not a union** — list returns _either_ active _or_ archived rows, never both. (Same for `--filter archived` on dashboard/collection.)
 - **segment / measure.** `update` and `archive` require a non-blank `revision_message` (audit-logged); the CLI does not synthesize it on `update`. `archive` defaults to `"Archived via mb CLI"` — override with `--revision-message`. `definition` is a flat MBQL clause (→ `mbql`): segment = a filter, measure = exactly one aggregation.
-- **timeline / timeline-event.** Timelines are collection-scoped event annotations for time-series charts: a timeline's events render only on time-series questions saved in the **same collection** (`collection_id`; null = root) — sub-collections do **not** inherit, and events never draw on dashboard cards, only in the question (and collection) view. To annotate a question's chart, create the timeline in that question's collection, then add events; an event only draws when its `timestamp` falls inside the chart's displayed time range. Event `create` requires `timestamp` (ISO 8601), `timezone` (IANA name), `time_matters` (true = the time of day is significant, false = date-only), and `timeline_id` — the API never auto-creates a default timeline. There is no `timeline-event list`; enumerate with `timeline events <id>` (`--archived` to include archived). Archiving a timeline cascades `archived` to its events; `delete` is a **hard** delete of the timeline and all its events — prefer `archive`.
+- **timeline / timeline-event.** A timeline's events draw only on time-series questions saved in the **same collection** (`collection_id`; null = root) — not sub-collections, never on dashboard cards — and only when the event's `timestamp` falls inside the chart's range. Event `create` requires `timestamp` (ISO 8601), `timezone` (IANA name), `time_matters` (false = date-only), and `timeline_id` — no default timeline is auto-created. There is no `timeline-event list`; use `timeline events <id>` (`--archived` to include archived). Archiving a timeline cascades to its events; `delete` is a **hard** delete of both — prefer `archive`.
 - **collection `<ref>`** (`get`/`items`): positive int, `root`, `trash`, or a 21-char entity_id; `update`/`archive` take the int only. `collection items` pages the server, pulling only what the cap can show — read `has_more`/`next_offset` to continue. `collection tree` is **JSON-only** and hides the Library without `--include-library`. A transform collection needs `collection create --namespace transforms`. `update` keeps `archived` unless `--archived` is given.
+<!-- requires: remoteSync -->
+- **remote-synced collections.** Synced content may depend only on synced content: a write that breaks this fails with 400 `Uses content that is not remote synced.` (a source outside sync scope) or `Used by remote synced content.` (archiving or moving out a dependency). Build versioned content inside the synced collection; to move existing content in, see `git-sync`.
+<!-- /requires -->
 - **setting set** parses the value as **strict JSON**: a string is `'"value"'` (inner quotes), booleans `true`/`false`, numbers bare. Wrong quoting silently errors — confirm with `setting get <key>` after. `setting get --json` works on every value type (wrapping bare-text responses into `{key, value}`).
 - **search vs. list.** Enumerate with `… list` verbs; `search` ranks a query or spans resources. `--search-native-query` matches native query text and keeps only query-bearing models; dashboard questions need `--include-dashboard-questions`.
 <!-- requires: transforms -->
@@ -171,9 +174,6 @@ This file is enough for any single-command task. For anything deeper, load the r
 - **`notification`** — scheduled delivery: question alerts (`mb alert`) and dashboard subscriptions (`mb subscription`). Choosing between them, the two schedule/recipient contracts, channel prerequisites, testing a send.
 <!-- requires: transforms -->
 - **`transform`** — transform body JSON, create + run-with-wait, run inspection, tags, jobs.
-  <!-- /requires -->
-  <!-- requires: transformTests -->
-- **`transform-test-plan`** — planning transform tests.
 <!-- /requires -->
 - **`document`** — Metabase documents (TipTap body, embedding cards).
 <!-- requires: remoteSync -->

package/skill-data/dashboard/SKILL.md

@@ -12,6 +12,12 @@ A dashboard starts as cards on a grid; it becomes an **app** when filters drive
 
 Inspect before you wire: `mb dashboard get <id> --json` hydrates `parameters`, `dashcards`, and `tabs`; `mb dashboard cards <id>` lists just the dashcards. To start from an existing dashboard, `mb dashboard copy <id> --collection-id <id> --json` copies it with its tabs and dashcards (the cards stay referenced; `--deep` duplicates the questions and metrics into the target collection, and a dashboard holding dashboard questions needs it). Cards left out of the copy come back by id as `uncopied`.
 
+<!-- requires: remoteSync -->
+
+A dashboard bound for a remote-synced collection is built in it directly: create the dashboard there, then its cards. A card only this dashboard shows is best a **dashboard question** — `card create` with `"dashboard_id": <dash-id>` and the dashboard's `collection_id` — so the dashboard and its questions move as one unit. A card shared across dashboards is a regular card and moves into the synced collection before any dashboard that uses it (`git-sync` → "Moving content into or out of a synced collection").
+
+<!-- /requires -->
+
 ## Layout: the grid is 24 columns — not 12
 
 Every dashcard carries `{col, row, size_x, size_y}` in grid units: `col` is 0-indexed from the left edge, `row` grows downward, and `col + size_x ≤ 24`. **Full-width is `size_x: 24` — Metabase's per-chart _default_ width of 12 is half a row.** A layout authored on the usual 12-column web-grid assumption crams the whole dashboard into the left half of the viewport. The server stores whatever geometry you send — overlaps and gaps included, no auto-fix.

package/skill-data/git-sync/SKILL.md

@@ -15,7 +15,7 @@ This skill covers the import/export workflow. Flag conventions and auth setup li
 
 ## Precondition: read state before mutating
 
-Always run `status` (or `is-dirty` + `has-remote-changes`) before `import` or `export`. Importing on a dirty instance silently rejects unless you pass `--force`.
+Always run `status` (or the individual checks below) before `import` or `export`. Importing on a dirty instance silently rejects unless you pass `--force`.
 
 <!-- requires: remoteSyncMerge -->
 
@@ -26,11 +26,18 @@ Exporting after the remote moved on ends in a `conflict` task unless the export
 ```bash
 mb git-sync status              --profile <n> --json   # → branch, dirty, current task
 mb git-sync is-dirty            --profile <n> --json   # → {is_dirty: bool}; instance has unexported changes
-mb git-sync has-remote-changes  --profile <n> --json   # → {has_changes: bool, remote_version, local_version, cached}; remote has unimported commits
 mb git-sync dirty               --profile <n> --json   # → list the dirty objects
 mb git-sync current-task        --profile <n> --json   # → in-flight task (or idle)
 ```
 
+<!-- requires: remoteSyncRemoteChanges -->
+
+```bash
+mb git-sync has-remote-changes  --profile <n> --json   # → {has_changes: bool, remote_version, local_version, cached}; remote has unimported commits
+```
+
+<!-- /requires -->
+
 **Clean up before exporting.** If you've created entities you intend to delete (a failed transform you're going to retry, a card you authored to test a body shape, a draft dashboard) — do the deletes _before_ the first `git-sync export`. Once committed, the cleanup needs a second commit, and the failed entity stays visible in `git log` forever. For transforms, prefer `transform update <id>` over delete + create (see the `transform` skill).
 
 ## Import (remote → instance)
@@ -53,8 +60,13 @@ Pulls the configured branch and applies it to the instance. Polls until the task
 Workflow:
 
 1. Read state (above) — confirm `is_dirty: false` (or `--force` is intended).
-2. Confirm `has-remote-changes` reports `has_changes: true` — there's actually something to import.
-3. `git-sync import --branch <branch>` — runs to terminal status by default.
+2. `git-sync import --branch <branch>` — runs to terminal status by default.
+
+<!-- requires: remoteSyncRemoteChanges -->
+
+Between the two, confirm `has-remote-changes` reports `has_changes: true` — there's actually something to import.
+
+<!-- /requires -->
 
 <!-- requires: remoteSyncMerge -->
 
@@ -110,17 +122,29 @@ mb git-sync export-preflight --profile <n> --json   # → {has_changes, clean, c
 
 A dry run against the live remote branch, writing nothing. Read it between the state check and the export, and decide from the fields:
 
-| Answer                              | Meaning                                                                                                                                                                     | Move                                                                                                                                                                                                                                                                                                                                                                                                               |
-| ----------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
-| `has_changes: false`                | The remote has not moved past the last sync, or nothing has been synced yet — and then `force_push_casualties` is empty whatever the remote holds.                          | `export -m "..."` applies as-is. Don't read empty casualties on a never-synced instance as leave to `--force`.                                                                                                                                                                                                                                                                                                     |
-| `has_changes: true`, `reason: null` | The remote moved on. `clean` says whether a three-way merge would apply; `conflicts` names the entities changed on both sides; `summary` counts what a merge would fold in. | `clean: true`: `export --merge -m "..."`. `clean: false`: the conflicts need the user's call — `create-branch <name>` then `export -m "..."` pushes Metabase's side to a new branch and leaves the old one untouched, `import --force` takes the remote's side, `export --force` takes Metabase's. A plain `export` ends in a `conflict` task, and so does `stash`: its new branch starts at the moved remote tip. |
-| `reason: "history-rewritten"`       | The remote was force-pushed or rebased, so there is no merge base.                                                                                                          | Only `export --force` can push, and only with the user's explicit go-ahead; `force_push_casualties` is exactly what it would delete or overwrite.                                                                                                                                                                                                                                                                  |
+| Answer                              | Meaning                                                                                                                                                                     | Move                                                                                                                                                                                                                                                                    |
+| ----------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `has_changes: false`                | The remote has not moved past the last sync, or nothing has been synced yet — and then `force_push_casualties` is empty whatever the remote holds.                          | `export -m "..."` applies as-is. Don't read empty casualties on a never-synced instance as leave to `--force`.                                                                                                                                                          |
+| `has_changes: true`, `reason: null` | The remote moved on. `clean` says whether a three-way merge would apply; `conflicts` names the entities changed on both sides; `summary` counts what a merge would fold in. | `clean: true`: `export --merge -m "..."`. `clean: false`: the conflicts need the user's call between the three options under "After a `conflict` task". A plain `export` ends in a `conflict` task, and so does `stash`: its new branch starts at the moved remote tip. |
+| `reason: "history-rewritten"`       | The remote was force-pushed or rebased, so there is no merge base.                                                                                                          | Only `export --force` can push, and only with the user's explicit go-ahead; `force_push_casualties` is exactly what it would delete or overwrite.                                                                                                                       |
+
+`force_push_casualties` is reported on every answer: it is the remote content a force push would discard instead of merging, so read it before ever passing `--force`. It is empty when nothing has been synced yet, yet `export --force` then replaces the remote's managed directories wholesale: check the remote before forcing a first export.
 
-`force_push_casualties` is reported on every answer: it is the remote content a force push would discard instead of merging, so read it before ever passing `--force`. It is empty when nothing has been synced yet, yet `export --force` then replaces the remote's managed directories wholesale: check the remote before forcing a first export. `--branch` defaults to the tracked `remote-sync-branch`; the server rejects any other branch with a 409 naming the current one, so pass it only to assert the branch you believe is tracked.
+Read the preflight before every export: an export that finds the divergence itself ends in `conflict`, and after that these fields can't be trusted (below).
 
 ### After a `conflict` task
 
-A task that ends in `conflict` makes the server count the remote commit it saw as synced. From then on `has-remote-changes` and `export-preflight` report nothing pending, and a retried `export`, `export --merge` or `import --merge` succeeds without bringing the remote's changes into Metabase; a full re-export can then remove them from the remote. So read `export-preflight` before exporting rather than letting an export find the divergence, and never answer a conflict with a retry: take the user's call between `import --force` (the remote's side), `export --force` (Metabase's side) and `create-branch <name>` then `export` (Metabase's side on a new branch).
+Never answer a conflict with a retry. A task that ends in `conflict` may make the server count the remote commit it saw as synced; the server version does not say whether it does. If it does, `has-remote-changes` and `export-preflight` report nothing pending, `force_push_casualties` comes back empty, and a retried `export`, `export --merge` or `import --merge` succeeds without bringing the remote's changes into Metabase; a later full or forced export can then overwrite them on the remote. So don't decide from those reads. Take the user's call between:
+
+- **The remote's side:** `import --force`. Discards Metabase's un-pushed work.
+- **Metabase's side:** `export --force`. Overwrites the remote, and its casualties can't be previewed after a conflict: show the user the remote's commits since the last export in git first.
+- **Both, through a reviewed PR:**
+  1. Note the tracked branch from `mb git-sync status --json` (`branch`): this is `<original>`.
+  2. `mb git-sync create-branch <name>`
+  3. `mb git-sync export -m "..."`
+  4. `mb git-sync import --force`, which reloads the instance from `<name>`.
+  5. Open a PR from `<name>` into `<original>` and review its diff before it merges. If the server counted the conflict as synced, `<name>` starts at the remote's tip, so the PR can undo the remote's edits to the conflicting entities without a git conflict: restore any such edit in the PR.
+  6. Once the PR merges, `mb git-sync import --branch <original>` tracks the original branch again and loads the merged result.
 
 <!-- /requires -->
 
@@ -169,7 +193,7 @@ mb git-sync remove-collection <collection-id> --profile <n> --json
 
 `<collection-id>` is a **positive integer** (the bulk endpoint's schema is `pos-int? → boolean`; nano-id / `root` / `trash` refs are not supported). Get the id from `collection list` (see `core`).
 
-Both verbs return `{ success: true, task_id?: <id> }`. The optional `task_id` only appears when the toggle triggered a follow-up task (e.g., a finalization import after switching to read-only mode); for a normal add/remove in read-write, expect `{ success: true }` and nothing else.
+Both verbs return `{ success: true }`, plus a `task_id` only when the toggle started a follow-up task (e.g. a finalization import after switching to read-only).
 
 **Cascade.** A toggle on a parent cascades to every descendant by `location` prefix — `add-collection 4` flips `4` plus every collection nested under it. `remove-collection 4` is the symmetric inverse. There is no per-leaf-only mode.
 
@@ -183,6 +207,32 @@ mb setting set remote-sync-type '"read-write"' --profile <n>
 
 **Verifying the result.** `mb git-sync status --profile <n> --json` lists the flagged collections under `synced_collections`, and `mb collection get <id> --json` shows the per-collection `is_remote_synced` flag.
 
+## Moving content into or out of a synced collection
+
+When remote sync is configured and the content is meant to be versioned, create it in the synced collection from the start. Nothing reaches git until `git-sync export`, and "Clean up before exporting" covers the drafts.
+
+Synced content may only depend on synced content. Creating a card, dashboard, document, or collection in a synced collection, moving one in, or updating one inside it walks its dependencies, and the server refuses with 400 `Uses content that is not remote synced.` if any of them sits outside sync scope. What counts as a dependency:
+
+- **Card:** the cards it is built on (source model, question, or metric), cards referenced as `{{#id}}` in native SQL, the card behind a filter's value source (`values_source_config.card_id`), and snippets — a snippet counts as synced only when the Library is.
+- **Dashboard:** every dashcard's card, `series` cards, cards in parameter mappings and parameter value sources, actions, and the cards and dashboards a link card points to.
+- Warehouse tables never count: a card on a raw table moves freely.
+
+Three ways through:
+
+1. **Bottom-up.** Move the sources first — models, then metrics, then the questions built on them — and the dashboard last. `card update <id> --body '{"collection_id":<synced-id>}'`, then `dashboard update <id> --body '{"collection_id":<synced-id>}'`.
+2. **The whole containing collection.** `mb collection update <id> --parent-id <synced-id>` checks once, after the whole subtree has moved, so references inside the subtree pass.
+3. **Dashboard questions.** A card created with `dashboard_id` (and the dashboard's `collection_id`) moves with its dashboard in the same transaction, so it never blocks the move.
+
+The reverse holds too: archiving something, or moving it out of sync scope, is refused with 400 `Used by remote synced content.` while synced content still depends on it. The error names the dependents by model and id (`Used by remote synced content: Card 12, Dashboard 3. …`); move or archive those first, or leave the dependency in place.
+
+Reading the inbound refusal: the error lists the blocking content as bare ids with no model type (`Uses content that is not remote synced: ids 412, 77. …`) — these are the dependencies to move first. Most are cards (`mb card get <id>`); otherwise try `mb dashboard get <id>` or `mb snippet get <id>`, and match the name against the content you meant to move.
+
+<!-- requires: dependencyGraph -->
+
+To plan the order before the first move, `mb dependency graph dashboard <id> --json` (or `card <id>`) lists everything the entity reads from; every card and snippet node outside the synced collection moves first.
+
+<!-- /requires -->
+
 <!-- requires: library -->
 
 ## Published table metadata (Library) and sync scope
@@ -203,11 +253,11 @@ Flagging the collection records it for the next export, which serializes its cur
 
 ## Don't (git-sync-specific)
 
-- Don't turn instance-side changes into hand-written repo files. When the changes were made against the instance, export them (`stash` / `create-branch` + `export`) and PR the exported branch; reconstructing them as YAML by hand — or pushing files in paths/formats the serializer doesn't own — produces content that never applies on import, and pushing behind Metabase's back races its own sync tasks. Hand-editing YAML belongs to the repo-first workflow, in the serialized layout the repo already uses.
+- Don't turn instance-side changes into hand-written repo files: export them and PR the exported branch (see the top of this skill). Files pushed behind Metabase's back race its own sync tasks.
 - Don't conclude from an empty `dirty` list that a change type isn't tracked. Dirty-tracking only records changes to _eligible_ objects; the usual cause is scope (the collection isn't flagged — see "Published table metadata"), not capability. Check `synced_collections` in `status` before concluding.
 - Don't run `git-sync import --force` or `git-sync export --force` without explicit user confirmation. Both are lossy — `--force` import discards instance-side work, `--force` export overwrites the remote branch.
 - Don't drive `git-sync` against a Metabase instance that doesn't have remote-sync configured — every verb returns an error pointing at the missing `remote-sync-*` settings. To check: `mb setting get remote-sync-url --profile <n> --json`.
 - Don't author content directly via `card create` / `transform create` and then assume `git-sync export` will commit it cleanly — the instance and repo can drift if you mix direct API writes with sync-tracked changes. If you do, follow direct writes immediately with `git-sync export -m "..."` to keep them in step.
+- Don't move a dashboard or question into a synced collection before what it depends on, and don't retry a `Uses content that is not remote synced.` refusal unchanged. Move the listed dependencies first, move the whole containing collection, or build the content in the synced collection to begin with (see "Moving content into or out of a synced collection").
 - Don't omit `-m` on `export` if the user wants a meaningful commit message — the default server-generated message is generic.
-- Don't `git-sync export` to `main`/`master` without explicit user confirmation — sync work is conventionally on a feature branch. See "Branch guard" above.
 - Don't reach for `mb setting set` to mark a collection as remote-synced — that endpoint writes single-key settings, not the bulk `collections` map. Use `mb git-sync add-collection <id>` / `mb git-sync remove-collection <id>` (above), and remember the toggle cascades to descendants.

package/skill-data/native-sql/SKILL.md

@@ -112,6 +112,6 @@ mb card query 12 --parameters '[{"type":"string/=","target":["dimension",["templ
 
 - Don't wrap a field filter in an operator (`WHERE col = {{ff}}`) — write it bare (`WHERE {{ff}}`).
 - Don't author the flat `{type:"native", …}` form — send the native stage above.
-- Don't use native SQL for DDL or multiple statements — the editor is read-only, single-statement; `CREATE`/`UPDATE`/`;`-chained SQL is unsupported. To materialize a table, use a `transform`; to write rows (`INSERT`/`UPDATE`/`DELETE`), use a data action (`data-action`).
+- Don't use native SQL for DDL or multiple statements — the editor is read-only, single-statement; `CREATE`/`UPDATE`/`;`-chained SQL is unsupported. To materialize a table, use a `transform`.
 - Don't expect `[[ ]]` to save you from a case/type mismatch — `WHERE plan = {{p}}` returns zero rows on a case-sensitive engine if the value's case is off; that's a value problem, not syntax.
 - Don't reach for native when a structured query fits — you lose the engine-independence and readability of an `mbql.stage/mbql` stage.

package/skill-data/transform/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: transform
-description: Author and run Metabase transforms via `mb` — body shape (native SQL or structured MBQL), create + run-with-wait, run inspection, dependencies, cancel, the `update`-vs-recreate iteration rule, the writable-keys-only PATCH contract, transform tests (fixtures and expectations run against temp tables), plus transform tags and tag-driven transform-job schedules. Load when the user touches transforms — "create a transform", "run a transform", "fix a failing transform", "test a transform", "list transform runs", "cancel a running transform", "manage transform tags", "run a transform job", or anything `mb transform …` / `mb transform-job …` / `mb transform-tag …` / `mb transform-test …`.
+description: Author and run Metabase transforms via `mb` — body shape (native SQL or structured MBQL), create + run-with-wait, run inspection, dependencies, cancel, the `update`-vs-recreate iteration rule, the writable-keys-only PATCH contract, plus transform tags and tag-driven transform-job schedules. Load when the user touches transforms — "create a transform", "run a transform", "fix a failing transform", "list transform runs", "cancel a running transform", "manage transform tags", "run a transform job", or anything `mb transform …` / `mb transform-job …` / `mb transform-tag …`.
 allowed-tools: Read, Write, Edit, Bash, AskUserQuestion
 requires: [transforms]
 ---
@@ -173,68 +173,6 @@ mb transform run "$ID" --wait --profile <n> --json     # → succeeded
 
 If you really must `create + delete` instead, do the `delete` **before** the first `git-sync export` so the failed entity never lands in git history — an export of a soft-failed state is noise that needs a follow-up cleanup commit. See `git-sync`, "Read state before mutating", for the ordering rule.
 
-<!-- requires: transformTests -->
-
-## Transform tests
-
-A transform test replaces every table the transform reads with a fixture, runs it into a temp table, and checks that output. The transform and the expectations read only the run's temp tables; a `format: "sql"` input runs verbatim against the transform's source database, so it may read real tables. Only query transforms (native SQL or MBQL) can be tested, and only on Postgres, MySQL, H2, ClickHouse, Redshift or SQL Server; otherwise `create`/`update`/`run` refuse with `transform-test.unsupported-transform` / `unsupported-driver` (422).
-
-```bash
-mb transform-test list --transform-id <id> --profile <n> --json  # --transform-id is optional
-mb transform-test get <id> --full --profile <n> --json        # --full for inputs/expectations
-mb transform-test create --file ./.scratch/test.json --profile <n> --json
-mb transform-test update <id> --file ./.scratch/patch.json --profile <n> --json
-mb transform-test delete <id> --yes --profile <n>
-mb transform-test run <id> --profile <n> --json               # exits 1 unless it passes
-```
-
-**`inputs`** — one per table the transform reads, each naming a `table` plus either `format: "sql"` with `sql`, or `format: "rows"` with `columns` (each a `name` and a `cast_type`) and `rows`.
-
-**`cast_type` is a `CAST` target, not a column type**, and the two vocabularies differ per warehouse: MySQL casts to `SIGNED` and reports `BIGINT`; ClickHouse takes `Nullable(Int32)` for a column that is `Int64`. So a body is warehouse-specific — don't copy a `database_type` out of a run result into a `cast_type`, and don't expect one body to run everywhere.
-
-**`expectations`** — `type: "empty"` with the `sql` that must return no rows, or `type: "equals"` with `format: "rows"` and the `columns` and `rows` the output must hold exactly. `equals` compares the rows as a multiset over the declared columns only, so an output column it does not declare is never checked. An `equals` without a `format` is refused, and one with `format: "sql"` is saved but reports `error` on every run, so its test can never pass.
-
-**Expectation SQL may only name the transform's target table and its declared input tables.** Those are rewritten to the run's temp tables; any other table is refused with `transform-test.unremapped-reference` (400), at `create`/`update` as well as `run`. A column qualified by its table name (`people.id`) is refused the same way, in expectation SQL and in the transform's own SQL alike: qualify by an alias (`FROM people p … p.id`) or leave the column bare — for the transform's SQL that means editing the transform. Expectation names are unique within a test (refused with "expectation names must be unique within a test"), and every `rows` row carries exactly its declared columns (refused naming the missing or undeclared columns).
-
-```json
-{
-  "transform_id": 1,
-  "name": "adults only",
-  "inputs": [
-    {
-      "table": { "schema": "public", "name": "people" },
-      "format": "rows",
-      "columns": [
-        { "name": "id", "cast_type": "INTEGER" },
-        { "name": "age", "cast_type": "INTEGER" }
-      ],
-      "rows": [
-        { "id": 1, "age": 30 },
-        { "id": 2, "age": 12 }
-      ]
-    }
-  ],
-  "expectations": [
-    {
-      "type": "equals",
-      "name": "exactly one row, id 1",
-      "format": "rows",
-      "columns": [{ "name": "id", "cast_type": "INTEGER" }],
-      "rows": [{ "id": 1 }]
-    },
-    {
-      "type": "empty",
-      "name": "no null ids",
-      "sql": "SELECT * FROM public.adults WHERE id IS NULL"
-    }
-  ]
-}
-```
-
-Create and update bodies are closed at every level (the top level is checked before sending; a stray nested key is a 400) — strip `id`, `entity_id`, `creator_id`, `created_at` and `updated_at` from a `get --full` body before sending it back.
-
-<!-- /requires -->
-
 ## Drop the materialized table (keep the transform)
 
 ```bash

package/dist/archive-3MQyc5Ih.mjs

@@ -1,32 +0,0 @@
-import { J as outputFlags, U as connectionFlags, Y as profileFlag, p as renderSummary } from "./cli.mjs";
-import { t as defineMetabaseCommand } from "./runtime-X6hVzSMW.mjs";
-import { t as parseId } from "./parse-id-CxHp2akh.mjs";
-import { t as DataAction } from "./data-action-DZxVB_hD.mjs";
-import { n as dataActionView } from "./data-action-R9qxJDPA.mjs";
-//#region src/commands/data-action/archive.ts
-var archive_default = defineMetabaseCommand({
-	meta: {
-		name: "archive",
-		description: "Archive (soft-delete) a data action by id"
-	},
-	requires: ["dataAction.archive"],
-	args: {
-		...outputFlags,
-		...profileFlag,
-		...connectionFlags,
-		id: {
-			type: "positional",
-			description: "Data action id",
-			required: true
-		}
-	},
-	outputSchema: DataAction,
-	examples: ["mb data-action archive 1"],
-	async run({ args, ctx, getClient }) {
-		const id = parseId(args.id);
-		const updated = await (await getClient()).dataAction.archive(id);
-		renderSummary(updated, dataActionView, `Archived data action ${updated.id} "${updated.name}".`, ctx);
-	}
-});
-//#endregion
-export { archive_default as default };

package/dist/card-P2-4BkXV.mjs

@@ -1,25 +0,0 @@
-import { t as defineCommandGroup } from "./group-D4w87fXL.mjs";
-//#region src/commands/card/index.ts
-var card_default = defineCommandGroup({
-	name: "card",
-	description: "Manage Metabase cards (questions, models, metrics)",
-	skills: [{
-		skill: "mbql",
-		purpose: "author the dataset_query"
-	}, {
-		skill: "visualization",
-		purpose: "choose display and visualization_settings"
-	}],
-	subCommands: {
-		list: () => import("./list-gqemddWB.mjs").then((mod) => mod.default),
-		get: () => import("./get-CWBN0G-4.mjs").then((mod) => mod.default),
-		query: () => import("./query-CsBe-kJn.mjs").then((mod) => mod.default),
-		alerts: () => import("./alerts-_ELZ12ye.mjs").then((mod) => mod.default),
-		create: () => import("./create-cqbpWaOi.mjs").then((mod) => mod.default),
-		update: () => import("./update-CHA4VWKT.mjs").then((mod) => mod.default),
-		verify: () => import("./verify-C2K-zMuQ.mjs").then((mod) => mod.default),
-		archive: () => import("./archive-CwBk5vxQ.mjs").then((mod) => mod.default)
-	}
-});
-//#endregion
-export { card_default as default };

package/dist/collection-BI8Fy9vS.mjs

@@ -1,21 +0,0 @@
-import { t as defineCommandGroup } from "./group-D4w87fXL.mjs";
-//#region src/commands/collection/index.ts
-var collection_default = defineCommandGroup({
-	name: "collection",
-	description: "Manage Metabase collections",
-	skills: [{
-		skill: "core",
-		purpose: "collection ref forms and the transforms namespace"
-	}],
-	subCommands: {
-		list: () => import("./list-C7PV9fYj.mjs").then((mod) => mod.default),
-		get: () => import("./get-xmhwvAQJ.mjs").then((mod) => mod.default),
-		items: () => import("./items-DNdICQ7M.mjs").then((mod) => mod.default),
-		tree: () => import("./tree-oBEw8hDj.mjs").then((mod) => mod.default),
-		create: () => import("./create-BfA1pnmS.mjs").then((mod) => mod.default),
-		update: () => import("./update-BqrZ-8IK.mjs").then((mod) => mod.default),
-		archive: () => import("./archive-ZnHzMJaM.mjs").then((mod) => mod.default)
-	}
-});
-//#endregion
-export { collection_default as default };

package/dist/create--b64pMVM.mjs

@@ -1,34 +0,0 @@
-import { J as outputFlags, U as connectionFlags, Y as profileFlag, p as renderSummary } from "./cli.mjs";
-import { t as defineMetabaseCommand } from "./runtime-X6hVzSMW.mjs";
-import { t as readBody } from "./body-BVrHLwJU.mjs";
-import { t as bodyInputFlags } from "./body-flags-AqKpN01Y.mjs";
-import { r as TransformTestCreateInput, t as TransformTest } from "./transform-test-BjjCQ2xm.mjs";
-import { n as transformTestView } from "./transform-test-DHGKeuHa.mjs";
-//#region src/commands/transform-test/create.ts
-var create_default = defineMetabaseCommand({
-	meta: {
-		name: "create",
-		description: "Create a transform test from JSON"
-	},
-	details: "The JSON body needs a `transform_id`, a `name`, the `inputs` standing in for every table the transform reads, and the `expectations` checked against its output. An input names its `table` and carries either `format: \"sql\"` with a `sql` query or `format: \"rows\"` with `columns` and `rows`. An expectation is either `type: \"empty\"` with the `sql` that must return nothing, or `type: \"equals\"` with `format: \"rows\"` and the `columns` and `rows` the output must hold exactly. The body is closed at every level: a test read back with `get --full` has to shed `id`, `entity_id`, `creator_id`, `created_at` and `updated_at` before it can be sent.",
-	requires: ["transformTest.create"],
-	args: {
-		...outputFlags,
-		...profileFlag,
-		...connectionFlags,
-		...bodyInputFlags
-	},
-	inputSchema: TransformTestCreateInput,
-	outputSchema: TransformTest,
-	examples: ["cat transform-test.json | mb transform-test create", "mb transform-test create --file transform-test.json"],
-	async run({ args, ctx, getClient }) {
-		const body = await readBody({
-			flag: args.body,
-			file: args.file
-		}, TransformTestCreateInput);
-		const created = await (await getClient()).transformTest.create(body);
-		renderSummary(created, transformTestView, `Created transform test ${created.id} "${created.name}".`, ctx);
-	}
-});
-//#endregion
-export { create_default as default };

package/dist/create-C7fVbQbQ.mjs

@@ -1,48 +0,0 @@
-import { J as outputFlags, U as connectionFlags, Y as profileFlag, p as renderSummary } from "./cli.mjs";
-import { t as defineMetabaseCommand } from "./runtime-X6hVzSMW.mjs";
-import { t as readBody } from "./body-BVrHLwJU.mjs";
-import { t as bodyInputFlags } from "./body-flags-AqKpN01Y.mjs";
-import { r as DataActionCreateInput, t as DataAction } from "./data-action-DZxVB_hD.mjs";
-import { n as DATA_ACTION_DATASET_QUERY_LABELS, o as preflightMbql5Query, s as skipValidateFlag } from "./validate-query-DIcK8alR.mjs";
-import { n as dataActionView } from "./data-action-R9qxJDPA.mjs";
-//#region src/commands/data-action/create.ts
-var create_default = defineMetabaseCommand({
-	meta: {
-		name: "create",
-		description: "Create a data action from JSON"
-	},
-	details: "A data action is a parameterized native query that writes to a database, filed in a collection. The JSON body needs `name`, `type: \"query\"`, `database_id`, a native `dataset_query` whose `{{tag}}` placeholders are its inputs, and `parameters` targeting those tags; `collection_id` picks the collection (omit for the root). Data actions must be enabled on the database. An MBQL 5 `dataset_query` is checked against a bundled JSON Schema before sending; pass --skip-validate to bypass.",
-	skills: [{
-		skill: "data-action",
-		purpose: "author a data action and its parameters"
-	}, {
-		skill: "native-sql",
-		purpose: "the native query and its template tags"
-	}],
-	requires: ["dataAction.create"],
-	args: {
-		...outputFlags,
-		...profileFlag,
-		...connectionFlags,
-		...bodyInputFlags,
-		...skipValidateFlag
-	},
-	inputSchema: DataActionCreateInput,
-	outputSchema: DataAction,
-	examples: [
-		"cat data-action.json | mb data-action create",
-		"mb data-action create --file data-action.json",
-		"mb data-action create --file data-action.json --skip-validate"
-	],
-	async run({ args, ctx, getClient }) {
-		const body = await readBody({
-			flag: args.body,
-			file: args.file
-		}, DataActionCreateInput);
-		preflightMbql5Query(body.dataset_query, DATA_ACTION_DATASET_QUERY_LABELS, { skip: args["skip-validate"] === true });
-		const created = await (await getClient()).dataAction.create(body);
-		renderSummary(created, dataActionView, `Created data action ${created.id} "${created.name}".`, ctx);
-	}
-});
-//#endregion
-export { create_default as default };

package/dist/dashboard-C-YJxDam.mjs

@@ -1,35 +0,0 @@
-import { t as defineCommandGroup } from "./group-D4w87fXL.mjs";
-//#region src/commands/dashboard/index.ts
-var dashboard_default = defineCommandGroup({
-	name: "dashboard",
-	description: "Manage Metabase dashboards",
-	skills: [
-		{
-			skill: "dashboard",
-			purpose: "wiring filters, linked filters, cross-filtering, click behavior, tabs"
-		},
-		{
-			skill: "visualization",
-			purpose: "dashcard display and visualization_settings"
-		},
-		{
-			skill: "core",
-			purpose: "the 24-column dashcard grid layout"
-		}
-	],
-	subCommands: {
-		list: () => import("./list-__Q79YXk.mjs").then((mod) => mod.default),
-		get: () => import("./get-BvUNnNRq.mjs").then((mod) => mod.default),
-		cards: () => import("./cards-B1pyPl77.mjs").then((mod) => mod.default),
-		"parameter-values": () => import("./parameter-values-BY2WA9qg.mjs").then((mod) => mod.default),
-		subscriptions: () => import("./subscriptions-DIRsHcKP.mjs").then((mod) => mod.default),
-		create: () => import("./create-BzE4q6F_.mjs").then((mod) => mod.default),
-		update: () => import("./update-D9eLVWFQ.mjs").then((mod) => mod.default),
-		"update-dashcard": () => import("./update-dashcard-DNsf-gJ1.mjs").then((mod) => mod.default),
-		copy: () => import("./copy-DAKdksBm.mjs").then((mod) => mod.default),
-		verify: () => import("./verify-CA4PEHlO.mjs").then((mod) => mod.default),
-		archive: () => import("./archive-D22VL5Bx.mjs").then((mod) => mod.default)
-	}
-});
-//#endregion
-export { dashboard_default as default };

package/dist/data-action-DER3EMD7.mjs

@@ -1,24 +0,0 @@
-import { t as defineCommandGroup } from "./group-D4w87fXL.mjs";
-//#region src/commands/data-action/index.ts
-var data_action_default = defineCommandGroup({
-	name: "data-action",
-	description: "Manage Metabase data actions",
-	skills: [{
-		skill: "data-action",
-		purpose: "author and run data actions"
-	}, {
-		skill: "native-sql",
-		purpose: "the data action's native query and its template tags"
-	}],
-	subCommands: {
-		list: () => import("./list-Owrzgtkc.mjs").then((mod) => mod.default),
-		get: () => import("./get-BwKQw_rR.mjs").then((mod) => mod.default),
-		create: () => import("./create-C7fVbQbQ.mjs").then((mod) => mod.default),
-		update: () => import("./update-Bdi40RG0.mjs").then((mod) => mod.default),
-		archive: () => import("./archive-3MQyc5Ih.mjs").then((mod) => mod.default),
-		delete: () => import("./delete-B0O-mf63.mjs").then((mod) => mod.default),
-		execute: () => import("./execute-DvBse4aF.mjs").then((mod) => mod.default)
-	}
-});
-//#endregion
-export { data_action_default as default };