feat: project views

[fblgit]

This PR:

• feat: adds a project view filter in the kanban board (by status, by project)
• feat: /projects board for projects creation and management

[claude]

Claude finished @fblgit's task —— View job

---

Code Review: Project Views Feature

I've completed my review of this PR that adds project view filtering and project management capabilities to ClaudeBench. Here's my comprehensive feedback:

✅ Strengths

1. Architecture Compliance: The implementation follows the ClaudeBench event-driven architecture properly:

   • New handlers use the @eventhandler decorator correctly
   • Schemas are properly defined with Zod v3
   • Event naming follows the domain.action convention

2. Good Integration: The project feature integrates well with existing task management:

   • Projects are tasks with type: "project" metadata
   • Subtasks maintain proper relationships via projectId and parentTaskId
   • Reuses existing task handlers for creation and updates

3. User Experience: The UI implementation provides good functionality:

   • Project filtering in the Kanban board
   • Dedicated /projects route for project management
   • Visual project cards with progress indicators
   • Group by project view mode

⚠️ Issues and Recommendations

1. Handler Length Violation (High Priority)

The TaskCreateProjectHandler is 373 lines, violating the CLAUDE.md guideline of <50 lines per handler. Consider breaking it down:

• Extract the task creation loop into a separate handler
• Move dependency mapping logic to a utility function
• Consider using a saga pattern for the multi-step project creation process

2. Missing Lua Scripts for Atomicity (High Priority)

The task.get_project.handler.ts performs multiple Redis operations that should be atomic:

// Lines 46-49 & 109-119: Multiple Redis operations that should be atomic
const redisTaskId = await redis.pub.hget(projectKey, "parentTaskId");
// ... later ...
const redisData = await redis.pub.hgetall(projectKey);

Per CLAUDE.md, all Redis operations should use Lua scripts for atomicity.

3. Type Safety Issues (Medium Priority)

Several places use 'any' type which bypasses TypeScript's type safety:

• Line 36 in task.get_project.handler.ts: const metadata = taskData.metadata as any;
• Line 107: let projectMetadata: any = {};
• Line 174: metadata: parentTask.metadata as any,

Define proper types for metadata structures instead.

4. Missing Error Boundaries (Medium Priority)

The React components lack error boundaries for handling failures gracefully. Add error boundaries especially for:

• ProjectDetailView component
• ProjectList component
• Project filtering in TaskKanban

5. Performance Concerns (Medium Priority)

• The task.get_project.handler.ts makes sequential database queries. Consider using Promise.all() for parallel fetching where possible
• The project creation process creates many tasks sequentially. Consider batching or parallel creation
• No pagination for project lists which could be problematic with many projects

6. Security Considerations (Low Priority)

• Project IDs are predictable (proj-{timestamp}-{random}). Consider using UUIDs
• No validation on project constraints/requirements array size limits
• Missing rate limiting on project view endpoints (only on creation)

📝 Test Coverage Gaps

Critical: No test files found for the new project functionality. You need:

1. Contract Tests (apps/server/tests/contract/):

   • task.create_project.test.ts
   • task.get_project.test.ts

2. Integration Tests (apps/server/tests/integration/):

   • Test Redis key creation and TTL
   • Verify project-task relationships
   • Test decomposition trigger
   • Validate attachment creation

3. Frontend Tests:

   • ProjectCard component tests
   • Project filtering in Kanban
   • useProjects hook tests

🔧 Actionable Improvements

1. Immediate: Split the large handler into smaller, focused handlers
2. Immediate: Add Lua scripts for atomic Redis operations
3. Important: Add comprehensive test coverage before merging
4. Important: Replace 'any' types with proper type definitions
5. Nice-to-have: Add pagination for project lists
6. Nice-to-have: Implement error boundaries in React components

📋 Checklist Before Merge

• Refactor TaskCreateProjectHandler to be <50 lines
• Add Lua scripts for atomic Redis operations
• Add contract tests for both new handlers
• Add integration tests for Redis/Prisma side effects
• Fix TypeScript 'any' type usage
• Add error handling in React components
• Consider adding pagination for large project lists

Overall, this is a solid foundation for project management, but it needs refinement to meet the codebase standards, especially around handler size, atomicity, and test coverage. The architecture is sound and the UX improvements are valuable.