A Outbound Machine (motor ob_*) é o motor de prospecção multicanal da Luby: dispara cadências de e-mail pelo Resend e de LinkedIn pela Unipile, e roda inteiro dentro do Supabase nearsmart, sem tela própria. Ele é o backend: o time cria, abastece e acompanha as campanhas pelo plugin outbound-campaigns, que funciona como a tela do motor dentro do Claude. Está no ar: em 07/10/2026 eram 28 campanhas ativas e 15 pausadas.

Como funciona

Fluxo

1. A campanha nasce paused em ob_campaigns (janela de envio, fuso, dias, parar ao responder, parar no bounce), com remetentes em ob_campaign_senders e uma sequência ativa em ob_sequences e ob_steps.
2. Os leads chegam por CSV no endpoint ob-ingest-leads: create-upload, upload do arquivo no Storage, process em simulação e confirm. O servidor valida, deduplica contra todo o ob_leads (por e-mail ou LinkedIn) e só então matricula.
3. Entre o process e o confirm, ob_block_check_job cruza o lote com a lista de empresas bloqueadas e o usuário decide o destino de cada empresa.
4. Opcional: enriquecimento via ob-enrich-leads (Apollo). A simulação mostra o custo em créditos antes de gastar.
5. O confirm chama ob_import_enroll, que usa ob_load_campaign: cria ob_enrollments com status active e next_run_at=now(), fixa a caixa de e-mail (rodízio entre as caixas ativas da campanha) e a conta de LinkedIn (rodízio ponderado por weekly_invite_cap) e pula pessoa repetida.
6. Alguém ativa a campanha. O ob_tick é global: os crons por canal varrem todas as campanhas ativas em fila justa (rodízio entre campanhas, ordem de chegada dentro de cada uma).
7. Toque de e-mail: dentro da janela da campanha, o tick confere a supressão (ob_is_suppressed), reserva um envio no balde da caixa (ob_email_reserve), cria a linha em email_outbox e chama email-push. Toque com IA passa antes por gen-email-copy (linha em awaiting_copy).
8. Campanha com batch_send=true não chama email-push: a linha fica em batching e o email-push-batch envia até 100 e-mails numa chamada ao Resend. Hoje 2 campanhas usam o lote.
9. email-push manda texto e HTML, anexa a assinatura (email_senders.signature_title), o cabeçalho de descadastro One-Click e uma chave de idempotência.
10. resend-webhook recebe entregue, aberto, clique, bounce, reclamação e falha; atualiza email_outbox, para a sequência em hard bounce e reclamação (com supressão global) e alimenta outbound_events.
11. Resposta de e-mail: o Resend Receiving recebe no MX dos domínios cadastrados em ob_inbound_domains e chama email-inbound, que casa pelo Message-ID do provedor (com fallback por endereço), roda ob_stop_on_reply, grava em messages_received, encaminha para o forward_to da caixa e avisa no Discord do mercado na primeira resposta.
12. Toque de LinkedIn: o tick faz o lookup do grau de conexão, reserva no balde da conta, gera a copy com gen-li-copy e envia com unipile-push (convite seco, mensagem ou InMail). unipile-webhook recebe aceite e resposta; unipile-accept-reconcile recupera aceite perdido a cada 6 horas.
13. wait agenda N dias úteis dentro da janela; end conclui. O link de descadastro (email-unsubscribe) suprime o endereço em todas as campanhas.
14. Vigilância: ob_engine_alerts posta no Discord a cada 15 minutos (modelo "caiu, voltou"); ob_bounce_guard pausa campanhas específicas acima de 3% de bounce; ob_bounce_watch só avisa acima de 2%.

Peças

Agendamentos

Os crons rodam em UTC. "Seg a sex" vale para o dia em UTC, ou seja, de domingo 21h a sexta 20h59 em BRT. O envio em si ainda respeita a janela de cada campanha ou conta.

Regras de negócio

• A campanha nasce pausada. draft não trava envio: o tick só pula paused, archived e completed. Carregar leads numa campanha ativa dispara no próximo ciclo.
• Teto de 60 e-mails por dia em cada caixa desde out/2026. É o valor de daily_limit; o gatilho divide pelas horas da janela da campanha para chegar ao ritmo por hora. Não há trava no banco que impeça um valor maior.
• Caixas @nearsmarter.com só servem às campanhas "Talent Pool US (email)" e "Wagner Signals - Nearsmarter". Os vínculos antigos dessas caixas com outras campanhas estão com is_active=false. É regra operacional, sem trava no banco.
• Resposta de e-mail é capturada pelo webhook de inbound do Resend. O leitor IMAP (email-reply-check) é legado e está sem cron.
• Idioma é por toque. E-mail sem content.language sai em inglês; e-mail em português só com language='pt-BR'.
• Remetente é fixado na matrícula. Mudar teto depois vale; trocar caixa só vale para matrículas novas.
• Convite de LinkedIn é sempre seco (sem nota).
• LinkedIn usa a janela do mercado da conta: 9h às 18h, seg a sex, em Nova York ou São Paulo. São 9 contas ativas (8 US, 1 BR), com 975 convites por semana somados.
• Abertura não decide nada. O motor decide por entrega, resposta e bounce; abertura é inflada por scanners.
• Passos de visita, curtida e comentário dentro da cadência só rodam em campanha com li_engagement_steps=true (hoje 1 piloto, pausada). Nas demais viram skip. Em fase final de análise; ver Comentários no LinkedIn.
• Talent Pool usa o carregador próprio ob_load_from_people e tem runbook no repo dela. Campanha nova nunca usa esse caminho.

Integrações e credenciais

Todas as edges rodam com verify_jwt=false e recusam qualquer chamada sem o cabeçalho certo. Trocar OB_PUSH_SECRET ou LI_PUSH_SECRET num lugar só faz tudo responder 401.

Como monitorar

-- funil e saúde por campanha
select * from public.ob_campaign_metrics;
select * from public.ob_campaign_health;

-- saúde e capacidade por remetente
select * from public.ob_sender_health;
select * from public.ob_email_capacity where limite_e_ficcao;

-- e-mails travados
select status, count(*) from public.email_outbox
 where (status in ('failed','awaiting_copy') and created_at < now() - interval '15 minutes')
    or (status = 'batching' and created_at < now() - interval '45 minutes')
 group by 1;

-- os crons do motor rodaram?
select j.jobname, d.status, d.start_time
  from cron.job_run_details d join cron.job j on j.jobid = d.jobid
 where j.jobname in ('ob_tick_email','ob_tick_linkedin','ob_drain_email','ob_engine_alert')
 order by d.start_time desc limit 20;

-- alertas abertos e histórico
select * from public.ob_alert_state order by opened_at;
select ts, transition, alert_key, detail from public.ob_alert_log order by ts desc limit 30;

Como usar

O que pedir ao Claude

O time opera o motor pelo plugin outbound-campaigns (página própria). Exemplos:

• "Cria uma campanha de e-mail para essa lista de CTOs nos EUA."
• "Sobe esse CSV na campanha AI Legacy Modernization."
• "Como está a campanha Wagner Signals - Nearsmarter?"
• "Me dá o report executivo de todas as campanhas."
• "Pausa a campanha X agora."
• "A empresa Y virou cliente, bloqueia ela."

Passo a passo

1. Instale o plugin outbound-campaigns e confirme que o conector do Supabase aponta para o projeto nearsmart.
2. Peça a campanha nova. O Claude pergunta objetivo, canal, mercado, idioma, responsável, janela, remetentes, cadência e copy, e cria tudo pausado.
3. Envie a lista em CSV (não Excel, não link). O Claude mostra quantos entram, quantos ficam de fora e por quê, e confere empresas bloqueadas.
4. Revise a prévia da mensagem e diga "pode colocar no ar". Só então a campanha começa a enviar, nos dias e horários escolhidos.
5. Acompanhe com "como está a campanha X" ou com o report executivo.

Cuidados

• Adicionar leads numa campanha ativa faz as pessoas receberem em minutos, sem revisão.
• Respeite o teto de 60 e-mails por dia por caixa e a regra das caixas @nearsmarter.com.
• Domínio do remetente é marca: @lubysoftware e @nearsmarter são empresas diferentes para quem recebe.
• Para parar qualquer campanha na hora, peça "pausa a campanha X". Pausar é sempre seguro.
• Não peça mudanças na Talent Pool pelo plugin; ela tem runbook próprio.

Fontes

• README do outbound-machine
• CLAUDE.md do outbound-machine
• CREDENCIAIS.md
• v2/README.md
• INDEX de implementação
• ARQUITETURA-v3-outbound-email.md (repo) e cópia no Drive
• ALERTAS-MOTOR-RUNBOOK.md (repo) e cópia no Drive
• webhook-recebimento-RUNBOOK.md (repo) e cópia no Drive
• MANUAL-configurar-campanha.md no Drive
• PLANO-ob-enrich-leads.md no Drive
• contrato-motor.md
• ingestao-leads-endpoint.md
• Supabase nearsmart (08/10/2026): cron.job, pg_get_functiondef de ob_tick, ob_bounce_guard, ob_bounce_watch, ob_engine_alerts e contagens das tabelas citadas

A rotina de engajamento no LinkedIn (subsistema ob_eng_*) curte ou reage às publicações do próprio lead por N dias, para o nome do remetente aparecer nas notificações dele antes ou durante a abordagem. Está no ar: o motor roda a cada 10 minutos, mas hoje nenhuma rotina está ativa.

Como funciona

Fluxo

1. A skill /engajamento chama ob_eng_create_routine: a rotina nasce paused com nome, mercado, reação, duração, contas, máximos por pessoa, filtro de IA e quantas publicações antigas curtir.
2. ob_eng_load_targets coloca as pessoas na rotina (de uma campanha existente ou de um CSV ingerido): divide os leads entre as contas em rodízio, fixa uma conta por pessoa e tira quem é de empresa bloqueada, pediu opt-out, já respondeu, não tem LinkedIn ou está repetido.
3. ob_eng_activate em simulação devolve o resumo de segurança; depois do "sim", ativa, grava starts_at e ends_at (início mais a duração) e registra o evento de ciclo de vida.
4. O cron ob_eng_tick roda a cada 10 minutos, com lock para dois ticks nunca rodarem juntos. Ele encerra rotinas vencidas, marca como esgotado quem bateu o máximo por pessoa, calcula a folga de cada conta (teto diário de reações somando todas as rotinas e balde de leitura), confere de novo a supressão e, dentro da janela da conta, dispara a varredura (ob-eng-scan-posts) e a reação (unipile-push, ação react).
5. ob-eng-scan-posts lista as publicações do lead na Unipile, descarta as de anos anteriores (ob_eng_post_min_posted_at), as já curtidas e, com o filtro ligado, as reprovadas pela IA (prompt eng-screen-post-v1). As aprovadas entram em ob_eng_post_candidates.
6. unipile-push reage com POST /api/v1/posts/reaction usando o social_id do post (urn:li:activity:...) e grava, numa operação só, a linha do ledger ob_eng_actions, o contador do alvo e o evento em ob_eng_events (ob_eng_record_action).
7. ob_eng_status e a view ob_eng_health mostram progresso, volume, detalhe por pessoa (que é também a lista de remoção manual) e saúde.
8. Ativar, pausar, encerrar e o fim por duração postam um aviso no Discord; editar fica só na auditoria.

Peças

Agendamentos

Regras de negócio

• A reação é pública e permanente. A instância da Unipile usada pelo motor não tem rota para remover reação (testado em 09/09/2026). Não existe desfazer; a remoção é manual, no LinkedIn, pela conta que curtiu, a partir do ledger.
• A rotina nasce parada; ativar é o último gesto, sempre depois do resumo de segurança e de um "sim" explícito. Religar uma rotina pausada passa pelo mesmo resumo.
• Uma conta fixa por pessoa. Com várias contas, o rodízio divide as pessoas; ao remover uma conta, as pessoas dela são redistribuídas.
• Janela e fuso vêm da conta que reage, não do público: 9h às 18h, seg a sex, em Nova York (US) ou São Paulo (BR). Hoje há contas ativas nos dois mercados (8 US, 1 BR).
• Só publicações do ano corrente (a partir de 1º de janeiro no fuso da conta), e só as publicadas pelo próprio lead.
• Padrões sugeridos pela skill: curtir, 7 dias, até 3 por pessoa, 1 por pessoa por dia, 1 publicação antiga no início, filtro de IA ligado.
• Supressão sem exceção: empresa bloqueada, opt-out e quem já respondeu nunca recebem, nem com pedido do usuário.
• Parar não remove nada. A resposta ao usuário sempre diz quantas reações continuam no ar.

Integrações e credenciais

Como monitorar

-- rotinas e última reação
select r.name, r.status, r.starts_at, r.ends_at,
       (select count(*) from ob_eng_actions a where a.routine_id = r.id and a.status = 'reacted') as reacoes,
       (select max(reacted_at) from ob_eng_actions a where a.routine_id = r.id) as ultima
  from ob_eng_routines r order by r.created_at;

-- saúde de uma rotina
select coverage_pct, failure_pct, reactions_done, reactions_failed,
       posts_screened_out, leads_no_post, accounts_usage
  from ob_eng_health where routine_id = '<ROTINA>';

-- alertas do engajamento abertos
select * from ob_alert_state where alert_key like 'eng_%';

Como usar

O que pedir ao Claude

• "Quero aquecer os leads da campanha X no LinkedIn antes do convite."
• "Curte os posts dessa lista por 14 dias usando o perfil do Rodrigo."
• "Como está o engajamento Networking Tiago?"
• "Pausa o engajamento X."
• "Aumenta a duração do engajamento X para 20 dias."
• "Desfaz as curtidas da pessoa Y." (o Claude responde com a lista para remoção manual)

Passo a passo

1. Peça a rotina e diga quem recebe: uma campanha existente ou uma planilha CSV (só a coluna de LinkedIn é obrigatória).
2. Escolha de quais perfis a reação sai. O Claude mostra nome, mercado e quantas reações cada perfil aguenta por dia.
3. Decida reação, duração, máximos por pessoa, publicações antigas e filtro de IA. O Claude sugere padrões.
4. O Claude cria a rotina parada e mostra quantas pessoas entram e quem ficou de fora, com o motivo.
5. Leia o resumo de segurança (alcance estimado, horários de cada perfil e o aviso de que as reações não podem ser desfeitas) e responda "sim" para colocar no ar.
6. Acompanhe pelo status. A rotina se encerra sozinha na data do fim.

Cuidados

• Com "publicações antigas" em 1 ou mais, a primeira curtida pode cair num post de meses atrás. Se não quiser isso, peça 0.
• Não desligue o filtro de IA sem pensar: é a única barreira antes de uma curtida pública.
• Para parar tudo na hora, diga "para o engajamento agora". O Claude pausa sem pedir confirmação.

Fontes

• README da pasta engajamento
• GO-LIVE.md
• PRD do engajamento
• Techspec do engajamento
• PRD de comentários (v2)
• ALERTAS-MOTOR-RUNBOOK.md
• SKILL.md do engajamento
• Supabase nearsmart (08/10/2026): cron.job, pg_get_functiondef de ob_eng_tick, ob_eng_lead_suppression e ob_li_comment_watch, contagens das tabelas ob_eng_*, ob_li_engagements e li_senders

Passos de visita, curtida e comentário dentro da cadência de uma campanha do motor de outbound: o motor visita o perfil do lead, curte e comenta uma publicação dele pela conta de LinkedIn fixa da matrícula, com triagem e redação por IA. Está em fase final de análise. É diferente do Engajamento no LinkedIn, que só curte publicações, fora da cadência, numa rotina própria de N dias.

Como funciona

Fluxo

1. A campanha recebe passos linkedin_visit, linkedin_react_post (reação em content.reaction_type, padrão linkedin_like) e linkedin_comment_post (idioma obrigatório em content.language, tom opcional em content.tone_hint). A chave ob_campaigns.li_engagement_steps só liga com a campanha pausada, sem matrícula e com idioma em todo comentário.
2. Sem a chave, o ob_tick pula esses passos. Com a chave, roda o prelúdio de LinkedIn (conta fixa e ativa, janela da conta, URL, supressão) e chama ob_li_engage_step.
3. ob_li_engage_step confere o opt-out primeiro. A visita reserva cota e dispara. Curtida e comentário sem texto pronto reservam uma leitura da conta e disparam o preparo (prepare) na edge ob-li-engage, via pg_net.
4. O prepare lista até 30 publicações do lead e fica com as autorais, com texto, do ano corrente e que a conta ainda não usou. Para comentar, exige ainda permissão de comentário, até 60 dias de idade e até 500 comentários no post.
5. Cada candidata (no máximo 3 por passo) passa por: triagem da curtida (a do v1), triagem do comentário, redator, validador automático e juiz. Aprovada vira ready com o texto; reprovada vira discarded com família e motivo; sem candidata, o passo vira skipped.
6. No tick seguinte, a cota do dia é reservada e a ação sai. Curtida: POST /posts/reaction. Comentário: uma pré-conferência lê todos os comentários do post para provar que a conta ainda não comentou ali, e só então POST /posts/{social_id}/comments.
7. Sucesso grava done com o comment_id. Resultado desconhecido (timeout, rede, 5xx) vira uncertain e só sai por reconcile, que procura o comentário; 3 buscas sem achar, ao longo de pelo menos 1 hora, gravam failed. Nunca há um segundo POST.
8. Comentário publicado é acompanhado por 14 dias (leituras em +2 h, 6 h, 1, 2, 4, 7, 10 e 14 dias). O cron ob_li_comment_watch despacha as leituras devidas, na janela da conta e até 10 por conta por vez. Se o lead respondeu, grava o horário e posta um aviso, uma única vez, no Discord do mercado. Responder é manual.

Peças

Prompts (tabelas prompts e prompt_configs, via OpenRouter):

Agendamentos

Regras de negócio

• Comentário é público e permanente. A Unipile desta instância não apaga nem edita comentário. A remoção é manual, no LinkedIn, pela conta que comentou, a partir da lista comentarios_publicados do ob_li_engagement_status.
• Tetos diários por conta, no fuso da conta e somando todas as campanhas, separados dos de convite e mensagem: visita 30, curtida 15, comentário 8 (a conta BR ativa está com 5). O teto de comentário é configurado à mão em cada conta, de acordo com a cadência. Espaçamento mínimo: 3 min entre visitas, 5 entre curtidas, 15 entre comentários.
• No teto, adia e nunca troca de conta. Teto zero é a parada de emergência daquela ação na conta. Erro de conta (429, 401/403, conta indisponível) trava o dia daquela ação; depois de 3 dias úteis, o passo é pulado.
• Uma vez por post: a mesma conta nunca curte nem comenta duas vezes a mesma publicação.
• Triagem em duas classes. Duro (tema sensível, opt-out) barra também a curtida. Leve (conteúdo não avaliável, contexto do post) barra só o comentário. Confiança abaixo de 0,8 ou idioma não identificado contam como leve: na dúvida, não comenta.
• Idioma vem do passo, não do post, sem fallback.
• Texto conferido por código antes do juiz: 30 a 300 caracteres (o redator mira 60 a 250), até 2 frases, uma linha, sem link, @, hashtag, emoji ou travessão, sem citar Luby ou Nearsmart, sem oferecer serviço, sem convite para conversar. O juiz reprova o que não for específico do post ou afirmar o que o autor não disse.
• Sem aprovação humana comentário a comentário (decisão do PRD). A calibragem é a prévia (preview): até 3 comentários de exemplo sobre os leads carregados, sem publicar nada.
• LGPD: o texto do post não é gravado e vai ao OpenRouter com coleta de dados negada. Fica gravado o texto do nosso comentário; da resposta do lead, só o horário e o id.
• A visita notifica o lead ("viu seu perfil"). As leituras do preparo não notificam.

Integrações e credenciais

Como monitorar

O piloto (Piloto passos de engajamento - Karime - Set/26, 4 leads) registrou 4 visitas, 3 curtidas e 3 comentários, com 6 publicações descartadas pelas barreiras antes de comentar.

-- campanhas com a chave ligada
select id, name, status from ob_campaigns where li_engagement_steps;

-- registro por ação, status e motivo
select action, status, family, reason, count(*)
  from ob_li_engagements group by 1,2,3,4 order by 1,2;

-- relatório de uma campanha (lista de remoção manual, respostas, cotas)
select ob_li_engagement_status('<CAMPANHA>');

-- alertas abertos deste recurso
select alert_key, title, detail, opened_at from ob_alert_state
 where alert_key like 'li_engage%' or alert_key like 'li_comment%';

Como usar

O que pedir ao Claude

• "Como está o piloto de passos de engajamento?"
• "Quais comentários a campanha X publicou no LinkedIn?" (vem a publicação, o texto e a conta: é a lista de remoção manual)
• "Algum lead respondeu aos nossos comentários?"
• "Pare os comentários da conta do Fulano agora." (o caminho é zerar o teto de comentário da conta)
• "Quero visita, curtida e comentário na cadência da campanha X." (enquanto está em análise, passa pela Karime)

Passo a passo

1. Combine com a Karime a campanha e as contas de LinkedIn. Enquanto o recurso está em análise, é ela quem liga os passos, com a campanha pausada e ainda sem leads.
2. Defina a cadência (por exemplo: visita, espera, curtida, espera, comentário), o idioma de cada comentário e, se quiser, uma orientação de tom curta.
3. Antes de ativar, peça a prévia: até 3 comentários de exemplo sobre publicações reais dos leads, sem publicar nada.
4. Ative e acompanhe pelo relatório. Quando um lead responde, chega aviso no Discord do mercado; a resposta é sua, à mão.

Cuidados

• O comentário sai no nome de uma pessoa real e o sistema não consegue apagá-lo. Revise a prévia com atenção.
• Para parar, pause a campanha. Não peça para "desligar os passos" de uma campanha no ar: isso pula os passos e avança os leads.

Fontes

• PRD de comentários (v2)
• README da pasta engajamento
• Contrato do motor na skill-base
• Supabase nearsmart, lido em 08/10/2026: código das edges ob-li-engage e ob-li-engage-probe; cron.job; colunas e comentários de ob_li_engagements, li_senders e ob_campaigns; pg_get_functiondef de ob_tick, ob_li_engage_step e ob_engine_alerts; prompts e prompt_configs; contagens do registro

A Warm-up machine é o aquecimento de e-mail caseiro da Luby: nossas próprias caixas trocam e-mails curtos entre si, pelo mesmo Resend das campanhas, e respondem automaticamente para construir reputação de domínio. Está parada porque nenhuma caixa está em aquecimento e não há previsão de religar. É decisão do time, não falha. Os crons seguem ligados sem ter o que enviar.

Como funciona

Fluxo

1. Pool automático. O gatilho trg_email_senders_warmup_upd (e o de inserção) roda warmup_sync_pool() sempre que muda email_senders.warmup_active. Caixa com a flag ligada entra em warmup_mailboxes com enabled=true; flag desligada vira enabled=false, sem apagar a linha nem a data de início.
2. Quem recebe. can_receive vem de ob_inbound_domains.webhook_enabled do domínio da caixa: só domínio com recebimento por webhook fecha o ciclo.
3. Envio. O cron warmup_tick chama a edge warmup-send com limite de 15 por passada. Ela pede a warmup_due_senders as caixas devidas, escolhe para cada uma um destino habilitado (de preferência de outro domínio), sorteia um modelo de abertura em warmup_templates e envia pelo Resend com a tag type=warmup e os cabeçalhos X-Warmup, X-Warmup-Id e X-Warmup-Depth.
4. Registro. Cada envio vira uma linha open em warmup_log (ou failed, com o erro).
5. Resposta automática. A caixa destino recebe pelo email-inbound, que reconhece o warm-up (cabeçalho X-Warmup ou remetente do pool) e responde cerca de 80% das vezes na mesma conversa, até profundidade 3. A resposta vira linha reply em warmup_log. Esse ramo não toca em campanha nenhuma.
6. Isolamento. A função ingest_outbound_event descarta tudo que é warm-up (pela tag, pelo id no warmup_log ou por remetente e destinatário do pool), então nada disso aparece nas métricas das campanhas.
7. Saúde. O cron warmup_health_alert chama warmup-alert, que só posta no Discord quando warmup_health_alerts() acha erro de envio no dia ou motor parado.

Peças

Agendamentos

Regras de negócio

• Rampa por caixa: meta do dia = o menor entre o teto (daily_cap) e 2 + dias desde warmup_started_at vezes o passo (ramp_step).
• Valores atuais: lubysoftware.com (8 caixas) e lubysoftware.com.br sobem 2 por dia até 30; lubysoftware.co, lubysoftware.tech, nearsmarter.com e 3 caixas lubysoftware.com mais novas sobem 1 por dia até 15. Caixa nova entra com passo 1 e teto 15.
• Pareamento prefere destino de outro domínio.
• O warm-up não passa pela reserva do motor (ob_email_reserve): a edge chama o Resend direto. Pela leitura do código, não consome o teto de 60 e-mails por dia da caixa, mas soma volume no domínio.

Como religar uma caixa

1. Confira se o domínio da caixa tem recebimento por webhook: select * from ob_inbound_domains;. Sem isso a caixa entra com can_receive=false e não serve de destino.
2. Ligue a flag: update email_senders set warmup_active = true where from_email = '<caixa>';. O gatilho põe a caixa no pool com enabled=true.
3. Garanta pelo menos duas caixas habilitadas e com can_receive=true. A edge nunca manda para o próprio remetente; com uma caixa só, ela não envia nada. As 3 sementes externas (Gmail e Outlook) estão desabilitadas e sem permissão de receber.
4. Decida a rampa. Como a data de início é preservada, uma caixa antiga volta direto no teto (15 ou 30 por dia). Para recomeçar de 2 por dia: update warmup_mailboxes set warmup_started_at = current_date where address = '<caixa>';. Para segurar mais: ajuste ramp_step e daily_cap na mesma tabela.
5. Não precisa religar cron: warmup_tick está ativo. O primeiro envio sai na próxima passada dentro da janela (seg a sex, 8h às 21h BRT).
6. Acompanhe por warmup_health no mesmo dia.

Para desligar de novo: update email_senders set warmup_active = false where from_email = '<caixa>';. Para parar tudo, inclusive o cron: select cron.unschedule('warmup_tick');.

Integrações e credenciais

Como monitorar

-- quem está no pool e habilitado
select address, enabled, can_send, can_receive, ramp_step, daily_cap, warmup_started_at
  from warmup_mailboxes order by enabled desc, address;

-- meta e realizado de hoje
select * from warmup_health_by_domain;
select address, flag, days_in_ramp, daily_target, opens_today, replies_today, errors_today
  from warmup_health where enabled order by domain, address;

-- o que rodou hoje
select direction, status, count(*) from warmup_log
 where sent_at >= date_trunc('day', now()) group by 1, 2;

Como usar

O que pedir ao Claude

• "Quais caixas estão em aquecimento hoje?"
• "Religa o warm-up das caixas @lubysoftware.tech começando a rampa do zero."
• "Como está o warm-up por domínio hoje?"
• "Desliga o warm-up da caixa X."

Passo a passo

1. Diga quais caixas quer aquecer e se a rampa deve recomeçar do zero.
2. O Claude confere se o domínio recebe por webhook e se existe pelo menos uma segunda caixa para receber.
3. Confirme. O Claude liga a flag (e, se você pediu, reinicia a data da rampa).
4. No mesmo dia, peça o status por domínio para ver os primeiros envios e respostas.

Cuidados

• Aquecer não é enviar campanha, mas usa o mesmo domínio: comece devagar em domínio novo.
• Enquanto o warm-up estiver parado, fique de olho manual nas respostas das campanhas, porque o alerta de "webhook mudo" depende dele.
• Desligar a flag não apaga histórico; religar retoma do ponto da rampa original.

Fontes

• plano-warmup-emails.md (repo) e cópia no Drive
• warmup-machine-como-funciona.md no Drive (versão anterior, de 28/07)
• ALERTAS-MOTOR-RUNBOOK.md
• INDEX de implementação
• CREDENCIAIS.md
• Edge warmup-send (código publicado) e Supabase nearsmart: cron.job, pg_get_functiondef de warmup_sync_pool, warmup_due_senders, warmup_health_alerts, trg_warmup_sync e ob_engine_alerts, contagens de warmup_mailboxes, warmup_log, warmup_templates e email_senders, em 08/10/2026

Campanha que apresenta 6 candidatos validados da Luby (CVs anonimizados) a empresas dos EUA que abriram vagas compatíveis. São duas campanhas independentes no motor ob_*, uma de LinkedIn (3 toques) e outra de e-mail. Status: No ar desde 13/07/2026.

Como funciona

Fluxo

1. Vagas de tecnologia chegam em jobs_analyzed e google_jobs_analyzed (coleta do Hunter Squad e Apify).
2. classify_offer_jobs_v1 casa o título da vaga com as match_queries de cada candidato em offer_candidates e grava offer_candidate_id e is_offer_target na vaga.
3. upsert_targets_from_offer_jobs(90) cria a empresa em targets e refresh_target_jobs_all liga vaga e empresa. Passos 2 e 3 rodam no cron offer_pipeline_daily.
4. Canal LinkedIn: stage_offer_outreach_v1(60, ...) marca people.offer_status='queued' para contatos de empresas com vaga-alvo nos últimos 60 dias, em rodízio por empresa entre os candidatos que têm vaga ali. Roda manual.
5. ob_tp_load (terças) chama ob_load_from_people e inscreve os queued com LinkedIn, link de CV e sem DNC.
6. ob_tick_linkedin executa a cadência: convite sem nota, cordial D+1 do aceite (template), oferta D+2 do aceite (IA, com link do CV).
7. ob_tp_sync vira offer_status para sent depois que o convite ou a mensagem saiu de verdade.
8. Canal e-mail: ob_offer_refresh_job_signal(60) grava em ob_offer_job_signal a data da vaga mais recente de cada pessoa. ob_load_tp_email_capped (25 por dia, no máximo 3 por domínio) inscreve quem passa no freio ob_offer_email_eligible e abre um ciclo em ob_offer_email_cycles.
9. ob_tick_email envia o único toque (e-mail por IA, prompt em-tpoffer-us-e1-ai-v1), espera 14 dias e encerra. ob_offer_reconcile_cycles fecha o ciclo e conta "sem reação".

Peças

Agendamentos

Regras de negócio

• Pessoa é casada pela empresa, não pelo perfil: rodízio entre candidatos com vaga na empresa. offer_job_title é o título da vaga.
• O stage só pega quem nunca teve offer_status. Quem já foi sent não volta sem limpar o campo.
• Para tirar alguém do LinkedIn: tirar o queued, esvaziar offer_cv_url ou marcar do_not_contact.
• Cordial com stop_on_reply:false: responder a ela não para a oferta. No e-mail, só resposta humana encerra (auto-reply não).
• Freio do e-mail: e-mail Verified, sem supressão, empresa fora de block_company, vaga mais nova que o último sinal, sem ciclo aberto, 30 dias desde o último ciclo, menos de 4 ciclos em 365 dias, menos de 4 ciclos sem reação.
• days do LinkedIn conta a partir do aceite, em dias de calendário no fuso America/New_York.
• Convite não aceito em 30 dias é retirado e o enrollment vira expired.

Integrações e credenciais

• Unipile (LinkedIn): UNIPILE_API_KEY, UNIPILE_DSN em Edge Function Secrets. LI_PUSH_SECRET no Vault e em Edge Function Secrets, com o mesmo valor nos dois.
• OpenRouter (copy por IA, openai/gpt-4o-mini): OPENROUTER_API_KEY em Edge Function Secrets.
• Resend (e-mail): RESEND_API_KEY e segredos de webhook em Edge Function Secrets (ver CREDENCIAIS.md do repo do motor).
• Alertas de resposta no Discord: DISCORD_WEBHOOK_URL_US (Edge Function Secret) e li_market_config.discord_webhook_url (coluna no banco).
• Senders LinkedIn em li_senders + ob_campaign_senders; caixas de e-mail em email_senders (4 caixas @nearsmarter.com ativas na campanha).

Como monitorar

-- Status das duas campanhas
select id, name, status from ob_campaigns
 where id in ('5edf6958-02a2-42b0-b51e-7165678b57bc','47930768-aedb-47ce-87bd-c023cf855a59');

-- Funil real do LinkedIn
select count(lo.connection_sent_at) convites, count(lo.connection_accepted_at) aceites, count(lo.replied_at) respostas
  from li_outbox lo join ob_enrollments e on e.id = lo.ob_enrollment_id
 where e.campaign_id = '5edf6958-02a2-42b0-b51e-7165678b57bc';

-- Enrollments parados por sender inativo
select * from ob_paused_sender_enrollments;

Números de 08/10/2026: LinkedIn com 2.190 convites, 339 aceites e 70 respostas. E-mail com 8 hard bounces, 46 aberturas, 23 cliques e 1 resposta.

Como usar

O que pedir ao Claude

• "Como está a Talent Pool? Me dá o funil do LinkedIn e do e-mail."
• "Quantos leads estão parados por sender inativo na Talent Pool?"
• "Troca o link do CV do candidato X pelo novo link" (o Claude valida a URL antes).
• "Por que a Talent Pool de e-mail não está enviando?"

Passo a passo

1. Peça o status. O Claude lê o funil e os alertas no banco.
2. Se o e-mail estiver pausado por bounce, decida com o time antes de religar: religar sem limpar a fila manda para quem já está acumulado.
3. Para alimentar o LinkedIn, peça "roda o stage da Talent Pool em dry-run". Confira o número e só então autorize a execução real.
4. A carga entra sozinha na terça seguinte, às 09:00.
5. Para parar tudo numa emergência, peça "pausa a Talent Pool LinkedIn" ou "pausa a Talent Pool e-mail".

Cuidados

• Nunca liste nomes de candidatos em material externo. Use o rótulo do perfil.
• Os CVs ficam só no bucket offer-cvs. Não anexe PDF em lugar nenhum.
• Mudar caps de sender tem efeito no próximo tick: suba diário e semanal juntos.
• Não desative sender com fila sem remanejar antes.

Fontes

• README.md
• RUNBOOK-talent-pool-live.md
• CREDENCIAIS.md
• tasks/EXECUCAO.md
• migrations/crons_fase2.sql
• Supabase nearsmart: cron.job, ob_campaigns, ob_enrollments, ob_activities, ob_alert_log, li_outbox, email_outbox, li_senders, people e definições das funções citadas

Coleta semanal de vagas de tecnologia em job boards dos EUA, que alimenta a base de vagas e empresas do Supabase (e, por tabela, a Talent Pool). A versão em squad + Supabase está pausada. Hoje a coleta roda no n8n e grava nas mesmas tabelas: apify_jobs e jobs_analyzed.

Como funciona

Fluxo

Versão squad (pausada), 11 passos com 4 checkpoints humanos:

1. Marcos Maestro lê hunter_sites ativos por prioridade, separa os requires_auth e estima o tempo.
2. Checkpoint: aprovação dos sites e da estimativa.
3. Sandro Scout raspa cada site com Playwright (paginação por data, limite de páginas por tier).
4. Natália Norm normaliza, canonicaliza a URL e deduplica por SHA-256 da URL.
5. Checkpoint: estatísticas por site antes de gravar.
6. Inês Insert chama a RPC 1 ingest_apify_jobs_bronze(p_items, p_scrapy_query_id, p_default_source) e grava no bronze apify_jobs.
7. Ana Analyst enriquece com IA (campos ai_*) em blocos de 15.
8. Checkpoint: amostra de 3 vagas enriquecidas.
9. Inês chama as RPCs 2 a 4: promote_apify_jobs_to_jobs_analyzed (prata), upsert_targets_from_jobs_analyzed (empresas em targets) e refresh_target_jobs_all (liga vaga e empresa em target_jobs).
10. Marcos atualiza last_run_at e registra erros por site.
11. Checkpoint: relatório final.

Depois da coleta, o banco segue sozinho: o cron offer_pipeline_daily reclassifica as vagas para a Talent Pool e roda refresh_target_jobs_all todo dia.

Versão n8n (atual): grava em apify_jobs e jobs_analyzed, as mesmas tabelas da versão Supabase. Workflow, fontes e agenda do fluxo n8n não foram levantados nesta documentação.

Peças

Agendamentos

Regras de negócio

• Prioridade define páginas: tier 1 e 2 (70 a 100) até 10 páginas, tier 3 e 4 até 5, tier 5 até 2.
• Sites requires_auth nunca entram no run.
• last_run_at só é atualizado quando todas as RPCs terminam com sucesso.
• Falha de site não aborta o run. Falha de RPC aborta.
• Dedup cruzado entre runs e com o Apify é feito no banco por url_sha256.
• A vaga só vira empresa se tiver domínio: upsert_targets_from_jobs_analyzed exige domain.
• No bronze, a promoção lê a chave organization (não company) e precisa de id no topo do item; sem id, a RPC insere mas não conta.

Integrações e credenciais

• Supabase: SUPABASE_URL + SUPABASE_KEY (script legado) ou SUPABASE_SERVICE_KEY (Scrapy v2), sempre por variável de ambiente local.
• Wellfound: sessão persistente de navegador em _opensquad/_browser_profile/wellfound/, renovada a cada 2 a 4 semanas.
• Apify: pipeline externo que grava no mesmo bronze (fontes de ATS como greenhouse, lever, ashby, workday). A confirmar onde mora a credencial do Apify.
• n8n: A confirmar credenciais e nós do fluxo atual.

Como monitorar

-- Última coleta e volume por semana
select date_trunc('week', fetched_at)::date semana, count(*) vagas, count(distinct source) fontes
  from apify_jobs where fetched_at > now() - interval '60 days' group by 1 order by 1 desc;

-- Prata e ouro
select max(created_at) ultima_prata from jobs_analyzed;
select max(created_at) ultimo_vinculo from target_jobs;

-- Sites do squad
select name, scraper_type, priority, active, last_run_at from hunter_sites order by priority desc;

Como usar

O que pedir ao Claude

• "Quando entrou a última vaga no Supabase e de quais fontes?"
• "Quantas vagas novas viraram empresa-alvo esta semana?"
• "O site X parou de trazer vaga. Roda o inspector e me sugere seletor" (só com o squad local).
• "Lista os sites ativos do Hunter e os que estão quebrados."

Passo a passo

1. Para saber se a coleta está viva, peça a última data de apify_jobs. Mais de 7 dias sem linha nova é sinal de problema no n8n.
2. Se estiver parado, avise a Karime: o fluxo vive no n8n e não é visível pelo Claude.
3. Para corrigir um site do squad, atualize hunter_sites.config.selectors e rode smoke_test_site.py antes do run.
4. Para religar o squad, rode /opensquad run hunter-squad na máquina local e aprove os 4 checkpoints.

Cuidados

• Não ative todos os 45 sites de uma vez: 20 estão desligados por anti-bot, domínio morto ou login.
• O bronze é compartilhado com o Apify. Não apague linhas de apify_jobs.
• Mudanças em jobs_analyzed afetam a classificação da Talent Pool no dia seguinte.

Fontes

• squad.yaml
• pipeline/pipeline.yaml
• _memory/memories.md e _memory/runs.md
• _design/arquitetura-v2.md
• scraper/README.md e scripts/README.md
• agents/marcos-maestro.agent.md
• state.json
• Supabase nearsmart: hunter_sites, scrapy_queries, apify_jobs, jobs_analyzed, google_jobs, google_jobs_analyzed, target_jobs, cron.job, assinaturas das RPCs

Máquina mensal que pega CTOs recém-empossados (até 6 meses no cargo) das listas do Apollo, qualifica, separa US e BR, coloca na lista de remarketing e envia os de US para uma campanha de e-mail no motor ob_*. O envio BR aguarda a conexão de uma nova conta. Status: No ar, com 1.354 CTOs US ativados.

Como funciona

Fluxo

1. Dia 10 de cada mês, os Workers (Plays) do Apollo, um para US e um para BR, buscam CTOs com até 6 meses no cargo, empresa de 1 a 1000 funcionários e e-mail verificado. Salvam a pessoa na lista cto_transiction e a empresa na lista cto_transiciton_company. US e BR usam as mesmas listas.
2. Dia 11, o cron cto-monthly-pull chama a edge cto-apollo-pull em modo live.
3. A edge lê a lista de empresas (accounts/search) e grava o país real em targets via fn_ingest_cto_accounts.
4. Lê a lista de pessoas (contacts/search), faz upsert em people (dedupe por e-mail, LinkedIn e person_id do Apollo) e inscreve todos em cto_list_members via fn_ingest_cto_batch.
5. fn_qualify_cto(cohort_month) promove para a GOLD cto_jobchange_leads quem é CTO de fato, tem pessoa e empresa no mesmo mercado, não é cliente nem concorrente e ainda não está na GOLD.
6. fn_sync_remarketing_cto marca people.is_remarketing e remarketing_campaign_id. O trigger trg_people_sync_remarketing_member coloca a pessoa em remarketing_campaign_members.
7. Às 08:00 BRT do mesmo dia, o cron cto-monthly-ob-us roda fn_cto_ob_push('us', cf72dce0..., 300, false): cria ou reaproveita o lead em ob_leads, inscreve na campanha via ob_load_campaign e marca ob_enrolled_at na GOLD só quando o enrollment existe.
8. ob_tick_email envia a sequência: e-mail 1, espera 3 dias, e-mail 2 na mesma thread, fim.
9. O remarketing é exportado à mão para o Google Ads pela view v_cto_remarketing_export.

Estado atual (08/10/2026)

• GOLD US: 1.354 activated (1.337 inscritos no motor ob_* em 01/09/2026, 17 sem inscrição) e 19 new da safra de setembro, à espera do próximo cto-monthly-ob-us.
• GOLD BR: 22 activated (enviados ao Lemlist BR) e 33 new. O envio BR aguarda a conexão de uma nova conta. Não existe cron BR, e a campanha ob_* BR (3569eb46-9f97-4fcc-bbe2-1758b1f34782) está paused.
• A doc v2 descreve push ao Lemlist US e BR (cto-monthly-lemlist-us e -br). Esses crons não existem mais. A edge cto-lemlist-push segue publicada, sem agendamento.
• Campanha US no motor: 500 waiting, 422 active, 396 completed, 14 bounced, 4 DNC. Métricas: 1.309 enviados, 1.290 entregues, 744 aberturas, 26 bounces.
• Remarketing: 1.349 membros em "CTO Transiction [US]" e 55 em "CTO Transiction [BR]". Os dois públicos estão com status pause em remarketing_campaigns porque hoje não há campanha rodando no Google Ads; isso pausa só o anúncio. A campanha de e-mail "CTOs em Transição, US, Indicação" segue enviando (563 e-mails em 7 dias até 08/10/2026).

Peças

Agendamentos

Regras de negócio

• Cargo: CTO, Chief Technology Officer e variações com founder. Ficam fora Field, Fractional, Deputy, Portfolio, "to the CTO", CTO Office, Chief of Staff, ex-CTO.
• Região só existe quando pessoa e empresa estão no mesmo mercado (US com US, BR com BR). Sem isso, o lead não entra.
• Headcount nulo é aceito, porque a API das listas não devolve número de funcionários e o worker já filtra porte.
• Exclusão por domínio normalizado contra clients e contra todos os 564 registros de competitors (canais luby.co e luby.com.br).
• Cada pessoa entra uma única vez na GOLD. O push ao motor marca pelo fato (enrollment criado), então lead pulado volta na próxima rodada.
• Remarketing não sequestra quem já está em outra campanha de remarketing.
• Rodada de setembro: 2.281 candidatos, 52 entraram, 224 não-CTO, 339 sem região, 310 empresa grande, 5 concorrentes, 0 clientes.

Integrações e credenciais

• Apollo: APOLLO_API_KEY em Edge Function Secrets. Ler listas não gasta crédito.
• Lemlist (legado): LEMLIST_API_KEY em Edge Function Secrets.
• Cron do pull: a credencial da chamada é lida do Supabase Vault.
• Envio: caixas de e-mail do motor (23 senders ativos na campanha US), via Resend.
• Google Ads: upload manual da lista de remarketing.

Como monitorar

-- GOLD por região, status e inscrição no motor
select region, status, (ob_enrolled_at is not null) inscrito, count(*)
  from cto_jobchange_leads group by 1,2,3 order by 1,2,3;

-- Últimas execuções e exclusões
select stage, status, inserted, started_at, notes from cto_pipeline_runs order by started_at desc limit 5;

-- Crons da máquina
select jobname, schedule, active from cron.job where jobname like 'cto-%' or jobname = 'ob_bounce_guard_cto_us';

-- Funil da campanha US
select em_sent, em_delivered, em_opened, em_bounced from ob_campaign_metrics
 where campaign_id = 'cf72dce0-b364-495a-83de-d855f6326d89';

Como usar

O que pedir ao Claude

• "Como está a máquina de CTOs? Quantos entraram este mês e quantos foram para a campanha?"
• "Quantos CTOs BR estão aguardando o envio BR?"
• "Roda o scout do CTO e me diz quantos novos tem nas listas do Apollo" (gratuito).
• "Me dá o funil da campanha de CTOs US."
• "Gera o export de remarketing de CTOs US para o Google Ads."

Passo a passo

1. Depois do dia 11, peça o resumo da rodada. O Claude lê cto_pipeline_runs e a GOLD.
2. Confira se os new de US viraram inscritos no motor depois das 08:00 do dia 11.
3. Para BR, o envio aguarda a conexão de uma nova conta. Não peça push dos leads BR antes disso.
4. Para o remarketing, peça o export e suba a lista no Google Ads.

Cuidados

• Mantenha clients atualizada: é ela que evita abordar cliente atual.
• Não rode fn_cto_ob_push com dry_run=false fora da rotina sem combinar: ele inscreve na hora.
• Não reative os pushes ao Lemlist: os mesmos leads já estão no motor ob_*.

Fontes

• Máquina de Aquisição CTOs em Transição, Documentação Técnica v2
• Apollo Worker (Enrollment), Configuração e Listas
• Supabase nearsmart: cron.job, cron.job_run_details, cto_jobchange_leads, cto_list_members, cto_pipeline_runs, cto_config (colunas), remarketing_campaigns, remarketing_campaign_members, ob_campaigns, ob_enrollments, ob_steps, ob_campaign_metrics, ob_alert_log, definições de fn_cto_ob_push, fn_qualify_cto, lista de edge functions

Robô que lê os comunicados do Banco Central, monta a lista de instituições reguladas (na fila de autorização e já autorizadas) com seus diretores estatutários, enriquece com Receita e Apollo e publica a planilha "Lista Bacen" no Drive para prospecção manual. Status: No ar, pela tarefa agendada bacen-lista-auto (dias úteis, 07:13 BRT). A base tem 716 instituições.

Como funciona

Fluxo

1. rodada.py coleta os comunicados pela API REST do BACEN (/api/search/app/normativos/buscanormativos), filtra por assunto e baixa o texto integral de cada um (exibeoutrasnormas).
2. Regex extrai instituição, tipo, CNPJ raiz, órgão estatutário e pessoas. O marcador "(instituição em processo de autorização)" separa fila de autorizada. Sem LLM.
3. O CNPJ completo é reconstruído (raiz + 0001 + dígito verificador) e consultado na Minha Receita (BrasilAPI de reserva): razão social, fantasia, capital social, QSA.
4. delta.py compara a coleta com o banco antes de gravar.
5. Só o que é novo vai ao Apollo: instituição nova (site e domínio, cerca de 1 crédito) e pessoa nova (LinkedIn e e-mail no mesmo match, cerca de 1 crédito). Dia sem novidade custa zero.
6. sync_supabase.py grava com merge preservador: campo preenchido nunca é sobrescrito por vazio.
7. exportar_final.py gera a planilha a partir do banco (abas Instituições, Pessoas, Metodologia e, quando há novidade, Novidades como primeira aba).
8. publicar_drive.py atualiza o Google Sheets "Lista Bacen" no lugar (mesmo link).
9. notificar.py avisa no Discord só quando há novidade ou falha de parsing.
10. A rodada é registrada em bacen_runs.

Peças

Agendamentos

A tarefa bacen-lista-auto é a rotina de nuvem descrita no NUVEM.md: está ativa nesta conta e bacen_runs mostra 60 rodadas ok em dias úteis desde 21/07/2026.

Regras de negócio

• "Pessoa" é o diretor estatutário que consta no comunicado e no QSA da Receita (decisão do Rodrigo Gardin, 28/04/2026).
• Domínio errado é pior que vazio: sem confirmação, o campo fica em branco e marcado como "sem informações públicas".
• O Apollo indexa a marca, não a razão social. O scoring só aceita domínio com evidência; o resto vai para conferência com CNPJ.
• A API do BACEN exige querystring percent-encoded em UTF-8. Acento mal codificado devolve 0 resultados com HTTP 200, sem erro. buscar() aborta se vier 0.
• Falha de parsing maior que 0 aborta a publicação e avisa: indica mudança de formato do BACEN.
• A planilha é sempre o mesmo arquivo: a service account não tem cota para criar arquivo novo, só para atualizar o de dono humano.

Integrações e credenciais

• Chave-mestra: SUPABASE_SERVICE_ROLE_KEY. Local: .env do projeto (gitignored). Na tarefa agendada: lida de public.ads_secrets id bacen-supabase-service.
• Cofre public.ads_secrets (lido com a chave-mestra): apollo-config (Apollo), drive-sa-key (service account do Drive), bacen-notification (webhook do Discord próprio da rotina).
• APOLLO_API_KEY pode existir no .env local só como transição até rodar bootstrap_secrets.py.
• Pasta do Drive: BACEN_DRIVE_FOLDER_ID (variável opcional; padrão no config.py).
• APIs públicas sem chave: BACEN, Minha Receita, BrasilAPI.

Como monitorar

-- Últimas rodadas
select id, iniciado_em, status, comunicados_novos, instituicoes_novas, pessoas_novas,
       creditos_apollo, falhas_parsing
  from bacen_runs order by iniciado_em desc limit 10;

-- Tamanho da base
select count(*) filter (where em_fila) na_fila, count(*) filter (where not em_fila) autorizadas,
       count(*) filter (where coalesce(dominio,'') <> '') com_dominio
  from bacen_instituicoes;

-- Créditos Apollo gastos no mês
select sum(creditos_apollo) from bacen_runs where iniciado_em >= date_trunc('month', now());

Como usar

O que pedir ao Claude

• "Quais instituições novas entraram na Lista Bacen esta semana?"
• "Quantos créditos do Apollo o robô do BACEN gastou este mês?"
• "A última rodada do BACEN deu erro?"
• "Me dá o link da Lista Bacen."
• "Quantas instituições na fila de autorização têm site e LinkedIn de diretor?"

Passo a passo

1. Abra a planilha "Lista Bacen" no Drive. A aba Novidades, quando existe, traz o que entrou na última rodada.
2. Para saber se o robô rodou, peça ao Claude o resumo de bacen_runs.
3. Se aparecer falha de parsing, avise o time técnico: o formato do comunicado mudou e a publicação foi bloqueada de propósito.
4. Para republicar a planilha sem coletar, peça "republica a Lista Bacen a partir do banco" (modo publicar).

Cuidados

• A planilha tem CPFs. Não compartilhe fora do time nem cole trechos em e-mail, chat ou documento.
• Não peça ao Claude para listar pessoas com CPF. Peça contagens ou nomes de instituições.
• Não rode o pipeline sobre arquivos locais fora do rodada.py.

Fontes

• README.md
• BRIEFING.md
• NUVEM.md
• config.py, rodada.py, .env.example
• Supabase nearsmart: bacen_runs, bacen_instituicoes, bacen_pessoas (só contagens), bacen_comunicados
• Lista de tarefas agendadas do Claude Code desta conta (bacen-lista-auto)

A lista de bloqueio (block_company) guarda as empresas que a Luby não prospecta: clientes, empresas do grupo, parceiros, concorrentes, ex-clientes e quem pediu para sair. Está no ar: 55 empresas bloqueadas em 08/10/2026, conferidas automaticamente sempre que entram leads numa campanha.

Como funciona

Fluxo

1. Cliente entra sozinho. Ao inserir uma empresa em clients, o gatilho trg_clients_sync_block (função tg_sync_client_to_block) adota a linha de bloqueio com o mesmo domínio, se existir, ou cria uma nova com motivo='cliente', blocked=true, origem='clients' e client_id. Em UPDATE de clients, ele sincroniza nome, domínio, mercado, setor, LinkedIn e localização.
2. Os outros motivos entram à mão, pela skill /bloqueio, com origem='manual', motivo, quem pediu (atualizado_por) e uma nota.
3. Entrada de leads. Nas skills de criar campanha (Fase 5a) e de adicionar leads (passo 4a), logo depois do process da ingestão, ob_block_check_job(job_id) cruza o lote em ob_import_staging com a lista e devolve um resumo por empresa.
4. Decisão do usuário, uma chamada de ob_block_apply_decision por empresa: excluir_campanha (fica fora deste lote), nunca_contatar (marca o lead com do_not_contact e o marcador _dnc_origem='block_company') ou ignorar.
5. Matrícula. No confirm, ob_import_enroll não matricula quem tem decisão excluir_campanha ou nunca_contatar.
6. Varredura ao bloquear. Depois de bloquear uma empresa, ob_block_scan_enrollments mostra quem dela já está em campanha (só leitura). Com o "sim", ob_block_stop_enrollments para só nas campanhas escolhidas.
7. Desbloquear. ob_block_undo libera só os leads que este bloqueio marcou e lista as matrículas paradas. ob_block_reactivate_enrollments reativa, campanha por campanha, depois de outro "sim".
8. Engajamento no LinkedIn também respeita a lista: ob_eng_lead_suppression barra empresa bloqueada na carga e a cada passada do ob_eng_tick.

Peças

Regras de negócio

• Seis motivos, lista fechada: cliente, empresa do grupo, parceiro, concorrente, ex-cliente, opt-out. Outro texto é recusado pelo banco. Motivo vazio aparece como "não informado" (1 empresa hoje).
• Dois níveis de casamento: com e-mail, pelo domínio (certeza); sem e-mail, pelo nome normalizado (provável, pode ser homônimo). Cada pessoa casa com no máximo uma empresa, e o domínio ganha.
• Sem filtro de mercado: o bloqueio vale para US e BR.
• A sugestão é sempre "tirar só desta campanha", que é reversível. "Ignorar e mandar mesmo assim" existe, mas nunca vem sugerida.
• Motivo cliente se cadastra em clients, não em block_company. Escrever nas duas duplica, e o índice único por domínio faz a segunda inserção falhar.
• Quem pediu é sempre perguntado e vai em atualizado_por. O Claude nunca preenche sozinho.
• Nunca liberar um opt-out: ob_block_apply_decision não adota do_not_contact de terceiros, e o ob_block_undo só libera quem tem _dnc_origem='block_company' e o id deste bloqueio.
• A campanha Talent Pool fica fora de todas as funções que varrem matrícula.

Integrações e credenciais

Não há serviço externo. Tudo roda no Supabase via execute_sql. Para completar dados de uma empresa nova, a skill usa a base, depois busca na web (Tavily) e só usa o Apollo com "sim", porque gasta crédito.

Como monitorar

-- retrato da lista
select count(*) filter (where blocked)          as bloqueadas,
       count(*) filter (where origem = 'clients') as de_clientes,
       count(*) filter (where origem = 'manual')  as manuais,
       count(*) filter (where motivo is null)     as sem_motivo,
       count(*) filter (where atualizado_por is null) as sem_dono
  from block_company;

-- consultar uma empresa
select company_name, domain, motivo, market, origem, blocked, atualizado_por, nota, last_update
  from block_company
 where domain_norm = norm_domain('<dominio>') or norm_name(company_name) = norm_name('<nome>');

-- decisões tomadas na entrada de leads
select block_decision, count(*) from ob_import_staging
 where block_decision is not null group by 1;

-- matrículas paradas por bloqueio
select count(*) from ob_enrollments where error_reason like 'bloqueio:%';

Como usar

O que pedir ao Claude

• "A empresa X está bloqueada?"
• "Bloqueia a empresa Y, ela é concorrente."
• "A Z virou cliente."
• "Pode voltar a prospectar a W."
• "Quais empresas estão na lista de bloqueio?"

Passo a passo

1. Peça para bloquear, liberar ou consultar. O Claude sempre consulta primeiro, para não duplicar.
2. Para bloquear, informe nome, domínio, mercado, motivo (um dos seis) e quem está pedindo. O Claude completa setor e localização e mostra o que achou para você confirmar.
3. Se o motivo for cliente, o Claude cadastra em clientes e a empresa entra sozinha na lista.
4. Logo depois, o Claude mostra quem daquela empresa já está em campanha e pergunta em quais campanhas parar.
5. Para liberar, diga o motivo. O Claude registra, libera as pessoas e pergunta se quer reativar as campanhas paradas.

Cuidados

• Bloquear não tira automaticamente quem já está em campanha: responda à pergunta da varredura.
• Ao liberar uma empresa que é cliente, diga se ela deixou de ser cliente ou se é só para liberar a prospecção.
• Ao subir leads, quando o Claude mostrar empresas bloqueadas, prefira "tirar só desta campanha".

Fontes

• Reference bloqueio-empresas.md
• SKILL.md bloqueio-empresas
• Pacote de tarefas do bloqueio
• INDEX de implementação
• SKILL.md criar-campanha-outbound e adicionar-leads-campanha
• Supabase nearsmart: pg_get_functiondef de tg_sync_client_to_block e ob_eng_lead_suppression, pg_trigger, information_schema.columns de block_company, contagens de block_company, clients, ob_import_staging, ob_enrollments e ob_leads, em 08/10/2026

Automação que entrega à BDR do mercado BR, como deals no HubSpot, os leads da campanha Outsourcing BR que aceitaram a conexão no LinkedIn, e que traz de volta do HubSpot o andamento desses deals para o dashboard. Status: Parado. A fila está parada porque hoje não há BDR no time.

Como funciona

Fluxo

De onde vêm os leads (Supabase para HubSpot):

1. A campanha "Outbound - Outsourcing BR" roda no Lemlist (e-mail e LinkedIn). Cada evento do Lemlist entra em outbound_events pela função ingest_outbound_event, com person_id ligado a people.
2. A jornada do lead (current_journey_outbound) é atualizada pela regra automática apply-rules-outreach. Nos leads já empurrados, a entrada na fase consideration do fluxo outreach coincide com a data do aceite no LinkedIn.
3. A view bdr_handoff_outsourcing_br monta a fila: pessoa com people.campaign = 'Outbound - Outsourcing BR', na fase consideration/outreach, que aceitou o convite no LinkedIn, recebeu mensagem e não respondeu, não é interna, não é DNC, empresa sem "concorrente" no nome, e ainda não está em bdr_handoff. Ordem: aceite mais recente primeiro.
4. O cron bdr-push-deals-outsourcing-br chama hubspot-push-bdr-deals?limit=15 em dias úteis. Para cada lead: procura o contato no HubSpot pelo e-mail (cria se não existir), cria o deal "[Outsourcing BR] Nome, Empresa" no pipeline Prospecção, etapa 1403129000, owner da BDR, e anexa uma nota com quem iniciou a prospecção, a mensagem enviada no LinkedIn e o e-mail da campanha.
5. Grava o resultado em bdr_handoff (status='pushed', ids de deal e contato, note_at). Quem está em bdr_handoff sai da fila.

De volta (HubSpot para Supabase):

6. bdr-ingest-daily lê todos os deals da BDR no pipeline Prospecção, resolve o contato e faz upsert em bdr_leads (etapa atual). Deal cujo e-mail já existe em people ou inbound_leads é ignorado (é de outro fluxo, via RPC bdr_emails_existing). Na prática, bdr_leads guarda os deals que a própria BDR abriu fora da automação.
7. bdr-sync-daily monta o snapshot da aba BDR do dashboard em bdr_snapshots: pipeline ao vivo por etapa, leads iniciados por semana (data_entrada_campanha), tarefas, notas, e-mails, ligações, próximos passos e métricas de e-mail da campanha ob_* c7a63770-9cfc-45f4-b754-ab2a0216ae96.

Peças

Agendamentos

Regras de negócio

• Até 15 deals por dia útil. Se a fila tiver menos, empurra o que houver. Fila vazia não gera erro.
• Só entra quem aceitou E recebeu mensagem no LinkedIn E não respondeu.
• Um lead vira deal uma única vez (chave person_id em bdr_handoff).
• Etapas são mapeadas por nome: novo contato, prospecção, conversa, standby, agendamento, reunião agendada, reunião realizada, perda.
• bdr-sync tolera falta de escopo do token: se o HubSpot negar tarefas, notas, e-mails ou ligações, aquele contador fica 0 e o resto segue.

Integrações e credenciais

• HubSpot: HUBSPOT_TOKEN em Edge Function Secrets. Pipeline 81ee3345-1b0f-42aa-9e78-580614546602 (Prospecção), owner 95822021 (BDR BR), fixos no código.
• bdr-ingest e bdr-sync: exigem CRON_SECRET_OUTBOUND_JOURNEY (Edge Function Secret; o cron lê do Supabase Vault).
• SUPABASE_SERVICE_ROLE_KEY injetada pelo Supabase nas três edges.

Como monitorar

-- Fila agora
select count(*) from bdr_handoff_outsourcing_br;

-- Pushes por dia
select pushed_at::date, count(*) from bdr_handoff group by 1 order by 1 desc limit 15;

-- Deals da BDR por etapa e último lead novo
select hs_stage_key, count(*) from bdr_leads group by 1;
select max(first_seen_at) from bdr_leads;

-- Saúde dos crons
select j.jobname, d.status, d.start_time from cron.job_run_details d join cron.job j on j.jobid = d.jobid
 where j.jobname like 'bdr-%' order by d.start_time desc limit 9;

Números de 08/10/2026: 53 deals em bdr_leads (42 perda, 6 reunião realizada, 3 novo contato, 1 conversa, 1 reunião agendada).

Como usar

O que pedir ao Claude

• "Quantos leads estão na fila da BDR hoje?"
• "Quantos deals foram para o HubSpot esta semana?"
• "Como está o pipeline da BDR por etapa?"
• "Por que a fila da BDR está vazia?"
• "Quem está na fila de cold call com 3 aberturas ou mais?"

Passo a passo

1. Peça o tamanho da fila. Zero por vários dias significa que a campanha de origem parou de gerar aceites.
2. Confira no Lemlist se a campanha "Outbound - Outsourcing BR" está rodando no LinkedIn. Se não estiver, a fila não volta sozinha.
3. Os deals aparecem no HubSpot às 07:00, no pipeline Prospecção, já com a nota da abordagem.
4. Para ver o trabalho da BDR, abra a aba BDR do dashboard (atualizada às 06:00).

Cuidados

• Não aumente o limit do push (15 por dia) sem combinar com a BDR.
• Não crie deal manual para quem já está em bdr_handoff: duplica no HubSpot.
• Dados de contato dos leads ficam no HubSpot e no Supabase. Não copie e-mail ou telefone para planilhas soltas.

Fontes

• Edge functions (código lido no Supabase): bdr-ingest, bdr-sync, hubspot-push-bdr-deals, sync-outbound-journey
• Supabase nearsmart: cron.job, cron.job_run_details, definições das views bdr_handoff_outsourcing_br, bdr_note_content, cold_call_queue, tabelas bdr_handoff, bdr_leads, bdr_snapshots, outbound_events, ob_campaigns, função ingest_outbound_event

Pipeline que descobre e enriquece concorrentes da Luby no mercado brasileiro a partir das buscas do Google, e acompanha a posição deles nas SERPs. Status: Parado. Está pausado no momento. A base tem 564 concorrentes.

Como funciona

Fluxo

1. Lê as consultas cadastradas em queries com channel='luby.com.br' (74 consultas: 54 comerciais originais + 20 tier-1 BR).
2. Fase 3: Tavily Search roda cada consulta (até 20 resultados) e grava a SERP em serp_results (url, posição, título, snippet, score).
3. Fase 4: blacklist e dedup por domínio registrável.
4. Fase 5: crawl local com crawl4ai (homepage em markdown, cache de 7 dias) e 2 passos de LLM no OpenRouter: filtro SIM/NÃO (modelo barato) e extração em JSON (vocabulário controlado).
5. Fase 6: upsert idempotente em competitors com channel='luby.com.br' e ligação em competitor_queries (qual consulta trouxe cada concorrente, com posição).
6. Cada execução abre e fecha um registro em pipeline_runs (started, completed, partial ou failed, com estatísticas em notes).
7. Modo tracking (mensal): repete a SERP. URL já conhecida vira linha em competitor_rankings; URL nova passa pelas fases 4 a 6.

Peças

Agendamentos

Regras de negócio

• dry_run=true é o padrão. Só grava com --no-dry-run ou PIPELINE_DRY_RUN=false.
• main_service e target_audience usam vocabulário fechado. Flags próprias: oferece_outsourcing (149 no canal BR), oferece_desenvolvimento_customizado, tipo_empresa_inferido, is_brazilian_company (300 no canal BR).
• domain_authority é a média do score do Tavily x 100, não é DA da Moz.
• O índice único de URL vale para todos os canais: um concorrente já no canal US bloqueia o mesmo domínio no BR.
• Uso fora do pipeline: a máquina de CTOs em transição exclui por domínio qualquer empresa presente em competitors (os dois canais). A lista funciona como lista de exclusão de prospecção.

Integrações e credenciais

• SUPABASE_URL, SUPABASE_SERVICE_ROLE_KEY, TAVILY_API_KEY, OPENROUTER_API_KEY: em GitHub Secrets (Actions) e no .env local (gitignored). Na rotina remota, como variáveis de ambiente da rotina.
• Modelos (opcionais, com padrão no código): OPENROUTER_FILTER_MODEL e OPENROUTER_EXTRACT_MODEL (família Gemini Flash).
• Custo estimado: cerca de US$ 0,58 por discovery completa e US$ 0,45 por tracking.

Como monitorar

-- Execuções
select id, mode, status, started_at, competitors_inserted, notes->'stats' stats
  from pipeline_runs order by started_at desc limit 10;

-- Tamanho da base por canal
select channel, count(*), max(created_at) from competitors group by 1;

-- Movimento de posições no último tracking
select date(created_at), count(*) from competitor_rankings group by 1 order by 1 desc limit 5;

No GitHub: aba Actions do repo, workflow "Pipeline BR, Tracking Mensal" (execuções e artifacts com os dumps).

Como usar

O que pedir ao Claude

• "Quantos concorrentes BR temos e quantos oferecem outsourcing?"
• "Quem são os concorrentes que mais aparecem em 'fábrica de software'?"
• "Como foi o último tracking de concorrentes? Teve erro?"
• "A empresa X está na lista de concorrentes?" (útil antes de prospectar)
• "Quais concorrentes subiram de posição no último mês?"

Passo a passo

1. Para consultar a base, peça a contagem ou a busca por nome ou domínio.
2. Para checar a saúde, peça o resumo de pipeline_runs. Status partial com 0 inseridos indica que a descoberta está travada.
3. Para religar a descoberta, alguém técnico precisa conferir os logs do Actions e rodar python -m pipeline_br doctor com as chaves.
4. Para adicionar consultas, peça a inclusão em queries com channel='luby.com.br'; elas entram no próximo dia 1.

Cuidados

• Rodar discovery real gasta Tavily e OpenRouter. Peça sempre dry-run primeiro.
• Não apague concorrente sem avisar: a lista também protege a prospecção de CTOs.
• Não compartilhe as chaves do .env; peça acesso a quem administra os GitHub Secrets.

Fontes

• README.md
• routines/README.md
• .github/workflows/tracking.yml
• .env.example
• scripts/run_remote_tracking.sh
• src/pipeline_br/pipeline.py
• Histórico de execuções do GitHub Actions do repo
• Supabase nearsmart: pipeline_runs, competitors, competitor_queries, competitor_rankings, serp_results, queries, definição de fn_qualify_cto

Cada empresa que o Apollo identifica visitando luby.co, luby.com.br ou finfy.luby.com.br vira um alerta no Discord do time, enviado pelo próprio Supabase, sem n8n. Está no ar desde 14/09/2026 e recebe dados nas janelas em que o tracking do Apollo está ligado (limite de 100 créditos).

Como funciona

Fluxo

1. O Apollo (Website Visitors) identifica a empresa que visitou o site. Um nó "Send webhook" por domínio faz POST para a Edge Function, num caminho por mercado: /functions/v1/apollo-visitor-webhook/us, /br ou /finfy.
2. O corpo é montado no Apollo com variáveis de conta: company, website_url, linkedin_url e country. O mercado vem do caminho da URL, não do corpo.
3. A função valida o header x-webhook-secret, valida que o corpo é um objeto JSON e grava uma linha em site_visitor_events (com o payload cru em raw_payload). Responde 202 e não fala com o Discord.
4. O trigger trg_site_visitor_notify (AFTER INSERT) chama site_visitor_notify(), que delega para site_visitor_resolve_dispatch(): lê a config do mercado em li_market_config, monta a mensagem com site_visitor_render_template() e dispara net.http_post (pg_net) para o webhook do Discord do mercado.
5. Cada disparo gera uma linha em visitor_notify_log com status queued (ou skipped, se o mercado estiver desligado).
6. O cron visitor_notify_reconcile roda a cada minuto, lê a resposta do Discord em net._http_response e fecha o status: 2xx vira delivered; 429 é reenviado respeitando o Retry-After (até 5 tentativas); outros erros viram failed e geram linha em sync_errors.

Peças

Agendamentos

Observação: as visitas reais registradas chegaram sempre entre 08:21 e 08:25 UTC (05:21 a 05:25 BRT), em lote. A confirmar se é o Apollo que envia uma vez por dia.

Regras de negócio

• Notifica 24/7, sem janela de horário, sem deduplicação e sem lista de bloqueio (decisão do PRD).
• Canais: US tem canal próprio; BR e FINFY dividem o mesmo canal. O placeholder {site} (mercado em maiúsculas) diz de qual site veio.
• Placeholders aceitos no template: {company} {website} {linkedin} {country} {time} {site}. {time} usa received_at em UTC.
• Hoje os três mercados usam o mesmo template em português (título "Nova visita no site" com o mercado, empresa em negrito, site, LinkedIn, país e horário). O US foi editado em 17/09 e o BR em 25/09.
• Linha de FINFY tem active=false (não é mercado de LinkedIn/booking) e visitor_active=true.
• O payload só traz dados de conta (empresa), não de pessoa. Página visitada e localização fina não vêm.
• Ligar e desligar por mercado é só mudar visitor_active na tabela, sem deploy.

Integrações e credenciais

• Apollo: tracker de Website Visitors com 3 nós "Send webhook" (um por domínio). Header x-webhook-secret configurado na própria UI do Apollo.
• Segredo de entrada: APOLLO_VISITOR_WEBHOOK_SECRET, em Edge Function Secrets do Supabase. Mesmo valor nos headers do Apollo.
• APOLLO_VISITOR_EXTRA_MARKETS (Edge Function Secrets, opcional): libera mercados de teste como e2e. Vazio em produção.
• Webhooks do Discord: coluna visitor_webhook_url de li_market_config (banco). Nunca vão para o repo.
• Testes E2E: variáveis em .env local (gitignored), modelo em .env.example.

Como monitorar

-- Volume e entrega por dia e mercado
select * from public.visitor_notify_metrics order by day desc, market;

-- Último evento por mercado
select market, count(*) as visitas, max(received_at) as ultimo
from public.site_visitor_events group by market;

-- Falhas recentes
select function_name, context, error_msg, created_at
from public.sync_errors
where function_name in ('site_visitor_notify','visitor_notify_reconcile')
order by created_at desc limit 20;

-- Config sem expor o webhook
select market, visitor_active, visitor_webhook_url is not null as tem_url, md5(visitor_webhook_url) as impressao
from public.li_market_config where market in ('us','br','finfy');

Como usar

O que pedir ao Claude

• "Quantas empresas visitaram o site esta semana, por mercado?"
• "Mostra as últimas 20 visitas do site US com empresa e país."
• "Alguma notificação de visitante falhou no Discord nos últimos 7 dias?"
• "Desliga o alerta de visitantes do FINFY sem mexer no BR." (pede confirmação antes de alterar)
• "Quando foi a última visita registrada pelo Apollo?"

Passo a passo

1. Combine com o time o período da janela de tracking no Apollo, de olho nos 100 créditos.
2. Ligue o tracking no Apollo para o período. Nada muda do lado do Supabase.
3. Acompanhe os alertas no canal do Discord do mercado (US, ou BR+FINFY).
4. No fim do período, peça ao Claude o resumo de visitas por mercado e confira se houve falha de entrega.
5. Para mudar o texto da mensagem ou trocar o canal, peça ao Claude para editar visitor_template ou visitor_webhook_url do mercado. Vale na próxima visita, sem deploy.

Cuidados

• Não use o "Send test" do Apollo para validar a mensagem: ele manda texto cru.
• Nunca cole o webhook do Discord nem o segredo do Apollo em chat, doc ou Trello.
• Se o canal ficar em silêncio, primeiro confirme se a janela do Apollo está ligada.
• Os dados são de empresa, mas a tabela é só para backend. Não exponha em painel público.

Fontes

• CLAUDE.md do website-visitors
• PRD
• Techspec
• Tasks
• Runbook de go-live
• Relatório de QA
• Bugs
• Edge Function apollo-visitor-webhook
• Migration de reconciliação
• Migration de seed dos mercados
• Supabase nearsmart: site_visitor_events, visitor_notify_log, li_market_config, sync_errors, cron.job (consultas de leitura em 08/10/2026)

Páginas públicas onde o lead escolhe dia e horário e marca 30 minutos com alguém da Luby: agendamento.luby.com.br (BR, pt-BR) e schedule.luby.co (US, en-US). Estão no ar: 11 reuniões nos últimos 30 dias (8 BR e 3 US).

Como funciona

Fluxo

1. O lead abre a página. Na raiz / aparece o host padrão do mercado; em /<slug> aparece o host do slug (ex.: /alon). O front lê o host na view hosts_public, filtrando por mercado (BR por locale = pt-BR, US por market = US). Slug de outro mercado dá 404.
2. Ao abrir, o front grava a atribuição first-touch na sessão (luby_attrib_v1): source (utm_source ou, sem ele, o referrer classificado como direct, llm:, organic:, landing:, social: ou referral:) e originUrl (URL com gclid/UTM/landing_page, completada pelo cookie luby_attribution das LPs).
3. O lead escolhe um dia (fins de semana e datas passadas ficam bloqueados). O front chama o webhook do Workflow A no n8n com o intervalo do dia em horário de São Paulo, duração 30 min e o host. O n8n devolve os horários livres.
4. O lead preenche nome, sobrenome, e-mail, telefone e mensagem e confirma.
   • BR: o front insere direto em agendamento_luby com a anon key.
   • US: o front chama a Edge Function submit-booking, que valida e insere com service role, forçando market = 'US'.
5. Antes do insert, o trigger trg_fill_attribution (fill_attribution_from_url) quebra a origin_url nas colunas gclid, gclsrc, gbraid, wbraid, utm_*, msclkid, fbclid e landing_page.
6. Depois do insert, um trigger por mercado dispara o n8n via pg_net: trg_notify_n8n_booking_br (quando host preenchido, status = 'pending' e market = 'BR') chama notify_n8n_booking_br(); o equivalente US é trg_notify_n8n_booking_us / notify_n8n_booking_us(). Cada um faz POST no webhook do Workflow B do seu mercado, com header x-webhook-secret.
7. O Workflow B (n8n) valida o segredo, calcula início e fim no fuso do lead, lê o host na tabela hosts, cria o evento no Google Calendar do host, atualiza a linha para booked com event_id e meet_link, e envia e-mail ao lead, e-mail ao time e mensagem no Discord.
8. Se o webhook falhar, um gatilho de agenda no próprio Workflow B pega as linhas pending com mais de 10 minutos e processa.
9. No navegador, após o insert ok, o front envia o evento form_submit ao GTM, que aciona as conversões (GA4 generate_lead, Google Ads, Meta Lead).

Peças

Agendamentos

Não há cron no Supabase para o agendamento. Intervalos lidos dos exports no repo; o n8n não foi acessado.

Regras de negócio

• Hosts ativos hoje: BR juliana_roman (padrão), alon, marcelo_feltrin, rodrigo_gardin; US wagner_lopes (padrão), alon-lubieniecki, maise_mandel, marine_pimenta. Inativos: daniel_schnaider e samuel_silva.
• Um único host padrão por mercado (índice único hosts_one_default_per_market).
• Reunião de 30 min. Todos os hosts estão no fuso America/Sao_Paulo, com expediente entre 08:00 e 19:00 conforme o host.
• Isolamento por mercado: o trigger BR só dispara para market = 'BR' e o US só para market = 'US', para um workflow não processar a reunião do outro.
• Validação BR: nome com letras, telefone com 10 a 13 dígitos, mensagem de 15 a 1.500 caracteres. Validação US: mensagem com pelo menos 10 caracteres.
• E-mails saem de noreply@nearsmarter.com. BR avisa os notify_emails do host; no export US a lista do time é fixa no nó do n8n.

Integrações e credenciais

• n8n (n8n.srv860950.hstgr.cloud): Workflow A via VITE_N8N_WEBHOOK_URL (com URL de fallback no código); Workflow B via URL gravada nas funções notify_n8n_booking_*.
• Segredo do webhook B: header x-webhook-secret.
• Google Calendar: credencial Google do n8n (dentro do n8n).
• Supabase no front: VITE_SUPABASE_URL e VITE_SUPABASE_ANON_KEY (US: GitHub Actions Secrets).
• Deploy: GitHub Actions Secrets SSH_HOST, SSH_USER, SSH_PASSWORD, SSH_PORT, DEPLOY_PATH, DISCORD_WEBHOOK_URL (aviso de deploy).
• GTM: container instalado no index.html; conversões configuradas no GTM.

Como monitorar

-- Reuniões dos últimos 30 dias por mercado e status
select market, status, count(*), max(created_at) as ultima
from public.agendamento_luby
where created_at > now() - interval '30 days'
group by 1, 2 order by 1, 2;

-- Travadas: pending há mais de 15 min (n8n não processou)
select id, market, host, created_at
from public.agendamento_luby
where status = 'pending' and created_at < now() - interval '15 minutes';

-- Hosts ativos por mercado
select market, slug, is_default, active from public.hosts order by market, slug;

Como usar

O que pedir ao Claude

• "Quantas reuniões foram agendadas pelas páginas de agendamento este mês, BR e US?"
• "De onde vieram as reuniões de setembro (UTM, LLM, landing)?"
• "Tem alguma reunião travada como pending?"
• "Qual é o link de agendamento da Marine?" (resposta: schedule.luby.co/marine_pimenta)
• "Quais hosts estão ativos na página BR?"

Passo a passo

1. Para mandar o link a um lead, use a raiz (host padrão) ou o link do host: agendamento.luby.com.br/<slug> no BR e schedule.luby.co/<slug> no US.
2. Em campanhas, mande o link com UTM (utm_source, utm_campaign). A origem fica gravada na reunião.
3. Quando o lead agenda, o host recebe o convite no Google Calendar com link do Meet, o time recebe e-mail e o Discord recebe aviso.
4. Para incluir, pausar ou trocar o host padrão, peça ao Claude para preparar a mudança na tabela hosts e aprove antes.

Cuidados

• Host novo precisa de calendário com acesso pela credencial Google do n8n; sem isso o evento não é criado.
• Não troque o host padrão sem avisar: a raiz da página passa a cair na agenda de outra pessoa.
• Não cole a URL do webhook do n8n nem o segredo em lugar nenhum.

Fontes

• docs/EDGE_FUNCTIONS.md (US)
• docs/US-MULTI-HOST.md (US)
• submit-booking
• booking.ts BR e booking.ts US
• slots.ts, hosts.ts e attribution.ts (BR)
• server/index.js BR
• Workflow B BR (export) e Workflow B US (export)
• Deploy BR e Deploy US
• Supabase nearsmart: agendamento_luby, hosts, hosts_public, pg_trigger, pg_policies, funções notify_n8n_booking_br/us e fill_attribution_from_url, lista de Edge Functions (leitura em 08/10/2026)

Sistema no Supabase que coloca cada lead (outbound e inbound) em uma de 6 fases e um de 7 fluxos, move o lead de fase por regras automáticas e espelha deals, contatos e atividades do HubSpot. Status Parcial: ainda não está 100% finalizado, e a regra do fluxo Outreach responde com erro. É débito técnico deixado pela Estela, que saiu da empresa; hoje a jornada está sem dono.

Como funciona

A Jornada é o sistema nervoso do funil de marketing: observa o comportamento de cada lead e o move sozinho de fase, sem ninguém atualizar status na mão. O objetivo é ter, a qualquer momento, uma foto honesta de onde está cada lead e quantos existem em cada etapa de cada canal. A documentação completa, com o funil, a arquitetura e o roteiro, está em Jornada do Lead (ago/2026).

Fases e fluxos

Nem todo fluxo começa na Descoberta. Formulário e Evento entram direto em Consideração, porque a pessoa já veio até a Luby. O BDR entra em Descoberta e pula a Consideração por desenho. Por isso algumas fases ficam vazias em certos fluxos.

As fases finais (reunião, proposta, contrato) vêm do mesmo motor comercial do HubSpot para todos os fluxos.

Fluxo

1. Entrada outbound: a cada hora, sync-outbound-journey busca em people quem ainda não tem linha em outbound_journey (RPC leads_pending_outbound_journey, lotes de 500, até 20 lotes) e grava o lead em Descoberta, no fluxo de people.flow ou, se vazio, em Outreach.
2. Entrada inbound: a view inbound_leads junta as tabelas de formulários, LPs, eventos e BDR (hoje 11 tabelas de origem). As regras de apply_form_rules colocam esses leads em inbound_journey.
3. Sinais: journey_events guarda eventos que não são de e-mail (reunião, proposta, contrato, ligação atendida, resposta). outreach_signals e email_events trazem aberturas, cliques, respostas, bounces e aceites do LinkedIn. A view all_lead_events junta tudo numa linha do tempo.
4. HubSpot para o Supabase (só leitura):
   • hubspot-sync: deals dos últimos 12 meses em hubspot_leads; apaga os que sumiram do HubSpot.
   • hubspot-deal-contacts-sync: para deals sem empresa, grava empresa, contatos e associações.
   • hubspot-activities-sync: 80 contatos por chamada; reuniões, e-mails recebidos e ligações atendidas viram eventos em journey_events.
   • apply_hubspot_commercial_events(): grava eventos de reunião, proposta e contrato dos deals já em fase comercial (view journey_historical_import).
   • reopen_hubspot_contacts_for_resync(): uma vez por dia, reabre os contatos que batem com leads para nova varredura.
5. Regras: apply-rules-outreach (RPC apply_outreach_rules) e apply-rules-form (RPC apply_form_rules) rodam de hora em hora e inserem uma nova linha de fase quando o lead cumpre a condição. Cada mudança é uma linha nova (histórico).
6. Nutrição: apply_nurture_enrollment() coloca em nurture_audience quem chegou em Engajamento ou além, tem e-mail, não é interno nem concorrente e ainda não está na lista. Roda em paralelo ao funil, sem mudar a fase.
7. Leitura: as views current_journey_outbound e current_journey_inbound dão a fase atual; journey_funnel dá a contagem por fluxo e fase, sem dados pessoais.

Peças

Agendamentos

Regras de negócio

• Cada lead vive em um único fluxo, definido na origem. Só BDR e Outreach aceitam transferência manual.
• Outreach: bounce, reclamação ou descadastro tiram o lead do fluxo (do_not_contact). Abrir ou clicar e-mail de prospecção, ou aceitar convite no LinkedIn, leva a Consideração. Responder, atender ligação ou clicar em newsletter leva a Engajamento. Reunião pula para Intenção; proposta leva a Oportunidade; contrato ganho a Fechamento.
• Formulário e Evento: formulário, LP ou inscrição leva a Consideração; participar ou clicar em newsletter leva a Engajamento; reunião, proposta e contrato seguem como no Outreach.
• BDR: sair de "Novo contato" leva a Descoberta; "Em conversa" a Engajamento; reunião a Intenção.
• Retrato em 08/10/2026: Outreach com 21.218 em Descoberta, 2.686 em Consideração, 765 em Engajamento e 9 nas fases comerciais. Formulário com 362 em Consideração, 34 em Oportunidade e 7 em Fechamento.

Listas de ação

Além de mover de fase, a jornada gera listas vivas a partir do comportamento do lead no Outreach:

• Nutrição: quem está de Engajamento em diante entra numa cadência institucional, sem interno, concorrente nem descadastrado.
• Fila de cold call: quem abriu e-mail 3 vezes ou mais, ou aceitou convite no LinkedIn, separado por mercado (BR e US) para cada BDR puxar a sua parte. Ver Fila do BDR.
• Remarketing comportamental: o grupo morno que alimenta os públicos de anúncio; sai sozinho quando o lead chega em Intenção. Ver Públicos de remarketing.

Quando a pessoa reage a essas ações (atende a ligação, responde), o retorno volta pelo HubSpot e sobe o lead de fase. A Qualificação (o quanto o lead tem o perfil de cliente da Luby) é um eixo separado da fase e está pendente de definição de critérios pelo time.

O que falta

• BDR, Oportunidade e Fechamento: quando um deal BDR vira negócio, ele muda para o funil comercial; o caminho está preparado, mas não foi validado num caso real.
• LinkedIn: marcar a pessoa nos eventos da Unipile para separar conexões pessoais das de prospecção.
• Evento: alimentar event_guests sozinho com inscrição e presença; hoje é importação manual por evento.
• HubSpot: liberar a leitura de e-mails recebidos para reconhecer "respondeu por e-mail" como Engajamento.
• Site: rastrear cliques nas LPs para ligar o fluxo Site.
• Antes do funil: gatilhos de mercado (mudança de emprego, aporte), em pesquisa de viabilidade.
• Dashboard: a aba Jornada foi construída e testada e aguarda acesso de publicação no repositório.

Integrações e credenciais

• HubSpot: HUBSPOT_TOKEN em Edge Function Secrets. Só leitura do HubSpot; nada é escrito lá por estas funções.
• Autenticação dos crons: CRON_SECRET_OUTBOUND_JOURNEY, no Supabase Vault (lido pelos crons) e em Edge Function Secrets (conferido pelas funções). hubspot-sync também aceita CRON_SECRET no header x-cron-secret.
• Todas as Edge Functions da jornada estão com verify_jwt = false; a proteção é o segredo próprio.

Como monitorar

-- Funil por fluxo e fase (sem PII)
select flow_name, stage_order, stage_name, outbound_count, inbound_count, total_count
from public.journey_funnel where total_count > 0 order by flow_name, stage_order;

-- Última transição por regra
select changed_by, count(*), max(created_at) from public.outbound_journey group by 1 order by 3 desc;
select changed_by, count(*), max(created_at) from public.inbound_journey group by 1 order by 3 desc;

-- Saúde dos crons nos últimos 7 dias
select j.jobname, count(*) as execucoes, max(d.start_time) as ultima
from cron.job j join cron.job_run_details d on d.jobid = j.jobid
where (j.jobname like '%journey%' or j.jobname like 'apply-%' or j.jobname like '%hubspot%')
  and d.start_time > now() - interval '7 days'
group by 1 order by 1;

-- Erros das syncs do HubSpot
select function_name, count(*), max(created_at) from public.sync_errors
where created_at > now() - interval '7 days' group by 1;

Observação: o cron registra sucesso mesmo quando a Edge Function responde 500 (a chamada é assíncrona). Para ver o status real, use os logs da função no painel do Supabase.

Como usar

O que pedir ao Claude

• "Como está o funil da Jornada do Lead por fluxo hoje?"
• "Quantos leads mudaram de fase esta semana, e por qual regra?"
• "Em que fase está o lead com o e-mail X?"
• "Quem entrou na lista de nutrição no último mês?"
• "Verifica se as regras da jornada rodaram sem erro nas últimas 24 horas."

Passo a passo

1. Peça o retrato do funil. Ele não mostra dados pessoais e pode ir para relatório.
2. Para um lead específico, peça a fase atual e o histórico de eventos.
3. Se um fluxo parecer parado, peça a última transição por regra e os logs da função.
4. A jornada está sem dono: combine com o time de Growth antes de mudar regra, fase ou fluxo.

Cuidados

• As tabelas da jornada têm dados pessoais. Não exporte listas com e-mail sem combinar com o time de Growth.
• Não mova lead de fase "na mão" sem registrar changed_by e motivo.
• Enquanto apply-rules-outreach responder com erro, os números de Outreach acima de Descoberta não avançam.

Fontes

• Supabase nearsmart, leitura em 08/10/2026: journey_stages, flows, journey_funnel, outbound_journey, inbound_journey, journey_events, flow_transitions, inbound_leads, nurture_audience, hubspot_leads, hubspot_contacts, hubspot_companies, hubspot_deal_contacts, sync_errors, cron.job, cron.job_run_details
• Funções SQL lidas: apply_outreach_rules, apply_form_rules, apply_outreach_* (exit, discovery, bypass), apply_nurture_enrollment, apply_hubspot_commercial_events, reopen_hubspot_contacts_for_resync
• Edge Functions lidas: sync-outbound-journey, apply-rules-outreach, apply-rules-form, hubspot-sync, hubspot-deal-contacts-sync, hubspot-activities-sync, sync-hubspot
• Logs de Edge Functions do Supabase (janela de 24 h até 08/10/2026)
• Jornada do Lead: documentação de negócio e técnica (ago/2026)
• hubspot-sync no repo do dashboard

Pipeline de agentes de IA que escolhe o tema, pesquisa, escreve, revisa, ilustra e publica artigos direto no WordPress dos blogs da Luby, sem aprovação prévia. Está no ar: publica em 4 blogs com assinatura dos autores cadastrados em publishers, com 193 artigos publicados e 38 nos últimos 30 dias.

Como funciona

O squad roda no Opensquad, framework que monta "squads" de agentes de IA dentro do Claude Code: cada squad tem squad.yaml, pipeline.yaml com os steps, um .agent.md por agente e uma pasta _memory. O Pipeline Runner executa os steps em ordem e só para em checkpoints, que este squad não tem. Comando: /opensquad run blog-luby-auto.

Fluxo

1. Tobias lista os publishers com active = true por canal. Canal sem publisher ativo fica fora da rodada.
2. Tobias olha a fila de cada canal. Artigo de publisher desativado é reatribuído a outro publisher ativo do mesmo canal.
3. Canal sem fila ganha 1 tema novo, pesquisado nas fontes do canal e inserido em articles.
4. Tobias pega o artigo mais antigo de cada canal (1 por canal) e grava article-queue.json.
5. Mateus pesquisa como subagente: mínimo de 5 fontes verificadas e 3 ângulos.
6. Lara escreve em HTML de blocos do WordPress (Gutenberg), no idioma e no tom (flavor) do publisher.
7. Pedro revisa precisão, fontes, HTML, SEO e idioma. Se vetar, corrige até 2 vezes e depois segue com aviso.
8. Iris escolhe a foto no Unsplash (buscas em inglês) e prepara a legenda com crédito ao fotógrafo.
9. Ada sobe a imagem destacada, publica o post com autor e categoria e confere com um GET que o post certo foi ao ar.
10. Ada atualiza articles (content, sources, approved = true, wp_url, published_at) e chama blog-approval em modo notification: e-mail "Novo artigo publicado" para Estela, Karime, Rodrigo e o publisher.

Peças

Agendamentos

A tarefa é uma rotina agendada do claude.ai na conta compartilhada do Growth, ativa desde 04/05/2026. Não há job no cron.job do Supabase para o blog.

Regras de negócio

• Exatamente 1 artigo por canal por rodada.
• Só publisher com active = true participa. Ligar e desligar publisher é decisão humana, feita direto no Supabase; nenhum agente escreve nessa coluna.
• Foco por canal: blog_luby, blog_nearsmarter e blog_luby_us cobrem tecnologia geral; blog_finfy só tecnologia aplicada a serviços financeiros, com fontes fintech.pt-br.
• Fila pendente é content IS NULL AND approved = false. Filtrar só por content nulo pega artigos já publicados (erro da rodada de 24/09/2026).
• Post não pode passar de max_words em mais de 20%. Dado que não está na pesquisa é removido.
• Em canal PT-BR, o CTA aponta para luby.com.br, nunca para luby.co.
• Quando a pesquisa contradiz o título da fila, vale a pesquisa (o título é ajustado).

Integrações e credenciais

• WordPress REST API de cada blog: Basic Auth com Application Password do publisher, guardada na tabela publishers. Nunca selecione essa coluna em consultas.
• Supabase: supabase_url e supabase_anon_key em pipeline/data/supabase-config.json.
• Zoho SMTP: zoho_user, zoho_pass, from_name, notification_emails, edge_function_url e media_uploader_url em pipeline/data/smtp-config.json.
• Unsplash API: chave de acesso na configuração do squad.

Como monitorar

-- publicações por canal nos últimos 30 dias
select p.channel, count(*) as publicados, max(a.published_at) as ultimo
from articles a join publishers p on p.id = a.publisher
where a.approved and a.published_at > now() - interval '30 days'
group by p.channel order by p.channel;

-- fila pendente (deve ter no máximo alguns itens)
select a.id, a.title, p.channel, a.created_at
from articles a left join publishers p on p.id = a.publisher
where a.content is null and a.approved = false
order by a.created_at;

-- publishers ativos por canal (sem a coluna de senha)
select channel, count(*) filter (where active) as ativos, count(*) as total
from publishers group by channel order by channel;

Também vale ler squads/blog-luby-auto/_memory/runs.md: cada rodada deixa uma linha com temas, canais e resultado.

Como usar

O que pedir ao Claude

• "Rode o squad blog-luby-auto agora."
• "Quantos artigos o blog automático publicou nos últimos 30 dias, por blog?"
• "Coloque na fila do blog Finfy o tema 'Pix Automático para empresas', com até 1.000 palavras, assinado pela publisher X."
• "O post de hoje no blog.luby.co saiu sem imagem destacada. Descubra o motivo."

Passo a passo

1. Para sugerir um tema, peça ao Claude para incluir na fila com título, instruções, limite de palavras e o publisher (autor) desejado.
2. Espere a próxima terça ou quinta. O artigo mais antigo da fila de cada blog é o que sai.
3. Confira o e-mail "Novo artigo publicado", com o link do post. Se vier o aviso amarelo, a revisão automática encontrou problemas.
4. Abra o post e leia. Se houver erro, apague ou edite no WordPress e avise o Claude para corrigir o registro em articles.
5. Para tirar um autor da rotação, peça a quem administra o Supabase para marcar o publisher como inativo.

Cuidados

• Não existe etapa de aprovação: o que entra na fila vai ao ar.
• Escreva as instruções do tema só com datas e números que a fonte confirma.
• Nunca cole senha de WordPress no chat; credencial nova é cadastrada direto no Supabase.
• Um tema por blog: não coloque o mesmo assunto em dois blogs do mesmo idioma.

Fontes

• squad.yaml
• pipeline.yaml
• GUIDE.md
• step-00-scout-and-pick.md
• step-05-send-email.md
• tobias.agent.md
• ada.agent.md
• sources.json
• memories.md
• runs.md
• README do Opensquad
• runner.pipeline.md
• Edge functions do projeto nearsmart (blog-approval, wp-publisher, wp-media-uploader)
• Supabase nearsmart: tabelas articles, publishers, prompts, topics e cron.job (consulta de leitura em 08/10/2026)

Dois squads de agentes de IA escrevem conteúdo de LinkedIn na voz de cada colaborador da Luby: posts curtos (squad ghostwriter-linkedin-auto) e artigos longos (squad ghostwriter-linkedin-article). Está no ar, roda sob demanda e atende 22 colaboradores ativos; o texto chega por e-mail e o próprio colaborador publica, manualmente.

Como funciona

Os dois squads rodam no Opensquad, framework que monta squads de agentes dentro do Claude Code (um squad.yaml, um pipeline.yaml com os steps, um .agent.md por agente e uma pasta _memory). O Pipeline Runner executa os steps em ordem e não há checkpoints: rodam do começo ao fim sem intervenção. Cada step processa a fila inteira de colaboradores antes de passar ao próximo.

Fluxo (posts, squad auto)

1. Lucas carrega de collaborators só quem tem active = true e loga quem está pausado. Fila vazia aborta a rodada.
2. Lucas escolhe o tema (flavor) de cada um cruzando collaborators.topics com as 41 buscas de related_searchs.
3. Marco pesquisa o tema na web, como subagente.
4. Sofia destila o perfil de voz (postura, cadência, vocabulário) e lista as aberturas usadas nos últimos ~3 posts, para não repetir.
5. Bruno escreve o post em EN a partir de um write-brief.md com alvo de tamanho (padrão 900 caracteres, teto 1.100).
6. Otávio faz a crítica editorial: regras duras mais nota de 1 a 5. Se reprovar, devolve um brief refinado e o post é reescrito do zero, até 3 vezes.
7. Bruno traduz para PT-BR quando language inclui pt-br.
8. Helena revisa fatos e engajamento, com até 2 correções automáticas.
9. Pedro remove marcas de texto de IA (skill humanizer e cliches-blocklist.md); só aprova com nota 8.0 e a lista de clichês limpa.
10. Lucas sorteia 2 colaboradores para receber vídeo, sem repetir quem já recebeu (video_rotation_linkedin).
11. Cleidim gera o vídeo no projeto Remotion luby-video-machine (30 s, 1920x1080, só música de fundo, sem narração) e sobe no bucket linkedin-ghostwriter-videos.
12. Diana escolhe uma foto no Unsplash (1 por colaborador, serve aos dois idiomas) e sobe em linkedin-ghostwriter-images.
13. Lucas gera dicas de melhoria do perfil LinkedIn e grava em collaborators.linkedin_improvement.
14. Lucas grava 1 linha por idioma em bloggers (content, image_url, video_url, submitted_content = false).
15. Lucas chama blog-approval em modo linkedin-post: e-mail "Seu post LinkedIn está pronto" só para o colaborador, com post(s), imagem, botão de download do vídeo e dicas de perfil. Depois marca submitted_content = true.
16. Bruno fecha a rodada e atualiza output/post-history.json (aberturas, fotos usadas, notas).

Fluxo (artigos, squad article)

1. Mesma base: carga de colaboradores, pesquisa (mais profunda), persona, escrita em EN, tradução, revisão e humanização.
2. O artigo tem de 1.500 a 2.000 palavras: título, introdução, 3 a 5 seções, conclusão e CTA.
3. Diana gera a capa 1200x627 no Gemini (Nano Banana Pro) via Playwright e sobe no bucket linkedin-ghostwriter-article-images. A capa segue o framework estético do agente Diana Arte, com três registros: editorial cinematográfico, 3D escultural isométrico e dashboard de KPI.
4. Lucas grava EN e PT-BR em bloggers com a mesma capa e envia o e-mail em modo linkedin-article, com os dois idiomas, a capa e o guia de imagem.

Peças

Agendamentos

Não há job no cron.job do Supabase. A tarefa agendada ghostwriter-linkedin-auto do claude.ai (terças às 10:00 BRT, cron 0 13 * * 2 UTC) existe na conta compartilhada, mas está desligada. A geração é feita sob demanda, quando alguém pede.

Regras de negócio

• Só entra quem tem active = true. Pausar não apaga a persona.
• language decide os idiomas: hoje 14 ativos só PT-BR, 6 só EN e 2 bilíngues.
• Voz de "alguém explicando para um colega": primeira pessoa, abertura pela coisa em si, sem fecho de aforismo, fonte citada dentro da frase.
• Proibido no post: "Luby" no corpo, emoji, link no corpo, hashtag no meio (máximo 5, só no fim), travessão.
• Para a Maise, nunca falar de nearshore, outsourcing ou custo.
• Vídeo: 2 por rodada; só conta como recebido o status uploaded.
• A mesma foto nunca se repete para o mesmo colaborador.
• O e-mail vai só para o próprio colaborador. A publicação no LinkedIn é sempre manual.

Integrações e credenciais

• Supabase: supabase_url e supabase_anon_key em pipeline/data/supabase-config.json de cada squad.
• Zoho SMTP: zoho_user, zoho_pass, from_name, notification_emails, edge_function_url em pipeline/data/smtp-config.json.
• Unsplash API: chave na configuração do squad auto.
• Gemini (só no squad de artigos): sessão do Google no navegador do Playwright. A confirmar: qual conta.
• Remotion: renderização local com Node (npx remotion render, limite de 480 s por vídeo).

Como monitorar

-- lotes gerados e enviados
select created_at::date as dia, count(*) as posts,
       count(distinct collaborator_id) as colaboradores,
       count(*) filter (where submitted_content) as enviados,
       count(*) filter (where video_url is not null) as com_video
from bloggers group by 1 order by 1 desc limit 10;

-- colaboradores ativos por idioma
select language, count(*) from collaborators where active group by 1;

-- rotação de vídeo
select status, language, count(*), max(generated_at)
from video_rotation_linkedin group by 1, 2;

Como usar

O que pedir ao Claude

• "Rode o ghostwriter de posts do LinkedIn para todos os colaboradores ativos."
• "Rode o ghostwriter de artigos longos só para o Rodrigo."
• "Pause o colaborador X no ghostwriter" (marca active = false).
• "Cadastre a nova colaboradora Y no ghostwriter: cargo, temas, idioma e tom."
• "Quem recebeu vídeo nas últimas rodadas?"
• "Quantos posts foram gerados e enviados no último lote?"

Passo a passo

1. Para entrar no ghostwriter, o colaborador precisa de uma linha completa em collaborators, com e-mail, temas, idioma e tom.
2. Peça ao Claude para rodar o squad; não há rodada agendada.
3. O colaborador recebe o e-mail com o post em cada idioma, a imagem sugerida e, se sorteado, o botão para baixar o vídeo.
4. Ele revisa, ajusta o que quiser, copia o texto e publica no LinkedIn. Vídeo é baixado e postado como vídeo nativo.
5. As dicas de perfil no fim do e-mail são opcionais.

Cuidados

• O texto é sugestão: o colaborador deve ler antes de publicar, principalmente números e experiências pessoais.
• Não cole o mesmo post em duas contas.
• Para tirar alguém da rodada, pause; não apague a linha.

Fontes

• squad.yaml do ghostwriter-linkedin-auto
• pipeline.yaml do ghostwriter-linkedin-auto
• GUIDE.md do ghostwriter-linkedin-auto
• memories.md do ghostwriter-linkedin-auto
• runs.md do ghostwriter-linkedin-auto
• step-09-send-email.md
• step-05c-video-selection.md
• step-05d-video-generation.md
• step-06-image-suggestion.md
• squad.yaml do ghostwriter-linkedin-article
• step-06-image-prompt.md do squad de artigos
• README do luby-video-machine
• README do Opensquad
• Edge function blog-approval
• Supabase nearsmart: tabelas collaborators, bloggers, related_searchs, video_rotation_linkedin, storage.buckets e políticas de RLS (consulta de leitura em 08/10/2026)

Linha de produção de vídeos técnicos para o YouTube da Luby, que combina cenas geradas por IA no Higgsfield, cenas animadas em Remotion e narração sintética. Está em teste: foram 8 vídeos de teste em maio/2026 com o Higgsfield, e o repositório da futura automação ainda está vazio.

Como funciona

Ainda não existe automação em produção. O que existe são testes manuais guardados no Drive e um repositório criado em 26/06/2026 sem nenhum arquivo. A descrição do repositório resume o desenho alvo: um squad de agentes no Claude Code que produz vídeos técnicos passando por estratégia, roteiro, storyboard, render em Remotion, narração ElevenLabs, trilha de fundo e thumbnail.

Fluxo

Fluxo usado nos testes, segundo o relatório de 26/06/2026 e os arquivos do Drive:

1. Roteiro do vídeo (narração), com título e descrição.
2. Cenas com pessoas e ambientes geradas no Higgsfield, com o modelo Kling 3.0 Turbo ou Seedance 2.0.
3. Cenas de conceito, diagramas, números e textos animados em Remotion, sem custo de crédito.
4. Narração por texto para fala no ElevenLabs.
5. Montagem em Remotion com vinheta, overlays e trilha de fundo (BGM). Formato dos testes: cerca de 60 s, 16:9, 720p.
6. Pacote de publicação: thumbnail, título com 2 alternativas A/B, descrição e tags (exemplo no doc "[THUMB + DESCRIÇÃO] IA agêntica: o segredo não é o modelo, é o loop").
7. Vídeo final e thumbnail salvos na pasta do episódio no Drive.

A confirmar: quanto desse fluxo é feito à mão e quanto já roda com agentes.

Peças

Regras de negócio

• Conclusão do relatório de testes: o híbrido é o melhor custo-benefício. Usar geração por IA só onde precisa de textura humana ou ambiente; conceito e dados vão para o Remotion, que não gasta crédito.
• Custo por vídeo de cerca de 60 s, contando 1 geração por cena e sem refações: Kling cerca de 88 créditos, Seedance cerca de 185, Híbrido (3 cenas Seedance e 3 Remotion) cerca de 94.
• Seedance entrega mais qualidade e consistência; Kling é 2,3 vezes mais barato por segundo gerado.
• Pela skill de roteiro, vídeo técnico tem de 1:30 a 4:00 de narração; o teto é 4 minutos.

Integrações e credenciais

• Higgsfield: conta no plano Plus. O Claude desta conta tem um conector Higgsfield disponível. A confirmar: de quem é a conta e onde fica o acesso.
• ElevenLabs: custo da voz é separado dos créditos do Higgsfield. A confirmar: conta e plano.
• Nenhuma credencial deste projeto está no Supabase nem no GitHub.

Como monitorar

• Abrir as pastas do Drive e conferir a data do último vídeo final e da thumbnail.
• Pedir ao Claude o saldo de créditos do Higgsfield antes de começar um vídeo novo.
• Quando o repositório luby-youtube-machine receber código, acompanhar os commits.

Como usar

O que pedir ao Claude

• "Escreva o roteiro de um vídeo técnico de 3 minutos para o YouTube sobre context window, em PT-BR."
• "Gere título com 2 alternativas A/B, descrição e tags para o vídeo sobre function calling."
• "Quantos créditos do Higgsfield ainda temos este mês?"
• "Liste os vídeos de teste da pasta Máquina de Vídeos e as datas."
• "Com base no relatório de testes, quanto custaria um vídeo de 2 minutos no modelo híbrido?"

Passo a passo

1. Combine o tema com o Cleidson, que é o dono do projeto.
2. Peça o roteiro ao Claude (skill luby-video-scriptwriter) e revise os dados técnicos.
3. O Cleidson define quais cenas vão para o Higgsfield e quais para o Remotion, gera a narração e monta o vídeo.
4. Revise o vídeo com olhar de público técnico: termos, números, pronúncia.
5. Prepare thumbnail, título, descrição e tags e salve tudo na pasta do episódio em "Vídeos YouTube".

Cuidados

• Créditos do Higgsfield são limitados: planeje as cenas antes de gerar.
• Os vídeos da pasta Testes são testes, não versões para publicar.
• Não prometa cadência de publicação enquanto o projeto estiver em teste.

Fontes

• Máquina de Vídeos (YOUTUBE)
• Testes
• Higgsfield
• relatorio-3-testes-video.pdf
• Doc THUMB + DESCRIÇÃO, IA agêntica
• Vídeos YouTube
• luby-youtube-machine
• README do luby-video-machine
• Skill luby-video-scriptwriter (SKILL.md, sincronizada na conta)

Robô que acompanha, a cada 2 horas, se as páginas dos sites e blogs da Luby estão indexadas no Google e por que as que faltam não entraram. Está no ar, monitora 2.089 URLs e manda um relatório diário no Discord. Ele não força indexação: mostra onde agir.

Como funciona

Fluxo

1. O pg_cron chama a edge function index-bot a cada 2 horas, com o header x-bot-secret.
2. O robô gera um token OAuth2 com a service account do Google e lista as propriedades do Search Console em que ela é Owner ou Full user (sites.list).
3. Descoberta: para cada propriedade, a Search Analytics API lista as páginas que o Google já mostrou na busca nos últimos 180 dias; URLs novas entram em indexing_urls como pending.
4. Seleção híbrida: em cada ciclo de 10, 7 vêm das páginas acionáveis (not_indexed, blocked, error, pending) checadas há mais tempo e 3 da rotação geral, que revisita as indexadas para pegar página que caiu do índice.
5. A URL Inspection API inspeciona as páginas, 5 em paralelo, até 110 s por execução (cerca de 75 a 80 URLs).
6. O resultado vira um status de ação e é gravado com notes (o coverageState do Google), last_response completo, last_checked_at e error_streak.
7. Push (experimento ligado): pede recrawl pela Indexing API para até 10 URLs not_indexed por dia, só em propriedades onde a service account é Owner, nunca repetindo URL empurrada há menos de 21 dias.
8. Uma vez por dia, index-report chama indexing_report_json() e posta no Discord: totais por status, indexadas por propriedade, URLs em erro e o placar do push.

Peças

Agendamentos

Regras de negócio

O status é o tipo de ação possível:

• Cor do relatório: verde sem erro e com execuções em dia; amarelo se a última checagem tem mais de 3 horas ou há erro recente; vermelho só para erro persistente (mesma URL falhando há mais de 2 checagens seguidas).
• Para incluir uma propriedade, basta adicionar o e-mail da service account nela no Search Console; o robô a pega na próxima execução.

Integrações e credenciais

• Google Search Console API (URL Inspection, Search Analytics, lista de sites) e Indexing API, via service account.
• Edge Function Secrets: GOOGLE_SA_EMAIL, GOOGLE_SA_PRIVATE_KEY, GSC_SITE_URL, PUSH_ENABLED, BOT_SHARED_SECRET, DISCORD_WEBHOOK_URL, mais os ajustes opcionais BATCH_SIZE, CONCURRENCY, TIME_BUDGET_MS, PRIORITY_PER_CYCLE, ROTATION_PER_CYCLE, AUTODETECT_PROPERTIES, EXCLUDE_PROPERTIES, DISCOVER_ENABLED, DISCOVERY_LOOKBACK_DAYS, PUSH_DAILY_LIMIT, PUSH_COOLDOWN_DAYS, PUSH_PROPERTIES e STALE_HOURS.
• Supabase Vault: index_bot_secret, usado pelos crons no header x-bot-secret.
• SUPABASE_URL e SUPABASE_SERVICE_ROLE_KEY são injetados pelo Supabase. As funções são publicadas sem verificação de JWT e fazem a própria checagem.
• A confirmar: em qual canal do Discord o relatório chega.

Como monitorar

Retrato de 08/10/2026, 09:00 BRT:

-- o mesmo JSON que vai para o Discord
select public.indexing_report_json();

-- situação por propriedade
select site_url, status, count(*)
from indexing_urls group by 1, 2 order by 1, 2;

-- últimas execuções dos crons
select j.jobname, d.status, d.start_time
from cron.job_run_details d join cron.job j on j.jobid = d.jobid
where j.jobname in ('daily-index-bot', 'daily-index-report')
order by d.start_time desc limit 20;

-- candidatas a Request Indexing manual
select url, site_url, notes, last_checked_at
from indexing_urls where status = 'not_indexed'
order by last_checked_at nulls first limit 20;

Como usar

O que pedir ao Claude

• "Como está a indexação dos blogs hoje?"
• "Liste as 10 páginas não indexadas mais antigas do blog.nearsmarter.com para eu pedir indexação manual."
• "Por que a URL X não está indexada?"
• "O relatório de indexação no Discord veio amarelo. O que aconteceu?"
• "Quantas páginas empurradas pelo push acabaram indexadas?"

Passo a passo

1. Leia o relatório diário no Discord, por volta das 23:30.
2. Verde: nada a fazer. Amarelo: peça ao Claude para checar se as execuções pararam. Vermelho: há URL falhando repetidamente; peça o diagnóstico.
3. Para as páginas "a indexar", abra o Search Console e use "Request Indexing" (cerca de 10 a 12 por dia) e crie links internos a partir do luby.co.
4. Páginas bloqueadas precisam de ajuste técnico no site; páginas sem solução saem do sitemap.
5. Para monitorar um site novo, adicione o e-mail da service account na propriedade do Search Console.

Cuidados

• O robô não indexa nada sozinho; o efeito vem das ações manuais e do conteúdo.
• Não aumente o limite do push sem combinar com o time.
• Mudanças em secrets e crons são feitas no Supabase, não no GitHub.

Fontes

• README.md
• FLUXO.md
• sql/01_schema.sql
• sql/02_report_function.sql
• sql/03_cron.sql
• supabase/functions/index-bot/index.ts
• supabase/functions/index-report/index.ts
• Histórico de commits
• Supabase nearsmart: cron.job, cron.job_run_details e tabela indexing_urls (consulta de leitura em 08/10/2026)

Rotina semanal, a ser construída como skill do Claude, que vai perguntar a vários modelos de IA, via OpenRouter, quais empresas eles recomendam em buscas de compra, e registrar se a Luby aparece, em que posição e ao lado de quais concorrentes. Está em construção: o card foi iniciado em 25/09/2026 e ainda não existe skill, tabela nem agendamento.

Como funciona

Nada desta seção roda hoje. O que está abaixo é o desenho proposto no card, que nasceu no Growth Planning de 25/09/2026. Nas falas registradas no card, o Rodrigo propõe usar o OpenRouter para monitorar as buscas em LLMs, ver se a Luby começa a aparecer e quais concorrentes surgem, montar um ranking associando cada resposta à pergunta e colocar isso como skill no Claude para rodar toda semana. A Karime dá o exemplo de pergunta: "as dez melhores empresas de software".

Fluxo

Proposto, ainda não implementado:

1. Uma lista de perguntas com intenção de compra, como "top 10 software companies".
2. Uma vez por semana, a skill dispara cada pergunta em vários modelos pelo OpenRouter.
3. Para cada resposta, registra se a Luby aparece, em que posição e quais concorrentes foram citados.
4. As respostas são associadas às perguntas e viram um ranking.
5. O ranking alimenta a discussão de estratégias para a Luby aparecer mais em IA generativa.

Peças

Agendamentos

Regras de negócio

O card define três medidas por resposta: presença da Luby, posição e concorrentes citados. O resto ainda está aberto:

• A confirmar: quais perguntas, em quais idiomas e para quais mercados (EN para os EUA, PT-BR para o Brasil).
• A confirmar: quais modelos entram e quantas vezes cada pergunta é repetida por semana.
• A confirmar: se as chamadas pelo OpenRouter terão busca na web ligada. A skill seo-geo-audit testa citação com busca ligada (ChatGPT em modo Search, Claude com ferramentas web, Perplexity).
• A confirmar: onde ficam os resultados e quem recebe o relatório.

Integrações e credenciais

• OpenRouter: a chave de API ainda não está em nenhum lugar conhecido. A confirmar: conta, orçamento e onde a chave vai morar (Edge Function Secrets, Vault ou configuração local da skill).
• Anexo do card "Luby Gap Analysis.pdf" (25/09/2026). A confirmar: se é o material do fornecedor de referência.

Relação com a skill seo-geo-audit

• A seo-geo-audit já existe e faz auditoria de um site: SEO técnico, schema, robots, métodos de GEO e ajustes por plataforma (Google AI Overviews, ChatGPT, Perplexity, Copilot, Claude). Ela diz o que corrigir.
• A própria skill afirma que o teste definitivo de GEO é perguntar aos modelos se citam o domínio. O monitoramento vai automatizar essa medição toda semana, com perguntas de compra em vez de perguntas sobre a marca.
• Uso combinado: o monitoramento mostra a posição; a auditoria explica por quê e o que mudar.

Como monitorar

Por enquanto, pelo próprio card no Trello (lista, checklist e anexos).

Como usar

O que pedir ao Claude

Hoje:

• "Mostre o status do card de monitoramento GEO no Trello."
• "Rode a auditoria SEO/GEO do luby.co."
• "Quais são as 10 melhores empresas de desenvolvimento de software para fintechs nos EUA? Diga se a Luby aparece e quais concorrentes você citou."

Depois que a skill existir (previsto, ainda não funciona):

• "Rode o monitoramento GEO da semana."
• "Compare a posição da Luby nas últimas 4 semanas e liste os concorrentes que mais aparecem."

Passo a passo

1. Acompanhe o card no Trello para saber quando a skill ficar pronta.
2. Até lá, para ter uma leitura pontual, rode a seo-geo-audit ou faça perguntas de compra direto ao Claude e anote o resultado.
3. Leve as perguntas que importam para o negócio à Karime: elas vão compor a lista oficial da rotina.

Cuidados

• Uma resposta isolada de um modelo não é ranking; espere a série semanal.
• Não confunda esta rotina com a auditoria: uma mede, a outra diagnostica.

Fontes

• Card Trello: Skill de monitoramento GEO via OpenRouter (descrição, anexos e atividade)
• Skill seo-geo-audit (SKILL.md, sincronizada na conta)
• Supabase nearsmart: information_schema.tables (consulta de leitura em 08/10/2026, sem tabelas de GEO)

Plugin do Claude com 10 skills para ler, diagnosticar, auditar e operar a conta Google Ads da Luby (5929844041) em qualquer formato: Search, Display, Video e Performance Max. Está no ar, na versão 0.2.0, e só escreve na conta com aprovação humana explícita.

Como funciona

Fluxo

1. Qualquer skill do plugin carrega primeiro a account-conventions (conta, padrão de nomes, inventário, tom de voz).
2. Antes de consultar ou mudar algo, carrega a credentials-and-access.
3. Confirma o tipo da campanha pelo campo campaign.advertising_channel_type. O prefixo do nome é só convenção.
4. Lê os dados por GAQL, por um de dois caminhos:
   • conector MCP google-ads-mcp (ferramenta search_search), preferido quando conectado;
   • script scripts/gaql.py, que usa a credencial embutida e devolve JSON (customer_id padrão 5929844041, troca com --customer-id).
5. Analisa com a lente do tipo de campanha e aponta um gargalo entre cinco: orçamento/entrega, segmentação, criativos, landing page ou rastreamento.
6. Entrega recomendações no formato de aprovação (Karime ou Gardin).
7. Se aprovado, escreve pela API direta: script Python com a biblioteca google-ads carregando google-ads.yaml, na ordem validate_only=True, mutate real e releitura. A releitura deve ir por outro caminho (escreve pelo Python, confere pelo MCP).
8. Registra cada mudança em logs/test-log.md com hipótese, baseline e data de avaliação (14 dias depois).

Peças

Agendamentos

Nenhuma rotina agendada. O weekly-review foi desenhado para toda segunda-feira, mas roda quando alguém pede: não há rotina dele na lista do claude.ai lida em 08/10/2026.

Regras de negócio

• Moeda BRL e fuso America/Sao_Paulo. cost_micros / 1e6 dá reais, inclusive nas campanhas [US]. Nunca reportar com "$".
• AW-1068701977 é o ID de conversão, não o customer_id.
• Padrão de nomes: [TIPO] | [Serviço] [Geo]. Prefixos PM |, SEARCH |, DISPLAY |, VIDEO |. Geo [US] = inglês americano e landing.luby.co; [BR] = PT-BR e landing.luby.com.br.
• Nunca misturar idiomas numa campanha. Ativo em PT-BR numa campanha US (ou o contrário) é problema crítico.
• As cerca de 155 campanhas legadas (Search BR de 2018 a 2023 e PMax antigas) ficam fora das revisões, salvo pedido.
• Cada tipo tem sua lente: Search e PMax por parcela de impressões; Display por CPM e visibilidade; Video por taxa de visualização, CPV e quartis, nunca por CPA de último clique.
• Orçamento: Lost IS (Budget) acima de 40% indica restrição de orçamento; Lost IS (Rank) acima de 20% indica rank. Faixas: conservadora +10 a 15%, moderada +20 a 30%, agressiva +50% com aprovação do Gardin.
• Criativos: avaliar após 2 semanas. "Best" não se mexe; "Low" ganha 2 ou 3 alternativas. RSA de Search deve ter 8 a 15 headlines e 3 a 4 descriptions.
• Copy: headline 30 caracteres, long headline 90, description 90, sitelink 25, callout 25. Sem exclamação e sem "best in class".
• Testes: uma variável por vez, avaliação após 2 semanas.
• Negativas: padrão EXACT. PHRASE só para marca ou produto de terceiro; PHRASE em termo genérico como "outsourcing" bloquearia a campanha de Outsourcing inteira.
• Cadência: revisão semanal (segunda), auditoria de criativos quinzenal, segmentação mensal, conta inteira trimestral.

Integrações e credenciais

• Leitura pelo conector google-ads-mcp: credencial OAuth em C:\Users\karime-luby\.google-ads\credentials.json, só com o trio OAuth (o developer token vem do servidor). O caminho é fixo no conector.
• Leitura e escrita pela API: arquivo google-ads.yaml, com developer_token, client_id, client_secret e refresh_token (escopo adwords). É a mesma credencial OAuth do MCP, em outro formato.
• GA4 e GTM só leitura: ga4-gtm-service-account.json, escopos analytics.readonly e tagmanager.readonly. Conta GA4 92196311 (propriedades Luby BR 273661637, Luby US 331136284, landing.luby.co 530755203, landing.luby.com.br 542377100, finfy 543337794). Conta GTM 6002513277. Mudanças em GA4 e GTM são feitas pela Karime na interface.
• Ambiente da escrita: Python 3.12 do perfil do usuário na máquina da Karime (não o do Git Bash), google-ads 31.4.0.

Como monitorar

• Abrir logs/test-log.md e checar testes com "Avaliar em" vencido. Em 28/08/2026 havia 3 testes aguardando aprovação (T-003, T-006, T-007).
• Rodar o weekly-review na segunda. Consulta base do passo inicial (GAQL, não SQL do Supabase):

SELECT campaign.name, campaign.advertising_channel_type, campaign.status, metrics.cost_micros, metrics.conversions
FROM campaign
WHERE campaign.status = 'ENABLED' AND segments.date DURING LAST_7_DAYS
ORDER BY metrics.cost_micros DESC

Como usar

O que pedir ao Claude

• "Como está a campanha SEARCH AI Senior Squads CTO US nos últimos 7 dias?"
• "O CPA da campanha Outsourcing BR disparou, investiga o que aconteceu."
• "Audita os anúncios da campanha Legacy Software BR e sugere substitutos para os fracos."
• "Minera os termos de pesquisa dos últimos 30 dias e me traz as negativas sugeridas."
• "Vale aumentar o orçamento da campanha de Outsourcing BR?"
• "Roda a revisão semanal do Google Ads."

Passo a passo

1. Abra uma sessão do Claude com o plugin luby-google-ads-toolkit ativo. Para leitura direta, o conector Google Ads precisa estar ligado (hoje ele roda no computador da Karime).
2. Peça em linguagem natural, citando a campanha e o período.
3. Confira se o Claude identificou o tipo certo de campanha antes de ler os números.
4. Leia o resultado: resumo, gargalo e ações em ordem de prioridade.
5. Para qualquer mudança, responda "sim" explicitamente para cada lote. O Claude valida, aplica e relê.
6. Peça o registro no test-log e volte em 2 semanas.

Cuidados

• Nada muda na conta sem aprovação explícita. Campanhas novas nascem pausadas.
• Valores sempre em reais, inclusive nas campanhas US.
• As PMax estão pausadas de propósito. Reativar é um relançamento (o aprendizado recomeça).

Fontes

• luby-google-ads-toolkit/.claude-plugin/plugin.json e .gitignore (plugin sincronizado no claude.ai)
• luby-google-ads-toolkit/skills/*/SKILL.md (as 10 skills)
• luby-google-ads-toolkit/scripts/gaql.py
• luby-google-ads-toolkit/logs/test-log.md
• Memória do robô de negativação

Skill do Claude que transforma a copy ou a URL de uma landing page em todos os textos e sinais de uma campanha Google Ads, prontos para colar na interface. Foi construída com instruções do Rodrigo Gardin e está no ar.

Como funciona

Fluxo

1. O Claude pede uma entrada, nesta ordem de preferência: a copy da landing page (colada ou anexada), a URL ou um brief curto (negócio, oferta, público).
2. Pede também o nome da campanha, o idioma dos anúncios (padrão: inglês americano) e o modo de entrega: passo a passo ou tudo de uma vez. Se o modo não vier, pergunta antes de seguir.
3. Extrai a inteligência da marca e documenta antes de escrever: oferta, público, diferenciais, dores, CTAs da página e provas (números, credenciais, certificações). Nada fora da página entra.
4. Gera os 7 ativos da tabela abaixo, com contagem de caracteres em cada opção.
5. Para os sitelinks, pergunta qual site usar (ex.: luby.co), faz busca na web para mapear as páginas reais (menu, rodapé, serviços, contato) e só usa URLs que existem. Se faltar uma página relevante, avisa e sugere criar.
6. Entrega:
   • modo passo a passo: um ativo por vez, perguntando se pode seguir ou se há ajustes;
   • modo tudo de uma vez: uma resposta com 7 seções na ordem fixa (o que torna o serviço único, produtos/serviços, headlines, long headlines, descriptions, sitelinks, search themes).

Peças

Ativos gerados:

Regras de negócio

• Inglês americano por padrão, salvo pedido.
• Nenhuma afirmação inventada: só o que está na página ou no brief.
• Limite de caracteres é rígido. Opção que passa do limite é sinalizada, nunca cortada em silêncio. Perto do limite, arredonda para baixo.
• Sem frases genéricas ("best in class", "industry leading", "cutting edge"), a menos que estejam na página.
• Foco em intenção de compra e no tom da página.
• Headlines: ângulos variados (benefício, dor, credibilidade, CTA, urgência), sem caixa alta, sem repetição, cada uma de pé sozinha, porque o Google combina as peças.
• Texto "o que torna único": estrutura gancho, problema, abordagem, diferenciais, resultado e fechamento, com os diferenciais em negrito.
• Descriptions cobrem 5 pilares: base/produto, processo, migração/entrega, custo/ROI, operação/suporte.
• Search themes são sinais de público para Performance Max (afetam Search, Display, YouTube e Gmail). Organizados em 4 grupos de intenção: contratar ou encontrar, serviço específico, plataforma mais dor, comparação ou validação.
• Search themes proibidos: termo genérico de plataforma sem intenção de serviço, jargão interno, consulta informativa, quase duplicatas e termos amplos demais. Teste final de cada tema: "quem busca exatamente isso provavelmente contataria um fornecedor?". Se não, sai.
• Casos de borda: URL inacessível pede a copy colada; copy curta pede mais contexto; página em outro idioma pede confirmação do idioma dos anúncios; página com vários serviços pede o foco principal.

Integrações e credenciais

Nenhuma. A skill não acessa a conta Google Ads, não usa credencial e não publica nada. O resultado é texto para colar na interface do Google Ads.

Como usar

O que pedir ao Claude

• "Monta os ativos da campanha Google Ads a partir desta landing page: https://landing.luby.co/ai-senior-software-squads/"
• "Cria a campanha de Outsourcing BR em português, tudo de uma vez, a partir desta copy." (colar a copy)
• "Quero só os 50 search themes da PMax de modernização de legado, em inglês."
• "Gera os sitelinks usando o site luby.co."
• "Vamos passo a passo: começa pelo texto do que torna a Luby única."

Passo a passo

1. Tenha em mãos a copy da landing page (melhor que a URL) e o nome da campanha.
2. Diga o idioma (inglês para [US], PT-BR para [BR]) e o modo de entrega.
3. Se escolher passo a passo, valide cada ativo antes de seguir.
4. Para os sitelinks, informe o domínio e confira se as URLs propostas abrem.
5. Selecione as melhores opções dentro dos tetos do Google Ads.
6. Peça uma revisão pelas regras da conta ("revisa essas headlines pelo ad-copy-principles").
7. Cole na interface do Google Ads ou peça a criação pela API com o plugin, aprovando cada lote.

Cuidados

• Não deixe passar afirmação que não esteja na página (números, certificações, prazos).
• Confira a contagem de caracteres de tudo que estiver perto do limite.
• Não misture idiomas na mesma campanha.
• Troque os temas genéricos e os exemplos de nuvem por termos da oferta real.

Fontes

• google-ads-campaign-builder/SKILL.md (biblioteca de skills do claude.ai, manifesto de 14/06/2026)
• luby-google-ads-toolkit/skills/ad-copy-principles/SKILL.md e credentials-and-access/SKILL.md
• Memória do robô de negativação

Robô que audita todo dia os termos de busca das campanhas Search e Performance Max ativas da conta Google Ads da Luby (5929844041) e negativa sozinho os que não combinam com a landing page. Quando ligado, roda em escrita real. Status: Parado. A tarefa agendada ads-negativacao-auto está desligada porque hoje não há campanha rodando no Google Ads.

Como funciona

Fluxo

1. Às 17h BRT a interface do Google Ads exporta o relatório de termos de pesquisa para uma planilha na pasta "Robô negativação automática google ads".
2. A rotina de nuvem clona o repo e roda /opensquad run ads-negativacao (sem a skill, segue os arquivos de passo em ordem).
3. Passo 00 (Rafa): se os segredos não estão no clone, lê as linhas google-ads-config e drive-sa-key da tabela public.ads_secrets e grava os arquivos. Troca o refresh token por um access token e lista as campanhas ENABLED do tipo SEARCH ou PERFORMANCE_MAX.
4. Passo 01 (Caio): para cada campanha:
   • extrai a oferta das landing pages com WebFetch (até cerca de 5.000 caracteres);
   • Search: termos dos últimos 30 dias via search_term_view;
   • PMax: termos da planilha (com custo real), lidos pelo sheets_reader.py; sem planilha, cai no detalhamento parcial da API;
   • lê as negativas já existentes e filtra os candidatos.
5. Passo 02 (Nina, modelo mais forte): julga cada termo contra a oferta, em lotes de cerca de 40, e separa negations (sem conversão) e review (converteu).
6. Passo 03 (Vitor): aplica as negativas EXACT em nível de campanha via campaignCriteria:mutate, respeitando teto e limites.
7. Passo 04 (Elis): grava o run-summary.md e move todas as planilhas da pasta de entrada para "auditados" (sheets_reader.py archive-all).
8. Passo 05 (Elis): manda o resumo para o Discord por webhook, via curl.

Peças

Agendamentos

Regras de negócio

• Parâmetros (settings.json): janela de 30 dias, mínimo de 1 impressão, confiança mínima 0,8, teto de 200 negativas por dia, correspondência EXACT, Search e PMax ligados, apply=true, arquivamento ligado, Discord ligado, e-mail desligado.
• Termo que converteu nunca é negativado sozinho: vai para a lista "revisar" e a decisão é humana.
• Negativa quando a intenção não combina com a oferta: emprego, curso, grátis ou pirata, outro produto, setor sem relação, DIY, nome de ferramenta ou concorrente, localidade fora do alvo.
• Marca própria (Luby, Finfy e variações) é negativada de propósito: campanha de prospecção não paga por tráfego de marca.
• Na dúvida, mantém. "How to hire" e "how to outsource" são mantidos (pesquisa de contratação); "how to build" e "o que é" são negativados.
• Sufixo jurídico (inc, llc, ltda, company) mais nome fora do vocabulário genérico indica empresa específica: negativa com confiança 0,82.
• Nome obscuro do tipo "palavra ia" só é negativado depois de confirmado por busca na web.
• Aplica por confiança decrescente até o teto; o resto fica para a próxima execução.
• Termo com mais de 80 caracteres é pulado e listado no Discord para negativação manual de uma versão curta.
• Lote com erro é reenviado termo a termo. Só conta como aplicada a negativa que volta com resourceName.
• Volume muito alto: o julgamento prioriza termos com custo maior que zero; os de impressão pura reaparecem nas próximas rodadas (janela móvel de 30 dias).

Integrações e credenciais

• API REST do Google Ads (googleads.googleapis.com/{api_version}): leitura por googleAds:searchStream, escrita por campaignCriteria:mutate. Credencial no arquivo gitignored pipeline/data/google-ads-config.json, campos developer_token, client_id, client_secret, refresh_token, login_customer_id, customer_id, api_version e discord_webhook. Na nuvem vem da linha google-ads-config de public.ads_secrets.
• Google Drive e Sheets: service account auditoria@n8n-integrations-487217.iam.gserviceaccount.com, escopos drive e spreadsheets.readonly. Chave em arquivo gitignored dentro de pipeline/data/ (nome no campo service_account_key do drive-config.json); na nuvem vem da linha drive-sa-key. A service account não escreve no Google Ads (NOT_ADS_USER).
• Tabela public.ads_secrets: colunas id, value (jsonb), description, created_at, updated_at.
• Discord: webhook do campo discord_webhook, sempre por curl (requisições Python levam 1010 ou 403 do Cloudflare).

Como monitorar

• Discord: mensagem "Negativação Google Ads" com o modo, totais, negativados, lista "revisar" e pulados.
• Pasta de entrada no Drive: planilha acumulando sem ir para "auditados" significa robô parado.
• Rotinas do claude.ai: ads-negativacao-auto precisa estar ativa e com última execução concluída no dia.
• Presença dos segredos sem ler o conteúdo (nunca selecione a coluna value):

select id, updated_at
from public.ads_secrets
where id in ('google-ads-config', 'drive-sa-key');

Como usar

O que pedir ao Claude

• "Roda o robô de negativação agora."
• "Simula a negativação sem aplicar nada e me mostra o que ele faria."
• "Quais termos estão na lista revisar do robô de negativação?"
• "A rotina de negativação rodou hoje? Ela está ativa?"

Passo a passo

1. Leia a mensagem do Discord do dia (depois das 18h BRT).
2. Decida a lista "revisar" (termos que converteram) e peça ao Claude para aplicar os aprovados.
3. Olhe os "pulados por tamanho" e peça a negativação de uma versão curta, se fizer sentido.
4. Quando uma campanha PMax nova entrar no ar, configure na interface do Google Ads: Termos de pesquisa, Programar, Diária 17h, Google Planilhas, pasta "Robô negativação automática google ads", com o nome da campanha no arquivo. A pasta precisa estar compartilhada com a service account como Editor.
5. Se o Discord ficar em silêncio, confira a rotina no claude.ai e a pasta de entrada.

Cuidados

• O robô escreve de verdade na conta. Para testar, peça modo simulação (apply=false) e não faça commit dessa troca.
• Não aumente o teto diário de 200 sem revisar o julgamento das últimas rodadas.
• Display e Video ficam fora do escopo.
• Marca própria é negativada por regra. Se a estratégia mudar, a regra da Nina precisa mudar junto.
• Nunca copie o google-ads-config.json nem a chave da service account para chat, doc ou commit.

Fontes

• README da squad
• squad.yaml e pipeline.yaml
• step-00, step-01, step-02, step-03, step-04, step-05
• settings.json e drive-config.json
• README dos scripts e sheets_reader.py
• Memória e log de execuções
• Doc Técnica v2
• Pasta "Robô negativação automática google ads" e subpasta auditados
• Supabase nearsmart: colunas de public.ads_secrets; lista de edge functions
• Lista de rotinas agendadas do claude.ai (lida em 08/10/2026)

Par do robô de negativação: em vez de bloquear termos ruins, adiciona os termos de busca relevantes e com tração que ainda não estão cadastrados na conta Google Ads da Luby (5929844041). Status: Parado. A tarefa agendada semanal ads-positivacao-auto está desligada porque hoje não há campanha ativa no Google Ads. Ela roda com apply=false (só simula): valida as adições e não escreve na conta.

Como funciona

Fluxo

1. A rotina de nuvem clona o repo e roda a squad (/opensquad run ads-positivacao; se a skill falhar, segue os arquivos de passo em ordem).
2. Passo 00 (Rafa): hidrata os mesmos dois segredos do robô de negativação a partir de public.ads_secrets (linhas google-ads-config e drive-sa-key), gravando em squads/ads-negativacao/pipeline/data/. Obtém o access token e lista as campanhas ENABLED Search e PMax.
3. Passo 01 (Caio): para cada campanha, coleta:
   • landing pages via WebFetch (a "oferta");
   • termos dos últimos 30 dias: Search por search_term_view com o grupo de anúncios de origem; PMax pelas planilhas do Drive (só leitura, sem arquivar);
   • cadastro atual: keywords positivas, negativas (campanha e grupo) e search themes de cada asset group, com o resource_name de cada tema e as vagas livres.
4. Filtra candidatos por tração e por não estarem cadastrados nem negativados.
5. Passo 02 (Nina): decide add ou skip por termo e, nos asset groups cheios, propõe rotações.
6. Passo 03 (Vitor): em simulação, monta as operações e confere com validateOnly=true; em escrita real, aplica keywords, temas em vaga e trocas.
7. Passo 04 (Elis): grava o run-summary.md com as sugestões cross-channel.
8. Passo 05 (Elis): resumo no Discord via curl.

Peças

Três formas de "positivar":

Agendamentos

Regras de negócio

• Parâmetros (settings.json): apply=false, janela de 30 dias, mínimo de 1 impressão, confiança mínima 0,8, teto de 50 adições por dia (keywords, temas e trocas somados), correspondência PHRASE, Search e PMax ligados, teto de 50 temas por asset group, rotação ligada com até 3 trocas por asset group e margem mínima 0,15, cross-channel ligado, arquivamento desligado, Discord ligado.
• Filtro de tração: converteu 1 vez ou mais, ou 3 cliques ou mais, ou 30 impressões ou mais. Cada termo ganha um nível: converted, clicks ou impressions.
• Dedup total: não adiciona o que já é keyword ou tema e nunca positiva o que está negativado.
• A Nina só marca add com relevância clara e tração, com confiança de 0,8 ou mais. Na dúvida, não adiciona.
• Nunca entra marca própria (Luby, Finfy) nem concorrente ou produto de terceiro.
• Keyword vai para o grupo de anúncios com mais cliques para aquele termo (desempate por impressões).
• Rotação: troca só se a confiança do candidato menos a relevância do tema existente for de 0,15 ou mais. Nunca remove tema central da oferta. A troca é atômica: se o novo tema falhar, nada é removido.
• Search themes não têm métrica individual na API, então a rotação é por relevância, não por desempenho.
• Termos fortes vindos de PMax viram sugestão de keyword para Search no relatório. Nunca são aplicados sozinhos.
• Pula keyword com mais de 80 caracteres ou mais de 10 palavras e tema com mais de 80 caracteres.

Integrações e credenciais

• API REST do Google Ads, mesma credencial do robô de negativação: arquivo gitignored squads/ads-negativacao/pipeline/data/google-ads-config.json (campos developer_token, client_id, client_secret, refresh_token, login_customer_id, customer_id, api_version, discord_webhook); na nuvem, linha google-ads-config de public.ads_secrets.
• Drive e Sheets pela service account do robô de negativação; chave em arquivo gitignored, na nuvem pela linha drive-sa-key.
• Discord pelo webhook do campo discord_webhook, sempre por curl.

Como monitorar

• Discord: mensagem com título "Positivação Google Ads" e o modo (DRY-RUN ou ESCRITA REAL), totais por tipo (keyword, tema em vaga, rotação), rotações e sugestões cross-channel.
• Rotinas do claude.ai: ads-positivacao-auto ativa e com execução concluída na segunda.
• Memória da squad: entrada nova no Run log a cada execução.
• Presença dos segredos (nunca selecione value):

select id, updated_at
from public.ads_secrets
where id in ('google-ads-config', 'drive-sa-key');

Como usar

O que pedir ao Claude

• "Roda a positivação em simulação e me mostra o que ela adicionaria."
• "Quais keywords a positivação sugeriu na última rodada?"
• "Tem sugestão cross-channel de PMax para Search?"
• "A rotina semanal de positivação está ativa?"
• "Liga a escrita real da positivação." (só depois de revisar as simulações)

Passo a passo

1. Na segunda, depois das 18h BRT, leia a mensagem do Discord.
2. Revise as keywords propostas por campanha e o motivo de cada uma.
3. Se concordar com as adições de várias rodadas seguidas, decida o go-live com a Karime.
4. Para ligar, peça ao Claude para trocar apply para true no settings.json e fazer commit. Para desligar, o caminho inverso.
5. Depois do go-live, acompanhe no Discord o que foi aplicado e confira na interface do Google Ads.

Cuidados

• Positivar termo ruim gasta dinheiro. Prefira menos adições a mais.
• Não ligue a escrita real sem revisar ao menos uma simulação recente.
• Rode a positivação antes da negativação no mesmo dia.
• Sugestão cross-channel é decisão estratégica: escolher a campanha Search certa é humano.

Fontes

• README da squad
• Documentação técnica
• squad.yaml e pipeline.yaml
• settings.json
• step-00, step-01, step-02, step-03, step-05
• Memória e log de execuções
• Supabase nearsmart: information_schema.columns de public.ads_secrets
• Lista de rotinas agendadas do claude.ai (lida em 08/10/2026)

Plugin do Claude que lê a conta Meta Ads "Luby - Principal" (477720682255836) pelo conector Meta Ads e entrega, em português, um relatório de resultados das campanhas de Facebook e Instagram. Está no ar na versão 0.1.1 e é somente leitura: não cria, edita, pausa nem ativa nada.

Como funciona

Fluxo

1. A pessoa pede em linguagem natural ("como estão as campanhas da meta?") ou usa o comando /meta-resultados com período, mercado ou campanha.
2. A skill resultados-meta-ads carrega a skill-base meta-ads-base e lê as referências de conector, períodos e métricas.
3. Primeira chamada da conversa: ads_get_ad_accounts. Se a conta 477720682255836 não aparece, ou vem com is_ads_mcp_enabled ou is_queryable falso, para e explica como pedir acesso. Anota o account_status.
4. Entende o modo: geral, recorte por mercado ("só BR"), recorte por status ("só as ativas") ou campanha específica. Sem recorte pedido, não pergunta: mostra tudo que gastou.
5. Calcula as datas (referência periodos.md) antes de consultar.
6. Coleta, nesta ordem: conta (período atual e anterior numa chamada), últimos 7 dias, configuração atual (o que está no ar, sem entrega, orçamentos), campanhas, gasto por dia, conjuntos, erros de veiculação e, quando precisa explicar uma mudança, o histórico de alterações.
7. Monta a tabela por grupo (BR, US, Impulsionamentos, Outros), com subtotais recalculados e uma linha por conjunto.
8. Aplica os 9 sinais de alerta em ordem de prioridade.
9. Escreve resumo executivo (3 a 5 itens, cerca de 120 palavras), visão geral, tabela, pontos de atenção, leitura (até 2 frases) e até 3 sugestões marcadas como "não executadas", com rodapé de fonte.

Peças

Regras de negócio

• Travas: só leitura; só a conta 477720682255836; nenhum número inventado ("sem dado" quando faltar); sem nomes de quem alterou a conta, só data e mudança.
• Conta: BM Luby 564808577848638, BRL, fuso America/Sao_Paulo. Pixel "Pixel de Luby" 1919871221505747, só PageView e Lead, sem API de Conversões. Atribuição padrão: 7 dias após o clique ou 1 dia após a visualização.
• Padrão de nomes: campanha MERCADO | Objetivo | Tema | MM-AAAA; conjunto Público | MERCADO | Tema (temas Legacy Software, Outsourcing, AI Senior Squads). Nome que começa com "Post do Instagram:", "Publicação do Instagram:", "Instagram Post" ou "Post:" vai para Impulsionamentos.
• Período padrão: últimos 30 dias completos contra os 30 anteriores, mais uma linha com os últimos 7 dias. O dia de hoje fica de fora. Período pedido vira o principal e é comparado com o anterior de mesmo tamanho.
• Formato: R$ 1.234,56, 1,22%, variação +24%, datas DD/MM. Nunca "$", nem nas campanhas US.
• Números pequenos (menos de 10) mostram diferença em quantidade, não em %. Campanha sem dado anterior aparece como "nova".
• Resultado só soma entre linhas do mesmo tipo. Custos, CTR e CPM são recalculados nos subtotais.

Sinais de alerta:

Integrações e credenciais

• Única integração: conector Meta Ads (MCP) do Claude. Cada pessoa conecta com o próprio login do Facebook, que precisa ter acesso à conta "Luby - Principal" no Business Manager. O plugin não guarda credencial.
• Ferramentas permitidas: ads_get_ad_accounts, ads_get_field_context, ads_get_ad_entities, ads_get_errors, ads_get_ad_preview, ads_account_get_activity_logs, ads_get_ad_account_custom_audiences, ads_get_custom_audience, ads_get_dataset_stats, ads_insights_industry_benchmark (só se pedirem), ads_insights_anomaly_signal, ads_insights_performance_trend, ads_get_creatives.
• Proibidas: tudo que começa com ads_create_, ads_update_ ou ads_delete_, ads_activate_entity, ads_boost_ig_post, ads_creative_*, e as de catálogo, pixel e experimento que escrevem.

Como monitorar

• Rodar o pedido padrão ("como estão as campanhas da meta?") e conferir se a primeira linha de alerta não é a situação da conta.
• Para mudanças nas skills, rodar de novo os 5 casos de evals.json com e sem a skill.
• Acompanhar commits no repo e a versão do plugin.

Como usar

O que pedir ao Claude

• "Como estão as campanhas da Meta?"
• "Me traga os resultados da Meta dos últimos 7 dias."
• "Resultados de agosto, só do mercado BR."
• "Como estão só as campanhas ativas?"
• "Como foi a campanha do evento Sibos? Vale repetir?"
• "Vale a pena reativar a campanha de remarketing?"
• "/meta-resultados setembro"

Passo a passo

1. Conecte o Meta Ads em Configurações, Conectores, com um login do Facebook que tenha acesso à conta "Luby - Principal". Sem acesso, peça a um administrador do Business Manager.
2. Instale o plugin: /plugin marketplace add https://github.com/Luby-Marketing/luby-meta-ads-toolkit e depois /plugin install luby-meta-ads-toolkit. É preciso ter acesso à organização Luby-Marketing no GitHub.
3. Faça a pergunta. Sem período, o relatório cobre os últimos 30 dias contra os 30 anteriores.
4. Leia o resumo executivo primeiro; o detalhe vem embaixo.
5. Se quiser mudar algo (pausar, reativar, mudar orçamento), use as sugestões como proposta e execute no Gerenciador de Anúncios.

Cuidados

• O relatório nunca executa mudança, mesmo que você peça junto. Ele devolve a proposta com os números.
• "Leads" no relatório é o evento do pixel atribuído aos anúncios, não lead qualificado no HubSpot.
• Valores em reais, inclusive das campanhas US.
• Para Google Ads, use o plugin luby-google-ads-toolkit.

Fontes

• README do repositório
• CLAUDE.md
• marketplace.json
• README do plugin
• meta-ads-base, conector-meta.md, periodos.md, metricas.md
• resultados-meta-ads e remarketing.md
• meta-resultados.md
• evals.json

Cadastro, no Supabase, dos públicos de remarketing da Luby: cada campanha nossa ganha uma lista de pessoas da base people, que depois vira público em LinkedIn, Meta ou Google Ads. Status Parcial: são 7 públicos com 8.750 membros, só "Legacy Software [US]" está ativo e o envio ao Google Ads é manual.

Como funciona

Fluxo

1. Cria-se a campanha em remarketing_campaigns: nome, descrição do público, status (active ou pause) e, quando existir, o ID da campanha no LinkedIn, na Meta e no Google Ads.
2. Uma pessoa entra no público quando, em people, recebe is_remarketing = true e remarketing_campaign_id apontando para a campanha.
3. O trigger trg_people_set_remarketing_campaign_name (antes da gravação) copia o nome da campanha para people.remarketing_campaigns.
4. O trigger trg_people_sync_remarketing_member (depois de INSERT ou UPDATE dessas colunas) chama people_sync_remarketing_member() e insere a pessoa em remarketing_campaign_members. Se já existir, não duplica.
5. Se a campanha for renomeada, trg_remarketing_campaigns_propagate_name atualiza o nome em todas as pessoas dela.
6. Públicos de CTO são automáticos: todo dia 11, o cron cto-monthly-pull chama a Edge Function cto-apollo-pull no modo live. Ela puxa as listas do Apollo, qualifica a coorte do mês (fn_qualify_cto) e roda fn_sync_remarketing_cto, que marca os CTOs qualificados com e-mail no público US ou BR definido em cto_config. Cada rodada fica registrada em cto_pipeline_runs.
7. Os públicos "Legacy Software [US]" e "Outsourcing [US]" foram carregados em lote (14 e 15/06 e 18/06/2026).
8. Envio aos canais: manual. Para os públicos de CTO há a view v_cto_remarketing_export (campanha, nome, sobrenome, cargo, país, e-mail), no formato de lista do Google Ads. O arquivo é gerado e subido à mão na plataforma.

Peças

Agendamentos

Os demais públicos não têm rotina automática.

Regras de negócio

Os 7 públicos em 08/10/2026:

• Os nomes estão gravados assim, com os erros de digitação; o nome vai no export.
• Legacy Software [US]: líderes de engenharia (CTO, CIO, VP Eng) e de finanças em fintechs, bancos, lending e pagamentos com sistemas legados críticos.
• Outsourcing [US]: empresas com vagas abertas, da base de scrape do Supabase.
• CTO Transiction: CTOs há no máximo 6 meses no cargo, sem indústria definida, pessoa e empresa no país do público.
• Anti-sequestro: fn_sync_remarketing_cto pula quem já está em outro público (22 pulados na coorte de junho, 2 na de agosto) e quem não tem e-mail.
• Uma pessoa tem um só remarketing_campaign_id por vez em people; a tabela de membros guarda o histórico (8.750 linhas para 8.747 pessoas).
• Nenhum público tem ID de campanha da Meta. Os públicos da Meta usados hoje vêm do pixel (nomes que começam com "LANDING" ou "Base"), fora desta estrutura.

Integrações e credenciais

• Apollo: APOLLO_API_KEY em Edge Function Secrets (usada por cto-apollo-pull).
• LinkedIn, Meta e Google Ads: nenhuma integração automática de upload. Os IDs em remarketing_campaigns servem só para cruzar resultados.

Como monitorar

-- Tamanho e status de cada público
select rc.name, rc.status, count(m.id) as membros, max(m.added_at) as ultima_entrada
from public.remarketing_campaigns rc
left join public.remarketing_campaign_members m on m.remarketing_campaign_id = rc.id
group by rc.id order by membros desc;

-- Últimas rodadas automáticas de CTO
select cohort_month, status, inserted, notes->>'members_us_total' as us, notes->>'members_br_total' as br, started_at
from public.cto_pipeline_runs where stage = 'remarketing_sync' order by started_at desc limit 6;

-- Quantos registros cada público de CTO teria no export
select campaign, count(*) from public.v_cto_remarketing_export group by 1;

Como usar

O que pedir ao Claude

• "Quantas pessoas tem cada público de remarketing hoje?"
• "Gera o CSV do público Legacy Software [US] para eu subir no Google Ads."
• "Quantos CTOs entraram no público de remarketing na última rodada?"
• "Cria um público novo chamado 'Fintech Lending [US]' com estes contatos." (o Claude mostra o plano e pede aprovação antes de gravar)
• "Quais públicos estão ativos e quais estão pausados?"

Passo a passo

1. Defina o público com o time: quem entra, mercado e canal.
2. Peça ao Claude para cadastrar a campanha em remarketing_campaigns e marcar as pessoas. Aprove o plano antes da gravação.
3. Peça o export em CSV do público. O arquivo tem e-mail: guarde só o necessário para o upload.
4. Suba o arquivo manualmente na plataforma (hoje, Google Ads) e anote o ID da campanha.
5. Peça ao Claude para gravar o ID da campanha no público e mudar o status para active.
6. Nos dias 11, confira se a leva nova de CTOs entrou e reenvie o arquivo, se o público estiver em uso.

Cuidados

• Os arquivos de export têm dados pessoais. Não deixe em pasta compartilhada nem anexe em Trello ou Discord.
• Antes de marcar alguém, confira se a pessoa já está em outro público; a marcação em people troca o público dela.
• Renomear um público muda o nome em todas as pessoas dele e no export.

Fontes

• Supabase nearsmart, leitura em 08/10/2026: remarketing_campaigns, remarketing_campaign_members, remarketing_audience, v_cto_remarketing_export, audience_members, audience_sync_log, cto_config, cto_pipeline_runs, pg_trigger, cron.job
• Funções SQL lidas: people_sync_remarketing_member, people_set_remarketing_campaign_name, remarketing_campaigns_propagate_name, fn_sync_remarketing_cto
• Edge Function lida: cto-apollo-pull
• Referência de remarketing do toolkit Meta Ads

Painel interno de marketing em marketing.luby.digital (Next.js com login Google) que junta funil do HubSpot, Google Ads, GA4, LinkedIn, Lemlist, concorrência e o kanban de iniciativas do Growth. Status Atenção: débito técnico deixado pela Estela. As fontes diárias estão em dia, mas o kanban de iniciativas não sincroniza com o Trello porque não há cron para trello-sync.

Como funciona

Fluxo

1. Crons diários no Supabase chamam Edge Functions que buscam dados nas fontes:
   • sync-ga4: GA4 BR e US, 12 meses por dia, em analytics_daily.
   • sync-ga4-pages: páginas do GA4 por dia e operação, em analytics_pages.
   • sync-google-ads: campanhas de 2026 por mês, reescreve a aba "ADS Campaigns" da planilha principal.
   • growth-metrics-sync: conta leads inbound por mês, origem e mercado em 8 tabelas de formulário e grava na aba "Inbound" da planilha.
   • gestao-sync: snapshot de 2026 com deals de origem marketing e respostas de outbound, em gestao_snapshots.
   • hubspot-sync (a cada 6 horas, compartilhado com a Jornada do Lead): deals dos últimos 12 meses em hubspot_leads.
2. A pessoa entra com Google (Supabase Auth). O servidor confere o e-mail na allowlist (AUTH_ALLOWED_EMAILS tem prioridade; senão vale AUTH_ALLOWED_DOMAINS).
3. A página /marketing busca os dados por rotas do próprio Next.js:
   • /api/dashboard/hubspot lê hubspot_leads.
   • /api/dashboard/ga4 e /api/dashboard/ga4-pages leem analytics_daily e analytics_pages.
   • /api/dashboard/lemlist lê lemlist_campaign_metrics.
   • /api/dashboard/linkedin e /linkedin-posts leem linkedin_metrics e linkedin_posts.
   • /api/sheets lê as abas Inbound, Outbound e ADS Campaigns da planilha principal.
   • /api/dashboard/leads-history e /ads-history leem a planilha "Indicadores Marketing 2025" para o histórico de 12 meses.
   • /api/dashboard/initiatives lê growth_initiatives e growth_initiative_lists.
4. A página /concorrencia lê a tabela competitors.
5. Kanban de iniciativas: o botão de sincronizar chama /api/dashboard/initiatives/sync, que repassa para a Edge Function trello-sync com o header x-cron-secret. A função lê o board do Trello, grava listas e cards por trello_card_id e apaga os cards que saíram do board. O Trello é a fonte da verdade; no painel só a prioridade (P0 a P3) é editável.
6. Deploy: push na main roda o GitHub Actions, que faz build standalone, envia por rsync via SSH e recarrega o PM2. O LiteSpeed da Hostinger encaminha o domínio para a porta 3000 por .htaccess.

Peças

Agendamentos

Não existe cron para trello-sync.

Regras de negócio

• Câmbio fixo de 5,60 BRL por USD em todo o painel e nas funções.
• ROAS: deals Won de canais pagos dividido pelo investimento acumulado, sem filtro de data.
• Google Ads: a API é a fonte de 2026 em diante; 2025 vem da planilha de 2025. O mercado US é deduzido pelo nome da campanha (palavra "US").
• Inbound: contagem por mês (não acumulada), desde jan/2026, excluindo e-mails @luby.com.br e @luby.co. A aba nunca é limpa: linhas casam pela coluna key.
• Gestão: só deals do pipeline de Vendas criados em 2026 com origem de marketing (Inbound em canais válidos ou Outreach); mercado pelo dono do deal (owner_market).
• Kanban: colunas são as listas do Trello; a lista "Drive" é ignorada.

Integrações e credenciais

• Servidor do painel (.env.production no servidor, gerado pelo deploy a partir de GitHub Actions Secrets): NEXT_PUBLIC_SUPABASE_URL, NEXT_PUBLIC_SUPABASE_ANON_KEY, AUTH_ALLOWED_DOMAINS, GOOGLE_API_KEY. Usadas pelo código mas fora do deploy: AUTH_ALLOWED_EMAILS, CRON_SECRET, NEXT_PUBLIC_HUBSPOT_PORTAL_ID, LEADS_HISTORY_SHEET_ID.
• Deploy (GitHub Actions Secrets): SSH_HOST, SSH_PORT, SSH_USER, SSH_PASSWORD, DEPLOY_PATH, DISCORD_WEBHOOK_URL.
• Edge Function Secrets: GA4_CREDENTIALS (service account, também editora da planilha), GA4_PROPERTY_ID_BR, GA4_PROPERTY_ID_US, GOOGLE_ADS_DEVELOPER_TOKEN, GOOGLE_ADS_CLIENT_ID, GOOGLE_ADS_CLIENT_SECRET, GOOGLE_ADS_REFRESH_TOKEN, HUBSPOT_TOKEN, TRELLO_KEY, TRELLO_TOKEN, TRELLO_BOARD_ID, TRELLO_IGNORED_LISTS, CRON_SECRET (trello-sync) e CRON_SECRET_OUTBOUND_JOURNEY (demais funções; lido pelos crons no Vault).

Como monitorar

-- Frescor das fontes do painel
select 'analytics_daily' as fonte, max(date)::text as ate, max(synced_at)::text as sync from public.analytics_daily
union all select 'analytics_pages', max(date)::text, max(synced_at)::text from public.analytics_pages
union all select 'hubspot_leads', null, max(synced_at)::text from public.hubspot_leads
union all select 'linkedin_metrics', max(date)::text, max(synced_at)::text from public.linkedin_metrics
union all select 'lemlist_campaign_metrics', max(date)::text, null from public.lemlist_campaign_metrics
union all select 'growth_initiatives', null, max(synced_at)::text from public.growth_initiatives
union all select 'gestao_snapshots', null, max(captured_at)::text from public.gestao_snapshots;

-- Crons do painel
select jobname, schedule, active from cron.job
where jobname in ('ga4-daily','ga4-pages-daily','google-ads-daily','gestao-sync-daily','growth-metrics-daily','sync-hubspot-deals');

Como usar

O que pedir ao Claude

• "Os dados do dashboard de marketing estão atualizados? Qual fonte está atrasada?"
• "Quantas sessões o site BR teve na última semana, segundo o GA4?"
• "Quanto investimos no Google Ads em setembro, por campanha?"
• "Por que o kanban de iniciativas não mostra os cards novos do Trello?"
• "Quem tem acesso ao dashboard?" (o Claude aponta as variáveis de allowlist; não lista e-mails em público)

Passo a passo

1. Acesse marketing.luby.digital e entre com a conta Google autorizada.
2. Use as abas Funil, Google Ads, Site e LinkedIn; o filtro BR/US muda a operação.
3. Para iniciativas, crie e mova cards no board do Trello do Growth. Depois clique em sincronizar no kanban (hoje não está funcionando; avise o time técnico).
4. Para alguém novo entrar, peça ao time técnico para incluir o e-mail em AUTH_ALLOWED_EMAILS no servidor.

Cuidados

• No kanban, só a prioridade é editada no painel. Nome, coluna, responsável e prazo são editados no Trello.
• Números de outbound vêm do Lemlist, não da aba Outbound da planilha.
• Não compartilhe prints com valores de deals fora do time.

Fontes

• CHANGELOG.md
• .env.example
• docs/DEPLOY.md
• docs/trello-integration-plan.md
• Página marketing
• Rota de sync das iniciativas
• Rota /api/sheets
• allowlist.ts
• trello-sync
• deploy.yml
• Supabase nearsmart, leitura em 08/10/2026: Edge Functions sync-ga4, sync-google-ads, growth-metrics-sync, gestao-sync, sheets-access-check; tabelas analytics_*, growth_initiatives, growth_initiative_lists, gestao_*, dashboard_config, linkedin_*, lemlist_campaign_metrics; cron.job e cron.job_run_details

O plugin outbound-campaigns é a forma do time operar a Outbound Machine pelo Claude, em português e sem SQL: criar campanha, subir leads, ver status, rodar o engajamento no LinkedIn e manter a lista de empresas bloqueadas. É a porta de entrada do motor de outbound: o plugin faz o papel de tela e o motor executa. Está no ar, na versão 0.4.2.

Como funciona

Fluxo

1. O usuário digita um comando (/campanha-nova, /campanha-leads, /campanha-status, /bloqueio, /engajamento) ou pede em português ("cria uma campanha de LinkedIn").
2. O comando é um arquivo curto em commands/ que só invoca a skill certa e repassa o texto do usuário.
3. Toda skill de tarefa carrega primeiro a skill-base motor-outbound-base, que traz o contrato do motor, as receitas SQL e a regra de linguagem.
4. A skill conversa em linguagem de marketing, mostra cada decisão de negócio com um valor sugerido e pergunta.
5. Por baixo, executa SQL no Supabase nearsmart pelo conector (execute_sql) e chama edges pelo curl (ingestão de CSV e enriquecimento).
6. Toda ação que muda produção segue: simular, mostrar os números, receber o "sim", aplicar.

Peças