- 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.
- infrastructure/docker/asterisk.Dockerfile: Asterisk 22.10.1 LTS compilado
do fonte oficial (Debian trixie nao distribui mais o pacote asterisk),
com PJSIP, AMI, ARI, res_odbc/res_config_odbc, cdr_adaptive_odbc,
cel_odbc, app_queue
- infrastructure/asterisk/config: templates renderizados no entrypoint
(secrets via envsubst, nunca versionados) + sorcery.conf/extconfig.conf
para PJSIP realtime, dialplan de teste (extensao 600)
- infrastructure/postgres/init/002-asterisk-realtime.sql: tabelas
ps_endpoints/ps_auths/ps_aors/ps_contacts/ps_endpoint_id_ips/
ps_registrations/cdr/cel no schema 'asterisk'
- infrastructure/nftables: protege AMI/ARI/SIP contra acesso pela LAN
(interface ens18), trazido da Fase 9 do TODO para ja, sem afetar SSH
nem a rede interna do Docker
- docker-compose.yml: servico asterisk em network_mode: host (RTP);
Postgres publicado em 127.0.0.1:5432 (nao 0.0.0.0) para o Asterisk
alcanca-lo, ja que host network nao enxerga a rede Docker interna
Testado: AMI login, ARI com auth (401 sem auth), pjsip realtime
consultando Postgres sem erro, dialplan originate -> CDR e CEL gravados
corretamente, healthcheck do compose passando.
