What problem does this solve?
src/app/install/install-wizard.tsx has three steps. Step 1 is the real GitHub install flow. Step 2 just renders "(Repo picker coming soon in #326)" and Step 3 renders "(Completion screen coming soon)". Meanwhile a fully working repo picker already exists at src/app/onboarding/repos, backed by getRepoPicker and setRepoManaged, with its own page at /onboarding/repos. The two onboarding flows were built separately and never connected.
Type
New Feature
Who benefits?
Contributors and maintainers going through onboarding
Proposed Solution
Mount the existing RepoPicker component (or redirect to /onboarding/repos) from the wizard's Step 2 instead of the placeholder text, passing through whatever installationId context the wizard has at that point. Step 3 can stay simple but should at least reflect that repo selection actually happened.
Alternatives Considered
Could keep them as two separate flows, but that means maintaining repo selection UI in two places, and new users currently hit a dead end at step 2 of the wizard.
Additional Context
More involved than it looks since the wizard's step state is local and URL based while the repo picker page is a full server component with its own data fetching. Wiring them together needs some thought about where installationId comes from inside the wizard.
What problem does this solve?
src/app/install/install-wizard.tsxhas three steps. Step 1 is the real GitHub install flow. Step 2 just renders "(Repo picker coming soon in #326)" and Step 3 renders "(Completion screen coming soon)". Meanwhile a fully working repo picker already exists atsrc/app/onboarding/repos, backed bygetRepoPickerandsetRepoManaged, with its own page at/onboarding/repos. The two onboarding flows were built separately and never connected.Type
New Feature
Who benefits?
Contributors and maintainers going through onboarding
Proposed Solution
Mount the existing
RepoPickercomponent (or redirect to/onboarding/repos) from the wizard's Step 2 instead of the placeholder text, passing through whateverinstallationIdcontext the wizard has at that point. Step 3 can stay simple but should at least reflect that repo selection actually happened.Alternatives Considered
Could keep them as two separate flows, but that means maintaining repo selection UI in two places, and new users currently hit a dead end at step 2 of the wizard.
Additional Context
More involved than it looks since the wizard's step state is local and URL based while the repo picker page is a full server component with its own data fetching. Wiring them together needs some thought about where
installationIdcomes from inside the wizard.