# 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
- [x] Monorepo Node.js/TypeScript (pnpm workspaces, tsconfig base)
- [x] Node 22 LTS + pnpm instalados no host
- [x] `packages/database` (Prisma 7 + driver adapter `pg`, migration inicial)
- [x] `packages/types` (TenantStatus, AgentState), `packages/shared`
- [x] Tabela `tenants` criada via migration (seção 29 do agente.md)

## PHASE 03 — Tenant Isolation
- [x] Tabelas `users` + `tenant_memberships` (tenant-scoped)
- [x] RLS (`ENABLE`/`FORCE ROW LEVEL SECURITY` + policy) em `tenant_memberships`
- [x] Tenant context via `set_config('app.current_tenant_id', ..., true)` (transaction-local)
- [x] Helper `withTenantContext()` em `packages/database`
- [x] Role de banco separado para runtime (`b2bcall_app`, sem SUPERUSER/BYPASSRLS) —
      achado crítico: o role padrão do Docker Postgres é SUPERUSER e SEMPRE ignora RLS,
      até com FORCE. Ver `docs/TENANT_ISOLATION.md`.
- [x] Teste automatizado de isolamento (`pnpm --filter @b2bcall/database run test:isolation`)

## PHASE 04 — Authentication / RBAC
- [x] `packages/auth`: hash Argon2id (`@node-rs/argon2`), JWT access token (`jose`),
      refresh token opaco com rotation
- [x] Tabelas `roles`, `permissions`, `role_permissions`, `user_roles`, `sessions`, `audit_logs`
- [x] `login()` / `refreshSession()` / `logout()` / `listUserTenants()` / `setActiveTenant()`
- [x] `userHasPermission()` (RBAC com scope PLATFORM/TENANT)
- [x] Seed: catálogo de permissions + roles de sistema + Platform Super Admin inicial
      (senha em `FIRST_LOGIN.txt`, fora do Git, `mustChangePassword=true`)
- [x] Teste automatizado (`pnpm --filter @b2bcall/auth run test:auth`)
- [x] `apps/api` (NestJS + Fastify): endpoints de auth, JwtAuthGuard, DomainExceptionFilter,
      rate limit de login via Redis (5/min por IP e por e-mail), helmet/cors, health checks
      — testado ponta a ponta com curl (login, refresh rotation, logout, RBAC, 401/403/429)
- [ ] Password reset por e-mail — depende de SMTP configurado

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