# 14 - Melhorias Futuras

> Roadmap técnico sugerido, priorizado por relação impacto/esforço. Não é compromisso — é a leitura do engenheiro que conhece o sistema sobre onde investir. Cada item aponta a dívida ou o fluxo que endereça.
>
> Relacionados: [13 - Dívidas Técnicas](13-dividas-tecnicas.md), [02 - Fluxos](02-fluxos-do-sistema.md).

## Prioridade 1 — Segurança e infraestrutura (fazer primeiro)

### M1. Externalizar segredos e rotacionar
Resolve [DT-C1](13-dividas-tecnicas.md#dt-c1-credenciais-e-segredos-hardcoded-no-código-versionado)/[DT-C2](13-dividas-tecnicas.md). Introduzir um mecanismo de configuração por ambiente (`.env` + leitura central), mover todas as credenciais/segredos/tokens para lá, rotacionar tudo que já esteve no git, e endurecer o JWT (segredo forte por ambiente, `exp` curto + refresh). **Maior impacto de risco do sistema, esforço moderado.**

### M2. Endurecer webhooks inbound
Resolve [DT-C3](13-dividas-tecnicas.md). Migrar os webhooks de WhatsApp para a infra genérica `webhook_endpoints` + `InboundHandler` (HMAC), aposentando os `index.php` soltos. Padrão já existe (IntegracaoWms) — é replicação.

### M3. Clarificar deploy e branch de produção
Resolve [DT-A1](13-dividas-tecnicas.md)/[DT-A2](13-dividas-tecnicas.md). Confirmar a árvore real em produção, unificar paths `galaxia`/`genesis`, e estabelecer uma branch/tag de produção protegida com um passo de verificação antes do `pull` (deploy = pull hoje é frágil).

### M4. Runner de migrations com registro de versão
Resolve [DT-M1](13-dividas-tecnicas.md). Script simples que aplica `Migrations/*.sql` em ordem e registra em `schema_migrations`, mantendo a idempotência. Dá visibilidade de estado de schema entre dev e prod.

## Prioridade 2 — Consolidação da arquitetura V2

### M5. Concluir o Central2 e planejar a virada
O painel de despacho (`Central`, V1, ~1.400 linhas) é o sinal mais crítico e mais legado em produção. O Central2 já é a reescrita V2 desacoplada, dev-gated e sandbox — vale investir para completá-lo (corrigir [DT-A5](13-dividas-tecnicas.md), ligar labs de escrita gradualmente) e planejar a migração de tráfego real. É o maior ganho de manutenibilidade do domínio central.

### M6. Consolidar as três implementações de WhatsApp
Resolve [DT-M2](13-dividas-tecnicas.md). Um único conector (o da Central de Mensageria) consumido pelo OTP e pelo webhook, com normalização de número única.

### M7. Falhar explícito em tenant não resolvido
Resolve [DT-A4](13-dividas-tecnicas.md). Substituir os fallbacks hardcoded (`block_empresa_id='3'`, `p_block=22`) por erro explícito quando a sessão não fornece o tenant — bugs de isolamento passam a ser detectáveis em vez de silenciosos. Requer cuidado (pode revelar chamadas hoje "funcionando" por acaso).

### M8. Desbloquear o tradutor de separação da IntegracaoWms
Fluxo [02 §4.2](02-fluxos-do-sistema.md#42-ordem-vinda-do-wms-externo-integracaowms). O tradutor `separacao` está bloqueado por incompatibilidade de contrato (falta `romaneio_id`/`pedido_id`). É uma decisão de produto pendente — resolvê-la abre separação para o WMS externo.

## Prioridade 3 — Qualidade e ferramental

### M9. Runner de testes agregado + CI
Resolve [DT-M3](13-dividas-tecnicas.md). Um harness que rode todos os `*TddTest.php`/integração e reporte agregado, mais um gate de CI (nem que seja `php -l` + testes unitários) antes do deploy. Hoje não há rede de segurança automatizada.

### M10. Read API de saldo do WMS (quando fizer sentido)
Fluxo [02 §4.1](02-fluxos-do-sistema.md#41-execução-interna-alocacaowms). Hoje o WMS externo é push-only por design; o `EsperadoProviderRegistry` do inventário cíclico é o seam planejado para um dia consultar saldo real sem reescrever o fluxo. Habilita inventário cíclico com fonte de verdade externa.

### M11. Logging estruturado
Resolve [DT-M7](13-dividas-tecnicas.md) e a ausência de agregação de logs. Introduzir níveis e um destino central (arquivo rotacionado ou serviço), desacoplando o `sendFail()` do ORM.

### M12. Value Objects para estruturas que cresceram
Fluxo Edicaorota. Quando uma "parada" passar de ~4 campos (título, endereço, lat/lng, janela), extrair um VO `Resolvers/Parada` em vez de arrays JSON soltos (recomendação já registrada no `COMPARACAO_FRAMEWORK.md`).

## Prioridade 4 — Higiene

### M13. Limpar a raiz e o código morto
Resolve [DT-B1](13-dividas-tecnicas.md)/[DT-M6](13-dividas-tecnicas.md). Remover/`.gitignore` os ~40 arquivos soltos, apagar as cópias mortas (`Diagramas copy`, `Armazem copy`, `Filtrosbackup`, `estrutura copy.php`), esclarecer as duplicações de sinais.

### M14. Alinhar skills/docs ao manual
Resolve [DT-M4](13-dividas-tecnicas.md). Atualizar as skills `genesis-*` (especialmente i18n) e `documentacoes/` para apontar a este manual como fonte única, corrigindo divergências.

### M15. Fixar Tailwind e limpar config
Resolve [DT-B3](13-dividas-tecnicas.md). Escolher v3 ou v4, remover `tailwind.config copy.js`, adicionar um script de build em `package.json`.

## Como usar esta lista

Comece por **P1** — são riscos que não dependem de reescrita e reduzem exposição imediata. **P2** é o trabalho de fundo que paga juros de manutenção ao longo dos anos. **P3/P4** entram no fluxo contínuo. Nenhum item de P2+ deve bloquear entregas de negócio; encaixe-os nas features que já tocam a área (ex.: mexeu no Central? avance o Central2).