@overscore/cli 0.13.7 → 0.13.9

package/dist/index.js

@@ -41,10 +41,17 @@ function parseEnv(content) {
 function safeApiUrl(apiUrl) {
     try {
         const h = new URL(apiUrl).hostname;
+        // Also allow the configured hub's host — prod by default, or a staging host
+        // only if the operator set OVERSCORE_HUB_URL (a trusted, user-set env var).
+        // If OVERSCORE_HUB_URL is unset, hubHost === overscore.dev and behavior is
+        // identical to before, so real users are unaffected.
+        const hubHost = new URL(HUB_URL).hostname;
         if (h === "overscore.dev" ||
             h.endsWith(".overscore.dev") ||
             h === "localhost" ||
-            h === "127.0.0.1") {
+            h === "127.0.0.1" ||
+            h === hubHost ||
+            h.endsWith("." + hubHost)) {
             return apiUrl;
         }
     }
@@ -176,7 +183,17 @@ async function apiRequest(method, urlPath, body, command) {
         }
     }
     if (!res.ok) {
-        console.error(`\n  Error: ${data.error || `HTTP ${res.status}`}\n`);
+        const errMsg = data.error || `HTTP ${res.status}`;
+        console.error(`\n  Error: ${errMsg}\n`);
+        // The warehouse "no data connection" error is a common onboarding dead-end:
+        // a dataset-backed project has no BigQuery connection, but `query run`/`test`
+        // only hit BigQuery. Point the user at the path that actually works.
+        if (/no data connection/i.test(errMsg)) {
+            console.error("  This usually means one of two things:");
+            console.error("   • The project uses an uploaded dataset (not BigQuery). `query run`/`test` only hit");
+            console.error("     BigQuery — inspect dataset columns and sample rows with:  npm run queries");
+            console.error("   • The project should use BigQuery but no warehouse is connected yet — connect it in the Hub.\n");
+        }
         process.exit(1);
     }
     return data;
@@ -268,6 +285,10 @@ const SOURCE_EXCLUDE = new Set([
     // this baseline exclusion protects the dashboard deploy path too, regardless of
     // whether a project has a .overscoreignore.
     "data",
+    // Vendored DuckDB runtime from a local-preview workaround (public/_runtime).
+    // Production serves /_runtime from the edge; shipping ~74MB of .wasm/.js would
+    // bloat the deploy. The built-files guard in deploy() also blocks it in dist/.
+    "_runtime",
 ]);
 const SECRET_FILE_EXTENSIONS = new Set([
     ".pem",
@@ -437,6 +458,30 @@ async function deploy() {
     }
     const builtFiles = collectFiles(distDir, "");
     console.log(`  Found ${builtFiles.length} built files.`);
+    // Guard: a vendored DuckDB runtime (public/_runtime) gets copied into dist/ by
+    // Vite and would ship ~74MB of .wasm/.js that production already serves from the
+    // edge. This is a local-preview workaround that must never deploy. Fail closed
+    // unless explicitly overridden with --allow-runtime.
+    const runtimeFiles = builtFiles.filter((f) => f === "_runtime" || f.startsWith("_runtime/"));
+    if (runtimeFiles.length > 0 && !process.argv.includes("--allow-runtime")) {
+        let bytes = 0;
+        for (const f of runtimeFiles) {
+            try {
+                bytes += fs.statSync(path.join(distDir, f)).size;
+            }
+            catch {
+                // ignore unreadable entries when sizing
+            }
+        }
+        const mb = (bytes / (1024 * 1024)).toFixed(1);
+        console.error(`\n  Deploy aborted: dist/_runtime contains ${runtimeFiles.length} file(s) (${mb}MB).`);
+        console.error("  This is a vendored DuckDB runtime, usually from a public/_runtime local-preview");
+        console.error("  workaround. Production serves /_runtime from the edge, so shipping it just bloats");
+        console.error("  the deploy.");
+        console.error("\n  Fix:  rm -rf public/_runtime   (then deploy again)");
+        console.error("  Or pass --allow-runtime to deploy it anyway.\n");
+        process.exit(1);
+    }
     // Collect source files (skipped entirely with --no-source). Source is saved
     // for versioning/restore; symlinks and secrets are always excluded.
     const noSource = process.argv.includes("--no-source");
@@ -873,8 +918,8 @@ async function pull(slug) {
             process.exit(1);
         }
     }
-    const apiUrl = "https://overscore.dev/api";
-    const baseUrl = apiUrl.replace(/\/api$/, "");
+    const apiUrl = `${HUB_URL}/api`;
+    const baseUrl = HUB_URL;
     const versionQuery = versionParam ? `?version=${versionParam}` : "";
     const url = `${baseUrl}/api/dashboards/${slug}/source${versionQuery}`;
     console.log(`\n  Pulling source for: ${slug}${versionParam ? ` (v${versionParam})` : ""}...`);
@@ -925,7 +970,7 @@ async function pull(slug) {
     const envContent = `# Overscore Configuration
 VITE_OVERSCORE_PROJECT_SLUG=${projectSlug}
 VITE_OVERSCORE_DASHBOARD_SLUG=${dashboardSlug}
-VITE_OVERSCORE_API_URL=https://overscore.dev/api
+VITE_OVERSCORE_API_URL=${HUB_URL}/api
 `;
     fs.writeFileSync(path.join(targetDir, ".env"), envContent, { mode: 0o600 });
     const rulesDir = path.join(targetDir, ".claude", "rules");
@@ -1087,7 +1132,23 @@ function collectFiles(dir, prefix) {
     return files;
 }
 // ── Analysis commands ──────────────────────────────────────────────
-const HUB_URL = "https://overscore.dev";
+// Hub the CLI talks to. Defaults to production. A TRUSTED override — the
+// OVERSCORE_HUB_URL env var, set deliberately by the operator (e.g. to point at
+// a staging environment during a security audit) — can repoint it. This is
+// distinct from the project-.env override (VITE_OVERSCORE_API_URL), which stays
+// restricted by safeApiUrl() so a poisoned project can't redirect the API key +
+// bundle to an attacker host (audit L6).
+const HUB_URL = (process.env.OVERSCORE_HUB_URL || "https://overscore.dev").replace(/\/+$/, "");
+// Bare host of the hub (overscore.dev, or overscore-test.com on staging) for
+// building the {slug}.<host> URLs we print back to the user.
+const HUB_HOST = (() => {
+    try {
+        return new URL(HUB_URL).hostname;
+    }
+    catch {
+        return "overscore.dev";
+    }
+})();
 function slugify(input) {
     return input
         .toLowerCase()
@@ -1754,7 +1815,7 @@ async function analysisNew(title) {
     npx @overscore/cli analysis publish
 
   The analysis will go live at:
-    https://${data.project_slug}.overscore.dev/analysis/${data.slug}
+    https://${data.project_slug}.${HUB_HOST}/analysis/${data.slug}
 `);
 }
 function loadAnalysisMetadata() {
@@ -2347,7 +2408,7 @@ async function dev() {
         apiKey = keyData.raw_key ?? null;
     }
     catch {
-        console.error("\n  Error: Could not reach overscore.dev to create dev session key.\n");
+        console.error(`\n  Error: Could not reach ${HUB_HOST} to create dev session key.\n`);
         process.exit(1);
     }
     if (!apiKey) {
@@ -2606,7 +2667,7 @@ async function templatePull(slug) {
         ? apiSlug.slice(apiSlug.indexOf("_") + 1)
         : apiSlug;
     const targetDir = path.resolve(process.cwd(), process.argv[5] || localSlug);
-    const url = `https://overscore.dev/api/templates/${apiSlug}/source`;
+    const url = `${HUB_URL}/api/templates/${apiSlug}/source`;
     console.log(`\n  Pulling template: ${slug}...`);
     let res;
     try {
@@ -2625,7 +2686,7 @@ async function templatePull(slug) {
         });
     }
     catch {
-        console.error(`\n  Error: Could not reach overscore.dev\n`);
+        console.error(`\n  Error: Could not reach ${HUB_HOST}\n`);
         process.exit(1);
     }
     if (!res.ok) {

package/dist/template-push.js

@@ -34,7 +34,8 @@
 import fs from "fs";
 import path from "path";
 import { execSync } from "child_process";
-const HUB_URL = "https://overscore.dev";
+// Trusted operator override (e.g. staging audit); defaults to production.
+const HUB_URL = (process.env.OVERSCORE_HUB_URL || "https://overscore.dev").replace(/\/+$/, "");
 // Mirrors the templates_slug_format CHECK in the marketplace migration.
 // `_` is the handle namespace delimiter in the stored slug ({handle}_{local}).
 const TEMPLATE_SLUG_RE = /^[a-z0-9]([a-z0-9_-]*[a-z0-9])?$/;
@@ -263,7 +264,7 @@ export async function templatePush(slugArg) {
         });
     }
     catch {
-        console.error(`\n  Error: Could not reach overscore.dev\n`);
+        console.error(`\n  Error: Could not reach ${new URL(HUB_URL).hostname}\n`);
         process.exit(1);
     }
     const data = (await res.json().catch(() => ({})));
@@ -300,7 +301,8 @@ export async function templatePush(slugArg) {
     const sourceCount = sourceFiles.length;
     const listingUrl = data.detail_url
         ? `${HUB_URL}${data.detail_url}`
-        : `${HUB_URL}/explore/${slug.replace("_", "/")}`;
+        : // Mirror the hub's templateExploreUrl: /u/{handle}/{slug} (first `_` only).
+            `${HUB_URL}/u/${slug.replace("_", "/")}`;
     console.log(`
   Pushed successfully!
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@overscore/cli",
-  "version": "0.13.7",
+  "version": "0.13.9",
   "description": "CLI for deploying Overscore dashboards and publishing analyses",
   "bin": {
     "overscore": "dist/index.js"

package/skills/bind-to-my-data/SKILL.md

@@ -1,40 +0,0 @@
----
-name: bind-to-my-data
-description: Binds a pulled or forked Overscore template to the user's own warehouse by regenerating SQL against their real schema and registering it under the template's query names, turning a sample-data demo into a live dashboard. Use after pulling or forking a template, when a dashboard shows mock or sample data and the user wants their own numbers, or when the user says "connect this template to my data", "bind to my warehouse", "make this use my real data", "wire up the queries", "regenerate the queries for my schema".
----
-
-# Bind a template to your data
-
-A pulled or forked template ships design + sample data + query **names** — never the author's SQL. To go live, you regenerate SQL against the user's OWN warehouse and register it under the same names. **All SQL generation runs here, on the user's own Claude tokens;** Overscore only stores and executes the result.
-
-## Step 0 — detect state
-
-| You see… | State | Do |
-| --- | --- | --- |
-| `.overscore/template.json`, no `.env` | **unbound demo** (`template pull`) | a pulled template has no project binding and runs on baked sample data. Land it in a project first: `npx create-overscore --template <handle>/<slug>`, or fork it in the hub and then `npx @overscore/cli pull <dashboard-slug>` to get a bound copy. Then continue. |
-| `.env` with `VITE_OVERSCORE_DASHBOARD_SLUG` | **bound dashboard** (forked + pulled) | ready to bind — continue. |
-
-## Process
-
-1. **Ensure a data source exists.** The project needs either a BigQuery connection (hub → the project's **Settings** page → **Connect BigQuery**, paste a read-only service-account JSON) or a dataset. New accounts auto-seed a sample dataset; the user can also upload one. Without one of these there is nothing real to bind to.
-2. **Read the contract.** Find every query the template expects. If the template still calls `useQuery("<name>")`, grep those names. If it was already converted for publishing, the `useQuery` calls are gone — the contract now lives in `src/mockData.ts`: each `MOCK_*` export's shape, plus any `// query:` annotation naming it. If names aren't annotated, infer them from the export names and how each component consumes the array. Run `npx @overscore/cli query list` to see what's already registered (a fresh fork has none).
-3. **Inspect the real schema.** Look at the user's actual tables and columns. Design SQL that produces each query's required shape from THEIR data — explore with `npx @overscore/cli query run "<sql>"` (ad-hoc; results land in `./data` and are never deployed).
-4. **Register SQL under the SAME names.** For each query name:
-   ```bash
-   npx @overscore/cli query add <name> "<sql>"           # BigQuery-backed
-   npx @overscore/cli query add <name> --dataset <name>  # or dataset-backed
-   ```
-   The name MUST match the template's `useQuery` call exactly, or that chart stays empty.
-5. **Go live in the components.** If the template renders from `src/mockData.ts` (converted for publishing), rewire each `import { MOCK_X }` back to `const { data } = useQuery("x")`. Keep the charts and layout identical — only the data source changes.
-6. **Verify and deploy.**
-   ```bash
-   npx @overscore/cli dev                          # resolves the names against your registered SQL
-   npx @overscore/cli deploy --message "Bound <template> to my data"
-   ```
-
-## What this skill does NOT do
-
-- **It does not generate SQL on Overscore's servers.** Every query is reasoned out here, against the user's schema, on the user's own Claude tokens.
-- **It does not invent query names.** Register under the EXACT names the template references — that mapping is the contract.
-- **It does not write SQL inside React.** Queries are referenced by name via `useQuery`; the SQL lives in the registry via `query add` only.
-- **It does not need the author's queries.** Query SQL isn't registered with a template — queries live by name only — so you rebuild it from the design + names against your own data.

package/skills/regenerate-clean/SKILL.md

@@ -1,43 +0,0 @@
----
-name: regenerate-clean
-description: Converts an Overscore dashboard or pulled template into a publishable template by replacing every live query with typed synthetic mock data in src/mockData.ts, so the frozen bundle renders standalone and no real warehouse data ever ships. Use when preparing a dashboard to publish to the marketplace, when a pulled template still shows "Failed to load" or runs live queries, or when the user says "publish this as a template", "convert this to mock data", "regenerate clean", "make this template safe to share", "prep this for the marketplace".
----
-
-# Regenerate clean — convert a dashboard into a safe template
-
-Run this in a pulled template directory (or a from-scratch dashboard) to swap every live `useQuery(...)` for fresh **synthetic** mock data, so the published template renders on its own. A template carries design + sample data + query **names** — never the creator's real SQL, schema, or rows. You generate the mock data here, locally, on the user's own Claude tokens. **Overscore's servers never generate anything.**
-
-## Step 0 — detect context
-
-| You see… | You're in… | Do |
-| --- | --- | --- |
-| `.overscore/template.json` | a **pulled template** (`template pull`) | convert it in place, then `template push` |
-| `.env` with `VITE_OVERSCORE_DASHBOARD_SLUG` + live `useQuery` calls | a **live dashboard** | DON'T convert in place. Tell the user to open the dashboard's **Publish as template** modal first — for a live-data dashboard it creates a **private draft** copy. Then `npx @overscore/cli template pull <handle>/<slug>` that draft and run this skill on the copy. **Never touch the live dashboard.** |
-| `src/mockData.ts` present, no `useQuery` left | already converted | skip to Verify |
-
-The original live dashboard is never modified. If it has live queries, the rule is **convert a private copy, attest, then promote** — never push a live-data dashboard straight to public.
-
-## Process
-
-1. **Inventory the data contract.** Grep the source for every `useQuery("<name>")` call. For each, record (a) the query **name** and (b) the row **shape** the component consumes — every column key and its type. These names + shapes ARE the template's contract; preserve them exactly.
-2. **Generate synthetic data — locally, on the user's tokens.** Create `src/mockData.ts`: one exported `interface` + one exported `MOCK_<NAME>` array per query, with realistic-but-fabricated rows matching each shape (same column names, types, rough cardinality). Annotate each export with its query name, e.g. `// query: mrr_monthly` — once `useQuery` is gone (step 3) this comment is the only record of the name a consumer needs to rebind. **Scrub every real company name, customer name, and identifying number** — invent plausible substitutes.
-3. **Rewire the components.** Replace each `const { data } = useQuery("x")` with `import { MOCK_X } from "./mockData"`. Change ONLY the data source — keep every chart, metric, filter, and layout byte-for-byte identical.
-4. **Strip real data.** Delete any `data/` directory (raw query dumps) and any `fixtures/`, `dumps/`, or `exports/` holding real rows. Confirm there is no `.env*`, `*.log`, or credential file in the tree.
-5. **Self-review for inline leaks.** The publish floor rejects `data/`, `.env*`, `*.log`, and secret-named files — but it is **content-blind**. Read `src/mockData.ts` and the components and confirm no real value (a real revenue figure, a real account name) was left inline.
-
-## Verify, then publish
-
-```bash
-npx @overscore/cli dev              # renders on mock data — no API key or warehouse needed
-npm run build                       # confirm the rewire compiles
-npx @overscore/cli template push    # upload the converted bundle (slug auto-read from .overscore/template.json)
-```
-
-After push, open the listing's **Update** modal, **read** the mock-data attestation, and only then check it and set the visibility (Public / Unlisted / Private). Attestation is a truthful claim that the data is synthetic — never check it on an unconverted bundle.
-
-## What this skill does NOT do
-
-- **It does not call any Overscore server-side AI.** All synthetic data is generated here, by you, on the user's own Claude tokens. Never tell the user "Overscore will convert this for you."
-- **It does not modify the original live dashboard.** Conversion always happens on a pulled template copy.
-- **It does not attest or publish for the user.** The user reads and checks the attestation themselves after reviewing the result.
-- **It does not lean on the server strip as the strategy.** The floor is a backstop; keeping real data out of the bundle in the first place is your job.