feat(web): open files in containing folder - #6463

💭 I should check the changed files for Effect service patterns, particularly the external launcher service, the editor contracts, and the web components that use them.

1. browse_code — apps/server/src/process/externalLauncher.ts

2. browse_code — packages/contracts/src/editor.ts

💭 I'm checking that the server file follows conventions for imports and layer structure, and confirming that the path schema intentionally allows spaces since the test asserts that behavior. Now I'm reviewing the web-side changes in fileLinkContextMenu.ts for correct type-only imports. I want to verify how ChatMarkdown.tsx imports Cause.fail and AsyncResult.failure, making sure they're consolidated named imports from "effect" rather than scattered subpath imports.

3. git_tools — ^import .*from "effect", "@effect", "effect/", "@t3tools

4. git_tools — ^import

💭 The web side seems to follow existing patterns, so I'm checking key convention areas like dependency acquisition, ManagedRuntime, Layer.succeed, and service-instance parameters, along with the server test harness and files like ws.ts, RpcAuthorization, and shellCommands.ts. The main thing to note is that customer conventions largely target Effect service definitions. The reveal-in-file-manager feature follows those same service patterns, and I don't see any real convention violations—error swallowing via orElseSucceed isn't flagged by the instructions, the error class reuse for unsupported editors is fine, and the schema validation looks correct. Import patterns in fileLinkContextMenu.ts also check out, using named and type-only imports appropriately. I still want to verify shellCommands.ts follows the createEnvironmentRpcCommand pattern, and confirm the ws.ts change matches how other shell methods use observeRpcEffect.

5. browse_code — packages/client-runtime/src/state/shellCommands.ts

6. git_tools — shellOpenInEditor|shellRevealInFileManager

💭 I'm checking whether wrapping the "no environment selected" message in a manufactured Error via Cause.fail violates the convention against creating Errors solely to populate a cause—though since this is UI-level AsyncResult logic rather than a service error, it may fall within an allowed boundary. Looking further, the ExternalLauncherUnsupportedEditorError message and the resolveFileManagerRevealLaunch environment usage both look fine, and the test file's use of Layer.succeed with service instances is permitted since tests have more flexibility. I'm also verifying that shellEnvironment exists in the web app state, that the fileManagerReveal capability key is optional in the contracts, and that the service interface remains properly inline without any misuse of Effect.fn.Return—nothing seems off so far. Now I'm thinking about whether discarding typed errors via orElseSucceed in resolveFileManagerRevealTarget matters, though conventions don't explicitly flag that pattern. I want to check if PullRequestSummaryTab.tsx properly imports EnvironmentId for its newly added interface field, since a missing import there would cause a TypeScript compile error, so I should look at how PullRequestTimelineTab handles that same import.

7. git_tools — EnvironmentId

8. git_tools — EnvironmentId

💭 Everything looks fine, no violations found. There's a tension between the instruction to output exactly "All clear" and the requirement to produce structured JSON, so I'll resolve this by including "All clear" as the summary while still following the schema format.