Estamos buscando um freelancer qualificado para realizar uma revisão de código abrangente em nossa plataforma SaaS de Comunicação Unificada (UCaaS + CCaaS). Nosso produto, que integra voz, SMS, WhatsApp e redes sociais, está na fase de pré-lançamento, com a Fase 1 já concluída e sem tráfego de produção ativo. Precisamos de uma análise detalhada para garantir a qualidade, segurança e escalabilidade antes do lançamento.
* Devido espaço limitado par edição disponibilizarei informações adicionais (stack completa, arquivos qeu deverão ser analisados, contexto adocional).
*Job para senior com experiência comprovada.
## Escopo da Revisao
### BLOCO 1 — Seguranca Multi-Tenant (prioridade MAXIMA)
> Um tenant não deve conseguir visualizar certos dados de outro, principalmente de um que não esteja hierarquicamente ligado a ele.
**Perguntas que devem ser respondidas:**
1. E possivel um tenant acessar dados de outro manipulando requests?
2. A CTE recursiva de hierarquia tem edge cases que permitiriam escalacao?
3. O cache Redis de tenant scope (5min TTL) pode ficar stale de forma perigosa?
4. Todas as rotas estao protegidas pelo middleware de tenant isolation?
### BLOCO 2 — Modelagem do Banco de Dados
> 26 migrations, dezenas de tabelas. Decisoes de schema sao caras de mudar depois.
**Perguntas:**
1. Os indices estao corretos para as queries mais frequentes?
2. Tem alguma decisao de modelagem que vai travar quando escalar (ex: 10.000+ agentes, milhoes de CDRs)?
3. As foreign keys e constraints estao consistentes?
4. A separacao de tabelas por dominio faz sentido?
5. Campos JSONB (meta_json, etc.) — Estao sendo usados corretamente ou deveriam ser colunas tipadas?
### BLOCO 3 — Pontos Criticos de Concorrencia
> Discador preditivo, filas BullMQ, CDR collector — varios processos rodando ao mesmo tempo.
**Perguntas:**
1. Tem race condition possivel entre o dialer e o call-tracker?
2. Os workers BullMQ estao seguros contra processamento duplicado?
3. O CDR collector pode perder eventos sob carga alta?
4. A exclusao mutua legado/BullMQ (feature flags) funciona de verdade?
5. Concurrency settings dos workers estao adequados?
### BLOCO 4 — Autenticacao e Autorizacao
> JWT, OAuth2, RBAC com 6 roles, quotas.
**Perguntas:**
1. A implementacao JWT tem alguma falha exploravel (timing attacks, key rotation, etc.)?
2. O RBAC pode ser bypassado por alguma rota?
3. O OAuth2 segue as boas praticas (PKCE, token rotation, scope validation)?
4. As quotas por role podem ser manipuladas?
### BLOCO 5 — Seguranca Geral
> Criptografia, audit trail, gdpr, ueba.
**Perguntas:**
1. A criptografia aes-256-gcm esta implementada corretamente (iv, key derivation, etc.)?
2. O hash chaining do audit log e realmente tamper-evident?
3. O GDPR (anonymize, purge, legal holds) funciona sem deixar residuos?
4. As regras ueba podem gerar falsos positivos em volume que impactariam operacao?
### bloco 6 — frontend (arquitetura e padroes)
> react 19, design system proprio,
sip.js para WebRTC.
**Perguntas:**
1. A arquitetura de estado (Zustand) esta adequada ou vai virar um problema?
2. O
SIP.js esta integrado de forma robusta (reconexao, fallback, cleanup)?
3. Os componentes do design system seguem boas praticas React 19?
4. O polling de 12-15s nos dashboards e a abordagem certa ou deveria ser WebSocket?
5. Tem memory leaks potenciais (event listeners, timers, subscriptions nao limpos)?
### BLOCO 7 — Arquitetura Geral (visao de alto nivel)
**Perguntas:**
1. A organizacao do projeto faz sentido para um SaaS multi-tenant?
2. Tem algum anti-pattern arquitetural obvio?
3. A separacao modules (rotas) vs services (logica) esta consistente?
4. Algo que voce mudaria ANTES de ir para producao?
## O que NAO faz parte do escopo
- Revisar testes individuais (6.926 testes — confiamos na cobertura + mutation testing)
- Revisar formatacao/estilo (Biome cuida)
- Revisar dependencias (Snyk + npm audit ja cobrem)
- Sugerir features novas
- Refatorar codigo (apenas apontar problemas)
## Entregavel esperado
**Formato: Issues no GitHub** (NAO em Word, Google Docs ou outro formato externo).
Abrir **7 Issues** no repositorio, uma por bloco:
| Issue | Titulo |
| #1 | Review: Seguranca Multi-Tenant |
| #2 | Review: Modelagem do Banco |
| #3 | Review: Concorrencia |
| #4 | Review: Auth/RBAC/OAuth2 |
| #5 | Review: Seguranca Geral |
| #6 | Review: Frontend |
| #7 | Review: Arquitetura Geral |
| #8 | RESUMO |
**Dentro de cada Issue, listar os achados com:**
1. **Severidade:** Critico / Importante / Sugestao
2. **Arquivo e linha** (ex: `backend/src/services/dialer/
dialer-engine.ts:142`) — o GitHub transforma em link clicavel
3. **Descricao do problema**
4. **Risco real** (o que pode acontecer)
5. **Sugestao de correcao**
**Ao final, abrir uma Issue de resumo (#8) com:**
- Veredito geral: "Pronto para producao" / "Precisa de ajustes" / "Precisa de refatoracao significativa"
- Top 5 riscos ordenados por impacto
- Nota geral de 1 a 10
Prazo de Entrega: Não estabelecido