# Onda 2 — Refactor Técnico — PRD bruto

> Parte do refinamento [`PRD/dashboard-operacional-refinamento/`](../../00-prd.md). Restrições globais herdadas — ver guarda-chuva.

## Problema / dor

O `componentes/Missoes/Logistica/sinais/Dashboard/html/dashboard.js` tem **~44KB num único arquivo**. Ele cresceu rápido na primeira onda (KPIs + 3 abas + rankings + séries) e já é difícil de:

- Ler/revisar em PR (diff grande, contexto perdido).
- Estender pelas ondas seguintes (drilldown, filtros, exportação, alertas) sem virar bola de neve.
- Testar — não há separação clara entre fetch, render, charts e estado.

Além disso, a feature `dashboard-logistica-api-v2` (mergeada antes) deixou **12 handlers em `Plataforma/sinais/Api/Handlers/Dashboard/`** dos quais provavelmente só 1 ou 2 (TiposMissaoHandler + metadados) sobreviveram à substituição feita pela `dashboard-operacional`. Os obsoletos continuam expostos, aumentando superfície e confundindo manutenção.

Possíveis Sondas duplicadas/agregações repetidas entre Sondas do `Dashboard` e Constelações também precisam de auditoria.

Esta onda é **refactor puro**: zero mudança de UX visível.

## Quem usa

- **Time de devs Genesis** — beneficiário direto. Onda existe pra eles. Diff menor, módulos coesos, manutenção mais barata, ondas seguintes mais previsíveis.
- **Reviewer** — review de PRs futuras menor.
- **QA** — testes mais focados, menos fragilidade.

(Usuários finais não percebem mudança — é o objetivo.)

## O que precisa fazer (alto nível)

### Modularizar `dashboard.js`

Quebra preferida (TL decide a final no `02-techplan.md`):

- **Por aba** (mais natural pro código atual):
  - `dashboard.core.js` — bootstrap, roteador de aba, estado global (período, aba ativa), fetch utilitário.
  - `dashboard.geral.js` — bloco da aba Visão Geral (KPIs do topo + fluxo + overnight + top 3).
  - `dashboard.separacao.js` — aba Separação (cards + ranking + erros + comparativo mensal).
  - `dashboard.carregamento.js` — aba Carregamento (cards + ranking + retrabalho + erros motorista).
- **Ou por responsabilidade** (se o estado global ficar pesado):
  - `dashboard.state.js` — período, aba, querystring, eventos.
  - `dashboard.api.js` — wrappers de `fetch('/api/v1/dashboard/*')`.
  - `dashboard.charts.js` — adapters da chart lib escolhida na onda 1.
  - `dashboard.render.js` — render de cards/rankings/badges.

Critério: cada módulo coeso, testável isoladamente, ≤ ~500 linhas.

### Auditar e podar handlers obsoletos

- Listar os ~12 handlers em `componentes/Missoes/Plataforma/sinais/Api/Handlers/Dashboard/`.
- Para cada um: usado pela UI atual? consumido por algo externo (mobile? terceiros? scripts)?
- Remover os obsoletos (handler + Validator + dispatcher + rota). Manter só o que `dashboard.js` consome.
- Atualizar `01-spec.md` da feature original e o `06-review.md` se ainda fizer sentido referenciar.

### Consolidar Sondas/agregações duplicadas

- Verificar `componentes/Missoes/Logistica/sinais/Dashboard/Sondas/` e `componentes/Constelacoes/` (relevantes ao domínio operacional).
- Se houver duplicação (ex.: 2 Sondas calculando assertividade do separador com lógicas levemente diferentes), consolidar numa só.
- Sem mudar fórmulas — apenas remover redundância.

### Padronizar logs/erros do JS

- Wrapper único de fetch que loga falhas, exibe toast/banner padrão e respeita i18n.
- Remover `console.log` deixados na onda 1.

## O que NÃO precisa fazer (escopo negativo)

- **Não** mudar UX visível (cores, layout, comportamento) — refactor puro.
- **Não** mudar contratos de API que sobrevivem à poda.
- **Não** trocar chart lib ou datepicker — herda da onda 1.
- **Não** introduzir TypeScript, bundler, ESLint novo.
- **Não** mexer em outros sinais de Logística.
- **Não** mudar schema do banco.
- **Não** mexer em CI/CD além do necessário pra os testes existentes continuarem passando.

## Restrições conhecidas

Ver [restrições globais](../../00-prd.md#restrições-globais-herdadas-em-todas-as-ondas).

Específicas:

- **Zero regressão visível**: testes de integração existentes (em `dev_gx_goldie`) **devem continuar verde sem alteração**. Se algum precisar de ajuste, é sinal de que o refactor mudou contrato — Reviewer trata como blocker.
- **Pode quebrar a poda em PR menor** — TL pode optar por dividir esta onda em (2a) modularização do JS, (2b) poda de handlers, (2c) consolidação Sondas. Decidir no `02-techplan.md`.
- **Sem feature flags** — refactor é completo, sem dual-stack.

## Inspirações / referências

- Estado atual: `componentes/Missoes/Logistica/sinais/Dashboard/html/dashboard.js` (~44KB).
- `componentes/Missoes/Plataforma/sinais/Api/Handlers/Dashboard/` — alvo da auditoria.
- `componentes/Missoes/Logistica/sinais/Dashboard/Sondas/` — alvo da consolidação.
- `componentes/Missoes/Logistica/sinais/Edicaorota/` — modularização exemplar V2.

## Métricas de sucesso

- Nenhum arquivo JS do sinal > ~500 linhas após modularização.
- Lista escrita de handlers removidos vs mantidos no `02-techplan.md` (com justificativa por handler).
- Suite de integration tests do `dev_gx_goldie` verde sem alteração.
- Zero `console.log` ou TODO órfão no JS após onda.
- p95 dos handlers mantidos **não regride** vs onda 1 (mesma medição).
- Code review do Reviewer aponta diff menor / mais legível em PRs simuladas posteriores (medida qualitativa).

## Notas

- **Branch**: `feature/dashboard-operacional-refactor-tecnico`.
- **Depende da onda 1** — chart lib, datepicker e cache fechados antes de modularizar.
- TL pode decidir mover **auditoria/poda dos 12 handlers** pra esta onda (ao invés da onda 1) — registrar a decisão no `02-techplan.md` da onda 1.
- Se a modularização revelar que o "estado global" do dashboard está espalhado, **considerar pequeno store** (objeto com pub/sub) — sem trazer biblioteca de fora.