# ⚠️ Central V2 — MÓDULO EM DESENVOLVIMENTO (NÃO É PRODUÇÃO)

> 🚧 **Este módulo está EM DESENVOLVIMENTO e é acessível apenas a desenvolvedores.**
> 🚫 **NÃO confundir com a produção.** Quem atende os operadores hoje é a **V1** (ver abaixo).
> Enquanto este aviso existir, **nada aqui deve ser considerado estável nem ligado para usuário comum.**

---

## O que é isto

Reescrita **V2, desacoplada e isolada** do módulo Central (painel TMS de despacho), construída *greenfield* nos moldes V2 (`Edicaorota`/`Otp`): controller dispatcher fino, `Eventos/` (socket isolado), `Adapters/<Dominio>/`, Sondas V2, `Migrations/`, `Testes/`.

Ela roda **em paralelo** à V1, que permanece **100% intacta e no ar**. O objetivo é desenvolver a V2 **sem prejudicar quem usa a V1**.

📄 Plano/decisão completo: **`review-central.md`** (neste diretório) — em especial a **§11 (Estratégia B — V2 paralela e coexistente, dev-gated)**.
🗂️ Timeline de desenvolvimento (tracking vivo): **`tasks/README.md`** — todas as tarefas B0→B4 + front, com status/dependências.

## Onde está a PRODUÇÃO (V1) — não mexer por causa da V2

| Camada | Caminho (V1 / produção) |
|---|---|
| Núcleo (satélite V1) | `componentes/Constelacoes/Logistica/Central/Satelites/Central.php` |
| Sinal / views / forms | `componentes/Missoes/Logistica/sinais/Central/` |
| Frontend (mapa) | `controladores/_Src/maps.js` |
| Socket (rooms de produção) | `galaxia_logistica_central` / `galaxia_logistica_board` |
| Cron que alimenta o painel | `crons/crompedidos_logistica.php` |

## Regras de isolamento (para a V2 NÃO interferir na V1)

1. **Acesso dev-only.** Entrada gateada por `ApiConfig::isDev($userId)` (allowlist `Config::DEV_USER_IDS`), no padrão de `Missoes/Logistica/sinais/Admin/Admin.php:470-490`. Usuário comum → `redirect(goldie_url())`. **Não remover o gate.**
2. **Socket em rooms próprias.** A V2 publica/lê **só** em `galaxia_logistica_central_v2` / `galaxia_logistica_board_v2`. **Nunca** emitir nas rooms da V1 — isso vazaria eventos de teste para a tela dos operadores reais.
3. **Dados isolados no dev.** Operar em **tenant/empresa sandbox** e/ou **read-only** nas telas de escrita até cada lab ter teste de caracterização verde. **Não** executar ações de escrita da V2 sobre romaneios/pedidos de tenant real (risco de dupla alocação de verdade).
4. **Migrations só aditivas.** Apenas **criar** tabelas novas (nome próprio) e colunas **aditivas**. **Proibido** `ALTER`/`DROP` destrutivo em tabela da V1 (romaneios, pedidos, etc.).
5. **Sem repontar produção para cá.** Não apontar cron, forms, `maps.js` de produção, nem URLs hardcoded para o `Central2`. O cutover é uma fase própria e posterior (B4), por tenant/usuário, com shims.
6. **Registries namespeados.** Usar chaves/contexto próprios (ex.: `central_v2`) para não sobrescrever registros da V1 em runtime.

## Status

- **Fase atual:** _(preencher — ex.: B0 esqueleto + gate)_
- **Pronto para produção?** ❌ Não.
- **Front (decidido):** front **próprio do `Central2`**, **derivado do `controladores/_Src/maps.js` como base — não 100%**. Porta-se o núcleo de mapa/markers/desenho de rota; reescreve-se a camada de **socket+estado coesa/desacoplada** (contrato de socket explícito, store no lugar do textarea `.rotasGeradas`, sem dispatch por `typeof fn`, i18n via `show()`). ⚠️ **Não editar** o `maps.js` compartilhado (fronteira fixa da V1) — o front da V2 é asset separado **sob este diretório**.
- **Decisão ainda em aberto** (ver `review-central.md` §11): isolamento de dados no dev (sandbox+read-only vs shadow tables).

## Quando remover este aviso

Só após: paridade funcional validada, pré-condições **P-3** (contrato de socket congelado/testado) e **P-4** (testes de caracterização das ações) atendidas, e cutover gradual concluído com a V1 aposentada. Até lá, **este módulo continua sendo dev.**