BK-201 · Automacao social de nova peca + auditoria do Squad

Contexto

• Foi criada uma peca nova e a expectativa operacional era ver desdobramento automatico de conteudo para:
• Instagram Feed
• Instagram Story
• Facebook Feed
• X / Threads
• Na pratica, o fluxo parece cada vez menos automatico e mais manual.
• Em paralelo, o botao Salvar configuração do Squad em admin/modulos/campanhas/redes_sociais.php#tab-squad aparenta nao responder.

Perguntas deste BK

• O cron diario/manhã deveria detectar peca nova e gerar pauta/copy automaticamente?
• O que hoje e automatico de verdade e o que depende de disparo manual?
• O botao de salvar configuracao do Squad esta quebrado no front, no endpoint ou so sem feedback visivel?
• Como endurecer essa automacao sem deixar o painel opaco?

Evidencias ja coletadas

• A tela principal existe em:
• admin/modulos/campanhas/redes_sociais.php
• O tab Squad e renderizado por:
• admin/modulos/campanhas/redes_sociais_ui_helper.php
• O JS do Squad e carregado no final da pagina:
• admin/modulos/campanhas/redes_sociais.php
• script redes_sociais_squad.js
• O botao de salvar configuracao existe no HTML:
• id btn-squad-save-settings
• O JS liga esse clique em:
• admin/modulos/campanhas/redes_sociais_squad.js
• saveRuntimeConfig()
• O backend exposto para salvar configuracao existe em:
• admin/modulos/campanhas/action_squad.php
• cmd=save_runtime_config
• O helper de persistencia existe em:
• admin/modulos/campanhas/social_squad_helper.php
• rnt_social_squad_runtime_config_save()
• O cadastro de peça chama gatilho social em:
• admin/modulos/pecas/action.php
• squad_pecas_trigger_event_creation($msg[1])
• O helper desse gatilho existe em:
• admin/modulos/pecas/squad_pecas_helper.php
• Hoje esse helper insere na fila apenas:
• type = facebook_event_draft
• status = queued
• Exemplo real desta rodada:
• peça 1493 / Fanáticos
• já apareceu em social_post_queue com:
• facebook_feed / planner_site_entry / pending_approval
• instagram_feed / planner_site_entry / pending_approval
• facebook_story / story_trigger / pending_approval
• instagram_story / story_trigger / pending_approval
• O cron social mais importante hoje segue em:
• admin/cron/sync_facebook_events.php
• A Central de Redes Sociais expõe botões manuais para:
• planner
• dispatcher
• run completa do cron
• reset
• page events

Leitura tecnica atual

• Leitura estatica do codigo:
• o botao Salvar configuração do Squad parece completo no papel
• HTML, binding JS, endpoint e helper de persistencia existem
• Isso sugere que o defeito mais provavel esta em um destes pontos:
• JS nao inicializado/runtime do tab
• erro silencioso no browser
• resposta de rede nao tratada como esperado
• problema de sessao/permissao/contexto do endpoint quando chamado pela tela real
• Sobre a automacao de nova peca:
• existe gatilho automatico real no cadastro de peca, mas ele e parcial
• hoje a peca nova dispara squad_pecas_trigger_event_creation()
• esse helper insere so um item facebook_event_draft na social_post_queue
• isso nao equivale a abrir automaticamente uma pauta multi-canal para:
• instagram feed
• instagram story
• facebook feed
• threads
• tiktok
• portanto a sensacao operacional de “cada vez menos automatico” faz sentido: o sistema atual automatiza um rascunho pontual, nao uma esteira completa de nova peca
• o cron sync_facebook_events.php trabalha forte sobre a fila social e sobre planejamentos/feed/story, mas a leitura atual nao prova um cron matinal dedicado a “peca nova -> semear campanha multi-canal”

RCA parcial consolidada nesta rodada

• Peça nova
• existe gatilho
• mas ele semeia so facebook_event_draft
• nao existe, pelo que foi lido ate aqui, um fan-out automatico completo por canal para nova peca
• Squad save
• no codigo, a trilha esta completa:
• botao HTML
• binding JS
• fetch('action_squad.php?cmd=save_runtime_config')
• backend save_runtime_config
• persistencia em robot_config.chave = squad_social_runtime_config
• entao o problema aparente e mais provavelmente:
• runtime/browser
• feedback fraco
• falha de rede/sessao
• erro JS anterior bloqueando a execucao real do clique
• Vazamento de instrução operacional para copy
• a trilha de refresh do approval estava mandando para a IA campos como:
• adjustment_request
• selected_seed_text
• current_options
• isso aumenta muito o risco de a IA incorporar instruções operacionais como se fossem copy final
• nesta rodada foi aplicada blindagem em:
• admin/modulos/campanhas/action_squad.php
• admin/cron/ai_copy_helper.php
• regra nova:
• esses campos nao entram mais no payload enriquecido que vai para a IA
• Stories presos no manual
• o cron ainda tratava manual_notified / preset_story_notified / notified como bloqueio operacional para sticker/link
• a publicacao ficava parada em notified
• nesta rodada foi aplicada mitigacao operacional:
• continuar tentando gerar prova/rascunho
• mas nao bloquear mais a publicacao automatica por causa do sticker
• WhatsApp admin
• a regra canônica passa a separar destinos:
• enviar_whatsapp_admin() fica restrito a alertas gerais e usa apenas BOT_WHATSAPP_NUMERO_ALERTA
• approvals de postagem saem por enviar_whatsapp_aprovacao_postagem()
• esse destino dedicado deve usar BOT_WHATSAPP_NUMERO_APROVACAO_POSTAGEM quando existir
• fallback operacional atual do approval dedicado: 5521999915554
• Paralelismo entre canais
• feed e story nao ficam bloqueando um ao outro por dependencia funcional direta
• o dispatcher separa as filas por canal:
• queue_fb_feed
• queue_ig_feed
• queue_fb_story
• queue_ig_story
• queue_threads_feed
• queue_tiktok_feed
• queue_tiktok_story
• depois processa cada grupo em sua propria trilha
• se um canal falha, os demais continuam no mesmo run
• Retry real
• existe retry automatico parcial, baseado em status error
• o planner usa ON DUPLICATE KEY UPDATE para reabrir itens error em alguns tipos:
• planner_site_entry
• planner_weekly_carousel
• planner_weekly_editorial_carousel
• o dispatcher incrementa attempts e grava last_error
• isso significa:
• ha reprocessamento automatico para itens de fila planejados
• mas nao ha, pelo que foi lido ate aqui, um orquestrador sofisticado de retry por etapa com backoff semantico por canal
• o modelo atual e mais “erro -> permanece em error -> proxima rodada/planner pode recolocar” do que um retry inteligente multi-estagio

Escopo desta rodada

• mapear a arquitetura atual
• diferenciar automacao real de expectativa operacional
• identificar onde instrumentar melhor a trilha
• decidir BK tecnico futuro para:
• autopauta de nova peca
• approvals automaticos guiados
• melhor feedback do botao do Squad

Proximos passos

• inspecionar:
• scripts/cron que abastecem social_post_queue
• gatilhos apos cadastro/edicao de peca
• fluxo do tab-squad no browser/network
• decidir se a automacao correta para nova peca deve:
• apenas criar rascunho de evento no Facebook
• ou tambem abrir fila multi-canal automaticamente
• se a decisao for multi-canal, o ponto inicial mais provavel de ajuste e:
• admin/modulos/pecas/squad_pecas_helper.php
• em conjunto com o consumo no admin/cron/sync_facebook_events.php
• revisar o runtime real do tab Squad no navegador para descobrir por que o botao de salvar parece morto apesar do fluxo de codigo existir ponta a ponta
• redesenhar a separacao:
• instrucao operacional
• direcao criativa
• copy final

Atualização de 2026-04-11 07:20 -03

Sintoma novo reportado

• em redes_sociais.php#tab-squad
• a execução fica em 2. copyRunning
• depois aparece como Cancelado
• contexto visual reportado:
• Tipo: copy
• Agente: backend
• IA planejada: gemini
• IA usada: gemini
• Modelo: gemini-3-flash-preview

Leitura técnica refinada

• o front do Squad não cria sozinho o cancelamento
• em admin/modulos/campanhas/redes_sociais_squad.js, o status Cancelado só aparece quando:
• run.status === 'canceled'
• ou chega evento run_aborted

Trechos relevantes:

• mapRunStatus() traduz canceled para Cancelado
• applyEventToBundle() faz:
• if (event.event === 'run_aborted') { next.run.status = 'canceled'; }

Implicação

• o cancelamento visto no passo copyRunning parece vir do runtime externo squad_ws / Cérebro
• não do card em si

Cruzamento com log local

O log admin/logs/ai_copy_pipeline.log mostrou nesta rodada:

• primary_start com:
• engine=gemini
• provider=squad_ws
• em várias execuções recentes, o primário concluiu com:
• primary_done
• error = null
• os ruídos mais frequentes ficaram em:
• opencode lateral com empty_opencode_output
• merge_skip
• merge_done com error = timeout em alguns casos

Hotfix aplicado nesta rodada

Arquivo alterado:

• admin/modulos/campanhas/redes_sociais_squad.js

Objetivo do hotfix:

• parar de mostrar só Cancelado
• expor o motivo real vindo do runtime quando existir

O que entrou:

• persistência de runtimeIssue e runtimeIssueType no resumo da run quando chegar:
• run_failed
• run_aborted
• limpeza defensiva de runtimeIssue/runtimeIssueType quando a run reinicia (run_started) ou conclui com sucesso (run_completed), para não deixar alerta residual em retry
• normalização de payloads estruturados do runtime:
• se error, reason, summary ou message vierem como objeto/array, a UI tenta extrair texto útil em vez de renderizar [object Object]
• preservação de currentStepKey no run_aborted quando o evento vier sem stepKey, para não perder contexto da etapa cancelada
• resumo da run agora mostra:
• Motivo do cancelamento
• ou Motivo da falha
• timeline do front agora também lê:
• error
• reason
• message
• statusText passa a refletir o motivo do run_failed/run_aborted quando o evento vier com detalhe

Conclusão operacional atual

• o bug principal não parece ser “Gemini sempre cancela”
• o mais provável é:
• aborto/cancelamento no runtime do Cérebro
• ou motivo de falha não propagado bem até a UI

Próximo passo

• reproduzir uma run real no tab-squad
• observar se agora o cancelamento vem com motivo explícito
• com esse motivo em mãos, decidir se o próximo patch é:
• timeout/provider
• fallback automático
• ou ajuste do runtime squad_ws

Fechamento operacional desta rodada

• facebook_feed com midia de video aprovada passou a subir o arquivo local do RNT via upload binario (source) em vez de depender de file_url
• validacao real executada em 03/04/2026:
• queue_id 1024
• peca Fanáticos
• retorno do dispatcher: SUCESSO! ID: 956902267291295
• o erro Unable to fetch video file from URL ficou tratado para o caso de facebook_feed com video local do acervo
• publishInstagramMedia() passou a aguardar o container de video do Instagram ficar pronto antes de publicar
• validacoes reais adicionais executadas em 03/04/2026:
• queue_id 1029
• peca Lisa, Lesa & Louca
• retorno do dispatcher: SUCESSO! ID: 18057407342468316
• queue_id 1028
• peca Fanáticos
• retorno do dispatcher: SUCESSO! ID: 18048627641547307
• o instagram_feed de Fanáticos (queue_id 1025) ainda estava queued para 03/04/2026 12:00, mas a trilha de publish usa o mesmo método endurecido agora validado nos stories de vídeo

Proposta operacional alvo

1. Gatilho de peça nova

• o cadastro de peca deve abrir imediatamente uma pauta multi-canal estruturada, nao so facebook_event_draft
• ao salvar peca nova:
• gerar itens para:
• facebook_feed
• instagram_feed
• facebook_story
• instagram_story
• threads_feed
• tiktok_feed e tiktok_story podem continuar como fase 2/manual-notificado

2. Approval noturno e dispatcher matinal

• melhor politica operacional sugerida:
• noite: gerar approvals e enviar WhatsApp para o admin aprovar com calma
• manhã: dispatcher publica o que já estiver aprovado
• motivacao:
• evita o gargalo “peca entrou e o admin nao viu a tempo”
• deixa a fila pronta para publicar cedo no dia seguinte
• hoje o planner_site_entry agenda para ~15 minutos apos o run
• proposta:
• separar:
• horario de geracao de approval
• horario de publicacao
• separar tambem o destino do WhatsApp:
• numero de approval/autorizacao de postagem nao deve receber alertas gerais de monitoramento

2.1 Regra operacional canônica de cooldown por peça

• story-first continua sendo a prioridade da primeira aparição social da peça
• peça nova sem histórico social pode abrir a primeira rodada automática com:
• facebook_story
• instagram_story
• facebook_feed
• instagram_feed
• threads_feed
• nessa primeira rodada, o criativo deve assumir posicionamento de:
• nova peça
• nova oferta
• desconto em destaque
• informações reais da peça e da próxima sessão
• descontos muito agressivos devem ser destacados com mais força no texto de lançamento
• depois da primeira rodada, qualquer planner automático de feed da mesma peça deve respeitar cooldown mínimo de 24h
• a trava vale tanto para:
• planner_site_entry
• planner_session
• se a peça tiver qualquer atividade social recente nas últimas 24h, o feed automático nao nasce
• objetivo:
• evitar flood da mesma peça
• impedir que novas rodadas de feed automático atropelem a janela do story
• manter o número de autorização focado apenas em approvals de postagem

2.2 Música em stories/feed

• a integração atual do FacebookEventService nao implementa trilha de música/áudio para story ou feed
• portanto a primeira rodada automática desta fase continua sem música embarcada via API
• se a operação quiser música canônica, isso precisa virar um slice separado:
• validar suporte real nas APIs dos canais
• decidir catálogo/fonte de áudio
• implementar payload específico por plataforma

2.3 Canais da primeira rodada

• a primeira rodada automática da peça nova deve abrir todos os canais realmente suportados hoje na esteira:
• facebook_feed
• instagram_feed
• facebook_story
• instagram_story
• threads_feed
• X/Twitter nao existe como canal implementado nesta base hoje
• se o usuário pedir X, isso deve virar BK separado de implementação, nao só ajuste de planner

3. Paralelismo entre canais

• feed e story podem continuar em paralelo
• nao vale criar dependencia artificial entre:
• facebook_feed
• instagram_feed
• facebook_story
• instagram_story
• se um canal falhar, os outros devem continuar no mesmo ciclo

4. Retry/rerun

• modelo alvo:
• erro transitorio:
• retry automatico com backoff
• erro de token/permissao:
• alerta admin + pausa do canal afetado
• erro criativo/approval:
• rerun de copy sem reabrir tudo
• hoje o sistema so chega parcialmente nisso via status=error, attempts, last_error e reentrada do planner

Atualizacao operacional de 03/04/2026

Confirmado

• o planner da peca nova foi ajustado para abrir a primeira rodada automatica em 5 canais:
• facebook_feed
• instagram_feed
• threads_feed
• facebook_story
• instagram_story
• o destino de WhatsApp para approval foi segregado do numero de alertas gerais.
• a aprovacao humana continua sendo gate obrigatorio:
• pending_approval nao publica
• so queued entra no dispatcher
• o approved_payload passou a gravar emojis corretamente:
• config/connect.php foi alinhado para utf8mb4
• admin/data/__CLASS.SQL.php tambem foi alinhado para utf8mb4
• a agenda social passou a ser a trilha canonica pos-aprovacao:
• mostra queue_id
• mostra tipo/gatilho humano + codigo tecnico
• mostra horario planejado completo
• mostra texto aprovado
• permite editar texto/midia/agendamento em estados editaveis
• o modal da agenda passou a trabalhar em duas fases:
• pending_approval: link para approval quando houver artifact
• queued/error/notified: edicao operacional direta
• o facebook_feed com status scheduled ganhou fluxo de Editar:
• cancela o agendamento remoto no Facebook
• volta o item para queued
• libera edicao local no modal
• houve validacao real desse fluxo no caso da Fanáticos:
• o item foi reaberto, reeditado e reagendado com novo rascunho remoto
• o scheduler real da VPS ficou alinhado para:
• planner noturno em 22:00
• dispatcher a cada 10 minutos
• o pool local de copy deixou de cair sempre em fallback:
• o helper/bridge passou a responder em execucao real
• o soft launch gerou approval real via pool reduzido

Inconsistencias observadas

• houve item orfao de approval:
• queue_id = 1028
• pending_approval sem artifact post_1028_*.json
• foi necessario regenerar manualmente o artifact para restaurar o link de approval
• story ainda estava abrindo approval com 3 opcoes de texto legadas em artifacts antigos.
• approvals de story ainda nao estao no formato canonico final de “midia/link apenas” para todos os casos ja gerados.
• threads_feed continua bloqueado por token invalido no ambiente atual.

Midia e canais

• video-first foi iniciado:
• facebook_feed
• instagram_feed
• facebook_story
• instagram_story
• threads_feed
• a alternancia semanal de midia foi introduzida com prioridade inicial para video quando existir asset em /arquivos/pecas/{id}/video.
• instagram_feed passou a montar payload de REELS quando houver video_url.
• threads_feed passou a montar tentativa com video_url, mas ainda depende de validacao real porque o canal esta barrado por token/configuracao.
• story passou a priorizar video quando existir, sem depender de copy pesada.

Pendencias abertas

• simplificar definitivamente o approval de story para:
• foco em midia
• foco em link/hint
• sem 3 copys principais
• tratar pending_approval sem artifact como erro operacional claro e/ou permitir regeneracao segura.
• permitir no modal da agenda:
• Aprovar direto para story pending_approval quando a arte ja estiver ok
• Editar de scheduled em outros canais depois do caso inicial de facebook_feed

Proximo passo operacional sugerido

• fechar o modo canonico de story sem copy pesada e regenerar approvals legados quando necessario
• corrigir credencial/token do Threads
• falta retry semantico por tipo de falha

5. Contrato de copy

• separar rigidamente 3 camadas:
• instrucao operacional
• ex: “story com foco no clique”
• ex: “usar video se existir”
• direcao criativa
• ex: “urgente, direto, comercial”
• copy final
• somente o texto publicavel
• regra:
• instrucao operacional nao deve entrar no payload bruto da IA como se fosse copy
• direcao criativa pode orientar a IA
• copy final deve sair limpa

6. Approval via WhatsApp

• contrato alvo:
• WhatsApp recebe:
• canal
• peça
• mídia escolhida
• link do approval
• admin:
• aprova 1 opcao
• ou pede rerun
• a tela web continua existindo como fallback/inspecao, nao como centro da operacao

7. Midia

• regra alvo:
• para story, sempre preferir asset em /arquivos/pecas/{id}/video
• se nao houver video valido, usar imagem
• WhatsApp/approval sempre deve explicitar:
• tipo da mídia
• URL do asset

Horario sugerido

• approval de nova peca: assim que a peca entra ou em janela noturna curta
• publish matinal: depois da janela de aprovacao
• desenho sugerido:
• run approval: noite
• run dispatcher: manhã
• definir se a automacao desejada vai nascer:
• no cron diario
• no cadastro da peca
• ou numa fila editorial hibrida

Criterio de aceite

• ficar claro:
• o que hoje e automatico
• o que hoje e manual
• por que a peca nova nao virou pauta automaticamente
• se o botao do Squad esta realmente quebrado ou so sem feedback suficiente