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-06-16] Helper WhatsApp compartilhado com Amor Eterno

• bot/whatsapp/server.js passou a reconhecer mensagens com tag #AE como tráfego do projeto Amor Eterno.
• Mensagens recebidas com #AE são roteadas para o webhook local do Amor Eterno e deixam de cair no webhook/histórico normal do Rio no Teatro.
• Envios feitos via API com project=AE são marcados para não poluir o histórico do Rio no Teatro.
• Adicionado suporte a envio de mídia por media_path restrito a /opt/amoreterno/media.
• Service rnt-whatsapp reiniciado e validado conectado em 127.0.0.1:3033.

[2026-05-20] Teste real WhatsApp: Enfermeira Zilda no Miguel Falabella

• Criado shortlink https://rionoteatro.com.br/4pie para Enfermeira Zilda com UTM da campanha de teste admin.
• Importada campanha de teste #10 (enfermeira_zilda_mf_20260520_test_admin) com apenas o numero admin 5521999915554, janela 00:00-17:30 por ser disparo no dia da sessao das 19:30.
• Enviado teste real pela fila profissional WhatsApp (queue_id=9741): sent=1, failed=0, blocked=0; kill switch global religado apos o envio.
• Ajustado segundo teste admin (#11, queue_id=9742) com "unica apresentacao da comedia", CTA em frase unica ate 18:30 e rodape PT-BR com opt-out acentuado + atualizacao de zonas de interesse; envio real: sent=1, failed=0, blocked=0.
• Confirmada viabilidade de base: 1256 compradores historicos do Teatro Miguel Falabella com celular 5521* e 3674 linhas de fila da base Zona Norte sem status sent.

[2026-05-20] Hotfix: lista digital do produtor abre token gerado pelo disparo diario

• Corrigido config/listaopen_token_helper.php para gerar tokens da lista digital com segredo estavel baseado nas variaveis DB_* do ambiente.
• Mantida compatibilidade de leitura com tokens legados gerados antes da correcao, incluindo o link ja enviado para Enfermeira Zilda - 20/05/2026 19:30:00.
• Causa confirmada: z_dispara_diario.php gerava o token sem constantes DB_ definidas, enquanto /produtor/listaopen.php validava com constantes DB_, fazendo o token resolver para 0 no produtor e mostrar "Sessão não encontrada.".
• Validacoes: php -l config/listaopen_token_helper.php, resolucao do token antigo em contexto raiz e /produtor, resolucao de token novo em /produtor e curl publico sem "Sessão não encontrada.".

[2026-04-29] BK-280: documentação da política de shortlinks

• Criado docs/SHORTLINKS.md como referência local da política de retenção.
• Adicionado comentário em config/shortlink_helper.php apontando para essa documentação.
• Reforçado que campanhas usam expires_at=NULL por padrão e que expiração é apenas opt-in/manual.
• Changelog detalhado: docs/changelog/2026/CL-2026-04-29-BK-280-doc-politica-shortlinks.md.

[2026-04-29] BK-279: roadmap de shortlink automático em Campanhas

• Documentado roadmap para implementar shortlink automático no fluxo admin/modulos/campanhas/incluir.php / action.php.
• Definida política de retenção: shortlinks de campanha ficam permanentes por padrão; expires_at passa a ser recurso opcional, não expiração automática.
• Registrada estratégia de execução para amanhã com revisões externas menores e paralelas por pacote.
• Atualizados os links atuais 1a2b e 9t66 para expires_at=NULL, mantendo histórico e redirect ativos por tempo indeterminado.
• Smoke de revisão externa pequena: Gemini CLI encerrou por timeout em 90s; OpenCode falhou por tools[*].eager_input_streaming.
• Backlog vivo: docs/backlog/BK-279-shortlink-automatico-campanhas.md.

[2026-04-29] BK-278: shortlinks rastreáveis para WhatsApp

• Criado short.php e config/shortlink_helper.php para gerar, resolver e rastrear links curtos de campanha.
• Adicionada regra de shortlink no .htaccess e no rewrite efetivo do Nginx da VPS.
• Gerados os links https://rionoteatro.com.br/1a2b e https://rionoteatro.com.br/9t66 preservando UTMs completas.
• Regenerados os CSVs da campanha com copy em português BR, acentuação correta e link curto.
• Canceladas as filas antigas importadas antes da copy final e importadas as filas v2 #3 e #4, ainda bloqueadas por global_kill_switch=true, dry_run_only=1 e sem aprovação.
• Validações: php -l, nginx -t, reload do Nginx, curl -L dos shortlinks, dedupe dos CSVs e processamento bloqueado por kill switch.
• Backlog vivo: docs/backlog/BK-278-shortlink-whatsapp-campanha.md.
• Changelog detalhado: docs/changelog/2026/CL-2026-04-29-BK-278-shortlink-whatsapp-campanha.md.

[2026-04-29] BK-277: dry-run WhatsApp Zona Norte com allowlist

• Criado admin/cron/whatsapp_campaign_dry_run_zona_norte.php para gerar dry-run da campanha de As Loucas do Meier sem disparo.
• A campanha segmenta compradores historicos de Teatro Miguel Falabella e Imperator, nao todos os teatros da Zona Norte; por padrao a query de destinatarios exige allowlist fixa 552199915551.
• Adicionados guardrails:
• script CLI-only;
• flags --send, --execute, --dispatch e --enviar abortam;
• nenhum helper/fila/webhook de WhatsApp e chamado;
• relatorios com destinatarios ficam em admin/runtime/campaigns/, ignorado pelo Git.
• Apos autorizacao do admin, o script ganhou --full-csv para gerar CSV completo sem allowlist, ainda sem qualquer rota de envio.
• O CSV final passou a deduplicar por WhatsApp normalizado, preservando o cadastro com compra historica mais recente.
• A mensagem no CSV passou a usar \n literal para manter uma linha por destinatario.
• Adicionado --expanded-csv para gerar CSV posterior de Zona Norte + Baixada, excluindo por WhatsApp normalizado quem ja entrou na base Miguel Falabella + Imperator.
• O CSV extra foi validado com 2503 WhatsApps unicos, 0 duplicados internos e 0 sobreposicao com a base dos 2 locais.
• Instalada fila profissional WhatsApp com kill switch global, dry-run por padrao, aprovacao nominal, ciclos randomicos de envio, footer obrigatorio de opt-out e opt-out inbound automatico.
• Auditoria final do commit 8d70565f5 confirmou global_kill_switch=true, campanhas v2 #3/#4 sem aprovacao real, sent_count=0, process --execute bloqueado por kill switch e smokes de footer/opt-out sem envio.
• Por autorizacao humana posterior, a campanha #3 foi aprovada para envio real e o global_kill_switch foi desligado, sem rodar process --execute; a campanha #4 segue bloqueada.
• Disparo real monitorado da campanha #3 enviou 15 mensagens, bloqueou 4 numeros sem WhatsApp ativo, pausou automaticamente por auto_failure_rate_21 e teve o global_kill_switch religado.
• Apos identificar telefones fora do DDD 21 no disparo, o fluxo foi corrigido para aceitar somente 5521 + 9 digitos, preferindo clientes.celular e usando clientes.telefone apenas como fallback valido; a fila tambem passou a prechecar /check-number antes de enviar.
• Backlog vivo: docs/backlog/BK-277-whatsapp-zona-norte-dry-run.md.
• Changelog detalhado: docs/changelog/2026/CL-2026-04-29-BK-277-whatsapp-zona-norte-dry-run.md.

[2026-04-28] BK-276: lock operacional local fora do GitHub

• docs/LOCK.md deixou de carregar estado vivo de locks e passou a ser apenas protocolo/template versionado.
• O estado operacional diario passa a ficar em docs/LOCK.local.md, ignorado pelo Git.
• Criado docs/LOCK.local.example.md como modelo versionado.
• Atualizados AGENTS.md, docs/AGENTS.md e docs/GIT_WORKFLOW.md para apontar o fluxo diario ao lock local.
• Changelog detalhado: docs/changelog/2026/CL-2026-04-28-BK-276-lock-local-fora-github.md.

[2026-04-28] BK-275: hotfix 502 no Gerar com IA do Texto para Audio

• Corrigido admin/modulos/campanhas/redes_sociais/texto_for_audio.php para o botao Gerar com IA nao aguardar provedores de IA dentro da requisicao web.
• Causa confirmada: o POST sincrono podia ficar preso em chamadas Gemini/Kimi/bridge por 75-120s e estourar o gateway.
• O botao principal e o Refazer com sugestao agora criam um job pendente em social_audio_jobs, redirecionam o admin e processam a IA em background.
• O fluxo Gerar TUDO (background) passou a reaproveitar o mesmo executor de job pendente.
• Apos teste real do job #13, o processamento passou a marcar processando antes de chamar IA e o timeout do bridge Gemini/Kimi foi reduzido para cair em fallback mais rapido quando o provedor travar.
• A tela do job ativo passou a mostrar alerta de status e auto-refresh enquanto o job estiver pendente ou processando.
• Apos o job #14, erros terminais do Gemini direto, como quota/billing/rate-limit, deixam de tentar o bridge e caem em fallback mais rapido com aviso mais fiel.
• Por decisao operacional posterior, o provider gemini do Texto para Audio deixou de usar chave/API Google e passou a chamar sempre o Gemini CLI logado na VPS.
• Validacao CLI: chamada PHP isolada retornou provider=gemini, model=gemini_cli_default e 3 versoes geradas.
• Validacao: php -l admin/modulos/campanhas/redes_sociais/texto_for_audio.php.
• Changelog detalhado: docs/changelog/2026/CL-2026-04-28-BK-275-hotfix-audio-copy-timeout-502.md.

[2026-04-27] Hotfix: feed pecas.xml inclui sessoes no ultimo dia da temporada

• Corrigido atualizar_feed.php para comparar DATE(sec_data) com fim_temporada ao montar os feeds Meta/Google.
• Causa confirmada: tab_sessoes.sec_data e datetime, enquanto pecas.fim_temporada e date; sessoes as 20h no proprio ultimo dia eram removidas do XML.
• Impacto confirmado: pecas.php listava 3 pecas ativas, mas pecas.xml publicava apenas Fanáticos; As Loucas do Méier e É Tudo Culpa Da Mãe ficaram fora por terem sessao unica no dia final da temporada.
• Feeds regenerados no servidor: pecas.xml, pecas_inteira.xml, ofertas.csv e offer.csv.
• Validacoes: php -l atualizar_feed.php; consulta SQL comparativa retornando 3 pecas; php atualizar_feed.php com itens=3; leitura local e via URL publica de https://rionoteatro.com.br/pecas.xml confirmando IDs 1509, 1493 e 1536.
• Changelog detalhado: docs/changelog/2026/CL-2026-04-27-hotfix-feed-pecas-ultimo-dia.md.

[2026-04-27] Hotfix crítico: valor unitário no Mercado Pago

• Corrigido o fluxo de rascunho do pedido para gravar pedidos.valor como valor unitário, não como total do pedido.
• Blindado o cálculo enviado ao Mercado Pago para detectar rascunhos antigos com total salvo em valor e cobrar somente valor_unitario * qtd.
• Ajustada a tela de checkout para exibir e inicializar PIX/cartão com o total protegido.
• Corrigidos rascunhos pendentes contaminados para evitar retomada de checkout com cobrança duplicada.
• Auditoria de impacto confirmou cobrança a maior nos pedidos #73731 e #73767; os estornos da diferença foram executados manualmente pelo admin.
• Validações: php -l em config/functions_new.php, pedido.php, pedido_pagseguro.php, action.php e checkout_pix.php; git diff --check; simulação local de cálculo pós-hotfix para #73731 e #73767.
• Changelog detalhado: docs/changelog/2026/CL-2026-04-27-hotfix-mercadopago-valor-unitario.md.

[2026-04-13] BK-271: restauração de agenda e carrossel compacto unificado

• eventos.php
• Restaurada a versão funcional da agenda (bkp_original_20260413-0354).
• Adicionado botão 'Voltar ao topo' com ícone oficial.
• Sincronizado o visual compacto do carrossel (Nome | Local | Classificação em uma linha).
• Sincronizado o comportamento de scroll direcional (some ao descer, aparece ao subir significativo).
• evento.php
• Alterada a frase do badge de venda externa para "VENDA EXTERNA | SEM PROMOÇÃO RIONOTEATRO".
• Unificado o visual compacto do carrossel e removido o botão grande de oferta.
• Implementada a lógica de scroll direcional, removendo a trava de visibilidade anterior.
• Estabilizado o offset fixo em 60px para ambos os arquivos.

[2026-04-12] BK-267: memória persistente de preço captado x corrigido

• admin/modulos/eventos/action.php passou a registrar overrides de valor do BOT em bot_valor_overrides quando o admin corrige um preço captado errado.
• o registro guarda, no mínimo:
• sugestão
• evento
• sessão/data
• valor captado
• valor corrigido
• bot/handlers/event_matcher.php passou a consultar essa memória antes de contar valor_alterado.
• resultado prático:
• se o BOT capturar novamente o mesmo valor errado já corrigido para aquela sessão, isso não volta como Alteração Detectada.

[2026-04-12] BK-267: hardening de unificação e nome editado do captado

• admin/modulos/eventos/action.php
• Unificar passou a forçar o evento destino para status = 'A'
• o merge agora também propaga para o destino o nome/sinopse/ficha/local editados pelo admin na sugestão captada
• o slug canônico do destino continua preservado

[2026-04-12] BK-267: conciliação preserva produtor/origem

• admin/modulos/eventos/action.php
• conciliar_vincular, conciliar_unificar, conciliar_aplicar_update e conciliar_reativar passaram a preservar origem e id_produtor atuais do evento destino
• admin/modulos/eventos/conciliacao.php
• a UI deixou de oferecer opções de migrar/assumir produtor nesta tela
• a tela passou a deixar explícito que a conciliação só atualiza conteúdo

BK-246 · Clarificação da janela real de lock em docs/LOCK.md

Data: 9 de Abril de 2026

Contexto operacional:

• a regra local de lock ainda deixava margem para manter o proprio docs/LOCK.md em LOCKED mesmo sem escrita ativa no arquivo.
• isso criava atrito desnecessario porque o quadro canonico precisava continuar disponivel para outros programadores registrarem seus arquivos.
• o alinhamento humano da rodada foi explicitar que espera por teste, autorizacao ou qualquer validacao externa nao justifica bloquear o quadro em si.

Ajustes aplicados:

• AGENTS.md
• a seção de lock por arquivo passou a declarar que docs/LOCK.md so fica LOCKED durante a janela real de edição do proprio arquivo;
• o fluxo obrigatorio ganhou a mesma regra nos passos de fechamento.
• docs/LOCK.md
• a seção Como usar passou a declarar expressamente a exceção operacional do proprio quadro;
• a seção Estados passou a registrar que o caso especial de docs/LOCK.md exige lock curto e funcional, não prolongado.

Validações:

• conferência textual dos trechos alterados em AGENTS.md
• conferência textual dos trechos alterados em docs/LOCK.md
• aplicação imediata da regra nas linhas abertas do BK-245

Referências:

• backlog vivo: BK-246-lock-md-so-durante-edicao-real.md
• changelog detalhado: CL-2026-04-09-BK-246-lock-md-so-durante-edicao-real.md

BK-245 · Hotfix de ultimo dia em peca.php

Data: 9 de Abril de 2026

Contexto operacional:

• a página pública de venda em peca.php considerava a peça encerrada logo após 00:00 do próprio fim_temporada quando o campo vinha salvo apenas como YYYY-MM-DD.
• isso fazia a vitrine cair cedo no layout enxuto de fora de cartaz mesmo durante o último dia válido da temporada.
• a validação funcional humana da rodada confirmou que esse era o comportamento observado em produção.

Ajustes aplicados:

• peca.php
• a regra de em_cartaz deixou de comparar strtotime($dtFim) diretamente com time();
• o arquivo passou a calcular dtFimTimestamp de forma defensiva:
• se fim_temporada vier como YYYY-MM-DD, o fim passa a ser interpretado como 23:59:59 desse dia;
• se no futuro o campo vier com horário real, o horário existente continua valendo.

Validações:

• php -l peca.php
• revisão do diff final isolado
• validação funcional humana no ar com confirmação de funcionamento

Referências:

• backlog vivo: BK-245-peca-ultimo-dia-fim-temporada.md
• changelog detalhado: CL-2026-04-09-BK-245-hotfix-ultimo-dia-peca.md

BK-244 · Hotfix de performance no painel de pedidos

Data: 9 de Abril de 2026

Contexto operacional:

• a tela painel/modulos/pedidos/index.php estava lenta no fluxo autenticado do cliente.
• a análise confirmou N+1 queries em pecas e tab_sessoes, além de leitura repetida de disponibilidade dentro da renderização.
• na mesma rodada, após o hotfix principal, o botão Carregar mais e os botões renderizados dinamicamente precisaram ser ajustados para voltar a funcionar e respeitar o tema dark atual.

Ajustes aplicados:

• painel/modulos/pedidos/index.php
• criados helpers locais read-only para validade e disponibilidade com cache por request;
• a listagem passou a pré-carregar peças, sessões, última sessão por evento, sessão atual por id_evento + data, totais comprados e configs mínimas antes do loop principal;
• removidas consultas repetidas a pecas e tab_sessoes dentro da renderização da listagem;
• o payload JS passou a usar status_label limpo para os cards carregados dinamicamente;
• o botão Carregar mais foi corrigido e o container da seção Todos foi fechado corretamente;
• os botões dinâmicos receberam ajuste visual local para respeitar o tema dark da tela atual.

Validações:

• php -l painel/modulos/pedidos/index.php
• revisão do diff final do arquivo
• validação funcional humana na própria sessão:
• abertura da tela mais rápida
• Carregar mais funcionando
• botões/cores coerentes com o tema dark

Referências:

• changelog detalhado: CL-2026-04-09-BK-244-hotfix-performance-painel-pedidos.md

BK-243 · Ajuste local da regra DONE vs UNLOCKED no LOCK

Data: 9 de Abril de 2026

Contexto operacional:

• a regra local ainda deixava margem para encerrar a linha criada pelo próprio BK como UNLOCKED.
• o alinhamento humano da rodada foi deixar DONE como padrão para a linha criada pelo BK atual e usar UNLOCKED apenas quando uma linha reaproveitada estiver sendo devolvida ao estado livre.

Ajustes aplicados:

• docs/LOCK.md
• a semântica de DONE e UNLOCKED foi esclarecida;
• a limpeza automática/manual de linhas DONE passou de 5 para 7 dias sem uso;
• as linhas abertas pelo BK-242 foram convertidas de UNLOCKED para DONE.
• AGENTS.md
• o protocolo do projeto foi alinhado para repetir a mesma regra prática em texto canônico.

Validações:

• conferência textual das regras em AGENTS.md e docs/LOCK.md
• conversão das linhas do BK-242 para o estado final correto da trilha

Referências:

• backlog vivo: BK-243-regra-done-vs-unlocked-lock.md
• changelog detalhado: CL-2026-04-09-BK-243-regra-done-vs-unlocked-lock.md

BK-242 · Inativação automática de peças vencidas no admin

Data: 9 de Abril de 2026

Contexto operacional:

• a listagem admin/modulos/pecas/index.php tratava a aba Ativas apenas por status = 'A'.
• por isso, peças com fim_temporada já encerrado continuavam aparecendo no admin quando o status não era limpo a tempo.
• o caso real da rodada foi a peça Bee Gees, Abba e Carpenters - Nos embalos de SÁBADO a noite (id=333), que ainda estava ativa mesmo tendo encerrado em 25/03/2026.

Ajustes aplicados:

• admin/cron/expired_pecas_status_helper.php
• criado helper compartilhado para localizar e inativar peças com status = 'A' e fim_temporada < CURDATE();
• adicionada guarda por lock e throttle curto para evitar reexecução excessiva.
• admin/modulos/pecas/index.php
• a rotina de saneamento passou a rodar antes da montagem da listagem do admin.
• admin/cron/sync_facebook_events.php
• a mesma rotina passou a rodar antes da sincronização com Facebook, com log quando houver atualização.

Validações:

• php -l admin/cron/expired_pecas_status_helper.php
• php -l admin/modulos/pecas/index.php
• php -l admin/cron/sync_facebook_events.php
• execução real da rotina no banco com 79 peças inativadas
• conferência posterior retornando 0 peças com status='A' e fim_temporada < CURDATE()

Referências:

• changelog detalhado: CL-2026-04-09-BK-242-inativacao-pecas-vencidas-admin.md

BK-241 · Hotfix da Central de Cancelamento para peças online

Data: 9 de Abril de 2026

Contexto operacional:

• a Central de Cancelamento de Sessão em admin/modulos/pecas/index.php havia voltado a divergir da vitrine pública.
• o select Espetáculo estava listando todos os eventos ativos, em vez de apenas as peças elegíveis de pecas.php.
• o select Sessão ainda incluía sessões antigas.
• a rodada também exigiu refinamento iterativo dos textos padrão enviados por WhatsApp.

Ajustes aplicados:

• admin/modulos/pecas/session_cancel_console_helper.php
• a elegibilidade pública foi centralizada em session_cancel_console_public_catalog_where();
• o select Espetáculo passou a espelhar a mesma regra comercial de pecas.php;
• a validação do event_id no backend passou a usar a mesma regra;
• o select Sessão passou a listar apenas sessões de hoje em diante;
• o envio passou a substituir {primeiro nome} pelo primeiro nome real do destinatário;
• as mensagens padrão do console foram alinhadas à copy final validada na rodada.
• admin/modulos/pecas/index.php
• comentário explícito deixado ao lado do select Espetáculo para evitar nova regressão por troca da fonte.
• docs/modules/pecas/KNOWN_TRAPS.md
• criado para registrar traps datados do módulo;
• incluída a regra de sempre comparar arquivo atual + bkp_original mais novo + backup antigo útil antes de reaproveitar trecho antigo.

Validações:

• php -l admin/modulos/pecas/session_cancel_console_helper.php
• php -l admin/modulos/pecas/index.php
• validação funcional incremental no admin com feedback humano durante a rodada

Referências:

• changelog detalhado: CL-2026-04-09-BK-241-hotfix-central-cancelamento-pecas-online.md

BK-240 · Upload rápido do admin com suporte a imagens

Data: 8 de Abril de 2026

Contexto operacional:

• a área admin/index.php de Upload Rápido de Arquivo aceitava apenas planilhas, documentos e formatos estruturados.
• a operação precisava subir também imagens jpg, jpeg e png sem quebrar a whitelist já existente.

Ajustes aplicados:

• admin/index.php
• o input de upload passou a aceitar jpg, jpeg e png;
• o texto de ajuda foi atualizado para refletir a nova whitelist.
• admin/upload_dashboard_arquivo.php
• a whitelist do backend passou a aceitar jpg, jpeg e png;
• a mensagem de erro foi alinhada à nova lista de formatos.
• imgs/20260408-224728-b1904ad8-logomarca-atelie-vo-neinha.png
• a imagem enviada no upload real da rodada foi movida de /arquivos/download/ para um caminho estável em imgs/.

Validações:

• php -l admin/index.php
• php -l admin/upload_dashboard_arquivo.php
• validação funcional com upload real de imagem no admin

Referências:

• changelog detalhado: CL-2026-04-08-BK-240-upload-rapido-admin-imagens.md

BK-239 · Unificacao documental de docs com AGENTS como entrada principal

Data: 8 de Abril de 2026

Contexto operacional:

• a camada /docs estava com onboarding fragmentado entre docs/AGENTS.md, docs/README.md e docs/00_SITEMAP_DOCUMENTACAO.md.
• parte dessa trilha ainda carregava referencias quebradas e descricao desalinhada do estado real do repositorio apos a limpeza recente de legados.

Ajustes aplicados:

• docs/AGENTS.md
• consolidado como ponto de entrada principal de /docs;
• passou a concentrar onboarding, fontes de verdade, mapa rapido e regras de manutencao da camada documental.
• docs/README.md
• reduzido a stub minimo de redirecionamento para docs/AGENTS.md e docs/00_SITEMAP_DOCUMENTACAO.md.
• docs/00_SITEMAP_DOCUMENTACAO.md
• reescrito para descrever apenas o estado real atual de docs/;
• deixou de tratar como referencia atual arquivos removidos, ausentes ou historicos.

Validações:

• conferência local de existencia dos links principais citados no novo AGENTS e no novo SITEMAP
• revisão da direção proposta com segunda opinião externa trazida via OpenCode pelo usuário, filtrando os itens realmente stale dos falsos positivos

Referências:

• changelog detalhado: CL-2026-04-08-BK-239-docs-agents-readme-sitemap.md

BK-236 · Fechamento do produtor sem seletor de período e sem RG

Data: 8 de Abril de 2026

Contexto operacional:

• a tela produtor/fechamento.php ainda permitia ao produtor trocar manualmente o período do relatório e exibia o RG dos compradores na planilha.
• na mesma rodada, a ação de WhatsApp precisava ser simplificada para um texto curto de aprovação do fechamento, em vez de abrir uma mensagem longa com todo o resumo novamente.

Ajustes aplicados:

• produtor/fechamento.php
• o seletor de período foi removido e a página passou a exibir apenas o mês vindo pela query m=YYYY-MM;
• o RG saiu da consulta SQL e da tabela renderizada para o produtor;
• o botão foi renomeado para Aprovar via WhatsApp;
• a mensagem do WhatsApp passou a abrir em formato curto:
• Fechamento da Peça {nome} aprovado!
• Valor Repasse (80%): R$ {valor}
• Segue PIX:
• Nome da conta:
• o e-mail financeiro@rionoteatro.com.br foi removido do rodapé da página.

Validações:

• php -l produtor/fechamento.php

Referências:

• changelog detalhado: CL-2026-04-08-BK-236-fechamento-produtor-whatsapp.md

BK-227 · Checkout de créditos com PIX, cartão MP e planos alinhados ao painel

Data: 8 de Abril de 2026

Contexto operacional:

• o módulo de painel/modulos/creditos/index.php ainda expunha um fluxo centrado só em PIX, com pacote teste de R$ 1, sem detalhar claramente o que cada valor entregava e sem aceitar cartão Mercado Pago dentro da própria tela.
• a operação também precisava alinhar os pacotes aos recursos premium reais do painel de eventos e exigir os mesmos dados de faturamento já usados no checkout principal para o cartão.

Ajustes aplicados:

• painel/modulos/creditos/index.php
• painel/modulos/creditos/action.php
• painel/modulos/creditos/callback_mp.php
• o pacote teste de R$ 1 foi ocultado e a tela passou a trabalhar com os planos reais 50, 200, 300 e 500;
• ao clicar no plano, a tela agora mostra o que aquele valor engloba, reaproveitando a lógica/copy dos recursos premium do painel de eventos;
• o usuário escolhe entre PIX e Cartão dentro da própria página;
• o PIX passou a abrir o QR Code em modal;
• o Cartão passou a usar o Brick oficial do Mercado Pago;
• foram adicionados os campos de faturamento exigidos pelo Mercado Pago para cartão: CEP, Telefone/Celular, Logradouro, Nº, Bairro, Cidade e UF;
• o backend de créditos passou a processar cartão Mercado Pago, consultar status da compra e reconciliar callback/webhook para PIX e Cartão;
• os textos dos pacotes e observações comerciais foram refinados conforme a regra operacional validada na sessão.

Validações:

• php -l painel/modulos/creditos/index.php
• php -l painel/modulos/creditos/action.php
• php -l painel/modulos/creditos/callback_mp.php
• node --check do JS inline sanitizado da tela de créditos

Referências:

• changelog detalhado: CL-2026-04-08-BK-227-creditos-pix-cartao-mercadopago.md

BK-225 · Ordem da vitrine de eventos separada por admin, produtor e bot

Data: 8 de Abril de 2026

Contexto operacional:

• a vitrine pública de eventos.php ainda agrupava tudo em apenas dois blocos: venda online/admin primeiro e o restante depois.
• a operação precisava destacar primeiro os eventos sob gestão do admin ou em parceria_online=1, depois os eventos aprovados de produtor e, por último, os eventos aprovados vindos do bot.

Ajustes aplicados:

• eventos.php
• o ORDER BY da listagem principal passou a priorizar em três níveis:
• admin e parceria_online=1
• produtor
• bot
• os filtros existentes de status, aprovação e janela de temporada foram preservados.

Validações:

• leitura da query principal em eventos.php
• php -l eventos.php
• consulta real na base confirmando os primeiros blocos na sequência admin/parceria -> produtor -> bot

Referências:

• changelog detalhado: CL-2026-04-08-BK-225-ordem-eventos-vitrine.md

BK-224 · Scroll horizontal mobile na lista de eventos do painel

Data: 7 de Abril de 2026

Contexto operacional:

• em telas mobile, a tabela de painel/modulos/eventos/index.php estourava a largura disponível e quebrava o layout da página.

Ajustes aplicados:

• painel/modulos/eventos/index.php
• a tabela passou a ficar dentro de um wrapper com overflow-x: auto no mobile;
• a largura mínima da tabela foi preservada para evitar colapso das colunas.

Validações:

• leitura da estrutura da tabela no painel
• php -l painel/modulos/eventos/index.php

Referências:

• changelog detalhado: CL-2026-04-07-BK-224-mobile-scroll-painel-eventos.md

BK-223 · Hotfixes do fluxo produtor/admin de eventos e peças

Data: 7 de Abril de 2026

Contexto operacional:

• o painel do produtor ainda limitava upload de foto a 5MB, mantinha imagens em pending_eventos sem promover para o caminho canônico em cenários de parceria online e permitia estados inconsistentes entre status, editado_produtor, origem e parceria_online.
• no admin, a fila de eventos precisava exibir melhor a mídia pendente, o dashboard precisava mostrar solicitações de exclusão, o save/approve precisava bloquear conflito de slug ativo e o módulo de peças precisava voltar a abrir previews válidos e permitir remover a gestão Admin quando apropriado.
• a VPS também estava sem agendamento ativo para o cleanup de imagens antigas, apesar do script já existir no repositório.

Ajustes aplicados:

• painel/modulos/eventos/incluir.php
• painel/modulos/eventos/editar.php
• painel/modulos/eventos/action.php
• upload de foto do produtor elevado para 10MB, mantendo crop/resize antes de persistir;
• edição do produtor bloqueada quando parceria_online=1, com aviso explícito e link de WhatsApp do admin;
• slug passou a ser validado contra peças/eventos ativos antes de cadastrar ou editar;
• exclusão lógica do produtor passou a apagar mídia local imediatamente;
• quando o evento entra em parceria_online=1, a foto pendente é promovida para /arquivos/pecas/<id>/... no próprio fluxo do painel.
• admin/modulos/eventos/index.php
• admin/modulos/eventos/editar.php
• admin/modulos/eventos/action.php
• admin/index.php
• dashboard admin ganhou alerta para Solicitação de Exclusão;
• fila admin passou a priorizar foto pendente, depois foto publicada e por fim imagem externa;
• campo slug foi exposto para revisão/edição do admin;
• aprovação, criação e edição no admin passaram a barrar conflito com slug já ativo.
• admin/modulos/pecas/index.php
• admin/modulos/pecas/action.php
• previews inativos voltaram a abrir rota pública válida;
• ativar peça/evento em contexto admin agora zera editado_produtor;
• badge Admin passou a permitir remover a gestão admin e devolver o item ao produtor com parceria_online=0 e status=I.
• admin/cron/cleanup_old_pecas_images.php
• cleanup endurecido para reconciliar tb_fotos durante execução real.

Validações:

• php -l em todos os PHPs alterados
• validação humana do botão salvar no painel produtor
• validação humana do link real da coluna Nome no admin de peças
• execução real do cleanup:
• 241 arquivos removidos
• 9.37 MB liberados
• 242 registros removidos de tb_fotos
• segundo dry-run com 0 candidatos restantes

Referências:

• changelog detalhado: CL-2026-04-07-BK-223-eventos-pecas-hotfixes.md

BK-222 · Link publico real na coluna Nome das pecas ativas

Data: 7 de Abril de 2026

Contexto operacional:

• na listagem de admin/modulos/pecas/index.php, a coluna Nome das peças/eventos ativos ainda abria o preview interno do admin com evento.php?id=...&preview=1.
• para operação e conferência rápida, o clique precisava abrir a URL pública real do evento no site, como https://rionoteatro.com.br/<slug>.

Ajustes aplicados:

• admin/modulos/pecas/index.php
• a coluna Nome passou a usar a URL pública canônica https://rionoteatro.com.br/<slug> quando o item está com status = A;
• quando o slug estiver vazio, o link faz fallback seguro para https://rionoteatro.com.br/evento.php?id=<id> ou https://rionoteatro.com.br/peca.php?id=<id>;
• itens fora do ar continuam abrindo o preview legado com &preview=1.

Validações:

• leitura do trecho de montagem da coluna Nome em admin/modulos/pecas/index.php
• conferência da regra pública já usada em admin/modulos/eventos/index.php
• php -l admin/modulos/pecas/index.php
• validação funcional no admin confirmando a abertura do link público real

Referências:

• changelog detalhado: CL-2026-04-07-BK-222-links-publicos-pecas-ativas.md

BK-183 · Correção da validação de datas de temporada no painel

Data: 7 de Abril de 2026

Contexto operacional:

• a edição de evento no painel do cliente-produtor estava bloqueando o salvamento com a mensagem Datas de temporada invalidas. Use DD/MM/AAAA. mesmo com datas válidas preenchidas.
• a comparação com painel/modulos/eventos/incluir.php mostrou que o formulário de edição estava sem os IDs esperados pela validação JavaScript.

Ajustes aplicados:

• painel/modulos/eventos/editar.php
• adicionados apenas id="inicio_temporada" e id="fim_temporada" nos campos de data;
• patch reduzido ao mínimo necessário para alinhar o formulário de edição ao padrão de incluir.php.

Validações:

• leitura comparativa de painel/modulos/eventos/incluir.php e painel/modulos/eventos/editar.php
• php -l painel/modulos/eventos/editar.php
• teste real no navegador confirmando o salvamento sem o erro anterior

Referências:

• changelog detalhado: CL-2026-04-07-BK-183-align-temporada-ids.md

BK-201 · Automação social da peça nova + agenda operacional

Data: 3 de Abril de 2026

Contexto operacional:

• o fluxo de nova peça ainda estava parcial, com approvals inconsistentes, stories pesados, WhatsApp misturado com alertas e agenda sem edição operacional suficiente.
• a operação precisava validar o ciclo real: gerar approvals, aprovar, reagendar, editar e reagendar postagem na plataforma.

Ajustes aplicados:

• a primeira rodada automática da peça nova passou a abrir a trilha de facebook_feed, instagram_feed, threads_feed, facebook_story e instagram_story
• o número de approval de postagem foi segregado dos alertas gerais no WhatsApp
• o pipeline de copy ganhou bridge/pool local e a aprovação humana seguiu como gate obrigatório
• a agenda passou a mostrar queue_id, gatilho humano + código técnico, horário planejado completo e texto aprovado
• a agenda ganhou edição operacional de texto, mídia e agendamento para itens editáveis
• o modal da agenda passou a abrir o approval quando o item estiver em pending_approval e houver artifact
• o charset do fluxo foi alinhado para utf8mb4, corrigindo degradação de emojis na agenda
• facebook_feed em scheduled ganhou fluxo de Editar, cancelando o agendamento remoto e reabrindo o item para edição
• o fluxo de mídia passou a priorizar vídeo nos canais compatíveis e a alternar vídeo/capa por peça+canal na semana
• facebook_feed com vídeo do acervo local passou a subir o arquivo por upload binário, evitando dependência do file_url remoto para a Graph API
• a publicação no Instagram passou a aguardar o container de vídeo ficar pronto antes do media_publish, reduzindo o erro 9007
• instagram_feed passou a montar payload de REELS quando houver vídeo
• threads_feed passou a montar payload com video_url, ainda dependente de validação real porque o token do canal segue inválido

Validações:

• php -l em:
• admin/cron/sync_facebook_events.php
• admin/cron/ai_copy_helper.php
• admin/classes/FacebookEventService.php
• admin/modulos/campanhas/action_squad.php
• admin/modulos/campanhas/aprovar_squad.php
• admin/modulos/facebook/agendamento.php
• admin/modulos/facebook/agendamento-events.php
• admin/modulos/facebook/agendamento-update-status.php
• config/connect.php
• admin/data/__CLASS.SQL.php
• validação real de approval e fila para Fanáticos
• validação real de Editar em facebook_feed scheduled, com novo rascunho agendado na plataforma
• rerun real do queue_id 1024 (Fanáticos / facebook_feed) saindo do erro de fetch remoto do vídeo para publicação bem-sucedida
• rerun real dos instagram_story com vídeo (queue_id 1028 e 1029) saindo do 9007 Media ID is not available para publicação bem-sucedida

Referências:

• backlog vivo: BK-201-automacao-social-nova-peca-e-squad.md
• changelog detalhado: CL-2026-04-03-BK-201.md

BK-195 · Análise de mídia e tração 2024 x 2025 x 2026

Data: 1 de Abril de 2026

Contexto operacional:

• o projeto já tem snapshots históricos de Meta Ads e snapshots recentes de GA4, permitindo uma leitura inicial da perda de tração de mídia.

Ajustes aplicados:

• criado ANALISE_MIDIA_TRACAO_2024_2026.md
• criado BK-195-analise-midia-tracao-2024-2026.md
• criado CL-195-analise-midia-tracao-2024-2026.md

Validações:

• leitura dos snapshots persistidos em campanhas_metricas_importadas
• comparação do histórico retroativo do Meta com o snapshot recente de GA4

BK-194 · Add Peça com IA no admin de Peças

Data: 1 de Abril de 2026

Contexto operacional:

• o fluxo atual depende de texto recebido no WhatsApp + consulta manual do Sympla + preenchimento manual em pecas/detalhe.php.
• isso é útil, mas lento e repetitivo.
• o follow-up do mesmo dia fechou a tentativa interrompida de embutir a nova tela direto na aba de Peças.

Ajustes aplicados:

• criada a nova aba Add Peça com IA em index.php
• criada a tela dedicada add_ia.php
• a primeira fase já permite:
• colar o texto do WhatsApp
• extrair campos principais
• detectar o link do Sympla
• abrir rapidamente a conciliação e o link da venda oficial
• o embed da aba passou a:
• respeitar #tab-add-ia no carregamento
• manter o POST interno em modo embed
• abrir detalhe.php na janela principal quando o rascunho é promovido
• ajustar a altura do iframe no carregamento
• o fluxo de peça admin/parceria foi endurecido para:
• persistir origem='admin' no save do módulo de peças;
• exibir endereço + mapa em peca.php;
• exibir CTA operacional de WhatsApp em evento.php quando faltar contato cadastrado;
• gerar meta descriptions corretas mesmo quando a sinopse antiga vier com entidades HTML;
• fazer novos salvamentos do editor em UTF-8 normal, sem ó/ç
• publicado CL-194-embed-fix-add-ia.md

Validações:

• leitura do fluxo atual em painel/modulos/eventos/incluir.php
• leitura da conciliação em admin/modulos/eventos/conciliacao.php
• leitura da listagem e do formulário de peças em admin/modulos/pecas/index.php e detalhe.php
• php -l admin/modulos/pecas/index.php
• php -l admin/modulos/pecas/add_ia.php
• php -l admin/modulos/pecas/action.php
• php -l peca.php
• php -l evento.php
• php -l meta-analytics.php

BK-188 · Mapa operacional de GTM/GA4/Ads/Meta

Data: 31 de Março de 2026

Contexto operacional:

• O repositório acumulava tracking atual e legado em paralelo, o que dificultava entender com clareza quais tags e eventos ainda são canônicos.

Ajustes aplicados:

• criado MAPA_TRACKING_GTM_GA4.md
• o documento separa:
• containers/tags identificados
• eventos identificados
• arquivos centrais
• camada atual vs legado
• recomendações de manutenção

Validações:

• leitura do HTML público da home
• busca em código por gtag, dataLayer, fbq, send_to, GTM, GA4, UA e Ads

BK-189 · Google Ads em rascunho para aprovação humana

Data: 31 de Março de 2026

Contexto operacional:

• o tracking atual do RNT já permite orientar melhor campanhas de mídia paga.
• o operador quer ajuda das IAs na criação de anúncios, mas sem publicação automática e sem risco de surpresa na fatura.

Ajustes aplicados:

• criado PLANO_GOOGLE_ADS_RASCUNHO_APROVACAO.md
• o documento formaliza:
• uso do tracking atual como base de sugestão;
• campanhas e anúncios em modo rascunho;
• aprovação humana antes de qualquer publicação;
• proibição explícita de automação cega de gasto/orçamento.

Validações:

• leitura do mapa atual de tracking do RNT
• alinhamento do fluxo operacional com a preferência de aprovação humana antes de mídia paga

BK-190 · Padronização de ARCHITECTURE.md e GUIDELINES.md

Data: 31 de Março de 2026

Contexto operacional:

• o projeto já tinha material útil em .agent/ e .context, mas faltava uma dupla curta e explícita na raiz para reduzir custo de contexto.

Ajustes aplicados:

• criado ARCHITECTURE.md
• criado GUIDELINES.md

Validações:

• leitura da estrutura real do projeto
• alinhamento com o mapa atual de tracking, admin e cron

BK-191 · Rascunho inicial de Google Ads e Meta Ads

Data: 31 de Março de 2026

Contexto operacional:

• o RNT já tem tracking suficiente para apoiar uma primeira rodada de mídia assistida.
• a operação continua exigindo aprovação humana antes de qualquer publicação ou gasto.

Ajustes aplicados:

• criado RASCUNHO_INICIAL_GOOGLE_META_ADS.md
• o documento consolida:
• rascunho inicial de Google Ads
• rascunho inicial de Meta Ads
• sinais de tracking usados
• públicos, copies e guardrails

Validações:

• leitura do mapa atual de tracking
• leitura do plano de Google Ads em rascunho
• leitura do sistema de tracking/ROI já documentado no projeto
• alinhamento da regra operacional: toda peça com venda online entra em mídia; ROI governa reforço/manutenção/pausa

BK-192 · Modernizar Analytics para GA4 e Meta Ads API read-only

Data: 31 de Março de 2026

Contexto operacional:

• o projeto já tem base de campanhas, ROI, tracking UTM e integrações iniciais, mas a leitura de Analytics ainda está presa ao modelo antigo.
• para chegar a ROI real com liberdade operacional assistida por IA, é necessário ler GA4 e Ads de forma moderna e segura.

Ajustes aplicados:

• criado PLANO_GA4_META_ADS_API_READONLY.md
• o documento consolida:
• estado atual do projeto
• lacunas da trilha antiga
• arquitetura recomendada para GA4, Google Ads e Meta Ads
• guardrails e fases de implantação

Validações:

• leitura dos módulos atuais de Analytics antigo
• leitura dos pontos de entrada de Google Ads e Facebook Ads no projeto
• leitura do sistema de ROI e tracking UTM já existente
• alinhamento da regra operacional de elegibilidade por peça com venda online

BK-193 · Hardening de token Meta e preparação de Meta Ads read-only

Data: 31 de Março de 2026

Contexto operacional:

• a frente de Meta Ads ainda não está bloqueada só por “falta de integração”; existe também um problema de segurança/hardening, com token Meta hardcoded no código.
• o fluxo admin atual atende página/Instagram, mas não fecha sozinho a camada de Ads Insights.

Ajustes aplicados:

• criado BK-193-hardening-meta-token-e-ads-readonly.md
• o BK separa explicitamente:
• remoção do token hardcoded de notifications.php
• provisão de META_ADS_ACCESS_TOKEN
• provisão de META_ADS_AD_ACCOUNT_ID
• preparação do collector isolado meta_ads

Validações:

• leitura do wrapper facebook_ads.php
• leitura do fluxo admin de token em admin/modulos/facebook/configure.php e admin/modulos/facebook/token_exchange.php
• varredura segura por credenciais Meta e por indícios de ad_account_id

BK-187 · Governanca global em /root + no-pull automatico na VPS

Data: 30 de Março de 2026

Contexto operacional:

• O repositório local ainda induzia git pull automatico na VPS como preflight de governanca.
• A nova camada global em /root passou a coordenar a VPS, mas sem substituir a fonte da verdade local do RNT.

Ajustes aplicados:

• AGENTS.md
• passou a reconhecer explicitamente a camada global em /root;
• passou a exigir conferencia local de branch/base com git checkout main, sem git pull automatico;
• passou a descrever merge sobre o estado local mais atual validado na VPS.
• docs/GIT_WORKFLOW.md
• removeu git pull do preflight;
• passou a declarar que a VPS deve ser tratada como potencialmente mais atual que o remoto;
• ajustou exemplos de fluxo e worktree para nao induzir pull cego.

Validações:

• leitura integral e diff local de AGENTS.md
• leitura integral e diff local de docs/GIT_WORKFLOW.md
• git status -sb conferido para manter os itens do BK-186 fora deste recorte

BK-182 · Auditoria e reconciliacao de branches antigas + stash

Data: 27 de Março de 2026

Contexto operacional:

• O repositório local acumulava branches antigas, um worktree documental e um stash com funcionalidades úteis de campanhas ainda fora da main.
• A limpeza exigia auditoria por trecho para não perder conteúdo útil misturado a histórico antigo.

Ajustes aplicados:

• integrados trechos úteis do stash bk170-campanhas-pendentes no fluxo social/admin;
• integrados trechos úteis do BK-167 em scraper Sympla, runtime do WhatsApp e conciliação de eventos/teatros;
• incorporado o backlog vivo do BK-156 ao repositório principal;
• removidas ou preparadas para remoção as referências locais obsoletas após reconciliar o conteúdo.

Validações:

• php -l nos PHP reconciliados
• node --check bot/whatsapp/server.js
• git diff --check

BK-181 · Feed pecas_inteira.xml separado do feed principal

Data: 27 de Março de 2026

Contexto operacional:

• O pecas.xml passou a servir bem ao catálogo principal com price + sale_price.
• Para testes/catálogos alternativos com base no preço cheio, ficou necessário um segundo feed de produtos sem sale_price.

Ajustes aplicados:

• atualizar_feed.php
• passou a gerar pecas_inteira.xml;
• manteve pecas.xml como está;
• o novo feed publica apenas g:price com valor cheio.
• admin/modulos/pecas/action.php
• passou a retornar a URL e o timestamp do pecas_inteira.xml.
• .gitignore
• passou a ignorar pecas_inteira.xml.

Validações:

• php -l atualizar_feed.php
• php -l admin/modulos/pecas/action.php
• php atualizar_feed.php
• inspeção direta de pecas_inteira.xml

BK-180 · Feed de ofertas Meta adiciona min_quantity = 1

Data: 27 de Março de 2026

Contexto operacional:

• O Meta rejeitou AUTOMATIC_AT_CHECKOUT sem pré-requisito.
• A própria documentação oficial exige min_quantity ou min_subtotal para esse tipo de oferta.

Ajustes aplicados:

• atualizar_feed.php
• passou a emitir a coluna min_quantity;
• passou a preencher min_quantity = 1 no ofertas.csv e no offer.csv.

Validações:

• php -l atualizar_feed.php
• php atualizar_feed.php
• inspeção direta de ofertas.csv

BK-179 · Feed de ofertas Meta usa AUTOMATIC_AT_CHECKOUT

Data: 27 de Março de 2026

Contexto operacional:

• O ofertas.csv estava emitindo application_type = SALE, o que modelava a oferta como desconto direto sobre o preço do item.
• Para testar a categoria “Promoção” do Commerce Manager de forma mais fiel, o feed precisava usar aplicação automática no checkout.

Ajustes aplicados:

• atualizar_feed.php
• passou a emitir application_type = AUTOMATIC_AT_CHECKOUT no ofertas.csv e no offer.csv;
• manteve exclude_sale_priced_products = YES.

Validações:

• php -l atualizar_feed.php
• php atualizar_feed.php
• inspeção direta de ofertas.csv

BK-178 · Feed de ofertas Meta exclui produtos com sale_price

Data: 27 de Março de 2026

Contexto operacional:

• O feed de ofertas continuava modelado como desconto percentual por item.
• Para alinhar com a opção do Commerce Manager de não aplicar oferta sobre produtos já com sale_price, o arquivo precisava declarar isso explicitamente.

Ajustes aplicados:

• atualizar_feed.php
• passou a emitir a coluna exclude_sale_priced_products;
• passou a preencher essa coluna com YES no ofertas.csv e no offer.csv.

Validações:

• php -l atualizar_feed.php
• php atualizar_feed.php
• inspeção direta de ofertas.csv
• inspeção direta de offer.csv

BK-174 · Feed Meta com price cheio e sale_price promocional

Data: 26 de Março de 2026

Contexto operacional:

• O pecas.xml estava enviando apenas o valor promocional em price.
• Quando o feed de ofertas do Meta também entrava, o Commerce Manager aplicava desconto adicional sobre um valor já reduzido.

Ajustes aplicados:

• atualizar_feed.php
• passou a calcular price a partir do valor cheio (sec_valor_de quando maior que sec_valor);
• passou a enviar sale_price com o valor promocional real (sec_valor);
• mantém apenas price quando não houver diferença entre inteiro e promocional.

Validações:

• php -l atualizar_feed.php
• php atualizar_feed.php
• conferência direta do pecas.xml regenerado
• g:price e g:sale_price validados nos itens ativos

BK-172 · Feed de ofertas Meta separado do catálogo

Data: 26 de Março de 2026

Contexto operacional:

• O pecas.xml carregava corretamente como feed de produtos, mas falhava quando era reutilizado no Commerce Manager como feed de ofertas/promoções.

Ajustes aplicados:

• atualizar_feed.php
• manteve a geração do pecas.xml;
• passou a gerar também ofertas.csv e offer.csv com schema de promoções baseado em pecas.oferta.
• passou a incluir target_type = line_item, exigido pelo Meta para o subtipo de desconto de produto.
• meta-analytics.php, pedido.php, confirm_pagamento.php
• os eventos do pixel RNT CLICKS passaram a usar um helper explícito com trackSingle para fixar ViewContent, AddToCart, InitiateCheckout e Purchase no pixel 897210417852424.
• admin/modulos/pecas/action.php
• passou a confirmar também a geração dos feeds de ofertas;
• passou a retornar as URLs públicas dos arquivos promocionais.

URLs operacionais:

• https://rionoteatro.com.br/pecas.xml
• https://rionoteatro.com.br/ofertas.csv
• https://rionoteatro.com.br/offer.csv

Validações:

• php -l atualizar_feed.php
• php -l admin/modulos/pecas/action.php
• php atualizar_feed.php
• conferência direta de ofertas.csv
• validação da action regenerar_feed_xml

BK-171 · Feed XML respeita status e fim de temporada

Data: 26 de Março de 2026

Contexto operacional:

• O botão manual de regeneração do pecas.xml estava executando o gerador corretamente, mas o feed ainda precisava de uma regra mais rígida para impedir peças inativas, vencidas ou com sessão fora da temporada de entrarem no XML.

Ajustes aplicados:

• atualizar_feed.php
• o feed passou a exigir status = 'A';
• passou a exigir fim_temporada válido ou não vencido;
• passou a desconsiderar sessões futuras que ultrapassem fim_temporada.

Validações:

• php -l atualizar_feed.php
• php atualizar_feed.php
• validação do endpoint admin/modulos/pecas/action.php?act=regenerar_feed_xml
• conferência direta no pecas.xml regenerado

BK-165 · Feed XML no path correto + PalcoFan visível + conciliação Sympla alinhada

Data: 25 de Março de 2026

Contexto operacional:

• O pecas.xml do catálogo Meta estava sendo gravado com caminho relativo e podia cair na raiz da VPS dependendo do diretório de trabalho do cron.
• O bloco público do PalcoFan ainda mantinha os botões de login/cadastro com contraste ruim.
• O conciliacao.php do Sympla tinha perdido parte do fluxo manual que já existia no conciliacao_eventim.php, especialmente em vínculo manual e separação por fonte.

Ajustes aplicados:

• atualizar_feed.php
• a gravação do feed passou a usar caminho absoluto com base em __DIR__, garantindo pecas.xml na raiz do projeto.
• includes/inc_palcofan.php
• os botões Fazer Login e Cadastre-se grátis ganharam cores explícitas e contraste seguro sobre o bloco branco.
• admin/modulos/eventos/conciliacao.php
• passou a filtrar por fonte = 'sympla', alinhando a tela ao particionamento já existente no Eventim;
• recuperou formulários de vínculo manual em abas onde o Sympla tinha perdido esse fallback;
• voltou a expor, quando o item já existe como admin, a opção de manter como Admin ou migrar para BOT.

Auditoria complementar:

• O backend atual de conciliação ainda só persiste edições de sessões já existentes em bot_sessoes_sugestoes.
• Não há hoje suporte completo no action.php para criar uma sessão nova capturada do zero via UI, então o botão de “nova sessão” exige um follow-up próprio e não foi improvisado parcialmente nesta entrega.

Validações:

• php -l atualizar_feed.php
• php -l includes/inc_palcofan.php
• php -l admin/modulos/eventos/conciliacao.php
• git diff --check

BK-164 · PalcoFan no dashboard/peça + auditoria do pecas.xml

Data: 25 de Março de 2026

Contexto operacional:

• O fluxo do PalcoFan já existia, mas faltavam dois pontos práticos:
• o admin dashboard não sinalizava comentários pendentes de moderação;
• a página da peça não mostrava um minicard de avaliações aprovado no grid principal.
• Em paralelo, foi pedida uma auditoria do gerador do feed pecas.xml, sem alterar o script nesta rodada.

Ajustes aplicados:

• admin/index.php
• passou a consultar tb_avaliacoes com status = 'pendente';
• ganhou card/alerta com link direto para admin/modulos/comentarios/index.php.
• peca.php
• passou a consultar média/quantidade de avaliações aprovadas da peça;
• ganhou minicard Avaliações no grid superior quando houver pelo menos 1 comentário aprovado;
• o minicard aponta para a âncora da seção completa do PalcoFan.
• includes/inc_palcofan.php
• ganhou âncora explícita #palcofan-avaliacoes para receber a rolagem do minicard.

Auditoria executada sem alteração de código:

• atualizar_feed.php
• confirmado como o arquivo que gera o pecas.xml;
• a gravação continua usando caminho relativo em file_put_contents('pecas.xml', $xml).
• /www/server/cron/f1fb970e7ca0b68f38510abb76a86aa0
• confirmado como o wrapper do cron que dispara php -q /www/wwwroot/rionoteatro.com.br/atualizar_feed.php.

Resultado técnico observado:

• O dashboard do admin agora está pronto para acender quando houver comentário PalcoFan realmente em pendente.
• O minicard de avaliações aparece no topo de peca.php quando a peça tiver comentários aprovados e leva o cliente para a seção detalhada.
• Na auditoria atual do banco, a tabela tb_avaliacoes estava com 0 pendentes e 1 avaliação já aprovada para a peça 23, então o alerta do dashboard não acenderia nesse instante porque não há pendência real.

Validações:

• php -l admin/index.php
• php -l peca.php
• php -l includes/inc_palcofan.php
• render local de peca.php confirmando minicard + âncora
• leitura integral de atualizar_feed.php e do wrapper /www/server/cron/f1fb970e7ca0b68f38510abb76a86aa0

BK-160 · Carrossel semanal cover por peça

Data: 25 de Março de 2026

Contexto operacional:

• O feed semanal que sai do cron sync_facebook_events.php vinha empacotando até nove peças em um único mosaico, o que diluía a identidade visual de cada capa e obrigava o Instagram a replicar o mesmo grid pouco legível.

Ajustes aplicados:

• admin/cron/sync_facebook_events.php
• reduziu a seleção a 10 peças por semana e reaproveitou image_mtime para gerar cache key por peça.
• substituiu buildWeeklyCarouselSlides por um compositor que gera um JPEG 1080x1350 por peça e usa a capa como fundo em cover.
• manteve items[] compatível com createFeedCarouselPost e createInstagramCarousel, preservando a legenda e os UTM já existentes.
• passou a espelhar a vitrine de pecas.php na elegibilidade comercial da semana-alvo, sem exigir sessão cadastrada para a peça continuar no carrossel se a temporada ainda estiver válida.
• passou a aceitar weekly comercial com apenas 1 peça e usa PROMOÇÃO DA SEMANA! no singular nesse caso.
• separou a cadência operacional em dois fluxos:
• domingo -> approval comercial da segunda;
• segunda -> approval editorial da quarta.
• ganhou um segundo tipo de fila semanal para o carrossel editorial dos eventos mais acessados do site, sem misturar esse fluxo com o weekly comercial.
• passou a reaproveitar o payload visual do weekly carousel no approval, preenchendo preview real do primeiro slide e hash visual para evitar recriação cega do mesmo approval.
• deixou de promover automaticamente o weekly carousel para queued quando o item retorna de erro, preservando a aprovação humana como gate antes do publish.
• admin/modulos/campanhas/aprovar_squad.php
• passou a renderizar uma galeria com todos os slides quando o approval contém carousel_items, mantendo o preview simples para posts comuns.
• admin/modulos/campanhas/action_squad.php
• passou a respeitar headline singular/plural no refresh do weekly e a aceitar também o tipo semanal editorial.
• includes/inc_palcofan.php
• endurecido para exibir estrelas unicode clicáveis e CTA visível de avaliação, sem depender visualmente do Font Awesome nem de JS mais moderno.

Resultado técnico observado:

• O cron agora freelanca slides individuais do carrossel com rolagem lateral nativa, removendo o card 3x3 e dando destaque à arte oficial de cada peça.
• O payload segue aceito pelas APIs da Meta porque continua entregando items com imagem_url (até 10 itens) e o cache evita rebuilds desnecessários quando a capa não muda.
• O link de approval do weekly carousel deixa de ser cego: o operador passa a enxergar o preview do primeiro slide e a galeria completa antes de aprovar.
• A elegibilidade comercial da próxima segunda deixa de cair no falso negativo de sessão ausente e passa a refletir o catálogo comercial ativo de pecas.php.
• O PalcoFan volta a mostrar estrelas e CTA de envio de forma explícita mesmo em browser/mobile mais sensível.

Validações:

• php -l admin/cron/sync_facebook_events.php
• php -l admin/modulos/campanhas/aprovar_squad.php
• php -l admin/modulos/campanhas/action_squad.php
• php -l includes/inc_palcofan.php
• git diff --check

BK-159 · Correção de Layout Mobile na Lista de Compradores

Data: 21 de Março de 2026

Contexto operacional:

• O formulário de visualização da lista de compradores (produtor/listaopen.php) apresentava problemas graves de responsividade no mobile.
• A coluna de RG/Documento ficava oculta ou inacessível em telas pequenas.

Ajustes aplicados:

• produtor/listaopen.php
• Implementado container de rolagem lateral (overflow-x: auto) para a tabela.
• Adicionado aviso visual em vermelho ("Role a tabela para o lado ->") exclusivo para mobile.
• Forçado display: table-cell !important para a coluna de RG via CSS responsivo.
• Otimizado formulário de envio de e-mail e botões para touch.
• Adicionado format-detection="telephone=no" para evitar links automáticos em documentos.

BK-151 · Brand profile bootstrap do RNT

Data: 20 de Março de 2026

Contexto operacional:

• O Squad ainda trabalhava com contexto disperso de marca, campanha e CTA.
• O primeiro corte da entrega mostrava o resumo do profile na UI, mas o helper JSON ainda não garantia brandProfile no payload da run.

Ajustes aplicados:

• admin/modulos/campanhas/social_brand_profile.php
• criado como artefato canônico PHP 5.6-safe do perfil inicial de marca.
• admin/modulos/campanhas/social_squad_helper.php
• passou a incluir o artefato e injetar brandProfile no piece_context.
• admin/modulos/campanhas/redes_sociais_ui_helper.php
• passou a renderizar um resumo do profile ativo no workspace do Squad.

Resultado técnico observado:

• o payload do Squad passa a carregar um profile de marca explícito e reutilizável;
• a UI local e o helper JSON passaram a usar a mesma fonte de verdade;
• o profile fica pronto para reutilização nos próximos BKs sem crawler nem banco novo.

BK-150 · Loop de metricas do Squad com social_post_metrics_history

Data: 19 de Março de 2026

Contexto operacional:

• O RNT já tinha coleta de métricas sociais, mas o approval e a próxima run do Squad ainda não aproveitavam esse histórico.
• O primeiro corte do BK-150 ainda ancorava o resumo no queue_id atual, o que não resolvia o caso real de desempenho anterior antes da aprovação.

Ajustes aplicados:

• admin/modulos/campanhas/action_squad.php
• passou a anexar metrics_summary com base na última performance anterior útil por peca_id + canal compatível, excluindo o queue_id atual;
• separou current_queue_metrics para o caso em que o próprio item já possua histórico.
• admin/modulos/campanhas/aprovar_squad.php
• passou a exibir painel de desempenho anterior útil antes da aprovação.
• admin/modulos/campanhas/social_squad_helper.php
• ganhou helpers de consulta/resumo de métricas;
• passou a injetar lastPerformance no contexto da próxima run;
• ficou compatível com uso embedded sem responder JSON bruto.

Resultado técnico observado:

• o approval passa a mostrar performance anterior realmente útil;
• o artefato final preserva esse resumo em approved_payload;
• a próxima run do Squad recebe contexto resumido de performance sem tabela nova e sem cron novo.

BK-149 · Hardening de permissoes e arquivos runtime do social

Data: 19 de Março de 2026

Contexto operacional:

• O fluxo social ainda carregava dívida objetiva de permissões frágeis (0777/0666) em paths de runtime.
• O endurecimento cego para 0755/0644 quebraria parte do contrato multi-worker entre cron CLI e painel web.

Ajustes aplicados:

• admin/cron/sync_facebook_events.php
• passou a diferenciar arquivos compartilhados (lock, state) de artefatos read-only;
• diretórios compartilhados passaram a tentar 02775 com fallback explícito para 0777;
• arquivos compartilhados passaram a tentar 0664 com fallback explícito para 0666.
• admin/cron/sync_facebook_page_events.php
• alinhado à mesma política de diretórios compartilhados;
• queue/sample do fallback browser passaram a receber permissão de escrita compartilhada porque o painel de approval também regrava esses arquivos.
• docs/AI_CEREBRO_RELAY.md
• política canônica de permissões reescrita com checklist operacional e rollback.

Resultado técnico observado:

• o fluxo social ficou menos frágil sem romper o contrato de escrita cruzada root + www-data;
• falhas de permissão deixam rastro explícito em log;
• o relay deixou de recomendar 777 como política base.

BK-148 · Modularizacao segura de redes_sociais.php (fase 1)

Data: 19 de Março de 2026

Contexto operacional:

• admin/modulos/campanhas/redes_sociais.php concentrava blocos grandes demais de preparo/render, aumentando risco de manutenção.
• A fase 1 precisava extrair apenas os blocos de menor risco, sem reescrever a tela inteira.

Ajustes aplicados:

• admin/modulos/campanhas/redes_sociais.php
• passou a delegar leitura/render de blocos específicos para helper dedicado.
• admin/modulos/campanhas/redes_sociais_ui_helper.php
• criado para absorver preparo do estado da ponte social;
• preparo do fallback browser de FB Events;
• render do painel de fallback browser;
• render do Radar de Recomendacao;
• render do conteúdo superior da aba Squad Social.

Resultado técnico observado:

• a tela única da Central de Redes Sociais foi preservada;
• o módulo principal ficou menor e mais legível;
• a base ficou pronta para as próximas fases sem big bang rewrite.

BK-147 · Visibilidade operacional da ponte social na Central de Redes Sociais

Data: 19 de Março de 2026

Contexto operacional:

• A Central de Redes Sociais não mostrava claramente quando a ponte de copy com o Cérebro estava saudável, degradada ou indisponível.
• O caso de failover para bridge local podia ser lido como sucesso remoto, escondendo degradação real da operação.

Ajustes aplicados:

• admin/cron/ai_copy_helper.php
• passou a persistir telemetria mínima da ponte em admin/logs/ai_bridge_status.json;
• anota provider = remote|local e propaga ai_reviewed_local quando a resposta útil vier da bridge local.
• admin/modulos/campanhas/redes_sociais.php
• passou a ler o snapshot da ponte no topo da tela;
• exibe badges de estado SAUDÁVEL, DEGRADADA, INDISPONÍVEL e sinais separados para FALLBACK BRIDGE e FALLBACK HARDCODED.

Resultado técnico observado:

• o operador ganhou visibilidade direta do estado da ponte social sem runtime paralelo novo;
• o fallback local deixou de aparecer falsamente como operação saudável;
• a trilha documental canônica do BK-147 ficou regularizada no RNT.

BK-158 · Saneamento P0 de credenciais expostas

Data: 19 de Março de 2026

Contexto operacional:

• O repositório mantinha na raiz um relatório versionado com segredos literais reais.
• O .gitignore local precisava endurecimento mínimo para reduzir risco de versionamento acidental de variantes do .env.

Ajustes aplicados:

• CREDENCIAIS_EXPOSTAS_RELATORIO.md
• removido da raiz do projeto.
• docs/seguranca/credenciais-audit-20260213.md
• criado como versão sanitizada e canônica do relatório, com valores literais ofuscados.
• .gitignore
• endurecido para cobrir .env, .env.local, .env..local e */.env.

Resultado técnico observado:

• nenhum relatório explícito de credenciais permaneceu solto na raiz do repositório;
• o conteúdo útil foi preservado em trilha documental segura;
• a proteção contra commit acidental de arquivos de ambiente ficou mais explícita.

BK-132 · Endurecimento do fluxo de prova de Story manual/notificado

Data: 19 de Março de 2026

Contexto operacional:

• O fluxo de prova de Story manual dependia exclusivamente do draft_url para ser considerado sucesso. Falhas na extração do link pela automação de browser resultavam em perda de sinal operacional, mesmo quando o screenshot ou artefato útil existia.

Ajustes aplicados:

• Esquema de Banco:
• Adicionadas colunas profile_id, draft_url, notification_sent_at e notification_result à tabela social_post_queue para suporte nativo a metadados de prova.
• admin/cron/sync_facebook_events.php:
• Função rntExecuteBrowserStoryDraftProof agora aceita sucessos parciais (existência de screenshot/artefato) e sincroniza automaticamente os dados para as novas colunas diretas da fila.
• admin/modulos/facebook/agendamento-events.php:
• Consulta SQL atualizada para carregar os novos campos de prova.
• Função rnt_social_queue_extract_draft_proof refatorada para preferir dados estruturados das colunas e oferecer fallback visual detalhado no calendário.

Resultado técnico observado:

• Itens em modo notified agora exibem prova operacional útil na agenda admin, seja via link direto para rascunho ou via sinalização de screenshot disponível, reduzindo a necessidade de conferência manual cega.

BK-138 · Correção de Mídias Invisíveis e Datas no Squad Approval

Data: 18 de Marco de 2026

Contexto operacional:

• o painel de Aprovação de Squad Social (aprovar_squad.php) acusava a ausência de mídias/criativos para peças mesmo quando os links deveriam estar disponíveis, e as datas de agendamento estavam travadas na hora contínua do disparo da rotina, confundindo a operação.

Ajustes aplicados:

• admin/cron/sync_facebook_events.php
• alteração em rntResolvePecaPrimaryImageAsset para retornar um array estritamente vazio (array()) caso não encontre nenhuma capa física válida via @is_file, permitindo grace-degradation no visualizador do Squad.
• resgate do metadado scheduled_for nos geradores de cron planSiteEntryFeedQueue, planWeeklyCarouselQueue, e gatilhos de stories, passando avante essa data exata para reescrever o campo date do json de Aprovação com $meta['scheduled_for'].

Resultado técnico observado:

• próximas peças submetidas pelo Cerebro na fila do Approval possuirão links físicos estritamente confirmados (caso preenchido) ou omitidos (caso em falta), e exibirão os verdadeiros horários projetados para as plataformas ao invés dos horários de processamento.

BK-137 · Fluxo social reconciliado com gate criativo, WhatsApp e prova de rascunho

Data: 18 de Marco de 2026

Contexto operacional:

• o fluxo social ja tinha pecas importantes implantadas, mas seguia com dois problemas reais:
• a copy de approval caia em fallback generico porque nao havia endpoint criativo funcional;
• a tela de aprovacao do admin ainda nao mostrava bem o contexto comercial, a midia prevista e o parecer interno do criativo.
• ao mesmo tempo, o contrato do produto foi finalmente fechado: criativo -> review interno -> WhatsApp -> agenda -> draft/post -> conferencia final.

Ajustes aplicados:

• admin/cron/ai_copy_helper.php
• passou a apontar por padrao para http://127.0.0.1:9903/api/social-copy;
• ganhou fallback local e enrich de contexto com capa + pasta /arquivos/pecas/{id}/video;
• passou a preservar review, selected_media, selected_media_reason, creative_direction e commercial_summary.
• admin/cron/sync_facebook_events.php
• approval payload ficou mais rico;
• midia escolhida pelo Cérebro passou a ser preservada no approval e reaproveitada na fila;
• o fluxo de prova de rascunho/manual draft ficou refletido na agenda.
• admin/modulos/campanhas/aprovar_squad.php
• a tela de aprovacao passou a mostrar canal, origem, CTA, resumo comercial, midia prevista e revisao interna.
• admin/modulos/campanhas/action_squad.php
• passou a persistir os novos metadados do approval aprovado em approved_payload.
• admin/modulos/facebook/agendamento.php e admin/modulos/facebook/agendamento-events.php
• seguiram exibindo a prova de rascunho e o estado real da fila.

Resultado tecnico observado:

• o approval do WhatsApp deixou de depender de endpoint vazio.
• o admin passou a aprovar com muito mais contexto.
• o proximo passo ativo volta a ser operacional, nao documental: fechar notificacao pos-publicacao e endurecer o story browser flow.

Validacoes executadas:

• php -l admin/cron/ai_copy_helper.php
• php -l admin/cron/sync_facebook_events.php
• php -l admin/modulos/campanhas/aprovar_squad.php
• php -l admin/modulos/campanhas/action_squad.php
• php -l admin/modulos/facebook/agendamento.php
• php -l admin/modulos/facebook/agendamento-events.php
• git diff --check

BK-136 · Governanca compartilhada de auto-fechamento e backlog->changelog

Data: 18 de Marco de 2026

Contexto operacional:

• depois de formalizar no Cérebro a regra de auto-fechamento de BK concluido e a semantica correta de backlog vivo versus changelog historico, o Rio no Teatro precisava receber o mesmo protocolo para eliminar divergencia entre os dois repositorios.
• a auditoria local mostrou duas lacunas principais:
• ainda havia texto permitindo hotfix direto na main em alguns trechos, apesar da regra da VPS ja exigir branch;
• ainda faltava explicitar aqui que backlog vivo e changelog detalhado devem caminhar juntos no fechamento do BK.

Ajustes aplicados:

• AGENTS.md
• passou a declarar que hotfix na VPS continua em branch obrigatoria;
• passou a exigir backlog vivo em docs/backlog/ e changelog detalhado em docs/changelog/;
• passou a mandar comparar /www/wwwroot/rionoteatro.com.br com /root/cerebro antes de alterar regra compartilhada;
• passou a exigir que BK concluido, auditado e validado siga ate merge/push/unlock no mesmo atendimento.
• docs/GIT_WORKFLOW.md
• ganhou o fluxo BK->CL no passo a passo do branch workflow;
• endureceu o fechamento automatico apos reconciliacao e auditoria de conteudo aprovadas;
• esclareceu que deploy direto fica restrito a fora da VPS.
• docs/BACKLOG.md
• passou a deixar explicita a semantica de backlog vivo e changelog historico;
• recebeu o fechamento do BK-136 como regra operacional permanente.
• docs/LOCK.md
• ganhou locks do BK-136 e passou a explicitar o significado operacional de UNLOCKED.

Resultado tecnico observado:

• Cérebro e Rio no Teatro ficam alinhados na mesma governanca para:
• branch obrigatoria na VPS;
• auditoria por hunk;
• backlog vivo + changelog detalhado;
• fechamento completo do BK no mesmo atendimento.
• isso reduz drift documental e evita retrabalho quando a CLI começa em um repo e depois migra para o outro.

Validacoes executadas:

• leitura integral e reconciliacao textual de AGENTS.md, docs/GIT_WORKFLOW.md, docs/BACKLOG.md, docs/CHANGELOG.md e docs/LOCK.md
• comparacao de governanca com /root/cerebro
• git diff --check

BK-135 · Protocolo canonico de auditoria por hunk antes de limpeza Git

Data: 18 de Marco de 2026

Contexto operacional:

• auditorias recentes de branch/worktree/stash mostraram o mesmo risco recorrente: um unico arquivo pode misturar, ao mesmo tempo, trecho novo e util, regressao, backup operacional e ruido de modo/ambiente.
• o erro de processo que precisava ser eliminado era decidir "descartar o arquivo" em vez de decidir por trecho de codigo.
• como a CLI costuma iniciar por este repositório e o AGENTS.md e a referencia primaria das IAs, a regra foi endurecida aqui de forma explicita.

Ajustes aplicados:

• AGENTS.md
• passou a declarar como proibicao absoluta descartar arquivo inteiro apenas porque a branch/worktree/stash parece antiga;
• formalizou que a unidade de decisao e o hunk, nao o arquivo;
• exigiu classificacao de cada diferenca em util e atual, util mas precisa adaptacao, regressao ou lixo/backup/legado;
• passou a exigir conclusao explicita de que nao sobrou nenhum hunk util fora da main antes de qualquer limpeza.
• docs/GIT_WORKFLOW.md
• ganhou a secao canonica Auditoria de Conteudo Antes de Merge ou Limpeza;
• passou a listar comandos minimos para auditar branch/worktree/stash contra a main atual e contra a base comum (merge-base);
• passou a instruir a mescla manual apenas dos hunks uteis na versao mais nova do arquivo.
• docs/BACKLOG.md
• recebeu o fechamento do BK-135 como regra operacional permanente.

Resultado tecnico observado:

• o protocolo deixa de permitir a simplificacao errada de "arquivo antigo => apagar tudo".
• futuras limpezas de branch, worktree, stash, tag de archive ou patch temporario passam a exigir triagem por trecho de conteudo.
• quando um arquivo misturar antigo + novo, a acao correta passa a ser montar uma nova versao com o melhor dos dois lados e so entao limpar o restante.

Validacoes executadas:

• leitura integral e reconciliacao textual de AGENTS.md, docs/GIT_WORKFLOW.md, docs/BACKLOG.md e docs/LOCK.md
• git diff --check

BK-104 · Fallback browser operacional para Facebook Page Events

Data: 17 de Marco de 2026

Contexto operacional:

• a RCA do Graph API permaneceu a mesma: POST /{page_id}/events segue bloqueado com code 100 / subcode 33.
• o desbloqueio real passou a depender do BK-129 no Cérebro, que agora ja possui:
• storage state autenticado fora do repo;
• probe autenticado validado;
• create-flow em modo seguro sem publicacao.

Ajustes aplicados:

• admin/cron/sync_facebook_page_events.php
• quando o probe do Graph continuar bloqueado, o cron agora monta a fila operacional do fallback browser em admin/runtime/facebook_page_events_browser_queue.json;
• o mesmo fluxo tambem grava um payload sample em admin/runtime/facebook_page_events_browser_sample_input.json;
• o snapshot inclui:
• profile_id;
• storage_state_path;
• output_root;
• lista de pecas elegiveis com event_title, event_url, start_iso, description, venue_name e cover_image_url;
• comandos prontos para probe e create-flow no Cérebro.
• admin/modulos/campanhas/redes_sociais.php
• a Central de Redes Sociais passou a exibir o status do fallback browser quando a fila runtime existir;
• a tela agora mostra:
• quantidade de itens preparados;
• motivo do bloqueio do probe;
• caminhos do snapshot/payload sample;
• comandos exatos para rodar o browser control autenticado no Cérebro.

Resultado tecnico observado:

• o BK-104 deixa de parar no diagnostico do Graph e passa a entregar um handoff operacional real para browser automation.
• o admin continua sem publicar nada automaticamente na Meta por este caminho.
• o create-flow fica seguro para endurecimento iterativo: primeiro draft/evidencia, publish apenas quando houver gate humano decidido.

Validacoes executadas:

• php -l admin/cron/sync_facebook_page_events.php
• php -l admin/modulos/campanhas/redes_sociais.php
• php admin/cron/sync_facebook_page_events.php
• confirmacao do snapshot runtime gerado em admin/runtime/facebook_page_events_browser_queue.json
• git diff --check

BK-104 · Probe e hardening do cron de Facebook Page Events

Data: 17 de Marco de 2026

Contexto operacional:

• o fluxo legado de Page Events ja tinha evidenciado leitura ok em GET /{page_id}/events, mas seguia falhando na criacao em POST /{page_id}/events com GraphMethodException code 100 / subcode 33.
• a verificacao de runtime foi repetida no ambiente atual com a propria configuracao da pagina:
• GET /{page_id}/events continua retornando eventos reais;
• um POST /{page_id}/events propositalmente vazio, portanto incapaz de criar qualquer evento, devolve o mesmo Unsupported post request ... code 100 / subcode 33.
• isso fecha a RCA do caminho Graph API atual: o bloqueio nao e apenas payload faltando, e sim operacao nao suportada/perdida para este contexto de pagina/token.

Ajustes aplicados:

• admin/classes/FacebookEventService.php
• ganhou probePageEventsCreateSupport() para testar o POST /{page_id}/events de forma segura, sem payload minimo de criacao;
• o service agora classifica o retorno entre:
• unsupported_endpoint;
• permission_denied;
• validation_error_only;
• unknown_error.
• admin/cron/sync_facebook_page_events.php
• passou a rodar o probe antes de qualquer cleanup/create/update;
• ganhou o modo probe_only=1;
• quando o endpoint continua bloqueado, o cron aborta cedo com diagnostico explicito, sem fingir sucesso operacional e sem tentar mutacoes na pagina.
• admin/modulos/campanhas/redes_sociais.php
• o botao operacional foi reposicionado para:
• FB Events (probe);
• FB Events (sync);
• a tela agora explica que o cron faz probe seguro antes de qualquer tentativa real.

Resultado tecnico observado:

• o sistema deixa de tratar FB Events (real) como se o problema fosse apenas de payload.
• o operador passa a ver um diagnostico honesto:
• se o Graph API estiver morto, o cron para antes;
• se algum dia a Meta voltar a aceitar o endpoint, o sync pode seguir sem remover esse hardening.
• a conclusao pratica deste BK mudou:
• desbloqueio via Graph API nao esta acontecendo neste caminho;
• o proximo passo de automacao real para Page Events precisa migrar para browser automation/orquestracao pelo Cerebro.

Validacoes executadas:

• php -l admin/classes/FacebookEventService.php
• php -l admin/cron/sync_facebook_page_events.php
• php -l admin/modulos/campanhas/redes_sociais.php
• php admin/cron/sync_facebook_page_events.php probe_only=1
• php admin/cron/sync_facebook_page_events.php
• curl GET /{page_id}/events com token da pagina retornando eventos reais
• curl POST /{page_id}/events sem payload minimo retornando GraphMethodException code 100 / subcode 33
• git diff --check

BK-103 · TikTok no orquestrador social em modo manual/notificado

Data: 17 de Marco de 2026

Contexto operacional:

• com a trilha mysql_* do admin adiada durante a venda ativa, o proximo passo operacional foi liberar o TikTok dentro do orquestrador social sem depender de publicacao automatica por API.
• o objetivo deste BK foi encaixar TikTok na mesma fila social ja usada por Facebook/Instagram/Threads, mas com regra explicita de operacao manual/notificada.

Ajustes aplicados:

• admin/modulos/facebook/agendamento.php
• a agenda manual ganhou os canais TikTok Feed e TikTok Story;
• o modal passou a forcar modo = notified para TikTok;
• a UI passou a esconder o fluxo de preset story para TikTok, mantendo esse recurso apenas para stories Meta.
• admin/modulos/facebook/agendamento-create.php
• o endpoint passou a aceitar tiktok_feed e tiktok_story;
• canais TikTok agora gravam a fila como manual_notified, mesmo que o operador tente auto.
• admin/modulos/facebook/agendamento-events.php
• calendario/filtros/labels/icones passaram a reconhecer TikTok.
• admin/modulos/facebook/agendamento-update-status.php
• itens TikTok em status = notified podem ser concluídos como posted_manual pela mesma ação da agenda.
• admin/cron/sync_facebook_events.php
• o dispatcher passou a ler itens due de tiktok_feed e tiktok_story;
• quando chega o horario, o item vira notified e fica aguardando postagem manual;
• o resumo final do cron passou a contabilizar TikTok notificados (manual).
• admin/modulos/campanhas/redes_sociais.php
• a Central de Redes Sociais passou a refletir TikTok em labels, resumos e na acao de trazer stories manuais para agora.

Resultado tecnico observado:

• TikTok passa a existir como canal operacional da social_post_queue, sem introduzir automacao de publicacao fora do que o ambiente atual suporta.
• o fluxo padrao deste BK fica:
• agendar item TikTok na agenda manual;
• dispatcher promover para notified no horario;
• operador publicar no app e marcar como posted_manual.

Validacoes executadas:

• php -l admin/modulos/facebook/agendamento.php
• php -l admin/modulos/facebook/agendamento-create.php
• php -l admin/modulos/facebook/agendamento-update-status.php
• php -l admin/modulos/facebook/agendamento-events.php
• php -l admin/cron/sync_facebook_events.php
• php -l admin/modulos/campanhas/redes_sociais.php
• extracao do JS inline de admin/modulos/facebook/agendamento.php + node --check
• git diff --check
• teste seguro em transacao do banco para o ciclo queued -> notified -> posted_manual com tiktok_feed, seguido de rollback

BK-102 · Complemento de tracking publico com GTM/dataLayer

Data: 17 de Marco de 2026

Contexto operacional:

• com o BK-87 adiado durante venda ativa, a frente menos invasiva escolhida foi o BK-102, restrito ao tracking publico e sem tocar na migracao mysql_* remanescente do admin.
• o objetivo foi complementar os eventos faltantes e padronizar a camada de dados para GTM/GA4 sem desmontar os fallbacks ja existentes de gtag.
• por definicao operacional do projeto:
• a margem real de referencia do negocio e 15% do bruto;
• o valor enviado para Google/Facebook continua em 10% do bruto como sinal conservador de otimizacao de midia/ROI.

Ajustes aplicados:

• meta-analytics.php
• ganhou o helper canonico window.rntTrackGtmEvent;
• o helper passa a:
• clonar o payload recebido;
• montar ecommerce automaticamente quando houver currency, value, items, transaction_id e coupon;
• publicar no dataLayer com event = rnt_track_event e event_name separado, evitando acoplamento direto do GTM ao nome cru do evento;
• manter fallback para window.gtag('event', ...).
• peca.php
• view_item foi migrado para o helper canônico, preservando o fallback de gtag.
• pedido.php
• begin_checkout publico foi migrado para o helper canônico, preservando o fallback de gtag.
• evento.php
• o clique de compra externa passou a usar o helper canônico no onclick, com fallback para gtag.
• confirm_pagamento.php
• begin_checkout de pagamento pendente e purchase de pagamento confirmado passaram a usar o helper canônico;
• a regra de 10% ficou documentada como decisao deliberada de otimizacao de midia, e nao como margem operacional real.

Resultado tecnico observado:

• o site passa a expor uma camada de dados publica mais previsivel para GTM, sem remover o comportamento atual de GA4/Ads.
• os principais eventos de funil publico (view_item, begin_checkout, purchase) ficam padronizados no mesmo helper.
• a nomenclatura deixa explicito no codigo que:
• 10% e sinal conservador para a plataforma de midia;
• 15% permanece como referencia financeira interna do negocio.

Validacoes executadas:

• php -l meta-analytics.php
• php -l peca.php
• php -l pedido.php
• php -l evento.php
• php -l confirm_pagamento.php
• node --check /tmp/bk102_tracking_inline_check.js
• git diff --check
• curl em HTML publico confirmando o helper rntTrackGtmEvent renderizado

BK-134 · RCA e hardening do fluxo pos-compra com cupom, assento e cancelamento

Data: 16 de Marco de 2026

Contexto operacional:

• o incidente nasceu de uma compra real de teste com cupom de 100%, que expôs varios sintomas no mesmo fluxo:
• pedido sem leitura clara de voucher/pago no admin;
• cliente redirecionado para remarcar assento mesmo ja tendo assento salvo;
• assento inicial permanecendo bloqueado apos solicitacao de cancelamento;
• cancelamento pouco visivel no painel do cliente;
• parceiro de cupom ainda preso ao hardcode KM de Vantagens.
• a RCA confirmou que o desvio principal era de regra de negocio/estado entre modulos, nao um efeito primario da migracao mysql_* para mysqli.
• por exigencia operacional do BK, backups versionados _bkp_20260316. foram criados antes das edicoes manuais dos arquivos centrais.

Ajustes aplicados:

• config/functions_new.php
• novos helpers para:
• localizar pedido rascunho reaproveitavel no contexto do voucher;
• localizar cupom por pedido;
• reativar cupom dentro da validade;
• liberar assentos de rascunhos duplicados;
• calcular janela recente de reserva considerando o legado misto de timestamps locais/UTC.
• action.php
• register_voucher passou a:
• validar melhor o cliente logado;
• reaproveitar o pedido rascunho correto quando o cupom 100% vira compra gratis;
• absorver assentos do rascunho duplicado para o pedido pago quando necessario;
• preservar metadados do pedido/cupom;
• devolver ao front a response.url correta para o proximo passo.
• painel/modulos/pedidos/action.php
• cancelamento de pedido VOUCHER passou a:
• refletir cancelamento imediato;
• limpar assentos;
• reativar o cupom quando ainda estiver valido;
• preservar metadados e marcar o foco de retorno para o painel.
• painel/modulos/pedidos/index.php, painel/modulos/pedidos/assento.php, painel/modulos/pedidos/detalhe.php
• o painel do cliente passou a refletir melhor cancelamento/foco;
• a tela de assento usa a janela de reserva endurecida para nao tratar indevidamente o proprio pedido como nova selecao;
• o detalhe do pedido passou a exibir Celular no lugar do telefone legado.
• admin/modulos/pedidos_2/index.php e admin/modulos/pedidos_2/detalhe.php
• o admin passou a exibir com mais clareza:
• compra por Voucher;
• cupom associado;
• status efetivo de Solicitado Cancelamento ou Cancelada.
• js/voucher.js
• o fluxo free passou a respeitar a response.url decidida pelo backend, em vez de sempre mandar o cliente para o painel generico.
• admin/modulos/cupons/index.php, admin/modulos/cupons/action.php, admin/js/cupom.js
• o hardcode KM de Vantagens foi trocado para RIONOTEATRO como parceiro padrao (001);
• o modulo ganhou criacao/exclusao de parceiros dinamicos;
• o backend deixou de mutilar delete_partner por causa de anti_injection(), usando sanitizacao propria para act/id;
• o front passou a tratar erro AJAX sem deixar o modal travado em Excluindo Parceiro.

Resultado funcional observado:

• o pedido pago por voucher deixa de competir com rascunho paralelo por assento.
• o fluxo de cancelamento de voucher passa a:
• liberar assento;
• refletir melhor o estado no painel/admin;
• devolver o cupom dentro da validade, conforme regra definida na RCA.
• o modulo de cupons deixa de depender de parceiro hardcoded e volta a responder corretamente no ciclo criar -> excluir parceiro.
• saneamento do incidente real validado no banco:
• pedidos 73616 e 73617 ficaram cancelados e sem assentos presos;
• cupom 12899 voltou para status=1.

Validacoes executadas:

• php -l action.php
• php -l config/functions_new.php
• php -l painel/modulos/pedidos/action.php
• php -l painel/modulos/pedidos/index.php
• php -l painel/modulos/pedidos/assento.php
• php -l painel/modulos/pedidos/detalhe.php
• php -l admin/modulos/pedidos_2/index.php
• php -l admin/modulos/pedidos_2/detalhe.php
• php -l admin/modulos/cupons/index.php
• php -l admin/modulos/cupons/action.php
• node --check js/voucher.js
• node --check admin/js/cupom.js
• git diff --check
• reproducao controlada do endpoint de parceiros com sessao admin sintetica:
• create_partner retornando JSON de sucesso;
• delete_partner retornando JSON de sucesso apos a correcao do act.

BK-101 · Radar operacional de recomendacao social

Data: 16 de Marco de 2026

Contexto operacional:

• depois do fechamento do BK-95, a referencia canonica registrada no backlog com base no protocolo do AGENTS.md apontava BK-92 -> BK-95 -> BK-101 como sequencia imediata de retomada.
• a operacao social ja possuia historico tecnico em social_post_metrics_history, mas ainda faltava transformar esse volume em leitura pratica dentro da propria Central de Redes Sociais.
• o objetivo do BK-101 foi entregar um MVP de recomendacao orientado por evidencias reais de performance, sem criar cron novo nem depender de camada externa de BI.

Ajustes aplicados:

• admin/modulos/campanhas/redes_sociais.php
• ganhou o estado $social_recommendation_snapshot e helpers para:
• inferir perfil/tipo da peca por generos e fallback em categoria;
• normalizar labels de canal, formato, dia da semana e janela de postagem;
• calcular score operacional combinando alcance, engajamento e interacoes relevantes do snapshot.
• ganhou o builder rnt_social_build_recommendation_snapshot(...), que:
• verifica a existencia de social_post_metrics_history;
• puxa o ultimo snapshot conhecido por item de fila/post;
• consolida amostras por peca/perfil;
• ranqueia melhor canal, melhor janela e melhor formato com base na media de score;
• produz linhas de recomendacao por peca com indicador de confianca.
• a aba Operacao Social passou a renderizar o painel BK-101 · Radar de Recomendacao, com:
• cards de canal lider, janela lider, formato lider e cobertura da amostra;
• tabela por peca/perfil contendo fonte da recomendacao, melhor horario e nivel de confianca;
• fallback textual quando ainda nao existir historico suficiente.

Resultado funcional observado:

• a Central de Redes Sociais passa a exibir um resumo operacional reutilizavel a partir do historico real ja salvo pelo BK-100, sem obrigar a operacao a consultar banco manualmente.
• o painel destaca qual canal/janela/formato estao performando melhor no recorte conhecido e ainda preserva leitura por peca/perfil para orientar publicacao assistida.
• quando a base historica ainda nao for suficiente, o modulo nao quebra: exibe aviso explicando a falta de cobertura.

Validacoes executadas:

• php -l admin/modulos/campanhas/redes_sociais.php
• git diff --check
• inspecao estrutural do modulo apos o merge para confirmar:
• presenca do painel BK-101 · Radar de Recomendacao;
• uso do ultimo snapshot conhecido por post em social_post_metrics_history
• tentativa de smoke de runtime via bootstrap/CLI do modulo:
• bloqueada por autenticacao MySQL do bootstrap do admin neste contexto de terminal, entao a validacao de runtime ficou parcial

BK-95 · Healthcheck WhatsApp em 5 min com cron canônico reconciliado

Data: 16 de Marco de 2026

Contexto operacional:

• apos o fechamento do BK-92, a priorizacao do dia foi reaplicada no backlog com base no protocolo de triagem/execucao do AGENTS.md, puxando o BK-95 como proxima frente de operacao/venda.
• a auditoria do agendamento mostrou que o healthcheck real nao estava mais no desenho documentado:
• o job canonico do aaPanel (crontab.id=24, wrapper 86f580c4ec3c598ee051b7783bacf704) rodava de hora em hora, com bash;
• havia uma linha manual duplicada no root para 0 /2 /www/wwwroot/rionoteatro.com.br/bot/whatsapp/healthcheck.sh, mas ela falhava com Permission denied;
• o watchdog_systemd.sh ja estava agendado a cada 5 minutos, porem tambem falhava com Permission denied por falta de interpretador explicito na linha manual.
• o efeito pratico era drift operacional: a documentacao falava em 2h, o runtime executava 1h pelo aaPanel e os jobs manuais geravam ruido de erro sem entregar o comportamento esperado.

Ajustes aplicados:

• runtime aaPanel / cron
• o job WhatsApp Healthcheck do aaPanel (id=24) foi reconciliado para minute-n com cadencia de 5 minutos, preservando o wrapper oficial do painel e a execucao via bash;
• a linha manual duplicada de 2h para healthcheck.sh foi removida do crontab do root;
• a linha manual do watchdog_systemd.sh foi mantida em */5, mas passou a chamar bash /www/wwwroot/rionoteatro.com.br/bot/whatsapp/watchdog_systemd.sh para parar o Permission denied.
• docs/BACKLOG.md
• ganhou nota explicita de repriorizacao do BK-95, referenciando o gate de triagem do AGENTS.md.
• bot/whatsapp/SETUP_RESILIENCIA.md
• passou a documentar healthcheck canonico a cada 5 minutos via aaPanel com bash, incluindo a recomendacao de nao manter jobs paralelos duplicados;
• passou a registrar o watchdog_systemd.sh tambem com invocacao via bash.
• docs/documentacao_tecnica/WHATSAPP_HELPER.md
• foi atualizado para refletir o runtime atual via systemd, o papel do healthcheck como job de 5 minutos e o disparo sob demanda feito pelo helper PHP.

Resultado funcional observado:

• o healthcheck passou a ter uma unica fonte canonica persistente no aaPanel para a cadencia de 5 minutos;
• o cron manual deixou de carregar a linha redundante quebrada de 2h;
• o watchdog de 5 minutos deixou de depender do bit de execucao do arquivo para rodar no cron manual.

Validacoes executadas:

• sqlite3 /www/server/panel/data/default.db "select id,name,type,where1,where_hour,where_minute from crontab where id=24;"
• crontab -l | rg "86f580c4ec3c598ee051b7783bacf704|healthcheck\\.sh|watchdog_systemd\\.sh"
• bash /www/server/cron/86f580c4ec3c598ee051b7783bacf704
• bash /www/wwwroot/rionoteatro.com.br/bot/whatsapp/watchdog_systemd.sh
• tail -n 20 /www/wwwroot/rionoteatro.com.br/bot/whatsapp/healthcheck.log
• tail -n 20 /www/server/cron/rnt_whatsapp_watchdog.log
• git diff --stat

BK-92 · Hardening operacional do stack WhatsApp e notify_state

Data: 16 de Marco de 2026

Contexto operacional:

• A priorizacao do dia foi registrada no backlog conforme o protocolo de triagem/execucao do AGENTS.md, com foco imediato em operacao/venda no item BK-92.
• A evidencia coletada antes da alteracao mostrou que o servico rnt-whatsapp estava ativo e enviando, porem com housekeeping incompleto:
• fila zerada;
• 151 locks anti-spam com mais de 24h em bot/whatsapp/locks/;
• 4 arquivos ativos em admin/cron/logs/notify_state/, sem excesso no momento.
• O bot/whatsapp/healthcheck.sh dependia de uma API_KEY hardcoded, criando acoplamento fragil com o runtime real do microservico.

Ajustes aplicados:

• docs/BACKLOG.md
• ganhou nota explicita de priorizacao do BK-92, referenciando o fluxo orientado por AGENTS.md.
• includes/whatsapp_helper.php
• ganhou limpeza defensiva de locks anti-spam expirados, com cooldown para nao escanear o diretorio a cada envio.
• bot/whatsapp/healthcheck.sh
• passou a carregar BOT_WHATSAPP_API_KEY/WPP_API_KEY do ambiente e/ou .env, removendo dependencia de chave hardcoded no shell;
• passou a limpar locks anti-spam expirados e arquivos temporarios antigos de fila antes do processamento.
• admin/cron/cron_whatsapp_notify.php
• passou a executar auto-limpeza defensiva de notify_state no proprio fluxo de debounce, reduzindo dependencia exclusiva do cron noturno.
• admin/cron/limpar_notify_state.php
• foi endurecido com configuracao por ambiente, guarda de realpath, ignorando symlinks e reportando melhor o que foi preservado/removido.

Resultado funcional observado:

• o healthcheck passou a autenticar usando a chave vigente do runtime, sem depender de segredo hardcoded em shell versionado;
• a execucao manual segura do healthcheck removeu 149 locks anti-spam expirados de uma vez, reduzindo o diretorio para 12 locks totais (10 recentes e 2 ainda dentro da margem de seguranca de 25h);
• o notify_state ficou sob duas camadas de limpeza: auto-higiene no helper e cron dedicado como retaguarda, sem remover os 4 arquivos ainda dentro da janela valida.

Validacoes executadas:

• git status -sb
• systemctl status rnt-whatsapp --no-pager -n 40
• contagem objetiva de runtime:
• find bot/whatsapp/locks ... -> 151 locks com mais de 24h antes do hardening
• find admin/cron/logs/notify_state ... -> 4 arquivos ativos no recorte inicial
• php -l includes/whatsapp_helper.php
• php -l admin/cron/cron_whatsapp_notify.php
• php -l admin/cron/limpar_notify_state.php
• bash -n bot/whatsapp/healthcheck.sh
• execucao manual segura:
• bash bot/whatsapp/healthcheck.sh
• php admin/cron/limpar_notify_state.php
• php -r 'require "admin/cron/cron_whatsapp_notify.php"; ... cronNotifyCleanupState(...)'

BK-133 · Auditoria do archive/20260209 e plano de resgate

Data: 15 de Marco de 2026

Contexto operacional:

• Durante a limpeza de branches antigas do projeto, foi preservado no GitHub o snapshot archive/20260209-stash-fix-url-ajax-teatros, originado de um stash antigo que ainda nao tinha sido auditado contra a main.
• O protocolo novo passou a exigir auditoria de conteudo arquivo a arquivo antes de apagar branch, worktree ou stash, entao o snapshot foi tratado como material potencialmente valioso, nao como lixo operacional.
• Na sequencia, o mesmo protocolo foi aplicado tambem ao snapshot archive/20260206-stash-ci-caminho-remoto-deploy, para permitir limpeza final das branches remotas sem perda de historico.

Evidencia objetiva coletada:

• branch auditada: archive/20260209-stash-fix-url-ajax-teatros
• commit preservado: 764f0849c303bc1c4519d60da2e5ffbfe0e61430
• data original do commit arquivado: 2026-02-09 08:16:02 +0000
• push de preservacao no GitHub: 2026-03-15 19:26:15 -0300
• comparacao contra a main atual:
• 34.766 caminhos tocados pelo snapshot;
• 1 caminho igual na main atual (admin/data/setup.php);
• 14.386 caminhos com conteudo/modo diferente da main;
• 20.379 caminhos existentes apenas no snapshot arquivado.

Blocos candidatos a resgate dirigido:

• Roteamento publico / AJAX / admin-data: action.php, index.php, admin/data/Fotos.php, admin/data/Login.php, admin/data/__CLASS.SQL.php, admin/data/config.php, admin/data/functions.php, admin/data/urlAmigavel.php
• Bot captador / Sympla: bot/cron_captador.php, bot/scrapers/sympla_scraper.php
• Referencias auxiliares do snapshot: README.md, action.php.bak, index.php_bkp

Blocos explicitamente bloqueados para merge cego:

• vendor/ (20.152 caminhos, todos apenas no snapshot)
• admin/outros/ (9.910 caminhos, quase todos divergentes da main)
• painel/, img/, apps/, produtor/, PagSeguroLibrary/, phpmailer/ e legado amplo do front/admin
• arquivos de infra/estaticos (.well-known/, paginas de erro, modos de arquivo, backups velhos) sem incidente atual associado

Decisao operacional:

• o snapshot continua preservado em branch propria no GitHub e localmente;
• foi aberto o BK-133 para resgate dirigido, com escopo inicial restrito aos arquivos de maior sinal funcional;
• qualquer recuperacao de codigo a partir desse snapshot deve acontecer por revisao manual de diff, arquivo a arquivo, nunca por merge amplo do snapshot.

Resultado final da auditoria:

• no archive/20260209, o bloco action.php/index.php/admin/data/* auditado nao trouxe correcao funcional reaproveitavel; o que apareceu ali foi majoritariamente drift historico e mudanca de modo.
• as mudancas funcionais encontradas em bot/cron_captador.php e bot/scrapers/sympla_scraper.php nao foram portadas para a main, porque o diff contra a main atual mostrou regressao para uma versao mais antiga do captador/scraper.
• no archive/20260206, a auditoria apontou um snapshot muito amplo e historico, sem recorte seguro para merge automatico.
• como destino final, ambos os snapshots foram preservados por tags Git:
• archive-20260209-stash-fix-url-ajax-teatros
• archive-20260206-stash-ci-caminho-remoto-deploy
• com isso, as branches remotas archive/... ficaram aptas a delecao sem perda de rastreabilidade.

Documento de apoio:

• ver docs/BK-133-RELATORIO-RESGATE-ARCHIVE-20260209.md

Validacoes executadas:

• git show -s --format='%H%n%ci%n%cn%n%s' archive/20260209-stash-fix-url-ajax-teatros
• git reflog show --date=iso refs/remotes/origin/archive/20260209-stash-fix-url-ajax-teatros
• git rev-list --left-right --count main...archive/20260209-stash-fix-url-ajax-teatros
• auditoria por arvore Git (blobs/modos) comparando os 34.766 caminhos tocados pelo snapshot contra a main
• git diff --stat main archive/20260209-stash-fix-url-ajax-teatros -- README.md action.php admin/data/Fotos.php admin/data/Login.php admin/data/__CLASS.SQL.php admin/data/config.php admin/data/functions.php admin/data/urlAmigavel.php admin/data/setup.php bot/cron_captador.php bot/scrapers/sympla_scraper.php index.php
• git show -s --format='%H%n%ci%n%cn%n%s' archive/20260206-stash-ci-caminho-remoto-deploy
• git reflog show --date=iso refs/remotes/origin/archive/20260206-stash-ci-caminho-remoto-deploy
• auditoria por arvore Git comparando os 37.638 caminhos do snapshot 20260206 contra a main
• git tag -a archive-20260209-stash-fix-url-ajax-teatros ...
• git tag -a archive-20260206-stash-ci-caminho-remoto-deploy ...

BK-132 · Console de cancelamento por sessao em Peças

Data: 14 de Marco de 2026

Contexto operacional:

• O usuario pediu uma ferramenta no admin de Peças para cancelar apenas uma sessao especifica, sem mexer no espetaculo inteiro e sem disparos automaticos fora de confirmacao explicita.
• O fluxo precisava separar dois grupos no momento do aviso:
• compradores com status 3/4, com mensagem editavel antes do envio;
• pedidos sem pagamento concluido, com mensagem padrao.
• O ponto mais importante desta entrega foi governanca:
• nao executar nada sozinho;
• exigir preview antes de liberar o envio final.

Ajustes aplicados:

• admin/modulos/pecas/index.php
• nova area Central de Cancelamento de Sessão dentro da propria tela de Peças.
• fluxo com:
• seletor de espetaculo;
• seletor de sessao;
• textarea editavel para compradores 3/4;
• textarea padrao para pedidos nao concluidos;
• resumo visual com contagem de pedidos travaveis, clientes por grupo e avisos de celular ausente.
• o botao final fica desabilitado ate existir uma pre-visualizacao valida.
• admin/modulos/pecas/action.php
• novos acts:
• cancelamento_list_sessions
• cancelamento_preview
• cancelamento_execute
• o envio/travamento ficou encapsulado em endpoint proprio, separado dos fluxos antigos do modulo.
• admin/modulos/pecas/session_cancel_console_helper.php
• novo helper para:
• listar pecas/sessoes elegiveis;
• consultar pedidos por sessao;
• agrupar destinatarios por cliente;
• separar paid, unpaid e ignored;
• aplicar status_manual + status_transacao=2 somente quando o operador confirmar.
• query de sessoes endurecida para nao inflar abertos em sessoes sem pedido.
• texto default dos compradores ficou neutro/editavel, sem sugestao automatica de desfecho.

Resultado funcional:

• O admin passa a conseguir preparar cancelamento por sessao sem sair de admin/modulos/pecas/index.php.
• O operador ve antes do envio:
• quantos pedidos serao travados;
• quantos clientes estao em 3/4;
• quantos sao pedidos nao concluidos;
• quantos estao sem celular;
• quem ficou fora da regra.
• O envio final continua manual e confirmado.

Validacoes executadas:

• php -l admin/modulos/pecas/session_cancel_console_helper.php
• php -l admin/modulos/pecas/action.php
• php -l admin/modulos/pecas/index.php
• extracao do JS inline de admin/modulos/pecas/index.php + node --check
• teste funcional seguro do preview:
• listagem real de sessoes por event_id
• chamada real do act=cancelamento_preview para a sessao 2026-03-14 19:00:00
• sem disparo de mensagens nem update de pedidos nesta validacao

BK-131 · Agenda social story-first + resiliencia do Rodar Squad

Data: 14 de Marco de 2026

Contexto operacional:

• A operacao relatou dois desvios no mesmo fluxo social:
• o botao Rodar Squad na aba #tab-squad parecia nao responder quando a tela ainda estava conectando/bootstrapando;
• o planner social seguia empilhando feed recorrente por sessao, mesmo com a regra operacional atual pedindo Story como padrao e feed apenas como excecao.
• Na agenda manual, a criacao de nova postagem ainda abria em facebook_feed, empurrando a operacao para o canal errado.
• Na sequencia, a operacao acrescentou mais duas exigencias do mesmo eixo:
• o gatilho last_tickets precisava avisar o admin no WhatsApp a cada novo marco de 10 ingressos vendidos para a proxima sessao;
• a segunda-feira precisava ganhar um carrossel semanal multi-peca em feed, sem depender de montagem manual fora do sistema.

Ajustes aplicados:

• admin/modulos/campanhas/redes_sociais_squad.js
• a intencao de start passou a ficar pendente enquanto bootstrap/WebSocket nao estao prontos.
• ao concluir a conexao, a run e enviada automaticamente sem exigir novo clique do operador.
• erros de run_ack limpam o estado pendente para evitar reenvio fantasma.
• admin/modulos/campanhas/redes_sociais.php
• cache-buster do asset redes_sociais_squad.js atualizado para forcar o admin a carregar a versao corrigida.
• admin/modulos/facebook/agendamento.php
• o modal Nova postagem agora abre em instagram_story com modo auto.
• os canais de Story foram movidos para o topo do seletor.
• o texto operacional passou a reforcar que Story automatico e o padrao; notified fica reservado para casos de sticker/link manual.
• admin/cron/sync_facebook_events.php
• o planner entrou em politica story-first.
• a fila legada planner_session de feed recorrente passou a ser cancelada automaticamente para nao continuar gerando tentativas desalinhadas.
• foi criado o planejamento planner_site_entry, que preserva apenas um feed automatico inicial por peca/canal quando ainda nao existe registro valido (queued, scheduled ou posted).
• o restante da pressao operacional continua nos gatilhos automaticos de Story que ja existiam no cron.
• admin/cron/sync_facebook_events.php
• o gatilho last_tickets passou a levar milestone, sold e horario de sessao no payload.
• foi criado maybeNotifyLastTicketsMilestone() para enviar alerta ao admin via WhatsApp helper quando a proxima sessao atinge novo marco de 10+ ingressos vendidos.
• foi criado o tipo de fila planner_weekly_carousel, com agendamento automatico para segunda-feira 09:05.
• o dispatcher passou a montar e publicar o carrossel semanal diretamente da fila, em facebook_feed e instagram_feed.
• os slides do carrossel passaram a ser compostos em JPG pelo proprio cron, agrupando varias pecas por pagina para caber toda a semana no limite das plataformas.
• admin/classes/FacebookEventService.php
• ganhou createFeedCarouselPost() para publicar album/carrossel de varias imagens no Facebook Page Feed.
• ganhou createInstagramCarousel() para criar container CAROUSEL no Instagram e publicar depois via media_publish.
• admin/modulos/facebook/agendamento-events.php
• a agenda passou a renderizar o item semanal com nome amigavel (Carrossel semanal) e imagem institucional, em vez de exibir Peca #0.
• docs/BACKLOG.md
• foi aberto o BK-110 para a camada editorial/manual do carrossel semanal, cobrindo override de curadoria, ordem e slide de abertura.

Resultado funcional:

• O Rodar Squad deixa de depender do timing exato entre clique e conexao do WebSocket.
• A agenda manual passa a nascer no fluxo esperado pela operacao social atual.
• O cron deixa de insistir em feed recorrente por sessao e reduz o ruido que estava alimentando erro em fila para um comportamento mais proximo da regra de negocio pedida.
• Quando a proxima sessao cruza um novo patamar de venda (10, 20, 30...), o admin recebe alerta para preparar o Story de urgencia.
• A segunda-feira passa a ter carrossel semanal multi-peca planejado e publicado automaticamente no feed, com asset composto pelo backend e rastreio na mesma social_post_queue.

Validacoes executadas:

• php -l admin/classes/FacebookEventService.php
• php -l admin/cron/sync_facebook_events.php
• php -l admin/modulos/facebook/agendamento.php
• php -l admin/modulos/facebook/agendamento-events.php
• php -l admin/modulos/campanhas/redes_sociais.php
• node --check admin/modulos/campanhas/redes_sociais_squad.js
• extracao do JS inline de admin/modulos/facebook/agendamento.php + node --check

BK-100 · Metricas por postagem social com historico por item de fila

Data: 13 de Marco de 2026

Contexto operacional:

• A fila social (social_post_queue) ja persistia platform_post_id, mas nao existia historico de snapshots por item nem qualquer leitura de metricas por postagem no admin.
• A agenda social mostrava apenas status operacional e Post ID, o que resolvia publicacao/triagem, mas nao permitia comparar alcance, engajamento ou resposta real por canal.
• Havia ainda uma aresta importante no fluxo manual/notificado:
• quando o operador conclui sem informar ID real, a referencia continua como manual:*, o que precisa ser tratado como nao mensuravel em vez de quebrar o coletor.

Ajustes aplicados:

• admin/cron/sync_social_metrics.php
• novo cron dedicado para coletar metricas sociais sem inflar ainda mais o sync_facebook_events.php.
• cria/garante social_post_metrics_history e grava snapshot diario por queue_id.
• processa posted, posted_manual e scheduled ja vencidos, com janela de seguranca para itens agendados na plataforma.
• trata referencias manual:* e URLs soltas como skipped, preservando rastreabilidade sem gerar erro falso.
• admin/classes/FacebookEventService.php
• novos leitores de metricas por canal para Facebook, Instagram e Threads.
• leitura por metrica individual para tolerar respostas parciais da API sem derrubar o snapshot inteiro.
• payload bruto das plataformas passou a ser preservado junto do resumo normalizado.
• admin/modulos/facebook/agendamento-events.php
• agenda passa a anexar o ultimo snapshot de social_post_metrics_history por item da fila.
• tooltip/modal agora mostram resumo das metricas disponiveis e usam permalink real da plataforma quando retornado.
• admin/modulos/facebook/agendamento.php
• CTA do modal foi generalizado para Ver na plataforma.
• prompt de conclusao manual passou a deixar explicito que o ID real ajuda a manter o item mensuravel.
• sql_updates/create_social_post_metrics_history.sql
• script documental da nova tabela de historico de metricas.

Resultado funcional:

• Cada item elegivel da fila social pode acumular snapshots diarios de desempenho, em vez de sobrescrever um unico estado final.
• O operador passa a ver, na propria agenda social, se o item ja tem alcance/engajamento/resposta e quando a ultima coleta aconteceu.
• O coletor continua robusto em cenarios incompletos:
• ok quando houve retorno normal;
• partial quando parte das metricas volta e outra parte falha;
• skipped quando a referencia nao e mensuravel (manual:* ou URL sem resolucao);
• error quando a API nao entrega retorno utilizavel.

Validacoes executadas:

• php -l admin/classes/FacebookEventService.php
• php -l admin/cron/sync_social_metrics.php
• php -l admin/modulos/facebook/agendamento-events.php
• php -l admin/modulos/facebook/agendamento.php
• extracao do JS inline de admin/modulos/facebook/agendamento.php + node --check
• execucao controlada do novo cron via injecao do .env da arvore viva:
• php admin/cron/sync_social_metrics.php --limit=5
• resultado do primeiro run: sem candidatos elegiveis dentro do limite consultado

BK-129 · Fundo do carrossel + flutuacao mobile em evento

Data: 13 de Marco de 2026

Contexto operacional:

• O ajuste visual anterior do carrossel em evento.php melhorou contraste e CTA, mas o usuario percebeu que a faixa escura ainda parecia curta por tras do bloco.
• Na mesma rodada, tambem foi pedido para o carrossel continuar acompanhando a rolagem na versao mobile da pagina de evento.

Ajustes aplicados:

• evento.php
• .rnt-event-carousel-container recebeu box-sizing: border-box, min-height: 170px e padding maior para a faixa escura cobrir melhor a altura visual do carrossel.
• o ajuste responsivo em max-width: 991px passou a manter a faixa com min-height: 150px e padding proprio, em vez de apenas resetar o wrapper.
• .rnt-event-carousel-inner passou a ocupar width: 100%, com respiro lateral proprio tambem no mobile.
• a funcao atualizarEstadoFlutuanteCarrosselEvento deixou de desligar o modo flutuante em telas <= 991px.

Resultado funcional:

• A faixa escura do carrossel fica mais consistente por tras dos cards, evitando a sensacao de fundo "curto".
• O carrossel de ofertas da pagina de evento continua acompanhando o scroll tambem no mobile, seguindo a mesma logica de placeholder e offset do header.

Validacoes executadas:

• php -l evento.php
• extracao do trecho JS de sincronizarCarrosselEvento + node --check
• confirmacao por diff da remocao da guarda window.innerWidth <= 991

BK-105 · Hardening do fluxo manual Story na agenda social

Data: 13 de Marco de 2026

Contexto operacional:

• O fluxo de Story com sticker/link ja passava por notified, mas a conclusao manual ainda gravava posted, misturando no historico itens manuais com publicacoes feitas por API/agendamento.
• O endpoint agendamento-update-status.php aceitava mark_posted_manual apenas com queue_id, sem validar no servidor se o item ainda estava em status=notified.

Ajustes aplicados:

• admin/modulos/facebook/agendamento-update-status.php
• passou a validar canal de Story + tipo manual/notificado + status = 'notified' antes de concluir a publicacao manual.
• status final passou de posted para posted_manual.
• last_error e limpo na conclusao manual bem-sucedida.
• admin/modulos/facebook/agendamento-events.php
• agenda ganhou o status/filtro posted_manual como classe propria do historico.
• admin/modulos/facebook/agendamento.php
• filtro visual passou a expor Publicado manualmente.
• docs/BACKLOG.md
• BK-97 foi removido da lista ativa porque ja estava fechado no historico/codigo.
• a subtarefa remanescente do BK-105 foi marcada como concluida com o fluxo oficial queued -> notified -> posted_manual.

Resultado funcional:

• Stories manuais deixam de aparecer como posted generico na fila social.
• A trilha operacional fica mais auditavel:
• queued para fila;
• notified para acao manual aguardando operador;
• posted_manual somente depois da confirmacao humana.
• O bypass direto de queued para conclusao manual deixa de ser aceito pelo endpoint.

Validacoes executadas:

• php -l admin/modulos/facebook/agendamento-update-status.php
• php -l admin/modulos/facebook/agendamento-events.php
• php -l admin/modulos/facebook/agendamento.php
• validacao do JS inline de admin/modulos/facebook/agendamento.php por extracao do bloco <script> + node --check

BK-128 · Workspace Squad Social na Central de Redes Sociais

Data: 13 de Marco de 2026

Contexto operacional:

• O runtime multiagente do Cerebro ja estava pronto para squads, mas o operador do RNT ainda precisava sair do admin para iniciar e revisar runs.
• A necessidade desta fase era abrir um workspace proprio dentro de redes_sociais.php para:
• briefing humano;
• escolha de template/modo;
• historico de runs;
• decisao humana (approve / reject / rerun) sem sair da Central de Redes Sociais.
• O escopo foi mantido pragmatico:
• publish continua assistido;
• esta entrega nao automatiza a publicacao final dentro do RNT.

Ajustes aplicados:

• admin/modulos/campanhas/redes_sociais.php
• nova aba Squad Social adicionada ao lado de Operacao Social, Videos IA e Texto Audio Story.
• novo workspace com:
• seletor de peca elegivel;
• seletor de template do squad;
• modos economico e alta_performance;
• engines Codex, Gemini e Kimi;
• briefing persistido em localStorage;
• historico de runs da workspace;
• console com resumo da run, etapas, artefatos e timeline;
• acoes manuais approve, reject e rerun.
• admin/modulos/campanhas/social_squad_helper.php
• novo helper JSON para o front da aba.
• expõe:
• bootstrap do Squad (wsUrl, defaults, namespace de sessao, dashboardUrl);
• contexto leve da peca selecionada (local, bairro, proxima sessao, preco/oferta e briefing base).
• faz fallback do endpoint WS para wss://cerebro.seuimovel.rio.br/api/gateway quando nenhum env especifico estiver definido.

Resultado funcional:

• O operador passa a conseguir iniciar uma run do Squad Social sem sair do admin do RNT.
• A mesma tela agora mostra:
• templates disponiveis do projeto rionoteatro;
• runs recentes da workspace atual;
• console por etapa com timeline e artefatos;
• decisao humana de aprovacao ou devolucao para rework.
• O fluxo continua seguro para esta fase porque o publish segue assistido, sem automacao cega de postagem final.

Validacoes executadas:

• php -l admin/modulos/campanhas/redes_sociais.php
• php -l admin/modulos/campanhas/social_squad_helper.php
• node --check admin/modulos/campanhas/redes_sociais_squad.js

BK-127 · Ajuste visual do carrossel em evento

Data: 13 de Marco de 2026

Contexto operacional:

• Depois da correcao funcional do carrossel flutuante em evento.php, o usuario pediu apenas refinamento visual.
• Os dois pedidos foram objetivos:
• aplicar fundo escuro com transparencia na div do carrossel;
• reduzir a tipografia do CTA QUERO ESTA OFERTA.

Ajustes aplicados:

• evento.php
• .rnt-event-carousel-container passou a usar background: rgba(8, 16, 28, 0.86).
• foi adicionado backdrop-filter: blur(10px) para reforcar a leitura do bloco enquanto ele flutua sobre a pagina.
• o seletor .rnt-event-carousel-container .btn.btn-success passou a aplicar font-size: 11px.

Resultado funcional:

• O carrossel continua acompanhando o header/menu, mas agora com contraste visual mais claro como faixa destacada.
• O CTA interno fica menos pesado visualmente e ocupa menos area horizontal.

Validacoes executadas:

• php -l evento.php
• validacao HTTP real da URL https://rionoteatro.com.br/se-der-corda
• confirmada a presenca de:
• background: rgba(8, 16, 28, 0.86)
• font-size: 11px

BK-126 · Correcao do carrossel flutuante em evento

Data: 13 de Marco de 2026

Contexto operacional:

• A URL https://rionoteatro.com.br/se-der-corda foi usada como validacao real apos o merge do BK-125.
• O HTML mostrava o wrapper novo do carrossel, mas no navegador ele ainda nao acompanhava o menu durante o scroll.

Causa raiz confirmada:

• evento.php
• o wrapper do carrossel estava em position: sticky;
• mas, na pratica, ele ficava limitado ao #carousel-placeholder, que nao oferecia area de rolagem suficiente para sustentar o efeito ao longo da pagina.
• Resultado:
• o carrossel parecia normal/estatico mesmo com as classes e scripts presentes.

Ajustes aplicados:

• evento.php
• o modo flutuante passou a usar position: fixed quando o topo do placeholder e ultrapassado.
• o #carousel-placeholder passou a reservar dinamicamente a altura do carrossel (minHeight) para evitar salto de layout.
• a funcao window.sincronizarCarrosselEvento foi exposta e continua recalculando:
• altura do header;
• offset do topo;
• estado flutuante;
• altura reservada.
• no mobile o comportamento continua estatico.

Resultado funcional:

• O carrossel de evento.php deixa de depender do limite estrutural do placeholder.
• Em desktop, ele passa a acompanhar de fato o header/menu durante a rolagem.
• O conteudo abaixo nao "sobe" quando o bloco entra em modo flutuante.

Validacoes executadas:

• php -l evento.php
• validacao HTTP real da URL https://rionoteatro.com.br/se-der-corda
• confirmada no HTML a presenca de:
• window.sincronizarCarrosselEvento
• placeholder.style.minHeight
• position: fixed no estado .is-floating

BK-125 · Carrossel flutuante na pagina de evento

Data: 13 de Marco de 2026

Contexto operacional:

• O usuario pediu explicitamente para mexer apenas em evento.php.
• O comportamento desejado era manter o carrossel acompanhando o menu/header quando a pagina de evento fosse rolada para baixo.
• O carrossel ja existia no topo da pagina, mas era apenas injetado no placeholder e desaparecia completamente durante a navegacao pelo restante do conteudo.

Ajustes aplicados:

• evento.php
• criado um wrapper dedicado do carrossel (#rnt-event-carousel-shell) exclusivo da pagina de evento.
• o wrapper passou a usar position: sticky somente em desktop.
• o top nao ficou fixo em valor magico: um script passa a recalcular --rnt-event-carousel-offset a partir da altura real do .rnt-header.
• listeners de load, resize e scroll mantem o offset sincronizado com o estado do header, inclusive quando ele encolhe no modo scrolled.
• o carrossel ganha sombra leve ao entrar em estado flutuante para reforcar visualmente que esta acompanhando o topo.
• em mobile (max-width: 991px) o comportamento volta para estatico para evitar um bloco grande ocupando a viewport.

Resultado funcional:

• Em desktop, o carrossel da pagina de evento passa a acompanhar o header/menu durante a rolagem.
• O offset acompanha a altura real do header para evitar colisao visual.
• Em mobile, a experiencia permanece conservadora e sem sobrecarga de sticky.

Validacoes executadas:

• php -l evento.php
• validacao estrutural do arquivo renderizado para confirmar:
• #rnt-event-carousel-shell
• --rnt-event-carousel-offset
• listeners de load, resize e scroll

BK-124 · Hardening de fora de cartaz em metadados + comentarios operacionais

Data: 13 de Marco de 2026

Contexto operacional:

• O usuario reportou a URL https://rionoteatro.com.br/gonzaguinha-eterno-aprendiz como se ainda estivesse com cara de peca atual.
• A verificacao real mostrou um quadro misto:
• o corpo da pagina ja estava no layout enxuto de fora de cartaz;
• o <head> ainda anunciava a peca como evento ativo, com oferta antiga, imagem antiga e JSON-LD de evento agendado.
• Esse desalinhamento explicava muito bem a percepcao de pagina "atual" em cache, preview social ou snippet, mesmo quando o layout visivel ja estava correto em aba anonima.

Causa raiz confirmada:

• meta-analytics.php
• o arquivo gerava OG/Twitter/JSON-LD sempre como evento ativo para as paginas de peca.php.
• isso incluia:
• og:title com sufixo de oferta antiga;
• og:image com a capa historica da peca;
• event:start_time / event:end_time;
• JSON-LD TheaterEvent com EventScheduled.
• evento.php
• o bloco proprio de OG/Twitter tambem continuava tratando eventos fora de cartaz como event, reaproveitando imagem e descricao historicas.
• peca.php e evento.php
• o layout enxuto de fora de cartaz existia, mas a regra operacional de limpeza de assets apos 7 dias nao estava comentada no proprio ponto de decisao da pagina.

Ajustes aplicados:

• meta-analytics.php
• passou a detectar quando a peca publica esta fora de cartaz.
• nesse caso:
• og:type passa a website;
• og:title / twitter:title deixam de carregar oferta antiga;
• meta description informa que o espetaculo nao esta em cartaz no momento;
• og:image / twitter:image passam a usar img/logo_2023.png;
• event:start_time / event:end_time deixam de ser publicados;
• o JSON-LD troca TheaterEvent/EventScheduled por WebPage.
• evento.php
• o bloco OG/Twitter proprio dos eventos de produtor foi alinhado com a mesma regra de fora de cartaz:
• og:type=website;
• descricao neutra;
• imagem institucional em vez da capa antiga.
• peca.php e evento.php
• comentarios operacionais adicionados para deixar explicito que:
• 7 dias apos o fim da temporada, fotos/videos antigos devem ser removidos pelo cleanup;
• o layout canonico de fora de cartaz deve esconder foto e dados da temporada passada e manter apenas o aviso de indisponibilidade com outras pecas abaixo.

Resultado funcional:

• A URL historica deixa de se vender como evento agendado quando ja esta fora de cartaz.
• O corpo e o <head> passam a contar a mesma historia:
• pagina indisponivel no momento;
• sem oferta antiga;
• sem imagem antiga;
• sem structured data de evento ativo.

Validacoes executadas:

• php -l peca.php
• php -l evento.php
• php -l meta-analytics.php
• Validacao HTTP real da URL https://rionoteatro.com.br/gonzaguinha-eterno-aprendiz:
• corpo com Nao temos informacoes deste espetaculo no momento
• og:type=website
• og:title=Gonzaguinha - o Eterno Aprendiz | Rio no Teatro
• og:image=https://rionoteatro.com.br/img/logo_2023.png
• ausencia de event:start_time / event:end_time
• JSON-LD com @type=WebPage

BK-123 · Hardening do login admin com fallback sem JSON cru

Data: 13 de Marco de 2026

Contexto operacional:

• O endpoint admin/action.php do login foi desenhado para responder JSON.
• Quando o submit do formulario caia como POST tradicional, sem o JavaScript interceptar a resposta, o navegador exibia diretamente:
• {"status":"success","url":"...","message":"Direcionando ..."}
• O sintoma era intermitente: em tentativas seguintes o login voltava a funcionar, reforcando que a autenticacao em si nao estava quebrada; o problema estava no acoplamento entre o form e o JS.

Causa raiz confirmada:

• admin/login.php
• o formulario aponta direto para admin/action.php.
• admin/action.php
• o case 'login' respondia JSON tanto para sucesso quanto para erro, sem fallback para submit tradicional.
• admin/js/parsley-validate-form.js
• o redirect real dependia da interceptacao AJAX no front-end.
• Com isso, qualquer falha transitora de carregamento/cache/execucao do JS fazia o navegador receber o JSON cru do endpoint.

Ajustes aplicados:

• admin/action.php
• adicionada deteccao de requisicao AJAX por HTTP_X_REQUESTED_WITH.
• no case 'login':
• AJAX continua recebendo JSON;
• submit tradicional recebe 302 para index.php quando autenticado;
• submit tradicional recebe 302 para login.php?login_error=1 quando invalido.
• as respostas JSON do endpoint passaram a declarar Content-Type: application/json; charset=utf-8.
• admin/login.php
• adicionado helper local com filemtime() para versionar:
• js/jquery.js
• js/bootstrap.min.js
• assets/toastr-master/toastr.js
• js/plugins/parsley/parsley.js
• js/parsley-validate-form.js
• adicionado alerta visual simples quando a tela voltar com login_error=1.

Resultado funcional:

• O login admin passa a ter dois caminhos seguros:
• caminho principal: AJAX + redirect no front-end, como antes;
• caminho de contingencia: redirect HTTP nativo sem exibir JSON cru no navegador.
• O cache-buster reduz a chance de recorrencia por asset JS stale depois de deploy/ajuste.

Validacoes executadas:

• php -l admin/login.php
• php -l admin/action.php
• Validacao HTTP real do fallback:
• POST tradicional invalido para admin/action.php retorna 302 Location: /admin/login.php?login_error=1
• POST com header X-Requested-With: XMLHttpRequest continua retornando JSON (status=error)
• GET admin/login.php renderiza os scripts com sufixo ?v=...

Riscos residuais:

• O fallback por header() depende de nao haver output prematuro em includes futuros de admin/action.php.
• Este BK cobre apenas o fluxo login; remember e recovery continuam dependentes do fluxo AJAX legado.

BK-122 · Copy IA multi-formato na Central de Redes Sociais

Data: 12 de Marco de 2026

Contexto operacional:

• A Central de Redes Sociais já tinha fluxo semimanual forte para vídeo, mas o texto para locução ainda estava em modo local/template.
• A operação precisava escalar para copies reutilizáveis por IA, com foco em venda: teatro, bairro, dia, horário, preço e desconto.
• O usuário também definiu um recorte funcional claro para esta fase:
• 2 stories por IA;
• 2 reels por IA;
• story mais direto/comercial;
• reels podendo falar um pouco mais do atrativo do espetáculo.

Ajustes aplicados:

• admin/modulos/campanhas/redes_sociais.php
• nova aba Texto Audio Story incorporada ao módulo.
• regra de elegibilidade de peça alinhada com a vitrine pública (pecas.php) para o seletor interno.
• contexto da peça enriquecido com:
• nome limpo da landing;
• teatro;
• bairro/região;
• próxima sessão;
• preço promocional;
• desconto percentual.
• nova tabela social_audio_jobs criada em runtime para persistir jobs de copy.
• geração por IA passou a suportar:
• Gemini via CLI na politica atual da VPS;
• OpenAI (OPENAI_API_KEY).
• para cada IA configurada, o clique em Gerar com IA passa a criar:
• 2 jobs story;
• 2 jobs reels.
• prompt endurecido para:
• priorizar local, bairro, dia, horário, preço e desconto;
• destacar quando o desconto supera a meia;
• evitar frases longas e inventar informações como sem taxa.
• listagem de jobs passou a mostrar:
• provider;
• modelo;
• formato;
• versões geradas;
• seleção manual da versão ativa.

Resultado funcional:

• A tela deixou de depender apenas de texto determinístico local.
• Quando as chaves estão configuradas, a operação passa a ter múltiplas versões de copy por IA e por formato.
• Quando as chaves não estão configuradas, o fluxo ainda salva job com fallback local para não interromper a rotina.

Validacoes executadas:

• php -l admin/modulos/campanhas/redes_sociais.php
• validacao do JS inline equivalente por extracao do bloco <script> + node

BK-119 · Reabrir sugestões aprovadas na conciliação do bot

Data: 11 de Marco de 2026

Contexto operacional:

• O fluxo de conciliação de bot perdeu funcionalidade após merge anterior: itens aprovados não tinham mais atalho de retorno para revisão.
• O usuário reportou que aprovados sumiam da lista de ação sem como reabrir para ajuste.

Ajustes aplicados:

• admin/modulos/eventos/action.php
• adicionado o case 'conciliar_reabrir'.
• valida que o usuário é admin.
• carrega a sugestão por id, valida existência e confirma status = 'aprovado'.
• atualiza a sugestão para:
• status = 'pendente'
• data_decisao = NULL
• retorna sucesso com mensagem e URL de retorno.
• admin/modulos/eventos/conciliacao.php e admin/modulos/eventos/conciliacao_eventim.php
• filtro getSugestoes() passou a aceitar aprovados com WHERE status = 'aprovado'.
• a ordenação da aba aprovados passou a usar ORDER BY COALESCE(data_decisao, data_captacao) DESC.
• nova aba Aprovados com cards de revisão e botão Reabrir para Revisão para cada item.

Resultado funcional:

• Aprovação continua registrada normalmente.
• Itens aprovados podem ser devolvidos ao fluxo de conciliação com um clique, sem perder histórico.

Validações executadas:

• php -l admin/modulos/eventos/action.php
• php -l admin/modulos/eventos/conciliacao.php
• php -l admin/modulos/eventos/conciliacao_eventim.php

BK-116 · Aba Aguardando Aprovação em Peças restrita a produtores reais

Data: 11 de Marco de 2026

Contexto operacional:

• A tela admin/modulos/pecas/index.php?filtro=aprovacao estava misturando dois fluxos diferentes:
• peças reais enviadas por produtores (pecas.editado_produtor = 1);
• sugestões do bot vindas de bot_pecas_sugestoes.
• Isso inflava o badge de aprovação, gerava linhas BOT-* dentro do módulo de Peças e confundia a curadoria de cadastro humano com o fluxo de conciliação automática do bot.

Ajustes aplicados:

• admin/modulos/pecas/index.php
• contador da aba Aguardando Aprovação passou a considerar apenas pecas.editado_produtor = 1.
• bloco que buscava bot_pecas_sugestoes WHERE status = 'pendente' foi removido da listagem.
• comentário operacional adicionado para deixar explícito que sugestões do bot não pertencem a essa aba.

Resultado funcional:

• Peças > Aguardando Aprovação agora lista somente eventos enviados por produtores reais.
• Sugestões do bot continuam restritas ao fluxo correto de Eventos/Conciliação.

Validacoes executadas:

• php -l admin/modulos/pecas/index.php
• verificacao estrutural do arquivo para confirmar remocao de:
• contador do bot na aba de aprovação;
• query em bot_pecas_sugestoes;
• linhas BOT-* renderizadas na tabela de Peças

BK-115 · Painel WhatsApp com fallback de historico e contraste por status

Data: 11 de Marco de 2026

Contexto operacional:

• Depois do redesenho visual do BK-114, a area Ultimos envios continuava sem utilidade pratica quando bot_whatsapp_stats estivesse vazia ou com poucos registros.
• A verificacao real confirmou:
• SELECT COUNT(*) FROM bot_whatsapp_stats retornava 0 no momento da analise inicial;
• whatsapp_mensagens seguia com historico recente e confiavel de envios processados;
• o helper de WhatsApp precisava garantir compatibilidade imediata do schema para voltar a alimentar a telemetria dedicada.

Ajustes aplicados:

• includes/whatsapp_helper.php
• _whatsapp_obter_schema_stats(...) deixou de apenas inspecionar e passou a autocorrigir o schema de bot_whatsapp_stats para o formato esperado pelo helper atual:
• status ENUM('sucesso','erro','bloqueado')
• coluna mensagem
• coluna message_id
• indice idx_numero_data
• admin/modulos/bot/stats.php
• a tela agora dispara a autocorrecao de schema logo na abertura, via helper.
• Ultimos envios passou a funcionar em tres modos:
• telemetria pura;
• fallback total com whatsapp_mensagens;
• modo misto (telemetria + fallback) quando a telemetria ainda esta retomando.
• refinamento de UX adicional:
• chips de contagem por sucesso, bloqueado e erro;
• origem da grade visivel (telemetria, fallback total ou telemetria + fallback);
• destaque visual por linha para cada status;
• preview da mensagem nos sucessos;
• copy operacional explicando quando o fallback esta em uso.

Evidencia operacional confirmada em 11/03/2026:

• schema apos autocorrecao:
• bot_whatsapp_stats passou a aceitar mensagem, message_id e status='bloqueado'
• teste controlado do helper:
• insert sucesso com message_id voltou a gravar corretamente
• registro de teste removido em seguida
• composicao final da grade:
• telemetry=1
• merged=50
• fallback_added=49
• topo da listagem mostrou primeiro o evento real bloqueado e, na sequencia, o historico recente vindo de whatsapp_mensagens

Validacoes executadas:

• php -l includes/whatsapp_helper.php
• php -l admin/modulos/bot/stats.php
• validacao do JS inline equivalente via extracao do bloco <script> + node --check
• teste controlado do helper com persistencia e limpeza do registro de teste
• validacao da composicao telemetria + fallback com consulta real ao banco

BK-118 · RCA WhatsApp: ACK pendente, restart agressivo e telemetria restaurada

Data: 11 de Marco de 2026

Contexto operacional:

• Incidente analisado a partir do envio da lista de compradores do evento pecas.id=333 / sessão 17592 em 11/03/2026.
• O banco (whatsapp_mensagens) mostrava 4 saídas processadas, mas apenas o número 21999915554 exibia a mensagem na conversa.
• O painel de stats também estava cego: o helper chamava _whatsapp_gravar_telemetria(), porém a tabela real bot_whatsapp_stats não tinha o mesmo schema esperado pelo código.

Causa raiz confirmada:

• includes/whatsapp_helper.php
• após cada HTTP 200 do /send, o helper executava um restart preventivo imediato do rnt-whatsapp.
• no journalctl -u rnt-whatsapp, os 4 envios do incidente apareceram em sequência, cada um seguido por SIGTERM e restart do serviço antes do próximo destinatário.
• bot/whatsapp/server.js
• os messageId reais puderam ser consultados em /message-status, confirmando o estado atual:
• 5521979346876 → ack=0 (ACK_PENDING)
• 5521996868181 → ack=0 (ACK_PENDING)
• 5521999915554 → ack=3 (ACK_READ)
• 5521967194720 → ack=0 (ACK_PENDING)
• cliente_id = NULL não era causa de bloqueio:
• o vínculo com cliente era usado apenas para histórico/CRM; o envio já havia acontecido antes dessa associação.
• bot_whatsapp_stats
• a tabela aceitava apenas sucesso|erro e não possuía colunas mensagem/message_id, enquanto o helper tentava gravar bloqueado e mensagem, falhando silenciosamente.

Ajustes aplicados:

• includes/whatsapp_helper.php
• removido o restart preventivo após envio bem-sucedido para não encerrar a sessão antes do ciclo de ACK do WhatsApp.
• logging de sucesso passou a registrar message_id retornado pelo microserviço.
• telemetria passou a detectar o schema real de bot_whatsapp_stats, normalizar status aceitos e inserir apenas colunas existentes.
• bot/whatsapp/server.js
• adicionado cache leve de contexto por messageId para correlacionar ACKs de mensagens enviadas.
• novo log message_ack com rótulos legíveis (ACK_PENDING, ACK_SERVER, ACK_DEVICE, ACK_READ, ACK_PLAYED).
• endpoint POST /message-status passou a retornar também ackLabel.
• setup_whatsapp_table.php
• schema de referência atualizado para refletir a telemetria usada em produção (bloqueado, mensagem, message_id, índice por número/data).
• Banco de dados
• bot_whatsapp_stats migrada para incluir:
• status ENUM('sucesso','erro','bloqueado')
• mensagem TEXT
• message_id VARCHAR(120)
• índice idx_numero_data (numero, data_envio)

Validações executadas:

• php -l includes/whatsapp_helper.php
• node --check bot/whatsapp/server.js
• php -l setup_whatsapp_table.php
• systemctl restart rnt-whatsapp
• consulta real em journalctl -u rnt-whatsapp para os 4 envios do incidente
• chamadas reais ao endpoint local POST /message-status com os messageId do incidente
• teste controlado de _whatsapp_gravar_telemetria() confirmando persistência de sucesso e bloqueado com message_id

BK-114 · Reorganizacao visual do painel WhatsApp (admin/modulos/bot/stats.php)

Data: 11 de Marco de 2026

Contexto operacional:

• A tela admin/modulos/bot/stats.php estava funcional, mas visualmente achatada e com baixa hierarquia de leitura para operacao diaria.
• O layout antigo espalhava status do servico, acao da fila, cards numericos, grafico e tabelas sem um bloco principal de contexto.
• Como esta e a tela mais direta para ver saude do WhatsApp, fila pendente e historico de envio, a leitura precisava ficar mais imediata e mais proxima do padrao visual das telas recentes do admin.

Ajustes aplicados:

• admin/modulos/bot/stats.php
• novo hero operacional com status do servico, fila atual, protecao 24h, ultimo registro e acoes rapidas.
• cards de KPI refeitos com icones, texto de apoio e destaque para fila atual.
• grafico de envios por hora ganhou container proprio, refinamento visual e resumo de pico do dia.
• resumo operacional lateral adicionado com taxa de sucesso, retentativas, item mais antigo na fila e leitura do helper/status.
• tabelas de historico e fila foram reorganizadas em cards responsivos com estados vazios mais claros.
• ajuste funcional acoplado ao layout: limparHistoricoEnvios(...) passou a aceitar o botao clicado diretamente, evitando dependencia do event.currentTarget global.
• docs/BACKLOG.md
• BK-114 registrado como melhoria de layout/operacao desta tela.

Validacoes executadas:

• php -l admin/modulos/bot/stats.php
• validacao do JS inline equivalente com extracao do bloco <script> e node --check apos substituir o placeholder PHP <?=$json_grafico?> por um array estatico

BK-113 · Restauracao de common-scripts.js em telas do admin

Data: 11 de Marco de 2026

Contexto operacional:

• Depois do fechamento do BK-111 e do BK-112, ficou evidente que a regressao do submenu lateral do admin nao estava isolada.
• Outras telas ainda encerravam a pagina sem common-scripts.js, ou com um rodape JS paralelo ao stack oficial do painel, o que deixava o submenu lateral e comportamentos base do admin inconsistentes entre modulos.
• A revisao foi aberta especificamente para as telas:
• admin/modulos/facebook/configure.php
• admin/modulos/facebook/agendamento.php
• admin/modulos/campanhas/index.php
• admin/modulos/campanhas/redes_sociais.php
• admin/modulos/bot/stats.php

Ajustes aplicados:

• admin/modulos/facebook/configure.php
• bloco final do admin reforcado com common-scripts.js apos inc-js.php.
• admin/modulos/facebook/agendamento.php
• common-scripts.js restaurado antes do JS especifico do FullCalendar e da agenda social.
• admin/modulos/bot/stats.php
• common-scripts.js restaurado antes do bloco inline de acoes do dashboard WhatsApp.
• admin/modulos/campanhas/index.php
• rodape JS paralelo por CDN removido do papel de stack principal.
• pagina voltou a usar inc-js.php + common-scripts.js, mantendo o JS proprio da listagem logo em seguida.
• admin/modulos/campanhas/redes_sociais.php
• rodape JS paralelo por CDN substituido pelo stack padrao do admin (inc-js.php + common-scripts.js), sem remover o JS operacional da tela.
• docs/BACKLOG.md
• BK-113 registrado como fechamento separado para rastrear a restauracao transversal do submenu.

Validacoes executadas:

• php -l admin/modulos/facebook/configure.php
• php -l admin/modulos/facebook/agendamento.php
• php -l admin/modulos/campanhas/index.php
• php -l admin/modulos/campanhas/redes_sociais.php
• php -l admin/modulos/bot/stats.php
• verificacao estrutural com busca por inc-js.php e common-scripts.js nas cinco telas ajustadas

BK-112 · Eventim via API publica + conciliacao admin versionada

Data: 11 de Marco de 2026

Contexto operacional:

• O backlog ainda tratava Eventim como incidente de bloqueio HTTP2 no HTML, com proposta aberta de stealth browser ou investigacao adicional.
• A evidencia real deste ambiente mostrou outro desenho operacional:
• a API publica public-api.eventim.com responde normalmente;
• o host HTML www.eventim.com.br continua expirando por timeout na VPS;
• o scraper Eventim ja estava implementado para priorizar a API publica;
• a tela admin conciliacao_eventim.php e os testes CLI existiam no servidor, mas nao estavam versionados no Git.

Ajustes aplicados:

• admin/modulos/eventos/conciliacao_eventim.php
• tela de conciliacao Eventim passou a ficar versionada no repositorio.
• isso fecha a lacuna entre o Git e o codigo ja referenciado no admin por:
• admin/modulos/eventos/index.php
• admin/modulos/eventos/conciliacao.php
• admin/modulos/eventos/action.php
• admin/modulos/eventos/conciliacao_eventim.php
• bloco final do JS padrao do admin foi reforcado com common-scripts.js, evitando regressao do submenu lateral.
• admin/modulos/eventos/conciliacao.php
• o mesmo bloco common-scripts.js foi restaurado para manter consistencia com a conciliacao principal do bot.
• bot/tests/test_eventim_api.php
• versionado teste de diagnostico da API publica.
• bot/tests/test_eventim_scraper.php
• versionado teste integrado do EventimScraper.
• bot/tests/test_eventim_site.php
• versionado teste de timeout/challenge do host HTML principal.
• bot/tests/test_eventim_validator.php
• versionado teste isolado da regra de validacao para diferenciar teatro real de curso/oferta indevida.
• bot/scrapers/eventim_scraper.php
• comentario operacional adicionado para registrar que HTML fica apenas como contingencia/diagnostico e que a fonte primaria neste ambiente deve ser a API publica.
• docs/BACKLOG.md
• item aberto de Eventim foi encerrado como BK-112 com evidencia concreta.

Evidencia operacional confirmada em 11/03/2026:

• php bot/tests/test_eventim_api.php
• HTTP 200
• 49 produtos/sessoes retornados para Rio de Janeiro
• php bot/tests/test_eventim_scraper.php
• 5 espetaculos unicos consolidados a partir da API publica
• php bot/tests/test_eventim_validator.php
• caso eventim_falso_negativo validado como teatro real
• caso eventim_curso_real rejeitado com erro Contém termo de exclusão: 'curso'
• php bot/tests/test_eventim_site.php
• timeout em ipv6 e default para https://www.eventim.com.br/city/rio-de-janeiro-1672/
• conclusao: o HTML principal segue inadequado como fonte primaria neste ambiente

Validacoes executadas:

• php -l admin/modulos/eventos/conciliacao_eventim.php
• php -l admin/modulos/eventos/conciliacao.php
• php -l bot/tests/test_eventim_api.php
• php -l bot/tests/test_eventim_scraper.php
• php -l bot/tests/test_eventim_site.php
• php -l bot/tests/test_eventim_validator.php
• php -l bot/scrapers/eventim_scraper.php
• execucao real dos 4 testes CLI acima

BK-111 · Correcao arquitetural do bootstrap do admin PalcoFan

Data: 11 de Marco de 2026

Contexto operacional:

• A tela admin/modulos/comentarios/index.php voltou a abrir sem CSS/JS porque estava subindo apenas com ../../data/setup.php.
• Nesse modo, APP_ROOT, MODULO_SLUG e MODULO_ACTIVE_MENU caiam nos fallbacks vazios de setup.php, quebrando os caminhos de asset do admin em head.php.
• O mesmo modulo executa queries mysqli_* com $conexao, mas setup.php sozinho nao inicializa a conexao mysqli.
• Havia um admin/modulos/comentarios/bootstrap.php solto no worktree, porem nao versionado e ainda incompleto para o uso atual do modulo.

Ajustes aplicados:

• admin/modulos/comentarios/bootstrap.php
• arquivo passou a ser a entrada obrigatoria do modulo.
• comentario de regra adicionado para deixar explicito que este modulo nao pode voltar a usar ../../data/setup.php direto.
• bootstrap endurecido com caminhos absolutos via __DIR__, incluindo config/connect.php para disponibilizar $conexao as queries mysqli_*.
• admin/modulos/comentarios/index.php
• topo trocado de require("../../data/setup.php"); para o bootstrap.php local.
• includes compartilhados (head.php, inc-topo.php, inc-menu.php, inc-footer.php) endurecidos com __DIR__ + APP_ROOT.
• bloco final de JS do admin restaurado com inc-js.php + common-scripts.js, reativando o submenu lateral e o comportamento padrao do painel.
• comentario operacional adicionado para registrar a dependencia de APP_ROOT/MODULO_* e $conexao.
• docs/BACKLOG.md
• BK-111 reaberto para rastrear a correcao arquitetural do modulo admin PalcoFan.
• BK-75 ajustado para nao seguir afirmando que a consolidacao do layout/bootstrapping do admin ja estava entregue.
• docs/CHANGELOG.md
• historico do BK-75 corrigido para refletir que a consolidacao do bootstrap/layout do modulo admin ficou como correcao posterior.

Validacoes executadas:

• php -l admin/modulos/comentarios/bootstrap.php
• php -l admin/modulos/comentarios/index.php
• renderizacao local via CLI com HTTP_HOST=localhost para confirmar:
• asset_ok;
• accordion_ok;
• common_ok;
• menu_ok.
• comparacao estrutural com modulos estaveis do admin para confirmar a presenca do bloco inc-js.php + common-scripts.js no fechamento da pagina.

Aba Storie · estabilizacao do upload de video .mp4 no admin

Data: 11 de Marco de 2026

Contexto operacional:

• A nova aba Storie estava listando assets corretamente, mas o upload de video grande continuava falhando no admin.
• Evidencia real coletada no debug.log:
• request chegava como multipart/form-data;
• CONTENT_LENGTH vinha preenchido (~37 MB);
• $_POST e $_FILES chegavam vazios.
• Causa raiz confirmada: override local em admin/.user.ini com post_max_size = 16M, enquanto o restante do site aceitava uploads maiores.

Ajustes aplicados:

• admin/.user.ini
• post_max_size elevado para 500M.
• upload_max_filesize elevado para 500M.
• max_input_time elevado para 1800.
• admin/js/gestor-story.js
• upload trocado para XMLHttpRequest puro com FormData(form).
• adicionada barra de progresso real.
• mantido envio dedicado para evitar interferencia do jQuery legado do admin em multipart grande.
• admin/inc-gestor.php
• adicionada UI de progresso do upload na aba Storie.
• admin/modulos/pecas/action.php
• logging expandido com CONTENT_TYPE, CONTENT_LENGTH, post_max_size e upload_max_filesize efetivos.
• tratamento explicito para multipart descartado antes de popular $_POST/$_FILES.
• admin/modulos/pecas/index.php
• cache-buster do JS atualizado para forcar carregamento da versao corrigida.

Evidencia operacional confirmada:

• Upload real da peca 1342 concluido com sucesso em 11/03/2026 11:41.
• Arquivo salvo em:
• /arquivos/pecas/1342/video/lisa-lesa-e-louca-story.mp4
• Evidencia de log:
• ini_post_max=500M ini_upload_max=500M
• files_keys=story_file
• OK item=0 salvo=/www/wwwroot/rionoteatro.com.br/arquivos/pecas/1342/video/lisa-lesa-e-louca-story.mp4

Validacoes executadas:

• php -l admin/modulos/pecas/action.php
• php -l admin/inc-gestor.php
• php -l admin/modulos/pecas/index.php
• node --check admin/js/gestor-story.js
• confirmacao em disco via ls -lah arquivos/pecas/1342/video

Fechamento operacional da branch vps/BK-109-story-video-priority · prioridade de video story por peca

Data: 11 de Marco de 2026

Contexto operacional:

• Em 11/03/2026, a fila social_post_queue registrou falhas reais de midia nos canais de feed:
• facebook_feed: Missing or invalid image file
• instagram_feed: Only photo or video can be accepted as media type.
• Casos confirmados no momento da analise:
• peca 333 (Bee Gees, Abba e Carpenters - Nos embalos de SABADO a noite)
• peca 1341 (E O Otimismo Que Faz O Besouro Voar!)
• A peca 1341 ja possuia mp4 em /arquivos/pecas/1341/video, enquanto outras pecas afetadas dependiam apenas da capa.

Ajustes aplicados:

• admin/cron/sync_facebook_events.php
• adicionado resolvedor de capa principal da peca e normalizacao para JPG compativel com Meta em uploads/social_meta_assets.
• stories passaram a procurar somente video em /arquivos/pecas/{id}/video.
• fallback de story ajustado para:
• usar video quando existir;
• cair direto para a capa da peca quando nao houver video.
• overlay automatico de story continua sendo aplicado apenas em fluxo por imagem.
• admin/classes/FacebookEventService.php
• createInstagramMedia(...) passou a aceitar video_url em stories.
• createFacebookStory(...) passou a tentar video_stories primeiro e, se necessario, cair para photo_stories.
• admin/inc-gestor.php
• nova aba Storie no gestor de pecas.
• admin/modulos/pecas/action.php
• upload, listagem e exclusao de assets de story em /arquivos/pecas/{id}/video.
• admin/js/gestor-story.js
• fluxo AJAX da aba Storie e deep-link para abrir o gestor da peca ja na aba correta.
• admin/modulos/facebook/agendamento.php
• atalho operacional para abrir o gestor da peca diretamente no contexto de story.
• admin/modulos/pecas/index.php
• inclusao do JS do gestor de story.

Validacoes executadas:

• php -l admin/classes/FacebookEventService.php
• php -l admin/cron/sync_facebook_events.php
• php -l admin/modulos/facebook/agendamento.php
• php -l admin/inc-gestor.php
• php -l admin/modulos/pecas/action.php
• php -l admin/modulos/pecas/index.php
• parse do JS novo admin/js/gestor-story.js via node -e
• smoke HTTP apos push em main:
• https://rionoteatro.com.br/ -> 200
• https://rionoteatro.com.br/admin/ -> 302
• https://rionoteatro.com.br/painel/modulos/eventos/ -> 302

Git / deploy:

• Commit funcional do codigo: 8d62d4bf3 (fix(social): prioriza video story por peca)
• Merge em main realizado na VPS com fast-forward.
• git push origin main executado com sucesso, disparando o workflow de deploy definido em .github/workflows/deploy.yml.
• Branch local vps/BK-109-story-video-priority removida apos merge.
• Consulta a origin confirmou que nao existia branch remota vps/BK-109-story-video-priority para exclusao.

Observacao de governanca:

• O identificador BK-109 ja estava em uso no historico do projeto para outra entrega (Corrigir erro de renderizacao da aba WhatsApp no detalhe de cliente).
• Para nao duplicar numeracao no backlog/changelog, este fechamento foi registrado como encerramento operacional da branch vps/BK-109-story-video-priority.

BK-75 · Correcao documental do modulo PalcoFan + inclusao publica em peca.php e evento.php

Data: 10 de Marco de 2026

Contexto:

• O historico do BK-75 estava inconsistente com o que realmente foi entregue para o modulo de avaliacoes PalcoFan.
• A analise do codigo em producao confirmou que o nucleo do modulo existia, mas a inclusao publica estava efetivamente presente apenas em teatro.php.

Ajustes aplicados:

• peca.php
• inclusao do bloco includes/inc_palcofan.php no frontend da pagina da peca.
• evento.php
• inclusao do bloco includes/inc_palcofan.php no frontend da pagina do evento.
• admin/modulos/comentarios/index.php
• modulo administrativo versionado e acessivel pelo submenu nativo Peças > Comentários.
• docs/BACKLOG.md
• registro consolidado do escopo real entregue pelo BK-75.

Escopo real confirmado do PalcoFan:

• Endpoint AJAX: includes/ajax_palcofan.php
• aceita apenas POST,
• exige cliente logado,
• valida tipo_item, nota e comentario,
• reenvia avaliacao atualizada para pendente.
• Moderacao admin: admin/modulos/comentarios/index.php
• filtros pendente, aprovado, rejeitado e todos,
• acoes de aprovar, rejeitar e excluir.
• Bloco publico: includes/inc_palcofan.php
• resumo de media,
• comentarios aprovados,
• formulario para cliente logado.
• SEO/Schema: meta-analytics.php
• aggregateRating dinamico para pecas com base em tb_avaliacoes.

Observacoes importantes:

• A tabela tb_avaliacoes existe em producao, com indices por item/status, mas a restricao de nota 1..5 esta implementada no PHP e nao como CHECK no schema MySQL atual.
• O link de contexto do item avaliado foi ajustado para tratar tipo_item='evento' pelo fluxo real da tabela pecas, com fallback legado para eventos.
• A consolidacao do bootstrap/layout padrao do admin para admin/modulos/comentarios/ nao estava de fato versionada neste momento; essa correcao arquitetural ficou registrada separadamente no BK-111.
• Este registro nao apaga o historico anterior do BK-75; ele corrige documentalmente o escopo efetivamente identificado no codigo/ambiente.

BK-108 · Reordenacao de CTA de compra e padronizacao AdSense no evento.php

Data: 06 de Marco de 2026

Objetivo operacional:

• Melhorar a experiência do usuário (UX) e o fluxo de conversão em eventos de produtores externos/bot, movendo o botão de compra para após a seção de localização.

Ajustes aplicados:

• evento.php:
• Botão de compra externa (CTA) removido do topo da página.
• Removida lógica condicional baseada na origem do evento.
• Inclusão de novo bloco de CTA fixo posicionado imediatamente após a seção de LOCAL.
• Padronização da chamada renderAdsenseResponsivoPorDispositivo() entre as seções:
• Após Sinopse.
• Após Ficha Técnica.
• Após Botão de Compra/Local.
• Após Dúvidas.
• Resultado:
• Layout mais limpo e informativo antes da decisão de compra.
• Melhor distribuição de anúncios ao longo da página.

BK-96 · Migracao de enderecos e bairros estruturados dos teatros

Data: 06 de Marco de 2026

Objetivo operacional:

• Estruturar os dados geográficos da tabela teatros, movendo informações misturadas no campo local para os campos dedicados endereco e bairro.

Ajustes aplicados:

• Criacao do script de migracao: admin/cron/migrar_enderecos_teatros.php:
• Extração inteligente de endereços de 118 registros via regex (Rua, Av, Pr, Estr).
• Limpeza automatica de HTML, iframes do Google Maps e avisos redundantes do campo local.
• Criacao do script de refinamento: admin/cron/extrair_bairros_do_endereco.php:
• Mapeamento de 86 bairros comuns e específicos do Rio de Janeiro e Niterói.
• Lógica de detecção por nome do teatro e sufixos no endereço.
• Resultado Final:
• 148 teatros ativos com endereco e bairro preenchidos (100% da base ativa).
• Campo local preservado apenas com informações complementares (capacidade, etc).
• Estrutura pronta para integração com mapas dinâmicos e SEO local.

BK-109 · Corrigir erro de renderizacao da aba WhatsApp no detalhe de cliente

Data: 06 de Marco de 2026

Objetivo operacional:

• Corrigir falha crítica no carregamento do histórico da aba #whatsapp-tab para clientes com histórico de conversa.

Ajustes aplicados:

• admin/modulos/clientes/detalhe.php:
• corrigido reset de cursor de resultado de $obj_sql->data_seek($q_wa, 0) para mysql_data_seek($q_wa, 0).
• mantida a lógica de fallback de busca por cliente_id, celular e telefone.
• Resultado observado:
• links como ...detalhe.php?id=50877#whatsapp-tab e ...detalhe.php?id=775 voltam a renderizar corretamente.

BK-94 · Validação E2E de quebra de linha e fila WhatsApp

Data: 06 de Marco de 2026

Objetivo operacional:

• Validar que o fluxo de envio via fila:
• aceita mensagens com quebra de linha,
• envia com payload JSON seguro,
• remove o item processado (fila zerada) após sucesso.

Ajustes aplicados:

• tests/bk94-whatsapp-e2e.sh (novo)
• verifica endpoints de detalhe de cliente (IDs 50877 e 775).
• executa validação offline de fila com mock de /status e /send.
• valida payload com linha 1\nlinha 2 e remoção do JSON da fila no final.

Validações executadas:

• bash tests/bk94-whatsapp-e2e.sh
• Resultado esperado: envio com \\n aceito e fila de teste finalizada sem arquivos remanescentes.

BK-107 · Gemini agora + arquivos por peca no modulo de videos

Data: 06 de Marco de 2026

Objetivo operacional:

• Tirar dependencia de uploads/video_examples, centralizar tudo em /arquivos/pecas/{id}/video e permitir disparo direto do gerador Gemini por job.

Ajustes aplicados:

• admin/modulos/campanhas/redes_sociais.php
• fallback operacional para quota da API:
• novo botao por job: "Gerar Prompt (Gemini App)",
• gera prompt manual completo (tom de voz + assets + link da peca + formato/duracao) para colar no app Gemini com upload manual dos arquivos,
• bloco copiavel na tela com botao "Copiar prompt".
• prompts manuais de video refinados para qualidade criativa:
• duracao obrigatoria entre 25 e 30 segundos (evita retorno curto de 8s),
• foco em transicoes e audio final,
• regra explicita para nao deformar textos/imagens e limitar animacao de texto ao nome da peca + CTA curto.
• novo endpoint AJAX interno (ajax=video_piece_files) para listar dinamicamente os arquivos da pasta da peca selecionada.
• painel lateral alterado de "Referencias em uploads/video_examples" para "Arquivos do Video (da peca selecionada)".
• painel "Arquivos do Video" ganhou upload rapido direto para a pasta da peca selecionada.
• seletor de peca passou a manter selecao apos postback e atualizar a listagem da pasta automaticamente.
• tabela "Jobs de Video Recentes" agora filtra pela mesma peca selecionada no topo (com botao para limpar filtro).
• card do job reforcado com bloco explicito para adicionar mais imagens/videos sem recriar job.
• lista de assets no card ganhou exclusao individual com botao X por arquivo (remove do job e tenta remover do disco com seguranca de referencia).
• adicionado botao por job: "Gerar com Gemini agora".
• adicionada opcao de excluir job (com escolha de remover tambem os arquivos daquele job).
• fluxo de formato no job:
• criacao/edicao com escolha entre Story (alvo 30s) e Reels (alvo 60s),
• campos persistidos no job (formato, duracao_alvo_sec) com migracao automatica para bases antigas.
• novo fluxo action=video_generate_now:
• consulta endpoint de video por variavel de ambiente (CEREBRO_VIDEO_ENDPOINT/RNT_AI_VIDEO_ENDPOINT),
• fallback direto por API Gemini foi removido em 2026-04-29 por politica operacional: sempre CLI/servico interno, nunca chave direta,
• leitura de env ampliada para fallback central da VPS (/root/cerebro/.env e /root/.env) para evitar duplicacao de segredos por projeto,
• ajuste de robustez para open_basedir (leitura de paths externos com checagem silenciosa, sem warning em tela),
• envia payload com job + peca + assets,
• tenta salvar retorno em /arquivos/pecas/{id}/video (path local, download por URL ou base64),
• atualiza video_final_path, transcricao_audio, status e assets_json.
• aplica regra operacional de duracao para Story: tenta forcar saida final em 30s com ajuste automatico quando vier menor.
• tratamento de erro normalizado no fallback direto/endpoint para nunca retornar mensagem generica Array (agora mostra texto real da API e HTTP quando existir).
• payload direto do Gemini ajustado para compatibilidade com o modelo atual (durationSeconds numerico e remocao de campos nao suportados).
• chamada direta agora usa duracao por formato do job (Story=30s, Reels=60s) com fallback tecnico para 8s apenas quando o modelo/API recusar o parametro.
• comentarios de regra mantidos para evitar regressao de caminho e de provedor.
• Operacao de arquivos (VPS):
• conteudo de uploads/video_examples foi transferido para /arquivos/pecas/1341/video.

BK-106 · Ajustes de operacao (retencao de video + presets de voz)

Data: 06 de Marco de 2026

Objetivo operacional:

• Evitar acumo de lixo de video na VPS e acelerar a criacao de roteiro/voz com presets reutilizaveis.

Ajustes aplicados:

• admin/cron/cleanup_old_pecas_images.php
• limpeza passou a considerar tambem a subpasta video por padrao.
• regra de retencao mantida em --days=7 (1 semana apos fim da temporada).
• comentarios de protecao adicionados (REGRA DE NEGOCIO (NAO REMOVER)).
• admin/modulos/campanhas/redes_sociais.php
• adicionada tabela de presets de voz (social_video_voice_presets) com seed inicial:
• preset comercial padrao,
• preset Sambarilove (Malandro Carioca).
• formulario de criacao de video ganhou:
• seletor de preset salvo,
• textarea de tom de voz (texto longo),
• painel para salvar/atualizar novos presets.
• compatibilidade de schema no job de video:
• tom_voz ajustado para TEXT (bases antigas com VARCHAR(180) sao migradas automaticamente).
• correcao operacional de upload/job:
• criacao de novo job passou a reaproveitar rascunho existente da mesma peca por padrao (evita duplicacao acidental de jobs),
• adicionado bloco Anexar assets/video ao job no card para complementar uploads sem recriar job,
• feedback de upload passou a mostrar Arquivos recebidos no POST,
• suporte de assets ampliado para extensoes heic/heif.
• mensagem de tela reforcada para evitar ambiguidade:
• etapa semimanual atual organiza insumos e ainda nao renderiza video automaticamente.

BK-106 · MVP semimanual de Video IA na Central de Redes Sociais

Data: 06 de Marco de 2026

Objetivo operacional:

• Viabilizar criacao de videos por fluxo semimanual (sem cron) diretamente no admin, usando Gemini como provedor padrao na VPS.

Ajustes aplicados:

• admin/modulos/campanhas/redes_sociais.php
• adicionada aba Videos IA (Gemini) na central.
• criado fluxo de job semimanual com:
• selecao de peca elegivel (somente venda online/Admin),
• upload de assets (imagem/video/audio),
• campo de roteiro base,
• campo de transcricao do audio editavel.
• criado controle de status do job (rascunho, pronto_revisao, aprovado, publicado, arquivado) com edicao posterior.
• criado anexo opcional de video final no proprio job.
• tabela social_video_jobs passa a ser garantida via CREATE TABLE IF NOT EXISTS (padrao do modulo).
• adicionadas regras comentadas no codigo (NAO REMOVER) para evitar regressao:
• provedor fixo gemini nesse fluxo,
• filtro de pecas somente catalogo online/Admin.
• listagem de referencia dos arquivos em uploads/video_examples dentro da propria aba.

BK-105/BK-106 · Kickoff de automacao assistida Story + pipeline de video IA

Data: 06 de Marco de 2026

Objetivo operacional:

• Formalizar os proximos passos para:
• automacao assistida de Story com sticker/link (fluxo de risco controlado),
• pipeline de video IA para divulgacao de pecas/eventos (Gemini como motor principal).

Ajustes aplicados:

• docs/BACKLOG.md
• BK-105 e BK-106 foram detalhados com:
• responsavel inicial,
• tarefas executaveis,
• criterios de operacao/fallback.
• docs/documentacao_tecnica/campanha_track/VIDEO_IA_PIPELINE_NOTAS_2026-03.md (novo)
• documento tecnico de referencia para BK-106 com:
• contrato de entrada (MVP),
• etapas do pipeline,
• modelo de fila de render,
• regras de qualidade e mitigacao de risco.

BK-99 · Fila social recorrente (social_post_queue) + agenda por fila

Data: 05 de Marco de 2026

Objetivo operacional:

• Encerrar dependencia do ciclo fixo de 21 dias no cron social.
• Permitir programacao recorrente robusta (varios agendamentos por peca/semana) sem duplicar postagens.
• Tornar a tela de agenda aderente ao que realmente esta na fila.

Ajustes aplicados:

• admin/cron/sync_facebook_events.php
• criada/garantida tabela social_post_queue via bootstrap automatico no cron (CREATE TABLE IF NOT EXISTS).
• hardening anti-duplicacao:
• garantia de UNIQUE em dedupe_key (com limpeza defensiva de legado antes de criar o indice).
• removido bloco legado de "evergreen 21 dias".
• adicionado planner por sessoes futuras:
• janela configuravel (SYNC_SOCIAL_PLANNER_DAYS, default 14),
• limite por semana/peca (SYNC_SOCIAL_MAX_FEED_PER_WEEK, default 3),
• deduplicacao por dedupe_key (canal:peca:session_date).
• separacao de modos no mesmo cron:
• mode=planner (planeja fila, sem enviar),
• mode=dispatcher (envia fila/gatilhos),
• mode=full (padrao; planner + dispatcher).
• feed FB/IG passou a usar itens da fila:
• FB: envia imediato ou com scheduled_publish_time para futuro (status scheduled na fila).
• IG: processa itens due (scheduled_for <= NOW()), mantendo os futuros em queued.
• reset (?reset=1) agora limpa tambem a social_post_queue.
• comentarios REGRA (NAO REMOVER) adicionados para evitar retorno ao fluxo antigo.
• ajuste adicional: fallback silencioso de fonte TTF com @file_exists para evitar warning de open_basedir.

• admin/modulos/facebook/agendamento-events.php
• agenda passou a ler social_post_queue como fonte principal.
• exibe um evento por item de fila (canal + status + post_id/erro).
• imagem do modal passou a usar pasta large (corrige falha de thumb ausente em alguns cards).
• payload dos eventos agora inclui icon_class e tooltip_html para hover enriquecido no calendario.
• fallback legado mantido para pecas.facebook_scheduled_at se a fila nao existir/estiver vazia.

• admin/modulos/facebook/agendamento.php
• texto da tela atualizado para explicitar que a agenda usa a fila social.
• adicionados filtros de status e canal no calendario (com refetch no endpoint).
• calendario localizado em portugues (meses/dias/botoes).
• novos recursos de UX:
• icone por canal no card do calendario (FB/IG),
• tooltip com resumo da postagem no hover.
• criacao manual de postagem diretamente na agenda (modal "Nova postagem").
• duplicacao de postagem direto do modal de detalhes (botao "Duplicar agendamento" com pre-preenchimento).
• comentario de protecao inserido no HTML (NAO REMOVER) para evitar regressao.

• admin/modulos/facebook/agendamento-create.php
• novo endpoint para inserir/agendar itens manuais na social_post_queue (feed e story).

• admin/cron/sync_facebook_events.php
• dispatcher passou a processar tambem itens manuais de facebook_story e instagram_story da fila (due por horario), alem dos gatilhos automáticos.

• sql_updates/create_social_post_queue.sql
• script versionado para criacao da fila social em ambientes externos.

Atualizacao complementar (05/03/2026 - noite):

• admin/classes/FacebookEventService.php
• adicionados metodos de Threads API:
• getThreadsUserInfo()
• createThreadsMedia()
• publishThreadsMedia()
• suporte por variaveis THREADS_ACCESS_TOKEN e THREADS_USER_ID.
• admin/cron/sync_facebook_events.php
• planner passou a incluir canal threads_feed quando Threads estiver configurado.
• dispatcher passou a processar threads_feed da fila.
• REGRA COMENTADA NO CODIGO (NAO REMOVER): container do Threads expira em ~24h, portanto o container eh criado/publicado apenas perto do horario due.
• resumo final de execucao passou a incluir Threads Feed ok/erro.
• admin/modulos/facebook/agendamento.php
• filtros e modal manual com opcao Threads Feed.
• novo fluxo de Story notificado/manual na agenda:
• status notified,
• botoes operacionais: salvar preset, aplicar preset, clonar em massa e marcar publicado manual.
• admin/modulos/facebook/agendamento-events.php
• canal threads_feed adicionado no endpoint de agenda (label + icone).
• status notified incluido no payload/filtros.
• admin/modulos/facebook/agendamento-create.php
• endpoint manual aceita threads_feed.
• modo de publicacao (auto/notified) para stories.
• admin/modulos/facebook/agendamento-preset-save.php
• salva preset por peca/canal de story.
• admin/modulos/facebook/agendamento-preset-apply.php
• aplica preset para gerar agenda semanal em lote.
• admin/modulos/facebook/agendamento-bulk-clone.php
• clona agendamento base em massa (N semanas).
• admin/modulos/facebook/agendamento-update-status.php
• marca item notificado como publicado manualmente (com post_id opcional).
• docs/documentacao_tecnica/campanha_track/THREADS_E_STORY_LINKS_NOTAS_2026-03.md
• documentacao operacional das limitacoes de Story link sticker (API vs notificado/manual) e regra de 24h do Threads.
• docs/BACKLOG.md
• adicionados BK-100, BK-101, BK-102 para inteligencia de horarios/posts e complemento de tracking via GTM.

Operacao aplicada na VPS (05/03/2026 18:51 - America/Sao_Paulo):

• cron legado horario do sync_facebook_events.php foi substituido por:
• 0 6 * -> planner (mode=planner)
• /5 * -> dispatcher (mode=dispatcher)
• wrappers criados em /www/server/cron/:
• rnt_sync_facebook_planner
• rnt_sync_facebook_dispatcher

Atualizacao complementar (05/03/2026 - noite, operacao social + tracking/admin):

• admin/modulos/facebook/agendamento.php
• REGRA COMENTADA (NAO REMOVER): modal "Nova Postagem" passou a listar somente pecas elegiveis de venda online com contexto/produtor Admin.
• select de peca passou a exibir nome do produtor junto ao titulo.
• campo Data da sessao (opcional) recebeu texto explicando uso em fila/gatilhos/analise por sessao.
• admin/modulos/facebook/agendamento-create.php
• validacao server-side da mesma regra de elegibilidade (evita bypass via POST manual).
• admin/inc-menu.php
• submenu legado Feed Facebook Ads foi roteado para central de redes sociais no modulo Campanhas.
• comentario operacional adicionado para evitar regressao de menu/link.
• admin/modulos/campanhas/redes_sociais.php (novo)
• central operacional de redes sociais com botoes para:
• sync_facebook_events.php (planner/dispatcher/full/reset),
• agenda social,
• feed catalogo CSV (feed_facebook_catalogo.php).
• resumo da social_post_queue por status/canal.
• lista de stories em operacao (queued/notified/error).
• acao manual para adiantar stories notificados para "agora" (uso operacional com sticker/link manual).
• admin/modulos/campanhas/index.php
• novo atalho "Redes Sociais" no cabecalho do modulo.
• admin/modulos/dashboard/tracking.php
• correcao de exibicao de horario para America/Sao_Paulo a partir de cliente_tracking.data_hora (UTC).
• tabela de eventos recentes ganhou coluna de links operacionais:
• origem do acesso,
• pagina canonica do evento/peca,
• pedido relacionado (quando vinculavel por cliente+peca).
• view_item e begin_checkout agora mostram nota de contexto de valor para evitar leitura como compra efetivada.
• docs/BACKLOG.md
• adicionado item BK-103 para integracao TikTok no orquestrador social.

Validacao operacional executada (05/03/2026 20:24 BRT):

• Execucao manual CLI:
• php admin/cron/sync_facebook_events.php mode=dispatcher
• cron executou em modo dispatcher e confirmou processamento de fila/gatilhos sem erro de acesso.
• observacao: stories manual_notified so mudam para notified quando scheduled_for <= NOW().

Atualizacao complementar (05/03/2026 - catalogo Meta + Facebook Events):

• atualizar_feed.php
• feed pecas.xml passou a refletir automaticamente pecas de venda online do site:
• status='A'
• (id_produtor IS NULL OR parceria_online=1)
• exclui Teste
• somente sessoes futuras com sec_valor > 0 (remove vencidas automaticamente).
• saida em CLI ficou enxuta (OK pecas.xml atualizado | itens=N) para evitar log gigante no cron.
• admin/cron/feed_facebook_catalogo.php
• corrigida query (remocao de coluna inexistente p.foto_home que deixava CSV sem linhas).
• mesmo filtro de elegibilidade do catalogo online.
• ajuste de preco:
• price usa valor cheio quando existir;
• sale_price usa valor final de venda (sec_valor) quando menor que o cheio.
• admin/classes/FacebookEventService.php
• updateEvent() ampliado para aceitar start_time, end_time, location e cover_url.
• admin/cron/sync_facebook_page_events.php (novo)
• cron para criar/atualizar/remover eventos de pagina FB por peca elegivel.
• inclui dry_run=1 para validacao sem publicar.
• cria coluna pecas.facebook_page_event_id automaticamente quando ausente.
• admin/modulos/campanhas/redes_sociais.php
• adicionados botoes operacionais:
• FB Events (dry-run)
• FB Events (real).
• Operacao de cron (VPS):
• feed pecas.xml passou de diario para /30 * (automatico mais rapido para catalogo).
• evidencia: /www/server/cron/f1fb970e7ca0b68f38510abb76a86aa0 executando com retorno OK pecas.xml atualizado | itens=3.
• Diagnostico de plataforma (ambiente atual):
• leitura de eventos da pagina funciona (GET /{page_id}/events).
• criacao via API falha (POST /{page_id}/events) com GraphMethodException code 100 / subcode 33.
• item aberto no backlog como BK-104 para desbloqueio definitivo.

BK-98 · Hardening do webhook WhatsApp para CRM externo (LegalizaRJ)

Data: 04 de Marco de 2026

Ajustes aplicados no helper (bot/whatsapp/server.js):

• Webhook passou a aceitar e enviar apenas eventos de chat privado valido (@c.us ou @s.whatsapp.net).
• Eventos de grupo/canal/newsletter/ID nao telefonico passam a ser ignorados.
• Inclusao de assinatura HMAC SHA-256 no webhook:
• X-Webhook-Timestamp
• X-Webhook-Signature (sha256=<hash>)
• Nova variavel obrigatoria no service:
• WPP_WEBHOOK_SECRET

Objetivo de seguranca:

• Evitar ingestao de mensagens indevidas no CRM externo.
• Reduzir risco de spoof de webhook com payload sem assinatura valida.

Operacao:

• Service reiniciado com novas variaveis:
• WPP_WEBHOOK_TOKEN (rotacionado)
• WPP_WEBHOOK_SECRET (novo)

BK-91 · Token Facebook/IG bloqueado por instabilidade externa (Meta/JSSDK)

Data: 03 de Marco de 2026

Diagnostico executado:

• sync_facebook_events.php?reset=1:
• Encontradas 3 pecas elegiveis para sincronizacao.
• erro de token: Session has expired on Monday, 02-Mar-26 20:00:00 PST.
• php admin/cron/monitor_story_roi.php:
• facebook_token_health=error
• expires_at=2026-03-03 01:00:00
• instagram_binding_live=warn por token expirado.
• Fluxo do painel em admin/modulos/facebook/configure.php:
• tentativa de Obter Token Automaticamente bloqueada com mensagem de plataforma:
• A opção JSSDK não está ativada.

Conclusao operacional:

• Bloqueio externo confirmado (Meta/Facebook instavel + dependencia de OAuth/JSSDK).
• BK-91 permanece aberto e pausado ate estabilizacao do fluxo de login/token no app Meta.

Retomada planejada (quando estabilizar):

• Renovar token da pagina no painel.
• Revalidar:
• php admin/cron/monitor_story_roi.php com status ok;
• https://rionoteatro.com.br/admin/cron/sync_facebook_events.php?reset=1 sem erro de token.

BK-97 · Governanca do pecas.json (runtime) + filtro da peca Teste no cron social

Data: 03 de Marco de 2026

Contexto validado:

• O endpoint sync_facebook_events.php?reset=1 nao regenera api/eventos/pecas.json; ele apenas limpa IDs sociais na tabela pecas.
• Consulta real de elegibilidade retornava 4 pecas, incluindo homologacao:
• 1343 | Teste | parceria=1.

Ajustes aplicados:

• admin/cron/sync_facebook_events.php
• selecao de pecas elegiveis passou a excluir nome = 'Teste'.
• Governanca de artefato gerado (api/eventos/pecas.json):
• removido do versionamento Git (git rm --cached);
• adicionado no .gitignore;
• criado api/eventos/pecas.example.json como base versionada.
• api/eventos/README.md
• documentacao atualizada para diferenciar pecas.example.json (versionado) de pecas.json (runtime).

Token Facebook/IG (evidencia operacional):

• Execucao em 03/03/2026 18:08:10 (PST) retornou:
• Session has expired on Monday, 02-Mar-26 20:00:00 PST.
• Backlog BK-91 atualizado para exigir renovacao e revalidacao do reset.

BK-86 · SQL/Collation do Robo ROI corrigidos + cron id=19 reativado

Data: 03 de Marco de 2026

Problemas corrigidos:

• Truncated incorrect DOUBLE value: 'pago' em sp_calcular_roi_campanhas.
• Illegal mix of collations for operation 'concat' em sp_gerar_alertas_roi.
• Retorno inconsistente ROI calculado para -1 registros.

Ajustes aplicados:

• Criado script versionado: SQL/bk86_fix_roi_procedures.sql.
• Recriadas procedures:
• sp_calcular_roi_campanhas
• ajuste de status de pagamento para p.status_transacao IN (3, 4);
• cast/sanitizacao de pedidos.valor (VARCHAR -> DECIMAL) em todos os somatorios;
• contagem explicita de linhas inseridas para retorno correto do total.
• sp_gerar_alertas_roi
• cast robusto de thresholds em robot_config.valor;
• padronizacao de collation em CONCAT/comparacoes com utf8mb4_unicode_ci.

Validacoes executadas:

• CALL sp_calcular_roi_campanhas(CURDATE() - INTERVAL 7 DAY, CURDATE())
• resultado: ROI calculado para 3 registros.
• CALL sp_gerar_alertas_roi()
• resultado: alertas_gerados = 0.
• php admin/cron/analisar_roi_campanhas.php
• execucao completa sem erros SQL/collation.

Operacao / Cron:

• Cron aaPanel id=19 (Robo ROI Rio no Teatro) reativado.
• Evidencia operacional: wrapper do cron executado manualmente com status final de sucesso.

BK-85 · Alerta WhatsApp para erro critico via debug_log (debounce 30min)

Data: 03 de Marco de 2026

Ajustes aplicados:

• admin/logs/debug_helper.php
• debug_log() passou a avaliar erros criticos e acionar notificacao para admin via WhatsApp.
• Adicionadas funcoes internas para:
• detectar gatilhos de erro (ERRO, FATAL, EXCEPTION, CRITICO);
• evitar loop de alerta para modulo WHATSAPP/DEBUG_LOG_ALERT;
• aplicar debounce global de 30 minutos (admin/logs/debug_whatsapp_alert_last_ts.lock);
• enviar mensagem resumida com link direto do painel de Debug Log.

Comportamento esperado:

• Ao registrar erro critico com debug_log('MODULO', '...ERRO...'), o sistema tenta enviar:
• ALERTA ERRO no site: [MODULO] ...
• Debug Log: https://www.rionoteatro.com.br/admin/modulos/debug_log/
• Novos alertas ficam bloqueados por 30 minutos para evitar flood.

Validacoes executadas:

• php -l admin/logs/debug_helper.php sem erros de sintaxe.
• Revisao de diff para confirmar anti-loop, debounce e integracao via enviar_whatsapp_admin().

BK-83 · Fila WhatsApp: correção de JSON com quebra de linha + higiene de cache

Data: 03 de Março de 2026

Causa raiz confirmada (pendência travada na fila mesmo com WhatsApp online):

• O bot/whatsapp/healthcheck.sh montava o body JSON do /send por interpolação de string.
• Mensagens com quebra de linha (\n) geravam payload inválido e a API retornava:
• JSON invalido: Bad control character in string literal ...
• Resultado: item permanecia na fila com tentativas incrementando.

Ajustes aplicados:

• bot/whatsapp/healthcheck.sh
• payload do /send passou a ser gerado com jq -cn (escaping seguro de caracteres especiais/quebras de linha).
• .gitignore
• adicionada regra bot/whatsapp/.wwebjs_cache/ (cache runtime do whatsapp-web.js fora do versionamento).

Validações executadas:

• bash -n bot/whatsapp/healthcheck.sh sem erros.
• Execução manual do healthcheck.sh com serviço conectado:
• envio da mensagem pendente concluído com sucesso.
• pasta bot/whatsapp/queue/ ficou vazia após processamento.

BK-82 · QR Code web no admin para reconexao WhatsApp + correcao JSON

Data: 03 de Março de 2026

Causa raiz confirmada (nao exibia QR no navegador):

• O backend Node mostrava QR apenas no terminal (journalctl) e nao expunha endpoint web para o painel.
• O endpoint de restart do admin podia retornar warnings PHP (open_basedir em file_exists('/bin/bash')), quebrando JSON do AJAX e impedindo o fluxo de exibir QR.

Ajustes aplicados:

• bot/whatsapp/server.js
• novo endpoint GET /qr com qr_image_data_url (PNG base64), qr_pending e qr_updated_at.
• cache do ultimo QR em memoria para entrega ao painel admin.
• bot/whatsapp/package.json
• adicionada dependencia qrcode.
• admin/whatsapp_qr.php (novo)
• endpoint autenticado para o admin consultar status + QR do microservico.
• admin/index.php
• bloco visual para exibir QR quando offline.
• polling de whatsapp_qr.php a cada 8s com cache: false.
• fluxo do botao reiniciar trata requires_qr sem reload forcado.
• admin/whatsapp_restart.php
• resposta JSON padronizada com requires_qr e qr_pending.
• blindagem de output (ob_clean) para evitar lixo antes do JSON.
• includes/whatsapp_helper.php
• _whatsapp_tentar_restart() passou a usar bash via PATH (remove warnings de open_basedir ao testar /bin/bash).
• bot/whatsapp/README.md
• documentado endpoint GET /qr.

Validações executadas:

• node --check bot/whatsapp/server.js sem erros.
• php -l em admin/index.php, admin/whatsapp_restart.php, admin/whatsapp_qr.php, includes/whatsapp_helper.php.
• Teste direto da API local:
• GET /status => disconnected com qr_pending=true.
• GET /qr => qr_image_data_url preenchido.
• Teste CLI do endpoint admin:
• REQUEST_METHOD=POST HTTP_HOST=localhost php admin/whatsapp_restart.php retornando JSON valido com requires_qr=true.

BK-80 · RCA WhatsApp Offline + auto-recuperacao systemd

Data: 03 de Março de 2026

Causa raiz confirmada (incidente):

• healthcheck.sh tentava reiniciar via PM2 (pm2 restart whatsapp-bot), mas o bot roda via systemd (rnt-whatsapp).
• cleanup.sh limpava apenas parte dos locks e ainda fazia chown para www-data, divergente do user do service (www), causando falhas recorrentes de lock/sessao.
• Timeout curto no AJAX do painel (30s) gerava falso erro de comunicacao em reinicios mais lentos.

Ajustes aplicados:

• bot/whatsapp/healthcheck.sh
• troca de PM2 para systemctl com fallback sudo -n.
• reinicio apenas quando API local esta indisponivel; disconnected nao força restart.
• lock file com trap para limpeza garantida.
• bot/whatsapp/cleanup.sh
• limpeza ampliada para auth/session (Singleton + DevToolsActivePort).
• kill de processos Chrome/Chromium relacionados ao userDataDir do bot.
• ownership alinhado dinamicamente ao usuario/grupo do service.
• bot/whatsapp/restart.sh
• restart via systemctl com verificacao em loop.
• rotacao simples de restart.log para evitar crescimento infinito.
• includes/whatsapp_helper.php
• _whatsapp_tentar_restart() passou a aguardar ate 45s por reconexao.
• admin/index.php
• timeout AJAX do botao de restart aumentado para 90s.
• bot/whatsapp/server.js
• removido webVersionCache remoto quebrado (URL 404).
• headless alterado para true (estabilidade com Chrome atual).
• client.initialize() com catch explicito e exit(1) para recovery por systemd.
• handler de SIGTERM para encerramento limpo (elimina timeout de stop).
• /etc/systemd/system/rnt-whatsapp.service
• adicionado PermissionsStartOnly=true para permitir ExecStartPre com privilegio de limpeza.

Validações executadas:

• bash -n: healthcheck.sh, cleanup.sh, restart.sh.
• node --check: bot/whatsapp/server.js.
• php -l: includes/whatsapp_helper.php, admin/index.php.
• systemctl restart rnt-whatsapp concluindo sem timeout (elapsed=1s).
• curl http://127.0.0.1:3033/status respondendo com JSON e service active.
• healthcheck.sh manual nao forca restart quando status esta disconnected.

BK-79 · Teatros canônicos sem /teatro + mapa e slugs normalizados

Data: 03 de Março de 2026

Ajustes:

• Teatros passaram a usar URL canônica pública em https://rionoteatro.com.br/<slug_do_teatro>.
• Rotas legadas /teatro/<slug|id> agora redirecionam com 301 para o slug direto.
• Página de teatro (teatro.php) passou a gerar/persistir slug automaticamente quando ausente (incluindo casos antigos como /teatro/118).
• teatros.php, lista-teatros.php e card de “outros teatros” foram ajustados para links diretos sem /teatro/.
• Roteamento de slug direto foi ampliado em peca.php: quando o slug não é peça, mas é teatro, a página do teatro é exibida.
• Mapa em teatro.php deixou de usar maps/embed/v1/place?key=... e passou a usar o mesmo padrão dos eventos (google.com/maps?output=embed&q=...), eliminando erro de API key inválida.
• Geração de slug em eventos/teatros foi reforçada no server-side (admin + painel) para substituir acentuação corretamente (ç -> c, ê -> e, etc.) mesmo com slug digitado manualmente.

Arquivos modificados:

• teatro.php
• teatros.php
• lista-teatros.php
• peca.php
• admin/modulos/teatros/action.php
• admin/modulos/eventos/action.php
• painel/modulos/eventos/action.php

Validações executadas:

• php -l em todos os arquivos PHP alterados: sem erros de sintaxe.
• HTTP: /teatro/118 retornando 301 para /acaso-cultural.
• HTTP: /teatro/grupo-teatros-da-barra retornando 301 para /grupo-teatros-da-barra.
• HTTP: /grupo-teatros-da-barra retornando 200.
• Conferência de HTML: sem links públicos restantes com /teatro/ em teatros.php e lista-teatros.php.

BK-78 · Canonical sem /evento/ em todo fluxo público

Data: 03 de Março de 2026

Ajustes:

• URLs públicas de eventos padronizadas para https://rionoteatro.com.br/<slug> nas listagens de eventos.php e teatro.php.
• Rota legada /evento/<slug> passou a responder com redirecionamento 301 para o slug canônico (preservando query string útil).
• go.php deixou de gerar destino /evento/<slug> (inclusive quando dest=evento) e agora direciona sempre para /<slug>.
• Metadados SEO em evento.php atualizados com rel="canonical" e og:url apontando para o slug canônico.
• Link de visualização pública no admin (admin/modulos/eventos/index.php) atualizado para o padrão sem /evento/.

Arquivos modificados:

• eventos.php
• teatro.php
• evento.php
• go.php
• admin/modulos/eventos/index.php

Validações executadas:

• php -l em todos os arquivos PHP alterados: sem erros de sintaxe.
• Teste HTTP: /evento/sarav-a-com-dia e /evento/os-homens-querem-casar retornando 301 para /<slug>.
• Teste HTTP: /go/<slug>?dest=evento retornando destino final sem /evento/.

BK-74 · UX WhatsApp + Lista diária também por WhatsApp

Data: 03 de Março de 2026

Ajustes:

• CTA de parceria no cadastro de eventos atualizado para "Fechei a Parceria Gratuita + Venda!".
• Texto pré-preenchido da mensagem WhatsApp do fluxo de parceria atualizado para a nova frase.
• Envio da lista digital diária de compradores passou a usar canal duplo:
• e-mail (fluxo existente preservado)
• WhatsApp para o celular do produtor (clientes.celular) quando disponível.

Observação de auditoria:

• painel/modulos/eventos/editar.php não possui atualmente botão WhatsApp equivalente ao fluxo de parceria do incluir.php.

Arquivos modificados:

• painel/modulos/eventos/incluir.php
• disparaemail.php
• docs/BACKLOG.md

BK-70 · Ajuste de frequência do alerta de token Facebook

Data: 03 de Março de 2026

Ajuste:

• O alerta cron_sync_facebook_token_error foi calibrado para repetição de 1 em 1 hora (min_seconds=3600, force=false).
• Objetivo: manter visibilidade do incidente sem voltar ao spam de intervalos curtos.

Arquivo modificado:

• admin/cron/sync_facebook_events.php

BK-69 · Debounce de alerta crítico do token Facebook + backlog rápido

Data: 03 de Março de 2026

Ajustes:

• Reduzido spam de WhatsApp no erro de token inválido/expirado do cron social.
• Alterado cron_sync_facebook_token_error para respeitar debounce real:
• min_seconds: 21600 (6h)
• force: false
• Mantido o exit(1) no cron quando token está inválido (comportamento operacional preservado).

Backlog documentado nesta entrega:

• Ajuste textual do CTA WhatsApp em painel/modulos/eventos/incluir.php e painel/modulos/eventos/editar.php.
• Envio complementar por WhatsApp do link diário da lista de compradores para o produtor.

Arquivos modificados:

• admin/cron/sync_facebook_events.php
• docs/BACKLOG.md

BK-66 · Parceria Premium (Admin x Produtor) + Visibilidade em Home/Peças

Data: 03 de Março de 2026

Funcionalidades:

• Admin ganhou ação dedicada para ativar Parceria Premium direto na edição do evento.
• Tela de eventos no admin recebeu botão + modal de confirmação para o fluxo de ativação.
• Módulo de peças do admin recebeu ação para desfazer Parceria Premium e botão de atalho.
• Listagem de peças/home pública passou a aceitar também eventos com parceria_online = 1.
• Fluxo do produtor foi ajustado para manter semântica de pendência (status/editado_produtor) no modo parceria.

Arquivos modificados:

• admin/modulos/eventos/action.php
• admin/modulos/eventos/editar.php
• admin/modulos/pecas/action.php
• admin/modulos/pecas/index.php
• painel/modulos/eventos/action.php
• index.php
• pecas.php

Validações executadas:

• php -l em todos os arquivos alterados: sem erros de sintaxe.
• Verificação de diff hygiene (git diff --check): sem trailing whitespace.

Dias da Semana e Horarios nos Eventos + Bot Captador

Data: 12 de Fevereiro de 2026

Funcionalidades:

• Novos campos dias_semana e horarios na tabela pecas (eventos)
• Painel do produtor: campos para informar dias da semana e horários do evento
• Bot capturador Sympla: extrai automaticamente dias e horários da agenda
• Admin: ao aprovar evento do bot, campos dias_semana e horários são salvos automaticamente
• Busca em eventos.php: agora busca também por dias da semana e horários
• Fallback na busca: se não encontrar sessões cadastradas, verifica se a data está dentro do período da temporada

Banco de Dados:

• Script SQL: update_pecas_schema.sql - Adiciona colunas dias_semana e horarios
• Script PHP: add_columns.php - Adiciona colunas via PHP (alternativa ao SQL)

Arquivos criados:

• update_pecas_schema.sql - Script SQL para adicionar colunas
• add_columns.php - Script PHP para adicionar colunas via código
• check_pecas_schema.php - Verifica estrutura da tabela pecas
• check_schema_temp.php - Script temporário de verificação

Arquivos modificados:

• eventos.php - Busca agora inclui dias_semana e horarios nos filtros
• painel/modulos/eventos/incluir.php - Campos dias_semana e horarios no formulário
• painel/modulos/eventos/editar.php - Campos dias_semana e horarios na edição
• painel/modulos/eventos/action.php - Salva dias_semana e horarios no cadastro
• admin/modulos/eventos/action.php - Salva dias_semana e horarios ao aprovar evento do bot
• bot/scrapers/sympla_scraper.php - Extrai dias e horários da agenda do Sympla

Busca Inteligente em Eventos

Data: 12 de Fevereiro de 2026

Funcionalidades:

• Campo de busca na pagina eventos.php (igual ao de teatros.php)
• Busca por: nome do evento, nome do teatro, bairro
• Busca por dia da semana (ex: "sabado", "segunda-feira")
• Busca por data especifica (ex: "23/04", "15/03/2025")
• Busca por data por extenso (ex: "23 de abril", "15 de março")
• Busca por dia do mes (ex: "15" - encontra eventos no dia 15 de qualquer mes)
• Filtro client-side instantaneo sem recarregar pagina
• Contador de resultados em tempo real

Estilo Visual:

• Implementado modo dark igual ao teatros.php
• Fundo escuro (var(--dark-card)) com borda sutil (var(--dark-border))
• Texto claro (var(--text-primary)) com placeholder em tom medio (var(--text-secondary))
• Efeito glow verde ao focar (var(--accent-green))
• Remove div rnt-container extra para layout mais limpo

Arquivos modificados:

• eventos.php - Adicionado campo de busca com filtros inteligentes e estilo dark mode

Arquivos de backup criados:

• eventos_backup_20260212.php

Notificacoes WhatsApp para Admin/Produtores + Resiliencia

Data: 09 de Fevereiro de 2026

Funcionalidades:

• Notificacoes WhatsApp para admin: novo produtor cadastrado, novo evento criado, interesse em creditos
• Notificacoes WhatsApp para produtores: cadastro aprovado/rejeitado, evento aprovado/correcao, conta bloqueada
• Sistema de resiliencia com auto-recuperacao: healthcheck antes de enviar, restart automatico se offline, fila de mensagens
• Restart preventivo apos envio bem-sucedido (limpa Chrome zumbis e locks)
• Nenhuma mensagem se perde: toda falha (cURL, HTTP, offline) enfileira automaticamente
• Dashboard admin com status WhatsApp em tempo real (verde=online, vermelho=offline) + contador de fila
• Cron de backup (a cada 2h) para processar fila em horarios sem movimento

Arquivos criados:

• includes/whatsapp_helper.php - Helper com funcoes reutilizaveis: enviar_whatsapp(), enviar_whatsapp_admin(), fila, healthcheck, restart
• bot/whatsapp/cleanup.sh - Mata zumbis Chrome + remove locks Puppeteer
• bot/whatsapp/restart.sh - Restart seguro do servico (cleanup + systemctl restart)
• bot/whatsapp/healthcheck.sh - Script cron para verificar saude e processar fila
• bot/whatsapp/SETUP_RESILIENCIA.md - Documentacao completa do setup no servidor

Arquivos modificados:

• action.php (root) - Notificacao WhatsApp ao admin quando novo produtor se cadastra
• painel/modulos/eventos/action.php - Notificacao WhatsApp ao admin quando novo evento e criado
• admin/modulos/produtores/action.php - WhatsApp para produtor (aprovacao/rejeicao/bloqueio)
• admin/modulos/eventos/action.php - WhatsApp para produtor (aprovacao/correcao de evento)
• admin/modulos/eventos/index.php - Fix: badge de eventos pendentes mostrava 0
• admin/modulos/eventos/editar.php - Fix: alerta de exclusao aparecia indevidamente (editado_produtor==4)
• admin/index.php - Dashboard com status WhatsApp em tempo real (verde/vermelho)
• painel/modulos/creditos/action.php - Notificacao WhatsApp quando produtor clica pacote creditos
• painel/modulos/creditos/index.php - AJAX para notificar + CSS redesign_2026

Setup servidor (manual):

• systemd: ExecStartPre=/bin/bash cleanup.sh (limpeza antes de cada start)
• Sudoers: www-data pode executar systemctl restart/is-active sem senha
• Cron aaPanel: healthcheck.sh a cada 2 horas
• Permissoes: restart.log com ownership www-data

Microservico WhatsApp + Scraping SPA + Alertas Bot Captador

Data: 08-09 de Fevereiro de 2026

Funcionalidades:

• Microservico Node.js para envio de mensagens WhatsApp via whatsapp-web.js (Puppeteer + Chrome headless)
• Endpoint POST /scrape para scraping de paginas SPA (Sympla) com scroll automatico e lazy loading
• Sistema de alertas integrado ao Bot Captador (WhatsApp primario, email fallback)
• Modulo debug_log no admin para monitoramento em tempo real
• Filtro "Somente BOT" no admin de eventos

Arquivos criados:

• bot/whatsapp/server.js - Servidor principal (API REST + WhatsApp + Scrape)
• bot/whatsapp/package.json - Dependencias npm (whatsapp-web.js, qrcode-terminal)
• bot/whatsapp/setup.sh - Script de instalacao para VPS com systemd
• bot/whatsapp/README.md - Documentacao completa do microservico
• bot/handlers/alert_handler.php - Handler de alertas (WhatsApp + email)

Arquivos modificados:

• config/bot_config.php - Configuracoes WhatsApp (URL, API key, numero alerta)
• bot/cron_captador.php - Integracao com AlertHandler pos-execucao
• admin/modulos/eventos/index.php - Filtro "Somente BOT" nas abas

Detalhes tecnicos:

• Engine: whatsapp-web.js v1.26+ com webVersionCache remoto
• Chrome: Google Chrome Stable (nao snap) em servidor headless
• Porta: 3033 (localhost only, protegida por API key)
• Servico: systemd rnt-whatsapp (User=www-data, Restart=on-failure)
• Sessao persistente via LocalAuth em bot/whatsapp/auth/

SQL executado:

• SQL/bot_melhorias_20260208.sql - Migracao InnoDB + tabela bot_alertas_log

2025

Sistema de Produtores - Historico Completo

FASES CONCLUIDAS

FASE 18: Integração de Recursos Premium no Cadastro de Eventos

Data: 02 de Dezembro de 2025

Funcionalidade:

• Integração completa da contratação de recursos premium diretamente no formulário de inclusão de eventos (incluir.php).
• Objetivo: Aumentar a conversão de upgrades no momento de maior interesse do produtor (criação do evento).

Implementação:

• [x] 18.1 - Seção de Recursos Premium no Formulário
• Adicionada seção visual "Recursos Premium" ao final do formulário de cadastro.
• Exibição em tempo real do saldo de créditos do produtor.
• Cards informativos com 3 grupos de ofertas:

1. Pacotes Completos: Combo Premium (500 créditos).
2. Destaques Individuais: Home (300 créditos) e Topo (200 créditos).
3. Recursos Adicionais: Link Externo (50 créditos).

• [x] 18.2 - Fluxo de Contratação Inteligente
• Auto-save: Ao clicar em ativar um recurso, o sistema salva automaticamente o evento primeiro (rascunho) para garantir que o ID exista.
• Modals de Confirmação: Detalham custos, benefícios e saldo final antes da confirmação.
• Validação de Saldo: Bloqueia ativação se saldo insuficiente e sugere compra de créditos.
• Feedback Visual: Botões com estados de carregamento e mensagens de sucesso/erro via Toastr.

Arquivos Modificados:

• painel/modulos/eventos/incluir.php
• painel/modulos/eventos/js/incluir.js (lógica de auto-save e ativação)

Impacto:

• Simplifica a jornada do produtor, permitindo destacar o evento imediatamente após o cadastro sem navegar por múltiplos menus.

FASE 17: Correção de Scroll no Painel 🐛

Data: 02 de Dezembro de 2025

Problema Identificado:

• A página painel/index.php não rolava para baixo apesar de ter conteúdo extenso.
• O problema era causado pela biblioteca jquery.nicescroll.js que conflita com renderizações modernas no elemento html.

Correções Aplicadas:

• [x] 17.1 - Desativação Local do NiceScroll
• Adicionado script em painel/index.php para remover o nicescroll especificamente nesta página.
• Mantido o funcionamento global do nicescroll para outras páginas (sidebar, etc) para evitar regressões visuais.
• Restaurado overflow: auto no elemento html.

Arquivos Modificados:

• painel/index.php

Backups Criados:

• painel/index_bkp_20251202.php
• painel/js/common-scripts_bkp_20251202.js (criado durante tentativa anterior, mantido por segurança)

Impacto:

• Restaura a usabilidade da Home do Painel permitindo acesso a todo o conteúdo.

FASE 16: Correção de Mensagens de Erro no Checkout 🐛

Data: 12 de Novembro de 2025

Problema Identificado:

• Mensagens de erro (warning/info) não apareciam ao tentar cadastrar email/CPF/RG duplicado
• JavaScript buscava apenas .alert-danger mas action.php retornava status "warning" ou "info"
• Usuários não recebiam feedback visual, levando ao abandono do processo de compra
• Possível causa da queda de vendas desde 02/11/2025

Correções Aplicadas:

• [x] 16.1 - Refatoração do Sistema de Alertas no pedido.php
• JavaScript agora busca alerta dinamicamente: .alert-{status} (warning, info, danger, success)
• Adiciona classe show necessária para exibir alertas (CSS usa display: none !important)
• Implementado scroll suave até o alerta para melhor UX
• Esconde alertas anteriores antes de mostrar o novo
• Aplicado em ambos os fluxos:
• Botão "Continuar para Pagamento" (usuário NÃO logado) - linhas 947-966
• Botão "Entendi, Prosseguir" (usuário logado) - linhas 1013-1032

• [x] 16.2 - Testes Completos via CURL
• ✅ Cadastro com CPF/Email/RG duplicado → Retorna status: "warning" com mensagem
• ✅ Cadastro com CPF inválido → Retorna status: "info" com mensagem
• ✅ Cadastro válido (novo usuário) → Retorna status: "success" + URL PagSeguro
• ✅ Validação de redirecionamento PagSeguro → Funcionando corretamente
• ✅ Validação de datas indisponíveis → Sistema valida corretamente

Arquivos Modificados:

• pedido.php - Linhas 947-966 (fluxo novo cadastro) e 1013-1032 (fluxo usuário logado)

Backups Criados:

• pedido_bkp_12112025.php - Backup antes das alterações

Impacto:

• Melhora significativa na UX do checkout
• Usuários agora recebem feedback claro sobre erros
• Redução de abandono de carrinho por falta de feedback
• Possível recuperação das vendas que caíram desde 02/11

Deploy:

• Commit: 722f38af
• Branch: main
• Deploy automático: ~1 minuto após push
• Status: ✅ EM PRODUÇÃO

FASE 15: Campo Status Admin + Exclusão de Fotos 🎛️

Data: 10 de Novembro de 2025

• [x] 15.1 - Exclusão de Fotos pelo Produtor
• Implementado botão "Excluir Foto" em painel/modulos/eventos/editar.php
• Função JavaScript deletarFoto() com confirmação
• Case deletar_foto em painel/modulos/eventos/action.php
• Deleta arquivos físicos de /large/ e /media/
• Remove registro do banco (tb_fotos)
• Validação de permissões (produtor só deleta suas fotos)
• Logs detalhados para debugging

• [x] 15.2 - Correção JSON no Admin
• Corrigido erro "SyntaxError: Unexpected token '<'" em admin/modulos/eventos/action.php
• Movido processamento de formulário PARA DENTRO dos cases
• Removido suporte a AVIF (PHP 5.6)
• Adicionados 4 cases especiais: aprovar, informar_correcao, rejeitar_definitivo, limpar_historico
• Restaurado Cropper.js no admin

• [x] 15.3 - Campo Status no Admin ⭐
• Adicionado campo <select name="status"> em admin/modulos/eventos/editar.php
• Dropdown com 2 opções: 'A' (Ativo) e 'I' (Inativo)
• Admin pode controlar visibilidade do evento manualmente
• Processamento em admin/modulos/eventos/action.php:
• Case 'cadastrar': Admin escolhe status inicial
• Case 'editar': Admin altera status manualmente
• Produtor continua sem acesso (status sempre 'I')
• Campo obrigatório com validação
• Help text explicativo

Arquivos Criados:

• docs/FUNCIONALIDADE_EXCLUSAO_FOTOS.md - Documentação de exclusão de fotos
• docs/CORRECAO_ACTION_ADMIN.md - Correção do action.php do admin
• docs/RESTAURACAO_CROP_ADMIN.md - Restauração do crop
• docs/CAMPO_STATUS_ADMIN.md - Documentação do campo status

Arquivos Modificados:

• painel/modulos/eventos/editar.php - Botão de exclusão de foto
• painel/modulos/eventos/action.php - Refatoração completa (case deletar_foto)
• admin/modulos/eventos/editar.php - Campo status + restauração do crop
• admin/modulos/eventos/action.php - Refatoração completa + processamento de status

Backups Criados:

• painel/modulos/eventos/editar_bkp_20251110.php
• painel/modulos/eventos/action_bkp_20251110.php
• painel/modulos/eventos/action_bkp_20251110_v2.php
• admin/modulos/eventos/editar_bkp_20251110_simplificado.php
• admin/modulos/eventos/editar_bkp_20251110_v2.php
• admin/modulos/eventos/editar_bkp_20251110_v3.php
• admin/modulos/eventos/action_bkp_20251110_v2.php
• admin/modulos/eventos/action_bkp_20251110_v3.php

Problema Resolvido:

• Código de processamento executava ANTES do switch, causando PHP Notices quando $_POST não tinha os campos esperados
• Solução: Movido TODO o processamento para DENTRO de cada case específico

Compatibilidade:

• PHP 5.6+ (sem AVIF)
• WebP com verificação function_exists()
• jQuery (usando jQuery ao invés de $ para compatibilidade global)

FASE 14: Sistema Completo de Tracking de ROI 📊

Data: 04 de Novembro de 2025

• [x] 14.1 - Estrutura de Banco de Dados
• Criadas 4 novas tabelas: campanhas, campanhas_roi, campanhas_alertas, robot_config
• Adicionados 5 campos UTM em cliente_tracking: utm_source, utm_medium, utm_campaign, utm_content, utm_term
• Criadas 2 VIEWs: v_campanhas_performance, v_ranking_fontes
• Criadas 2 Stored Procedures: sp_calcular_roi_campanhas, sp_gerar_alertas_roi
• Índices otimizados para performance em todas as tabelas

• [x] 14.2 - Tracking Frontend Automático
• Criado js/utm-tracker.js para captura automática de UTM parameters
• Sistema de cookies (7 dias) e sessão PHP
• Tracking de 3 eventos: view_item, begin_checkout, purchase
• First touch e last touch attribution
• APIs backend: api/track-utm.php, api/track-event.php

• [x] 14.3 - Módulo Admin Completo de Campanhas
• 8 arquivos PHP em admin/modulos/campanhas/:
• index.php - Listagem com 4 cards de métricas
• incluir.php - Criar campanha com preview de link UTM
• editar.php - Editar com métricas ao vivo
• detalhes.php - Visão completa + gráfico de evolução
• dashboard-roi.php - Dashboard com Chart.js (3 gráficos)
• alertas.php - Sistema de alertas inteligentes
• action.php - Backend com 8 actions (criar, editar, deletar, etc.)
• bootstrap.php - Configuração do módulo

• [x] 14.4 - Dashboard Analítico com Gráficos
• Chart.js 3.9.1 para visualizações
• Gráfico 1: Evolução do ROI (linha temporal)
• Gráfico 2: Receita por Fonte (pizza)
• Gráfico 3: Performance por Fonte (barras)
• Top 5 melhores e piores campanhas
• Filtros por período (data início/fim)
• KPIs em tempo real

• [x] 14.5 - Sistema de Alertas Automáticos
• 5 tipos de alertas: roi_positivo, roi_negativo, baixa_conversao, alto_custo, meta_atingida
• 4 níveis de prioridade: urgente, alta, media, baixa
• 4 status: novo, lido, resolvido, ignorado
• Ações sugeridas automáticas
• Interface completa com filtros e ações rápidas

• [x] 14.6 - Robô de Análise Automática
• Script admin/cron/analisar_roi_campanhas.php
• 7 passos de execução automática:

1. Carrega configurações do robô
2. Calcula ROI de campanhas ativas
3. Gera alertas inteligentes
4. Busca alertas para notificação
5. Envia email HTML com resumo
6. Limpa alertas antigos (>30 dias)
7. Gera estatísticas finais

• Sistema de logs detalhados em admin/cron/logs/
• Compatível com CLI e execução WEB
• Pronto para cron job diário

• [x] 14.7 - Métricas Calculadas
• ROI % e Valor (lucro líquido)
• CPA (Custo Por Aquisição)
• Taxa de Conversão
• Ticket Médio
• Receita Bruta
• Visualizações, Checkouts, Vendas

• [x] 14.8 - Documentação Completa
• docs/SISTEMA_TRACKING_ROI.md (1000+ linhas) - Manual completo
• docs/GUIA_TESTES_ROI.md - 34 casos de teste em 7 fases
• docs/RESUMO_IMPLEMENTACAO_ROI.md - Resumo executivo
• docs/CHECKLIST_POS_UPLOAD.md - Validação pós-deploy
• admin/cron/README.md - Configuração do cron job

Arquivos Criados:

• SQL: EXECUTAR_ESTE.sql, EXECUTAR_FALTANTE.sql, adicionar_menu_campanhas.sql
• JS: js/utm-tracker.js
• APIs: api/track-utm.php, api/track-event.php
• Admin: 8 arquivos em admin/modulos/campanhas/
• Cron: admin/cron/analisar_roi_campanhas.php
• Docs: 4 arquivos em docs/

Arquivos Modificados:

• includes/inc_peca.php → includes/inc_peca_2026.php (adicionado utm-tracker.js na linha 451)
• meta-analytics.php (adicionadas variáveis globais JavaScript nas linhas 250-260)

Banco de Dados:

• 4 novas tabelas
• 5 campos adicionados em cliente_tracking
• 2 VIEWs
• 2 Stored Procedures
• 8 configurações do robô

Tecnologias:

• PHP 5.6+ (mysql_* functions)
• MySQL 5.7+ (VIEWs, Stored Procedures)
• JavaScript ES5 (compatibilidade)
• Chart.js 3.9.1
• Bootstrap 3.x
• Parsley.js (validação)

Total: 24 arquivos criados/modificados | ~8.000 linhas de código

Status: ✅ Testado e funcionando em produção

Documentação: Ver SISTEMA_TRACKING_ROI.md (SISTEMA_TRACKING_ROI.md) para manual completo

FASE 13: Democratização do Acesso aos Eventos 🎭

Data: 03 de Novembro de 2025

• [x] 13.1 - Documento opcional no cadastro de produtor
• Removida obrigatoriedade de anexar documento em cadastro-produtor.php
• Campo "Documento Comprobatório" agora é opcional
• Backend action.php adaptado para aceitar envio vazio
• Objetivo: Facilitar inclusão de novos produtores

• [x] 13.2 - Link "Divulgue seu Evento" dinâmico
• Link do menu público agora muda baseado no estado de login
• NÃO logado → /cadastro-produtor.php
• Logado → /painel/modulos/eventos/
• Implementado em desktop e mobile

• [x] 13.3 - Correção de layout da página de login
• Removido padding-top: 100px do body
• Menu agora encosta no topo da página
• Login wrapper centralizado com flexbox
• Adicionado margin: 0 auto para centralização horizontal

• [x] 13.4 - Sistema de redirect inteligente para login
• Login redireciona para pecas.php por padrão
• Exceção: Se estava em peca.php, volta para o evento específico
• Cadastro e compra mantêm comportamento original (qualquer página)
• Aplicado em login AJAX e Google OAuth

• [x] 13.5 - Menu "Divulgar Eventos" visível para todos
• Removida verificação de is_produtor no painel/inc-menu.php
• Nome alterado: "Meus Eventos" → "Divulgar Eventos"
• Link agora SEMPRE visível para todos os clientes
• Código simplificado (removida query com JOIN)

• [x] 13.6 - Documentação completa atualizada
• Nova seção "Menu do Painel do Cliente" em menu.md
• Resumo de todas as 5 alterações documentado
• Histórico de versões atualizado para 3.2
• Comparação ANTES/DEPOIS dos fluxos

Arquivos Modificados:

• cadastro-produtor.php (../cadastro-produtor.php) (linha 82-85)
• action.php (../action.php) (linhas 145-166, 221-243, 966-999)
• includes/inc_peca.php (../includes/inc_peca.php) (linhas 483-487, 531, 541)
• painel/login.php (../painel/login.php) (linhas 46-71)
• painel/inc-menu.php (../painel/inc-menu.php) (linhas 17-23)
• docs/menu.md (../docs/menu.md) (versão 3.2)

Status: ✅ Funcionando em produção

FASE 12: Implementação de Toastr em Formulários 🔔

Data: 31 de Outubro de 2025

• [x] 12.1 - Correção do sistema de alertas em cadastre-se.php
• Substituído sistema legado de alertas HTML por notificações Toastr
• Adicionada biblioteca Toastr (CSS e JS) no cadastre-se.php
• Configuração centralizada de Toastr com barra de progresso
• Posicionamento: topo centralizado (toast-top-center)

• [x] 12.2 - Atualização de js/cadastre-se.js (v1.0.1 → v1.0.2)
• Reescrita completa do handler de sucesso AJAX
• Implementada lógica especial para emails duplicados
• Adicionado link clicável para "Recuperar Senha" em erros de duplicidade
• Timeout estendido (15s) para mensagens de erro com ações
• Removido sistema antigo de scroll e manipulação de elementos HTML

• [x] 12.3 - Padronização de notificações
• Formato consistente: toastrstatus (message)
• Suporte a HTML em mensagens (links, botões, ícones)
• Tratamento de erros genéricos (falha de comunicação)
• Redirecionamento automático após 3 segundos em caso de sucesso

• [x] 12.4 - Testes completos via cURL
• ✅ Teste 1: Cadastro novo - PASSOU
• ✅ Teste 2: Email duplicado - PASSOU
• ✅ Teste 3: CPF inválido - PASSOU
• ✅ Teste 4: Segundo cadastro novo - PASSOU
• ✅ Teste 5: Cadastro produtor (email duplicado) - PASSOU
• ✅ Teste 6: Cadastro produtor (sem documento) - PASSOU

• [x] 12.5 - Documentação
• Criado formularios.md (formularios.md) com documentação completa
• Documentados todos os formulários do sistema
• Incluídos exemplos de uso, troubleshooting e testes
• Adicionado roadmap de melhorias futuras

Arquivos Modificados:

• cadastre-se.php (../cadastre-se.php) (linhas 13, 308)
• js/cadastre-se.js (../js/cadastre-se.js) (reescrita)

Status: ✅ Funcionando em produção

FASE 11: Simplificação do Upload de Imagens 🎨

• [x] 11.1 - Refatoração para input file nativo HTML5
• Removido sistema drag-drop complexo do gestor de imagens
• Implementado input file nativo com atributo accept para validação
• Interface mais simples e intuitiva para produtores
• [x] 11.2 - Preview instantâneo da imagem
• JavaScript com FileReader API para preview antes do upload
• Validação client-side de formato (JPG, JPEG, PNG)
• Validação de tamanho (máximo 5MB)
• Mensagens de erro claras e específicas
• [x] 11.3 - Unificação da interface
• Campo de foto adicionado diretamente no formulário de incluir.php
• Campo de foto adicionado diretamente no formulário de editar.php
• Removido alerta "Importante: Após preencher os dados..."
• Removida seção separada "Gestor de Foto do Evento"
• [x] 11.4 - Limpeza de código
• Removidos scripts não utilizados (uploader-eventos.js)
• Removidas bibliotecas de drag-drop não necessárias
• Código JavaScript inline simplificado
• Redução de dependências externas

FASE 10: Upload de Imagens para Eventos 📸

• [x] 10.1 - Integração do Gestor de Imagens no fluxo de eventos
• Redirect automático para editar.php após cadastro (com ID do evento)
• Mensagem incentiva: "Agora adicione uma foto para deixar seu evento mais atrativo!"
• [x] 10.2 - Gestor de Fotos no editar.php
• Seção "Foto do Evento" totalmente funcional
• Upload de APENAS 1 foto (limite configurado)
• Sem vídeos, sem tabs (simplificado para produtores)
• Script customizado: painel/modulos/eventos/js/uploader-eventos.js (../painel/modulos/eventos/js/uploader-eventos.js)
• [x] 10.3 - Preview visual no incluir.php
• Seção de foto visível mas desabilitada (opacity: 0.5; pointer-events: none)
• Alerta amarelo: "Salve o evento primeiro!"
• UX clara: produtor já vê onde vai adicionar a foto
• [x] 10.4 - Configurações de upload
• Formatos aceitos: JPG, JPEG, PNG
• Limite: 1 foto por evento
• Mensagem de erro: "Máximo de 1 foto permitida. Delete a foto atual para enviar outra."
• Admin mantém funcionalidades completas (múltiplas fotos e vídeos)

FASE 9: Estrutura de Relacionamento Produtor-Peça 🔗

• [x] 9.1 - Análise completa da estrutura atual vs. ideal
• Documento: ANALISE_ESTRUTURA_PECAS.md (ANALISE_ESTRUTURA_PECAS.md)
• Identificado conflito: código tentava usar id_cliente, SQL planejado usava id_produtor
• Decisão: implementar id_produtor (semântica correta + performance)
• [x] 9.2 - Alteração do banco de dados
• Script: /SQL/SQL_ADD_ID_PRODUTOR_PECAS.sql (../SQL/SQL_ADD_ID_PRODUTOR_PECAS.sql)
• Executado: ALTER TABLE pecas ADD COLUMN id_produtor INT NULL
• Criado índice: idx_id_produtor para performance
• Coluna editado_produtor já existia (não foi necessário criar)
• [x] 9.3 - Correção do código do painel
• painel/modulos/eventos/action.php:84 (../painel/modulos/eventos/action.php#L84) - INSERT com id_produtor
• painel/modulos/eventos/index.php:77 (../painel/modulos/eventos/index.php#L77) - Listagem filtrando por id_produtor
• painel/modulos/eventos/editar.php:14 (../painel/modulos/eventos/editar.php#L14) - Verificação de propriedade
• painel/modulos/eventos/sessoes.php:15 (../painel/modulos/eventos/sessoes.php#L15) - Verificação de propriedade
• Todas queries de segurança atualizadas
• [x] 9.4 - Otimização do código do admin
• admin/modulos/pecas/index.php:111-115 (../admin/modulos/pecas/index.php#L111-L115) - Query otimizada com LEFT JOIN
• Eliminado lookup ineficiente por produtor_email
• Contador de pendentes usando editado_produtor = 1
• Performance melhorada significativamente

FASE 8: Correções Críticas e Debug 🐛

• [x] 8.1 - Criação de DEBUG.md (DEBUG.md) com processo de exposição de erros SQL
• [x] 8.2 - Correção inicial de nomenclatura (descobriu necessidade da Fase 9)
• [x] 8.3 - Implementação de editado_produtor=1 ao criar/editar peças
• Nova peça: marca editado_produtor=1 (aguarda aprovação admin)
• Edição de peça: marca editado_produtor=1 e status=I (aguarda nova aprovação)
• Admin aprova: altera editado_produtor=0 e status=A (peça vai ao ar)

FASE 7: Módulo Admin de Produtores 🎭

• [x] 7.1 - Criação completa do módulo /admin/modulos/produtores/
• [x] 7.2 - Sistema de listagem com JOIN à tabela clientes
• [x] 7.3 - Formulário de aprovação/rejeição/bloqueio (detalhe.php)
• [x] 7.4 - Campos Email e Celular editáveis no admin
• [x] 7.5 - Visualização de documentos anexados (PDF e imagens)
• [x] 7.6 - Sistema de status com dropdown (pendente, ativo, rejeitado, bloqueado)
• [x] 7.7 - Campos de motivo de rejeição e bloqueio
• [x] 7.8 - Correção de roteamento AJAX com data-action-url
• [x] 7.9 - Refatoração de SQL UPDATE para melhor tratamento de erros
• [x] 7.10 - Exibição de status e motivo de rejeição no painel do cliente
• [x] 7.11 - Sistema de resubmissão após rejeição (máx 3 tentativas)
• [x] 7.12 - Atualização automática de clientes.is_produtor ao aprovar

FASE 6: Backend de Solicitação de Produtor 🚀

• [x] 6.1 - Implementar case "solicitar_produtor" em produtor/action.php
• [x] 6.2 - Sistema completo de upload de documentos
• [x] 6.3 - Validações de segurança (tipo, tamanho, tentativas)
• [x] 6.4 - Integração com tabela tb_produtores
• [x] 6.5 - Controle de status e tentativas (máx 3)
• [x] 6.6 - Correção do frontend para enviar para produtor/action.php
• [x] 6.7 - Implementação de div para exibir motivo de rejeição
• [x] 6.8 - Backup de segurança do arquivo produtor/action.php

FASE 1: Preparação e Backup ⚠️

• [x] 1.1 - Backup de todos os arquivos que serão modificados
• [x] 1.2 - Análise da estrutura atual do banco de dados
• [x] 1.3 - Documentação das modificações necessárias

FASE 2: Estrutura de Banco de Dados 🗄️

• [x] 2.1 - Adicionar campo use_cpf na tabela tab_users
• [x] 2.2 - Adicionar campo produtor_email na tabela pecas
• [x] 2.3 - Adicionar campo status_aprovacao na tabela pecas
• [x] 2.4 - Criar índices necessários for performance

FASE 3: Sistema de Cadastro Público 📝

• [x] 3.1 - Criar página /cadastro-produtor.php (formulário público)
• [x] 3.2 - Criar validação de CPF e e-mail únicos
• [x] 3.3 - Sistema de confirmação por e-mail (no-reply@rionoteatro.com.br)
• [x] 3.4 - Integrar com design atual do site

FASE 4: Modificações no Admin 👨💼

• [x] 4.1 - Modificar /admin/modulos/administradores/index.php (adicionar CPF)
• [x] 4.2 - Modificar /admin/modulos/pecas/index.php (aba aprovação + filtros)
• [x] 4.3 - Sistema de controle via Status (Ativo/Inativo) + campo editado_produtor
• [x] 4.4 - Sistema de notificação por e-mail para produtores

📊 IMPLEMENTAÇÕES RECENTES (Outubro 2025)

🎨 Simplificação do Upload de Imagens para Eventos ✅

Data: 26/10/2025

• FUNCIONALIDADE IMPLEMENTADA: Refatoração completa do sistema de upload de fotos para interface nativa HTML5
• MOTIVAÇÃO:
• Sistema drag-drop anterior era complexo demais para apenas 1 foto
• Dependências externas desnecessárias (uploader-eventos.js, jquery.uploadfile.min.js)
• Interface confusa com seções separadas e alertas múltiplos
• MUDANÇAS IMPLEMENTADAS:
• Input File Nativo:
• Substituído sistema drag-drop por <input type="file">
• Atributo accept="image/jpeg,image/jpg,image/png" para validação nativa
• Compatível com todos navegadores modernos e mobile
• Preview Instantâneo:
• JavaScript puro com FileReader API
• Preview da imagem antes do upload (sem necessidade de salvar)
• Imagem exibida em tamanho otimizado (max-width: 300px, max-height: 200px)
• Validações Client-Side:
• Tamanho máximo: 5MB (alerta antes do upload)
• Formatos aceitos: JPG, JPEG, PNG (validação dupla: HTML5 + JS)
• Mensagens de erro específicas e claras
• Interface Unificada:
• Campo de foto integrado diretamente no formulário
• Mesmo comportamento em incluir.php e editar.php
• Removidos alertas informativos redundantes
• Removida seção separada "Gestor de Foto do Evento"
• Limpeza de Código:
• Removidos 140+ linhas de código desnecessário
• Eliminadas 5 dependências de bibliotecas externas
• JavaScript simplificado (30 linhas vs. 92 anteriores)
• ARQUIVOS MODIFICADOS:
• painel/modulos/eventos/incluir.php
• Removido alerta informativo (linhas 76-79)
• Removida seção "Gestor de Foto do Evento" (linhas 177-194)
• Adicionado input file com preview no formulário principal
• Adicionado JavaScript de validação e preview (30 linhas)
• painel/modulos/eventos/editar.php
• Removida seção "Gestor de Foto do Evento" (linhas 201-216)
• Adicionado input file com preview no formulário principal
• Removidos scripts de upload antigos (linhas 337-344)
• Adicionado JavaScript de validação e preview (30 linhas)
• BENEFÍCIOS:
• ✅ Interface mais simples e intuitiva
• ✅ Menos dependências externas (melhor performance)
• ✅ Preview instantâneo melhora UX
• ✅ Compatibilidade mobile melhorada
• ✅ Código mais limpo e manutenível
• ✅ Validações mais claras para o usuário
• IMPACTO:
• Redução de ~60% no código relacionado a upload
• Interface unificada entre incluir e editar
• Experiência do usuário mais fluida
• OBSERVAÇÃO:
• ⚠️ Backend (action.php) precisará ser ajustado para processar upload via formulário
• 📝 Documentação atualizada em README.md e RESUMO_FASE_11.md

🔒 reCAPTCHA v3 Invisível - Esqueceu Senha ✅

Data: 25/10/2025

• FUNCIONALIDADE IMPLEMENTADA: Sistema de proteção anti-bot invisível no formulário de recuperação de senha
• ARQUIVOS MODIFICADOS:
• painel/esqueceu_senha.php - Frontend com reCAPTCHA v3
• painel/data/functions.php - Função verify_captcha() atualizada
• CHAVES reCAPTCHA v3:
• Site Key: 6Ldnb3AqAAAAADI_kdUeqIbA26axUeeKMom3rKOp
• Secret Key: 6Ldnb3AqAAAAAORTDGsZCoYo8RHquhsGutVt6trB
• IMPLEMENTAÇÃO:
• Script carregado: https://www.google.com/recaptcha/api.js?render=[SITE_KEY]
• Execução invisível com grecaptcha.execute() na ação 'submit'
• Sem checkbox visível (100% invisível para o usuário)
• Validação backend baseada em score (0.0 a 1.0)
• Score mínimo aceito: 0.5 (humano provável)
• FLUXO DE VALIDAÇÃO:

1. Usuário preenche email e clica "Enviar"
2. reCAPTCHA v3 executa invisível em background
3. Token gerado automaticamente
4. Backend valida token via API do Google
5. Score >= 0.5 = aprovado, email enviado
6. Score < 0.5 = rejeitado como bot

• PROTEÇÃO CONTRA:
• Ataques de força bruta
• Spam de emails
• Enumeração de usuários
• DoS (Denial of Service)
• LOGS DE DEBUG:
• Logs detalhados em error_log() para troubleshooting
• Registro de token, score e motivos de rejeição
• BENEFÍCIOS:
• Experiência do usuário sem fricção (sem captcha visível)
• Proteção robusta contra bots automatizados
• Gratuito (até 1 milhão de requisições/mês)

🎨 Simplificação e Ajustes do Formulário de Eventos ✅

Data: 25/10/2025

• FUNCIONALIDADE IMPLEMENTADA: Simplificação do formulário de eventos e correções de validação
• MÓDULO ATUALIZADO: /painel/modulos/eventos/
• MUDANÇAS IMPLEMENTADAS:
• Campo Contato (WhatsApp):
• Máscara automática: (21) 99999-9999
• Validação de 11 dígitos obrigatórios (DDD + 9 dígitos)
• Salva no banco apenas números limpos (sem formatação)
• Mensagem de ajuda: "Este número precisa ser de WhatsApp pois será o contato dos interessados"
• Campo Classificação:
• Alterado de input text para dropdown
• Opções: LIVRE, 10 anos, 12 anos, 14 anos, 16 anos, 18 anos
• Campo Teatro:
• Agora obrigatório (*)
• Dropdown populado da tabela teatros
• Campo Ficha Técnica:
• Agora é opcional (removido asterisco)
• CKEditor Simplificado:
• Toolbar reduzida: Negrito, Itálico, Sublinhado, Remover Formatação
• Alinhamento: Esquerda, Centro, Direita, Justificado
• Formato: Somente Parágrafo Normal (p) e Título (h1)
• Altura fixada em 200px
• Campos Removidos:
• Quantidade Máxima de Ingressos
• Oferta (Desconto em %)
• Local e Contatos
• Regras
• Contatos Vendas Interno
• E-mail lista de compradores
• Tempo do envio antecipado
• Correção do Action:
• Adicionado data-action-url="action.php" nos formulários
• Corrige envio para o action.php correto do módulo
• Validação JavaScript:
• Máscara dinâmica no campo contato
• Validação de 11 dígitos antes de enviar
• Limpeza automática do número (remove formatação)
• Confirmação:
• Eventos são inseridos na tabela pecas (corrigido de 'tb_pecas')
• Campo id_produtor relaciona evento ao cliente produtor
• Correção de Nome de Tabela:
• Corrigido TB_ATUAL de 'tb_pecas' para 'pecas' no bootstrap.php
• Tabela correta do banco de dados é 'pecas' (sem prefixo 'tb_')