@malloydata/malloyyo 0.2.14 → 0.2.16

package/dist/index.js

@@ -86,13 +86,18 @@ import path from "node:path";
 import url from "node:url";
 var HOST_ONLY = "host_only";
 var contentFiles = {
+  "dashboards/authoring.md": '---\ndescription: How to author a dashboard \u2014 a self-contained file in the dashboards/ directory that defines its own query; the entry point for dashboard how-to\n---\n\n# Authoring dashboards\n\nA dashboard is a **self-contained `.malloy` file in the `dashboards/`\ndirectory**. The file IS the dashboard: it imports the model parts it needs,\ndefines its query (with the filtering it applies), and tags it. No manifest, and\nfor the basic case no JavaScript. Preview with `malloyyo dashboard dev`; check\nwith `malloyyo lint`. Requires `@malloydata/malloy` 0.0.423+.\n\nRelated: `yo_help dashboards/givens-and-controls` (filter controls),\n`dashboards/grid-layout` (columns/colspan/break), `dashboards/custom-components`\n(a flat `<name>.jsx`), `dashboards/vega-charts` (`<VegaChart>`).\n\n> **Need a chart the `# bar_chart`/`# line_chart`/`# shape_map` tags can\'t do?**\n> Use the `<VegaChart>` COMPONENT (a Vega-Lite spec over query rows) \u2014 NOT a `#`\n> tag; there is no `# vega_lite`. See `yo_help dashboards/vega-charts`.\n\n## The layout\n\n```\nmodel/\n  ecommerce.malloy     # sources, reusable views/measures, # drill tags\n  givens.malloy        # given: declarations (the filter controls)\n  index.malloy         # imports/exports sources \u2014 the MCP/data surface ONLY\n  dashboards/\n    overview.malloy    # one dashboard; the FILENAME is its name/slug\n    overview.jsx       # optional custom component for overview\n```\n\n**The filename is the dashboard\'s name** \u2014 its URL slug, its `# drill` target,\nand the basename of its optional component. Discovery globs\n`dashboards/*.malloy` and compiles EACH as its own entry \u2014 so dashboards are NOT\ndeclared in, or exported through, `index.malloy` (`index.malloy` is just the\n`query`/`describe_source` data surface).\n\n## Preferred: put the query IN the dashboard file\n\nDefine the query right in `dashboards/<name>.malloy` and tag it `# artifact`, so\nthe given mapping (the `where: \u2026 ~ $GIVEN`) is visible next to the dashboard:\n\n```malloy\n// dashboards/overview.malloy\n##! experimental.givens\nimport "../ecommerce.malloy"          // BARE import: source + givens in scope\n\n#" Business health at a glance \u2014 sales, margin, orders.\n# artifact { title="Business Overview" } dashboard {columns=6}\nquery: overview is order_items -> {\n  where:                                            // the given mapping, HERE\n    inventory_items.product_brand ~ $BRAND,         // multi-filter where: is\n    inventory_items.product_category ~ $CATEGORY,   // COMMA separated\n    created_at ~ $PERIOD\n  # colspan=2\n  aggregate: total_sales, total_gross_margin, order_count\n  # colspan=3\n  nest:\n    # line_chart\n    sales_trend is by_month\n    top_brands\n    # shape_map\n    sales_by_state\n}\n```\n\nThat\'s a complete dashboard: the runtime auto-renders a title (the tag\'s\n`title`, else the `#"` doc), a control for every given the query references, and\nthe result panel. `# artifact` DECLARES the dashboard; `# dashboard {columns=6}`\nis the renderer tag that draws it as KPI tiles + a card grid \u2014 partners, on the\nsame line. Grid rules: `yo_help dashboards/grid-layout`.\n\n**You know you\'re doing it right when the `where: foo ~ $FOO` is in the DASHBOARD\nfile, not the model.** Keep the model\'s sources/views reusable and given-free;\neach dashboard decides its own filtering.\n\n**The bare import is required for controls.** A control renders only when the\ngiven\'s DECLARATION is in the dashboard file\'s scope \u2014 a bare\n`import "../ecommerce.malloy"` (or `import "../givens.malloy"`) brings them all;\nthe runtime shows a control for exactly the givens the query references. A\nselective `import { order_items } from \u2026` brings the filter but NOT the control.\n\nKeep the FILENAME as the name \u2014 don\'t set `name=`, so the URL, the\n`# drill { to=\u2026 }`, and the component basename all agree (one source of truth).\n\n## Other forms\n\n- **A view of a source you extend in the file** \u2014 tag the dashboard `view:` with\n  `# artifact` (runs as `<source> -> <view>`). Good when the dashboard needs\n  helper views defined alongside it.\n- **Compose existing views**: a model-level `## artifact { tiles=["a -> b", "c -> d"]\n  dashboard_columns=6 }` (`##`, ONE line) names several views, run separately and\n  combined into one `# dashboard`. Use for multi-tile / cross-source; prefer the\n  inline query whenever a dashboard has its own filtering.\n- A `dashboards/*.malloy` with NO `# artifact`/`## artifact` is a shared INCLUDE\n  (skipped by discovery) \u2014 put helper sources/views there for several dashboards\n  to import.\n\n## Givens (filter controls)\n\nDeclare givens as `filter<T>` in the MODEL (`givens.malloy` or the source file) \u2014\nthey\'re shared and used by the MCP surface too; each dashboard APPLIES them in\nits `where:`. Full control reference: `yo_help dashboards/givens-and-controls`.\nPer-dashboard starting values go in the tag:\n\n```malloy\n# artifact { title="Ford recalls" givens { MANUFACTURER=f\'Ford Motor Company\' } }\n```\n\n## Drill from a dimension\n\n`# drill` on a source `dimension:` (in the model) makes its cells clickable \u2014\nopening another dashboard (seeding the value) or filtering in place:\n\n```malloy\ndimension:\n  # drill { to=[category_explorer, self] }\n  category is inventory_items.product_category\n```\n\n`to` is a list; each is a **dashboard slug** (a `dashboards/<slug>.malloy`\nfilename) \u2192 opens it, seeding the value into the given named like the dimension\nUPPER-cased (`category` \u2192 `CATEGORY`), or **`self`** \u2192 filter the current\ndashboard in place. Add `given=` when the target given differs. `lint` VERIFIES\nevery `to=` slug resolves to a real dashboard file (a typo/renamed dashboard\nfails loudly, not at click time).\n\n> **malloy#2979 (fixed in 0.0.423):** a `# drill` on a bare `group_by: name` was\n> dropped when nested through `+ {\u2026}`. Put it on the source `dimension:`, or use\n> `group_by: name is concat(name,\'\')`.\n\n## Custom component (optional)\n\nFor bespoke layout/charts, add a flat sibling `dashboards/<name>.jsx` (or\n`.tsx`). Only React + `@malloyyo/dashboard` importable (sandboxed). A bare\n`<Panel/>` renders the whole dashboard; a `<Panel query="\u2026"/>` /\n`<VegaChart query="\u2026"/>` runs a query DEFINED in this dashboard file (by name) or\na `source -> view`. `lint` checks each `query="\u2026"` still resolves. See `yo_help\ndashboards/custom-components`.\n\n## Rules\n- Each dashboard is one `dashboards/<name>.malloy`; the filename is the slug.\n  Prefer the inline `query: \u2026 # artifact` form \u2014 the `where: ~ $GIVEN` lives in\n  the dashboard file.\n- Bare-import the model (and/or `givens.malloy`) so the controls render.\n- Givens are `filter<T>` declared in the model; options come from `# suggest {\u2026}`;\n  interactivity = setting given values, not rewriting query text.\n- `index.malloy` is the data surface, NOT where dashboards live.\n- If a query/given you need is missing, add it (check with `describe_source`).\n\n## Preview & validate\n`malloyyo dashboard dev` \u2192 open the URL; `.malloy`/`.jsx` edits hot-reload.\n`malloyyo lint` checks each dashboard file on its own: it compiles as its entry;\neach tile/query and `# suggest` compiles; `dashboard_columns` is a positive int;\nthe component compiles and its `query="\u2026"` resolve; no duplicate names, no\norphaned component; every `# drill { to=\u2026 }` resolves. Tight loop: the local\n`malloyyo mcp --develop` server hot-reloads edits \u2014 `query(execute:false)` to\ncompile-check, `execute:true` to run. Don\'t validate against a hosted/claude.ai\nconnector \u2014 it serves the PUBLISHED model (stale until `malloyyo publish`).\n',
+  "dashboards/custom-components.md": '---\ndescription: Custom dashboard UI \u2014 a flat dashboards/<name>.jsx|tsx sibling composing @malloyyo/dashboard widgets/hooks/helpers with your own React\n---\n\n# Custom dashboard components (`dashboards/<name>.jsx`)\n\nThe default UI (auto-rendered controls + panel) covers most dashboards. When it\nisn\'t enough, add ONE file \u2014 a **flat sibling** `dashboards/<name>.jsx` (or\n`.tsx`) next to the dashboard\'s `dashboards/<name>.malloy` (same basename) \u2014 that\ncomposes the runtime\'s widgets/hooks with your own React. You own layout, copy,\nand theming; the `.malloy` file still owns every query and filter. See also\n`yo_help dashboards/authoring` and `dashboards/vega-charts`.\n\n```tsx\nimport React from "react";\nimport { Controls, Given, Search, Select, TimeRange, Panel, filters, useGiven } from "@malloyyo/dashboard";\n\nexport default function Dashboard({ dashboard, givens }) {\n  return (\n    <div style={{ maxWidth: 860, margin: "0 auto", padding: 24 }}>\n      <h1>{dashboard.title}</h1>\n      <Controls>\n        <Given name="STATE" />          {/* picks the control from the declaration */}\n        <Search given="NAME" />         {/* committing input + typeahead + validation */}\n        <TimeRange given="PERIOD" presets={[\n          { value: "", text: "All time" },\n          { value: filters.lastN(1, "day"), text: "Last day" },\n          { value: filters.lastN(1, "week"), text: "Last week" },\n          { value: filters.lastN(1, "month"), text: "Last month" },\n        ]} />                            {/* "Custom range\u2026" is always appended */}\n        <Select given="MIN_SAMPLE"\n          options={[10, 200, 1000].map(n => ({ value: filters.greaterThan(n), text: `> ${n}` }))} />\n      </Controls>\n      <Panel givens={givens} />         {/* the dashboard itself (its tiles/query) */}\n      <Panel query="baby_names -> births_by_decade" givens={givens} />  {/* a specific query */}\n    </div>\n  );\n}\n```\n\nFrom `@malloyyo/dashboard` (also handed to the component as props):\n- **Widgets** (headless-ish; restyle via className/style or the `--dash-*` CSS\n  vars \u2014 see Theming below): `<Controls/>` (all givens, or compose children;\n  grows Apply/Reset under `autorun=false`), `<Given name/>`,\n  `<Select given [options]/>`, `<Search given/>` (committing input + typeahead +\n  inline \u2715 clear), `<MultiSelect given [options]/>` (chip multi-select for a\n  `filter<string>` \u2014 commits an exact-match list via `filters.oneOf`),\n  `<Range given [min max]/>`, `<TimeRange given [presets]/>` (temporal presets +\n  custom range), `<Checkbox given/>` (bound to a boolean given),\n  `<VegaChart spec query|malloy|data givens/>` (a Vega-Lite chart over query\n  rows \u2014 see `yo_help dashboards/vega-charts`)\n- **Hooks**: `useGiven(name)` \u2192 {value, set, spec};\n  `useOptions(name, typed?)` \u2192 {options, loading} (typeahead);\n  `useQuery({query|malloy, givens})` \u2192 {rows, loading, error} \u2014 plain rows\n  for your own visuals\n- **Helpers**: `filters.oneOf/contains/between/atLeast/\u2026` build\n  filter-expression strings with correct escaping; temporal:\n  `filters.lastN(7, "day")` \u2192 `\'7 days\'`, `filters.dateRange("2026-01-01",\n  "2026-07-01")`, `filters.afterDate/beforeDate`; read back with\n  `filters.values/numberRange/threshold/inLast/temporalRange`;\n  `filters.isValid(type, src)` checks typed input.\n  Never hand-concatenate a filter string.\n  **Escaping rule for custom controls:** a filter given\'s value is an\n  EXPRESSION, so committing a raw column value is wrong the moment it contains\n  a comma/percent/dash (\'Tesla, Inc.\' parses as two alternatives and matches\n  nothing). Commit `filters.oneOf(value)` (exact) or\n  `filters.contains(term)` (substring), and unwrap for display with\n  `filters.values(src)`. The stock `<Select/>` does this automatically;\n  `<Search/>` deliberately commits raw text (its input IS a filter\n  expression).\n- `<Panel/>` runs against the DASHBOARD\'s own file: a bare `<Panel/>` renders\n  the whole dashboard (its tiles); `<Panel query="\u2026"/>` runs a query defined in\n  the dashboard file (by name) or a `source -> view`; `<Panel malloy="\u2026"/>` and\n  `runData(text, givens)` run arbitrary Malloy as a RESTRICTED query (no import /\n  given: / connection.* / raw SQL / ##! flags \u2014 the model\'s governed surface\n  only). `lint` checks each hard-coded `query="\u2026"` still resolves.\n\n## Theming\n\nEvery widget is styled by the runtime\'s **default Malloyyo theme** (system\nfont, neutral grays, blue accent, auto light/dark following the viewer\'s OS) \u2014\na bare component looks styled with zero effort, so DON\'T hand-hardcode\n`fontFamily`/colors. The theme is CSS custom properties; override any subset by\nsetting them on a wrapper element (more specific than the runtime\'s `:root`):\n\n```tsx\n<div style={{ "--dash-accent": "#e11d48", "--dash-controls-bg": "#faf5ff" }}>\n  <Controls /> \u2026\n</div>\n```\n\nVars: `--dash-font`, `--dash-bg`, `--dash-fg`, `--dash-muted`, `--dash-border`,\n`--dash-accent`, `--dash-accent-fg`, `--dash-control-bg`, `--dash-controls-bg`,\n`--dash-chip-bg`, `--dash-chip-fg`, `--dash-panel-bg`, `--dash-radius`,\n`--dash-danger`. `DefaultDashboard` also takes a `theme={{ accent, controlsBg }}`\nprop (camelCase keys \u2192 `--dash-*`). The results `<Panel>` keeps a light surface\nin both light/dark (the Malloy renderer has no dark theme) \u2014 override\n`--dash-panel-bg` if your renderer output is dark-safe.\n\nFor charts beyond the Malloy renderer\'s `#` tags, use `<VegaChart>` \u2014\n`yo_help dashboards/vega-charts`.\n',
+  "dashboards/givens-and-controls.md": "---\ndescription: Dashboard filter controls \u2014 declare filter<T> givens with # label / suggest / control tags; faceted (related) suggestions\n---\n\n# Dashboard givens & controls\n\nA dashboard's filters are `filter<T>` **givens** declared in the model; the\n`#` tags on each declaration drive its control. This is part of authoring a\ndashboard \u2014 see also `yo_help dashboards/authoring`.\n\n**Declare the filters as `filter<T>` givens** \u2014 never raw strings/numbers.\nA `filter<string>` value accepts one value ('NY'), alternatives ('NY, CA'),\nwildcards ('Ann%'), negation ('-NY'); a `filter<number>` accepts ranges\n('[1910 to 1930]') and comparisons ('> 200'); a `filter<timestamp>` /\n`filter<date>` accepts relative windows ('7 days' = the last 7 days, 'today',\n'last month') and literal ranges ('2026-01-01 to 2026-07-01' \u2014 NO `@` in\nfilter literals). Apply with `~`; `f''` = empty = no filter (the natural\n\"All\"/\"all time\" \u2014 just `col ~ $X`, no `$X = '' or \u2026` dance):\n\n```malloy\n##! experimental { givens }\ngiven:\n  # label=\"State\" control=select suggest { source=baby_names dimension=state }\n  STATE :: filter<string> is f'NY'\n  # label=\"Brand\" suggest { query=brand_suggest dimension=product_brand }\n  BRAND :: filter<string> is f''\n  # label=\"Names\" control=multiselect suggest { query=name_suggest dimension=name }\n  NAMES :: filter<string> is f''\n  # label=\"Years\" range_min=1910 range_max=2025\n  YEAR_RANGE :: filter<number> is f'[1910 to 1930]'\n  # label=\"Time period\"\n  PERIOD :: filter<timestamp> is f''\n  # label=\"Include rare names\"\n  INCLUDE_RARE :: boolean is false\n```\n\nTags on the declaration drive the control (tag syntax is `key=\"value\"` \u2014\nequals, not colon):\n- `label` \u2014 control caption (defaults to the given's name)\n- `suggest { \u2026 }` \u2014 where the control's options come from. NO Malloy code in\n  strings \u2014 just names:\n  - `suggest { query=brand_suggest dimension=product_brand }` \u2014 the FIRST\n    COLUMN of a named query (declare the query in the model \u2014 governed and\n    reviewable). PREFER THIS FORM. The query must be in scope where the dashboard\n    runs (bring it in with the dashboard file's bare `import`).\n  - `suggest { source=baby_names dimension=state }` \u2014 the DISTINCT VALUES of\n    a dimension on a source (the source must be in the dashboard's scope)\n  A `dimension` (in either form) is what enables SERVER-SIDE TYPEAHEAD: the\n  runtime refines the base query with what the user has typed\n  (`\u2026 + { where: lower(field) ~ f'll%'; limit: 50 }`, case-insensitive,\n  escaped). Without a dimension the fetched list is filtered client-side.\n  Runs as a restricted query; lint checks the declaration compiles.\n\n  **RELATED (faceted) filters** \u2014 query-form only: a suggest query may\n  reference the OTHER givens, and the runtime runs it with the dashboard's\n  current values (the suggested given itself is excluded, so the list never\n  collapses to the current pick). Brand suggestions narrow when Category is\n  set:\n\n  ```malloy\n  query: brand_suggest is inventory_items -> product_brand + {\n    where:\n      product_category ~ $CATEGORY,      // NOT product_brand ~ $BRAND\n      product_department ~ $DEPARTMENT\n    limit: 500\n  }\n  ```\n\n  Declare one `*_suggest` per filter, each referencing the others; `f''`\n  defaults mean unset filters don't constrain. `source=` suggests can't do\n  this (no place for a `where:`) \u2014 another reason to prefer `query=`.\n- `control=select` \u2014 a fixed dropdown instead of a typeahead search box\n- `control=multiselect` \u2014 a tokenized multi-select for a `filter<string>`:\n  each pick is a removable chip, the committed value is an exact-match list\n  (`Emma, Olivia, Sophia`). Ideal for \"pick several\" filters (names, brands).\n  Suggestions come from the given's `suggest {\u2026}` (server-side typeahead when\n  it names a dimension). Empty (start from `f''`) = no filter (all).\n- `range_min` / `range_max` \u2014 bounds; makes a filter<number> given a\n  dual-thumb range slider\n- anything else passes through in `spec.tags` for custom components\n\nControl picked from the declaration automatically: numeric range tags \u2192\ndual-thumb slider; `filter<timestamp|timestamptz|date>` \u2192 the TimeRange\nwidget (relative presets: Today / Last 7 days / Last 30 days / \u2026 plus a\n\"Custom range\u2026\" from/to date picker); `control=multiselect` \u2192 chip\nmulti-select; suggest + control=select \u2192 dropdown; boolean \u2192 checkbox;\nanything else \u2192 committing search box with typeahead (an inline \u2715 clears it;\na \"Press \u21B5 to apply\" hint shows while the typed draft differs from what's\nrunning \u2014 free text can't safely re-run per keystroke).\nThe suggest-driven options are DATA VALUES only \u2014 options that aren't column\nvalues (custom time presets, threshold buckets) need a custom component\n(`yo_help dashboards/custom-components`) with explicit `{value, text}` options\nwhere value is a filter expression built with `filters.*`.\n\n## When the query re-runs: live (default) vs. Apply\n\nBy default a dashboard is **live** \u2014 every control change re-runs the query\nimmediately (the committing search box is the exception: free text commits on\nEnter/blur, since a half-typed filter is invalid). To batch changes behind an\n**Apply** button instead, set `autorun=false` on the `# artifact` tag:\n\n```malloy\n# artifact { name=\"births-by-name\" title=\"Births by name\" autorun=false }\n```\n\n`autorun=false` makes `<Controls>` grow an Apply/Reset pair \u2014 controls edit a\ndraft and nothing re-runs until Apply. Reach for it when the query is expensive\nor several filters are usually changed together; leave it off (live) otherwise.\n",
+  "dashboards/grid-layout.md": "---\ndescription: Dashboard grid layout \u2014 # dashboard {columns=N} with # colspan and # break to place KPI tiles and charts\n---\n\n# Dashboard grid layout (`# dashboard {columns=N}`)\n\nBy default a `# dashboard` result flows its KPI tiles and cards and wraps.\nAdd `{columns=N}` to place them on a fixed **N-column grid** instead \u2014 use\n`columns=6`, which divides evenly into 2- and 3-wide cards.\n\n**Key mechanic:** a tag placed ABOVE `aggregate:` or `nest:` applies to EVERY\nitem declared in that block. So you set card widths once per block, not per\nfield.\n\n```malloy\n# artifact { title=\"Customer Insights\" } dashboard {columns=6}\nview: customer_insights is {\n  where: created_at ~ $PERIOD\n  # colspan=2\n  aggregate: total_sales, user_count, order_count, average_order_value\n  # colspan=3\n  nest:\n    # break\n    # bar_chart\n    users_by_spend_tier\n    sales_by_traffic_source\n    # shape_map\n    sales_by_state\n    # colspan=6\n    recent_orders                      // wide detail table \u2192 full width\n}\n```\n\n## The conventions\n\n- **`# colspan=2` above `aggregate:`** \u2014 each KPI / measure tile spans 2 of 6\n  columns \u2192 3 tiles per row.\n- **`# colspan=3` above `nest:`** \u2014 each graph or small table spans 3 \u2192 2 per\n  row. Per-item render tags (`# line_chart`, `# bar_chart`, `# shape_map`) still\n  go on the individual nested items.\n- **`# colspan=6`** \u2014 a single wide / many-column table gets its own full-width\n  line. Tag that one item; a per-item `# colspan` overrides the block default.\n- **`# break` on the FIRST nest item** \u2014 starts the graphs on a fresh row, so\n  KPI tiles and charts never share one. The renderer splits fields into a new\n  grid at each `# break`. Just always add it: it's a no-op when the tiles\n  already fill complete rows, and the fix when they don't (e.g. 4 measures\n  leave a lone tile a colspan-3 chart would otherwise pack in beside).\n\n`# colspan` only does anything in columns mode \u2014 without `{columns=N}` the\nlayout is free-flow wrap and colspan is ignored. Clamp colspans to `1..N`.\n\nSee also `yo_help dashboards/vega-charts` for custom charts, and the fuller\nauthoring guide surfaced by the local `malloyyo mcp` server.\n",
+  "dashboards/vega-charts.md": '---\ndescription: Custom dashboard charts with Vega-Lite \u2014 the <VegaChart> component, for charts the # renderer tags can\'t do\n---\n\n# Custom charts with Vega-Lite (`<VegaChart>`)\n\nWhen Malloy\'s renderer tags (`# bar_chart`, `# line_chart`, `# shape_map`, \u2026)\ndon\'t cover the chart you want, a dashboard can draw a **Vega-Lite** spec with\nthe `<VegaChart>` component. The chart engine ships in the dashboard runtime, so\nyou author only a JSON spec + a Malloy query \u2014 no library to load.\n\n**It is a COMPONENT, not a `#` tag.** There is no `# vega_lite` or\n`# scatter_chart` tag. `<VegaChart>` lives in a custom component \u2014 a flat sibling\n`dashboards/<name>.jsx` (or `.tsx`) next to the dashboard\'s\n`dashboards/<name>.malloy` \u2014 a different layer from the `#` renderer tags. (The\ndashboard\'s query is declared in the `.malloy` file; the component only\ncustomizes presentation. Preview with `malloyyo dashboard dev`, validate with\n`malloyyo lint`.)\n\n## The recipe\n\n```tsx\nimport { VegaChart } from "@malloyyo/dashboard";\n\n// Encodings point at the query\'s OUTPUT COLUMN NAMES (here: name, births).\nconst spec = {\n  mark: { type: "bar", tooltip: true },\n  encoding: {\n    y: { field: "name", type: "nominal", sort: "-x" },\n    x: { field: "births", type: "quantitative" },\n  },\n};\n\nexport default function Dashboard({ givens }) {\n  return <VegaChart spec={spec} query="births_by_name" givens={givens} />;\n}\n```\n\nThree ways to feed it data:\n- `<VegaChart spec={spec} query="births_by_name" givens={givens}/>` \u2014 a query\n  defined in the dashboard\'s `.malloy` file (by name), or a `source -> view`\n- `<VegaChart spec={spec} malloy="source -> view" givens={givens}/>` \u2014 restricted\n  Malloy text (same governance as the explore surface: no import / given: /\n  connection.* / raw SQL / ##! flags)\n- `<VegaChart spec={spec} data={rows}/>` \u2014 rows you already have from `useQuery`\n\n## Gotchas (the ones that actually bite)\n\n- **Shape the data in Malloy; return FLAT rows.** Do ranking, share/percent\n  (`all(x, dim)`), and label lookups (a `pick` for month names) in the QUERY.\n  The spec just encodes columns \u2014 it is not the place to reshape data.\n- **Match column names character-for-character.** Run the query once with\n  `query(execute:true)` and read the exact output column names; the spec\'s\n  `field` values must match them exactly.\n- **The spec\'s `data` is ignored / any `url` is stripped.** The frame has no\n  network \u2014 remote data URLs, transform lookups, and remote `image` marks are\n  removed. Adapting a Vega-Lite gallery example = delete its\n  `"data": {"url": \u2026}` and repoint the encodings; the query rows are inlined for\n  you as the dataset.\n- **Nests come back as arrays.** Flatten to plottable rows in the query, or bind\n  a nest to its own chart: `<VegaChart data={row.my_nest}/>`.\n- **Interactivity = setting given values**, never rewriting query text per\n  interaction. Client-side chart interactions (tooltip, zoom, brush) work;\n  anything that calls a server does not.\n- **Reads well:** for normalized/share data use a diverging color scale with\n  `domainMid` (e.g. `1/12` for month-share), and sort a discrete axis by a\n  companion numeric field (`month_name` sorted by `month_num`) rather than\n  alphabetically.\n\n## Validate\n\n`malloyyo lint` checks the query, the givens, AND the component (it compiles,\nand each `query="\u2026"` it references resolves) \u2014 your only pre-browser check. Then\n`malloyyo dashboard dev` to see it render.\n',
   "develop/connection-setup.md": '---\ndescription: Setting up a data connection (malloy-config.json)\n---\n\n# Setting up a data connection\n\nA model reaches its data through a **connection** declared in\n`malloy-config.json` at the **root of the model** (next to `index.malloy`). This\nis Malloy\'s standard connection config \u2014 the full reference, with every\nconnector\'s properties, is at\n<https://docs.malloydata.dev/documentation/setup/config>. The essentials:\n\n## The file\n\n```json\n{\n  "connections": {\n    "mydb": { "is": "duckdb" }\n  }\n}\n```\n\n- A connection has a **name** (the key) and a type (`is`). Sources refer to it by\n  that name \u2014 `source: x is mydb.table("orders")` or `mydb.sql("SELECT \u2026")` \u2014 so\n  the name in the config must match the name in the model.\n- Supported types (`is`): `duckdb` (incl. MotherDuck), `bigquery`, `postgres`,\n  `mysql`, `snowflake`, `databricks`, `trino`, `presto`. Each has its own\n  properties \u2014 see the full docs.\n\n## Default connections (and when they apply)\n\nSetting `"includeDefaultConnections": true` makes one connection available for\n**each registered database type, named by the type** \u2014 a `duckdb` connection\nnamed `duckdb`, a `postgres` named `postgres`, and so on. Each uses that\nconnector\'s default settings, which for several backends means picking up\ncredentials from the environment (e.g. BigQuery\'s application-default\ncredentials \u2014 see the per-connector setup docs). Connections you name explicitly\nin `connections` always win; the defaults only fill in types you didn\'t list.\n\n```json\n{\n  "includeDefaultConnections": true,\n  "connections": { "warehouse": { "is": "postgres", "host": "\u2026" } }\n}\n```\n\nmalloyyo has one rule worth knowing:\n\n- **No `malloy-config.json` at all \u2192 defaults are ON.** `duckdb` just works with\n  zero setup.\n- **Write a `malloy-config.json` and they turn OFF** unless you add\n  `"includeDefaultConnections": true`. A config that only defines, say, a\n  `postgres` connection will report *No connection named "duckdb"* if a source\n  still references `duckdb`.\n\nThis is deliberate \u2014 your local connections then resolve exactly the way the\npublished server\'s will, rather than silently leaning on a default that would not\nexist in production. (It differs from `malloy-cli`, which forces the defaults on\nunconditionally.)\n\nGive a connection a **custom name** \u2014 not the bare type default \u2014 whenever you\nhave more than one connection of the same type, or need non-default parameters.\n\n## DuckDB and local files (the common case)\n\nDuckDB can either open a **DuckDB database file** or read **local data files**\n(CSV, Parquet, \u2026) directly.\n\n**A pre-loaded database file** \u2014 point `databasePath` at a `.duckdb` file and\nreference its tables by name (an absolute path is safest):\n\n```json\n{ "connections": { "warehouse": { "is": "duckdb", "databasePath": "/data/warehouse.duckdb" } } }\n```\n\n**Local files, by path** \u2014 read a CSV or Parquet file straight into a source.\nThese paths are **project-relative** \u2014 resolved against the model root, so they\nsurvive publishing:\n\n    source: my_csv     is duckdb.table(\'data/my_file.csv\')\n    source: my_parquet is duckdb.table(\'data/my_file.parquet\')\n\n`.table()` names a single file. When you need something it can\'t express \u2014 a\nglob, a union, any SQL \u2014 wrap it in `.sql()` (its paths are project-relative too):\n\n    source: payments is duckdb.sql(\n      "SELECT * FROM read_parquet(\'data/payments-*.parquet\')"\n    )\n\nThe default `duckdb` connection is **in-memory** \u2014 nothing persists between runs;\nyour data lives in the files (or the `databasePath` database) you read.\n\n**MotherDuck:** a DuckDB connection against an `md:` database; set the\n`MOTHERDUCK_TOKEN` environment variable.\n\n## Secrets \u2014 keep them out of the file\n\nAny property value may be written as `{ "env": "VAR_NAME" }`. It resolves from\n`process.env.VAR_NAME` when the connection opens, so passwords and tokens never\nget committed:\n\n```json\n{\n  "connections": {\n    "analytics": {\n      "is": "postgres",\n      "host": "db.internal",\n      "databaseName": "analytics",\n      "username": "reader",\n      "password": { "env": "PG_PASSWORD" }\n    }\n  }\n}\n```\n\n(The non-secret property names here are illustrative \u2014 each connector\'s exact\nproperties are in the full docs. The `{ "env": \u2026 }` form is the part that\nmatters: it works for any value.)\n\n## malloyyo specifics\n\n- **One file, one place.** Only the `malloy-config.json` at the model root is\n  read \u2014 there is no walk-up to parent directories.\n- **Local override:** a `malloy-config-local.json` (do **not** commit it)\n  **replaces** `malloy-config.json` entirely when present \u2014 your private variant\n  for local credentials or a different database.\n- **The same file ships to production.** Publishing uploads this exact\n  `malloy-config.json`, so it must resolve the same way locally and on the\n  server \u2014 put anything environment-specific behind `{ "env": \u2026 }` rather than\n  hard-coding it. That is what makes the local test window faithful to\n  production.\n- Edits are picked up **without a restart** \u2014 the server re-reads the file when\n  it changes.\n\n## When a connection will not resolve\n\nFix the connection **first**: a broken connection yields an empty schema and then\na cascade of misleading `field-not-found` errors \u2014 ignore those and fix the\nconnection. A fast check is to compile a probe and see if it alone compiles:\n\n    source: _probe is mydb.sql("SELECT 1 AS one")\n',
   "develop/getting-started.md": '---\ndescription: Getting started \u2014 build a Malloy model step by step\n---\n\n# Building a Malloy model, step by step\n\nA model is a `malloy-config.json` (the connection to the data) and an\n`index.malloy` (the published query surface), optionally with other `.malloy`\nfiles that `index.malloy` imports. You edit these with your own file tools; the\nMCP tools compile, inspect, and test what you wrote. Never read `.malloy` as\ntext \u2014 compiling a bare source is how you read a table\'s schema.\n\n## 1. Verify the connection first\n\nConfirm the connection named in `malloy-config.json` resolves \u2014 compile a\nthrowaway probe inline with `compile` (no file needed):\n\n    source: _probe is CONN.sql("SELECT 1 AS one")\n\nIf it compiles, the connection is good. If not, fix the connection / config\nbefore going further \u2014 a broken connection produces an empty schema and then a\ncascade of misleading `field-not-found` errors; ignore the cascade and fix the\nconnection. Call `yo_help("develop/connection-setup")` for how to set up or repair a connection.\n\n## 2. Identify the tables the model needs\n\nIf you are unsure which tables matter, ask the fox \u2014 they own the data and know\nwhere it lives.\n\n## 3. Get a base source per table\n\nA base is "what\'s in the table and what\'s computable from it" \u2014 no joins.\nDiscover the schema by compiling a bare stub inline with `compile`:\n\n    source: users_base is CONN.table("users")\n\n`compile` returns the full column list + types \u2014 that is your schema browser.\nThen write the base into its own file and iterate with `compile_file`, adding\nonly the dimensions and measures intrinsic to that one table:\n\n    // users_base.malloy\n    source: users_base is CONN.table("users") extend {\n      measure: user_count is count()\n    }\n\nIf the data lives in files rather than database tables \u2014 common when the\nconnection is DuckDB \u2014 DuckDB lets you name a file path as the table (a\nproject-relative path):\n\n    source: users_base is CONN.table(\'data/users.parquet\')\n\nOnly drop to a `.sql()` block when a single file-as-table can\'t express what you\nneed \u2014 e.g. globbing or unioning several files:\n\n    source: users_base is CONN.sql("SELECT * FROM read_parquet(\'data/users-*.parquet\')")\n\n(`read_parquet` there is DuckDB SQL, not Malloy \u2014 see `yo_help("develop/connection-setup")`.)\n\n## 4. Assemble index.malloy \u2014 the published surface\n\nImport the bases, join them into the consumer-facing sources, and explicitly\nexport what consumers may query:\n\n    import "users_base.malloy"\n    import "orders_base.malloy"\n\n    source: users is users_base extend {\n      join_many: orders is orders_base on id = orders.user_id\n    }\n    source: orders is orders_base extend { }\n\n    export { users, orders }\n\n**Export discipline** \u2014 the model is a published artifact, so be deliberate about\nits public surface:\n\n- Imported names are private. Base sources stay internal scaffolding unless you\n  export them.\n- Without an `export` statement, everything you define is public. Add one and the\n  surface becomes explicit: only the names you list \u2014 defined or imported \u2014 are\n  public.\n- Hide intermediates. A staging source you define only so other sources can build\n  on it should not be exported.\n- The export list is the consumer\'s menu \u2014 exactly what the test window and real\n  consumers can query, nothing more.\n\n## The loop\n\nEdit a file \u2192 `compile_file` \u2192 fix `problems[]` \u2192 `query` (pass the model file\'s\npath as `ref`; `execute: false` validates first and reports the givens the query\nneeds, supplied via `givens`). Query text is restricted \u2014 `import`, `given:`\ndeclarations, `connection.table`/`connection.sql`, raw SQL, and `##!` flags\nbelong in the model file, not the query. When `compile`/`compile_file` returns\n`formatted: false`, call `prettify` and save its output. Use project-relative\ndata paths, not absolute \u2014 they resolve against the project root and survive\npublishing the model.\n',
   "develop/working-with-models.md": "---\ndescription: Working with an existing Malloy model\n---\n\n# Working with an existing model\n\nAn existing model is an `index.malloy` (plus any `.malloy` files it imports) and\na `malloy-config.json`.\n\n## Understand the model\n\n- **Read `malloy-config.json` directly** \u2014 it is JSON, so read it as text. It\n  lists the connection(s) the model queries against; `yo_help(\"develop/connection-setup\")` explains\n  the format (and how to set one up or repair it).\n- **Do NOT read `.malloy` as text \u2014 compile it.** `compile_file` returns the\n  structured model: each source with its fields, joins, views, and named queries,\n  plus `problems[]`. That is how you describe what is in the model. (Compiling a\n  bare source \u2014 no `extend` block \u2014 likewise reads a raw table's schema.)\n\n## The loop\n\nEdit a file \u2192 `compile_file` \u2192 fix `problems[]` \u2192 `query`. Pass the model file's\npath as `ref`; `execute: false` validates first and reports the givens the query\nneeds (supplied via `givens`). Query text is restricted \u2014 `import`, `given:`\ndeclarations, `connection.table`/`connection.sql`, raw SQL, and `##!` flags\nbelong in the model file, not the query. When `compile`/`compile_file` returns\n`formatted: false`, run `prettify` and save its output. Use project-relative data\npaths, not absolute.\n",
   "explore/how-to.md": '---\ndescription: Extended instructions working with this MCP server\n---\n# General Notes\nMalloy is a combined semantic layer/query language. It describes data and analysis, and it can generate and execute SQL.\n\nYou answer questions from published Malloy semantic models. A model publishes sources and queries.\n\n* Some tools return problems[] to indicate invalid Malloy.  problems may have a `help_topic` field \u2014 call `yo_help(help_topic)` for detailed guidance.\n* `yo_help()` with no topic will show an index which include error explanations, examples of Malloy syntax for common patterns, and a language reference manual (Malloy syntax is still evolving).\n* Tools that inspect Malloy code return objects with schemas, among other things.  An entry with a name which requires `back-tick-quoting` (reserved word, special characters), will have `must_quote: true`\n* When limiting queries, do ranking, top-N, and member selection in Malloy, not in client code.  Results are byte-budgeted: oversized results are truncated (the response says so and may link the full result). Reading aggregated rows is better analysis and the only way to see everything.\n* Compose your answer from what the model publishes. When composing a query, you can make new sources, extending existing sources with measures dimensions and joins. If the model\'s surface genuinely cannot answer a question, that is useful signal about the model.\n\n# Answering A Question\nTo answer a question you need to see what sources are available which pertain to the question.\n\n`list_sources` (when available) \u2014 see the sources you can query, grouped by model, with each model\'s named queries. If you already know the source, go straight to describe_source.\n\n# Build the Query\n* New to a pattern? `yo_help("explore/query-examples")` \u2014 the handful of Malloy query shapes (views, the workhorse group_by/aggregate, filtered aggregates, `all()`, `extend:`, `select:`, `nest:`) that cover almost every question, with the SQL habits that are wrong in Malloy.\n* `describe_source(source, model_ref)` \u2014 always describe a source before querying it (`model_ref` optional when the name is unique). Returns:\n  * `described_source` \u2014 the source\'s `dimensions` (columns), `measures`, and `views` (the author\'s saved queries). A dimension\'s `type` is a scalar or a nested record (`origin.city`); an array column has no `type` \u2014 it shows up as a `joins` entry at its `path`.\n  * `joins` \u2014 keyed by path, the arrays and source-joins this source reaches. `fans_out` marks a path that fans out. Each entry is one of: `{ source }` (fields in `join_source_map`), `{ source_def }` (an anonymous source\'s fields, inline), or an array `{ is_array, source_def }` \u2014 a record array\'s fields are used directly (`parcels.sku`), a scalar array\'s element is `each` (`tags.each`). To write a reference, use the entry\'s `quoted_path` if it has one, else the key.\n  * `join_source_map` \u2014 the named sources those `{ source }` joins resolve to, deduped.\n  * In its own content block, the source\'s raw Malloy, for anything the structured output above doesn\'t cover.\n* `query(source: "...", malloy: "run: source -> { ... }", execute: false)` \u2014 validate without running; it returns the SQL. Iterate until clean. (`model_ref` optional, needed only when the source name is ambiguous.)\n* Some queries accept parameters (givens). More info if needed: yo_help("language/givens-model-level-parameters")\n\n# Run the query\n* Pass a plain-English question with EVERY query, describing what that specific query answers. Queries are recorded/shared independently. Don\'t try to group related queries.\n* query(source: "...", malloy: "run: source -> { ... }", question: "...") \u2014 run it; get the rows.\n\n# Displaying Results\n* Lead with a natural-language restatement of the query \u2014 a short heading works well.\n* A successful query comes back with an ltool_link \u2014 {text, url}, already assembled. It opens this exact query so the user can keep exploring, or share the insight. Follow the data with a markdown link, [\u2197 text](url).\n* When it helps the reader add a short note on how you got the answer: the Malloy logic (filters, grouping, aggregation, ordering, pipeline stages), and any post-processing done outside Malloy.',
-  "explore/query-examples.md": "---\ndescription: Worked query examples \u2014 the handful of Malloy shapes that cover almost every question. Read this before writing a query from scratch.\n---\n# Query Examples\n\nAlmost every query is one of the shapes below. Examples use a `flights` source\n(dimensions like `carrier`, `distance`, `origin`, `destination`, `state`,\n`dep_delay`, `is_small_plane`; measures `flight_count`, `total_distance`).\nSubstitute the real fields from `describe_source`.\n\nTwo rules first: do ordering, limiting, and ranking **in Malloy**, not in client\ncode \u2014 and reuse what the source already publishes before writing your own.\n\n## Run a saved view\n\nThe source may already answer the question. A view is invoked by name:\n\n```malloy\nrun: flights -> by_carrier\n```\n\nRefine a saved view in place with `+ { \u2026 }` \u2014 no need to rewrite it:\n\n```malloy\nrun: flights -> by_carrier + { where: state = 'CA' }\n```\n\n## The workhorse query\n\nWhen no view fits, write a stage. The vast majority of queries are this shape \u2014\n`group_by` the dimensions, `aggregate` the **measures the source already\ndeclares**, `where` to filter, `order_by` to rank. Reuse the measures\n`describe_source` lists (here `flight_count`); don't re-derive an aggregate the\nsource already defines (`count()`):\n\n```malloy\nrun: flights -> {\n  group_by: destination\n  aggregate: flight_count\n  where: state = 'CA'\n  order_by: flight_count desc\n  limit: 10\n}\n```\n\nEvery clause is `keyword:` (note the colon, including `order_by:`).\n\n### Aggregate moves\n\n**Filtered aggregate** \u2014 `measure { where: \u2026 }` filters *that one number* only,\nindependent of the stage `where:`. Two kinds of `where`: stage-level (which rows\nenter the query) vs aggregate-level (which rows a single aggregate counts).\n\n```malloy\nrun: flights -> {\n  group_by: carrier\n  aggregate:\n    flight_count\n    percent_late is flight_count { where: dep_delay > 15 } / flight_count * 100\n}\n```\n\n**Aggregates from scratch** \u2014 *only when the source has no measure for what you\nneed*, define your own with `is`:\n\n```malloy\nrun: flights -> {\n  group_by: carrier\n  aggregate:\n    flight_count is count()                -- row count\n    destination_count is count(destination) -- DISTINCT destinations\n    total_distance is distance.sum()        -- field-first aggregation\n}\n```\n\n**Percent of total with `all()`** \u2014 `all(expr)` ignores the `group_by:` to give\nthe grand total, so a share is `part / all(part)`:\n\n```malloy\nrun: flights -> {\n  group_by: carrier\n  aggregate:\n    flight_count\n    pct_of_total is flight_count / all(flight_count)\n}\n```\n\n(`all(expr, dim)` totals within a subgroup \u2014 it takes the **alias from\n`group_by:`**, not a dotted path.)\n\n### Declare once, reuse \u2014 `extend:`\n\nWhen an expression repeats in a query, define it locally in an `extend:` block:\n\n```malloy\nrun: flights -> {\n  extend: {\n    measure: total_distance is distance.sum()\n    dimension: state_first_letter is substr(state, 1, 1)\n  }\n  group_by: state_first_letter\n  aggregate:\n    total_distance\n    small_plane_distance is total_distance { where: is_small_plane }\n}\n```\n\n**Composing aggregates.** You can't reference one aggregate from another in the\nsame stage (`aggregate: a is \u2026, b is a/2` fails \u2014 *\"'a' is not defined\"*). To\nbuild a value *from* other aggregates \u2014 a ratio, a share \u2014 define the parts as\nmeasures in `extend:` (measures **can** reference each other), then use them:\n\n```malloy\nrun: flights -> {\n  extend: {\n    measure:\n      late_flights is flight_count { where: dep_delay > 15 }\n      pct_late is late_flights / flight_count\n  }\n  group_by: carrier\n  aggregate: late_flights, pct_late\n  order_by: pct_late desc\n}\n```\n\nTo rank by a computed value, name it (in `aggregate:` or `extend:`) and\n`order_by:` that name \u2014 `order_by:` takes an output field name, never a raw\nexpression, and there is no `derive:` step.\n\n## Flat detail rows \u2014 `select:`\n\nTo fetch raw rows instead of aggregating, use `select:` (the columns to return):\n\n```malloy\nrun: flights -> {\n  select: id, carrier, origin, destination, distance\n  where: distance > 1000\n  order_by: distance desc\n  limit: 100\n}\n```\n\nA stage is **either** a reduction (`group_by:` / `aggregate:`) **or** a projection\n(`select:`) \u2014 never both in the same stage. And `select:` **cannot** be combined\nwith `nest:` in any way; nesting belongs to reductions.\n\n## Nesting \u2014 a sub-table per row\n\n`nest:` attaches a whole query to each row of the outer one. This is where\nanswers get their depth (a per-row ranked breakdown):\n\n```malloy\nrun: flights -> {\n  group_by: origin\n  aggregate: flight_count\n  nest: by_carrier is {\n    group_by: carrier\n    aggregate: flight_count\n    order_by: flight_count desc\n    limit: 5\n  }\n}\n```\n\n**Listing top-N detail rows in a nest \u2014 `group_by:`, not `select:`.** A nest is a\nreduction, so to nest raw rows (not an aggregate) list the columns with\n`group_by:` (`select:` is not allowed inside a nest):\n\n```malloy\nrun: flights -> {\n  group_by: carrier\n  aggregate: flight_count\n  nest: longest_flights is {\n    group_by: origin, destination, distance\n    order_by: distance desc\n    limit: 5\n  }\n}\n```\n\n## Multi-stage \u2014 aggregate, then aggregate again (`->`)\n\nA second `->` runs another stage over the **output** of the first. Reach for it\nwhen you need to aggregate an aggregate \u2014 e.g. the **peak** of a per-period\ntotal. You can't write `flight_count.max()` (that's an aggregate of an aggregate\n\u2014 it errors); compute the per-period total in one stage, then take the max in the\nnext:\n\n```malloy\nrun: flights -> {\n  group_by: carrier, dep_year\n  aggregate: flights_that_year is flight_count\n} -> {\n  group_by: carrier\n  aggregate: peak_year is flights_that_year.max()\n}\n```\n\nIn the second stage `flights_that_year` is an ordinary column (the first stage's\noutput), so `.max()` is valid. The same shape filters or re-ranks already-\naggregated rows.\n\n## SQL habits that are WRONG in Malloy\n\n| You'd write in SQL | Malloy |\n| --- | --- |\n| `COUNT(DISTINCT x)` | `count(x)` \u2014 `count(distinct x)` is a deprecated error |\n| `SUM(x)` | `x.sum()` |\n| `SUM(x) OVER ()` | `all(x)` |\n| `COUNT(*) FILTER (WHERE c)` / `CASE WHEN` | `count() { where: c }` |\n| `SELECT \u2026 GROUP BY \u2026` | `group_by:` + `aggregate:` (one stage is reduction OR `select:`, never both) |\n",
+  "explore/query-examples.md": "---\ndescription: Worked query examples \u2014 the handful of Malloy shapes that cover almost every question. Read this before writing a query from scratch.\n---\n# Query Examples\n\nAlmost every query is one of the shapes below. Examples use a `flights` source\n(dimensions like `carrier`, `distance`, `origin`, `destination`, `state`,\n`dep_delay`, `is_small_plane`; measures `flight_count`, `total_distance`).\nSubstitute the real fields from `describe_source`.\n\nTwo rules first: do ordering, limiting, and ranking **in Malloy**, not in client\ncode \u2014 and reuse what the source already publishes before writing your own.\n\n## Run a saved view\n\nThe source may already answer the question. A view is invoked by name:\n\n```malloy\nrun: flights -> by_carrier\n```\n\nRefine a saved view in place with `+ { \u2026 }` \u2014 no need to rewrite it:\n\n```malloy\nrun: flights -> by_carrier + { where: state = 'CA' }\n```\n\n## The workhorse query\n\nWhen no view fits, write a stage. The vast majority of queries are this shape \u2014\n`group_by` the dimensions, `aggregate` the **measures the source already\ndeclares**, `where` to filter, `order_by` to rank. Reuse the measures\n`describe_source` lists (here `flight_count`); don't re-derive an aggregate the\nsource already defines (`count()`):\n\n```malloy\nrun: flights -> {\n  group_by: destination\n  aggregate: flight_count\n  where: state = 'CA'\n  order_by: flight_count desc\n  limit: 10\n}\n```\n\nEvery clause is `keyword:` (note the colon, including `order_by:`).\n\n### Aggregate moves\n\n**Filtered aggregate** \u2014 `measure { where: \u2026 }` filters *that one number* only,\nindependent of the stage `where:`. Two kinds of `where`: stage-level (which rows\nenter the query) vs aggregate-level (which rows a single aggregate counts).\n\n```malloy\nrun: flights -> {\n  group_by: carrier\n  aggregate:\n    flight_count\n    percent_late is flight_count { where: dep_delay > 15 } / flight_count * 100\n}\n```\n\n**Aggregates from scratch** \u2014 *only when the source has no measure for what you\nneed*, define your own with `is`:\n\n```malloy\nrun: flights -> {\n  group_by: carrier\n  aggregate:\n    flight_count is count()                -- row count\n    destination_count is count(destination) -- DISTINCT destinations\n    total_distance is distance.sum()        -- field-first aggregation\n}\n```\n\n**Percent of total with `all()`** \u2014 `all(expr)` ignores the `group_by:` to give\nthe grand total, so a share is `part / all(part)`:\n\n```malloy\nrun: flights -> {\n  group_by: carrier\n  aggregate:\n    flight_count\n    pct_of_total is flight_count / all(flight_count)\n}\n```\n\n(`all(expr, dim)` totals within a subgroup \u2014 it takes the **alias from\n`group_by:`**, not a dotted path.)\n\n### Declare once, reuse \u2014 `extend:`\n\nWhen an expression repeats in a query, define it locally in an `extend:` block:\n\n```malloy\nrun: flights -> {\n  extend: {\n    measure: total_distance is distance.sum()\n    dimension: state_first_letter is substr(state, 1, 1)\n  }\n  group_by: state_first_letter\n  aggregate:\n    total_distance\n    small_plane_distance is total_distance { where: is_small_plane }\n}\n```\n\n**Composing aggregates.** You can't reference one aggregate from another in the\nsame stage (`aggregate: a is \u2026, b is a/2` fails \u2014 *\"'a' is not defined\"*). To\nbuild a value *from* other aggregates \u2014 a ratio, a share \u2014 define the parts as\nmeasures in `extend:` (measures **can** reference each other), then use them:\n\n```malloy\nrun: flights -> {\n  extend: {\n    measure:\n      late_flights is flight_count { where: dep_delay > 15 }\n      pct_late is late_flights / flight_count\n  }\n  group_by: carrier\n  aggregate: late_flights, pct_late\n  order_by: pct_late desc\n}\n```\n\nTo rank by a computed value, name it (in `aggregate:` or `extend:`) and\n`order_by:` that name \u2014 `order_by:` takes an output field name, never a raw\nexpression, and there is no `derive:` step.\n\n## Flat detail rows \u2014 `select:`\n\nTo fetch raw rows instead of aggregating, use `select:` (the columns to return):\n\n```malloy\nrun: flights -> {\n  select: id, carrier, origin, destination, distance\n  where: distance > 1000\n  order_by: distance desc\n  limit: 100\n}\n```\n\nA stage is **either** a reduction (`group_by:` / `aggregate:`) **or** a projection\n(`select:`) \u2014 never both in the same stage. And `select:` **cannot** be combined\nwith `nest:` in any way; nesting belongs to reductions.\n\n## Nesting \u2014 a sub-table per row\n\n`nest:` attaches a whole query to each row of the outer one. This is where\nanswers get their depth (a per-row ranked breakdown):\n\n```malloy\nrun: flights -> {\n  group_by: origin\n  aggregate: flight_count\n  nest: by_carrier is {\n    group_by: carrier\n    aggregate: flight_count\n    order_by: flight_count desc\n    limit: 5\n  }\n}\n```\n\n**Listing top-N detail rows in a nest \u2014 `group_by:`, not `select:`.** A nest is a\nreduction, so to nest raw rows (not an aggregate) list the columns with\n`group_by:` (`select:` is not allowed inside a nest):\n\n```malloy\nrun: flights -> {\n  group_by: carrier\n  aggregate: flight_count\n  nest: longest_flights is {\n    group_by: origin, destination, distance\n    order_by: distance desc\n    limit: 5\n  }\n}\n```\n\n## Multi-stage \u2014 aggregate, then aggregate again (`->`)\n\nA second `->` runs another stage over the **output** of the first. Reach for it\nwhen you need to aggregate an aggregate \u2014 e.g. the **peak** of a per-period\ntotal. You can't write `flight_count.max()` (that's an aggregate of an aggregate\n\u2014 it errors); compute the per-period total in one stage, then take the max in the\nnext:\n\n```malloy\nrun: flights -> {\n  group_by: carrier, dep_year\n  aggregate: flights_that_year is flight_count\n} -> {\n  group_by: carrier\n  aggregate: peak_year is flights_that_year.max()\n}\n```\n\nIn the second stage `flights_that_year` is an ordinary column (the first stage's\noutput), so `.max()` is valid. The same shape filters or re-ranks already-\naggregated rows.\n\n## Make a cell a clickable deep link \u2014 `# link`\n\nWhen the answer is \"here's the row, go look at it in the source system\", tag a\n`group_by:`/`select:` field with `# link` so its cell renders as a hyperlink\n(in the shareable ltool view and in dashboards). Three forms:\n\n```malloy\nrun: flights -> {\n  # link                                                    -- the value IS a full URL\n  group_by: page is concat('https://wikipedia.org/wiki/', origin)\n}\n```\n\n```malloy\nrun: flights -> {\n  # link { url_template='https://www.flightsfrom.com/$$' }  -- $$ = this cell's value\n  group_by: origin\n}\n```\n\nLink to a value *other* than the one displayed with `field=`, and hide the raw\nid with `# hidden` so only the label shows:\n\n```malloy\nrun: flights -> {\n  # link { url_template='https://crm.example.com/person/$$' field=person_id }\n  group_by: person_name\n  # hidden\n  group_by: person_id\n}\n```\n\n`$$` is substituted anywhere in the template (`.../$$-SJC` works). Sibling\n`# image { url_template=\u2026 width= height= alt= }` renders the cell as an inline\nimage instead. Deep links open in a new browser tab.\n\n## SQL habits that are WRONG in Malloy\n\n| You'd write in SQL | Malloy |\n| --- | --- |\n| `COUNT(DISTINCT x)` | `count(x)` \u2014 `count(distinct x)` is a deprecated error |\n| `SUM(x)` | `x.sum()` |\n| `SUM(x) OVER ()` | `all(x)` |\n| `COUNT(*) FILTER (WHERE c)` / `CASE WHEN` | `count() { where: c }` |\n| `SELECT \u2026 GROUP BY \u2026` | `group_by:` + `aggregate:` (one stage is reduction OR `select:`, never both) |\n",
   "explore/restricted-queries.md": "# Restricted Query Explanation\n\nThe `query` tool runs your Malloy against a **published model**. You have that\nmodel's entire published surface to work with \u2014 and you can build on it. The\nmodel is an inentionally curated subset of the data available in the\ndatabase.\n\n## You can\n\n- Use everything the model defines: its **sources, dimensions, measures, views,\n  joins, and named queries**. `describe_source` shows exactly what's there.\n- **Run a named query and refine it** \u2014\n  `run: top_carriers + { where: dep_year = 2024 }`.\n- **Define your own** dimensions, measures, and **your own sources and joins** \u2014\n  as long as they are *derived from the model's sources*. You are not limited to\n  the author's fields; compose new ones from them.\n- Reference the model's `$NAME` givens and supply values via the `givens` map on\n  the `query` call (use `execute: false` to discover which a query needs).\n- Use a model field that was itself defined with raw SQL \u2014 the author vouched\n  for the model's own definitions.\n\n## What is \"Restricted\"\n\nIf you see `restricted-construct-forbidden`, the query used something that\nreaches *outside* the published model: pulling in another file (`import`),\nopening a raw connection (`connection.table(...)` / `connection.sql(...)`),\nwriting raw SQL (`name!type(...)` or the `sql_*` functions), declaring new\n`given:`s, or setting `##!` compiler flags.\n\nThe fix is never to work around it \u2014 express the answer in terms of what the\nmodel publishes (define derived sources, joins, dimensions, and measures from\nthe model's sources). If something fundamental is missing, that's feedback for\nthe model's author.\n",
-  "language/malloy-language-reference.md": '<!-- Copied from malloy-cli (jrtipton/malloy-cli) skills/malloy-language-reference.md on 2026-06-11.\n     Deliberate temporary fork \u2014 converge when the engine is extracted to @malloydata. -->\n---\ndescription: Malloy language reference \u2014 concepts, syntax, compilation model. Load this before writing or reviewing Malloy code.\n---\n# Malloy Language Reference\n\nMalloy is a semantic data modeling and query language. It compiles to SQL and runs against existing database engines (DuckDB, BigQuery, Snowflake, PostgreSQL, MySQL, Trino, Presto). It is not a SQL wrapper or abstraction layer \u2014 it has its own type system, scoping rules, expression semantics, and compilation pipeline.\n\nMalloy is designed around how humans think about data, not how data computations are mechanically accomplished. SQL is oriented around the machine \u2014 you specify joins, group-by columns, subqueries, and window functions in terms of what the database needs to do. Malloy is oriented around the analyst \u2014 you describe relationships, name computations, and compose questions in terms of what the data means. Malloy bridges the gap between these two by compiling the human-oriented description into correct, efficient SQL.\n\nA core design principle is that **most queries are themselves designing a new semantic model.** Formulating a question about data \u2014 choosing what to group by, what to aggregate, what to nest \u2014 is inherently an act of defining a new way to look at that data. Malloy is built around this idea: the output of every query is not just a result set but a new source with its own schema, and data comprehension is an ongoing iterative process where later stages want not only the data from a previous stage but how that data came into being. This is why query output carries metadata, why queries can be used as sources, and why views and pipelines compose naturally.\n\n## Documents and Statements\n\nA Malloy file (`.malloy`) is a sequence of statements, optionally separated by semicolons. There are five statement types:\n\n- **`import`** \u2014 import sources and queries from another `.malloy` file\n- **`source:`** \u2014 define a named, reusable data source with its schema and extensions\n- **`query:`** \u2014 define a named query (source + view) for reuse\n- **`run:`** \u2014 execute a query (the "do it now" statement)\n- **`given:`** \u2014 declare model-level parameters supplied at run time (experimental, see Givens)\n\n```malloy\nimport "shared_model.malloy"\n\nsource: flights is duckdb.table(\'flights.parquet\') extend {\n  measure: flight_count is count()\n}\n\nquery: carrier_summary is flights -> {\n  group_by: carrier\n  aggregate: flight_count\n}\n\nrun: carrier_summary\n```\n\nComments use `//` or `--` (both are line comments).\n\n## Sources\n\nA **source** is anything you can hand a SQL database and get a schema back \u2014 a table name, a SQL SELECT, or the output of another Malloy query. The columns in that schema become the source\'s initial fields (all dimensions).\n\n```malloy\nsource: flights is duckdb.table(\'flights.parquet\')\nsource: limited is duckdb.sql("""SELECT * FROM flights LIMIT 100""")\nsource: carrier_facts is carrier_summary   -- a query used as a source\n```\n\nWhat makes sources central to Malloy is **extension**. The `extend` block lets you layer on dimensions, measures, views, joins, filters, primary keys, field restrictions, and renames. These extensions travel with the source \u2014 any query against it gets them for free.\n\n```malloy\nsource: flights is duckdb.table(\'flights.parquet\') extend {\n  primary_key: id\n\n  dimension: distance_km is distance * 1.609344\n\n  measure:\n    flight_count is count()\n    total_distance is sum(distance)\n\n  join_one: carriers with carrier\n  join_one: origin_airport is airports on origin_airport.code = origin\n\n  where: dep_time > @2001\n\n  view: by_carrier is {\n    group_by: carrier\n    aggregate: flight_count, total_distance\n  }\n}\n```\n\nSources can extend other sources, creating a refinement chain:\n\n```malloy\nsource: ca_flights is flights extend {\n  where: origin.state = \'CA\'\n}\n```\n\nField access control uses `accept:` (allowlist) or `except:` (denylist) to restrict which inherited columns are visible. Fields can be renamed with `rename: new_name is old_name`.\n\n## Joins\n\nJoins are declared in the source, not reconstructed in every query. This is a fundamental design difference from SQL: the graph structure of your data is a property of the model.\n\n```malloy\njoin_one: carriers with carrier                          -- FK \u2192 PK shorthand\njoin_one: origin_airport is airports on origin_airport.code = origin  -- explicit ON\njoin_many: line_items on line_items.order_id = id        -- one-to-many\njoin_cross: other_table on other_table.key = key         -- cross join\n```\n\n- `join_one` \u2014 the joined source has at most one row per source row (many-to-one or one-to-one)\n- `join_many` \u2014 the joined source has potentially many rows per source row\n- `join_cross` \u2014 a full cross product\n\nThe `with` shorthand requires the joined source to have a declared `primary_key`. All joins are left outer by default. There is no right join \u2014 Malloy\'s graph model doesn\'t need one.\n\n**Choosing `join_one` vs `join_many`:** Ask "for a single row in the base source, can the joined source match more than one row?" If yes \u2192 `join_many`. If no (or at most one) \u2192 `join_one`. The common mistake is reaching for `join_many` when joining a *lookup or summary table* (e.g., joining an inventory snapshot to a purchase history on a wine key). Even though the joined table may have many rows overall, if each base row resolves to *at most one* joined row, use `join_one`. Use `join_many` only when the join genuinely fans out the base rows \u2014 e.g., joining line items to orders, or notes to a wine catalog.\n\nWhen you reference a joined source\'s fields, you use dot notation: `carriers.nickname`, `origin_airport.state`. This is one of Malloy\'s most important abstractions: **the access path to nested data is identical regardless of how the nesting is physically stored.** An array of records embedded in a column, a `join_many` to a separate table, a record-typed column \u2014 all are navigated with the same dot notation. The SQL required to traverse these different physical arrangements varies wildly (unnesting arrays, LEFT JOINs, correlated subqueries, ARRAY_AGG), but Malloy hides all of that. You think about the logical shape of your data \u2014 "flights have carriers, carriers have a nickname" \u2014 and write `carriers.nickname`. The compiler figures out what SQL is needed to get there. This means you can restructure your physical schema (normalize a nested array into a separate table, or denormalize a joined table into a record column) without changing any of the Malloy that references that data.\n\n## Fields\n\nMalloy has four kinds of fields: **dimensions**, **measures**, **views**, and **calculations**.\n\n### Dimensions\n\nScalar expressions \u2014 they compute a value per row. All columns inherited from a table are dimensions. Computed dimensions reference other dimensions or columns:\n\n```malloy\ndimension: full_name is concat(first_name, \' \', last_name)\ndimension: is_long_haul is distance > 1000\n```\n\n### Measures\n\nAggregate expressions \u2014 they compute a value across a set of rows. A field is a measure when its defining expression contains an aggregate function (`count`, `sum`, `avg`, `min`, `max`):\n\n```malloy\nmeasure:\n  flight_count is count()\n  total_distance is sum(distance)\n  avg_distance is avg(distance)\n  pct_delayed is count() { where: dep_delay > 30 } / count()\n```\n\n**`count(expr)` counts distinct values.** Unlike SQL\'s `COUNT(DISTINCT expr)`, Malloy uses `count(expr)` for distinct counting. The `count(distinct expr)` form is a deprecated syntax that will produce an error. Use `count()` for total row count, `count(field)` for distinct values of that field:\n\n```malloy\naggregate:\n  total_rows is count()               -- all rows\n  unique_carriers is count(carrier)   -- distinct carriers\n```\n\nMeasures can be filtered inline with `{ where: ... }`, which is how you build things like "percent of flights delayed" without subqueries.\n\n### Views\n\nA view is a query saved into the source \u2014 a reusable transformation:\n\n```malloy\nview: by_carrier is {\n  group_by: carrier\n  aggregate: flight_count, total_distance\n  limit: 10\n}\n```\n\nViews can reference other views from the same source as a starting point, and can be extended with `+`.\n\n### Calculations\n\nWindow functions over the grouped result. Calculations can only be defined in a query stage with `calculate:`, never in a source definition, because they depend on the output columns of the query:\n\n```malloy\nrun: flights -> {\n  group_by: carrier\n  aggregate: flight_count\n  calculate: carrier_rank is rank()\n}\n```\n\n## Queries and Views\n\nA query pairs a source with a view (the transformation). Everything after the first `->` is the view.\n\n```malloy\nrun: flights -> {\n  group_by: carrier\n  aggregate: flight_count\n}\n```\n\n### Reduction vs. Projection\n\nEach stage of a view performs exactly one of:\n\n- **Reduction** \u2014 uses `group_by:` and/or `aggregate:` to reduce grain. Analogous to `SELECT ... GROUP BY` in SQL.\n- **Projection** \u2014 uses `select:` to pick fields without aggregation. Analogous to `SELECT` without `GROUP BY`.\n\nThese cannot be mixed in a single stage. A stage with `group_by:` cannot have `select:`, and vice versa.\n\n### Source-level definitions vs. query-level operations\n\nThe same `name is expression` syntax defines fields in both sources and queries:\n\n```malloy\n-- In a source (reusable):\nsource: flights is ... extend {\n  measure: flight_count is count()          -- defines a measure in the model\n}\n\n-- In a query (ad hoc):\nrun: flights -> {\n  aggregate: flight_count is count()        -- defines the same measure inline\n}\n```\n\nWhen used in a source, `measure:` and `dimension:` are **definition statements** \u2014 they add named fields to the source\'s schema. When used in a query, `group_by:`, `aggregate:`, `select:`, `nest:`, and `calculate:` are **query operations** \u2014 they specify what the query does. The field definitions are syntactically identical in both contexts, but the enclosing keyword determines the role:\n\n| Source keyword | Query keyword | What it holds |\n|---|---|---|\n| `dimension:` | `group_by:` or `select:` | scalar expressions |\n| `measure:` | `aggregate:` | aggregate expressions |\n| `view:` | `nest:` | sub-queries |\n| _(n/a)_ | `calculate:` | window functions |\n\nThis is why `measure` and `aggregate` are separate keywords. `measure:` is a *modeling* statement \u2014 "this source has a reusable aggregate computation called X." `aggregate:` is a *query* statement \u2014 "in this query, include these aggregate values in the output." A query\'s `aggregate:` can reference a previously defined measure by name, or define one inline. The distinction parallels the separation between defining a dimension in a source and using it via `group_by:` in a query.\n\n### Multi-stage Pipelines\n\nStages chain with `->`. Each stage\'s output becomes the next stage\'s source:\n\n```malloy\nrun: flights -> {\n  group_by: carrier\n  aggregate: flight_count is count()\n} -> {\n  where: flight_count > 1000\n  select: *\n}\n```\n\n### Refinement with `+`\n\nThe refinement operator `+` merges query operations together. It works both within a view and at the top level on a named query:\n\n```malloy\n-- Refining a view within a query:\nrun: flights -> by_carrier + { limit: 5 } + { nest: by_destination }\n\n-- Refining a named query at the top level:\nrun: carrier_summary + { group_by: origin }   -- add origin grouping to existing query\n```\n\nWhen a dimension name appears as a bare reference, it expands to `{ group_by: name }`. A measure name expands to `{ aggregate: name }`:\n\n```malloy\nrun: flights -> carrier + flight_count + { limit: 10 }\n-- equivalent to: flights -> { group_by: carrier; aggregate: flight_count; limit: 10 }\n```\n\nFor multi-stage queries, refinement semantics get more complex \u2014 but for single-stage queries, `+` straightforwardly merges operations into the stage.\n\n### Nesting\n\n`nest:` embeds an aggregating subquery inside a reduction. Each row of the outer query gets a subtable from the nested query. Nests can nest arbitrarily deep:\n\n```malloy\nrun: flights -> {\n  group_by: carrier\n  aggregate: flight_count\n  nest: top_routes is {\n    group_by: origin, destination\n    aggregate: flight_count\n    limit: 3\n  }\n}\n```\n\n### Other query operations\n\n- **`where:`** \u2014 filter rows (pre-aggregation). Comma-separated filters are ANDed.\n- **`having:`** \u2014 filter groups (post-aggregation), like SQL\'s HAVING.\n- **`limit:`** / **`order_by:`** \u2014 limit and sort output.\n- **`extend`** \u2014 add fields or joins to a source inline within a query expression.\n\n## Aggregate Locality (Symmetric Aggregates)\n\nThis is one of Malloy\'s most important features. In SQL, when you join tables and aggregate, you risk double-counting (the "fan trap"). Malloy solves this with **aggregate locality** \u2014 you specify *where in the join graph* an aggregation should be computed.\n\n```malloy\nrun: flights -> {\n  aggregate:\n    -- avg seats weighted by number of flights (locality: source, i.e. flights)\n    avg_seats_per_flight is source.avg(aircraft.aircraft_models.seats)\n    -- avg seats per aircraft model (locality: aircraft_models)\n    avg_seats_per_model is aircraft.aircraft_models.seats.avg()\n}\n```\n\nThree syntactic forms:\n\n- `avg(expr)` \u2014 aggregate at the current source (implicit locality)\n- `joined_source.avg(expr)` \u2014 aggregate at the specified join point (explicit locality)\n- `joined_source.field.avg()` \u2014 shorthand for aggregating the field at its parent source\n\nFor `sum` and `avg` (asymmetric aggregates), when the expression crosses a join boundary, Malloy *requires* explicit locality \u2014 it won\'t silently give you a wrong answer. For `min`, `max`, and `count` (symmetric), locality doesn\'t change the result, so implicit is always fine.\n\nMalloy implements this with a technique called **symmetric aggregates** \u2014 it internally de-duplicates rows based on primary keys at the appropriate join level, so aggregations are always mathematically correct regardless of join fan-out.\n\n## Ungrouped Aggregates\n\n`all()` and `exclude()` allow computing aggregates at different grouping levels within a single query:\n\n```malloy\nrun: airports -> {\n  group_by: state, faa_region\n  aggregate:\n    airport_count is count()\n    total_airports is all(count())                   -- ungrouped: total across all rows\n    region_airports is all(count(), faa_region)       -- grouped only by faa_region\n    pct_of_total is count() / all(count())\n}\n```\n\n`all(expr)` removes all grouping. `all(expr, dim1, dim2)` keeps only the specified grouping dimensions. `exclude(expr, dim)` removes the specified dimension from grouping.\n\n**Important:** `all(expr, dim)` takes the **local alias name** as defined in the query\'s `group_by:`, not a dotted path. If you want to partition by a joined field, alias it first:\n\n```malloy\n-- WRONG: all(count(), director.primaryName)  -- dot paths don\'t work here\n-- RIGHT:\nrun: movies -> {\n  group_by: director is director.primaryName   -- alias it\n  aggregate:\n    movies is count()\n    director_total is all(count(), director)   -- reference the alias\n    pct is count() / all(count(), director)\n}\n```\n\n## Expressions\n\nMalloy expressions include arithmetic, comparison, logical operators, function calls, type casts, and several Malloy-specific forms.\n\n### Evaluation Spaces\n\nEvery expression has an evaluation space: **literal**, **constant**, **input**, or **output**. Input expressions reference source columns/dimensions. Output expressions reference the results of the current query stage (used in `calculate:`). Some functions constrain their arguments \u2014 e.g., `lag(expr)` requires an output expression, `avg(expr)` requires an input expression.\n\n### Application and Partial Comparison\n\nThe `?` operator applies a condition to a value. Partial comparisons are conditions without a left-hand side:\n\n```malloy\nwhere: state ? \'CA\' | \'NY\'         -- state is \'CA\' or \'NY\'\nwhere: distance ? > 500 & < 2000   -- distance between 500 and 2000\n```\n\n`|` is alternation (OR), `&` is conjunction (AND) within partials.\n\n### Pick Expressions\n\nMalloy\'s equivalent of CASE:\n\n```malloy\ndimension: size_bucket is\n  pick \'short\' when distance < 500\n  pick \'medium\' when distance < 1500\n  else \'long\'\n```\n\n### Filtered Aggregate Expressions\n\nAny aggregate can be filtered inline:\n\n```malloy\nmeasure: ca_flights is count() { where: origin.state = \'CA\' }\n```\n\n### Type Casting\n\n```malloy\ntotal_distance::string       -- Malloy type cast\nname::"VARCHAR(32)"          -- database-native type cast\n```\n\n### Time Literals and Ranges\n\n```malloy\n@2003                       -- the year 2003\n@2003-Q2                    -- second quarter of 2003\n@2024-01-15 10:30:00        -- timestamp literal\ndep_time ? @2003 to @2005   -- range comparison\nnow                         -- current timestamp\n```\n\n## Data Types\n\nMalloy\'s type system: `string`, `number`, `boolean`, `date`, `timestamp`, `timestamptz`, `json`, and `sql native` (for unsupported database types). Compound types: `type[]` for arrays, `{ name :: type, ... }` for records, nesting arbitrarily: `{ x :: number, tags :: string[] }[]`.\n\n## Annotations and Tags\n\nThese are related but distinct concepts.\n\n### Annotations\n\nAnnotations are **text strings** attached to objects during compilation. They are metadata \u2014 they never affect query execution or SQL generation. An annotation starts with `#` and continues to end of line:\n\n```malloy\n# bar_chart\nview: by_carrier is { ... }\n```\n\n- `#` annotations attach to the next object defined below them\n- `##` annotations attach to the model (the file)\n- Block annotations use `#|` ... `|#` for multi-line content (closing delimiter must match the column position of the opener)\n\nAnnotations distribute over definition lists:\n\n```malloy\n# currency\nmeasure:           -- all three measures get the # currency annotation\n  revenue is sum(amount)\n  # percent          -- this measure also gets # percent\n  margin is revenue / cost\n  cost is sum(amount)\n```\n\n### Tags (a use of annotations)\n\nTags are the primary *consumer* of annotation strings. They interpret annotation text using a structured property language (MOTLY). The key distinction: **annotations are the transport mechanism (raw strings attached to objects), tags are the interpretation layer (parsed key-value properties).**\n\nNot all annotations are tags. An annotation is just text. Tags are annotations that happen to be written in the tag property language and parsed by an application.\n\n### Annotation prefixes (routing)\n\nThe character(s) immediately after `#` route the annotation to different consumers:\n\n- `# ` (hash-space) \u2014 renderer tags, parsed by the Malloy VS Code extension for visualization\n- `##!` \u2014 compiler directives (e.g., `##! experimental.parameters`, `##! experimental.givens`)\n- `#"` \u2014 reserved for documentation strings\n- `#(appName)` \u2014 application-specific tags (e.g., `#(docs) hidden`)\n\n```malloy\n# bar_chart size=large        -- renderer tag: tells VS Code how to render\n##! experimental.parameters   -- compiler tag: enables a feature flag\n#(myApp) priority=high        -- custom app tag: ignored by renderer/compiler\n```\n\n### Tag property syntax\n\n```\ntName                         -- boolean flag (exists = true)\ntName=value                   -- set property value\ntName=[a, b, c]               -- array value\ntName: { p1=v1 p2=v2 }       -- nested properties (replaces)\ntName { p1=v1 }               -- nested properties (merges)\n-tName                        -- delete a property\ntName.sub.path=value          -- deep path assignment\n```\n\nValues can be unquoted identifiers, quoted strings, numbers, or typed values prefixed with `@` (`@true`, `@false`, `@2024-01-15`).\n\n## Givens (Model-Level Parameters)\n\n**Status: experimental, gated by `##! experimental.givens`.** Naming is provisional.\n\nGivens are values supplied at run time that the model can reference in any expression. The motivating use case is row-level access control \u2014 a model written once with `where: x.tenant_id = $TENANT` and the tenant supplied per API call \u2014 but they also fit configuration values, session context, and any "one compiled model, many invocations with varying context" pattern.\n\nGivens are model-wide: a single namespace, one value per name per compilation. They are *complementary to* source/query parameters (`source: foo(x :: string) is ...`), not a replacement. Use a parameter when you want two differently-bound copies of the same source side-by-side in one model; use a given when you want one value visible everywhere in the compilation.\n\n### Declaration\n\nThe `given:` top-level statement introduces givens, with a name, a type, and an optional default:\n\n```malloy\ngiven:\n  TENANT :: string\n  MAX_ROWS :: number is 1000\n  CUTOFF_DATE :: date is @2024-01-01\n```\n\nType can be any Malloy atomic type or compound type, including `filter<T>`:\n\n```malloy\ngiven:\n  ROLE :: string\n  ALLOWED_ROLES :: string[]\n  SESSION :: { user_id :: string, tenant :: string }\n  TENANT_FILTER :: filter<string>\n```\n\nDefaults are expressions over constants and other givens. Annotations attach to given declarations the same way they attach to sources or measures.\n\n### Reference: the `$` sigil\n\nInside any expression, a given is referenced with a leading `$`:\n\n```malloy\nsource: orders_for_user is orders extend {\n  where: orders.tenant_id = $TENANT\n}\n\nquery: recent_orders is orders_for_user -> {\n  where: order_date >= $CUTOFF_DATE\n  limit: $MAX_ROWS\n}\n```\n\n`$` appears *only* at expression references. The other three sites where a given\'s name appears \u2014 declaration, import, and supply (caller side) \u2014 use the bare name, because syntactic position already disambiguates. Givens share the top-level declaration namespace with sources/queries/views, so `source: x is ...` plus `given: x :: string` is a name-conflict error.\n\n### Set membership: `expr in $arrayGiven`\n\nThe RHS of `in` is either a parenthesized list of expressions (`in (1, 2, x, y * 7)`, same as SQL) or a given with an array value (`in $ARR`). A bare array-typed expression \u2014 a dimension, a joined array field, an inline `[a, b, c]` literal \u2014 is *not* legal on the RHS; arrays only reach the RHS via the given form.\n\nWhen a given has array type, `expr in $ARR` tests `expr` against the runtime-bound array; `not in $ARR` is the negation. The left-hand side must match the array\'s element type (`string in $string[]`, `number in $number[]`, etc.); mismatches are translate-time errors. Records and nested arrays are out of scope.\n\n```malloy\ngiven:\n  ALLOWED_STATES :: string[]\n  URGENT_STATUSES :: string[]\n\nsource: orders extend {\n  where: state in $ALLOWED_STATES\n  dimension: is_urgent is order_status in $URGENT_STATUSES\n}\n```\n\nAt SQL emit, the array\'s contents land in a generated `IN (...)` clause. Empty or `null` arrays collapse to the obvious result (`IN` \u2192 `FALSE`, `NOT IN` \u2192 `TRUE`). NULL elements inside a non-empty array follow standard SQL `IN` semantics.\n\nTo derive a value from an array \u2014 typically a boolean gate \u2014 *without* the array itself reaching row-position SQL, use an inline given (below).\n\n### Inline givens\n\nAn `inline` given is evaluated at **bind time**, before SQL is emitted: its default expression runs against the resolved given values and reduces to a literal, and that literal is what reaches SQL.\n\n```malloy\ngiven:\n  CAPABILITIES :: string[]\n  inline CAN_READ_ORDERS :: boolean is \'read_orders\' in $CAPABILITIES\n  inline CAN_MUTATE :: boolean\n    is \'write_orders\' in $CAPABILITIES or \'admin\' in $CAPABILITIES\n\nsource: orders extend {\n  where: $CAN_READ_ORDERS   -- SQL sees: WHERE ... AND TRUE  (or FALSE)\n}\n```\n\nThis is the **row-level access-control gate** pattern: the host supplies a capability list as a regular given, an inline given derives a boolean from it, and only the boolean \u2014 not the list \u2014 crosses into row-position SQL. The query planner sees a constant predicate.\n\nRules:\n\n- An inline given **must** have a default. `inline FOO :: number` with no `is` clause is a translate-time error.\n- The default may use:\n  - Boolean and comparison operators: `and`, `or`, `not`, `=`, `!=`, `<`, `<=`, `>`, `>=`\n  - The `in $array` test against another given\n  - Literals (string, number, boolean, null, array) and references to other givens\n- The default cannot call SQL functions, reference fields, or use any operator outside that list. Disallowed operators are reported at translate time with the offending operator names.\n- Inline givens are filtered out of `Model.givens` and `PreparedQuery.givens` \u2014 they\'re computed, not supplied \u2014 so introspection-driven UIs don\'t render editors for them. A caller can still shadow one by binding it explicitly (useful in tests).\n- `inline` is a context-sensitive modifier, not a reserved keyword: fields, sources, views, dimensions, and joins can still be named `inline`.\n\n### Imports\n\nGivens behave like every other top-level named thing under import:\n\n- **Bare import** (`import "b.malloy"`) brings B\'s full export surface in, including all of B\'s givens, under their original names.\n- **Selective import** (`import { source1 } from "b.malloy"`) brings in only what\'s listed. To surface a given to your callers, list it: `import { source1, MAX_ROWS } from "b.malloy"`.\n- **Rename** uses the existing `LOCAL is REMOTE` form: `import { CAP is MAX_ROWS } from "b.malloy"`.\n\nSurfacing controls *who can supply a value*, not whether internal references work. An imported source can reference a given the importer didn\'t surface; the reference still resolves internally, and at run time the unsurfaced given relies on its declaration-site default.\n\nA common project convention is a shared `tenant_givens.malloy` (declaring `$TENANT`, `$USER_ROLE`, etc.) that every root file bare-imports on line 1, so the project\'s given contract is visible at the top of any model.\n\n### Satisfiability\n\nA query referencing `$X` is satisfiable if either `$X` is in the model\'s namespace (so a caller can supply a value) or `$X` has a default at its declaration site. Otherwise the query is unsatisfiable and errors. Latent definitions (views, dimensions, measures) that reference `$X` are fine if no query actually invokes them \u2014 satisfiability is a property of running queries.\n\n### Supplying values\n\nValues can be supplied at two layers, which compose (per-query overrides per-runtime):\n\n**Per-runtime** \u2014 bound to a `Runtime`, applied as defaults to every query through it. Two paths:\n\n1. **`givensPath` in `malloy-config.json`** points at a JSON file of `name \u2192 value`:\n   ```jsonc\n   { "givensPath": "./local-givens.json" }\n   // or env-var indirection (resolved at config load):\n   { "givensPath": { "env": "GAME_STORE_GIVENS" } }\n   ```\n   The values file is a flat JSON map, keys are caller-facing surface names:\n   ```jsonc\n   { "TENANT": "acme", "USER_ROLE": "admin", "CUTOFF_DATE": "2024-01-01" }\n   ```\n\n2. **Direct on the Runtime constructor** (for per-request multi-tenant servers, tests, scripts):\n   ```typescript\n   const runtime = new Runtime({\n     config,\n     givens: { TENANT: claims.tenant_id, USER_ROLE: claims.role },\n     urlReader,\n   });\n   ```\n   Constructor values *merge over* the file at `givensPath` per-key.\n\n**Per-query** \u2014 supplied on a single `.run({ givens: ... })` call:\n```typescript\nawait query.run({ givens: { STATE_FILTER: "CA", LIMIT_OVERRIDE: 50 } })\n```\nAvailable on every compile-or-run entry point (`runtime.loadQuery(...).run(options)`, `preparedQuery.getPreparedResult(options)`, `preparedQuery.getSQL(options)`).\n\nThe resolved per-runtime values are exposed on `runtime.givens` (read-only) for diagnostics.\n\n### Finalized givens (security primitive)\n\nA multi-tenant deployment usually wants `TENANT`/`USER_ROLE`/`REGION` to be runtime-bound and **un-overridable per-query** \u2014 otherwise a downstream endpoint that accidentally accepts user-controlled query params and plumbs them into `.run({ givens: ... })` becomes a tenant-leak vulnerability.\n\n`finalizeGivens` in the config locks names at the API surface:\n\n```jsonc\n{\n  "givensPath": { "env": "GAME_STORE_GIVENS" },\n  "finalizeGivens": ["TENANT", "USER_ROLE", "REGION"]\n}\n```\n\nFinalize doesn\'t change *what* a given resolves to \u2014 only *who* can supply it. A `.run({ givens: { TENANT: ... } })` for a finalized name throws at API entry (named, not silently dropped). Finalized givens are filtered out of `Model.givens` and `PreparedQuery.givens` so introspection-driven UIs don\'t render editors for locked names.\n\n### JS shapes for supplied values\n\nBoth the JSON values file and per-query `givens` maps accept the same per-type shapes:\n\n| Malloy type | JS |\n|---|---|\n| `string` | string |\n| `number` | `number`, `bigint`, or string (precision escape hatch) |\n| `boolean` | boolean |\n| `date` | ISO date string `"2024-01-15"` |\n| `timestamp` (naive) | ISO string without offset \u2014 *not* a JS `Date` |\n| `timestamptz` | JS `Date` or ISO string with offset (string preferred \u2014 makes TZ choice visible) |\n| `T[]` | JS array |\n| `{ name :: T, ... }` | JS object |\n| `filter<T>` | JS string (Malloy filter expression source) |\n\nNaive timestamp givens reject `Date` because `Date` represents a UTC instant, not a wall-clock value, and `new Date("2001-01-01T00:00:00")` silently picks up the system\'s local TZ. Type mismatches throw at the boundary with a path that points at the offending location (e.g., `givens.SESSION.user_id: expected string, got number`). `null` is legal for any given type.\n\n### Introspection\n\n`Model.givens` and `PreparedQuery.givens` expose, to the host, the supplyable givens \u2014 for whole-model parameter editors and per-query "run this" forms respectively. Each entry carries name, type, default expression (or undefined if the caller must supply), location, and access to declaration-site annotations via `tagParse`/`getTaglines`.\n\n## How a Malloy Query Becomes SQL\n\nThe compilation pipeline has two phases:\n\n### Phase 1: Translation (source code \u2192 IR)\n\n```\nMalloy source \u2192 ANTLR lexer/parser \u2192 parse tree \u2192 AST builder \u2192 AST \u2192 IR generator \u2192 IR\n```\n\nThe **Intermediate Representation (IR)** is a plain, serializable data structure (JSON-compatible) that fully describes the semantic model and query. Note that IR is *not* dialect-agnostic \u2014 the same Malloy source compiled against different databases can produce different IR, because schema information, type mappings, and available functions vary by backend. It can be cached, transmitted, and reused. Key IR types:\n\n- **`SourceDef`** \u2014 a source\'s complete definition: schema, fields, joins, filters\n- **`Query`** \u2014 a source paired with a pipeline of operations\n- **`FieldDef`** \u2014 definition of any field (dimension, measure, join, calculation)\n- **`Expr`** \u2014 expression tree (arithmetic, comparisons, aggregates, function calls, field references)\n\nThe translator handles all language-level semantics: scoping, name resolution, type checking, evaluation space validation.\n\n### Phase 2: Compilation (IR \u2192 SQL)\n\n```\nIR \u2192 query compiler \u2192 expression compiler \u2192 dialect-specific SQL generator \u2192 SQL + metadata\n```\n\nThe compiler walks the IR query pipeline, translating each stage into SQL constructs (CTEs, subqueries, GROUP BY, window functions). A **Dialect** layer handles database-specific SQL generation.\n\nThe compiler also produces **metadata** alongside the SQL \u2014 structural information needed to interpret the result set (column types, nesting structure, annotation data). This metadata is what allows Malloy renderers to reconstruct nested/hierarchical results from the flat SQL result set and apply visualization tags.\n\n### Key architectural consequences\n\n- Because the IR is serializable, it can be cached and reused across compilations (though IR is database-specific \u2014 the same source compiled against different backends may produce different IR).\n- Because joins are declared in the source (not the query), the compiler knows the full join graph and can compute symmetric aggregates correctly.\n- Because nested queries are first-class, the compiler generates the appropriate SQL (correlated subqueries or ARRAY_AGG patterns depending on dialect) automatically.\n- Because measures are typed as aggregates in the IR, the compiler can validate that they only appear in aggregate context and enforce locality rules.\n\n## Where to Go Deeper\n\nThis document is a conceptual reference \u2014 enough to reason about the language and its design, but not exhaustive. Here\'s where to find more detail.\n\n### Language Documentation\n\nThe full docs live at [https://docs.malloydata.dev](https://docs.malloydata.dev). Key pages by topic:\n\n| Topic | URL |\n|---|---|\n| Sources, extensions, joins, primary keys | [documentation/language/source](https://docs.malloydata.dev/documentation/language/source) |\n| Queries, views, reduction vs projection | [documentation/language/query](https://docs.malloydata.dev/documentation/language/query), [views](https://docs.malloydata.dev/documentation/language/views) |\n| Fields: dimensions, measures, views, calculations | [documentation/language/fields](https://docs.malloydata.dev/documentation/language/fields) |\n| Aggregate functions and aggregate locality | [documentation/language/aggregates](https://docs.malloydata.dev/documentation/language/aggregates) |\n| Ungrouped aggregates (`all`, `exclude`) | [documentation/language/ungrouped-aggregates](https://docs.malloydata.dev/documentation/language/ungrouped-aggregates) |\n| Nested views / aggregating subqueries | [documentation/language/nesting](https://docs.malloydata.dev/documentation/language/nesting) |\n| Joins | [documentation/language/join](https://docs.malloydata.dev/documentation/language/join) |\n| Expressions, operators, pick, apply | [documentation/language/expressions](https://docs.malloydata.dev/documentation/language/expressions) |\n| Evaluation spaces (literal, constant, input, output) | [documentation/language/eval_space](https://docs.malloydata.dev/documentation/language/eval_space) |\n| Filters and filter placement | [documentation/language/filters](https://docs.malloydata.dev/documentation/language/filters) |\n| Annotations and tags | [documentation/language/tags](https://docs.malloydata.dev/documentation/language/tags) |\n| Calculations and window functions | [documentation/language/calculations_windows](https://docs.malloydata.dev/documentation/language/calculations_windows) |\n| Data types | [documentation/language/datatypes](https://docs.malloydata.dev/documentation/language/datatypes) |\n| Time operations, ranges, timezones | [documentation/language/timestamp-operations](https://docs.malloydata.dev/documentation/language/timestamp-operations), [time-ranges](https://docs.malloydata.dev/documentation/language/time-ranges), [timezones](https://docs.malloydata.dev/documentation/language/timezones) |\n| Imports | [documentation/language/imports](https://docs.malloydata.dev/documentation/language/imports) |\n| Top-level statements and model structure | [documentation/language/statement](https://docs.malloydata.dev/documentation/language/statement) |\n| Functions reference | [documentation/language/functions](https://docs.malloydata.dev/documentation/language/functions) |\n\n### Examples and Patterns\n\nThe docs site includes worked examples of common analytical patterns at [documentation/patterns](https://docs.malloydata.dev/documentation/patterns/): percent-of-total, year-over-year, cohort analysis, sessionization, moving averages, nested subtotals, and more.\n\nEnd-to-end guides are at [documentation/user_guides](https://docs.malloydata.dev/documentation/user_guides/), including [Malloy by Example](https://docs.malloydata.dev/documentation/user_guides/malloy_by_example) (a comprehensive walkthrough) and a three-part series for SQL users ([part 1](https://docs.malloydata.dev/documentation/user_guides/sql_experts1), [part 2](https://docs.malloydata.dev/documentation/user_guides/sql_experts2), [part 3](https://docs.malloydata.dev/documentation/user_guides/sql_experts3)).\n\n### Source Code\n\nThe Malloy implementation lives at [github.com/malloydata/malloy](https://github.com/malloydata/malloy). Key entry points:\n\n| What | Where |\n|---|---|\n| ANTLR grammar (lexer + parser) | `packages/malloy/src/lang/grammar/` |\n| AST node hierarchy | `packages/malloy/src/lang/ast/` |\n| Parse tree \u2192 AST builder | `packages/malloy/src/lang/malloy-to-ast.ts` |\n| IR type definitions | `packages/malloy/src/model/malloy_types.ts` |\n| IR \u2192 SQL compiler | `packages/malloy/src/model/` |\n| Dialect-specific SQL generation | `packages/malloy/src/dialect/` |\n| Tag/annotation parsing (MOTLY) | `packages/malloy-tag/` |\n| Renderer | `packages/malloy-render/` |\n| Architecture overview | `CONTEXT.md` (root and in each package) |\n',
+  "language/malloy-language-reference.md": '<!-- Copied from malloy-cli (jrtipton/malloy-cli) skills/malloy-language-reference.md on 2026-06-11.\n     Deliberate temporary fork \u2014 converge when the engine is extracted to @malloydata. -->\n---\ndescription: Malloy language reference \u2014 concepts, syntax, compilation model. Load this before writing or reviewing Malloy code.\n---\n# Malloy Language Reference\n\nMalloy is a semantic data modeling and query language. It compiles to SQL and runs against existing database engines (DuckDB, BigQuery, Snowflake, PostgreSQL, MySQL, Trino, Presto). It is not a SQL wrapper or abstraction layer \u2014 it has its own type system, scoping rules, expression semantics, and compilation pipeline.\n\nMalloy is designed around how humans think about data, not how data computations are mechanically accomplished. SQL is oriented around the machine \u2014 you specify joins, group-by columns, subqueries, and window functions in terms of what the database needs to do. Malloy is oriented around the analyst \u2014 you describe relationships, name computations, and compose questions in terms of what the data means. Malloy bridges the gap between these two by compiling the human-oriented description into correct, efficient SQL.\n\nA core design principle is that **most queries are themselves designing a new semantic model.** Formulating a question about data \u2014 choosing what to group by, what to aggregate, what to nest \u2014 is inherently an act of defining a new way to look at that data. Malloy is built around this idea: the output of every query is not just a result set but a new source with its own schema, and data comprehension is an ongoing iterative process where later stages want not only the data from a previous stage but how that data came into being. This is why query output carries metadata, why queries can be used as sources, and why views and pipelines compose naturally.\n\n## Documents and Statements\n\nA Malloy file (`.malloy`) is a sequence of statements, optionally separated by semicolons. There are five statement types:\n\n- **`import`** \u2014 import sources and queries from another `.malloy` file\n- **`source:`** \u2014 define a named, reusable data source with its schema and extensions\n- **`query:`** \u2014 define a named query (source + view) for reuse\n- **`run:`** \u2014 execute a query (the "do it now" statement)\n- **`given:`** \u2014 declare model-level parameters supplied at run time (experimental, see Givens)\n\n```malloy\nimport "shared_model.malloy"\n\nsource: flights is duckdb.table(\'flights.parquet\') extend {\n  measure: flight_count is count()\n}\n\nquery: carrier_summary is flights -> {\n  group_by: carrier\n  aggregate: flight_count\n}\n\nrun: carrier_summary\n```\n\nComments use `//` or `--` (both are line comments).\n\n## Sources\n\nA **source** is anything you can hand a SQL database and get a schema back \u2014 a table name, a SQL SELECT, or the output of another Malloy query. The columns in that schema become the source\'s initial fields (all dimensions).\n\n```malloy\nsource: flights is duckdb.table(\'flights.parquet\')\nsource: limited is duckdb.sql("""SELECT * FROM flights LIMIT 100""")\nsource: carrier_facts is carrier_summary   -- a query used as a source\n```\n\nWhat makes sources central to Malloy is **extension**. The `extend` block lets you layer on dimensions, measures, views, joins, filters, primary keys, field restrictions, and renames. These extensions travel with the source \u2014 any query against it gets them for free.\n\n```malloy\nsource: flights is duckdb.table(\'flights.parquet\') extend {\n  primary_key: id\n\n  dimension: distance_km is distance * 1.609344\n\n  measure:\n    flight_count is count()\n    total_distance is sum(distance)\n\n  join_one: carriers with carrier\n  join_one: origin_airport is airports on origin_airport.code = origin\n\n  where: dep_time > @2001\n\n  view: by_carrier is {\n    group_by: carrier\n    aggregate: flight_count, total_distance\n  }\n}\n```\n\nSources can extend other sources, creating a refinement chain:\n\n```malloy\nsource: ca_flights is flights extend {\n  where: origin.state = \'CA\'\n}\n```\n\nField access control uses `accept:` (allowlist) or `except:` (denylist) to restrict which inherited columns are visible. Fields can be renamed with `rename: new_name is old_name`.\n\n## Joins\n\nJoins are declared in the source, not reconstructed in every query. This is a fundamental design difference from SQL: the graph structure of your data is a property of the model.\n\n```malloy\njoin_one: carriers with carrier                          -- FK \u2192 PK shorthand\njoin_one: origin_airport is airports on origin_airport.code = origin  -- explicit ON\njoin_many: line_items on line_items.order_id = id        -- one-to-many\njoin_cross: other_table on other_table.key = key         -- cross join\n```\n\n- `join_one` \u2014 the joined source has at most one row per source row (many-to-one or one-to-one)\n- `join_many` \u2014 the joined source has potentially many rows per source row\n- `join_cross` \u2014 a full cross product\n\nThe `with` shorthand requires the joined source to have a declared `primary_key`. All joins are left outer by default. There is no right join \u2014 Malloy\'s graph model doesn\'t need one.\n\n**Choosing `join_one` vs `join_many`:** Ask "for a single row in the base source, can the joined source match more than one row?" If yes \u2192 `join_many`. If no (or at most one) \u2192 `join_one`. The common mistake is reaching for `join_many` when joining a *lookup or summary table* (e.g., joining an inventory snapshot to a purchase history on a wine key). Even though the joined table may have many rows overall, if each base row resolves to *at most one* joined row, use `join_one`. Use `join_many` only when the join genuinely fans out the base rows \u2014 e.g., joining line items to orders, or notes to a wine catalog.\n\nWhen you reference a joined source\'s fields, you use dot notation: `carriers.nickname`, `origin_airport.state`. This is one of Malloy\'s most important abstractions: **the access path to nested data is identical regardless of how the nesting is physically stored.** An array of records embedded in a column, a `join_many` to a separate table, a record-typed column \u2014 all are navigated with the same dot notation. The SQL required to traverse these different physical arrangements varies wildly (unnesting arrays, LEFT JOINs, correlated subqueries, ARRAY_AGG), but Malloy hides all of that. You think about the logical shape of your data \u2014 "flights have carriers, carriers have a nickname" \u2014 and write `carriers.nickname`. The compiler figures out what SQL is needed to get there. This means you can restructure your physical schema (normalize a nested array into a separate table, or denormalize a joined table into a record column) without changing any of the Malloy that references that data.\n\n## Fields\n\nMalloy has four kinds of fields: **dimensions**, **measures**, **views**, and **calculations**.\n\n### Dimensions\n\nScalar expressions \u2014 they compute a value per row. All columns inherited from a table are dimensions. Computed dimensions reference other dimensions or columns:\n\n```malloy\ndimension: full_name is concat(first_name, \' \', last_name)\ndimension: is_long_haul is distance > 1000\n```\n\n### Measures\n\nAggregate expressions \u2014 they compute a value across a set of rows. A field is a measure when its defining expression contains an aggregate function (`count`, `sum`, `avg`, `min`, `max`):\n\n```malloy\nmeasure:\n  flight_count is count()\n  total_distance is sum(distance)\n  avg_distance is avg(distance)\n  pct_delayed is count() { where: dep_delay > 30 } / count()\n```\n\n**`count(expr)` counts distinct values.** Unlike SQL\'s `COUNT(DISTINCT expr)`, Malloy uses `count(expr)` for distinct counting. The `count(distinct expr)` form is a deprecated syntax that will produce an error. Use `count()` for total row count, `count(field)` for distinct values of that field:\n\n```malloy\naggregate:\n  total_rows is count()               -- all rows\n  unique_carriers is count(carrier)   -- distinct carriers\n```\n\nMeasures can be filtered inline with `{ where: ... }`, which is how you build things like "percent of flights delayed" without subqueries.\n\n### Views\n\nA view is a query saved into the source \u2014 a reusable transformation:\n\n```malloy\nview: by_carrier is {\n  group_by: carrier\n  aggregate: flight_count, total_distance\n  limit: 10\n}\n```\n\nViews can reference other views from the same source as a starting point, and can be extended with `+`.\n\n### Calculations\n\nWindow functions over the grouped result. Calculations can only be defined in a query stage with `calculate:`, never in a source definition, because they depend on the output columns of the query:\n\n```malloy\nrun: flights -> {\n  group_by: carrier\n  aggregate: flight_count\n  calculate: carrier_rank is rank()\n}\n```\n\n## Queries and Views\n\nA query pairs a source with a view (the transformation). Everything after the first `->` is the view.\n\n```malloy\nrun: flights -> {\n  group_by: carrier\n  aggregate: flight_count\n}\n```\n\n### Reduction vs. Projection\n\nEach stage of a view performs exactly one of:\n\n- **Reduction** \u2014 uses `group_by:` and/or `aggregate:` to reduce grain. Analogous to `SELECT ... GROUP BY` in SQL.\n- **Projection** \u2014 uses `select:` to pick fields without aggregation. Analogous to `SELECT` without `GROUP BY`.\n\nThese cannot be mixed in a single stage. A stage with `group_by:` cannot have `select:`, and vice versa.\n\n### Source-level definitions vs. query-level operations\n\nThe same `name is expression` syntax defines fields in both sources and queries:\n\n```malloy\n-- In a source (reusable):\nsource: flights is ... extend {\n  measure: flight_count is count()          -- defines a measure in the model\n}\n\n-- In a query (ad hoc):\nrun: flights -> {\n  aggregate: flight_count is count()        -- defines the same measure inline\n}\n```\n\nWhen used in a source, `measure:` and `dimension:` are **definition statements** \u2014 they add named fields to the source\'s schema. When used in a query, `group_by:`, `aggregate:`, `select:`, `nest:`, and `calculate:` are **query operations** \u2014 they specify what the query does. The field definitions are syntactically identical in both contexts, but the enclosing keyword determines the role:\n\n| Source keyword | Query keyword | What it holds |\n|---|---|---|\n| `dimension:` | `group_by:` or `select:` | scalar expressions |\n| `measure:` | `aggregate:` | aggregate expressions |\n| `view:` | `nest:` | sub-queries |\n| _(n/a)_ | `calculate:` | window functions |\n\nThis is why `measure` and `aggregate` are separate keywords. `measure:` is a *modeling* statement \u2014 "this source has a reusable aggregate computation called X." `aggregate:` is a *query* statement \u2014 "in this query, include these aggregate values in the output." A query\'s `aggregate:` can reference a previously defined measure by name, or define one inline. The distinction parallels the separation between defining a dimension in a source and using it via `group_by:` in a query.\n\n### Multi-stage Pipelines\n\nStages chain with `->`. Each stage\'s output becomes the next stage\'s source:\n\n```malloy\nrun: flights -> {\n  group_by: carrier\n  aggregate: flight_count is count()\n} -> {\n  where: flight_count > 1000\n  select: *\n}\n```\n\n### Refinement with `+`\n\nThe refinement operator `+` merges query operations together. It works both within a view and at the top level on a named query:\n\n```malloy\n-- Refining a view within a query:\nrun: flights -> by_carrier + { limit: 5 } + { nest: by_destination }\n\n-- Refining a named query at the top level:\nrun: carrier_summary + { group_by: origin }   -- add origin grouping to existing query\n```\n\nWhen a dimension name appears as a bare reference, it expands to `{ group_by: name }`. A measure name expands to `{ aggregate: name }`:\n\n```malloy\nrun: flights -> carrier + flight_count + { limit: 10 }\n-- equivalent to: flights -> { group_by: carrier; aggregate: flight_count; limit: 10 }\n```\n\nFor multi-stage queries, refinement semantics get more complex \u2014 but for single-stage queries, `+` straightforwardly merges operations into the stage.\n\n### Nesting\n\n`nest:` embeds an aggregating subquery inside a reduction. Each row of the outer query gets a subtable from the nested query. Nests can nest arbitrarily deep:\n\n```malloy\nrun: flights -> {\n  group_by: carrier\n  aggregate: flight_count\n  nest: top_routes is {\n    group_by: origin, destination\n    aggregate: flight_count\n    limit: 3\n  }\n}\n```\n\n### Other query operations\n\n- **`where:`** \u2014 filter rows (pre-aggregation). Comma-separated filters are ANDed.\n- **`having:`** \u2014 filter groups (post-aggregation), like SQL\'s HAVING.\n- **`limit:`** / **`order_by:`** \u2014 limit and sort output.\n- **`extend`** \u2014 add fields or joins to a source inline within a query expression.\n\n## Aggregate Locality (Symmetric Aggregates)\n\nThis is one of Malloy\'s most important features. In SQL, when you join tables and aggregate, you risk double-counting (the "fan trap"). Malloy solves this with **aggregate locality** \u2014 you specify *where in the join graph* an aggregation should be computed.\n\n```malloy\nrun: flights -> {\n  aggregate:\n    -- avg seats weighted by number of flights (locality: source, i.e. flights)\n    avg_seats_per_flight is source.avg(aircraft.aircraft_models.seats)\n    -- avg seats per aircraft model (locality: aircraft_models)\n    avg_seats_per_model is aircraft.aircraft_models.seats.avg()\n}\n```\n\nThree syntactic forms:\n\n- `avg(expr)` \u2014 aggregate at the current source (implicit locality)\n- `joined_source.avg(expr)` \u2014 aggregate at the specified join point (explicit locality)\n- `joined_source.field.avg()` \u2014 shorthand for aggregating the field at its parent source\n\nFor `sum` and `avg` (asymmetric aggregates), when the expression crosses a join boundary, Malloy *requires* explicit locality \u2014 it won\'t silently give you a wrong answer. For `min`, `max`, and `count` (symmetric), locality doesn\'t change the result, so implicit is always fine.\n\nMalloy implements this with a technique called **symmetric aggregates** \u2014 it internally de-duplicates rows based on primary keys at the appropriate join level, so aggregations are always mathematically correct regardless of join fan-out.\n\n## Ungrouped Aggregates\n\n`all()` and `exclude()` allow computing aggregates at different grouping levels within a single query:\n\n```malloy\nrun: airports -> {\n  group_by: state, faa_region\n  aggregate:\n    airport_count is count()\n    total_airports is all(count())                   -- ungrouped: total across all rows\n    region_airports is all(count(), faa_region)       -- grouped only by faa_region\n    pct_of_total is count() / all(count())\n}\n```\n\n`all(expr)` removes all grouping. `all(expr, dim1, dim2)` keeps only the specified grouping dimensions. `exclude(expr, dim)` removes the specified dimension from grouping.\n\n**Important:** `all(expr, dim)` takes the **local alias name** as defined in the query\'s `group_by:`, not a dotted path. If you want to partition by a joined field, alias it first:\n\n```malloy\n-- WRONG: all(count(), director.primaryName)  -- dot paths don\'t work here\n-- RIGHT:\nrun: movies -> {\n  group_by: director is director.primaryName   -- alias it\n  aggregate:\n    movies is count()\n    director_total is all(count(), director)   -- reference the alias\n    pct is count() / all(count(), director)\n}\n```\n\n## Expressions\n\nMalloy expressions include arithmetic, comparison, logical operators, function calls, type casts, and several Malloy-specific forms.\n\n### Evaluation Spaces\n\nEvery expression has an evaluation space: **literal**, **constant**, **input**, or **output**. Input expressions reference source columns/dimensions. Output expressions reference the results of the current query stage (used in `calculate:`). Some functions constrain their arguments \u2014 e.g., `lag(expr)` requires an output expression, `avg(expr)` requires an input expression.\n\n### Application and Partial Comparison\n\nThe `?` operator applies a condition to a value. Partial comparisons are conditions without a left-hand side:\n\n```malloy\nwhere: state ? \'CA\' | \'NY\'         -- state is \'CA\' or \'NY\'\nwhere: distance ? > 500 & < 2000   -- distance between 500 and 2000\n```\n\n`|` is alternation (OR), `&` is conjunction (AND) within partials.\n\n### Pick Expressions\n\nMalloy\'s equivalent of CASE:\n\n```malloy\ndimension: size_bucket is\n  pick \'short\' when distance < 500\n  pick \'medium\' when distance < 1500\n  else \'long\'\n```\n\n### Filtered Aggregate Expressions\n\nAny aggregate can be filtered inline:\n\n```malloy\nmeasure: ca_flights is count() { where: origin.state = \'CA\' }\n```\n\n### Type Casting\n\n```malloy\ntotal_distance::string       -- Malloy type cast\nname::"VARCHAR(32)"          -- database-native type cast\n```\n\n### Time Literals and Ranges\n\n```malloy\n@2003                       -- the year 2003\n@2003-Q2                    -- second quarter of 2003\n@2024-01-15 10:30:00        -- timestamp literal\ndep_time ? @2003 to @2005   -- range comparison\nnow                         -- current timestamp\n```\n\n## Data Types\n\nMalloy\'s type system: `string`, `number`, `boolean`, `date`, `timestamp`, `timestamptz`, `json`, and `sql native` (for unsupported database types). Compound types: `type[]` for arrays, `{ name :: type, ... }` for records, nesting arbitrarily: `{ x :: number, tags :: string[] }[]`.\n\n## Annotations and Tags\n\nThese are related but distinct concepts.\n\n### Annotations\n\nAnnotations are **text strings** attached to objects during compilation. They are metadata \u2014 they never affect query execution or SQL generation. An annotation starts with `#` and continues to end of line:\n\n```malloy\n# bar_chart\nview: by_carrier is { ... }\n```\n\n- `#` annotations attach to the next object defined below them\n- `##` annotations attach to the model (the file)\n- Block annotations use `#|` ... `|#` for multi-line content (closing delimiter must match the column position of the opener)\n\nAnnotations distribute over definition lists:\n\n```malloy\n# currency\nmeasure:           -- all three measures get the # currency annotation\n  revenue is sum(amount)\n  # percent          -- this measure also gets # percent\n  margin is revenue / cost\n  cost is sum(amount)\n```\n\n### Tags (a use of annotations)\n\nTags are the primary *consumer* of annotation strings. They interpret annotation text using a structured property language (MOTLY). The key distinction: **annotations are the transport mechanism (raw strings attached to objects), tags are the interpretation layer (parsed key-value properties).**\n\nNot all annotations are tags. An annotation is just text. Tags are annotations that happen to be written in the tag property language and parsed by an application.\n\n### Annotation prefixes (routing)\n\nThe character(s) immediately after `#` route the annotation to different consumers:\n\n- `# ` (hash-space) \u2014 renderer tags, parsed by the Malloy VS Code extension for visualization (`# bar_chart`, `# line_chart`, `# shape_map`; `# link { url_template="https://\u2026/$$" }` turns a field\'s cell into a clickable deep link \u2014 `$$` is the cell value, `field=other` links on a different (often `# hidden`) field; `# image { url_template=\u2026 }` renders it as an image)\n- `##!` \u2014 compiler directives (e.g., `##! experimental.parameters`, `##! experimental.givens`)\n- `#"` \u2014 reserved for documentation strings\n- `#(appName)` \u2014 application-specific tags (e.g., `#(docs) hidden`)\n\n```malloy\n# bar_chart size=large        -- renderer tag: tells VS Code how to render\n##! experimental.parameters   -- compiler tag: enables a feature flag\n#(myApp) priority=high        -- custom app tag: ignored by renderer/compiler\n```\n\n### Tag property syntax\n\n```\ntName                         -- boolean flag (exists = true)\ntName=value                   -- set property value\ntName=[a, b, c]               -- array value\ntName: { p1=v1 p2=v2 }       -- nested properties (replaces)\ntName { p1=v1 }               -- nested properties (merges)\n-tName                        -- delete a property\ntName.sub.path=value          -- deep path assignment\n```\n\nValues can be unquoted identifiers, quoted strings, numbers, or typed values prefixed with `@` (`@true`, `@false`, `@2024-01-15`).\n\n## Givens (Model-Level Parameters)\n\n**Status: experimental, gated by `##! experimental.givens`.** Naming is provisional.\n\nGivens are values supplied at run time that the model can reference in any expression. The motivating use case is row-level access control \u2014 a model written once with `where: x.tenant_id = $TENANT` and the tenant supplied per API call \u2014 but they also fit configuration values, session context, and any "one compiled model, many invocations with varying context" pattern.\n\nGivens are model-wide: a single namespace, one value per name per compilation. They are *complementary to* source/query parameters (`source: foo(x :: string) is ...`), not a replacement. Use a parameter when you want two differently-bound copies of the same source side-by-side in one model; use a given when you want one value visible everywhere in the compilation.\n\n### Declaration\n\nThe `given:` top-level statement introduces givens, with a name, a type, and an optional default:\n\n```malloy\ngiven:\n  TENANT :: string\n  MAX_ROWS :: number is 1000\n  CUTOFF_DATE :: date is @2024-01-01\n```\n\nType can be any Malloy atomic type or compound type, including `filter<T>`:\n\n```malloy\ngiven:\n  ROLE :: string\n  ALLOWED_ROLES :: string[]\n  SESSION :: { user_id :: string, tenant :: string }\n  TENANT_FILTER :: filter<string>\n```\n\nDefaults are expressions over constants and other givens. Annotations attach to given declarations the same way they attach to sources or measures.\n\n### Reference: the `$` sigil\n\nInside any expression, a given is referenced with a leading `$`:\n\n```malloy\nsource: orders_for_user is orders extend {\n  where: orders.tenant_id = $TENANT\n}\n\nquery: recent_orders is orders_for_user -> {\n  where: order_date >= $CUTOFF_DATE\n  limit: $MAX_ROWS\n}\n```\n\n`$` appears *only* at expression references. The other three sites where a given\'s name appears \u2014 declaration, import, and supply (caller side) \u2014 use the bare name, because syntactic position already disambiguates. Givens share the top-level declaration namespace with sources/queries/views, so `source: x is ...` plus `given: x :: string` is a name-conflict error.\n\n### Set membership: `expr in $arrayGiven`\n\nThe RHS of `in` is either a parenthesized list of expressions (`in (1, 2, x, y * 7)`, same as SQL) or a given with an array value (`in $ARR`). A bare array-typed expression \u2014 a dimension, a joined array field, an inline `[a, b, c]` literal \u2014 is *not* legal on the RHS; arrays only reach the RHS via the given form.\n\nWhen a given has array type, `expr in $ARR` tests `expr` against the runtime-bound array; `not in $ARR` is the negation. The left-hand side must match the array\'s element type (`string in $string[]`, `number in $number[]`, etc.); mismatches are translate-time errors. Records and nested arrays are out of scope.\n\n```malloy\ngiven:\n  ALLOWED_STATES :: string[]\n  URGENT_STATUSES :: string[]\n\nsource: orders extend {\n  where: state in $ALLOWED_STATES\n  dimension: is_urgent is order_status in $URGENT_STATUSES\n}\n```\n\nAt SQL emit, the array\'s contents land in a generated `IN (...)` clause. Empty or `null` arrays collapse to the obvious result (`IN` \u2192 `FALSE`, `NOT IN` \u2192 `TRUE`). NULL elements inside a non-empty array follow standard SQL `IN` semantics.\n\nTo derive a value from an array \u2014 typically a boolean gate \u2014 *without* the array itself reaching row-position SQL, use an inline given (below).\n\n### Inline givens\n\nAn `inline` given is evaluated at **bind time**, before SQL is emitted: its default expression runs against the resolved given values and reduces to a literal, and that literal is what reaches SQL.\n\n```malloy\ngiven:\n  CAPABILITIES :: string[]\n  inline CAN_READ_ORDERS :: boolean is \'read_orders\' in $CAPABILITIES\n  inline CAN_MUTATE :: boolean\n    is \'write_orders\' in $CAPABILITIES or \'admin\' in $CAPABILITIES\n\nsource: orders extend {\n  where: $CAN_READ_ORDERS   -- SQL sees: WHERE ... AND TRUE  (or FALSE)\n}\n```\n\nThis is the **row-level access-control gate** pattern: the host supplies a capability list as a regular given, an inline given derives a boolean from it, and only the boolean \u2014 not the list \u2014 crosses into row-position SQL. The query planner sees a constant predicate.\n\nRules:\n\n- An inline given **must** have a default. `inline FOO :: number` with no `is` clause is a translate-time error.\n- The default may use:\n  - Boolean and comparison operators: `and`, `or`, `not`, `=`, `!=`, `<`, `<=`, `>`, `>=`\n  - The `in $array` test against another given\n  - Literals (string, number, boolean, null, array) and references to other givens\n- The default cannot call SQL functions, reference fields, or use any operator outside that list. Disallowed operators are reported at translate time with the offending operator names.\n- Inline givens are filtered out of `Model.givens` and `PreparedQuery.givens` \u2014 they\'re computed, not supplied \u2014 so introspection-driven UIs don\'t render editors for them. A caller can still shadow one by binding it explicitly (useful in tests).\n- `inline` is a context-sensitive modifier, not a reserved keyword: fields, sources, views, dimensions, and joins can still be named `inline`.\n\n### Imports\n\nGivens behave like every other top-level named thing under import:\n\n- **Bare import** (`import "b.malloy"`) brings B\'s full export surface in, including all of B\'s givens, under their original names.\n- **Selective import** (`import { source1 } from "b.malloy"`) brings in only what\'s listed. To surface a given to your callers, list it: `import { source1, MAX_ROWS } from "b.malloy"`.\n- **Rename** uses the existing `LOCAL is REMOTE` form: `import { CAP is MAX_ROWS } from "b.malloy"`.\n\nSurfacing controls *who can supply a value*, not whether internal references work. An imported source can reference a given the importer didn\'t surface; the reference still resolves internally, and at run time the unsurfaced given relies on its declaration-site default.\n\nA common project convention is a shared `tenant_givens.malloy` (declaring `$TENANT`, `$USER_ROLE`, etc.) that every root file bare-imports on line 1, so the project\'s given contract is visible at the top of any model.\n\n### Satisfiability\n\nA query referencing `$X` is satisfiable if either `$X` is in the model\'s namespace (so a caller can supply a value) or `$X` has a default at its declaration site. Otherwise the query is unsatisfiable and errors. Latent definitions (views, dimensions, measures) that reference `$X` are fine if no query actually invokes them \u2014 satisfiability is a property of running queries.\n\n### Supplying values\n\nValues can be supplied at two layers, which compose (per-query overrides per-runtime):\n\n**Per-runtime** \u2014 bound to a `Runtime`, applied as defaults to every query through it. Two paths:\n\n1. **`givensPath` in `malloy-config.json`** points at a JSON file of `name \u2192 value`:\n   ```jsonc\n   { "givensPath": "./local-givens.json" }\n   // or env-var indirection (resolved at config load):\n   { "givensPath": { "env": "GAME_STORE_GIVENS" } }\n   ```\n   The values file is a flat JSON map, keys are caller-facing surface names:\n   ```jsonc\n   { "TENANT": "acme", "USER_ROLE": "admin", "CUTOFF_DATE": "2024-01-01" }\n   ```\n\n2. **Direct on the Runtime constructor** (for per-request multi-tenant servers, tests, scripts):\n   ```typescript\n   const runtime = new Runtime({\n     config,\n     givens: { TENANT: claims.tenant_id, USER_ROLE: claims.role },\n     urlReader,\n   });\n   ```\n   Constructor values *merge over* the file at `givensPath` per-key.\n\n**Per-query** \u2014 supplied on a single `.run({ givens: ... })` call:\n```typescript\nawait query.run({ givens: { STATE_FILTER: "CA", LIMIT_OVERRIDE: 50 } })\n```\nAvailable on every compile-or-run entry point (`runtime.loadQuery(...).run(options)`, `preparedQuery.getPreparedResult(options)`, `preparedQuery.getSQL(options)`).\n\nThe resolved per-runtime values are exposed on `runtime.givens` (read-only) for diagnostics.\n\n### Finalized givens (security primitive)\n\nA multi-tenant deployment usually wants `TENANT`/`USER_ROLE`/`REGION` to be runtime-bound and **un-overridable per-query** \u2014 otherwise a downstream endpoint that accidentally accepts user-controlled query params and plumbs them into `.run({ givens: ... })` becomes a tenant-leak vulnerability.\n\n`finalizeGivens` in the config locks names at the API surface:\n\n```jsonc\n{\n  "givensPath": { "env": "GAME_STORE_GIVENS" },\n  "finalizeGivens": ["TENANT", "USER_ROLE", "REGION"]\n}\n```\n\nFinalize doesn\'t change *what* a given resolves to \u2014 only *who* can supply it. A `.run({ givens: { TENANT: ... } })` for a finalized name throws at API entry (named, not silently dropped). Finalized givens are filtered out of `Model.givens` and `PreparedQuery.givens` so introspection-driven UIs don\'t render editors for locked names.\n\n### JS shapes for supplied values\n\nBoth the JSON values file and per-query `givens` maps accept the same per-type shapes:\n\n| Malloy type | JS |\n|---|---|\n| `string` | string |\n| `number` | `number`, `bigint`, or string (precision escape hatch) |\n| `boolean` | boolean |\n| `date` | ISO date string `"2024-01-15"` |\n| `timestamp` (naive) | ISO string without offset \u2014 *not* a JS `Date` |\n| `timestamptz` | JS `Date` or ISO string with offset (string preferred \u2014 makes TZ choice visible) |\n| `T[]` | JS array |\n| `{ name :: T, ... }` | JS object |\n| `filter<T>` | JS string (Malloy filter expression source) |\n\nNaive timestamp givens reject `Date` because `Date` represents a UTC instant, not a wall-clock value, and `new Date("2001-01-01T00:00:00")` silently picks up the system\'s local TZ. Type mismatches throw at the boundary with a path that points at the offending location (e.g., `givens.SESSION.user_id: expected string, got number`). `null` is legal for any given type.\n\n### Introspection\n\n`Model.givens` and `PreparedQuery.givens` expose, to the host, the supplyable givens \u2014 for whole-model parameter editors and per-query "run this" forms respectively. Each entry carries name, type, default expression (or undefined if the caller must supply), location, and access to declaration-site annotations via `tagParse`/`getTaglines`.\n\n## How a Malloy Query Becomes SQL\n\nThe compilation pipeline has two phases:\n\n### Phase 1: Translation (source code \u2192 IR)\n\n```\nMalloy source \u2192 ANTLR lexer/parser \u2192 parse tree \u2192 AST builder \u2192 AST \u2192 IR generator \u2192 IR\n```\n\nThe **Intermediate Representation (IR)** is a plain, serializable data structure (JSON-compatible) that fully describes the semantic model and query. Note that IR is *not* dialect-agnostic \u2014 the same Malloy source compiled against different databases can produce different IR, because schema information, type mappings, and available functions vary by backend. It can be cached, transmitted, and reused. Key IR types:\n\n- **`SourceDef`** \u2014 a source\'s complete definition: schema, fields, joins, filters\n- **`Query`** \u2014 a source paired with a pipeline of operations\n- **`FieldDef`** \u2014 definition of any field (dimension, measure, join, calculation)\n- **`Expr`** \u2014 expression tree (arithmetic, comparisons, aggregates, function calls, field references)\n\nThe translator handles all language-level semantics: scoping, name resolution, type checking, evaluation space validation.\n\n### Phase 2: Compilation (IR \u2192 SQL)\n\n```\nIR \u2192 query compiler \u2192 expression compiler \u2192 dialect-specific SQL generator \u2192 SQL + metadata\n```\n\nThe compiler walks the IR query pipeline, translating each stage into SQL constructs (CTEs, subqueries, GROUP BY, window functions). A **Dialect** layer handles database-specific SQL generation.\n\nThe compiler also produces **metadata** alongside the SQL \u2014 structural information needed to interpret the result set (column types, nesting structure, annotation data). This metadata is what allows Malloy renderers to reconstruct nested/hierarchical results from the flat SQL result set and apply visualization tags.\n\n### Key architectural consequences\n\n- Because the IR is serializable, it can be cached and reused across compilations (though IR is database-specific \u2014 the same source compiled against different backends may produce different IR).\n- Because joins are declared in the source (not the query), the compiler knows the full join graph and can compute symmetric aggregates correctly.\n- Because nested queries are first-class, the compiler generates the appropriate SQL (correlated subqueries or ARRAY_AGG patterns depending on dialect) automatically.\n- Because measures are typed as aggregates in the IR, the compiler can validate that they only appear in aggregate context and enforce locality rules.\n\n## Where to Go Deeper\n\nThis document is a conceptual reference \u2014 enough to reason about the language and its design, but not exhaustive. Here\'s where to find more detail.\n\n### Language Documentation\n\nThe full docs live at [https://docs.malloydata.dev](https://docs.malloydata.dev). Key pages by topic:\n\n| Topic | URL |\n|---|---|\n| Sources, extensions, joins, primary keys | [documentation/language/source](https://docs.malloydata.dev/documentation/language/source) |\n| Queries, views, reduction vs projection | [documentation/language/query](https://docs.malloydata.dev/documentation/language/query), [views](https://docs.malloydata.dev/documentation/language/views) |\n| Fields: dimensions, measures, views, calculations | [documentation/language/fields](https://docs.malloydata.dev/documentation/language/fields) |\n| Aggregate functions and aggregate locality | [documentation/language/aggregates](https://docs.malloydata.dev/documentation/language/aggregates) |\n| Ungrouped aggregates (`all`, `exclude`) | [documentation/language/ungrouped-aggregates](https://docs.malloydata.dev/documentation/language/ungrouped-aggregates) |\n| Nested views / aggregating subqueries | [documentation/language/nesting](https://docs.malloydata.dev/documentation/language/nesting) |\n| Joins | [documentation/language/join](https://docs.malloydata.dev/documentation/language/join) |\n| Expressions, operators, pick, apply | [documentation/language/expressions](https://docs.malloydata.dev/documentation/language/expressions) |\n| Evaluation spaces (literal, constant, input, output) | [documentation/language/eval_space](https://docs.malloydata.dev/documentation/language/eval_space) |\n| Filters and filter placement | [documentation/language/filters](https://docs.malloydata.dev/documentation/language/filters) |\n| Annotations and tags | [documentation/language/tags](https://docs.malloydata.dev/documentation/language/tags) |\n| Calculations and window functions | [documentation/language/calculations_windows](https://docs.malloydata.dev/documentation/language/calculations_windows) |\n| Data types | [documentation/language/datatypes](https://docs.malloydata.dev/documentation/language/datatypes) |\n| Time operations, ranges, timezones | [documentation/language/timestamp-operations](https://docs.malloydata.dev/documentation/language/timestamp-operations), [time-ranges](https://docs.malloydata.dev/documentation/language/time-ranges), [timezones](https://docs.malloydata.dev/documentation/language/timezones) |\n| Imports | [documentation/language/imports](https://docs.malloydata.dev/documentation/language/imports) |\n| Top-level statements and model structure | [documentation/language/statement](https://docs.malloydata.dev/documentation/language/statement) |\n| Functions reference | [documentation/language/functions](https://docs.malloydata.dev/documentation/language/functions) |\n\n### Examples and Patterns\n\nThe docs site includes worked examples of common analytical patterns at [documentation/patterns](https://docs.malloydata.dev/documentation/patterns/): percent-of-total, year-over-year, cohort analysis, sessionization, moving averages, nested subtotals, and more.\n\nEnd-to-end guides are at [documentation/user_guides](https://docs.malloydata.dev/documentation/user_guides/), including [Malloy by Example](https://docs.malloydata.dev/documentation/user_guides/malloy_by_example) (a comprehensive walkthrough) and a three-part series for SQL users ([part 1](https://docs.malloydata.dev/documentation/user_guides/sql_experts1), [part 2](https://docs.malloydata.dev/documentation/user_guides/sql_experts2), [part 3](https://docs.malloydata.dev/documentation/user_guides/sql_experts3)).\n\n### Source Code\n\nThe Malloy implementation lives at [github.com/malloydata/malloy](https://github.com/malloydata/malloy). Key entry points:\n\n| What | Where |\n|---|---|\n| ANTLR grammar (lexer + parser) | `packages/malloy/src/lang/grammar/` |\n| AST node hierarchy | `packages/malloy/src/lang/ast/` |\n| Parse tree \u2192 AST builder | `packages/malloy/src/lang/malloy-to-ast.ts` |\n| IR type definitions | `packages/malloy/src/model/malloy_types.ts` |\n| IR \u2192 SQL compiler | `packages/malloy/src/model/` |\n| Dialect-specific SQL generation | `packages/malloy/src/dialect/` |\n| Tag/annotation parsing (MOTLY) | `packages/malloy-tag/` |\n| Renderer | `packages/malloy-render/` |\n| Architecture overview | `CONTEXT.md` (root and in each package) |\n',
   "language/pick.md": "---\ndescription: pick expressions \u2014 Malloy's CASE/if-then-else\n---\n\n`pick` is Malloy's equivalent of SQL `CASE WHEN`. Each branch is its own\n`pick` keyword; the `else` clause catches the remainder.\n\nThere are two forms of pick. In the first the `when` expression is any\nboolean expression.\n\n```malloy\n    pick 'Female' when upper(first_name) in ('JENNIFER', 'ELIZABETH', 'AMY', 'JESSICA')\n    pick 'Male'   when upper(first_name) in ('JAMES', 'JOHN', 'ROBERT', 'MICHAEL')\n    else 'Unknown'\n```\n\n## Example usage in a query\n\n```malloy\nrun: payments -> {\n  group_by: tier is\n    pick 'high'   when total_amount > 10000\n    pick 'medium' when total_amount > 1000\n    else 'low'\n  aggregate: payment_count is count()\n}\n```\n\n## Common mistakes\n\n- **Every branch needs its own `pick` keyword** \u2014 there is no `when \u2026 then`:\n  ```malloy\n  -- WRONG:\n  pick 'a' when x = 1 'b' when x = 2 else 'c'\n\n  -- RIGHT:\n  pick 'a' when x = 1\n  pick 'b' when x = 2\n  else 'c'\n  ```\n\n- **`else` is required** when the branches don't cover all cases \u2014 omitting it\n  returns `null` for unmatched rows.\n",
   "writing-malloy-with-mcp.md": "---\ndescription: How to write Malloy over an MCP surface \u2014 the compiler-in-the-loop discipline, common errors, and givens. Tool-agnostic; read once.\n---\n# Writing Malloy over MCP\n\nMalloy is a semantic language: a source already carries measures, dimensions,\nviews, and joins, and the compiler typechecks every query against them. The\nsingle most useful habit is **let the compiler be ground truth** \u2014 don't guess\nsyntax or field names. Read the source's shape first, validate before you run,\nand read the `problems[]` the surface returns.\n\nThe exact tools differ by surface (an explore surface exposes describe + query;\nan authoring surface adds compile/prettify), but the loop is the same:\n\n1. **Read the shape.** Describe the source you're querying \u2014 its measures,\n   dimensions, views, and joins. The model usually already defines the\n   aggregation you want; reuse it instead of re-deriving it.\n2. **Validate, then run.** Compile/validate the query first (no execution) to\n   confirm it typechecks and to see the generated SQL or the givens it needs;\n   fix any `problems[]`, then execute to get rows.\n3. **Recover from problems[].** Every failure \u2014 parse, field-not-found,\n   aggregate-locality, runtime \u2014 comes back as a uniform `problems[]` with a\n   `code` and (when known) a `help_topic`. Pull that topic with `yo_help`.\n\n## Common errors and how to read them\n\n- **Unknown field** \u2014 describe the source and check its dimensions / measures /\n  views / joins for what actually exists. A join rendered by `source_ref` is\n  described under that name in the same response.\n- **Aggregate locality** \u2014 `sum(joined.x)` across a join needs explicit\n  locality: `source.sum(joined.x)` or `joined.x.sum()`.\n- **Mixed reduction / projection** \u2014 one query stage is either\n  `group_by:`/`aggregate:` OR `select:`, never both.\n- **Calculation in a source** \u2014 `calculate:` (window functions) lives in\n  queries, not in source definitions.\n\n## Givens (`$NAME` parameters)\n\nSome models declare given parameters (`$TENANT`, `$MAX_ROWS`, \u2026). Validate a\nquery with execution off to learn which givens it references (with their types\nand whether a default exists), then supply values keyed by surface name (no\n`$`). A given with a default is optional; one without must be supplied. For the\nper-type value shapes (dates as ISO strings, records as objects, `filter<T>` as\na Malloy filter string, \u2026) pull `yo_help(\"givens\")` \u2014 don't guess; the compiler\nvalidates and points at the offending field.\n\n## Before writing non-trivial Malloy\n\nBrowse the `language/*` topics first (start with `yo_help(\"language/overview\")`).\nThe language has real scoping and typing rules the compiler enforces \u2014 reading\nthe reference beats guessing.\n"
 };
@@ -1152,6 +1157,23 @@ function docText(t) {
     return void 0;
   }
 }
+function resolveTile(tile, source) {
+  const t = tile.trim();
+  if (source && !t.includes("->")) return `${source} -> ${t}`;
+  return t;
+}
+function readGivens(tag) {
+  const givensTag = tag.tag("artifact", "givens");
+  if (!givensTag) return void 0;
+  const givens = {};
+  for (const [key, t] of Object.entries(givensTag.dict ?? {})) {
+    const eq = t.eq;
+    if (typeof eq === "string" || typeof eq === "number" || typeof eq === "boolean") {
+      givens[key] = eq;
+    }
+  }
+  return Object.keys(givens).length ? givens : void 0;
+}
 function readArtifactTag(ident, q) {
   let tag;
   try {
@@ -1164,33 +1186,51 @@ function readArtifactTag(ident, q) {
   const description = docText(q);
   const name = nested?.text("name") ?? tag.text("name") ?? ident.defaultName;
   const title = nested?.text("title") ?? tag.text("title") ?? description?.split("\n")[0] ?? ident.defaultName;
+  const rawTiles = nested?.textArray("tiles") ?? tag.textArray("tiles");
+  if (rawTiles && rawTiles.length) {
+    const info2 = {
+      name,
+      query: "",
+      title,
+      tiles: rawTiles.map((t) => resolveTile(t, ident.source))
+    };
+    if (ident.source) info2.source = ident.source;
+    if (description) info2.description = description;
+    const cols = nested?.numeric("dashboard_columns") ?? tag.numeric("dashboard_columns");
+    if (typeof cols === "number") info2.dashboard_columns = cols;
+    const autorunText2 = nested?.text("autorun") ?? tag.text("autorun");
+    if (autorunText2 === "false") info2.autorun = false;
+    const givens2 = readGivens(tag);
+    if (givens2) info2.givens = givens2;
+    return info2;
+  }
   const info = { name, query: ident.runExpr, title };
   if (ident.source) info.source = ident.source;
   if (ident.view) info.view = ident.view;
   if (description) info.description = description;
-  const givensTag = tag.tag("artifact", "givens");
-  if (givensTag) {
-    const givens = {};
-    for (const [key, t] of Object.entries(givensTag.dict ?? {})) {
-      const eq = t.eq;
-      if (typeof eq === "string" || typeof eq === "number" || typeof eq === "boolean") {
-        givens[key] = eq;
-      }
-    }
-    if (Object.keys(givens).length) info.givens = givens;
-  }
+  const autorunText = nested?.text("autorun") ?? tag.text("autorun");
+  if (autorunText === "false") info.autorun = false;
+  const givens = readGivens(tag);
+  if (givens) info.givens = givens;
   return info;
 }
 async function artifactQueries(runtime, entry) {
   try {
     const model = await runtime.loadModel(entry).getModel();
     const artifacts = [];
+    const modelComposite = readArtifactTag({ runExpr: "", defaultName: "dashboard" }, model);
+    if (modelComposite?.tiles) artifacts.push(modelComposite);
     for (const queryName of model.queries().named) {
       const pq = model.getPreparedQueryByName(queryName);
       const info = readArtifactTag({ runExpr: queryName, defaultName: queryName }, pq);
       if (info) artifacts.push(info);
     }
     for (const src of model.explores) {
+      const srcComposite = readArtifactTag(
+        { runExpr: "", defaultName: src.name, source: src.name },
+        src
+      );
+      if (srcComposite?.tiles) artifacts.push(srcComposite);
       for (const field of src.allFields) {
         if (!field.isQueryField()) continue;
         const view = field;
@@ -1211,6 +1251,111 @@ async function artifactQueries(runtime, entry) {
     return { ok: false, error: e instanceof Error ? e.message : String(e) };
   }
 }
+async function collectDrillTargets(runtime, entry) {
+  try {
+    const model = await runtime.loadModel(entry).getModel();
+    const targets = /* @__PURE__ */ new Set();
+    for (const src of model.explores) {
+      for (const field of src.allFields) {
+        const tagged = field;
+        let tag;
+        try {
+          tag = tagged.annotations.parseAsTag().tag;
+        } catch {
+          continue;
+        }
+        const drill = tag.tag("drill");
+        if (!drill) continue;
+        const to = drill.textArray("to") ?? (drill.text("to") ? [drill.text("to")] : []);
+        for (const t of to) if (t && t !== "self") targets.add(t);
+      }
+    }
+    return { ok: true, targets: [...targets] };
+  } catch (e) {
+    return { ok: false, error: e instanceof Error ? e.message : String(e) };
+  }
+}
+async function modelArtifact(runtime, entry, defaultName) {
+  try {
+    const model = await runtime.loadModel(entry).getModel();
+    const composite = readArtifactTag({ runExpr: "", defaultName }, model);
+    if (composite?.tiles) return { ok: true, artifact: composite };
+    for (const queryName of model.queries().named) {
+      const pq = model.getPreparedQueryByName(queryName);
+      const info = readArtifactTag({ runExpr: queryName, defaultName }, pq);
+      if (info && !info.tiles) return { ok: true, artifact: { ...info, tiles: [info.query], query: "" } };
+    }
+    for (const src of model.explores) {
+      for (const field of src.allFields) {
+        if (!field.isQueryField()) continue;
+        const view = field;
+        const info = readArtifactTag(
+          { runExpr: `${src.name} -> ${view.name}`, defaultName, source: src.name, view: view.name },
+          view
+        );
+        if (info && !info.tiles) return { ok: true, artifact: { ...info, tiles: [info.query], query: "" } };
+      }
+    }
+    return { ok: true, artifact: void 0 };
+  } catch (e) {
+    return { ok: false, error: e instanceof Error ? e.message : String(e) };
+  }
+}
+function liftRenderTags(annotations) {
+  if (!annotations) return [];
+  return annotations.filter((a) => {
+    const v = a.value;
+    return v.startsWith("# ") && !v.startsWith("# artifact");
+  });
+}
+function tileAsNestField(name, res) {
+  const fields = (res.schema?.fields ?? []).map((f) => ({
+    name: f.name,
+    type: f.type,
+    annotations: f.annotations
+  }));
+  return {
+    kind: "dimension",
+    name,
+    type: {
+      kind: "array_type",
+      element_type: { kind: "record_type", fields }
+    },
+    annotations: liftRenderTags(res.annotations)
+  };
+}
+function uniqueName(name, taken) {
+  if (!taken.has(name)) {
+    taken.add(name);
+    return name;
+  }
+  let i = 2;
+  while (taken.has(`${name}_${i}`)) i++;
+  const out = `${name}_${i}`;
+  taken.add(out);
+  return out;
+}
+function combineTiles(tiles, opts = {}) {
+  const taken = /* @__PURE__ */ new Set();
+  const named = tiles.map((t) => ({ name: uniqueName(t.name, taken), result: t.result }));
+  const columns = typeof opts.columns === "number" && Number.isFinite(opts.columns) ? ` {columns=${Math.trunc(opts.columns)}}` : "";
+  return {
+    // Provenance carried from the first tile; the combined result never runs
+    // SQL itself, so connection_name is cosmetic but the renderer reads it.
+    connection_name: tiles[0]?.result.connection_name ?? "composite",
+    model_annotations: tiles[0]?.result.model_annotations,
+    annotations: [{ value: `# dashboard${columns}
+` }],
+    schema: { fields: named.map((t) => tileAsNestField(t.name, t.result)) },
+    // One dashboard row whose columns are the tiles' data cells (verbatim).
+    data: {
+      kind: "array_cell",
+      array_value: [
+        { kind: "record_cell", record_value: named.map((t) => t.result.data) }
+      ]
+    }
+  };
+}
 var INSTANCE_PLACEHOLDER = "{{INSTANCE_NAME}}";
 function renderInstructions(text, instanceName) {
   return text.replaceAll(INSTANCE_PLACEHOLDER, instanceName);
@@ -1361,6 +1506,17 @@ function refModelProblem(ref, e) {
   const msg = e instanceof Error ? e.message : String(e);
   return codeProblem("model-not-found", `Cannot use model '${ref}': ${msg}`);
 }
+function refNudge(ref, inspect) {
+  const also = inspect.also ? ` and ${inspect.also}=<the source you queried>` : "";
+  return (p) => {
+    if (p.code !== "field-not-found") return p;
+    return {
+      ...p,
+      message: `${p.message} \u2014 call ${inspect.tool} with ${inspect.param}="${ref}"${also} to see what fields, measures, views, and joins exist.`,
+      help_topic: p.help_topic ?? "language/fields"
+    };
+  };
+}
 async function executeQuery(m, args, fix, result) {
   const malloy = argString(args, "malloy");
   const execute = argOptBool(args, "execute") ?? true;
@@ -1374,6 +1530,50 @@ async function executeQuery(m, args, fix, result) {
   const budgeted = await applyResultBudget(full, result, { toolName: "query", args });
   return { ...budgeted, problems: budgeted.problems.map(fix) };
 }
+function queryTool(host, opts = {}) {
+  const inspect = opts.inspect ?? { tool: "describe_source", param: "model_ref", also: "source" };
+  return {
+    name: "query",
+    title: prompts.shared.tools.query.title,
+    description: prompts.shared.tools.query.description,
+    inputSchema: {
+      type: "object",
+      properties: {
+        model_ref: {
+          type: "string",
+          description: "Model ref \u2014 a published model name, or (on a local develop server) the path of the root model file."
+        },
+        malloy: { type: "string", description: "Malloy query text, e.g. `run: orders -> { ... }`." },
+        question: {
+          type: "string",
+          description: "Plain-English description of what this query answers; hosts may record or share it."
+        },
+        givens: {
+          type: "object",
+          description: "Values for $NAME givens, keyed by name (no $). Validate with execute:false to learn which givens the query needs."
+        },
+        execute: { type: "boolean", description: "Default true. false \u2192 compile/validate only (no execution)." },
+        max_rows: { type: "integer", minimum: 1, maximum: 1e4, description: `Row cap (default ${DEFAULT_ROW_LIMIT}).` }
+      },
+      required: ["model_ref", "malloy"],
+      additionalProperties: false
+    },
+    handler: async (args) => {
+      const ref = argString(args, "model_ref");
+      if (!ref.trim()) {
+        return { ok: false, problems: [codeProblem("model-ref-required", prompts.shared.errors["no-model-ref"])] };
+      }
+      try {
+        return await host.withModel(
+          ref,
+          (m) => executeQuery(m, args, refNudge(ref, inspect), opts.result)
+        );
+      } catch (e) {
+        return { ok: false, problems: [refModelProblem(ref, e)] };
+      }
+    }
+  };
+}
 async function resolveModel(host, source, modelRef) {
   if (modelRef) return { model_ref: modelRef };
   if (!host.list) {
@@ -1654,9 +1854,126 @@ function exploreSurface(host, opts = {}) {
     skills: sharedSkills()
   };
 }
+var pathSchema = {
+  type: "string",
+  description: "Path to a .malloy file, relative to the server root. (Absolute paths and file:// URIs are also accepted.)"
+};
+var sourceSchema = { type: "string", description: "Malloy source code." };
+var basePathSchema = {
+  type: "string",
+  description: "Optional path for resolving relative imports in the inline source \u2014 typically the file the snippet will live next to. If omitted, imports must be absolute."
+};
+var expandSchema = {
+  type: "string",
+  enum: ["ref", "inline"],
+  description: "Join rendering: 'ref' (default) references joined sources by name via source_ref; 'inline' recursively inlines the joined schema."
+};
+var emitRunSqlSchema = {
+  type: "boolean",
+  description: "Compile each run: statement to SQL and include it as model.runs[].sql. Default false (large; use query to execute)."
+};
+function developSurface(host, opts = {}) {
+  async function lease(input, fn) {
+    try {
+      return await host.withRuntime(input, fn);
+    } catch (e) {
+      return { ok: false, problems: [errorProblem(e)] };
+    }
+  }
+  const modelHost = {
+    withModel: (ref, fn) => host.withRuntime({ url: ref }, fn)
+  };
+  const tools = [
+    {
+      name: "compile_file",
+      title: prompts.develop.tools.compile_file.title,
+      description: prompts.develop.tools.compile_file.description,
+      inputSchema: {
+        type: "object",
+        properties: { path: pathSchema, expand: expandSchema, emit_run_sql: emitRunSqlSchema },
+        required: ["path"],
+        additionalProperties: false
+      },
+      handler: async (args) => lease(
+        { url: argString(args, "path") },
+        (m) => compile(m.runtime, m.entry, {
+          readSource: m.readSource,
+          expand: argOptString(args, "expand"),
+          emitRunSql: argOptBool(args, "emit_run_sql")
+        })
+      )
+    },
+    {
+      name: "compile",
+      title: prompts.develop.tools.compile.title,
+      description: prompts.develop.tools.compile.description,
+      inputSchema: {
+        type: "object",
+        properties: {
+          source: sourceSchema,
+          base_path: basePathSchema,
+          expand: expandSchema,
+          emit_run_sql: emitRunSqlSchema
+        },
+        required: ["source"],
+        additionalProperties: false
+      },
+      handler: async (args) => lease(
+        { source: argString(args, "source"), baseUrl: argOptString(args, "base_path") },
+        (m) => compile(m.runtime, m.entry, {
+          readSource: m.readSource,
+          expand: argOptString(args, "expand"),
+          emitRunSql: argOptBool(args, "emit_run_sql")
+        })
+      )
+    },
+    queryTool(modelHost, {
+      result: opts.result,
+      inspect: { tool: "compile_file", param: "path" }
+    }),
+    {
+      name: "prettify",
+      title: prompts.develop.tools.prettify.title,
+      description: prompts.develop.tools.prettify.description,
+      inputSchema: {
+        type: "object",
+        properties: { source: sourceSchema },
+        required: ["source"],
+        additionalProperties: false
+      },
+      handler: async (args) => prettify(argString(args, "source"))
+    },
+    yoHelpTool()
+  ];
+  return {
+    tools: tools.map(withHelp),
+    instructions: assembleInstructions("develop"),
+    skills: sharedSkills()
+  };
+}
 
 // src/host.ts
 var ENTRY = "index.malloy";
+function tileName(runExpr) {
+  const arrow = runExpr.lastIndexOf("->");
+  return (arrow >= 0 ? runExpr.slice(arrow + 2) : runExpr).trim();
+}
+async function validateQuery(runtime, entry, runExpr, givens) {
+  try {
+    const q = runtime.loadModel(entry).loadQuery(`run: ${runExpr}`);
+    const has = givens && Object.keys(givens).length > 0;
+    await q.getSQL(has ? { givens } : void 0);
+    return { ok: true };
+  } catch (e) {
+    return { ok: false, error: e instanceof Error ? e.message : String(e) };
+  }
+}
+async function validateRestrictedText(runtime, entry, malloy) {
+  const v = await validateRestricted(runtime, entry, malloy);
+  if (v.ok) return { ok: true };
+  const msg = v.problems.filter((p) => p.severity === "error").map((p) => p.message).join("; ");
+  return { ok: false, error: msg || "restricted query failed to compile" };
+}
 function fsReader() {
   return {
     readURL: async (u) => {
@@ -1677,56 +1994,123 @@ async function makeRunner(root) {
   await import("@malloydata/malloy-connections");
   const abs = path2.resolve(root);
   const rootUrl = url2.pathToFileURL(abs + path2.sep);
-  async function lease(fn) {
-    const reader = fsReader();
-    const config = await loadConfig(rootUrl, reader);
-    const { reader: prepared, entry } = prepareSource(reader, { url: path2.join(abs, ENTRY) });
+  const reader = fsReader();
+  let configPromise = null;
+  const getConfig = () => configPromise ??= loadConfig(rootUrl, reader);
+  let inFlight = 0;
+  async function leaseIn(entryFile, fn) {
+    const config = await getConfig();
+    const { reader: prepared, entry } = prepareSource(reader, { url: path2.join(abs, entryFile) });
     const runtime = new Runtime({ config, urlReader: prepared });
+    inFlight++;
     try {
       return await fn(runtime, entry);
     } finally {
-      await config.shutdown("idle").catch(() => {
+      inFlight--;
+      if (inFlight === 0) await config.shutdown("idle").catch(() => {
       });
     }
   }
+  const lease = (fn) => leaseIn(ENTRY, fn);
   return {
     root: abs,
     entryExists: () => fs.existsSync(path2.join(abs, ENTRY)),
+    async dispose() {
+      if (!configPromise) return;
+      const config = await configPromise.catch(() => null);
+      configPromise = null;
+      if (config) await config.shutdown("close").catch(() => {
+      });
+    },
     run(runExpr, givens) {
       return lease(
         (runtime, entry) => run(runtime, entry, { runExpr, givens, stableResult: true, rowLimit: 5e3 })
       );
     },
+    runIn(entryFile, runExpr, givens) {
+      return leaseIn(
+        entryFile,
+        (runtime, entry) => run(runtime, entry, { runExpr, givens, stableResult: true, rowLimit: 5e3 })
+      );
+    },
     runText(malloy, givens) {
       return lease(
         (runtime, entry) => runRestricted(runtime, entry, malloy, { givens, stableResult: true, rowLimit: 5e3 })
       );
     },
+    runTextIn(entryFile, malloy, givens) {
+      return leaseIn(
+        entryFile,
+        (runtime, entry) => runRestricted(runtime, entry, malloy, { givens, stableResult: true, rowLimit: 5e3 })
+      );
+    },
     validateText(malloy) {
-      return lease(async (runtime, entry) => {
-        const v = await validateRestricted(runtime, entry, malloy);
-        if (v.ok) return { ok: true };
-        const msg = v.problems.filter((p) => p.severity === "error").map((p) => p.message).join("; ");
-        return { ok: false, error: msg || "restricted query failed to compile" };
-      });
+      return lease((runtime, entry) => validateRestrictedText(runtime, entry, malloy));
+    },
+    validateTextIn(entryFile, malloy) {
+      return leaseIn(entryFile, (runtime, entry) => validateRestrictedText(runtime, entry, malloy));
     },
     givensForQuery(runExpr) {
       return lease((runtime, entry) => dashboardGivenSpecs(runtime, entry, runExpr));
     },
+    givensForQueryIn(entryFile, runExpr) {
+      return leaseIn(entryFile, (runtime, entry) => dashboardGivenSpecs(runtime, entry, runExpr));
+    },
     artifacts() {
       return lease((runtime, entry) => artifactQueries(runtime, entry));
     },
-    validate(runExpr, givens) {
-      return lease(async (runtime, entry) => {
-        try {
-          const q = runtime.loadModel(entry).loadQuery(`run: ${runExpr}`);
-          const has = givens && Object.keys(givens).length > 0;
-          await q.getSQL(has ? { givens } : void 0);
-          return { ok: true };
-        } catch (e) {
-          return { ok: false, error: e instanceof Error ? e.message : String(e) };
+    drillTargets() {
+      return lease((runtime, entry) => collectDrillTargets(runtime, entry));
+    },
+    artifactForFile(entryFile, defaultName) {
+      return leaseIn(entryFile, (runtime, entry) => modelArtifact(runtime, entry, defaultName));
+    },
+    runDashboard(entryFile, tiles, opts) {
+      return leaseIn(entryFile, async (runtime, entry) => {
+        const givens = opts.givens ?? {};
+        const ran = [];
+        for (const tile of tiles) {
+          const specs = await dashboardGivenSpecs(runtime, entry, tile);
+          const names = specs.ok ? new Set(specs.givens.map((s) => s.name)) : null;
+          const tileGivens = names ? Object.fromEntries(Object.entries(givens).filter(([k]) => names.has(k))) : givens;
+          const result = await run(runtime, entry, {
+            runExpr: tile,
+            givens: tileGivens,
+            stableResult: true,
+            rowLimit: 5e3
+          });
+          ran.push({ name: tileName(tile), result });
         }
+        const problems = ran.flatMap((t) => t.result.problems ?? []);
+        const good = ran.filter((t) => t.result.ok && t.result.stable_result);
+        if (good.length === 0) return { ok: false, problems };
+        if (good.length === 1) {
+          return { ok: true, stable_result: good[0].result.stable_result, problems };
+        }
+        const combined = combineTiles(
+          good.map((t) => ({ name: t.name, result: t.result.stable_result })),
+          { columns: opts.columns }
+        );
+        return { ok: true, stable_result: combined, problems };
       });
+    },
+    dashboardGivens(entryFile, tiles) {
+      return leaseIn(entryFile, async (runtime, entry) => {
+        const byName = /* @__PURE__ */ new Map();
+        for (const tile of tiles) {
+          const specs = await dashboardGivenSpecs(runtime, entry, tile);
+          if (specs.ok) {
+            for (const s of specs.givens) if (!byName.has(s.name)) byName.set(s.name, s);
+          }
+        }
+        return { ok: true, givens: [...byName.values()] };
+      });
+    },
+    validate(runExpr, givens) {
+      return lease((runtime, entry) => validateQuery(runtime, entry, runExpr, givens));
+    },
+    validateIn(entryFile, runExpr, givens) {
+      return leaseIn(entryFile, (runtime, entry) => validateQuery(runtime, entry, runExpr, givens));
     }
   };
 }
@@ -1754,28 +2138,37 @@ function gatherDirectory(dir) {
   const config = existsSync2(configPath) ? readFileSync2(configPath, "utf8") : void 0;
   return { files, config };
 }
-function listDashboardDirs(dir) {
-  const base = join2(dir, "dashboards");
-  if (!existsSync2(base)) return [];
-  return readdirSync(base).filter((name) => statSync(join2(base, name)).isDirectory()).sort();
-}
 async function gatherDashboards(dir) {
+  const dashDir = join2(dir, "dashboards");
+  if (!existsSync2(dashDir)) return [];
   const runner = await makeRunner(dir);
-  const res = await runner.artifacts();
-  if (!res.ok) throw new Error(`model error: ${res.error}`);
-  return res.artifacts.map((a) => {
-    const tsxPath = join2(dir, "dashboards", a.name, "Dashboard.tsx");
-    const manifest = { title: a.title, query: a.query };
-    if (a.source) manifest.source = a.source;
-    if (a.view) manifest.view = a.view;
-    if (a.description) manifest.description = a.description;
-    if (a.givens) manifest.givens = a.givens;
-    return {
-      name: a.name,
-      manifest,
-      source: existsSync2(tsxPath) ? readFileSync2(tsxPath, "utf8") : ""
-    };
-  });
+  try {
+    const files = readdirSync(dashDir).filter((f) => f.endsWith(".malloy")).sort();
+    const payloads = [];
+    for (const file of files) {
+      const base = file.slice(0, -".malloy".length);
+      const entryFile = `dashboards/${file}`;
+      const res = await runner.artifactForFile(entryFile, base);
+      if (!res.ok) throw new Error(`dashboard ${file}: ${res.error}`);
+      if (!res.artifact) continue;
+      const a = res.artifact;
+      const manifest = { title: a.title, entryFile };
+      if (a.tiles) manifest.tiles = a.tiles;
+      if (a.dashboard_columns !== void 0) manifest.dashboard_columns = a.dashboard_columns;
+      if (a.description) manifest.description = a.description;
+      if (a.givens) manifest.givens = a.givens;
+      if (a.autorun === false) manifest.autorun = false;
+      const component = ["jsx", "tsx"].map((ext) => join2(dashDir, `${base}.${ext}`)).find((p) => existsSync2(p));
+      payloads.push({
+        name: a.name || base,
+        manifest,
+        source: component ? readFileSync2(component, "utf8") : ""
+      });
+    }
+    return payloads;
+  } finally {
+    await runner.dispose();
+  }
 }
 function gitInfo(dir) {
   const git = (args) => execFileSync("git", args, {
@@ -1805,85 +2198,135 @@ function gitInfo(dir) {
 }
 
 // src/lint.ts
-import { existsSync as existsSync3, readFileSync as readFileSync3 } from "node:fs";
+import { existsSync as existsSync3, readdirSync as readdirSync2, readFileSync as readFileSync3 } from "node:fs";
 import { join as join3, resolve } from "node:path";
 import * as esbuild from "esbuild";
 var quoteField = (f) => /^[A-Za-z_]\w*$/.test(f) ? f : `\`${f}\``;
+function componentQueryLiterals(source) {
+  const out = /* @__PURE__ */ new Set();
+  const re = /\bquery\s*=\s*(["'])([^"'\n]+)\1/g;
+  let m;
+  while ((m = re.exec(source)) !== null) out.add(m[2].trim());
+  return [...out];
+}
 async function lintDashboards(root) {
   const abs = resolve(root);
-  const dashboards = [];
   const runner = await makeRunner(abs);
-  if (!runner.entryExists()) {
-    return { ok: false, dashboards: [{ name: "(model)", errors: [`no index.malloy at ${abs}`] }] };
+  try {
+    return await runLint(abs, runner);
+  } finally {
+    await runner.dispose();
   }
-  const arts = await runner.artifacts();
-  if (!arts.ok) {
-    return { ok: false, dashboards: [{ name: "(model)", errors: [arts.error] }] };
+}
+async function runLint(abs, runner) {
+  const dashboards = [];
+  if (runner.entryExists()) {
+    const arts = await runner.artifacts();
+    if (!arts.ok) dashboards.push({ name: "index.malloy", errors: [arts.error], warnings: [] });
+  }
+  const dir = join3(abs, "dashboards");
+  if (!existsSync3(dir)) return { ok: dashboards.every((d) => d.errors.length === 0), dashboards };
+  const entries = readdirSync2(dir);
+  const malloyFiles = entries.filter((f) => f.endsWith(".malloy")).sort();
+  const malloyBases = new Set(malloyFiles.map((f) => f.slice(0, -".malloy".length)));
+  for (const c of entries.filter((f) => /\.(jsx|tsx)$/.test(f)).sort()) {
+    const cbase = c.replace(/\.(jsx|tsx)$/, "");
+    if (!malloyBases.has(cbase)) {
+      dashboards.push({
+        name: c,
+        errors: [`component "${c}" has no matching "${cbase}.malloy" dashboard`],
+        warnings: []
+      });
+    }
   }
-  const artifacts = arts.artifacts;
-  const dirs = listDashboardDirs(abs);
-  if (artifacts.length === 0 && dirs.length === 0) return { ok: true, dashboards };
-  const declared = new Set(artifacts.map((a) => a.name));
-  for (const dir of dirs) {
+  const seenNames = /* @__PURE__ */ new Map();
+  for (const file of malloyFiles) {
+    const base = file.slice(0, -".malloy".length);
+    const entryFile = join3("dashboards", file);
     const errors = [];
-    if (existsSync3(join3(abs, "dashboards", dir, "manifest.json"))) {
-      errors.push(
-        `manifest.json is obsolete \u2014 delete it; the model's \`# artifact title="\u2026"\` tag on the query is the manifest now`
-      );
+    const warnings = [];
+    const res = await runner.artifactForFile(entryFile, base);
+    if (!res.ok) {
+      dashboards.push({ name: base, errors: [res.error], warnings: [] });
+      continue;
     }
-    if (!declared.has(dir)) {
-      errors.push(
-        `no query is tagged for this dashboard \u2014 tag one with \`# artifact\` (or \`# artifact name="${dir}"\`) in the model`
-      );
+    if (!res.artifact) continue;
+    const art = res.artifact;
+    if (seenNames.has(art.name)) {
+      errors.push(`duplicate dashboard name "${art.name}" (also declared by ${seenNames.get(art.name)})`);
+    } else {
+      seenNames.set(art.name, file);
     }
-    if (errors.length) dashboards.push({ name: dir, errors });
-  }
-  for (const artifact of artifacts) {
-    const errors = [];
-    const v = await runner.validate(artifact.query, {});
-    if (!v.ok) errors.push(v.error);
-    const specs = await runner.givensForQuery(artifact.query);
+    if (art.dashboard_columns !== void 0 && (!Number.isInteger(art.dashboard_columns) || art.dashboard_columns < 1)) {
+      errors.push(`dashboard_columns must be a positive integer (got ${JSON.stringify(art.dashboard_columns)})`);
+    }
+    const tiles = art.tiles ?? [];
+    if (tiles.length === 0) errors.push(`\`## artifact\` declares no tiles`);
+    for (const tile of tiles) {
+      const v = await runner.validateIn(entryFile, tile, {});
+      if (!v.ok) errors.push(`tile "${tile}": ${v.error}`);
+    }
+    const specs = await runner.dashboardGivens(entryFile, tiles);
     if (specs.ok) {
       for (const spec of specs.givens) {
-        if (spec.tags?.suggest_query !== void 0) {
-          errors.push(
-            `given "${spec.name}": suggest_query is obsolete \u2014 declare # suggest { source=\u2026 dimension=\u2026 } or # suggest { query=\u2026 }`
-          );
-        }
         const suggest = spec.suggest;
         if (!suggest) continue;
-        const base = suggest.query ? `run: ${suggest.query}` : suggest.source && suggest.dimension ? `run: ${suggest.source} -> ${quoteField(suggest.dimension)}` : null;
-        if (base === null) {
+        const suggestBase = suggest.query ? `run: ${suggest.query}` : suggest.source && suggest.dimension ? `run: ${suggest.source} -> ${quoteField(suggest.dimension)}` : null;
+        if (suggestBase === null) {
           errors.push(
-            `given "${spec.name}": suggest must be \`suggest { source=<source> dimension=<field> }\` or \`suggest { query=<named_query> [dimension=<field>] }\``
+            `given "${spec.name}": suggest must be \`suggest { source=<source> dimension=<field> }\` or \`suggest { query=<query> [dimension=<field>] }\``
           );
           continue;
         }
-        const sv = await runner.validateText(base);
+        const sv = await runner.validateTextIn(entryFile, suggestBase);
         if (!sv.ok) errors.push(`given "${spec.name}": suggest does not compile \u2014 ${sv.error}`);
       }
     }
-    const tsxPath = join3(abs, "dashboards", artifact.name, "Dashboard.tsx");
-    if (existsSync3(tsxPath)) {
+    for (const ext of ["jsx", "tsx"]) {
+      const cp = join3(dir, `${base}.${ext}`);
+      if (!existsSync3(cp)) continue;
+      const source = readFileSync3(cp, "utf8");
       try {
-        await esbuild.transform(readFileSync3(tsxPath, "utf8"), { loader: "tsx", jsx: "automatic" });
+        await esbuild.transform(source, { loader: ext, jsx: "automatic" });
       } catch (e) {
         const msg = e.errors?.map((x) => x.text).join("; ") ?? String(e);
-        errors.push(`Dashboard.tsx: ${msg}`);
+        errors.push(`${base}.${ext}: ${msg}`);
+        continue;
+      }
+      for (const q of componentQueryLiterals(source)) {
+        const v = await runner.validateIn(entryFile, q, {});
+        if (!v.ok) errors.push(`${base}.${ext}: query "${q}" doesn't resolve \u2014 ${v.error}`);
+      }
+    }
+    dashboards.push({ name: art.name, errors, warnings });
+  }
+  const drills = await runner.drillTargets();
+  if (drills.ok) {
+    for (const target of drills.targets) {
+      if (!seenNames.has(target)) {
+        dashboards.push({
+          name: `drill \u2192 ${target}`,
+          errors: [
+            `# drill { to=[${target}] } targets no dashboard \u2014 add dashboards/${target}.malloy, or fix the slug to a real dashboard`
+          ],
+          warnings: []
+        });
       }
     }
-    dashboards.push({ name: artifact.name, errors });
   }
   return { ok: dashboards.every((d) => d.errors.length === 0), dashboards };
 }
 function printLintReport(report) {
   for (const d of report.dashboards) {
-    if (d.errors.length === 0) {
+    const hasErr = d.errors.length > 0;
+    const hasWarn = d.warnings.length > 0;
+    if (!hasErr && !hasWarn) {
       console.log(`  \u2713 ${d.name}`);
-    } else {
-      console.log(`  \u2717 ${d.name}`);
-      for (const e of d.errors) console.log(`      ${e}`);
+      continue;
     }
+    console.log(`  ${hasErr ? "\u2717" : "\u26A0"} ${d.name}`);
+    for (const e of d.errors) console.log(`      ${e}`);
+    for (const w of d.warnings) console.log(`      warning: ${w}`);
   }
 }
 
@@ -2167,271 +2610,12 @@ function attachSurface(server, surface, opts = {}) {
   }
 }
 
-// src/dashboard-guidance.ts
-var DASHBOARD_GUIDANCE = `
-
-# Authoring dashboards
-
-A dashboard is DECLARED IN THE MODEL \u2014 there is no manifest file and, for the
-basic case, no JavaScript at all. Preview with \`malloyyo dashboard dev\`; check
-with \`malloyyo lint\`.
-
-## Make dashboards discoverable: the entry model
-
-**The entry is \`index.malloy\`.** \`dashboard dev\`, \`lint\`, and the hosted
-server only see what that file EXPORTS. Three things must all be surfaced
-(imported AND exported) through it, or the feature looks broken:
-
-1. **Whatever holds each \`# artifact\` tag.** A tag on a \`view:\` rides along
-   with its SOURCE (export the source \u2014 you can't export a view on its own); a
-   tag on a top-level \`query:\` needs that query exported. Not surfaced \u2192
-   \`dashboard dev\` says "No dashboards declared" and \`lint\` says "no dashboards
-   to lint", even though the model compiles clean.
-2. **Every filter given the dashboards reference.** An unexported given
-   silently resolves to its declaration default \u2014 the control still renders
-   but CAN'T CHANGE THE QUERY (the filter looks inert).
-3. **Whatever backs each \`suggest\`** \u2014 the named query (\`suggest {query=\u2026}\`)
-   or source (\`suggest {source=\u2026}\`). Suggestions run against the entry model;
-   an unexported one fails lint with "Reference to undefined object".
-
-\`\`\`malloy
-##! experimental.givens
-import {
-  order_items,                      // the source \u2014 carries its # artifact views
-  BRAND, CATEGORY, PERIOD,          // the filter givens
-  brand_suggest                     // backs a suggest {query=\u2026}
-} from 'ecommerce.malloy'
-export { order_items, BRAND, CATEGORY, PERIOD, brand_suggest }
-\`\`\`
-
-Exporting the source is often the whole job: its \`# artifact\` views, its
-dimensions (for \`suggest {source=\u2026}\`), and its measures all travel with it.
-
-Prefer \`suggest { query=<named-query> \u2026 }\` over \`suggest { source=\u2026 }\` for
-anything beyond a throwaway: you export one small governed query instead of a
-whole base source.
-
-## The model is the whole contract
-
-**1. Tag a \`view:\` inside a source** with \`# artifact\` to declare a dashboard
-(the idiomatic form \u2014 a view is reusable, nestable, and explorable through the
-normal \`query\`/\`describe_source\` surface). For the common overview shape
-(top-level aggregates + nests), ALSO tag it \`# dashboard\` so the result
-renders as KPI tiles + a card grid instead of one flat table \u2014 they're
-partners: \`# artifact\` declares the dashboard, \`# dashboard\` is the renderer
-tag that draws it like one:
-
-\`\`\`malloy
-source: order_items is \u2026 extend {
-  #" Business health at a glance \u2014 sales, margin, orders.
-  # artifact { title="Business Overview" } dashboard
-  view: overview_dashboard is {
-    where:
-      inventory_items.product_brand ~ $BRAND,     // multi-filter where: is
-      inventory_items.product_category ~ $CATEGORY,  // COMMA separated
-      created_at ~ $PERIOD
-    aggregate: total_sales, total_gross_margin, order_count
-    nest:
-      # line_chart
-      sales_trend is by_month
-      top_brands
-      # shape_map
-      sales_by_state
-  }
-}
-\`\`\`
-
-That's a complete dashboard: the runtime auto-renders a title (the tag's
-\`title\`, else the \`#"\` doc comment), a control for every given the view
-references, and the result panel. It runs as \`run: <source> -> <view>\` (here
-\`order_items -> overview_dashboard\`). \`name="slug"\` overrides the
-URL/directory slug (default: the view name). Note the \`where:\` clauses
-applying givens are COMMA-separated \u2014 newline-separated conditions do not
-parse.
-
-Tagging a **top-level \`query:\`** still works and behaves identically (it runs
-as \`run: <name>\`) \u2014 reach for it only when the dashboard query doesn't belong
-to any one source.
-
-Two dashboards can share a given but start on different values \u2014 a \`givens\`
-block in the tag sets PER-DASHBOARD defaults (given values, i.e. filter
-expressions; URL params still win):
-
-\`\`\`malloy
-# artifact { name="manufacturer" title="Manufacturer Recall Profile" givens { MANUFACTURER="Ford Motor Company" } }
-\`\`\`
-
-This replaces the "declare the given's default per dashboard" role the old
-manifests had: declare the given once with a neutral default (often \`f''\` =
-no filter), and let each tag pick its landing state.
-
-**2. Declare the filters as \`filter<T>\` givens** \u2014 never raw strings/numbers.
-A \`filter<string>\` value accepts one value ('NY'), alternatives ('NY, CA'),
-wildcards ('Ann%'), negation ('-NY'); a \`filter<number>\` accepts ranges
-('[1910 to 1930]') and comparisons ('> 200'); a \`filter<timestamp>\` /
-\`filter<date>\` accepts relative windows ('7 days' = the last 7 days, 'today',
-'last month') and literal ranges ('2026-01-01 to 2026-07-01' \u2014 NO \`@\` in
-filter literals). Apply with \`~\`; \`f''\` = empty = no filter (the natural
-"All"/"all time" \u2014 just \`col ~ $X\`, no \`$X = '' or \u2026\` dance):
-
-\`\`\`malloy
-##! experimental { givens }
-given:
-  # label="State" control=select suggest { source=baby_names dimension=state }
-  STATE :: filter<string> is f'NY'
-  # label="Brand" suggest { query=brand_suggest dimension=product_brand }
-  BRAND :: filter<string> is f''
-  # label="Years" range_min=1910 range_max=2025
-  YEAR_RANGE :: filter<number> is f'[1910 to 1930]'
-  # label="Time period"
-  PERIOD :: filter<timestamp> is f''
-  # label="Include rare names"
-  INCLUDE_RARE :: boolean is false
-\`\`\`
-
-Tags on the declaration drive the control (tag syntax is \`key="value"\` \u2014
-equals, not colon):
-- \`label\` \u2014 control caption (defaults to the given's name)
-- \`suggest { \u2026 }\` \u2014 where the control's options come from. NO Malloy code in
-  strings \u2014 just names:
-  - \`suggest { query=brand_suggest dimension=product_brand }\` \u2014 the FIRST
-    COLUMN of a named query (declare the query in the model \u2014 governed,
-    reviewable, and only that query needs exporting). PREFER THIS FORM.
-  - \`suggest { source=baby_names dimension=state }\` \u2014 the DISTINCT VALUES of
-    a dimension on a source (the whole source must be exported)
-  A \`dimension\` (in either form) is what enables SERVER-SIDE TYPEAHEAD: the
-  runtime refines the base query with what the user has typed
-  (\`\u2026 + { where: lower(field) ~ f'll%'; limit: 50 }\`, case-insensitive,
-  escaped). Without a dimension the fetched list is filtered client-side.
-  Runs as a restricted query; lint checks the declaration compiles.
-
-  **RELATED (faceted) filters** \u2014 query-form only: a suggest query may
-  reference the OTHER givens, and the runtime runs it with the dashboard's
-  current values (the suggested given itself is excluded, so the list never
-  collapses to the current pick). Brand suggestions narrow when Category is
-  set:
-
-  \`\`\`malloy
-  query: brand_suggest is inventory_items -> product_brand + {
-    where:
-      product_category ~ $CATEGORY,      // NOT product_brand ~ $BRAND
-      product_department ~ $DEPARTMENT
-    limit: 500
-  }
-  \`\`\`
-
-  Declare one \`*_suggest\` per filter, each referencing the others; \`f''\`
-  defaults mean unset filters don't constrain. \`source=\` suggests can't do
-  this (no place for a \`where:\`) \u2014 another reason to prefer \`query=\`.
-- \`control=select\` \u2014 a fixed dropdown instead of a typeahead search box
-- \`range_min\` / \`range_max\` \u2014 bounds; makes a filter<number> given a
-  dual-thumb range slider
-- anything else passes through in \`spec.tags\` for custom components
-
-Control picked from the declaration automatically: numeric range tags \u2192
-dual-thumb slider; \`filter<timestamp|timestamptz|date>\` \u2192 the TimeRange
-widget (relative presets: Today / Last 7 days / Last 30 days / \u2026 plus a
-"Custom range\u2026" from/to date picker); suggest + control=select \u2192 dropdown;
-boolean \u2192 checkbox; anything else \u2192 committing search box with typeahead.
-The suggest-driven options are DATA VALUES only \u2014 options that aren't column
-values (custom time presets, threshold buckets) need a custom component
-(below) with explicit \`{value, text}\` options where value is a filter
-expression built with \`filters.*\`.
-
-## Custom components (optional): ./dashboards/<slug>/Dashboard.tsx
-
-When the default UI isn't enough, add ONE file. It composes the runtime's
-widgets/hooks with your own React \u2014 you own layout, copy, and theming; the
-model still owns every query and filter:
-
-\`\`\`tsx
-import React from "react";
-import { Controls, Given, Search, Select, TimeRange, Panel, filters, useGiven } from "@malloyyo/dashboard";
-
-export default function Dashboard({ dashboard, givens }) {
-  return (
-    <div style={{ maxWidth: 860, margin: "0 auto", padding: 24 }}>
-      <h1>{dashboard.title}</h1>
-      <Controls>
-        <Given name="STATE" />          {/* picks the control from the declaration */}
-        <Search given="NAME" />         {/* committing input + typeahead + validation */}
-        <TimeRange given="PERIOD" presets={[
-          { value: "", text: "All time" },
-          { value: filters.lastN(1, "day"), text: "Last day" },
-          { value: filters.lastN(1, "week"), text: "Last week" },
-          { value: filters.lastN(1, "month"), text: "Last month" },
-        ]} />                            {/* "Custom range\u2026" is always appended */}
-        <Select given="MIN_SAMPLE"
-          options={[10, 200, 1000].map(n => ({ value: filters.greaterThan(n), text: \`> \${n}\` }))} />
-      </Controls>
-      <Panel givens={givens} />         {/* the tagged query, Malloy renderer */}
-      <Panel malloy="baby_names -> births_by_decade" givens={givens} />  {/* restricted text */}
-    </div>
-  );
-}
-\`\`\`
-
-From \`@malloyyo/dashboard\` (also handed to the component as props):
-- **Widgets** (headless-ish; restyle via className/style or CSS vars
-  \`--dash-fg/-muted/-border/-accent/-control-bg/-controls-bg\`):
-  \`<Controls/>\` (all givens, or compose children), \`<Given name/>\`,
-  \`<Select given [options]/>\`, \`<Search given/>\`, \`<Range given [min max]/>\`,
-  \`<TimeRange given [presets]/>\` (temporal presets + custom range),
-  \`<Checkbox given/>\` (bound to a boolean given)
-- **Hooks**: \`useGiven(name)\` \u2192 {value, set, spec};
-  \`useOptions(name, typed?)\` \u2192 {options, loading} (typeahead);
-  \`useQuery({query|malloy, givens})\` \u2192 {rows, loading, error} \u2014 plain rows
-  for your own visuals
-- **Helpers**: \`filters.oneOf/contains/between/atLeast/\u2026\` build
-  filter-expression strings with correct escaping; temporal:
-  \`filters.lastN(7, "day")\` \u2192 \`'7 days'\`, \`filters.dateRange("2026-01-01",
-  "2026-07-01")\`, \`filters.afterDate/beforeDate\`; read back with
-  \`filters.values/numberRange/threshold/inLast/temporalRange\`;
-  \`filters.isValid(type, src)\` checks typed input.
-  Never hand-concatenate a filter string.
-  **Escaping rule for custom controls:** a filter given's value is an
-  EXPRESSION, so committing a raw column value is wrong the moment it contains
-  a comma/percent/dash ('Tesla, Inc.' parses as two alternatives and matches
-  nothing). Commit \`filters.oneOf(value)\` (exact) or
-  \`filters.contains(term)\` (substring), and unwrap for display with
-  \`filters.values(src)\`. The stock \`<Select/>\` does this automatically;
-  \`<Search/>\` deliberately commits raw text (its input IS a filter
-  expression).
-- \`<Panel/>\` and \`runData(text, givens)\` \u2014 named queries are the primary
-  form; arbitrary Malloy runs as a RESTRICTED query (no import / given: /
-  connection.* / raw SQL / ##! flags \u2014 the model's published surface only).
-
-## Rules
-- Declare data in the model: givens are \`filter<T>\`, options come from
-  \`# suggest {\u2026}\` declarations, dashboards are \`# artifact\` tags. If a query or given you
-  need is missing, add it to the \`.malloy\` file first (check with
-  \`describe_source\`).
-- Surface everything through the entry model (see the top section).
-- Only React + \`@malloyyo/dashboard\` are importable. No other imports, no
-  network \u2014 the runtime sandboxes the component.
-- Interactivity = setting given values (filter-expression strings), not
-  rewriting query text per interaction.
-
-## Preview & validate
-\`malloyyo dashboard dev\` \u2192 open the printed URL. Edits to \`.malloy\` (tags,
-givens, queries) and \`Dashboard.tsx\` hot-reload. \`malloyyo lint\` validates
-the tagged queries, given \`suggest\` declarations, and any Dashboard.tsx \u2014
-but only for dashboards REACHABLE FROM THE ENTRY: "no dashboards to lint"
-usually means the \`# artifact\` queries aren't exported through
-\`index.malloy\`, not that they don't exist.
-
-Validation loop that works well: the local \`malloyyo mcp\` server hot-reloads
-working-directory edits \u2014 \`query(execute:false)\` to compile-check,
-\`execute:true\` to run. A \`# artifact\` view runs as
-\`run: <source> -> <view>\`; a top-level \`# artifact\` query runs as
-\`run: <name>\`. Either is only visible once surfaced through the entry (export
-the source for a view, the query for a top-level query). Don't validate local
-edits against a hosted/claude.ai connector \u2014 that serves the PUBLISHED model,
-which is stale until \`malloyyo publish\`.
-`;
-
 // src/mcp.ts
 var ENTRY2 = "index.malloy";
+var MODE_STUB = {
+  develop: "\n\n# DEVELOP (author) mode\nYou can author this Malloy model \u2014 compile / compile_file / prettify / query the files in this project (any .malloy path; no index.malloy required). For how-to, call yo_help \u2014 start with `dashboards/authoring`, then `dashboards/grid-layout`, `dashboards/vega-charts`, and the `develop/*` topics. To preview exactly what claude.ai web will see, relaunch as `malloyyo test`.",
+  explore: "\n\n# TEST (explore) mode\nThis mirrors the claude.ai web experience \u2014 the same tools a hosted consumer gets, over this project's published entry model (index.malloy). Call yo_help for guidance. To author the model (compile / edit / dashboards), relaunch as `malloyyo author`."
+};
 function defaultConfig(rootUrl) {
   return new MalloyConfig2({ includeDefaultConnections: true }, {
     rootDirectory: rootUrl.toString()
@@ -2525,16 +2709,21 @@ function makeExploreHost(root, currentConfig) {
     }
   };
 }
+function makeDevelopHost(root, currentConfig) {
+  return { withRuntime: makeWithRuntime(root, currentConfig) };
+}
 async function serveMcp(opts) {
   await import("@malloydata/malloy-connections");
   const root = path3.resolve(opts.root ?? process.cwd());
+  const mode = opts.mode ?? "explore";
   const currentConfig = makeConfigSource(root);
-  const surface = exploreSurface(makeExploreHost(root, currentConfig));
+  const surface = mode === "develop" ? developSurface(makeDevelopHost(root, currentConfig)) : exploreSurface(makeExploreHost(root, currentConfig));
   const instanceName = process.env.INSTANCE_NAME || "Malloyyo";
+  const serverName = mode === "develop" ? "malloyyo-develop" : "malloyyo-explore";
   const server = new McpServer(
-    { name: "malloyyo-explore", version: opts.version },
+    { name: serverName, version: opts.version },
     {
-      instructions: renderInstructions(surface.instructions, instanceName) + DASHBOARD_GUIDANCE,
+      instructions: renderInstructions(surface.instructions, instanceName) + MODE_STUB[mode],
       capabilities: { tools: {}, prompts: {}, resources: {} }
     }
   );
@@ -2588,12 +2777,20 @@ function resolveRuntimeDir() {
 }
 var resolveFrameEntry = () => path4.join(resolveRuntimeDir(), "..", "frame-entry.tsx");
 async function discoverDashboards(root, runner) {
-  const result = await runner.artifacts();
-  if (!result.ok) throw new Error(`model error: ${result.error}`);
-  return result.artifacts.map((a) => {
-    const tsxPath = path4.join(root, "dashboards", a.name, "Dashboard.tsx");
-    return { ...a, tsxPath: fs3.existsSync(tsxPath) ? tsxPath : void 0 };
-  });
+  const dir = path4.join(root, "dashboards");
+  if (!fs3.existsSync(dir)) return [];
+  const files = fs3.readdirSync(dir).filter((f) => f.endsWith(".malloy")).sort();
+  const dashboards = [];
+  for (const file of files) {
+    const base = file.slice(0, -".malloy".length);
+    const entryFile = path4.join("dashboards", file);
+    const res = await runner.artifactForFile(entryFile, base);
+    if (!res.ok) throw new Error(`dashboard ${file}: ${res.error}`);
+    if (!res.artifact) continue;
+    const component = ["jsx", "tsx"].map((ext) => path4.join(dir, `${base}.${ext}`)).find((p) => fs3.existsSync(p));
+    dashboards.push({ ...res.artifact, name: res.artifact.name || base, entryFile, tsxPath: component });
+  }
+  return dashboards;
 }
 var esc = (s) => s.replace(/&/g, "&amp;").replace(/</g, "&lt;").replace(/>/g, "&gt;").replace(/"/g, "&quot;");
 function makeBundler() {
@@ -2657,7 +2854,9 @@ function parentShell(dash, frameBase, all, initialGivens) {
     return `<a href="/?d=${encodeURIComponent(x.name)}" style="padding:4px 10px;border-radius:6px;text-decoration:none;${on ? "background:#1a1a1a;color:#fff" : "color:#333"}">${esc(x.title || x.name)}</a>`;
   }).join("") + `</nav>` : "";
   return html(
-    `<div style="display:flex;flex-direction:column;height:100vh">` + nav + `<iframe id="f" sandbox="allow-scripts allow-same-origin" src="${frameBase}/frame?d=${encodeURIComponent(dash.name)}${givensQs}" style="border:0;flex:1;width:100%"></iframe></div><script>
+    `<div style="display:flex;flex-direction:column;height:100vh">` + nav + // allow-popups(+escape-sandbox): let a # link mark open its target in a
+    // normal new tab on click instead of being blocked by the sandbox.
+    `<iframe id="f" sandbox="allow-scripts allow-same-origin allow-popups allow-popups-to-escape-sandbox" src="${frameBase}/frame?d=${encodeURIComponent(dash.name)}${givensQs}" style="border:0;flex:1;width:100%"></iframe></div><script>
 const f=document.getElementById('f');
 try{new EventSource('/events').onmessage=()=>location.reload();}catch(e){}
 window.addEventListener('message',async(e)=>{
@@ -2666,15 +2865,22 @@ window.addEventListener('message',async(e)=>{
   if(m&&m.type==='givens'){
     const u=new URL(location.href); u.search='';
     u.searchParams.set('d',${d});
-    for(const [k,v] of Object.entries(m.givens)) u.searchParams.set(k,String(v));
+    for(const [k,v] of Object.entries(m.givens)) if(v!=null&&String(v)!=='') u.searchParams.set('$'+k,String(v));
     history.replaceState(null,'',u.pathname+u.search);
     return;
   }
+  if(m&&m.type==='navigate'&&typeof m.dashboard==='string'){
+    const u=new URL(location.href); u.search='';
+    u.searchParams.set('d',m.dashboard);
+    for(const [k,v] of Object.entries(m.givens||{})) if(v!=null&&String(v)!=='') u.searchParams.set('$'+k,String(v));
+    location.href=u.pathname+u.search;
+    return;
+  }
   if(!m||m.type!=='run')return;
   let out;
   try{
     const res=await fetch('/api/run',{method:'POST',headers:{'content-type':'application/json'},
-      body:JSON.stringify({d:${d},query:m.query,malloy:m.malloy,givens:m.givens})});
+      body:JSON.stringify({d:${d},query:m.query,malloy:m.malloy,givens:m.givens,dashboard:m.dashboard})});
     out=await res.json();
   }catch(err){ out={ok:false,problems:[{message:String(err)}]}; }
   f.contentWindow.postMessage({type:'result',id:m.id,...out},${fb});
@@ -2694,7 +2900,10 @@ function frameDoc(dash, givenSpecs, initialGivens) {
     query: dash.query,
     title: dash.title,
     description: dash.description,
-    givens: dash.givens
+    tiles: dash.tiles,
+    dashboard_columns: dash.dashboard_columns,
+    givens: dash.givens,
+    autorun: dash.autorun
   };
   return html(
     `<div id="root"></div><script>window.__DASHBOARD__=${JSON.stringify(info)};window.__GIVENS__=${JSON.stringify(givenSpecs)};window.__INITIAL_GIVENS__=${JSON.stringify(initialGivens)}</script><script src="/bundle.js?d=${encodeURIComponent(dash.name)}"></script>`,
@@ -2758,7 +2967,7 @@ async function serveDashboard(opts) {
       if (onFramePort) {
         if (url4.pathname === "/frame") {
           const dash = pick(url4);
-          const specs = await runner.givensForQuery(dash.query);
+          const specs = dash.tiles && dash.entryFile ? await runner.dashboardGivens(dash.entryFile, dash.tiles) : await runner.givensForQuery(dash.query);
           if (!specs.ok) {
             return send(
               200,
@@ -2784,10 +2993,11 @@ async function serveDashboard(opts) {
         return send(200, "text/html; charset=utf-8", parentShell(pick(url4), frameBase, dashboards, givensFromUrl(url4)));
       }
       if (url4.pathname === "/api/run" && req.method === "POST") {
-        const { d, query, malloy, givens } = JSON.parse(await readBody(req));
+        const { d, query, malloy, givens, dashboard } = JSON.parse(await readBody(req));
         const dash = byName.get(d);
         if (!dash) return send(404, "application/json", JSON.stringify({ ok: false, problems: [{ message: `no dashboard '${d}'` }] }));
-        const out = typeof malloy === "string" ? await runner.runText(malloy, givens ?? {}) : await runner.run(String(query ?? dash.query), givens ?? {});
+        const entry = dash.entryFile;
+        const out = dashboard && dash.tiles && entry ? await runner.runDashboard(entry, dash.tiles, { columns: dash.dashboard_columns, givens: givens ?? {} }) : typeof malloy === "string" ? entry ? await runner.runTextIn(entry, malloy, givens ?? {}) : await runner.runText(malloy, givens ?? {}) : entry ? await runner.runIn(entry, String(query ?? ""), givens ?? {}) : await runner.run(String(query ?? dash.query), givens ?? {});
         return send(200, "application/json", JSON.stringify(out));
       }
       send(404, "text/plain", "not found");
@@ -2812,8 +3022,126 @@ async function serveDashboard(opts) {
   });
 }
 
+// src/init.ts
+import fs4 from "node:fs";
+import path5 from "node:path";
+var AUTHOR_MCP = {
+  mcpServers: {
+    // No -C: the server roots at the launch cwd (the project dir), so this file
+    // is portable/committable — no absolute paths baked in.
+    malloyyo_author: { command: "malloyyo", args: ["mcp", "--develop"] }
+  }
+};
+function exportableNames(src) {
+  const names = /* @__PURE__ */ new Set();
+  const code = src.replace(/\/\/[^\n]*/g, "");
+  for (const m of code.matchAll(/^\s*(?:source|query)\s*:\s*([A-Za-z_]\w*)\s+is\b/gm)) {
+    names.add(m[1]);
+  }
+  for (const m of code.matchAll(/^\s*([A-Za-z_]\w*)\s*::/gm)) {
+    names.add(m[1]);
+  }
+  return [...names];
+}
+function scaffoldIndex(root) {
+  const indexPath = path5.join(root, "index.malloy");
+  if (fs4.existsSync(indexPath)) {
+    return { wrote: false, note: "index.malloy already exists \u2014 left as-is" };
+  }
+  const models = fs4.readdirSync(root).filter((f) => f.endsWith(".malloy") && f !== "index.malloy").sort();
+  if (models.length === 0) {
+    return { wrote: false, note: "no .malloy files found \u2014 skipped index.malloy" };
+  }
+  const blocks = [
+    "// Generated by `malloyyo init` \u2014 the entry model. `dashboard dev`, `lint`,",
+    "// `malloyyo test`, and the hosted app only see what THIS file exports.",
+    "// Review the re-exports below (add givens / suggest queries your dashboards",
+    "// reference), then validate with `malloyyo mcp --develop` or `dashboard dev`.",
+    ""
+  ];
+  let anyNames = false;
+  for (const file of models) {
+    const names = exportableNames(fs4.readFileSync(path5.join(root, file), "utf8"));
+    if (names.length === 0) {
+      blocks.push(`// ${file}: no top-level source/query/given detected \u2014 add exports by hand`);
+      continue;
+    }
+    anyNames = true;
+    const list = names.join(", ");
+    blocks.push(`import { ${list} } from './${file}'`);
+    blocks.push(`export { ${list} }`);
+    blocks.push("");
+  }
+  fs4.writeFileSync(indexPath, blocks.join("\n") + "\n");
+  return {
+    wrote: true,
+    note: anyNames ? `wrote index.malloy re-exporting ${models.length} model file(s) \u2014 REVIEW it` : "wrote index.malloy skeleton \u2014 no exports detected, fill them in by hand"
+  };
+}
+async function initCmd(dir) {
+  const root = path5.resolve(dir);
+  if (!fs4.existsSync(root) || !fs4.statSync(root).isDirectory()) {
+    throw new Error(`not a directory: ${root}`);
+  }
+  const mcpPath = path5.join(root, ".mcp.json");
+  if (fs4.existsSync(mcpPath)) {
+    console.log(`\u2022 .mcp.json exists \u2014 leaving it. For author-by-default it should be:`);
+    console.log(`    ${JSON.stringify(AUTHOR_MCP.mcpServers.malloyyo_author)}`);
+    console.log(`  (server key "malloyyo_author", command "malloyyo mcp --develop").`);
+  } else {
+    fs4.writeFileSync(mcpPath, JSON.stringify(AUTHOR_MCP, null, 2) + "\n");
+    console.log(`\u2713 wrote .mcp.json \u2014 \`cd ${dir} && claude\` now opens in AUTHOR mode`);
+  }
+  const idx = scaffoldIndex(root);
+  console.log(`${idx.wrote ? "\u2713" : "\u2022"} ${idx.note}`);
+  console.log("");
+  console.log("Next:");
+  console.log("  claude              # author mode (mcp__malloyyo_author__* tools)");
+  console.log("  malloyyo test       # preview exactly what claude.ai web will see");
+  console.log("  malloyyo dashboard dev   # see dashboards render in a browser");
+}
+
+// src/launch.ts
+import { spawn as spawn2 } from "node:child_process";
+import fs5 from "node:fs";
+import os from "node:os";
+import path6 from "node:path";
+var SURFACE_FLAG = { author: "--develop", test: "--explore" };
+var SERVER_KEY = { author: "malloyyo_author", test: "malloyyo_test" };
+async function launchCmd(mode, opts) {
+  const root = path6.resolve(opts.root ?? process.cwd());
+  const tmpDir = fs5.mkdtempSync(path6.join(os.tmpdir(), "malloyyo-launch-"));
+  const cfgPath = path6.join(tmpDir, "mcp.json");
+  const cfg = {
+    mcpServers: {
+      // Absolute -C: an ephemeral config, so pinning the root is robust.
+      [SERVER_KEY[mode]]: { command: "malloyyo", args: ["mcp", SURFACE_FLAG[mode], "-C", root] }
+    }
+  };
+  fs5.writeFileSync(cfgPath, JSON.stringify(cfg, null, 2));
+  const label = mode === "author" ? "AUTHOR (compile/edit)" : "TEST (claude.ai web preview)";
+  process.stderr.write(`\u25B6 launching Claude in ${label} mode over ${root}
+`);
+  const child = spawn2("claude", ["--strict-mcp-config", "--mcp-config", cfgPath], {
+    stdio: "inherit",
+    cwd: root
+  });
+  await new Promise((resolve3) => {
+    child.on("error", (e) => {
+      process.stderr.write(
+        `\u2717 could not launch \`claude\`: ${e.message}
+  (is Claude Code installed and on PATH?)
+`
+      );
+      resolve3();
+    });
+    child.on("exit", () => resolve3());
+  });
+  fs5.rmSync(tmpDir, { recursive: true, force: true });
+}
+
 // package.json
-var version = "0.2.14";
+var version = "0.2.16";
 
 // src/index.ts
 function shortSha(sha) {
@@ -2899,10 +3227,26 @@ program.command("lint").argument("[dir]", "directory to lint", ".").description(
   if (!report.ok) process.exit(1);
 });
 program.command("status").argument("<target>", "named target from the `malloyyo` config block").option("--token <token>", "bearer token (overrides login/env)").description("show what's live on <target>: version, commit, compile state").action(status);
-program.command("mcp").option("-C, --root <dir>", "project root (default: current directory)").description(
-  "run a local stdio MCP server (the explore / test-window surface) over the Malloy model in the current directory"
+program.command("mcp").option("-C, --root <dir>", "project root (default: current directory)").option("--develop", "author surface: compile/prettify/query any .malloy in the project").option("--explore", "explore surface: the claude.ai web preview (index.malloy only) [default]").description(
+  "run a local stdio MCP server over the Malloy model in the current directory. --develop for authoring, --explore (default) to preview the web experience"
 ).action(async (opts) => {
-  await serveMcp({ root: opts.root, version });
+  if (opts.develop && opts.explore) {
+    throw new Error("pass only one of --develop / --explore");
+  }
+  await serveMcp({
+    root: opts.root,
+    version,
+    mode: opts.develop ? "develop" : "explore"
+  });
+});
+program.command("init").argument("[dir]", "model repo to set up", ".").description(
+  "set up a model repo: write .mcp.json so `cd <repo> && claude` opens in author mode, and scaffold index.malloy if missing"
+).action(initCmd);
+program.command("author").option("-C, --root <dir>", "project root (default: current directory)").description("launch Claude wired ONLY to the author surface (compile/edit the model)").action(async (opts) => {
+  await launchCmd("author", opts);
+});
+program.command("test").option("-C, --root <dir>", "project root (default: current directory)").description("launch Claude wired ONLY to the explore surface \u2014 the claude.ai web preview").action(async (opts) => {
+  await launchCmd("test", opts);
 });
 program.command("dashboard").argument("<action>", "action to run (currently: dev)").option("-C, --root <dir>", "project root (default: current directory)").option("-p, --port <port>", "port to serve on", "4173").description("preview dashboard artifacts in ./dashboards against the local Malloy model").action(async (action, opts) => {
   if (action !== "dev") throw new Error(`unknown dashboard action '${action}' (expected: dev)`);