fix(server): recreate a thread's worktree before starting a turn - #7839

💭 I want to check the changed files to see how conventions are applied, particularly the git workflow service, the VCS driver files, and the provider command reactor.

1. browse_code — apps/server/src/git/GitWorkflowService.ts

2. browse_code — apps/server/src/orchestration/Layers/ProviderCommandReactor.ts

💭 I'm noting that ProviderCommandReactorShape is pre-existing and outside the changed scope. Now I'm checking the GitVcsDriverCore prune implementation and the new ensureThreadWorktree code, which uses catchCause with hasInterruptsOnly to properly preserve interruption semantics per convention. The main things worth flagging: whether catchCause vs catchTags is appropriate here (seems acceptable as a best-effort logging catch-all), whether tests exist for the behavior change (they do), and whether pruneWorktrees follows the same Effect.fn naming convention as other methods. I want to look at the surrounding code in GitVcsDriverCore and the changed region of ProviderCommandReactor to confirm consistency.

3. browse_code — apps/server/src/vcs/GitVcsDriverCore.ts

4. browse_code — apps/server/src/orchestration/Layers/ProviderCommandReactor.ts

💭 I'm checking whether logging the pretty-printed cause in that git command warning violates the convention against reintroducing raw defect text into log payloads, since it could leak command output. There's an existing formatFailureDetail pattern doing the same thing, so I want to check how Effect.logWarning is used elsewhere in the codebase to see if this is an accepted pattern before flagging it as a violation. Looking at interruption handling, using catchCause with hasInterruptsOnly seems reasonable for a best-effort cleanup path, even though it's broader than catchTags — I don't think this rises to a real convention violation worth failing on. Now I'm checking the service interface additions for GitVcsDriver and GitWorkflowService, along with the imports in ProviderCommandReactor.ts, to make sure the dependency wiring follows the established patterns. In the test file, I'm verifying that the fake GitWorkflowService and mocked methods like pruneWorktrees and createWorktree are provided correctly via Layer.succeed, which is standard practice for tests. I'm also wondering whether other test stubs implementing GitVcsDriver elsewhere in the codebase would need updates to include pruneWorktrees, though that's more of a compile-time concern than a convention issue. Now I want to check the GitWorkflowService.make implementation around lines 300-340 to see how it handles command execution patterns, and whether there's a VcsDriverRegistry or other driver implementations that also need to implement pruneWorktrees. I should look at GitVcsDriver.ts to confirm where else this interface gets implemented, and check the logging calls for consistency in how errors are reported.

5. git_tools — Cause.pretty

6. browse_code — apps/server/src/git/GitWorkflowService.ts

💭 The cause.pretty pattern in the log payload matches existing conventions, so it's not a new issue. Since this is a behavior change, tests are warranted, and the fake createWorktree returning a successful effect looks fine for the test setup. Checking whether other GitVcsDriver test doubles now need pruneWorktrees — if missing it'd just be a compile error, not a convention violation, so I can skip that. Now I want to look at the ProviderCommandReactor call site around line 1134 to see the context around ensureThreadWorktree.

7. browse_code — apps/server/src/orchestration/Layers/ProviderCommandReactor.ts

💭 Everything here follows the file's existing patterns for imports, service definition, and error handling. I'm checking whether adding the FileSystem dependency to the layer means it needs to be provided upstream in the app's composed layers, since otherwise it'd surface as a type error rather than a convention issue. Production construction correctly pulls dependencies from the environment, and the test harness presumably supplies NodeFileSystem, so that's not a convention concern either. I'm concluding this is clean with no findings, so the final structured response should report success with a summary of "All clear."