🧩 Por que quebrar o fluxo em tarefas pequenas
Novo aqui? Uma task (tarefa) é um pedaço isolado de trabalho dentro de uma automação — por exemplo "buscar o e-mail novo" é uma task, "gravar no banco de dados" é outra. Pense numa linha de montagem: se a etapa de pintura falhar, você não desmonta o carro inteiro e recomeça do zero — você conserta só a pintura.
No seu laptop, quando um script quebra no meio, você vê o erro na tela, aperta uma tecla e roda de novo. Na nuvem, ninguém está olhando. Se a automação inteira for "um bloco só" e qualquer parte falhar, ou tudo roda de novo do início (gastando tempo e, às vezes, repetindo uma ação que já tinha dado certo), ou tudo trava e fica esperando você notar. Nenhuma das duas é boa.
💡 Conceito Principal
Automação boa é feita de tarefas pequenas e independentes. Se uma falha, só ela repete — o resto do trabalho que já deu certo fica de pé.
- •Bloco único: falhou em qualquer ponto, refaz tudo (ou trava tudo).
- •Tarefas pequenas: falhou uma, só ela repete — as outras nem percebem.
🔁 O que é uma retentativa, na prática
Novo aqui? Retentativa (em inglês, retry) é a plataforma tentando de novo, sozinha, uma tarefa que falhou — sem você precisar apertar botão nenhum. É como ligar de novo pra alguém quando a chamada cai: você não desiste na primeira tentativa, tenta de novo em alguns segundos.
A maioria das falhas em automação não é "está tudo quebrado" — é passageira: o serviço externo estava sobrecarregado por dois segundos, a internet engasgou, o servidor demorou um pouco além do esperado. Uma retentativa automática resolve a maior parte disso sem ninguém perceber.
Legenda: uma falha isolada quase sempre resolve na 2ª ou 3ª tentativa, sem intervenção humana. Só quando as tentativas se esgotam é que um alerta chega até você.
🔍 Por dentro
- Tentativas com espera crescente: a plataforma não insiste imediatamente — ela espera um pouco mais a cada tentativa, pra dar tempo do problema passar.
- Limite de tentativas: depois de um número definido (normalmente 3), a plataforma desiste e marca a tarefa como falha, te avisando.
📥📤 Buscar dado não é gravar dado
Aqui está o motivo real de quebrar em tarefas pequenas: buscar um dado (ler um e-mail, consultar uma planilha) pode repetir à vontade sem problema — ler de novo não muda nada. Já gravar um dado (mandar um e-mail, criar uma cobrança, salvar um registro novo) é diferente: se a retentativa repetir essa parte, você pode acabar com o e-mail mandado duas vezes, ou o mesmo registro duplicado no banco.
Por isso a regra prática: separe "buscar" de "gravar" em tarefas diferentes. Se a tarefa de gravar falhar depois que a de buscar já funcionou, a retentativa repete só a gravação — sem buscar (e sem arriscar duplicar) o dado de novo.
✓ Tarefas separadas
- ✓Task 1 busca o pedido novo. Task 2 grava a confirmação. Se a 2 falhar, só ela repete.
- ✓Repetir a gravação é seguro porque ela já sabe exatamente qual pedido confirmar.
- ✓Nenhum e-mail duplicado, nenhuma cobrança duplicada.
✗ Tudo em uma tarefa só
- ✗Uma única task busca o pedido e já grava a confirmação, no mesmo passo.
- ✗Se falhar depois de gravar (por exemplo, ao registrar que terminou), a retentativa refaz tudo — inclusive a gravação que já tinha acontecido.
- ✗Resultado: e-mail duplicado ou cobrança duplicada, sem ninguém perceber na hora.
💡 Dica Prática
Ao pedir uma automação pro Claude Code, diga explicitamente "separe a etapa de buscar da etapa de gravar, em tasks diferentes". É uma frase simples que evita boa parte dos problemas de duplicidade.
🚦 A fila: quem espera a vez
Novo aqui? Uma fila é uma lista de tarefas esperando a vez de rodar, igual fila de banco: cada uma é atendida em ordem, uma de cada vez (ou algumas em paralelo, dependendo da configuração), sem depender de você estar olhando. Se chegam 50 pedidos ao mesmo tempo, eles entram na fila e vão sendo processados sem travar o sistema todo.
A fila trabalha junto com a retentativa: quando uma tarefa falha, em vez de sumir, ela pode voltar pro fim da fila pra tentar de novo depois. É esse mecanismo, junto, que dá a uma automação a resiliência de rodar 24 horas sem alguém cutucando ela toda hora.
O evento acontece
Um pedido novo chega, um horário agendado bate — a tarefa entra na fila.
A plataforma tira uma da vez
Sem sobrecarregar o sistema — se chegam 50 de uma vez, ela processa no ritmo que aguenta.
Deu certo, sai da fila
Fica registrado no painel de execuções (módulo 4.7) como concluída.
Falhou, volta pra fila (com retentativa)
Espera um pouco, tenta de novo — até o limite de tentativas do tópico 2.
📋 Por que o modo plano pesa mais aqui
Lá no módulo 0.5 você aprendeu o modo plano: pedir pro Claude Code mostrar o passo a passo antes de agir, pra você revisar antes de qualquer mudança de verdade. Em tarefas locais, um bug vira um arquivo bagunçado que você conserta em segundos. Em produção, um bug numa automação que roda sozinha custa dado duplicado ou uma ação real feita errado — um e-mail que foi mandado duas vezes pro cliente, uma cobrança duplicada no cartão de alguém.
Por isso, ao pedir pro agente escrever ou alterar uma automação que vai rodar em produção — principalmente se ela grava dados ou envia coisas pra fora —, use o modo plano sempre. Leia o plano com atenção especial pra pergunta: "isso separa buscar de gravar? Isso é seguro de repetir se falhar no meio?"
✓ Antes de publicar uma automação
- ✓Pediu o plano e leu antes de aprovar a mudança
- ✓Confirmou que buscar e gravar estão em tasks separadas
- ✓Testou em dev (módulo 4.3) antes de tocar em produção
✗ Publicando no impulso
- ✗Aceitou a mudança sem olhar o plano
- ✗Não perguntou o que acontece se a task falhar no meio
- ✗Foi direto pra produção sem passar por dev
⚠️ Atenção
Reforçando o padrão "Novo aqui?": idempotência é o nome técnico pra uma tarefa que pode ser repetida várias vezes sem mudar o resultado (repetir "buscar" é idempotente; repetir "gravar" pode não ser). Você não precisa memorizar o termo — precisa lembrar da regra prática: separe buscar de gravar.
✅ Checklist antes de publicar uma automação
Antes de escrever o código de verdade (isso vem no módulo 4.6, o Build desta trilha), vale ter uma pergunta pronta pra fazer ao Claude Code — em texto simples, sem precisar entender programação.
Objetivo: pedir pro agente revisar o desenho da automação antes de escrever o código, aplicando o que este módulo ensinou.
Antes de escrever o código desta automação, me mostre o plano dividido em
tarefas pequenas (tasks). Para cada task, diga: (1) ela só busca dado, ou
também grava/envia algo pra fora? (2) se ela falhar no meio e a plataforma
tentar de novo automaticamente, existe risco de duplicar um e-mail, uma
cobrança ou um registro? Se existir, ajuste o plano separando busca de
gravação antes de eu aprovar.Como verificar: a resposta deve listar tasks separadas com nomes claros (ex.: "buscar pedidos novos", "gravar confirmação") e explicar, pra cada uma que grava algo, por que é seguro repetir sem duplicar. Se a resposta só disser "sim, está tudo certo" sem explicar o porquê, peça de novo com mais detalhe.
🎯 Conceito Principal
- •Tarefas pequenas → falha isolada → estrago pequeno.
- •Retentativa cuida do "tenta de novo"; separar buscar de gravar cuida do "sem duplicar".
- •Fila garante que nada se perde mesmo quando muita coisa chega de uma vez.
Checagem rápida (opcional): por que separar "buscar dado" de "gravar dado" em tarefas diferentes?