🧑💼 O estagiário e o botão de enviar
Novo aqui? Publicar (também chamado de deploy, "colocar no ar") significa fazer uma versão do seu trabalho ficar visível e acessível para outras pessoas na internet — em vez de só rodar no seu computador. É a diferença entre um rascunho na sua mesa e a carta já postada no correio.
Imagine um estagiário excelente, rápido, que trabalha sozinho no rascunho de um relatório para o cliente. Ele pesquisa, escreve, revisa a formatação — tudo isso ele faz por conta própria, sem precisar de aprovação a cada frase. Mas existe uma linha que ele nunca cruza sozinho: apertar "enviar" no e-mail que vai para o cliente. Isso é decisão do gerente, sempre — mesmo que o estagiário tenha certeza de que está pronto.
O agente de código é exatamente esse estagiário. Ele pode construir, testar, ajustar o design (módulos 5.1 a 5.6) e até rodar o comando de publicação sozinho, se você deixar — ele tem a capacidade técnica. A pergunta deste módulo não é "ele consegue publicar sozinho?" (consegue). É "ele deveria?" E a resposta, por padrão, é não — até você dizer explicitamente que sim.
💡 Conceito Principal
Autonomia para construir e testar ≠ autonomia para publicar. São duas permissões diferentes, e a segunda é sempre mais restrita.
- •Um agente sem essa trava pode publicar cedo demais, com erro, ou fora de hora — e ninguém percebeu antes de ir ao ar.
- •A trava não é desconfiança do agente. É a mesma trava que existiria com um funcionário humano novo.
📜 A regra de ouro no CLAUDE.md
Novo aqui? O CLAUDE.md é um arquivo de texto simples que você deixa dentro da pasta do projeto (visto a fundo no módulo 0.4) com instruções fixas para o agente — ele lê esse arquivo automaticamente toda vez que abre o projeto. É o lugar certo para registrar uma regra que precisa valer sempre, em toda sessão, mesmo com um agente novo ou depois de meses.
A regra de ouro deste módulo é curta e deve ser escrita, palavra por palavra, perto do topo desse arquivo: o agente nunca publica ou faz deploy sozinho — só quando o humano der uma ordem explícita para aquela publicação específica. Não vale "ele já publicou antes, então pode de novo". Cada publicação é uma decisão nova.
Legenda: o agente tem liberdade total para construir e testar local (verde à esquerda) — mas antes de qualquer coisa cruzar o portão amarelo com cadeado rumo ao `git push`, precisa da sua ordem explícita. Depois do push, a ferramenta externa (amarelo tracejado à direita) publica sozinha — automática e fora do seu controle direto.
🔍 Por dentro
- Onde escrever: logo no topo do CLAUDE.md, numa seção clara tipo "Regras de publicação" — não escondida no meio do texto.
- Por que funciona: o agente lê esse arquivo antes de agir. Uma regra explícita ali pesa mais que "achar" que já pode publicar.
⚙️ O pipeline git → deploy automático
Novo aqui? Um repositório (ou "repo") é uma pasta de projeto guardada com histórico completo de versões, geralmente hospedada num serviço como o GitHub. Commit é o comando que grava uma "fotografia" das mudanças que você fez, com uma mensagem explicando o que mudou. Push é o comando que envia esses commits guardados no seu computador para o repositório na nuvem.
Aqui está o ponto que confunde muita gente que está começando: na maioria dos projetos deste curso,
"publicar" não é um botão especial de publicação. É só isso: commit
+ push pro repositório. Uma
ferramenta externa — Vercel, GitHub Pages, e outras parecidas — fica "de olho" nesse repositório e, assim
que percebe uma mudança nova, publica sozinha, sem mais nenhuma ação sua.
Isso divide o trabalho em duas partes bem separadas: a parte que você (ou o agente, com sua ordem)
controla diretamente — construir, testar, e mandar o push —
e a parte automática, que roda sozinha depois disso e está fora do seu controle direto. Não adianta ficar
checando o painel da ferramenta a cada minuto: uma vez que o push saiu, o resto é entre o repositório e a
ferramenta de publicação.
🕐 A linha do tempo de uma publicação
Construir e testar em localhost
O agente trabalha livre nessa fase (recapitulando o módulo 5.7) — sem pedir aprovação a cada ajuste.
Você olha, de verdade, a versão local
Abre no navegador, clica, confere se está como deveria. Sem pular esse passo.
Você dá a ordem explícita — "pode publicar"
Este é o portão do tópico 2. Sem essa frase, nada do que vem depois deveria acontecer.
O agente roda commit + push
O trabalho humano/agente termina exatamente aqui — no envio do código pro repositório.
A ferramenta externa publica sozinha
Vercel/GitHub Pages capta a mudança e coloca no ar — automático, fora do seu controle direto a partir daqui.
💡 Dica Prática
Se a ferramenta de publicação bloquear ou falhar depois do push, isso não é problema seu para resolver na hora — é da conta da ferramenta, e você (o humano) resolve quando fizer sentido. "Concluído" para o agente é o push ter entrado no repositório, não o site já estar no ar.
⚖️ Regras boas × regras arriscadas
Nem toda regra escrita no CLAUDE.md protege de verdade. Algumas parecem seguras mas deixam brecha; outras são explícitas o bastante para segurar o agente mesmo num dia em que ele "tem certeza" de que está tudo pronto. Compare:
✓ Regras que seguram de verdade
- ✓"Nunca rode
git pushou qualquer comando de deploy sem eu pedir explicitamente, mesmo que os testes locais tenham passado." - ✓Regra escrita perto do topo do arquivo, em destaque — não enterrada no meio de outras 40 linhas.
- ✓Cada publicação exige uma ordem nova — "publicado antes" não vira permissão permanente.
- ✓Regra separa claramente "testar local" (livre) de "publicar" (com ordem).
✗ Regras que dão falsa sensação de segurança
- ✗"Tenha cuidado ao publicar" — vago demais, o agente decide o que é "cuidado".
- ✗Nenhuma regra escrita — confiar só no "bom senso" do agente naquela sessão.
- ✗"Pode publicar sempre que os testes passarem" — testes automatizados não pegam tudo que um humano vê olhando de verdade.
- ✗Regra dada só de boca, numa conversa antiga, e nunca escrita no CLAUDE.md — some quando a sessão termina.
📝 O que colocar no CLAUDE.md, na prática
- 1. A regra de ouro (tópico 2) — palavra por palavra, sem margem para interpretação.
- 2. O que conta como "publicar" nesse projeto específico — nem sempre é só
git push; às vezes inclui rodar um comando de deploy manual. - 3. Onde testar antes — qual endereço de localhost olhar, o que checar (recapitula o módulo 5.7).
- 4. O que fazer se a publicação falhar — normalmente: avisar o humano, não tentar resolver sozinho re-disparando o deploy.
🛠️ Escrevendo e autorizando na prática
Três passos para deixar isso funcionando de verdade no seu projeto: escrever a regra, testar em localhost antes de qualquer publicação, e só então autorizar o push com uma frase explícita. Vamos direto ao que colar.
Cole a regra no CLAUDE.md do seu projeto
Objetivo: deixar a trava escrita e permanente, não uma combinação verbal que some quando a sessão fecha.
## Regras de publicação - **Nunca publicar/fazer deploy sem ordem explícita.** Isso inclui `git push`, qualquer comando de deploy manual, ou reativar um deploy travado. - Construir e testar em `<endereço do seu localhost>` são livres — não precisam de aprovação a cada passo. - Publicar só depois que eu disser algo como "pode publicar" ou "manda pro ar" — palavras explícitas, referidas a ESSA mudança específica. - Se a publicação falhar depois do push, avise-me. Não tente resolver sozinho re-disparando o deploy.
Como verificar: abra o CLAUDE.md e confirme que a seção está perto do topo, visível, sem precisar rolar a página inteira para achar.
Sempre olhe o localhost antes de autorizar
Recapitulando o módulo 5.7: peça ao agente para rodar o servidor local e abra o endereço no navegador de verdade. Clique nos links, teste no celular se for responsivo. Nunca autorize publicação "de confiança", só pela descrição do que foi feito.
Autorize com uma frase clara, e deixe o agente rodar o push
Objetivo: transformar a autorização verbal num comando real de publicação, sem o agente ter que adivinhar a sintaxe.
git add <arquivos que mudaram, ou . se for tudo> git commit -m "<mensagem curta explicando o que mudou>" git push
Como verificar: rode git log -1 e confira se o commit aparece com a mensagem certa; depois confira no painel do repositório (GitHub) se o push chegou. "Concluído" termina aqui — não precisa ficar checando se o site já atualizou.
⚠️ Atenção
"Pode continuar" ou "tá bom" NÃO são ordens de publicação — são só aprovação de um passo de trabalho. A frase de publicação precisa ser inequívoca: "pode publicar", "manda pro ar", "autorizado o deploy". Se estiver em dúvida se a frase do humano contava como autorização, o comportamento certo do agente é perguntar antes de rodar o push, não presumir.
🎯 Os 40% que fecham a trilha
Desde o módulo 5.1 essa trilha repete um número: o agente entrega rápido uns 60% de qualquer interface — genérica, funcional, mas sem alma — e os últimos 40% (a marca, o polimento, a decisão fina) dependem de você entrar com referência, gosto e revisão. Este módulo mostra que o mesmo princípio vale para a publicação: os últimos 40% não são só estéticos, são de governança — quando e se algo vai ao ar é sempre uma decisão sua, nunca delegada por padrão.
Isso não é burocracia nem falta de confiança no agente. É a mesma disciplina que qualquer equipe séria tem com qualquer pessoa nova: liberdade total para produzir, e uma aprovação final que nunca é automática. Separar "eu construí e testei local" de "eu autorizei publicar" em duas frases diferentes é o que garante que um erro de um passo nunca vire um problema no ar sem ninguém ter revisado.
🧵 O fio condutor da Trilha 5
- •5.1–5.4: por que o padrão sai genérico e como fechar o laço olhando de verdade (screenshot).
- •5.5–5.6: como trazer referência visual e marca própria — a parte que o agente não inventa sozinho.
- •5.7–5.8: construir, testar local, e só publicar com autorização explícita — a última decisão sempre humana.
✓ Checklist final da trilha
- ✓CLAUDE.md do projeto tem a regra de publicação escrita perto do topo.
- ✓Você sabe qual endereço de localhost abrir para testar cada projeto.
- ✓Você tem uma frase de autorização clara e sempre a usa antes do push.
- ✓Você sabe onde termina o trabalho do agente (push) e onde começa o automático (deploy).
✗ Erros comuns a evitar
- ✗Deixar o agente com autonomia de deploy "sem querer" — configurando um MCP ou permissão ampla demais sem pensar nessa consequência.
- ✗Esquecer de testar em localhost e autorizar só pela descrição do que foi feito.
- ✗Tratar "pode continuar" como se fosse "pode publicar".
- ✗Ficar cutucando a ferramenta de deploy depois do push, tentando "resolver" algo que não é sua responsabilidade direta.
✏️ Exercício
Abra o CLAUDE.md de um projeto real seu (ou crie um, se ainda não tem) e escreva sua própria versão da regra de publicação — use o bloco do tópico 5 como ponto de partida, mas adapte pro seu caso: qual é o endereço de localhost, o que conta como "publicar" nesse projeto, e qual frase você vai usar para autorizar. Depois, na próxima vez que for publicar algo com o agente, teste se ele respeitou a regra antes de rodar o push.
Checagem rápida (opcional): o que separa "testar em localhost" de "publicar", segundo a regra de ouro deste módulo?