fix(web): resolve skill vs type-chip routing conflicts#3031
Conversation
Clear the opposing selection when the user picks a skill or scenario chip, and omit skillId when a scenario plugin is active on submit.
lefarcen
left a comment
There was a problem hiding this comment.
Hey @leno23, thanks for jumping on the #2972 routing conflict so quickly — the Summary and Validation make the fix direction easy to follow.
One small PR-description housekeeping ask before pool review: could you update the ## Surface area section to use the repo's checklist and tick the affected surface (this looks like UI/default routing behavior), rather than only listing files? That helps reviewers and release verification see the user-facing surface at a glance.
Siri-Ray
left a comment
There was a problem hiding this comment.
@leno23 I reviewed the HomeView routing changes and the added context-picker regression coverage. The updated selection handlers now clear the opposing route source, submit derives skillId from the active scenario state, and the new tests cover both chip-to-skill and skill-to-chip flows. CI is green for the relevant web/workspace checks; I could not rerun the focused Vitest locally because this Looper worktree has no node_modules, but the live Web workspace tests passed. Thanks for tightening this routing path and adding focused regression coverage.
















































Fixes #2972
Summary
Home hero could keep both an active scenario type chip (plugin) and an
@skillselection at once, then submit with conflictingpluginId+skillIdrouting. Picking one source now clears the other, and submit omitsskillIdwhenever a scenario plugin is active.Surface area
apps/web/src/components/HomeView.tsx— mutual exclusion inusePlugin/useSkill; guardskillIdon submit.apps/web/tests/components/HomeView.context-picker.test.tsx— regression tests for chip→skill and skill→chip flows.Validation
cd apps/web && pnpm test tests/components/HomeView.context-picker.test.tsx— 5 passed.Made with Cursor