Welcome-back gate must only trigger for true returning visitors

Fixkamolos
Shipped
May 16, 2026 at 3:44 AM UTC
Author
Kamo
Commit
1d4648b

Brand-new visitors were hitting the welcome-back gate the moment they entered their name, because hasPriorProgress was recomputed from current state on every render — so as soon as state.preferredName was set, the gate fired in the middle of the conversation. Root-cause fix: snapshot the "did we load with progress?" decision ONCE at hydration time and never recompute. In-session edits cannot flip a visitor from "fresh" to "returning" — only what was in IndexedDB at page mount can. Also extracted hasPriorProgress() to lib/persistence/progress.ts so the component and tests share one source of truth, and added 6 unit tests covering the four important cases: - empty state → not returning - default flow set only → not returning (system default) - preferredName set → returning - any answer present → returning - empty-string name → not returning - empty answers object → not returning Audit-driven UX cleanups in the same commit: - "Start over" link now hidden on the very first screen (the user has nothing to start over) and gated by `showStartOverWhen` on CenterStage - EstimateReveal opens with a personalized lead-in bubble + a clear "real numbers come once we pull a quote" reassurance bubble (instead of dumping straight into ballpark figures) - Welcome-back fallback copy (no name on file) reads as a friendly "welcome back, you started something before" instead of the vague "looks like we already started something together" 82/82 tests pass (was 76; +6 progress unit tests).

All changes

Like what you see shipping?

Every one of these updates lands in your workspace automatically. Start free and watch it grow week after week.

Start Free ForeverView Pricing