feat(onboarding): first-run funnel telemetry

.github/meta/merge-commit.txt

@@ -0,0 +1,24 @@
+Merge origin/main into feat/AI-7520-social-signup-authorize
+
+Resolve conflicts from upstream's TUI extraction (packages/opencode/src/cli/cmd/tui
+→ packages/tui) and fork-features-as-plugins re-architecture, re-applying the
+AI-7520 CLI onboarding onto the new structure:
+
+- dialog-provider: export/reorder PROVIDER_PRIORITY (Altimate LLM Gateway first),
+  brand the gateway option, add WARNLIST + DialogAltimateAuth, harden the OAuth
+  authorize/AutoMethod UX (try/catch → toast, inline green success + auto-close)
+- dialog-model: keep the READY / NEEDS-SETUP restructure + Big Pickle, wired through
+  upstream's new DialogVariant flow; gateway leads the full list
+- use-connected + home tips: fix undefined-cost mislabeling OpenCode as connected
+- app.tsx: /connect (welcome picker), /auth (gateway), /logout (plugin command +
+  resetSetupComplete); gate the update-available dialog on onboarding readiness
+- home.tsx: render the WelcomePanel in the home_logo slot
+- provider-credentials plugin: add altimate.provider.logout
+- providers.ts: Altimate LLM Gateway first in the login picker
+- relocate altimate-onboarding + welcome-panel into packages/tui with relative imports
+
+Verified: `bun run typecheck` green in packages/tui and packages/opencode; the
+onboarding/provider/model/app-lifecycle tests pass. Pre-existing sync*.test.tsx
+failures come from origin/main's own merge (files untouched here).
+
+Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

.gitignore

@@ -41,3 +41,6 @@ tsconfig.tsbuildinfo
 **/.github/meta/pr-body-*.md
 .bridge-merge-report.md
 /data/
+
+# Rendered VHS demos — regenerable from .tape files, kept out of git
+docs/media/*.gif

docs/docs/reference/telemetry.md

@@ -47,8 +47,32 @@ We collect the following categories of events:
 | `schema_complexity` | Warehouse schema structural metrics from introspection — bucketed table, column, and schema counts plus average columns per table. No schema names or content. |
 | `validator_check` | A completion-gate validator ran on session end — validator name, `ok` boolean, step, retry count, `enforced` flag (false in shadow mode), and structured `details` (model counts, elapsed time, concurrency limit — no SQL or model content). Only emitted when `ALTIMATE_VALIDATORS_ENABLED=1` or `ALTIMATE_VALIDATORS_SHADOW=1`. See [Validators](../data-engineering/validators.md). |
 | `validator_retries_exhausted` | A session terminated with unresolved validator failures after exhausting the synthetic-retry budget — names of the failing validators (no failure body content). |
-
-Each event includes a timestamp, anonymous session ID, CLI version, and an anonymous machine ID (a random UUID stored in `~/.altimate/machine-id`, generated once and never tied to any personal information).
+| `onboarding_started` | The first-run setup gate opened (fresh launch with no usable model). |
+| `model_picker_shown` | The provider picker was displayed. `trigger` distinguishes the first run from `/connect`, from declining Big Pickle, and from the prompt gate. |
+| `provider_selected` | A provider row was chosen (`altimate_gateway`, `anthropic`, `openai`, `google`, `big_pickle`, `search_all`). Recorded at the moment of choice, so a sign-in that is then cancelled still counts. |
+| `big_pickle_confirm_shown` / `big_pickle_choice` | The Big Pickle interstitial was shown, and what the user decided (`accept`/`cancel`). |
+| `gateway_device_code_issued` | The Altimate Gateway authorize URL was built and the browser open attempted. **Name note:** the flow is a browser loopback OAuth — there is no device code. The name follows the original event spec. |
+| `gateway_auth_completed` / `gateway_auth_failed` | Gateway sign-in outcome. `reason` is `timeout`, `denied`, or `error` — never the underlying message, which can contain the instance name. An unrecognised callback state does not reject the pending attempt, so a CSRF mismatch surfaces as `timeout`. |
+| `instance_connected` | Credentials received and saved. `time_to_connect_ms` runs from the start of the authorize call, so it includes the browser launch. No instance or tenant name is sent. |
+| `onboarding_completed` | A model is ready and chat is live. |
+| `scan_gate_shown` / `scan_gate_choice` | The "scan your environment?" gate appeared, and whether the user chose `scan` or `skip`. |
+| `environment_scan_completed` | A `project_scan` finished — `has_dbt`, `has_warehouse`, `is_repo`, `connections_found`, and a bounded list of short `degraded` detection keys. No paths, hostnames, or connection details. Fires for every scan, including `/discover`, not just onboarding. |
+| `sample_setup_completed` | The sample dbt project was materialised. `success`, `models`, `tables`, and `reused` — the tool is deliberately re-callable, so this is per invocation. The target path is never sent. |
+| `activation_menu_shown` | The activation menu was (very likely) rendered. `variant` is `warehouse` or `no_data`. **Derived** — see the note below. |
+| `activation_job_selected` / `first_job_completed` | Which activation job the user started and, where observable, finished. **Derived** — see the note below. |
+| `first_prompt_sent` | The user's first typed message in an onboarding session. Slash commands are excluded, so the hidden `/onboard-connect` submission does not count. |
+| `onboarding_abandoned` | The CLI exited during a first run without connecting. `last_stage` is the furthest point reached: `started`, `model_picker`, `provider_setup`, `big_pickle_confirm`, `gateway_auth`, or `connected`. Only emitted for a genuine first run — opening `/connect` as an existing user does not enter the funnel, and abandonment after setup completes is out of scope by definition. |
+
+### A note on the derived activation events
+
+`activation_menu_shown`, `activation_job_selected`, and `first_job_completed` are **inferred, not observed**. The activation menu is not a UI element: it is text the model writes from a prompt template, and the user picks a job by replying in free text. Nothing in the CLI can see either moment directly.
+
+They are therefore inferred from the closest deterministic signals — the menu from the command dispatch or the completed environment scan, the job from the first matching tool or skill invocation that follows. Treat the counts as **lower bounds**, and note two specific gaps:
+
+- The "something else" branch has no tool signature at all and is never counted.
+- `first_job_completed` only fires for jobs with a real completion signal. Skill-driven jobs (downstream impact, SQL review, cost) load an instruction bundle and then do their work through other tools, so their completion is not observable and they are absent from this event rather than wrongly counted in it.
+
+Each event includes a timestamp, anonymous session ID, a per-launch correlation ID (`launch_id` — a random value regenerated every process start, not persisted and not derived from your machine or identity; it exists only to group events from the same run), CLI version, and an anonymous machine ID (a random UUID stored in `~/.altimate/machine-id`, generated once and never tied to any personal information).
 
 ## Delivery & Reliability
 

packages/dbt-tools/test/fixture/.user.yml

@@ -0,0 +1 @@
+id: 03b8c7b7-4b26-4408-9876-88d05b7da4f5

packages/opencode/sample-projects/jaffle-shop-duckdb/.gitignore

@@ -0,0 +1,12 @@
+# Build/run artifacts that must NOT be committed. `target/*` (not `target/`)
+# so the re-include below actually works — git ignores the CONTENTS of target/
+# individually, then lets us un-ignore the one pre-compiled artifact we ship.
+# Using `target/` here would exclude the directory as a whole and make the
+# `!target/manifest.json` line inert (git will not descend into an ignored
+# directory to re-include children).
+target/*
+!target/manifest.json
+
+dbt_packages/
+logs/
+.user.yml

packages/opencode/sample-projects/jaffle-shop-duckdb/README.md

@@ -0,0 +1,55 @@
+# Jaffle Shop — altimate-code starter sample
+
+Everything below runs against a local DuckDB file — no cloud warehouse, no
+credentials, no network calls.
+
+## What's in here
+
+```
+dbt_project.yml         dbt project config
+profiles.yml            DuckDB profile — path is project-relative
+sample-manifest.json    version metadata used by altimate-code to detect
+                        stale copies on upgrade
+models/
+  staging/
+    stg_customers.sql   renames raw customer columns to snake_case
+    stg_orders.sql      renames raw order columns
+    schema.yml          column descriptions + unique/not_null tests
+  marts/
+    customers.sql       one row per customer, joins in order counts
+    orders.sql          one row per order, joins in customer names
+    schema.yml          column descriptions + tests + relationships
+seeds/
+  raw_customers.csv     3 rows of test data
+  raw_orders.csv        4 rows of test data
+target/
+  manifest.json         PRE-COMPILED dbt manifest — ships with the sample so
+                        altimate-code's static workflows (/discover, /review)
+                        work without dbt-core / dbt-duckdb installed
+```
+
+## What to try (works with zero external tools)
+
+- `/discover stg_customers` — walk the DAG and see what depends on this model
+- `/review models/marts/customers.sql` — run the reviewer against a mart model
+- Open any `.sql` file and ask altimate-code to explain the transformation
+- Ask altimate-code "what tests would you recommend for `orders`?"
+
+## What to try (needs `dbt-core` + `dbt-duckdb` installed)
+
+```bash
+pip install dbt-duckdb
+cd ~/altimate-sample-dbt         # or wherever you materialized the sample
+dbt seed                          # load the CSVs into DuckDB
+dbt build                         # run models + tests
+duckdb target/jaffle.duckdb -c 'select * from customers'
+```
+
+Once `dbt-duckdb` is on your `$PATH`, altimate-code detects it automatically
+and the "run" workflows appear in `/help`.
+
+## Bringing your own project
+
+When you're ready to switch to your real dbt project, `cd` into it and run
+altimate-code again. The scan will pick up your `dbt_project.yml` and offer
+to connect its warehouse.

packages/opencode/sample-projects/jaffle-shop-duckdb/dbt_project.yml

@@ -0,0 +1,16 @@
+name: "jaffle_shop"
+version: "1.0.0"
+
+profile: "jaffle_shop"
+
+model-paths: ["models"]
+seed-paths: ["seeds"]
+target-path: "target"
+clean-targets: ["target", "dbt_packages"]
+
+models:
+  jaffle_shop:
+    staging:
+      +materialized: view
+    marts:
+      +materialized: table

packages/opencode/sample-projects/jaffle-shop-duckdb/models/marts/customers.sql

@@ -0,0 +1,9 @@
+select
+    c.customer_id,
+    c.first_name,
+    c.last_name,
+    count(o.order_id) as order_count,
+    coalesce(sum(o.amount), 0) as total_amount
+from {{ ref('stg_customers') }} c
+left join {{ ref('stg_orders') }} o on c.customer_id = o.customer_id
+group by c.customer_id, c.first_name, c.last_name

packages/opencode/sample-projects/jaffle-shop-duckdb/models/marts/orders.sql

@@ -0,0 +1,8 @@
+select
+    o.order_id,
+    o.customer_id,
+    c.first_name || ' ' || c.last_name as customer_name,
+    o.order_date,
+    o.amount
+from {{ ref('stg_orders') }} o
+join {{ ref('stg_customers') }} c on o.customer_id = c.customer_id

packages/opencode/sample-projects/jaffle-shop-duckdb/models/marts/schema.yml

@@ -0,0 +1,32 @@
+version: 2
+
+models:
+  - name: customers
+    description: One row per customer with total order count and revenue.
+    columns:
+      - name: customer_id
+        description: Primary key.
+        data_tests:
+          - unique
+          - not_null
+      - name: order_count
+        description: Number of orders placed by the customer (0 when none).
+        data_tests:
+          - not_null
+      - name: total_amount
+        description: Sum of all order amounts (0 when none).
+        data_tests:
+          - not_null
+
+  - name: orders
+    description: One row per order with a joined customer name.
+    columns:
+      - name: order_id
+        description: Primary key.
+        data_tests:
+          - unique
+          - not_null
+      - name: customer_id
+        description: Foreign key to `stg_customers`.
+        data_tests:
+          - not_null

packages/opencode/sample-projects/jaffle-shop-duckdb/models/staging/schema.yml

@@ -0,0 +1,27 @@
+version: 2
+
+models:
+  - name: stg_customers
+    description: Renamed customer columns from the raw seed.
+    columns:
+      - name: customer_id
+        description: Primary key of the customer.
+        data_tests:
+          - unique
+          - not_null
+
+  - name: stg_orders
+    description: Renamed order columns from the raw seed.
+    columns:
+      - name: order_id
+        description: Primary key of the order.
+        data_tests:
+          - unique
+          - not_null
+      - name: customer_id
+        description: Foreign key to `stg_customers`.
+        data_tests:
+          - not_null
+          - relationships:
+              to: ref('stg_customers')
+              field: customer_id

packages/opencode/sample-projects/jaffle-shop-duckdb/models/staging/stg_customers.sql

@@ -0,0 +1,5 @@
+select
+    id as customer_id,
+    first_name,
+    last_name
+from {{ ref('raw_customers') }}

packages/opencode/sample-projects/jaffle-shop-duckdb/models/staging/stg_orders.sql

@@ -0,0 +1,6 @@
+select
+    id as order_id,
+    customer_id,
+    order_date,
+    amount
+from {{ ref('raw_orders') }}

packages/opencode/sample-projects/jaffle-shop-duckdb/profiles.yml

@@ -0,0 +1,14 @@
+# DuckDB profile — everything runs locally against a single file at
+# `target/jaffle.duckdb` (created on first `dbt build`). No cloud credentials.
+# `path:` is unqualified, so dbt-duckdb resolves it against the PROCESS
+# working directory at build time — NOT the project directory. Run
+# `dbt build` from the materialized sample dir (`cd <sample-path>`) and
+# the database lands at `<sample-path>/target/jaffle.duckdb`.
+# Run it from anywhere else and dbt writes to `$PWD/target/jaffle.duckdb`.
+jaffle_shop:
+  target: dev
+  outputs:
+    dev:
+      type: duckdb
+      path: "target/jaffle.duckdb"
+      threads: 1

packages/opencode/sample-projects/jaffle-shop-duckdb/sample-manifest.json

@@ -0,0 +1,16 @@
+{
+  "$comment": "Metadata about this sample project. Distinct from dbt's target/manifest.json — this is our own version stamp for conflict detection on the materialized copy at ~/altimate-sample-dbt/. If you edit any source file below, run ./regenerate.sh and commit the refreshed target/manifest.json alongside your change.",
+  "name": "jaffle-shop-duckdb",
+  "version": "1.0.0",
+  "kind": "altimate-starter-sample",
+  "source": "packages/opencode/sample-projects/jaffle-shop-duckdb",
+  "requires": {
+    "dbt-core": ">=1.7 <2.0",
+    "dbt-duckdb": ">=1.7 <2.0"
+  },
+  "notes": [
+    "Renamed profile from the original test fixture: `test_jaffle_shop` → `jaffle_shop`.",
+    "DuckDB target file resolves project-relative at `target/jaffle.duckdb`; no host paths bake into the profile.",
+    "target/manifest.json ships pre-compiled so static workflows (/discover, /review) work without dbt installed."
+  ]
+}

packages/opencode/sample-projects/jaffle-shop-duckdb/seeds/raw_customers.csv

@@ -0,0 +1,4 @@
+id,first_name,last_name
+1,Alice,Smith
+2,Bob,Jones
+3,Carol,White

packages/opencode/sample-projects/jaffle-shop-duckdb/seeds/raw_orders.csv

@@ -0,0 +1,5 @@
+id,customer_id,order_date,amount
+1,1,2024-01-15,100
+2,1,2024-02-20,200
+3,2,2024-01-10,150
+4,3,2024-03-05,300