@metabase/cli 0.5.4 → 0.5.5

package/skill-data/data-app-filters/SKILL.md

@@ -19,12 +19,13 @@ Before any control, write one row per filter: the question that gives its option
 | Plan      | orders broken out by plan  | plan text    | orders                 | revenue, stock |
 
 - A filter in the page's global bar changes every panel that can take it. One that can't reach a panel is scoped to its section, visibly, or left out. A KPI and its detail table about the same thing take the same filters, unless the UI says why not.
+- A KPI on an aggregated question shows one complete bucket (`data-app-data`, _Runtime clauses_): it gets its own control of one-bucket presets starting at the last complete bucket, never All time, rather than a shared bar's ranges.
 - One date control per scope. Never a global date range beside a page-specific date where one of the two does nothing; a page whose cards use another date column gets one control for that column.
 - Build each panel's clauses from its own question's columns, inline at its hook call. Never reuse an array built for another question.
 
 ## Values and options
 
-- Every filter starts at **All**. Keep it as `"all"` in state and send it as no clause (`[]`); treat `""`, `null` and `undefined` the same way. In a Yes/No/All filter, Yes and No each filter (`true`, `false`), and only All sends nothing.
+- Every filter starts at **All**, except a KPI's own date control (above). Keep it as `"all"` in state and send it as no clause (`[]`), except on an aggregated question whose panel doesn't show the filtered column, where All is its own question (`data-app-data`, _Runtime clauses_); treat `""`, `null` and `undefined` the same way. In a Yes/No/All filter, Yes and No each filter (`true`, `false`), and only All sends nothing.
 - Options come at runtime from their own question in the app's collection, broken out on the filtered column — never hardcoded unless the user gave a closed list. Dedupe them from its rows, and keep the label apart from the value.
 - Filter by a stable raw value (an id) and show its label; never filter by a display label when an id exists, and never feed free text into an exact-id filter.
 - All stays selectable while options load, come back empty or fail; don't disable the control. When fresh options no longer hold the selected value, reset to All:
@@ -48,7 +49,7 @@ Any list whose options come from a question — an id shown as a name, a categor
 
 ## Date ranges
 
-A preset bar lists the durations, then All time, then Custom last — leave Custom out only if the user asked for fixed presets. Every option ends in the same `[start, end]` range (All time is `[null, null]`), so one `between` filter serves them all. Custom is `DateRangePopover` around your own trigger, or `DateRangeCalendar` inline, both from `@metabase/embedding-sdk-react/data-app`. No date-picker library and no `<input type="date">` for a range.
+A preset bar lists the durations, then All time, then Custom last — leave Custom out only if the user asked for fixed presets, or the bar filters an aggregated question, which offers only whole, complete buckets and no All time on a KPI (`data-app-data`, _Runtime clauses_). Every option ends in the same `[start, end]` range (All time is `[null, null]`), so one `between` filter serves them all. Custom is `DateRangePopover` around your own trigger, or `DateRangeCalendar` inline, both from `@metabase/embedding-sdk-react/data-app`. No date-picker library and no `<input type="date">` for a range.
 
 ```tsx
 import { DateRangePopover, filter, useDateFormatter } from "@metabase/embedding-sdk-react/data-app";
@@ -68,7 +69,7 @@ const [start, end] = range;
 - Label it with `formatDateRange(range)` (or `formatDate` for one end), which formats in the instance's locale; both take a dayjs `format`, and `formatDateRange` a `separator`. It returns `""` until the SDK loads. Never `new Date("YYYY-MM-DD")`: a date-only string parses as UTC and shows the previous day west of Greenwich.
 - The popover closes once both ends are picked (`closeOnSelect`); `opened` and `onOpenedChange` control it yourself. Also `defaultValue`, `minDate` and `maxDate` (`YYYY-MM-DD`), `numberOfColumns` (default 2) and `position` (default `bottom-start`). `DateRangeCalendar` takes the same value props plus `className` and `style`.
 
-A preset's range, from local dates — never `toISOString()`, which shifts the day:
+A preset's range, from local dates — never `toISOString()`, which shifts the day. `lastMonths` is a rolling window, for a rows question; on a month question, `lastCompleteMonths` gives bucket starts:
 
 ```ts
 const ymd = (d: Date) =>
@@ -78,10 +79,17 @@ const lastMonths = (n: number): [string, string] => {
   const start = new Date(end.getFullYear(), end.getMonth() - n, end.getDate());
   return [ymd(start), ymd(end)];
 };
+const lastCompleteMonths = (n: number): [string, string] => {
+  const now = new Date();
+  return [
+    ymd(new Date(now.getFullYear(), now.getMonth() - n, 1)),
+    ymd(new Date(now.getFullYear(), now.getMonth() - 1, 1)),
+  ];
+};
 ```
 
 **A single date or a date-time** is the one case for a library: `npm install react-datepicker`, import `react-datepicker/dist/react-datepicker.css`, type the callback (`(date: Date | null) => …`), and convert with `ymd` above. Pass `null`, never `new Date("")`, for an empty value.
 
 ## Check
 
-For every visible filter: All runs the unfiltered question; its options come from a question; each option changes every panel the contract says it reaches, and no other; a preset bar ends with Custom; and no scope has two date controls. Search the filter controls for `<select` and `type="date"` — an action form keeps its date inputs. Then build and publish (`data-app`, _Build and publish_).
+For every visible filter except a KPI's own date control: All runs the unfiltered question, or its All question; its options come from a question; each option changes every panel the contract says it reaches, and no other; a preset bar ends with Custom unless it filters an aggregated question; and no scope has two date controls. Search the filter controls for `<select` and `type="date"` — an action form keeps its date inputs. Then build and publish (`data-app`, _Build and publish_).

package/skill-data/data-app-ui/SKILL.md

@@ -35,7 +35,7 @@ Everything here runs inside the sandbox, the same in the dev preview as in Metab
 | `navigator.geolocation` and other device APIs                                                              | Nothing.                                                                                  |
 | Key, input, composition and clipboard listeners (`keydown`, `paste`, `input`, …) on `window` or `document` | A React handler (`onKeyDown`, `onPaste`, …) on your own element.                          |
 
-**External APIs.** A raw `fetch` reaches only the origins in the app's `allowed_hosts`, exact or with a `*.` subdomain wildcard: `mb data-app update <slug> --body '{"allowed_hosts":["https://api.example.com"]}'`, plus an `allowed_hosts:` list in `data_app.yaml` beside `package.json` for the preview, then restart `npm run dev`. Never list the Metabase URL. In Metabase the same list governs `<iframe src>` and native `<form action>` submits, and the target must allow framing; the preview blocks both. Use `<form onSubmit>` with `preventDefault`: a native submit navigates the app away.
+**External APIs.** A raw `fetch` reaches only the origins in the app's `allowed_hosts`, exact or with a `*.` subdomain wildcard: `mb data-app update <slug> --body '{"allowed_hosts":["https://api.example.com"]}'`. The preview reads the `allowed_hosts:` list in `data_app.yaml` beside `package.json`: in a synced repository that file is the app's exported manifest, so export again and pull the export branch (`data-app`, _Move to another instance_) to refresh it rather than writing it; without one, write the list there yourself. Then restart `npm run dev`. Never list the Metabase URL. In Metabase the same list governs `<iframe src>` and native `<form action>` submits, and the target must allow framing; the preview blocks both. Use `<form onSubmit>` with `preventDefault`: a native submit navigates the app away.
 
 ## Layout
 
@@ -69,12 +69,12 @@ export function AppError({ message }: SdkErrorComponentProps) {
 
 ## SDK components
 
-| Import                                                                           | For                                                                   |
-| -------------------------------------------------------------------------------- | --------------------------------------------------------------------- |
-| `StaticQuestion`                                                                 | A chart, KPI or table without drill-through — the default.            |
-| `InteractiveQuestion`                                                            | One meant to be explored: drill-through, chart switching, the editor. |
-| `StaticDashboard`, `InteractiveDashboard`, `EditableDashboard`                   | A dashboard.                                                          |
-| `CreateQuestion`, `MetabotQuestion`, `CollectionBrowser`, `CreateDashboardModal` | Authoring flows, rarely in an app.                                    |
+| Import                | For                                                                                     |
+| --------------------- | --------------------------------------------------------------------------------------- |
+| `StaticQuestion`      | A chart, KPI or table without drill-through — the default.                              |
+| `InteractiveQuestion` | One meant to be explored: drill-through, chart switching; pass `isSaveEnabled={false}`. |
+
+Both take a question in the app's collection. Dashboards and the authoring components (`CreateQuestion`, `CreateDashboardModal`, saving from the editor) don't work in an app: its collection can't hold a dashboard, and an app can't save content.
 
 ## A Metabase chart or your own
 
@@ -82,13 +82,13 @@ Ask "can Metabase draw this at all?", never "which looks closer to the design?"
 
 - **Yes** — bar, line, area, combo, row, pie, scalar, smartscalar, gauge, progress, funnel, scatter, waterfall, boxplot, sankey, pivot, map, tables: render it with `useMetabaseQueryObject` and `StaticQuestion` (`data-app-data`). It keeps the instance's formatting, tooltips, theming and drill-through. Styling is never a reason to draw it yourself.
 - **No**, or the user asked for a custom one — scorecards, timelines, calendar grids, one visual from several queries: draw it from `useMetabaseQuery` rows, with SVG or a chart library the app already has.
-- A KPI is `scalar`, `smartscalar`, `gauge` or `progress`; put what Metabase doesn't draw (a caption, stars) beside it.
+- A KPI is `scalar`, `smartscalar`, `gauge` or `progress` — on a question filtered at runtime to one bucket, `scalar` (a `smartscalar` loses its comparison); put what Metabase doesn't draw (a caption, stars) beside it.
 - `InteractiveQuestion`: pass `isSaveEnabled={false}`, and `title={false}` in a panel with its own heading. Children replace its layout: `<InteractiveQuestion card={card}><InteractiveQuestion.QuestionVisualization height={360} /></InteractiveQuestion>` is the chart alone.
 
-**Visualization settings.** Add `visualizationSettings` only for a change the user asked for. Their keys are a question's `visualization_settings` keys — the `visualization` skill lists them — and the installed types decide what's legal: `rg -n "<key>|declare type .*VisualizationSettings" node_modules/@metabase/embedding-sdk-react/dist/index.d.ts`, never the whole file, never from memory. Keep them few: keys such as `graph.dimensions`, `pie.metric` and `column_settings` name result columns and break when the question changes.
+**Visualization settings.** Add `visualizationSettings` only for a change the user asked for, or `scalar.field` on a KPI whose first column isn't the number. Their keys are a question's `visualization_settings` keys — the `visualization` skill lists them — and the installed types decide what's legal: `rg -n "<key>|declare type .*VisualizationSettings" node_modules/@metabase/embedding-sdk-react/dist/index.d.ts`, never the whole file, never from memory. Keep them few: keys such as `graph.dimensions`, `pie.metric` and `column_settings` name result columns and break when the question changes.
 
 - A `table` with two breakouts and one aggregation renders as a pivot when a breakout has at most 16 values; `{ "table.pivot": false }` keeps one row per group.
-- A scalar shows the first column: with a key column first, point it at the number with `{ "scalar.field": "avg_rating" }`.
+- A scalar shows the first column: with a key or breakout column first (a date on a month question), point it at the number with `{ "scalar.field": "avg_rating" }`.
 - A header: `column_settings: { '["name","approvers"]': { column_title: "Approvers" } }`.
 
 ## Pages
@@ -117,4 +117,4 @@ Metabase mirrors each route to `/apps/<slug>/<path>`, and a reload there opens t
 
 ## Before handoff
 
-`npm run dev` only transpiles: run `npm run typecheck` after every round of edits and fix what it reports, and report the result, errors grouped by cause. Search the changed files and fix what turns up: `card={{` (every `card` comes from `useMemo`), `row[0]` and `as unknown as` (rows are keyed by column name), `<select` for a list from a question (`data-app-filters`), `type="date"` and `new Date(` in a date filter, `* 100` and `%`. Read the diagnostics feed with every panel mounted, then build and publish (`data-app`, _Build and publish_).
+`npm run dev` only transpiles: run `npm run typecheck` after every round of edits and fix what it reports, and report the result, errors grouped by cause. Search the changed files and fix what turns up: `card={{` (every `card` comes from `useMemo`), `row[0]` and `as unknown as` (rows are keyed by column name), `<select` for a list from a question (`data-app-filters`), `type="date"` and `new Date("` (a date string parsed as UTC) in a date filter, `* 100` and `%`. Read the diagnostics feed with every panel mounted, then build and publish (`data-app`, _Build and publish_).

package/skill-data/data-workflow/references/reusable-definitions.md

@@ -49,7 +49,7 @@ Two things never bend in any mode: when genuinely unsure, **ask** (the Shared Co
   - "Let me filter to just the active ones" → a **segment** (saved filter).
   - "Let me add up revenue the same way everywhere, on this table" → a **measure** on the table.
   - "Revenue is an _official company number_ people pull onto dashboards" → a **metric** in a collection, with a default month-by-month view so it charts cleanly. Lean: make it a metric when it's a headline figure the org reuses across many questions/dashboards; keep it a measure when it's a table-local convenience.
-- **Where the metric lives.** Metrics sit in a collection (folder). Lean: put the org's blessed ones in the shared **Library** so they surface prominently; keep experimental ones in a working collection until trusted.
+- **Where the metric lives.** Metrics sit in a collection (folder). Lean: put the org's blessed ones in the Library's **Metrics** collection so they surface prominently; keep experimental ones in a working collection until trusted.
 <!-- requires: library -->
 - **Publish the official tables to the Library.** The clean, analysis-ready tables your definitions sit on are the org's official starting points — the **Library** is how you mark them as such. Tables published to the Library's **Data** section appear _first_ when anyone picks a data source, nudging people toward your curated tables instead of raw warehouse ones. Lean: publish the wide clean tables you built the semantic layer on; hold back raw or half-built ones. Surface which tables you'd publish and confirm. (Only admins and data analysts can publish — mechanics in `core`.)
 <!-- /requires -->
@@ -102,7 +102,7 @@ Build each agreed definition. The verb mechanics (create/update flags, the `revi
 
 - **Segment** → `mb segment create`. A flat MBQL filter clause on a table.
 - **Measure** → `mb measure create`. **Exactly one** aggregation on a table.
-- **Metric** → `mb card create` with the metric shape (`type: "metric"`) — it lives in a **collection**, carries the aggregation plus an optional default time dimension. Put org-blessed ones in the Library collection.
+- **Metric** → `mb card create` with the metric shape (`type: "metric"`) — it lives in a **collection**, carries the aggregation plus an optional default time dimension. Put org-blessed ones in the Library's **Metrics** collection (id from `mb library get`).
 <!-- requires: library -->
 - **Publish the official tables** → `mb library create` then `mb library publish` (mechanics in `core`) to move the clean tables your definitions sit on into the Library's **Data** section, so people start from your curated set, not raw warehouse tables.
 <!-- /requires -->

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

@@ -7,7 +7,7 @@ requires: [remoteSync]
 
 # git-sync (representations ↔ instance)
 
-Metabase content (cards, dashboards, transforms, snippets, collections, …) can live in a git repo as YAML and round-trip in and out of a Metabase instance via the `git-sync` verbs. The instance is configured with a `remote-sync-*` settings block (URL, branch, token, type read-only/read-write); the CLI drives the sync tasks against `/api/ee/remote-sync/*`. Only collections flagged for sync serialize; everything else is local-only. Table and field metadata round-trips too, for Library-published tables in a flagged collection — see "Published table metadata" below.
+Metabase content (cards, dashboards, transforms, snippets, collections, …) can live in a git repo as YAML and round-trip in and out of a Metabase instance via the `git-sync` verbs. The instance is configured with a `remote-sync-*` settings block (URL, branch, token, type read-only/read-write); the CLI drives the sync tasks against `/api/ee/remote-sync/*`. Only flagged collections serialize, plus, unflagged: each data app's collection (with its app, `data_apps/<slug>/`), transforms (`remote-sync-transforms`), and snippets, data actions and glossary once the Library is synced. Everything else is local-only. Table and field metadata round-trips too, for Library-published tables in a flagged collection — see "Published table metadata" below.
 
 The repo and the instance are two ends of the same state; what "push my changes" means depends on where the changes were made. If they were made **in the instance** (CLI verbs against a read-write instance — cards edited, transforms created, tables published, metadata written), "push my changes" / "save this to the repo" / "open a PR with these changes" means driving the instance's export to a branch (`stash` or `create-branch` + `export`) and opening the PR from that branch — not reconstructing the changes as files. If the workflow is **repo-first** (content YAML edited in the repo, the instance imports it), plain `git` against the repo is the way — but only in the serialized layout already there: files in paths or formats the serializer doesn't own are invisible to Metabase and never apply on import.
 
@@ -64,7 +64,7 @@ Workflow:
 
 <!-- requires: remoteSyncRemoteChanges -->
 
-Between the two, confirm `has-remote-changes` reports `has_changes: true` — there's actually something to import.
+Between the two, confirm `has-remote-changes` reports `has_changes: true` (`--force-refresh` after your own push: the answer is cached).
 
 <!-- /requires -->
 
@@ -168,7 +168,7 @@ Skip the prompt only if the user's instructions already specified the branch (e.
 ```bash
 mb git-sync branches --profile <n> --json                 # list remote branches
 mb git-sync create-branch <name> --profile <n>            # create + switch sync to it
-mb git-sync stash --profile <n>                           # export current state to a NEW branch
+mb git-sync stash --new-branch <name> --profile <n>       # export current state to a NEW branch
 ```
 
 `stash` is the safe move when the instance has team work you don't want to lose, but you need to pivot to a different branch (`import` would discard, `export --force` would overwrite). It exports current state to a fresh branch first.
@@ -184,19 +184,21 @@ Use `wait` after `import --no-wait` / `export --no-wait`. Use `cancel-task` if a
 
 ## Adding / removing a directory (collection) to sync
 
-The set of directories under sync is governed by which **collections** carry `is_remote_synced: true`. Every collection so flagged serializes to its own folder under `collections/` in the repo; everything outside that set is local-only. The CLI exposes per-collection toggles that route to the underlying bulk endpoint (`PUT /api/ee/remote-sync/settings`):
+The set of directories under sync is governed by which **collections** carry `is_remote_synced: true`. Every collection so flagged serializes to its own folder under `collections/` in the repo; so do the unflagged ones above (a data app's collection can't be flagged). Everything else is local-only. Toggle one collection at a time:
 
 ```bash
 mb git-sync add-collection    <collection-id> --profile <n> --json
 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`).
+`<collection-id>` is a **positive integer** (no nano-id, `root` or `trash`). Get the id from `collection list` (see `core`).
 
-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).
+Both return `{ success: true }`, plus a `task_id` when the toggle started a follow-up task.
 
 **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.
 
+**Custom collections.** Outside the Library, transforms, snippets and data actions, a flag answers 400 unless the admin setting `remote-sync-custom-collections-enabled` is on (a data app's collection can't be flagged at all).
+
 **Mode prerequisite.** The server rejects toggles while `remote-sync-type` is `:read-only` (the install default; `mb git-sync status --json` reports it as `sync_type`). If `mb git-sync add-collection 12` returns `Metabase returned 400 … Cannot change synced collections when remote-sync-type is read-only.`, switch first with:
 
 ```bash
@@ -237,13 +239,13 @@ To plan the order before the first move, `mb dependency graph dashboard <id> --j
 
 ## Published table metadata (Library) and sync scope
 
-Table and field metadata — table/field descriptions, semantic types (`type/PK`, `type/FK`), FK targets, plus segments and measures on the table — serializes for **Library-published tables only**, under `databases/<db>/schemas/<schema>/tables/<table>/…` in the repo. Eligibility is two-gated: the table must be published (`mb library publish`), **and** the Library collection holding it must itself carry `is_remote_synced: true`. An ordinary warehouse table, or a transform's target table that isn't published, never serializes — a transform's YAML carries only the transform definition (query, target, description), not the output table's field metadata.
+Table and field metadata — table/field descriptions, semantic types (`type/PK`, `type/FK`), FK targets, plus segments and measures on the table — serializes for **Library-published tables only**, under `databases/<db>/schemas/<schema>/tables/<table>/…` in the repo. Eligibility is two-gated: the table must be published (`mb library publish`), **and** Library Data must be synced; flag the Library root, as Data alone leaves out Metrics, Dashboards, snippets, data actions and glossary. An ordinary warehouse table, or a transform's target table that isn't published, never serializes — a transform's YAML carries only the transform definition (query, target, description), not the output table's field metadata.
 
-The classic trap: publish tables, write field metadata, then `git-sync dirty` comes back empty and nothing lands in the repo. That does not mean git-sync can't carry table metadata — it means the Library collection isn't in the sync scope, so nothing was eligible for dirty-tracking when the writes happened. Check the scope (`synced_collections` in `status`), then:
+The classic trap: publish tables, write field metadata, then `git-sync dirty` comes back empty and nothing lands in the repo. It means the Library collection isn't in the sync scope, so nothing was eligible for dirty-tracking when the writes happened. Check the scope (`synced_collections` in `status`), then:
 
 ```bash
-mb library get --profile <n> --json                                # Library Data collection id
-mb git-sync add-collection <library-data-id> --profile <n>
+mb collection list --profile <n> --json                            # the "type": "library" entry's id
+mb git-sync add-collection <library-id> --profile <n>
 mb git-sync stash --new-branch <branch> -m "..." --profile <n>     # or create-branch + export
 ```
 
@@ -256,7 +258,7 @@ Flagging the collection records it for the next export, which serializes its cur
 - 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 git-sync status --profile <n> --json` reports `remote_configured: false` when no remote is configured.
+- Don't drive `git-sync` against a Metabase instance that doesn't have remote-sync configured — import, export, has-remote-changes and export-preflight answer `Remote sync is not configured.` To check: `mb git-sync status --profile <n> --json` succeeds and reports `remote_configured: false`.
 - 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.

package/dist/git-sync-Czena0TW.mjs

@@ -1,29 +0,0 @@
-import { t as defineCommandGroup } from "./group--6adAsqG.mjs";
-//#region src/commands/git-sync/index.ts
-var git_sync_default = defineCommandGroup({
-	name: "git-sync",
-	description: "Sync Metabase content with a git remote",
-	skills: [{
-		skill: "git-sync",
-		purpose: "import/export round-trip and dirty checks"
-	}],
-	subCommands: {
-		status: () => import("./status-BezD_K-g.mjs").then((mod) => mod.default),
-		"is-dirty": () => import("./is-dirty-haRLODo1.mjs").then((mod) => mod.default),
-		"has-remote-changes": () => import("./has-remote-changes-DZq7q2Wk.mjs").then((mod) => mod.default),
-		dirty: () => import("./dirty-BHwdHOEj.mjs").then((mod) => mod.default),
-		"current-task": () => import("./current-task-DhgwtGN3.mjs").then((mod) => mod.default),
-		"cancel-task": () => import("./cancel-task-BuZsQuLp.mjs").then((mod) => mod.default),
-		wait: () => import("./wait-DEYagfq4.mjs").then((mod) => mod.default),
-		import: () => import("./import-DKZF0kMU.mjs").then((mod) => mod.default),
-		export: () => import("./export-BNj3RvAl.mjs").then((mod) => mod.default),
-		"export-preflight": () => import("./export-preflight-F3OapAD5.mjs").then((mod) => mod.default),
-		stash: () => import("./stash-leoW1fby.mjs").then((mod) => mod.default),
-		branches: () => import("./branches-CERgKqFq.mjs").then((mod) => mod.default),
-		"create-branch": () => import("./create-branch-D_nbKxDS.mjs").then((mod) => mod.default),
-		"add-collection": () => import("./add-collection-D2x34KVO.mjs").then((mod) => mod.default),
-		"remove-collection": () => import("./remove-collection-Qne5ww6M.mjs").then((mod) => mod.default)
-	}
-});
-//#endregion
-export { git_sync_default as default };

package/dist/table-Dzp1uANs.mjs

@@ -1,26 +0,0 @@
-import { t as defineCommandGroup } from "./group--6adAsqG.mjs";
-//#region src/commands/table/index.ts
-var table_default = defineCommandGroup({
-	name: "table",
-	description: "Manage Metabase tables",
-	skills: [{
-		skill: "metadata",
-		purpose: "table and column metadata, semantic types, visibility"
-	}],
-	subCommands: {
-		list: () => import("./list-P7FnSsbZ.mjs").then((m) => m.default),
-		get: () => import("./get-uHs9Ve-4.mjs").then((m) => m.default),
-		fields: () => import("./fields-BkAS_wIA.mjs").then((m) => m.default),
-		fks: () => import("./fks--SaqvPw1.mjs").then((m) => m.default),
-		update: () => import("./update-Zv7PP8nl.mjs").then((m) => m.default),
-		"sync-schema": () => import("./sync-schema-BtjC-PNY.mjs").then((m) => m.default),
-		"rescan-values": () => import("./rescan-values-COzM86P5.mjs").then((m) => m.default),
-		"discard-values": () => import("./discard-values-BWlh2ce8.mjs").then((m) => m.default),
-		"bulk-edit": () => import("./bulk-edit-CJxoxDGQ.mjs").then((m) => m.default),
-		"bulk-sync-schema": () => import("./bulk-sync-schema-CBIs4yHs.mjs").then((m) => m.default),
-		"bulk-rescan-values": () => import("./bulk-rescan-values-DflzyxEj.mjs").then((m) => m.default),
-		"bulk-discard-values": () => import("./bulk-discard-values-BQ3z6nJb.mjs").then((m) => m.default)
-	}
-});
-//#endregion
-export { table_default as default };

package/dist/transform-C-0nV5Et.mjs

@@ -1,28 +0,0 @@
-import { t as defineCommandGroup } from "./group--6adAsqG.mjs";
-//#region src/commands/transform/index.ts
-var transform_default = defineCommandGroup({
-	name: "transform",
-	description: "Manage Metabase transforms",
-	skills: [{
-		skill: "transform",
-		purpose: "body shape, run-with-wait, iterate"
-	}, {
-		skill: "mbql",
-		purpose: "MBQL source.query bodies"
-	}],
-	subCommands: {
-		list: () => import("./list-BiIZdUoN.mjs").then((mod) => mod.default),
-		get: () => import("./get-BjgB5l7X.mjs").then((mod) => mod.default),
-		dependencies: () => import("./dependencies-D6SNdLW8.mjs").then((mod) => mod.default),
-		create: () => import("./create-DEIIUohY2.mjs").then((mod) => mod.default),
-		update: () => import("./update-CEDMvgJI.mjs").then((mod) => mod.default),
-		delete: () => import("./delete-ZjLpkwgx.mjs").then((mod) => mod.default),
-		"delete-table": () => import("./delete-table-CnGv1gx9.mjs").then((mod) => mod.default),
-		run: () => import("./run-JYNbEO_V.mjs").then((mod) => mod.default),
-		cancel: () => import("./cancel-CyTRWSOr.mjs").then((mod) => mod.default),
-		"get-run": () => import("./get-run-CHup8cMl.mjs").then((mod) => mod.default),
-		runs: () => import("./runs-GQD6FO2k.mjs").then((mod) => mod.default)
-	}
-});
-//#endregion
-export { transform_default as default };

package/dist/transform-job-B9MPk7S5.mjs

@@ -1,22 +0,0 @@
-import { t as defineCommandGroup } from "./group--6adAsqG.mjs";
-//#region src/commands/transform-job/index.ts
-var transform_job_default = defineCommandGroup({
-	name: "transform-job",
-	description: "Manage Metabase transform jobs",
-	skills: [{
-		skill: "transform",
-		purpose: "tag-driven job schedules"
-	}],
-	subCommands: {
-		list: () => import("./list-OUSeeuXb.mjs").then((mod) => mod.default),
-		get: () => import("./get-gGSl7Se4.mjs").then((mod) => mod.default),
-		create: () => import("./create-XVjr8IDS.mjs").then((mod) => mod.default),
-		update: () => import("./update-7iXRB23T2.mjs").then((mod) => mod.default),
-		delete: () => import("./delete-CuyGTe0i.mjs").then((mod) => mod.default),
-		run: () => import("./run-Bwj4Uuxk.mjs").then((mod) => mod.default),
-		transforms: () => import("./transforms-DcXL4Dox.mjs").then((mod) => mod.default),
-		"set-active": () => import("./set-active-CWDdv3kN.mjs").then((mod) => mod.default)
-	}
-});
-//#endregion
-export { transform_job_default as default };