Claude Code Harness Smoke Test: prova de 15 minutos antes de confiar em um agente

A primeira tarefa séria com Claude Code não precisa de uma grande automação. Precisa de um pequeno smoke test. Defina arquivos lidos, arquivos editáveis, áreas proibidas e a prova que encerra o trabalho.

A intenção é prática: saber até onde delegar a um agente. Em um site de receita, a prova inclui PDF grátis, Gumroad e consultoria, não apenas build local.

Leituras relacionadas: Claude Code harness engineering, first repo audit checklist, permission safety ladder.

Por que este padrão funciona

O harness smoke test não prova que o modelo é sempre seguro. Ele prova que o ambiente tem limites. Uma pequena mudança pode quebrar formulário, link de produto ou caminho de consultoria.

Quinze minutos é curto o bastante para repetir todo dia: leitura, edição limitada, build, URL pública e captura.

Fluxo prático

1. Escreva o objetivo em uma frase e limite a edição a três arquivos
2. Marque segredos, pagamento, dados de clientes e deploy como áreas bloqueadas
3. Escolha antes da edição o comando de prova, diff, URL e captura
4. Em artigos e páginas, inclua PDF grátis, Gumroad e consultoria na checagem
5. Guarde o run card para a próxima tarefa começar com evidência

Situação	Ação segura	Prova
Novo artigo	Permitir apenas corpo e frontmatter; layouts e API ficam leitura	build e URL pública
Página de produtos	Mudar texto e ordem dos cards; conferir links de compra	checagem Gumroad
Adoção em equipe	Começar em leitura e permitir só uma alteração pequena	diff e captura

Prompt e código para copiar

Execute um harness smoke test de 15 minutos neste repositório. Ainda não faça edição ampla. Retorne objetivo, arquivos editáveis, áreas bloqueadas, comandos de prova, checagens de URL pública e CTAs de PDF/Gumroad/consultoria.

const runCard = {
  slug: "claude-code-harness-smoke-test-loop",
  goal: "publish one safe content change",
  allowedFiles: ["site/src/content/blog-en/example.mdx"],
  blockedAreas: [".env", "billing/", "cloudflare/"],
  proof: ["npm.cmd run build", "public URL screenshot"],
  ctas: ["free PDF", "Setup Guide", "consultation"]
};

function readyForAgent(card) {
  return card.allowedFiles.length > 0 &&
    card.blockedAreas.length > 0 &&
    card.proof.some((item) => item.includes("build")) &&
    card.ctas.length >= 3;
}

console.log(readyForAgent(runCard) ? "ready" : "tighten scope");

O código transforma um pedido vago em run card. Use a mesma forma em PR, checklist de publicação ou preparação de consultoria.

Três exemplos reais

Publicação Astro

Limite a edição a corpo, heroImage e CTA. Build verde não basta se h1 ou CTA em produção apontam para outra página.

Pequena mudança de UI

Mesmo texto de botão pede revisão em mobile e área de toque. Se leva a produto, confira a URL.

Primeira adoção de equipe

Não comece codando. Mapeie README, permissões, testes e áreas bloqueadas. Isso vira pauta.

Falhas a evitar

• Pedir para melhorar tudo aumenta demais o escopo.
• Parar no build local esconde fallback e CTA antiga.
• Não checar Gumroad pode mandar iniciantes para a oferta errada.

Em vários idiomas, o slug pode estar certo enquanto texto e CTA estão antigos. Confira a página pública.

Como ligar PDF grátis, Gumroad e consultoria

Quem ainda aprende comandos começa pelo cheatsheet grátis. Para permissões, CLAUDE.md, hooks, MCP ou CI, use o Setup Guide.

Para prompts repetidos de review e debug, use 50 Prompt Templates. Para rollout de equipe, siga para consultoria. Compare recursos em products.

O que verificar antes e depois de publicar

Antes de publicar, confira frontmatter, heroImage, links internos e Gumroad. Depois, em mobile, veja h1, início do texto e CTA. HTTP 200 não basta se for fallback.

Métricas para acompanhar

Acompanhe busca, inícios de PDF, cliques Gumroad, visitas a produtos e consultoria. PV sem clique de produto indica CTA fora de estágio.

Revisão operacional de 30 minutos

Quando o harness smoke test entra no trabalho real, a revisão mais útil acontece no dia seguinte. Leia o log e anote escopo permitido, arquivos alterados, comandos de prova e páginas públicas inspecionadas. Não escreva só “verificado”; registre h1 mobile, início do texto, área CTA, link Gumroad e caminho de consultoria.

Separe confiança do operador e comportamento do leitor. Do lado operacional, confirme áreas bloqueadas, build, mesmo slug público e ausência de corpo em inglês nas páginas traduzidas. Do lado do leitor, confirme o próximo passo: PDF grátis para comandos, Gumroad para gargalo repetível e consultoria para desenho de workflow.

Transforme a revisão em uma regra futura. Não adicione dez regras por problema. Adicione uma: perguntar antes de mexer em layout, clicar cada URL Gumroad em produção ou capturar o início do texto em cada idioma. Regra pequena executada todo dia vale mais que política longa.