Multi Repo Project Support

[fblgit]

This PR:

• feat: adds cli to bootstrap claudebench on existing project repositories [hooks, mcp, etc]
• feat: workingDir pushed via relay & stored in instance metada (system register)
• feat: worker selector for context & decompose (ui modals)
• feat: create_project, context, decompose handlers to support workingDir metadata (handlers)
• feat: task manager>instances displays workingDir for each registered instance

2025-09-22 14:52:33,391 - claudebench_inference.main - INFO - Context generation for subtask t-1758517127774
2025-09-22 14:52:33,391 - claudebench_inference.main - INFO - Using working directory: /Users/mrv/Desktop/GIT/DIL_Workbench
2025-09-22 14:52:33,392 - claudebench_inference.sampling - INFO - Using working directory: /Users/mrv/Desktop/GIT/DIL_Workbench

[claude]

Claude finished @fblgit's task —— View job

---

🔍 Code Review for PR #18: Multi Repo Project Support

I've completed my review of this PR that adds multi-repo project support to ClaudeBench. The implementation enables workers to operate on different project directories and includes a CLI installer for bootstrapping existing projects.

Review Checklist:

• Read CLAUDE.md for project conventions
• Review Python changes (inference layer)
• Review TypeScript handlers and schemas
• Review frontend components
• Review CLI installer script
• Check documentation additions
• Evaluate test coverage
• Post comprehensive review feedback

---

✅ Strengths

1. Well-structured implementation - The workingDir feature is cleanly integrated across the stack
2. Good separation of concerns - Each component handles its specific responsibility
3. Comprehensive CLI installer - The claudebench-init.ts script provides excellent project bootstrapping
4. Documentation included - Added guides for CLI installer and repository onboarding
5. Follows project patterns - Adheres to the handler-centric design and Redis-first architecture

🔍 Code Quality Observations

Python Layer (Inference)

• Good: Clean integration of workingDirectory parameter in sampling functions
• Good: Proper logging of working directory when provided
• Note: The cwd parameter is passed correctly to ClaudeCodeOptions

TypeScript Handlers

• Good: Consistent pattern for extracting workingDir from instance metadata
• Good: Proper null checking and error handling
• Minor: Some console.log statements could use consistent formatting (e.g., [TaskContext] prefix)

Frontend Components

• Good: Worker selector UI cleanly integrated
• Good: Proper state management and useEffect hooks
• Note: Good extraction of metadata display for working directories

CLI Installer

• Excellent: Comprehensive setup with proper error handling
• Good: Creates all necessary configuration files
• Good: Includes relay wrapper and proper Python script integration
• Minor: Could benefit from a --version flag

⚠️ Potential Issues

1. Missing Tests: No test files were added or modified. Critical functionality like:

   • Working directory propagation through handlers
   • CLI installer edge cases
   • Instance metadata storage/retrieval
     Should have test coverage

2. Error Recovery: In task.context.handler.ts line 176, when a requested worker is not found, it only logs a warning. Consider whether this should fail more explicitly.

3. Type Safety: The workingDirectory field is added dynamically to various objects. Consider adding proper TypeScript types to the schemas.

4. Security Consideration: The CLI installer copies and executes Python scripts. Ensure proper validation of script sources.

🔧 Suggestions for Improvement

1. Add Integration Tests:

   // Example test for workingDir propagation
   it('should preserve workingDirectory through task context', async () => {
     const workingDir = '/test/project';
     // Test instance registration with metadata
     // Test context generation with workingDir
     // Verify sampling receives correct cwd
   });

2. Type Definitions: Add workingDirectory to schemas:

   // In system.schema.ts
   export const instanceMetadata = z.object({
     workingDirectory: z.string().optional(),
     // ... other fields
   });

3. CLI Version Management: Add version checking to prevent compatibility issues:

   // In claudebench-init.ts
   if (args.includes('--version')) {
     console.log(`ClaudeBench Init v${VERSION}`);
     process.exit(0);
   }

4. Documentation Enhancement: Consider adding:

   • Troubleshooting section for common relay issues
   • Examples of multi-repo workflows
   • Migration guide for existing projects

📊 Performance Considerations

• The relay wrapper spawns Python processes - consider monitoring resource usage
• Multiple workers with different workingDirs may increase memory footprint
• Redis metadata storage is efficient but ensure cleanup of stale instances

🔐 Security Notes

• Working directories are passed to the SDK's cwd parameter - ensure path validation
• The CLI installer modifies package.json - validate JSON parsing errors
• Python relay script execution should validate environment variables

✨ Overall Assessment

This is a solid implementation that extends ClaudeBench to support multi-repository workflows. The code follows project conventions well and includes good documentation. The main areas for improvement are:

1. Add test coverage for the new functionality
2. Strengthen type safety with proper schema updates
3. Consider error handling improvements for edge cases

The PR accomplishes its goal of adding multi-repo support effectively. With test coverage added, this would be ready for production use.

---

Recommendation: Approve with suggestions - The implementation is functional and well-structured, but would benefit from test coverage before merging.