@metabase/cli 0.1.18 → 0.2.1-alpha.bcm-ghy-4075-spawn-default-profile.eb120d1

package/skill-data/core/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: core
-description: Foundations for driving Metabase from the terminal with the `mb` CLI — authentication and named profiles, the flag/output/`--json` conventions every command shares, JSON body input, command discovery via `mb __manifest`, and the per-resource footguns (db, table, field, card, dashboard, collection, segment, measure, library, setting, search, eid). Load first for any `mb` task; it routes to the specialized skills for deeper work.
+description: Foundations for driving Metabase from the terminal with the `mb` CLI — authentication and named profiles, the flag/output/`--json` conventions every command shares, JSON body input, command discovery via `--help` (add `--json` for machine-readable schemas), and the per-resource footguns (db, table, field, upload, card, dashboard, collection, segment, measure, timeline, library, setting, search, eid). Load first for any `mb` task; it routes to the specialized skills for deeper work.
 allowed-tools: Read, Write, Edit, Bash, AskUserQuestion
 ---
 
@@ -11,11 +11,12 @@ The official Metabase CLI (`mb`) drives a Metabase instance over its REST API: a
 Top-level command groups (run `mb <group> --help` to discover verbs):
 
 ```
-auth | db | table | field | query | card | dashboard | snippet | segment | measure | collection | library
-document | transform | transform-job | transform-tag | setting | search | git-sync | setup | eid | uuid | upgrade | skills
+auth | db | table | field | upload | query | card | dashboard | snippet | segment | measure | collection | library
+document | timeline | timeline-event | transform | transform-job | transform-tag | setting | search | git-sync | setup
+eid | uuid | upgrade | skills
 ```
 
-The conventions below — auth, flags, output, body input — hold across **every** group. Per-command flags, examples, and output schemas live in `mb __manifest`. A few flows have their own skills (see "Specialized skills"). When a card needs a query, prefer MBQL over native SQL (portable, pre-flight-validated — load `mbql`); fall back to native SQL when MBQL can't express it.
+The conventions below — auth, flags, output, body input — hold across **every** group. Per-command flags and examples live in each command's `--help`; add `--json` for the machine-readable form with the output JSON Schema. A few flows have their own skills (see "Specialized skills"). When a card needs a query, prefer MBQL over native SQL (portable, pre-flight-validated — load `mbql`); fall back to native SQL when MBQL can't express it.
 
 ## Auth & profiles
 
@@ -59,22 +60,25 @@ Every list/get verb supports the same output flags:
 - `--json` — emit the full JSON envelope, safe for `jq`. Default is human-readable text.
 - `--full` — include every field (the compact projection is the default, and is the agent-facing contract).
 - `--fields a,b.c.d` — project specific dot-paths. Mutually exclusive with `--full`. **Paths are relative to each `data[]` item on list verbs, and to the root on single-item verbs.** So it's `--fields id,name` on `… list` / `database schema-tables` (`data.id` and `data[].id` both fail with `unknown field path: "data.id"`), and `--fields id,name,display` on `card get`, `--fields data.rows` on `mb query` (whose `data` is an object).
-- `--max-bytes <n>` — cap **list** output size (drops trailing items, sets `truncated`). Default 65536; `0` disables. Single-item commands (`get`, `metadata`) never truncate — when their output exceeds the cap they throw a `ConfigError` (exit 2: "output is N bytes, over the M-byte --max-bytes cap…"); raise `--max-bytes` or narrow with `--fields`.
+- `--max-bytes <n>` — cap **list** output size (drops trailing items, sets `truncated`). Default 24576 (sized to fit under agent-harness tool-output limits); `0` disables. Single-item commands (`get`) never truncate — when their output exceeds the cap they throw a `ConfigError` (exit 2: "output is N bytes, over the M-byte --max-bytes cap; …") whose tail names the remedy: on schema-shaped commands it is the exact narrower command to run instead — follow it rather than raising the cap.
+- JSON output is a single line when stdout is piped (pretty-printed only at a TTY) — always parse it, never scrape by line position.
 
-List envelope shape:
+List envelope shape (metadata first, so counts and the truncation marker survive if a consumer cuts the tail):
 
 ```json
 {
-  "data": [
-    /* items */
-  ],
   "returned": 10,
   "total": 42,
   "limit": 50,
-  "truncated": false
+  "truncated": { "reason": "max_bytes", "bytes": 123456 },
+  "data": [
+    /* items */
+  ]
 }
 ```
 
+`truncated` is present only when the cap dropped trailing items.
+
 `total` is best-effort and may be `null` (empty / permissions-filtered collections, or `--limit` early-stop); use `returned` for the count you got and `data.length` for the rendered slice.
 
 ## Body input (create / update / run)
@@ -99,38 +103,42 @@ Single-quoted `'EOF'` stops the shell interpolating `$vars` inside the JSON.
 
 Write working files to **`./.scratch`** in the current directory (`mkdir -p ./.scratch` first), never `/tmp` — better permissions, they persist across the session, and the user can review them.
 
-## Discover the full surface: `mb __manifest`
+## Discovering commands and schemas
+
+Cheapest source that answers the question wins:
 
-The canonical, machine-readable inventory of every command — name, description, per-command `details`, examples, every flag with type and default, and the output JSON Schema:
+- What groups/verbs exist? → `mb --help`, then `mb <group> --help`. Add `--json` for a machine-readable `{command, description}` index (`mb --help --json` lists every command).
+- What flags does a command take? → `mb <command> --help` — flags with enums and defaults, examples, ~1 KB.
+- Output JSON Schema before parsing, JSON-body input schema before authoring, machine-readable arg types, min server version? → `mb <command> --help --json` — that command's full entry (`inputSchema` is the exact validator the command runs on the body; `null` when it takes none).
 
 ```bash
-mb __manifest | jq -r '.commands[].command'                                                  # every command name
-mb __manifest | jq -r '.commands[] | select(.command | startswith("transform")) | .command'  # verbs under "transform"
-mb __manifest | jq '.commands[] | select(.command == "card query") | .args'                  # flags + types for a command
-mb __manifest | jq '.commands[] | select(.command == "card list") | .outputSchema'           # output schema before parsing
+mb card query --help                                    # flags, enums, defaults, examples
+mb card list --help --json | jq .outputSchema           # output schema before parsing
+mb card create --help --json | jq .inputSchema          # body schema before authoring
+mb transform --help --json | jq -r '.commands[].command'  # verbs under "transform"
 ```
 
-The leading `__` hides it from `--help`, but it's stable. Reach for it instead of per-command `--help` to enumerate verbs, validate flag names, or read an output schema before parsing.
-
 ## Resource quirks worth memorizing
 
-Routine verb shapes (list / get / create / update), every flag, and output schemas live in `mb __manifest`. Below is only what the manifest does _not_ tell you: footguns and non-obvious behaviors.
+Routine verb shapes (list / get / create / update), every flag, and output schemas live in each command's `--help` (add `--json` for output schemas). Below is only what help does _not_ tell you: footguns and non-obvious behaviors.
 
-- **db traversal vs. rollup.** Default to granular: `database list` → `database schemas <db-id>` → `database schema-tables <db-id> <schema>` → `table get <table-id> --include fields`. The rollup endpoints (`database get --include tables.fields`, `database metadata <db-id>`) pull megabytes and blow the context window on any real warehouse — use them only on a small/dev db. `sync-schema` / `rescan-values` queue async work and return `{status:"ok"}` immediately; `sync-schema --wait` blocks until `initial_sync_status: complete`.
-- **table fields.** `table get` never returns fields on its own — pass `--include fields` (compact) or use `table fields <id>` (list envelope). `table metadata <id>` adds FKs + dimensions (heavier). `table update` patches table-level metadata only; physical columns aren't editable.
+- **db traversal: the hydration ladder.** Start with `database get <db-id> --include tables` — the compact table map (id, name, schema, description per table), one call that fits most databases. Pick the relevant tables, then `table fields <table-id>` per table (bounded: fields are per-table). `--include tables.fields` is the full rollup — small databases only; when either outgrows the cap the error message names the next command down the ladder. Hundreds of tables? Traverse by schema (`database schemas <db-id>` → `database schema-tables <db-id> <schema>`) or look tables up by name (`search <term> --models table --db-id <db-id> --limit 10`). `sync-schema` / `rescan-values` queue async work and return `{status:"ok"}` immediately; `sync-schema --wait` blocks until `initial_sync_status: complete`.
+- **table fields.** `table get` never returns fields on its own — pass `--include fields` (compact; the underlying query_metadata response also carries FK targets and dimensions, visible under `--full`) or use `table fields <id>` (list envelope). `table update` patches table-level metadata only; physical columns aren't editable.
 - **field has no `list`.** Fields are per-table — get them via `table get <id> --include fields`. Never enumerate fields across a whole db (context blow-up). `field summary` is live cardinality `{field_id, count, distincts}`; `field values` is the cached distinct set (`has_more_values: true` ⇒ truncated cache). `field update` patches metadata only (`base_type` isn't editable) — this is where you set a column's `semantic_type` or foreign-key target.
+- **upload (CSV → tables).** `upload csv --file <path>` creates a new table + model (prints `{model_id, table_id}`); `upload append <table-id>` / `upload replace <table-id> --file <path>` add to / overwrite a table **previously created by upload** (columns must match). The destination db+schema is admin-configured, not per-call — check with `mb setting get uploads-settings --json` (`db_id: null` ⇒ uploads off/unconfigured; needs admin to read). `--collection <id|root>` only sets the model's collection. Max 50 MB. Errors: **"The uploads database is not configured."** = no db has uploads enabled; **"Uploads are not enabled."** = the append/replace target isn't an uploaded table.
 - **card.** `dataset_query` is the **flat** `mbql/query` value, not a legacy `{type:"query",query:…}` envelope (→ `mbql`). `--export-format csv|xlsx` streams the raw export (pipe to a file), bypassing the JSON envelope. `archive` is the only delete; unarchive with `update --body '{"archived":false}'`. `visualization_settings` keys are scoped by `display` and aren't pre-flighted — see `visualization`.
-- **dashboard.** Dashcards round-trip through `PUT /api/dashboard/:id` (no per-dashcard endpoint): `update-dashcard <dash-id> <dashcard-id>` patches one safely; `update --body '{"dashcards":[…]}'` replaces the whole set (omitted ids are deleted server-side; negative ids for new cards). `create` accepts the **same** `dashcards` array in its initial body — lay out the whole dashboard in one call: negative ids for new cards, and `card_id:null` plus a `visualization_settings.virtual_card` block (`{display:"text"|"heading"|"link"|…}`) for non-question cards. `create`/`update` pre-flight every positive `card_id` and exit **2** with `{ok:false,errors:[…]}` on a bad ref (non-bypassable). `dashboard get <id>` (or `--full`) hydrates dashcards/tabs; `list` omits them. **The grid is 24 columns wide:** each dashcard's `{col, row, size_x, size_y}` is in grid units — **full-width is `size_x: 24`** (`size_x: 12` is half a row, the usual cause of a card filling only half the width). Keep `col + size_x ≤ 24`, start a full-width stack's `col` at 0, and don't overlap (the server stores collisions as sent — no auto-fix).
+- **dashboard.** Dashcards round-trip through `PUT /api/dashboard/:id` (no per-dashcard endpoint): `update-dashcard <dash-id> <dashcard-id>` patches one safely; `update --body '{"dashcards":[…]}'` replaces the whole set (omitted ids are deleted server-side; negative ids for new cards). `create` accepts the **same** `dashcards` array in its initial body — lay out the whole dashboard in one call: negative ids for new cards, and `card_id:null` plus a `visualization_settings.virtual_card` block (`{display:"text"|"heading"|"link"|…}`) for non-question cards. `create`/`update` pre-flight every positive `card_id` and exit **2** with `{ok:false,errors:[…]}` on a bad ref (non-bypassable). `dashboard get <id>` (or `--full`) hydrates dashcards/tabs; `list` omits them. **The grid is 24 columns wide:** each dashcard's `{col, row, size_x, size_y}` is in grid units — **full-width is `size_x: 24`** (`size_x: 12` is half a row, the usual cause of a card filling only half the width). Keep `col + size_x ≤ 24`, start a full-width stack's `col` at 0, and don't overlap (the server stores collisions as sent — no auto-fix). Layout patterns and per-chart default sizes → the `dashboard` skill; load it before composing any `dashcards` array.
 - **dashboard parameters (filters).** A dashboard's `parameters` array holds its filter widgets; they're part of the dashboard record, so read them with `dashboard get <id> --fields parameters --json` (no separate verb). **Editing replaces the _whole_ array** (like dashcards), so it's a read-modify-write loop: pull the current set with `dashboard get <id> --fields parameters --json`, add/change entries, and send the full array back via `dashboard update --body '{"parameters":[…]}'` (or supply it in `create`). Omitting a parameter deletes it. Each parameter is `{id, type, …}`. **`id` is a descriptive slug-like string you pick (e.g. `order_status`), unique within this dashboard — Metabase stores any non-blank string verbatim. Do NOT invent a random/opaque id by guessing; reuse the `slug`. If you genuinely need an opaque id, mint one with `mb uuid` — never fabricate one.** `type` is a **closed enum**; an unlisted value is a hard parse error that echoes the full allowed set back to you: string ops `string/=` `string/!=` `string/contains` `string/does-not-contain` `string/starts-with` `string/ends-with`; number ops `number/=` `number/!=` `number/between` `number/>=` `number/<=`; date `date/single` `date/range` `date/relative` `date/month-year` `date/quarter-year` `date/all-options`; plus `category`, `id`, `boolean/=`, `temporal-unit`, and bare `number`/`text`/`date`/`boolean`. A parameter only filters a card once it is **mapped**: each dashcard's `parameter_mappings` is `[{parameter_id, target}]` where `parameter_id` must match a parameter's `id` exactly, and `target` is `["dimension", ["field", <field-id>, null]]` for an MBQL card column, `["dimension", ["template-tag", "<tag>"]]` for a native field-filter tag, or `["variable", ["template-tag", "<tag>"]]` for a native raw-value tag. Populate a dropdown with `values_source_type`: `"static-list"` + `values_source_config.values`, or `"card"` + `{card_id, value_field, label_field}`; omit it to pull live distinct values from the mapped field. `dashboard parameter-values <id> <parameter-id> [--query <substr>]` fetches those selectable values (`{values, has_more_values}`); `--query` is a case-insensitive substring search.
 - **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 (that's UI-only). 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`.
 - **collection `<ref>`** accepts four forms only — positive int, `root`, `trash`, or a 21-char entity_id; anything else is a client-side `ConfigError`. `collection items` auto-paginates (cap with `--limit`, which then omits `total`). `collection tree` is **JSON-only** (`--format text` is rejected). A transform collection needs `collection create --namespace transforms`.
 - **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.** For plain enumeration of cards/dashboards/collections use the dedicated `… list` verbs; reach for `search --models <kind>` only for ranking against a query string or a cross-resource lookup.
 - **transform.** Iterate with `transform update <id>`, never `delete` + `create` (keeps the row, `entity_id`, materialized table, and YAML filename — avoids `_2` suffixes and noisy git history). `transform run` needs `--wait` (or `--sync`, which also waits for the output table to register and returns `target_table_id`) or you get only `{run_id, final:null}`. (→ `transform`.)
 - **setup is one-shot.** `mb setup` walks `/api/setup` for a **fresh** instance only — errors against an already-configured one. Mostly for bootstrapping local / e2e instances.
 - **eid** translates a string entity id → numeric id: `mb eid --model <model> <eid1,eid2> --json`. Entity ids are NanoIDs that can start with `-`, which the positional form misreads as a flag (shell quotes don't help) — for those, use `--body '{"entity_ids":{"card":["-…"]}}'` (the id is a JSON string value, immune to flag parsing).
-- **library.** EE-only (`library` premium feature, v59+). The Library is a curated subtree (`library-data` "Data" + `library-metrics` "Metrics" under a `library` root): tables published to **Data** appear first in data pickers and rank up in search; metrics saved to **Metrics** are prioritized in nav, search, and the query builder — it's how you tell people (and agents) "start from these, they're trusted." `library get` shows the Library and its Data/Metrics collection ids; `library create` provisions it (idempotent). `library publish --table-ids/--db-ids/--schemas` publishes tables into Data — it **resolves the Data collection itself and creates the Library if absent** (no collection id to find); each `--schemas` entry is `<db-id>:<schema>` (e.g. `1:public`), not a bare name. `publish` cascades to upstream FK dependencies, `unpublish` to downstream dependents; both need **admin or data-analyst** (Curate alone won't publish) and exit **403** without write **and** query permission on every affected table. Publish status shows on the table: `table get`/`table list` carry `is_published` (`collection_id` under `--full`). Good candidates are finished, analysis-ready tables — clean/combine via transforms first, then publish the polished result.
+- **library.** EE-only (`library` premium feature, v59+). The Library is a curated subtree (`library-data` "Data" + `library-metrics` "Metrics" under a `library` root): tables published to **Data** appear first in data pickers and rank up in search; metrics saved to **Metrics** are prioritized in nav, search, and the query builder — it's how you tell people (and agents) "start from these, they're trusted." `library get` shows the Library and its Data/Metrics collection ids; `library create` provisions it (idempotent). `library publish --table-ids/--db-ids/--schemas` publishes tables into Data — it **resolves the Data collection itself and creates the Library if absent** (no collection id to find); each `--schemas` entry is `<db-id>:<schema>` (e.g. `1:public`), not a bare name. `publish` cascades to upstream FK dependencies, `unpublish` to downstream dependents; both need **admin or data-analyst** (Curate alone won't publish) and exit **403** without write **and** query permission on every affected table. Publish status shows on the table: `table get`/`table list` carry `is_published` (`collection_id` under `--full`). Good candidates are finished, analysis-ready tables — clean/combine via transforms first, then publish the polished result. Publishing does not put the Data collection in the git-sync scope: on a remote-sync instance, `mb git-sync add-collection <data-collection-id>` is what makes exports carry the published tables' metadata (see the `git-sync` skill).
 - **query / uuid.** `mb query` is the ad-hoc MBQL surface (`--print-schema` → `--dry-run` → run); `mb uuid --count <n>` mints the `lib/uuid` values MBQL clauses need. Both live in `mbql`.
 
 ## Specialized skills (load on demand)

package/skill-data/dashboard/SKILL.md

@@ -1,17 +1,39 @@
 ---
 name: dashboard
-description: Build interactive Metabase dashboards via the `mb` CLI — turn cards into a filterable, cross-linked app. Covers wiring filters to cards (parameters + parameter_mappings), the field-filter vs. raw-variable target grammar, linked/cascading filters and their foreign-key requirement, cross-filtering (click a chart to filter the rest), click-through to a question/dashboard/URL, multi-series overlays, and tabs. Grid math, the parameter type enum, and whole-array replace semantics live in `core`. Triggers — "wire a filter to these cards", "make a filter cascade", "click a bar to filter the other charts", "add a dashboard tab", "add a second series", "make clicking a row open another dashboard", "why isn't my filter showing".
+description: Build Metabase dashboards via the `mb` CLI — lay out dashcards on the 24-column grid (`{col,row,size_x,size_y}` math, per-chart default sizes) and turn cards into a filterable, cross-linked app. Covers wiring filters to cards (parameters + parameter_mappings), the field-filter vs. raw-variable target grammar, linked/cascading filters and their foreign-key requirement, cross-filtering, click-through, multi-series overlays, and tabs. The parameter type enum and whole-array replace semantics live in `core`. Triggers — "build a dashboard from these cards", "my dashboard is squished into half the width", "wire a filter to these cards", "make a filter cascade", "click a bar to filter the other charts", "add a dashboard tab", "add a second series", "why isn't my filter showing".
 allowed-tools: Read, Write, Edit, Bash, AskUserQuestion
 ---
 
 # Dashboard
 
-A dashboard starts as cards on a grid; it becomes an **app** when filters drive the cards, charts cross-filter each other, and clicks navigate. This skill is that interactive layer.
+A dashboard starts as cards on a grid; it becomes an **app** when filters drive the cards, charts cross-filter each other, and clicks navigate. This skill owns both: the grid layout and the interactive layer.
 
-**`core` owns the mechanics** — the 24-column grid and `{col,row,size_x,size_y}` math, the whole-array replace semantics (editing `dashcards` or `parameters` replaces the entire set; omitted entries are deleted; new cards use negative ids), `update-dashcard` for a single safe patch vs. `update --body` for a full replace, the closed `parameter.type` enum, and the `parameter-values` verb. Read it first (`mb skills get core`). **`visualization`** owns each card's chart and the full `click_behavior` key catalog. This file assumes both and focuses on wiring.
+**`core` owns the transport mechanics** — the whole-array replace semantics (editing `dashcards` or `parameters` replaces the entire set; omitted entries are deleted; new cards use negative ids), `update-dashcard` for a single safe patch vs. `update --body` for a full replace, the closed `parameter.type` enum, and the `parameter-values` verb. Read it first (`mb skills get core`). **`visualization`** owns each card's chart and the full `click_behavior` key catalog.
 
 Inspect before you wire: `mb dashboard get <id> --json` hydrates `parameters`, `dashcards`, and `tabs`; `mb dashboard cards <id>` lists just the dashcards.
 
+## 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.
+
+Default sizes (w×h): `scalar`/`smartscalar` 6×3, `pie` 12×8, `table`/`pivot`/`object` 12×9, `waterfall` 14×6, `sankey` 16×10, `heading` 24×1, `text` 12×3, every other chart 12×6.
+
+The standard shape — a KPI row of scalars across the full 24, charts in halves or thirds below, wide tables full-width:
+
+```jsonc
+"dashcards": [
+  { "id": -1, "card_id": 101, "col": 0,  "row": 0, "size_x": 6,  "size_y": 3 },  // 4 KPIs × 6 = 24
+  { "id": -2, "card_id": 102, "col": 6,  "row": 0, "size_x": 6,  "size_y": 3 },
+  { "id": -3, "card_id": 103, "col": 12, "row": 0, "size_x": 6,  "size_y": 3 },
+  { "id": -4, "card_id": 104, "col": 18, "row": 0, "size_x": 6,  "size_y": 3 },
+  { "id": -5, "card_id": 105, "col": 0,  "row": 3, "size_x": 12, "size_y": 6 },  // two halves
+  { "id": -6, "card_id": 106, "col": 12, "row": 3, "size_x": 12, "size_y": 6 },
+  { "id": -7, "card_id": 107, "col": 0,  "row": 9, "size_x": 24, "size_y": 9 }   // full-width table
+]
+```
+
+**Sanity-check before sending:** rows should fill to 24 and at least one card must end at `col + size_x = 24`. If nothing in the array crosses column 12, you've authored a 12-column layout — double every width.
+
 ## The wiring loop: a filter is a parameter + a mapping per card
 
 A dashboard filter is one entry in the dashboard's `parameters` array **plus** a `parameter_mappings` entry on every dashcard it should control. A parameter with no mapping is an inert widget — the most common "my filter does nothing" cause.
@@ -101,6 +123,7 @@ Set the **driver** chart's whole-card click behavior to `crossfilter`, mapping t
 
 ## Don't
 
+- Don't lay out on a 12-column assumption — full-width is `size_x: 24`; a layout where no card crosses column 12 renders in the left half of the viewport.
 - Don't declare a parameter and forget the per-card `parameter_mappings` — the widget won't filter anything.
 - Don't expect a linked filter to work off a model/question join, a custom column, or with a static/card value source — it needs a metadata FK and a live source.
 - Don't hand-author a complex `click_behavior` — copy a UI-built one.

package/skill-data/data-workflow/SKILL.md

@@ -10,14 +10,14 @@ The front door for turning a raw database into clean tables, reusable definition
 
 A data project moves through stages. A user can start at any of them — detect where their data already is, don't assume.
 
-| Stage                       | What it does                                                                                              | Where the method lives                                                                 |
-| --------------------------- | --------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------- |
-| **Build clean tables**      | Raw, normalized source DB → a small set of wide, clean, analysis-ready tables (built as transforms)       | `references/building-clean-tables.md`                                                  |
-| **Define reusable metrics** | Clean tables → shared segments (saved filters), measures (saved calculations), metrics (official numbers) | `references/reusable-definitions.md`                                                   |
-| **Answer questions**        | Clean tables → a trustworthy plain-language written answer                                                | `references/answering-questions.md`                                                    |
-| **Build dashboards**        | Clean tables / definitions → charts and dashboards people look at                                         | the `visualization` skill (charts) + `dashboard` skill (wiring filters, interactivity) |
+| Stage                       | What it does                                                                                              | Where the method lives                                                                       |
+| --------------------------- | --------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------- |
+| **Build clean tables**      | Raw, normalized source DB → a small set of wide, clean, analysis-ready tables (built as transforms)       | `references/building-clean-tables.md`                                                        |
+| **Define reusable metrics** | Clean tables → shared segments (saved filters), measures (saved calculations), metrics (official numbers) | `references/reusable-definitions.md`                                                         |
+| **Answer questions**        | Clean tables → a trustworthy plain-language written answer                                                | `references/answering-questions.md`                                                          |
+| **Build dashboards**        | Clean tables / definitions → charts and dashboards people look at                                         | the `visualization` skill (charts) + `dashboard` skill (grid layout, filters, interactivity) |
 
-The first three methods are references in this skill — read **only the one the current stage needs**: run `mb skills path data-workflow` and Read `references/<file>.md`. (`mb skills get data-workflow --full` appends all three at once — heavier; prefer the single Read.) "Build dashboards" lives in two standalone skills — `visualization` for authoring each chart, `dashboard` for wiring filters and interactivity across the dashboard — both CLI capabilities in their own right.
+The first three methods are references in this skill — read **only the one the current stage needs**: run `mb skills path data-workflow` and Read `references/<file>.md`. (`mb skills get data-workflow --full` appends all three at once — heavier; prefer the single Read.) "Build dashboards" lives in two standalone skills — `visualization` for authoring each chart, `dashboard` for laying cards out on the grid and wiring filters and interactivity — both CLI capabilities in their own right. Load `dashboard` before composing any dashboard, even a plain no-filter layout: the grid geometry lives there.
 
 CLI mechanics come from the reference skills, not from here: `mb skills get core` (auth, inspection, the `field`/`table`/`library`/`segment`/`measure` verbs), `mbql` (query and definition bodies), `transform` (creating/running transforms). This skill owns the _judgment_ — which tables, which definitions, what to keep — and the conventions below.
 
@@ -88,19 +88,21 @@ The rules every stage follows. The reference files assume this contract rather t
 
 Don't make the user name a _stage_ — but do find out _where their data lives_ before going looking.
 
+**Data not in a database yet?** A local CSV gets in via `mb upload csv --file <path>` (creates a table + model); treat the result as a starting table and clean it with a transform if needed. Uploads must be admin-enabled — check `mb setting get uploads-settings --json` (`db_id: null` ⇒ not configured). See `core`'s **upload** quirk for the rest.
+
 **Ask before you crawl.** If you don't already know which database/schema/table the user means, ask — one plain question short-circuits a dozen tool calls. The asymmetry: if they name a **database**, ask which **schema**; if they name a **table**, ask which **database**. "If you don't know, no problem — I'll look" is the fallback, not the opener.
 
-**When you do crawl,** use `core`'s cheap, narrowest-first ladder (never whole-warehouse rollups): `mb db list` → `db schemas <id>` → `db schema-tables <id> <schema>` → `table list [--db-id]` → `table fields <id>` (or `table metadata <id>` for FK targets and dimensions — heavier). Have a _name_ rather than a tree to walk? `mb search <query> [--models] [--db-id]`. Need to know what's in a column? `mb field summary <id>` (counts) and `field values <id>` (sample values). If a database looks freshly connected or an expected table is missing, offer `mb db sync-schema <id> --wait` before concluding it doesn't exist.
+**When you do crawl,** use `core`'s cheap, narrowest-first ladder (never whole-warehouse rollups): `mb db list` → `db schemas <id>` → `db schema-tables <id> <schema>` → `table list [--db-id]` → `table fields <id>` (or `table get <id> --include fields --full` for FK targets and dimensions). Have a _name_ rather than a tree to walk? `mb search <query> [--models] [--db-id]`. Need to know what's in a column? `mb field summary <id>` (counts) and `field values <id>` (sample values). If a database looks freshly connected or an expected table is missing, offer `mb db sync-schema <id> --wait` before concluding it doesn't exist.
 
 **Read the shape to pick a stage.** Raw, normalized, SaaS-synced tables (many tables, coded columns, `*_field`/`*_choice` lookups)? → **build clean tables** first. Already wide, clean, human-readable ones? Then it depends on the goal:
 
-| What the user wants / what's there                                                                             | Stage                                                                     |
-| -------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------- |
-| "Clean up / flatten / make sense of" raw, normalized data; no clean tables yet                                 | Build clean tables → `references/building-clean-tables.md`                |
-| Clean tables exist; "make this reusable", "define active customers / revenue / MRR officially"                 | Define reusable metrics → `references/reusable-definitions.md`            |
-| Clean tables exist; "answer this question", "who registered", "analyze / report on X" (wants a written answer) | Answer questions → `references/answering-questions.md`                    |
-| Clean tables (and maybe definitions) exist; "chart this", "build a dashboard", "show me X over time"           | Build dashboards → `visualization` (charts) + `dashboard` (interactivity) |
-| "Do the whole thing" / "set up analytics for X" from raw data                                                  | Start at build-clean-tables, then continue down the stages                |
+| What the user wants / what's there                                                                             | Stage                                                                             |
+| -------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------- |
+| "Clean up / flatten / make sense of" raw, normalized data; no clean tables yet                                 | Build clean tables → `references/building-clean-tables.md`                        |
+| Clean tables exist; "make this reusable", "define active customers / revenue / MRR officially"                 | Define reusable metrics → `references/reusable-definitions.md`                    |
+| Clean tables exist; "answer this question", "who registered", "analyze / report on X" (wants a written answer) | Answer questions → `references/answering-questions.md`                            |
+| Clean tables (and maybe definitions) exist; "chart this", "build a dashboard", "show me X over time"           | Build dashboards → `visualization` (charts) + `dashboard` (layout, interactivity) |
+| "Do the whole thing" / "set up analytics for X" from raw data                                                  | Start at build-clean-tables, then continue down the stages                        |
 
 **Answer and dashboard are alternative endpoints, not a sequence.** Once tables are clean (and maybe defined), answering in prose and building a dashboard are two different things you can do with the data — route to whichever the goal calls for; neither has to precede the other.
 

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

@@ -1,12 +1,14 @@
 ---
 name: git-sync
-description: Round-trip Metabase content (cards, dashboards, transforms, snippets, collections) between an instance and a git remote via `mb git-sync …` — status, dirty / has-remote-changes checks, import, export (with branch guard), branches, stash, add/remove a collection from sync. Load when the user wants to "import the latest changes", "export to git", "git sync", "dirty check", "stash before pulling", "add a collection to sync", or anything `mb git-sync …`.
+description: Round-trip Metabase content (cards, dashboards, transforms, snippets, collections, Library-published table/field metadata) between an instance and a git remote via `mb git-sync …` — status, dirty / has-remote-changes checks, import, export (with branch guard), branches, stash, add/remove a collection from sync. Load when the user wants to "import the latest changes", "export to git", "push my changes to the repo", "open a PR with my Metabase changes", "git sync", "dirty check", "stash before pulling", "add a collection to sync", or anything `mb git-sync …`.
 allowed-tools: Read, Write, Edit, Bash, AskUserQuestion
 ---
 
 # 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.
+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.
+
+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.
 
 This skill covers the import/export workflow. Flag conventions and auth setup live in `core` (`mb skills get core`). To author content YAML by hand: the per-resource clause and settings shapes mirror the API form — query bodies follow the `mbql` skill, `visualization_settings` follow the `visualization` skill — except the portable YAML uses **name-based** references (e.g. `[Sample Database, PUBLIC, ORDERS, TOTAL]`, and entity-ids for cross-entity FKs) where the API form uses numeric ids. For the on-disk folder layout, model new files on what the synced repo already contains.
 
@@ -126,13 +128,26 @@ mb setting set remote-sync-type '"read-write"' --profile <n>
 
 (`setting set` parses the value as strict JSON — mind the inner double quotes; see `core`.) The server also rejects switching to `:read-only` while the Remote Sync collection is dirty; export or `--force` import first if you're going the other way.
 
-**Verifying the result.** The CLI's `Collection` schema doesn't yet expose `is_remote_synced`, so `collection get --json` won't show the flag. The pragmatic confirmation paths are:
+**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.
+
+## 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.
+
+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:
+
+```bash
+mb library get --profile <n> --json                                # Library Data collection id
+mb git-sync add-collection <library-data-id> --profile <n>
+mb git-sync stash --new-branch <branch> -m "..." --profile <n>     # or create-branch + export
+```
 
-- `mb git-sync is-dirty --profile <n> --json` after editing a card in the now-synced collection — a `true` reading proves it's tracked.
-- The Metabase Admin UI's Remote Sync page renders the per-collection toggles.
+Flagging the collection records it for the next export, which serializes its current content — including already-published tables and their field metadata. `mb library publish` prints a reminder when the target collection is outside the sync scope on an instance with a configured remote.
 
 ## 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 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.

package/skill-data/visualization/SKILL.md

@@ -158,3 +158,4 @@ mb skills path visualization           # → the skill dir; then Read references
 - Don't use the MBQL-5 field-ref order inside a `column_settings` `["ref", …]` key — that key uses the **legacy** `["field", id, opts]` order. Prefer the `["name", …]` form.
 - Don't expect a pre-flight to catch viz mistakes — there is none. Verify by reading the card back.
 - Don't hand-author complex charts when you can pull a working `visualization_settings` from a UI-built card.
+- Don't look for an event/annotation key in `visualization_settings` — vertical event markers on time-series charts come from timelines (`mb timeline` / `mb timeline-event`) living in the question's own collection (same collection only, no sub-collection inheritance; question view only, never dashboard cards).

package/dist/add-collection-DbalcC3_.mjs

@@ -1,11 +0,0 @@
-import "./notice-DyVl5aYB.mjs";
-import "./error-BaBm-UrT.mjs";
-import "./command-augment-DdZIfx1V.mjs";
-import "./runtime-oxjmrYoP.mjs";
-import "./capabilities-N0jo5U7S.mjs";
-import "./parse-id-DlXnOcmP.mjs";
-import "./poll-hgnrHBoh.mjs";
-import "./poll-task-NQNLT_aA.mjs";
-import { SyncSettingsUpdateResult, add_collection_default, setCollectionRemoteSynced, syncSettingsUpdateView } from "./add-collection-CRZAFCZy.mjs";
-
-export { add_collection_default as default };

package/dist/auth--PWX0oj5.mjs

@@ -1,22 +0,0 @@
-import "./command-augment-DdZIfx1V.mjs";
-import { defineCommandGroup } from "./group-BNE_RiH5.mjs";
-
-//#region src/commands/auth/index.ts
-var auth_default = defineCommandGroup({
-	name: "auth",
-	description: "Authenticate against a Metabase instance",
-	defaultCommand: "login",
-	skills: [{
-		skill: "core",
-		purpose: "authentication and named profiles"
-	}],
-	subCommands: {
-		login: () => import("./login-C6ZAnGHz.mjs").then((m) => m.default),
-		status: () => import("./status-C_7aqTvB.mjs").then((m) => m.default),
-		list: () => import("./list-CjF12k1G.mjs").then((m) => m.default),
-		logout: () => import("./logout-CWjyY3Y8.mjs").then((m) => m.default)
-	}
-});
-
-//#endregion
-export { auth_default as default };

package/dist/capabilities-N0jo5U7S.mjs

@@ -1,239 +0,0 @@
-import { ConfigError, itemOversizeMessage, listTruncationNotice, warn } from "./notice-DyVl5aYB.mjs";
-import { z } from "zod";
-import Table from "cli-table3";
-
-//#region src/runtime/predicates.ts
-function isPlainObject(value) {
-	return typeof value === "object" && value !== null && !Array.isArray(value);
-}
-
-//#endregion
-//#region src/output/cap.ts
-function capListEnvelope(envelope, maxBytes) {
-	if (maxBytes <= 0) return envelope;
-	const fullBytes = jsonByteLength(envelope);
-	if (fullBytes <= maxBytes) return envelope;
-	let lo = 0;
-	let hi = envelope.data.length;
-	while (lo < hi) {
-		const mid = Math.ceil((lo + hi) / 2);
-		if (jsonByteLength(truncate(envelope, mid, fullBytes)) <= maxBytes) lo = mid;
-		else hi = mid - 1;
-	}
-	return truncate(envelope, lo, fullBytes);
-}
-function truncate(envelope, count, originalBytes) {
-	return {
-		...envelope,
-		data: envelope.data.slice(0, count),
-		returned: count,
-		truncated: {
-			reason: "max_bytes",
-			bytes: originalBytes
-		}
-	};
-}
-function jsonByteLength(value) {
-	return Buffer.byteLength(JSON.stringify(value), "utf8");
-}
-
-//#endregion
-//#region src/output/projection.ts
-function applyProjection(value, view, full, fields) {
-	if (fields !== void 0) {
-		if (fields.length === 0) throw new ConfigError("--fields requires at least one path");
-		return projectFields(value, fields);
-	}
-	if (full) return value;
-	const parsed = view.compactPick.safeParse(value);
-	if (parsed.success) return parsed.data;
-	throw new ConfigError(`compact projection failed: ${parsed.error.message}`);
-}
-function projectFields(value, fields) {
-	const out = {};
-	for (const path of fields) {
-		if (path.length === 0) throw new ConfigError(`empty field path`);
-		const parts = path.split(".");
-		if (parts.some((part) => part.length === 0)) throw new ConfigError(`invalid field path: "${path}"`);
-		setPath(out, parts, pickPath(value, parts));
-	}
-	return out;
-}
-function pickPath(value, parts) {
-	let cursor = value;
-	for (const part of parts) {
-		if (!isPlainObject(cursor) || !Object.hasOwn(cursor, part)) throw new ConfigError(`unknown field path: "${parts.join(".")}"`);
-		cursor = Reflect.get(cursor, part);
-	}
-	return cursor;
-}
-function setPath(target, parts, value) {
-	let cursor = target;
-	const lastIndex = parts.length - 1;
-	for (const [index, part] of parts.entries()) {
-		if (index === lastIndex) {
-			cursor[part] = value;
-			return;
-		}
-		const existing = cursor[part];
-		if (isPlainObject(existing)) cursor = existing;
-		else {
-			const next = {};
-			cursor[part] = next;
-			cursor = next;
-		}
-	}
-}
-
-//#endregion
-//#region src/output/table.ts
-const PLAIN_TABLE_STYLE = {
-	head: [],
-	border: []
-};
-function renderTable(rows, columns) {
-	const head = columns.map((column) => column.label ?? column.key);
-	const widths = columns.map((column) => column.width ?? null);
-	const hasWidth = widths.some((width) => width !== null);
-	const table = new Table(hasWidth ? {
-		head,
-		colWidths: widths,
-		style: PLAIN_TABLE_STYLE
-	} : {
-		head,
-		style: PLAIN_TABLE_STYLE
-	});
-	for (const row of rows) table.push(columns.map((column) => formatCell(row, column)));
-	return table.toString();
-}
-function renderRows(head, rows) {
-	const table = new Table({
-		head: [...head],
-		style: PLAIN_TABLE_STYLE
-	});
-	for (const row of rows) table.push([...row]);
-	return table.toString();
-}
-function formatCell(row, column) {
-	const value = row[column.key];
-	if (column.format !== void 0) return column.format(value);
-	return formatScalar(value);
-}
-function formatScalar(value) {
-	if (value === null || value === void 0) return "";
-	if (typeof value === "string" || typeof value === "number" || typeof value === "boolean") return String(value);
-	return JSON.stringify(value);
-}
-
-//#endregion
-//#region src/output/render.ts
-function writeJson(value) {
-	process.stdout.write(JSON.stringify(value, null, 2) + "\n");
-}
-function writeText(text) {
-	process.stdout.write(text + "\n");
-}
-function renderItem(item, view, opts) {
-	const projected = applyProjection(item, view, opts.full, opts.fields);
-	const body = renderItemBody(item, view, projected, opts) + "\n";
-	assertItemWithinMaxBytes(body, opts.maxBytes);
-	process.stdout.write(body);
-}
-function renderSummary(item, view, summaryText, opts) {
-	if (opts.format === "json" || opts.fields !== void 0 || opts.full) {
-		renderItem(item, view, opts);
-		return;
-	}
-	const body = (typeof summaryText === "function" ? summaryText() : summaryText) + "\n";
-	assertItemWithinMaxBytes(body, opts.maxBytes);
-	process.stdout.write(body);
-}
-function renderList(envelope, view, opts) {
-	if (opts.format === "json") {
-		renderJsonEnvelope(envelope, view, opts);
-		return;
-	}
-	if (envelope.data.length === 0) {
-		process.stdout.write("(no results)\n");
-		return;
-	}
-	if (opts.fields !== void 0) {
-		renderProjectedTable(envelope, view, opts.fields, opts.maxBytes);
-		return;
-	}
-	const capped = capListEnvelope(envelope, opts.maxBytes);
-	process.stdout.write(renderTable(capped.data, view.tableColumns) + "\n");
-	if (capped.truncated !== void 0) warn(listTruncationNotice(capped.truncated.bytes));
-}
-function renderProjectedTable(envelope, view, fields, maxBytes) {
-	const projectedItems = projectListItems(envelope.data, view, false, fields);
-	const capped = capListEnvelope({
-		...envelope,
-		data: projectedItems
-	}, maxBytes);
-	const rows = capped.data.map((item) => fields.map((path) => formatScalar(pickPath(item, path.split(".")))));
-	process.stdout.write(renderRows(fields, rows) + "\n");
-	if (capped.truncated !== void 0) warn(listTruncationNotice(capped.truncated.bytes));
-}
-function projectListItems(items, view, full, fields) {
-	try {
-		return items.map((item) => applyProjection(item, view, full, fields));
-	} catch (error) {
-		throw enrichListFieldPathError(error, fields);
-	}
-}
-function enrichListFieldPathError(error, fields) {
-	if (fields === void 0 || !(error instanceof ConfigError) || !error.message.startsWith("unknown field path")) return error;
-	const prefix = "data.";
-	const culprit = fields.find((field) => field === "data" || field.startsWith(prefix));
-	if (culprit === void 0) return error;
-	const suggestion = culprit.startsWith(prefix) ? culprit.slice(prefix.length) : "<field>";
-	return new ConfigError(`${error.message} — on list commands --fields paths are relative to each item in \`data\`, not the envelope. Drop the \`data.\` prefix (e.g. use \`${suggestion}\` instead of \`${culprit}\`).`);
-}
-function renderJsonEnvelope(envelope, view, opts) {
-	const projectedItems = projectListItems(envelope.data, view, opts.full, opts.fields);
-	const projectedEnvelope = {
-		...envelope,
-		data: projectedItems
-	};
-	const capped = capListEnvelope(projectedEnvelope, opts.maxBytes);
-	process.stdout.write(JSON.stringify(capped, null, 2) + "\n");
-	if (capped.truncated !== void 0) warn(listTruncationNotice(capped.truncated.bytes));
-}
-function renderItemBody(item, view, projected, opts) {
-	if (opts.format === "json") return JSON.stringify(projected, null, 2);
-	if (opts.fields !== void 0 || opts.full) return renderKeyValueLines(objectPairs(projected));
-	return renderKeyValueLines(columnPairs(item, view.tableColumns));
-}
-function columnPairs(item, columns) {
-	return columns.map((column) => [column.label ?? column.key, formatCell(item, column)]);
-}
-function objectPairs(value) {
-	if (!isPlainObject(value)) {
-		const scalar = formatScalar(value);
-		return scalar === "" ? [] : [["", scalar]];
-	}
-	return Object.entries(value).map(([key, raw]) => [key, formatScalar(raw)]);
-}
-function renderKeyValueLines(pairs) {
-	if (pairs.length === 0) return "";
-	const padding = Math.max(...pairs.map(([label]) => label.length));
-	return pairs.map(([label, value]) => `${label.padEnd(padding)}  ${value}`).join("\n");
-}
-function assertItemWithinMaxBytes(body, maxBytes) {
-	if (maxBytes <= 0) return;
-	const bytes = Buffer.byteLength(body, "utf8");
-	if (bytes <= maxBytes) return;
-	throw new ConfigError(itemOversizeMessage(bytes, maxBytes));
-}
-
-//#endregion
-//#region src/runtime/capabilities.ts
-const Capabilities = z.object({
-	minVersion: z.number(),
-	tokenFeature: z.string().optional()
-});
-const BASELINE_CAPABILITIES = Object.freeze({ minVersion: 58 });
-
-//#endregion
-export { BASELINE_CAPABILITIES, Capabilities, formatScalar, isPlainObject, renderItem, renderList, renderRows, renderSummary, writeJson, writeText };

package/dist/card-D07WYCQY.mjs

@@ -1,26 +0,0 @@
-import "./command-augment-DdZIfx1V.mjs";
-import { defineCommandGroup } from "./group-BNE_RiH5.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-D-rgDFa5.mjs").then((mod) => mod.default),
-		get: () => import("./get-Dz7fcqoG.mjs").then((mod) => mod.default),
-		query: () => import("./query-BQfgKV68.mjs").then((mod) => mod.default),
-		create: () => import("./create-DhrftYre.mjs").then((mod) => mod.default),
-		update: () => import("./update-CrRz47aj.mjs").then((mod) => mod.default),
-		archive: () => import("./archive-Z8ZM-ilB.mjs").then((mod) => mod.default)
-	}
-});
-
-//#endregion
-export { card_default as default };