Contribution proposal: unit tests for crates/git, Vitest infrastructure, and Claude executor ToolResult support

[fatihkutlar]

Hi team,

I've been exploring the codebase and identified three areas where I think I can add meaningful value. I'd like to get your thoughts before opening any PRs — happy to adjust scope or approach based on your feedback.

I'm planning to open three separate PRs, one per topic.

---

1. Unit tests for crates/git

crates/git/src/lib.rs is ~1,970 lines with no #[cfg(test)] blocks. It covers commit, diff, worktree creation/removal, merge, and branch operations — all untested.

I'd like to add a #[cfg(test)] module using tempfile::TempDir and git2 (both already available as dev-dependencies) following the same pattern as the existing test in crates/worktree-manager/src/worktree_manager.rs. The starting set would cover commit(), is_worktree_clean(), get_diffs(), get_current_branch(), is_branch_name_valid(), and get_head_info(). No production code would be touched.

Is there a specific subset of GitService methods the team considers highest priority to cover first?

---

2. Vitest infrastructure + first tests in packages/web-core

There are currently no test files anywhere in the frontend packages and no test framework installed. CONTRIBUTORS.md mentions Vitest as the expected tool. There's also an orphaned fixture at src/test/fixtures/normalized_entries.json with nothing using it.

I'd like to add Vitest + @testing-library/react to packages/web-core, a vitest.config.ts that reuses the existing path aliases from tsconfig.json, and write the first two test suites:

• utils.test.ts — covering the cn() utility (including documenting the current clsx-only behaviour while twMerge is disabled)
• useTodos.test.ts — covering the timestamp comparison, hasMeaningfulTodos filtering, and in_progress / in-progress detection logic in the useTodos hook

The orphaned fixture would be used in the useTodos suite.

---

3. ToolResult support in the Claude executor

There are two places in crates/executors/src/executors/claude.rs where ToolResult blocks are silently dropped with a TODO comment (lines ~1020 and ~1575). These are the outputs the agent receives back from its own tool calls — bash results, file contents, test output — and they're currently invisible in the conversation log.

I'd like to:

• Add an ActionType::ToolResult { tool_use_id: String, is_error: bool } variant to crates/executors/src/logs/mod.rs
• Wire both drop sites to produce a NormalizedEntry using the existing normalize_claude_tool_result_value() helper already in the file
• Add a generate_concise_content() arm for the new variant
• Extend the existing test module in claude.rs with cases covering both the ClaudeContentItem::ToolResult and ClaudeJson::ToolResult paths

I'd keep this scoped to the Claude executor only — no changes to droid, opencode, or other executors. Frontend rendering would fall through to the existing Other fallback until a follow-up UI PR is warranted. I'd also run pnpm run generate-types:check before submitting since the new variant derives TS.

Is the TODO comment on these sites still an accurate reflection of the blocker ("when the type system supports it"), or has something changed since it was written?

---

Thanks for reading. Let me know which of these are aligned with where the project is headed, and I'll start with whichever is most useful.