Found during the v0.11.1 release review (Tech Lead persona). Deferred because: decoupling fresh-install detection from the TUI welcome flow is more than a quick fix.
startup_ready.fresh_install is set only when track() observes a non-upgrade first_launch event (packages/opencode/src/altimate/telemetry/index.ts), and first_launch is only tracked from packages/opencode/src/cli/welcome.ts, which is TUI-only onboarding. serve and run never go through it, so a brand-new machine's first altimate serve or altimate run always reports fresh_install: false.
Those are exactly the entry points the v0.11.0 first-run freeze hit, and the "startup time by command, fresh vs returning" KQL in docs/internal/first-run-telemetry.md will mis-bucket every fresh headless install.
Suggested fix. Derive fresh_install from the install marker / machine-id probe directly (the same signal first_launch uses), independent of which command consumed it, or emit first_launch from the CLI middleware for every command.
Found during the v0.11.1 release review (Tech Lead persona). Deferred because: decoupling fresh-install detection from the TUI welcome flow is more than a quick fix.
startup_ready.fresh_installis set only whentrack()observes a non-upgradefirst_launchevent (packages/opencode/src/altimate/telemetry/index.ts), andfirst_launchis only tracked frompackages/opencode/src/cli/welcome.ts, which is TUI-only onboarding.serveandrunnever go through it, so a brand-new machine's firstaltimate serveoraltimate runalways reportsfresh_install: false.Those are exactly the entry points the v0.11.0 first-run freeze hit, and the "startup time by command, fresh vs returning" KQL in
docs/internal/first-run-telemetry.mdwill mis-bucket every fresh headless install.Suggested fix. Derive
fresh_installfrom the install marker / machine-id probe directly (the same signalfirst_launchuses), independent of which command consumed it, or emitfirst_launchfrom the CLI middleware for every command.