improve(ui): nest Settings pages under /settings routes#100928
Conversation
|
@clawsweeper review |
|
🦞🧹 I asked ClawSweeper to review this item again. |
|
Codex review: needs maintainer review before merge. Reviewed July 7, 2026, 8:53 AM ET / 12:53 UTC. Summary PR surface: Source +5, Tests +34. Total +39 across 8 files. Reproducibility: not applicable. as a cleanup/UX PR: the current-main baseline uses top-level Settings paths, and the PR changes generated route metadata plus tests to Review metrics: 1 noteworthy metric.
Merge readiness Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch. Rank-up moves:
Risk before merge
Maintainer options:
Next step before merge
Maintainer decision needed
Security Review detailsBest possible solution: Land the narrow route metadata change only after maintainers accept Do we have a high-confidence way to reproduce the issue? Not applicable as a cleanup/UX PR: the current-main baseline uses top-level Settings paths, and the PR changes generated route metadata plus tests to Is this the best way to solve the issue? Yes mechanically: shared route metadata and page definitions are the right layer for generated URLs and router aliases; maintainer acceptance of the canonical namespace remains the open decision. AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning high; reviewed against a9582a1bb62a. Label changesLabel justifications:
Evidence reviewedPR surface: Source +5, Tests +34. Total +39 across 8 files. View PR surface stats
What I checked:
Likely related people:
What the crustacean ranks mean
Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics. How this review workflow works
Review history (4 earlier review cycles)
|
f5b28fa to
6569808
Compare
6569808 to
dc71f12
Compare
dc71f12 to
2652c73
Compare
|
Merged using rebase. What changed after review:
Verification:
Landed on main:
Thanks @vyctorbrzezowski! |
What Problem This Solves
In the pre-change routing model, Control UI Settings pages live at several top-level URLs, so Settings navigation does not have a single canonical URL namespace. This PR proposes
/settings/*as the canonical Settings route family while preserving existing top-level deep links.Why This Change Was Made
In this PR, Settings route metadata points navigation and programmatic route generation at
/settings/general,/settings/worktrees,/settings/appearance, and the rest of the/settings/*pages. Existing top-level paths such as/config,/worktrees,/appearance,/channels,/debug, and/logsremain registered as aliases so old links still resolve to the same route ids.This intentionally does not change Settings layout, sidebar structure, visual styling, form placement, or content organization.
User Impact
In this PR, Settings URLs are canonicalized under
/settings/*; existing bookmarks and direct links to the older top-level Settings paths continue to work.Screenshots
Desktop
/settings/generalin this PR:Mobile
/settings/generalin this PR:Evidence
Validated in this refresh:
git diff --checkoxfmt --check --threads=1 ui/src/app-navigation-groups.test.ts ui/src/app-navigation.test.ts ui/src/app-route-paths.ts ui/src/pages/worktrees/route.tspathForRoute("worktrees") -> /settings/worktrees,/settings/worktrees -> worktrees,/worktrees -> worktrees,/settings/general -> config, and/config -> config./settings/worktrees,/worktrees,/settings/general, and/configin the mock Control UI dev server.Updated tests cover the new Worktrees canonical route and legacy alias behavior.