- apps/frontend: Next.js 15 (App Router) + Tailwind v4 + componentes estilo
shadcn/ui sobre Radix UI + TanStack Query. Tema light/dark, logo
processada. Menu completo (secao 52) com gating por permissao real.
Todas as telas do checklist de aceite (secao 90) conectadas a endpoints
reais (nao mockup): login, usuarios, perfis/permissoes, ramais/troncos,
dialplan, filas/agentes, console do agente, campanhas (CPS/CSV/
iniciar/pausar), monitoramento ao vivo (polling, nao WebSocket real),
TME/TMA, busca/export de chamadas, administracao do Asterisk, auditoria
- infrastructure/nginx: reverse proxy colocando frontend+API na mesma
origem (porta 80), antecipado da Fase 9 pois a API nao publica porta
propria
- apps/api: GET /api/monitoring/agents (estado corrente real via
agent_state_events em aberto) e filtro queueId em GET /api/reports/calls
Pendencia registrada: tela de Callbacks nao implementada (schema existe
desde a Fase 6, mas nunca houve controller/service — construir a tela sem
API real seria mockup). Verificacao visual em navegador nao foi possivel
neste ambiente headless; validado via tsc/eslint/next build limpos + curl
reproduzindo as chamadas do navegador (middleware de auth, 24 paginas
protegidas via Nginx, endpoints de dados com cookie de sessao).
- Reconciliação de tentativas órfãs após restart (reconciliation.ts),
rodando a cada 60s.
- Vínculo real agente<->chamada (agent-call-binding.ts): claim atômico de
agente disponível via FOR UPDATE SKIP LOCKED, DialAttempt.agentId
populado no connect, ciclo AVAILABLE -> IN_CALL -> WRAP_UP -> AVAILABLE.
- Corrige abandonRate (EWMA) nunca atualizado pelo campaign-worker real —
agora o fluxo QUEUED -> connect-or-abandon atualiza as estatísticas de
fato usadas pelo predictive engine.
- Novo módulo de relatórios: /api/reports/calls (+export CSV), /metrics
(TME/TMA/abandono), /agents/:id.
- Novo módulo de dashboard: /api/dashboard, /calls-by-hour,
/campaigns/:id (Postgres + snapshot EWMA do Redis).
- Novo módulo de compliance: ComplianceSettings configurável +
/api/compliance/settings e /indicators com contadores reais.
- Validado end-to-end contra containers reais (campanha de teste em modo
simulação): agentId no connect, ciclo de estado do agente e abandonRate
todos confirmados corrigidos com dados reais, não só no harness isolado.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QoVkLx1KsvtT1C88dRS3QW
- packages/database: Campaign, LeadImport, Lead, DialAttempt,
CallDisposition, Callback, SuppressionEntry (agente.md secao 53)
- packages/shared: normalizePhone (BR, E.164) com 7 testes unitarios
- apps/api/src/campaigns: CRUD completo (todos os campos da secao 24) com
maquina de estados validada (DRAFT/READY/RUNNING/PAUSED/DRAINING/
STOPPED/COMPLETED) — edicao bloqueada com campanha RUNNING
- apps/api/src/leads: import CSV via streaming multipart (deteccao
automatica de delimitador, mapeamento de coluna por header, validacao+
normalizacao+dedupe em lotes de 500, CSV de rejeitados com motivo, modo
dryRun para preview)
- apps/api/src/suppression: CRUD + import CSV da lista de bloqueio,
remocao sempre exige motivo e e auditada, isSuppressed() pronto para o
dialer-worker checar antes de originar
- apps/api/src/dispositions: CRUD de disposicoes de chamada
Testado ponta a ponta: campanha criada com defaults corretos, import de
CSV real (3 validos/1 invalido/1 duplicado, contadores batendo), leads
persistidos com telefone normalizado, transicoes de estado da campanha
rejeitando movimentos invalidos (PAUSED->PAUSED = 400).
- packages/database: Agent, AgentSession, AgentStateEvent, AgentPauseEvent,
PauseReason, Queue, QueueMember (agente.md secao 53)
- apps/api/src/queues: CRUD de filas gerando queues.conf pelo mesmo padrao
do dialplan (arquivo compartilhado + module reload app_queue.so), mas
SEM membros estaticos no arquivo — membership eh 100% dinamica via AMI
(evita duas fontes de verdade conflitantes)
- apps/api/src/pause-reasons: CRUD de motivos de pausa
- apps/api/src/agents: CRUD administrativo de agentes (1:1 com User)
- apps/api/src/agent-console: maquina de estados do agente
(LOGGED_IN/AVAILABLE/PAUSED), 'tela do agente' via
login/available/pause/unpause/logout, cada transicao aciona AMI
QueueAdd/QueuePause/QueueRemove de verdade e registra
agent_state_events/agent_pause_events com inicio/fim
- apps/api/src/monitoring: GET /api/monitoring/queues (chamadas
aguardando, agentes logados/pausados/disponiveis via AMI QueueStatus ao
vivo) — metricas historicas (TME/TMA/SLA) ficam para a Fase 7
Testado ponta a ponta contra o Asterisk real: fila criada aparece via
'queue show'; agente loga, fica disponivel (QueueAdd confirmado, membro
dinamico visivel), pausa com motivo (confirmado 'paused:Almoco' ao vivo),
despausa, desloga (QueueRemove confirmado, fila volta a 'No Members').
Disposicoes de chamada e Callback adiados para a Fase 6 (dependem de
haver chamadas de campanha reais para classificar).
- packages/database: DialplanEntry + DialplanVersion (schema/config
gerado, nunca dialplan cru vindo do usuario)
- apps/api/src/dialplan: DialplanService gera extensions a partir de
entradas estruturadas (campos com allowlist estrita de caracteres),
escreve em arquivo compartilhado via volume Docker 'dialplan-generated'
entre api e asterisk, recarrega via AMI ('dialplan reload') e valida
checando 'dialplan show <contexto>' por marcadores de erro. Falha na
validacao dispara rollback automatico para a versao anterior; rollback
manual tambem disponivel para qualquer versao no historico
- infrastructure/asterisk: extensions.conf agora inclui o arquivo gerado
pela aplicacao; entrypoint garante que ele existe (vazio) no primeiro
boot antes da primeira publicacao
- apps/api/src/asterisk-admin: status (AMI + heartbeat), module show, e
diagnostico com ALLOWLIST ESTRITA de comandos exatos (nunca shell
arbitraria) — agente.md secao 22
Testado ponta a ponta contra o Asterisk real: dialplan publicado fica
ativo imediatamente sem restart (confirmado via 'dialplan show'),
comando de diagnostico fora da allowlist rejeitado com 400.
- apps/api/src/telephony: TelephonyModule (conexao AMI da API para
comandos de controle) + PjsipRealtimeService (unico ponto de escrita nas
tabelas realtime do schema 'asterisk' via Prisma $executeRaw
parametrizado)
- apps/api/src/trunks: CRUD completo (tipos IP/AUTH/REGISTRATION), secret
cifrado em repouso (AES-256-GCM), endpoint de teste de status via
PJSIPShowContacts/pjsip show registration
- apps/api/src/extensions: CRUD completo, senha SIP gerada
automaticamente, endpoint de reset, nunca reexibe a senha apos a criacao
- apps/api/src/monitoring: GET /api/monitoring/extensions com prioridade
de cor (agente.md secao 15) a partir do ExtensionState alimentado por
apps/asterisk-events
- health check agora reporta status real do Asterisk/AMI via heartbeat do
asterisk-events no Redis, sem precisar de conexao AMI propria para isso
Testado ponta a ponta contra o Asterisk real: ramal e tronco criados via
API aparecem imediatamente via 'pjsip show endpoint' sem reload (realtime
funcionando), secret nunca retornado pela API, exclusao em cascata
confirmada (ps_endpoints/ps_auths/ps_aors/ps_contacts/ps_registrations).
- packages/database: schema Prisma (users/sessions/roles/permissions/
user_roles/role_permissions/audit_logs/password_reset_tokens), migration
inicial e seed (permissoes+perfis+bootstrap super_admin com senha
aleatoria em FIRST_LOGIN.txt). Decisao de ORM (Prisma) documentada em
docs/ARCHITECTURE.md
- packages/shared: catalogo de permissoes (fonte unica usada por seed e API)
- apps/api: NestJS 11 + Fastify
- autenticacao: Argon2id, access JWT + refresh token opaco com rotacao,
cookies HttpOnly/SameSite=Lax, change/forgot/reset password
- rate limiting progressivo de login via Redis (bloqueio crescente por IP)
- RBAC reforcado no backend (PermissionsGuard), protecao contra
auto-elevacao de privilegio
- auditoria (audit_logs) nas acoes sensiveis, com redacao de segredos
- health checks reais (postgres+redis), swagger desabilitavel, logs
estruturados JSON com request_id de correlacao, filtro global de
excecoes sem vazar erro cru
- infrastructure/docker/api.Dockerfile: build multi-stage do monorepo pnpm
- docker-compose.yml: servico api na rede interna, sem porta publicada
Testado via containers reais: login, /me, refresh, change-password,
rate limit (7 tentativas -> 429), RBAC (nega/permite), bloqueio de
auto-elevacao (403), audit log populado, health checks, lint e testes
unitarios passando.
