# ELLUX HUB COMERCIAL — PACOTE V2.3 PARA PROGRAMADOR
**Domínio definitivo:** https://hub.ellux.com.br
**Arquitetura de acesso aprovada:** Cloudflare Zero Trust Access com MFA (camada externa) + login individual por e-mail e senha no Ellux Hub (camada interna). **Não há TOTP próprio do Hub.**

## Entrega
- `sistema-atual/`: base funcional v2.0.3 preservada. Não apagar nem substituir cadastros reais do navegador.
- `backend/public/login.html`: tela de login e recuperação de senha, sem segundo fator próprio.
- `backend/private/auth_router.php`: API inicial de autenticação, sessão, logout, reset de senha e leitura protegida de arquivos.
- `backend/sql/001_initial.sql` e `002_auth_security.sql`: banco inicial e tabelas de controle de tentativas/recuperação. **Somente para banco novo.**
- `backend/scripts/create_admin.php`: script CLI para primeiro gestor.
- `backend/private/config.example.php`: exemplo de configuração com domínio oficial. **Não contém credenciais.**
- `exportar-representantes-para-migracao.html`: utilitário de migração; só funciona na origem que tem os dados, sujeito a validação.

## Instruções de implantação
1. Confirmar hospedagem do projeto correto; **não usar o cPanel `elluxrh` do outro HUB**. Preservar backups e banco do outro HUB.
2. Configurar DNS e HTTPS para `hub.ellux.com.br`. Criar banco separado com privilégio mínimo e importar SQL 001 e 002.
3. Publicar somente `backend/public` como raiz pública, mantendo `backend/private`, `backend/scripts` e `sistema-atual` fora do alcance público; revisar roteamento e caminhos dos módulos antes de disponibilizar.
4. Configurar `backend/private/config.php` com segredos somente no servidor; criar o primeiro gestor por CLI. Configurar SMTP autenticado para recuperação de senha (a implementação inicial usa `mail()` e está desativada por padrão).
5. Criar aplicação **Self-hosted** no Cloudflare Zero Trust Access protegendo `hub.ellux.com.br` e **todos os caminhos**, inclusive `/auth/*`, `/assets/*`, `/app` e API. Definir política Allow por usuários/grupo corporativo, sem acesso público. Exigir MFA **no provedor de identidade (IdP)** integrado ao Access e testar a política. Um código enviado por e-mail não deve ser apresentado como MFA forte sem uma política adequada.
6. **Impedir bypass do Cloudflare**: proteger IP/origem (Cloudflare Tunnel ou firewall de origem apropriado), revisar DNS e rotas diretas. Não confiar apenas no cabeçalho de identidade sem validar assinatura, emissor, audiência e expiração caso use JWT do Access.
7. Conectar a interface e Gestão > Acessos ao backend e banco; hoje o frontend v2.0.3 continua protótipo localStorage. Implementar autorização por rota e registro, CRUD de usuários, permissões, auditoria, anexos e migração de representantes com vínculos.
8. Homologar login, logout, recuperação, MFA no IdP, usuários autorizados/não autorizados, sessão expirada, acesso direto à origem, API, arquivos, representantes, contratos, metas e dashboards. Só liberar após aprovação.

## Limitações e validação
- O login PHP e a tela foram **preparados**, mas não testados ponta a ponta em hospedagem real.
- Cloudflare Access, IdP, MFA, DNS, SSL e SMTP **não estão configurados neste pacote** e exigem acesso administrativo do programador.
- O protótipo não está conectado integralmente ao banco. Não utilizar em produção sem concluir a integração e a auditoria de segurança.
- O ZIP não inclui dados reais do navegador, anexos IndexedDB, senhas ou chaves.
- `HISTORICO_HOMOLOGACAO_V2_1_NAO_SEGUIR.md` é documentação histórica, **não** instrução atual de implantação.