Task Phases

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:

​

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

​

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

​

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

​

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

​

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:

​

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

​

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

​

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

​

Next steps