feat(web): open project settings from thread menus - #8925

💭 With both prior findings addressed, I'm checking the current head state to confirm the fixes landed correctly - the legacy sidebar item without an icon, the projectGroupsRef usage in Sidebar.tsx, and the thread action menu's project resolution via environmentId all look correct. I want to double check whether the settings icon in the menu fallback is still needed, since the modern menu still uses it even though the legacy menu dropped it - if the web fallback renders the modern menu, that icon path matters. Let me verify all modern menu items have icons and check the fallback icon rendering.

1. browse_code — apps/web/src/components/threadActionMenu.logic.ts

2. browse_code — apps/web/src/contextMenuFallback.ts

💭 I should check whether the chat header menu renders icons through a React icon-mapping component, since the "settings" icon used in threadActionMenu might not be registered there — if it's missing, the icon wouldn't show up in the dropdown header menu. I'm going to search the web components for that icon map.

3. git_tools — "mail-open"|'mail-open'|mail-open

💭 So icons are only rendered through fallback paths, no React icon map needed. I should check whether there's an Electron-side context menu icon map, but that's out of scope. Next I want to verify the useThreadActionMenu project-settings case and the openProjectSettings behavior in Sidebar to see if it navigates or opens a dialog, so I'll look at the relevant sections of Sidebar.

4. browse_code — apps/web/src/components/Sidebar.tsx

5. browse_code — apps/web/src/components/Sidebar.tsx

💭 I'm checking the sidebar thread context-menu case around line 3133, and whether the sidebar menu properly closes the mobile sidebar. I'm also considering what happens if the project group isn't found — it returns silently, which could mean no navigation occurs even though the item still shows; this seems like a minor finding worth flagging, tied to how useThreadActionMenu derives its fallback key. Since the item comes from the shared buildThreadActionMenuItems list, it's always shown regardless — so if a thread's project isn't in projectGroups (unloaded or hidden), clicking does nothing, which is a minor issue. I want to look at the Sidebar code around lines 3120-3150 and the LegacySidebar changes next.

6. browse_code — apps/web/src/components/Sidebar.tsx

7. browse_code — apps/web/src/components/LegacySidebar.tsx

💭 The placement order is similar enough between the two menus. But I notice a discrepancy: in LegacySidebar, "project-settings" links to the sidebar item's own project rather than the specific thread's project, since threads are grouped under a project in that view. Actually a project group can span multiple member projects, so navigating to the group's logical project key still seems correct here — that's fine. I also see delete already has a trash icon in the legacy list, so the list isn't fully icon-less as I assumed; my earlier suggestion to drop the icon aligns with what's already there, so no need to revisit. Now I want to check the full useThreadActionMenu implementation, especially how the project key is derived and how environment scoping works.

8. browse_code — apps/web/src/hooks/useThreadActionMenu.ts

💭 I want to verify the signatures of buildPhysicalToLogicalProjectKeyMap and deriveLogicalProjectKeyFromSettings/derivePhysicalProjectKey are correct, particularly whether the primaryEnvironmentId and settings parameters line up properly. I also want to confirm the /projects/$projectKey route correctly resolves logical keys, and check whether there's a lingering issue with the settings. Also worth checking whether the chat header menu icons render fine through the same context menu bridge, and whether Electron's main-process menu has a separate icon whitelist that might reject or warn on the "settings" icon.

9. git_tools — folder-tree|"pin-off"

💭 The web fallback confirms this is fine. The ICON_PATHS ordering isn't strictly alphabetical anyway, so settings being out of order isn't an issue. I'm also noting that the modern Sidebar closes the mobile sidebar on openProjectSettings, while the chat header's useThreadActionMenu has no such mobile concern, and I want to check whether the shared item behaves consistently across both. I should verify the route file handles unresolved projectKeys gracefully, since remote or hosted environments might not have a corresponding settings page. There's also a question of whether the chat header menu could appear for threads whose project isn't in useProjects() — this would make the menu item silently do nothing rather than target the wrong server, which is a milder concern than an actual misdirected action, and Sidebar has the same silent-return behavior, so it's likely not worth flagging as a concrete finding. Both Sidebar and useThreadActionMenu correctly match on environmentId and projectId, so the environment routing itself looks sound. Now I need to confirm that the logical project key resolution stays consistent between the two — Sidebar derives it via projectGroup.projectKey from buildSidebarProjectSnapshots (which respects grouping overrides), while useThreadActionMenu relies on buildPhysicalToLogicalProjectKeyMap, so I want to check that function's semantics alongside deriveLogicalProjectKeyFromSettings to make sure they align.

10. git_tools — export function buildPhysicalToLogicalProjectKeyMap|export function deriveLogicalProjectKeyFromSettings|export function derivePhysicalProjectKey

💭 Both prior findings are addressed and the implementation looks fine. Now I want to check if commit 450fa8b introduced anything new beyond a43cc22, so I'll look at the commits since fa436a5.

11. git_tools — c17d02c..450fa8b

💭 The commit hashes seem to differ from earlier references, likely due to a rebase—the head commit moved the project-settings item placement, and the shared list now places it after "copy" and before archive, consistent with the updated test. I want to check the latest commit diff to confirm what changed last.

12. git_tools — 450fa8b

💭 I'm confirming that "project-settings" correctly groups with the "Copy" section since it sits between the copy separator and the archive separator, and that the legacy sidebar's item placement above Delete is fine without needing an extra separator. No new issues to flag.