Build the onboarding UI

Where the onboarding conversation actually happens. Four pieces underneath: the surface itself, getting new signups into it and giving them a way out, stopping the existing welcome tour and education modal from firing on this path, and handing the conversation over to the Expert drawer when the user gets taken into the editor.

The surface embeds the existing expert components and reads the same store, so it's the same conversation rendered differently rather than a second chat implementation. Restyled chrome, shared innards.

### Direction still to be agreed

We have four sketched treatments. This needs a team decision rather than being settled here, so the mockups are below and the tradeoffs are summarised so we can argue about it properly.

**Standalone conversation.** Full window, one column, the transcript grows above you. Progress is implied rather than shown, carried by what the Expert says.

---

**One question, full bleed.** Each question owns the screen with large option tiles. A thin unlabelled thread is the only progress signal.

---

**Conversation beside the build.** Left half conversation, right half an integral panel showing what exists so far, so provisioning is something you watch rather than something you're told about.

---

**Collapsing transcript.** Answered questions fold into one quiet line each, with the picks kept as editable chips. The stack of folded answers is the progress indicator.

---

### Recommended approach

For what it's worth, my reading is that the collapsing transcript is the strongest fit for 3.1, with the right-hand build panel added later. Two reasons, both practical rather than aesthetic:

* The Expert decides at runtime how many questions to ask, one to four per turn. Anything that commits to a fixed number of steps up front will eventually be wrong, and a progress indicator that lies is worse than none. A stack that grows with what actually happened can't be wrong.
* Answers staying visible and editable means a wrong pick is cheap to fix, which matters when the options are being read by someone unfamiliar with the domain language.

The conversation beside the build is arguably the better idea overall, since making the provisioning wait watchable is the hardest problem in the flow. It's just more work, and it wants the workspace-ready signal to be in place first to feel right.

The one question full bleed treatment is the one I'd argue against, since the Expert can return up to four questions in a single turn and this shows one at a time, so we'd be splitting and reassembling turns in the frontend to satisfy a layout choice.

None of that is settled. If the team lands somewhere else, the four children below don't change much, since the shell is the only one that cares about layout.

### Worth knowing

Whatever we pick has to hand over cleanly when the Expert navigates the user into the editor. A surface rendered on a team page can't follow them there, but the drawer can, since it's mounted above the router views. The conversation lives in the store rather than in any component, so handing between the two is unmounting one renderer and mounting another with no state transfer.