Matheus/b2bcall
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
8d522e93a33799a526f9812c1aab7b39b9fd8925
b2bcall/TODO.md
B2BCall Bootstrap 8d522e93a3 feat: bootstrap b2bcall architecture 
- docs/ARCHITECTURE.md: decisoes de arquitetura (monorepo, rede Asterisk host
  mode, realtime PJSIP, camada de telefonia, seguranca desde o design)
- TODO.md: checklist vivo de implementacao por fases
- estrutura inicial do monorepo (apps/, packages/, infrastructure/, scripts/)
- docker-compose.yml: postgres 17 + redis 7 com healthchecks, sem portas
  publicadas no host, schema 'asterisk' dedicado no Postgres
- .env.example + scripts/generate-secrets.sh
2026-08-27 10:17:07 -03:00

6.2 KiB
Raw Blame History

B2BCall — TODO Operacional

Checklist vivo. Marcar [x] somente após testar. Não deixar item concluído sem validação. Ver critérios de aceite completos em docs/ARCHITECTURE.md e no prompt mestre original (agente.md, seções 90-93).

Fase 0 — Infraestrutura base

  • Levantamento do servidor (SO, recursos, rede)
  • docs/ARCHITECTURE.md
  • TODO.md
  • Git init + .gitignore + primeiro commit
  • Instalar Docker Engine + Compose plugin (29.7.2 / Compose v5.5.0)
  • Estrutura de diretórios do monorepo
  • .env.example (+ scripts/generate-secrets.sh, .env real gerado localmente)
  • nftables (firewall base, default-deny administrativo, sem bloquear SSH) — adiado para a Fase 9, quando houver serviços/portas reais a proteger

Fase 1 — Dados e cache

  • docker-compose: serviço postgres 17-alpine (schemas application/asterisk) — testado, healthy
  • docker-compose: serviço redis 7-alpine (auth, AOF, maxmemory 100mb) — testado, healthy
  • Health checks postgres/redis
  • packages/database: schema inicial + migrations tool

Fase 2 — Asterisk

  • Dockerfile Asterisk 22 LTS (host network)
  • PJSIP (transports, sem chan_sip)
  • AMI habilitado (bind local/rede interna apenas)
  • ARI habilitado (idem)
  • Realtime ODBC -> Postgres (schema asterisk)
  • CDR, CEL, queue_log habilitados
  • Dialplan inicial de teste

Fase 3 — Backend base

  • apps/api (NestJS + Fastify) bootstrap
  • Autenticação (Argon2id, access+refresh, cookies HttpOnly)
  • Rate limiting (login e endpoints sensíveis)
  • RBAC (users/roles/permissions/user_roles/role_permissions) + tela de perfis
  • Auditoria (audit_logs) + interceptor genérico
  • Health checks /api/health(/live|/ready)
  • Swagger/OpenAPI (desabilitável em produção)

Fase 4 — Telefonia (camada de aplicação)

  • packages/telephony: TelephonyProvider + AsteriskTelephonyProvider
  • apps/asterisk-events (AMI listener, normalização, persistência, pub/sub)
  • CRUD Troncos (com CPS máximo, ACL, teste de status)
  • CRUD Ramais (senha SIP gerada, reset, status tempo real)
  • Painel visual de Ramais (WebSocket, prioridade de cores)
  • Dialplan estruturado (versionado, modo Advanced, validação+rollback)
  • Administração do Asterisk (abas: geral, pjsip, rtp, filas, cdr, cel, logs, ami, ari, modules, diagnóstico com allowlist de comandos)

Fase 5 — Call Center

  • Agentes (agents, agent_sessions) separados de users
  • Máquina de estados do agente (OFFLINE..PAUSED)
  • Motivos de pausa (CRUD)
  • Filas (CRUD + estratégias documentadas)
  • Tela do agente (login dinâmico, pausa/retomada, disposição)
  • Disposições de chamada (CRUD + ações: callback, DNC)
  • Callback (agendamento + scheduler)
  • Monitoramento de Filas (tempo real)

Fase 6 — Campanhas e discador preditivo

  • CRUD Campanhas (todos os campos da seção 24)
  • Import CSV streaming (preview, mapeamento, validação, duplicados, rejeitados)
  • Normalização de telefone (serviço dedicado, BR inicialmente)
  • Lista de supressão (DNC) + checagem obrigatória pré-originação
  • CPS limiter (token bucket, coordenado via Redis, multi-worker)
  • Reserva concorrente de leads (FOR UPDATE SKIP LOCKED + timeout)
  • Idempotência de originação (attempt_id/call_id/uniqueid/linkedid, state machine)
  • PredictiveDialerEngine (EWMA, pacing, previsão de liberação de agentes)
  • Controle de abandono (pacing cai / suspende originação)
  • AMD opcional por campanha
  • Wrap-up time
  • Retry engine (regras por causa, limite de tentativas)
  • Horário de campanha (timezone, dias/horários, WAITING_SCHEDULE)
  • Lock distribuído por campanha (Redis)
  • docs/PREDICTIVE_DIALER.md

Fase 7 — CDR, métricas e relatórios

  • Modelo consolidado de chamadas (CDR+CEL+AMI+queue_log)
  • Reconciliação de estados órfãos após restart
  • TME / TMA (definições documentadas, cálculo correto)
  • Relatório de Chamadas (filtros, paginação server-side, export CSV)
  • Relatório de Agentes (tempos, pausas detalhadas)
  • Dashboard geral (cards + gráficos reais)
  • Dashboard do discador (por campanha, tempo real)
  • Compliance de Chamadas (parâmetros configuráveis, alertas, contadores)

Fase 8 — Frontend completo

  • Bootstrap Next.js + Tailwind + shadcn/ui + TanStack Query + WS client
  • Logo processada (b2bcall.png) + tema light/dark
  • Menu completo (seção 52)
  • Todas as telas do checklist de aceite (seção 90)

Fase 9 — Segurança e produção

  • Criptografia de segredos de trunk (AES-256-GCM)
  • HTTP security headers, CORS, CSRF, Helmet
  • nftables final revisado
  • Logs estruturados JSON (sem segredos)
  • Correlation IDs (request_id/attempt_id/call_id)
  • Métricas Prometheus (/metrics)
  • Bootstrap super_admin (senha aleatória, FIRST_LOGIN.txt, forçar troca)
  • Seed (permissões, perfis, pausas, disposições) sem dados fake em produção
  • Backup/restore (postgres, asterisk config, .env seguro)
  • scripts/install.sh, update.sh, backup.sh, restore.sh, healthcheck.sh
  • Nginx reverse proxy (80/443, WS, HTTPS documentado)

Fase 10 — Testes e aceite

  • Unit tests (predictive engine, CPS limiter, permissions, phone norm, retry, state machines, TME/TMA, scheduling)
  • Integration tests (postgres, redis, repositories, API, AMI mock)
  • E2E (login → ... → RBAC, conforme seção 64)
  • Modo simulação (DIALER_SIMULATION=true) + testes do predictive engine
  • Prova de CPS respeitado / concorrência máxima / sem discagem dupla / pausa efetiva / recuperação após restart / pacing reage a abandono / supressão respeitada / horário respeitado
  • Quality gate (lint, typecheck, unit, integration, e2e, compose config, compose ps, health checks) — tudo verde
  • Aceite de segurança (seção 92)
  • Aceite Asterisk (seção 93, comandos documentados)
  • README final completo
  • Relatório final da implementação

Nota de ambiente: VM atual com 1.9 GiB RAM / 2 vCPU — adequada para dev e simulação, não para carga real de produção. Ver docs/ARCHITECTURE.md seção 1.

Reference in New Issue View Git Blame Copy Permalink