@overscore/cli 0.13.10 → 0.13.12

package/dist/index.js

@@ -431,6 +431,9 @@ function extractZip(zipBuffer, targetDir) {
 }
 // ── Commands ────────────────────────────────────────────────────────
 async function deploy() {
+    // Refuse to deploy to the wrong hub (e.g. a staging dashboard to prod because
+    // OVERSCORE_HUB_URL wasn't set). Runs before loadEnv so it fails fast.
+    assertHubMatchesEnv();
     const { apiUrl, apiKey, dashboardSlug } = await loadEnv();
     // Parse --message flag
     const msgIndex = process.argv.indexOf("--message");
@@ -572,10 +575,32 @@ async function deploy() {
     // Pull latest platform rules so the local project stays up to date
     await syncPlatformRules(process.cwd(), baseUrl, apiKey);
 }
+/**
+ * Print the project's warehouse-connection status. A live connection (e.g.
+ * BigQuery) can exist with ZERO registered queries — so this is surfaced
+ * independently of the query list. Without it, an empty query list reads as
+ * "no warehouse here" even when one is wired and queryable via `query run`.
+ */
+function printConnection(connection) {
+    if (!connection)
+        return;
+    if (connection.connected) {
+        const label = connection.type === "bigquery" ? "BigQuery" : connection.type ?? "warehouse";
+        const where = connection.gcp_project_id ? ` — GCP project: ${connection.gcp_project_id}` : "";
+        console.log(`  Data connection: ${label} connected${where}`);
+        console.log(`    A live warehouse is wired up. Explore it with: npx @overscore/cli query run "<sql>"`);
+        console.log(`    Then register the metrics you want: npx @overscore/cli query add <name> "<sql>"\n`);
+    }
+    else {
+        console.log(`  Data connection: none (uploaded datasets only — no warehouse connected)\n`);
+    }
+}
 async function queryList() {
     const { dashboardSlug } = await loadEnv();
     const data = (await apiRequest("GET", `/api/dashboards/${dashboardSlug}/queries`, undefined, "query-list"));
     console.log(`\n  Dashboard: ${data.dashboard}\n`);
+    // Warehouse connection status (independent of registered queries)
+    printConnection(data.connection);
     // Registered queries
     if (data.queries.length === 0) {
         console.log("  No queries registered yet.\n");
@@ -1155,6 +1180,46 @@ const HUB_HOST = (() => {
         return "overscore.dev";
     }
 })();
+/**
+ * Fail fast on a hub mismatch. A dashboard's .env names the hub it belongs to
+ * (VITE_OVERSCORE_API_URL), but credentialed CLI ops (key minting, deploy
+ * upload) target HUB_URL — which only repoints at staging when the operator
+ * sets OVERSCORE_HUB_URL. When the .env names a different host than HUB_URL, the
+ * CLI silently falls back to prod (safeApiUrl, audit L6) and mints a key /
+ * deploys to the WRONG hub, surfacing later as a baffling "Invalid API key" in
+ * the browser. We do NOT trust the .env host for anything credentialed — we
+ * just detect the mismatch and tell the user which env var to set. Localhost
+ * dashboards are dev-only and always fine.
+ */
+function assertHubMatchesEnv() {
+    const envPath = path.resolve(process.cwd(), ".env");
+    if (!fs.existsSync(envPath))
+        return;
+    const envApiUrl = parseEnv(fs.readFileSync(envPath, "utf-8")).VITE_OVERSCORE_API_URL;
+    if (!envApiUrl)
+        return;
+    let envHost;
+    try {
+        envHost = new URL(envApiUrl).hostname;
+    }
+    catch {
+        return;
+    }
+    if (envHost === "localhost" || envHost === "127.0.0.1" || envHost === HUB_HOST)
+        return;
+    const envBase = envApiUrl.replace(/\/api\/?$/, "").replace(/\/+$/, "");
+    console.error(`
+  Error: this dashboard targets ${envHost}, but the CLI is pointed at ${HUB_HOST}.
+
+  Credentialed commands won't authenticate against ${envHost} until you point the
+  CLI there. Set this in your shell first, then re-run:
+
+    export OVERSCORE_HUB_URL=${envBase}
+
+  (Add it to ~/.zshrc to make it stick. A new terminal without it goes back to prod.)
+`);
+    process.exit(1);
+}
 function slugify(input) {
     return input
         .toLowerCase()
@@ -2375,6 +2440,10 @@ async function dev() {
         console.error("\n  Error: VITE_OVERSCORE_PROJECT_SLUG not set in .env.\n");
         process.exit(1);
     }
+    // Stop now if the dashboard's hub doesn't match where the CLI is pointed —
+    // otherwise we'd mint a key against the wrong hub and the browser would get
+    // "Invalid API key".
+    assertHubMatchesEnv();
     // Get device token from global config
     const configPath = path.join(process.env.HOME || "", ".overscore", "config");
     if (!fs.existsSync(configPath)) {

package/package.json

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

package/templates/analysis/.claude/CLAUDE.md

@@ -24,6 +24,13 @@ Every meaningful exploration step in the log is a new entry: the question being
 
 ## How to run BigQuery queries
 
+This project has a **live BigQuery connection** — the credentials live in the Hub and `query run` executes against your real warehouse. You don't need to "find" or "set up" a connection: if `query run` returns rows, the warehouse is wired and working. If you're unsure what's in it, discover the schema directly rather than assuming there's no data:
+
+```bash
+# list datasets/tables you can reach
+npx @overscore/cli query run "SELECT table_schema, table_name FROM \`<gcp_project>\`.region-us.INFORMATION_SCHEMA.TABLES LIMIT 200"
+```
+
 Use the Overscore CLI to run SQL against the project's BigQuery connection:
 
 ```bash

package/templates/analysis/.claude/skills/start-analysis/SKILL.md

@@ -33,7 +33,7 @@ Ask these one or two at a time conversationally — don't dump all 7 at once lik
 
 ## After the interview
 
-1. **Read `.claude/knowledge/INDEX.md`** and any relevant knowledge files to understand what previous sessions have already documented about this project's data. Cross-reference what the user said against what's already known.
+1. **Read `.claude/knowledge/INDEX.md`** and any relevant knowledge files to understand what previous sessions have already documented about this project's data. Cross-reference what the user said against what's already known. An empty knowledge base does NOT mean there's no data — this project has a **live BigQuery connection**. If neither the user nor the knowledge base names the tables, your first approved query can be an `INFORMATION_SCHEMA.TABLES` discovery pass (see CLAUDE.md); never conclude "there's no warehouse/no data" without actually querying it.
 
 2. **Write `this-analysis.md` immediately** — before proposing a query plan. Fill in every section:
    - **Question** — the clarified question, not the original title