BK-183 - Checklist de validação pós-auditoria de branches antigas/stash

Objetivo

• Validar amanhã, em fluxo real, o que entrou na main via BK-182.
• Confirmar se os resgates de código antigo ficaram corretos na prática.

O que testar primeiro

1. Approval social / campanhas

• Abrir um approval social existente.
• Confirmar se existe a 4ª opção manual em aprovar_squad.php.
• Testar Aprovar e Programar usando o texto manual do admin.
• Testar Corrigir e Atualizar com observação curta.
• Confirmar se o refresh volta só no Gemini e não trava o approval.

2. Pipeline social via cron/helper

• Rodar o fluxo que usa ai_copy_helper.php.
• Conferir se o log admin/logs/ai_copy_pipeline.log está sendo preenchido.
• Verificar se aparecem etapas como:
• pipeline_start
• primary_start
• primary_done
• primary_retry_start quando houver timeout
• merge_start / merge_done

3. Cliente / aba WhatsApp

• Abrir um cliente em admin/modulos/clientes/detalhe.php.
• Trocar de aba e recarregar.
• Confirmar se o hash preserva a aba ativa corretamente.

4. Scraper Sympla / datas reais

• Validar um caso real em que o nome do ingresso traz data por extenso.
• Confirmar se a sessão sugerida entra com a data correta e não com fallback errado.

5. Eventos / conciliação / reativação

• Abrir uma sugestão de conciliação com evento já existente.
• Validar as opções de reativação:
• manter Admin
• manter Produtor
• converter para BOT quando permitido
• Confirmar se peça em temporada atual não migra indevidamente para BOT.

6. Teatros / endereço captado

• Abrir sugestão de teatro com endereço captado completo.
• Confirmar se rua, número e bairro foram separados corretamente.
• Verificar se CEP/RJ/trechos irrelevantes não poluem o campo de bairro.

7. Runtime WhatsApp

• Confirmar nos logs do serviço se aparecem:
• WPP_INSTANCE_LABEL
• WPP_AUTH_DIR
• Validar se a instância continua respondendo normal após o ajuste.

Critério de aceite

• Nenhum erro fatal novo nas telas tocadas.
• Fluxos acima funcionando ou, se algo falhar, falha reproduzível com evidência clara.
• Se houver regressão, abrir BK específico por área em vez de misturar tudo de novo.

Auditoria de retomada

Atualizado em: 2026-04-02 15:16 -03

Estado atual da rodada

• Este BK nao pode ser tratado como concluido so porque a branch antiga foi absorvida na main.
• A branch Git relacionada ja nao tinha diff util fora da main, mas o checklist operacional continua exigindo aceite por item.
• A rodada atual esta registrando evidencias tecnicas diretamente neste arquivo para evitar perda de contexto em caso de queda de energia, timeout ou troca de sessao.

Evidencias ja confirmadas

1. Approval social / campanhas

• Implementacao encontrada em:
• admin/modulos/campanhas/aprovar_squad.php
• admin/modulos/campanhas/action_squad.php
• Evidencias em codigo:
• existe Corrigir e Atualizar
• existe Aprovar e Programar
• existe opcao manual de midia (media_override = __manual__)
• o refresh usa ai_copy_helper.php via rnt_action_squad_build_refreshed_payload()
• Status da auditoria:
• implementado
• ainda sem aceite em fluxo real nesta rodada

2. Pipeline social via cron/helper

• Implementacao encontrada em:
• admin/cron/ai_copy_helper.php
• Evidencias em log real:
• admin/logs/ai_copy_pipeline.log existe e recebeu eventos recentes em 2026-04-01
• eventos confirmados:
• pipeline_start
• primary_start
• primary_done
• merge_start
• merge_done
• tambem apareceu merge_skip, o que confirma runtime real do pipeline
• Status da auditoria:
• validado com evidencia real

3. Cliente / aba WhatsApp

• Implementacao encontrada em:
• admin/modulos/clientes/detalhe.php
• Evidencias em codigo:
• a tela le window.location.hash
• a tab correspondente e reaberta no carregamento
• o shown.bs.tab atualiza o hash ao trocar de aba
• Status da auditoria:
• implementado
• ainda sem aceite em fluxo real nesta rodada

4. Scraper Sympla / datas reais

• Implementacao encontrada em:
• bot/scrapers/sympla_scraper.php
• Evidencias em codigo:
• funcoes especificas para mes por extenso, fallback de data e parsing do nome do ticket
• Teste tecnico executado nesta rodada:
• "Ingresso Sexta 14 de março às 20h" -> 2026-03-14
• "Sábado 5 de abril 19h" -> 2026-04-05
• Status da auditoria:
• validado no parser central
• ainda sem caso manual de conciliacao/sugestao aberto em tela nesta rodada

5. Eventos / conciliação / reativação

• Implementacao encontrada em:
• admin/modulos/eventos/conciliacao.php
• admin/modulos/eventos/action.php
• Evidencias em codigo:
• ha opcoes manter_admin, manter_produtor e converter_bot
• a UI mostra Reativar como Admin, Manter Produtor e Assumir/Reativar como BOT
• o backend bloqueia migracao para BOT quando a peca esta em temporada atual
• Status da auditoria:
• implementado
• ainda sem aceite em fluxo real nesta rodada

6. Teatros / endereço captado

• Implementacao encontrada em:
• admin/modulos/teatros/index.php
• admin/modulos/teatros/action.php
• Evidencias em codigo:
• limpa CEP
• separa logradouro e numero
• tenta isolar bairro
• ignora trechos irrelevantes como RJ
• Tentativa de teste tecnico nesta rodada:
• o include direto da tela travou por dependencia de bootstrap/login admin
• Status da auditoria:
• implementado
• ainda sem teste real concluido nesta rodada

7. Runtime WhatsApp

• Implementacao encontrada em:
• bot/whatsapp/server.js
• Evidencias em codigo:
• existem WPP_AUTH_DIR
• existe WPP_INSTANCE_LABEL
• Observacao operacional desta rodada:
• o endpoint http://127.0.0.1:3033/status nao respondeu no teste local feito nesta sessao
• a trilha documental do projeto aponta que o runtime correto roda via systemd no servico rnt-whatsapp, e nao via pm2
• o arquivo bot/whatsapp/healthcheck.log registrou ciclos recentes em 2026-04-02 14:15 ate 2026-04-02 15:00 com STATUS: Online e Conectado
• o arquivo bot/whatsapp/restart.log registrou Servico reiniciado e conectado em 2026-04-02 10:00:32 -03
• Status da auditoria:
• implementado
• validado com evidencia operacional equivalente, apesar do curl local isolado ter falhado nesta sessao

Conclusao parcial

• Este BK seguia aberto apenas por validacao operacional remanescente no admin.
• A parte principal da rodada ja estava implementada e validada documentalmente.
• O ultimo ponto pendente em admin/modulos/eventos/editar.php foi considerado aprovado pelo usuario em 2026-04-08.
• Com isso, o BK-183 pode ser tratado como concluido para fins operacionais.

Leitura cruzada via worker externo

• Worker usado: gemini
• Modo: --include-directories /www/wwwroot/rionoteatro.com.br
• Resultado sintetico retornado pelo worker:
• 1 | Implementado | Código em aprovar_squad.php e action_squad.php com opções de aprovação manual e refresh via helper.
• 2 | Validado | Log admin/logs/ai_copy_pipeline.log com eventos reais de pipeline e merge em 01/04/2026.
• 3 | Implementado | Lógica de hash/tab presente em admin/modulos/clientes/detalhe.php.
• 4 | Validado | Parser técnico em sympla_scraper.php convertendo datas por extenso corretamente.
• 5 | Implementado | Reativação Admin/Produtor/BOT e bloqueio de BOT em temporada atual em eventos/action.php.
• 6 | Implementado | Limpeza de CEP e separação de logradouro/bairro em teatros/action.php.
• 7 | Implementado | WPP_AUTH_DIR e WPP_INSTANCE_LABEL presentes em server.js, mas sem validação do endpoint local nesta rodada.

Leitura cruzada adicional via worker externo

• Worker usado: opencode
• Modelo: opencode/minimax-m2.5-free
• Resultado sintetico retornado pelo worker:
• BK-183 segue aberto
• 2 ja esta validado
• 4 esta validado no parser tecnico
• 1, 3, 5 e 6 seguem pendentes de fluxo real
• a recomendacao operacional foi priorizar exatamente esses itens antes de considerar fechamento

Fechamento posterior

Atualizado em: 2026-04-08 02:36 -03

• O usuario confirmou que o BK-183 ja esta concluido e aprovado.
• Ajuste operacional aplicado:
• limpar a ultima linha HANDOFF remanescente de admin/modulos/eventos/editar.php em docs/LOCK.md
• tratar este backlog vivo como historico de auditoria/validacao, sem novas pendencias ativas nesta trilha