@lightdash/cli 2.305.0 → 2.305.2

package/dist/handlers/apps/scaffolding.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"scaffolding.d.ts","sourceRoot":"","sources":["../../../src/handlers/apps/scaffolding.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,KAAK,eAAe,EAAE,MAAM,mBAAmB,CAAC;AAMzD;;GAEG;AACH,wBAAgB,gBAAgB,CAAC,UAAU,EAAE,MAAM,EAAE,GAAG,MAAM,GAAG,IAAI,CAKpE;AA6DD;;;GAGG;AACH,eAAO,MAAM,oBAAoB,gBAChB,MAAM,WACV,MAAM,KAChB,MAAmE,CAAC;AAEvE;;;;GAIG;AACH,eAAO,MAAM,wBAAwB,eACrB,MAAM,KACnB,MAAM,CAAC,MAAM,EAAE,MAAM,CAevB,CAAC;AAWF,eAAO,MAAM,yBAAyB,eACtB,MAAM,KACnB,eAAe,EAeb,CAAC;AAEN,eAAO,MAAM,yBAAyB,QAAO,eAAe,EAG3D,CAAC;AAEF;;;;;GAKG;AACH,eAAO,MAAM,uBAAuB,QAAO,eAQ1C,CAAC;AAEF,4EAA4E;AAC5E,MAAM,MAAM,eAAe,GAAG,KAAK,GAAG,YAAY,CAAC;AAEnD;;GAEG;AACH,eAAO,MAAM,yBAAyB,SAAU;IAC5C,OAAO,EAAE,MAAM,CAAC;IAChB,UAAU,EAAE,MAAM,CAAC;IACnB,MAAM,CAAC,EAAE,eAAe,CAAC;CAC5B,KAAG,eAAe,EA8GlB,CAAC"}
+{"version":3,"file":"scaffolding.d.ts","sourceRoot":"","sources":["../../../src/handlers/apps/scaffolding.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,KAAK,eAAe,EAAE,MAAM,mBAAmB,CAAC;AAMzD;;GAEG;AACH,wBAAgB,gBAAgB,CAAC,UAAU,EAAE,MAAM,EAAE,GAAG,MAAM,GAAG,IAAI,CAKpE;AA6DD;;;GAGG;AACH,eAAO,MAAM,oBAAoB,gBAChB,MAAM,WACV,MAAM,KAChB,MAAmE,CAAC;AAEvE;;;;GAIG;AACH,eAAO,MAAM,wBAAwB,eACrB,MAAM,KACnB,MAAM,CAAC,MAAM,EAAE,MAAM,CAevB,CAAC;AAWF,eAAO,MAAM,yBAAyB,eACtB,MAAM,KACnB,eAAe,EAeb,CAAC;AAEN,eAAO,MAAM,yBAAyB,QAAO,eAAe,EAG3D,CAAC;AAEF;;;;;GAKG;AACH,eAAO,MAAM,uBAAuB,QAAO,eAQ1C,CAAC;AAEF,4EAA4E;AAC5E,MAAM,MAAM,eAAe,GAAG,KAAK,GAAG,YAAY,CAAC;AAEnD;;GAEG;AACH,eAAO,MAAM,yBAAyB,SAAU;IAC5C,OAAO,EAAE,MAAM,CAAC;IAChB,UAAU,EAAE,MAAM,CAAC;IACnB,MAAM,CAAC,EAAE,eAAe,CAAC;CAC5B,KAAG,eAAe,EAsHlB,CAAC"}

package/dist/handlers/apps/scaffolding.js

@@ -186,6 +186,13 @@ const buildStaticAuthoringFiles = (args) => {
         path: '.gitignore',
         contentBase64: (0, fs_1.readFileSync)(path.join(authoringDir, 'gitignore')).toString('base64'),
     });
-    return files;
+    // 7. Codex discovers skills in .agents/skills, not .claude/skills.
+    const agentsSkillMirrors = files
+        .filter((file) => file.path.startsWith('.claude/skills/'))
+        .map((file) => ({
+        ...file,
+        path: file.path.replace(/^\.claude\//, '.agents/'),
+    }));
+    return [...files, ...agentsSkillMirrors];
 };
 exports.buildStaticAuthoringFiles = buildStaticAuthoringFiles;

package/dist/vendor/authoring/AGENTS.md.tmpl

@@ -1,6 +1,6 @@
 # Working on this Lightdash data app
 
-Two skills in `.claude/skills/` describe how to edit this app:
+Two bundled skills describe how to edit this app:
 - `lightdash-data-app` — the Lightdash SDK surface (querying data, filters, downloads).
 - `developing-data-apps-locally` — the local workflow: edit `src/`, `lightdash apps validate --build`, `lightdash apps preview`, `lightdash upload --apps <slug> --path ../..`; the SDK is the only data access; `.lightdash/context/` holds the project's semantic layer and theme.
 

package/dist/vendor/authoring/chart-type/AGENTS.md.tmpl

@@ -2,7 +2,7 @@
 
 This folder is a **custom chart type** (a reusable visualization, the `data_app_viz` template) — ONE chart component that receives its data and settings from Lightdash, not a data app. It runs no query, owns no explore, and must not fetch anything itself.
 
-Two skills in `.claude/skills/` describe how to edit it:
+Two bundled skills describe how to edit it:
 - `reusable-visualization` — the contract: the `useVizContext()` hook, the field/option declaration, resolved series colours, pivoted results.
 - `developing-chart-types-locally` — the local workflow: the vizSchema lockstep rule, validate/upload/verify loop, and the path to the official registry.
 

package/dist/vendor/authoring/chart-type/App.jsx

@@ -43,7 +43,7 @@ const token = (name) =>
 // mapping from the field names declared in lightdash-app.yml's vizSchema to
 // the query's columns. Everything read here (`category`/`value` fields,
 // `showLabels`/`maxBars` options) is declared there; keep the two in lockstep
-// (see .claude/skills/reusable-visualization).
+// (see the reusable-visualization skill).
 function App() {
     const context = useVizContext();
     const { fieldMapping, rows, options, colorPalette, ready } = context;

package/dist/vendor/authoring/chart-type/README.md.tmpl

@@ -5,7 +5,7 @@ Created or downloaded with the Lightdash CLI. This is a **custom chart type** (a
 ## Edit → validate → upload
 Run these commands from this folder under `chart-types/<slug>/`. The upload path `../..` selects the Lightdash content root.
 
-1. Edit files under `src/`. The component's contract with Lightdash — the fields it maps and the config options viewers can change — is declared in `lightdash-app.yml` under `vizSchema` and must match what `src/App.jsx` reads (see `.claude/skills/reusable-visualization`).
+1. Edit files under `src/`. The component's contract with Lightdash — the fields it maps and the config options viewers can change — is declared in `lightdash-app.yml` under `vizSchema` and must match what `src/App.jsx` reads (see the `reusable-visualization` skill).
 2. Run `lightdash apps validate` to check the source and manifest; `lightdash apps validate --build` adds the Cloud-parity Vite production build.
 3. `lightdash upload --chart-types <slug> --path ../..` (the `slug` from `lightdash-app.yml`) — Lightdash rebuilds and serves it.
 4. Open any explore in Lightdash, run a query, and pick this chart type in the chart type picker to see it against real data.

package/dist/vendor/authoring/developing-chart-types-locally/SKILL.md

@@ -9,7 +9,7 @@ You are editing a Lightdash **custom chart type** (a reusable visualization, the
 
 ## The contract is the reusable-visualization skill
 
-Read `.claude/skills/reusable-visualization` before editing. It defines everything the component may do: `useVizContext()` is the only channel to the host (data, options, resolved colours), the component runs no query, owns no explore, and never fetches anything itself. App-level SDK APIs (query builder, `useLightdash`, filters, `externalFetch`) do not apply here and must not be introduced.
+Read the `reusable-visualization` skill before editing. It defines everything the component may do: `useVizContext()` is the only channel to the host (data, options, resolved colours), the component runs no query, owns no explore, and never fetches anything itself. App-level SDK APIs (query builder, `useLightdash`, filters, `externalFetch`) do not apply here and must not be introduced.
 
 Never hand-build a data-point action menu when `useVizContext().pointMenu.enabled` — call `pointMenu.open({ x, y, row, metric })` and let Lightdash render it; an in-viz menu is only the fallback for hosts that predate the capability.
 

package/dist/vendor/template/skill.md

@@ -4,6 +4,16 @@ You are building a React data app that queries the Lightdash semantic layer. Thi
 
 **Building a single reusable chart rather than an app?** Use the `reusable-visualization` skill before writing any code. A reusable visualization runs no query of its own — the host hands it rows, a field mapping, config option values and a colour palette — so the data and filter APIs below do not apply to it. That skill is the contract for those builds and overrides this guide wherever the two differ. Everything else here (environment, components, visual design) still applies. It says nothing about light/dark mode, and silence is not an override: **following the host's colour scheme is a platform contract that applies to a reusable visualization exactly as it does to an app** — see "Visual Design".
 
+## User-facing responses
+
+The person using the data app cares about what it shows and how it behaves, not how its code is implemented. For both the first build and follow-up changes, keep progress updates and final replies concise and non-technical unless otherwise asked:
+
+- Describe the user-visible UI and behavior: what changed, where to find it, and what the user can do. Refer to controls and sections by their visible labels.
+- Do not include source filenames or paths, line references, code snippets or tokens, component or function names, or other technical implementation details unless the user explicitly asks for them. Technical context in the prompt is not itself a request for a technical explanation.
+- Explain limitations or unfinished work in terms of their effect on the app and any action the user can take, rather than exposing debugging or build details.
+
+For example: "The date filter now updates all charts on this page. Use Clear filters to return to the full view."
+
 ## Iteration mindset
 
 This pipeline is built for iteration — the user refines the app with follow-up prompts, and you have the full conversation history on every iteration. **Favor a responsive first build over upfront perfection.** Hit the core ask and ship; let the user tell you what to add.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@lightdash/cli",
-  "version": "2.305.0",
+  "version": "2.305.2",
   "description": "Lightdash CLI tool",
   "license": "MIT",
   "repository": {
@@ -22,8 +22,8 @@
     "@actions/core": "1.11.1",
     "@aws-sdk/credential-providers": "3.995.0",
     "@casl/ability": "6.8.0",
-    "@lightdash/common": "2.305.0",
-    "@lightdash/warehouses": "2.305.0",
+    "@lightdash/common": "2.305.2",
+    "@lightdash/warehouses": "2.305.2",
     "@sidvind/better-ajv-errors": "7.0.0",
     "@types/columnify": "1.5.1",
     "ajv": "8.18.0",