Product / Design / UX

In priority order:

1. Working branch should probably be main, not dev. Before the first publish there's nothing in prod to protect, so starting on a dev branch is ceremony without governance value — and it's what's driving the stubbed-out machinery in publish-project.ts. Consider working directly on main with editable=true until first publish, then flipping main to non-editable and requiring dev branches for subsequent edits. The tradeoff is a dual-mode main (editable pre-publish, protected post-publish), but it collapses onboarding into a single commit path. Worth checking with the Platform team on whether this is feasible before more of publish-project.ts gets built out.

2. Commit message "Initial dashboard commit" is sometimes inaccurate. Tracing the code: ConnectorForm.svelte:saveConnector wires "Save" → onClose → onDone → publishProjectAndRedirect, so a user can publish after creating only a connector (no source, no dashboard). Suggest "Initial project setup" instead — covers all paths honestly.

3. No exit on project welcome. Once a user lands on /-/welcome, the +layout.ts forces them back every time they try to navigate elsewhere (until the welcome branch is cleared). If a user creates a project by mistake, there's no discoverable escape hatch. Product may have intentionally chosen to force users through the funnel — flagging for discussion. If they do want an exit, a "Cancel" or "Delete this project" affordance would do it.

4. Form field labeled "URL". CreateProjectForm.svelte labels the name input "URL" with a prefix of https://ui.rilldata.com/{org}/. Users are naming a project, not entering a URL — the label should be "Project name". The URL preview is a nice affordance but the label is misleading.

5. "Create new" button copy + placement. In ProjectCards.svelte the button lives inside a sentence ("Check out your projects below.") and is labeled just "Create new". It reads awkwardly next to the hint text and would be clearer as its own heading row with a full "Create project" label. Same button on [organization]/+page.svelte.

6. allowEmpty={false} on project welcome. The cloud welcome hides the "Start a blank project" card, which is reasonable since the user already named the project. But there's no "skip and start empty in code" path visible. Intentional for now?

Engineering Implementation

In priority order:

1. Bugs.

• web-common/src/features/add-data/manager/GenerateDashboardStatus.svelte:185 — onClick={() => onDone} returns the function reference instead of invoking it. Should be onClick={onDone}.
• web-common/src/features/add-data/form/ConnectorForm.svelte:95 — if (config) return goto(...) is a no-op gate: config is a required prop so it's always truthy. Probably intended if (!config.skipNavigation). The current code navigates to /files/... in the cloud flow, which is a broken route.
• web-common/src/features/add-data/manager/steps/connector.ts — maybeInitProject drops the olapEngine detection entirely and now always unpacks with the default (DuckDB). This also affects SourceForm.svelte, which is used outside the cloud onboarding flow. If a rill-dev user adds ClickHouse as their first connector, olap_connector will no longer auto-route. Intentional or collateral?

2. setTimeout(() => goto(...)) is being papered on. This PR adds two new instances (publish-project.ts:24, create-project/+page.svelte:46), and the pattern already exists in -/welcome/organization/+page.svelte, OrgNameSettings.svelte, and ProjectNameSettings.svelte. Five workarounds for the same "navigation cancelled" symptom suggests something structural is wrong — likely a load function throwing, an in-flight query being invalidated, or a reactive statement re-running. Worth tracing the root cause in a follow-up rather than adding a sixth.

3. projectWelcomeStatusStores — is sessionStorage the right backing? Welcome state is tracked in a per-tab sessionStorage store, which means: open the project in another tab, no welcome; close the tab after abandoning, welcome state is lost; can't resume on another device. The backend already knows whether a project is unpublished (skipDeploy, no primary deployment). Consider deriving "show welcome" from server state rather than maintaining client state that can drift from reality.

4. FileAndResourceWatcher duplication with PR 8912's edit route. Both the welcome layout and the edit layout wrap children in FileAndResourceWatcher + runtime resolution. Not a blocker for this PR — once both land we should consolidate into a shared layout or component so the authoring surfaces share one runtime-watching entry point.

5. config.skipNavigation naming is confusing. The flag is used in two opposite-looking conditions across GenerateDashboardStatus.svelte (if (!config.skipNavigation) return goto(...) vs. {#if config.skipNavigation} around the Skip button). Each may be individually defensible, but together they're hard to reason about. Consider renaming to something intent-based (e.g. autoNavigateOnDone for the auto-redirect, showSkipButton for the button visibility), and splitting if they're independent concerns.

6. Reliability nits.

• projectWelcomeStatusStores.welcomeStatus is a Map keyed by project name that grows unbounded per session. If we keep sessionStorage, skip the in-memory cache — storage is already the source of truth.
• ProjectGlobalStatusIndicator.svelte adds optional chaining to projectParser.state.parseErrors. Likely defensive-fixing a crash in the new flow (parser state not yet populated). Worth a one-line comment or finding the root cause so this doesn't silently swallow future bugs.

7. Test coverage. Not a blocker for merging, but before we ship to users this flow needs a component test for CreateProjectForm (happy path + form error mapping) and an e2e covering the full welcome → connect → publish loop. The e2e can wait until the Cloud Editing PR is in.

Developed in collaboration with Claude Code

Approving, though I do think we should come back to my point 1. I think it should be possible for us to provision the main branch first as an editable dev deployment, then later promote it (and scale it up) to an non-editable prod deployment.