B2BCall-dialer/TODO.md

TODO — B2BCall

PHASE 01 — Infrastructure

• Diagnóstico do servidor (Debian 13, 2 vCPU, ~1.9GB RAM, 26GB disco livre)
• Docker + Docker Compose instalados
• Estrutura de monorepo criada (apps/, packages/, infrastructure/, scripts/, docs/)
• PostgreSQL 18 (docker-compose, porta 127.0.0.1:5432)
• Redis 7 (docker-compose, porta 127.0.0.1:6379)
• Secrets gerados em .env (POSTGRES_PASSWORD, REDIS_PASSWORD, JWT_SECRET, JWT_REFRESH_SECRET, ENCRYPTION_KEY, ESL_PASSWORD)
• FREESWITCH_PAT configurado em .env (não commitado)
• FreeSWITCH (build/imagem própria, ver risco de RAM abaixo)
• nginx (reverse proxy)

PHASE 02 — SaaS Core

• Monorepo Node.js/TypeScript (pnpm workspaces, tsconfig base)
• Node 22 LTS + pnpm instalados no host
• packages/database (Prisma 7 + driver adapter pg, migration inicial)
• packages/types (TenantStatus, AgentState), packages/shared
• Tabela tenants criada via migration (seção 29 do agente.md)

PHASE 03 — Tenant Isolation

• Tabela tenants + RLS
• Tenant context em transação PostgreSQL

PHASE 04 — Authentication / RBAC

• Login (Argon2id), access/refresh tokens
• roles/permissions/user_roles/role_permissions

PHASE 05+ — ver agente.md seções 15 em diante (FreeSWITCH, Telefonia, Call Center,

Predictive Dialer, Recordings, AI, Billing, Frontend, Reports, Security, Tests)

---

Riscos conhecidos

• RAM da VM (1.9GB total): insuficiente para rodar toda a stack (Postgres + Redis + FreeSWITCH + múltiplos workers Node + Next.js) simultaneamente sem swap/OOM. Avaliar upgrade de RAM antes de subir FreeSWITCH + frontend + workers juntos.
• Disco (26GB livre): build do FreeSWITCH + imagens Docker + gravações vão consumir espaço rápido. Monitorar com df -h.