Projeto: RioNoTeatro. Fonte principal: /www/wwwroot/rionoteatro.com.br/docs/CHANGELOG.md.

Changelog - Rio no Teatro

> Changelog = historico do que ja foi entregue e validado.

> Backlog vivo de cada BK fica em docs/backlog/BK-XX-*.md.

> Antes de alterar regra compartilhada de governanca/workflow, comparar este repositorio com /root/cerebro.

2026

[2026-10-18] Página /parceria-vendas; "Sem repasse. Vendas abaixo dos R$50"; relatório com divulgação e vendas da temporada

Pedidos do ADMIN (18/10): (1) no relatório de fim de temporada (só admin), custo com divulgação, pessoas que viram os anúncios, que acessaram a página, que compraram e o total arrecadado — só da última temporada; (2) mês com vendas abaixo de R$ 50 não tem repasse: mostrar "Sem repasse. Vendas abaixo dos R$50" (admin e produtor), com o trecho da regra no topo da tela do produtor e mantendo o comprovante no admin; (3) página /parceria-vendas com as regras e botão para o produtor aceitar pelo WhatsApp (peça, link oficial, valor promocional, celulares da lista, 20 assentos, "Li e aceito as regras da parceria com vendas e comissão").

Mudança: admin/modulos/pecas/relatorios.php — bloco "Divulgação e vendas" da última temporada (detectada pelas sessões: pausa > 30 dias separa temporadas): custo/exibições/cliques Meta+Google pelos dias da janela (30 dias antes da 1ª sessão até a última; de /www/rnt-deploy/status/divulgacao_pecas.json), alcance total da campanha, visitas à página (cliente_tracking view_item), compradores e arrecadado (pagos 3/4, sessão na temporada); fechamento < R$ 50 = "Sem repasse" (Marcar como pago continua) e botão de WhatsApp sem pedir dados bancários. produtor/fechamento.php — mês < R$ 50: quadro com itens 5.2 e 13 do termo, "Sem repasse. Vendas abaixo dos R$50" e sem o botão de aprovar/PIX. parceria-vendas.php (novo) + includes/termo_parceria_regras.php (texto do termo extraído; termo-parceria.php passa a incluir, saída idêntica). Regras seguem 30 ingressos (20 em sala pequena); o aceite pelo WhatsApp é sempre 20 (o ADMIN pede mais com boa venda). Fora do Git: rewrite nginx /parceria-vendas (e /parceira-vendas → 301); rnt-tools/motor_divulgacao_resumo.php (cron :43, por dia, não sobrescreve com erro).

Validado: Sintaxe PHP ok (php83); JS inline validado (simulação do formulário e da mensagem); nginx -t, curl 200/301 e páginas de peça intactas; termo idêntico (diff só de ids aleatórios); relatório e tela do produtor renderizados (mês < R$ 50 e mês normal). gpt-6-astra: P2 corrigidos (celular sem DDD, número enganoso, anúncios por temporada), revisão final sem P1/P2.

[2026-10-18] Fim de temporada: WhatsApp à produção + push ao ADMIN; Google para 1h antes da última sessão; aviso "pausar" sem ruído

Pedidos do ADMIN (18/10): (1) Google parar sozinho 1h antes da última sessão; (2) calar o aviso "pausar" da rotina simulada quando a campanha já terminou sozinha; (3) "quando a temporada termina, push com link do relatório de vendas, e mensagem para a produção perguntando se a peça irá prorrogar (tem no e-mail, deveria ter no WhatsApp)".

Mudança: admin/cron/fim_temporada_whatsapp.php (novo; /etc/cron.d/rnt-fim-temporada-whatsapp, 10h) — no dia seguinte à ÚLTIMA sessão (tab_sessoes, não fim_temporada), mesmo filtro do e-mail do z_dispara_diario.php (ativa, venda própria ou parceria_online=1; fora origem='bot'): WhatsApp à produção (rnt_fin_whatsapp_produtor, sem celular = não envia, nunca SAC) com o texto aprovado pelo ADMIN ("Boa tarde! Tudo bem? / A temporada de X terminou em dd/mm. Vamos ter prorrogação ou nova temporada? / Agradecemos desde já a parceria e seguimos a disposição! / Jorge | Rio no Teatro 15 anos"); mesmo número com 2+ peças = 1 mensagem (anti-spam dos últimos 100 bytes); push ao ADMIN por peça (push_eu.php) com admin/modulos/pecas/relatorios.php?id=X. Trava, reserva na tabela rnt_fim_temporada_aviso antes de enviar (uma vez por peça+última sessão), falha de banco para tudo, --data só com ensaio/teste. Fora do Git: rnt-tools/motor_google_fim.php (cron 15/15 min) pausa a campanha do Google 1h antes da última sessão (a API não aceita término com hora) e religa só o que pausou se a peça for prorrogada (respeita motor_anuncios.PARAR); Cinderela Negra pausada no Google. motor_anuncios_rotina.php não avisa "pausar" quando o end_time do conjunto já passou.

Validado: Sintaxe PHP ok (php83); ensaio do Google (só Cinderela) e aplicação real; ensaio do fim de temporada (Cinderela Negra e Discutindo a Relação, celulares da produção achados) e 3 testes idênticos só para o gestor (WhatsApp + push), texto aprovado pelo ADMIN. gpt-6-astra: P2 (PARAR no religar) e 4 P2 do fim de temporada corrigidos.

[2026-10-18] BK-566 fechado: motor não religa anúncio pausado à mão + campanha da Meta termina 1h antes da última sessão

Pedidos do ADMIN (18/10): "manda o BK-566 pra frente agora"; "a campanha tinha que ter sido programada para acabar 1 hora antes da peça, sem necessidade de pausar ao fim da temporada".

Mudança BK-566: admin/modulos/campanhas/api/fb_dashboard.php — ao pausar anúncio, o ID entra em /www/rnt-deploy/status/anuncios_pausa_manual.json ANTES do pedido à Meta; ao religar, sai só depois da Meta confirmar; tudo sob a trava fixa anuncios_pausa_manual.lock (temporário exclusivo + rename no JSON); lista sumida/inválida recusa a operação; marca "pausa manual" na lista de anúncios. Fora do Git: motor_anuncios_conf.php (motor_pausas_manuais(), motor_pausas_travar()), motor_anuncios_auto.php — ativação inicial, --ligar e "anúncio novo" pulam os IDs pausados à mão; todos pausados = campanha não liga; lista ilegível/sumida = não liga nada; aviso uma vez.

Mudança término: MOTOR_HORAS_ANTES_FIM = 1 (era 3h) em motor_anuncios_meta.php e motor_anuncios_auto.php; as 4 campanhas da Meta ajustadas (ex.: Discutindo a Relação 16:00 → 18:00 de hoje). Google: a API recusa término que não seja fim do dia (DATE_RANGE_ERROR_END_TIME_MUST_BE_THE_END_OF_A_DAY), continua 23:59:59 do último dia.

Validado: Sintaxe PHP ok (php83); ad_pause real como www em anúncio já pausado (lista, marca, motor lê com trava); lista corrompida/sumida = não liga; ensaios Meta e Google; aplicação real na Meta ok. gpt-6-astra: 1 P1 (trava do motor sobrescrita) + 1 P2 (lista sumida recriada) corrigidos, nova passada sem P1/P2.

[2026-10-18] Deploy automático desligado: push só guarda no GitHub; deploy manual só publica o .env

Pedido do ADMIN (18/10): "ninguem mexe em outro lugar mais, so VPS"; "so seria preciso o deploy qdo alterada alguma senha"; permissões e afins por "um script nosso mais rapido q o deploy".

Mudança: .github/workflows/deploy.yml virou "Publicar senhas (.env) - manual" — só workflow_dispatch, só monta e publica o .env (mesmas 43 linhas de Secret) + smoke; sem rsync, composer ou build. AGENTS.md: seção "Deploy: so manual, so senhas". Fora do Git: /root/rnt-tools/rnt_pos_commit.sh (post-commit em /usr/local/libexec/rnt/git-hooks/, o core.hooksPath): dono/permissão dos arquivos do commit e pastas (segredos de fora, executável preservado), api/eventos, composer install se mudou, aviso se o scraper mudou, smoke com Host certo; log backups/rnt_pos_commit.log. pre-push (BK-489) só avisa edição sem commit. /root/rnt-tools/publicar_senhas.sh dispara o workflow, acompanha a execução certa e falha se token sumir ou o monitor do MP não der OK.

Validado: YAML ok; bash -n ok; rnt_pos_commit.sh em 2 commits reais (inclusive arquivo novo); gpt-6-astra: 2 P2 do publicar_senhas.sh corrigidos.

[2026-10-18] Motor de anúncios: rodada diária às 05:00 (era 9h), aviso ao gestor às 9h

Pedido do ADMIN (18/10): "vamos mudar para as 05:00 e nao mais as 9h"; o aviso de campanha ligada/término ajustado fica segurado até as 9h.

Mudança: admin/modulos/campanhas/api/fb_dashboard.php — texto "Roda sozinho todo dia às 5h (o aviso no WhatsApp chega às 9h)". Fora do Git: /etc/cron.d/rnt-motor-anuncios (rodada 0 5, novo 0 9 com motor_avisos_soltar.php); motor_anuncios_auto_rodar.sh exporta MOTOR_SEGURAR_AVISO_ATE=9 só na rodada diária (o botão "rodar agora" avisa na hora); motor_anuncios_conf.php — motor_avisar_gestor() guarda o aviso em backups/motor_avisos_segurados.json antes das 9h (Rio).

Validado: Sintaxe PHP ok (php83), bash -n ok; fila testada com aviso falso sem envio (guardado, listado no --ensaio, apagado).

[2026-10-18] Push ao ADMIN com link para abrir e texto para copiar (push_eu.php + copiar.php)

Pedido do ADMIN (18/10): "sempre que eu precisar clicar em um link aqui você me envia o link pelo push, e quando for um texto para eu copiar também, com o botão de copiar sempre no push". Depois: só no Android; botão Copiar também no push de link; não fechar a aba sozinho; texto editável antes de copiar.

Mudança: copiar.php (raiz, novo) — mostra o texto gravado em /www/rnt-deploy/copiar/<token>.json (pasta do root, www só lê, vale 24h), copia sozinha quando aberta pelo botão Copiar (auto=1 ou pclick=copiar do sw antigo), texto editável, no-store/noindex/no-referrer/CSP, texto escapado. sw.js — requireInteraction opcional (fixo), endereço próprio por botão (data.acoes), pclick só em link do próprio site (origem exata; link externo abre intacto), clique em qualquer botão conta como "botao" no BK-481. js/rnt-push.js — a cada página pede registration.update() (o sw.js tem cache de 30 dias e o Android ficou preso na versão antiga; o log mostrou que ele nunca buscou o novo) + ?ver=1.5 em admin/inc-footer.php e includes/inc_peca.php. Fora do Git: /www/rnt-push-sender/send.php ganhou --action-id, --tag, --fixo, --inscricao e segundo botão (--button2/--action-id2/--url2); /root/rnt-tools/push_eu.php (--link= com Abrir+Copiar, --copiar=/--copiar-arquivo= com Copiar), só para a inscrição #223 (Android do ADMIN), recusa texto com formato de senha/token/chave. Regra em /root/AGENTS.md e na memória: link/texto acionável sempre também por push.

Validado: Sintaxe PHP ok (php83); Sintaxe JS ok (sw.js, rnt-push.js); JS inline validado; copiar.php pelo site (XSS escapado, cabeçalhos, token inválido/inexistente); ensaio só com #223; 5 testes reais no Android (Abrir, Copiar após atualizar o sw, permissão de cópia só na 1ª vez, editar e copiar). gpt-6-astra sem P1/P2 (2 passadas).

[2026-10-18] Deploy não apaga mais o GOOGLE_ADS_REFRESH_TOKEN do .env

Pedido do ADMIN (18/10): "pq isso sempre acontece? vamos corrigir p nao acontecer mais".

Causa: /usr/local/libexec/rnt/publicar_env.sh substitui o .env inteiro pelo candidato montado dos GitHub Secrets; o refresh token é gravado no servidor pelo google_ads_oauth_callback.php e não existe como Secret, então sumia em todo push (e o .env mudado obrigava restaurar + --seal do monitor do MP).

Mudança (fora do Git): publicar_env.sh ganhou MANTER_DO_SERVIDOR=GOOGLE_ADS_REFRESH_TOKEN: se o candidato não traz valor (ausente, vazio, só espaços ou CR), a linha do .env atual é copiada literalmente para um arquivo de trabalho; candidato com valor vence. Validações (obrigatórias, contagem, duplicadas) rodam no arquivo final; nenhum valor é impresso. deploy.yml: comentário atualizado (não criar Secret nem linha vazia para o token).

Validado: cópia isolada do script em 5 casos (sem token → .env final idêntico ao real; vazio; só espaços; vazio com CR; token no candidato vence) + --dry-run; bash -n ok. gpt-6-astra: 1 P2 (espaços/CR) corrigido. Pendente: prova no próximo deploy real (--check OK sem restaurar nada). Resíduo: callback e deploy ao mesmo tempo podem perder um token recém-gerado (raro: consentimento manual).

[2026-10-18] Mapa de assentos sem "Cadeirante" + aba "Textos de divulgação" (BK-564) — commit do trabalho da madrugada

Pedido do ADMIN (18/10): commitar junto com o painel de anúncios o que estava no ar sem commit (o push travava pelo BK-489).

Mudança: peca.php — "Cadeirante" saiu da legenda do mapa (não vendemos online, só na bilheteria), legenda no verde do assento livre, datas no celular ajustadas. admin/modulos/campanhas/redes_sociais.php — aba "Textos de divulgação" (BK-564: textos de Reels/Feed escritos por IA), com redes_sociais_textos.php, textos_divulgacao_action.php, textos_divulgacao_lib.php, admin/js/textos-divulgacao.js e admin/cron/textos_divulgacao.php. BACKLOG: BK-565 aberto.

Validado no commit: Sintaxe PHP ok (php83) nos 6 arquivos; Sintaxe JS ok; sem segredo nos arquivos novos. A validação de tela é a da sessão que fez o trabalho.

[2026-10-18] Painel Meta: anúncios de cada campanha com pausar/ligar; fim do PHP 5.6; legenda do carrossel sem log do dotenv

Pedidos do ADMIN (18/10): (1) o carrossel aprovado saiu com [dotenv@17.3.1] injecting env... no início da legenda; (2) impulsionar o Reels de "Uma Velha Canção" com link marcado para a página da peça e ver os anúncios no painel fb_dashboard.php (só listava campanhas); (3) acabar com a compatibilidade com o 5.6 sempre que mexermos num arquivo.

Mudança: admin/modulos/campanhas/api/facebook_ads.php ganhou getAccountAds()/getAccountAdInsights() (conta inteira, seguindo a paginação da Meta, com incompleto), getAd(), setAdStatus() (só ACTIVE/PAUSED) e getAdAccountId(). fb_dashboard.php: "Anúncios (N)" embaixo de cada campanha (situação real em português, gasto/impressões/cliques/CTR do período, prévia, pausar/ligar); POST ad_pause/ad_activate exige CSRF, ID numérico e reconsulta na Meta que o anúncio é da conta e da campanha da linha; recusa arquivado; error_log com quem mudou; aviso quando a lista vier incompleta. AGENTS.md: 5.6 encerrado (lint só php83 -l; modernizar o arquivo que for mexido; v83.sh u deixa de ser rollback garantido).

Fora do Git: anúncio MOTOR p1652 ... | reels (ID 120253405404680418) criado no conjunto do motor com o Reels Dent_EDtTgr, botão Comprar agora e utm_content=reels, ligado e aprovado. Legenda: quiet:true no dotenv de cerebro/tools/groq_cli.js, kimi_cli.js e kernel/social_creative_service.js (cerebro 591e01e) + filtro dotenv@ em rnt-tools/carrossel_semanal.php; legenda do Facebook do post 20261018-ultimodia corrigida pela API (Instagram corrigido à mão pelo ADMIN).

Validado: Sintaxe PHP ok (php83); render GET logado em CLI com 16 anúncios em 9 campanhas (igual à Meta); POST recusa campanha errada, ID inválido e CSRF ruim sem escrever na Meta; ligar anúncio pela mesma chamada da API ok. gpt-6-astra sem P1/P2. Pausa manual de anúncio do motor só é desfeita se a peça for religada à força pelo motor.

[2026-10-17] BK-563: aba "Vídeo promo" no Gestor de peças (editor de vídeo básico)

Pedido do ADMIN (17/10): subir os vídeos que o produtor manda, cortar (em geral tirar o flyer de informações do final), juntar vídeos, pôr a nossa arte no final e exportar MP4 em formato storie ou feed. Ao longo do dia: listar os vídeos da aba Storie, linha do tempo com arrastar e soltar, edições salvas (várias por peça), botões Cortar/Dividir, play/pausar/continuar a partir de qualquer ponto, 3 tipos de transição com tempo, camadas por cima do vídeo (template da Arte promo, imagem/logo, texto) e limite de 5 min (Reels aceita 3 min).

Mudança: admin/modulos/pecas/video_promo_lib.php (acts video_promo_* em action.php; upload em pedaços de 4 MB porque o nginx corta POST > 50 MB; fontes em arquivos/pecas/<id>/video_promo/fontes/, apagadas em 30 dias; prontos em arquivos/pecas/<id>/video_promo/; edições salvas em admin/runtime/video_promo/rascunhos/<peca>/). admin/cron/video_promo.php + /etc/cron.d/rnt-video-promo (minuto, root, flock): ffprobe, converte HEVC/HDR para H.264, monta tudo num único ffmpeg (concat/xfade/acrossfade + overlays das camadas; selos com enable periódico, uma entrada por selo). Tela: admin/inc-gestor-video-promo.php + admin/js/gestor-video-promo.js (aba incluída por admin/inc-gestor.php). Exportar NÃO vira mídia dos stories automáticos sozinho: só pelo botão "Usar nos stories" (copia para video/).

Complemento (mesmo dia, pedido do ADMIN): as camadas viraram FAIXAS acima da linha do tempo, no mesmo eixo de tempo do vídeo final (arrastar a barra move a janela, bordas mudam início/fim, clique no fundo marca o ponto de reprodução); geometria respeita a largura mínima dos blocos curtos e o desconto das transições.

Fluxo: opencode (deepseek-v4.1-flash-free) escreveu o grosso em pedidos pequenos com diário + Monitor; Claude revisou/corrigiu; gpt-6-astra revisou em 7 rodadas (todos os P2 corrigidos, sem P1).

Validado: lint php83 + node --check; ensaios do cron (storie 1080x1920 e feed 1080x1350, transições com quadros conferidos, camadas template/selos/imagem/texto, 180 s renderizado em 87 s); importação da aba Storie (cópia md5 idêntica, original intacto, ../ recusado); capturas da tela em 1400/500 px com o JS real. Não validado: tela no navegador logado (teste do ADMIN).

[2026-10-17] Carrossel "Programa infantil do fim de semana" (sexta 10h) e regra de prioridade

Pedido do ADMIN (17/10): fazer a sugestao 3 (infantil de sexta). Regra permanente: SEMPRE nossas pecas a venda primeiro, com informacao completa; depois eventos do eventos.php so com nome, local e datas com horarios.

Mudanca (fora do Git, rnt-tools/carrossel_semanal.php): --edicao=infantil = nossas infantis com sessao ate domingo + infantis do eventos.php (mais acessados), ate 10 slides; sem nossa, so com 2+ eventos. Eventos passam a listar TODAS as sessoes da janela (ate 4). Edicao com 1 item vira post unico (Instagram nao aceita carrossel de 1). Correcoes do gpt-6-astra: "— ESTREIA" so na estreia de verdade; ultimos ingressos exige MAIS de 80%, inclusive com sessao indicada direto, e so marca a sessao se gerou; "ultimas apresentacoes" 1 por DIA. Pagina: rotulo de validade por tipo e previa do post unico com o video vertical do Reels. BK-562 aberto (captador traz pouco infantil).

Validado: lint php83/56; simulacoes (16/10 infantil = Cinderela; 23/10 = 1 evento so, nao gera); 18/10 ultimodia em carrossel com titulo no plural.

[2026-10-17] Posts "estreia", "ultimos ingressos", "ultimas apresentacoes" (qua-sex) e ultimo dia em carrossel; alerta com nome do status

Pedidos do ADMIN (17/10): fazer as sugestoes 1 (estreia) e 2 (ultimos ingressos); o post do ultimo dia vai num CARROSSEL com todas as pecas que encerram no dia (nao um post por peca), e durante a semana posts separados de "ultimas apresentacoes" para variar e nao amontoar no fim de semana. Alerta "Pedido pago mudou de status" mostrava so "status 11".

Mudanca (/root/rnt-tools/carrossel_semanal.php, fora do Git): --edicao=ultimodia agora agrupa todas as nossas com ultima sessao hoje (1 peca = post unico; titulo "Hoje sao as ultimas apresentacoes"); ultimasemana (qua-sex 9h) = 1 post por dia da peca que encerra primeiro ate domingo (nunca no ultimo dia; historico em backups/carrossel_ultimasemana.json); estreia (todo dia 9h) = post unico no dia da PRIMEIRA sessao de todas da peca, a partir das 13h; ultimos (a cada 2h, 9-19h) = post unico quando a sessao passa de 80% da cota (sec_total) em pedidos pagos - sec_quantidade NAO baixa com a venda -, uma vez por sessao. Carrosseis marcam "— ESTREIA" na peca que estreia na janela. Publicador e admin/modulos/campanhas/carrossel_semanal.php aceitam as edicoes novas.

Alerta: includes/compra_aprovada_avisos.php - rnt_ca_status_nome ganhou o 11 ("Virou credito na carteira do cliente", gravado por painel/modulos/pedidos/action.php) e mostra nome + codigo.

Validado: lint php83/56; simulacoes: 18/10 ultimodia = carrossel Cinderela + Discutindo; 31/10 estreia = Uma Velha Cancao; 28/10 ultimasemana = Labios Que Beijei (31/10 nao gera, e o ultimo dia); 19/10 segunda marca a estreia; ultimos hoje = nenhuma sessao > 80%.

[2026-10-17] Posts sazonais: "ultima semana em cartaz" (terca) e "hoje e a ultima apresentacao" (dia da ultima sessao)

Pedido do ADMIN (17/10): post no dia da ultima sessao (so venda online) e carrossel das pecas que encerram na semana; nunca na mesma hora: 3h de intervalo, intercalando; seg = carrossel da semana (eventos ate qui), ter = ultimas semanas.

Mudanca: /root/rnt-tools/carrossel_semanal.php ganhou --edicao=terca (nossas com a ultima sessao ate domingo) e --edicao=ultimodia (um post unico por peca, publica a partir das 13h, vence 1h antes da sessao; Reels com o video vertical no IG, foto no FB). publicar_carrossel_semana.php agora le uma FILA (/www/rnt-deploy/pedidos/<edicao>.json): 3h desde o ultimo post, intercala carrossel/unico, prioriza o que vence primeiro, avisa quando um post vence sem sair. admin/modulos/campanhas/carrossel_semanal.php aceita as edicoes novas, grava na fila e mostra horario/validade. Cron: ter 10h e todo dia 9h.

Validado: lint php83/56; ensaio de terca (Discutindo a Relacao + Cinderela Negra); simulacao de 18/10 09:00 gera os 2 posts do ultimo dia; teste da fila sem publicar: pedido aprovado ficou aguardando o intervalo de 3h e foi preservado. Nao validado: publicacao real de Reels (primeira em 18/10).

[2026-10-16] Registro das entregas do dia feitas pela sessao do opencode (conferido pelo gpt-6-astra)

Commits na main em 16/10 que nao tinham entrada propria neste changelog:

• f93325db0 fix(BK-538): oculta pecas expiradas da conciliacao e do alerta;
• 250e0ede4 scrapers Divertix e Ticketmaster (nasceram desligados); b1ea06fd2 deploy propaga TICKETMASTER_API_KEY dos Secrets; c82a49d3a liga os dois scrapers (prova em dry-run);
• b15647681 whitelist Algolia do Sympla aceita o tema TEATRO (o volume do Sympla subiu para ~465 eventos/rodada - motivo da cota por fonte);
• 70e8c8502, a21120fa8, 47da3be55: painel do bot com filtros, vigencia, deep-link e resumo por fonte; links oficial/site na conciliacao;
• dedff7b4d telas de conciliacao Divertix e Ticketmaster + limpeza exige fonte (nunca mais limpeza global);
• 3bb03d143 Squad Social usa sempre o video da peca quando existir (sem alternancia semanal).

Revisao do gpt-6-astra (17/10): codigo confere com as mensagens dos commits.

[2026-10-16] Carrossel semanal novo (segunda e quinta) substitui o do Squad

Origem: o ADMIN aprovou o carrossel "O que ver no teatro esta semana" publicado a mao em 16/10 ("muito melhor que o nosso squad tem feito semanalmente") e pediu para programar, incluindo "outros espetaculos" do eventos.php e duas edicoes.

Mudanca:

• admin/cron/sync_facebook_events.php: interruptor RNT_SQUAD_CARROSSEL_SEMANAL_ANTIGO (false) desliga o carrossel semanal antigo; 79 itens antigos parados em pending_approval desde abril foram cancelados (last_error = substituido_carrossel_jornalistico_20261016, backup em /root/backups-versionados/squad-carrossel-cancelado-*).
• admin/modulos/campanhas/carrossel_semanal.php (novo): previa (videos/fotos, legendas IG e FB, descricao por foto) e Aprovar/Descartar; link assinado (HMAC, mesmo segredo do ir_gerenciador.php) ou login do admin; grava pedido em /www/rnt-deploy/carrossel_semanal.pedido.
• Fora do Git (/root/rnt-tools): carrossel_semanal.php (gera seg/qui 10h; nossas a venda + ate 5 outros mais acessados em 7 dias pelo log do nginx - o site nao grava view_item nas paginas do evento.php -, senao sessao mais proxima; texto pelo opencode deepseek -> groq -> modelo fixo, conferido), publicar_carrossel_semana.php (le o manifest; IG carrossel video/foto, FB fotos com descricao; grava "publicando" ANTES de cada rede e, se uma tentativa nao confirmar, NAO republica sozinho - avisa para conferir; --forcar libera. Nao e garantia absoluta contra duplicata: e protecao contra repeticao automatica). Cron /etc/cron.d/rnt-carrossel-semanal.

Validado: lint php83/56; edicao de teste 20261016-quinta gerada sem aviso (texto do opencode, 1690 caracteres, 10 slides); pagina 200 com assinatura e 302 para o login sem ela; publicador em ensaio. Nao validado: o clique em Aprovar e a publicacao automatica (primeira edicao real: segunda 19/10 10h).

[2026-10-16] Monitor de integridade do Mercado Pago: o mesmo desvio so reavisa em 24h

Origem: o ADMIN recebeu 6 alertas no WhatsApp (2 numeros) entre 16:19 e 20:40 pelo mesmo desvio (config/bot_config.php editado de forma legitima e sem re-seal). Pedido: parar de "sujar a reputacao do WhatsApp a toa".

Mudanca: mp_guard_should_send_alert - mesmo hash de desvio volta a avisar depois de 86400 s (era 1800). Desvio novo continua avisando na hora, WhatsApp + push. O "PUSH - falhou" do log nao era falha: o push do gestor deduplica 24h por conteudo (push_dispatch.log: "SUPRIMIDO (dedup 86400s)"). Copias admin/cron/ e /usr/local/libexec/rnt/ mantidas iguais.

Validado: lint php83; --seal + --status OK. Licao (3a vez): editar arquivo monitorado (incl. config/bot_config.php) exige --seal logo depois, e todo push no RNT tambem (o deploy recria o .env).

[2026-10-16] [BK-460] Motor de anuncios automatico (Meta e Google) + botao no fb_dashboard

Decisao do ADMIN (16/10): peca com venda online (pecas.xml) ganha campanha SOZINHA e JA LIGADA na Meta e no Google, sem aprovacao; o gestor recebe o link e pausa se precisar. Termino acompanha a ultima sessao (prorrogou no admin -> prorroga nas campanhas). Verba R$ 10 de 24h antes ate 1h antes de cada sessao; regra por vendas so como AUMENTO (4 -> R$ 10, mais de 8 -> R$ 20); freios so avisam (atribuicao fraca, BK-560).

No repositorio: admin/modulos/campanhas/api/fb_dashboard.php ganhou o botao "Rodar motor de anuncios agora" (CSRF da tela; grava pedido em /www/rnt-deploy/motor_anuncios.pedido, o cron de root atende em ate 5 min) e a linha "ultima rodada" (/www/rnt-deploy/motor_anuncios.ultimo.json).

Fora do repositorio (/root/rnt-tools, sem Git): motor_anuncios_auto.php (Meta: cria pelo criador de sempre e liga so o que nasceu na rodada; rollback tudo-ou-nada; pendente com retentativa; termino so prorroga), google_ads_auto.php (Google v26: Search R$ 5/dia, endDateTime, nao recria removida, mapeia por link, limite 5 novas/rodada, titulo sem "OFF" - politica CAPITALIZATION), motor_verba_janela.php (cron */15), motor_conversao_pronta.php (segunda 10h, so avisa), motor_anuncios_auto_rodar.sh (9h + botao). Crons em /etc/cron.d/rnt-motor-anuncios. Desligar: /root/rnt-tools/backups/motor_anuncios.PARAR.

Corrigido no caminho: sync do Google nao rodava ha dias (cron como www sem poder criar o log; token apagado do .env a cada deploy) -> credencial so em /www/rnt-secrets/google_ads.env (fora do open_basedir do site); API do Google v22 em brownout -> v26.

Validado: lint php83/56 no fb_dashboard; ensaios das duas plataformas; validateOnly no Google (criar campanha, endDateTime, status, anuncio, palavra-chave); rodada real da verba as 20h (Lábios Meta+Google e Discutindo Meta para R$ 10, conferido por releitura); 1652 ligada pelo ADMIN (--ligar). Revisao: opencode NO-GO -> pontos corrigidos; gpt-6-astra sem cota (revisao agendada 21:50/21:56). Nao validado: criacao real (primeira rodada 9h de 17/10) e clique no botao.

[2026-10-16] Bot captador: cota por fonte no botao, cron sem limite, Sympla por ultimo

Origem: o ADMIN sentiu falta de eventos (Divertix tinha 14 na home e 0 na fila). O teto global BOT_MAX_EVENTOS_POR_EXECUCAO=50 (trava provisoria de 08/08) era consumido pelo Sympla, primeiro da fila (465 eventos apos o tema TEATRO), e Eventim/Divertix/Ticketmaster nem rodavam (log: "Limite de eventos atingido (50). Parando execucao.").

Medido: rodada de 16/10 16:28-16:52 com o site no ar: 571 requisicoes, 0 erros 5xx; ~28 s por evento.

Mudanca:

• config/bot_config.php: teto global 0 (cron das 4h sem limite); BOT_LIMITE_POR_FONTE_BOTAO=40; BOT_TEMPO_MAX_EXECUCAO=10800 (3h).
• bot/cron_captador.php: aceita --limite-fonte=N.
• bot/captador.php: cota por eventos PROCESSADOS por fonte (o custo vem antes de virar sugestao); teto de tempo entre eventos; Sympla roda por ultimo.
• admin/modulos/bot/action.php: o botao passa --limite-fonte=40 (o painel nao carrega o bot_config; valor duplicado e documentado nos dois lados).

Validado: lint php83 e 5.6 nos 4 arquivos; dry-run --limite-fonte=2/3 processou as 4 fontes na ordem eventim, divertix, ticketmaster, sympla. gpt-6-astra: 2 NO-GO corrigidos, GO na 3a rodada. Residuo (timeout de chamada externa e cursor entre rodadas) virou BK-558.

[2026-10-16] Conciliacao: "reativar" abre como evento do bot e sempre pega a foto nova

Origem: o ADMIN reativou 3 pecas na aba Reativar (#94 A Bela e a Fera, #166 Allan Kardec, #845 Paulinho Serra 40+) e recebeu 6 pedidos de post do Squad Social no WhatsApp: as pecas antigas eram origem='admin' e voltaram no layout de venda propria do peca.php (o reativar preservava origem de proposito). Ordem do ADMIN: reativar do painel do bot NUNCA vira venda propria, e sempre pega a foto nova. Os 6 pedidos foram so para o numero do gestor; nada publicado.

Mudanca (admin/modulos/eventos/action.php, conciliar_reativar):

• peca admin/bot reabre como origem='bot' + id_produtor do bot + parceria_online=0 -> evento.php e fora do Squad Social (que so pega id_produtor IS NULL OR parceria_online=1); evento de produtor continua do produtor; sem o produtor do bot, recusa;
• baixa a foto da sugestao pela mesma baixarFotoExternaEvento do cadastro novo, via baixarFotoExternaEventoComCopia (copia o cartaz atual antes, aborta se a copia falhar, devolve se a gravacao falhar, preserva a copia se a devolucao falhar); mensagem avisa quando a foto nao vem.

Dados (com OK do ADMIN): #94, #166 e #845 passaram a origem='bot'/produtor 50929 e receberam a foto do Sympla (estavam sem cartaz: o cleanup das 04:17 apaga imagem de peca inativa). Backup das linhas e script em /root/backups-versionados/rnt-reativar-evento-20261016-1805/. Status mantido pausado (ADMIN).

Validado: lint php83 e 5.6; testes reais na #94: link invalido (cartaz intacto, http_403), link certo (troca), falha de gravacao simulada com chattr +i (cartaz devolvido com md5 igual, sem temporarios); imagens servidas com 200. gpt-6-astra: 2 NO-GO corrigidos, GO na 3a rodada. Nao validado: o clique do reativar na tela (proximo uso prova). Mesmo problema no "vincular" virou BK-559.

[2026-10-15] [BK-557] Atribuição de pedido quase nunca fechava — 2 bugs reais corrigidos

Origem: investigando por que a tabela final de atribuição por pedido (rnt_pedido_atribuicao) tinha só 27-28 linhas no total e zero com fbclid/gclid, apesar da captura de visita/clique funcionar bem (achado do BK-556). Investigado pelo Codex (gpt-6-astra); os 2 fixes revisados e validados com execução real por mim antes de comitar, porque a rodada do Codex foi interrompida (timeout) antes do próprio relato final.

Causa raiz 1: rnt_atrib_capturar_interno() (includes/atribuicao_helper.php) checava $_SESSION['cliente']['id']/$_SESSION['CLIENTE_X']['id'] pra saber se tinha cliente logado — nenhuma das duas é a chave real. O login de cliente de verdade (painel/data/Login.php, área do CLIENTE) grava em $_SESSION['CMS_X_Cliente']['id']. Resultado: cliente_id ficava sempre null, mesmo com o cliente logado no momento do clique. Confirmado com a campanha do Meta Ads do BK-556: 459 contatos capturados, 0 com cliente_id.

Causa raiz 2: action.php, ao reaproveitar um pedido "rascunho" (criado por pedido.php, até 60min antes), sobrescrevia metadados com um $meta montado do zero — descartando a chave rnt_atrib que o rascunho original já carregava (gravada mais perto do clique, mais confiável), quebrando o elo que a reconciliação horária precisa.

Mudança:

• includes/atribuicao_helper.php: nova condição checando $_SESSION['CMS_X_Cliente']['tipo'] === 'cliente' antes de usar o id (produtor compartilha a mesma estrutura de sessão, só com tipo='produtor' — não pode virar cliente_id). Fallbacks antigos mantidos depois, por segurança.
• action.php: lê metadados do rascunho (rnt_order_meta_array()) e copia só o campo rnt_atrib pro $meta novo antes de serializar — sem reutilizar nenhum outro campo antigo do carrinho (evita reabrir o híbrido que o BK-464 de 20/09 já tinha corrigido).

Validado com execução real (dados de teste criados e removidos depois, nenhum cliente real afetado): sessão CMS_X_Cliente/tipo=cliente/id=775 (conta real de teste) grava cliente_id=775 corretamente; sessão tipo=produtor continua sem gerar cliente_id (como esperado); rnt_order_meta_array() extrai rnt_atrib certo quando existe e não quebra quando não existe (rascunho antigo). php83 -l limpo nos 2 arquivos. Monitor de integridade do Mercado Pago pausado antes da edição (action.php é arquivo monitorado) e re-selado depois da revisão.

O que NÃO foi resolvido, de propósito: casamento de visitante anônimo que nunca loga antes de comprar (exigiria reconciliação por cookie puro, fora do escopo autorizado); nenhum backfill do dado histórico (a campanha do BK-556 continua sem atribuição retroativa). Falta acompanhar nos próximos dias se o cron de reconciliação horária (vinculos=0 hoje, sempre) passa a encontrar vínculos — registrado como item de acompanhamento no BK-557.

[2026-10-15] [BK-549b] Mesmo bug do BK-549 (vid_ordem) em outros 4 cadastros de vídeo

Origem: achado durante o BK-549 (cadastro de vídeo em peça falhava sempre por faltar vid_ordem no INSERT), documentado como fora do escopo daquela tarefa. Decisão do ADMIN: corrigir agora, enquanto o assunto estava fresco, em vez de só registrar backlog.

Causa raiz: o mesmo padrão de bug do BK-549 (tb_videos.vid_ordem é NOT NULL sem DEFAULT; com sql_mode=STRICT_TRANS_TABLES o INSERT falha sempre, ERROR 1364) existia, intocado, em outros 4 arquivos com o mesmo bloco case "cadastr_video":

• admin/modulos/eventos/action.php
• painel/modulos/eventos/action.php
• produtor/modulos/pecas/action.php
• produtor/modulos/eventos/action.php

Mudança: mesma correção do BK-549 repetida nos 4 — adicionado $camp[] = "vid_ordem"; $val[] = 0; ao array do INSERT, em cada um.

Validado: php83 -l limpo nos 4 arquivos. Testado diretamente no banco o INSERT exato que o código corrigido gera (INSERT INTO tb_videos (vid_titulo,vid_url,vid_modulo,vid_vinculo,vid_ordem) VALUES (...,0)), confirmado sucesso (linha inserida e removida depois). Revisado por Codex (gpt-6-astra), que confirmou a correção correta nos 4 lugares e sem colisão com vid_capa.

Validação pendente (registrada, não contornada): NÃO foi feito teste de ponta a ponta via UI/sessão real (login → botão → AJAX → resposta) pra nenhum dos 4, diferente do BK-549 original (testado com a sessão real do ADMIN numa peça real). Os 3 módulos de evento exigem sessão de produtor ou vínculo id_produtor/produtor_email que não foi possível simular sem alterar dados reais de propriedade — mais invasivo que a própria correção. Como a mudança só ADICIONA uma coluna antes ausente (sem ela o insert já falhava sempre, em qualquer caminho), o risco de regressão é baixo, mas o fluxo completo fica como pendência pro primeiro cadastro de vídeo real em cada um desses 3 módulos.

[2026-10-15] [BK-553] Vídeo da galeria de peça.php dava "Erro 153 - erro de configuração do player"

Origem: ADMIN - ao clicar num vídeo da galeria (depois do BK-552 já ter corrigido o clique chegar no player), o YouTube mostrava "Erro 153". Reportou também que o vídeo em formato Shorts testado "continua sem subir".

Causa raiz (erro 153): o site manda referrer-policy: same-origin pra todo o domínio. O #rnt-lightbox-iframe (player do lightbox) não tinha nenhum referrerpolicy próprio, então ao carregar o embed do YouTube (cross-origin) o navegador não mandava Referer nenhum — e o YouTube exige Referer pra liberar a reprodução embutida (documentado pelo próprio Google: https://developers.google.com/youtube/terms/required-minimum-functionality). Outro iframe na mesma página (mapa do Google Maps) já contornava o mesmo problema com referrerpolicy="no-referrer-when-downgrade".

Mudança: adicionado referrerpolicy="strict-origin-when-cross-origin" no #rnt-lightbox-iframe — o mesmo valor que o widget oficial de oEmbed do YouTube usa (conferido em https://www.youtube.com/oembed?url=...).

Sobre o Shorts "que não sobe": não é bug de código. Conferido via oEmbed público do YouTube (https://www.youtube.com/oembed?url=https://www.youtube.com/shorts/8hvFZj8WTfs) que esse vídeo específico retorna 403 Forbidden, e carregando o embed direto no navegador o próprio YouTube mostra "This video is private" — o vídeo de teste que o ADMIN usou está marcado como privado no YouTube, precisa ser tornado público/não listado pra testar de novo.

Validado: Playwright real contra produção, abrindo o player de dentro do lightbox (não só setando src) — antes do fix, o vídeo público sZGtDCaapD0 mostrava "Error 153"; depois, carrega normal (nome do canal, thumbnail, "Watch on"). Revisado por Codex (gpt-6-astra): fix correto e documentado oficialmente pelo Google.

[2026-10-15] [BK-551] Galeria de peça.php: miniaturas do lado da imagem (desktop) e setas de navegação no celular

Origem: ADMIN, em https://rionoteatro.com.br/uma-velha-cancao-quase-esquecida - "qdo tem mais de uma foto as miniaturas estao ficando ao lado da imagem grande, qdo deveriam ficar embaixo dela no desktop. No mobile nem tem que aparecer miniatura, só ter o botao de seta para os lados para rodar entre fotos e videos, qdo tiver mais de 1."

Causa raiz (miniaturas do lado): .rnt-gallery é display:flex sem flex-direction, então o flex-row padrão colocava a faixa de miniaturas (#rnt-galeria-thumbs) como item irmão ao LADO da imagem principal, em vez de abaixo.

Mudança:

• .rnt-gallery: adicionado flex-direction: column (miniaturas empilham abaixo da imagem no desktop); removido overflow:hidden/max-height:690px do container (o teto de altura fica só em .rnt-main-image, que já tinha o seu próprio).
• Celular (@media max-width:767px): .rnt-thumbnails { display:none } — some a faixa de miniaturas, como pedido.
• Navegação inline: 2 botões (<button>, não <span> — ver nota de acessibilidade abaixo) sobre a imagem principal, só visíveis no celular e só quando há mais de 1 item ($tem_galeria), navegando circularmente entre todos os itens (fotos e vídeos) da mesma galeria que já existia pro lightbox em tela cheia. Indicador de "▶" sobre a imagem quando o item atual é vídeo. Clicar na imagem abre o lightbox já no item que estava sendo mostrado ali (antes sempre abria no item 0).
• Removido de js/peca-redesign.js um handler duplicado em .rnt-thumb.video a que abria um modal de vídeo próprio sem CSS nenhuma (invisível) — o lightbox de peca.php já trata o mesmo clique corretamente.

3 bugs reais encontrados e corrigidos durante a implementação (todos via teste real com Playwright/headless chromium contra produção, não só leitura de código):

1. A função que atualiza a imagem ao clicar nas setas usava por engano a variável da <img> ESCONDIDA do lightbox em tela cheia (#rnt-lightbox-img) em vez da <img> VISÍVEL do cartaz (#rnt-lightbox-trigger) — a seta "não fazia nada" porque atualizava o elemento errado.
2. Corrigido isso, as setas (ancoradas em top:50% de uma caixa sem teto de altura no celular — BK-495) ficavam atrás do badge de desconto (.rnt-discount-badge, sempre fixo no topo, z-index:10) quando a imagem trocava pra uma proporção mais baixa (ex: thumbnail de vídeo, 4:3) — a caixa encolhia o suficiente pra a seta subir pra dentro da zona do badge, que roubava o clique. Fix: min-height:220px em .rnt-main-image, só em páginas com galeria (classe rnt-capa-wrap-com-galeria vinda do PHP — não usamos :has() porque esse seletor só tem suporte a partir de Safari 15.4/Chrome 105, e o público do site inclui celular mais antigo).
3. Acessibilidade (achado do Codex): as setas eram <span role="button">, sem foco por Tab nem ativação por Enter/Espaço — trocado por <button type="button"> de verdade, com reset de estilo (border/padding/-webkit-appearance) pra manter a aparência circular escura. Também corrigido o fallback do alt da imagem, que ficava preso na legenda do item anterior quando a legenda do item novo vinha vazia.

Limitação conhecida, documentada e não resolvida agora: em viewport muito curto (320×568, ex. iPhone 5/SE de 1ª geração — raro em 2026), a seta pode ficar atrás do botão flutuante "COMPRAR" (position:fixed; bottom:0; z-index:1000) logo no carregamento da página. Recuperável com um scroll pequeno (confirmado com Playwright: 40px de scroll já libera o clique). Resolver por completo exigiria ou limitar a altura da galeria nesse tamanho específico (contrariando o BK-495, que tira o teto de altura no celular justamente pra não cortar arte alta) ou redesenhar a área de clique do botão flutuante — maior que o pedido original.

Validado: Playwright real contra produção (celular 390×844, 375×667, 360×640 e desktop 1280×1000) — ciclo completo capa→foto→vídeo1→vídeo2→capa (circular) com troca de imagem, badge de vídeo e seta funcionando; selo de promoção (.rnt-capa-selos) confirmado visível por padrão numa peça com selo real configurado (sem galeria de vários itens — toggle de esconder validado por leitura de código, mesma lógica já comprovada com o badge de vídeo); desktop com miniaturas empilhadas abaixo da imagem e clique em thumbnail de vídeo ainda abrindo o lightbox certo; nenhum modal duplicado órfão. Revisado em 2 rodadas por Codex (gpt-6-astra), que sugeriu as 3 correções de acessibilidade/robustez acima, aplicadas e revalidadas.

[2026-10-15] [BK-552] Thumbnail de vídeo na galeria de peça.php não abria o player; fundo escuro das miniaturas

Origem: ADMIN - em https://rionoteatro.com.br/uma-velha-cancao-quase-esquecida, clicar numa thumbnail de vídeo não abria o player (fotos abriam certo). Pediu também para remover o fundo escuro var(--bg-input) atrás da faixa de miniaturas.

Causa raiz (vídeo): em css/redesign_2026.css, .rnt-thumb.video::after desenha o badge de play (círculo com ▶) com position:absolute cobrindo o centro da miniatura, sem pointer-events:none. elementFromPoint no centro da thumb de vídeo acertava a própria <div class="rnt-thumb video"> (dono do pseudo-elemento), não o <a class="rnt-galeria-abrir"> por dentro dela — e clique não se propaga para baixo na árvore DOM, então o addEventListener do lightbox (inline em peca.php, ~linha 3196) nunca disparava. Confirmado ao vivo com Playwright (headless real) antes e depois do fix.

Mudança:

• css/redesign_2026.css: pointer-events: none; em .rnt-thumb.video::after (badge deixa de bloquear o clique) e .rnt-thumbnails { background: var(--bg-input) → transparent; }.
• includes/inc_peca.php: redesign_2026.css?ver=2.2 → ?ver=2.3 (cache-busting, pra visitante não continuar servindo o CSS antigo).

Validado: Playwright real contra produção — antes do fix, clique na thumb de vídeo não abria o lightbox (display:none); depois, elementFromPoint acerta o <img> e o lightbox abre com o iframe do YouTube certo (display:flex, iframe com src do embed). Fundo da faixa de miniaturas confirmado rgba(0,0,0,0). Revisado por Codex (gpt-6-astra): fix correto e suficiente; evento.php não tem essa galeria de vídeo, não precisa do mesmo fix; achado fora do escopo (não corrigido): css/redesign.css (legado, não carregado em nenhum PHP encontrado) tem a mesma duplicação de fundo/badge sem pointer-events:none — manutenção preventiva, sem uso ativo hoje.

[2026-10-15] [BK-549] Cadastro de vídeo (YouTube) em peças falhava sempre, não só nessa URL

Origem: ADMIN - não conseguiu adicionar https://www.youtube.com/watch?v=sZGtDCaapD0 na aba Vídeos de uma peça, viu erro.

Causa raiz: tb_videos.vid_ordem é NOT NULL sem DEFAULT, e o INSERT em admin/modulos/pecas/action.php (case cadastr_video) nunca incluía essa coluna. Com sql_mode=STRICT_TRANS_TABLES ativo, isso falhava com ERROR 1364 pra QUALQUER vídeo, não só essa URL — o bug não tinha nada a ver com o parsing do link do YouTube (que já funcionava certo). Não aparecia no log porque Sql::insert() nunca loga mysql_error() em caso de falha, só devolve "Falha ao tentar alterar!" genérico.

Mudança: adicionado vid_ordem = 0 ao insert (mesmo valor que os 62 registros existentes já têm, implícito antes do modo estrito pegar isso).

Validação: php83 -l ok. Fluxo AJAX ponta a ponta reproduzido e corrigido com a URL real do ADMIN (peça 1652): erro confirmado antes do fix, sucesso confirmado depois, linha real gravada em tb_videos, thumbnail do YouTube extraída certo. Revisão do gpt-6-astra (plano + diff): aprovado.

Achado fora do escopo (registrar backlog): o mesmo padrão de INSERT incompleto existe em admin/modulos/eventos/action.php, painel/modulos/eventos/action.php, produtor/modulos/pecas/action.php e produtor/modulos/eventos/action.php — continuam quebrados do mesmo jeito. Conserto na raiz sugerido pelo Codex: ALTER TABLE tb_videos ALTER COLUMN vid_ordem SET DEFAULT 0 (não destrutivo, resolve os 5 pontos de uma vez em vez de patch disperso) — decisão de fazer isso fica pro ADMIN.

[2026-10-15] [BK-550] Botão "Gerar vídeo para Storie" ganha dica quando falta só o selo

Origem: ADMIN - "https://rionoteatro.com.br/admin/modulos/pecas/index.php?status=ativas&origem=admin#artepromo nao ta podendo clicar no botao Gerar video para Storie". Investigado: não é bug. O botão (admin/inc-gestor.php, componente "gestor" compartilhado por várias telas admin) fica desabilitado até 4 condições — imagem carregada, moldura montada no servidor, pelo menos 1 selo ativo, nada pendente. O ADMIN confirmou que não sabia que precisava adicionar um selo primeiro; o único sinal disso era o title (tooltip, só aparece passando o mouse).

Mudança: admin/js/gestor-arte-promo.js (atualizarBotoes()) — nova dica de texto visível (#artePromoVideoDica, HTML em admin/inc-gestor.php) que aparece só quando a condição que falta é exatamente a ausência de selo (as outras 3 já ok), pra não ficar redundante quando falta outra coisa.

Validação: node --check e php83 -l ok. HTTP real confirma o elemento presente na tela. Revisão do gpt-6-astra: confirmou que a condição faltaSoSelo reproduz exatamente os outros fatores de videoOk (sem erro de digitação na cópia), aprovado.

[2026-10-15] [BK-545 ajuste 2] "Vendas por origem registrada": separa Share Site do tráfego real da mesma fonte

Origem: ADMIN - pediu o mesmo ajuste de rótulo ("Whatsapp" → "Share Site") no bloco "Vendas por origem registrada" (gráfico + tabela), e perguntou se dá pra saber de onde a pessoa que compartilhou veio, pra mostrar os dois juntos (ex: "ShareSite/GoogleAds").

Resposta sobre a origem de quem compartilhou: não temos. O link do botão "Compartilhar Oferta" (includes/rnt_share.php) é genérico — todo mundo que clica gera o mesmo link, sem id de sessão/cliente embutido. Sabemos que a venda veio por indicação (alguém usou o botão) e por qual canal foi compartilhado (ex. WhatsApp), mas não quem compartilhou nem de onde essa pessoa veio.

Mudança: dashboard-roi.php — a classificação por origem ($por_fonte, usada no gráfico de pizza e na tabela "Vendas por origem registrada") agora dá uma chave própria sharesite:<canal> quando utm_medium for share/indicacao, antes de cair no balde genérico por fonte. Isso evita misturar venda por indicação com tráfego real de campanha que use a mesma fonte (ex. uma futura campanha de WhatsApp de verdade não ficaria somada com as indicações via WhatsApp). Rótulo mostrado: "Share Site/{canal}" (ex. "Share Site/Whatsapp") — mostra o canal de compartilhamento real, sem sugerir que sabemos a origem de quem compartilhou.

Validação: php83 -l ok. HTTP real no período 01/10-15/10: "Share Site/Whatsapp" aparece separado de "Origem desconhecida", R$180,00/2 pedidos preservado (mesmo total já confirmado no ajuste anterior). Revisão do gpt-6-astra: reconciliação confirmada (cada pedido entra em exatamente 1 grupo), rótulo considerado honesto, aprovado.

[2026-10-15] [BK-545 ajuste] Ranking "Campanhas UTM": rótulo "Share Site" em vez de "Whatsapp/share"

Origem: ADMIN - viu "Whatsapp/share" no ranking "Campanhas UTM com maior venda atribuída" (BK-545) e achou estranho (confundiu com campanha de WhatsApp disparada). Investigado junto: são 2 pedidos reais (73978 de 10/10, 73984 de 11/10, R$90 cada) atribuídos à UTM compartilhar-peca — não tem nada a ver com cliques no botão "Compartilhar" de dentro de uma campanha de WhatsApp (mecanismo totalmente separado); é o botão "Compartilhar Oferta" do site (includes/rnt_share.php), venda por indicação entre clientes.

Mudança: dashboard-roi.php — quando utm_medium for share ou indicacao (mesmo recurso, nome antigo e atual, ver includes/rnt_wa_campanha_publico.php:235), mostra "Share Site" em vez de "{fonte}/{medio}".

Validação: php83 -l ok. HTTP real: "Share Site" aparece corretamente no período 01/10-15/10. Revisão do gpt-6-astra aprovada.

[2026-10-15] [BK-546] Home do admin: qualidade do WhatsApp API oficial numa linha

Origem: ADMIN - "em admin/index.php abaixo do WhatsApp Online... incluir a medicao do nosso qualidade na api oficial do whatsapp, se está verde, amarela ou vermelha, qtas mensagens por dia podemos enviar... em somente 1 linha... bem simples".

Mudança:

• divulgai.com.br/campanha.php: o cron "qualidade" (roda a cada 2 min, ja existia) passa a escrever tambem uma copia simples em /tmp/divulgai_qualidade_rnt.json (qualidade/status/pode_enviar/limite_conta/timestamp, sem segredo nenhum) — /tmp ja esta no open_basedir do rionoteatro.com.br, diferente de /www/server/divulgai/, que NAO esta (decisao: nao abrir open_basedir pra isso, e mudanca de seguranca compartilhada). Escrita atomica via tempnam()+rename() (evita seguir symlink se algo plantar um link no caminho previsivel em /tmp).
• rionoteatro.com.br/admin/index.php: nova linha "WhatsApp API oficial: qualidade {verde/amarela/vermelha}" com cor e "Envio: {LIMITED/...} · limite da conta: {TIER_2K/...}", lendo so esse cache. Não mostra o bloco se o dado tiver mais de 600s (10min) de idade — nao apresenta cache velho como atual. Validacao de tipo antes de indexar o mapa de cores (JSON corrompido nao quebra a pagina).

Validação: php83 -l ok nos 2 arquivos (projetos/repositorios diferentes: rionoteatro2025 e divulgai). HTTP autenticado real: linha aparece certa ("qualidade amarela", "Envio: LIMITED", "limite da conta: TIER_2K" — dado real da conta hoje). Revisão do gpt-6-astra: 1ª rodada achou riscos reais (escrita nao-atomica/symlink, falta de checagem de atualidade, falta de validacao de tipo, texto fixo de limite em vez de dado real) — corrigidos pelo próprio Codex (sandbox danger-full-access, projeto já trusted, sem a flag --sandbox workspace-write que causava a falha de permissao bwrap em rodadas anteriores desta sessão), revisados por mim e aprovados na 2ª rodada.

[2026-10-15] [BK-545] Dashboard de ROI: remove bloco legado incompatível, ticket por ingresso

Origem: ADMIN - dashboard-roi.php mostrava "Receita Bruta: 0 vendas realizadas" na mesma tela que o bloco de cima (BK-461) mostrava 69 ingressos/R$2.247,00 pro mesmo período (15/09 a 15/10). Pediu correção completa ("tudo de uma vez"), incluindo "Ticket por pedido" (que confundia pedido com múltiplos ingressos).

Causa raiz: o bloco "Receita Bruta"/"ROI Médio"/"Lucro Líquido"/rankings/gráficos vinha de v_campanhas_performance/campanhas_roi — sem filtro de período nenhum (soma a view inteira) e com join legado (campanha→tracking→cliente→pedido) que nunca bate com nenhuma venda real hoje (68 campanhas na view, soma de vendas = 0 em todas, sempre, independente do período). Já estava documentado como pendência desde BK-534 ("ROI e CPA da view legada"), mas continuava visível mostrando números incompatíveis com o bloco real ao lado.

Mudança (admin/modulos/campanhas/dashboard-roi.php):

• Removidos: 4 KPIs legados, gráfico "Evolução do ROI" (campanhas_roi), gráficos/rankings "por fonte"/"melhores-piores campanhas" (v_campanhas_performance), tabela de fontes duplicada no fim da página.
• Substituídos por consultas reais em pedidos (mesma base do extrato BK-461: status_transacao IN (3,4), pedidos.created no período), agregadas em PHP a partir de UMA única query: "Vendas diárias" (gráfico real), "Vendas por origem registrada" (via rnt_pedido_atribuicao, mostrando "Origem desconhecida" quando não há registro — não inventa número), "Campanhas UTM com maior venda atribuída" (top 5, sem ranking de piores — ROI por campanha continua pendente, ver BK-534).
• Pedido com mais de uma linha de atribuição conflitante entra em "atribuição ambígua" em vez de escolher uma arbitrariamente (sem UNIQUE(pedido_id) no banco, só proteção de aplicação).
• Adicionado "Ticket por ingresso" (vendas_brutas/ingressos) ao lado do já existente "Ticket por pedido" (vendas_brutas/pedidos) — eram conceitos diferentes sendo confundidos em um só número.

Validação: php83 -l ok. HTTP autenticado real no período exato reportado (15/09 a 15/10/2026): reconciliação confirmada — total da nova query bate exatamente com o extrato (31 pedidos, R$2.247,00 nos dois). Por origem: desconhecida 29 pedidos/R$2.067, whatsapp 2 pedidos/R$180 (soma = R$2.247, confere). Ticket por ingresso R$32,57 vs ticket por pedido R$72,48, ambos conferidos por cálculo manual. Testado período sem nenhuma venda: 200 OK, sem erro, sem divisão por zero. Revisão do gpt-6-astra em paralelo com a investigação (pergunta aberta antes de eu decidir o plano) e 4 rodadas de revisão do diff real — achou e eu corrigi: chave de agrupamento por campanha usando só o nome (sem distinguir fonte/meio, corrigido pra chave via serialize()) e chave reservada 'ambigua'/'desconhecida' colidindo com possível utm_source real literal (corrigido com prefixo src: nas fontes reais).

[2026-10-15] [BK-537 ajuste] "Dashboard de ROI" removido do submenu Campanhas

Origem: ADMIN - "Dashboard de ROI pode retirar do submenu de campanhas. deixa só em Analise." (a mesma tela tinha 2 entradas de menu desde o BK-537, uma em cada grupo, de propósito na época).

Mudança: só banco (tb_menus), sem código. Apagada a linha men_id=75 (men_pai=53, grupo Campanhas). Achado no caminho: setar men_status='I' não funciona pra remover item de SUBMENU — admin/inc-menu.php só filtra men_status='A' nos itens de nível raiz (men_pai=0); a query de filhos (linha ~119) não filtra status, então "inativo" continua aparecendo. Registrado aqui como nota pra próxima vez: desativação de submenu precisa apagar a linha, não só marcar inativo.

Validação: HTTP autenticado real — "Dashboard de ROI" aparece 1 vez só agora (grupo Análises, men_id=80).

[2026-10-15] [BK-544] Lembrete de pedido pendente volta ao texto humano (pré-BK-533)

Origem: ADMIN - "a mensagem que enviamos após uma pessoa nao concluir a compra, deve voltar a ser essa que estavamos recebendo retorno das pessoas, deve estar mais humano", colando o texto exato desejado (nome completo, saudação por horário, peça em caixa alta, desconto em percentual, assinatura "Jorge | Equipe RIONOTEATRO").

Mudança: admin/cron/lembrete_pedido_pendente.php, montar_mensagem_lembrete() — volta do texto "oferta"/negrito/riscado do BK-533 (09/10/2026, que parou de gerar retorno de cliente) pro formato humano anterior: {Saudação por horário}, {Nome completo}! Tudo bem? / Vimos que você não concluiu a compra para o espetáculo "{PEÇA EM CAIXA ALTA}" com incríveis {X}% de desconto no {link da peça}. / Alguma dúvida ou dificuldade? Estou aqui a disposição! 😊 / Jorge | Equipe RIONOTEATRO. Saudação (Bom dia/Boa tarde/Boa noite) usa o mesmo padrão de fuso America/Sao_Paulo já usado em convite_parceria_produtor.php (VPS está com date.timezone=PRC). O texto colado pelo ADMIN não tinha link; perguntado, ele decidiu que o próprio link da peça substitui o texto "RIONOTEATRO.com.br".

Validação: php83 -l ok. --preview com pedido real reproduziu o padrão exato do texto colado pelo ADMIN (mesmo cliente/peça do exemplo — Tereza Cristina Elias Pereira / Lisa, Lesa & Louca —, só o percentual difere por ser pedido com preço diferente: 63% vs 66%, fórmula confirmada correta). --test-send entregue ao gestor (21999915554), aprovado ("ok, manda ver"). Revisão do gpt-6-astra no diff real: aprovado.

[2026-10-15] [BK-543] Dashboard de Facebook Ads: orçamento real (ad set, não campanha)

Origem: ADMIN - "So a coluna orçamento que consta R$0 para todos. Tinha q ser R$5 o u o valor total q eu temos aind a p gastar em cada campanha?".

Causa raiz: nesta conta (sem Advantage Campaign Budget), o orçamento mora no ad set, não na campanha — daily_budget/lifetime_budget da campanha sempre vêm NULL. Confirmado via API: as 4 campanhas MOTOR têm R$5,30/dia cada, só que no ad set. O botão "editar orçamento" já existente também sempre apontou pra campanha (updateCampaignBudget) — nunca teria funcionado pra essas campanhas reais (embora nem aparecesse, já que exigia daily_budget setado na campanha).

Mudança:

• facebook_ads.php: getAccountAdSets() (1 chamada pra conta inteira) e updateAdSetBudget().
• fb_dashboard.php: rnt_fb_dashboard_orcamento() decide a origem explícita (campanha-diário/campanha-total/conjunto-diário-único/conjunto-total-único/múltiplos conjuntos/nenhum) sem somar diário com vitalício; só oferece edição quando o alvo é inequívoco. Não mostra "resta hoje" (budget_remaining) — semântica de reinício diário não confirmada com certeza suficiente. Form de editar orçamento manda target_type+target_id explícitos (não assume mais campanha por padrão) e some na aba "finalizadas" (mesma lógica do botão "Ativar").
• 3 camadas de defesa no handler de escrita (mais rígido que a tela de leitura, por ser mutação real): target_type restrito a campaign/adset via in_array estrito; servidor reconsulta a API e recalcula o orçamento real antes de qualquer POST pra Meta, recusando se o alvo enviado não bater (campo oculto pode ser adulterado); se a consulta de ad sets vier com paging.next (não viu todos os conjuntos da conta), recusa a edição por segurança em vez de arriscar o alvo errado. pause/activate/update_budget agora exigem $result['success'] === true estrito, não só isset().

Validação: php83 -l limpo. HTTP autenticado real: as 4 MOTOR mostram "R$ 5,30 (diário · conjunto)" (antes R$0,00); POST com CSRF válido mas budget_target_id adulterado foi recusado com "O alvo enviado não corresponde mais ao orçamento real desta campanha" sem mutar nada na Meta (caminho de sucesso real não testado, pra não alterar orçamento de campanha ativa). Revisão do gpt-6-astra em paralelo com a investigação (não só depois do plano fechado) — 4 rodadas de revisão do diff real, cada uma achando um problema genuíno (mistura diário+vitalício ambíguo tratado como único; handler assumindo campanha por padrão quando alvo ausente; target_type aceitando qualquer valor não-"adset"; escrita sem bloqueio de paginação incompleta), todos corrigidos antes da aprovação final.

[2026-10-15] [BK-542] Dashboard de Facebook Ads: métricas reais e 3 abas por status

Origem: ADMIN - "Conseguimos incluir mais informacoes? mais colunas de informacoes como valor do click, do ROI, e etc como tem no Gerenciador de anuncios do Facebook/Meta? e divide a pagina com aba de anuncios ativos e anuncios pausados e finalizados".

Mudança:

• facebook_ads.php: novo método getAccountInsights() — 1 chamada só pra conta inteira (level=campaign), em vez de 1 chamada por campanha (evita N+1/rate limit). Campos: gasto, impressões, alcance, frequência, cliques/CPC/CTR gerais e de link. getCampaigns() passou a pedir também effective_status/start_time/stop_time.
• fb_dashboard.php: 3 abas (Ativas/Pausadas/Finalizadas) classificadas por rnt_fb_dashboard_classificar() — ARCHIVED/DELETED ou stop_time no passado vira "finalizada" mesmo que o status ainda diga PAUSED (agenda encerrada ≠ pausada-pode-reativar); por isso campanha finalizada não oferece mais botão "Ativar", só o texto "agenda encerrada". Seletor de período (hoje/ontem/7d/30d, padrão 30d) via ?periodo=. Tabela com gasto, impressões, alcance, cliques de link, CPC de link, CTR de link, por campanha. Erro real na consulta de métricas aparece como alerta visível, não como "—" silencioso (evita confundir falha de consulta com ausência real de entrega).
• Sem ROI/ROAS fabricado de propósito: a conversão de compra desta conta está contaminada por ação que não é compra (achado desta mesma sessão) — nota fixa "ROAS/retorno indisponível" em vez de inventar uma métrica que enganaria.

Validação: php83 -l limpo nos 2 arquivos. HTTP autenticado real: 5 campanhas em Ativas, 0 em Pausadas, 3 em Finalizadas (as 3 com stop_time de 2024/2025/abr-2026, todas no passado — confirma a lógica). Dados reais por campanha (ex.: MOTOR p1085 Cinderela Negra: R$25,78 gasto/30d, 3.602 impressões, 188 cliques de link, R$0,14 CPC, 5,22% CTR). ?periodo=today muda os números corretamente (R$2,76 hoje vs R$25,78/30d); período inválido na URL cai pro default sem erro. Revisão do gpt-6-astra em paralelo com a investigação (não só depois de decidido o plano) e revisão final do diff — aprovado, com 2 ressalvas corrigidas na hora (alerta de erro visível, botão "Ativar" suprimido em finalizada) e 1 aceita como limite documentado da 1ª versão (paginação com limit=500, hoje bem abaixo do real de 8 campanhas).

[2026-10-15] [BK-541] Dashboard de Facebook Ads: token real, CSRF e entrada no menu

Origem: ADMIN notou admin/modulos/campanhas/api/fb_dashboard.php (corrigido de layout no BK-539) mostrando "Token inválido ou expirado" e "Nenhuma campanha encontrada", e perguntou por que a tela não estava no menu. "vamos resolver as coisas e nao só deixar em backlog!!"

Causa raiz: admin/modulos/campanhas/api/facebook_ads.php (classe FacebookAdsAPI) lia app_id/app_secret/access_token/ad_account_id do .env. FACEBOOK_ADS_ACCESS_TOKEN e FACEBOOK_ADS_AD_ACCOUNT_ID nunca existiram lá (mesmo achado do BK-540), e o FACEBOOK_APP_ID do .env é de um app DIFERENTE do que emitiu o token real — por isso a validação (debug_token) falhava mesmo quando o token funcionava para ler campanhas.

Mudança:

• facebook_ads.php: app_id/app_secret/access_token passam a vir, juntos, da mesma linha de config_facebook (tabela), com fallback por FONTE inteira pro .env (nunca mistura token de um app com credencial de outro). ad_account_id ganhou default real act_269864494837203 (conta pré-paga das campanhas MOTOR atuais), com override por .env se configurado. Self-contido: garante conexão mysqli mesmo quando o caller (test_api.php, sales_webhook.php) não passa por bootstrap_v2.php antes.
• fb_dashboard.php: os 2 forms POST (pausar/ativar e atualizar orçamento) mudavam campanha real sem nenhum token de sessão — mesma classe de falha do BK-539. Adicionado rnt_request_csrf_token/rnt_request_csrf_validate (padrão já usado em action.php/alertas.php).
• tb_menus: nova entrada "Facebook Ads - Campanhas" (men_id=82) sob o grupo Campanhas (men_pai=53) → campanhas/api/fb_dashboard.php. threads_callback.php não entrou no menu de propósito: é só callback OAuth do Threads, nunca deve ser acessado por clique direto.

Validação: php83 -l limpo nos 2 arquivos. HTTP autenticado real: "Token válido" (antes "inválido" mesmo funcionando), 8 campanhas carregando com dados reais (conta 269864494837203, R$ 308,67 gasto), POST com csrf errado rejeitado com "Sessão expirada ou token inválido" sem executar a ação. Revisão do gpt-6-astra (2 rodadas: achou mistura de credencial de fontes diferentes no fallback por campo, corrigido para fallback por fonte inteira; aprovado na 2ª rodada).

Limite conhecido (pré-existente, não ligado a este fix): includes/db.php ainda usa die() se a conexão cair (sem fallback suave); o mecanismo antigo refreshToken()/token_cache.json só persiste em arquivo e nunca ganha prioridade sobre o token do banco na próxima carga de página — já era 100% inalcançável antes deste fix (dependia de um access_token do .env que nunca existiu).

[2026-10-09] [BK-534 nginx] Chegadas por campanha contadas no registro de acessos do servidor

Origem: ADMIN - "precisamos tambem ter acesso aos acessos tanto do nginx quanto do analytics" / "pode seguir com o quadro de acessos como preferir".

Mudanca:

• /root/rnt-tools/acessos_nginx_campanhas.php (cron /etc/cron.d/rnt-acessos-nginx, minutos 20 e 50): le o access log do nginx do dia e do anterior, considera so GET de pagina com resposta 200 e utm_campaign no endereco, separa gente de robo pelo navegador declarado e grava em rnt_campanha_acessos_nginx (tabela nova, InnoDB) por dia, campanha e variacao: chegadas de pessoas, pessoas distintas (IP + navegador, aproximacao) e chegadas de robos. Nenhum IP e gravado;
• admin/modulos/campanhas/detalhes.php: quadro "Chegadas ao site por esta campanha (registro do servidor, 14 dias)", para qualquer campanha que tenha dado, com a contagem do registro proprio do site ao lado.

Validacao: php83 -l ok; contador rodado (698 linhas com campanha, 32 gravadas); quadro renderizado fora do painel para as campanhas 95 (motor), 93 (WhatsApp) e 1 (sem dado, nao aparece). Na 95, 13 pessoas + 49 robos = 62, igual as 62 visitas do registro do site - que inclui os robos. Tela logada NAO aberta; sem revisao do gpt-6-astra.

Limite conhecido: a analise de anuncio da Meta acessa com navegador de celular (Instagram/Facebook) e conta como pessoa: 57 das 62 chegadas "de gente" com a marca do motor em 09/10 foram ANTES de os anuncios serem ligados (14h e 15h). O Analytics (GA4) continua sem acesso por API (BK-462).

[2026-10-09] [BK-534 item 1] Detalhes da campanha: pedidos pagos e venda calculados certo

Origem: ADMIN - "sim" para atacar o BK-534 comecando pelo funil e pela receita.

Mudanca (admin/modulos/campanhas/detalhes.php, quadro "Pedidos atribuidos"):

• pago passa a ser status 3 (Paga) e 4 (Disponivel). Antes o status 1 (aguardando) contava como pago e os pagos entravam como "nao concluidos";
• a venda e preco x quantidade e so dos pedidos pagos (antes somava o preco unitario de todos os status). O rotulo virou "Venda dos pedidos pagos";
• o pedido e achado pelo registro de origem (rnt_pedido_atribuicao.ultimo_utm_campaign). O texto em metadados ficou so como apoio para pedido antigo sem registro, com a marca inteira entre aspas;
• a tabela por status mostra o nome do status em vez do codigo;
• a etapa "Compra atribuida" do funil nao deixa mais pedido virar sessao (podia dar conversao acima de 100%).

Validacao: php83 -l ok; consulta nova executada no banco para quatro campanhas (sem erro; hoje nenhuma tem pedido com registro de origem de campanha). Revisao do gpt-6-astra: dois P2, corrigidos. A tela logada NAO foi aberta.

Continua no BK-534: ROI e CPA da view legada, investimento sem periodo comum, quadro do WhatsApp, permissao e CSRF do modulo.

[2026-10-09] [BK-460 exclusao] Excluir campanha do motor pausa na Meta antes

Origem: analise do gpt-6-astra pedida pelo ADMIN (P1).

Mudanca: admin/modulos/campanhas/action.php, case deletar: campanha com fonte_importacao = 'motor' e pausada na Meta antes de o cadastro ser apagado; se a Meta nao confirmar, nada e apagado e o painel avisa. Antes o anuncio seguia gastando e sumia do painel. detalhes.php: o bloco do motor ignora valor de tipo inesperado vindo de dados_externos (evita erro fatal no PHP 8.3) e os titulos das colunas dizem o periodo de cada numero.

Validacao: php83 -l ok nos dois; bloco renderizado fora do painel com dados propositalmente errados (lista no lugar de texto) e com a campanha 97 real, sem aviso nem erro. A exclusao logada NAO foi exercitada. Achados nao corrigidos do painel: BK-534.

[2026-10-09] [BK-460 acompanhamento] Tela de detalhes da campanha mostra os anuncios do motor

Origem: ADMIN - "rionoteatro.com.br/admin/modulos/campanhas tem algo para acompanharmos os anuncios?".

Mudanca: admin/modulos/campanhas/detalhes.php ganha o bloco "Anuncios na Meta (motor de anuncios)", so para campanha com fonte_importacao = 'motor': verba diaria do conjunto, gasto de hoje/7 dias/total, e uma linha por anuncio (foto, video, foto com musica) com situacao na Meta, gasto, exibicoes, cliques, visitas contadas pelo pixel, visitas registradas pelo site, pedidos pagos e botao "Abrir na Meta"; embaixo, vendas vindas do anuncio em 7 dias e o que as regras pedem agora. A tela so le dados_externos; quem grava e a rotina do servidor (/root/rnt-tools/motor_anuncios_rotina.php), que passou a importar os numeros por anuncio.

Validacao: php83 -l ok; bloco renderizado fora do painel com a campanha 97 (do motor) sem aviso nem erro, e vazio para a 93 (WhatsApp). A tela logada NAO foi aberta. Sem revisao do gpt-6-astra nesta mudanca.

[2026-10-09] [BK-533] Lembrete de pedido pendente: texto novo, falando em "oferta"

Origem: ADMIN - mandou o texto atual e o novo ("alterar para").

Mudanca: admin/cron/lembrete_pedido_pendente.php, montar_mensagem_lembrete() (fase 1). De "Oi Fulano! Notamos que voce nao concluiu a compra para ... Ficou com alguma duvida ou teve algum problema no pagamento? ..." para "Oi, Fulano! Tudo bem? Notamos que voce nao conseguiu obter a oferta Peca (dd/mm as hh:mm) de ~R$X~ por somente R$Y !! / Ficou com alguma duvida ou dificuldade? Estou a disposicao para lhe ajudar. / Para facilitar segue link da oferta 👉 link". A oferta inteira fica em negrito; o valor cheio continua riscado (decisao anterior do dono); os dois erros de digitacao do texto enviado foram corrigidos. A fase 2 (cliente que ja pagou) nao mudou.

Validacao: php83 -l ok; --dry-run ok; --test-send entregue ao gestor (amostra do pedido 73972).

Incidente da rodada: a primeira edicao (16:15) foi SOBRESCRITA pelo deploy do push das 16:14 - o arquivo voltou ao texto antigo as 16:16, sem aviso. Reaplicada e commitada em seguida. Regra ja registrada (nao editar arquivo versionado na janela de ~2 min apos um push) e descumprida aqui.

[2026-10-09] [BK-460 atalho] Atalho que abre o anuncio do motor no Gerenciador da Meta

Origem: ADMIN - o link direto do Gerenciador abria o aplicativo do Facebook no celular, sem ir para a edicao.

Mudanca: admin/modulos/campanhas/ir_gerenciador.php (novo). Recebe o id da campanha do painel, tira conta e anuncio do dados_externos e redireciona para o Gerenciador (destino fixo; nao e redirecionador aberto). Entra por link ASSINADO (HMAC com config/motor_link_secret.php, fora do Git) sem pedir login, ou, sem assinatura valida, pelo login do admin. .gitignore ganhou o arquivo do segredo.

Validacao: php83 -l ok; por curl: link assinado de foto e de video devolve 302 para o anuncio certo; campanha que nao e do motor, 404; assinatura errada vai para o login.

NAO resolvido: no celular do ADMIN o link nao abriu a edicao do anuncio (09/10, ele pediu para ver depois). E o login do admin, vindo de um link com retorno, caiu no inicio do painel em vez de voltar ao endereco pedido - nao reproduzido sem a senha; no servidor o retorno e repassado.

[2026-10-09] [BK-460 painel] Pausar campanha do motor de anuncios pelo painel pausa de verdade na Meta

Origem: ADMIN - "tenho que poder ver os dados das campanhas e parar elas direto do nosso painel de campanha".

Mudanca:

• admin/modulos/campanhas/includes/motor_anuncios_helper.php (novo): rnt_motor_pausar_na_meta() envia status=PAUSED para a campanha da Meta guardada em dados_externos e confere relendo pela conta. Nenhuma funcao escreve ACTIVE;
• admin/modulos/campanhas/action.php, case alterar_status: em campanha com fonte_importacao = 'motor', Pausar/Finalizar so grava depois de a Meta confirmar; se recusar, o painel nao muda e avisa. Ligar pelo painel e recusado. O pedido de pausa so e aceito com origem no proprio site;
• case editar: a tela de edicao nao troca status, gasto nem marca de campanha do motor (antes dava para gravar "pausada" com o anuncio gastando).

Campanhas que nao sao do motor seguem como antes.

Validacao: php83 -l ok nos dois arquivos; pausa chamada por CLI na campanha 94 (ja pausada): confirmada pela Meta; campanha 93 (WhatsApp) recusada como "nao e do motor"; endpoint sem login devolve 302. Revisao do gpt-6-astra com 3 achados, corrigidos; a versao final nao foi revista de novo. O clique logado no botao NAO foi testado.

[2026-10-09] [BK-532] Copia de banco de 2024 retirada do site e do repositorio; nginx bloqueia dump e compactado

Origem: achado de 09/10/2026 ao procurar backups antigos do cadastro (BK-531); ADMIN mandou bloquear e remover, mantendo uma copia fora do Git.

O que havia: um dump completo do banco de 03/11/2024 (17 MB, cadastro de ~50 mil clientes) versionado desde 15/10/2025 em painel/ e painel_old/. A copia de painel/ respondia 200 pela internet: a regra do vhost so negava nome TERMINADO em .sql, e o arquivo terminava em .gz.

Mudanca:

• vhost nginx: duas regras novas - .sql em qualquer ponto do nome e todo compactado (gz|tgz|bz2|xz|zip|7z|rar|tar|dump) respondem 404. Conferido no access log de 5 dias que nenhum compactado e servido de proposito;
• os dois arquivos sairam do Git e do webroot; .gitignore ganhou .sql.gz, .sql.zip e .sql_*;
• uma unica copia guardada fora do webroot e do Git, em pasta so do root (700/600); uma terceira copia identica numa pasta antiga de configuracao do nginx foi apagada.

Validacao: nginx -t ok e reload; o endereco passou de 200 para 404 (publico e direto na origem); home, pagina de peca, pecas.xml e CSS seguem em 200.

Acessos: no access log de 02/04/2026 a 09/10/2026 so ha os dois pedidos de cabecalho do proprio teste. Antes de abril nao ha log.

Fica em aberto (decisao do ADMIN): o arquivo continua no HISTORICO do repositorio no GitHub; as senhas daquele dump sao hash antigo (ver pendencia do SHA-1 sem salt); a copia guardada ainda nao esta cifrada com senha.

[2026-10-09] [BK-530 parte 2] Carrinho reaproveitado ganha registro de origem, sem duplicar

Origem: ADMIN - "pode fazer a parte 2 do BK-530".

Mudanca:

• includes/atribuicao_helper.php: nova rnt_atrib_garantir_pedido() - para pedido que JA existe. Com linha, nada muda (a origem fica congelada no nascimento); sem linha, amarra primeiro o retrato orfao cuja chave ja viaja no metadados e, nao havendo, grava o retrato de agora com regra_versao = 'v1-tardio'. Trava GET_LOCK por pedido; sem a trava nao grava;
• rnt_atrib_vincular_interno() e os dois UPDATE da funcao nova ganham NOT EXISTS: nenhum caminho amarra um segundo retrato a pedido que ja tem linha (a tabela so tem indice unico em chave). Nenhuma consulta depois do UPDATE - a reconciliacao le mysqli_affected_rows();
• config/functions_new.php (gerenciar_pedido_carrinho(), ramo de reuso do rascunho): preserva metadados['rnt_atrib'] e chama a funcao nova.

action.php NAO foi alterado (sem re-seal do monitor do Mercado Pago).

Validacao: php83 -l ok (e php -l 5.6 no functions_new.php); 7 casos exercitados no banco dentro de transacao desfeita (pedido com linha, sem linha, repeticao, orfao recuperado, segundo retrato recusado, vinculo normal, chave invalida) e trava ocupada por outra conexao (nao grava, 2s); pagina de pedido renderizada como visitante; tres passadas do gpt-6-astra, um P2 em cada, os tres corrigidos. O reuso real com cliente logado nao foi exercitado antes do commit.

Continua no BK-530 (aberto): action.php ~1015 ainda regrava o metadados sem a chave no reuso do efetuacompra (a linha fica amarrada por pedido_id, entao so afeta a reconciliacao); INSERTs sem origem em action.php:1971 e :2331, painel/modulos/pedidos/action.php:99 e fluxos PagSeguro - recriacao medida em 2 de 101 pedidos desde 01/07/2026.

[2026-10-09] [BK-530 parte 1] Pedido de cliente ja cadastrado passa a nascer com registro de origem

Origem: ADMIN - "pode investigar o BK-530" / "pode aplicar a parte 1" (achado do BK-529: a linha "pedidos atribuidos ao link do botao" do relatorio de campanha dava 0 sempre).

Causa: o pedido de quem ja tem cadastro nasce em pedido.php, por gerenciar_pedido_carrinho(), que so grava a origem sob function_exists('rnt_atrib_carimbar') - e as paginas de pedido nao carregavam includes/atribuicao_helper.php. De 22/09 a 09/10/2026, 7 de 25 pedidos ganharam registro, todos criados junto com o cadastro (action.php).

Mudanca: pedido.php e pedido_pagseguro.php carregam o atribuicao_helper.php (so define funcoes; nenhuma captura de visita ali).

Validacao: php83 -l ok nos dois; pagina de pedido da peca 1024 renderizada como visitante (POST + redirecionamento), sem erro fatal e sem criar pedido; consulta previa e revisao final do gpt-6-astra sem P1/P2. O caminho logado NAO foi exercitado (criaria pedido real): a prova e o proximo pedido de cliente cadastrado gerar linha em rnt_pedido_atribuicao.

Continua no BK-530 (aberto): rascunho reaproveitado nas ultimas 24h, exclusividade por pedido_id, preservacao da chave no metadados e os demais caminhos de INSERT sem origem. Pedidos antigos sem registro nao sao recuperaveis.

[2026-10-09] [BK-529] Relatorio de vendas da campanha da API oficial perdia a compra de quem recebeu a mensagem (fuso)

Origem: ADMIN - "Ja tivemos vendas sim. Tem que ver como estamos pegando essa informacao ... precisa cruzar se os compradores sao pessoas que receberam a mensagem da parte 1 ou 2 e conferir pq nao computamos".

Causa: rnt_wa_campanha_vendas() (includes/rnt_wa_campanha_publico.php) transformava a hora do primeiro envio com date(). A API bot/whatsapp/prefs_api.php nao carrega o functions_new.php, entao valia o php.ini da VPS (PRC) e o corte saia 11 horas adiantado: para a leva 2 (12h00) o relatorio procurava pedidos criados depois das 23h. pedidos.created e gravado na hora do Rio.

Mudanca: o corte passa a ser montado com DateTime + America/Sao_Paulo explicito.

Validacao: php83 -l ok; funcao reproduzida nos dois fusos com a fatia C da leva 2 (PRC: 0 pedidos; Sao Paulo: 1 pago, 2 ingressos, R$ 90,00); campanha.php vendas rodado nas quatro campanhas depois da correcao - leva 2C passa a mostrar o pedido 73970 (cliente recebeu as 12h07 e comprou as 12h17), leva 1 e fatias A/B seguem em 0, conferido contra a tabela pedidos. Revisao gpt-6-astra sem P1/P2.

Fica em aberto: a linha "pedidos atribuidos ao link do botao" continua em 0 por outro motivo - ver BK-530.

[2026-10-09] [BK-528] Botao PRODUTOR no filtro de origem da lista de pecas do admin

Origem: ADMIN - "temos os botoes admin bot aguardando mas nao temos produtores para listar as pecas de produtores. Juliana Palmer incluiu um evento e nao consigo ver".

Mudanca: admin/modulos/pecas/index.php ganha o valor origem=produtor e o botao PRODUTOR no grupo Origem, ao lado de ADMIN e BOT. Lista toda peca com produtor real vinculado (id_produtor preenchido, fora origem bot e o cadastro bot@rionoteatro.com.br). Antes, peca de origem produtor sem parceria_online nao cabia em ADMIN nem em BOT e so aparecia em "Todas as Pecas" sem origem marcada. As de produtor com parceria_online=1 aparecem em PRODUTOR e seguem tambem em ADMIN - a regra do ADMIN nao foi alterada.

Validacao: php83 -l ok; consulta do filtro conferida no banco (25 pecas, nenhuma ativa em 09/10); revisao gpt-6-astra sem P1/P2; ADMIN testou a tela no ar e aprovou.

[2026-10-09] [BK-527] "Sair" digitado tratado tambem pelo numero oficial, sem confirmacao em dobro

Origem: ADMIN - "Sempre que escrever sair sozinho, sem outras palavras ja nao envia mais mensagens para essa pessoa (do rionoteatro, com outros clientes analisamos dps)".

Mudanca:

• Divulg AI (repo proprio, webhook.php + lib_prefs.php): mensagem de texto que e SO a palavra "sair" (maiuscula, acento e pontuacao nao importam; "quero sair" nao vale) passa pelo mesmo caminho do botao "Parar de Receber": acao assinada optout do site (cadastro sair = 1 + lista de bloqueio) e confirmacao ao cliente, na hora, sem depender do bot do whatsapp-web.js;
• includes/whatsapp_inbound_analyzer.php: o monitor do bot (5 em 5 min) nao manda a segunda confirmacao quando o telefone ja esta na lista de bloqueio (rnt_wa_campaign_is_blacklisted). Antes so olhava clientes.sair, entao quem nao tem cadastro receberia duas.

O bot continua tratando sozinho "parar", "cancelar", "remover", "descadastrar" e "nao quero receber", como antes.

Validacao: php83 -l ok; regra do "sair" exercitada com 12 textos. O caminho inteiro com um cliente real digitando "sair" NAO foi exercitado (gravaria um pedido de saida de verdade); o trecho de gravacao e o mesmo do botao, que funcionou em 08/10.

[2026-10-09] [BK-526] Regulamento das pecas ativas e regras pre-definidas: "RG" vira "documento com foto cadastrado"

Origem: ADMIN - "pode olhar so das pecas ativas e aonde setamos as regras pre-configuradas" (continuacao do BK-525).

Mudanca (so dado, 8 linhas): pecas.regulamento das 4 pecas ativas que citavam RG (1024, 1085, 1342, 1634) e tb_regras_predefinidas.conteudo das 4 regras (adulto/infantil, com/sem assento). Quatro frases por texto: "Basta apresentar o seu RG cadastrado", "apresentando somente seu RG (documento de identificacao com foto) cadastrado", "APRESENTANDO SOMENTE SEU RG CADASTRADO" e "O RG do comprador" (virou "O documento cadastrado do comprador"). As 1.024 pecas inativas com RG no regulamento ficaram como estavam: peca reativada precisa do regulamento novo (reaplicar a regra pre-definida).

Como: /root/rnt-tools/bk526_regulamento_documento.php (ensaio por padrao; --aplicar grava). pecas e MyISAM, sem rollback: o texto original das 8 linhas esta em /root/rnt-tools/backups/bk526_regulamento_antes_20261009-013325.json; so foi alterada a linha em que as quatro trocas fecharam sem sobrar "RG".

Validacao: ensaio antes (8 de 8 com 4 trocas e 0 sobrando); depois, 0 pecas ativas e 0 regras com "RG"; pagina /discutindo-relacao em 200 com o texto novo.

[2026-10-09] [BK-525] Texto de retirada: "RG cadastrado" vira "documento com foto cadastrado"

Origem: ADMIN - "apresentando somente o RG cadastrado alterar para apresentando somente o documento com foto cadastrado (pq atualmente o novo CPF tem foto e a pessoa pode apresentar somente o CPF se esse for o documento cadastrado)" e, sobre os demais lugares do site, "sim, pode trocar la tambem".

Mudanca (so texto, 11 ocorrencias em 10 arquivos): action.php (e-mail da compra), action_pagseguro.php, apps/Helpers/PaymentView.class.php (tela de pagamento), confirm_pagamento.php, painel/modulos/pedidos/index.php (painel do cliente, 2), pedido.php, pedido_pagseguro.php, politica_de_devolucao.php, index.php e pecas.php (chamada da home). A saudacao automatica do WhatsApp (Divulg AI) recebeu a mesma troca.

Ficou como estava, de proposito: o termo de parceria e as telas do produtor (termo-parceria.php, painel/modulos/eventos/editar.php e incluir.php), que ja dizem "RG (ou documento original com foto cadastrado...)" e sao texto de contrato; a mensagem de erro "CPF, E-MAIL ou RG" (fala do campo do cadastro); e arquivos sem acesso (pedido_mysqli.php, peca_nova.php, index_2026.php, copias datadas). O regulamento gravado em cada peca no banco nao foi conferido.

Validacao: php83 -l ok nos 10; todas as linhas do diff sao a frase trocada; arquivos em UTF-8. Monitor do Mercado Pago pausado para o action.php e selado depois do commit.

[2026-10-09] [BK-523] Conversas do Divulg AI: etiquetas Cliente / Produtor e filtros como os do WhatsApp

Origem: ADMIN - "inclua as tags de cliente / produtor / e os filtros igual tem no app do whatsapp de nao lidas, grupos e etc" e "veja algumas coisas que fizemos tbm no whatsapp do painel do admin do rionoteatro".

Mudanca (site):

• includes/rnt_wa_conversas_tags.php (novo, so leitura): rnt_wa_conversas_classificar() recebe ate 200 telefones e devolve, para cada um, cliente (tem cadastro), nome, produtor (linha ATIVA em tb_produtores pelo id_cliente), e o rotulo proprio / "fixo" que a tela admin/modulos/bot/whatsapp.php ja usa (admin/runtime/whatsapp_labels.json). Uma consulta para o lote (8 digitos finais) + conferencia exata com rnt_wa_prefs_phone_variants(). Do cadastro so sai o nome;
• bot/whatsapp/prefs_api.php: acao assinada classificar.

Mudanca (Divulg AI, repo proprio): selos Cliente / Produtor / Fixo e nome do cadastro na lista e no topo da conversa; fileira de filtros Todas, Nao lidas, Aguardando resposta, Clientes, Produtores, Sem cadastro, Campanha, com contagem; conversa fixada sobe; "lido" guardado no servidor; cache das etiquetas por 6h (1h para quem nao tem cadastro).

Ficou de fora (no BK-522): etiquetas coloridas do aplicativo WhatsApp Business e filtro de Grupos (a API oficial nao entrega mensagem de grupo).

Validacao: php83 -l e node --check ok; 99 numeros classificados em 68 ms (97 clientes, 1 produtor); chamada assinada real 200 em 109 ms; a caixa do painel aberta pelo ADMIN ja buscou e guardou as etiquetas de 97 contatos sozinha. Tela NAO conferida pela IA (sem login). gpt-6-astra antes e depois (dois pedidos): sem P1; P2 de normalizacao de telefone corrigido, os demais no BK-522.

[2026-10-08] [BK-521] Campanha da API oficial nasce sozinha na tela Campanhas; visitas por botao x por indicacao

Origem: ADMIN - "ja cria a campanha corretamente pra acompanharmos pelo rionoteatro para irmos treinando a automacao sem depender de nos" e "para sabermos quais botoes clicaram, para criarmos os funis".

Mudanca:

• includes/rnt_wa_campanha_publico.php: rnt_wa_campanha_registrar() - cria/atualiza a campanha por utm_campaign (so marca no formato wa-p<peca>-l<leva>[letra]). Linha nova: planejada/ativa, fonte_importacao = divulgai. Linha auto-detectada ou ja marcada divulgai: regrava nome, descricao e publico e vira planejada. Linha cadastrada ou editada a mao: so investimento_total e dados_externos (o texto do admin fica). dados_externos guarda os numeros (enviadas, entregues, lidas, toques nos botoes) em JSON;
• mesma funcao de vendas (rnt_wa_campanha_vendas): visitas_pelo_botao deixa de somar as visitas com utm_medium = indicacao, que saem em visitas_por_indicacao (link encaminhado pelo "Compartilhar Oferta", que agora leva a marca da campanha);
• bot/whatsapp/prefs_api.php: acao assinada campanha_registrar.
• Lado do Divulg AI (repo proprio): o enviador registra ao aprovar e a cada rodada; investimento_total e ESTIMATIVA (entregues x R$ 0,3217) e e regravado a cada rodada - valor digitado a mao na campanha e sobrescrito.

Validacao: php83 -l ok; funcao exercitada com linha de teste (wa-p999999-l99: criada -> atualizada -> so_custo depois de editada a mao -> adotada quando detectada; marca fora do formato recusada) e a linha apagada; pela API assinada de verdade a campanha 87 respondeu so_custo e manteve o texto. A consulta de desenho ao gpt-6-astra caiu por tempo; a revisao final foi feita em cinco pedidos separados: sem P1, P2 no BK-522. Do P2 do site saiu um ajuste: campanha criada pelo enviador e editada na tela (admin/modulos/campanhas/action.php) perde a marca divulgai e o texto do admin nao e mais regravado.

[2026-10-08] [BK-520] Campanhas: mover auto-detectada para Planejadas e campanha 87 preenchida

Origem: ADMIN - "Quero ter a opcao de incluir essas campanhas Auto-detectadas em planejadas" e "incluir em editar.php?id=87 o custo da campanha e demais informacoes".

Mudanca:

• admin/modulos/campanhas/action.php: acao mover_planejada (so quando a origem e detectada; mesmo id, entao cliques, vendas e link curto ficam) e, no editar, promocao detectada -> planejada quando o formulario manda origem=planejada. So nesse sentido: voltar a detectada deixaria o "Criar campanha" adotar a linha (BK-498). O nome perde o sufixo final "(Auto-detectada)";
• admin/modulos/campanhas/editar.php: campo "Aba da listagem" nas auto-detectadas (padrao: manter);
• admin/modulos/campanhas/index.php: botao "Mover para Planejadas" em cada linha da aba Detectadas.
• Dado: campanha 87 (wa-p1024-l1, leva 1 da peca 1024 pela API oficial) com nome, publico, descricao e investimento R$ 26,06 (81 entregues x R$ 0,3217, estimativa), origem planejada, sem data_fim (o dashboard-roi.php esconde a campanha em periodo posterior a data de fim).

Validacao: php83 -l ok nos tres; POST sem login em action.php devolve 302 para o login; v_campanhas_performance da 87 conferida. Fluxo AJAX do botao NAO exercitado logado pela IA - teste do ADMIN. gpt-6-astra antes e depois: sem P1; P2 (padrao do campo promovia sem querer) corrigido.

[2026-10-08] [BK-519] Publico da campanha pela API oficial: levas, conferencia de SAIR na hora e marca de WhatsApp

Origem: ADMIN - "pode seguir pela campanha"; regras dadas ao longo da noite de 08/10 (ver BK-519 no backlog).

Parte do site; o enviador mora no Divulg AI (campanha.php, so linha de comando).

Mudanca:

• includes/rnt_wa_campanha_publico.php (novo, so leitura): quem ja comprou na area da peca, em PARTES pela compra

mais recente (24 meses, depois de 12 em 12) e em LEVAS de envio (partes vizinhas juntadas ate ~100 numeros);

celular no campo celular ou telefone; so DDD 21/22/24 (21 nas levas, 22/24 e numero antigo com o 9

acrescentado na ultima); fora quem pediu SAIR, lista de bloqueio, ja tem ingresso, preferencia de outra regiao;

• bot/whatsapp/prefs_api.php: acoes publico (resumo das levas; com leva, tambem nome e telefone daquela leva -

unica acao que devolve dado de cliente, pela mesma assinatura HMAC) e marcar_whatsapp;

• includes/rnt_wa_prefs.php: get passa a dizer sair (qualquer cadastro do numero) e bloqueado (lista de

bloqueio), que o enviador confere na hora de cada envio; rnt_wa_prefs_marcar_whatsapp() grava o retorno da API

nas colunas da checagem do BK-385 com origem cloud_api, sem rebaixar um "tem" confirmado por mensagem recebida.

• /root/rnt-tools/publico_campanha_api.php usa a mesma funcao (ensaio e envio nunca divergem).

Medido para a peca 1024 (zona): levas 96 / 168 / 231 / 142 / 206 / 109 / 47; 93 celulares achados so no campo

telefone; 183 compradores fora por DDD de fora do RJ.

Validacao: php83 -l ok; pela API assinada: resumo sem linhas, leva 1 com 96 linhas so DDD 21 e 13 digitos,

leva e peca inexistentes (422), get com sair/bloqueado. Revisao do gpt-6-astra antes do primeiro envio: os

P1 do lado do site (lista de bloqueio lida com falha = sem publico; SAIR de qualquer cadastro) corrigidos.

Nao validado (na entrega): nenhum disparo real ainda; marcar_whatsapp so com numero inexistente.

Complemento de 08/10/2026 21h - primeiro disparo real e relatorio de vendas: a leva 1 da peca 1024 saiu pelo

Divulg AI entre 21:04 e 21:09 (96 enviadas, 81 entregues, 4 nao entregues 131026, 5 retidas pela Meta 130472).

marcar_whatsapp gravou 81 cadastros como "tem WhatsApp" (origem cloud_api). Um cliente tocou em "Parar de

Receber" as 21:09:01 e foi tratado: rnt_wa_prefs_log com optout e 1 cliente, clientes.sair = 1 e o telefone

na lista de bloqueio das campanhas. Nova acao vendas na API + rnt_wa_campanha_vendas(): visitas pelo link,

pedidos atribuidos a marca da campanha (rnt_pedido_atribuicao), pedidos da peca feitos por quem recebeu, venda

paga (valor x qtd) e margem pela regua do margem_helper.php. O rastreio do site ja tinha criado sozinho a

campanha wa-p1024-l1 (id 87) e registrado 11 visitas minutos depois do envio.

[2026-10-08] [BK-518] Cidade (municipio) no cadastro dos teatros e no pecas.xml

Origem: ADMIN - terceiro passo combinado das preferencias pelo WhatsApp ("So no meu municipio" e pecas em

Friburgo, Teresopolis etc.): o teatro so tinha bairro.

Mudanca:

• banco: teatros.cidade VARCHAR(60) NULL (copia da tabela antes em

/root/rnt-tools/backups/teatros_antes_cidade_20261008-185023.sql.gz);

• preenchimento automatico pelo bairro, so onde a deducao e segura: 170 de 184 teatros (157 Rio de Janeiro,

6 Niteroi, 2 Nova Iguacu, 1 cada em Saquarema, Duque de Caxias, Itaguai, Macae e Nilopolis). Regra: municipio

escrito no bairro, cidade da Baixada, bairro com zona da capital no rnt_zonas_do_bairro() ou um dos 10 bairros

da capital que o mapa de zonas nao conhece;

• admin/modulos/teatros/editar.php + action.php: campo "Cidade (municipio)" com os 92 do RJ (Rio e Niteroi

primeiro); a gravacao so aceita nome da lista do IBGE e so mexe na cidade se o formulario mandar o campo;

• atualizar_feed.php: <rnt:cidade> no pecas.xml e no pecas_inteira.xml.

Validacao: php83 -l ok nos tres; feed regerado, XML valido, as 4 pecas com Rio de Janeiro e o resto do feed

identico. Nao validado: a tela de editar teatro no admin (exige login).

Ficaram sem cidade (14, bairro vazio ou invalido) - ADMIN preencher: #88 e #98 VillageMall, #99 Fashion Mall,

#177 Kinoplex Shopping Leblon, #179 Teatro Negro Chica Xavier, #180 COC Campo Grande, #181 Waldir Onofre,

#182 Sergio Britto, #183 IFRJ, #185 Midrash Barra, #186 Citta America, #187 Jardim Suspenso do Valongo,

#188 Dercy Goncalves (Grajau Country Club), #189 Igreja Batista Atitude Cosmos.

[2026-10-08] [BK-516] Preferencias de recebimento respondidas pelo WhatsApp gravadas no cadastro

Origem: ADMIN - depois de aprovar o formulario no numero de teste do Divulg AI: "sim, pode seguir nessa ordem"

(modelos reais com botoes -> gravar as respostas no cadastro -> cidade nos teatros).

Como funciona: o cliente toca em "Escolher o que receber" numa mensagem de divulgacao enviada pela API

oficial; o Divulg AI responde com um formulario dentro do WhatsApp (tipo de espetaculo, de onde receber, regioes

em caixas de selecao, municipio numa lista dos 92 do RJ) e entrega a resposta aqui. "Parar de receber" marca SAIR.

Mudanca:

• banco: clientes ganha pref_tipo (adulto|infantil|ambos), pref_alcance (zonas|municipio|estado),

pref_municipio (nome IBGE) e pref_atualizado_em; tabela nova rnt_wa_prefs_log (hash da mensagem ja

aplicada). ALTER ... ALGORITHM=INPLACE, LOCK=NONE; copia da tabela antes em

/root/rnt-tools/backups/clientes_antes_pref_20261008-184120.sql.gz;

• includes/rnt_wa_prefs.php (ler, gravar, sair) e bot/whatsapp/prefs_api.php (so POST, HMAC-SHA256 de

timestamp.corpo, janela de 5 min; segredo em config/divulgai_prefs_secret.php, fora do Git);

• includes/data/municipios_rj.json: os 92 municipios do RJ (IBGE), para validar o que chega.

Decisoes (consulta ao gpt-6-astra antes de implementar):

• cliente SO por telefone completo com DDD; o nono digito so e posto/tirado em celular antigo (8 digitos comecando

em 6-9). O casamento por sufixo de 8 digitos do analisador antigo ignora o DDD e poderia gravar na pessoa errada;

• o municipio da preferencia NAO vai para clientes.cidade (endereco de pagamento; o perfil do painel so conhece 24

municipios e gravaria NULL por cima);

• zonas_interesse segue sendo o CSV de sempre (zonas -> nomes; estado -> "Todo o RJ"; municipio -> vazio);
• gravar preferencia nunca mexe em sair; a mesma resposta nunca e aplicada duas vezes (marca + gravacao na mesma

transacao); o "sair" poe o telefone na lista de bloqueio das campanhas antes de marcar, e nao envia mensagem daqui.

Validacao: php83 -l ok; pela API: leitura do cadastro do ADMIN (1 cliente), numero inexistente, tipo invalido,

sem zonas e municipio falso (422), assinatura errada, timestamp velho (403) e GET (405); um evento assinado simulado

do numero real gravou "Ambos / Centro, Zona Sul, Zona Norte, Zona Sudoeste" no cadastro do ADMIN (as escolhas que

ele fez no teste), recusou codigo de formulario errado e nao duplicou na reentrega; "sair" de numero inexistente foi

para a lista de bloqueio (registro de teste removido depois). Revisao final do gpt-6-astra: 2 P1 corrigidos antes do

commit (nono digito casando celular com fixo; reentrega sem fim em recusa definitiva).

Nao validado: um cliente real tocando no botao (os modelos reais com botoes ainda estao em analise na Meta e

nenhuma campanha saiu) e o "sair" num cadastro de verdade. Ainda nao existe: filtro de campanha que use esses

campos, e os campos novos no perfil do painel (BK-517).

[2026-10-08] [BK-515] pecas.xml ganha <rnt:nome> (nome limpo da peca)

Origem: envio de teste dos modelos de WhatsApp pelo Divulg AI (pedido do ADMIN: "enviarmos pelo test p ver

como vai ficar"). O g:title do feed leva "NN%OFF bairro" colado, o que estraga a frase "X esta em cartaz".

Mudanca (atualizar_feed.php): cada item passa a trazer <rnt:nome> com o nome da peca sem oferta nem bairro.

Validacao: php83 -l ok; feed regerado (itens=4), XML valido, quatro nomes corretos e o resto do feed

identico ao anterior (diff sem a linha nova). Usado no envio de teste entregue no celular do ADMIN.

[2026-10-08] [BK-514] Tela de pedido: atualizar a pagina volta para a peca, sem "reenvio de formulario"

Origem: ADMIN - ao atualizar o pedido.php o navegador mostrava "Confirmar reenvio do formulario /

ERR_CACHE_MISS"; "o ideal seria voltar para a tela de selecao pois algumas pessoas com medo ira fechar a pagina".

E o texto do botao ainda falava em Pagbank/PagSeguro.

Causa: a tela e o resultado direto de um POST da pagina da peca; navegador nenhum reexibe POST sem perguntar.

Mudanca (pedido.php, bloco no topo): Post/Redirect/Get de uso unico. O POST com os seis campos que a

peca envia (page_return, clubernt, data, quantity, id, assentos) guarda a selecao em

$_SESSION['rnt_pedido_prg'][codigo] e responde 303 para /pedido.php?sel=<codigo>&peca=<id>. Esse GET exibe a

tela uma vez, com os mesmos dados; atualizar de novo, voltar do pagamento, codigo vencido (30 min) ou de outra

sessao levam para /peca.php?id=<id>. POST fora desse padrao e GET sem codigo (volta do login/cadastro, carrinho

de 5 min em $_SESSION[$ip]) seguem o caminho antigo.

Por que uso unico (consulta ao gpt-6-astra antes de implementar): reexibir a cada refresh rodaria de novo o

gerenciar_pedido_carrinho() do cliente logado, que sobrescreve valor/metadados do rascunho e poderia desfazer um

cupom ja aplicado. Com uso unico a tela roda uma vez so por selecao, como hoje.

Texto: "* Clique em Confirmar para ser direcionado ao Mercado Pago e efetuar o pagamento com seguranca do

Mercado Pago, em nome de Jorge Luiz (parceiro operacional)."

Validacao: php83 -l ok; oito caminhos ensaiados por curl como visitante (envio 303; primeira exibicao 200

com quantidade, total e economia iguais; atualizar 302 para a peca; GET sem codigo 200; codigo inventado 302;

POST com campo a mais 200 sem redirecionar; codigo em outra sessao 302; GET puro 200 sem fatal); revisao final do

gpt-6-astra sem P1/P2. Nao validado: cliente LOGADO, cupom, e o gesto de atualizar num navegador de verdade.

Mesmo assunto, nao alterado: a pagina ainda cita "Saldo PagSeguro" no bloco de formas de pagamento.

[2026-10-08] [BK-513] Tela de pedido: "Valor total economizado" no resumo e titulo do cupom maior

Origem: ADMIN - "acho interessante incluirmos o valor que a pessoa vai economizar diminuindo o valor

promocional do valor total da compra inteira"; e "titulo do cupom pode aumentar".

Mudanca (pedido.php):

• os dois resumos ganham a linha Valor total economizado, logo abaixo de "Valor total do pedido":

sec_valor_de da sessao x quantidade - total do pedido. So aparece se a sessao tem preco cheio e sobra economia;

• no resumo do cliente logado o total pode mudar com o cupom (js/voucher.js troca o texto de .total-checkout);

um script pequeno na propria pagina recalcula a economia quando isso acontece (o voucher.js nao foi tocado);

• titulo "Cupom de Desconto" (.rnt-coupon-section h4) de 12px para 20px (mesma causa do BK-512).

Validacao: php83 -l ok; script inline com node --check e a conta ensaiada em 4 casos (inclusive milhar e

cupom); tela aberta como visitante com 2 ingressos da sessao de 11/10/2026 19:30 da peca 1342: "Valor do ingresso

R$22,00 / Valor total do pedido R$44,00 / Valor total economizado R$76,00" (preco cheio da sessao: R$ 60,00).

Nao validado: o resumo do cliente LOGADO e a troca ao aplicar cupom, que exigem sessao de cliente.

[2026-10-08] [BK-512] Tela de pedido: aviso do Painel retirado e nome da peca legivel

Origem: ADMIN - "achei confuso esse texto. Pode confundir as pessoas. Pode retirar. e o campo que aparece o

nome da peca pode aumentar. Esta muito pequeno."

Mudanca (pedido.php): saiu o paragrafo "* Com o email e senha informados, acesse seu Painel para ver o

status do seu pedido. Ao final do pagamento voce podera acessar o Painel."; o nome da peca (.rnt-order-header h3

e .rnt-summary-header h3) passou a 26px (22px ate 767px de largura).

Causa do nome pequeno (medida): o css/redesign_2026.css pede font-size: 1.2rem, mas o css/bootstrap.css

fixa html { font-size: 10px } - saia com 12px. A regra nova fica so no <style> do pedido.php.

Validacao: php83 -l ok; GET /pedido.php 200, sem fatal novo no log. Nao validado: a tela com um pedido

de verdade em andamento (precisa escolher sessao e quantidade) - conferencia do ADMIN.

Mesma causa, nao alterado: o titulo "Cupom de Desconto" (.rnt-coupon-section h4) usa o mesmo 1.2rem.

[2026-10-08] [BK-511] pecas.xml passa a trazer o video da peca (<rnt:video>)

Origem: ADMIN, sobre os modelos de mensagem do Divulg AI - "qdo tiver video .mp4 cria o modelo da peca com

video .mp4 qdo tiver so foto cria o modelo com a foto da peca".

Mudanca (atualizar_feed.php): nova rnt_feed_video_da_peca() procura em arquivos/pecas/<id>/video/*.mp4,

prefere o story com a arte da promocao (-story-arte-, gerado pelo arte_promo_video.php), senao o mais recente,

e ignora arquivo acima de 16 MB (limite do WhatsApp). Havendo video, o item ganha <rnt:video> no pecas.xml e

no pecas_inteira.xml. Sem video, a tag nao e escrita.

Validacao: php83 -l ok; feed regerado (itens=4), XML valido, as 4 pecas com video e as 4 URLs em 200

video/mp4; o resto do feed ficou identico ao anterior (diff sem a linha nova). O catalogo da Meta ja convivia

com tags rnt: (sessoes, teatro, bairro).

[2026-10-08] [BK-510] Zoom com os dedos liberado na pagina da peca (mapa de assentos no celular)

Origem: ADMIN - "no mobile tem que poder dar zoom na tela do celular p aumentar os assentos".

Causa: o <meta viewport> do includes/inc_peca.php trava o zoom (maximum-scale=1, user-scalable=no) em

todas as paginas que usam esse cabecalho.

Mudanca: peca.php define $rnt_viewport_permite_zoom = true antes de carregar o cabecalho, e o

inc_peca.php (dentro de LoadHeader(), por isso a variavel entrou no global) passa a escrever

width=device-width, initial-scale=1, maximum-scale=5 so nesse caso. Home, cadastro e demais paginas seguem

com o viewport travado de antes.

Validacao: php83 -l ok nos dois; viewport conferido na resposta real: peca com maximum-scale=5, home e

cadastre-se.php inalterados. Nao validado: o gesto num celular de verdade - conferencia do ADMIN.

Efeito colateral possivel: no iPhone, com o zoom liberado, tocar num campo de texto com letra menor que 16px

aproxima a tela sozinho.

[2026-10-08] [BK-509] Painel do produtor mostrava o WhatsApp pessoal do gestor no botao de parceria

Origem: ADMIN - "a mensagem veio pro meu whatsapp pessoal, nao pode passar esse meu contato para os

produtores" e, sobre o aviso: "manda tanto por push qto whatsapp pro numero do rionoteatro".

Causa (lida no codigo e conferida com a conversa recebida as 14:50): em painel/modulos/eventos/editar.php

o botao "Salvar e Contactar via WhatsApp" abria a conversa em parceriaAdminNumber = '5521999915554', o numero

pessoal do gestor, desde o BK-228. O incluir.php ja usava o oficial. A produtora mandou o texto "FECHEI

PARCERIA GRATUITA + VENDA COMISSAO!!" direto no pessoal. Coincidiu com a queda do bot (QR da coexistencia do

Divulg AI, 14:40-15:00), mas nao foi causado por ela.

Mudanca:

• painel/modulos/eventos/editar.php: o botao abre o numero oficial 5521999605790.
• painel/modulos/eventos/ajax_notificar_parceria.php: o aviso de parceria (checkbox marcado e parceria

aceita) deixa de acrescentar a forca o numero pessoal e passa por enviar_whatsapp_admin(): push de admin

+ WhatsApp para BOT_WHATSAPP_NUMERO_ALERTA (hoje 5521999605790). Antes saia so por WhatsApp, sem push.

Validacao: php83 -l ok nos dois arquivos; git grep 999915554 -- painel/ nao acha mais nada entregue ao

navegador (as ocorrencias que sobram sao destino de alerta no servidor, em painel/modulos/creditos/).

Nao validado: clique real de produtor no navegador, e se o push sai de dentro de requisicao web (historico

de 11/09 diz que nao saia; causa em aberto) - conferir em admin/logs/push_dispatch.log na proxima parceria.

Complemento no mesmo dia (ADMIN: "pode alterar para o rionoteatro"): painel/modulos/creditos/action.php e

painel/modulos/creditos/callback_mp.php tambem deixam de acrescentar o numero pessoal ao alerta de compra de

credito e passam por enviar_whatsapp_admin() (push + WhatsApp no numero do RNT). php83 -l ok nos dois;

git grep 999915554 -- painel/ = 0. O callback_mp.php e vigiado pelo monitor do Mercado Pago: re-selado

depois do commit. Nao validado com compra real de credito.

[2026-10-07] [BK-508] Salvar campanha: Data de Inicio ja preenchida e aviso de qual campo falta

Origem: ADMIN - "quando clica em copiar link rastreavel ele para de funcionar o salvar campanha".

Causa (medida no log de acessos): nao era o botao de copiar. As tres tentativas de salvar (23:23, 23:23

e 23:56 de 06/10) chegaram ao servidor e foram recusadas com "Preencha todos os campos obrigatorios": a

tela aberta direto (sem vir do botao da peca) nascia com a Data de Inicio vazia, a biblioteca de

validacao (parsley) nao e carregada nessa pagina e o aviso nao dizia qual campo faltava.

Mudanca:

• incluir.php: Data de Inicio nasce com a data de hoje (hora do Rio); antes de enviar, a tela confere os

campos que o servidor exige (nome, URL de destino, UTM Source, UTM Campaign, Data de Inicio), marca o

campo, mostra "Falta preencher: ..." acima dos botoes e leva ate ele. Erro do servidor tambem aparece

nesse aviso.

• incluir.php: os dois botoes de copiar confirmam no proprio botao ("Copiado!"), sem alert().
• action.php: a recusa por campo vazio passa a dizer quais campos faltam.
• editar.php (segundo relato do ADMIN, mesma noite): ao salvar, o navegador mostrava a resposta crua

{"success":true,"message":"Campanha atualizada com sucesso!",...}. A tela chama js/parsley/parsley.min.js,

que nao existe no servidor (404); $('#form-campanha').parsley() estourava, o envio por AJAX nunca

era ligado e o formulario ia pelo envio comum. A alteracao era gravada, so a tela ficava no JSON. Agora o

parsley so e usado se existir; os campos ja tem required do navegador. Ensaiado em Chrome automatico

com a campanha 83 e o action.php interceptado: envia por AJAX, mostra a mensagem e volta para a lista.

• Validacao: Sintaxe PHP ok (2 arquivos); JS inline validado e Fluxo AJAX validado ate o envio, em

Chrome automatico com a tela real renderizada com login simulado e o action.php interceptado (nada

gravado): salvar sem tocar na data envia com a data de hoje; copiar e depois salvar envia; data apagada

ou nome/origem vazios nao enviam e mostram o aviso com os campos. A gravacao real fica com o ADMIN.

[2026-10-06] [BK-506] Campanhas: origem "Meta" com o canal preenchido pela propria Meta

Origem: ADMIN - anuncio de catalogo roda em varios canais da Meta, nao so Facebook ou Instagram; a

tela de campanha so tinha as duas origens separadas.

Mudanca:

• incluir.php e editar.php: nova opcao de UTM Source Meta (anuncio em varios canais) (meta).
• incluir.php: ao escolher Meta, o UTM Content (se vazio) recebe {{site_source_name}}_{{placement}} -

variaveis que a Meta troca pelo canal de cada clique (ig_Instagram_Stories, fb_Facebook_Feed...) - e

o UTM Medium vazio vira cpc. Texto digitado pelo admin nao e sobrescrito; trocar de origem limpa so o

que a tela preencheu. Aparece o aviso de usar o link completo.

• incluir.php, editar.php e action.php (campanhas_tracking_destination): o link gerado mantem as

chaves {{...}} literais (antes viravam %7B%7B, e a Meta nao trocaria). Chave solta continua

codificada.

• action.php + index.php: depois de salvar campanha de origem Meta, o aviso na lista mostra o **link

completo** para colar no anuncio (no link curto a Meta nao troca as variaveis).

• Ajustes da revisao final do gpt-6-astra (sem P1; 2 P2 e 1 P3, os tres aplicados): a tabela de

campanhas ganhou o botao Copiar link completo (anuncio Meta) nas campanhas de origem Meta (o aviso

temporario some ao recarregar); editar.php tambem preenche o UTM Content ao trocar a origem para Meta;

o aviso com o link completo aparece mesmo se o link curto falhar.

• Nao mudou: as origens facebook/instagram (usadas pelas rotinas automaticas), o link curto das

demais campanhas e o catalogo.

• Validacao: Sintaxe PHP ok (4 arquivos); funcao do servidor ensaiada (link com as variaveis intactas;

link comum igual ao de antes); JS inline validado em Chrome automatico com os campos e o script reais

da tela: escolher Meta preenche content/medium e mostra o aviso, trocar de origem limpa, texto digitado

e preservado, sem erro de JS. A tela nao foi aberta com login nem salva pelo admin: o salvar de ponta a

ponta fica para o primeiro uso do ADMIN.

[2026-10-06] [BK-505] Push programado: "enviado" so com pelo menos uma entrega

Origem: ADMIN - "resolve isso agora", sobre o achado do gpt-6-astra na revisao do changelog do dia.

Problema: admin/cron/push_agendados.php tratava como sucesso qualquer resposta com a linha

Enviadas: N, inclusive Enviadas: 0 | Falhas: 117, e tambem "nenhuma inscricao". O gestor recebia o

aviso com titulo "Push programado enviado" sem nada ter sido entregue.

Mudanca: nova pa_resultado() le os numeros da resposta do sender. So fica enviado com 1 entrega ou

mais; zero entregas, ninguem para receber ou resposta ilegivel viram erro e o aviso sai como "Push

programado FALHOU", com o resumo na frente ("NENHUMA entrega. Entregues: 0 | Falhas: 117 | Expiradas: 6").

No sucesso o aviso tambem passa a abrir pelos numeros.

• Validacao: Sintaxe PHP ok; funcao ensaiada com 6 respostas (110 entregues -> enviado; 0 com falhas,

0 sem falhas, sem inscricao, erro fatal e resposta vazia -> falhou); --dry-run do cron sem erro.

Revisao final do gpt-6-astra: P2 (texto de uma falha individual podia ser lido como o resumo)

corrigido - so vale a linha de resumo inteira - e reensaiado com os 2 casos dele. Nenhum

push enviado no teste. A prova real e o agendamento 7 (Cinderela Negra, 07/10 10h).

[2026-10-06] [BK-504] Eventos duplicados no pixel da Meta: etiqueta do Tag Manager pausada

Origem: ADMIN - "corrige o achado no bk504" (eventos extras vistos na extensao da Meta).

Causa (medida): o conteiner GTM-KTLMMVG tinha ativa a etiqueta

FB_CONVERSIONS_API-897210417852424-Web-Tag-Pixel_Template (tipo Meta Pixel, template cvt_5RM3Q, criada

~16 dias antes), apontada para o pixel 897210417852424. Ela disparava em TODO evento do Google no

dataLayer e traduzia o nome: view_item -> ViewContent, purchase -> Purchase, begin_checkout ->

InitiateCheckout, page_view -> PageView; o resto ia com o nome cru (scroll, gtag.config). O id de

evento dela nao e o do site, entao a Meta nao deduplicava: cada pagina de peca mandava 2 PageView e 3

ViewContent (2 sem id de peca), e a compra confirmada podia gerar um segundo Purchase.

Correcao: o ADMIN pausou a etiqueta no painel e publicou a versao 13 do conteiner (conferido no

gtm.js publicado: nenhuma etiqueta cvt_5RM3Q ativa). Nenhum codigo do site mudou: a IA chegou a

bloquear a etiqueta por gtm.blocklist em meta-analytics.php, sem commit, e retirou a linha depois da

pausa (arquivo de volta ao commitado, conferido byte a byte).

• Validacao em Chrome automatico, pagina real, com a v13 e sem bloqueio no codigo:
• Meta: PageView, ViewContent (com id) e AddToCart (no clique da sessao). Home: so PageView.

Antes: mais 1 PageView e 2 ViewContent vindos do GTM.

• GA4 e Clarity: iguais ao que eram. Sem erro de JS.
• Nao houve compra de teste: o fim do Purchase duplicado fica para conferir na proxima venda.
• Google Analytics (mesma noite): o ADMIN pausou tambem ...-Web-Tag-GA4_Config e ...-Web-Tag-GA4_Event

(versao 14 do conteiner; so o Clarity ficou ativo nele). Elas reenviavam a G-0JKS304GTN o que o site ja

manda pelo gtag direto. Medido: view_item por pagina de peca caiu de 3 para 1 e o evento gtm.dom

sumiu; page_view segue 1; a propriedade G-587082M9FW nao mudou. Relatorios do GA4 com view_item

vao mostrar essa queda a partir de 06/10/2026 - e a contagem correta, nao perda de visita.

• Deixam de ir para a Meta (iam so por essa etiqueta, seguem indo ao Google): clique_compra_externa,

clique_compra_externa_sessao, redirecionamento_compra_externa e os eventos sem uso (scroll etc.).

[2026-10-06] [BK-504] AddToCart da Meta so quando o cliente escolhe a sessao

Origem: ADMIN - "pode mudar o AddToCart p disparar so qdo escolher a sessao". Achado na analise do

alerta do catalogo (BK-501), confirmado pelo gpt-6-astra.

Problema: o AddToCart saia ao ABRIR a pagina da peca (meta-analytics.php), com o preco cheio, e so

para peca com pecas.valor_de > 0. Contava visita como intencao de compra e deixava de fora peca com

preco so na sessao (Lisa, Lesa & Louca).

Mudanca:

• meta-analytics.php: sai o disparo na abertura; entra window.rntFbAddToCart(valor, sessaoId), que

manda o evento uma vez por sessao em cada abertura da pagina, com o id da peca, content_type: 'product'

e id de evento cart_<evento>_<sessao>.

• peca.php: o clique no cartao da sessao chama a funcao com o preco daquela sessao (o promocional).
• Efeito esperado nos relatorios: o numero de AddToCart cai bastante (antes era quase igual ao de

visitas) e passa a valer para todas as pecas com sessao.

• Validacao: Sintaxe PHP ok (2 arquivos); JS inline validado em Chrome automatico na pagina real -

Cinderela Negra: nenhum AddToCart ao abrir, 1 ao clicar na sessao (valor 15, id 1085), 0 no segundo

clique; Lisa, Lesa & Louca: 1 por sessao clicada (valor 22, id 1342), sem erro de JS.

• Erro de processo nesta rodada: a primeira edicao foi feita ~1 min depois de um push de documentacao e o

deploy a regravou. Reaplicada depois do deploy; nada ficou quebrado no ar.

[2026-10-06] [BK-501] Purchase da Meta: mesmo valor e mesmo id no navegador e no servidor

Origem: ADMIN - "corrige a anotacao antiga e corrige o erro de valores diferentes no meta". Achado

na investigacao do alerta do RNT CLICKS (o alerta em si segue no backlog, aguardando o ADMIN).

Problema: no pagamento por PIX, o Purchase do navegador (js/checkout_pix.js, dois pontos) saia

com 15% do total (o comentario dizia "10%") e eventID = 'mp_<pedido>'; o do servidor (CAPI) saia

com o total e event_id = 'rnt_pedido_<pedido>'. Com ids diferentes a Meta nao deduplica: a mesma

venda podia contar duas vezes, com dois valores.

Mudanca:

• js/checkout_pix.js: funcao rntPixelCompra() devolve o total do pedido e o id rnt_pedido_<id>;

os dois Purchase e o InitiateCheckout passaram a usar. Pedido que nao e ingresso (ClubeRNT-...)

nao tem evento na CAPI e leva id proprio. checkout_pix.php: so a versao do script (cache).

• js/voucher.js: cupom aplicado na tela do PIX sem recarregar atualiza tambem o total que o Pixel le

(achado do gpt-6-astra na revisao final; antes sairia o valor sem o desconto).

• Anotacao antiga corrigida em rnt_valor_midia_pedido() (margem_helper.php), conversao_meta_helper.php

e confirm_pagamento.php: "venda cheia" e o total realmente pago (preco promocional x quantidade),

nao a inteira nem a margem. Saiu o que nao se sustentava (mandar margem "nao melhora nada", "corta

alcance", a conta de "82%"); ficou o que sustenta a decisao. Nenhum valor mudou nesses tres arquivos.

• Decisao (revista com o gpt-6-astra em 06/10): a Meta recebe a venda paga; a comissao de 20% continua

sendo a regua interna (CPA-alvo e painel). A Meta nao cobra percentual sobre o valor do evento.

• Catalogo de produtos nao foi tocado (admin/cron/feed_facebook_catalogo.php segue publicando

inteira e promocional).

• Validacao: Sintaxe JS ok (node --check), Sintaxe PHP ok (4 arquivos). rntPixelCompra() ensaiada

fora do navegador: pedido 73961 total 120 -> valor 120, id rnt_pedido_73961; ClubeRNT-55 -> id

proprio; total zero/ausente -> 0. O total do checkout (rnt_order_gateway_unit_value() * qtd) e o

mesmo numero que o servidor grava em rnt_conversoes.valor_total. Monitor de integridade do Mercado

Pago pausado so para os dois arquivos e selado de novo ao fim. Nao houve compra real de teste: a

conferencia no Gerenciador de Eventos fica para a proxima venda por PIX.

• Complemento (06/10 noite, pedido do ADMIN): o Purchase do servidor passou a levar `content_type:

'product' e content_ids` com o id da peca, como o do navegador ja levava

(includes/conversao_meta_helper.php). Sintaxe PHP ok; nenhum evento de teste foi enviado a Meta.

• Revisao final do gpt-6-astra: sem P1. P2 do cupom corrigido acima; P3 (comentario) corrigido. O

Purchase sem id que ele achou em pedido_mysqli.php nao esta no ar (o nginx devolve 404 para o arquivo).

[2026-10-06] [BK-500] Programar push da peca para data e hora

Origem: ADMIN - precisa programar um push de peca infantil para o dia seguinte as 10h, na propria

tela admin/modulos/pecas/push.php.

Mudanca:

• push.php: campo "Ou programar para (hora do Rio)" + botao "Programar notificacao" (act agendar),

que grava em rnt_push_agendados (SQL/rnt_push_agendados.sql) o titulo, texto, link, botao e zona

como estao na tela; painel "Pushes programados desta peca" com status, resultado e Cancelar (act

cancelar_agendamento). Aceita de 2 minutos a 60 dias a frente. O disparo imediato nao mudou.

• admin/cron/push_agendados.php + /etc/cron.d/rnt-push-agendados (a cada minuto, fora do Git): envia

pelo mesmo sender da tela, com --tipo cliente explicito e --origem peca_agendado (entra no historico

rnt_push_envios), e avisa o gestor por push (so admin) com o resultado.

• Travas: a linha e "pega" (agendado -> enviando) antes do envio, entao duas rodadas nao mandam o mesmo

push; horario vencido ha mais de 3h nao e enviado (vira erro e o gestor e avisado); peca que saiu do

ar vira cancelado. Tudo em hora do Rio - o php.ini esta em PRC, nada usa date() puro.

• Validacao (nenhum push chegou a cliente): Sintaxe PHP ok; --dry-run do cron com uma linha vencida

(117 inscricoes na Zona Oeste seriam notificadas, linha intacta); --teste-admin (3 aparelhos de

admin); rodada real com uma linha vencida ha 5h (erro) e uma de peca inativa (cancelado), segunda

rodada sem repetir nada, 0 envio a cliente com origem peca_agendado. Tela renderizada pela CLI com

login simulado: campo e botao presentes, agendar para 07/10 10:00 gravou certo e listou com Cancelar.

Linhas de ensaio removidas; fila vazia.

• Revisao do gpt-6-astra: sem P1; 3 P2 corrigidos e reensaiados - reenvio do formulario duplicava o

agendamento (agora redireciona depois de gravar e o mesmo pedido nao entra duas vezes); programar e

cancelar sem token de formulario (agora exigem); zona desconhecida virava "todas as regioes" (agora

e recusada).

• Regra de regiao (ADMIN, 06/10): quem escolheu regiao so recebe peca da regiao dele; quem nao

escolheu nada recebe de todas. O sender ja aplica isso quando recebe --zona; o furo era a tela, que

oferecia "Todas as regioes" e tratava zona vazia/desconhecida como todas - a peca ia para quem

escolheu OUTRA regiao. Agora a zona e obrigatoria no disparo imediato e no programado (sem a opcao

"Todas"; pre-selecionada pela localizacao do teatro). Medido: 152 inscricoes ativas de cliente, 56 com

regiao escolhida, 96 sem preferencia. Ensaiado com o sender desligado: sem zona, "Todo o RJ" e zona

desconhecida sao recusados; com zona segue.

• Zona automatica (ADMIN, 06/10): a zona nao e escolha de quem dispara, sai do bairro do teatro.

includes/rnt_zonas.php (rnt_zonas_do_bairro) cobre 162 dos 184 teatros; os outros (Niteroi,

Saquarema, Macae, bairro em branco) nao tem zona entre as que o cliente pode marcar, e so nesses a

tela ainda pede a zona. Na tela a zona virou texto fixo; o que vier no POST e ignorado.

Barra, Recreio e Jacarepagua valem como "Zona Sudoeste" e "Zona Oeste" ao mesmo tempo, num envio

so: o site nunca explicou a diferenca ao cliente e sempre ficava alguem de fora. Para isso o sender

(/www/rnt-push-sender/send.php, fora do Git; backup *_BK-500-multizona) passou a aceitar lista em

--zona. Simulado: Zona Oeste 118, Zona Sudoeste 119, as duas juntas 123 inscricoes; zona invalida

dentro da lista e recusada. Ensaio da tela: pecas 1085 e 1024 (Barra) -> Sudoeste + Oeste, 1634

(Centro) -> Centro, 1028 (Niteroi) -> pede a zona; POST forjado com outra zona grava a do teatro.

• Nao validado: a tela no admin real com login, e um envio programado real a clientes.

[2026-10-06] [BK-497] Selos e video tambem no modo Editar (borracha)

Origem: ADMIN - o botao "Editar (borracha)" das fotos tambem precisa dos botoes de gerar video.

Mudanca (gestor-arte-promo.js, inc-gestor.php, arte_promo_lib.php): no modo Editar, quando a

foto e a arte padrao (600x1067), aparecem os 3 botoes de selo, o tamanho, o Mover (para arrastar o

selo) e "Gerar video para Storie". Se a foto ja tem posicao de selos gravada (rnt_pecas_selos), os

mesmos selos ligam sozinhos no mesmo lugar - o video sai igual ao que alterna na pagina. Os precos dos

selos vem do cadastro da peca (arte_promo_dados passou a devolver tambem selos_cfg). Foto que nao e

a arte padrao (banner, foto de cena) continua so com a borracha.

• Validacao: Sintaxe JS ok, Sintaxe PHP ok; navegador headless com o HTML real do Gestor: arte padrao

(ligar 2 selos, arrastar, pedir video com a posicao nova, salvar copia), banner 1128x634 (sem selos nem

video), arte com posicao gravada (3 selos ligados sozinhos, tamanho 134, Salvar desabilitado ate algo

mudar) e saida da edicao. Zero erro de JS. Nao testado no admin real.

• Limite: a base do video e a foto como esta. Se ela ja tem um selo desenhado, os selos animados

precisam ficar em cima dele (e o que acontece quando a posicao gravada e reaproveitada).

[2026-10-06] [BK-498] Salvar campanha adota a "(Auto-detectada)" em vez de recusar

Origem: ADMIN - em admin/modulos/campanhas/incluir.php, ao salvar a campanha cwa a tela disse que

ela ja existia; perguntou se tinha sido criada sozinha.

Causa (medida no access log e no banco): foi. O rastreamento (tracking/save_tracking.php) cria uma

campanha "(Auto-detectada)" quando alguem abre um link com utm_campaign desconhecido. O link ja estava

no WhatsApp: 19:45:44 o robo da Meta buscou a previa; **19:47:06 um visitante abriu o link e 19:47:07

nasceu a campanha 77 "Cwa (Auto-detectada)"**; 19:47:14 e 19:47:29 o ADMIN clicou em Salvar e recebeu

"Ja existe uma campanha com este UTM Campaign". Nao houve duplo envio nem gravacao pela tela.

Mudanca (action.php act criar, e o aviso em incluir.php): quando o UTM ja existe e a campanha

existente tem origem = 'detectada', o formulario a adota: mesmo id (os acessos ja registrados

continuam nela), dados do formulario, origem passa a planejada, e o shortlink e criado como numa

campanha nova. Campanha cadastrada por gente continua recusada com a mesma mensagem.

• Validacao: Sintaxe PHP ok; adocao ensaiada com os helpers reais (db_insert/db_update/db_delete)

numa campanha de teste criada e apagada na hora: origem detectada -> planejada, nome e status do

formulario, mesmo id; repetir o update (0 linha alterada) segue contando como sucesso.

• Nao testado: o clique real em Salvar no admin. A campanha 77 nao foi alterada - o ADMIN salva de novo.
• Botao "Campanha" na coluna Acoes da lista de pecas (pecas/index.php): abre

campanhas/incluir.php?origem=pecas&peca_id=<id> ja com nome, link da peca, datas (ate a ultima

sessao), conteudo e termos. Source e Medium ficam em branco para o ADMIN escolher o canal; ao

escolher, o UTM Campaign e o nome ganham o canal no fim (<peca>_<bairro>_<data>_whatsapp_canal),

ate o campo ser editado a mao. Sem isso duas campanhas da mesma peca no mesmo dia colidiam no codigo.

Testado: pre-preenchimento da peca 1024 e, em navegador headless, a troca de canal (5 casos).

• Corrigido junto: a tela usava date('Y-m-d') puro e o php.ini esta em PRC - depois das 13h do Rio a

campanha nascia com data de inicio e codigo do dia seguinte. Agora campanha_hoje() usa

America/Sao_Paulo. O fluxo vindo dos Disparos de WhatsApp nao mudou de comportamento alem da data.

• Link curto a mao. O shortlink ja era criado ao salvar (rnt_shortlinks, ex.: campanha 80 ->

rionoteatro.com.br/5s8k), mas a tela redirecionava sem avisar e a lista so mostrava o link para

abrir - o ADMIN colou o link completo de 300 caracteres. Agora: depois de salvar, a lista abre com um

aviso "Link curto para divulgar" e botao Copiar; cada linha da lista tem Copiar ao lado do link curto

(abrir o link conta como clique); e a ajuda da previa diz para preferir o link curto. Testado em

navegador headless (aviso, copia, volta do botao), zero erro de JS.

• UTM sem espaco nem "+". O conteudo padrao era centro + zona_sul e o termo uma frase com espacos:

no link viravam centro+%2B+zona_sul e promocao+teatro+.... Agora centro_zona_sul e termos unidos

por _. Nada no sistema dependia do texto antigo (procurado no codigo). E quando a campanha nasce do

botao da peca, Content e Term vem vazios (descrevem disparo segmentado de CRM e anuncio pago, nao

post de canal): o link sai so com source, medium e campaign. O fluxo dos Disparos mantem os dois.

• Campanha 77 (cwa) convertida a pedido do ADMIN: origem detectada -> planejada, nome "Discutindo a

Relacao | WhatsApp Social Post | 2026-10-06", data_fim = 18/10/2026 (fim da temporada da peca 1024),

e link curto criado. Backup da linha em SQL/bkp_campanha77_*.json.

• Mesmo pedido: opcao canal ("Canal (ex.: Canal do WhatsApp)") no UTM Medium de incluir.php e

editar.php, para separar post no Canal do WhatsApp de disparo de CRM. A coluna e varchar, nada

mais valida o valor.

[2026-10-06] [BK-497] Selos alternando na pagina da peca e video para stories - parte 2

Origem: ADMIN escolheu as opcoes 1 e 3: a capa continua um PNG parado (e o que vai para WhatsApp e

Facebook), os selos alternam por cima do cartaz na pagina da peca, e ha um video vertical para stories.

Pagina da peca (opcao 1):

• Tabela nova rnt_pecas_selos (SQL/rnt_pecas_selos.sql): uma linha por peca com o arquivo da capa, o

tamanho dele em bytes, a lista de selos e a posicao (fracoes da imagem). Gravada pela aba ao salvar

como capa com 2 ou 3 selos (act arte_promo_selos_salvar); com menos selos a linha e apagada;

excluir a foto apaga a linha.

• peca.php: quando a capa atual e exatamente aquele arquivo (nome e tamanho), o cartaz ganha um

wrapper do tamanho da imagem e os selos por cima. O que entra faz fade sobre o que esta visivel, que

so some depois - nunca fica sem selo. Trocar a capa desliga a animacao sozinha. Respeita

prefers-reduced-motion. Sem linha na tabela a pagina sai igual a antes.

• selo_promo.php (publico, so leitura): desenha o selo com o preco atual da peca. So responde para

peca ativa, com selos configurados, e para um tipo da lista dela; o resto e 404. ETag + cache em /tmp.

• selo3.png (logo) refeito sobre a silhueta do selo 1: era um pouco menor e deixaria aparecer o

contorno do selo fixo do arquivo (2.424 pixels medidos; agora 0).

Video para stories (opcao 3):

• Botao "Gerar video para Storie": a aba manda a arte sem selo e a posicao; o act arte_promo_video

so valida (PNG 600x1067, peca, precos) e enfileira em admin/runtime/arte_promo_video/.

• admin/cron/arte_promo_video.php + /etc/cron.d/rnt-arte-promo-video (a cada minuto, fora do Git):

gera com ffmpeg um MP4 1080x1920 H.264 de 13,2 s com faixa de audio muda, confere com ffprobe e so

entao grava (por rename) em arquivos/pecas/<id>/video/<slug>-story-arte-<data>.mp4 - a pasta da aba

Storie. Esse arquivo passa a ser a midia dos stories automaticos da peca (o cron social usa o

video da pasta). Pedido que falha vai para falhas/ e nao se repete.

• Depois de pedir o video a aba consulta a lista da aba Storie a cada 10 s (ate 3 min) e, quando o

arquivo aparece, atualiza a aba e avisa na tela; o cron manda push ao gestor (so admin) quando o

video fica pronto e quando falha. Pedido do ADMIN depois do primeiro video real (peca 1634, 18:58 ->

pronto 18:59:15): ele abriu a aba Storie 12 s depois do clique e nao viu o arquivo.

• O ffmpeg nao roda na requisicao web de proposito: o php-fpm encerra requisicao longa e cada clique

prenderia um worker do site (consulta previa ao gpt-6-astra).

• Validacao: Sintaxe PHP ok (6 arquivos), Sintaxe JS ok.

Pagina real, com uma configuracao de teste ligada por ~1 min na peca 1024 e depois removida: wrapper

igual a imagem, selo em 76,0%/49,0% com 32,0% de largura no desktop (388x690) e no celular (320x569),

3 selos carregados, sequencia de visibilidade sempre com 1 selo (2 so durante o fade), clique sobre o

selo ainda abre a imagem ampliada, zero erro de JS. Sem configuracao: sem wrapper e selo_promo 404.

Video: 3 pedidos numa fila de teste (3 selos, 2 selos, incompleto) - 2 MP4 validos (h264 1080x1920 30fps

yuv420p + aac, 13,2 s, ~700 KB, ~16 s cada para gerar), o incompleto foi para falhas/; quadros

extraidos mostram a alternancia. Enfileirar como usuario www e processar pelo cron: ok. Fila, log e

script do cron nao sao servidos pela web (403/404/404).

Aba em navegador headless: salvar como capa grava a posicao; com 1 selo apaga; sem o check de capa

nao mexe; o pedido de video leva a arte sem selo.

• Revisao final do gpt-6-astra: sem P1; 1 P2 corrigido - o bloco dos selos no peca.php nao tinha

try/catch, e uma falha da lib ou da tabela derrubaria a pagina de venda. Agora qualquer Throwable

ali so desliga os selos.

• Nao validado: a aba no admin real com login, e nenhum video foi gerado na pasta real de stories.

[2026-10-06] [BK-497] Selos dinamicos no meio da arte (aba Arte promo) - parte 1

Origem: ADMIN mandou os 3 selos que vao no meio das imagens (De/Por, % OFF, logo) e pediu botoes

para inclui-los, posicionar e dimensionar, com os valores e a % atualizados sozinhos. Em seguida pediu

que os 3 fiquem na mesma posicao alternando com fade ("impressao de video").

Feito nesta parte:

• arte_promo_lib.php: rnt_arte_selo() desenha o texto sobre os modelos arte_promo/selo{1,2,3}.png

(os arquivos do ADMIN em dobro de resolucao, com a area do texto limpa nos selos 1 e 2). Selo 1 em

Oswald Bold (a mais proxima do modelo entre 4 testadas), selo 2 em Sora ExtraBold; texto encolhe para

caber (testado com R$1.250 / R$899,90). Act arte_promo_selo no action.php (so leitura).

• Aba: 3 botoes (De / Por, % OFF, Logo), controle de tamanho, arrastar o selo no quadro. Todos os selos

ligados ficam na MESMA posicao e tamanho; com 2 ou 3 ligados a previa alterna entre eles com fade.

Mudar preco ou % refaz os selos junto com o topo e o rodape.

• O arquivo salvo ainda e um PNG parado, com o primeiro selo ligado.

• Validacao: Sintaxe PHP ok, Sintaxe JS ok; navegador headless: ligar, arrastar, ampliar, alternancia

(6 estados distintos em 7 s), troca de preco refletida no selo e no rodape (63% -> 75%), salvar, e

preco invalido desligando os selos que dependem dele. Zero erro de JS. Nao testado no admin real.

• Pendente de decisao do ADMIN: como a alternancia chega ao publico (so na pagina da peca, arquivo

animado como capa, ou video para stories). Ver BK-497 no backlog quando decidido.

[2026-10-06] [BK-496] Mapa de assentos cabe na tela, com o palco alinhado as poltronas

Origem: ADMIN - em /discutindo-relacao, ao clicar numa data, o palco passava do limite da tela e a

disposicao das poltronas estava ruim.

Causa: .teatro tinha width: 1150px !important. No celular (390px) a caixa "Palco" (805px) saia da

tela, o rotulo nem aparecia e o mapa (505px) era cortado; no desktop o mapa ficava pequeno (poltrona

20x22, letra de 8px), colado a esquerda, com o palco mais largo que as poltronas.

Mudanca (peca.php): palco e poltronas viraram um bloco so (.rnt-mapa), do tamanho do proprio

mapa e centralizado; rntAjustarMapa() escala o bloco para a largura disponivel (ate 1,5x quando sobra,

ate 0,7x quando falta; abaixo disso rola para os lados, comecando centralizado) e roda quando o mapa

aparece e quando a tela muda de tamanho. Palco com desenho de palco; letra da poltrona 8 -> 9px;

no celular o espaco entre poltronas caiu de 4 para 2px; legenda "Seleciondo" -> "Selecionado".

Nao mudou: texto, data-id e clique das poltronas - e o texto delas que vai para a compra.

• Validacao em Chrome headless, clicando numa data real: pecas 1024 (teatro 15, 19 poltronas de largura)

e 1085 (teatro 79, 14), em 1366, 1024, 390 e 360px. Pagina nunca rola para os lados; palco sempre dentro

da tela e alinhado as poltronas (diferenca <= 3px). Desktop: poltrona 30x33, letra 13,5px. Celular 390:

teatro 15 em 0,746x (poltrona 15x16, letra 6,7px), teatro 79 em 1,12x (22x25, 10px).

Fluxo AJAX validado: selecionar 2 poltronas preenche assentosselecionados, "Meus Assentos" e a

quantidade como antes. Peca sem mapa (1634) segue sem mapa. Zero erro de JS. Sintaxe PHP ok.

• Revisao do gpt-6-astra: 1 P2 (mapa mais largo que a tela ficaria com poltronas inalcancaveis a

esquerda por causa do text-align: center). Nao reproduz: medido em tela de 280px, rolando tudo

para a esquerda a primeira poltrona fica em x=16 (area comeca em 15) e para a direita a ultima fica

em x=250 (area termina em 250) - o navegador alinha pelo inicio quando o conteudo estoura. Tambem

medido: girar a tela (280 -> 700px) e trocar de data reajustam a escala.

• Limite: no celular, teatro largo como o 15 fica com poltrona pequena (15px). O zoom por pinca esta

desligado no site (user-scalable=no), entao nao ha como ampliar; a alternativa seria rolar o mapa.

• Visto e nao alterado: na legenda a bolinha de "Disponivel" e azul-escura e a poltrona livre e verde.

[2026-10-06] [BK-495] Cartaz inteiro na pagina da peca (desktop cortava)

Origem: ADMIN - em /discutindo-relacao a arte nova aparecia grande e cortada; o certo e a imagem

inteira, com a altura maxima atual, podendo sobrar espaco dos lados.

Causa: no CSS inline do peca.php a .rnt-gallery tinha 690px fixos e a .rnt-main-image

preenchia tudo com object-fit: cover. Medido em 1366px: arte 600x1067 e banner 1128x634 exibidos

ambos em 531x690, ou seja, cortados (vertical em cima/embaixo, horizontal nas laterais). Sempre foi

assim no desktop - a Lisa, Lesa & Louca tambem estava cortada; no celular ja era contain.

Mudanca (peca.php, so CSS): 690px virou altura MAXIMA; a imagem usa width/height: auto,

max-width: 100%, max-height: 690px e object-fit: contain.

• Validacao: Sintaxe PHP ok; pagina renderizada em Chrome headless antes e depois, desktop 1366 e

celular 390, em 3 pecas: 1024 e 1342 (600x1067) passam a 388x690; 1085 (1128x634) passa a 531x299;

nenhuma cortada; celular identico ao de antes (320x569 e 320x180).

• Revisao do gpt-6-astra: 1 P2 corrigido - o teto de 690px na caixa valia tambem abaixo de 768px e

cortaria arte alta em tela de 700px; no bloco mobile a caixa voltou a max-height: none.

• Efeito colateral esperado: banner horizontal fica mais baixo do que a coluna de informacoes ao lado

(antes ele era ampliado e cortado para preencher os 690px).

• Nao alterado: peca_pagseguro.php tem o mesmo CSS antigo.

[2026-10-06] [BK-494] Aba "Arte promo" no Gestor de pecas

Origem: ADMIN - perdia tempo no Photoshop so para trocar preco, local e % na arte padrao. Pediu

uma aba no Gestor (ao lado de Fotos, Videos e Storie) para soltar a arte do cliente e sair com o

topo e o rodape, podendo mover, dar zoom e apagar logo de terceiros (Sympla, Eventim, Divertix).

Mudanca:

• admin/modulos/pecas/arte_promo_lib.php + arte_promo/ (modelo topo.png/rodape.png recortado

da arte da peca 1342 e fontes Sora, licenca OFL): desenha a MOLDURA 600x1067 com o meio transparente.

Fontes ditadas pelo ADMIN: De = Sora Light, Por = Sora ExtraBold, Local e % = Sora Bold.

• admin/modulos/pecas/action.php: acts arte_promo_dados (de/por/%/bairro da peca) e

arte_promo_moldura (PNG). So leitura; os dois entraram na lista de excecoes do bloco de campos.

• admin/inc-gestor.php + admin/js/gestor-arte-promo.js: a aba. O navegador encaixa a arte sob a

moldura (arrastar, roda/barra de zoom, "Encaixar inteira"/"Preencher a faixa"), a borracha preenche

a area pintada com as cores vizinhas, e "Salvar" envia o PNG pelo upload_foto de sempre - a arte

entra na aba Fotos; virar cartaz continua sendo "Usar como capa".

• Check "Usar como capa da peca" (marcado por padrao): ao salvar, a arte ja vira a capa pelo act

marcar_capa de sempre. Desmarcado, so entra nas fotos. Se a troca falhar, a tela avisa que a arte

foi salva mas nao e a capa. Pedido do ADMIN depois do primeiro teste real (o salvar funcionou).

• admin/js/gestor-foto-zoom.js: na aba Fotos, clicar na miniatura abre a foto cheia (/large/) por

cima do modal; fecha com clique ou Esc. A miniatura e um recorte 348x228 e nao deixava ver qual era.

• Botao "Editar (borracha)" em cada foto da aba Fotos (pecas_gestor_card_foto): abre a foto na

aba Arte promo em modo edicao - quadro grande no tamanho da propria foto, so a borracha, sem topo e

rodape. Salva uma copia (a original fica); se a foto editada era a capa, o check ja vem marcado e

a copia assume a capa. JPG continua JPG.

• deletar_foto: excluir a capa deixava a peca sem capa mesmo com outras fotos, e o site caia no

logo. Aconteceu na peca 1024 as 17:25 de 06/10 (o ADMIN excluiu o banner do Divertix; a arte nova

ficou com fot_capa = 0 e o og:image virou logo_2023.png). Agora a primeira foto da ordem

assume. Na 1024 a capa foi reposta a mao (foto 2966) e pecas.imagem/imagem_formato acertados.

• Primeiro selo do rodape: "Assento marcado" ou "Entrada por fila", conforme a regra predefinida da

peca. A escolha do select "Regras Predefinidas" nao e gravada (so preenche pecas.regulamento), entao

le-se o texto: o item 1.3 das duas regras "sem assento" diz "entrada e por ordem de fila, sem assento

marcado". A tela traz o selo ja escolhido num select editavel e **avisa quando a regra e as sessoes

discordam** - caso real: peca 1342 (Lisa, Lesa & Louca) tem regra "sem assento" e vende com mapa de 27

lugares. CLI: --entrada=assento|fila. Com "assento" a imagem continua identica a aprovada.

• Peca com preco so nas sessoes (pecas.valor vazio, caso da 1342): a aba usa a proxima sessao a venda.
• CLI /root/rnt-tools/arte_promo.php passou a usar a mesma lib (imagem identica, 0 pixel de diferenca).

• Validacao: Sintaxe PHP ok (php83 -l nos 4 .php), Sintaxe JS ok (node --check). Tela exercitada

em navegador headless com o HTML real do inc-gestor.php e um roteador de teste sobre a mesma lib:

dados da peca 1024 preenchidos, arte quadrada e vertical, borracha sobre o logo do Divertix (apagou

em ~1,7 s), desfazer, preencher + arrastar + roda, troca de preco/local, preco invalido bloqueando o

salvar, e o PNG salvo saindo 600x1067. Zero erro de JS. Sem login no admin: action.php responde 302.

• Nao validado: a tela dentro do admin real (exige login) nem o upload_foto real. Falta o teste do ADMIN.
• Revisao do gpt-6-astra: consulta antes (lista de excecoes, resposta binaria, cache do JS - aplicados) e

revisao final com 2 P2 corrigidos (salvar com moldura desatualizada; resposta atrasada de outra peca).

• Defeito antigo corrigido junto (fallout do PHP 8.3, BK-348): os acts fora da lista de excecoes e

sem categorias[] - list-picture e list-video, ou seja, abrir o Gestor - morriam em

implode(', ', $_POST['categorias']) com TypeError; o Gestor abria sem listar as fotos ja enviadas.

Medido no log: excecao as 17:01:32 de 06/10, antes desta edicao (resposta de 20 bytes). O Gestor e

pouco usado (1 POST em 12 dias), por isso passou. Agora sem categorias[] o campo vai vazio, como

era no PHP 5.6. cadastrar/editar continuam recebendo o array do formulario.

• Limites conhecidos: a borracha so fica boa em fundo liso; arte 9:16 nao cabe inteira na faixa (pedir a

quadrada); arte salva em peca fora de temporada e apagada pelo cron de limpeza de cartaz, como

qualquer foto; o modulo de pecas segue sem CSRF (ja era assim no upload_foto).

[2026-10-06] [BK-492] Push ao gestor a cada disparo de lista de compradores

Origem: ADMIN - "pode me enviar por push tbm sempre que disparar uma lista"; e em seguida: o push

e so do admin, o produtor segue no WhatsApp porque pode nao ter o push liberado.

Mudanca (z_dispara_diario.php): depois do e-mail e do WhatsApp de cada sessao, chama

enviar_push_admin() com "Lista enviada: <peca>" (ou "Lista NAO enviada" quando nada saiu), a sessao,

as contagens de e-mail e WhatsApp e o link da lista. Dedup 0: cada disparo avisa. Envio ao produtor

(e-mail e WhatsApp) e a regra que marca sec_enviolista = 0 nao mudaram.

• Validacao: Sintaxe PHP ok (php83 -l); o bloco foi ensaiado em script isolado com as mesmas

variaveis e o push de teste chegou (log push_dispatch.log: 3 enviadas, 0 falhas). O cron real nao

foi rodado - reenviaria listas a produtores; a primeira prova em producao e a proxima sessao com

venda (Discutindo a Relacao, 10/10).

• Achado, nao alterado: $ok_wpp nao e zerado a cada sessao no laco; com e-mail desligado, uma

sessao sem telefone poderia herdar o "ok" da anterior e ser marcada como enviada. Hoje o e-mail

esta ligado nos dois crons, entao nao dispara. BK-493.

[2026-10-06] Ferramenta teatros.php e telefones da lista (peca 1024)

• /root/rnt-tools/teatros.php (so leitura): buscar, mapa, blocos e assentos, que traduz o

pedido do ADMIN ("B e C centrais", "bloqueio c e f", "C1 a C14 exceto C7") no CSV do sec_mapa.

Conferida contra os dois cadastros do dia: 18 poltronas no teatro 15 e 27 no teatro 79, iguais ao

que esta gravado. Intervalo compara o numero, entao B6-B14 casa B06 (contorna o BK-490).

• Peca 1024: telefone_lista = 21981154040 (produtor), 21999915554 (ADMIN) e 21999605790

(numero do RNT - assumido; o ADMIN nao disse qual e).

[2026-10-06] Discutindo a Relacao reativada no Teatro dos Grandes Atores (Divertix)

Origem: ADMIN - "atualize a peca https://divertix.com.br/teatro/dr-discutindo-a-relacao de 120 por

45, assentos B e C centrais", com a ordem de trocar o teatro (a temporada anterior era no Vannucci).

Dados (peca 1024, sem mudanca de codigo): teatro 21 -> 15 (Grandes Atores - Sala Vermelha);

sessoes novas 19326-19329 (sab 10/10 20h, dom 11/10 19h, sab 17/10 20h, dom 18/10 19h), R$ 120 ->

R$ 45, 18 lugares cada: bloco central das fileiras B e C (B06-B14, C06-C14); temporada 10/10 a

18/10; oferta 63%; status I -> A; duracao 100 -> 80 minutos e classificacao 12 -> 14 anos, como no

Divertix; sinopse com "10 anos / 500 mil espectadores"; cartaz do Divertix (740x380, horizontal) em

arquivos/pecas/1024/ + tb_fotos. Backup: SQL/bkp_peca1024_20261007_032008.json.

• Validacao: pagina /discutindo-relacao 200 sem erro, com as 4 datas, 120,00, 45,00 e o teatro novo;

og:image e imagem em 200; Fluxo AJAX validado - act=entradas devolve as 18 poltronas nas 4

sessoes; check_temporada.php sem alerta (inclusive cartaz); peca na home.

• Nao conferido: o mapa do Divertix exige login, entao as 18 poltronas saem da frase do ADMIN e do

nosso mapa do teatro. O Divertix nao diz a sala; usada a Sala Vermelha, unica do teatro no sistema.

• email_lista: saiu so bilheteriateatrovannucci@gmail.com (bilheteria do teatro ANTERIOR; o campo

tambem da acesso aos pedidos no painel do produtor - P2 da revisao do gpt-6-astra). Ficaram o interno

e os dois da producao. Nao alterado: ficha tecnica (vazia no Divertix) e telefone_lista (vazio).

• Mapa conferido depois com a captura do Divertix enviada pelo ADMIN

(arquivos/download/20261006-162115-...png): B06-B14 e C06-C14 aparecem bloqueados la, igual ao

nosso sec_mapa. A mesma captura mostra diferencas no nosso mapa do teatro 15 fora de B/C (BK-491).

• Doc: secao 10 nova no runbook de cadastro. Achado virou BK-490 (assentos.php e poltrona B06).

[2026-10-06] [BK-489] Trava: push com edicao nao commitada e recusado

Origem: o deploy de um push de docs apagou a edicao viva do BK-488 (ver entrada abaixo).

Mudanca: pre-push em .git/hooks/pre-push (fora do Git; fonte em

/root/rnt-tools/git-hooks/pre-push-rnt). Recusa git push para a main deste repositorio

enquanto houver arquivo versionado modificado sem commit (staged ou nao) e lista os arquivos.

Nao conta arquivo nao rastreado nem docs/, que o rsync do deploy nao regrava (EXCLUDE do

deploy.yml). Se o git status falhar, recusa. Bypass consciente: RNT_PUSH_SUJO=1 git push origin main.

• Validacao: bash -n ok; em repositorio de teste - arvore limpa passa, .php modificado ou

staged recusa (inclusive em git push real: nada chegou ao remoto), so docs/ modificado

passa, outra branch e outro remoto passam, bypass passa, falha do git status recusa.

• Revisao do gpt-6-astra: sem P1; 3 P2 corrigidos (falha do git status liberava o push;

bloqueava docs/, que o deploy nao toca; bloqueava remoto sem deploy).

• Limite: hook de .git/hooks nao e versionado - um clone novo nasce sem a trava (reinstalar com o

cp do cabecalho do script). Protege o push feito nesta VPS, nao push de outra maquina.

• Correcao em 06/10 17:37: instalada em .git/hooks/, a trava so valeu ate o deploy seguinte - o

chmod 644 do deploy tirou o bit de execucao e o git passou a ignora-la (visto no push do BK-494:

hint: ... ignoredHook). Movida para /usr/local/libexec/rnt/git-hooks/ via core.hooksPath, fora

do alcance do deploy. Retestada: push sujo recusado, push limpo passa. O teste original nao pegou

porque foi feito antes de qualquer deploy rodar por cima.

[2026-10-06] [BK-488] Produtor nao ve mais a coluna Transacao na tela de pedidos

Mudanca (produtor/modulos/pedidos/index.php e action.php): o cabecalho e a celula

"Transacao" (codigo da transacao com link de busca no PagSeguro) so aparecem quando

$_SESSION['CMS_X']['tipo'] == 'admin', mesmo criterio que a tela ja usava para "Acoes" e

"E-mail". Vale para a carga inicial e para as tres listagens paginadas por AJAX do action.php.

• Editado em 03/10/2026 e ficou no ar sem commit. Em 06/10 o deploy de um push de docs regravou os

dois arquivos com a versao do repositorio e apagou a edicao (14:48:59); reaplicada a partir

do diff no mesmo minuto - arquivos com o mesmo tamanho de antes (19.218 e 27.100 bytes). A causa

virou o BK-489 (trava de pre-push, entrada acima).

• Validacao: Sintaxe PHP ok (php83 -l nos dois); cabecalho e linhas saem com o mesmo numero de

colunas nos dois perfis (conferido no codigo); 3 acessos reais ao modulo entre 03/10 e 06/10, todos

200, sem erro no log do PHP. Tela nao foi exercitada com login de produtor nesta rodada.

[2026-10-06] Cinderela Negra reativada (18/10) e runbook para link Bileto

Origem: o ADMIN colou a mensagem do Teatros da Barra ("de 50 por 15", link

bileto.sympla.com.br/event/105219, "Bloqueio c e f") e pediu para deixar documentado.

Dados (peca 1085, sem mudanca de codigo do site): sessao nova 19325, dom 18/10/2026 16:00,

copia da 19224 (R$ 50 -> R$ 15, 27 lugares, fileiras C e F); inicio_temporada/fim_temporada =

18/10; status I -> A; datas da sinopse trocadas ("Dia 18 de Outubro / Domingo as 16h").

O cartaz tinha sido apagado pelo cron de limpeza em 07/09 com pecas.imagem ainda apontando para

ele: reposto a partir do Sympla (large/media/thumb + linha em tb_fotos).

Backup: SQL/bkp_peca1085_20261007_010333.json (o nome sai em horario PRC do php.ini).

Ferramenta: /root/rnt-tools/sympla_evento.php passou a ler link Bileto (antes devolvia

"nenhum evento encontrado"): sessoes, tipos de ingresso, fileiras fora da venda no Sympla,

descricao e cartaz (--cartaz). Doc: §9 novo em docs/RUNBOOK_CADASTRO_EVENTO_PRODUTOR.md.

• Validacao: Sintaxe PHP ok (php83 -l na ferramenta); pagina /cinderela-negra 200 sem erro,

com 18/10, 50,00 e 15,00; og:image e imagem em 200; Fluxo AJAX validado - act=entradas

devolve os 27 assentos de C e F; check_temporada.php sem alerta; peca na home. O mapa do Sympla

confirma o bloqueio: C1-C14 e F1-F13 fora da venda la.

• Lista de compradores, por ordem do ADMIN: email_lista = `lista@rionoteatro.com.br,

katiaporto2013@gmail.com (antes so o da produtora); telefone_lista = 21970672515, 21999915554`.

[2026-10-03] [BK-487] Lista digital mostra "comprado por" em pedido transferido

Origem: o ADMIN nao achou na lista digital a compra do aviso de venda do pedido #73957.

O pedido constava, mas tinha sido transferido no mesmo dia: o aviso sai com o nome de quem

comprou e a lista mostrava so o novo titular.

Mudanca (produtor/listaopen.php): quando pedidos.metadados traz cliente_original

diferente do cliente_id atual, a celula do nome ganha (comprado por <nome>), fora do link de

marcar ingresso retirado. Consulta, ordenacao, total e produtor/fechamento.php nao mudaram.

O mesmo texto vai no e-mail do "enviar lista" da tela, que reutiliza o mesmo HTML.

• Validacao: Sintaxe PHP ok (php83 -l); tres listas renderizadas em 200 sem erro no log -

sessao 19316 mostra o "comprado por", sessoes 19310 e 19278 (sem transferencia) iguais a antes,

totais iguais. Clique de marcar/desmarcar ingresso nao foi exercitado (link nao alterado).

• Revisao final do gpt-6-astra: sem P1/P2.
• Conferido na mesma rodada, sem mudanca: pedidos #73955 e #73956 constam na lista de 02/10 e no

fechamento de outubro da peca 1634 (5 pedidos, 9 ingressos, R$ 270,00 bruto).

[2026-10-03] [BK-486] WhatsApp de compra aprovada: "Aprovada a compra de...", local do evento e link sem https

Origem: pedido do ADMIN, a partir da mensagem recebida pelo cliente do pedido #73957.

Mudanca (includes/whatsapp_helper.php, rnt_msg_compra_aprovada_cliente()):

• "E 1 ingresso para o Evento..." / "Sao N ingressos..." virou

"Aprovada a compra de 1 ingresso para o Evento..." / "Aprovada a compra de N ingressos...";

• linha nova Local: <teatro> (<bairro>), lida de pecas.teatro -> teatros pela funcao nova

rnt_local_do_evento(). Sem teatro cadastrado, sem conexao ou com erro de consulta a linha some e

a mensagem sai igual - o local nunca impede o aviso;

• o link de detalhes saiu de https://rionoteatro.com.br/peca.php?id=N#regras para

www.rionoteatro.com.br/peca.php?id=N#regras, a pedido do ADMIN, para nao virar link.

Nao provado: o WhatsApp costuma tornar clicavel tambem o endereco com www.; o ADMIN confere

na mensagem de teste.

Vale para os tres caminhos (PIX/cartao pelo cron BK-478, carteira em action.php, rota PagSeguro em

notifications.php), porque todos chamam a mesma funcao. O rodape (numero do pedido + assinatura,

os ultimos 100 bytes que o anti-spam compara) nao mudou, e os crons que procuram a mensagem no

historico casam por Compra foi Aprovada e #pedido*, nao pela frase trocada.

• Validacao: Sintaxe PHP ok (php83 -l e php -l 5.6); texto gerado com o pedido real #73957

(singular, com local) e com caso sintetico (plural, peca inexistente, sem a linha do local);

teste enviado so ao numero do gestor, marcado TESTE BK-486, HTTP 200.

• Monitor MP: arquivo monitorado, baseline selada apos a edicao, --check OK.
• gpt-6-astra consultado antes (sem P1; P2 preventivo de instanceof mysqli + Throwable aplicado)

e na revisao final (sem P1/P2).

[2026-10-01] [BK-484] Quantidade nao numerica no pedido.php dava fatal no PHP 8.3

Origem: alerta do vigia_erros_runtime - FATAL em pedido.php:105 (15x),

TypeError: Unsupported operand types: string * float.

Quem bateu no erro (medido): um unico IP, 15 POSTs em 17 segundos (15:55:28-15:55:45), dentro de

uma varredura de 147 requisicoes em 3 minutos que sondou swagger.json/openapi.json e injetou lixo

nos formularios de login, cadastro e pedido. Nenhum cliente foi afetado: o ultimo POST legitimo

(15:41) respondeu 200 e nao ha outra fatal no dia. Nenhum outro 5xx nessa varredura e nenhum payload

de exploracao nas URLs; o corpo dos POSTs nao fica no access log.

Causa: $quantity vem do POST e entra em valor * quantity (linhas 105, 116 e o calculo do

pedido mais abaixo) sem checagem numerica. O BK-423 blindou so o valor com (float). No 5.6 texto

valia zero; no 8.3 string totalmente nao numerica e fatal.

Correcao (pedido.php): a validacao de quantidade que ja existia (vazio ou 0) passou a recusar

tambem o que nao e inteiro positivo, com o mesmo aviso "Voce nao escolheu uma quantidade de ingressos".

• Validacao: Sintaxe PHP ok (php83 -l); condicao isolada (1, 2, 10 passam; texto, negativo,

decimal, vazio e zero recusados); POST real com quantidade invalida direto no vhost respondeu 200

com o aviso e sem fatal nova no log.

• Nao testado por HTTP: o caminho de compra valida (criaria pedido de teste). A mudanca so

acrescenta casos de recusa.

• Sem re-seal: pedido.php nao esta na lista do monitor MP (mp_guard_file_paths()).
• Revisao final do gpt-6-astra: sem bloqueador.
• Detalhe que engana: a mensagem string * float nao diz qual lado e a string - o lado esquerdo

ja era (float); a string era a quantidade.

• Ponta aberta: o alerta nao diz de quantos IPs vieram as fatais - BK-485.

[2026-09-30] [BK-374] Debug de pagamento dos conferir_* sai do webroot

O debugLog() de admin/modulos/pedidos_2/conferir_mercadopago.php e conferir_pagseguro.php gravava

debug_mp.txt/debug_ps.txt em __DIR__, dentro do webroot, com id de pedido + transaction_id do MP em

claro (servidos 200 ate a allowlist do BK-376; 404 desde entao).

• A funcao agora usa error_log() tipo 0, que grava no log do pool rnt

(/www/wwwlogs/rnt83-php-error.log) com prefixo [RNT-DEBUG-MP]/[RNT-DEBUG-PS].

• Por que nao um arquivo proprio em /www/wwwlogs/: o open_basedir do .user.ini nao inclui

wwwlogs e o @file_put_contents falharia em silencio. error_log tipo 0 nao sofre open_basedir

(provado em CLI: tipo 3 e file_put_contents devolvem false no mesmo cenario).

• Uma linha por registro e os marcadores do vigia_erros_runtime (PHP Fatal error, PHP Parse error,

PHP_EXCEPTION) neutralizados, para dado vindo do gateway nao virar alerta falso de fatal.

• Historico arquivado em /www/wwwlogs/rnt-debug-pagamentos/ (750, arquivos 640 www:www), SHA-256

conferido antes de remover os .txt do webroot (estao no .gitignore; o deploy nao repoe).

• Sem re-seal: os conferir_* nao estao na lista do monitor MP (mp_guard_file_paths()).
• Validacao: Sintaxe PHP ok (php83 -l) nos dois; teste CLI isolado da funcao com open_basedir

restritivo. Nao testado via FPM (sem GET em /admin/, que alerta o gestor): no primeiro uso do

botao, conferir com grep RNT-DEBUG /www/wwwlogs/rnt83-php-error.log.

• Outros escritores de dado de pagamento no webroot ficaram no BK-374b.

[2026-09-29] [BK-482] WhatsApp de compra "sem conta" que tinha conta (LID) + alerta diz se o problema e do numero ou do sistema

Origem: alerta do BK-361 as 08:49: #73952 (cartao, cliente DDD 61) sem a confirmacao, com o texto

"e a mesma falha do BK-359 voltando". Nao era: o cron do BK-478 achou o pedido em 3 min e o dono,

o push e o Ads receberam; so o WhatsApp ao cliente falhou, com 422 No LID for user.

Causa (medida): o 422 so sai quando o erro vem do sendMessage() - o isRegisteredUser() tinha

aceitado o numero (journal sem "Numero invalido"). O /check-number mostrou que 5561998021609 e

556198021609 resolvem para o MESMO 143396828086521@lid: o cliente TEM WhatsApp; o WhatsApp Web e que

nao liga aquele @c.us ao LID. Todo numero resolve para @lid hoje, inclusive os DDD 21 que funcionam.

Gateway (bot/whatsapp/server.js):

• sendWithLidFallback(): envia para o @c.us de sempre; so em No LID for user (nada foi enviado)

repete UMA vez para o id do getNumberId(). Vale para texto, midia e enquete.

• Antes do reenvio registra LID e variante sem o 9 -> numero do cadastro (o message_create pode chegar

antes do sendMessage() voltar - P1 do gpt-6-astra no desenho). O webhook gravou 5561998021609.

• /check-number devolve tambem o wid (so leitura).
• Primeiro desenho (trocar o id pelo resolvido, aceitando so @c.us) nao teria consertado nada: o

resolvido e @lid. Pego no teste antes de fechar.

**Avisos (pedido do ADMIN: "o alerta precisa dizer o motivo ... conferir celular e telefone e se o numero

ja esta com o 9"):**

• rnt_ca_candidatos_fone(): celular, telefone, cada um com o 9 acrescentado se estiver no formato

antigo, e fixo por ultimo.

• avisos_compra_aprovada.php: consulta cada candidato no /check-number (rnt_wa_check_consultar_bot,

BK-385); so passa ao proximo quando o WhatsApp CONFIRMA que nao ha conta (falha de envio para, senao

duplicaria - astra). Estado novo sem_whatsapp; o que foi conferido fica em erro.

• verifica_wa_compra_aprovada.php: acha a mensagem pelo #<pedido>* em qualquer numero e o alerta diz

o motivo: "Cliente sem WhatsApp - nao e falha do sistema" (com os numeros conferidos), "falha no

envio" (nosso) ou "nao entrou na fila de avisos". Aviso preso >30 min em pendente vira alerta.

Validado: node --check e php83 -l; gateway reiniciado 3x sem QR; DDD 21 com --test-send 2x

(recebido pelo ADMIN) sem acionar o reenvio; #73952 entregue as 12:05 pelo reenvio ao LID;

verificador em simulacao ve o #73952 como saiu=SIM | aviso=enviado | ok; 8 casos da regra de

candidatos; simulacao dos dois crons limpa; revisao final do astra sem P1 (3 P2 corrigidos).

Nao exercitado ao vivo: os textos novos de alerta sem_whatsapp/falhou (dependem de um cliente

real sem WhatsApp). Pontas abertas: BK-482b e BK-483.

[2026-09-28] [BK-481c] Modulo Campanhas em utf8mb4 (emoji virava "?") + editar.php quebrado desde 30/04

Pedido do ADMIN: "corrige as outras telas de campanhas tambem" (emoji aparecia como "?") e trocar

o presente do desconto por fogo no titulo sugerido do push por peca.

Causa: admin/modulos/campanhas/includes/db.php conectava em utf8 (3 bytes); o MySQL troca emoji

(4 bytes) por "?". O site principal (config/connect.php) ja era utf8mb4 - o modulo era o unico fora.

Por que nao bastava trocar a conexao: o servidor esta em STRICT_TRANS_TABLES e 4 tabelas gravadas

pelo modulo eram utf8: com conexao utf8mb4, emoji nelas daria ERRO e perderia o registro - inclusive

o rastreio de visitas do site publico, que grava pelo tracking/save_tracking.php deste modulo.

O que mudou:

• Backup: /root/rnt-tools/backups/dump_bk481c_20260928-181205_utf8.sql.gz (600, fora do webroot).
• ALTER TABLE ... CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci (mesma semantica de

comparacao do utf8_general_ci) em robot_config (9 linhas), campanhas_alertas (0), campanhas (44)

e cliente_tracking (45.140 linhas, 3,2 s); contagem igual antes/depois; lock_wait_timeout=10.

• includes/db.php: conexao em utf8mb4. campanhas/push.php perdeu o ajuste local, agora redundante.
• editar.php: usava db_escape(), que so existe no social_squad_helper.php (nao carregado) e devolve

sem aspas - a tela Editar dava erro fatal em toda campanha com UTM desde 30/04/2026 (commit

4b0e72b08). Trocado pelo escape() do modulo.

• admin/modulos/pecas/push.php: titulo sugerido com 🔥NN%OFF no lugar de 🎁 (commit 02ad23256).

Titulos ja enviados ficam como foram (historico).

Validado: php83 -l; POST real no save_tracking.php com emoji na URL gravou 🔥🎭 e nao criou

campanha (linha de teste apagada); db_update com emoji em campanhas dentro de transacao desfeita;

8 telas renderizadas sem erro (index, dashboard-roi, alertas, detalhes, editar, incluir, redes_sociais,

push). Emoji gravado ANTES desta data nessas 4 tabelas ja tinha virado "?" na gravacao: nao ha como

recuperar.

[2026-09-28] [BK-481] Relatorio de Notificacoes Push em Campanhas (envios, cliques, base)

Pedido do ADMIN: submenu de push dentro de Campanhas "com relatorios de envios, dados e etc";

escolheu gravar cada disparo em tabela e depois pediu clique real, graficos e detalhe por disparo.

O que mudou:

• SQL/rnt_push_envios_BK481.sql (idempotente): rnt_push_envios (1 linha por disparo) e

rnt_push_envio_itens (1 por aparelho: dispositivo, zonas no momento, resultado, codigo HTTP,

clique). Nao guarda endpoint nem chaves.

• /www/rnt-push-sender/send.php (fora do Git; backup ao lado): grava o disparo, os itens como

pendente ANTES do envio e o resultado depois; so marca concluido com os itens gravados por

inteiro (senao erro = historico incompleto). Qualquer falha dessa gravacao vai so para

/www/wwwlogs/rnt_push_audit.log - saida Enviadas: N e codigo de saida dos callers inalterados

(testado forcando erro). Novos --origem, --operador, --peca-id. Para cliente, acrescenta

envio_N ao utm_content (o admin de pecas ja poe o bairro ali) e manda o numero do envio no payload.

• sw.js: no toque, avisa push_action.php (act=clique) em paralelo com a abertura da pagina.
• push_action.php: act=clique so marca se aquele aparelho recebeu aquele envio (item aceito ou

pendente + endpoint da inscricao), 1o clique vale.

• admin/modulos/pecas/push.php: passa origem, peca e quem disparou.
• admin/modulos/campanhas/push.php (novo) + tb_menus #74 "Notificacoes Push" sob Campanhas:

KPIs, taxa de clique, filtro de periodo, grafico aceitas x cliques x visitas dos ultimos

disparos, crescimento semanal da base, aparelhos, zonas, visitas por campanha, funil do banner

(so Apple, com aviso), detalhe por disparo (aparelho, zona, logado, botao x texto, tempo ate o

clique) e aba de alertas internos so para perfil admin.

• /root/rnt-tools/push_backfill_log.php: importou 310 disparos do push_dispatch.log (5 ao publico,

305 alertas; 622 SUPRIMIDOS pulados; contagem ausente fica desconhecida). Liga campanha antiga por

data E peca. Idempotente.

Validado: php83 -l e node --check; disparo real sem inscritos e com 3 aparelhos (itens

pendente->ok, HTTP 201); clique: 5 cenarios no endpoint + **toque real no celular do ADMIN

(envio #1244, 11 s, "corpo")**; tela renderizada em 6 cenarios, JS inline ok, anonimo -> login.

Revisao do gpt-6-astra: 0 P1, 6 P2 - todos corrigidos (utm_content do bairro, clique durante o

envio, clique em item falho, campanha de outra peca no importador, totais cortados em 200, status

concluido antes dos itens). Pontas no BK-481b.

[2026-09-28] [BK-480] Push de admin nao e mais rebaixado para cliente quando a sessao cai

Achado: o push de teste do vigia do Divulg AI (BK-474) nao chegava ao ADMIN. O celular dele estava

inscrito como cliente: a re-sincronizacao silenciosa do js/rnt-push.js roda em toda pagina e o

push_action.php regravava tipo/admin_id pela sessao do momento. Sem a sessao do admin, a

inscricao do gestor virava cliente sem aviso - perdia os pushes de admin e passava a receber

divulgacao. Com o login do admin no celular, a mesma inscricao (#223) voltou a admin e o teste chegou.

O que mudou: no upsert do push_action.php, navegador que ja e admin segue admin quando a

requisicao vem sem sessao de admin (admin_id = COALESCE(novo, atual)); cliente segue cliente e a

promocao a admin continua pelo login. Consequencia aceita: voltar um navegador de admin para cliente

so corrigindo no banco. Inscricoes de admin hoje, todas do Jorge (admin_id 2): #223 Android, #54 Mac,

#272 Windows.

Validado: php83 -l; o SQL extraido do proprio arquivo em tabela temporaria, 7 casos (1a vez

cliente, promocao a admin, sessao caida, sem login, cliente estavel, 1a vez ja admin); POST real de

re-sincronizacao sem sessao em /push_action.php com a inscricao #223 -> {"ok":true} e continuou

admin (antes rebaixaria); push de teste recebido no celular do ADMIN.

[2026-09-27] [BK-479c] Botao "conferir" diz "sem mudanca" quando nada mudou

Pedido do ADMIN: o "conferir" Mercado Pago/PagSeguro da tela de Pedidos respondia "Status atualizado

de 3 para 3". Agora: "Status confirmado: Paga (sem mudança)" ou "Status atualizado de Aguardando

pagamento para Paga", com o nome do status. A gravacao nao mudou (continua o mesmo UPDATE).

admin/modulos/pedidos_2/conferir_{mercadopago,pagseguro}.php. Validado: php83 -l e php56 -l,

arquivos UTF-8, regra da mensagem testada nos 3 casos (igual, pago, cancelado).

[2026-09-27] [BK-479] Senha do banco fora do codigo; duas paginas a serviam para qualquer um

Pergunta do ADMIN: "senha do banco no codigo e perigoso? e um erro?" Sim. Medido: o usuario do

banco so entra de localhost e a 3306 esta fechada no ufw, entao a senha sozinha nao abre o banco

pela internet - o risco e quem le o repositorio e qualquer outro site da VPS comprometido.

Pior do que parecia: a senha estava em 20 arquivos versionados (a 1a contagem, 12, buscou o

nome do usuario, nao a senha) e dois caminhos a serviam em 200 a qualquer um:

admin/debug_env.php (imprimia a senha e print_r($_SERVER), sem nenhum chamador) e 2 .md de

docs/ (manual_usuario/GUIA_SYNC_BANCO.md, documentacao_tecnica/campanha_track/README_CAMPANHAS_V2.md).

Logs desde 02/04/2026: nenhum acesso externo a eles; de 10/12/2025 a 02/04/2026 nao ha log.

O que mudou:

• config/db_env.php (novo): leitor puro do .env, so chaves DB_*, sem fallback de senha,

sintaxe 5.6.

• 8 arquivos que conectam sozinhos trocaram SO o literal da senha por rnt_db_env('DB_PASS')

(usuario/host/nome intactos, por fidelidade): `admin/modulos/pedidos_2/{conferir_mercadopago,

conferir_pagseguro,sync_mercadopago_pendentes}.php, admin/modulos/campanhas/includes/db.php`,

img/cupom/data/config.php, painel_old/{seguranca.php,data/config.php},

PagSeguroLibrary/painel/seguranca.php.

• 2 .md mascarados. admin/debug_env.php e 16 copias mortas (.bkp, connect.php.bak_,

config_backup_*, geral/remote/path/...) movidos para /root/.rnt_security/bk479_quarentena/

(reversivel); os rastreados sairam do Git. Backups da rodada fora do webroot, de proposito: um

backup ao lado conteria a senha.

Validado: php83 -l e php56 -l nos 9 arquivos; harness sem imprimir segredo (leitor igual a

senha antiga, require resolvendo para config/db_env.php, literal ausente, constante DB_PASS do

cupom igual); conexao real pelo db.php de campanhas; open_basedir inclui a raiz; paginas

vazadas agora 404 / sem a senha. Fora do .env e dos backups dele (BK-459), nenhum arquivo do

webroot tem mais a senha. Endpoints do pedidos_2 nao executados (gravam) - teste do ADMIN no

BK-479b. Erro meu na rodada: uma sondagem HTTP em PagSeguroLibrary/painel/ bateu num FATAL

antigo e disparou 3 alertas ao gestor (conferir a regra do vhost em vez de sondar URL).

Continua valendo: a senha segue no historico do Git; so a troca (BK-375) resolve.

[2026-09-27] [BK-478b] Conferencia com o Mercado Pago a cada 10 min (so leitura)

Resposta a pergunta do ADMIN "se nao aprovar na hora, o sistema confere de novo?": nao conferia.

admin/cron/sync_mercadopago.php (cron /etc/cron.d/rnt-sync-mercadopago) pergunta ao MP pelos

pedidos com sessao a partir de hoje-7 e escreve no log o que diverge do banco. **Nao grava nem envia

nada.** Validado: php83 -l; --pedido=73950 confere; 8 pedidos cancelados conferidos um a um;

janela normal 7 pedidos e --janela=90 62 pedidos, 0 divergencias. Revisao do gpt-6-astra: 3 P2

corrigidos (status 6/7 incluidos, prioridade da tentativa aprovada entre todas, sem teto de 60); o

P1 (webhook sobrescreve pago com tentativa recusada atrasada) ficou no BK-478b como condicao para

liberar escrita.

[2026-09-27] [BK-478] Compra com cartao nunca avisava ninguem: avisos saem de um cron que le o banco

Sintoma: o verificador do BK-361 acusou o pedido #73950 (cartao, 2 ingressos, pago 15:35):

o comprador nao recebeu o WhatsApp de compra aprovada, e o dono tambem nao recebeu a "Nova venda".

Causa: os avisos saiam de dentro do webhook_mp_ingressos.php, e so na TRANSICAO de status

(status_antigo != 3/4). No cartao quem grava o pagamento e o action.php

(efetuacompra_cartao_mp), um segundo antes do webhook; o webhook chegava com o pedido ja pago e

pulava o bloco inteiro: WhatsApp ao comprador, WhatsApp + push "Nova venda" ao dono e

sales_webhook (receita para o ajuste de Ads). A conversao do BK-464 escapou porque ja ficava fora.

O PIX funcionava porque quem aprova e o webhook. Havia mais dois gravadores com o mesmo buraco: a

consulta de status do navegador (action.php) e a tela de Pedidos do admin

(pedidos_2/sync_mercadopago_pendentes.php).

Por que so apareceu agora: as duas vendas de cartao anteriores (#73908 de 31/08 e #73909 de

01/09) sairam como "sem celular" no verificador. O cliente tinha o numero so em clientes.telefone,

e o verificador (como o webhook) so olhava celular - a falha passou calada. Medido hoje: 15.993 de

51.084 clientes estao assim.

O que mudou:

• admin/cron/avisos_compra_aprovada.php (novo, /etc/cron.d/rnt-avisos-compra, 1 min, php83):

le o BANCO, nao o caminho. Pedido de Mercado Pago pago, com sessao a partir de hoje-7 (janela

pedida pelo ADMIN), vira uma linha por efeito na tabela nova rnt_avisos_compra

(UNIQUE(pedido_id, efeito, destinatario)), com claim por UPDATE (affected_rows=1) e flock.

Efeitos: wa_cliente, wa_dono (uma linha por numero), push_dono, sales_webhook e

alerta_mudanca (pedido que ja foi pago sai de pago -> WhatsApp so ao gestor 21 99991-5554,

sem janela de data, com ate 3 tentativas). Sem retry nos demais: repetir WhatsApp duplica.

Antes de enviar, procura o pedido no historico (#<id>); o que ja saiu vira enviado_previo.

Flags --dry-run, --test-send=<pedido>, --status, --instalar [--confirmo].

• includes/compra_aprovada_avisos.php (novo): regra de telefone (celular com prioridade,

telefone de reserva, como o BK-383) e textos do dono (copiado do webhook) e do alerta.

• webhook_mp_ingressos.php: bloco de avisos removido (UPDATE, carteira e conversao intactos).
• action.php: consulta de status tratava >= 3 como pago (inclusive 6 devolvida e 7 cancelada);

agora IN (3,4).

• admin/cron/verifica_wa_compra_aprovada.php: mesma regra de telefone e busca pela mensagem DO

pedido (#<id>*), nao so "alguma compra aprovada deste telefone".

• includes/whatsapp_helper.php: "E(Sao) 2 ingresso(s)" virou "E 1 ingresso" / "Sao *2

ingressos*" (pedido do ADMIN); o mesmo nas mensagens do dono e do alerta.

Implantacao: 132 pedidos pagos de MP com sessao de 180 a 8 dias atras semeados como legado

(nao recebem aviso, entram no alerta de estorno). Dentro da janela quem decidiu foi o historico: os

6 PIX (#73944-#73949) viraram enviado_previo; o #73950 mandou so o que faltava (dono, push,

sales_webhook - HTTP 200). A confirmacao da compradora do #73950 foi enviada a mao antes, as 16:02.

Validado: php83 -l nos 6 arquivos; webhook real do #73950 reenviado (JSON ok, conversao

ja_existia); 1a rodada real conferida pedido a pedido; 2a rodada e duas execucoes simultaneas nao

repetiram nada; --test-send ao gestor; mensagens com 1 e 2 ingressos renderizadas, pedido segue nos

ultimos 100 bytes (BK-412); monitor do MP pausado por arquivo e selado (--check OK).

Revisao do gpt-6-astra: desenho consultado antes (1 P1 de semeadura resolvido pela prova no

historico; 4 P2 absorvidos) e revisao final. O P1 que sobrou - nada consulta o MP sobre pedido

pendente - e anterior a esta rodada e virou o BK-478b. Os P2 restantes estao no BK-478c.

[2026-09-24] [BK-459] .env em 644 no deploy: fechado, e os 13 backups dele tambem

O ADMIN perguntou por que o monitor devolve o .env de 644 para 640 sem avisar, e se dava

para resolver. Dava — e a origem ja estava resolvida sem ninguem ter marcado.

O conserto ja existia desde 20/09/2026 17:15 (commit 0be70ae3d): o rsync ja excluia o

.env, o find . -type f -exec chmod 644 virou find . -type f ! -name '.env' ..., e o

/usr/local/libexec/rnt/publicar_env.sh cria o arquivo em 640 por temporario + rename, antes

de publicar. O backlog e que seguiu marcando ABERTO. Conclusao delimitada, na redacao sugerida

pelo gpt-6-astra: corrigido o caminho conhecido de publicacao insegura do .env; estado atual

640 www:www; ultimo autoheal em 21/09 17:17 e nenhum ate 24/09, com o cron rodando no intervalo.

Os 6 desvios historicos daquele dia nao podem ser atribuidos por arquivo — o log so guarda a

contagem. Essa limitacao virou o BK-459b.

O que o conserto de 20/09 deixou passar, achado hoje: o filtro ! -name '.env' nao casa com

os backups do arquivo. Havia 13 na raiz (.env.bkp_original_, .env_bkp_ e

.env.bkp_security_*), todos em 644, e o deploy os reabria a cada push. Conteudo conferido

arquivo a arquivo: os 13 tem DB_PASS e token do Mercado Pago preenchidos; um tem tambem

GA4_API_SECRET; nenhum tem META_CAPI_TOKEN. Nao vazavam pela web (404, conferido), mas

numa VPS multi-site qualquer usuario do sistema lia.

E um 14o arquivo, que nenhum filtro por .env jamais pegaria: private/rnt.env, em 644,

versionado no Git, com PAGBANK_TOKEN e PAGBANK_BRIDGE_API_KEY preenchidos. Tambem 404 na

web. A permissao foi fechada agora; a credencial estar no repositorio e outro problema, e depende

do ADMIN — BK-473.

Feito: os 13 backups e o private/rnt.env fechados para 640 www:www (zero ainda legiveis por

outros). No workflow, a normalizacao passou a excluir .env, .env.bkp, .env_bkp e

private/rnt.env — e nao .env.* generico, que excluiria tambem os tres .env.example

(modelos sem segredo, que devem seguir 644).

O -exec nao servia para isto. O gpt-6-astra reproduziu: com o comando interno falhando, o

SCRIPT_AFTER ainda terminava em exit 0, apesar do set -Eeuo pipefail — find -exec nao

propaga a falha. Entao o endurecimento virou laco explicito com || exit 1, e ganhou um passo

final que confere o resultado (-perm -004) e aborta o deploy se algum segredo tiver escapado.

Validado em sandbox, com a arvore reproduzida: .env, backups e private/rnt.env terminam 640;

.env.example, peca.php e arquivo em subpasta terminam 644; e, plantando um backup em 644

depois do hardening, o passo de conferencia detectou e abortaria. Mais yaml.safe_load e

bash -n no SCRIPT_AFTER extraido.

Por que o monitor cala, para ficar registrado: e decisao do BK-356. Permissao ele sabe

consertar sozinho, entao corrige e segue; desvio de hash continua alertando normalmente. O

problema nunca foi calar — foi calar sem registrar o que corrigiu, o que transformou uma causa

recorrente (deploy) em algo invisivel. Isso e o BK-459b.

Dois numeros meus que a revisao do gpt-6-astra derrubou, e que eu havia passado ao ADMIN:

• eu disse que o guard.log nao tinha rotacao. Tem, desde 18/09 (/etc/logrotate.d/rnt-mp-guard,

mensal, 12 arquivos, compress). Ainda nao ha arquivo rotacionado porque o corte e mensal;

• eu disse "401 autoheals". Nao existem 401: sao 153 linhas METADATA CORRIGIDA + 248

CHECK AUTOHEAL OK, duas categorias diferentes que eu somei num grep so, e que podem pertencer

a mesma execucao. E 153 tambem nao e o total historico (segunda correcao do astra, conferida):

essa linha so passou a existir em 26/08/2026, com o BK-356, enquanto CHECK AUTOHEAL OK

existe desde 07/04 — ha 133 dessas antes da primeira METADATA CORRIGIDA. O honesto e dizer

"153 linhas dessa categoria desde 26/08", sem converter em total de correcoes.

[2026-09-24] [BK-377] feedback pos-evento provado ponta a ponta, por evidencia de producao

O BK-377 pedia um teste de ponta a ponta. **Correcao importante, achada na revisao final do

gpt-6-astra: o teste da campanha 123 ACONTECEU — o ADMIN respondeu.** O texto anterior

deste changelog, e o de PENDENCIAS_ADMIN.md, diziam que ele nao tinha respondido. Errado:

| queue_id | telefone | resposta | quando | contexto |

|---|---|---|---|---|

| 9993 | ****5554 | msg 3444, texto 5 | 07/09 12:19:09 | ctx 1, concluida, estrelas=5, evento 23 |

| 9994 | ****9992 | msg 3449, texto 5, depois Nao | 07/09 12:51:42 | ctx 2, concluida, estrelas=5, evento 1593 |

O que ficou sem explicacao em 07/09: as duas conversas chegaram a etapa=concluida com

estrelas=5 gravadas em post_event_feedback_conversa, mas hoje **nao ha avaliacao do

cliente_id=775** em tb_avaliacoes. As avaliacoes de 07/09 (ids 4 a 11) sao de outros clientes,

do disparo do /root/g.sh.

Investigado depois, e a leitura mudou: provavelmente nao foi falha de gravacao.

save_comment() e chamado antes do INSERT do contexto e lanca RuntimeException se a query

falha — se tivesse falhado, o contexto nao existiria, e ele existe (ordem identica nas duas versoes

do helper daquele dia). E tb_avaliacoes esta com auto_increment=19 e ids 4..11 + 15..18:

faltam 1, 2, 3, que cairiam exatamente antes da avaliacao id=4, de 07/09 13:13. Compativel com

avaliacao de teste criada e depois apagada. Sem log de DELETE, nao e reconstituivel. Registrado

como BK-472, rebaixado de bug para ponta historica.

O que continua certo e o principal: o ADMIN respondeu, e o item passou 17 dias dizendo que nao.

A prova veio de outro lugar: clientes reais, em 16/09/2026. A campanha 136

(post_event_feedback_20260912) enviou 4 mensagens as 15:07-15:08 e a cadeia inteira

esta registrada no banco, item por item:

| queue_id | telefone | enviada | resposta | texto | contexto | avaliacao |

|---|---|---|---|---|---|---|

| 10363 | ****1309 | 15:07:25 | 15:09:43 | 5 | ctx 17, estrelas=5 | aval 17, nota 5 |

| 10365 | ****5834 | 15:08:58 | 15:09:27 | 4 | ctx 16, estrelas=4 | aval 16, nota 4 |

| 10366 | ****0659 | 15:08:59 | 18:29:20 | 2 | ctx 19, estrelas=2 | aval 18, nota 2 |

| 10364 | ****2445 | 15:07:26 | — | — | — | nao respondeu |

Cada elo confere: whatsapp_campaign_queue -> whatsapp_mensagens (enviada) ->

whatsapp_mensagens (recebida, com o numero em claro) -> post_event_feedback_conversa

(estrelas gravadas) -> tb_avaliacoes. Tres notas diferentes (5, 4 e 2), cada uma

batendo com o texto que o cliente mandou. Taxa de resposta 3 de 4.

Desenho revisado pelo gpt-6-astra antes de qualquer acao. Ele recusou aceitar as

tres avaliacoes como prova so por serem do mesmo dia do lote ("indicio, nao prova de

causalidade") e exigiu a cadeia com IDs e horarios — que e a tabela acima. Tambem

corrigiu um erro meu: eu tinha concluido que as notas 2 e 4 derrubavam a suspeita do

BK-450. Nao derrubam. Ler numero corretamente e inventar 5 quando nao ha numero sao

comportamentos independentes; o BK-450 tem aceite proprio (abaixo).

O que este item NAO prova, e fica registrado: a selecao automatica de publico. As

campanhas de feedback de 13/09 a 22/09 (ids 135, 137-139, 145-151) foram geradas e

aprovadas com inserted: 0. A hipotese e falta de publico: de 10/09 a 23/09 so houve

sessao com pedido pago em 12/09 (4 pagos), e setembro inteiro teve 17 pedidos / 10 pagos.

Hipotese, nao causa estabelecida — sem reconciliar elegivel por elegivel, inserted: 0

correto e inserted: 0 por bug sao indistinguiveis. Aceite separado, anotado no BK-452.

Limite de escopo, apontado pelo gpt-6-astra: o BK-377 original tambem cobria a

exibicao no PalcoFan (primeiro nome, evento fora de cartaz — ver a entrada de 07/09 sobre

o fluxo de 2 passos e a inversao do default de exibir_nome). A prova nova termina em

tb_avaliacoes: ela cobre envio -> resposta -> gravacao. As avaliacoes 16 e 17 estao

aprovado e a 18 segue pendente. **A exibicao publica dessas tres nao foi verificada nesta

rodada** — o que vale para ela sao as validacoes anteriores, nao esta.

Nenhuma mensagem foi enviada para fechar este item. O global_kill_switch continua

1, com updated_at de 18/09/2026 21:49 intacto.

[2026-09-24] [BK-450] confirmado por teste isolado: o parser nao inventa nota

O BK-450 ja estava entregue em 19/09, com testes de fluxo registrados naquela entrada.

O que faltava nao era toda a prova, e sim atualizar PENDENCIAS_ADMIN.md, que seguia

avisando o ADMIN que "qualquer resposta sem numero vira nota 5" — o que nao e mais verdade

desde 18/09. Este e um teste adicional, de unidade, sobre a funcao de parse.

rnt_post_event_feedback_extract_rating() foi exercitada isoladamente, **sem banco, sem

envio e sem gravacao**, em 25 entradas. Todas corretas:

• nota explicita: 5->5, 4->4, 2->2, 1->1, nota: 3->3, nota 4->4, 4/5->4,

4 estrelas->4, 5 - Excelente->5, cinco->5, minha nota e cinco->5

• sem nota, o caso do bug — otimo, adorei o espetaculo, muito bom!,

gostei muito, parabens, Nao, Zona Sul, vazio: todos 0, nenhum vira 5

• armadilhas: dou 2 ingressos->0, nao dou 5->0, nota 4/10->0, dia 4/5->0
• fora da escala: 0->0, 6->0, 10->0

O 0 significa "sem nota reconhecida". Nao significa que o sistema sempre volta a pedir

(ressalva do gpt-6-astra): ha filtros antes, silencio na reconciliacao e limite de tentativa

de aviso. O teste cobre a funcao de parse, nao a politica de repergunta.

Ressalva honesta: as tres avaliacoes de 16/09 sao anteriores a correcao de 18/09 e

todas continham numero explicito, entao elas nao exercitam o caminho do bug. Quem prova o

BK-450 e o teste isolado acima, nao elas.

[2026-09-24] Campanha 141 cancelada: 181 promocionais represadas ha 8 dias

lisa_prorrog_lote2_20260916 (prorrogacao de Lisa, Lesa & Louca) ficou com 181 linhas

pending desde 16/09, seguradas so pelo kill switch. Era **o unico lote que dispararia

sozinho** no instante em que a flag caisse: o dispatcher so despacha campanha approved

ou running (includes/whatsapp_campaign_queue.php:831), e ela estava running.

Recomendacao do gpt-6-astra, seguida: nao liberar como estava. Oito dias exigem

revalidar datas, preco, link, urgencia do texto e quem ja comprou ou pediu SAIR.

Antes de cancelar, o registro foi preservado: as 200 linhas (com message_body)

exportadas para /www/wwwlogs/rnt-campanhas-preservadas/campanha_141_saldo_20260924_171029.csv,

fora do webroot, modo 600. Cancelamento pela ferramenta oficial, mirando por ID e nao

por chave (campaign_key nao e unica — ver BK-461). Depois: 181 cancelled, 17 sent e

2 blocked preservadas, campanha cancelled.

A reversao e manual, e o CSV nao e backup integral (ressalva do gpt-6-astra, conferida):

resume so recupera linha paused, nao desfaz cancelled; e o CSV e um recorte de 8 colunas,

sem os demais metadados da fila nem o estado da campanha. Retomar essa promocao significa

campanha nova com publico e texto revalidados, preservando os 17 enviados e os 2 bloqueados.

Ganho colateral, medido as 17:15 de 24/09/2026: naquele instante, desligar o kill switch

nao dispararia nada. O que sobrava era 363 linhas de campanhas imported (sem approved_at,

o process devolve campaign_not_approved_for_real_send) e 307 paused da campanha 5, de

abril. A flag deixou de ser a unica coisa entre a fila e 181 clientes.

Isso e um inventario do instante, nao uma garantia futura (ressalva do gpt-6-astra): o

cron das 19:00/19:02 gera e aprova sozinho a campanha de feedback do dia. Havendo publico,

amanha existe fila aprovada de novo. Conferir a fila antes de afirmar silencio, sempre.

[2026-09-21] [BK-471] Add Peca com IA ja traz as sessoes da Sympla

Pedido do ADMIN depois de cadastrar a Labios que Beijei (peca 1634) a mao: "melhorar essa pagina

pra ja pegar as sessoes tbm". Desenho proposto pelo gpt-6-astra antes de implementar e revisado por

ele no fim (sem P1; os dois P2 foram corrigidos na mesma rodada).

Fonte. O endpoint publico event-page.svc.sympla.com.br/api/event-bff/purchase/event/<id>/tickets

devolve um grupo por apresentacao ("03/out - sabado, 19h") com os ingressos e o preco sem taxa

(netValueMonetary). O inicio da sessao e o endDate do ingresso, conferido contra o nome do grupo;

divergencia vira linha "Conferir". Link do Bileto nao e lido (outra API, exige chave).

Fluxo. add_ia.php mostra as sessoes no preview e guarda um rascunho separado na sessao PHP ->

o form da peca avisa -> ao salvar, action.php (cadastrar/editar) manda para

sessoes.php?id=X&ia_sessoes=1 -> o admin confirma inteira, promocional, associado e quantidade ->

act=importar_sessoes_ia grava. Arquivo novo: admin/modulos/pecas/add_ia_sessoes_lib.php.

Regras. Importacao so aditiva (nunca altera, remarca ou apaga sessao; pedidos.data casa

por datetime exato). Lista de sessoes vem da $_SESSION, nunca do POST. CSRF no import. GET_LOCK

por peca (a tab_sessoes e MyISAM sem indice unico). Preco da Sympla e so referencia. O rascunho

leva um token que o form da peca devolve, para a aba errada nao herdar as sessoes de outra; lote

parcial mantem as sugestoes nao marcadas.

Dois bugs corrigidos no caminho:

• criar_sessao/editar_sessao por dia da semana: o laco zerava $camp/$val com "" e voltava a

usar [] -- no PHP 8 e fatal a partir da segunda sessao (gravava 1 e quebrava). Fallout do

BK-348 ainda nao disparado: o debug.log nao tem criar_sessao desde 01/08.

• Abrir peca ativa pelo Add IA e salvar a desativava: o rascunho traz status = 'I' e o

detalhe.php aplicava. Agora o status do banco e mantido em peca existente.

Validado: php83 -l nos 5 arquivos; lib contra o banco real (10 sessoes da 1634, validacoes,

recusa de outra peca, reenvio sem duplicar, insert real numa peca inexistente 999999 com as linhas

apagadas em seguida, lote parcial e troca de aba); telas renderizadas logadas por CLI (preview,

rascunho gravado, detalhe mantendo Ativo, painel em sessoes.php). Nao validado ponta a ponta:

o POST de importar_sessoes_ia logado (teste do ADMIN no navegador). Pontas abertas no BK-471.

[2026-09-21] Dois incidentes causados por mim nesta rodada, e o que ficou corrigido

1. 33 alertas do monitor do Mercado Pago, madrugada inteira

O que aconteceu. Do commit do BK-464 em action.php (20/09 22:31) ate o selo de 21/09 12:05, o

monitor de integridade ficou em drift e mandou 33 alertas, a cada ~31 minutos, para 2 numeros de

WhatsApp mais push -- incluindo 02:15, 02:46, 03:17 da manha. Os drifts eram action.php,

webhook_mp_ingressos.php (os dois do BK-464/464b) e .env (as chaves do GA4 e da Meta).

Por que e grave. Nao por risco -- eram alteracoes minhas e autorizadas --, mas porque alerta de

seguranca que dispara 33 vezes por coisa conhecida ensina o gestor a ignorar o proximo. E eu

tinha construido a pausa do monitor (BK-455) exatamente para isso, horas antes, e nao usei. A

regra ja estava na memoria do projeto ("re-seal obrigatorio apos editar arquivo monitorado").

Verificacao antes de selar -- selar sem conferir anula o monitor:

• action.php e webhook_mp_ingressos.php identicos ao HEAD, vindos de tres commits do BK-464;
• zero drift ENV: o monitor confere o valor de cada credencial do MP por HMAC, separado do

hash do arquivo. Nenhuma credencial do Mercado Pago mudou;

• o conjunto de chaves do .env e identico ao que o deploy.yml escreve (38 chaves).

Selado as 12:05; o cron confirmou CHECK OK as 12:06.

2. 50 vendas historicas foram para a Meta com data de 20/09

O que aconteceu. No primeiro ciclo depois de o META_CAPI_TOKEN entrar no .env (21/09 01:08),

a CAPI mandou 50 compras reais de 04/06 a 12/09/2026, R$ 3.073, todas com event_time de

20/09/2026 22:30 -- um pico de vendas que nunca existiu.

Causa. A data do evento caia para recebido_em quando aprovado_em era nulo. recebido_em e

quando a reconciliacao criou a linha, e a cadeia nasceu em 20/09 -- entao toda conversao

historica tinha recebido_em de ontem. O guarda de 7 dias media a idade pelo mesmo campo e deu

zero dia. O cabecalho do arquivo dizia desde o comeco "nao envia conversao historica como se fosse

de hoje". Estava escrito e nao estava implementado.

Correcao (da57ab46b): data do evento = aprovado_em, senao pedidos.created; recebido_em

nunca. A semeadura da fila usava o mesmo campo e foi corrigida junto. A conversao que restava

(compra de 12/09) passou a ser recusada com evento_antigo. Nada saiu depois da correcao.

Nao da para desfazer -- a Meta nao apaga evento enviado. O dano pratico e limitado porque **nao

ha campanha ativa desde marco**, entao nenhum lance foi decidido em cima disso. Mas o conjunto de

dados 897210417852424 guarda o pico, e **ao voltar a anunciar, os primeiros dias de relatorio da

Meta vao mostrar 50 compras que nao vieram de anuncio nenhum**.

[2026-09-20] BK-461 etapa 1 — extrato auditavel de vendas, e o ROI antigo marcado como invalido

Desenho pedido ao gpt-6-astra antes de escrever codigo. Ele recomendou aposentar a procedure

como motor de calculo, nao corrigi-la -- e comecar pelo menor corte que ja elimina falsa precisao.

Foi o que entrou.

admin/modulos/campanhas/includes/margem_helper.php calcula o periodo direto de pedidos,

sem JOIN com eventos de navegacao, e com valor qtd -- porque pedidos.valor e o *preco

unitario**, nao o total do pedido (o metadados repete o mesmo numero em valor_unitario). Eu

mesmo tinha errado isso na primeira medicao: somar so valor deu R$ 384 onde havia R$ 752.

Com o imposto definido pelo ADMIN como incidente sobre a comissao, a tela mostra: pedidos,

ingressos, vendas brutas, ticket, comissao (20%), imposto (10% da comissao) e **contribuicao antes

do MP (18% da venda). Deixa escrito que vendas brutas nao sao receita do RNT** -- 80% e repasse.

O que nao da para saber sai como —, com o motivo na tela, nunca como zero: a taxa do Mercado

Pago nao e guardada em nenhuma coluna de pedidos (precisa vir do pagamento), e o custo de midia

nao e importado desde maio/2026 (GA4) e marco/2026 (Meta Ads). A tela lista a cobertura real de

cada fonte. Denominador zero devolve indefinido, nao zero.

O bloco antigo ganhou aviso em destaque: nao serve para decidir investimento, porque multiplica

receita no JOIN, compara investimento total com receita diaria e consolida por media de

percentuais. Ele continua visivel como historico.

Validacao: Sintaxe PHP ok nos dois arquivos; o helper conferido contra a medicao manual (365

dias: 198 pedidos, 397 ingressos, R$ 10.829,70 — identico); periodo sem venda devolvendo ticket

indefinido em vez de zero; e a tela renderizada com sessao simulada (37 KB, os quatro blocos

presentes, sem erro no HTML).

Segue no BK-461, com o desenho ja escrito: motor determinista publicando por execucao, atribuicao

persistida com um evento por pedido, separacao de data de criacao/pagamento/toque, tratamento dos

265 registros historicos (parte deles ficara com ROI permanentemente desconhecido), periodo

aplicado aos indicadores legados, leitura da view instalada e a falha de recalculo que hoje nao

impede a geracao de alertas.

[2026-09-20] Campanhas: dois endpoints sem login tirados do ar, e o mapa do que existe

Levantamento a pedido do ADMIN (anuncios automaticos e melhoria das telas de campanhas). O que foi

feito hoje; o resto virou BK-460 a BK-463.

Dois endpoints respondiam HTTP 200 sem login em admin/modulos/campanhas/:

debug_db_structure.php e update_db_schema.php. Eram restos de ambiente local (XAMPP), com

root/root escrito no codigo, e fatalavam com stack trace expondo o caminho absoluto do servidor.

O update_db_schema.php rodaria ALTER TABLE se a conexao tivesse funcionado — na VPS ela e

negada, entao nao houve DDL. Os dois foram para /www/rnt-quarantine/20260920-campanhas/ (nao

apagados) e agora respondem 404.

Medicoes que mudam as decisoes seguintes:

• ultimos 30 dias: 16 pedidos pagos, R$ 384,00, ticket R$ 24,00, em 2 pecas (de 8 com

parceria_online=1). A 20% de comissao, R$ 76,80 de margem bruta no mes antes de taxa e imposto;

• a importacao de metricas esta morta: GA4 parou em 20/05/2026 e Meta Ads em 31/03/2026. A

causa nao e bug de codigo — as quatro variaveis do Google estao MISSING no .env, porque o

deploy recria o arquivo a partir dos 36 Secrets e elas nao estao la (mesmo padrao que apagou as

credenciais da Cloud API em agosto);

• duas chaves privadas de service account estao versionadas no Git; o .gitignore cobre a

pasta campanhas_v2, nao a campanhas. O nginx nao as serve (404 — a allowlist do BK-376

esta aplicada e funcionando, ao contrario do que o PENDENCIAS_ADMIN.md ainda dizia);

• a conta de ROI de hoje esta errada, conferida por mim na procedure instalada: soma receita

sobre o JOIN com eventos (receita multiplicada), compara investimento TOTAL com receita diaria, e

o dashboard consolida com AVG(roi_percentual). Virou BK-461, e bloqueia o BK-460 — decidir

gasto por um ROI errado seria pior do que nao decidir.

Sobre a pergunta do acompanhamento de qualidade (historico de 30 dias, motivos de qualidade

baixa/media, qualidade do modelo): isso e metrica da WhatsApp Business Platform, que a Meta

calcula para quem usa a Cloud API. Nao usamos — nosso envio e o servico local. Nao existe hoje, e

nenhuma tela poderia mostrar: falta a fonte, nao a interface. Um painel interno de 30 dias e

possivel (tentativa, aceite, opt-out, falha, resposta, compra atribuida), mas sent na fila **nao

prova entrega nem leitura**, e blocked interno nao prova bloqueio pelo destinatario. Se for feito,

tem que se identificar como metrica interna, sem imitar a nota oficial da Meta.

[2026-09-20] BK-459 — o .env deixou de ser publicado em 644

Desenho do gpt-6-astra, pedido antes de escrever codigo. O ponto que mudou o plano: **excluir o

.env do rsync nao bastava**, porque o SCRIPT_AFTER roda find . -type f -exec chmod 644 no

que ja esta no servidor, tenha vindo no deploy ou nao. Eram duas fontes do 644, nao uma.

Publicador proprio, fora do webroot (/usr/local/libexec/rnt/publicar_env.sh, root:root 700):

• valida antes de publicar: 9 chaves obrigatorias com valor, minimo de 20 variaveis e **nenhuma

duplicada** — duplicada importa porque o consumidor (config/connect.php:16) fica com a

primeira ocorrencia, entao chave repetida publica um valor diferente do que se pensa ter

publicado. Nenhum valor e impresso em lugar nenhum, so nome de chave;

• dono e modo finais sao aplicados ao candidato ANTES de ele existir com o nome final, e a

publicacao e por rename no mesmo filesystem: o nome final sempre aponta para um arquivo

completo, o antigo ou o novo. Nada de sobrescrever o .env vivo in-place;

• guarda o .env anterior no cofre /www/rnt-secrets/ (fora do Git e do webroot, 600 root);
• confere no fim que o www le o arquivo publicado e que o modo e 640; se nao for, falha alto.

Modo de falha escolhido: qualquer validacao que falhe deixa o .env antigo valendo. Deploy

sem segredo novo e ruim; site sem segredo e pior.

No workflow (.github/workflows/deploy.yml):

• o .env deixou de nascer dentro da arvore do rsync: e montado em $RUNNER_TEMP/rnt.env com

umask 077 (36 linhas trocadas), e /.env/ entrou no EXCLUDE;

• o find de normalizacao passou a pular o .env, com chown www:www + chmod 640 explicitos

logo em seguida;

• passo novo depois do rsync e da correcao de permissoes: sobe o candidato por scp para

/www/rnt-secrets/incoming.env, poe 600 e chama o publicador. A chave de deploy e escrita com

umask 077 e apagada no fim.

Validacao (no servidor, com o publicador ja instalado): candidato incompleto recusado, com a

lista de chaves faltando; candidato com chave duplicada recusado; --dry-run aprovando o

.env real (36 variaveis, 9 obrigatorias); e publicacao real de uma copia fiel do .env atual

— hash identico antes e depois (60449b83…), www:www 640, backup criado no cofre e candidato

removido. bash -n no publicador e YAML do workflow conferido com parser, listando os 8 passos na

ordem certa.

O que so o proximo deploy prova: o caminho scp + ssh a partir do runner. Se falhar, falha

alto e o .env antigo continua no ar — mas fica registrado que esta parte nao pode ser testada

daqui.

Nao entrou, e segue no BK-459/BK-458: mover o .env para fora do webroot (/etc/rnt/) com grupo

proprio de leitores, e trocar a normalizacao recursiva por politica por classe de arquivo. Enquanto

o diretorio do projeto for gravavel pelo www, um .env ali pode ser substituido mesmo com dono

e modo corretos.

[2026-09-20] BK-458 etapa 1 — o monitor do MP saiu do webroot

Desenho pedido ao gpt-6-astra antes de escrever codigo. A frase dele que definiu tudo:

arquivo root:root dentro de diretorio gravavel pelo www nao satisfaz a fronteira — quem pode

escrever no diretorio substitui o arquivo. Entao chown root nos scripts seria conserto de

mentira.

O que mudou:

• a copia que o cron roda como root agora vive em

/usr/local/libexec/rnt/monitor_mercadopago_integrity.php (root:root 700, diretorio `root:root

755), fora do alcance do www. Conferido no fim da instalacao: www` nao le o arquivo e

nao escreve no diretorio;

• o repositorio continua sendo a fonte (versionada, revisavel). A promocao e ato deliberado:

/root/rnt-tools/instalar_monitor_mp.sh mostra hashes e diff, roda php83 -l antes, guarda a

versao anterior e troca por rename. Nada de sincronizar sozinho — copiar automaticamente o

arquivo vivo devolveria exatamente o problema que isto resolve;

• os subprocessos de envio largaram o root: rodam como www (sudo -n -u www) e recebem a

mensagem por STDIN. Antes eu passava por arquivo no storage do monitor, que e 0700 root —

abrir aquele diretorio para o filho seria furar a propria fronteira;

• RNT_MP_REPO_ROOT diz ao monitor instalado onde fica o projeto vigiado.

Dois defeitos que os testes acharam, os dois meus:

1. caminho de projeto errado virava alarme de invasao. Rodei a copia instalada sem a variavel:

o monitor deduziu /usr/local, nao achou nenhum arquivo monitorado e mandou *"10 alteracoes

detectadas"* — 2 alertas reais ao gestor por erro de operacao. Agora ele confere marcadores

do projeto (/admin/cron, /config/connect.php) e aborta com erro em vez de alertar;

1. o filho como www morria antes de enviar. O mp_guard_ensure_storage_dir() roda no inicio

e o www nao tem acesso a /root/.rnt_security — resultado: saida=1, sem envio. Os modos de

envio passaram a ser despachados antes de qualquer coisa que exija o storage.

Inventario que ficou pronto para as proximas etapas: das 19 rotinas que rodam como root a

partir do webroot, 17 nao tem necessidade aparente de root. So o watchdog_systemd.sh

(systemctl) e o verifica_wa_compra_aprovada.php (escreve em /root) precisam de tratamento

especifico; duas outras so escrevem log do painel bt. Detalhe e plano por familia no BK-458.

Validacao: Sintaxe PHP ok; bash -n no instalador; instalacao conferindo que www nao le nem

escreve; copia instalada rodando --check, --status e --heartbeat como o cron roda; execucao

sem a variavel abortando com saida 2 sem alertar; filho executado como www recusando

mensagem vazia sem enviar. Nao testei o envio real pelo fallback como www — seriam mais

mensagens ao gestor, e o canal que entrega de fato e o direto. Fica registrado como nao coberto.

Custo desta rodada: 2 alertas (total do dia: 10), os do defeito 1.

Etapa seguinte, ja desenhada e nao feita: BK-459 (publicar o .env sem janela, tirando o find

destrutivo do deploy) e a migracao das rotinas de negocio para www, uma primeiro e depois lotes.

[2026-09-20] BK-457c — ultima volta do monitor: 6 correcoes, incluindo uma regressao minha

Segunda verificacao do gpt-6-astra sobre o 95f3f3a36. Dos 9 pontos anteriores, **4 estavam

resolvidos, 3 parciais e 1 virou regressao minha**. Corrigidos:

1. Regressao [reproduzida por ele]: eu gravava last_attempt_failed_at antes do envio, e o

heartbeat lia qualquer valor ali como falha consumada. Com os dois crons se cruzando a cada 10

minutos, ele reproduziu o heartbeat acusando "alerta nao entregue" **no meio de um envio que

estava indo bem** — e isso ainda queimava a hora de cooldown dele. Agora existe

last_attempt_pendente_at: pendente recente e envio em andamento; pendente ha mais de 10 min e

resultado desconhecido (pode ter entregue e morrido antes de gravar), que e diferente de

falha comprovada. Testado nos dois cenarios;

1. die("texto") sai com codigo 0 no PHP — medido por ele e confirmado aqui. O subprocesso do

BK-457b lia isso como sucesso e registrava "repassado" sem envio nenhum. Agora o filho **imprime

MP_GUARD_ENVIO_OK depois de concluir, e o pai exige codigo 0 e** o marcador;

1. A baseline instalada nao tinha hmac_key_id (foi promovida as 07:41, antes de o campo

existir), entao a protecao do BK-457b simplesmente nao entrava: ele reproduziu chave trocada

devolvendo 5 falsos "credencial mudou". Baseline sem identidade agora bloqueia a comparacao

com mensagem propria, e a baseline viva foi reselada com o campo;

1. A gravacao da tentativa era ignorada: disco cheio ou erro de rename deixavam de novo a

tentativa sem registro. As duas gravacoes agora sao conferidas e reclamam no log e no stderr;

1. O estado era lido antes do lock, entao dois processos liam a mesma versao velha e o segundo

regravava por cima do primeiro. O --check agora rele o estado sob o lock, e --seal e

--migrar-v2 passaram a disputar o mesmo lock. Falha ao ABRIR o lock deixou de se disfarcar de

"outra execucao";

1. O --status nao enxergava o heartbeat.json. Separar o estado resolveu a disputa mas

escondeu tentativa, falha e ultimo aviso do heartbeat; voltaram para o status, junto da

tentativa em andamento.

Tambem: os timeouts do envio direto cairam para 10s/5s por numero. O astra somou os limites e viu

que uma rodada ruim passava de 115 segundos, mais que o intervalo do cron; agora o pior caso

cabe em ~80s, e o flock faz a rodada seguinte sair na hora em vez de empilhar.

Custo desta rodada: mais 2 alertas (total do dia: 8). Os dois foram legitimos — a baseline

estava mesmo sem identidade de chave — mas sairiam de qualquer jeito se eu tivesse reselado antes

de trocar a regra. Ordem errada minha.

Regra de parada combinada com o ADMIN, para a revisao nao virar loop: fecha quando nao sobrar

nenhum P1; o que for P2 vira BK. O astra sempre devolve lista, porque e isso que se pede a ele

— a evidencia de convergencia e a gravidade cair, e caiu: da primeira rodada (fila inteira

paralisada, credencial sem vigilancia) para esta (campos faltando no --status).

Abertos como BK em vez de entrar aqui: BK-458 (o cron roda como root arquivos que pertencem ao

www, entao escrita pelo lado web vira execucao root em ate 60s) e BK-459 (o deploy publica o

.env em 644 e o monitor conserta depois). Os dois saem do codigo do monitor e mexem em deploy e

em fronteira de privilegio.

[2026-09-20] BK-457b — nove achados do astra no BK-456/457, corrigidos no mesmo dia

Revisao final independente sobre o 9ab1b1707. Ele nao aprovou o fechamento, e tinha razao:

seis dos nove eram P1, todos reproduzidos por ele com dado sintetico antes de eu mexer.

1. HMAC indisponivel podia virar OK. A comparacao so acontecia com os dois HMACs

preenchidos — se o valores.key sumisse, o valor atual saia vazio e a credencial ficava **sem

vigilancia, com o monitor dizendo OK**. E se a chave fosse recriada sozinha, TODAS as

credenciais viravam "mudou de valor": alarme falso indistinguivel de invasao. Agora a baseline

guarda hmac_key_id; chave ausente ou trocada bloqueia a comparacao com mensagem propria,

e so --seal/--migrar-v2 podem criar chave. HMAC vazio de qualquer lado tambem virou desvio;

1. o fallback podia matar o monitor antes de ele registrar a falha. O envio acontecia antes da

gravacao do estado, e o bot_config.php faz die() sem BOT_WHATSAPP_API_KEY — com o stdout

do cron no lixo, nem a mensagem do die() aparecia. Agora a **tentativa e persistida antes do

envio, e o fallback (e o push) rodam em subprocesso** com timeout: se morrerem, morre so

o filho;

1. "entrega" incluia bloqueado e enfileirado. O fallback usava return_blocked_as_success e o

helper devolve true ate quando apenas enfileira. Isso limpava a falha e comprava 30 minutos de

silencio sem ninguem ter recebido nada. Agora so o canal proprio confirma entrega (HTTP 2xx

por numero); o fallback e registrado como "repassado" e nao carimba cooldown;

1. o heartbeat carimbava cooldown mesmo com todos os envios falhando — uma hora de silencio

justamente com o canal quebrado. Agora so entrega confirmada compra silencio;

1. os dois crons disputavam o state.json. Gravacao nao atomica e sem exclusao: um heartbeat

atrasado sobrescrevia o check com estado velho, apagando falha de entrega e cooldown. O

heartbeat ganhou estado proprio (heartbeat.json), o --check roda sob flock e toda

gravacao virou temporario + rename;

1. a migracao podia promover arquivo nao conferido. A segunda coleta comparava so o env e

salvava tambem os files novos: arquivo alterado entre as duas coletas entrava na baseline sem

passar pela conferencia. Agora compara os dois, exige HMAC das chaves exigidas e recusa sem

hmac_key_id;

1. eu tinha errado a regra de chave duplicada. Escrevi que "o PHP fica com a ultima" — para

ESTE consumidor e falso: o config/connect.php:16 so grava se a chave ainda nao existir, entao

a primeira ocorrencia vence. O monitor comparava um valor que a aplicacao nao usa. Corrigido

e provado em teste, com a logica do consumidor reproduzida lado a lado;

1. erro de leitura do .env desligava tambem a comparacao de arquivos (eu dava return):

quem tornasse o .env ilegivel ganhava ponto cego em todo o resto na mesma tacada. Agora pula

so as comparacoes de credencial;

1. legada presente e vazia nao era denunciada (MERCADOPAGO_ACCESS_TOKEN= passava batido),

porque eu testava present em vez de existe. Nao ativa credencial, mas viola a politica.

Validacao: Sintaxe PHP ok; os 6 cenarios de falha que ele reproduziu, agora passando (chave

HMAC sumida, chave trocada, HMAC vazio, legada vazia, .env ilegivel e .env ilegivel COM arquivo

adulterado junto — este ultimo provando que a comparacao de arquivo continua); duplicada conferida

contra a logica do connect.php lado a lado; despacho dos modos isolados recusando arquivo

inexistente sem tentar enviar; lock do --check recusando execucao simultanea (OCUPADO);

--status, --check e --heartbeat OK ao fim. Nenhuma mensagem enviada nestes testes.

Segue aberto no BK-456 o que ele listou como proximo passo e nao cabia aqui: comparacao semantica

do .env inteiro, permissao do .env ja no deploy, auditoria de quem escreve o codigo que o cron

roda como root, e agrupamento de eventos por ciclo. Ele tambem lembrou que o heartbeat nao

cobre erro de sintaxe no proprio script, falha do PHP nem parada do cron — para isso seria preciso

um vigia externo a esta maquina.

[2026-09-20] BK-456 e BK-457 — o monitor do MP passou a enxergar credencial e a saber avisar

Desenho pedido ao gpt-6-astra antes de escrever codigo, a pedido do ADMIN ("sempre com

analise do codex p nao ter mais retrabalho"). Duas premissas minhas cairam na analise dele:

reescrever bytes identicos nao muda o SHA-256 (entao o deploy so gera drift se o conteudo

mudar mesmo), e selar com o leitor novo e conferir com o mesmo leitor nao gera enxurrada.

BK-456 — ver a credencial, nao so o arquivo

• Leitor proprio do .env (mp_guard_ler_env_puro()): recebe caminho, devolve dado. Sem

putenv(), sem escrever em $_ENV/$_SERVER, sem require de aplicacao e sem banco. Nao da

para reaproveitar o mp_guard_parse_env_file() que ja existia: ele muda o ambiente inteiro **e

tira aspas, enquanto o carregador que a aplicacao usa (config/connect.php:7) preserva**.

Com valor entre aspas, os dois liam coisas diferentes do mesmo arquivo. A regra aqui e a do

consumidor. Incluir o connect.php estava fora de questao: ele abre banco com or die e isto

roda de minuto em minuto;

• ausente, vazia e erro de leitura sao tres estados diferentes. .env ilegivel vira um desvio

proprio e para a comparacao ali, senao um erro de permissao viraria 7 alertas de "credencial

sumiu". Chave duplicada tambem e desvio: escolher uma ocorrencia em silencio esconde

configuracao ambigua (o PHP fica com a ultima, quem le o arquivo costuma olhar a primeira);

• politica por chave em vez de lista solta. MERCADOPAGO_WEBHOOK_SECRET_PIX entrou (era

credencial de webhook sem vigilancia). As duas legadas nao sairam: viraram

esperada_ausente, porque checkout_pix.php:381 ainda as le como fallback — se aparecerem,

alguem pos credencial por fora, e isso alerta;

• painel/modulos/creditos/callback_mp.php entrou na lista de arquivos: consome o segredo do

webhook e estava de fora;

• HMAC-SHA-256 no lugar do SHA-256 puro nos valores, com chave exclusiva do monitor em

valores.key (0600), separada da baseline. Motivo concreto: BOT_WHATSAPP_NUMERO_ALERTA e um

telefone — hash simples de valor previsivel se quebra por tentativa. Sairam tambem length e

fingerprint: o alerta diz qual chave mudou, nunca um pedaco do valor;

• baseline v2 com migracao controlada. Baseline em versao antiga desliga a comparacao e

avisa, em vez de comparar errado. O --migrar-v2 recusa migrar se houver desvio de arquivo

pendente contra a v1 (migrar congelaria esse desvio como estado correto), mostra o estado de

cada chave sem exibir valor, exige --confirmo, rele o .env na promocao e aborta se algo

mudou no meio. A v1 fica preservada.

BK-457 — o monitor conseguir avisar

• canal de alerta independente. O caminho antigo passa por config/bot_config.php:337, que faz

die() se faltar BOT_WHATSAPP_API_KEY — ou seja, apagar essa chave **derrubava o aviso de que

ela foi apagada**. Agora existe alerta.conf (0600, fora do webroot, congelado por

--configurar-alerta) e envio por cURL direto, com timeout. O helper da aplicacao virou

fallback;

• tentativa, entrega e cooldown separados. O last_alert_at era carimbado mesmo com o envio

falhando, adiando a proxima tentativa em 30 minutos justamente quando o canal estava ruim. Agora

so entrega carimba cooldown; falha grava last_attempt_failed_at e a proxima passada tenta de novo;

• heartbeat em processo separado (--heartbeat, cron */10): alerta se a ultima execucao

passou de 15 min, se a baseline sumiu ou esta em versao velha, ou se o ultimo alerta nao foi

entregue, com cooldown proprio de 1h. Ele nao carimba ultima_execucao_at — se carimbasse,

manteria o marcador fresco sozinho e nunca perceberia o monitor parado;

• o cron parou de jogar a saida fora. Era >/dev/null 2>&1: erro do proprio monitor sumia.

Agora o stderr vai para /www/server/cron/rnt_mercadopago_guard.log (o OK de cada minuto

segue descartado, para o log nao crescer a toa);

• --status passou a mostrar versao da baseline, se o canal proprio existe, ha quanto tempo foi a

ultima execucao e se ha alerta nao entregue.

Validacao: Sintaxe PHP ok. 7 casos de comparacao por chave (valor trocado, credencial

sumida, credencial esvaziada, legada aparecendo, .env ilegivel, chave duplicada e caso sem

mudanca) e 10 verificacoes do leitor (aspas preservadas igual ao connect.php, vazio != ausente,

= dentro do valor, duplicada, espacos, CRLF, arquivo ausente, symlink recusado). Migracao rodada

de verdade: v1 -> v2 promovida com as 5 chaves exigidas SET e as 2 legadas AUSENTE, v1

preservada em baseline.json.bkp_v1_20260920-074158, --check seguinte OK. Heartbeat: detecta

"ultima execucao ha 60 min" e respeita o cooldown sem enviar.

Custo honesto desta rodada: 6 alertas de WhatsApp ao gestor. Quatro as 07:41, porque o cron de

minuto em minuto pegou a janela entre dois patches meus (snapshot ja v2, baseline ainda v1) — a

trava de versao que impede isso entrou logo depois. Dois as 07:44, num teste de heartbeat em que o

cenario nao montou e o alarme disparou de verdade; serviu de prova de ponta a ponta, mas foi erro

meu. Em ambos os casos o conteudo era alerta legitimo, nao mensagem de teste.

O que o astra apontou e NAO entrou (registrado para nao virar promessa esquecida): comparar o

.env inteiro semanticamente para distinguir "so formatacao mudou" de alteracao real; publicar o

.env ja com permissao correta no deploy, em vez de 644 seguido de correcao; auditar quem pode

escrever o codigo que o cron roda como root (nobody:nogroup em alguns caminhos); e agrupar

eventos por chave/fonte/tipo numa mensagem por ciclo.

[2026-09-20] BK-455b — a pausa do monitor MP podia calar o .env; corrigido no mesmo dia

Revisao final independente do gpt-6-astra sobre o commit 9d5b56913, com os achados conferidos

na fonte. O primeiro era grave e e por isso que a revisao existe:

[P1] A pausa podia esconder troca de credencial. A regra "ENV nunca e pausado" parecia

suficiente, mas os diffs ENV ... nunca acontecem — o monitor le credencial so do ambiente do

processo e o cron roda sem o .env, entao as 6 entradas ENV da baseline estao todas

present=NAO (virou BK-456, e e anterior a tudo isto). Com os diffs ENV mortos, o unico sinal

de .env alterado e FILE .env hash mudou — e a pausa aceitava silenciar esse. Agora o .env e

lista negra: nao e pausavel nem citado no escopo, nem por engano, nem de proposito.

Demais correcoes, todas reproduzidas por ele antes e conferidas por teste aqui depois:

• escopo virou obrigatorio. --somente=, --somente=,,, e --somente action.php (sem =)

produziam escopo vazio, que o codigo lia como "pausar tudo". Uma variavel vazia no comando

viraria suspensao geral silenciosa. Nao existe mais pausa geral; o escopo tem que citar

arquivo que esteja na lista monitorada;

• opcao em qualquer posicao. --motivo=x --pausar=60 nao pausava: o $argv[1] mandava, a

chamada caia no --check e podia disparar alerta em vez de pausar. E --pausar=60abc virava

60 calado. Agora --pausar e reconhecido em qualquer posicao e so aceita numero puro;

• a promessa de "alerta na proxima passada" era falsa. Preservar o last_alert_hash nao basta:

se o mesmo desvio ja tinha alertado antes da pausa, o cooldown de 1800s ainda valia. Ele

reproduziu: pausa vencida, mesmo hash alertado ha 6 minutos, nao envia. Agora a supressao grava

pausa_suprimiu no estado e o primeiro check sem pausa forca o alerta, ignorando o cooldown;

• --retomar dizia "cancelada" mesmo falhando, e a criacao ignorava o retorno da gravacao. Os

dois agora falham alto, com codigo de saida 1;

• gravacao atomica do pausa.json (temporario + rename): o cron roda de minuto em minuto e

podia ler o arquivo no meio da escrita, concluir que nao ha pausa e mandar justamente o alerta

que a pausa existia para evitar.

Validacao: Sintaxe PHP ok. 8 casos da regra de escopo, agora incluindo .env no escopo,

.env sem escopo e .env com outro escopo — os tres tem que alertar. **7 casos de linha de

comando**, todos recusados como esperado: .env no escopo, escopo vazio, escopo so com virgulas,

sem --somente, arquivo fora da lista monitorada e minutos com lixo; mais --motivo antes de

--pausar, que agora pausa em vez de cair no check. Monitor em OK e sem pausa ativa ao fim.

Ressalvas que ficam registradas, tambem dele: renovar a pausa repetidamente estende a suspensao

(o teto de 2h e por criacao); --seal nao cancela pausa; e alteracao maliciosa dentro do arquivo

pausado tambem nao alerta — se for revertida durante a pausa, resta so o log, e se for incorporada

por um --seal distraido, deixa de ser drift. **Por isso o --seal exige revisar os desvios

antes**, e isso entrou no guia.

[2026-09-20] BK-455 — monitor do Mercado Pago ganhou pausa com prazo (e nao desligamento)

Pedido do ADMIN nesta rodada: "qdo for mexer nesse tipo de coisa nao seria melhor desligar isso e

dps ligar p nao ficar gastando em vao msg via whatsapp?".

O gasto e real e maior do que parecia. A trava de 30 minutos do monitor so vale para o **mesmo

hash** (monitor_mercadopago_integrity.php:511: hash diferente = alerta imediato). Como o cron roda

de minuto em minuto, cada salvamento novo de um arquivo monitorado vira um alerta na hora. Medido

no banco: editando o includes/whatsapp_helper.php durante o BK-441, sairam 15 mensagens para os

dois numeros do gestor entre 01:48 e 01:59 de 20/09/2026.

Nao foi feito o que ele sugeriu ao pe da letra, e o motivo esta aqui: desligar e religar a mao

depende de lembrar de religar, e isto e o monitor do fluxo de pagamento — um desligamento

esquecido atravessa a sessao e ninguem percebe. O que entrou foi uma pausa que expira sozinha:

• --pausar=<minutos>, com teto de 2 horas. Passou do teto, o script corta para 120 e avisa;
• --somente=a.php,b.php limita a pausa aos arquivos que voce vai mexer. Sempre usar: sem

escopo, a pausa cala o hash de todos os monitorados;

• --motivo="BK-XXX" fica no log, para a pausa nao ser anonima;
• --retomar solta antes da hora; --status mostra ate quando a pausa vale, o escopo e o motivo.

A pausa nao e um desligamento, e a diferenca importa:

• ela continua conferindo e gravando todo desvio no log do guard, inclusive o que nao alerta;
• ela cala apenas desvio de hash de arquivo. ENV (credencial), dono, grupo e permissao alertam

do mesmo jeito — nenhum deles e efeito colateral de editar codigo, e o BK-356 ja custou 6 horas de

.env em 644. Arquivo que some tambem nao e pausado;

• ela nao toca no last_alert_hash, entao o desvio que continuar depois do prazo gera alerta na

primeira passada seguinte do cron. Pausa adia; nao apaga.

Validacao: Sintaxe PHP ok (php83 -l). 9 casos da regra de escopo, extraida do proprio arquivo

e exercitada fora dele: hash no escopo pausa; hash fora do escopo alerta; sem escopo pausa qualquer

hash; ENV mudando ou sumindo alerta; permissao e dono alertam; arquivo sumindo alerta; e

whatsapp_helper.php.bkp nao e confundido com whatsapp_helper.php por prefixo. Teste de ponta a

ponta em producao: pausa de 15 min com escopo no helper, drift real criado no arquivo, --check

devolveu DRIFT-PAUSADO, o log registrou o desvio com o hash e zero mensagens de WhatsApp

saíram no periodo (conferido em whatsapp_mensagens). O caminho de alerta nao foi disparado de

proposito, para nao gastar mensagem: e o mesmo caminho de antes, sem alteracao.

Fluxo novo documentado em docs/01_GUIA_MANUTENCAO.md: pausar com escopo antes de editar arquivo

monitorado, --seal ao terminar.

[2026-09-20] BK-441 — fila de recuperacao do WhatsApp: lock real, escrita atomica e id estavel

Fundacao da fila, na ordem recomendada pelo gpt-6-astra: antes de mexer em horario

(BK-451) ou em estado de envio (BK-454), a fila precisava parar de permitir duas drenagens ao

mesmo tempo e de gravar arquivo pela metade.

1. O lock que destravava a si mesmo. No bot/whatsapp/healthcheck.sh, o

trap 'rm -f "$LOCK_FILE"' EXIT era instalado antes da conferencia do lock. A execucao que

encontrava a trava ocupada saia por exit 0 — e o trap apagava a trava **de quem estava

rodando**. A execucao seguinte entrava junto. Reproduzido hoje com o backup do arquivo antigo:

com o dono do lock vivo, o codigo antigo deixa o arquivo de lock sem existir; o novo mantem.

Agora o lock e flock no descritor 9, mantido pelo processo inteiro; ninguem apaga arquivo para

destravar, e o kernel solta sozinho se o processo morrer. Some tambem o find -mmin +5 -delete,

que podia liberar processo vivo.

2. O processador PHP nao tinha lock nenhum. A trava existia so no bash, e

_whatsapp_processar_fila() (includes/whatsapp_helper.php) e chamado de mais lugares do que

parecia: pelo painel, e a cada envio bem-sucedido (:1377) e na recuperacao apos erro HTTP

(:1402). Os dois consumidores agora disputam o mesmo arquivo de lock

(bot/whatsapp/queue.lock, _whatsapp_fila_lock()), em modo nao-bloqueante: quem perde vai

embora, porque quem ganhou vai percorrer a fila inteira. O corpo da drenagem virou

_whatsapp_processar_fila_travada(), chamado sob try/finally, e o retorno ganhou

ignorada => true. A tela admin/modulos/bot/stats.php passa a dizer "a fila ja estava sendo

drenada por outro processo" em vez de exibir "0 processadas", que parecia fila travada.

3. Escrita atomica. O JSON era escrito direto no nome final, no enfileiramento e no

incremento de tentativa. Agora vai para um temporario exclusivo na mesma pasta e entra por

rename/mv -f. No bash, o temporario tinha nome fixo ($MSG_FILE.tmp), compartilhado por

duas drenagens simultaneas; virou mktemp. Isso tambem explica os 5 .json.tmp de 0 byte de

17/09: o shell cria o destino do > antes de rodar o jq, entao jq que falha deixa o

arquivo vazio para tras. Reproduzido em teste isolado (x.json.tmp (0 bytes)); o codigo novo

apaga o temporario e registra o erro no log.

4. Identidade estavel. O nome do item era time() . '_' . md5(numero . mensagem): duas

mensagens identicas para o mesmo numero no mesmo segundo geravam o mesmo nome, e uma

sobrescrevia a outra. Agora cada item nasce com id aleatorio (_whatsapp_fila_id(), com queda

para mt_rand() onde random_bytes() nao existe, porque o log_telemetry.php ainda e chamado

pelo php do PATH, que e 5.6), mais schema_version e criado_em em epoch — o timestamp

antigo nao tem fuso e o epoch e o que serve para contar validade no BK-451. Medido: dois

enfileiramentos identicos no mesmo segundo agora dao 2 itens; antes davam 1.

5. php -> /usr/bin/php83 nas duas chamadas ao log_telemetry.php no healthcheck.

6. Cinco achados do gpt-6-astra na revisao final, corrigidos antes do commit. O primeiro

era regressao minha:

• curl do envio sem --max-time (healthcheck.sh). Ja era assim antes, mas agora esse

curl roda segurando o lock da fila: um /send que aceita a conexao e nunca responde

paralisaria cron, painel e todo envio do PHP por tempo indefinido, e flock nao expira por

idade. Entraram --max-time 20 --connect-timeout 10 (os mesmos limites do lado PHP) e

timeout 30 nas duas chamadas ao bridge de telemetria, que tambem rodam dentro da secao

travada;

• mensagem que chega durante a drenagem esperava o cron. O consumidor trabalha sobre uma

fotografia da fila, e o disparo imediato da mensagem nova bate no lock ocupado e desiste --

entao ela so sairia ate 5 minutos depois. Os dois consumidores passaram a fazer **ate 3

passadas**, relistando a fila, com marcacao de item ja tentado para ninguem ser enviado duas

vezes na mesma rodada. Isso estreita a janela, nao fecha: sobra o intervalo entre a ultima

listagem e a liberacao do lock. Latencia aceita e documentada; garantia de envio imediato exige

sinalizacao, e isso e BK-451. O comentario que eu tinha escrito ("o outro vai processar a fila

inteira") estava errado e foi corrigido no codigo;

• erro ao abrir o lock virava "ja esta drenando". fopen() falhando devolvia o mesmo false

da contencao, entao o painel diria "aguarde" justamente quando ninguem esta drenando.

_whatsapp_fila_lock() agora separa ocupado de erro_abertura/erro_flock (usando o

$would_block do flock()), e o painel mostra erro pedindo para conferir a permissao do

queue.lock. Testado de verdade: como www, com o lock em 600 do root, da erro_abertura;

com dono www e 664, pega normal;

• falha no enfileiramento nao chegava ao chamador. _whatsapp_enfileirar() agora devolve

bool, e enviar_whatsapp() deixa de responder true quando a gravacao falhou (disco cheio,

permissao, JSON invalido) -- antes isso virava "mensagem que nao existe em lugar nenhum,

contada como enviada". O caso em que o enfileiramento da certo e o cron conta como enviado

continua aberto e e o BK-454;

• falha ao gravar a tentativa passava batido. No bash o mv ficava fora do if; no PHP o

retorno da escrita atomica era ignorado. Sem isso, um item podia repetir a mesma tentativa para

sempre, calado. Os dois agora conferem e registram no log.

Tambem por indicacao dele: os locks sao www:www 0664 em vez de 0666 (root escreve de qualquer

jeito e nao se abre o arquivo para outro usuario local), e o comentario sobre o flock foi

corrigido -- o lock e da descricao de arquivo aberta, entao **filho que herda o descritor segura o

lock junto**, e matar so o bash nao garante liberacao. E por isso que todo comando da secao

travada ganhou teto de tempo.

O que ele apontou e nao entrou aqui: o bk94_session e lido e reenviado pelo bash, mas o

consumidor PHP nao o encaminha (divergencia antiga, some quando o BK-451 unificar os

consumidores); e o id ainda nao vai como chave de idempotencia para a API, entao queda depois

da entrega e antes do unlink ainda reenvia.

Nao entrou nesta rodada, de proposito: janela de horario, validade/expiracao, vazao (BK-440) e

dedupe_key de intencao. Lock e dedup locais nao garantem entrega unica — se o transporte

envia e a resposta se perde, o retry continua ambiguo (bot/whatsapp/server.js nao usa chave de

idempotencia). E os dois "sucesso" no mesmo segundo de 17/09 seguem sem causa provada: o que

esta feito aqui fecha mecanismos capazes de duplicar, nao o episodio.

Os locks agora persistem em disco e entraram no .gitignore.

Validacao (repetida depois das correcoes acima): Sintaxe PHP ok (php83 -l no helper, no

stats.php e no log_telemetry.php), Sintaxe Shell ok (bash -n), git diff --check limpo. Testes com o servico conectado e a fila vazia: lock do healthcheck

ocupado -> segunda execucao sai sem apagar a trava alheia; lock da fila ocupado -> drenagem

pulada com aviso; rodada normal -> "Fila vazia"; incremento de tentativa em arquivo corrompido ->

item original preservado e nenhum .tmp deixado para tras. Os 2 itens de teste criados na fila

foram removidos antes de qualquer drenagem e nenhuma mensagem foi enviada (log do healthcheck

sem o numero de teste). Revisao final independente do gpt-6-astra.

[2026-09-19] BK-450 — feedback pos-evento nao inventa mais nota 5

rnt_post_event_feedback_extract_rating() devolvia 5 para texto vazio e para qualquer texto

sem digito, e pegava o primeiro 1-5 solto ("nota 10" virava 1). Como o contexto pendente vale

10 dias, a primeira mensagem da pessoa nesse periodo virava avaliacao, fosse "SAIR", "Zona

Sul" ou "quero ingresso". O "Nao consegui identificar sua nota" nunca disparava.

Estrago medido: das 21 notas recebidas pelo WhatsApp ate hoje, 1 estava errada: "Nao fui

😅🤭" virou 5 estrelas publicadas em "Cinderela Negra" (tb_avaliacoes.id=11). A correcao

nao altera avaliacao existente. Por decisao do ADMIN, a id=11 foi tirada do ar em 19/09/2026

03:09 (status aprovado -> rejeitado, o mesmo do botao do admin; backup da linha em

/www/rnt-backups/tb_avaliacoes_11_20260919-140914.json, com o nome no fuso PRC do php.ini).

A peca ficou sem nenhuma avaliacao aprovada.

• extrator devolve 0 sem nota explicita. Aceita: digito sozinho (e o que o voto da enquete manda),

os 5 rotulos antigos da enquete, "nota/avaliacao 4" em qualquer ponto, "4/5" so como resposta

inteira, "4 de 5"/"4 estrelas", "dou 4" so no fim da mensagem, por extenso ("cinco"), so

estrelas (inclusive ⭐️ com U+FE0F). Recusa qualquer "nao" ("nao dou 5", "nao e nota 5", "nao

fui"), outra escala ("nota 4/10", "nota 4 de 10"), data ("dia 4/5", "4 / 5 / 2026") e "dou 2

ingressos"/"dou 2, um para cada amigo". Na duvida, pede de novo;

• etapa 1 sem nota: SAIR e mensagem so de zonas ficam em silencio (o analyzer ja tratou); o resto

recebe o pedido de nota uma vez por item da fila. A marca e um UPDATE condicional

(last_error vira feedback_nota_invalida so se nao for feedback_received nem ela mesma), e so

responde quem gravou: duas mensagens juntas nao avisam duas vezes, e uma atrasada nao apaga a

nota que chegou antes;

• a reconciliacao do admin (source=admin_whatsapp_chat_reconcile), que reprocessa mensagens

antigas ao abrir o chat, nunca responde nem consome a marca;

• etapa 2: SAIR e mensagem so de zonas nao viram mais comentario publico. Na

rnt_post_event_feedback_so_zonas, toda palavra tem que ser de zona ou conectivo ("Zona Sul e

Norte", "Todas as zonas do Rio de Janeiro"); "Teatro no Centro, lindo" continua comentario.

Revisado duas vezes pelo gpt-6-astra, com os achados conferidos na fonte. O que ele achou e ja

existia antes virou BK-452. Validacao: Sintaxe PHP ok (php83 -l); 68 casos do extrator, 13 de

zonas e 11 do fluxo com banco e envio substituidos por stubs, todos passando; replay das 21 notas

reais pelo extrator final, com 1 divergencia, que e o proprio bug.

[2026-09-19] Lembrete e pedido de nota: uma vez por peca POR TEMPORADA

Regra do ADMIN: temporada e o mes/ano do pedido. Uma vez por cliente+peca+temporada. Se no

mes seguinte a pessoa fizer outro pedido e nao pagar, recebe outro lembrete. Se comprar e

assistir de novo numa nova temporada, recebe outro pedido de nota e comentario.

Lembrete (admin/cron/lembrete_pedido_pendente.php). O controle de repeticao era por

dia, e o pedido fica elegivel por 7 dias: o lembrete se repetia todo dia, sempre a

meia-noite (virada do dia). Em 60 dias, 5 clientes receberam 8 lembretes pela mesma peca.

• fases 1 e 2: bloqueia se houve envio com sucesso para o mesmo cliente+peca por um pedido

do mesmo mes/ano (pedidos.created, via pedido_id do log), ou qualquer tentativa hoje (falha

nao conta como recebido, mas nao martela o numero, e tambem so vale na mesma temporada). O

envio de uma fase bloqueia a outra na mesma temporada;

• fase 1 ganhou a guarda em memoria que a fase 2 ja tinha, e as duas agora usam

cliente+peca+mes/ano: dois pedidos da mesma temporada na mesma rodada geram uma tentativa so;

• --test-send termina antes da fase 2. Se todos os candidatos da fase 1 fossem pulados por

falta de valor promocional, o teste caia na fase 2 e enviava ao celular real do cliente;

• a hora e conferida de novo antes de cada envio: rodada que comeca 21:59 nao passa das 22h.

Pedido de nota (admin/cron/post_event_feedback_queue.php). Qualquer avaliacao da peca

bloqueava a pessoa para sempre. Agora so fica fora quem ja avaliou depois desta compra

(data_criacao >= pedidos.created) ou quem ja tem pedido de nota na fila (enviado ou ainda

pendente/pausado) por um pedido da mesma peca no mesmo mes/ano.

Avaliacao por temporada. tb_avaliacoes nao tem indice unico, mas os dois pontos que gravam

sobrescreviam a avaliacao existente. A nota do ano seguinte apagaria a anterior:

• WhatsApp (save_comment): atualiza so a avaliacao feita depois da compra da conversa (pelo

pedido_id do payload da fila); a de uma compra anterior fica intacta e a nova vira outra

linha. Testado contra o banco so com leitura: mesma compra -> UPDATE, compra posterior -> INSERT;

• site (includes/ajax_palcofan.php): atualiza so a avaliacao do mes corrente, pelo id. Antes

o UPDATE ia por cliente+item e, com duas temporadas, reescreveria as duas.

Revisado pelo gpt-6-astra em quatro passadas, com os achados conferidos na fonte. Os dois casos

de borda que dependem de a avaliacao saber de qual pedido veio viraram BK-453. Validacao:

Sintaxe PHP ok nos 4 arquivos. As queries do lembrete e do feedback foram executadas direto no banco sem erro (o script

do lembrete trata erro de SQL como "nenhum elegivel"). Audiencia do feedback nos ultimos 60 dias:

28 linhas antes, 19 depois, e as 9 que sairam ja tinham recebido o pedido de nota. --dry-run do

lembrete as 02:26: "fora da janela" e nenhum elegivel. Pela regra antiga havia 1: a mesma cliente

do caso das 00:00, que receberia outro lembrete as 10h.

[2026-09-18] Lembrete de pedido pendente so envia das 10h as 22h

Pedido do ADMIN: um lembrete ("Notamos que voce nao concluiu a compra...") chegou para uma

cliente as 00:00:08. O admin/cron/lembrete_pedido_pendente.php (BK-343) roda */5 o dia

inteiro e nao tinha nenhuma trava de horario. Nos 30 dias anteriores, **15 dos 23 lembretes

(65%) sairam entre 22h e 10h**, no maximo 1 por noite.

• nova lembrete_dentro_da_janela(): envia das 10:00 ate antes das 22:00, com fuso

America/Sao_Paulo explicito. O php.ini da VPS e PRC, e as 21:55 de Brasilia ele diria

08:55, que bloquearia o horario comercial;

• fora da janela, a rodada sai antes da query, sem enviar e sem gravar dedup (fases 1 e 2).

O pedido continua elegivel (a query cobre 7 dias) e sai na primeira rodada das 10h;

• --dry-run avisa que esta fora da janela e continua listando; --test-send continua (vai so

para o gestor); o cron em /etc/cron.d/rnt-lembrete-pedido-pendente nao mudou.

Conferido: nenhuma outra automacao manda WhatsApp a cliente de madrugada. Credito sai as 10:15,

feedback entre 19h e 22h, convite a produtor entre 9h e 18h, e verifica_wa_compra_aprovada so

avisa o gestor.

Validacao: Sintaxe PHP ok (php83 -l); a funcao testada em 00:00, 09:59, 10:00, 15:30, 21:59,

22:00 e 23:59, todos certos; --dry-run as 21:54 sem erro; rodada real das 22:00:01

registrou Fora da janela 10:00-22:00 -- nada enviado.

[2026-09-18] O "rsync externo NBi7" e o deploy do proprio projeto

Investigado a pedido do ADMIN, que disse nao mexer nesse sincronismo ha muito tempo. Por quase um

mes isto foi tratado como sync externo desconhecido — e decisoes reais sairam dessa leitura

errada, como mover segredo para fora do .env.

E o .github/workflows/deploy.yml ("Deploy para Producao"), que roda em push na main e

usa easingthemes/ssh-deploy@v5.0.0 com o secret SSH_PRIVATE_KEY. A chave teatro@NBi7 (RSA

4096, SHA256:W1J04J…) em /root/.ssh/authorized_keys e a contraparte desse secret; a privada

nao esta na VPS. Os runners do GitHub rodam no Azure, o que explica os IPs que pareciam

aleatorios. A ultima alteracao do workflow e de marco/2026, coerente com "nao mexo ha muito

tempo".

Cada sintoma tem uma linha que o explica:

| sintoma | causa |

|---|---|

| .env vira 644 | ARGS: --chmod=D755,F644 e find . -type f -exec chmod 644 \; (deploy.yml:106-108) |

| chown -R www:www . | SCRIPT_AFTER (deploy.yml:106) |

| edicao no .env nao persiste | o .env e recriado do zero a partir de 36 GitHub Secrets (deploy.yml:40-65); nao vem do Git |

| mtime novo sem mudar conteudo | -re.iLsfxCIvu e a string de capacidade de protocolo, nao flags do usuario — nao ha -t nem -c |

| codigo nao e revertido | vem do checkout do commit empurrado; se a origem ja tem a edicao, ela volta igual |

O que fechou o caso: o deploy de 17/09 23:45:36 rodou o commit 0fecd7cbd (23:45:32), e o

rsync tocou os arquivos as 23:46:31/23:46:40. O gpt-6-astra achou no audit o rename de

.env.615KOj para .env — troca de inode, ou seja, substituicao de verdade, nao so chmod.

Duas coisas que eu afirmei e estavam erradas:

• "um IP diferente por conexao": e um IP por execucao, com duas conexoes — a primeira faz o

rsync, a segunda roda o SCRIPT_AFTER. No par medido, as duas vieram de 20.220.110.153.

• "a cada ~11min": e por push na main, portanto em rajada — 27 ciclos em 17/09, 62

conexoes em 07/09, e dias inteiros sem nada.

A disputa de permissao nao e incidente: o deploy poe .env em 644 e o

monitor_mercadopago_integrity.php:602 devolve para 640 em ate um minuto, sem alertar, por

decisao explicita no codigo. Na web o .env esta bloqueado por duas regras independentes do

vhost, entao o 644 e exposicao local, nao HTTP.

Risco que permanece, e nao e invasao: a chave autentica como root e a linha em

authorized_keys nao tem restricao (command=, from=). Reduzir o privilegio desse deploy e

melhoria legitima. O astra deixou uma sequencia segura, caso um dia se queira cortar — o workflow

tambem compila o scraper, instala Composer/Node, recarrega PM2 e ajusta api/eventos/pecas.json,

entao cortar sem substituir essas funcoes quebraria o site.

Alerta pratico levantado na investigacao: a VPS estava **7 commits a frente do

origin/main**. Como o deploy publica o commit empurrado, re-executar o ultimo deploy

sobrescreveria o que so existe aqui. Conferir git status -sb antes de qualquer deploy.

[2026-09-18] Baseline do monitor MP re-selada, e o log dele ganhou rotacao

O monitor de integridade do Mercado Pago passou a alertar no WhatsApp a cada rodada com dois

drifts: webhook_mp_ingressos.php e includes/whatsapp_helper.php. Eram as minhas proprias

alteracoes desta madrugada — BK-431 (marcador de pedido de teste) e BK-438 (nao descartar mensagem

por falso negativo).

Conferido antes de selar, porque selar por cima e o jeito de o monitor perder o sentido: os

dois arquivos estao identicos ao HEAD do git (git diff --quiet HEAD limpo), o hash atual de cada

um bate exatamente com o hash "novo" que o alerta reportou, e a baseline anterior era de

11/09 20:46 — antes das edicoes. Drift autorizado, entao. Re-selada em 18/09 03:21; a

verificacao seguinte devolveu OK.

De passagem: o guard.log do monitor estava com 243.397 linhas / 15,2 MB, acumulando

desde 03/04/2026 sem rotacao nenhuma — o cron roda a cada minuto e grava uma linha por

verificacao, ~1.440 por dia. Criado /etc/logrotate.d/rnt-mp-guard: mensal, 12 copias,

comprimido, copytruncate (o monitor mantem o arquivo aberto). Retencao longa de proposito, por

ser a unica trilha de quando cada drift foi detectado.

Outro dado que ficou visivel no log: nas ultimas 20.000 linhas ha **2.620 registros de DRIFT com

alerta=suprimido**. Investigado logo em seguida — ver a entrada do rsync do NBi7 abaixo. Duas

coisas que eu havia dito aqui e corrijo: a frequencia nao e "a cada ~11min" (e em rajada, 27

ciclos ontem), e o sync nao re-sela o baseline do guard; essa conclusao ja constava como

errada no registro do projeto, e eu a repeti por descuido — quem re-selava era um hook local

(/root/cerebro/guard/postedit.sh).

[2026-09-18] BK-446 fechado: o CLI basta, sem tela no admin

Decisao do ADMIN em 18/09/2026, sobre a unica ponta que restava do BK-446: o acesso ao historico

de pedidos com peca removida fica so no CLI (/root/rnt-tools/pedidos_orfaos.php), sem tela

no admin. O gpt-6-astra defendia a tela; pesou o fato de serem 11 ids com **94% do valor

concentrado num unico evento de 2017**. Nao ha mais nada aberto neste BK.

[2026-09-18] As 3 pontas do BK-446: job nao para por DELETE, e R$ 18,5 mil sem tela (BK-446b)

(1) Os jobs de audio/video ficam como AUDITORIA, sem cascata — decidido contra a minha

inclinacao inicial, por uma razao que o gpt-6-astra apontou e eu confirmei na fonte: o

processamento continua depois da resposta HTTP (fastcgi_finish_request em

admin/modulos/campanhas/redes_sociais/texto_for_audio.php), entao mudar status no banco ou

apagar a linha nao interrompe nada. Cascata daria a ilusao de parar o job.

A protecao certa e recusar o INICIO. Os dois caminhos de geracao de video (redes_sociais.php) e

o de voz (voz_audio.php) usavam LEFT JOIN pecas e seguiam sem a peca, com o slug caindo para

peca-<id> e a geracao recriando arquivos/pecas/<id>/ — ressuscitando a pasta orfa de uma

peca recem-excluida. Agora recusam com mensagem clara. Os 12 jobs atuais tem peca existente, logo

a guarda e preventiva.

Correcao de contagem minha: eu escrevi "4 tabelas, 13 linhas". Sao **3 tabelas de job com 12

linhas; a quarta que eu contei, social_story_presets, e preset**, nao job.

(2) Encerrar o processamento onde a linha fica como auditoria — 3 correcoes feitas, 2 recusadas.

Feitas: rnt_post_event_feedback_conversa_ativa() passou a exigir INNER JOIN pecas (sem isso, a

proxima mensagem do cliente era capturada como feedback de peca fantasma); o SELECT de

admin/cron/palcofan_nota_pendente_alerta.php tambem (avisar o gestor sobre nota de peca

inexistente e ruido que ele nao pode resolver); e pending_approval entrou na limpeza de fila de

sync_facebook_events.php, que era o estado de 240 das 255 linhas — a limpeza nao alcancava

quase nada. 144 linhas serao canceladas no proximo run. Nos dois primeiros a exigencia e

EXISTIR, nao estar ativa: feedback depois do fim da temporada e legitimo.

A propria correcao criou um risco, que peguei antes de deixar valer. O upsert do planner revive

status so a partir de 'error', entao linha canceled nao voltava: a peca era prorrogada e o

post nunca mais saia, em silencio. Os 4 upserts passaram a reviver tambem canceled, **mas so

quando last_error = 'peca_inativa_ou_removida'** — o cancelamento automatico. Cancelamento

manual do gestor continua valendo. Provado em banco: a linha automatica voltou para

pending_approval com last_error limpo; a manual ficou canceled.

Recusadas com motivo: o astra pediu guarda em post_event_feedback_queue.php:82 e

whatsapp_campaign_queue.php:887. Nao apliquei porque o cenario nao pode ocorrer — feedback

exige pedido PAGO (status_transacao IN (3,4)) e peca com pedido nunca e apagavel, a guarda

recusa; e os orfaos historicos sao de ate nov/2025, fora da janela da fila, que e por data de

sessao. Guarda que nao pode disparar e codigo morto. Se a guarda de pedidos for afrouxada algum

dia, isto volta a valer. Ele corrigiu, com razao, uma premissa minha: a fila e identificavel

por peca, porque id_evento vai no source_payload_json

(post_event_feedback_queue.php:252) — mas a conclusao acima nao depende disso.

(3) Orfaos historicos: PRESERVAR, e o acesso passou a existir. Nao apagar e nao anular

id_evento: sao a unica pista do que foi vendido. So que "deixar e medir" era insuficiente,

porque esse dinheiro nao aparecia em tela nenhuma — produtor/fechamento.php:98 so consulta os

pedidos if ($peca) e admin/modulos/pecas/relatorios.php sai antes quando nao acha a peca.

Criado /root/rnt-tools/pedidos_orfaos.php, somente leitura (resumo, --detalhe,

--evento=<id>, --csv). Medido em 18/09/2026: 1.190 pedidos, R$ 34.802,40, dos quais

661 pagos = R$ 18.499,10. O detalhe encolhe o problema: esta em 11 ids, e **94% do valor

pago e de UM evento** — o 222, "Terapia do Riso - Especial 12 anos", 625 pedidos pagos,

R$ 17.479,90, sessoes de jun a dez/2017. Dois dos 11 sao evento de teste, com R$ 0. O nome sai de

pedidos.item (texto congelado na compra, com ate 4 grafias para o mesmo evento); produtor e

destino de repasse nao sao reconstruidos, seria suposicao.

Erro meu, corrigido: eu reportei "aprovados orfaos: 0". Era falso negativo — status_transacao

e codigo numerico (3 Paga, 4 Disponivel, 6 Devolvida, 7 Cancelada, conforme

getStatusTransacao() em painel_old/modulos/pedidos/bootstrap.php:37) e eu comparei com texto.

Arquivos: admin/cron/sync_facebook_events.php, includes/post_event_feedback_helper.php,

admin/cron/palcofan_nota_pendente_alerta.php,

admin/modulos/campanhas/redes_sociais.php, admin/modulos/campanhas/redes_sociais/voz_audio.php,

e o novo /root/rnt-tools/pedidos_orfaos.php.

[2026-09-18] Excluir peca passa a RECUSAR peca com acervo (BK-446)

O ADMIN deu o eixo que faltava: "a pagina da peca nunca morre". Quando a temporada acaba, o

site apaga a foto e a ficha tecnica (na proxima temporada o elenco pode ser outro) e a peca vira

evento.php com informacao basica — URL, SEO e comentarios ficam no ar, e a pagina serve de

convite para o produtor mandar a atualizacao. Isso ja funcionava e nao foi tocado

(admin/cron/cleanup_old_pecas_images.php apaga tb_fotos e os arquivos e preserva a peca).

Consequencia: o botao de excluir e para LIXO — duplicata, teste, erro do captador. E ele

estava aceitando apagar coisa que nao e lixo.

Achado que motivou a guarda. As 13 pecas criadas SO para pendurar o acervo do Facebook

(ids 1600-1612, BK-411/413 — so nome, slug, status='I' e zero pedidos) estavam **todas

apagaveis por um clique**. Entre elas a 1604, com comentario aprovado e visivel no PalcoFan, e a

1601/1604 com decidido_admin = 1, que e decisao final do ADMIN e que o registro do projeto diz

que nenhuma automacao pode desfazer. Pior: palcofan.php:48 usa JOIN pecas (inner), entao

guardar a linha do comentario nao o mantem no ar — apagar a peca o faz desaparecer em

silencio. No total, 16 pecas apagaveis carregavam 160 comentarios de arquivo.

Guarda nova (GUARDA): a exclusao e recusada — sem "excluir mesmo assim" — quando a peca tem

comentario de arquivo, avaliacao de espectador, link curto publico, linha no mapa de promocoes do

import do Facebook, ou vinculo em produtos. Falha de consulta tambem recusa (fail-closed): nao

afirmar ausencia de acervo sem ter conseguido olhar. Medido: de **326 pecas elegiveis, recusa 16 e

deixa 310 apagaveis. Visualizacao em cliente_tracking nao** bloqueia (seriam 69, e isso

tornaria o botao inutil), mas entra como aviso na resposta.

O astra defendeu recusar em vez de avisar, e convence: um aviso com confirmacao nao protege a

decisao do dono, permite viola-la em um clique.

Tres cascatas que eu escrevi e ele me fez REVERTER, com razao funcional que eu nao tinha visto.

Eu ia apagar a memoria do captador junto com a peca. Isso **faz o bot recriar o que acabou de ser

excluido** — autossabotagem, porque o botao serve justamente para apagar duplicata:

• bot_pecas_sugestoes e a memoria de decisao por URL (bot/handlers/event_matcher.php:33:

SELECT ... WHERE url_externa). Sem a linha, a proxima captacao trata o evento como inedito.

• bot_eventos_log e a barreira de dedup por hash (bot/handlers/deduplicator.php:34:

WHERE evento_hash). Apagar derruba a barreira.

• bot_valor_overrides e consultado por sugestao OU peca (event_matcher.php:1229), entao

apagar so por peca_id e incoerente.

Quarta reversao: o convite saiu da cascata. Apagar rnt_convite_parceria_log remove a trava de

25h por PRODUTOR e pode antecipar o convite de outra peca dele — e **restaurar a linha do backup

nao desfaz um WhatsApp enviado**. Manter a linha orfa nao quebra nada. Isso nao contradiz a ordem

do ADMIN de apagar o orfao da peca 1613: aquela foi limpeza pontual, ja feita, e a linha tinha 8

dias, fora da janela.

social_post_queue nao e apagada, e CANCELADA. Linha posted e registro do que foi publicado

em rede social e nao se reescreve; linha ainda executavel vira canceled, o que preserva o rastro

e impede que alguem aprove depois e gere post sobre peca inexistente. De passagem: o cron

sync_facebook_events.php:4395 ja cancela post de peca inativa/removida, mas **omite

pending_approval** — que e o estado de 240 das 255 linhas da fila.

Testes, todos com peca descartavel e conferencia independente:

• peca 244 (no mapa de promocoes) e as 1600/1604 (acervo): recusadas, citando a razao;
• guarda de produtos provada criando o vinculo, recusando, removendo o vinculo e apagando;
• memoria do bot (sugestao, log, override) e log de convite: sobrevivem a exclusao;
• social_post_queue: a pending_approval virou canceled e a posted ficou intacta;
• lixo sem acervo: continua apagando normalmente;
• ao final, acervo conferido intacto: 13 pecas, 4.837 comentarios, 118 linhas de mapa, e o maior

id de pedidos de volta em 73939.

O inventario completo das 26 tabelas e o destino de cada uma ficaram no BK-446, junto com tres

pontas abertas: os 4 social_*_jobs (cascata que exige interromper job e cobrir os arquivos no

backup), o encerramento de processamento nas tabelas mantidas como auditoria (dois casos medidos:

post_event_feedback_helper.php:418 e o pending_approval acima) e os orfaos historicos.

Arquivo: admin/modulos/eventos/action.php.

[2026-09-18] Revisao do gpt-6-astra sobre a exclusao de peca: 6 correcoes (BK-437e)

Pedi a ele para revisar o BK-437d/443 com o case 'deletar' completo e o trecho de dedup do cron

em recorte (sem mandar o CHANGELOG, que tem 8.000+ linhas). Ele achou defeitos reais, todos

conferidos na fonte antes de eu mexer:

1. Minha conclusao sobre o convite estava errada — e o erro era meu, nao dele. Eu escrevi que

a trava por produtor "nao depende" da linha apagada. Falso: a clausula e

l2.id_produtor = p.id_produtor AND l2.ultima_tentativa_em > NOW() - INTERVAL 25 HOUR, isto e,

qualquer linha recente daquele produtor bloqueia o convite de todas as pecas dele. Apagar

uma linha com menos de 25h pode antecipar o convite de outra peca do mesmo produtor. Para a

linha da 1613 que eu apaguei nao houve efeito (ela tinha 8 dias), mas o comentario no codigo

generalizava e estava errado. Corrigido tambem que a trava por peca exige

enviado = 1 OR tentativas >= CONVITE_MAX_TENTATIVAS, nao "qualquer registro".

2. As imagens eram destruidas antes da ultima recusa possivel — o achado mais grave. O

unlink acontecia ANTES da reconferencia de pedidos do BK-443 e ANTES do DELETE da peca. Se um

pedido aparecesse ali, a peca ficava, mas sem imagens — e o JSON guarda caminhos, nao bytes.

A recuperabilidade que eu tinha anunciado era falsa. Agora o passo e o ultimo e deixou de ser

destrutivo: a pasta inteira e movida para junto do backup com rename() (atomico, mesmo

filesystem, device 2049 conferido nos dois lados). Testado: com pedido presente as 3 imagens

sobrevivem intactas; sem pedido, vao para peca_<id>_<ts>_imagens/ com os bytes preservados.

3. O backup gravava cada valor DUAS vezes. fetch_array devolve MYSQL_BOTH, entao a peca

saia com 120 chaves para 60 colunas. Isso dobrava o arquivo e quebrava a restauracao: um

restore que percorre as chaves bate em Unknown column '0'. Descobri isso porque fui fazer a

prova que ele cobrou. Agora so as chaves nomeadas entram — 60 chaves, 5.203 -> 3.234 bytes.

4. A prova de recuperacao, que eu nao tinha feito. Conferir que o JSON "tem as secoes" nao

demonstra nada. Ciclo completo executado: peca criada -> excluida pelo action.php real ->

restaurada so a partir do material preservado -> comparada com o estado original. nome,

sinopse (com acento), status, contagem de sessoes, foto, convite e os bytes das duas imagens:

todos IGUAIS. Depois excluida de novo.

5. DELETE condicionado a uma fotografia antiga. As remocoes de foto e convite so rodavam se o

SELECT anterior tivesse achado linha. Linha inserida depois do SELECT ficava orfa e a resposta

dizia sucesso sem aviso. Agora o DELETE roda sempre e ha conferencia de que sobrou zero —

prova mais forte que contar linhas afetadas, e sem depender de affected_rows, que a classe Sql

nao expoe ($conx e privado). Cheguei a escrever $obj_sql->affected_rows(), que seria fatal

por metodo inexistente; peguei antes de seguir.

6. Backup: colisao de nome e conteudo bloqueante. O nome era peca + segundo, gravado sem

criacao exclusiva — duas exclusoes no mesmo segundo se sobrescreviam. Agora leva microsegundo,

usa fopen(..., 'xb') (falha se existir) e chmod 0640. E o conteudo do convite ia no mesmo

json_encode obrigatorio: um campo com UTF-8 invalido bloqueava a exclusao inteira, contradizendo

o "best-effort". Agora, se falhar, tenta de novo sem os dados do convite e registra o motivo.

Correcao factual que ele me fez: eu havia comentado que "sem transacao (MyISAM) nao ha como

travar". Falso — MyISAM aceita LOCK TABLES (testei: LOCK TABLES pecas WRITE e aceito, e

inclusive ficou esperando um SELECT longo soltar o read lock). Fechar a janela de verdade exige

coordenar esta tela com o webhook que INSERE o pedido, que hoje nao valida se a peca existe. Isso

e mudanca de arquitetura, nao de botao: BK-445.

Um ponto em que ele apontou e eu conferi que nao ha bug: $cnv_rs usado num if distante.

Esgotar o resultado no while nao transforma um result set valido em false. Ele mesmo concluiu

o mesmo.

Arquivo: admin/modulos/eventos/action.php.

[2026-09-18] Excluir peca reconfere pedidos duas vezes (BK-443)

Achado do gpt-6-astra: entre o COUNT dos pedidos e o DELETE existe uma janela em que uma

compra pode cair — um checkout iniciado antes da inativacao, cujo webhook chega no meio da

exclusao. Sem transacao nao ha como travar (pecas, pedidos, tab_sessoes e tb_fotos sao

todas MyISAM), mas da para estreitar a janela e escolher o dano menor:

• reconferencia 1, logo antes do primeiro DELETE: reduz a janela ao tempo de gravar o

backup. Se apareceu pedido, cancela sem apagar nada;

• reconferencia 2, logo antes de apagar a peca: se um pedido apareceu mesmo assim, a **peca

fica**. Pedido apontando para peca inexistente quebra fechamento financeiro e historico do

cliente; sessao e foto perdidas estao no backup e sao recuperaveis. Entre os dois danos, este

e o menor — e a resposta diz isso ao operador em vez de fingir sucesso.

Testado com peca descartavel: o caminho completo segue funcionando (peca 1623 excluida, sessao e

backup conferidos) e a peca com pedido e recusada com o pedido e as sessoes intactos. **A janela

concorrente em si nao foi simulada** — a recusa medida veio da guarda inicial, porque o pedido

ja existia quando a requisicao entrou; a reconferencia e identica em forma aquela guarda, o que e

semelhanca, nao prova.

O pedido de teste criado para esse ensaio (73940, conta de teste 50877) foi removido e conferido:

o maior id de pedidos voltou a ser 73939, o da tentativa real da Silvas. Cuidado herdado do

BK-412, em que um teste com transacao vazou pedido aprovado falso numa tabela MyISAM.

Arquivo: admin/modulos/eventos/action.php.

[2026-09-17] Excluir peca tambem limpa o log de convite de parceria (BK-437d)

A exclusao da peca 1613 (Silvas da assessora, cuja parceria acabou fechada na peca 1620)

deixou uma linha orfa em rnt_convite_parceria_log. Antes de apagar, a duvida certa era se esse

log funciona como travamento de reconvite — apagar poderia fazer a produtora receber convite de

novo. A conferencia em admin/cron/convite_parceria_produtor.php:140-158 mostrou que a

deduplicacao e dupla, e que as duas metades se comportam de formas diferentes:

• por peca_id: permanente, mas inutil quando a peca nao existe mais;
• por id_produtor: limitada a INTERVAL 25 HOUR, ou seja, expira sozinha.

A linha era de 10/09, oito dias fora da janela de 25h. Apagar nao liberava nada que nao

estivesse liberado — por isso foi seguro. Linha removida com backup em

scratchpad/orfaos_1613/rnt_convite_parceria_log_1613.json.

No codigo, case 'deletar' passa a incluir a tabela na cascata (o comentario do BK-437c dizia o

oposto, que era preservada de proposito; foi revertido por decisao do ADMIN). A diferenca

importante e que aqui a limpeza e best-effort e nao bloqueante, ao contrario de sessoes e

fotos: falha de leitura ou de DELETE nao cancela a exclusao, so avisa na resposta. A assimetria

e do dano — sessao orfa quebra venda, foto orfa deixa cartaz inalcancavel, linha orfa de convite

nao quebra nada. Acoplar o botao de excluir a uma tabela auxiliar criaria um modo de falha novo

em troca de nada.

Dois defeitos meus vieram junto, os dois achados por teste real (peca descartavel 1621/1622

criada, excluida pelo action.php de verdade via arnes CLI, e conferida por consulta

independente) — nenhum dos dois o php83 -l pegaria:

1. o diretorio de imagens nunca era removido, e a tela dizia sucesso. O caminho usava

dirname() TRES vezes, o que da .../admin — certo para admin/logs/, errado para

arquivos/, que fica na raiz do site. Procurava em admin/arquivos/pecas/<id>, que nunca

existiu; is_dir() dava false, o loop era pulado inteiro, e como $arquivos_sobraram so era

marcado DENTRO daquele if, a resposta declarava limpeza completa. Efeito: linha da foto

apagada e arquivos orfaos no disco — exatamente o que o BK-437c existia para evitar. Agora sao

quatro dirname(), e ha guarda nova: se arquivos/pecas (a pasta base) nao existe, o caminho

esta errado e isso e reportado em vez de virar silencio.

2. o backup morava dentro do webroot. .json e servido de proposito pelo vhost

(/api/eventos/pecas.json e export publico), entao admin/logs/pecas_excluidas/*.json ficava

legivel pela web para quem adivinhasse o nome — e o arquivo traz o telefone do produtor. Pior:

o rsync externo do NBi7 reescreve o webroot a cada ~11min, e este JSON e o UNICO rollback

possivel (todas as tabelas envolvidas sao MyISAM). Migrado para /www/rnt-backups/pecas_excluidas

(750, www:www), mesma convencao do /www/rnt-push-sender. Nao ha open_basedir no pool, e a

escrita como www foi testada.

Guardas reconferidas no mesmo teste, todas recusando sem apagar nada: id nao numerico

('123abc'), peca com status A, e id inexistente.

Arquivo: admin/modulos/eventos/action.php.

De passagem: as duas entradas anteriores estavam datadas 2026-09-18, efeito do

date.timezone=PRC do php.ini (o PHP ve 18/09 10:55 de Pequim quando aqui sao 17/09 23:55).

Os commits correspondentes sao de 17/09 21:25 e 23:45. Corrigidas.

[2026-09-17] Mensagem nao e mais descartada por falso negativo de destinatario (BK-438)

Em 17/09 a mensagem ao cliente 51222 (pedido 73939, Silvas) foi descartada as 20:00:45 com

Numero sem conta WhatsApp ativa (No LID), minutos depois do QR ser escaneado (~19:57). O

/check-number do proprio servico responde exists: true para o mesmo numero com a sessao

estavel. O cliente era alcancavel, e a mensagem foi jogada fora.

O que tornava isso permanente eram duas regras em includes/whatsapp_helper.php: qualquer HTTP

422, e o substring no lid independentemente do codigo HTTP. A segunda foi apontada pelo

gpt-6-astra — e importa, porque o false do precheck (bot/whatsapp/server.js:1209) sai como

HTTP 500, nao 422, entao trocar so o 422 nao resolveria nada.

• bot/whatsapp/server.js: grava bot/whatsapp/READY_SINCE no evento ready e apaga em

auth_failure e disconnected;

• includes/whatsapp_helper.php: novo _whatsapp_sessao_aquecendo(). Dentro de

RNT_WA_AQUECIMENTO_SEG (180s), "sem conta WhatsApp" passa a ser transitorio e a

mensagem nao e descartada. Sem a marca, o comportamento antigo e mantido — nao inventa

veredito a partir de ausencia de informacao.

Testado nos tres estados: sem marca -> null (mantem permanente); ready ha 0s -> true

(transitorio); ready ha 600s -> false (permanente vale). A marca foi restaurada ao estado

original depois do teste, e o servico nao foi reiniciado (a sessao esta conectada).

Ressalvas honestas:

• os 180s sao margem operacional, nao garantia. Nao existe N comprovado;
• a causa exata do falso negativo nao esta provada. O 422 medido nao veio do precheck — deve

ter vindo da resolucao de destinatario dentro do sendMessage(). O que esta provado e que o

veredito estava errado;

• tornar transitorio nao e reter. A mensagem ainda morre depois de 5 tentativas

(whatsapp_helper.php:909). Arquivar em vez de apagar continua no BK-438.

[2026-09-17] BK-437b/431d: correcoes da revisao do astra sobre o botao de excluir

Excluir evento (admin/modulos/eventos/action.php) — tres defeitos no que eu entreguei ontem:

• o backup podia passar vazio. A validacao era $gravou === false, e isso aceitava: o SELECT

das sessoes falhar (backup com sessoes: []), o json_encode devolver false (gravando string

vazia) e escrita parcial (0 !== false). Agora confere a consulta, a serializacao e se os

bytes gravados batem com o tamanho do JSON;

• os DELETE nao eram conferidos. Se apagar as sessoes falhasse, a peca era apagada de todo

jeito — deixando exatamente a sessao orfa que a guarda existe para evitar. Agora confere que

sobraram zero sessoes antes de apagar a peca, e **erro na conferencia final nao vira

sucesso** (antes, $conf_rs === false caia no ramo de sucesso);

• o (int) truncava o id. '123abc' virava 123 e apagaria a peca 123. Agora exige

ctype_digit e recusa formato invalido.

admin/js/deletar.js: a mensagem "A peca NAO foi excluida" no .fail() estava errada —

timeout ou JSON invalido podem acontecer depois de o servidor ter apagado. Passou a dizer que

nao foi possivel confirmar.

Marcador de teste no sales_webhook.php (BK-431d) — minha correcao de ontem nao funcionava,

e a medicao que a "provou" era invalida. O require config/connect.php estava dentro do

processSale(), entao $link/$conexao ficavam locais ao metodo, e o resolvedor do helper

procura globais. Eu tinha testado carregando o connect em escopo global — contexto que nao existe

no endpoint. Mesmo erro de metodo que o astra ja tinha me pegado no BK-431b.

Corrigido dando ao helper a capacidade de abrir a propria conexao como ultimo recurso, lendo o

.env, read-only e com falha aberta. Nao usei o connect.php de proposito: ele faz

or die(mysql_error()) (config/connect.php:93), o que colocaria texto fora do JSON e passaria a

exigir banco num endpoint que hoje so usa arquivo. Medido no contexto real do endpoint (so

facebook_ads.php carregado, sem globais): conexao resolvida, 50877 = true, 50220 = false.

[2026-09-17] Excluir evento no admin passa a funcionar, com guarda por pedido (BK-437)

O botao de excluir ja existia na listagem (admin/modulos/eventos/index.php:493, so para evento

inativo), o admin/js/deletar.js ja estava carregado e o case 'deletar' ja existia em

action.php:3548. Nada disso funcionava, por tres defeitos empilhados:

1. A condicao checava o dono errado. Era

WHERE id = X AND id_produtor = $id_produtor AND status = 'I', e $id_produtor no admin e

$login->GetId() — o id do admin logado, nao o produtor da peca. E codigo copiado do painel

do produtor sem adaptar. Como nunca casava, o admin recebia sempre

"Voce so pode excluir eventos pendentes de aprovacao!".

1. O JS mentia. Mostrava "Registro Deletado com sucesso!" e sumia com a linha no .done(),

sem olhar a resposta. Por isso o botao parecia nao funcionar em vez de mostrar a recusa.

1. O DELETE deixava orfao — tocava so pecas, e as sessoes ficavam penduradas.

O achado que mudou o desenho: a condicao quebrada estava, por acidente, evitando um estrago

maior. O botao aparece para toda peca inativa — sao 1.283, e 957 delas tem pedido.

Simplesmente "consertar o que estava errado" transformaria um botao inofensivo num destruidor de

historico de venda: pedidos.id_evento apontaria para peca inexistente, quebrando fechamento

financeiro e historico do cliente.

Por isso a guarda que entra no lugar e por pedido, nao por dono. Ressalva: a guarda

confere o COUNT antes do DELETE e nao ha trava — um pedido criado nesse intervalo nao e barrado

(config/functions_new.php:946 insere sem conferir a peca). Ver BK-443.

• evento precisa existir e estar inativo;
• zero pedidos, em qualquer status — e, se houver, a recusa diz quantos;
• backup das linhas (peca + sessoes) em admin/logs/pecas_excluidas/peca_<id>_<ts>.json antes

de apagar, e a exclusao e cancelada se o backup nao gravar;

• apaga tab_sessoes e depois pecas, confere que as sessoes sairam antes de apagar a peca,

e nao chama de sucesso quando a propria conferencia falha (corrigido no BK-437b).

Sem transacao, de proposito: pecas, tab_sessoes e pedidos sao todas MyISAM —

START TRANSACTION/ROLLBACK nao desfaz nada nelas. Foi a licao do BK-412, em que um ROLLBACK

deixou vazar um pedido aprovado falso. Em MyISAM o que protege e conferir antes e ter o backup.

O admin/js/deletar.js e compartilhado por 10+ modulos (teatros, categorias, pedidos,

newsletter, indexfotos...). Conferi que todos respondem com status = 'success', entao a correcao

vale para todos. Ressalva: sao 16 modulos que carregam o JS e 13 tem case 'deletar';

config e notificacoes carregam sem o case, e clubentpedidos tem botao sem action.php. E o JS

sozinho nao "conserta a mentira": varios handlers continuam declarando sucesso sem conferir o

DELETE (ex.: admin/modulos/categorias/action.php:57). Ver BK-444.

Simulacao das guardas: peca 1613 (inativa, 0 pedidos) -> apaga com 3 sessoes; peca 1620 (ativa) ->

recusa; peca 17 (inativa, 63 pedidos) -> recusa dizendo quantos.

[2026-09-17] BK-421b/431c: dois defeitos que a revisao final do astra achou

1. admin/modulos/bot/stats.php:263 — eu furei a propria protecao que tinha criado.

Ao dar $forcar = true nos "caminhos manuais" do BK-421, incluí esse — mas ele nao e o botao de

reiniciar, e a acao "processar fila". Com o servico em qr_pending, a saude devolve offline e

esse caminho reiniciaria o servico, **gerando um QR novo e invalidando o que o operador esta

tentando escanear** — exatamente o que o BK-420 existia para impedir. Voltou ao comportamento

automatico. Agora so dois caminhos forcam, e os dois sao o botao explicito de reiniciar

(admin/whatsapp_restart.php:56 e stats.php:205).

2. admin/modulos/campanhas/api/sales_webhook.php — o marcador de teste continuava inerte la.

O BK-431b corrigiu 3 dos 4 contextos sem conexao; este ficou. O endpoint e uma chamada HTTP

independente e o bootstrap dele so carrega facebook_ads.php, que nao abre banco. Medido:

```

conexao=NENHUMA rnt_pedido_e_teste(50877)=false

```

Ou seja, **venda de conta de teste continuava entrando no log de vendas e no gatilho de orcamento

de anuncio**. Passou a carregar config/connect.php. Depois: conexao=achou, 50877=true,

50220=false.

Correcao de um exemplo meu: eu escrevi que '1.5:30' dava 5400 no 5.6. Errado — 5.400 e so a

parcela das horas; o total (horas + minutos) e 7.200. A conclusao nao muda (o (float) e

que reproduz o 5.6, o (int) nao), mas o numero que eu citei estava errado.

[2026-09-17] BK-423b: a blindagem usava (int) onde o 5.6 usava float

Erro meu, achado por teste proprio ao preparar a revisao final. Eu tinha declarado a blindagem do

BK-423 "identica byte a byte ao 5.6" — e era, nos formatos que eu testei ('', '00:00',

'01:00', '02:00, 01:00', '0:30'). Ampliando o corpus, apareceu a diferenca:

```

'1.5:30' 5.6: h*3600 = 5400 com (int): 3600

'0x10:00' 5.6: h*3600 = 57600 com (int): 0

```

O 5.6 multiplicava a string direto, com semantica de float: '1.5' * 3600 = 5400. Meu

(int)'1.5' trunca para 1. Trocado para (float) nos 24 pontos (12 locais x 2 linhas) dos 11

arquivos. Com (float) a saida volta a bater com o 5.6 em todos os formatos testados.

Menos um, que nao tem conserto: '0x10'. O PHP 5 interpretava string hexadecimal em contexto

numerico; o PHP 7 removeu isso da linguagem. Nenhum cast traz de volta — a diferenca e da versao,

nao da blindagem. Dado assim nao existe na base (pecas.tempo_antes de peca ativa so tem

'02:00, 01:00', '01:00', '' e '00:00').

A licao: "identico byte a byte" so vale para o corpus que foi testado. Eu afirmei equivalencia

geral a partir de 5 formatos bem-comportados.

Validado: php83 -l e php56 -l limpos nos 11; home, /silvas, /pe-de-cachimbo,

/lisa-lesa-e-louca e /eventos.php em 200; act=entradas respondendo; zero erro novo no log.

[2026-09-17] BK-432 (parte 1): 4 automacoes saem do PHP 5.6

Migradas, com o metodo que o gpt-6-astra recomendou — e a correcao que ele fez ao meu plano:

em vez de require config/connect.php (que abre uma segunda conexao, sobrescreve $link/$conexao

e troca o charset), basta mysqli_report(MYSQLI_REPORT_OFF) antes do bootstrap. No 8.3 o padrao

do mysqli e lancar excecao, e @ nao suprime excecao: sem isso, todo if (!$result) desses

scripts viraria codigo morto.

| Script | O que precisou | Como provei |

|---|---|---|

| atualizar_feed.php | nada no codigo | rodado pelo wrapper real; os 4 arquivos regerados |

| admin/cron/sync_social_metrics.php | mysqli_report(OFF) antes do setup.php, que abre a conexao antes do connect.php | rodado no 8.3, exit 0, zero deprecation |

| api/eventos/gerar_json.php | mysqli_report(OFF) + guarda nos 2 num_rows() + error_reporting | JSON byte a byte identico ao do 5.6 |

| admin/cron/analisar_roi_campanhas.php | mysqli_report(OFF) antes do new mysqli | saida identica a do 5.6 (44 campanhas, 41 ativas, R$ 70,00) |

Detalhes que valem registro:

• gerar_json.php: Sql::num_rows(false) cai no $this->last_query e chega a

mysqli_num_rows() com algo que nao e resultado. Medi no 5.6: devolve NULL, e NULL > 0 e

false — o bloco era pulado. No 8.3 seria TypeError. O if ($result && ...) reproduz o 5.6.

• gerar_json.php: as 13 chamadas a utf8_encode() (deprecated desde o 8.2) cuspiam

1.417 linhas de Deprecated por rodada, a cada 2h. Silenciei a categoria, como

z_dispara_pagamento.php:2 ja faz. Trocar o utf8_encode de verdade e outro trabalho — ha

conversao possivelmente duplicada preexistente.

• atualizar_feed.php: os arquivos gerados MUDAM, e e conserto. O PHP 5.6 tem tzdata 2016.10

e ainda acredita no horario de verao brasileiro, extinto em 2019 — a partir de 18/10/2026 ele

emitia -02:00 onde o certo e -03:00. O 8.3 tem tzdata 2024.2. Sao 10 sessoes futuras de peca

ativa na faixa afetada. Isso vale para qualquer script em 5.6 que formate data futura.

• armadilha silenciosa conferida e nao disparada hoje: atualizar_feed.php:210 usa

$row['oferta'] > 0, e 'abc' > 0 e false no 5.6 e true no 8.3. Na base real, pecas.oferta

de peca ativa so tem NULL, '', '63%' e '70%'.

/root/v83.sh s estava mentindo, e o erro era meu. O detector que eu adicionei no BK-417

procurava o caminho explicito /www/server/php/56/bin/php — mas /usr/bin/php e /bin/php sao

symlink para o 5.6, entao wrapper nenhum precisa citar o 5.6. Ele dizia cron bt .. PHP 8.3

com 4 scripts ainda no 5.6 — o mesmo tipo de ponto cego que eu tinha criticado no proprio v83.sh.

Reescrito com a logica invertida: wrapper que invoca script do RNT e nao usa binario 8.3

explicito esta em 5.6. Agora acusa os 6 que faltam.

Nao migrados, e por que: z_dispara_pagamento.php e z_dispara.php (decisao de produto — ver

abaixo), sync_facebook_events.php (posta em publico; precisa de forma de validar sem postar) e

report_monthly.php (bloqueado: 7 arquivos do vendor/tecnickcom/tcpdf nao compilam no 8.3).

[2026-09-17] Destaques do fim de semana voltam a ser postados (BK-419)

admin/cron/post_highlights.php pedia inc-config.php e inc-conexao.php, que **nao existem no

projeto. Resultado: PHP Fatal error em 49 execucoes seguidas**, com o wrapper do painel bt

imprimindo ★ Successful logo abaixo — ele nao olha o codigo de saida do PHP. O RNT ficou meses

sem postar destaque automatico no Facebook e no Instagram e ninguem viu.

• carga corrigida na mesma ordem do cron irmao que funciona (sync_facebook_events.php:15-16):

admin/data/setup.php traz a classe Sql que o FacebookEventService.php:29 instancia, e

config/connect.php publica o $link

• novo --dry-run: o script publica em rede social publica assim que roda, e **nao havia como

testar sem postar**. Agora ele escolhe as pecas, monta o texto, resolve a imagem e para antes de

publicar, imprimindo o que sairia. A guarda fica antes das tres chamadas de publicacao

(createFeedPost, createInstagramMedia, publishInstagramMedia)

• UTM duplicado corrigido: duas linhas seguidas acrescentavam os mesmos tres parametros, a

primeira com weekend_highlights fixo e a segunda com o nome que varia por dia da semana. Todo

link saia com utm_source, utm_medium e utm_campaign repetidos. So apareceu porque o

--dry-run deixou ler o texto antes de publicar

• wrapper do cron passou de /www/server/php/56/bin/php para o 8.3 (era um dos 9 do BK-432);

backup em /root/rnt-tools/backups/cron/

Nao ha risco de enxurrada ao religar: o script e sem estado. Cada execucao consulta sessoes dos

proximos 4 dias (ORDER BY RAND() LIMIT 4, so peca com status = 'A') e monta um post. Nao

existe fila acumulada dos meses parados.

Validado com --dry-run no 8.3: post montado com 4 pecas em cartaz, imagem resolvida, links com

UTM unico. Nada foi publicado.

Aprendizado, que vale para as outras tarefas de /www/server/cron/: o ★ Successful do

wrapper do painel bt nao prova nada — ele imprime isso incondicionalmente depois do PHP, sem

olhar o codigo de saida. Foi isso que escondeu 49 fatais seguidos aqui, e o mesmo padrao apareceu

no z_dispara_pagamento.php, que falha calado a cada minuto. **Conferir sempre o log da propria

automacao. Proxima execucao real: 21/09 as 06:04** (o cron roda dias

1, 5, 9, 13, 17, 21, 25 e 29).

[2026-09-17] BK-431b: o marcador de teste era INERTE em 4 dos 6 consumidores

Revisao do gpt-6-astra sobre o 326350c5e, confirmada testando o bootstrap de cada consumidor:

rnt_clientes_teste_ids() procurava so $GLOBALS['conexao'] e $GLOBALS['link']. Dos seis,

apenas z_dispara_pagamento.php publica essas globais (via config/connect.php). Os outros:

• lembrete e lista do produtor usam a classe Sql, que guarda a conexao em $this->conx (privada);
• o feedback usa um $db local devolvido por rnt_wa_campaign_db();
• o webhook de campanhas e uma chamada HTTP independente.

Nesses quatro a lista voltava vazia, o fragmento SQL saia string vazia e o filtro **nao

filtrava nada** — em silencio, porque a falha aberta e justamente nao mudar o SQL. Medido:

```

connect ids=[50877] filtro=ativo

admin ids=[] filtro=VAZIO (nao filtra!)

produtor ids=[] filtro=VAZIO (nao filtra!)

campanha ids=[] filtro=VAZIO (nao filtra!)

```

Meu erro de validacao: eu provei o filtro executando o SQL numa conexao que eu mesmo tinha

aberto no script de teste. Isso valida o fragmento, nao o consumidor. A prova certa e carregar o

bootstrap de cada um e perguntar ao helper se ele acha a conexao.

Corrigido:

• novo rnt_pedido_teste_conexao(): tenta as globais, depois rnt_mysql_link() — o resolvedor

do proprio shim do BK-348 (config/mysql_compat.php:38), que guarda o link aberto pelo

mysql_connect() da classe Sql — e por fim rnt_wa_campaign_db(). Os quatro contextos passaram

a resolver

• NULL preservado: NULL NOT IN (50877) nao e verdadeiro, entao pedido com cliente_id

NULL sumia do resultado. Em consulta com LEFT JOIN (a lista do produtor) isso mudava

comportamento para pedido legitimo. Agora o fragmento e

AND (p.cliente_id IS NULL OR p.cliente_id NOT IN (...))

• try/catch: mysqli em modo estrito lanca excecao e @ nao suprime excecao no PHP 8
• validacao estrita do CSV: ctype_digit, porque o (int) cru aceitava '50877abc' como 50877

Validado: 4/4 contextos com filtro ativo, os 36 pedidos da conta de teste ainda excluidos, e

pedidos com cliente_id NULL preservados.

[2026-09-17] BK-423 (complemento): z_dispara.php tambem blindado

A auditoria do BK-432 achou um buraco na entrega do BK-423 de hoje: z_dispara.php:129-131 tem o

mesmo padrao (explode em campo vazio + aritmetica) e ficou de fora. O filtro de "arquivos

vivos" que eu usei para montar a lista excluiu z_dispara* por engano, e eu declarei 12 arquivos

cobertos.

Aqui a conta e soma, nao multiplicacao: date('H') + $tempo_antes_h. No 5.6, 12 + '' da 12;

no 8.3 e TypeError: Unsupported operand types: int + string. A peca 1619 tem exatamente o dado

que dispara (tempo_antes = '').

O script esta duplamente desligado hoje — fora do crontab e com o kill switch

RNT_LISTA_EMAILS_ENABLED ausente do .env — entao nao havia falha em producao. Mas religar sem

isto traria o fatal junto.

Fidelidade medida como no resto do BK-423: rodei o trecho original no 5.6 e o blindado no 8.3 sobre

'', '00:00', '01:00', '02:00, 01:00' e '0:30' — janelas de inicio e fim identicas.

[2026-09-17] BK-431: marcador de pedido de teste

Nao existe sandbox no checkout do RNT: o fluxo usa token de producao do Mercado Pago e callback de

producao, e so abrir pedido.php logado ja cria pedido (config/functions_new.php:905). Pior,

a janela para desfazer nao e de 10 minutos: z_dispara_pagamento.php roda a cada minuto e

seleciona status_transacao = '1' OR transaction_id = '' sem carencia — e-mail ao cliente em

menos de 60s. Em 11/09/2026 um teste ja vazou o pedido 73919 aprovado em nome de uma cliente real

(pedidos e MyISAM, ROLLBACK nao desfaz).

Novo includes/pedido_teste.php:

• o marcador nunca vem do POST. E derivado no servidor do cliente_id contra uma allowlist em

site_config.clientes_teste_ids — tabela que nenhum codigo escreve, so acesso ao banco

altera. Assim nao existe parametro que um visitante mande para se declarar "teste" e escapar de

cobranca ou ganhar ingresso

• falha aberta de proposito: consulta com erro ou chave ausente devolve lista vazia, e o SQL

fica identico ao de hoje. Falhar fechado silenciaria notificacao de compra REAL, que e pior

• rnt_sql_sem_pedidos_teste($alias) devolve fragmento SQL e sanitiza o alias
• rnt_log_pedido_teste() grava em admin/logs/pedido_teste.log o que teria sido enviado —

sem isso o teste fica cego sobre se a notificacao seria disparada

Conta de teste autorizada pelo ADMIN: 50877, Nea Barros (neaparente@gmail.com).

Regra: suprime o que alcanca CLIENTE ou PRODUTOR; mantem o que vai para o GESTOR, porque e

assim que o operador enxerga o teste acontecendo.

| Suprimido | Canal |

|---|---|

| z_dispara_pagamento.php | e-mail ao cliente, a cada minuto |

| admin/cron/lembrete_pedido_pendente.php | WhatsApp ao cliente (2 consultas) |

| webhook_mp_ingressos.php | WhatsApp de compra aprovada ao cliente |

| admin/cron/post_event_feedback_queue.php | pesquisa de satisfacao ao cliente |

| produtor/listaopen.php | lista de compradores do produtor |

| admin/modulos/campanhas/api/sales_webhook.php | orcamento de anuncio |

Mantidos de proposito: notifica_pedido_push.php e verifica_wa_compra_aprovada.php (gestor).

Validado: php83 -l e php56 -l limpos nos 7 arquivos; o helper devolve o mesmo resultado nas

duas versoes (o cron mais perigoso roda em 5.6); o SQL montado de cada consulta foi executado

no banco; e a prova direta — numa consulta com 41 linhas de duas clientes, o marcador removeu

exatamente os 36 pedidos da conta de teste, e a lista do produtor caiu de 2 para 1.

Pendencia conhecida: o celular da conta de teste esta gravado como (55) 2 1979-9799, que

normaliza para 5555219799799 e o dispatcher rejeita (regra ^55219[0-9]{8}$). Teste que

envolva WhatsApp para ela nao chega — e nao por causa do marcador.

Nao coberto: uma compra de teste ainda marca sec_enviolista = 1, o que pode disparar o

e-mail diario ao produtor mesmo com a lista vazia. Ver BK-431 no backlog.

[2026-09-17] BK-423: blindagem dos campos vazios que viravam fatal no 8.3

Fallout do BK-348 que so apareceu no BK-422: explode(':', '') devolve array de uma posicao,

o indice [1] fica indefinido e a multiplicacao seguinte recebe string vazia. No 5.6 isso era

Notice suprimido (peca.php:4) e a conta dava zero; no 8.3 e TypeError fatal, e derruba

a pagina inteira.

14 pontos em 12 arquivos, todos com a mesma transformacao — vazio ou ausente vira zero:

| Defeito | Arquivos |

|---|---|

| tempo_antes vazio na aritmetica | peca.php:998, config/functions.php:308 e :351, painel/data/functions.php:264, painel/modulos/pedidos/action.php:389, produtor/data/functions.php:258, admin/data/functions.php:294, img/cupom/data/functions.php:222, produtor/listaopen.php:79, produtor/modulos/pedidos/enviar.php:102, admin/modulos/pecas/enviar.php:96 |

| indice [1] sem isset (warning, nao fatal) | painel/modulos/pedidos/index.php:546 |

| pecas.valor vazio em valor * quantidade | pedido.php:103 e :112 — caminho de checkout |

| divisao sem conferir denominador | peca.php:652 (valor_de = 0 dava DivisionByZeroError) |

A fidelidade foi medida, nao assumida. Rodei o trecho original no 5.6 e o blindado no 8.3

sobre os mesmos seis formatos ('', '00:00', '01:00', '02:00, 01:00', '0:30',

' 01:00 '): a saida e identica byte a byte. Ou seja, as 10 pecas ativas que ja tem

antecedencia preenchida nao mudam de comportamento, e o vazio volta a significar

zero antecedencia (venda ate a hora da sessao), como era antes da virada.

Validado depois de aplicar: php83 -l e php56 -l limpos nos 12; home, /silvas,

/pe-de-cachimbo, /lisa-lesa-e-louca, /a-noite-dos-vampiros, /eventos.php e

/teatros.php em 200; admin/login.php e painel/login.php em 200; action.php act=entradas

devolvendo as 27 poltronas da peca 1342 (com mapa) e as 30 entradas da 1620 (sem mapa);

nenhum erro novo em rnt83-php-error.log.

Nao tocado de proposito: painel/modulos/pedidos/index.php:48 ja tinha blindagem anterior com

default de 2 horas em vez de zero. Na pratica esse default nunca dispara (explode sempre

devolve o indice 0, e (int)'' e zero), entao nao conflita — mas e semantica de outra pessoa.

Continua aberto no BK-423: preencher/validar tempo_antes antes de habilitar venda

interna (aprovacao em admin/modulos/eventos/action.php:2926 e ativacao de parceria em :3382

nao preenchem), e conferir se existe peca ativa com valor = '' ou valor_de = 0.

[2026-09-17] BK-422: slug duplicado da Silvas escondia uma pagina de venda quebrada

Duas pecas "Silvas" com o mesmo slug: 1613 (inativa, parceria_online=0, da produtora de

comunicacao) e 1620 (ativa, parceria_online=1, do produtor que fechou parceria). Era o unico

dos 27 grupos de slug duplicado do banco que envolvia peca ativa.

• pecas.slug da 1613 passou a silvas-1613. Zero pedidos, nenhum shortlink apontando para ela,

3 sessoes nunca configuradas (sec_quantidade = 0). Backup em

SQL/bkp_peca1613_slug_20260917_121716.json

Ao tirar a 1613 da frente, /silvas passou a responder HTTP 500 — e a causa nao foi a troca:

```

PHP Fatal error: Uncaught TypeError: Unsupported operand types: string * int

in peca.php:1000

```

peca.php:211 trata parceria_online = 1 como venda propria e mantem a peca no layout de venda;

sem parceria, delega para evento.php (peca.php:254), que reconsulta exigindo

status='A' AND editado_produtor=0 (evento.php:796). Por isso a 1613 ganhava o /silvas,

delegava, e o evento.php acabava renderizando a 1620 — o HTML mostrava imagens da 1620 antes

da troca, o que confundiu o diagnostico. Com a 1613 fora, a 1620 finalmente foi renderizada como

pagina de venda e chegou na linha 1000 com pecas.tempo_antes vazio.

O slug duplicado estava mascarando uma pagina de venda quebrada, nao causando o defeito.

• pecas.tempo_antes da 1620 preenchido. Primeiro pus '01:00' (o valor de 7 das 10 pecas

ativas) e estava errado: medido nos dois binarios com o trecho literal de peca.php:996-1000,

tempo_antes = '' no 5.6 da corte na hora exata da sessao, nao uma hora antes —

'' 3600 vale zero la. '01:00' teria fechado a venda as 18:00 numa sessao de 19:00 *do

mesmo dia**. Corrigido para '00:00', que reproduz o 5.6 exatamente. Apontado pelo gpt-6-astra,

conferido rodando o trecho no 5.6 e no 8.3 antes de aceitar

Validado: /silvas HTTP 200, marcador id=1620 em_cartaz=1, sessao de 17/09 na pagina, e

action.php act=entradas devolvendo 30 entradas disponiveis nas duas datas. Nenhum fatal novo.

A correcao e de DADO, nao de codigo — a proxima peca com parceria e antecedencia vazia

quebra igual. Virou BK-423.

[2026-09-17] BK-421: restart manual do WhatsApp voltou a funcionar (regressao do BK-420)

Revisao do gpt-6-astra sobre o BK-420 achou o que eu nao vi: as travas novas (nao esperar em

SAPI web, abortar em qr_pending, cooldown de 10 min) valiam tambem para o **restart pedido a

mao pelo operador**. Consequencias:

• admin/whatsapp_restart.php decide sucesso por $sucesso && $online; com o retorno sempre

false na web, o endpoint podia responder HTTP 500 mesmo com o servico online;

• admin/modulos/bot/stats.php:205 e :263 (botao "reiniciar", com log

RESTART MANUAL - Solicitado pelo admin) passavam a reportar falha.

Nao se recusa um restart pedido a mao, nem se devolve "falhou" so porque nao esperamos.

• _whatsapp_tentar_restart($forcar = false): com $forcar, pula a checagem de qr_pending,

pula o cooldown e espera o resultado mesmo na web. Sem $forcar, o comportamento do BK-420

fica de pe para a recuperacao automatica dentro de um envio

• os tres caminhos manuais passam true; os tres automaticos

(whatsapp_helper.php:767, :1247, :1348) seguem com as travas.

O :767 ja estava correto por outro motivo: so roda quando o servico esta inalcancavel,

e ai nao existe qr_pending para ler

Validado com o servico real em qr_pending: a chamada sem $forcar registra

RESTART - ABORTADO: servico esperando leitura do QR Code e o MainPID do rnt-whatsapp

fica identico antes e depois — o guard segura de verdade, nao so no papel.

Pendencias que o astra levantou e ficaram abertas (nao entram neste BK):

corrida entre ler o mtime e o touch do cooldown; qr_pending pode ficar true com QR

obsoleto porque bot/whatsapp/server.js:553 nao limpa qrDisplayed no auth_failure; e a

fila bot/whatsapp/queue/ apaga a mensagem apos 5 tentativas sem entregar

(whatsapp_helper.php:909).

[2026-09-17] BK-420: aprovar peca dava erro com o WhatsApp caido (e o restart matava o QR)

O ADMIN nao conseguia aprovar a peca 1619 (Pe de Cachimbo). A aprovacao funcionava —

pecas.aprovada_em = 2026-09-17 00:37:34, status A, 6 sessoes, editado_produtor = 0. O que

quebrava era a tela, depois do banco ja ter gravado.

Sequencia, pelo rnt83-php-error.log:

```

00:37:34 [DEBUG APROVAR] Evento aprovado com sucesso!

00:37:34 [WHATSAPP] SAUDE - Servico OFFLINE

00:37:34 [WHATSAPP] RECUPERACAO - Tentando restart automatico...

00:38:19 [WHATSAPP] RESTART - Resultado: FALHOU (timeout=45s)

```

_whatsapp_tentar_restart() dormia 9 x 5s esperando o servico subir, **dentro da requisicao

web. O nginx registrou HTTP 499** duas vezes as 00:38:09 (cliente desistiu antes da

resposta). A tela dava erro numa operacao que tinha dado certo, e reenviar custava mais 45s.

Tres correcoes em includes/whatsapp_helper.php:

1. restart nao bloqueia requisicao web. O nohup ja deixou o restart correndo; esperar so

prende a pagina. Em SAPI != cli a funcao dispara e devolve false, o chamador enfileira — o

estado final e o MESMO de antes, sem os 45s. No CLI (crons) a espera continua, porque la nao

custa tela de ninguem.

1. nao reiniciar quando o servico esta em qr_pending. Esse era o pior:

_whatsapp_verificar_saude() devolve false tanto para "processo morto" quanto para

"esperando alguem ler o QR", e o codigo tratava os dois como "reinicie". Sao opostos — um

pede restart, o outro pede gente. Como restart.sh faz systemctl restart, cada tentativa

derrubava a sessao e gerava um QR novo, invalidando o que o operador tentava escanear.

Foram 10 restarts em 12 horas com o servico parado em qr_pending desde 16/09 18:55.

1. cooldown de 10 min entre restarts (bot/whatsapp/ULTIMO_RESTART). O restart.sh nao

tinha trava nenhuma e cada envio falhado reiniciava o servico de novo.

O healthcheck.sh:169 ja fazia certo ("API online, mas WhatsApp desconectado. Sem restart

forcado.") — quem estava errado era so o lado PHP. A correcao alinha os dois.

Nenhuma mensagem foi perdida: as 3 que estavam na fila (bot/whatsapp/queue/), inclusive o

aviso de aprovacao ao produtor, saem quando o numero reconectar.

Junto: /root/qr.sh mostra o QR Code atual limpo e escaneavel. O admin nao tem tela de QR, e o

QR que sai no log do systemd fica deslocado pelo prefixo do journalctl, entao nao le. O QR

nao vai para o webroot de proposito: quem escaneia conecta um aparelho na conta do RNT.

Fechado como: entregue. Validado que o guard aborta o restart com o servico real em

qr_pending; o caminho web se prova no proximo [WHATSAPP] RESTART - disparado sem esperar.

[2026-09-17] BK-417: captador saiu do PHP 5.6 (cron do painel bt e botao do admin)

O BK-348 virou web+cron para 8.3 em 25/08/2026, mas o captador ficou para tras porque mora no

terceiro lugar de agendamento: /www/server/cron/ (tarefas do painel bt), que nem

crontab -l nem /etc/cron.d mostram.

• /www/server/cron/bfc5bb6c... (diario 04:01, --verbose) e /www/server/cron/f9659feb...

(a cada 7 dias, --reprocessar): /www/server/php/56/bin/php -> /www/server/php/83/bin/php.

Atencao: esses arquivos sao gerados pelo painel bt; editar a tarefa pela interface dele

reescreve o script e devolve o 5.6. Backup em /root/rnt-tools/backups/cron/

• admin/modulos/bot/action.php: o bloco que escolhia o binario testava PHP_BINARY (que sob

php-fpm nao e um CLI utilizavel), depois 5 caminhos que nao existem nesta VPS, e caia em

php do PATH — que e o 5.6. Nao era "pior caso": as 6 execucoes gravadas em

admin/logs/debug.log mostram PHP Bin: php nas 6. Agora o caminho e explicito e a ausencia

dele devolve erro visivel em vez de rodar a versao errada calado

Compatibilidade verificada antes de trocar, nao depois:

• php83 -l limpo nos 13 arquivos do runtime do captador
• const_undef.php e var_null_array.php (BK-362/363) acusaram 22 constantes e 2 variaveis —

todos falso positivo, conferidos na fonte: as BOT_LOG_* estao em config/bot_config.php

(o scanner nao segue o include para fora de bot/), e o $saida de sympla_scraper.php:2352

e parametro por referencia com o chamador inicializando

• dry-run 5.6 x 8.3 no mesmo momento: **22 captados / 20 cadastrados / 0 atualizados /

0 duplicados / 2 invalidos, exit 0 e zero deprecation nos dois**

• exec() esta ON nos dois CLIs (o 8.3 carrega php-cli.ini proprio, nao o php.ini

compartilhado que proibe); o Puppeteer de sympla_scraper.php:793 nao esta instalado em

nenhum dos dois, entao falha do mesmo jeito

Nao coberto pelo dry-run: refinarEvento() so roda em modo real. A rodada automatica das

04:01 de 17/09 e a validacao; rollback = restaurar os dois backups de cron.

Junto, em admin/modulos/bot/index.php (BK-416): o painel passou a marcar rodada de --dry-run

com selo "simulacao". Um dry-run escreve no MESMO log e com o mesmo cabecalho de resumo, entao

sem essa marca o painel apresentaria uma simulacao como captacao real — o defeito que o BK-416

acabara de remover. Apareceu porque os testes desta rodada o provocaram.

Fechado como: entregue, com a rodada real das 04:01 pendente de conferencia.

[2026-09-16] BK-416: painel do bot mostrava "Nunca executou" com o captador rodando todo dia

admin/modulos/bot/index.php lia bot_eventos_log — tabela morta desde 11/02/2026. O unico

INSERT e Deduplicator::registrarLog() (bot/handlers/deduplicator.php:318) e **nenhum arquivo

chama esse metodo**; sobraram 428 linhas congeladas de 09 a 11/02. Resultado: os 4 cards mostravam

zero e "Ultima Execucao: Nunca", e a lista "Logs Recentes" exibia eventos de FEVEREIRO como se

fossem de agora — enquanto o cron do painel bt (/www/server/cron/, ainda em PHP 5.6) roda o

captador todo dia as 04h. Ninguem percebeu porque a tela nao dava erro: dava zero.

• cards passam a ler o resumo que o proprio cron escreve no log da rodada

(bot/logs/captador_AAAAMMDD.log), com o ULTIMO bloco RESUMO DA EXECUCAO do arquivo mais novo;

rotulo mudou de "(7 dias)" para "(ultima rodada)", que e o que o numero realmente mede

• numero ausente no log vira travessao, nao zero — zero e afirmacao, ausencia nao e
• card de erros ganhou os descartados pelo validador (33 de 47 em 16/09, numero que nao aparecia

em lugar nenhum da tela)

• "Logs Recentes" virou "Sugestoes recentes do captador", lendo bot_pecas_sugestoes, com selo

de pendentes de aprovacao (20 em 16/09)

• fonte e nome_captado passaram a sair com htmlspecialchars: vem raspados de Sympla/Eventim

e eram impressos crus

• fallback por filemtime converte explicitamente para America/Sao_Paulo. O php.ini desta VPS

esta em date.timezone=PRC: na primeira versao o teste de borda mostrou 10:14 (China) para um

arquivo de 23:14. O log do captador nao sofre disso porque bot/config.php:15 fixa o timezone

• a bot_eventos_log NAO foi ressuscitada de proposito: os SELECT de dedup por hash

(deduplicator.php:34,56,108,122) dependem dela, e volta-la a popular muda o que o captador

suprime. Decisao separada, com risco real; o painel so parou de depender de tabela morta

Validado: php83 -l; bloco novo executado contra log e banco reais (47 captados / 2 cadastrados /

2 atualizados / 10 duplicados / 33 invalidos / 0 erros, e 20 pendentes — bateu com o log de 16/09);

6 casos de borda (sem diretorio, sem log, log 0 byte, log sem resumo, dois resumos no mesmo arquivo,

varios arquivos); JS inline conferido identico; encoding UTF-8 sem mojibake.

Fechado como: entregue. Validacao no navegador pendente (tela de admin, exige login).

[2026-09-12] BK-415: paginacao do historico de compras na ficha do cliente

Nunca funcionou, nem no 5.6. Na aba Compras de admin/modulos/clientes/detalhe.php a carga

inicial contava a tabela pedidos inteira (~72 mil: links 1-5 e "Ultimo" na pagina 1.448, vazia),

e cada clique voltava sem link de pagina porque o total vinha de um #list-total que a ficha nao

tem (BK-414). Na pratica so atinge 3 clientes com mais de 50 pedidos, quase tudo cancelado.

• action.php: total contado no servidor por cliente e status nos 3 cases do historico

(paginate-historic, search-historic, paginate-search-historic), paginacao pela mesma

clientes_render_pagination() da lista de clientes

• clientes_render_pagination() foi para bootstrap.php (a ficha usa na carga inicial) e parou

de repetir o link "1" nas paginas 2 e 3 (afeta tambem a lista de clientes, para melhor)

• o filtro de status sobrescrevia TODAS as tabelas da ficha: o JS usava .panel-body tbody, e

esse .panel-body envolve a pagina inteira (Abandonos, WhatsApp, Creditos viravam compras).

Seletores restritos a #historic-tab; search-client-historic.js ver=1.7

• SQL: setQueryStatus() so aceita codigos 1..10, user com (int), termo da busca com escape
• paginate-search-historic montava WHERE 1AND clientes.id (sem espaco): no 5.6 falhava calado,

no 8.3 lanca mysqli_sql_exception

• revisao do gpt-6-astra (sem regressao) apontou 4 defeitos antigos da mesma aba, conferidos e

corrigidos: apagar 1-2 letras da busca limpava a tabela; trocar status durante a busca trazia o

backup antigo de volta; id[] fazia preg_match lancar TypeError; termo sem escape no HTML

• teste CLI no 8.3 (cliente 15716, 289 cancelados): paginas 1 a 6 certas, 7 vazia, injecao em

status/user neutralizada. Validacao no navegador pendente (ver BACKLOG)

[2026-09-12] BK-414: filtro do historico de compras do cliente quebrava no PHP 8.3

Alerta "EXCECAO em admin/modulos/clientes/action.php:350 (9x)". Os botoes de status do

historico de compras em admin/modulos/clientes/detalhe.php nao listavam nada: o JS le o total

de #list-total, que so existe nas telas de listagem, e mandava total="". No 5.6 "" / 50

dava 0; no 8.3 e TypeError: Unsupported operand types: string / int.

• (float) $_POST['total'] / 50 no case paginate-historic (fiel ao 5.6: vazio vira 0)
• a mesma linha em notificacoes, cupons, pedidos_2 e clubent; em notificacoes havia gatilho

real (tabela sem registro deixa #list-total vazio), as outras recebem sempre COUNT(*)

• teste CLI no 8.3: backup lanca o TypeError, versao nova devolve a lista (clientes e notificacoes)
• nao mudou: a paginacao do historico continua sem links de pagina (total 0), como no 5.6

[2026-09-11] BK-413: lembrete mensal de credito na carteira por WhatsApp

Pedido do ADMIN: quem tem credito esquece. Novo admin/cron/lembrete_credito_carteira.php

(/etc/cron.d/rnt-lembrete-credito, diario 10:15, janela 10h-18h de Brasilia) manda um

WhatsApp curto, sem valor, a quem tem saldo disponivel > 0 e sair=0.

• no maximo 1 a cada 30 dias, contados do ultimo lembrete OU do credito mais recente
• dedup e historico em rnt_lembrete_credito_log (tabela nova); 1 tentativa por dia; 20 por rodada
• flags --dry-run, --preview, --test-send (so para o numero do gestor, sem gravar log)
• instalado sem enviar nada: os 3 clientes com saldo hoje (21061, 48841 e a conta de teste

50877) foram registrados como avisados em 11/09, entao o primeiro disparo real e 11/10/2026

• texto ditado pelo dono, com ortografia corrigida e dominio .com.br (ele escreveu .com)

[2026-09-11] BK-412: credito de cliente aparecia como R$ 0,00 no checkout

Cliente sem linha em tb_produtores tinha o credito gravado no ledger, mas checkout, carteira e

estorno leem tb_produtores.creditos — viam R$ 0,00. Nao era tarifa: o pedido 73917 virou

R$ 44,00 de credito corretamente. 3 clientes presos (R$ 44, R$ 40, R$ 25).

• config/functions_cliente_carteira.php: sem linha de produtor, o saldo e o ledger
• admin/modulos/pedidos_2/action.php: "Virou credito" do admin creditava so o valor unitario
• detalhes: docs/changelog/2026/CL-2026-09-11-BK-412-credito-cliente-invisivel.md

[2026-09-10] BK-210: e-mail da lista diaria reativado e causa raiz do incidente corrigida

O certificado TLS do servidor de e-mail nao cobre mail.rionoteatro.com.br, o host que estava

no codigo: o PHPMailer recusava por hostname mismatch, todo envio SMTP falhava e caia no

mail() local — origem das 426 mensagens presas no MTA em abril. Corrigido o host, o envio

voltou (validado com mensagem recebida, em 8.3 e em 5.6).

• credenciais SMTP saem de 16 arquivos vivos para o .env (novo config/mail_credentials.php)
• a senha do sac@ em z_dispara_pagamento.php nao autenticava mais (SMTP 535); a valida foi para o .env
• each() (3x) e FILTER_FLAG_HOST_REQUIRED corrigidos: eram fatais em PHP 8 dentro do PHPMailer
• disparaemail.php: guard de CLI (respondia 500 por HTTP) e isMail() -> setSMTP()
• crons da lista diaria migrados para php83 e e-mail religado por flag no wrapper
• detalhes e pontas abertas: docs/changelog/2026/CL-2026-09-10-BK-210-reativacao-email-lista.md

[2026-09-10] BK-410: convite automatico de parceria 3 dias apos a aprovacao da peca

Peca cadastrada pelo produtor e aprovada pelo ADMIN, sem parceria_online, passa a receber

um WhatsApp oferecendo a parceria gratuita (20% de comissao) com o link do termo, a partir de

24h depois da aprovacao, na janela comercial de 9h-18h (todos os dias).

• Novo carimbo pecas.aprovada_em (nao existia data de aprovacao no banco), gravado nos dois

caminhos de aprovacao do admin em admin/modulos/eventos/action.php.

• Nova pagina publica termo-parceria.php — o termo so existia no modal do painel (com login)

e num PDF que o nginx devolve 403.

• Novo admin/cron/convite_parceria_produtor.php + /etc/cron.d/rnt-convite-parceria-produtor

(a cada 30 min, 9h-20h), com --dry-run, --preview, --test-send e dedup de 1 convite por peca.

• Detalhes, ressalvas e pontas abertas: docs/changelog/2026/CL-2026-09-10-BK-410-convite-parceria-produtor.md

[2026-09-10] Triagem dos itens soltos do backlog: 7 viraram BK, 3 ja estavam entregues

Ultimo pedaco da higiene do BACKLOG.md. Tres secoes sem numero de BK — `PROXIMOS

PASSOS (ordem sugerida), BACKLOG (sem ordem definida) e Marketing/ROI/Ads

(03/03/2026)` — foram triadas item a item.

Viraram BK numerado e entraram na lista do Studio: BK-403 (tela para baixar os CSVs

de assets), BK-404 (refinamento via Cerebro com limite RSA/PMAX), BK-405 (servico local

do WhatsApp com detached Frame), BK-406 (limpeza do notify_state/), BK-407 (link de

compra do produtor no bot captador), BK-408 (seletores com IA, adiado como contingencia)

e BK-409 (UI do Scraper Studio, congelado). A ponta aberta do BK-170 virou stub proprio.

Sairam porque ja estavam entregues — conferido antes de apagar:

• "WhatsApp para admin ao detectar erro no log" (unico item de PROXIMOS PASSOS,

proposto com debounce de 30 min): ja implementado. admin/logs/debug_helper.php:167

chama _debug_log_deve_alertar_whatsapp() / _debug_log_enviar_alerta_whatsapp(),

ambas definidas no mesmo arquivo (linhas 23 e 72) — conferi que existem, porque

chamada sob function_exists para funcao inexistente ja mordeu aqui no BK-359. O

alerta de erro de runtime e coberto por outro caminho: vigia_erros_runtime.php,

no cron a cada 5 min, le o rnt83-php-error.log e avisa por WhatsApp + push.

• ROI Rio no Teatro (SQL/collation + cron id=19): e o BK-86, ja no changelog.
• "Expandir debug_log para todo o site": e o BK-89, ja no changelog.
• Todo o historico [x] de Marketing/ROI/Ads (BK-96, 97, 105, 106, 118, 170, 171):

conferido um a um, todos com registro no changelog ou em changelog/2026/.

Fundido: "Migracao completa mysql_* para mysqli" era duplicata do BK-87, que ja

estava na lista numerada. Os dados uteis da duplicata (ja migrados pecas e

indexfotos) foram para a linha do BK-87.

Removido tambem: os dois rodapes Ultima atualizacao: ... de marco/2026, que

repetiam em prosa fechamentos que ja estao no changelog, e o paragrafo gigante de

fechamentos no cabecalho do arquivo.

BACKLOG.md fechou o dia em 998 linhas, contra 2689 pela manha.

[2026-09-10] Prorrogacao de temporada: Lisa, Lesa & Louca (peca 1342)

Pedido operacional do ADMIN, sem BK: prorrogar a peca em 7 datas, mantendo as

fileiras C e F. Nao houve mudanca de codigo do site — o registro esta aqui porque a

rodada virou runbook e ferramenta.

Estado antes: temporada 08/08 a 27/09, sessoes de sabado 20h no Barra Point

(teatro 79), mapa C1-C14,F1-F13 (27 assentos), R$ 60,00 -> R$ 22,00.

Duas das sete datas ja existiam (12/09 e 26/09, sec_id 19179 e 19181) e nao foram

tocadas. Criadas as 5 restantes, com o sec_dia_semana = date('w'):

| data | dia | hora | sec_id |

|---|---|---|---|

| 11/10 | domingo (0) | 19:30 | 19276 |

| 18/10 | domingo (0) | 19:30 | 19277 |

| 24/10 | sabado (6) | 20:00 | 19278 |

| 01/11 | domingo (0) | 19:30 | 19279 |

| 15/11 | domingo (0) | 19:30 | 19280 |

Valores, mapa e estoque copiados da sessao que ja estava no ar. pecas.fim_temporada

estendida de 27/09 para 15/11. Backup do estado anterior em

SQL/bkp_peca1342_20260910_213636.json.

Validacao: pagina /lisa-lesa-e-louca em 200 sem fatal, as 7 datas no seletor e o

rotulo "Sabado 20h e Domingo 19h30"; POST /action.php act=entradas nas 5 datas novas

devolve 30 entradas disponiveis com o CSV C+F completo; nenhum residuo do horario 19:00

da temporada de marco/abril.

Duas coisas que a rodada corrigiu na fonte:

1. sec_quantidade maior que o sec_mapa nao e bug. O runbook mandava igualar os

dois; medido em producao, a peca roda com sec_quantidade = 30 para 27 poltronas, e

isso e a regra 1.4 do proprio regulamento (esgotando a marcacao, a venda segue e o

lugar sai na bilheteria). Do jeito que estava escrito, o proximo agente baixaria 30

para 27 e tiraria estoque vendido de proposito. Corrigido em

docs/RUNBOOK_CADASTRO_EVENTO_PRODUTOR.md (§4 e checklist).

1. Sessao alem do fim_temporada e falha silenciosa. A sessao vende pelo link direto

mas a peca some da home, do carrossel e do grid (index.php e peca.php filtram por

fim_temporada >= hoje) e passa a ser tratada como fora de cartaz pelo cron de limpeza

de cartaz. A pagina da peca continua mostrando as datas, entao parece certo. Virou a

§7 (Prorrogacao de temporada) do runbook e a ferramenta

/root/rnt-tools/check_temporada.php (exit 1 se achar, --fix <peca_id> estende ate a

ultima sessao). O detector foi provado contra o estado pre-correcao: com fim_temporada

em 27/09 ele acusa peca 1342, 5 sessoes alem. Hoje sai limpo nas 10 pecas ativas com

sessao futura.

Nao foi feito: cartaz e link de YouTube continuam manuais no painel.

[2026-09-09] menu do painel do cliente fatal em Meu Perfil (BK-402)

Fechado como: CORRIGIDO em 09/09/2026 · migrado do BACKLOG.md em 10/09/2026.

Chegou pelo vigia de erros (WhatsApp + push) as 17:52 de 09/09/2026, 2 ocorrencias.

• sintoma: GET /painel/modulos/profile/ responde 200, mas o corpo para no

meio do menu lateral. Nao vira 5xx, entao so o vigia enxerga.

• erro: [PHP_EXCEPTION] Undefined constant "MODULO_ACTIVE_MENU" em

painel/inc-menu.php:72.

• causa: modulos/profile/bootstrap.php (e tambem modulos/bootstrap.php,

clubent, clubernt) define MODULO_SLUG mas nao define

MODULO_ACTIVE_MENU. No 5.6 a constante indefinida virava a string

"MODULO_ACTIVE_MENU", a comparacao dava false e o item so nao ficava ativo;

no 8.3 e Error fatal. Mesma classe do BK-362/BK-363, fallout da virada de 25/08.

• por que so a linha 72: as outras 6 linhas do mesmo arquivo (12, 18, 33, 97,

105, 111) ja tinham a guarda defined(). A 72 — dentro do laco do menu vindo do

banco — ficou de fora na passada de endurecimento.

• correcao: guarda defined('MODULO_ACTIVE_MENU') && ... na linha 72, igual as

demais. Fidelidade conferida nos dois binarios: no 5.6 o codigo antigo dava

inativo; no 8.3 o antigo era fatal e o novo devolve inativo com a constante

ausente e ativo quando ela existe e casa.

• linha 84 (MODULO_SLUG) nao foi tocada: painel/data/setup.php ja garante a

constante com fallback vazio, entao nunca fatalou.

• efeito colateral util: a validacao deste BK expos que php -l nesta VPS

compila no 5.6 (o php do PATH nunca mudou; o site e 8.3 desde 25/08).

docs/00_PROTOCOLO.md mandava php -l em 9 lugares e foi corrigido para

php83 -l; o guard da VPS passou a avisar (rnt-php-versao-lint) quando o

binario errado toca arquivo do webroot. Todos os /etc/cron.d/rnt-* ja usavam

/usr/bin/php83.

• latente, fora deste BK: painel_old/inc-menu.php:57,

painel_old/inc-menu_2026.php e img/cupom/inc-menu.php tem o mesmo uso sem

guarda. So disparam se alguem abrir essas telas.

[2026-09-07] voto de enquete virava o comentario publico (BK-401)

Fechado como: CORRIGIDO em 07/09/2026 · migrado do BACKLOG.md em 10/09/2026.

Achado pelo ADMIN minutos depois de religar a enquete, testando: ele votou e o fluxo

pulou a pergunta do comentario e mandou o fecho, como se ele ja tivesse comentado.

Causa. A conversa dele ja estava na etapa comentario (de um teste anterior). O voto

chega ao webhook como mensagem de texto "5" — de proposito, e o que faz o BK-389

reaproveitar todo o fluxo. So que na etapa do comentario qualquer texto e aceito, entao o

"5" virou o comentario: gravou comentario="5", concluiu e agradeceu.

Por que isso ficou serio agora. Enquanto so existia a via de texto, era dificil

acontecer. Com as duas vias ligadas (BK-400), o caminho e natural: a pessoa responde a

nota digitando, recebe a pergunta do comentario, volta e toca na enquete — e o toque

vira o comentario publico dela.

Correcao, com duas guardas na etapa do comentario:

• is_poll_vote no payload, que o server.js ja mandava desde o BK-389 e ninguem usava.

E o sinal confiavel;

• formato: um digito de 1 a 5 sozinho e nota repetida, nao comentario.

Conferido que comentario legitimo continua passando: "5 estrelas! Adorei" e

"nota 5 mesmo" sao gravados; "5", "4" e voto de enquete sao ignorados; "Não"

continua pulando o comentario; anexo continua ignorado pelo BK-388.

Dado limpo: a avaliacao id 2 tinha ficado com comentario="5". Zerada.

Segundo achado, menor: o ADMIN recebeu a enquete sem a mensagem de abertura. Isso

foi artefato do meu teste — chamei rnt_post_event_feedback_enviar_enquete() direto, sem

mandar o texto antes. No fluxo real a fila manda a abertura e o gancho de

mark_queue_sent manda a enquete em seguida. Nao e defeito do produto, mas vale registrar

para nao assustar em teste futuro: testar a enquete isolada da abertura induz ao erro.

[2026-09-07] enquete religada (BK-400)

Fechado como: FEITO em 07/09/2026 · migrado do BACKLOG.md em 10/09/2026.

A enquete tinha sido desligada no BK-391 porque o voto nao voltava. Com o BK-399 provado

em producao, foi religada: RNT_PEF_ENQUETE_ATIVA = true, e o texto de abertura voltou a

dizer "Toque na enquete abaixo ou responda apenas com o número".

As duas vias continuam valendo, de proposito. A enquete e a via facil — um toque, sem

ambiguidade de interpretacao. O texto e a via que sobrevive: se o WhatsApp mudar de novo o

contrato interno (e mudou duas vezes so hoje, de 2.3000.1046948731 para

2.3000.1046951358), a nota continua chegando por escrito. Desligar e uma linha, e o

fluxo nao para.

Alarme armado: o diagnostico do BK-397 grita ALARME no boot se nem _serialized nem

$1 servirem. O proximo rename aparece no log, nao em recurso mudo por semanas.

[2026-09-07] correcao do contrato da chave de mensagem (BK-399)

Fechado como: RESOLVIDO em 07/09/2026 · migrado do BACKLOG.md em 10/09/2026.

A correcao que os BK-393 a 398 levaram o dia inteiro para poder escrever com seguranca.

O que estava errado: o WhatsApp Web renomeou _serialized para $1 nas chaves de

mensagem (Wid nao mudou). A lib 1.34.7 le ._serialized de chave de mensagem em ~20

lugares e recebia undefined.

Por que patch e nao getter no prototipo (a opcao que eu ia escolher, derrubada pelo

gpt-6-astra com argumento verificado no codigo): Utils.js faz

Object.assign({}, msg.id, ...) ao mandar o modelo para o Node, e **Object.assign nao

copia propriedade herdada**. Um getter no prototipo se perderia exatamente onde o

downloadMedia() le this.id._serialized no Node — consertaria a pagina e deixaria o

download quebrado do mesmo jeito.

Seis alteracoes, em patches/apply_rnt_patches.py (versionado, idempotente, com

backup .rnt-bak e --desfazer):

1. window.WWebJS.__rntKeyId(), adaptador central;
2. o modelo que atravessa para o Node ganha _serialized como propriedade propria;
3. e 4. getChatModel busca a ultima mensagem pela chave boa;
4. o gancho do voto usa a chave boa em parentMsgKey;
5. o bulkUpsert original passa a rodar sempre, mesmo se a observacao falhar.

A alteracao 6 conserta um dano que a lib causava. Medido: voto real, sonda nunca

disparou e a tabela de votos ficou vazia. O gancho quebrado nao so deixava de avisar —

impedia o proprio WhatsApp de gravar o voto. Ele atrapalhava mais do que ajudava.

Regras que o patch segue, herdadas da revisao do astra:

• prefere o nativo: se o WhatsApp voltar a expor _serialized, e ele que vale; $1 so

entra depois de validado por round-trip no MsgKey. Nunca aceitar string solta do objeto

como id;

• nao toca em Wid, que nao quebrou;
• idempotente, e npm install nao apaga o script — so exige rodar de novo.

Base de decisao, medida antes de escrever (BK-398): com a chave boa, getChats passa

60 de 60 em todas as etapas (era 0 de 120). Para midia, a chave acha a mensagem; o

resto ficou indeterminado porque a amostra era uma imagem nunca baixada

(mediaStage=INIT e o esperado nesse caso, nao prova de segunda quebra).

TESTADO EM PRODUCAO, com voto real:

[Voto] onPollVoteEvent chamado: 1 voto(s) opcoes=1 temParent=true

[Enquete] voto de 5521979979992: 4

banco: recebida | +55219797***** | "4"

temParent=true e a prova do patch da lib — e exatamente ali que quebrava

(Msg.get(parentMsgKey._serialized) com undefined). A linha seguinte e a prova do

BK-397: a versao anterior do handler descartaria o voto por esperar string de telefone

num objeto.

Prova independente: o message_id voltou. Eram 72 ocorrencias de N/A no log de

hoje antes do patch; depois, id real. Era o mesmo defeito, visivel o dia inteiro sem

ninguem entender.

getChats: 60 de 60 em todas as etapas, contra 0 de 120 pela manha.

Download de midia: NAO testado, e sem previsao de ser. O canal de arquivo foi criado

para outra finalidade (trazer os zips do historico do WhatsApp, BK-387), e o ADMIN cortou

com razao: para a enquete nao serve. Fica registrado que a chave acha a mensagem, que

era o que falhava; o resto do caminho de download segue sem medicao.

Rollback: python3 patches/apply_rnt_patches.py --desfazer e reiniciar.

[2026-09-07] medir etapa por etapa ANTES de escrever a correcao (BK-398)

Fechado como: PRONTO em 07/09/2026 · migrado do BACKLOG.md em 10/09/2026.

O gpt-6-astra recusou prometer que consertar a chave recupera os tres recursos, e listou o

que faltava medir. Este item e essa medicao — para entrar no conserto sabendo o tamanho

dele, em vez de cair num ciclo de consertar-testar-descobrir-outra.

A ideia: em vez de escrever a correcao e descobrir no teste, simular a correcao.

O /diag-steps usa a chave validada ($1 hoje, o nativo se voltar) e refaz as etapas na

mao, registrando qual passa e qual quebra. So leitura: nao envia, nao baixa midia de

verdade, nao busca historico.

1. getChats, decomposto em chat.serialize(), chat.formattedTitle e

Msg.get(chave boa), contados separadamente. Se a busca passar com a chave boa mas

serialize continuar quebrando, a chave nao basta — e a gente descobre agora, nao

depois.

2. Midia: se acha a mensagem pela chave boa, e se tem mediaStage, directPath e

mediaKey, que sao os campos que o download exige. Sem eles, a chave sozinha nao devolve

o download.

3. Voto: se ha voto persistido na WAWebPollsVotesSchema. Isso decide entre dois

mundos:

• ha voto gravado -> existe caminho alternativo (client.getPollVotes), que recupera o

voto mesmo sem o evento disparar;

• nao ha -> o gancho falha antes de gravar, e consultar a tabela nao adianta.

4. Sonda de voto, permanente. O window.onPollVoteEvent foi embrulhado por uma versao

que registra quando e chamado e repassa para a original. Isso responde a pergunta que

faltava — onde o voto morre:

[Voto] onPollVoteEvent chamado: N voto(s) -> a pagina fez a parte dela, o problema e no Node

(nada no log) -> morre antes, na preparacao dentro do gancho

Sem isso, o BK-397 (handler consertado) e a correcao da chave seriam testados as cegas: se

o voto nao voltasse, nao daria para saber qual das duas pontas falhou.

Observacao nova, com peso na decisao: entre dois reinicios de hoje o WhatsApp Web

mudou sozinho de 2.3000.1046948731 para 2.3000.1046951358. O bundle troca em minutos.

Isso enterra de vez a ideia de fixar versao — seria mirar em alvo movel — e reforca a regra

do astra: preferir o nativo e revalidar a alternativa a cada boot, nunca assumir que

$1 e eterno. O $1 continuou valido na versao nova, o que e bom sinal para a correcao.

Precisa de restart para a rota e a sonda existirem.

[2026-09-07] duas armadilhas no MEU codigo, achadas pelo gpt-6-astra (BK-397)

Fechado como: CORRIGIDO em 07/09/2026 · migrado do BACKLOG.md em 10/09/2026.

Ao avaliar onde aplicar a correcao da chave, o astra achou dois defeitos no codigo que eu

mesmo escrevi hoje. Os dois sao do tipo que so aparece quando ja e tarde.

1. O diagnostico mentia. O health check do BK-394 testava _serialized num Wid

criado pelo WidFactory — e Wid nao quebrou. Ele dizia PRESENTE enquanto tres

recursos estavam mortos, e foi exatamente esse "PRESENTE" que me fez declarar a hipotese do

rename como morta, atrasando o diagnostico.

Agora testa chave de mensagem, que e o que getChats, downloadMedia e o voto de fato

leem, com a regra que o astra recomendou: prefere o nativo; se o WhatsApp voltar a

expor _serialized, e ele que vale. O $1 so entra como alternativa e **so depois de

validado** (round-trip pelo MsgKey e Msg.get achando a mensagem). Nunca aceitar uma

string qualquer do objeto como id. Tres saidas possiveis no log:

OK pelo nativo (_serialized)

DEGRADADO: _serialized ausente, usando $1 (validado) <- estado de hoje

ALARME: nem _serialized nem $1 servem <- proximo rename

2. O handler de voto descartaria o voto na porta. PollVote.voter recebe

data.sender, que e objeto, e eu fazia String(vote.voter) comparando com regex de

telefone. Todo voto cairia no return, com um aviso enganoso de "JID nao telefonico" —

ou seja, mesmo consertando o evento, o voto morreria aqui, e o log culparia o remetente.

Corrigido para extrair o jid do objeto (_serialized, $1, toString(), user@server) e

reusar o realPhoneForMessage(), que ja resolve LID desde as campanhas e fez 69

resolucoes hoje sem uma falha. Conferido que essa funcao tolera msg = null: todo acesso a

msg dentro dela tem guarda.

Nao resolve as tres quebras — a chave continua sendo o problema de fundo. Isto so tira

duas armadilhas do caminho: um diagnostico que dava falso conforto e um handler que

jogaria fora o resultado do conserto.

Precisa de restart para valer.

[2026-09-07] teste da chave de mensagem, cruzado por tipo de contato (BK-396)

Fechado como: PRONTO em 07/09/2026 · migrado do BACKLOG.md em 10/09/2026.

Fecha (ou derruba) a hipotese de que _serialized mudou de nome nas **chaves de

mensagem** — e ao mesmo tempo testa uma observacao do ADMIN que muda o desenho do teste.

A hipotese. Os tres recursos quebrados leem _serialized de chave de mensagem:

| Caminho | Campo |

|---|---|

| getChatModel | chat.lastReceivedKey._serialized |

| downloadMedia | this.id._serialized |

| Voto | vote.pollUpdateParentKey._serialized |

Evidencia: message_id=N/A em 68 de 68 mensagens processadas hoje (o campo vem de