> ## Documentation Index
> Fetch the complete documentation index at: https://docs.charle.agency/llms.txt
> Use this file to discover all available pages before exploring further.

# Task Phases

> Understanding task workflow phases and transitions

Tasks in CharleOS progress through structured phases from design through deployment. This guide explains each phase, how transitions work, and what happens at each stage.

## Phase overview

Tasks follow a sequential workflow through these phases:

<Steps>
  <Step title="Backlog">
    Task created, not yet planned
  </Step>

  <Step title="Planned">
    Scheduled for delivery
  </Step>

  <Step title="Design">
    Visual design work
  </Step>

  <Step title="Development">
    Building features
  </Step>

  <Step title="Internal QA">
    Team testing
  </Step>

  <Step title="External QA">
    Client review
  </Step>

  <Step title="Deployment">
    Production deploy
  </Step>

  <Step title="Complete">
    All work finished
  </Step>
</Steps>

<Info>
  Phases can be skipped. For example, bug fixes often skip the Design phase and go straight to Development.
</Info>

## The seven phases

### 1. Backlog

**What it means:**

* Task created but not yet scheduled
* No subtasks have dates or assignees
* Not yet prioritized for delivery

**How it gets here:**

* Task created from approved quote
* Task created manually by CSM/Manager

**Next step:**

* Add to client roadmap for a specific month
* Moves to Planned phase

<Tip>
  Use backlog for collecting work that will be scheduled later. Don't leave tasks in backlog too long - prioritize them monthly.
</Tip>

### 2. Planned

**What it means:**

* Task added to a specific month's roadmap
* Ready to be scheduled
* Subtasks not yet assigned dates

**How it gets here:**

* PM or CSM adds task to a specific month's roadmap
* Appears in client's schedule Planner

**Next step:**

* PM schedules subtasks (assigns dates and team members)
* Moves to first work phase (Design or Development)

### 3. Design

**What it means:**

* Visual design work in progress
* Designer creating mockups, prototypes
* May require client feedback

**Subtask types:**

* `design` - Initial design work
* `client_design_feedback` - Incorporating client feedback (created dynamically)

**How it gets here:**

* First subtask in Design phase is started
* OR if all subtasks scheduled but none started, phase shows as Design

**Next step:**

* Design approved (internally or by client)
* Moves to Development phase

<Note>
  The Design phase is optional. Tasks without design requirements skip straight to Development.
</Note>

### 4. Development

**What it means:**

* Building the feature or fix
* Writing code, implementing functionality
* Includes fixing issues from QA

**Subtask types:**

* `development` - Core development work
* `internal_qa_fixes` - Fixes from internal QA (created dynamically)
* `external_qa_fixes` - Fixes from client QA (created dynamically)

**How it gets here:**

* Design phase completes
* OR task starts here if no design required

**Next step:**

* Development complete
* Moves to Internal QA phase

### 5. Internal QA

**What it means:**

* Team testing the work
* QA team reviewing functionality
* Pass/fail review required

**Subtask types:**

* `internal_qa_review` - Internal testing and review

**How it gets here:**

* Development phase completes

**Possible outcomes:**

* **Pass**: Creates external QA review, moves to External QA phase
* **Fail**: Creates fix subtask and new QA review round, returns to Development phase

<Warning>
  Internal QA is a quality gate. Work cannot proceed to the client until internal QA passes.
</Warning>

### 6. External QA

**What it means:**

* Client reviewing the work
* Client testing functionality
* Client approval required

**Subtask types:**

* `external_qa_review` - Client reviews via portal

**How it gets here:**

* Internal QA passes
* CSM/PM sends work to client

**Possible outcomes:**

* **Approve**: Moves to Deployment phase
* **Request Changes**: Creates `external_qa_fixes` subtask, returns to Development phase

<Tip>
  Set clear expectations with clients about review turnaround time to avoid delays.
</Tip>

### 7. Deployment

**What it means:**

* Deploying to production
* Making work live for end users
* Final step before completion

**Subtask types:**

* `deployment` - Production deployment

**How it gets here:**

* External QA approved
* OR Internal QA passed (if no external QA required)

**Next step:**

* Deployment signed off
* Task marked complete

## Phase transitions

### Automatic transitions

Phases change automatically when:

1. All subtasks in current phase complete
2. System checks for subtasks in next phase
3. Task moves to next phase with work
4. Status determined by next phase's subtasks

**Example flow:**

1. **Development complete** → Internal QA scheduled → Task moves to Internal QA phase
2. **Internal QA passes** → External QA scheduled → Task moves to External QA phase
3. **External QA approved** → Deployment scheduled → Task moves to Deployment phase
4. **Deployment complete** → All subtasks done → Task marked complete

### Phase skipping

Tasks skip phases without subtasks:

**Bug fix (no design):**
Planned → Development → Internal QA → External QA → Deployment

**Internal improvement (no client QA):**
Planned → Development → Internal QA → Deployment

**Content update (no QA):**
Planned → Development → Deployment

## Phase statuses

Each phase has a status indicating progress:

| Status            | Meaning                                     |
| ----------------- | ------------------------------------------- |
| **Not Scheduled** | No dates assigned yet                       |
| **Scheduled**     | Subtasks have dates but work hasn't started |
| **In Progress**   | Work actively happening                     |
| **With Client**   | Awaiting client action (Design phase only)  |
| **Complete**      | Phase finished                              |

<Info>
  The "With Client" status is only used for the Design phase. External QA uses "In Progress" status since the phase name already implies client involvement.
</Info>

## Feedback loops

### QA failure loops

When QA fails, work loops back:

**Internal QA fails:**

1. QA marks review as "Failed"
2. System creates `internal_qa_fixes` subtask
3. Task returns to Development phase
4. Developer fixes issues
5. Returns to Internal QA for re-testing
6. Iteration count increments

**External QA fails:**

1. Client marks review as "Request Changes"
2. System creates `external_qa_fixes` subtask
3. Task returns to Development phase
4. Developer fixes issues
5. Goes through Internal QA again
6. Returns to External QA
7. Iteration count increments

<Warning>
  Multiple QA failures can significantly impact budget. Monitor iterations to identify estimation or communication issues.
</Warning>

### Design feedback loops

When client requests design changes:

1. Client provides feedback on design
2. System creates `client_design_feedback` subtask
3. Designer incorporates changes
4. Client reviews again
5. Iteration count increments

## Phase-based scheduling

### Phase continuity

CharleOS encourages assigning the same person throughout a phase:

* Developer who built feature also fixes issues
* Maintains context and knowledge
* Faster fixes and fewer communication issues

**Example:**

* Alice builds feature (development subtask)
* Internal QA fails
* Alice automatically suggested for internal\_qa\_fixes
* Client requests changes
* Alice automatically suggested for external\_qa\_fixes

### Capacity planning

Phases affect scheduling:

* **Design**: Designer capacity
* **Development**: Developer capacity
* **QA**: QA team capacity
* **Deployment**: PM/DevOps capacity

<Tip>
  When scheduling, consider that QA phases don't consume retainer hours but do require team capacity.
</Tip>

## Viewing phase information

### Task detail page

The task sidebar shows:

* Current phase badge
* Phase status badge
* Phase icon and color

### Task lists

Tasks display:

* Phase column (sortable)
* Phase filters
* Status badges

### Client schedule

Tasks organized by phase:

* Group by current phase
* Filter to specific phases
* See phase progression

## Best practices

<CardGroup cols={2}>
  <Card title="Don't skip QA" icon="shield-check">
    Always run internal QA before sending to client - it catches issues early
  </Card>

  <Card title="Set realistic dates" icon="calendar-days">
    Account for feedback loops when estimating completion dates
  </Card>

  <Card title="Monitor iterations" icon="chart-line">
    Track how many feedback loops occur to improve estimates
  </Card>

  <Card title="Clear handoffs" icon="arrow-right-arrow-left">
    Provide clear handoff notes between phases to avoid confusion
  </Card>

  <Card title="Phase continuity" icon="link">
    Keep the same developer throughout a feature to maintain context
  </Card>

  <Card title="Client communication" icon="comments">
    Set expectations with clients about review turnaround times
  </Card>
</CardGroup>

## Next steps

<CardGroup cols={2}>
  <Card title="Subtasks" icon="list-check" href="/user-guide/tasks/subtasks">
    Learn how to manage subtasks within phases
  </Card>

  <Card title="Reviews & Sign-offs" icon="circle-check" href="/user-guide/tasks/reviews-signoffs">
    Understand the review and approval process
  </Card>

  <Card title="Client Schedule" icon="calendar" href="/user-guide/clients/client-schedule">
    Learn how to schedule tasks by phase
  </Card>

  <Card title="Time Tracking" icon="clock" href="/user-guide/time-tracking">
    Log time against subtasks in each phase
  </Card>
</CardGroup>