# Backlog Técnico — Execução e Review em Agent Teams Paralelos no TUI

---

## Backlog

| ID | Título | Estimativa | Dependências | Arquivos | Status |
|----|--------|-----------|-------------|----------|--------|
| T-01 | Criar `parallel.rs` com tipos fundacionais e `supports_parallel` | P (2–3h) | — | `src/tui/parallel.rs` (novo), `src/tui/mod.rs` | Done |
| T-02 | Implementar `plan_parallel_slots` | P (2–3h) | T-01 | `src/tui/parallel.rs` | Done |
| T-03 | Implementar `compose_parallel_artifact` e `traceability_table` | P (2–3h) | T-01 | `src/tui/parallel.rs` | Done |
| T-04 | Implementar `spawn_parallel_agent` em `runner.rs` | M (3–4h) | T-01 | `src/tui/runner.rs` | Done |
| T-05 | Estender `App`: campos, variantes de `Screen` e métodos de controle | M (4–5h) | T-01, T-02, T-03, T-04 | `src/tui/app.rs` | Done |
| T-06 | Estender event loop em `mod.rs`: drena N receivers e resolve barreira | P (2–3h) | T-05 | `src/tui/mod.rs` | Done |
| T-07 | Implementar `render_parallel_running` e `render_parallel_decision` | M (3–4h) | T-05 | `src/tui/ui.rs` | Done |
| T-08 | Implementar `update_parallel_decision` (Retentar / Aceitar parcial / Cancelar) | P (2–3h) | T-05 | `src/tui/app.rs` | Done |
| T-09 | Testes de regressão: single-agent e todas as telas | M (3–4h) | T-06, T-07, T-08 | `src/tui/{app,ui,runner}.rs` | Done |

### Tasks independentes entre si (podem rodar em paralelo)

- **Grupo A** (após T-01 concluída): T-02, T-03 e T-04 são independentes entre si.
- **Grupo B** (após T-05 e T-06 concluídas): T-07 e T-08 são independentes entre si.

---

## Dependências

### Grafo de dependências

```
T-01 ──┬──► T-02 ──┐
       ├──► T-03 ──┤
       ├──► T-04 ──┤
       └──────────► T-05
                     │
                     ├──► T-06 ──┐
                     ├──► T-07   ├──► T-09
                     └──► T-08 ──┘
```

### Tabela de dependências

| Tarefa | Depende de | Motivo |
|--------|-----------|--------|
| T-01 | — | Fundação; nenhuma dependência prévia |
| T-02 | T-01 | Requer `TaskRef` e `AgentSlotStatus` |
| T-03 | T-01 | Requer `SlotResult` e `AgentSlotStatus` |
| T-04 | T-01 | Requer `AgentHandle`, `TaskRef` |
| T-05 | T-01, T-02, T-03, T-04 | Chama `plan_parallel_slots`, `spawn_parallel_agent`, `compose_parallel_artifact` |
| T-06 | T-05 | `App::parallel`, `on_parallel_event` e `parallel_barrier_reached` devem existir |
| T-07 | T-05 | `App::parallel` e `parallel_stage` necessários na renderização |
| T-08 | T-05 | `update_parallel_decision` é método de `App` |
| T-09 | T-06, T-07, T-08 | Regressão cobrindo todas as implementações finalizadas |

---

## Critérios de aceite

### T-01 — Tipos fundacionais e `supports_parallel`

```gherkin
Funcionalidade: Tipos fundacionais do módulo parallel

  Cenário: AgentSlotStatus cobre todos os estados do ciclo de vida de um slot
    Dado o enum AgentSlotStatus definido em parallel.rs
    Quando enumeramos suas variantes
    Então existem exatamente quatro: Aguardando, EmExecucao, Concluido e Erro

  Cenário: supports_parallel retorna true apenas para Execution e Review
    Dado a função supports_parallel disponível
    Quando chamada com Stage::Execution
    Então retorna true
    Quando chamada com Stage::Review
    Então retorna true
    Quando chamada com qualquer outra Stage
    Então retorna false

  Cenário: O módulo parallel é registrado em mod.rs
    Dado parallel.rs criado em src/tui/
    Quando compilamos o crate
    Então pub mod parallel está em src/tui/mod.rs e compila sem erros
```

### T-02 — `plan_parallel_slots`

```gherkin
Funcionalidade: Planejamento de slots paralelos a partir do backlog

  Cenário: Retorna lista vazia quando o Markdown não contém tasks
    Dado uma string Markdown vazia passada para plan_parallel_slots
    Quando a função é chamada
    Então retorna Vec::new()

  Cenário: Identifica tasks marcadas como independentes
    Dado um 04-tasks.md com três tasks, duas marcadas como independentes
    Quando plan_parallel_slots é chamada com esse conteúdo
    Então retorna Vec<TaskRef> com as duas tasks com independent = true

  Cenário: Nunca pânica em Markdown malformado
    Dado um 04-tasks.md com formato inesperado
    Quando plan_parallel_slots é chamada
    Então retorna Vec::new() sem panic

  Cenário: Preserva a ordem declarada no Backlog
    Dado tasks na ordem T-01, T-02, T-03 no Markdown
    Quando plan_parallel_slots é chamada
    Então o Vec segue a mesma ordem
```

### T-03 — `compose_parallel_artifact` e `traceability_table`

```gherkin
Funcionalidade: Composição determinística do artefato paralelo

  Cenário: Artefato composto contém rastreabilidade no topo
    Dado dois SlotResult com status Concluido
    Quando compose_parallel_artifact é chamada
    Então o artefato começa com a tabela de rastreabilidade (traceability_table)

  Cenário: Artefato parcial com slot em Erro inclui marcação explícita
    Dado um SlotResult Concluido e outro em Erro
    Quando compose_parallel_artifact é chamada
    Então o fragmento Concluido está presente
    E o slot em Erro tem marcação "[ERRO] slot falhou — fragmento ausente"

  Cenário: compose_parallel_artifact é função pura
    Dado os mesmos argumentos chamados duas vezes
    Quando compose_parallel_artifact é invocada duas vezes
    Então ambas as chamadas retornam string idêntica
```

### T-04 — `spawn_parallel_agent`

```gherkin
Funcionalidade: Disparo de agente paralelo por slot

  Cenário: Retorna um Receiver que entrega StageEvent::Finished ao completar
    Dado um executável stub que termina com exit 0
    Quando spawn_parallel_agent é chamada
    Então o Receiver entrega StageEvent::Finished em até 5 segundos

  Cenário: Finished carrega exit_code != 0 quando executável falha
    Dado um executável stub que termina com exit 1
    Quando spawn_parallel_agent é chamada
    Então StageEvent::Finished carrega exit_code diferente de zero

  Cenário: Desconexão do canal não causa panic
    Dado o Sender descartado antes de Finished ser enviado
    Quando o event loop chama try_recv
    Então recebe Disconnected e trata como Erro de slot sem panic
```

### T-05 — Extensão de `App`

```gherkin
Funcionalidade: App suporta execução paralela de agentes

  Cenário: start_parallel_stage popula App::parallel com um handle por task independente
    Dado App em StageBoard com Stage::Execution selecionado
    E um 04-tasks.md com duas tasks independentes
    Quando start_parallel_stage é chamada
    Então App::parallel tem dois elementos
    E a tela muda para Screen::ParallelRunning

  Cenário: on_parallel_event atualiza o slot correto sem afetar os demais
    Dado App::parallel com dois slots em Aguardando
    Quando on_parallel_event é chamada com slot_index=0 e StageEvent::Trace
    Então o slot 0 tem status EmExecucao
    E o slot 1 permanece em Aguardando

  Cenário: parallel_barrier_reached retorna true somente quando todos terminaram
    Dado App::parallel com três slots: Concluido, Concluido, EmExecucao
    Quando parallel_barrier_reached é chamada
    Então retorna false
    Quando o terceiro slot transita para Concluido
    Então parallel_barrier_reached retorna true

  Cenário: resolve_parallel_barrier avança para ParallelDecision com erros
    Dado um slot em Erro após a barreira
    Quando resolve_parallel_barrier é chamada
    Então a tela muda para Screen::ParallelDecision
```

### T-06 — Extensão do event loop

```gherkin
Funcionalidade: Event loop drena múltiplos receivers sem bloquear a UI

  Cenário: Todos os slots são drenados a cada frame
    Dado App::parallel com dois slots com eventos pendentes
    Quando o event loop executa uma iteração
    Então on_parallel_event é chamada para cada evento de cada slot

  Cenário: A barreira é verificada após a drenagem de todos os slots
    Dado todos os slots em estado terminal após a drenagem
    Quando o event loop conclui a drenagem
    Então resolve_parallel_barrier é chamada uma vez naquele frame

  Cenário: O caminho single-agent (App::pending) permanece inalterado
    Dado App com pending: Some(rx) e parallel vazio
    Quando o event loop executa
    Então o rx de pending é drenado normalmente sem acionar código de parallel
```

### T-07 — Renderização das telas paralelas

```gherkin
Funcionalidade: Renderização do painel de slots paralelos

  Cenário: render_parallel_running exibe status por slot e contador global
    Dado App::parallel com dois slots: um EmExecucao e outro Concluido
    Quando render_parallel_running é chamada em largura 80
    Então o frame não pânica
    E o frame exibe "1 de 2 concluídos"

  Cenário: render_parallel_decision exibe opções de decisão
    Dado App em Screen::ParallelDecision com um slot em Erro
    Quando render_parallel_decision é chamada
    Então o frame exibe: Retentar, Aceitar parcial e Cancelar
    E o slot em Erro é destacado com mensagem de erro isolada

  Cenário: Ambas as telas renderizam sem pânica em largura 120
    Dado qualquer estado válido de App::parallel
    Quando as funções são chamadas em largura 120
    Então nenhuma pânica ocorre
```

### T-08 — `update_parallel_decision`

```gherkin
Funcionalidade: Decisão do usuário na tela ParallelDecision

  Cenário: Retentar faz respawn dos slots em Erro
    Dado App em Screen::ParallelDecision com um slot Concluido e um Erro
    Quando update_parallel_decision recebe Action::Regenerate
    Então o slot em Erro é re-despachado
    E o slot Concluido permanece inalterado
    E a tela volta para Screen::ParallelRunning

  Cenário: Aceitar parcial compõe artefato apenas com slots bem-sucedidos
    Dado App em Screen::ParallelDecision com um slot Concluido e um Erro
    Quando update_parallel_decision recebe Action::Approve
    Então compose_parallel_artifact é chamada apenas com os Concluido
    E a tela avança para Screen::Viewer

  Cenário: Cancelar descarta resultados e volta ao StageBoard
    Dado App em Screen::ParallelDecision
    Quando update_parallel_decision recebe Action::Quit
    Então App::parallel está vazio
    E parallel_stage é None
    E a tela é Screen::StageBoard
```

### T-09 — Testes de regressão

```gherkin
Funcionalidade: Regressão — nenhuma mudança quebra o caminho existente

  Cenário: renders_all_screens_no_panic cobre ParallelRunning e ParallelDecision
    Dado um App com estado mínimo válido para cada Screen
    Quando render é chamado para cada Screen em larguras 80 e 120
    Então nenhum frame pânica

  Cenário: O caminho pending (single-agent) permanece funcional
    Dado App com pending: Some(rx) para Stage::Idea
    Quando o event loop processa eventos do rx
    Então app.parallel permanece vazio durante todo o fluxo

  Cenário: Etapas não-paralelas não ativam o modo paralelo
    Dado Confirm em qualquer etapa que não seja Execution nem Review
    Quando o App processa a ação
    Então start_stage (single-agent) é chamado, não start_parallel_stage
    E Screen transita para Running, não ParallelRunning
```

---

## Ordem sugerida

### Sequência recomendada

```
Fase 1 — sequencial obrigatória
  └── T-01: Criar parallel.rs com tipos e supports_parallel

Fase 2 — paralelas entre si (após T-01)
  ├── T-02: Implementar plan_parallel_slots
  ├── T-03: Implementar compose_parallel_artifact + traceability_table
  └── T-04: Implementar spawn_parallel_agent

Fase 3 — sequencial (aguarda Fase 2 completa)
  └── T-05: Estender App com campos, Screen e métodos de controle

Fase 4 — paralelas entre si (após T-05)
  ├── T-06: Estender event loop em mod.rs
  ├── T-07: Implementar render_parallel_running e render_parallel_decision
  └── T-08: Implementar update_parallel_decision

Fase 5 — sequencial (aguarda Fase 4 completa)
  └── T-09: Testes de regressão abrangentes
```

### Caminho crítico

`T-01 → T-05 → T-06 → T-09`

### Definition of Done (por task)

- Código compila sem erros nem warnings (`cargo build --release`).
- Todos os testes unitários passam (`cargo test`).
- Critérios de aceite Gherkin verificados.
- Sem `unwrap()` não justificado.
- Sem `Arc<Mutex<_>>` novo — manter padrão `mpsc`.
- T-09 verde antes de considerar a feature completa.

---

## Rastreabilidade

| Campo | Valor |
|-------|-------|
| Slug | `tui-team-agents-execution-review` |
| Origem — Ideia | `docs/tui-team-agents-execution-review/01-idea.md` |
| Origem — PRD | `docs/tui-team-agents-execution-review/02-prd.md` |
| Origem — Tech Spec | `docs/tui-team-agents-execution-review/03-techspec.md` |
| Caminho local | `docs/tui-team-agents-execution-review/04-tasks.md` |
| Próxima etapa | Refinement (opcional) ou Execution |
| Arquivos a criar | `src/tui/parallel.rs` |
| Arquivos a alterar | `src/tui/app.rs`, `src/tui/runner.rs`, `src/tui/mod.rs`, `src/tui/ui.rs` |
