Problem
The new first-run onboarding flow has no telemetry. We can't tell how many people who open the CLI for the first time get as far as a working model, where they drop out, which provider they pick, or whether they reach the activation step.
Proposal
A consistent event taxonomy for the whole first-run flow, emitted from where each thing actually happens:
- First run and provider choice (TUI) — the setup gate opening, the picker being shown, which provider was chosen, the Big Pickle interstitial and its outcome
- Gateway auth — authorize started, completed or failed with a classified reason, and the instance connecting
- Scan gate — shown, and the user's choice
- Environment scan — what the scan found, as counts and booleans
- Activation — the menu, the job chosen, the first job completed, the first typed prompt
- Drop-off — abandoned, with the furthest stage reached
Counts, booleans and closed enums only. No warehouse or tenant names, file paths, or credential material.
Complications worth knowing up front
The TUI renders on the process main thread while the server runs in a Worker, and each holds its own telemetry state — so events span two module instances with separate buffers, and neither exit path currently flushes.
packages/tui also can't import the telemetry module, so TUI-side events need a seam from the host.
The activation menu isn't UI — it's text the model writes from a prompt template, and the user replies in free text. Those events can only be inferred from proxies, and should be labelled as lower bounds rather than presented as observations.
Problem
The new first-run onboarding flow has no telemetry. We can't tell how many people who open the CLI for the first time get as far as a working model, where they drop out, which provider they pick, or whether they reach the activation step.
Proposal
A consistent event taxonomy for the whole first-run flow, emitted from where each thing actually happens:
Counts, booleans and closed enums only. No warehouse or tenant names, file paths, or credential material.
Complications worth knowing up front
The TUI renders on the process main thread while the server runs in a Worker, and each holds its own telemetry state — so events span two module instances with separate buffers, and neither exit path currently flushes.
packages/tuialso can't import the telemetry module, so TUI-side events need a seam from the host.The activation menu isn't UI — it's text the model writes from a prompt template, and the user replies in free text. Those events can only be inferred from proxies, and should be labelled as lower bounds rather than presented as observations.