feat(web): pick settings environment and project as two selects#10636

🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win

Disambiguate checkout items with duplicate environment labels.

If two member checkouts have the same environment label and workspace path, their rendered ComboboxItem entries have identical text even though they target different environments. Add the environment URL when labels duplicate.

✅ Addressed in commit 1a70479

Fixed in 1a70479f2b1 and propagated upstack. Duplicate checkout labels and the selected trigger include the connection URL, with environment ID fallback. Checkout paths remain searchable, long labels wrap so the distinguishing address stays visible, and full identities have tooltips. Label regressions and the 179-test integrated run pass; inspected the actual picker at 1440px.

@juliusmarminge, thanks for the fix. The connection URL and environment-ID fallback address the duplicate checkout-label ambiguity. The preserved checkout-path search, wrapping, tooltips, and reported test coverage are consistent with the requested behavior.

🐇 ✅

@juliusmarminge Thanks for confirming the fix. I couldn't resolve this review thread on the repository platform, so it remains open. Please retry or resolve it manually.

You are interacting with an AI system.

🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win

Render unavailable scopes before project details.

When project is set and machine is unavailable, this condition mounts ProjectSettingsPanel before the scope.kind === "unavailable" branch. The panel then shows a checkout error instead of the resolver message that identifies the unavailable environment. Check scope.kind === "unavailable" first, then render project details only for resolved project or checkout scopes.

✅ Addressed in commit 1a70479

Fixed in 1a70479f2b1 and carried through both dependent PRs. Unavailable scopes render their resolver message before project details; the panel only mounts for resolved project or checkout targets. Verified a real stale-environment URL shows 'This environment is no longer available.' with no project controls. The integrated 179-test run and web typecheck pass.

@juliusmarminge, thanks for the fix and verification. The unavailable scope now preserves the resolver message and does not mount ProjectSettingsPanel.

🐇 ✅

If you found this review helpful, would you consider giving us a shout-out on X?

Thank you for using CodeRabbit!

@juliusmarminge Thanks for confirming the fix. I couldn't resolve this review thread on the repository platform, so it remains open. Please retry or resolve it manually.

You are interacting with an AI system.

Follow-up after the regrouping check: missing environments and incomplete checkout targets are blocked before the project editor. A project-missing or checkout-missing state may retain the mounted panel so it can follow previously selected members when a grouping change replaces the group key. Initial invalid URLs have no remembered selection and show no editable controls. Verified missing-environment and grouping/reset paths in the isolated app at 4cf0934097a and integrated 949c04f415a.

@juliusmarminge, thanks for the clarification and verification.

The current projectScope condition makes the required distinction. It blocks unavailable environments before ProjectSettingsPanel mounts. It retains the panel for project-missing and checkout-missing states during regrouping. The original recommendation was too broad, so I am withdrawing it.

✅ Review thread resolved.

You are interacting with an AI system.

🟠 High settings/settingsScope.ts:100

A project-wide selection returns kind: "project" with members whose environmentId is no longer present in environments, so settings updates can target a removed environment instead of showing an unavailable selection. The project branch only validates the explicitly selected machine; verify every member's environment exists and return environment-missing when any is stale.

Verified against the production data flow; this needs inconsistent synthetic inputs, not a reachable project target. useSettingsProjectGroups consumes useProjects(), whose projectRefsAtom enumerates only catalogValueAtom.entries (packages/client-runtime/src/state/projectEntities.ts:72-88). Environment presentations enumerate the same current catalog and keep an entry even when offline/unloaded (state/presentation.ts:32-56). Removing an environment deletes that catalog entry before cache cleanup, so its cached projects are no longer included. A stale request still targets that exact ID and fails with EnvironmentNotRegisteredError, with no primary-environment fallback. The existing registry removal-race test passes. Keeping the shared-catalog invariant instead of adding a second filter for unreachable input.

🟡 Medium settings/SettingsScopeSelects.logic.ts:24

environmentAxisValue returns "all" for a checkout-only scope such as ?project=...&checkout=..., even though resolveSettingsScope has resolved that checkout to an environment. The select therefore displays “All environments”, and choosing that displayed value calls selectEnvironmentAxis without checkout, widening the edit target to every checkout in the project. Use the resolved environment for checkout-only scopes before falling back to ALL_ENVIRONMENTS_VALUE.

Fixed in d0f11eda0f. environmentAxisValue takes the resolved checkout's environment, so a legacy ?project&checkout link shows that environment and picking it does not widen the target. Test added.

🟠 High settings/ProjectsSettings.tsx:29

Selecting a project with multiple checkouts applies project-level edits to every matching checkout because this scope UI never emits a checkout value. The ProjectSettingsPanel checkout picker only changes local action-selection state, so it cannot narrow the route to an exact checkout; add a checkout selector wired through onScopeChange (or have the picker update the route).

Intended. A project is the same project on every selected environment; the environment crumb decides which environments a project edit writes to, and a project has at most one checkout per environment in a group. Duplicate checkouts on one environment are not a first-class target in this UI (the checkout search key is only honoured for legacy links), so there is no separate selector.

🟠 High settings/settingsScope.ts:78

scope=device ultimately saves project defaults for every connected environment instead of this device. This branch returns kind: "device" with no environmentId, so ProjectsSettings passes null to ProjectDefaultsSettings, where null means all environments; preserve the device target when constructing ProjectDefaultsSettings rather than treating it as null.

The scope=device state no longer exists on this branch: SettingsScopeSearch has only project/machine/checkout and validateSettingsScopeSearch ignores scope. Device-local rows always render and never take an environment target, so there is no branch that could route a device edit to every environment.

I still see scope=device preserved in settingsScope.ts and resolved as kind: "device". ProjectsSettings passes it as environmentId={null}, which ProjectDefaultsSettings expands to all environments, so the concern still applies.