material da comunidade 7 prompts na ordem a venda aprova e o acesso chega sozinho use Opus 4.8 ou Opus 5

entrega e recuperação

passo a passo

7 prompts, 1 dia

A venda aprova
e o acesso chega sozinho
no WhatsApp, do seu número.

Duas coisas acontecem no minuto seguinte a uma venda, e as duas costumam ser feitas na mão: mandar o acesso pra quem pagou, e cobrar quem gerou o pix e sumiu. Você vai construir o sistema que faz as duas sozinho, falando pelo seu próprio número, com a sua foto e o seu jeito. E que para de cobrar no segundo em que a pessoa paga.

7 prompts prontos peça Opus 4.8 ou Opus 5 sai do seu número testa em modo seco antes

Painel de entregas com o status do WhatsApp conectado e a lista de acessos entregues — **O destino.** Print de verdade do sistema rodando. Cada linha é uma pessoa que comprou e recebeu o acesso sem ninguém digitar nada. Os nomes e telefones dos prints são inventados, o resto é real.

Z-API ou Evolution? A resposta é: as duas, e você escolhe depois

Essa é a primeira pergunta de todo mundo, e ela tem uma resposta melhor do que escolher um lado.

Os dois fazem a mesma coisa: conectam no WhatsApp pelo seu número, por QR Code, e te dão um endereço pra onde você manda "escreve isso pra esse telefone". Nenhum dos dois é oficial do WhatsApp, e por isso os dois pedem cuidado no ritmo (o passo 08 é inteiro sobre isso).

Comece com Z-API. Faça o código não saber disso.

Z-API: você paga por mês, lê o QR Code no painel deles e em dez minutos está mandando mensagem. Eles cuidam do servidor, da reconexão e das quedas. É o caminho pra quem quer o sistema funcionando hoje.

Evolution: é aberta e sem mensalidade de licença, mas você precisa subir e manter um servidor. Sai mais barato quando você tem vários números (agência com muitos clientes) e mais caro quando o assunto é o seu tempo. Se você não sabe o que é uma máquina virtual, não comece por aqui.

A jogada do material é essa: o envio fica atrás de um arquivo só, com os dois provedores dentro e uma variável escolhendo qual usar. Você começa com Z-API hoje e, no dia que quiser, troca uma palavra na configuração e passa pra Evolution. O resto do sistema nem fica sabendo.

Agora a ideia do sistema, que também é curta. Uma venda gera dois caminhos: se foi aprovada, ela vira uma entrega (mensagem única, com o link do produto). Se foi só um pix gerado, ela vira uma fila de cobranças agendadas, que morre no instante em que o pagamento entra.

Use no mínimo o Opus 4.8. Se tiver Opus 5, use o Opus 5.

Aqui o erro não fica na tela, ele vai pro celular de um cliente. Mensagem duplicada, cobrança em quem já pagou, link do produto errado: tudo isso é constrangimento com gente que acabou de te dar dinheiro. É o projeto da série em que eu menos economizaria no modelo.

Modelo em Opus e uma conversa só do primeiro ao último prompt.
Conta no Supabase com um projeto novo.
Um número de WhatsApp que você aceite usar pra isso, com o app instalado e ativo.
Acesso pra cadastrar um webhook no seu gateway e os links de acesso dos seus produtos.

O banco

Cinco tabelas: as entregas, os links de cada produto, os textos que você edita sem mexer em código, os pix em aberto e a fila de cobranças agendadas. A chave única aqui tem uma função extra: é ela que impede a mesma pessoa de receber a mesma mensagem duas vezes quando o gateway reenvia o aviso.

SQL · cole no editor do Supabase

-- 1. AS ENTREGAS (uma linha por venda aprovada)
create table if not exists entrega_entregas (
  id uuid primary key default gen_random_uuid(),
  platform text not null,                  -- cakto | manual
  transaction text not null,
  evento text,
  nome text,
  email text,
  telefone text,                           -- ja normalizado (so digitos, com 55)
  telefone_bruto text,                     -- como veio, pra investigar depois
  produto_id text,
  produto_nome text,
  valor numeric,
  link text,                               -- o link que foi enviado
  texto text,                              -- a mensagem exata que saiu
  status text not null default 'pendente', -- pendente|enviado|dry|sem_telefone|sem_link|erro
  erro text,
  tentativas int not null default 0,
  enviado_em timestamptz,
  raw jsonb,
  created_at timestamptz not null default now(),
  unique (platform, transaction)           -- webhook repetido NAO manda de novo
);

-- 2. O LINK DE CADA PRODUTO (editavel no painel, sem tocar em codigo)
create table if not exists entrega_links (
  produto_id text primary key,
  produto_nome text,
  link text,
  updated_at timestamptz not null default now()
);

-- 3. TEXTOS E CONFIGURACOES (a mensagem de entrega, os 4 toques do pix)
create table if not exists entrega_config (
  chave text primary key,
  valor text,
  updated_at timestamptz not null default now()
);

-- 4. OS PIX EM ABERTO
create table if not exists entrega_pix (
  id uuid primary key default gen_random_uuid(),
  platform text not null,
  transaction text not null,
  nome text, telefone text, email text,
  produto_id text, produto_nome text,
  valor numeric,
  pix_code text,                           -- o copia e cola, quando a plataforma manda
  checkout_url text,
  status text not null default 'aberto',   -- aberto | pago | perdido | cancelado
  pago_em timestamptz,
  created_at timestamptz not null default now(),
  unique (platform, transaction)
);

-- 5. A FILA DE COBRANCAS (uma linha por toque agendado)
create table if not exists entrega_pix_msgs (
  id uuid primary key default gen_random_uuid(),
  pix_id uuid not null references entrega_pix(id) on delete cascade,
  passo int not null,                      -- 1 a 4
  send_at timestamptz not null,            -- a hora marcada pra sair
  status text not null default 'pendente', -- pendente | enviado | cancelado | erro
  enviado_em timestamptz,
  erro text,
  unique (pix_id, passo)
);
create index if not exists idx_pix_fila on entrega_pix_msgs (status, send_at);
create index if not exists idx_entrega_status on entrega_entregas (status, created_at desc);

-- TRAVA: RLS ligada e sem policy nenhuma.
-- Aqui tem telefone e nome de cliente. So o servidor toca nisso.
alter table entrega_entregas enable row level security;
alter table entrega_links    enable row level security;
alter table entrega_config   enable row level security;
alter table entrega_pix      enable row level security;
alter table entrega_pix_msgs enable row level security;

Prompt 01: o adaptador de WhatsApp

Comece por aqui, e não pelo webhook. Esse arquivo é o que responde a pergunta do começo: ele guarda os dois provedores e uma variável decide qual usar.

E ele tem a melhor invenção desse projeto: o modo seco. Sem as credenciais preenchidas, o sistema faz tudo, grava tudo, mostra tudo no painel, e não dispara nada. É assim que você testa a coisa inteira sem mandar mensagem torta pra um cliente de verdade.

Prompt 01 · o adaptador e o modo seco

Você é um engenheiro sênior. Vamos construir um sistema que, quando a venda é aprovada no meu gateway, manda o acesso pro cliente no WhatsApp saindo do MEU número, e que cobra sozinho quem gerou pix e não pagou.

STACK
- Funções serverless em JavaScript puro, sem framework, na Vercel. Uma pasta de rotas e uma de biblioteca.
- Banco: Supabase, acessado só pelo servidor com a chave de serviço.
- O painel é um arquivo HTML estático que conversa com essas rotas.

COMECE PELO ENVIO. Um arquivo só, que o resto do sistema usa sem saber quem entrega a mensagem.

1. DOIS PROVEDORES ATRÁS DA MESMA PORTA
- Exporte uma função de enviar mensagem que recebe telefone e texto.
- Uma variável de ambiente escolhe o provedor: Z-API (padrão) ou Evolution.
- Z-API: mandar para o endereço de envio de texto da instância, com o id e o token da instância no caminho e o token do cliente no cabeçalho.
- Evolution: mandar para o endereço de envio de texto da instância, com a chave da API no cabeçalho.
- Se um dia eu quiser um terceiro provedor, tem que ser só mais uma função nesse arquivo. Nenhum outro arquivo do sistema pode saber qual eu uso.

2. MODO SECO (a parte mais importante)
- Se as credenciais do provedor escolhido não estiverem preenchidas, NÃO dispare nada: devolva um resultado marcado como seco.
- Quem chamou grava normalmente, com o status de simulado, e o painel mostra a mensagem exata que teria sido enviada.
- É assim que eu vou testar o sistema inteiro sem mandar mensagem errada pra cliente de verdade. Isso não é enfeite: é o modo padrão até eu mandar ligar.

3. NORMALIZAÇÃO DE TELEFONE BRASILEIRO
Escreva uma função que recebe o telefone de qualquer jeito e devolve só dígitos, pronto pra API:
- Tira tudo que não é número e zeros à esquerda.
- Se vier sem o código do país e tiver 10 ou 11 dígitos, coloca o 55 na frente.
- Com o 55, um número válido tem 12 dígitos (fixo) ou 13 (celular com o nono dígito). Fora disso, devolve vazio em vez de tentar mandar.
- Número de outro país passa direto, com o código dele.
- Nunca invente dígito nem remova o nono. Quando não der pra normalizar, o certo é registrar como "sem telefone válido" e seguir.

4. STATUS DA CONEXÃO
Uma função que pergunta ao provedor se o meu número está conectado, pra o painel mostrar isso no topo. Se cair a conexão eu preciso ver na hora, não descobrir por cliente reclamando.

REGRAS
- Credenciais só em variáveis de ambiente do servidor. Nunca no código, nunca numa resposta de API.
- Nada de TODO e nada de função vazia.
- Me diga como testar esse arquivo sozinho, mandando uma mensagem pro meu próprio número, e como conferir que sem credencial ele fica em modo seco.

Prompt 02: a entrega automática

Agora o caminho feliz: venda aprovada, mensagem com o link certo, uma vez só. Três detalhes fazem esse pedaço não dar vergonha: o link vem de uma tabela (não do código), a mensagem é um texto que você edita no painel com variáveis, e a mesma venda nunca é entregue duas vezes.

Prompt 02 · venda aprovada vira acesso

Agora a entrega: venda aprovada vira mensagem com o acesso.

A ROTA DO WEBHOOK
1. Só aceita POST e confere um segredo meu (na URL ou no cabeçalho). Sem isso, 401. Essa rota fica aberta na internet.
2. Traduz o aviso do gateway pro meu formato: plataforma, id da transação, evento, nome, e-mail, telefone, id e nome do produto, valor, e o aviso cru inteiro.
3. Decide se é aprovação pelo NOME DO EVENTO, não pelo status que vem dentro do pedido. Alguns gateways mandam o pedido marcado como pago até num evento de pix apenas gerado, e aí você entrega acesso pra quem não pagou.
4. Se não for aprovação, registra e sai sem entregar.
5. Responde 200 rápido em qualquer caso. Gateway que recebe erro repetido desliga o webhook.

A ENTREGA
1. Grava a venda na tabela de entregas com a chave única de plataforma e transação. Se já existe, atualiza. É isso que impede a mesma pessoa de receber a mesma mensagem duas vezes quando o aviso chega repetido.
2. Descobre o link daquele produto na tabela de links, pelo id do produto. Se não achar pelo id, tenta pelo nome. Se não achar de jeito nenhum, marca a entrega como "sem link" e me avisa: é problema meu de cadastro, não do cliente.
3. Monta o texto a partir do modelo que está salvo no banco (editável no painel), trocando as variáveis: primeiro nome da pessoa, nome do produto, link e e-mail. O primeiro nome entra com a primeira letra maiúscula e o resto minúsculo, porque muita gente digita tudo em caixa alta no checkout.
4. Normaliza o telefone. Sem telefone válido, marca como "sem telefone" e para. Não tente adivinhar.
5. Manda pelo adaptador e grava o resultado: enviado, simulado (modo seco), sem telefone, sem link ou erro, junto com a mensagem exata que saiu e a hora.
6. Guarda o número de tentativas.

MODELO PADRÃO DA MENSAGEM
Escreva um texto inicial curto, em primeira pessoa, deixando claro que é a minha conversa pessoal e que a pessoa pode responder ali mesmo. Nada de linguagem de robô, nada de "prezado cliente", nada de emoji em excesso. Uma linha dizendo que o acesso está liberado, o link, e uma linha oferecendo ajuda.

REENVIO
Uma rota que reenvia uma entrega específica mesmo que ela já tenha sido feita, pra quando a pessoa apagar a conversa ou trocar de número. Ela grava tentativa de novo e mantém o histórico.

Me entregue os arquivos e me diga como simular uma venda aprovada pra testar sem esperar venda real.

Aba de links, com o link de acesso de cada produto

Editor da mensagem de entrega com variáveis

Prompt 03: a régua que cobra o pix

Aqui está o dinheiro que já é seu e você não pegou. A pessoa quis comprar, gerou o pix e travou em alguma coisa. Quatro toques, com intervalos pensados, e uma regra que vale mais que os quatro juntos: parar no segundo em que o pagamento entra.

Repare nos tempos do prompt. O primeiro toque em oito minutos não é chute: quem gerou e não pagou nesse tempo normalmente travou numa dúvida e ainda está com o celular na mão. Depois disso a conversa esfria rápido.

Prompt 03 · recuperação de pix

Agora a recuperação: quem gerou o pix e não pagou vai ser cobrado sozinho, com jeito.

QUANDO O PIX É GERADO
O mesmo webhook recebe o evento de cobrança gerada. Nesse caso:
1. Grava na tabela de pix em aberto, com a chave única de plataforma e transação.
2. AGENDA os quatro toques de uma vez, gravando uma linha por toque na fila, cada uma com a hora marcada pra sair.
Os tempos são contados a partir do pix gerado:
toque 1: 8 minutos
toque 2: 45 minutos
toque 3: 6 horas
toque 4: no dia seguinte
Agendar tudo de uma vez é melhor que recalcular depois: fica visível na tela o que vai sair e quando, e dá pra cancelar.

A ROTINA QUE DISPARA
Uma rota agendada, rodando de 5 em 5 minutos:
1. Pega da fila as mensagens pendentes cuja hora já passou, ordenadas da mais antiga.
2. LIMITE DE 8 POR RODADA. Isso é proposital: é o meu número pessoal, não pode sair rajada. Se acumular, sai aos poucos.
3. Antes de mandar CADA UMA, confere se aquele pix ainda está em aberto. Se pagou entre o agendamento e agora, cancela o toque e todos os seguintes daquela pessoa. Cobrar quem já pagou é o pior erro possível desse sistema.
4. Monta o texto do toque a partir dos modelos salvos no banco, com as variáveis: primeiro nome, produto, valor formatado em real, link do checkout e o código do pix copia e cola quando a plataforma mandar.
5. Manda pelo adaptador, grava enviado ou erro com a hora.
6. Protege a rota com o cabeçalho do agendador ou um segredo meu.

QUANDO O PAGAMENTO ENTRA
O evento de aprovação faz duas coisas: marca o pix como pago e CANCELA todos os toques pendentes daquela pessoa. Depois segue o fluxo normal de entrega do acesso.

OS QUATRO TEXTOS
Escreva os quatro, curtos, em primeira pessoa, cada um com um papel diferente:
1. Perguntar se travou em alguma coisa e se oferecer pra ajudar. Sem cobrança.
2. Lembrar do valor em aberto e explicar em uma linha como pagar, oferecendo gerar outro código se expirou.
3. Dizer que o acesso está separado esperando, e abrir espaço pra pessoa dizer que desistiu.
4. Último toque, sem peso: o link continua valendo, e se não for o momento, tudo bem.
Nenhum deles pode ter tom de cobrança de banco, ameaça de prazo ou pressão inventada. É o seu número pessoal e essa pessoa ainda pode comprar depois.

Me entregue os arquivos e me diga como testar a régua inteira em minutos, sem esperar 24 horas.

Prompt 04: o painel

Sem essa tela você não sabe se o sistema está funcionando, e vai continuar conferindo na mão, que era o que a gente queria matar. A primeira coisa que ela mostra não é número: é se o seu WhatsApp ainda está conectado.

Prompt 04 · o painel de entregas

Agora o painel, num arquivo HTML estático, protegido por uma senha minha que fica em variável de ambiente.

NO TOPO
- O título e uma frase curta explicando o que o sistema faz.
- Um selo grande com o estado da conexão do meu WhatsApp: conectado em verde, desconectado em vermelho com o motivo. Se estiver em modo seco, um selo amarelo dizendo que está simulando e não enviando.
- Cinco números: entregas de hoje, entregues, simuladas, travadas e total. Uma barra colorida mostrando a proporção.

QUATRO ABAS

1. ENTREGAS
Tabela com aluno (nome e telefone), produto e plataforma, status colorido, quando aconteceu, e um botão de reenviar em cada linha. Clicar numa linha abre a mensagem exata que foi enviada, pra eu conferir o que a pessoa recebeu.
Filtro por status, com destaque pras travadas: são as que precisam de mim.

2. LINKS DOS PRODUTOS
Lista dos produtos que já venderam, cada um com um campo pro link de acesso e um botão de salvar. Produto que vendeu e ainda não tem link cadastrado aparece em destaque no topo, porque toda venda dele vai travar.

3. MENSAGEM
Um editor do texto de entrega, com a lista das variáveis disponíveis ao lado e uma prévia de como fica com dados de exemplo. Botão de salvar e botão de voltar ao texto padrão.

4. ENVIAR NA MÃO
Nome, telefone, produto e um botão. É a saída de emergência pra quando alguém compra por fora, ou pra reenviar pra um número novo. Usa o mesmo caminho de entrega, então cai no mesmo histórico.

REGRAS
- Uma chamada só traz tudo. Atualiza sozinho a cada minuto, sem piscar.
- Estado vazio com frase curta em toda lista.
- Nada de mostrar telefone completo em tela pública, e nada de deixar essa página sem senha: aqui tem dado de cliente.
- Bom no celular antes de ser bom no computador.
Me entregue os arquivos e o que testar.

Prompt 05: o painel do pix

A régua trabalha sozinha, mas você precisa ver o que ela está prestes a mandar. Essa tela é a única do sistema que mostra o futuro: as mensagens agendadas que ainda não saíram.

Prompt 05 · a tela da recuperação

Agora a tela da recuperação de pix, dentro do mesmo painel.

NÚMEROS DO TOPO
- Pix em aberto agora, com o valor somado.
- Recuperados no período: quantos pagaram depois de receber pelo menos um toque, e quanto isso deu em dinheiro. Esse é o número que justifica o sistema inteiro existir.
- Perdidos: passaram pelos quatro toques e não pagaram.
- Taxa de recuperação em porcentagem.

LISTA DOS PIX
Cada pessoa com: nome, produto, valor, quando gerou, o status (em aberto, pago, perdido) e uma linha de quatro bolinhas mostrando os toques: cinza pro que ainda vai sair, verde pro enviado, apagado pro cancelado. Passar o mouse mostra a hora marcada de cada um.
Um botão pra cancelar a régua daquela pessoa, pra quando ela me responder pedindo pra parar.

FILA
Uma lista curta do que vai sair nas próximas horas, em ordem de horário, com o texto exato de cada mensagem. É a tela que eu abro antes de dormir pra ter certeza de que não vai sair nada estranho de madrugada.

TEXTOS DOS 4 TOQUES
Um editor pra cada um dos quatro, com as variáveis disponíveis e prévia. Salvar vale só pros agendamentos futuros: o que já está na fila mantém o texto do momento em que foi agendado, senão eu mudo um texto e reescrevo o passado.

REGRAS
- Deixe claro na tela quando o sistema está em modo seco, senão eu vou achar que a régua está rodando e ela não está.
- A recuperação é a parte mais delicada do sistema: qualquer coisa que dispare mensagem precisa aparecer aqui antes de sair.
Me entregue os arquivos e o que testar.

Prompt 06: não tomar bloqueio

Esse passo não constrói funcionalidade nenhuma, e é o que decide se o seu número sobrevive. Nenhuma dessas conexões é oficial do WhatsApp. O que faz um número ser bloqueado quase nunca é a ferramenta: é o comportamento. Número novo mandando cinquenta mensagens pra desconhecidos em dez minutos é o retrato exato do que eles caçam.

Prompt 06 · as travas de segurança do número

Agora as travas que protegem o meu número de ser bloqueado. Implemente todas no código, não só como recomendação.

1. RITMO
- Limite de mensagens por rodada da rotina automática (comece com 8).
- Um intervalo aleatório de alguns segundos entre uma mensagem e outra, nunca disparo instantâneo em sequência.
- Limite diário total, configurável, que quando estourado adia o resto pro dia seguinte em vez de mandar.

2. HORÁRIO
- Nada sai antes das 8h nem depois das 21h, no meu fuso. Mensagem de madrugada é o jeito mais rápido de virar denúncia.
- O que vencer fora da janela é adiado pro próximo horário permitido, não descartado.

3. UMA CONVERSA, NÃO UMA CAMPANHA
- Nunca mande duas mensagens seguidas pra mesma pessoa no mesmo minuto.
- Se a pessoa já recebeu mensagem minha nas últimas horas por outro motivo, espace.
- Texto variado entre os toques: mensagem idêntica repetida pra muita gente é o padrão que sistema antifraude enxerga.

4. SAÍDA FÁCIL
- Toda régua tem que parar quando a pessoa pede. Crie uma lista de bloqueio: telefone que entrar nela nunca mais recebe nada automático.
- O último toque precisa deixar claro que aquilo é o último.

5. CANAL CERTO
- Isso aqui é pra falar com quem TENTOU COMPRAR de você. Não use pra lista fria, não use pra grupo, não use pra quem nunca te procurou. Além de bloquear o número, é a diferença entre relacionamento e spam.

6. SE CAIR
- O painel precisa mostrar a conexão caída em vermelho, no topo, imediatamente.
- Enquanto estiver caído, o sistema NÃO descarta mensagem: ela fica na fila e sai quando voltar.
- Me diga como reconectar em cada provedor, e o que fazer se o número for bloqueado de vez.

Implemente tudo isso e me mostre onde cada trava está no código, pra eu poder afrouxar ou apertar depois.

Se for começar com número novo, aqueça antes

Número recém-criado que estreia disparando automação é o perfil mais fácil de bloquear que existe. Use por alguns dias como número normal: converse, receba resposta, entre em alguma conversa de verdade. Depois ligue o sistema, começando devagar.

E prefira o número que você já usa pra falar com cliente. Ele já tem histórico, já tem conversa de verdade, e a mensagem chegando dele tem outro peso: a pessoa reconhece a sua foto.

Prompt 07: no ar e o teste real

A ordem aqui importa mais que nos outros materiais: suba em modo seco, teste tudo, e só depois ligue o envio. O primeiro disparo de verdade é pro seu próprio número.

Prompt 07 · deploy, conexão e conferência

Meu sistema funciona local, em modo seco. Quero ele no ar hoje, com cuidado.

Me guie clicado, assumindo que eu não sei o que é terminal:
1. Como subir o projeto.
2. Onde cadastrar as variáveis de ambiente: banco, senha do painel, segredo do webhook, segredo da rotina agendada, e as credenciais do provedor de WhatsApp. Deixe as do provedor VAZIAS por enquanto, pra subir em modo seco.
3. Como ligar a rotina agendada de 5 em 5 minutos.
4. Onde eu colo a URL do webhook no painel do gateway e quais eventos eu marco: aprovação e cobrança gerada, no mínimo.
5. Como conectar o meu WhatsApp no provedor escolhido, passo a passo, incluindo onde aparece o QR Code e o que fazer se cair.

TESTE EM MODO SECO, antes de qualquer mensagem sair:
- Simular uma venda aprovada e ver a entrega aparecer como simulada, com a mensagem exata que teria saído.
- Conferir se o link do produto está certo nessa mensagem.
- Simular um pix gerado e ver os quatro toques agendados, com as horas certas.
- Simular o pagamento desse pix e conferir que os toques pendentes foram cancelados.
- Cadastrar um produto sem link e ver a entrega travar com o aviso certo, em vez de mandar mensagem sem link.
- Mandar um telefone inválido e ver o sistema recusar em vez de tentar.

DEPOIS LIGUE O ENVIO, nessa ordem:
- Preencha as credenciais e confirme o selo de conectado no painel.
- Primeiro disparo: use o envio na mão pro SEU PRÓPRIO número. Olhe a mensagem no seu WhatsApp com olho de cliente. O texto está bom? O link abre? A quebra de linha ficou certa?
- Só então faça uma compra de teste de verdade, com o valor mais baixo que você tiver, e receba o acesso como cliente.
- Por último, gere um pix e não pague: espere o primeiro toque chegar de verdade.
Depois disso, me diga o que monitorar na primeira semana.

o que isso resolve acesso na hora, de madrugada também pix esquecido vira venda ninguém mais te cobra o link no direct

Os 3 loops, mirando o que chega no celular do cliente

Nos outros materiais, um erro aparecia numa tela sua. Aqui ele aparece na conversa de alguém que acabou de te pagar. Rode os três antes de ligar o envio.

Loop 01 · caça-problema

Pare de construir. Agora ataque o próprio trabalho, procurando tudo que faria uma mensagem errada chegar num cliente.

Investigue especificamente:
- O gateway reenvia o mesmo aviso três vezes: a pessoa recebe uma mensagem ou três?
- A pessoa paga no exato minuto em que um toque de cobrança está saindo: ela é cobrada depois de pagar?
- Compra dois produtos no mesmo pedido, ou compra o principal mais um order bump: recebe um link, dois, ou o errado?
- Produto sem link cadastrado: manda mensagem sem link ou trava e me avisa?
- Telefone com DDI de outro país, telefone fixo, telefone com nono dígito faltando, telefone escrito com máscara.
- Nome vazio, nome em caixa alta, nome com emoji: como fica o "Olá" da mensagem?
- Nome ou produto com caractere que quebra a mensagem.
- O mesmo cliente comprando de novo no dia seguinte: recebe normal?
- Reembolso depois da entrega: o sistema faz alguma coisa? Deveria?
- Conexão do WhatsApp caída na hora do disparo: a mensagem se perde ou fica na fila?
- A rotina agendada rodando duas vezes ao mesmo tempo: manda duas vezes?
- Pix gerado e cancelado pelo cliente: os toques são cancelados?
- Cem pix gerados de uma vez numa campanha: o limite por rodada segura o ritmo?
- Alguém descobre a URL do webhook e inventa uma venda: consegue fazer o sistema mandar mensagem?

Escreva a lista numerada, do mais grave pro mais bobo, com o que acontece na prática. Não conserte ainda.
Depois conserte um por um e me diga o que mudou.
No fim, rode tudo de novo. Repita até uma passagem não achar nada novo.

Loop 02 · leia como cliente

Agora esqueça o código. Você é a pessoa que acabou de comprar, ou que gerou o pix e não pagou, e essas mensagens chegaram no seu WhatsApp.

Para CADA uma das cinco mensagens (a entrega e os quatro toques), responda:
1. Ela parece escrita por uma pessoa ou por um sistema? O que exatamente entrega que é automático?
2. Dá pra saber em três segundos quem está falando e por quê?
3. Tem alguma palavra que soa a cobrança de banco, a robô ou a vendedor insistente?
4. O que essa mensagem me faz fazer? Se a resposta for "nada", ela não deveria existir.
5. Se eu já tivesse pago, essa mensagem me deixaria irritado?

Depois reescreva as cinco, mantendo:
- Primeira pessoa, do jeito que eu falo, frases curtas.
- Nenhuma promessa que o produto não cumpre.
- No máximo um emoji, e só se fizer sentido.
- Uma pergunta de verdade no primeiro toque, porque o objetivo dele é conversa, não venda.
Me mostre o antes e o depois lado a lado, e me diga em uma linha o que mudou em cada uma.

Loop 03 · o invasor

Esqueça que você construiu isso. Você é uma pessoa mal intencionada que descobriu o endereço do meu sistema. Objetivos: usar o meu número pra mandar mensagem, roubar a minha lista de clientes, ou pegar o link do meu produto de graça.

Liste tudo que tentaria e o resultado real, considerando o meu código:
- Chamar a rota do webhook inventando uma venda aprovada com o meu telefone, pra receber o link do produto sem pagar. O segredo está sendo conferido mesmo?
- Chamar a rota de envio manual sem senha.
- Abrir o painel sem senha, e chamar as rotas de dados direto.
- Disparar a rotina agendada mil vezes.
- Inventar mil vendas de uma vez pra usar o meu número como máquina de spam e me fazer tomar bloqueio.
- Mandar um nome de cliente com HTML ou script dentro e ver se executa no meu painel.
- Mandar um nome gigante ou um texto de 100 mil caracteres, e ver o que sai na mensagem.
- Ler as tabelas com a chave pública do banco: telefones e e-mails dos meus clientes. Deve dar zero. Me prove.
- Achar as credenciais do provedor de WhatsApp no que chega no navegador.
- Descobrir o link de acesso dos meus produtos por alguma rota sem senha.

Para cada item: o que tentei, o que aconteceu, e se é um buraco.
Se algo passar, me entregue a correção pronta e a explicação em português.
No fim, diga em uma frase o risco real que sobra. Aqui tem telefone de cliente e o meu número em jogo, então seja rigoroso.

Quando travar

A corrente aqui tem cinco elos: o gateway avisou, o sistema recebeu, achou o link, achou o telefone, e o provedor entregou. Quase todo problema é um desses cinco.

SOS · destravar sem piorar

Alguém não recebeu, ou recebeu errado. Antes de mexer em qualquer linha, investigue.

Quem: NOME OU TELEFONE DA PESSOA
O que era pra acontecer: DESCREVA
O que aconteceu: DESCREVA
No painel, essa entrega aparece? Com qual status? DESCREVA
O selo do WhatsApp está conectado? SIM OU NÃO
Está em modo seco? SIM, NAO OU NAO SEI

Siga exatamente esta ordem, seguindo a corrente:
1. O gateway chegou a avisar? Procure o registro cru daquele pedido no banco.
2. O sistema registrou a venda? Com qual status?
3. Achou o link daquele produto?
4. O telefone foi normalizado ou recusado?
5. O provedor aceitou o envio? Qual foi a resposta dele?
Diga em qual elo quebrou ANTES de propor qualquer correção.

Depois: a causa, mais duas hipóteses, o teste mais rápido pra confirmar, e só então a correção mínima.
No fim, refaça o caminho dessa mesma pessoa e me mostre funcionando.
Se não tiver certeza, diga que não tem certeza. Chutar correção aqui manda mensagem errada pra cliente.

o sintoma

o que é, na real

Ninguém recebeu nada, e o painel mostra tudo simulado

O sistema está em modo seco: falta credencial do provedor. É o comportamento correto, só falta ligar.

A entrega ficou como "sem link"

O produto não tem link cadastrado, ou o id do produto mudou no gateway. Cadastre na aba de links.

A entrega ficou como "sem telefone"

O gateway não pediu telefone no checkout, ou mandou num formato que não dá pra normalizar. Confira o campo no checkout.

O cliente recebeu duas vezes

Faltou a chave única de plataforma e transação, ou a entrega está sendo disparada pelo webhook e por outra rota ao mesmo tempo.

Cobrança em quem já pagou

A rotina não conferiu o status do pix imediatamente antes de mandar. Essa checagem tem que ser na hora do envio, não no agendamento.

O provedor responde 401

Credencial errada ou trocada de lugar. Na Z-API são três valores diferentes, e é fácil trocar o token da instância pelo do cliente.

O provedor aceita mas a mensagem não chega

Quase sempre o número está desconectado no aparelho, ou o telefone de destino não tem WhatsApp. Olhe o selo de conexão.

A conexão cai toda hora

Celular sem bateria, sem internet, ou o WhatsApp Web foi desconectado no aparelho. Deixe o celular carregando e não desconecte a sessão.

Mensagem saiu de madrugada

Faltou a janela de horário. Sem ela a fila dispara na hora que vencer, inclusive às 3h.

Número bloqueado pelo WhatsApp

Volume alto em pouco tempo, número novo, ou muita gente marcando como spam. Reveja o ritmo e o texto antes de ligar outro número.

As oito regras que fazem esse caminho funcionar

Nenhuma é sobre código. E aqui elas protegem duas coisas que você não pode perder: a confiança de quem comprou e o seu número de WhatsApp.

Opus, sempre

No mínimo Opus 4.8, de preferência Opus 5. O erro desse projeto não fica numa tela sua: ele chega no celular de quem acabou de te pagar.

Uma conversa só

Do prompt 01 ao 07 no mesmo chat, senão a IA reinventa o formato da venda e as duas metades param de conversar.

Modo seco primeiro

Suba sem credencial, teste tudo simulado, leia as mensagens que teriam saído. Só depois ligue o envio de verdade.

O primeiro disparo é pra você

Antes de qualquer cliente, mande pro seu próprio número e leia com olho de quem recebeu. Depois faça uma compra de teste.

Pagou, para na hora

A checagem de pagamento acontece no instante do envio, não no agendamento. Cobrar quem já pagou é o pior erro possível aqui.

Devagar é mais rápido

Limite por rodada, intervalo entre mensagens e janela de horário. Número bloqueado custa mais caro que meia hora de atraso.

Só quem tentou comprar

Esse sistema fala com quem gerou pedido no seu checkout. Lista fria e grupo não entram, nem uma vez, nem pra testar.

Proibido TODO

Repita em todo prompt: nada de função vazia, nada de "aqui você implementa". Sem isso, você recebe meia entrega bonita.

o que vem depois

Agora o pós-venda inteiro passa a ser seu.

Com a venda entrando no seu banco e o WhatsApp saindo do seu número, o que era atendimento manual vira sistema. A mesma engrenagem serve pra tudo que acontece depois do pagamento.

Boas-vindas em dois tempos: o acesso na hora, e no dia seguinte uma pergunta se conseguiu começar
Carrinho abandonado: mesma régua, outro gatilho, pra quem nem chegou a gerar o pix
Aviso de renovação e recuperação de assinatura que falhou no cartão
E o painel de vendas mostrando quanto a régua recuperou, em dinheiro

Copia o primeiro e vai.

Sete prompts. Uma conversa. No fim do dia alguém compra às duas da manhã, recebe o acesso em dez segundos e responde "que rápido", achando que você estava acordado.

Começar pelo prompt 01