Loop de Desafio (Gauntlet Loop)
Transforme as instruções ou objetivo iniciais de um usuário em um Loop de Desafio (Gauntlet Loop) — um ciclo autônomo de feedback construtor-versus-crítico baseado na técnica Claude of Duty de Matt Shumer, robonuggets/gauntlet-loop, duolahypercho/gauntlet-loop e no AI Loop Engineering Three-Elements Framework.
A maioria das saídas de agentes para em "bom o suficiente para IA" porque o construtor avalia seu próprio trabalho com base em palavras vagas. Um Loop de Desafio substitui o prompt único por um ciclo persistente construído sobre três elementos centrais:
- Objetivo: A entrega concreta e o estado de resultado que deve se tornar verdadeiro.
- Referência ou Métrica (O Padrão e o Crítico Severo): Um benchmark nomeado, buscável e comparável lado a lado — emparelhado com testes ou métricas objetivas, quando aplicável — julgado às cegas por um crítico separado com contexto novo.
- Limite: Critérios de sucesso explícitos, limites de rodadas/estagnação, regras de mudança de estratégia e portões de segurança/permissão que controlam quando o loop para ou escala.
Etapa 1: Identificar as Instruções Iniciais e o Contexto
- Se o usuário passou instruções embutidas com
/gauntlet-loop <instruções>, use-as como semente. - Se o usuário invocou
/gauntlet-loopsem argumentos durante uma conversa em andamento, use a tarefa, plano ou prompt atual em discussão. - Se não houver uma tarefa clara na mensagem ou no histórico da conversa, pergunte ao usuário o que ele deseja construir ou alcançar antes de prosseguir.
- Se a tarefa envolver uma base de código ou espaço de trabalho local, inspecione rapidamente a estrutura de diretórios, a pilha de tecnologia, o executor de testes ou os scripts de compilação para que suas propostas padrão façam referência a ferramentas e comandos reais do projeto.
Etapa 2: Esclarecer os Três Elementos do Loop (Propondo Padrões)
Audite a solicitação do usuário em relação aos Três Elementos Centrais abaixo. Sempre que qualquer elemento estiver ausente, subespecificado ou usar um padrão de qualidade vago, peça ao usuário para confirmar ou ajustar os três elementos enquanto propõe padrões concretos e opinativos.
Regra de caminho rápido: Se o usuário já forneceu um Objetivo claro, uma Referência/Métrica específica e buscável, e Limites claros — ou disse explicitamente "usar padrões" / "apenas escreva o prompt" — pule a pergunta e vá diretamente para a Etapa 3 usando seus melhores padrões.
1. Objetivo (Qual Resultado Concreto Deve se Tornar Verdadeiro?)
- Substitua intenções vagas ("melhorar o site", "escrever um bom CLI") por um estado de resultado observável e uma entrega ("Construir uma página de preços SaaS responsiva em Next.js + Tailwind onde um visitante de primeira viagem possa comparar todos os planos e concluir a compra no celular").
- Padrão Proposto: Elabore um Objetivo aprimorado de 1–2 frases (incluindo a pilha de tecnologia ou formato detectado/recomendado) para o usuário aprovar ou ajustar.
2. Referência ou Métrica (O Padrão de Qualidade e o Juiz Externo)
Tudo em um Loop de Desafio depende do padrão de qualidade. Uma referência válida deve passar em três testes:
- Nomeada: Um artefato específico do mundo real, não um adjetivo ou categoria. ("Página de preços ao vivo do Stripe" ou "Capturas de tela de combate de Hades" funcionam; "design SaaS premiado" ou "qualidade AAA" sozinhos falham.)
- Buscável / Inspecionável: O crítico pode realmente obtê-lo e inspecioná-lo durante a execução — capturar a tela da URL ao vivo, ler o artigo publicado, executar o binário ou inspecionar o repositório. Se o agente não puder buscar a referência, ele alucinará a comparação e aprovará trabalho medíocre.
- Comparável: Tanto nossa saída real quanto a referência podem ser colocadas lado a lado com rótulos removidos para que um crítico novo possa fazer uma escolha binária A/B cega ("Qual vence?") e nomear a maior lacuna restante única. Nunca use uma pontuação numérica de 1 a 10, que tende a aumentar a cada rodada.
Gosto + Número vence apenas gosto: Sempre que o objetivo tiver uma dimensão mensurável (conjunto de testes unitários/integração, latência p95, pontuação Lighthouse/acessibilidade, transbordamento horizontal zero em 360px, taxa de transferência de benchmark, contagem de palavras ou rastreamento de citações de fontes primárias), emparelhe a referência qualitativa com um verificador objetivo rígido.
| Tipo de Objetivo | Referência + Métrica que Funciona |
|---|---|
| Site, App, UI | URL ao vivo de um produto específico de melhor qualidade (linear.app, stripe.com/pricing, vercel.com) capturado em viewports de desktop e celular + zero erros de console/acessibilidade/transbordamento |
| Código, CLI, Biblioteca | Um repositório ou implementação de código aberto nomeado (ripgrep, jq, esbuild) + um conjunto de testes automatizados, fuzzer de propriedades e script de benchmark de latência/taxa de transferência |
| Jogo, 3D, Interativo | Capturas de tela ou filmagens reais de jogo de um título nomeado lançado (Call of Duty, Hades, Brotato) comparadas com quadros em tempo real + verificação de FPS alvo / jogabilidade |
| Escrita, Documentação, Explicador | 2–3 peças publicadas específicas de um autor ou publicação nomeada (ex.: Julia Evans, Stripe Engineering Blog, Gwern) comparadas às cegas com créditos removidos + verificação de comprimento/tempo de leitura alvo |
| Pesquisa, Estratégia, Análise | Um relatório de analista nomeado, seção de métodos de artigo de benchmark ou memorando de vendas a descoberto forense + reconciliação automatizada de todas as alegações contra os dados brutos da fonte |
| Apresentação de Slides, Entrega | Um deck público específico ou memorando de uma empresa de referência com a mesma contagem de páginas/slides + verificação de clareza narrativa |
- Padrão Proposto: Ofereça 2 a 3 candidatos nomeados, específicos e buscáveis (marcando o mais difícil genuinamente alcançável como
(Recomendado)), emparelhados com uma métrica/verificador objetivo concreto.
3. Limite (Condições de Parada, Orçamentos e Portões de Segurança)
"Loop até a perfeição total" motiva o crítico, mas um loop ilimitado contra um padrão inatingível pode girar para sempre, queimar tokens ou fazer alterações inseguras. Defina limites explícitos em três sub-eixos:
- Parada por Sucesso e Convergência: Saia quando cada componente passar em seu verificador objetivo e vencer a comparação cega contra a referência (ou quando o "freio" designado pelo humano parar a execução).
- Limite de Iteração e Estagnação: Limite as rodadas por componente (padrão: máx. 5 rodadas por peça ou pare após 2 rodadas consecutivas sem melhoria significativa). Exija que o construtor mude de estratégia se a mesma lacuna falhar duas vezes seguidas.
- Portão de Permissões e Segurança: Permita leitura local, rascunho, edição, compilação, renderização e teste. Proíba ações irreversíveis ou externas sem aprovação humana explícita (sem implantação em produção, exclusões destrutivas, gastos com API pagos, alterações de credenciais/segredos ou mensagens externas).
Como Perguntar ao Usuário
Se for necessário esclarecimento, apresente um prompt breve e escaneável (ou use a ferramenta estruturada ask_question do harness, se disponível) cobrindo apenas os elementos não resolvidos, com padrões pré-preenchidos para que o usuário possa responder com uma única abreviação (ex.: "1, usar padrões"):
- Objetivo: Declare seu Objetivo aprimorado proposto + pilha e pergunte se algo deve mudar.
- Referência e Métrica: Liste 2–3 candidatos nomeados e buscáveis (
A,B,C, comA (Recomendado)) mais o verificador/teste objetivo proposto. - Limite: Proponha a condição de parada padrão (ex.: Vença A/B cego + passe nas verificações, máx. 5 rodadas/peça, mude de estratégia após 2 falhas idênticas, edições apenas locais) OU "Humano como freio (continue em loop até eu parar)", e pergunte qual modo preferem.
Etapa 3: Saída do Loop de Desafio Transformado
Depois que o Objetivo, Referência/Métrica e Limite forem escolhidos (ou padronizados), apresente o resultado em três partes:
1. Cartão de Design do Loop de Desafio
Produza uma tabela de resumo concisa fixando a arquitetura do loop:
- Objetivo: A entrega exata e o resultado que deve se tornar verdadeiro.
- Referência (Gosto): O artefato nomeado e buscável e como será buscado/inspecionado antes da construção.
- Métrica Objetiva (Número): O teste automatizado, benchmark, verificação de layout ou verificação factual necessária antes de uma revisão do crítico.
- Regra de Decomposição: Como o trabalho se divide em peças pequenas e julgáveis independentemente (paralelizando apenas partes genuinamente independentes; mantendo sistemas fortemente acoplados sob posse sequencial coerente).
- Protocolo do Crítico: Subagente separado com contexto novo; inspeciona o artefato real renderizado/executado (nunca o resumo do construtor); executa uma comparação A/B cega com rótulos removidos; faz uma escolha binária e nomeia a maior lacuna restante única.
- Estado e Progresso: O arquivo usado para persistir a memória do loop (
GAUNTLET_PROGRESS.mdou uma página de progresso ao vivo) registrando partes concluídas, evidências, abordagens falhadas e lacunas restantes para que o contexto não se deteriore. - Limite: As regras ativas de parada, limites de rodadas e portões de segurança.
2. O Prompt do Loop de Desafio
Produza um prompt autocontido e pronto para copiar e colar dentro de um bloco markdown com cerca. Forneça o Prompt Universal do Loop de Desafio abaixo (adaptado à tarefa, ferramentas e pilha do usuário) e, se o usuário quiser o estilo ultracompacto de 3 parágrafos de Matt Shumer ou comandos de loop específicos do harness, adapte a cauda final de acordo (consulte references/examples.md).
Construa [ENTREGA / OBJETIVO] em [PILHA / FORMATO].
## 1. O Padrão de Qualidade e a Métrica (Busque Primeiro)
O padrão de qualidade é [REFERÊNCIA NOMEADA E BUSCÁVEL]. Antes de construir ou julgar, busque e inspecione a referência real diretamente ([COMO BUSCAR: capture a tela da URL ao vivo em desktop e celular / extraia o texto publicado / clone ou execute a implementação de referência]) — nunca compare com uma memória ou descrição dela.
Cada peça também deve passar nestas verificações objetivas: [MÉTRICAS / TESTES / BENCHMARKS OBJETIVOS].
## 2. Decomposição e Posse
Divida o trabalho nas menores peças que podem ser construídas, verificadas e julgadas por conta própria: [PEÇAS CANDIDATAS INICIAIS].
- Distribua subagentes construtores em paralelo SOMENTE para peças que são genuinamente independentes.
- Mantenha sistemas fortemente acoplados sob posse sequencial e coerente para que os componentes não colidam.
## 3. O Loop Construtor vs. Crítico Severo
Para cada peça, execute um construtor e um subagente crítico separado com contexto novo (sem acesso à cadeia de pensamento ou desculpas do construtor):
1. **Construa e Verifique**: O construtor cria ou revisa a peça e executa as verificações objetivas ([TESTES / LINT / BENCHMARK / RENDERIZAÇÃO]).
2. **Inspecione o Artefato Real**: O crítico abre e inspeciona a saída real ([CAPTURAS DE TELA / BINÁRIO EM EXECUÇÃO / LOGS DE TESTE / TEXTO RASCUNHADO]) — nunca o resumo do construtor.
3. **Escolha A/B Cega**: O crítico coloca nosso artefato ao lado de [REFERÊNCIA NOMEADA] às cegas com rótulos removidos, faz uma escolha binária de qual é melhor e, se o nosso perder, identifica a **maior lacuna restante única** com evidências concretas e a envia de volta ao construtor.
4. **Sem Notas Suaves**: O crítico deve ser impiedosamente severo. Elogios e pontuações numéricas de 1 a 10 são proibidos. Se o nosso não vencer a comparação cega e passar em todas as verificações objetivas, continue em loop.
## 4. Rastreamento de Estado e Mudanças de Estratégia
Mantenha um `GAUNTLET_PROGRESS.md` compacto (e/ou uma visualização de progresso ao vivo) após cada rodada registrando: peça atual, número da rodada, veredito do crítico, a lacuna única alvo, abordagens falhadas e resultados das verificações objetivas. Se a mesma lacuna falhar duas vezes seguidas, abandone a abordagem atual e tente uma estratégia estruturalmente diferente.
## 5. Passagem de Integração Final e Limites
- **Crítico de Integração**: Assim que as peças individuais vencerem, crie um crítico de integração novo para inspecionar o artefato montado completo de ponta a ponta quanto a consistência, emendas, desempenho e adequação ao objetivo original.
- **Limites**: [CONDIÇÕES DE PARADA: ex.: Pare quando todas as peças + integração vencerem o A/B cego e passarem em todas as verificações objetivas, ou após N rodadas por peça / 2 rodadas consecutivas sem ganho mensurável]. Ações permitidas: [AÇÕES LOCAIS PERMITIDAS]. Não faça [AÇÕES PROIBIDAS: implantar em produção, excluir dados, gastar dinheiro ou tocar em credenciais] sem aprovação humana explícita.
[CAUDA DO LOOP DO HARNESS: Continue em loop até o crítico escolher o nosso em cada peça, executando construtores e críticos como subagentes. / Ou para Claude Code: `/loop` em cada peça até vencer; distribua subagentes e `ultracode`. / Ou para Codex: `/goal` até cada peça vencer.]
3. Oferta de Execução
Termine perguntando:
"Gostaria que eu executasse este Loop de Desafio agora como orquestrador principal, ajustasse algum dos três elementos (Objetivo, Referência/Métrica, Limite) ou mudasse o estilo do prompt (Universal Limitado vs. Prompt Clássico de 150 Palavras para Claude
/loopou Codex/goal)?"
Se o usuário disser para executar, adote imediatamente o prompt gerado como suas instruções operacionais ativas: busque a referência primeiro, inicialize GAUNTLET_PROGRESS.md, decomponha as peças e inicie a Rodada 1.
O que Quebra um Loop de Desafio (Barreiras de Proteção)
Nunca permita que esses modos de falha entrem em um prompt de Desafio gerado:
- Um padrão vago ou não buscável: "Torne-o de classe mundial" ou nomear um artefato atrás de paywall/inacessível força o crítico a alucinar a comparação e carimbar tudo.
- O construtor julgando seu próprio trabalho: Um construtor se lembra de cada compromisso que fez e os racionaliza. O crítico deve ser um subagente com contexto novo (ou uma passagem de verificação limpa despojada de justificativas do construtor).
- Pontuações numéricas de 1 a 10 em vez de uma escolha binária: Pontuações de 10 flutuam de 7/10 para 9/10 automaticamente ao longo das rodadas. Exija uma escolha binária A/B cega ("Qual vence?") mais a maior lacuna restante única.
- Crítico lendo resumos em vez de inspecionar o artefato: Um relatório de status markdown brilhante não é evidência. O crítico deve inspecionar pixels renderizados, executar o binário/testes ou ler o texto real.
- Paralelizar código fortemente acoplado: Distribuir 10 subagentes no mesmo loop de estado ou pipeline de renderização compartilhado causa colisões de mesclagem e emendas visuais. Paralelize apenas peças independentes e exija posse sequencial para o resto.
- Sem limite de rodadas ou freio humano: Um loop sem limite de rodadas ou condição de parada queima tokens em retornos decrescentes ou piora a saída. Sempre inclua um limite de rodadas por peça, uma regra de mudança de estratégia e um portão de segurança.
- Métrica objetiva ausente quando mensurável: Apenas o gosto sem um número permite a aprovação de saídas que parecem boas, mas falham em testes, quebram layout ou estão factualmente erradas. Inclua verificações automatizadas sempre que possível.