# TODO — B2BCall

## PHASE 01 — Infrastructure
- [x] Diagnóstico do servidor (Debian 13, 2 vCPU, ~1.9GB RAM, 26GB disco livre)
- [x] Docker + Docker Compose instalados
- [x] Estrutura de monorepo criada (apps/, packages/, infrastructure/, scripts/, docs/)
- [x] PostgreSQL 18 (docker-compose, porta 127.0.0.1:5432)
- [x] Redis 7 (docker-compose, porta 127.0.0.1:6379)
- [x] Secrets gerados em `.env` (POSTGRES_PASSWORD, REDIS_PASSWORD, JWT_SECRET, JWT_REFRESH_SECRET, ENCRYPTION_KEY, ESL_PASSWORD)
- [x] `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 (workspaces, tsconfig base)
- [ ] `packages/database` (schema, migrations)
- [ ] `packages/types`, `packages/shared`

## 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`.