016-2: Backend Automation - Planning Trigger + Task Approval

[frankbria]

Part of #197 - Planning Phase Automation

Scope

This issue covers the backend automation that triggers after PRD generation and the task approval flow.

Tasks

1. Planning Automation Trigger (~2h)

• Modify codeframe/ui/routers/discovery.py
• After PRD generation completes, trigger background task
• Call LeadAgent.generate_issues(sprint_number=1)
• Call LeadAgent.decompose_prd()
• Add WebSocket events:
  • planning_started - when automation begins
  • issues_generated - with count of issues created
  • tasks_decomposed - with count of tasks created
  • tasks_ready - when ready for user review
• Handle errors gracefully (allow retry)

2. Task Approval Endpoint (~1.5h)

• Add POST /api/projects/:id/tasks/approve to tasks.py
• Request body:

  {
    "approved": true,
    "excluded_task_ids": []
  }

• Use PhaseManager to transition to "development"
• Mark approved tasks as "pending" (ready for assignment)
• Broadcast development_started event
• Return approval summary

Acceptance Criteria

• PRD completion triggers automatic issue/task generation
• WebSocket events broadcast at each step
• Task approval transitions phase to "development"
• Excluded tasks are not marked as pending
• All unit tests pass

Dependencies

• Requires: 016-1 (PhaseManager class)

Blocks

• 016-3: Session UI - SessionStatus + PhaseProgress Components #200 (016-4: Create Tasks Button) - needs WebSocket events
• 016-4: Create Tasks Button in DiscoveryProgress #201 (016-5: TaskReview Component) - needs approval endpoint

Files

• codeframe/ui/routers/discovery.py (modify)
• codeframe/ui/routers/tasks.py (modify)
• tests/ui/test_discovery_automation.py (new)
• tests/ui/test_task_approval.py (new)

Effort

~3.5 hours

[traycerai]

Plan

Found the issue! The frontend is sending task_ids (line 111), but the backend expects excluded_task_ids and approved (line 123 in tasks.py). Let me verify the exact mismatch:

Frontend sends:

{
  "task_ids": ["string", "string", ...]
}

Backend expects:

{
  "approved": true,
  "excluded_task_ids": [1, 2, 3]
}

This is causing the HTTP 422 validation error because Pydantic is rejecting the request body - it has an unexpected field task_ids and is missing the required fields approved and excluded_task_ids.

Root Cause Analysis

The HTTP 422 error occurs because of a request body mismatch between the frontend and backend:

The Problem

Frontend (web-ui/src/lib/api.ts, line 111):

approveTaskBreakdown: (projectId: number, taskIds: string[]) =>
  api.post<...>(`/api/projects/${projectId}/tasks/approve`, { task_ids: taskIds })

Backend (codeframe/ui/routers/tasks.py, lines 120-123):

class TaskApprovalRequest(BaseModel):
    approved: bool
    excluded_task_ids: List[int] = Field(default_factory=list)

The frontend sends { "task_ids": [...] } but the backend expects { "approved": bool, "excluded_task_ids": [...] }. Pydantic rejects this with HTTP 422 (Unprocessable Entity) because:

1. The approved field is required but missing
2. The task_ids field is unexpected and not defined in the model

The Fix

You need to update the frontend API client to match the backend contract. Change line 111 in web-ui/src/lib/api.ts:

approveTaskBreakdown: (projectId: number, taskIds: string[]) =>
  api.post<{
    success: boolean;
    message: string;
    approved_count: number;
    project_phase: string;
  }>(`/api/projects/${projectId}/tasks/approve`, { 
    approved: true,
    excluded_task_ids: []  // All selected tasks are approved, none excluded
  }),

However, there's a secondary issue: The frontend is passing taskIds (the selected tasks), but the backend logic expects excluded_task_ids (tasks to exclude). You need to decide on the logic:

Option A (Recommended): Keep the backend logic as-is and update the frontend to send all task IDs as excluded if the user deselected them:

approveTaskBreakdown: (projectId: number, selectedTaskIds: string[], allTaskIds: string[]) =>
  api.post<...>(`/api/projects/${projectId}/tasks/approve`, { 
    approved: true,
    excluded_task_ids: allTaskIds
      .filter(id => !selectedTaskIds.includes(id))
      .map(id => parseInt(id, 10))
  }),

Option B: Update the backend to accept approved_task_ids instead:

class TaskApprovalRequest(BaseModel):
    approved: bool
    approved_task_ids: List[int] = Field(default_factory=list)

Then update the approval logic to only mark those tasks as pending.

I recommend Option A because it maintains the current backend design and the frontend already has all the information needed. The TaskReview component initializes all tasks as selected and tracks deselections, so you can compute the excluded IDs easily.

Import In IDE

🤖 Prompt for AI Agents

Found the issue! The frontend is sending `task_ids` (line 111), but the backend expects `excluded_task_ids` and `approved` (line 123 in tasks.py). Let me verify the exact mismatch:

**Frontend sends:**
```json
{
  "task_ids": ["string", "string", ...]
}
```

**Backend expects:**
```json
{
  "approved": true,
  "excluded_task_ids": [1, 2, 3]
}
```

This is causing the HTTP 422 validation error because Pydantic is rejecting the request body - it has an unexpected field `task_ids` and is missing the required fields `approved` and `excluded_task_ids`.

## Root Cause Analysis

The HTTP 422 error occurs because of a **request body mismatch** between the frontend and backend:

### The Problem

**Frontend (`web-ui/src/lib/api.ts`, line 111):**
```typescript
approveTaskBreakdown: (projectId: number, taskIds: string[]) =>
  api.post<...>(`/api/projects/${projectId}/tasks/approve`, { task_ids: taskIds })
```

**Backend (`codeframe/ui/routers/tasks.py`, lines 120-123):**
```python
class TaskApprovalRequest(BaseModel):
    approved: bool
    excluded_task_ids: List[int] = Field(default_factory=list)
```

The frontend sends `{ "task_ids": [...] }` but the backend expects `{ "approved": bool, "excluded_task_ids": [...] }`. Pydantic rejects this with HTTP 422 (Unprocessable Entity) because:
1. The `approved` field is required but missing
2. The `task_ids` field is unexpected and not defined in the model

### The Fix

You need to **update the frontend API client** to match the backend contract. Change line 111 in `web-ui/src/lib/api.ts`:

```typescript
approveTaskBreakdown: (projectId: number, taskIds: string[]) =>
  api.post<{
    success: boolean;
    message: string;
    approved_count: number;
    project_phase: string;
  }>(`/api/projects/${projectId}/tasks/approve`, { 
    approved: true,
    excluded_task_ids: []  // All selected tasks are approved, none excluded
  }),
```

However, there's a **secondary issue**: The frontend is passing `taskIds` (the selected tasks), but the backend logic expects `excluded_task_ids` (tasks to exclude). You need to decide on the logic:

**Option A (Recommended):** Keep the backend logic as-is and update the frontend to send all task IDs as excluded if the user deselected them:

```typescript
approveTaskBreakdown: (projectId: number, selectedTaskIds: string[], allTaskIds: string[]) =>
  api.post<...>(`/api/projects/${projectId}/tasks/approve`, { 
    approved: true,
    excluded_task_ids: allTaskIds
      .filter(id => !selectedTaskIds.includes(id))
      .map(id => parseInt(id, 10))
  }),
```

**Option B:** Update the backend to accept `approved_task_ids` instead:

```python
class TaskApprovalRequest(BaseModel):
    approved: bool
    approved_task_ids: List[int] = Field(default_factory=list)
```

Then update the approval logic to only mark those tasks as pending.

I recommend **Option A** because it maintains the current backend design and the frontend already has all the information needed. The TaskReview component initializes all tasks as selected and tracks deselections, so you can compute the excluded IDs easily.

---

Execution Information

Branch: main
Commit: 0306a4e

---

💡 Tips

Supported Commands (Inside Comments)

• Use @traycerai generate to iterate on the previous version of the implementation plan.

Supported Commands (Inside Description)

• Add @traycerai ignore anywhere in the ticket description to prevent this ticket from being processed.
• Add @traycerai branch:<branch-name> anywhere in the ticket description to specify the target branch for the implementation plan.

Community

• Join our Discord Community to get help, request features, and share feedback.
• Follow us on X/Twitter for updates and announcements.

[coderabbitai]

📝 CodeRabbit Plan Mode

Generate an implementation plan and prompts that you can use with your favorite coding agent.

• Create Plan

Examples

• Example 1
• Example 2

---

⚠️ Possible Duplicate Issue

• feat: Planning Phase Automation - Bridge PRD to Development #197

🔗 Related PRs

#181 - fix(discovery): Allow starting discovery when project is running but discovery idle [closed]
#191 - feat(e2e): Enable conditional tests and fix discovery startup [merged]
#194 - Fix PRD generation progress tracking UI [merged]
#196 - fix(discovery): Synchronize PRD buttons and fix state persistence on tab revisit [merged]

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[frankbria]

Bug Update: HTTP 422 Error on Task Approval

Observation

Just tested the task approval workflow on https://dev.codeframeapp.com and encountered a different error than the original 400:

Error Details:

• HTTP Status: 422 (Unprocessable Entity)
• Endpoint: POST /api/projects/:id/tasks/approve
• Error Message: "Failed to approve tasks. Please try again"

Test Environment

• Project ID: 3 (test-weather-app)
• Tasks Generated: 16 tasks (8 Core Features + 8 Non-Functional Requirements)
• Tasks Selected: All 16 tasks checked ✅
• Action: Clicked "Approve and Start Development" button

Console Logs

Failed to load resource: server responded with a status of 422 ()
URL: https://api.dev.codeframeapp.com/api/projects/3/tasks/approve
[TaskReview] Task approval failed: Y

Possible Cause

The API is returning 422 (validation error) instead of 400 (bad request). This suggests the request body or state validation on the backend is failing. The original issue mentioned 400, which may indicate the validation logic has changed or evolved.

Note

This is blocking the entire workflow - users cannot progress from Planning Phase to Development Phase.

---

Tested by: Rocket 🦊 via automated workflow testing

[traycerai]

I have updated the Implementation Plan to reflect the recent changes in the ticket.

Previous Plan

Observations

The codebase has well-established patterns for background task execution and WebSocket broadcasting. The discovery router already demonstrates the pattern needed: generate_prd_background() uses BackgroundTasks with asyncio.to_thread() for synchronous operations and broadcasts progress via WebSocket events. The LeadAgent class has the required generate_issues() and decompose_prd() methods. The PhaseManager class (from dependency #16-1) will handle phase transitions. The project model includes a phase field, and tasks have a status field that can be updated to "pending" for approved tasks.

Approach

The implementation follows the existing background task pattern from PRD generation. After PRD completion, trigger a new background task that calls LeadAgent.generate_issues() and LeadAgent.decompose_prd() sequentially, broadcasting WebSocket events at each stage. For task approval, create a new POST endpoint in the tasks router that uses PhaseManager to transition the project phase to "development", updates approved task statuses to "pending", and broadcasts a completion event. This approach maintains consistency with existing patterns and ensures proper error handling and user feedback through WebSocket events.

Implementation Steps

1. Planning Automation Trigger

1.1 Create Planning Background Task Function

In file:codeframe/ui/routers/discovery.py, add a new background task function after generate_prd_background():

async def generate_planning_background(project_id: int, db: Database, api_key: str):

This function should:

• Broadcast planning_started event when automation begins
• Call LeadAgent.generate_issues(sprint_number=1) using asyncio.to_thread()
• Broadcast issues_generated event with count of issues created
• Call LeadAgent.decompose_prd() using asyncio.to_thread()
• Broadcast tasks_decomposed event with count of tasks created
• Broadcast tasks_ready event when ready for user review
• Handle errors gracefully with try-except blocks and broadcast error events
• Follow the same pattern as generate_prd_background() with progress stages

1.2 Modify PRD Generation Completion

In file:codeframe/ui/routers/discovery.py, modify the generate_prd_background() function:

• After broadcasting prd_generation_completed event (around line 119-128)
• Add a call to trigger the planning automation:

  # Trigger planning automation
  background_tasks.add_task(generate_planning_background, project_id, db, api_key)

• Note: You'll need to pass background_tasks parameter to generate_prd_background() function signature
• Update the call site in submit_discovery_answer() endpoint (line 260-262) to pass background_tasks

1.3 Add WebSocket Event Broadcasts

Create helper functions in file:codeframe/ui/websocket_broadcasts.py following existing patterns:

• broadcast_planning_started(manager, project_id) - Notify planning automation begins
• broadcast_issues_generated(manager, project_id, issue_count) - Report issues created
• broadcast_tasks_decomposed(manager, project_id, task_count) - Report tasks created
• broadcast_tasks_ready(manager, project_id, total_tasks) - Signal ready for review

Each function should:

• Follow the pattern of existing broadcast functions (lines 36-787)
• Include type, project_id, relevant data, and timestamp fields
• Use datetime.now(UTC).isoformat().replace("+00:00", "Z") for timestamps
• Handle exceptions with try-except and log errors

2. Task Approval Endpoint

2.1 Create Request/Response Models

In file:codeframe/ui/routers/tasks.py, add Pydantic models after existing models (after line 36):

class TaskApprovalRequest(BaseModel):
    """Request model for task approval."""
    approved: bool
    excluded_task_ids: List[int] = Field(default_factory=list)

class TaskApprovalResponse(BaseModel):
    """Response model for task approval."""
    success: bool
    phase: str
    approved_count: int
    excluded_count: int
    message: str

2.2 Create Approval Endpoint

In file:codeframe/ui/routers/tasks.py, add new endpoint:

@router.post("/api/projects/{project_id}/tasks/approve")
async def approve_tasks(
    project_id: int,
    request: TaskApprovalRequest,
    db: Database = Depends(get_db),
    current_user: User = Depends(get_current_user),
):

Implementation steps:

1. Verify project exists and user has access (follow pattern from create_task())
2. If request.approved is False, return early with rejection message
3. Import and use PhaseManager to transition phase to "development":

   from codeframe.core.phase_manager import PhaseManager
   phase_manager = PhaseManager(db)
   await asyncio.to_thread(phase_manager.transition_to_development, project_id)

4. Get all tasks for the project using db.get_project_tasks(project_id)
5. Filter out excluded tasks based on request.excluded_task_ids
6. Update approved tasks to status "pending" using db.update_task(task_id, {"status": "pending"})
7. Broadcast development_started event via WebSocket
8. Return TaskApprovalResponse with summary statistics

2.3 Add Development Started Broadcast

In file:codeframe/ui/websocket_broadcasts.py, add:

async def broadcast_development_started(
    manager, project_id: int, approved_count: int, excluded_count: int
):

Follow existing broadcast patterns with appropriate message structure.

2.4 Import WebSocket Manager

In file:codeframe/ui/routers/tasks.py, add import at the top:

from codeframe.ui.shared import manager

3. Error Handling and Retry Support

3.1 Planning Automation Error Handling

In generate_planning_background():

• Wrap each stage in try-except blocks
• Broadcast specific error events: planning_failed, issues_generation_failed, tasks_decomposition_failed
• Include error message and allow retry by not updating project phase on failure
• Log errors with full stack traces using logger.error()

3.2 Task Approval Validation

In approve_tasks() endpoint:

• Validate project is in "planning" phase before allowing approval
• Return HTTP 400 if project is not in correct phase
• Validate that tasks exist for the project
• Return HTTP 404 if no tasks found

4. Testing

4.1 Create Discovery Automation Tests

Create file:tests/ui/test_discovery_automation.py:

Test cases:

• test_planning_automation_triggered_after_prd - Verify background task is triggered
• test_issues_generated_successfully - Mock LeadAgent.generate_issues() and verify WebSocket events
• test_tasks_decomposed_successfully - Mock LeadAgent.decompose_prd() and verify WebSocket events
• test_planning_automation_error_handling - Verify error broadcasts and retry capability
• test_websocket_events_broadcast_correctly - Verify all 4 events are sent with correct data

Follow existing test patterns from file:tests/ui/test_websocket_broadcasts.py and file:tests/ui/conftest.py for fixtures.

4.2 Create Task Approval Tests

Create file:tests/ui/test_task_approval.py:

Test cases:

• test_approve_tasks_success - Verify phase transition and task status updates
• test_approve_tasks_with_exclusions - Verify excluded tasks remain unchanged
• test_approve_tasks_rejection - Verify rejection flow when approved=False
• test_approve_tasks_wrong_phase - Verify 400 error if not in planning phase
• test_approve_tasks_no_tasks - Verify 404 error if no tasks exist
• test_development_started_broadcast - Verify WebSocket event is sent

Use pytest fixtures for database setup, mock PhaseManager, and mock WebSocket manager.

Sequence Diagram

sequenceDiagram
    participant User
    participant API as Discovery API
    participant BG as Background Task
    participant LA as LeadAgent
    participant DB as Database
    participant WS as WebSocket

    User->>API: Submit final discovery answer
    API->>LA: process_discovery_answer()
    API->>BG: generate_prd_background()
    BG->>WS: prd_generation_started
    BG->>LA: generate_prd()
    BG->>DB: Save PRD
    BG->>WS: prd_generation_completed
    BG->>BG: Trigger planning automation
    BG->>WS: planning_started
    BG->>LA: generate_issues(sprint_number=1)
    LA->>DB: Save issues
    BG->>WS: issues_generated (count)
    BG->>LA: decompose_prd()
    LA->>DB: Save tasks
    BG->>WS: tasks_decomposed (count)
    BG->>WS: tasks_ready
    
    User->>API: POST /tasks/approve
    API->>DB: Get project & tasks
    API->>DB: PhaseManager.transition_to_development()
    API->>DB: Update task statuses to "pending"
    API->>WS: development_started
    API->>User: Approval summary

Loading

Files to Modify

• file:codeframe/ui/routers/discovery.py - Add planning automation background task
• file:codeframe/ui/routers/tasks.py - Add task approval endpoint
• file:codeframe/ui/websocket_broadcasts.py - Add 5 new broadcast functions

Files to Create

• file:tests/ui/test_discovery_automation.py - Planning automation tests
• file:tests/ui/test_task_approval.py - Task approval tests

Dependencies

• Requires PhaseManager class from issue Enhanced Verification and Reporting #16-1 with method transition_to_development(project_id)
• If PhaseManager is not yet implemented, use direct database update: db.update_project(project_id, {"phase": "development"})

Integration Points

• WebSocket events integrate with frontend components in issues 016-3: Session UI - SessionStatus + PhaseProgress Components #200 and 016-4: Create Tasks Button in DiscoveryProgress #201
• Planning automation runs automatically after PRD generation
• Task approval endpoint enables user review workflow before development phase

Import In IDE

🤖 Prompt for AI Agents

## Observations

The codebase has well-established patterns for background task execution and WebSocket broadcasting. The discovery router already demonstrates the pattern needed: `generate_prd_background()` uses `BackgroundTasks` with `asyncio.to_thread()` for synchronous operations and broadcasts progress via WebSocket events. The `LeadAgent` class has the required `generate_issues()` and `decompose_prd()` methods. The `PhaseManager` class (from dependency #016-1) will handle phase transitions. The project model includes a `phase` field, and tasks have a `status` field that can be updated to "pending" for approved tasks.

## Approach

The implementation follows the existing background task pattern from PRD generation. After PRD completion, trigger a new background task that calls `LeadAgent.generate_issues()` and `LeadAgent.decompose_prd()` sequentially, broadcasting WebSocket events at each stage. For task approval, create a new POST endpoint in the tasks router that uses `PhaseManager` to transition the project phase to "development", updates approved task statuses to "pending", and broadcasts a completion event. This approach maintains consistency with existing patterns and ensures proper error handling and user feedback through WebSocket events.

## Implementation Steps

### 1. Planning Automation Trigger

#### 1.1 Create Planning Background Task Function
In `file:codeframe/ui/routers/discovery.py`, add a new background task function after `generate_prd_background()`:

```python
async def generate_planning_background(project_id: int, db: Database, api_key: str):
```

This function should:
- Broadcast `planning_started` event when automation begins
- Call `LeadAgent.generate_issues(sprint_number=1)` using `asyncio.to_thread()`
- Broadcast `issues_generated` event with count of issues created
- Call `LeadAgent.decompose_prd()` using `asyncio.to_thread()`
- Broadcast `tasks_decomposed` event with count of tasks created
- Broadcast `tasks_ready` event when ready for user review
- Handle errors gracefully with try-except blocks and broadcast error events
- Follow the same pattern as `generate_prd_background()` with progress stages

#### 1.2 Modify PRD Generation Completion
In `file:codeframe/ui/routers/discovery.py`, modify the `generate_prd_background()` function:

- After broadcasting `prd_generation_completed` event (around line 119-128)
- Add a call to trigger the planning automation:
  ```python
  # Trigger planning automation
  background_tasks.add_task(generate_planning_background, project_id, db, api_key)
  ```
- Note: You'll need to pass `background_tasks` parameter to `generate_prd_background()` function signature
- Update the call site in `submit_discovery_answer()` endpoint (line 260-262) to pass `background_tasks`

#### 1.3 Add WebSocket Event Broadcasts
Create helper functions in `file:codeframe/ui/websocket_broadcasts.py` following existing patterns:

- `broadcast_planning_started(manager, project_id)` - Notify planning automation begins
- `broadcast_issues_generated(manager, project_id, issue_count)` - Report issues created
- `broadcast_tasks_decomposed(manager, project_id, task_count)` - Report tasks created
- `broadcast_tasks_ready(manager, project_id, total_tasks)` - Signal ready for review

Each function should:
- Follow the pattern of existing broadcast functions (lines 36-787)
- Include `type`, `project_id`, relevant data, and `timestamp` fields
- Use `datetime.now(UTC).isoformat().replace("+00:00", "Z")` for timestamps
- Handle exceptions with try-except and log errors

### 2. Task Approval Endpoint

#### 2.1 Create Request/Response Models
In `file:codeframe/ui/routers/tasks.py`, add Pydantic models after existing models (after line 36):

```python
class TaskApprovalRequest(BaseModel):
    """Request model for task approval."""
    approved: bool
    excluded_task_ids: List[int] = Field(default_factory=list)

class TaskApprovalResponse(BaseModel):
    """Response model for task approval."""
    success: bool
    phase: str
    approved_count: int
    excluded_count: int
    message: str
```

#### 2.2 Create Approval Endpoint
In `file:codeframe/ui/routers/tasks.py`, add new endpoint:

```python
@router.post("/api/projects/{project_id}/tasks/approve")
async def approve_tasks(
    project_id: int,
    request: TaskApprovalRequest,
    db: Database = Depends(get_db),
    current_user: User = Depends(get_current_user),
):
```

Implementation steps:
1. Verify project exists and user has access (follow pattern from `create_task()`)
2. If `request.approved` is False, return early with rejection message
3. Import and use `PhaseManager` to transition phase to "development":
   ```python
   from codeframe.core.phase_manager import PhaseManager
   phase_manager = PhaseManager(db)
   await asyncio.to_thread(phase_manager.transition_to_development, project_id)
   ```
4. Get all tasks for the project using `db.get_project_tasks(project_id)`
5. Filter out excluded tasks based on `request.excluded_task_ids`
6. Update approved tasks to status "pending" using `db.update_task(task_id, {"status": "pending"})`
7. Broadcast `development_started` event via WebSocket
8. Return `TaskApprovalResponse` with summary statistics

#### 2.3 Add Development Started Broadcast
In `file:codeframe/ui/websocket_broadcasts.py`, add:

```python
async def broadcast_development_started(
    manager, project_id: int, approved_count: int, excluded_count: int
):
```

Follow existing broadcast patterns with appropriate message structure.

#### 2.4 Import WebSocket Manager
In `file:codeframe/ui/routers/tasks.py`, add import at the top:

```python
from codeframe.ui.shared import manager
```

### 3. Error Handling and Retry Support

#### 3.1 Planning Automation Error Handling
In `generate_planning_background()`:
- Wrap each stage in try-except blocks
- Broadcast specific error events: `planning_failed`, `issues_generation_failed`, `tasks_decomposition_failed`
- Include error message and allow retry by not updating project phase on failure
- Log errors with full stack traces using `logger.error()`

#### 3.2 Task Approval Validation
In `approve_tasks()` endpoint:
- Validate project is in "planning" phase before allowing approval
- Return HTTP 400 if project is not in correct phase
- Validate that tasks exist for the project
- Return HTTP 404 if no tasks found

### 4. Testing

#### 4.1 Create Discovery Automation Tests
Create `file:tests/ui/test_discovery_automation.py`:

Test cases:
- `test_planning_automation_triggered_after_prd` - Verify background task is triggered
- `test_issues_generated_successfully` - Mock `LeadAgent.generate_issues()` and verify WebSocket events
- `test_tasks_decomposed_successfully` - Mock `LeadAgent.decompose_prd()` and verify WebSocket events
- `test_planning_automation_error_handling` - Verify error broadcasts and retry capability
- `test_websocket_events_broadcast_correctly` - Verify all 4 events are sent with correct data

Follow existing test patterns from `file:tests/ui/test_websocket_broadcasts.py` and `file:tests/ui/conftest.py` for fixtures.

#### 4.2 Create Task Approval Tests
Create `file:tests/ui/test_task_approval.py`:

Test cases:
- `test_approve_tasks_success` - Verify phase transition and task status updates
- `test_approve_tasks_with_exclusions` - Verify excluded tasks remain unchanged
- `test_approve_tasks_rejection` - Verify rejection flow when `approved=False`
- `test_approve_tasks_wrong_phase` - Verify 400 error if not in planning phase
- `test_approve_tasks_no_tasks` - Verify 404 error if no tasks exist
- `test_development_started_broadcast` - Verify WebSocket event is sent

Use pytest fixtures for database setup, mock `PhaseManager`, and mock WebSocket manager.

## Sequence Diagram

```mermaid
sequenceDiagram
    participant User
    participant API as Discovery API
    participant BG as Background Task
    participant LA as LeadAgent
    participant DB as Database
    participant WS as WebSocket

    User->>API: Submit final discovery answer
    API->>LA: process_discovery_answer()
    API->>BG: generate_prd_background()
    BG->>WS: prd_generation_started
    BG->>LA: generate_prd()
    BG->>DB: Save PRD
    BG->>WS: prd_generation_completed
    BG->>BG: Trigger planning automation
    BG->>WS: planning_started
    BG->>LA: generate_issues(sprint_number=1)
    LA->>DB: Save issues
    BG->>WS: issues_generated (count)
    BG->>LA: decompose_prd()
    LA->>DB: Save tasks
    BG->>WS: tasks_decomposed (count)
    BG->>WS: tasks_ready
    
    User->>API: POST /tasks/approve
    API->>DB: Get project & tasks
    API->>DB: PhaseManager.transition_to_development()
    API->>DB: Update task statuses to "pending"
    API->>WS: development_started
    API->>User: Approval summary
```

## Files to Modify

- `file:codeframe/ui/routers/discovery.py` - Add planning automation background task
- `file:codeframe/ui/routers/tasks.py` - Add task approval endpoint
- `file:codeframe/ui/websocket_broadcasts.py` - Add 5 new broadcast functions

## Files to Create

- `file:tests/ui/test_discovery_automation.py` - Planning automation tests
- `file:tests/ui/test_task_approval.py` - Task approval tests

## Dependencies

- Requires `PhaseManager` class from issue #016-1 with method `transition_to_development(project_id)`
- If `PhaseManager` is not yet implemented, use direct database update: `db.update_project(project_id, {"phase": "development"})`

## Integration Points

- WebSocket events integrate with frontend components in issues #200 and #201
- Planning automation runs automatically after PRD generation
- Task approval endpoint enables user review workflow before development phase

---

Execution Information

Branch: main
Commit: 02f1413

New Plan

Found the issue! The frontend is sending task_ids (line 111), but the backend expects excluded_task_ids and approved (line 123 in tasks.py). Let me verify the exact mismatch:

Frontend sends:

{
  "task_ids": ["string", "string", ...]
}

Backend expects:

{
  "approved": true,
  "excluded_task_ids": [1, 2, 3]
}

This is causing the HTTP 422 validation error because Pydantic is rejecting the request body - it has an unexpected field task_ids and is missing the required fields approved and excluded_task_ids.

Root Cause Analysis

The HTTP 422 error occurs because of a request body mismatch between the frontend and backend:

The Problem

Frontend (web-ui/src/lib/api.ts, line 111):

approveTaskBreakdown: (projectId: number, taskIds: string[]) =>
  api.post<...>(`/api/projects/${projectId}/tasks/approve`, { task_ids: taskIds })

Backend (codeframe/ui/routers/tasks.py, lines 120-123):

class TaskApprovalRequest(BaseModel):
    approved: bool
    excluded_task_ids: List[int] = Field(default_factory=list)

The frontend sends { "task_ids": [...] } but the backend expects { "approved": bool, "excluded_task_ids": [...] }. Pydantic rejects this with HTTP 422 (Unprocessable Entity) because:

1. The approved field is required but missing
2. The task_ids field is unexpected and not defined in the model

The Fix

You need to update the frontend API client to match the backend contract. Change line 111 in web-ui/src/lib/api.ts:

approveTaskBreakdown: (projectId: number, taskIds: string[]) =>
  api.post<{
    success: boolean;
    message: string;
    approved_count: number;
    project_phase: string;
  }>(`/api/projects/${projectId}/tasks/approve`, { 
    approved: true,
    excluded_task_ids: []  // All selected tasks are approved, none excluded
  }),

However, there's a secondary issue: The frontend is passing taskIds (the selected tasks), but the backend logic expects excluded_task_ids (tasks to exclude). You need to decide on the logic:

Option A (Recommended): Keep the backend logic as-is and update the frontend to send all task IDs as excluded if the user deselected them:

approveTaskBreakdown: (projectId: number, selectedTaskIds: string[], allTaskIds: string[]) =>
  api.post<...>(`/api/projects/${projectId}/tasks/approve`, { 
    approved: true,
    excluded_task_ids: allTaskIds
      .filter(id => !selectedTaskIds.includes(id))
      .map(id => parseInt(id, 10))
  }),

Option B: Update the backend to accept approved_task_ids instead:

class TaskApprovalRequest(BaseModel):
    approved: bool
    approved_task_ids: List[int] = Field(default_factory=list)

Then update the approval logic to only mark those tasks as pending.

I recommend Option A because it maintains the current backend design and the frontend already has all the information needed. The TaskReview component initializes all tasks as selected and tracks deselections, so you can compute the excluded IDs easily.

Import In IDE

🤖 Prompt for AI Agents

Found the issue! The frontend is sending `task_ids` (line 111), but the backend expects `excluded_task_ids` and `approved` (line 123 in tasks.py). Let me verify the exact mismatch:

**Frontend sends:**
```json
{
  "task_ids": ["string", "string", ...]
}
```

**Backend expects:**
```json
{
  "approved": true,
  "excluded_task_ids": [1, 2, 3]
}
```

This is causing the HTTP 422 validation error because Pydantic is rejecting the request body - it has an unexpected field `task_ids` and is missing the required fields `approved` and `excluded_task_ids`.

## Root Cause Analysis

The HTTP 422 error occurs because of a **request body mismatch** between the frontend and backend:

### The Problem

**Frontend (`web-ui/src/lib/api.ts`, line 111):**
```typescript
approveTaskBreakdown: (projectId: number, taskIds: string[]) =>
  api.post<...>(`/api/projects/${projectId}/tasks/approve`, { task_ids: taskIds })
```

**Backend (`codeframe/ui/routers/tasks.py`, lines 120-123):**
```python
class TaskApprovalRequest(BaseModel):
    approved: bool
    excluded_task_ids: List[int] = Field(default_factory=list)
```

The frontend sends `{ "task_ids": [...] }` but the backend expects `{ "approved": bool, "excluded_task_ids": [...] }`. Pydantic rejects this with HTTP 422 (Unprocessable Entity) because:
1. The `approved` field is required but missing
2. The `task_ids` field is unexpected and not defined in the model

### The Fix

You need to **update the frontend API client** to match the backend contract. Change line 111 in `web-ui/src/lib/api.ts`:

```typescript
approveTaskBreakdown: (projectId: number, taskIds: string[]) =>
  api.post<{
    success: boolean;
    message: string;
    approved_count: number;
    project_phase: string;
  }>(`/api/projects/${projectId}/tasks/approve`, { 
    approved: true,
    excluded_task_ids: []  // All selected tasks are approved, none excluded
  }),
```

However, there's a **secondary issue**: The frontend is passing `taskIds` (the selected tasks), but the backend logic expects `excluded_task_ids` (tasks to exclude). You need to decide on the logic:

**Option A (Recommended):** Keep the backend logic as-is and update the frontend to send all task IDs as excluded if the user deselected them:

```typescript
approveTaskBreakdown: (projectId: number, selectedTaskIds: string[], allTaskIds: string[]) =>
  api.post<...>(`/api/projects/${projectId}/tasks/approve`, { 
    approved: true,
    excluded_task_ids: allTaskIds
      .filter(id => !selectedTaskIds.includes(id))
      .map(id => parseInt(id, 10))
  }),
```

**Option B:** Update the backend to accept `approved_task_ids` instead:

```python
class TaskApprovalRequest(BaseModel):
    approved: bool
    approved_task_ids: List[int] = Field(default_factory=list)
```

Then update the approval logic to only mark those tasks as pending.

I recommend **Option A** because it maintains the current backend design and the frontend already has all the information needed. The TaskReview component initializes all tasks as selected and tracks deselections, so you can compute the excluded IDs easily.

---

Execution Information

Branch: main
Commit: 0306a4e