# Idea — Layout do TUI com experiência similar ao OpenCode

## Rastreabilidade
- Orquestração: Precisamos que o layout em si do TUI tenha uma experiência similar à do OpenCode
- Slug: `precisamos-que-o-layout-em-si-do-tui-tenha-uma-experiencia-similar-a-do-opencode`
- Origem: entrada bruta do usuário + 2 screenshots de referência do OpenCode (model selector e home)
- Etapa anterior: `00-risk-classification.md` (risco **medium**, fator `external_dependency`)
- Decisões do design-interview: overhaul completo · estética + command palette · minimalista com detalhe sob demanda
- Estado: draft

## Problema
O TUI atual (`src/tui/`, ratatui 0.29 + crossterm 0.28) é funcional, porém visualmente pesado e de alta carga cognitiva:
- **Bordas em toda parte** (`Block::default().borders(Borders::ALL)` em praticamente todas as telas) criam ruído e fragmentam a leitura.
- **Densidade alta por padrão**: telemetria de tokens, tabela de roteamento por etapa, limites de provider e budget aparecem sempre, competindo com a ação principal (ver `render_board` em `src/tui/ui.rs`).
- **Navegação só por telas e teclas posicionais** (`↑/↓`, `Enter`, `p`, `Esc`), sem um ponto único de descoberta de comandos.
- Acentos de cor distribuídos (ciano, azul, amarelo, verde, magenta) sem um **acento primário** consistente.
- Seleção sinalizada por símbolo (`▸`/`▶`) em vez de **barra full-width**, reduzindo affordance.

Resultado: a ferramenta passa sensação de "console de operação" em vez da experiência fluida e moderna que o OpenCode entrega no terminal.

## Objetivo
Reposicionar o **SDD cockpit** de uma estética de "painéis com bordas densas" para uma experiência **minimalista, centrada e calma no estilo OpenCode**, sem alterar o motor de orquestração SDD (etapas, checkpoints, rastreabilidade, providers). Concretamente:

1. **Overhaul completo** — reestilizar as 11 telas do enum `Screen` (`ProviderSetup`, `OrchestrationList`, `NewOrchestration`, `StageBoard`, `Running`, `Viewer`, `Checkpoint`, `RefinementPrompt`, `ErrorPanel`, `Help`, `Summary`).
2. **Estética + command palette** — adicionar um overlay de command palette (fuzzy `/comando` + atalhos) como entrada primária, sobreposto às telas, sem remover a navegação por telas existente.
3. **Minimalista com detalhe sob demanda** — telemetria densa sai do default e passa a viver em overlays/expansão acionável.
4. **Sistema de tema central** — tokens de cor/spacing/seleção em um módulo único, reutilizado por toda a renderização, com acento primário consistente.
5. **Preservar 100% do comportamento de domínio** — `stage.rs`, checkpoints, `persist.rs`, `runner.rs` e rastreabilidade intactos. A mudança é de camada de apresentação e de input/roteamento de comandos.

Sinais de referência do OpenCode a reproduzir: logo figlet na home + lista de comandos em 3 colunas + input com `>` + footer "enter send … modelo"; e o model selector como modal flutuante sobre fundo escurecido, com busca, listas agrupadas por seção, barra de seleção full-width e tags à direita.

### Fora de escopo
- Mudar o fluxo SDD, a ordem das etapas ou as regras de `can_navigate`.
- Alterar contratos de artefatos, schemas ou persistência em `docs/<slug>/`.
- Trocar a biblioteca de TUI (continua ratatui/crossterm).
- Suporte a mouse, temas customizáveis pelo usuário ou modo claro (follow-up).
- Reescrever o motor de providers ou a telemetria de tokens (apenas onde/como é exibida muda).

## Usuários
- **Primário**: engenheiros e tech leads que rodam o fluxo SDD no terminal fora do editor/agent (o caso "quando não for dentro do editor/agent").
- **Secundário**: pessoas avaliando a camada SDD pela primeira vez — a home/launcher é o cartão de visita do produto.

## Critérios de sucesso
- **CS-1 (estética)**: as 11 telas usam o tema central, sem `Borders::ALL` como padrão; acento primário único e barras de seleção full-width substituem os símbolos `▸`/`▶`.
- **CS-2 (command palette)**: é possível disparar todas as ações principais (nova orquestração, trocar provider, abrir etapa, aprovar checkpoint, ajuda) a partir do palette, com busca fuzzy e atalhos visíveis.
- **CS-3 (minimalismo)**: a tela default de cada etapa mostra apenas a ação principal e o essencial; telemetria de tokens/routing/limites só aparece quando o usuário a expande.
- **CS-4 (home)**: a primeira tela apresenta logo figlet, versão e lista de comandos navegável, fiel à referência do OpenCode.
- **CS-5 (sem regressão)**: o fluxo Ideia→Memória, os checkpoints e a persistência continuam funcionando; `cargo test` (incluindo os testes de render `renders_all_screens_no_panic`) passa em larguras 40/80/120.
- **CS-6 (degradação graciosa)**: em terminais estreitos ou sem truecolor, o layout não quebra — há fallback legível.

## Riscos iniciais
- **R1 (external_dependency)**: fidelidade visual depende do terminal (truecolor, largura, glifos). Precisa de fallback gracioso.
- **R2**: overhaul toca `ui.rs` (1484 linhas) e o input em `event.rs`/`app.rs` — risco de regressão visual e de quebra dos testes de render.
- **R3**: command palette é interação nova — risco de conflito de teclas e de aumento de complexidade de estado em `app.rs`.
- **R4**: minimalismo pode esconder informação que operadores hoje usam (budget/limites) — precisa de descoberta clara do overlay.

## Próxima etapa
PRD (`02-prd.md`) com requisitos funcionais, regras de negócio, jornadas, princípios de experiência, estados e critérios de aceite em Gherkin. **Checkpoint humano obrigatório após o PRD.**
