Architecture: extract settings access policy

Summary

Extract settings route access and redirect decisions into a pure policy module. The route loader should gather route/config/cache facts at the edge, pass plain data into the policy, and receive a render-or-redirect decision.

Files

• frontend/src/routes/settings.tsx
• frontend/src/utils/settings-utils.ts
• frontend/src/hooks/use-settings-nav-items.ts
• frontend/src/utils/org/permission-checks.ts
• frontend/src/utils/org/billing-visibility.ts

Problem

The settings clientLoader owns path classification, SaaS-only path guards, feature-flag hide redirects, ACP gating, selected-organization lookup, billing visibility, admin permission checks, and redirect selection.

Some of the decisions are already factored into helpers such as getFirstAvailablePath, isBillingHidden, rolePermissions, and getActiveOrganizationUser. The remaining problem is that orchestration and redirect selection are still procedural in the loader, and the loader directly reads query-cache data such as organizations and personal settings. That coupling makes the redirect matrix awkward to unit-test and keeps low-level organization/config imports in the route.

Proposed direction

Introduce a pure policy function, for example:

decideSettingsAccess(facts): { kind: "render" } | { kind: "redirect"; to: string }

Keep queryClient.getQueryData(...), selected-organization store reads, route params, and config lookup in a thin fact-gathering step at the route edge. The policy should receive plain facts such as config, feature flags, pathname, selected organization, current user, organization membership/permissions, and personal settings.

The policy should own the SaaS path guard, feature flag hide rules, ACP gating, organization permission decisions, billing visibility behavior, and fallback navigation target selection.

Testing focus

Add unit tests for decideSettingsAccess(...) that cover the redirect matrix without React Router loaders, TanStack Query, or store setup. Include cases for SaaS-only paths, hidden settings sections, ACP redirects, missing/changed selected organizations, billing visibility, and admin-only pages.

Expected wins

• Better locality for settings access rules
• Higher leverage tests over redirect behavior
• Less direct importing of low-level organization or config details from settings routes
• Cleaner separation between cache/fact gathering and access policy

Recommendation strength

Worth exploring