> ## 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.

# Reviews & Sign-offs

> Understanding the review and approval process

CharleOS uses reviews and sign-offs to ensure quality at each phase. This guide explains who reviews what, how the process works, and what happens when work needs changes.

## Review overview

Reviews are quality gates that work must pass through:

* **Design review** - Client approves visual designs
* **Internal QA review** - Internal testing and approval
* **External QA review** - Client tests and approves work
* **Deployment sign-off** - Final approval before going live

<Info>
  Not all subtasks require review. Only design, QA, and deployment subtasks go through formal review processes.
</Info>

## Reviewable subtasks

Five subtask types require review:

| Subtask Type           | Reviewer            | Outcome Options           |
| ---------------------- | ------------------- | ------------------------- |
| Design                 | Client or Internal  | Approve / Request Changes |
| Client Design Feedback | Client or Internal  | Approve / Request Changes |
| Internal QA Review     | QA Team or Manager  | Pass / Fail               |
| External QA Review     | Client              | Approve / Request Changes |
| Deployment             | PM, CSM, or Manager | Sign-off / Fail           |

## Review workflow

### Standard review process

<Steps>
  <Step title="Work completed">
    Assignee completes the subtask
  </Step>

  <Step title="Awaiting review">
    Status changes to "Awaiting Review"
  </Step>

  <Step title="Reviewer notified">
    System notifies appropriate reviewer
  </Step>

  <Step title="Review submitted">
    Reviewer approves or requests changes
  </Step>

  <Step title="Next action">
    Work proceeds or fix subtask created
  </Step>
</Steps>

## Design reviews

### When design is complete

1. Designer completes design subtask
2. Provides handoff URL (Figma link, etc.)
3. Status becomes "Awaiting Review"

### Review process

**Internal review:**

* PM or CSM reviews design internally
* Checks alignment with requirements
* Approves or requests changes

**Client review:**

* Design sent to client via portal
* Client provides feedback
* Approves or requests changes

### Outcomes

**Approved:**

* Design subtask marked complete
* Task moves to Development phase

**Changes requested:**

* "Client Design Feedback" subtask created
* Assigned to original designer
* Designer incorporates feedback
* Returns to review
* Iteration count increments

<Tip>
  Get internal design approval before sending to client to avoid unnecessary client feedback loops.
</Tip>

## Internal QA reviews

### When development is complete

1. Developer completes development subtask
2. Provides:
   * Branch name
   * Preview/staging URL
   * Testing notes
3. Internal QA review subtask becomes available

### QA testing process

<Steps>
  <Step title="QA assigns themselves">
    QA team member takes the review
  </Step>

  <Step title="Test the work">
    * Check functionality
    * Test edge cases
    * Verify requirements met
    * Document issues found
  </Step>

  <Step title="Mark outcome">
    Pass or Fail with notes
  </Step>
</Steps>

### Pass outcome

When QA passes:

* Internal QA subtask marked complete
* Task moves to External QA phase
* Notifications sent to CSM/PM
* Work ready for client review

### Fail outcome

When QA fails:

1. QA provides failure notes/issues
2. System creates "Internal QA Fixes" subtask
3. Auto-assigned to original developer
4. Task returns to Development phase
5. Developer fixes issues
6. Returns to Internal QA for re-test
7. Iteration increments

<Warning>
  QA failures significantly impact timeline. Encourage developers to self-test thoroughly before handing to QA.
</Warning>

## External QA reviews

### Sending to client

After internal QA passes:

1. CSM or PM clicks "Send to Client"
2. Client receives notification
3. Work appears in client portal for review
4. External QA review subtask status updates

### Client testing

Clients review work via portal:

* Access preview/staging URL
* Test functionality
* Provide feedback via review form
* Choose outcome: Approve or Request Changes

### Approve outcome

When client approves:

* External QA subtask marked complete
* Task moves to Deployment phase
* Notifications sent to PM
* Work ready for production deploy

### Request changes outcome

When client requests changes:

1. Client provides feedback and issues
2. System creates "External QA Fixes" subtask
3. Auto-assigned to original developer
4. Task returns to Development phase
5. Developer fixes issues
6. Goes through Internal QA again
7. Returns to External QA for re-review
8. Iteration increments

<Note>
  External QA fixes must pass through Internal QA again before returning to the client. This ensures quality.
</Note>

## Deployment sign-offs

### After external QA approval

1. Deployment subtask scheduled
2. Assigned to appropriate person (PM/DevOps)
3. Work deployed to production

### Deployment process

<Steps>
  <Step title="Deploy to production">
    Deploy work to live environment
  </Step>

  <Step title="Verify deployment">
    Confirm work is live and functioning
  </Step>

  <Step title="Sign-off">
    PM, CSM, or Manager signs off deployment
  </Step>
</Steps>

### Sign-off outcomes

**Approved:**

* Deployment subtask marked complete
* Task marked complete
* Notifications sent to team and client
* Work officially launched

**Failed:**

* Deployment subtask stays in progress
* Issues documented
* Fix and re-deploy
* Returns to sign-off process

## Review permissions

### Who can review

| Review Type | Who Can Review           |
| ----------- | ------------------------ |
| Design      | PM, CSM, Manager, Client |
| Internal QA | QA Team Members, Manager |
| External QA | Client Users             |
| Deployment  | PM, CSM, Manager         |

**Important rules:**

* Assignee cannot review their own work
* Reviews require management role or QA work type
* Client reviews done via portal only

## Feedback loops

### Understanding iterations

Iterations track how many times work has been reviewed:

* **Iteration 1**: Initial submission
* **Iteration 2**: First round of fixes
* **Iteration 3+**: Additional fix rounds

### Why iterations matter

High iteration counts indicate:

* Unclear requirements
* Scope creep
* Communication breakdowns
* Estimation problems
* Technical challenges

<Warning>
  Each iteration consumes the feedback budget (20% of estimate). Multiple iterations can exceed budget and impact profitability.
</Warning>

### Monitoring iterations

Track iterations to:

* Identify problematic requirements
* Improve estimation accuracy
* Spot communication issues
* Inform future quotes

## Review best practices

### For assignees

<CardGroup cols={2}>
  <Card title="Self-test first" icon="vial">
    Test your own work thoroughly before handoff
  </Card>

  <Card title="Clear handoff" icon="arrow-right">
    Provide detailed URLs, notes, and testing instructions
  </Card>

  <Card title="Document decisions" icon="file-text">
    Explain why you made certain choices
  </Card>

  <Card title="Respond quickly" icon="bolt">
    Address feedback promptly to avoid delays
  </Card>
</CardGroup>

### For reviewers

<CardGroup cols={2}>
  <Card title="Review promptly" icon="clock">
    Don't let work sit in review - it blocks progress
  </Card>

  <Card title="Be specific" icon="crosshairs">
    Provide actionable, specific feedback
  </Card>

  <Card title="Check requirements" icon="list-check">
    Verify work meets original requirements
  </Card>

  <Card title="Consider budget" icon="money-bill">
    Balance perfection with budget constraints
  </Card>
</CardGroup>

## Common review scenarios

### Scenario 1: Design needs minor tweaks

**Situation**: Client wants small color/spacing changes

**Process**:

1. Client requests changes
2. Client Design Feedback subtask created
3. Designer makes tweaks (15-30 min)
4. Re-submit for review
5. Client approves
6. Moves to development

### Scenario 2: Development fails Internal QA

**Situation**: QA finds bugs in functionality

**Process**:

1. QA marks as Failed with issue list
2. Internal QA Fixes subtask created
3. Developer debugs and fixes (1-2 hours)
4. Re-submit to QA
5. QA passes
6. Moves to External QA

### Scenario 3: Client finds major issues

**Situation**: Client testing reveals missing functionality

**Process**:

1. Client requests changes with detailed feedback
2. External QA Fixes subtask created
3. Developer addresses issues (4-8 hours)
4. Goes through Internal QA (pass/fail loop possible)
5. Returns to External QA
6. Client re-tests and approves
7. Moves to Deployment

### Scenario 4: Multiple QA failures

**Situation**: Work fails QA multiple times

**Actions**:

* Review requirements with team
* Check if scope changed
* Assess if more time needed
* Consider if right person assigned
* Escalate to PM/CSM if needed

## Review notifications

### Who gets notified

**Design complete:**

* PM, CSM (internal review)
* Client (if sent for review)

**Internal QA ready:**

* QA team

**Internal QA passed:**

* PM, CSM (ready for client)

**External QA ready:**

* Client users

**External QA approved:**

* PM (ready for deployment)

**Deployment complete:**

* PM, CSM, Client

## Troubleshooting

<AccordionGroup>
  <Accordion title="My subtask is stuck in Awaiting Review">
    Follow up with the reviewer. If urgent, escalate to PM or CSM. Check if reviewer has been notified correctly.
  </Accordion>

  <Accordion title="QA keeps failing my work">
    Request a call with QA to understand issues. Review requirements together. Check if acceptance criteria was clear upfront.
  </Accordion>

  <Accordion title="Client is taking too long to review">
    CSM should follow up with client. Set expectations about review turnaround times. Consider escalating if blocking other work.
  </Accordion>

  <Accordion title="I can't review my own subtask">
    By design - assignees cannot review their own work. Ask PM, CSM, or Manager to review.
  </Accordion>
</AccordionGroup>

## Next steps

<CardGroup cols={2}>
  <Card title="Task Phases" icon="bars-progress" href="/user-guide/tasks/task-phases">
    Understand how reviews fit into task phases
  </Card>

  <Card title="Subtasks" icon="list-check" href="/user-guide/tasks/subtasks">
    Learn about subtask types and workflows
  </Card>

  <Card title="Quotes" icon="file-text" href="/user-guide/quotes">
    How clear requirements reduce review iterations
  </Card>

  <Card title="Time Tracking" icon="clock" href="/user-guide/time-tracking">
    Log time on fix subtasks
  </Card>
</CardGroup>