Speed up the Welcome kickoff and show the team arriving

[morgmart]

Why

Landing on the Welcome channel meant staring at an empty room. The kickoff had a deliberate delay before it started, the closer dragged, and the whole thing gave no sign it was working — so a new user's first impression of Buzz was silence, and a failed kickoff looked exactly like a slow one.

The new-user sequence

Before: onboarding ends → brief blank → empty Welcome channel → (eventually) Fizz speaks, or doesn't, with no way to tell which you're in.

After: onboarding's last screen stays up as a curtain while the app mounts behind it → it fades to reveal Welcome with the starter team already on the composer banner → Fizz greets you by name → teammates introduce themselves in-thread → Fizz closes with the CTA.

What's in it

• No kickoff landing delay — the choreography starts immediately; the closer's beat is tightened.
• Direct handoff from onboarding to Welcome. The onboarding screen holds as an opaque curtain while the app mounts underneath on the Welcome route, then fades once Welcome reports its first settled render (with a safety timeout so a slow load can't strand anyone). No flash of empty app.
• A loading stage on the composer banner — the starter team characters stand there while setup is genuinely in progress, so the wait reads as activity rather than silence.
• Fizz greets the new user by name.
• The opener's thread is watched directly, so teammate intros are seen without the user opening the thread.

Failure states

Situation	What the user sees
No AI provider configured	Fizz explains, points at Settings ✅
Honey & Bumble never come online	Fizz greets solo, self-contained opener ✅
Agent spawns but requirements fail	The agent itself posts a setup nudge ✅
Fizz dead / relay down / rate-limited	Silent — but degrades to an ordinary, usable empty channel ⚠️

That last row is the honest gap. The stage waits 90s, then the characters exit and the banner reverts to its normal mention hint — so a failed kickoff stops claiming a team is coming, but it can't say why. It's driven purely by "is the timeline empty" plus a timer; it never reads real kickoff state, so it can't tell "Fizz crashed" from "the relay is slow."

Explaining the cause is deliberately out of scope here and tracked in docs/welcome-kickoff-silent-failures.md, which this PR updates to reflect that the perception gap is now handled while the silent paths themselves are not.

Review findings addressed

Three issues found in self-review and fixed in c887e34a:

1. The timeout didn't resolve anything. timed-out rendered identically to active — the banner kept promising a team was being set up, forever. Now timed-out exits, and a terminal done phase keeps a finished stage from re-entering active off the still-empty timeline and looping the characters.
2. Teammate intros are thread replies, which never reach the main timeline (non-broadcast replies are filtered out). Extracted mergeKickoffEvents so the closer's classification sees them without the user opening the thread — pinned by a test that fails against the old behavior.
3. The opener thread query refetched forever on every Welcome revisit (staleTime: 0). Latched off once the closer marker exists.

Merge with main

main moved 13 commits during this work, 5 of them onboarding PRs touching the same screens (#2048, #2055, #2056, #2058). Merged in 07144e95 — four conflicts, resolved in favor of main wherever it had made a deliberate choice this branch hadn't:

• Main's new WelcomeSetup back button was grafted onto this branch's relocated render, so it survives the restructure.
• Main relocated the stage-flag declaration to feed its new autofocus effect; the entering stage was grafted onto it. Without that, the step chrome would unmount and the shell would snap alignment the instant the curtain began — a visible jump before the fade.
• Main's onboarding shell layout taken wholesale (h-dvh, per-stage alignment, pb-36). This branch never intended spacing polish there; main's ramp wins.

Testing

• Gates green on the merged tree: typecheck, biome lint, px-text guard, 3140/3140 desktop tests (+7 new here), plus rust, mobile, and tauri suites via pre-push.
• New unit coverage on the stage phase machine (timeout resolves, done is terminal, banner never claims setup once resolved) and on mergeKickoffEvents.

Not verified by hand: the app was not run manually for this change. Verification is automated gates plus code reading. In particular the 90s timeout path has no eyes-on confirmation — it's covered by unit tests on the phase logic, not by watching it happen.

🤖 Generated with Claude Code

[wesbillman]

Reviewed the full diff against merge-base (79598bd — one commit behind main, no overlap with #2050). Approving.

What holds up well:

• The stage phase machine is sound: done is terminal and checked before isWelcome so a momentary non-Welcome read can't launder it back to hidden; the timeout genuinely resolves; all pinned by the new unit tests.
• The per-channel latch on the opener-thread query correctly escapes the self-referential trap (retiring drops the very evidence that justified retiring) — the comment explains it and the code matches.
• mergeKickoffEvents fixes a real bug (thread-reply intros invisible to the closer classification) and the dedup handles the legitimate overlap between live subscription and open-thread feed.
• The App.tsx restructure preserves boot semantics — transaction → needsSetup → error → applied-gate ordering is unchanged, and keeping the flow in one stable tree slot across the finalizing→entering flip avoids the remount restart.
• Edge cases covered: reduced-motion keeps a 1ms animation (so onAnimationEnd still fires and the stage can reach done), owner mention deduped, getProfile failure degrades to an ungreeted opener, 8s curtain safety valve.

Non-blocking nits:

• announcedChannelIdRef in useWelcomeKickoffStagePresence holds a single id, so A→B→A re-announces the surface-ready event. Harmless today (nothing listens once the curtain is gone), just noting it.
• Stray blank line added in ChannelScreen.tsx (~line 261).

CI is fully green including both E2E integration shards and all four smoke shards. The documented silent-failure gap is reasonably scoped out to the follow-up doc.

[brow]

🤖 Independent second review (load-bearing), requested in the Buzz #buzz-launch thread. Reviewed the full diff at 7fafb93 against merge-base 79598bd and ran the onboarding unit suites locally (53/53 pass). No red flags. Report-only pass — approval is with the primary reviewer.

What I verified:

• Stage phase machine: done checked before isWelcome so the terminal state can't be laundered back to hidden; timeout only downgrades active; reduced-motion keeps 1ms animations so onAnimationEnd still fires and done stays reachable. The container's onAnimationEnd correctly filters on animationName, so bubbled child enter-animations can't trigger a premature exit.
• Kickoff thread-watch latch: one-way per-channel latch is the right call (deriving from kickoffEvents would be self-referential, as the comment explains); the closer path is double-guarded (merged-events marker check + server-side markerExists in sendWelcomeKickoffCloser), so no duplicate closer even across remounts where the latch resets.
• App.tsx restructure: boot ordering preserved (transaction → needsSetup → apply-error → applied gate); the flow keeps one stable tree slot across finalizing→entering so no remount restart; key={communityKey} retained on provider and AppReady.
• Direct entry: takePendingWelcomeChannelForDirectEntry consumes the pending entry so a later Home visit can't be yanked back to Welcome; a persisted entering transaction self-heals on app relaunch via the 8s safety valve (isTransaction accepts the new stage, so the localStorage round-trip parses).
• Beat removal: KICKOFF_BEAT_MS removed cleanly; waitForWelcomeKickoffBeat now requires waitMs and all remaining callers pass it.

Two non-blocking notes as inline comments (curtain event not scoped to the target channel; single-slot resolvedChannelId latch).

[brow]

🤖 Non-blocking: beginFade fires on any WELCOME_SURFACE_READY_EVENT without checking detail.channelId against the channel the router was just pointed at. Today only the Welcome ChannelScreen emits this event and direct entry navigates there synchronously before entering begins, so a mismatched emitter can't realistically exist — but if a second Welcome-like surface ever announces readiness, the curtain would fade on the wrong channel's signal. A one-line detail.channelId check would make the contract explicit.

[brow]

🤖 Non-blocking: resolvedChannelId holds a single channel id, so with two Welcome channels (e.g. per-community) an A→B→A visit drops A's latch and re-enables the opener-thread query for one refetch until the closer marker re-latches it. Correctness is unaffected — the closer path is still guarded by the merged-events marker check plus the server-side markerExists in sendWelcomeKickoffCloser — it just costs one redundant subtree fetch. A small Set<string> would avoid it if that ever matters.