@@ -45,6 +45,7 @@ import {
   useSetupComplete,
   markFirstRunActive,
   resetSetupComplete,
+  useFirstRunOpenedThisLaunch,
 } from "./component/altimate-onboarding"
 // altimate_change end
 // altimate_change — Part 2 scan gate (fires once when Part 1 first completes)
@@ -607,6 +608,9 @@ function App(props: { onSnapshot?: () => Promise<string[]>; pluginHost: TuiPlugi
   const onboardingReady = useReady()
   // altimate_change — setup completion alone (no `connected()` term); see the scan-gate effect
   const setupComplete = useSetupComplete()
+  // altimate_change — cubic review (3986532221): see `firstRunOpenedThisLaunch`'s declaration in
+  // altimate-onboarding.tsx
+  const firstRunOpenedThisLaunch = useFirstRunOpenedThisLaunch()
   // altimate_change — onboarding funnel tracker (no-op when the host injected none)
   const trackOnboarding = useOnboardingTelemetry()
   // altimate_change end
@@ -729,17 +733,27 @@ function App(props: { onSnapshot?: () => Promise<string[]>; pluginHost: TuiPlugi
     // hits the picker again on their next submit and loses whatever they typed. See
     // `hasUsableFreeDefault`'s declaration in local.tsx for where the fold now lives.
     // altimate_change start — Kilo review round 6 (3986171188): `shouldSkipOnboardingAtStartup`
-    // — see its declaration in local.tsx — added the `setupComplete()` discriminator. Without it,
-    // an impatient first-run user who submits before this effect settles — the prompt gate
-    // (component/prompt/index.tsx) opens the picker on its own, they pick a free Zen model,
-    // `set()` marks it explicit/recent and `markSetupComplete()` runs — made
-    // `hasUsableFreeDefault()` true by the time THIS effect finally runs, latching here and
-    // returning before the `onboardingReady()` branch below (which exists for exactly this
+    // — see its declaration in local.tsx — added a discriminator for "did first-run genuinely
+    // complete THIS launch". Without it, an impatient first-run user who submits before this
+    // effect settles — the prompt gate (component/prompt/index.tsx) opens the picker on its own,
+    // they pick a free Zen model, `set()` marks it explicit/recent and `markSetupComplete()` runs
+    // — made `hasUsableFreeDefault()` true by the time THIS effect finally runs, latching here
+    // and returning before the `onboardingReady()` branch below (which exists for exactly this
     // impatient-user case, per its own comment) ever got a chance to fire the funnel telemetry
-    // and `openScanGate()`. A genuine RETURNING user's `setupComplete()` is always false here —
-    // it starts false every launch and is set only by a setup completed DURING this one (see the
-    // comment on the `onboardingReady()` branch) — so this changes nothing for that case; it only
-    // stops THIS branch from swallowing a same-launch setup that `onboardingReady()` needs to see.
+    // and `openScanGate()`.
+    //
+    // cubic review (3986532221): a bare `setupComplete()` is NOT that discriminator — it is a
+    // global flag `markSetupComplete()` sets for ANY model selection, first-run or not, so a
+    // RETURNING user (`hasExistingLegacySelection()` or `hasUsableFreeDefault()` already true)
+    // who does an ordinary `/model` switch while this effect is still settling ALSO makes
+    // `setupComplete()` true — which used to fall through to the `onboardingReady()` branch and
+    // fire onboarding telemetry + open the scan gate for a routine model change, not a first run.
+    // `firstRunOpenedThisLaunch()` (see its declaration in altimate-onboarding.tsx) is the fix: a
+    // one-way latch set only when the first-run picker itself actually opened THIS launch (this
+    // effect's own fallthrough below, or the prompt gate's equivalent) — `setupComplete() &&
+    // firstRunOpenedThisLaunch()` is true only for a GENUINE first-run completion. A returning
+    // user's routine switch never sets `firstRunOpenedThisLaunch()`, so it correctly reads false
+    // and this branch keeps skipping for them, exactly as before this whole discriminator existed.
     // A paid pick is unaffected either way: `hasUsableFreeDefault()` requires a free model, so it
     // was never true for one.
     if (
@@ -750,7 +764,7 @@ function App(props: { onSnapshot?: () => Promise<string[]>; pluginHost: TuiPlugi
         // early above unless `kv.ready`, so it is always a plain boolean by the time it runs
         // here; the explicit check just satisfies the union type without widening it elsewhere.
         local.model.hasUsableFreeDefault() === true,
-        setupComplete(),
+        setupComplete() && firstRunOpenedThisLaunch(),
       )
     ) {
       startupDecisionHandled = true
 
@@ -35,8 +35,33 @@ const [setupComplete, setSetupComplete] = createSignal(false)
 // model switching, so it consults this before emitting any funnel event — otherwise every model
 // change for the life of the product would look like an onboarding provider choice.
 const [firstRunActive, setFirstRunActive] = createSignal(false)
+// altimate_change start — cubic review (3986532221): app.tsx's startup effect used
+// `setupComplete()` alone to decide whether THIS launch's model selection is a genuine
+// first-run/impatient-picker completion (worth firing onboarding telemetry + the scan gate for)
+// versus a RETURNING user's ordinary `/model` switch that merely raced the startup effect —
+// `markSetupComplete()` fires for BOTH cases identically. `firstRunActive` above cannot answer
+// this either: `markSetupComplete()` deliberately CLEARS it (so a later routine switch doesn't
+// look like onboarding), so by the time app.tsx's effect gets around to checking it, it has
+// already been reset to `false` for both a genuine first-run AND the very completion that would
+// prove it happened. `firstRunOpenedThisLaunch` is a separate, ONE-WAY latch: set whenever the
+// first-run picker actually opens THIS launch — either app.tsx's own startup fallthrough, or the
+// prompt gate's equivalent for an impatient submit before that effect settles (see
+// `component/prompt/index.tsx`'s `markFirstRunActive()` call) — and never cleared by
+// `markSetupComplete()`/`clearFirstRunActive()` (only by `resetSetupComplete()`, on `/logout`,
+// which returns the user to a genuinely fresh state). `setupComplete() &&
+// firstRunOpenedThisLaunch()` is the correct "did first-run genuinely complete this launch"
+// signal; a returning user's routine mid-race `/model` switch has `setupComplete() === true` but
+// `firstRunOpenedThisLaunch() === false`, so it reads as `false` and no longer fires anything.
+const [firstRunOpenedThisLaunch, setFirstRunOpenedThisLaunch] = createSignal(false)
+export function useFirstRunOpenedThisLaunch() {
+  return firstRunOpenedThisLaunch
+}
+// altimate_change end
 export function markFirstRunActive() {
   setFirstRunActive(true)
+  // altimate_change — see `firstRunOpenedThisLaunch`'s declaration above
+  setFirstRunOpenedThisLaunch(true)
+  // altimate_change end
 }
 /**
  * Clear without marking setup complete.
@@ -65,6 +90,10 @@ export function markSetupComplete() {
 export function resetSetupComplete() {
   setSetupComplete(false)
   setFirstRunActive(false)
+  // altimate_change — see `firstRunOpenedThisLaunch`'s declaration above: /logout returns the
+  // user to a genuinely fresh state, so a first run after it must be free to latch again.
+  setFirstRunOpenedThisLaunch(false)
+  // altimate_change end
 }
 export function useReady() {
   const connected = useConnected()
 
@@ -48,7 +48,7 @@ import { useDialog } from "../../ui/dialog"
 import { DialogProvider as DialogProviderConnect, WARNLIST } from "../dialog-provider"
 // altimate_change — first-run submit gate: open the curated welcome picker instead
 // of erroring when no model is ready yet (see altimate-onboarding.tsx).
-import { DialogModelWelcome, useReady, useReadyPending } from "../altimate-onboarding"
+import { DialogModelWelcome, markFirstRunActive, useReady, useReadyPending } from "../altimate-onboarding"
 import { DialogAlert } from "../../ui/dialog-alert"
 import { useToast } from "../../ui/toast"
 import { useKV } from "../../context/kv"
@@ -1103,6 +1103,13 @@ export function Prompt(props: PromptProps) {
         deferredSubmit = true
         return false
       }
+      // altimate_change — cubic review (3986532221): this is the prompt-gate's own equivalent of
+      // app.tsx's first-run picker (an impatient submit before that startup effect settled), so
+      // it must latch the SAME "first-run opened this launch" signal — see
+      // `firstRunOpenedThisLaunch`'s declaration in altimate-onboarding.tsx for why app.tsx's
+      // startup effect needs this to tell a genuine first-run completion apart from a returning
+      // user's routine `/model` switch racing that same effect.
+      markFirstRunActive()
       dialog.replace(() => (
         <DialogModelWelcome
           intro="First, let's connect your AI model — then I'll get right on that."
 
@@ -1,4 +1,14 @@
 import { expect, test } from "bun:test"
+// altimate_change — cubic review (3986532221): the real, module-level onboarding signals, to
+// test the app.tsx call site's discriminator computation against the ACTUAL production functions
+// rather than only the pure `shouldSkipOnboardingAtStartup` predicate in isolation.
+import {
+  markFirstRunActive,
+  markSetupComplete,
+  resetSetupComplete,
+  useFirstRunOpenedThisLaunch,
+  useSetupComplete,
+} from "../../src/component/altimate-onboarding"
 import {
   allowsManagedBaseDefault,
   ALTIMATE_BASE_MODEL,
@@ -371,6 +381,63 @@ test("shouldSkipOnboardingAtStartup: a same-launch setup must not swallow the on
 })
 // altimate_change end
 
+// altimate_change start — cubic review (3986532221): the fix above still passed a bare
+// `setupComplete()` at the app.tsx call site, which is a GLOBAL flag `markSetupComplete()` sets
+// for ANY model selection, not only a first-run one. A RETURNING user (existing
+// legacy/free-default selection) who does an ordinary `/model` switch while app.tsx's startup
+// effect is still settling made `setupComplete()` true too, which used to fall through to the
+// `onboardingReady()` branch and fire `onboarding_started`/`onboarding_completed`/
+// `scan_gate_shown` telemetry plus `openScanGate()` for a routine model change — not a first run.
+// `firstRunOpenedThisLaunch()` (altimate-onboarding.tsx) is a one-way latch set only when the
+// first-run picker itself actually opens THIS launch (app.tsx's own fallthrough, or the prompt
+// gate's equivalent in component/prompt/index.tsx); `setupComplete() && firstRunOpenedThisLaunch()`
+// — what app.tsx now actually passes — is the correct "did first-run genuinely complete this
+// launch" signal. These tests exercise the REAL production signals (not synthetic booleans),
+// asserting `shouldSkipOnboardingAtStartup` receives the correctly-computed discriminator: `skip
+// === true` means app.tsx's startup effect returns BEFORE ever reaching the telemetry/scan-gate
+// branch, so it is the direct proxy for "no onboarding telemetry, no scan gate" at this call site.
+test("a returning user's routine /model switch during the startup race window fires no onboarding telemetry or scan gate", () => {
+  resetSetupComplete()
+  try {
+    // Returning user: has an existing legacy/free-default selection (`hasExistingLegacySelection`
+    // true below). They switch models via an ORDINARY `/model` pick — NOT through the first-run
+    // picker — while app.tsx's startup effect is still settling. `markSetupComplete()` fires for
+    // this exactly as it does for every model pick, first-run or not.
+    markSetupComplete()
+    const setupComplete = useSetupComplete()
+    const firstRunOpenedThisLaunch = useFirstRunOpenedThisLaunch()
+    expect(setupComplete()).toBe(true)
+    expect(firstRunOpenedThisLaunch()).toBe(false)
+
+    // Mirrors app.tsx's actual call site exactly.
+    const skip = shouldSkipOnboardingAtStartup(true, false, setupComplete() && firstRunOpenedThisLaunch())
+    expect(skip).toBe(true)
+  } finally {
+    resetSetupComplete()
+  }
+})
+
+test("a genuine impatient first-run completion (the prompt gate opened this launch) still fires the onboardingReady() branch", () => {
+  resetSetupComplete()
+  try {
+    // The prompt gate (component/prompt/index.tsx's `!ready()` branch) — or app.tsx's own
+    // startup fallthrough — actually opened the first-run picker THIS launch...
+    markFirstRunActive()
+    // ...and the user picked a free model there, completing it.
+    markSetupComplete()
+    const setupComplete = useSetupComplete()
+    const firstRunOpenedThisLaunch = useFirstRunOpenedThisLaunch()
+    expect(setupComplete()).toBe(true)
+    expect(firstRunOpenedThisLaunch()).toBe(true)
+
+    const skip = shouldSkipOnboardingAtStartup(false, true, setupComplete() && firstRunOpenedThisLaunch())
+    expect(skip).toBe(false)
+  } finally {
+    resetSetupComplete()
+  }
+})
+// altimate_change end
+
 // altimate_change start — PR #1302 Codex review round 2, P2: `migrateLegacyDefault({ from })`'s
 // captured `from` must not bypass free-model validation entirely.
 test("isMigrationStillEligibleAfterCapture: only the launch-default-unchanged or registration-induced-Base transitions stay eligible", () => {