Worktree Detection Method

[thomas-intramotev]

Summary

Changes the methodology of detecting Claude Code Worktree conversations. I know that I'm the one who originally suggested that Claudine scan for worktrees under .claude/worktrees/* 🙈, but I've found a number of issues with this method in practice:

• Directories under .claude/worktrees/* are fairly ephemeral: Claude is liable to delete them when a session closes, especially if they don't contain changes from the 'main' worktree
• Claude's "worktree sessions" seem to be a distinct concept from existent Git worktrees: the former only persist as long as a conversation remains open
• Some Claude Worktree conversations--namely those started from the CLI with the --worktree flag--have a distinct project folder of the form <workspace-name>--claude-worktrees-<worktree-name>, but a Conversation can have a different worktree session open than the one reflected in its project folder (if any)
  • In all cases: conversations (even those started with the --worktree flag) expect to be resumed from the base Workspace folder, not the .claude/worktrees/* subdirectory, so the Conversation's workspacePath field should really be the base Workspace path, even if there's an active worktree session

The basic crux of this PR is that Claudine no longer pays any attention to the .claude/worktrees folder: instead, if monitorWorktrees is true, Claudine pulls in conversations from project folders matching the format <monitored-workspace-name>--claude-worktrees-* (which generally persist even after the corresponding directory in .claude/worktrees/ is deleted). Additionally: a Conversation's worktreeName field is now parsed from worktree-state JSONL messages rather than its filepath.

Changes

• ConversationParser.ts:
  • Parses 'worktree-state' JSONL entries to extract worktreeName (set on session open, cleared on session close)
  • extractWorkspacePath now strips the --claude-worktrees-* suffix from the project folder name before resolving the workspace path, so worktree conversations resolve to the base workspace path
  • parseMessageContent was written to normalize message content that Claude Code would sometimes emit as a bare string or single object (instead of an array of content blocks)
• ClaudeCodeWatcher.ts:
  • Worktree metadata is now sourced from the parser rather than watcher; this does revert a fair amount of the code from this commit, namely getEffectiveWorkspaceRoots, getClaudeWorktreePaths, resolveWorkspacePathForFile, extractWorktreeName, and applyWorkspaceMetadata
  • getProjectDirsToScan now uses a prefix match when monitorWorktrees is enabled, picking up project directories of the form <workspace-name>--claude-worktrees-* alongside the base workspace directory.
  • isFromCurrentWorkspace and isFromExcludedWorkspace use a similar prefix-match strategy when monitorWorktrees is on
• StandaloneMessageHandler.ts:
  • Forwards the monitorWorktrees setting to the webview (it was previously missing from the settings snapshot)
• types:
  • Added 'worktree-state' as a valid ClaudeCodeJsonlEntry type with a worktreeSession field
• TaskCard
  • Added flex-wrap to the meta row and max-width/overflow to the WT badge to prevent layout overflow when branch and worktree labels appear together

Other Notes

• @salam I noticed in reviewing this commit that newer release notes seem to be going to RELEASE_NOTES.md rather than CHANGELOG.md--is that where I should be recording changes?
• monitorWorktrees (again: another of my own suggestions 🙈🙈) can arguably be deleted. It does have an effect, but the concept of "project folders" might be more Inside Baseball than needs to be surfaced in a user-facing setting. It's important to note that as of this PR: monitorWorktrees has no effect on whether the worktreeName field and WT badges are parsed from a Conversation, it only filters out certain conversations based on their project folder.
• Whether this PR closes [Feature]: Worktree Conversations on Board #5 is debatable. Worktree conversations are now surfaced on the board, but, as noted in that thread: a worktree conversation can't actually be resumed in a VS Code Editor tab due to a known limitation in Claude Code. Maybe that can be a separate issue, though.

Checklist

• npm test passes
• npm run lint passes
• Webview builds (cd webview && npm run build)
• Tested manually in the Extension Development Host
• Updated CHANGELOG.md (if user-facing change)
• User-facing strings use vscode.l10n.t() for i18n