clube67_newwhats.local/newwhats.clube67.com/newwhats.local/continuar.md

Continuar — NewWhats como Motor Central (SaaS multi-tenant)

Instrução inicial para a próxima sessão

Faça uma análise profissional da ideia descrita abaixo. Antes de escrever qualquer código:

1. Gere uma lista de tarefas detalhada (fases, dependências, critérios de aceite) e salve em TAREFAS.md.
2. Mantenha um relatório vivo de todas as implementações em RELATORIO.md (o que foi feito, decisões técnicas, pontos de atenção, próximos passos).
3. Regra-ouro: toda funcionalidade nova deve ser pensada e entregue como plugin (em /plugins/<nome>/ com manifest.json, hooks, config_schema). Nada vai direto ao core se couber como plugin.

---

Contexto do projeto

• Projeto motor: /home/deploy/projetos/newwhats.local — já possui Baileys (WhatsApp), inbox, sessões, storage (Wasabi), sistema de plugins estilo WordPress, e API de pareamento OTP (/api/pair/*) com integration_key.
• Projetos satélites: múltiplos sistemas (ex.: Alemão Conveniências em /home/deploy/projetos/alemaoconveniencias.local) que não devem instalar Baileys. Devem consumir o motor via API autenticada por integration_key.
• Já implementado: pair system (OTP por e-mail), plugin newwhats no Alemão com x-nw-key auth, modal de pareamento em 3 passos no dashboard.
• Falta: expor inbox, sessões e secretária virtual como serviço consumível pelos satélites.

Ideia a analisar

Transformar o NewWhats em motor SaaS multi-tenant, onde cada projeto satélite é um cliente leve que consome:

• Inbox (chats, mensagens, envio, mídias)
• Sessões (status WA, QR, pareamento de números)
• Secretária virtual (IA com contexto — roda 100% no motor, satélite só consome output)

Arquitetura-alvo

NewWhats (motor)
 ├─ Baileys + Inbox + Storage + Secretária (IA)
 └─ API /api/ext/*  (auth: x-nw-key)
           │
           ▼ HTTPS + WebSocket
   ┌───────┴────────┬──────────┐
   Alemão        Projeto B    Projeto C
   (plugin       (plugin      (plugin
   nw-client)    nw-client)   nw-client)

Decisões propostas (validar antes de implementar)

1. Plugin nw-client portável em /plugins-sdk/newwhats-client/ — reutilizável em todos os satélites, zero dependência de Baileys.
2. API /api/ext/* nova (além de /api/pair/* já existente), autenticada por x-nw-key:
   • GET /api/ext/sessions
   • GET /api/ext/inbox?session=X
   • GET /api/ext/inbox/:chatId/messages
   • POST /api/ext/inbox/:chatId/send
   • POST /api/ext/secretaria/ask
   • WS /api/ext/stream (eventos realtime — fallback polling 5s)
3. Secretária virtual sempre no motor — centraliza custo LLM e contexto.
4. Isolamento multi-tenant — integration_key resolve para user_id + allowed_sessions[]. Satélite nunca vê dados de outro tenant.
5. Distribuição do client plugin — opções:
   • (a) npm publish @newwhats/client (registry privado/público)
   • (b) git submodule
   • (c) CLI nw plugin install que baixa tarball assinado do motor ← recomendado
6. Tudo como plugin:
   • Motor: plugins/ext-api/ (expõe /api/ext/*), plugins/secretaria-virtual/ (IA), plugins/realtime-bridge/ (WS).
   • Satélite: plugins/newwhats-client/ (consumidor único, com UI de inbox embutida).

Tradeoffs a documentar no relatório

• WS vs polling — WS é melhor para UX, mas adiciona complexidade de reconexão/auth. V1 polling 5s, V2 WS.
• Proxy de mídias — satélite baixa mídia via motor (/api/ext/media/:id) ou recebe URL assinada Wasabi? URL assinada é mais leve mas expõe storage.
• Rate limit por integration_key — necessário desde o v1 para proteger motor.
• Versionamento da API — /api/ext/v1/* desde o início.

Pendências herdadas (do project_alemao_plugin_session.md)

• aria-hidden warning no pairModal (Bootstrap 5 — usar inert ou Bootstrap 5.3+).
• Inbox no Alemão via plugin — esta é a primeira entrega desta nova fase.
• SMTP não configurado no NewWhats — dev_code exposto na resposta até configurar.

Entregáveis esperados da próxima sessão

1. TAREFAS.md — backlog fase-a-fase (motor → SDK → satélite → secretária).
2. RELATORIO.md — iniciado com análise profissional da ideia, riscos, e decisões arquiteturais.
3. Esqueleto dos plugins (manifests + hooks declarados, sem lógica ainda) para validar a forma antes de implementar.
4. Pergunta ao usuário: (A) contrato detalhado da API primeiro, ou (B) PoC end-to-end de /api/ext/inbox no Alemão para validar fluxo.

Referências rápidas

• Sistema de plugins: backend/src/core/ (types, hook-bus, plugin-loader, plugin-registry)
• Pair system: backend/src/modules/pair/pair.routes.ts + pair.service.ts
• Plugin consumidor existente: /home/deploy/projetos/alemaoconveniencias.local/sistema-nuvem/plugins/newwhats/
• Build backend: npm run build em /home/deploy/projetos/newwhats.local/backend
• Serviços: newwhats-backend.service (8008), alemaoconveniencias.service (4001)