Backlog Unificado

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

Modo read-only: ações de escrita ficam disponíveis apenas para o Cérebro.

Sem itens pendentes em /www/wwwroot/rionoteatro.com.br/docs/BACKLOG.md.

Especificações Disponíveis (fora da fila pendente)

/www/wwwroot/rionoteatro.com.br/docs/backlog/BK-267-unificacao-eventos-duplicados-conciliacao.md • 2026-04-13T03:41:59.406Z

evitar que o bot crie múltiplos eventos separados para o mesmo espetáculo quando só mudam as datas
adicionar a ação Unificar na aba Prováveis Duplicatas
preservar o link externo correto por sessão/data para o CTA do evento unificado

Comédia 3 Em 1 Na Lapa
hoje existe em múltiplos registros pecas com mesmo nome/slug/teatro/origem bot
variando principalmente:
data_inicio
data_fim
url_origem
link_externo

duplicata forte deve considerar:
nome normalizado
local/teatro equivalente
valor quando fizer sentido
caso 100% coerente:
mesmo nome normalizado
mesmo local/teatro equivalente
mesma sessão (data + hora)
mesmo valor
nesse cenário o BOT deve tratar como evento já conhecido, e não abrir novo item
exceção crítica:
se o link_externo/url_origem for o mesmo e a data mudar, isso deve ir para Atualizações
não deve virar novo evento nem nova sessão
cautela crítica com preço:
diferença de valor isolada não pode ser tratada como alteração confiável
o valor salvo pelo admin pode ser o unitário, enquanto a origem externa destaca combo/duplo ou outro valor agregado
se a única divergência for preço, segurar a automação e não promover como alteração certa
ainda assim, esse caso deve entrar em Atualizações para conferência humana
quando o admin corrigir manualmente um valor captado errado, salvar:
valor captado
valor corrigido
sessão/data
se o mesmo valor errado voltar a ser captado na mesma sessão, isso não deve voltar como nova alteração
alteração textual:
se a mudança for só sinopse/descrição, o sistema só pode atualizar automaticamente quando houver identidade mínima forte
identidade mínima forte:
mesmo link externo
ou mesmo nome + mesmo local + mesma sessão
unificação deve:
manter um evento mestre
anexar sessões das sugestões duplicadas ao mestre
guardar o link externo por sessão/data

event_matcher.php
passou a diferenciar melhor same_external_link e same_session_duplicate
mesmo link externo prioriza Atualizações
mesma sessão no mesmo local fortalece a ida para Prováveis Duplicatas
conciliacao.php
aba Prováveis Duplicatas recebeu ação Unificar
action.php
nova ação conciliar_unificar
persistência de sec_link_externo em tab_sessoes
links externos por sessão passaram a sobreviver ao fluxo de unificação/regeneração
evento.php
CTA externo agora abre modal de data quando houver múltiplos links por sessão
minicard Valor Indicativo incluído
minicard de classificação incluído
documentação viva atualizada em docs/documentacao_tecnica/BOT_CAPTADOR_EVENTOS.md

o caso real País Gambiarra mostrou que a fila de conciliação não é a única fonte de duplicatas:
havia 6 eventos já aprovados/ativos em pecas, com mesmo slug, mesmo teatro e mesma origem bot
a vitrine de eventos.php estava correta ao listar todos; o problema era dado legado ativo no banco
saneamento operacional aplicado em 2026-04-12:
evento mestre mantido: 1513
duplicados inativados: 1512, 1514, 1515, 1516, 1517
sessões consolidadas no mestre com sec_link_externo por data
consequência prática:
além da aba de duplicatas pendentes, precisamos também de uma pesquisa periódica de similares já aprovados
relatório operacional gerado fora do Git:
/root/rnt_similares_aprovados_50_20260412-1837.json
follow-up operacional:
Unificar passou a forçar o evento destino para status = 'A'
quando o admin edita o nome antes de Vincular/Unificar, a peça destino passa a usar o nome editado
o slug canônico existente do destino é preservado
a conciliação deixou de alterar origem e id_produtor
a partir daqui, Vincular, Unificar, Aplicar Atualização e Reativar preservam sempre o produtor/origem atuais do evento destino

a página admin/modulos/eventos/conciliacao.php estava lenta principalmente no retorno pós-ação porque o servidor montava todas as abas no mesmo request
isso fazia a volta para #duplicatas continuar pagando o custo de:
novos
duplicatas
atualizacoes
reativar
aprovados
aprovados-similares
ignorados
gargalo crítico identificado:
getAprovadosSimilaresConciliacao() fazia scan de todos os eventos ativos e ainda executava COUNT(pedidos) por evento
correção aplicada:
action.php passou a devolver ?tab=<aba>#<aba> na URL de retorno
conciliacao.php passou a ler $_GET['tab'] como aba ativa do servidor
o PHP agora renderiza pesado apenas a aba ativa no request inicial
a navegação entre abas passou a recarregar a página com tab= para que o servidor saiba qual conteúdo montar
getAprovadosSimilaresConciliacao() deixou de fazer COUNT por evento e passou a pré-carregar os totais em uma única query agrupada
efeito esperado:
retorno muito mais rápido nas ações de Duplicatas, Atualizações e Reativar
a aba Aprovados Similares continua mais pesada que as demais, mas deixa de contaminar todo reload da tela

admin/modulos/eventos/conciliacao_eventim.php recebeu a paridade operacional das melhorias que já existiam na trilha Sympla
melhorias refletidas em todas as abas:
Novos
Duplicatas
Atualizações
Reativar
Aprovados
Aprovados Similares
Ignorados
paridade portada:
navegação com ?tab=<aba>#<aba> para o servidor saber a aba alvo no retorno
render pesado apenas da aba ativa
busca/vínculo manual no padrão mais novo
Duplicatas com links do captado e do existente
ação Unificar também no Eventim
selo Preserva produtor/origem
Reativar e Aprovados com os mesmos atalhos operacionais
Ignorados com limpeza automática de passados e ação Excluir da Lista
Aprovados Similares com helper de similaridade e merge manual
observação arquitetural:
a entrega resolveu a paridade operacional agora
a duplicação estrutural entre Sympla e Eventim continua existindo
a refatoração para base única foi separada para o roadmap BK-270