# Onda 3 — Drilldown + Filtros Operacionais — PRD bruto

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

## Problema / dor

Hoje o ranking de separadores e conferentes mostra **número agregado por pessoa no período** — mas o coordenador, ao ver "João tem 78% de assertividade no mês", não consegue:

- Saber **em quais rotas** ele errou.
- Saber **quais tipos de erro** (trocado/falta/sobra) prevalecem para ele.
- Ver **a evolução curta** (assertividade dele dia-a-dia no período).
- Filtrar o dashboard por **filial/CD**, **turno** ou **tipo de rota** — hoje vê tudo misturado.

Sem drilldown e filtros operacionais, o dashboard responde "quem", mas não "onde" e "por quê" — o coordenador volta a abrir SQL/relatórios externos.

## Quem usa

- **Coordenador de separação** — clica num separador e vê detalhe acionável (rotas/erros dele).
- **Coordenador de expedição** — idem para conferentes.
- **Gestor logístico / supervisor** — usa filtros (filial/CD, turno) pra comparar centros de distribuição.

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

### Drilldown por pessoa

- Clicar numa linha do ranking (Separação ou Carregamento) abre painel de detalhe (modal lateral ou inline acima da tabela — TL decide).
- O painel mostra:
  - **Cabeçalho**: nome, foto/avatar (se houver), papel (separador/conferente), período corrente do filtro.
  - **KPIs da pessoa no período**: itens, cubagem, tempo médio, assertividade, score, posição no ranking.
  - **Lista de rotas/cargas dele no período**: data, código da rota/carga, erros tipados, link para o sinal correspondente (Edicaorota — preparado pra onda 5).
  - **Pie de tipos de erro dele** (separação: trocado/falta/sobra; carregamento: faltando/trocado/avaria/endereço).
  - **Sparkline de assertividade dia-a-dia** dentro do período (ou semana-a-semana se >60 dias).
- Fechar o painel volta ao ranking sem perder estado.

### Filtros operacionais

Adicionar 3 filtros no topo (próximos ao DateRange) que se propagam como **queryparams** pra todos os handlers:

- **`branchId`** — filial/CD (Centro de Distribuição). Multi-select ou single? PO decide na spec; default = "todas".
- **`shift`** — turno (manhã / tarde / noite / madrugada — depende do que a empresa usa; PO valida com coordenador).
- **`routeType`** — tipo de rota (urbana / interurbana / express — idem, PO valida).

Filtro vazio = "todos". Persistência junto com período + aba (querystring, herdado da onda 1).

### Novos handlers e Sondas

- `/api/v1/dashboard/separator/{personId}` — detalhe do separador.
- `/api/v1/dashboard/checker/{personId}` — detalhe do conferente.
- (Talvez) `/api/v1/dashboard/branches`, `/api/v1/dashboard/shifts`, `/api/v1/dashboard/route-types` — para popular os selects dos filtros (alternativa: hardcoded em config se forem enums fixos; TL decide).
- Sondas/Laboratorios novos para agregar dados-da-pessoa-no-período. Verificar reuso de Sondas existentes da onda 1.

### i18n

Todos os novos labels (filtros, painel de drilldown, breadcrumb) nas 3 línguas.

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

- **Não** implementar exportação do drilldown (CSV/PDF) — onda 4.
- **Não** implementar comparativo entre pessoas — onda 4.
- **Não** implementar metas/targets — onda 4.
- **Não** implementar alertas — onda 5.
- **Não** linkar pra outros sinais (Edicaorota, Ocorrencias, Designacoes) **com profundidade** — onda 5. Aqui apenas link simples (URL) é aceitável; deep-link com contexto fica pra onda 5.
- **Não** mudar layout do ranking principal — drilldown é complemento.
- **Não** abrir `/api/v1` publicamente.
- **Não** mudar schema do banco se os dados de filial/turno/tipo já existem nas tabelas — TL valida no techplan; se faltarem, **abrir ticket separado** (não nesta onda).

## Restrições conhecidas

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

Específicas:

- Filtros **dependem de colunas existentes** nas tabelas mapeadas pelas Sondas. TL valida em `dev_gx_goldie` se `branchId`, `shift`, `routeType` (ou equivalente) existem. Se não, decidir com PO se a onda fica em standby ou se entra apenas com os filtros que existem.
- Drilldown **precisa de paginação** se a pessoa tiver >50 rotas/cargas no período (período pode ir até 365 dias).
- Performance: handler de drilldown deve responder em <500ms para período de 30 dias (mantém budget da onda 1).
- **Modularização do `dashboard.js`** (onda 2) precisa estar pronta — drilldown é nova "tela" que vai conviver com os módulos existentes.

## Inspirações / referências

- Onda 1 (`ux-foundation`) — chart lib e datepicker fechados.
- Onda 2 (`refactor-tecnico`) — modularização do JS.
- `componentes/Missoes/Logistica/sinais/Edicaorota/` — referência V2 (Adapters, Callbacks, padrão de detalhe).
- `componentes/Missoes/Logistica/sinais/Dashboard/Sondas/` — Sondas existentes pra reuso.

## Métricas de sucesso

- Coordenador consegue, em <10s a partir da home do dashboard, ver o detalhe de qualquer pessoa do ranking.
- Filtros (branch/shift/routeType) propagam corretamente para 100% dos handlers.
- p95 do handler de drilldown <500ms para período de 30 dias em `dev_gx_goldie`.
- i18n nas 3 línguas para todos os novos labels.
- Zero `sendToGalaxia`; tudo via `/api/v1/dashboard/*`.
- Persistência: drilldown aberto + filtros persistem via querystring (link compartilhável).

## Notas

- **Branch**: `feature/dashboard-operacional-drilldown-filtros`.
- **Depende das ondas 1 e 2.**
- **Pode rodar em paralelo com a onda 4** se houver capacidade de dev — mas atenção a conflitos no `dashboard.js` modularizado.
- A pergunta "single-select vs multi-select" para `branchId` é decisão de PO/coordenador — registrar no `01-spec.md`.
- Se o painel de drilldown for **modal**, considerar acessibilidade (tecla ESC fecha, foco volta pra linha).
- **Histórico de evolução longo** (ex.: assertividade do separador últimos 12 meses, comparado com média) **não é desta onda** — é da onda 5.