README.mdfeat(onboarding): make /onboarding the whole setup, and retire the modal
The card-and-dots wizard at /onboarding only connected accounts. Everything a
user actually has to decide — inbox layout, sub-inboxes, task groups, pipeline
views — was discoverable only by finding the right dialog afterwards. The other
thing called onboarding, a dev-only modal behind two profile menus, ran on mock
data and configured nothing at all.
So /onboarding is now the full-page rail-driven flow, and the integration steps
survive inside it as the Connect section, spliced in from whatever the org has
installed rather than hard-coded — a team with no CRM never sees a CRM step, and
the rail does not count one toward its progress. Provider selection moved inside
each step, so Back means one thing instead of two.
The modal is deleted along with the CRMTablePreview/SimpleCRM subtree only it
used. Its templates screen is kept, unreferenced, at modules/onboarding/
templates: the AI-variable notation and source-email provenance are the design a
real templates surface should be built on, and re-deriving them would lose that.
Nothing imports it and it is not routed, but it stays inside the project so it
keeps type-checking instead of rotting into a snippet that no longer builds.
Also drops /onboarding-setup, added one commit ago — one flow, one URL.
Co-Authored-By: Claude Opus 5 (1M context) <<email>>Sep 1, 2026, 11:52 AMtemplate-fixtures.tsfeat(onboarding): make /onboarding the whole setup, and retire the modal
The card-and-dots wizard at /onboarding only connected accounts. Everything a
user actually has to decide — inbox layout, sub-inboxes, task groups, pipeline
views — was discoverable only by finding the right dialog afterwards. The other
thing called onboarding, a dev-only modal behind two profile menus, ran on mock
data and configured nothing at all.
So /onboarding is now the full-page rail-driven flow, and the integration steps
survive inside it as the Connect section, spliced in from whatever the org has
installed rather than hard-coded — a team with no CRM never sees a CRM step, and
the rail does not count one toward its progress. Provider selection moved inside
each step, so Back means one thing instead of two.
The modal is deleted along with the CRMTablePreview/SimpleCRM subtree only it
used. Its templates screen is kept, unreferenced, at modules/onboarding/
templates: the AI-variable notation and source-email provenance are the design a
real templates surface should be built on, and re-deriving them would lose that.
Nothing imports it and it is not routed, but it stays inside the project so it
keeps type-checking instead of rotting into a snippet that no longer builds.
Also drops /onboarding-setup, added one commit ago — one flow, one URL.
Co-Authored-By: Claude Opus 5 (1M context) <<email>>Sep 1, 2026, 11:52 AMtemplate-utils.tsxfeat(onboarding): make /onboarding the whole setup, and retire the modal
The card-and-dots wizard at /onboarding only connected accounts. Everything a
user actually has to decide — inbox layout, sub-inboxes, task groups, pipeline
views — was discoverable only by finding the right dialog afterwards. The other
thing called onboarding, a dev-only modal behind two profile menus, ran on mock
data and configured nothing at all.
So /onboarding is now the full-page rail-driven flow, and the integration steps
survive inside it as the Connect section, spliced in from whatever the org has
installed rather than hard-coded — a team with no CRM never sees a CRM step, and
the rail does not count one toward its progress. Provider selection moved inside
each step, so Back means one thing instead of two.
The modal is deleted along with the CRMTablePreview/SimpleCRM subtree only it
used. Its templates screen is kept, unreferenced, at modules/onboarding/
templates: the AI-variable notation and source-email provenance are the design a
real templates surface should be built on, and re-deriving them would lose that.
Nothing imports it and it is not routed, but it stays inside the project so it
keeps type-checking instead of rotting into a snippet that no longer builds.
Also drops /onboarding-setup, added one commit ago — one flow, one URL.
Co-Authored-By: Claude Opus 5 (1M context) <<email>>Sep 1, 2026, 11:52 AMTemplatesPage.tsxfeat(onboarding): make /onboarding the whole setup, and retire the modal
The card-and-dots wizard at /onboarding only connected accounts. Everything a
user actually has to decide — inbox layout, sub-inboxes, task groups, pipeline
views — was discoverable only by finding the right dialog afterwards. The other
thing called onboarding, a dev-only modal behind two profile menus, ran on mock
data and configured nothing at all.
So /onboarding is now the full-page rail-driven flow, and the integration steps
survive inside it as the Connect section, spliced in from whatever the org has
installed rather than hard-coded — a team with no CRM never sees a CRM step, and
the rail does not count one toward its progress. Provider selection moved inside
each step, so Back means one thing instead of two.
The modal is deleted along with the CRMTablePreview/SimpleCRM subtree only it
used. Its templates screen is kept, unreferenced, at modules/onboarding/
templates: the AI-variable notation and source-email provenance are the design a
real templates surface should be built on, and re-deriving them would lose that.
Nothing imports it and it is not routed, but it stays inside the project so it
keeps type-checking instead of rotting into a snippet that no longer builds.
Also drops /onboarding-setup, added one commit ago — one flow, one URL.
Co-Authored-By: Claude Opus 5 (1M context) <<email>>Sep 1, 2026, 11:52 AM