O que foi coberto
Resumo executivo do recorte auditado.
/webhook
3 PHP
listener principal, adaptador de envio e agendamento de confirmação
/webhook/sessions
63 JSON
persistência local do estado da conversa por cliente + profissional
Dependências cruzadas
O listener do webhook só faz sentido quando lido junto destas áreas.
- menuia.php depende de ../sistema/conexao.php e consulta tabelas de agenda, clientes, serviços, usuários e configuração.
- confirmacao.php agenda callbacks em ../ajax/retorno.php quando o provedor ativo é Enviame.
- api-texto.php usa variáveis já carregadas pelo chamador; ele não é endpoint externo independente.
- O /webhook convive com pagamentos/webhook.php, mas os papéis são diferentes: um atende mensageria/chat e o outro pagamentos.
Achados reais
Constatações do código auditado que ajudam o próximo dev a entender o recorte.
- O núcleo real do recorte é menuia.php; os outros dois PHPs funcionam como auxiliares contextuais.
- O estado do chatbot fica em arquivos JSON no disco, não no banco, o que muda backup, limpeza e permissão de escrita.
- Há escrita de dados de negócio dentro do listener, então o problema pode aparecer no chat mas a causa real estar em agenda/cliente/serviço.
- Existe logging local em menuia_debug.txt, útil para depuração mas sensível a crescimento e exposição.
Sobreposições que o dev precisa entender
Não são bugs da doc; são cruzamentos reais da arquitetura.
- Mensageria também aparece em /ajax, /cron e áreas de pagamentos, mas /webhook centraliza o listener do chatbot e os adaptadores locais de mensagem.
- O callback de confirmação conversa com ../ajax/retorno.php; por isso um bug “no webhook” pode exigir leitura de /ajax.
- Telas públicas, agenda e financeiro são afetados pelo listener, então o diagnóstico correto costuma atravessar mais de uma pasta.
O que ainda falta fora do painel
Depois de fechar /webhook, estas viram as lacunas externas centrais.
/app, /apps e /public/config e utilitários residuais
Conclusão
No recorte /webhook, a cobertura técnica agora fica fechada.
O próximo dev já consegue localizar o listener real, entender o papel dos adaptadores internos,
seguir a persistência em sessions/*.json e mapear as integrações mais sensíveis.