feat(mcp): expose project thread launch service#10565

🟡 Medium project/handlers.ts:72

A failed launch.launch leaves the thread-scoped attachment copies orphaned, so repeated failed launches accumulate files while the pending originals remain retryable. The handler maps the launch error without releasing claimed.claimedPaths; release those paths on launch failure before returning the error.

The proposed blanket cleanup is unsafe at this boundary. In the unchanged ThreadLaunchService, message.dispatch commits the attachment references at lines 520-534, then getThreadProjection at lines 548-550 can still fail; the later preparation re-read can also fail. A launch error therefore does not prove those copies are unused. Releasing claimedPaths in tapError can delete bytes referenced by an accepted durable message. This wrapper deliberately retains copies on an uncertain outcome, as stated in the PR limits. Cleanup that distinguishes proven pre-acceptance failure from partial acceptance belongs in the shared launch service as a separate change; no unconditional release is being added here.

This handler introduces new backend behavior that nothing exercises: the full-access/default capability gate, the pending-upload-only attachment rejection, the caller inheritance of projectId/modelSelection/runtimeMode/interactionMode, and the runId/status lookup keyed by messageId. Consider adding a focused test (e.g. toolkits/project/handlers.test.ts, in the style of toolkits/preview/handlers.test.ts / toolkits/worktree/registration.test.ts) that provides a test layer for ThreadLaunchService only and asserts the denied-caller path, the non-pending attachment rejection, and the inherited defaults reaching launch.

^{Posted via Macroscope — Effect Service Conventions}

The maintainer explicitly requested shared MCP tests and existing service tests instead of per-tool suites. This wrapper delegates execution/provisioning to ThreadLaunchService, uses the shared live caller helper, restricts project launch to full-access/default, and only accepts pending uploads for a new thread. Default inheritance is explicit nullish forwarding; the returned run is found by the exact generated initial message ID, never by the latest run. These lines have been source-reviewed; no concrete faulty behavior was identified. Launch execution/partial acceptance remain the service responsibility and its tests; the MCP core/real integration coverage stays shared.

This handler adds backend behavior that lives only here and not in ThreadLaunchService: the full-access/default capability gate, the pending-upload-only attachment rule, and the caller-inheritance defaults for projectId/modelSelection/runtimeMode/interactionMode/workspaceStrategy. None of it is covered by a test — consider a focused test alongside toolkits/core.test.ts, which already exercises a toolkit handler through Toolkit.toLayer with a test layer for ThreadManagementService, so the launch service can be substituted the same way without mocking the launch logic itself.

^{Posted via Macroscope — Effect Service Conventions}

The maintainer explicitly requested shared MCP tests and existing service tests instead of per-tool suites. This wrapper delegates execution/provisioning to ThreadLaunchService, uses the shared live caller helper, restricts project launch to full-access/default, and only accepts pending uploads for a new thread. Default inheritance is explicit nullish forwarding; the returned run is found by the exact generated initial message ID, never by the latest run. These lines have been source-reviewed; no concrete faulty behavior was identified. Launch execution/partial acceptance remain the service responsibility and its tests; the MCP core/real integration coverage stays shared.

The delegation boundary is clear, but the capability gate, pending-upload rejection, and inheritance are handler-owned. Current shared integration coverage does not exercise uploads or inherited defaults, so the test-coverage concern remains.

unavailable discards the structured AttachmentClaimError, so caller-actionable claim reasons ("attachment not found", "stored size does not match", "attachment type does not match the upload") collapse into "The operation could not be completed." The sibling claim site (toolkits/attachment/handlers.ts) and ws.ts launchThread both preserve error.message; consider mapping this failure where its context is known rather than through the generic helper.

^{Posted via Macroscope — Effect Service Conventions}

Fixed in 530b178333. The launch wrapper now preserves AttachmentClaimError.message, matching the send wrapper and existing WS boundary, while excluding its raw cause. The public code remains orchestration_error because this typed channel also covers operational copy/stat failures. Final shared core + real MCP integration 7/7, server typecheck and targeted lint/fmt/diff pass. No claim or launch service behavior changed.