{"content_id":"z9qcc6lzi3","slug":"claude-code-loop-engineering-guide","locale":"pt","schema_type":"TechArticle","category":"tutorial","category_name":"Tutorial","title":"Guia de Claude Code Loop Engineering: 4 Loops e design de automação segura","summary":"O Loop do Claude Code é uma estrutura de controle que faz o agente repetir observação, ação e verificação até uma condição de encerramento. Explica as diferenças entre os quatro tipos de Loop e métodos práticos de design que incluem evidências de verificação, hard stop, idempotência, custos e privilégio mínimo.","author":{"name":"Injoys Admin","url":"https://injoys.com/ko/about"},"key_points":["O Loop do Claude Code não é um loop de código, mas uma estrutura de execução de agente que repete observação, ação e verificação até uma condição de encerramento.","Turn-based transfere o procedimento de verificação; Goal-based, o julgamento de encerramento; Time-based, o momento de reexecução; e Proactive transfere o início da tarefa e a orquestração ao sistema.","Um bom Loop deve ter condições de conclusão mensuráveis, evidências externas de verificação, encerramento forçado, idempotência e privilégio mínimo.","O modelo de avaliação `/goal` julga apenas as evidências expostas na conversa, portanto é preciso relatar claramente a saída dos testes, o código de encerramento e o escopo das alterações.","Transformações determinísticas devem ser tratadas por Script, e Dynamic Workflow e múltiplos agentes só devem ser aplicados a trabalhos de grande escala que realmente exijam paralelismo."],"content_markdown":"O Loop do Claude Code não é simplesmente um recurso para executar o modelo por mais tempo. O ponto central está em posicionar **Trigger, Verifier, Success condition, Hard stop, Permission boundary** ao redor de um AI Agent que age probabilisticamente, transformando tarefas repetitivas em um sistema controlável. Este artigo organiza de uma só vez as diferenças entre Turn-based, Goal-based, Time-based e Proactive Loop, além dos princípios de design prático.\n\n## 1. O que é Loop no Claude Code\n\nAqui, Loop não é uma instrução `for` ou `while` de uma linguagem de programação. O Loop descrito pela equipe do Claude Code é uma estrutura de execução em que o Agent observa o estado atual, age, verifica o resultado e volta a trabalhar até que a condição de encerramento seja satisfeita.\n\n```text\nInício da tarefa\n  ↓\nEntendimento do estado e do código\n  ↓\nElaboração do plano\n  ↓\nAlteração de código ou execução de ferramenta\n  ↓\nTeste·verificação\n  ↓\nCondição de conclusão satisfeita?\n  ├─ Não: próxima iteração\n  └─ Sim: encerrar e relatar resultado\n```\n\nAo distinguir Loops, as quatro perguntas a seguir são úteis.\n\n1. O que inicia a tarefa?\n2. O que encerra a tarefa?\n3. Qual recurso do Claude Code controla a repetição?\n4. Para que tipo de tarefa ele é adequado?\n\nNão é necessário transformar todo trabalho em um Loop complexo. Para tarefas cujo resultado pode ser confirmado imediatamente, como corrigir um erro de digitação em um arquivo ou fazer uma simples mudança de nome, um prompt comum é mais eficiente. Loop deve ser escolhido apenas quando várias rodadas de observação·correção·verificação forem realmente necessárias.\n\n## 2. Comparação entre quatro tipos de Loop\n\n| Tipo | Condição de início | Condição de encerramento | Recursos usados principalmente | Tarefas adequadas | Responsabilidade transferida pela pessoa |\n|---|---|---|---|---|---|\n| Turn-based | Prompt do usuário | Quando Claude julga que concluiu ou precisa de informações adicionais | Conversa comum, Skills, ferramentas de teste·navegador | Implementações·correções curtas e pontuais | Procedimento de verificação repetida |\n| Goal-based | Usuário especifica a condição de conclusão | Modelo avaliador confirma o cumprimento da condição ou usuário interrompe | `/goal`, Auto mode se necessário | Tarefas com estado de conclusão mensurável, como testes·build·migração | Julgamento de encerramento |\n| Time-based | Horário·intervalo·agenda definidos | Usuário cancela ou uma tarefa externa termina | `/loop`, `/schedule` | Monitoramento de PR·CI·deploy, resumo periódico, Polling de status | Próximo momento de execução |\n| Proactive | Agenda, API, eventos do GitHub etc. | Cumprimento do objetivo da tarefa individual, desativação da Routine | Routines, `/goal`, Skills, Dynamic Workflows, Auto mode | Trabalho contínuo como classificação de issues, tratamento de bugs, migração em larga escala | Descoberta de tarefas, execução de prompts, orquestração |\n\nO ponto central dessa classificação não é “quão inteligente é a AI”, mas **qual responsabilidade de controle a pessoa transfere ao sistema**. No Turn-based, a pessoa cria o próximo prompt; no Goal-based, transfere o julgamento de conclusão; no Time-based, transfere o momento de reexecução. Na etapa Proactive, até a responsabilidade de detectar o surgimento de tarefas e executar o prompt adequado passa para o sistema.\n\n## 3. Turn-based Loop: transferir o procedimento de verificação\n\nTurn-based Loop é a forma básica como a maioria dos desenvolvedores usa o Claude Code.\n\n```text\nHuman → Claude → Human → Claude\n```\n\nQuando o usuário faz uma solicitação, Claude encontra arquivos relacionados, modifica o código, testa e relata o resultado. Internamente, várias observações·ações·verificações podem ocorrer, mas a autoridade para iniciar a próxima tarefa permanece com o usuário.\n\n### Alterar código e completar uma funcionalidade são coisas diferentes\n\nMesmo que Claude relate que “concluiu a implementação e os testes”, os seguintes problemas podem permanecer no produto real.\n\n- O estado não muda após clicar no botão.\n- Ocorrem erros no console do navegador.\n- O layout mobile quebra.\n- Atributos de acessibilidade estão ausentes.\n- Os testes passam, mas o fluxo real no navegador falha.\n- Arquivos não relacionados à mudança também foram modificados.\n\nPortanto, o critério de conclusão não deve ser “o código foi alterado”, mas “o funcionamento foi confirmado por evidência externa”.\n\n### Reutilizar a verificação com `SKILL.md`\n\nSkill é uma forma de armazenar instruções e procedimentos usados repetidamente em `SKILL.md`. Claude pode carregá-la automaticamente ao julgar que há relevância, ou ela pode ser executada diretamente com `/skill-name`. Em vez de colocar sempre procedimentos operacionais longos em `CLAUDE.md`, separar para carregar a Skill apenas no momento necessário permite usar o contexto de forma mais eficiente.\n\n```markdown\n---\nname: verify-ui-change\ndescription: Verifica a alteração de UI no ambiente real de execução antes de marcá-la como concluída.\n---\n\n# Verificação de alteração de UI\n\n1. Execute o servidor de desenvolvimento.\n2. Abra a tela alterada no navegador.\n3. Interaja de fato com o novo controle.\n4. Confirme se a mudança de estado esperada ocorre.\n5. Verifique novos erros e avisos no console do navegador.\n6. Verifique acessibilidade e principais indicadores de desempenho.\n7. Se falhar, corrija e verifique novamente desde o início.\n8. Relate evidências como comandos executados, resultados e screenshots.\n```\n\nUma boa Skill contém uma checklist executável, não recomendações abstratas. “Revisar com mais cuidado” é uma regra muito mais fraca do que “confirmar que `npm test` termina com código de saída 0”.\n\n### Força das evidências de verificação\n\n| Evidência | Confiabilidade | Motivo |\n|---|---:|---|\n| Explicação do Agent dizendo “parece estar normal” | Baixa | É apenas inferência, não resultado de execução |\n| Diff de código e revisão estática | Média | As mudanças são visíveis, mas o comportamento em Runtime não é confirmado |\n| Saída real de testes e código de saída | Alta | Existe resultado externo reproduzível |\n| Interação no navegador, screenshots, resultados de console·desempenho | Muito alta | Verifica diretamente o caminho do usuário e o estado em Runtime |\n| Review Agent independente e CI chegam à mesma conclusão | Muito alta | Reduz o viés de auto-confirmação do Agent implementador |\n\nA documentação oficial do Claude Code também descreve bundled Skills como `/run`, para verificar uma aplicação em execução, e `/verify`, para validar mudanças no ambiente real de execução. Se a forma de executar o projeto for complexa, é mais seguro registrar em uma Skill própria da equipe os comandos exatos de inicialização, variáveis de ambiente e procedimentos de preparação de dados.\n\n## 4. Goal-based Loop: transferir o julgamento de encerramento\n\nGoal-based Loop não exige que o usuário decida a cada vez “se deve trabalhar mais uma vez”. O usuário define o estado de conclusão, e Claude continua por vários Turns até que essa condição seja satisfeita.\n\n```text\nUsuário define Goal\n  ↓\nTurn de trabalho do Claude\n  ↓\nModelo avaliador separado verifica a condição de conclusão\n  ├─ Não satisfeita: transmite o motivo ao próximo Turn\n  └─ Satisfeita: encerra o Goal\n```\n\n`/goal` está documentado como disponível no Claude Code v2.1.139 ou superior. Apenas um Goal pode estar ativo em uma sessão.\n\n### O que o modelo avaliador realmente vê\n\nAo fim de cada Turn, um small fast model separado avalia a condição de conclusão e o conteúdo da conversa, julgando como `satisfeita` ou `não satisfeita`. A configuração padrão é um modelo avaliador da família Haiku. Uma limitação importante é que o modelo avaliador não lê arquivos diretamente nem executa testes separadamente.\n\nPortanto, o Claude que executou a tarefa deve deixar claramente na conversa as seguintes evidências.\n\n- Comandos executados\n- Número de testes e resultados de aprovação·falha\n- Código de saída\n- Resultado do build\n- Lista de arquivos alterados\n- Causas de falhas restantes\n- Resultado da confirmação de que as restrições de escopo foram respeitadas\n\nO modelo avaliador julga não “o que realmente aconteceu”, mas “quais evidências aparecem na conversa”.\n\n### Quatro elementos de um bom Goal\n\nUm bom Goal inclui os quatro elementos a seguir.\n\n1. **Condição de sucesso mensurável**: testes passando, build bem-sucedido, fila vazia, alcance de limiar de pontuação\n2. **Método de verificação**: especificar com qual comando ou ferramenta o sucesso será comprovado\n3. **Restrição de escopo de mudança**: diretórios modificáveis, arquivos proibidos, Side effect permitido\n4. **Condição de encerramento forçado**: máximo de Turns, tempo máximo, número de falhas consecutivas, interrupção em caso de erro de permissão\n\n```text\n/goal todos os testes relacionados a auth e o lint devem ter sucesso,\ne o git diff deve incluir apenas src/auth e arquivos de teste relacionados.\nEm cada Turn, relatar o resultado da execução e o código de saída.\nInterromper ao atingir no máximo 12 turns ou 45 minutos e resumir as falhas restantes.\n```\n\nAs principais condições de encerramento do próprio `/goal` são o julgamento de sucesso do modelo avaliador ou o `/goal clear` do usuário. Para impor limite de Turn·tempo, isso deve ser explicitado dentro da condição do Goal.\n\n### Condições boas e ruins\n\n| Boa condição | Má condição |\n|---|---|\n| `npm test` termina com código de saída 0 | Tornar o código perfeito |\n| Todos os 48 testes relacionados a autenticação passam | Melhorar ao máximo a experiência do usuário |\n| Todos os pontos de chamada de API são alterados para a nova interface e o build tem sucesso | Refatorar para uma estrutura melhor |\n| A fila de issues alvo fica vazia e o resultado é registrado em cada issue | Processar o maior número possível de issues |\n\nObjetivos ambíguos podem encerrar cedo demais ou repetir melhorias indefinidamente.\n\n### Verificação de status e interrupção\n\n- `/goal`: confirmar condição ativa, tempo de execução, número de Turns avaliados, uso de tokens, motivo da avaliação recente\n- `/goal clear`: interromper Goal ativo\n- Definir novo Goal: substituir o Goal existente\n- `--resume` ou `--continue`: permite restaurar Goal incompleto\n\nAo retomar, as condições são mantidas, mas o número de Turns, tempo e linha de base de tokens podem ser reinicializados; por isso, é recomendável gerenciar Hard stop junto com métricas operacionais.\n\n### `/goal` e permissões são coisas separadas\n\n`/goal` apenas inicia automaticamente o próximo Turn, não amplia permissões de ferramentas. Se escrita de arquivos, comandos de teste ou operações Git exigirem aprovação, a aprovação ainda pode ser necessária durante o Goal.\n\nPara execução não assistida, é possível usar Auto mode em conjunto, mas Auto mode não é um recurso que “permite incondicionalmente todas as ferramentas”. O classificador bloqueia operações destrutivas, difíceis de reverter ou direcionadas para fora da fronteira de confiança, e regras explícitas de `ask` e `deny` são aplicadas antes do classificador.\n\n## 5. Time-based Loop: transferir o momento de reexecução\n\nSe o Goal-based Loop trata de “quando parar”, o Time-based Loop trata de “quando executar novamente”. Ele é adequado para tarefas em que o estado de sistemas externos muda com o passar do tempo.\n\n- Verificar se há novas reviews em um PR\n- Verificar se CI ou deploy terminou\n- Verificar status de build de longa duração\n- Resumir mensagens do Slack diariamente\n- Verificar novos itens em uma fila de issues\n\n### `/loop`: execução repetida dentro da sessão atual\n\n```text\n/loop 10m verificar o PR atual, incorporar novas reviews,\ne se houver CI com falha, analisar a causa e corrigir.\n```\n\nAs principais formas descritas na documentação atual são as seguintes.\n\n| Entrada | Comportamento |\n|---|---|\n| `/loop 5m \u003cprompt\u003e` | Executa o Prompt em um intervalo fixo especificado |\n| `/loop \u003cprompt\u003e` | Claude escolhe o intervalo a cada repetição |\n| `/loop` | Executa o Prompt built-in de manutenção ou o `loop.md` do projeto |\n| `/loop 20m /review-pr 1234` | Reexecuta uma Skill permitida no intervalo especificado |\n\n`/loop` depende da sessão atual do Claude Code. O computador e a sessão precisam estar em execução, e ao iniciar uma nova conversa as tarefas no escopo da sessão desaparecem. Tarefas não expiradas podem ser restauradas com `--resume` ou `--continue`, mas tarefas repetitivas expiram por padrão 7 dias após a criação. Ciclos perdidos também não são executados retroativamente.\n\nComo Jitter pode ser aplicado ao Scheduler da sessão, ele pode não ser adequado para requisitos operacionais que precisam “executar obrigatoriamente no horário exato”.\n\n### `/schedule`: Cloud Routine gerenciada pela Anthropic\n\n`/schedule` cria uma Routine que combina Prompt, Repository, Connector e Trigger para execução na infraestrutura gerenciada pela Anthropic. Ela pode executar mesmo com o notebook fechado, e a documentação oficial a apresenta como Research Preview.\n\nOs Triggers suportados por Routine são os seguintes.\n\n- Agenda repetida\n- Agenda única em um momento futuro específico\n- Chamada de API autenticada\n- Evento de GitHub Pull request ou Release\n\nVários Triggers podem ser conectados a uma única Routine. Por exemplo, uma PR Review Routine pode rodar todas as noites e também reagir ao evento `pull_request.opened`.\n\n### Comparação entre `/loop` e `/schedule`\n\n| Categoria | `/loop` | `/schedule` Routine |\n|---|---|---|\n| Local de execução | Computador e sessão atuais | Cloud gerenciada pela Anthropic |\n| Execução após desligar o computador | Geralmente não disponível | Disponível |\n| Sessão aberta necessária | Necessária | Desnecessária |\n| Arquivos locais não commitados | Acessíveis | Inacessíveis, Repository é clonado novamente a cada execução |\n| Intervalo mínimo | 1 minuto segundo a documentação oficial | 1 hora segundo a documentação oficial |\n| Persistência | Centrado na sessão, tarefas repetitivas expiram em 7 dias | Routine salva na conta |\n| Prompt de permissão | Herda a política da sessão atual | Execução autônoma sem aprovação interativa |\n| Uso adequado | Monitoramento curto de PR·deploy | Automação operacional contínua |\n\n### Quando Event é melhor que Polling\n\nSe um PR com poucas alterações for verificado a cada 1 minuto, a maioria das execuções terminará sem fazer nada. Se o sistema externo puder enviar eventos, a estrutura abaixo é mais eficiente.\n\n```text\nFalha de CI ou atualização de PR\n  ↓\nGitHub Trigger ou Routine API\n  ↓\nExecutar Claude apenas quando necessário\n```\n\nO design baseado em Event reduz atrasos e diminui chamadas desnecessárias ao modelo e consumo de tokens. Quando Polling for inevitável, é recomendável aumentar o intervalo de acordo com a frequência real de mudanças e aplicar Backoff quando não houver mudanças por longo período.\n\n### Condições obrigatórias de tarefas baseadas em tempo\n\n1. **Idempotência**: mesmo recebendo o mesmo evento várias vezes, não devem surgir comentários duplicados, PRs duplicados ou deploys duplicados.\n2. **Estado de processamento**: deve-se registrar o último Event ID, Commit SHA, Review Comment ID etc.\n3. **Estado de encerramento**: deve ser possível determinar encerramento, como PR merge·close, Queue empty, Deploy success·rollback.\n4. **Escopo de escrita**: Side effects devem ser limitados, como permitir comentários, proibir Merge, fazer Push apenas em Branch `claude/*`.\n5. **Tratamento de falhas**: são necessárias regras de retentativa e Escalation em caso de falha de serviço externo, expiração de autenticação, Rate limit ou falta de permissão.\n\n## 6. Proactive Loop: transferir descoberta de tarefas e orquestração\n\nProactive Loop não é um único comando, mas uma arquitetura de automação contínua que combina vários recursos.\n\n```text\nTrigger\n+ Goal\n+ Skills\n+ Dynamic Workflow\n+ Auto mode\n+ Repository·Connector·Browser·CI ferramentas\n```\n\nMesmo sem uma pessoa digitando prompts em tempo real, novas tarefas são detectadas, processadas, verificadas e relatadas.\n\n### Exemplo: tratamento automático de feedback de bugs\n\n```text\nReceber GitHub Issue ou feedback no Slack\n  ↓\nClassificar duplicidade·prioridade·reprodutibilidade\n  ↓\nCriar teste de reprodução\n  ↓\nExplorar soluções candidatas\n  ↓\nImplementar a solução escolhida\n  ↓\nReview Agent independente procura contraexemplos\n  ↓\nVerificações de teste·build·segurança\n  ↓\nDraft PR e relatório de resultado\n```\n\nAs responsabilidades por componente são as seguintes.\n\n| Componente | Responsabilidade |\n|---|---|\n| Trigger ou `/schedule` | Determinar quando iniciar uma nova tarefa |\n| `/goal` | Definir o que é estado de conclusão nesta execução |\n| Skill | Padronizar procedimentos de reprodução, implementação, verificação e relatório |\n| Dynamic Workflow | Execução paralela e ramificação condicional de múltiplos Subagents |\n| Auto mode | Executar chamadas de ferramentas permitidas sem esperar aprovação |\n| Permission policy | Fixar escopos de proibição·aprovação·permissão automática |\n\n### Dynamic Workflow e Worktree\n\nDynamic Workflow é uma estrutura em que o Runtime executa um Script de orquestração JavaScript escrito por Claude. Em chamadas comuns de Subagent, Claude escolhe o próximo Agent a cada Turn; em Workflow, Loop, processamento paralelo, ramificação e armazenamento de resultados intermediários passam para o Script.\n\n```text\nWorkflow Script\n  ├─ Agent A: análise de requisitos\n  ├─ Agent B: design de testes\n  ├─ Agent C: exploração de candidatos de implementação\n  ├─ Agent D: revisão de segurança\n  └─ Judge: comparação baseada em evidências\n```\n\nComo os resultados intermediários ficam em variáveis do Script, e não no Context da conversa principal, tarefas em grande escala podem ser organizadas de forma mais reproduzível. A documentação atual especifica limites de Runtime de até 16 Agents simultâneos e até 1,000 Agents por execução, mas limitações em estágio de produto Preview podem mudar.\n\nSe for necessário testar vários candidatos de implementação ao mesmo tempo, é possível separar os espaços de trabalho com Git Worktree.\n\n```text\nrepo/\nworktree-solution-a/\nworktree-solution-b/\nworktree-solution-c/\n```\n\nQuando cada Agent trabalha em uma Branch e diretório independentes, é possível reduzir problemas de sobrescrever os mesmos arquivos simultaneamente. O Judge Agent deve comparar os candidatos com base em cumprimento dos requisitos, resultados de testes, risco de regressão, escopo de mudança, complexidade, desempenho, segurança e consistência com a arquitetura existente.\n\n### Mais Agents nem sempre é melhor\n\nSe apenas aumentar o número de Agents em uma tarefa sem paralelismo, o custo e a latência aumentam. Se vários Agents compartilharem a mesma suposição incorreta, o erro também pode ser ampliado.\n\nDynamic Workflow é adequado nos seguintes casos.\n\n- Migration aplicando a mesma transformação a centenas de arquivos\n- Audit de segurança·qualidade em toda a base de código\n- Comparação de Plans sob várias perspectivas independentes\n- Research que exige dividir muitos itens e fazer verificação cruzada\n- Tarefas em que é difícil colocar todos os resultados intermediários no Context de um único Agent\n\nPara pequenas correções de bug, refatoração de um arquivo ou adição simples de testes, um Turn-based Loop comum ou `/goal` é melhor.\n\n## 7. Sistema para manter a qualidade do código em Loop\n\nA qualidade dos resultados de Loop depende fortemente não apenas do modelo em si, mas também do sistema de verificação ao redor do modelo.\n\n### 7.1 Organizar a base de código\n\nClaude segue fortemente os padrões do código existente. Se houver APIs antigas, implementações duplicadas, estrutura de testes pouco clara, módulos enormes ou regras inconsistentes de tratamento de exceções, o Loop pode replicar rapidamente esses problemas.\n\nAs bases essenciais são as seguintes.\n\n- Formatter e lint\n- Limites claros de diretórios e módulos\n- Unit·Integration·E2E Test confiáveis\n- Distinção entre APIs em uso e Deprecated APIs\n- Regras de desenvolvimento específicas do projeto\n- Ambiente Build·Dev reproduzível\n\n### 7.2 Criar Definition of Done por tipo de mudança\n\n| Tipo de mudança | Verificação mínima |\n|---|---|\n| API | Testes de contrato, compatibilidade retroativa, atualização de exemplos de Schema·documentação |\n| Frontend | Interação real no navegador, erros de console, acessibilidade, telas responsivas |\n| Database | Forward·Rollback Migration, escopo de Lock, plano de execução |\n| Dependency | Build, principais testes de regressão, verificação de License·Security |\n| Infrastructure | Plan Diff, privilégio mínimo, Rollback, verificação de exposição de segredos |\n\nÉ melhor fixar esses critérios em Skill, Hook, Script ou CI Rule do que repeti-los longamente em cada Prompt.\n\n### 7.3 Fornecer documentação atualizada e versões exatas\n\nLoop pode repetir suposições incorretas várias vezes. É preciso facilitar a localização da Version exata usada no projeto, documentação oficial, documentos internos de Architecture, especificações de API, Migration Guide e exemplos aprovados.\n\n### 7.4 Separar Agent implementador e Review Agent\n\nO Agent que implementou já é influenciado pelo design e pelo raciocínio que escolheu. Um Review Agent em novo Context pode fazer as seguintes perguntas de forma mais independente.\n\n- Os testes foram enfraquecidos para fazê-los passar?\n- Arquivos fora do escopo foram alterados?\n- A fronteira de segurança foi quebrada?\n- Caminhos de falha e testes de valores-limite ficaram de fora?\n- Houve regressão em funcionalidades existentes?\n\nÉ mais eficaz escrever o Review Prompt como “assuma que a implementação está errada, encontre contraexemplos e anexe evidência de reprodução a cada apontamento” do que “resuma os pontos positivos”.\n\n### 7.5 Conectar falhas individuais a melhorias de sistema\n\nSe o mesmo erro se repete, não basta corrigir apenas aquele resultado. É preciso alterar um dos itens abaixo para dificultar a recorrência do tipo de falha.\n\n- Adicionar Regression Test\n- Reforçar o procedimento de verificação da Skill\n- Adicionar regra em `CLAUDE.md`\n- Adicionar Hook ou lint Rule\n- Adicionar regra Deny de permissão\n- Reforçar a condição de conclusão do Goal\n- Complementar a Review Checklist\n\nBoa Loop Engineering não é o trabalho de corrigir uma falha uma vez, mas **criar um sistema em que esse tipo de falha tenha dificuldade de reaparecer**.\n\n## 8. Gerenciamento de Token e custo\n\nO custo de Loop pode aumentar bastante em relação a um único Prompt.\n\n```text\nCusto total ≈\ncusto dos Turns do Agent principal\n+ custo de avaliação do Goal\n+ custo de Subagent\n+ custo de repetição de Workflow\n+ custo de Context para ler resultados de ferramentas\n+ frequência de execução baseada em tempo\n```\n\nA cobrança exata varia conforme Plan, Model e Provider, mas os princípios que determinam a estrutura de custo são os mesmos.\n\n### Princípios práticos para reduzir custo\n\n1. **Não usar Loop para tarefas pequenas.** Erros de digitação, mudanças de nome e erros de tipo em um arquivo devem ser tratados em um único Turn.\n2. **Usar condição de sucesso junto com Hard stop.** Considerar sucesso, máximo de Turns, tempo máximo, falhas consecutivas e erros de permissão.\n3. **Testar Workflows grandes em escopo pequeno.** Validar custo e qualidade em 5 arquivos, um diretório ou algumas Issues antes de expandir.\n4. **Tratar tarefas determinísticas com Script.** Substituições AST, conversões JSON, Formatting e geração de formatos fixos são mais baratos e reproduzíveis com Scripts verificados.\n5. **Ajustar o ciclo de Polling à frequência real de mudanças.** Usar Event Trigger sempre que possível.\n6. **Observar o uso em andamento.** Verificar uso de Skill·Subagent·MCP·Turn·Token em `/usage`, `/goal`, `/workflows`.\n7. **Não continuar tentando quando o mesmo erro se repete.** Definir limite de falhas consecutivas e fazer Escalation para uma pessoa.\n\n### Model e Effort são alavancas diferentes\n\n- **Model** altera a capacidade básica de raciocínio e o escopo dos problemas solucionáveis.\n- **Effort** altera o número de arquivos lidos, o número de ferramentas usadas, a amplitude da verificação e até que ponto tarefas de várias etapas são levadas adiante.\n\nSe Claude confirmou todos os arquivos e testes necessários, mas o julgamento em si continua errado, pode ser necessário um Model mais forte. Por outro lado, se arquivos importantes não são lidos, testes são pulados ou a refatoração termina no meio, aumentar Effort pode ser mais apropriado.\n\n## 9. Permissões e fronteiras de segurança\n\nO design mais perigoso em Proactive Loop é conceder permissões amplas ao Agent e deixar frouxas as condições de sucesso e interrupção.\n\nAuto mode reduz Prompts comuns de permissão, mas Tool calls difíceis de reverter, destrutivas ou direcionadas para fora da fronteira de confiança podem ser bloqueadas pelo classificador. Além disso, `permissions.ask` e `permissions.deny` explícitos têm prioridade sobre Auto mode.\n\n### Exemplo de camadas de permissão\n\n| Nível | Exemplo |\n|---|---|\n| Permitir automaticamente | Leitura de código, testes·lint·Build, análise, criação de Branch `claude/*`, criação de Draft PR |\n| Aprovação humana | Aplicar em Default Branch, deploy em produção, aplicar DB Migration, enviar mensagens externas a clientes |\n| Sempre proibido | Force push, saída de Secret, exclusão de dados de produção, bypass de permissões, remoção de logs de auditoria |\n\nÉ mais seguro fixar em Rules permanentes de `ask`·`deny` do que dizer uma vez na conversa “não faça Push”. Isso porque regras da conversa podem enfraquecer com compressão de Context ou mudança de sessão.\n\nCloud Routine clona novamente o Repository a cada execução e opera com permissões conectadas de GitHub·Connector. Os seguintes escopos devem ser minimizados.\n\n- Repository e Branch acessíveis\n- Network Domain permitido\n- Connector a usar\n- Variáveis de ambiente e Secret\n- Permissões de escrita em sistemas externos\n- Escopo de criação de PR·Push·Merge\n\nO estado “encerramento normal” na lista de execuções de Routine pode significar apenas que a Session terminou sem erro de Infrastructure, e não garante que o objetivo de negócio teve sucesso. Transcript, Test evidence e Diff gerado devem ser revisados separadamente.\n\n## 10. Template de design de Loop para projetos de desenvolvimento\n\nO YAML abaixo não é uma sintaxe real do Claude Code, mas um Template para revisão de design.\n\n```yaml\ntrigger:\n  type: manual | interval | schedule | github_event | api_event\n\nscope:\n  repositories:\n    - target-repository\n  allowed_paths:\n    - src/**\n    - tests/**\n  prohibited_paths:\n    - production/**\n    - secrets/**\n\ntask:\n  objective: objetivo a alterar ou processar\n  input: Issue, Event, File ou estado recém-recebido\n\nverification:\n  commands:\n    - unit-test\n    - integration-test\n    - lint\n    - build\n  runtime_checks:\n    - browser-interaction\n    - console-errors\n    - accessibility\n  evidence:\n    - command-output\n    - exit-code\n    - test-summary\n    - screenshots\n\nsuccess:\n  condition: estado de conclusão que pode ser julgado como verdadeiro ou falso\n\nstop:\n  max_turns: 12\n  max_duration_minutes: 45\n  max_consecutive_failures: 3\n  stop_on_permission_error: true\n  escalate_on_external_outage: true\n\nside_effects:\n  idempotency_key: event-id-or-commit-sha\n  allow_branch_push: claude/*\n  require_human_for_merge: true\n  require_human_for_deploy: true\n\nreview:\n  independent_agent: true\n  adversarial_review: true\n\nobservability:\n  report_progress: true\n  report_token_usage: true\n  report_changed_files: true\n  report_remaining_failures: true\n```\n\nOs itens mais importantes não são a frase do prompt em si, mas os cinco pontos a seguir.\n\n```text\nTrigger\nVerifier\nSuccess condition\nHard stop\nPermission boundary\n```\n\n## 11. Qual Loop escolher\n\n| Situação | Abordagem recomendada |\n|---|---|\n| Tarefa que termina com uma única correção e verificação | Turn-based |\n| Tarefa que exige várias tentativas, mas tem estado de conclusão claro | `/goal` |\n| Tarefa que precisa esperar por um tempo o estado de CI·PR·deploy externo | `/loop` |\n| Trabalho que precisa executar repetidamente mesmo com o notebook fechado | `/schedule` Routine |\n| Trabalho que precisa reagir imediatamente a eventos do GitHub ou Alert | Event-triggered Routine |\n| Trabalho que exige processar centenas de itens em paralelo e fazer verificação cruzada | Dynamic Workflow |\n| Transformação cujas regras de entrada e saída são totalmente determinísticas | Script ou CI Job |\n\nA ordem de escolha deve se basear não no “recurso mais poderoso”, mas na “estrutura de controle mais simples que atinge o objetivo”.\n\n## 12. Ordem segura de adoção\n\n1. Escolha uma tarefa de gargalo que uma pessoa verifica repetidamente.\n2. Primeiro, transforme o procedimento de verificação em Skill, Script e CI.\n3. Estabilize a qualidade da verificação no modo Turn-based.\n4. Se o estado de conclusão for claro, adicione `/goal`.\n5. Use `/loop` apenas quando for necessário esperar um estado externo.\n6. Se for necessária execução de longo prazo, mova para `/schedule` Routine.\n7. Expanda para Dynamic Workflow e Proactive Loop apenas depois de verificar idempotência, permissões e custo.\n\n## 13. Mal-entendidos frequentes\n\n| Mal-entendido | Interpretação correta |\n|---|---|\n| Loop é execução infinita | É uma estrutura de repetição limitada com condição de sucesso e Hard stop |\n| O relatório de conclusão do Agent é verificação | São necessários saída de comandos externos, código de saída e resultado em Runtime |\n| `/goal` permite automaticamente todas as permissões | Ele apenas inicia automaticamente o próximo Turn; a política de permissões é separada |\n| `/loop` é um Scheduler de operação de longo prazo | É centrado na sessão e tem expiração de 7 dias e restrições de ambiente de execução |\n| Quanto mais Agents, melhor o resultado | A paralelização só tem valor quando papéis·perspectivas·verificações são diferentes |\n| Toda tarefa repetitiva deve ser feita por LLM | Partes determinísticas são mais baratas e reproduzíveis com Script |\n\n## Conclusão\n\nLoop Engineering não é uma técnica para executar AI por mais tempo, mas o **design de um sistema de controle que faz a AI descobrir por si mesma quando erra, corrigir dentro de um limite de custo e parar em pontos perigosos**.\n\nLLM é forte em exploração, raciocínio, implementação, análise de exceções e comparação de alternativas. O sistema deve cuidar do momento de execução, escopo de mudança, método de verificação, critério de encerramento, limite de custo e fronteira de aprovação. Quanto mais clara essa divisão de papéis, mais a automação do Claude Code deixa de ser uma simples ferramenta de geração de código e se aproxima de um sistema de operação de desenvolvimento reproduzível e auditável.","content_html":"\u003cp\u003eO Loop do Claude Code não é simplesmente um recurso para executar o modelo por mais tempo. O ponto central está em posicionar \u003cstrong\u003eTrigger, Verifier, Success condition, Hard stop, Permission boundary\u003c/strong\u003e ao redor de um AI Agent que age probabilisticamente, transformando tarefas repetitivas em um sistema controlável. Este artigo organiza de uma só vez as diferenças entre Turn-based, Goal-based, Time-based e Proactive Loop, além dos princípios de design prático.\u003c/p\u003e\n\u003ch2\u003e\u003ca href=\"#1-o-que-é-loop-no-claude-code\" class=\"anchor\" id=\"1-o-que-é-loop-no-claude-code\"\u003e\u003c/a\u003e1. O que é Loop no Claude Code\u003c/h2\u003e\n\u003cp\u003eAqui, Loop não é uma instrução \u003ccode\u003efor\u003c/code\u003e ou \u003ccode\u003ewhile\u003c/code\u003e de uma linguagem de programação. O Loop descrito pela equipe do Claude Code é uma estrutura de execução em que o Agent observa o estado atual, age, verifica o resultado e volta a trabalhar até que a condição de encerramento seja satisfeita.\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003eInício da tarefa\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003eEntendimento do estado e do código\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003eElaboração do plano\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003eAlteração de código ou execução de ferramenta\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003eTeste·verificação\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003eCondição de conclusão satisfeita?\n\u003c/span\u003e\u003cspan\u003e  ├─ Não: próxima iteração\n\u003c/span\u003e\u003cspan\u003e  └─ Sim: encerrar e relatar resultado\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eAo distinguir Loops, as quatro perguntas a seguir são úteis.\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003eO que inicia a tarefa?\u003c/li\u003e\n\u003cli\u003eO que encerra a tarefa?\u003c/li\u003e\n\u003cli\u003eQual recurso do Claude Code controla a repetição?\u003c/li\u003e\n\u003cli\u003ePara que tipo de tarefa ele é adequado?\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003eNão é necessário transformar todo trabalho em um Loop complexo. Para tarefas cujo resultado pode ser confirmado imediatamente, como corrigir um erro de digitação em um arquivo ou fazer uma simples mudança de nome, um prompt comum é mais eficiente. Loop deve ser escolhido apenas quando várias rodadas de observação·correção·verificação forem realmente necessárias.\u003c/p\u003e\n\u003ch2\u003e\u003ca href=\"#2-comparação-entre-quatro-tipos-de-loop\" class=\"anchor\" id=\"2-comparação-entre-quatro-tipos-de-loop\"\u003e\u003c/a\u003e2. Comparação entre quatro tipos de Loop\u003c/h2\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eTipo\u003c/th\u003e\n\u003cth\u003eCondição de início\u003c/th\u003e\n\u003cth\u003eCondição de encerramento\u003c/th\u003e\n\u003cth\u003eRecursos usados principalmente\u003c/th\u003e\n\u003cth\u003eTarefas adequadas\u003c/th\u003e\n\u003cth\u003eResponsabilidade transferida pela pessoa\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd\u003eTurn-based\u003c/td\u003e\n\u003ctd\u003ePrompt do usuário\u003c/td\u003e\n\u003ctd\u003eQuando Claude julga que concluiu ou precisa de informações adicionais\u003c/td\u003e\n\u003ctd\u003eConversa comum, Skills, ferramentas de teste·navegador\u003c/td\u003e\n\u003ctd\u003eImplementações·correções curtas e pontuais\u003c/td\u003e\n\u003ctd\u003eProcedimento de verificação repetida\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eGoal-based\u003c/td\u003e\n\u003ctd\u003eUsuário especifica a condição de conclusão\u003c/td\u003e\n\u003ctd\u003eModelo avaliador confirma o cumprimento da condição ou usuário interrompe\u003c/td\u003e\n\u003ctd\u003e\u003ccode\u003e/goal\u003c/code\u003e, Auto mode se necessário\u003c/td\u003e\n\u003ctd\u003eTarefas com estado de conclusão mensurável, como testes·build·migração\u003c/td\u003e\n\u003ctd\u003eJulgamento de encerramento\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eTime-based\u003c/td\u003e\n\u003ctd\u003eHorário·intervalo·agenda definidos\u003c/td\u003e\n\u003ctd\u003eUsuário cancela ou uma tarefa externa termina\u003c/td\u003e\n\u003ctd\u003e\u003ccode\u003e/loop\u003c/code\u003e, \u003ccode\u003e/schedule\u003c/code\u003e\u003c/td\u003e\n\u003ctd\u003eMonitoramento de PR·CI·deploy, resumo periódico, Polling de status\u003c/td\u003e\n\u003ctd\u003ePróximo momento de execução\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eProactive\u003c/td\u003e\n\u003ctd\u003eAgenda, API, eventos do GitHub etc.\u003c/td\u003e\n\u003ctd\u003eCumprimento do objetivo da tarefa individual, desativação da Routine\u003c/td\u003e\n\u003ctd\u003eRoutines, \u003ccode\u003e/goal\u003c/code\u003e, Skills, Dynamic Workflows, Auto mode\u003c/td\u003e\n\u003ctd\u003eTrabalho contínuo como classificação de issues, tratamento de bugs, migração em larga escala\u003c/td\u003e\n\u003ctd\u003eDescoberta de tarefas, execução de prompts, orquestração\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003eO ponto central dessa classificação não é “quão inteligente é a AI”, mas \u003cstrong\u003equal responsabilidade de controle a pessoa transfere ao sistema\u003c/strong\u003e. No Turn-based, a pessoa cria o próximo prompt; no Goal-based, transfere o julgamento de conclusão; no Time-based, transfere o momento de reexecução. Na etapa Proactive, até a responsabilidade de detectar o surgimento de tarefas e executar o prompt adequado passa para o sistema.\u003c/p\u003e\n\u003ch2\u003e\u003ca href=\"#3-turn-based-loop-transferir-o-procedimento-de-verificação\" class=\"anchor\" id=\"3-turn-based-loop-transferir-o-procedimento-de-verificação\"\u003e\u003c/a\u003e3. Turn-based Loop: transferir o procedimento de verificação\u003c/h2\u003e\n\u003cp\u003eTurn-based Loop é a forma básica como a maioria dos desenvolvedores usa o Claude Code.\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003eHuman → Claude → Human → Claude\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eQuando o usuário faz uma solicitação, Claude encontra arquivos relacionados, modifica o código, testa e relata o resultado. Internamente, várias observações·ações·verificações podem ocorrer, mas a autoridade para iniciar a próxima tarefa permanece com o usuário.\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#alterar-código-e-completar-uma-funcionalidade-são-coisas-diferentes\" class=\"anchor\" id=\"alterar-código-e-completar-uma-funcionalidade-são-coisas-diferentes\"\u003e\u003c/a\u003eAlterar código e completar uma funcionalidade são coisas diferentes\u003c/h3\u003e\n\u003cp\u003eMesmo que Claude relate que “concluiu a implementação e os testes”, os seguintes problemas podem permanecer no produto real.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eO estado não muda após clicar no botão.\u003c/li\u003e\n\u003cli\u003eOcorrem erros no console do navegador.\u003c/li\u003e\n\u003cli\u003eO layout mobile quebra.\u003c/li\u003e\n\u003cli\u003eAtributos de acessibilidade estão ausentes.\u003c/li\u003e\n\u003cli\u003eOs testes passam, mas o fluxo real no navegador falha.\u003c/li\u003e\n\u003cli\u003eArquivos não relacionados à mudança também foram modificados.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003ePortanto, o critério de conclusão não deve ser “o código foi alterado”, mas “o funcionamento foi confirmado por evidência externa”.\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#reutilizar-a-verificação-com-skillmd\" class=\"anchor\" id=\"reutilizar-a-verificação-com-skillmd\"\u003e\u003c/a\u003eReutilizar a verificação com \u003ccode\u003eSKILL.md\u003c/code\u003e\u003c/h3\u003e\n\u003cp\u003eSkill é uma forma de armazenar instruções e procedimentos usados repetidamente em \u003ccode\u003eSKILL.md\u003c/code\u003e. Claude pode carregá-la automaticamente ao julgar que há relevância, ou ela pode ser executada diretamente com \u003ccode\u003e/skill-name\u003c/code\u003e. Em vez de colocar sempre procedimentos operacionais longos em \u003ccode\u003eCLAUDE.md\u003c/code\u003e, separar para carregar a Skill apenas no momento necessário permite usar o contexto de forma mais eficiente.\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003e---\n\u003c/span\u003e\u003cspan\u003ename: verify-ui-change\n\u003c/span\u003e\u003cspan\u003edescription: Verifica a alteração de UI no ambiente real de execução antes de marcá-la como concluída.\n\u003c/span\u003e\u003cspan\u003e---\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003e# Verificação de alteração de UI\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003e1. Execute o servidor de desenvolvimento.\n\u003c/span\u003e\u003cspan\u003e2. Abra a tela alterada no navegador.\n\u003c/span\u003e\u003cspan\u003e3. Interaja de fato com o novo controle.\n\u003c/span\u003e\u003cspan\u003e4. Confirme se a mudança de estado esperada ocorre.\n\u003c/span\u003e\u003cspan\u003e5. Verifique novos erros e avisos no console do navegador.\n\u003c/span\u003e\u003cspan\u003e6. Verifique acessibilidade e principais indicadores de desempenho.\n\u003c/span\u003e\u003cspan\u003e7. Se falhar, corrija e verifique novamente desde o início.\n\u003c/span\u003e\u003cspan\u003e8. Relate evidências como comandos executados, resultados e screenshots.\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eUma boa Skill contém uma checklist executável, não recomendações abstratas. “Revisar com mais cuidado” é uma regra muito mais fraca do que “confirmar que \u003ccode\u003enpm test\u003c/code\u003e termina com código de saída 0”.\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#força-das-evidências-de-verificação\" class=\"anchor\" id=\"força-das-evidências-de-verificação\"\u003e\u003c/a\u003eForça das evidências de verificação\u003c/h3\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eEvidência\u003c/th\u003e\n\u003cth\u003eConfiabilidade\u003c/th\u003e\n\u003cth\u003eMotivo\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd\u003eExplicação do Agent dizendo “parece estar normal”\u003c/td\u003e\n\u003ctd\u003eBaixa\u003c/td\u003e\n\u003ctd\u003eÉ apenas inferência, não resultado de execução\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eDiff de código e revisão estática\u003c/td\u003e\n\u003ctd\u003eMédia\u003c/td\u003e\n\u003ctd\u003eAs mudanças são visíveis, mas o comportamento em Runtime não é confirmado\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eSaída real de testes e código de saída\u003c/td\u003e\n\u003ctd\u003eAlta\u003c/td\u003e\n\u003ctd\u003eExiste resultado externo reproduzível\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eInteração no navegador, screenshots, resultados de console·desempenho\u003c/td\u003e\n\u003ctd\u003eMuito alta\u003c/td\u003e\n\u003ctd\u003eVerifica diretamente o caminho do usuário e o estado em Runtime\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eReview Agent independente e CI chegam à mesma conclusão\u003c/td\u003e\n\u003ctd\u003eMuito alta\u003c/td\u003e\n\u003ctd\u003eReduz o viés de auto-confirmação do Agent implementador\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003eA documentação oficial do Claude Code também descreve bundled Skills como \u003ccode\u003e/run\u003c/code\u003e, para verificar uma aplicação em execução, e \u003ccode\u003e/verify\u003c/code\u003e, para validar mudanças no ambiente real de execução. Se a forma de executar o projeto for complexa, é mais seguro registrar em uma Skill própria da equipe os comandos exatos de inicialização, variáveis de ambiente e procedimentos de preparação de dados.\u003c/p\u003e\n\u003ch2\u003e\u003ca href=\"#4-goal-based-loop-transferir-o-julgamento-de-encerramento\" class=\"anchor\" id=\"4-goal-based-loop-transferir-o-julgamento-de-encerramento\"\u003e\u003c/a\u003e4. Goal-based Loop: transferir o julgamento de encerramento\u003c/h2\u003e\n\u003cp\u003eGoal-based Loop não exige que o usuário decida a cada vez “se deve trabalhar mais uma vez”. O usuário define o estado de conclusão, e Claude continua por vários Turns até que essa condição seja satisfeita.\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003eUsuário define Goal\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003eTurn de trabalho do Claude\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003eModelo avaliador separado verifica a condição de conclusão\n\u003c/span\u003e\u003cspan\u003e  ├─ Não satisfeita: transmite o motivo ao próximo Turn\n\u003c/span\u003e\u003cspan\u003e  └─ Satisfeita: encerra o Goal\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003e\u003ccode\u003e/goal\u003c/code\u003e está documentado como disponível no Claude Code v2.1.139 ou superior. Apenas um Goal pode estar ativo em uma sessão.\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#o-que-o-modelo-avaliador-realmente-vê\" class=\"anchor\" id=\"o-que-o-modelo-avaliador-realmente-vê\"\u003e\u003c/a\u003eO que o modelo avaliador realmente vê\u003c/h3\u003e\n\u003cp\u003eAo fim de cada Turn, um small fast model separado avalia a condição de conclusão e o conteúdo da conversa, julgando como \u003ccode\u003esatisfeita\u003c/code\u003e ou \u003ccode\u003enão satisfeita\u003c/code\u003e. A configuração padrão é um modelo avaliador da família Haiku. Uma limitação importante é que o modelo avaliador não lê arquivos diretamente nem executa testes separadamente.\u003c/p\u003e\n\u003cp\u003ePortanto, o Claude que executou a tarefa deve deixar claramente na conversa as seguintes evidências.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eComandos executados\u003c/li\u003e\n\u003cli\u003eNúmero de testes e resultados de aprovação·falha\u003c/li\u003e\n\u003cli\u003eCódigo de saída\u003c/li\u003e\n\u003cli\u003eResultado do build\u003c/li\u003e\n\u003cli\u003eLista de arquivos alterados\u003c/li\u003e\n\u003cli\u003eCausas de falhas restantes\u003c/li\u003e\n\u003cli\u003eResultado da confirmação de que as restrições de escopo foram respeitadas\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eO modelo avaliador julga não “o que realmente aconteceu”, mas “quais evidências aparecem na conversa”.\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#quatro-elementos-de-um-bom-goal\" class=\"anchor\" id=\"quatro-elementos-de-um-bom-goal\"\u003e\u003c/a\u003eQuatro elementos de um bom Goal\u003c/h3\u003e\n\u003cp\u003eUm bom Goal inclui os quatro elementos a seguir.\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eCondição de sucesso mensurável\u003c/strong\u003e: testes passando, build bem-sucedido, fila vazia, alcance de limiar de pontuação\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eMétodo de verificação\u003c/strong\u003e: especificar com qual comando ou ferramenta o sucesso será comprovado\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eRestrição de escopo de mudança\u003c/strong\u003e: diretórios modificáveis, arquivos proibidos, Side effect permitido\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eCondição de encerramento forçado\u003c/strong\u003e: máximo de Turns, tempo máximo, número de falhas consecutivas, interrupção em caso de erro de permissão\u003c/li\u003e\n\u003c/ol\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003e/goal todos os testes relacionados a auth e o lint devem ter sucesso,\n\u003c/span\u003e\u003cspan\u003ee o git diff deve incluir apenas src/auth e arquivos de teste relacionados.\n\u003c/span\u003e\u003cspan\u003eEm cada Turn, relatar o resultado da execução e o código de saída.\n\u003c/span\u003e\u003cspan\u003eInterromper ao atingir no máximo 12 turns ou 45 minutos e resumir as falhas restantes.\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eAs principais condições de encerramento do próprio \u003ccode\u003e/goal\u003c/code\u003e são o julgamento de sucesso do modelo avaliador ou o \u003ccode\u003e/goal clear\u003c/code\u003e do usuário. Para impor limite de Turn·tempo, isso deve ser explicitado dentro da condição do Goal.\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#condições-boas-e-ruins\" class=\"anchor\" id=\"condições-boas-e-ruins\"\u003e\u003c/a\u003eCondições boas e ruins\u003c/h3\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eBoa condição\u003c/th\u003e\n\u003cth\u003eMá condição\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003ccode\u003enpm test\u003c/code\u003e termina com código de saída 0\u003c/td\u003e\n\u003ctd\u003eTornar o código perfeito\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eTodos os 48 testes relacionados a autenticação passam\u003c/td\u003e\n\u003ctd\u003eMelhorar ao máximo a experiência do usuário\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eTodos os pontos de chamada de API são alterados para a nova interface e o build tem sucesso\u003c/td\u003e\n\u003ctd\u003eRefatorar para uma estrutura melhor\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eA fila de issues alvo fica vazia e o resultado é registrado em cada issue\u003c/td\u003e\n\u003ctd\u003eProcessar o maior número possível de issues\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003eObjetivos ambíguos podem encerrar cedo demais ou repetir melhorias indefinidamente.\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#verificação-de-status-e-interrupção\" class=\"anchor\" id=\"verificação-de-status-e-interrupção\"\u003e\u003c/a\u003eVerificação de status e interrupção\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ccode\u003e/goal\u003c/code\u003e: confirmar condição ativa, tempo de execução, número de Turns avaliados, uso de tokens, motivo da avaliação recente\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003e/goal clear\u003c/code\u003e: interromper Goal ativo\u003c/li\u003e\n\u003cli\u003eDefinir novo Goal: substituir o Goal existente\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003e--resume\u003c/code\u003e ou \u003ccode\u003e--continue\u003c/code\u003e: permite restaurar Goal incompleto\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eAo retomar, as condições são mantidas, mas o número de Turns, tempo e linha de base de tokens podem ser reinicializados; por isso, é recomendável gerenciar Hard stop junto com métricas operacionais.\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#goal-e-permissões-são-coisas-separadas\" class=\"anchor\" id=\"goal-e-permissões-são-coisas-separadas\"\u003e\u003c/a\u003e\u003ccode\u003e/goal\u003c/code\u003e e permissões são coisas separadas\u003c/h3\u003e\n\u003cp\u003e\u003ccode\u003e/goal\u003c/code\u003e apenas inicia automaticamente o próximo Turn, não amplia permissões de ferramentas. Se escrita de arquivos, comandos de teste ou operações Git exigirem aprovação, a aprovação ainda pode ser necessária durante o Goal.\u003c/p\u003e\n\u003cp\u003ePara execução não assistida, é possível usar Auto mode em conjunto, mas Auto mode não é um recurso que “permite incondicionalmente todas as ferramentas”. O classificador bloqueia operações destrutivas, difíceis de reverter ou direcionadas para fora da fronteira de confiança, e regras explícitas de \u003ccode\u003eask\u003c/code\u003e e \u003ccode\u003edeny\u003c/code\u003e são aplicadas antes do classificador.\u003c/p\u003e\n\u003ch2\u003e\u003ca href=\"#5-time-based-loop-transferir-o-momento-de-reexecução\" class=\"anchor\" id=\"5-time-based-loop-transferir-o-momento-de-reexecução\"\u003e\u003c/a\u003e5. Time-based Loop: transferir o momento de reexecução\u003c/h2\u003e\n\u003cp\u003eSe o Goal-based Loop trata de “quando parar”, o Time-based Loop trata de “quando executar novamente”. Ele é adequado para tarefas em que o estado de sistemas externos muda com o passar do tempo.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eVerificar se há novas reviews em um PR\u003c/li\u003e\n\u003cli\u003eVerificar se CI ou deploy terminou\u003c/li\u003e\n\u003cli\u003eVerificar status de build de longa duração\u003c/li\u003e\n\u003cli\u003eResumir mensagens do Slack diariamente\u003c/li\u003e\n\u003cli\u003eVerificar novos itens em uma fila de issues\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3\u003e\u003ca href=\"#loop-execução-repetida-dentro-da-sessão-atual\" class=\"anchor\" id=\"loop-execução-repetida-dentro-da-sessão-atual\"\u003e\u003c/a\u003e\u003ccode\u003e/loop\u003c/code\u003e: execução repetida dentro da sessão atual\u003c/h3\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003e/loop 10m verificar o PR atual, incorporar novas reviews,\n\u003c/span\u003e\u003cspan\u003ee se houver CI com falha, analisar a causa e corrigir.\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eAs principais formas descritas na documentação atual são as seguintes.\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eEntrada\u003c/th\u003e\n\u003cth\u003eComportamento\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003ccode\u003e/loop 5m \u0026lt;prompt\u0026gt;\u003c/code\u003e\u003c/td\u003e\n\u003ctd\u003eExecuta o Prompt em um intervalo fixo especificado\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003ccode\u003e/loop \u0026lt;prompt\u0026gt;\u003c/code\u003e\u003c/td\u003e\n\u003ctd\u003eClaude escolhe o intervalo a cada repetição\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003ccode\u003e/loop\u003c/code\u003e\u003c/td\u003e\n\u003ctd\u003eExecuta o Prompt built-in de manutenção ou o \u003ccode\u003eloop.md\u003c/code\u003e do projeto\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003ccode\u003e/loop 20m /review-pr 1234\u003c/code\u003e\u003c/td\u003e\n\u003ctd\u003eReexecuta uma Skill permitida no intervalo especificado\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003e\u003ccode\u003e/loop\u003c/code\u003e depende da sessão atual do Claude Code. O computador e a sessão precisam estar em execução, e ao iniciar uma nova conversa as tarefas no escopo da sessão desaparecem. Tarefas não expiradas podem ser restauradas com \u003ccode\u003e--resume\u003c/code\u003e ou \u003ccode\u003e--continue\u003c/code\u003e, mas tarefas repetitivas expiram por padrão 7 dias após a criação. Ciclos perdidos também não são executados retroativamente.\u003c/p\u003e\n\u003cp\u003eComo Jitter pode ser aplicado ao Scheduler da sessão, ele pode não ser adequado para requisitos operacionais que precisam “executar obrigatoriamente no horário exato”.\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#schedule-cloud-routine-gerenciada-pela-anthropic\" class=\"anchor\" id=\"schedule-cloud-routine-gerenciada-pela-anthropic\"\u003e\u003c/a\u003e\u003ccode\u003e/schedule\u003c/code\u003e: Cloud Routine gerenciada pela Anthropic\u003c/h3\u003e\n\u003cp\u003e\u003ccode\u003e/schedule\u003c/code\u003e cria uma Routine que combina Prompt, Repository, Connector e Trigger para execução na infraestrutura gerenciada pela Anthropic. Ela pode executar mesmo com o notebook fechado, e a documentação oficial a apresenta como Research Preview.\u003c/p\u003e\n\u003cp\u003eOs Triggers suportados por Routine são os seguintes.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eAgenda repetida\u003c/li\u003e\n\u003cli\u003eAgenda única em um momento futuro específico\u003c/li\u003e\n\u003cli\u003eChamada de API autenticada\u003c/li\u003e\n\u003cli\u003eEvento de GitHub Pull request ou Release\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eVários Triggers podem ser conectados a uma única Routine. Por exemplo, uma PR Review Routine pode rodar todas as noites e também reagir ao evento \u003ccode\u003epull_request.opened\u003c/code\u003e.\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#comparação-entre-loop-e-schedule\" class=\"anchor\" id=\"comparação-entre-loop-e-schedule\"\u003e\u003c/a\u003eComparação entre \u003ccode\u003e/loop\u003c/code\u003e e \u003ccode\u003e/schedule\u003c/code\u003e\u003c/h3\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eCategoria\u003c/th\u003e\n\u003cth\u003e\u003ccode\u003e/loop\u003c/code\u003e\u003c/th\u003e\n\u003cth\u003e\u003ccode\u003e/schedule\u003c/code\u003e Routine\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd\u003eLocal de execução\u003c/td\u003e\n\u003ctd\u003eComputador e sessão atuais\u003c/td\u003e\n\u003ctd\u003eCloud gerenciada pela Anthropic\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eExecução após desligar o computador\u003c/td\u003e\n\u003ctd\u003eGeralmente não disponível\u003c/td\u003e\n\u003ctd\u003eDisponível\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eSessão aberta necessária\u003c/td\u003e\n\u003ctd\u003eNecessária\u003c/td\u003e\n\u003ctd\u003eDesnecessária\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eArquivos locais não commitados\u003c/td\u003e\n\u003ctd\u003eAcessíveis\u003c/td\u003e\n\u003ctd\u003eInacessíveis, Repository é clonado novamente a cada execução\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eIntervalo mínimo\u003c/td\u003e\n\u003ctd\u003e1 minuto segundo a documentação oficial\u003c/td\u003e\n\u003ctd\u003e1 hora segundo a documentação oficial\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003ePersistência\u003c/td\u003e\n\u003ctd\u003eCentrado na sessão, tarefas repetitivas expiram em 7 dias\u003c/td\u003e\n\u003ctd\u003eRoutine salva na conta\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003ePrompt de permissão\u003c/td\u003e\n\u003ctd\u003eHerda a política da sessão atual\u003c/td\u003e\n\u003ctd\u003eExecução autônoma sem aprovação interativa\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eUso adequado\u003c/td\u003e\n\u003ctd\u003eMonitoramento curto de PR·deploy\u003c/td\u003e\n\u003ctd\u003eAutomação operacional contínua\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003ch3\u003e\u003ca href=\"#quando-event-é-melhor-que-polling\" class=\"anchor\" id=\"quando-event-é-melhor-que-polling\"\u003e\u003c/a\u003eQuando Event é melhor que Polling\u003c/h3\u003e\n\u003cp\u003eSe um PR com poucas alterações for verificado a cada 1 minuto, a maioria das execuções terminará sem fazer nada. Se o sistema externo puder enviar eventos, a estrutura abaixo é mais eficiente.\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003eFalha de CI ou atualização de PR\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003eGitHub Trigger ou Routine API\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003eExecutar Claude apenas quando necessário\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eO design baseado em Event reduz atrasos e diminui chamadas desnecessárias ao modelo e consumo de tokens. Quando Polling for inevitável, é recomendável aumentar o intervalo de acordo com a frequência real de mudanças e aplicar Backoff quando não houver mudanças por longo período.\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#condições-obrigatórias-de-tarefas-baseadas-em-tempo\" class=\"anchor\" id=\"condições-obrigatórias-de-tarefas-baseadas-em-tempo\"\u003e\u003c/a\u003eCondições obrigatórias de tarefas baseadas em tempo\u003c/h3\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eIdempotência\u003c/strong\u003e: mesmo recebendo o mesmo evento várias vezes, não devem surgir comentários duplicados, PRs duplicados ou deploys duplicados.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eEstado de processamento\u003c/strong\u003e: deve-se registrar o último Event ID, Commit SHA, Review Comment ID etc.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eEstado de encerramento\u003c/strong\u003e: deve ser possível determinar encerramento, como PR merge·close, Queue empty, Deploy success·rollback.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eEscopo de escrita\u003c/strong\u003e: Side effects devem ser limitados, como permitir comentários, proibir Merge, fazer Push apenas em Branch \u003ccode\u003eclaude/*\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eTratamento de falhas\u003c/strong\u003e: são necessárias regras de retentativa e Escalation em caso de falha de serviço externo, expiração de autenticação, Rate limit ou falta de permissão.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2\u003e\u003ca href=\"#6-proactive-loop-transferir-descoberta-de-tarefas-e-orquestração\" class=\"anchor\" id=\"6-proactive-loop-transferir-descoberta-de-tarefas-e-orquestração\"\u003e\u003c/a\u003e6. Proactive Loop: transferir descoberta de tarefas e orquestração\u003c/h2\u003e\n\u003cp\u003eProactive Loop não é um único comando, mas uma arquitetura de automação contínua que combina vários recursos.\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003eTrigger\n\u003c/span\u003e\u003cspan\u003e+ Goal\n\u003c/span\u003e\u003cspan\u003e+ Skills\n\u003c/span\u003e\u003cspan\u003e+ Dynamic Workflow\n\u003c/span\u003e\u003cspan\u003e+ Auto mode\n\u003c/span\u003e\u003cspan\u003e+ Repository·Connector·Browser·CI ferramentas\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eMesmo sem uma pessoa digitando prompts em tempo real, novas tarefas são detectadas, processadas, verificadas e relatadas.\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#exemplo-tratamento-automático-de-feedback-de-bugs\" class=\"anchor\" id=\"exemplo-tratamento-automático-de-feedback-de-bugs\"\u003e\u003c/a\u003eExemplo: tratamento automático de feedback de bugs\u003c/h3\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003eReceber GitHub Issue ou feedback no Slack\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003eClassificar duplicidade·prioridade·reprodutibilidade\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003eCriar teste de reprodução\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003eExplorar soluções candidatas\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003eImplementar a solução escolhida\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003eReview Agent independente procura contraexemplos\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003eVerificações de teste·build·segurança\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003eDraft PR e relatório de resultado\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eAs responsabilidades por componente são as seguintes.\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eComponente\u003c/th\u003e\n\u003cth\u003eResponsabilidade\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd\u003eTrigger ou \u003ccode\u003e/schedule\u003c/code\u003e\u003c/td\u003e\n\u003ctd\u003eDeterminar quando iniciar uma nova tarefa\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003ccode\u003e/goal\u003c/code\u003e\u003c/td\u003e\n\u003ctd\u003eDefinir o que é estado de conclusão nesta execução\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eSkill\u003c/td\u003e\n\u003ctd\u003ePadronizar procedimentos de reprodução, implementação, verificação e relatório\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eDynamic Workflow\u003c/td\u003e\n\u003ctd\u003eExecução paralela e ramificação condicional de múltiplos Subagents\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eAuto mode\u003c/td\u003e\n\u003ctd\u003eExecutar chamadas de ferramentas permitidas sem esperar aprovação\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003ePermission policy\u003c/td\u003e\n\u003ctd\u003eFixar escopos de proibição·aprovação·permissão automática\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003ch3\u003e\u003ca href=\"#dynamic-workflow-e-worktree\" class=\"anchor\" id=\"dynamic-workflow-e-worktree\"\u003e\u003c/a\u003eDynamic Workflow e Worktree\u003c/h3\u003e\n\u003cp\u003eDynamic Workflow é uma estrutura em que o Runtime executa um Script de orquestração JavaScript escrito por Claude. Em chamadas comuns de Subagent, Claude escolhe o próximo Agent a cada Turn; em Workflow, Loop, processamento paralelo, ramificação e armazenamento de resultados intermediários passam para o Script.\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003eWorkflow Script\n\u003c/span\u003e\u003cspan\u003e  ├─ Agent A: análise de requisitos\n\u003c/span\u003e\u003cspan\u003e  ├─ Agent B: design de testes\n\u003c/span\u003e\u003cspan\u003e  ├─ Agent C: exploração de candidatos de implementação\n\u003c/span\u003e\u003cspan\u003e  ├─ Agent D: revisão de segurança\n\u003c/span\u003e\u003cspan\u003e  └─ Judge: comparação baseada em evidências\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eComo os resultados intermediários ficam em variáveis do Script, e não no Context da conversa principal, tarefas em grande escala podem ser organizadas de forma mais reproduzível. A documentação atual especifica limites de Runtime de até 16 Agents simultâneos e até 1,000 Agents por execução, mas limitações em estágio de produto Preview podem mudar.\u003c/p\u003e\n\u003cp\u003eSe for necessário testar vários candidatos de implementação ao mesmo tempo, é possível separar os espaços de trabalho com Git Worktree.\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003erepo/\n\u003c/span\u003e\u003cspan\u003eworktree-solution-a/\n\u003c/span\u003e\u003cspan\u003eworktree-solution-b/\n\u003c/span\u003e\u003cspan\u003eworktree-solution-c/\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eQuando cada Agent trabalha em uma Branch e diretório independentes, é possível reduzir problemas de sobrescrever os mesmos arquivos simultaneamente. O Judge Agent deve comparar os candidatos com base em cumprimento dos requisitos, resultados de testes, risco de regressão, escopo de mudança, complexidade, desempenho, segurança e consistência com a arquitetura existente.\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#mais-agents-nem-sempre-é-melhor\" class=\"anchor\" id=\"mais-agents-nem-sempre-é-melhor\"\u003e\u003c/a\u003eMais Agents nem sempre é melhor\u003c/h3\u003e\n\u003cp\u003eSe apenas aumentar o número de Agents em uma tarefa sem paralelismo, o custo e a latência aumentam. Se vários Agents compartilharem a mesma suposição incorreta, o erro também pode ser ampliado.\u003c/p\u003e\n\u003cp\u003eDynamic Workflow é adequado nos seguintes casos.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eMigration aplicando a mesma transformação a centenas de arquivos\u003c/li\u003e\n\u003cli\u003eAudit de segurança·qualidade em toda a base de código\u003c/li\u003e\n\u003cli\u003eComparação de Plans sob várias perspectivas independentes\u003c/li\u003e\n\u003cli\u003eResearch que exige dividir muitos itens e fazer verificação cruzada\u003c/li\u003e\n\u003cli\u003eTarefas em que é difícil colocar todos os resultados intermediários no Context de um único Agent\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003ePara pequenas correções de bug, refatoração de um arquivo ou adição simples de testes, um Turn-based Loop comum ou \u003ccode\u003e/goal\u003c/code\u003e é melhor.\u003c/p\u003e\n\u003ch2\u003e\u003ca href=\"#7-sistema-para-manter-a-qualidade-do-código-em-loop\" class=\"anchor\" id=\"7-sistema-para-manter-a-qualidade-do-código-em-loop\"\u003e\u003c/a\u003e7. Sistema para manter a qualidade do código em Loop\u003c/h2\u003e\n\u003cp\u003eA qualidade dos resultados de Loop depende fortemente não apenas do modelo em si, mas também do sistema de verificação ao redor do modelo.\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#71-organizar-a-base-de-código\" class=\"anchor\" id=\"71-organizar-a-base-de-código\"\u003e\u003c/a\u003e7.1 Organizar a base de código\u003c/h3\u003e\n\u003cp\u003eClaude segue fortemente os padrões do código existente. Se houver APIs antigas, implementações duplicadas, estrutura de testes pouco clara, módulos enormes ou regras inconsistentes de tratamento de exceções, o Loop pode replicar rapidamente esses problemas.\u003c/p\u003e\n\u003cp\u003eAs bases essenciais são as seguintes.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eFormatter e lint\u003c/li\u003e\n\u003cli\u003eLimites claros de diretórios e módulos\u003c/li\u003e\n\u003cli\u003eUnit·Integration·E2E Test confiáveis\u003c/li\u003e\n\u003cli\u003eDistinção entre APIs em uso e Deprecated APIs\u003c/li\u003e\n\u003cli\u003eRegras de desenvolvimento específicas do projeto\u003c/li\u003e\n\u003cli\u003eAmbiente Build·Dev reproduzível\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3\u003e\u003ca href=\"#72-criar-definition-of-done-por-tipo-de-mudança\" class=\"anchor\" id=\"72-criar-definition-of-done-por-tipo-de-mudança\"\u003e\u003c/a\u003e7.2 Criar Definition of Done por tipo de mudança\u003c/h3\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eTipo de mudança\u003c/th\u003e\n\u003cth\u003eVerificação mínima\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd\u003eAPI\u003c/td\u003e\n\u003ctd\u003eTestes de contrato, compatibilidade retroativa, atualização de exemplos de Schema·documentação\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eFrontend\u003c/td\u003e\n\u003ctd\u003eInteração real no navegador, erros de console, acessibilidade, telas responsivas\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eDatabase\u003c/td\u003e\n\u003ctd\u003eForward·Rollback Migration, escopo de Lock, plano de execução\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eDependency\u003c/td\u003e\n\u003ctd\u003eBuild, principais testes de regressão, verificação de License·Security\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eInfrastructure\u003c/td\u003e\n\u003ctd\u003ePlan Diff, privilégio mínimo, Rollback, verificação de exposição de segredos\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003eÉ melhor fixar esses critérios em Skill, Hook, Script ou CI Rule do que repeti-los longamente em cada Prompt.\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#73-fornecer-documentação-atualizada-e-versões-exatas\" class=\"anchor\" id=\"73-fornecer-documentação-atualizada-e-versões-exatas\"\u003e\u003c/a\u003e7.3 Fornecer documentação atualizada e versões exatas\u003c/h3\u003e\n\u003cp\u003eLoop pode repetir suposições incorretas várias vezes. É preciso facilitar a localização da Version exata usada no projeto, documentação oficial, documentos internos de Architecture, especificações de API, Migration Guide e exemplos aprovados.\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#74-separar-agent-implementador-e-review-agent\" class=\"anchor\" id=\"74-separar-agent-implementador-e-review-agent\"\u003e\u003c/a\u003e7.4 Separar Agent implementador e Review Agent\u003c/h3\u003e\n\u003cp\u003eO Agent que implementou já é influenciado pelo design e pelo raciocínio que escolheu. Um Review Agent em novo Context pode fazer as seguintes perguntas de forma mais independente.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eOs testes foram enfraquecidos para fazê-los passar?\u003c/li\u003e\n\u003cli\u003eArquivos fora do escopo foram alterados?\u003c/li\u003e\n\u003cli\u003eA fronteira de segurança foi quebrada?\u003c/li\u003e\n\u003cli\u003eCaminhos de falha e testes de valores-limite ficaram de fora?\u003c/li\u003e\n\u003cli\u003eHouve regressão em funcionalidades existentes?\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eÉ mais eficaz escrever o Review Prompt como “assuma que a implementação está errada, encontre contraexemplos e anexe evidência de reprodução a cada apontamento” do que “resuma os pontos positivos”.\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#75-conectar-falhas-individuais-a-melhorias-de-sistema\" class=\"anchor\" id=\"75-conectar-falhas-individuais-a-melhorias-de-sistema\"\u003e\u003c/a\u003e7.5 Conectar falhas individuais a melhorias de sistema\u003c/h3\u003e\n\u003cp\u003eSe o mesmo erro se repete, não basta corrigir apenas aquele resultado. É preciso alterar um dos itens abaixo para dificultar a recorrência do tipo de falha.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eAdicionar Regression Test\u003c/li\u003e\n\u003cli\u003eReforçar o procedimento de verificação da Skill\u003c/li\u003e\n\u003cli\u003eAdicionar regra em \u003ccode\u003eCLAUDE.md\u003c/code\u003e\u003c/li\u003e\n\u003cli\u003eAdicionar Hook ou lint Rule\u003c/li\u003e\n\u003cli\u003eAdicionar regra Deny de permissão\u003c/li\u003e\n\u003cli\u003eReforçar a condição de conclusão do Goal\u003c/li\u003e\n\u003cli\u003eComplementar a Review Checklist\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eBoa Loop Engineering não é o trabalho de corrigir uma falha uma vez, mas \u003cstrong\u003ecriar um sistema em que esse tipo de falha tenha dificuldade de reaparecer\u003c/strong\u003e.\u003c/p\u003e\n\u003ch2\u003e\u003ca href=\"#8-gerenciamento-de-token-e-custo\" class=\"anchor\" id=\"8-gerenciamento-de-token-e-custo\"\u003e\u003c/a\u003e8. Gerenciamento de Token e custo\u003c/h2\u003e\n\u003cp\u003eO custo de Loop pode aumentar bastante em relação a um único Prompt.\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003eCusto total ≈\n\u003c/span\u003e\u003cspan\u003ecusto dos Turns do Agent principal\n\u003c/span\u003e\u003cspan\u003e+ custo de avaliação do Goal\n\u003c/span\u003e\u003cspan\u003e+ custo de Subagent\n\u003c/span\u003e\u003cspan\u003e+ custo de repetição de Workflow\n\u003c/span\u003e\u003cspan\u003e+ custo de Context para ler resultados de ferramentas\n\u003c/span\u003e\u003cspan\u003e+ frequência de execução baseada em tempo\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eA cobrança exata varia conforme Plan, Model e Provider, mas os princípios que determinam a estrutura de custo são os mesmos.\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#princípios-práticos-para-reduzir-custo\" class=\"anchor\" id=\"princípios-práticos-para-reduzir-custo\"\u003e\u003c/a\u003ePrincípios práticos para reduzir custo\u003c/h3\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eNão usar Loop para tarefas pequenas.\u003c/strong\u003e Erros de digitação, mudanças de nome e erros de tipo em um arquivo devem ser tratados em um único Turn.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eUsar condição de sucesso junto com Hard stop.\u003c/strong\u003e Considerar sucesso, máximo de Turns, tempo máximo, falhas consecutivas e erros de permissão.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eTestar Workflows grandes em escopo pequeno.\u003c/strong\u003e Validar custo e qualidade em 5 arquivos, um diretório ou algumas Issues antes de expandir.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eTratar tarefas determinísticas com Script.\u003c/strong\u003e Substituições AST, conversões JSON, Formatting e geração de formatos fixos são mais baratos e reproduzíveis com Scripts verificados.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eAjustar o ciclo de Polling à frequência real de mudanças.\u003c/strong\u003e Usar Event Trigger sempre que possível.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eObservar o uso em andamento.\u003c/strong\u003e Verificar uso de Skill·Subagent·MCP·Turn·Token em \u003ccode\u003e/usage\u003c/code\u003e, \u003ccode\u003e/goal\u003c/code\u003e, \u003ccode\u003e/workflows\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eNão continuar tentando quando o mesmo erro se repete.\u003c/strong\u003e Definir limite de falhas consecutivas e fazer Escalation para uma pessoa.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch3\u003e\u003ca href=\"#model-e-effort-são-alavancas-diferentes\" class=\"anchor\" id=\"model-e-effort-são-alavancas-diferentes\"\u003e\u003c/a\u003eModel e Effort são alavancas diferentes\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eModel\u003c/strong\u003e altera a capacidade básica de raciocínio e o escopo dos problemas solucionáveis.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eEffort\u003c/strong\u003e altera o número de arquivos lidos, o número de ferramentas usadas, a amplitude da verificação e até que ponto tarefas de várias etapas são levadas adiante.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eSe Claude confirmou todos os arquivos e testes necessários, mas o julgamento em si continua errado, pode ser necessário um Model mais forte. Por outro lado, se arquivos importantes não são lidos, testes são pulados ou a refatoração termina no meio, aumentar Effort pode ser mais apropriado.\u003c/p\u003e\n\u003ch2\u003e\u003ca href=\"#9-permissões-e-fronteiras-de-segurança\" class=\"anchor\" id=\"9-permissões-e-fronteiras-de-segurança\"\u003e\u003c/a\u003e9. Permissões e fronteiras de segurança\u003c/h2\u003e\n\u003cp\u003eO design mais perigoso em Proactive Loop é conceder permissões amplas ao Agent e deixar frouxas as condições de sucesso e interrupção.\u003c/p\u003e\n\u003cp\u003eAuto mode reduz Prompts comuns de permissão, mas Tool calls difíceis de reverter, destrutivas ou direcionadas para fora da fronteira de confiança podem ser bloqueadas pelo classificador. Além disso, \u003ccode\u003epermissions.ask\u003c/code\u003e e \u003ccode\u003epermissions.deny\u003c/code\u003e explícitos têm prioridade sobre Auto mode.\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#exemplo-de-camadas-de-permissão\" class=\"anchor\" id=\"exemplo-de-camadas-de-permissão\"\u003e\u003c/a\u003eExemplo de camadas de permissão\u003c/h3\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eNível\u003c/th\u003e\n\u003cth\u003eExemplo\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd\u003ePermitir automaticamente\u003c/td\u003e\n\u003ctd\u003eLeitura de código, testes·lint·Build, análise, criação de Branch \u003ccode\u003eclaude/*\u003c/code\u003e, criação de Draft PR\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eAprovação humana\u003c/td\u003e\n\u003ctd\u003eAplicar em Default Branch, deploy em produção, aplicar DB Migration, enviar mensagens externas a clientes\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eSempre proibido\u003c/td\u003e\n\u003ctd\u003eForce push, saída de Secret, exclusão de dados de produção, bypass de permissões, remoção de logs de auditoria\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003eÉ mais seguro fixar em Rules permanentes de \u003ccode\u003eask\u003c/code\u003e·\u003ccode\u003edeny\u003c/code\u003e do que dizer uma vez na conversa “não faça Push”. Isso porque regras da conversa podem enfraquecer com compressão de Context ou mudança de sessão.\u003c/p\u003e\n\u003cp\u003eCloud Routine clona novamente o Repository a cada execução e opera com permissões conectadas de GitHub·Connector. Os seguintes escopos devem ser minimizados.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eRepository e Branch acessíveis\u003c/li\u003e\n\u003cli\u003eNetwork Domain permitido\u003c/li\u003e\n\u003cli\u003eConnector a usar\u003c/li\u003e\n\u003cli\u003eVariáveis de ambiente e Secret\u003c/li\u003e\n\u003cli\u003ePermissões de escrita em sistemas externos\u003c/li\u003e\n\u003cli\u003eEscopo de criação de PR·Push·Merge\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eO estado “encerramento normal” na lista de execuções de Routine pode significar apenas que a Session terminou sem erro de Infrastructure, e não garante que o objetivo de negócio teve sucesso. Transcript, Test evidence e Diff gerado devem ser revisados separadamente.\u003c/p\u003e\n\u003ch2\u003e\u003ca href=\"#10-template-de-design-de-loop-para-projetos-de-desenvolvimento\" class=\"anchor\" id=\"10-template-de-design-de-loop-para-projetos-de-desenvolvimento\"\u003e\u003c/a\u003e10. Template de design de Loop para projetos de desenvolvimento\u003c/h2\u003e\n\u003cp\u003eO YAML abaixo não é uma sintaxe real do Claude Code, mas um Template para revisão de design.\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003etrigger\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003etype\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003emanual | interval | schedule | github_event | api_event\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003escope\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003erepositories\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003etarget-repository\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003eallowed_paths\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003esrc/**\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003etests/**\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003eprohibited_paths\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003eproduction/**\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003esecrets/**\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003etask\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003eobjective\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003eobjetivo a alterar ou processar\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003einput\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003eIssue, Event, File ou estado recém-recebido\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003everification\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003ecommands\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003eunit-test\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003eintegration-test\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003elint\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003ebuild\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003eruntime_checks\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003ebrowser-interaction\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003econsole-errors\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003eaccessibility\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003eevidence\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003ecommand-output\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003eexit-code\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003etest-summary\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003escreenshots\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003esuccess\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003econdition\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003eestado de conclusão que pode ser julgado como verdadeiro ou falso\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003estop\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003emax_turns\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003e12\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003emax_duration_minutes\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003e45\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003emax_consecutive_failures\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003e3\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003estop_on_permission_error\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003etrue\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003eescalate_on_external_outage\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003etrue\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003eside_effects\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003eidempotency_key\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003eevent-id-or-commit-sha\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003eallow_branch_push\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003eclaude/*\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003erequire_human_for_merge\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003etrue\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003erequire_human_for_deploy\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003etrue\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003ereview\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003eindependent_agent\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003etrue\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003eadversarial_review\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003etrue\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003eobservability\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003ereport_progress\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003etrue\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003ereport_token_usage\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003etrue\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003ereport_changed_files\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003etrue\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003ereport_remaining_failures\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003etrue\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eOs itens mais importantes não são a frase do prompt em si, mas os cinco pontos a seguir.\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003eTrigger\n\u003c/span\u003e\u003cspan\u003eVerifier\n\u003c/span\u003e\u003cspan\u003eSuccess condition\n\u003c/span\u003e\u003cspan\u003eHard stop\n\u003c/span\u003e\u003cspan\u003ePermission boundary\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003ch2\u003e\u003ca href=\"#11-qual-loop-escolher\" class=\"anchor\" id=\"11-qual-loop-escolher\"\u003e\u003c/a\u003e11. Qual Loop escolher\u003c/h2\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eSituação\u003c/th\u003e\n\u003cth\u003eAbordagem recomendada\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd\u003eTarefa que termina com uma única correção e verificação\u003c/td\u003e\n\u003ctd\u003eTurn-based\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eTarefa que exige várias tentativas, mas tem estado de conclusão claro\u003c/td\u003e\n\u003ctd\u003e\u003ccode\u003e/goal\u003c/code\u003e\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eTarefa que precisa esperar por um tempo o estado de CI·PR·deploy externo\u003c/td\u003e\n\u003ctd\u003e\u003ccode\u003e/loop\u003c/code\u003e\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eTrabalho que precisa executar repetidamente mesmo com o notebook fechado\u003c/td\u003e\n\u003ctd\u003e\u003ccode\u003e/schedule\u003c/code\u003e Routine\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eTrabalho que precisa reagir imediatamente a eventos do GitHub ou Alert\u003c/td\u003e\n\u003ctd\u003eEvent-triggered Routine\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eTrabalho que exige processar centenas de itens em paralelo e fazer verificação cruzada\u003c/td\u003e\n\u003ctd\u003eDynamic Workflow\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eTransformação cujas regras de entrada e saída são totalmente determinísticas\u003c/td\u003e\n\u003ctd\u003eScript ou CI Job\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003eA ordem de escolha deve se basear não no “recurso mais poderoso”, mas na “estrutura de controle mais simples que atinge o objetivo”.\u003c/p\u003e\n\u003ch2\u003e\u003ca href=\"#12-ordem-segura-de-adoção\" class=\"anchor\" id=\"12-ordem-segura-de-adoção\"\u003e\u003c/a\u003e12. Ordem segura de adoção\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eEscolha uma tarefa de gargalo que uma pessoa verifica repetidamente.\u003c/li\u003e\n\u003cli\u003ePrimeiro, transforme o procedimento de verificação em Skill, Script e CI.\u003c/li\u003e\n\u003cli\u003eEstabilize a qualidade da verificação no modo Turn-based.\u003c/li\u003e\n\u003cli\u003eSe o estado de conclusão for claro, adicione \u003ccode\u003e/goal\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eUse \u003ccode\u003e/loop\u003c/code\u003e apenas quando for necessário esperar um estado externo.\u003c/li\u003e\n\u003cli\u003eSe for necessária execução de longo prazo, mova para \u003ccode\u003e/schedule\u003c/code\u003e Routine.\u003c/li\u003e\n\u003cli\u003eExpanda para Dynamic Workflow e Proactive Loop apenas depois de verificar idempotência, permissões e custo.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2\u003e\u003ca href=\"#13-mal-entendidos-frequentes\" class=\"anchor\" id=\"13-mal-entendidos-frequentes\"\u003e\u003c/a\u003e13. Mal-entendidos frequentes\u003c/h2\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eMal-entendido\u003c/th\u003e\n\u003cth\u003eInterpretação correta\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd\u003eLoop é execução infinita\u003c/td\u003e\n\u003ctd\u003eÉ uma estrutura de repetição limitada com condição de sucesso e Hard stop\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eO relatório de conclusão do Agent é verificação\u003c/td\u003e\n\u003ctd\u003eSão necessários saída de comandos externos, código de saída e resultado em Runtime\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003ccode\u003e/goal\u003c/code\u003e permite automaticamente todas as permissões\u003c/td\u003e\n\u003ctd\u003eEle apenas inicia automaticamente o próximo Turn; a política de permissões é separada\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003ccode\u003e/loop\u003c/code\u003e é um Scheduler de operação de longo prazo\u003c/td\u003e\n\u003ctd\u003eÉ centrado na sessão e tem expiração de 7 dias e restrições de ambiente de execução\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eQuanto mais Agents, melhor o resultado\u003c/td\u003e\n\u003ctd\u003eA paralelização só tem valor quando papéis·perspectivas·verificações são diferentes\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eToda tarefa repetitiva deve ser feita por LLM\u003c/td\u003e\n\u003ctd\u003ePartes determinísticas são mais baratas e reproduzíveis com Script\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003ch2\u003e\u003ca href=\"#conclusão\" class=\"anchor\" id=\"conclusão\"\u003e\u003c/a\u003eConclusão\u003c/h2\u003e\n\u003cp\u003eLoop Engineering não é uma técnica para executar AI por mais tempo, mas o \u003cstrong\u003edesign de um sistema de controle que faz a AI descobrir por si mesma quando erra, corrigir dentro de um limite de custo e parar em pontos perigosos\u003c/strong\u003e.\u003c/p\u003e\n\u003cp\u003eLLM é forte em exploração, raciocínio, implementação, análise de exceções e comparação de alternativas. O sistema deve cuidar do momento de execução, escopo de mudança, método de verificação, critério de encerramento, limite de custo e fronteira de aprovação. Quanto mais clara essa divisão de papéis, mais a automação do Claude Code deixa de ser uma simples ferramenta de geração de código e se aproxima de um sistema de operação de desenvolvimento reproduzível e auditável.\u003c/p\u003e\n","tags":["Claude Code","Engenharia de loops","Agente de IA","Automação de desenvolvimento","Fluxo de agentes"],"faqs":[{"question":"Em que o Loop do Claude Code é diferente de laços de repetição comuns for·while?","answer":"Laços de repetição comuns repetem de forma determinística os comandos definidos no código. O Loop do Claude Code é uma estrutura de controle de agente em que o Agent observa o código e o estado externo, infere a próxima ação, executa ferramentas, valida o resultado e então volta a trabalhar conforme a condição de encerramento."},{"question":"Quando o Turn-based Loop é mais adequado?","answer":"Ele é adequado para tarefas curtas, pontuais, cujos resultados o usuário pode revisar imediatamente. Porém, se o procedimento de validação se repetir, como em UI·API·banco de dados, é melhor transformar esse procedimento em uma Skill ou Script para que Claude faça a própria validação usando os mesmos critérios."},{"question":"O modelo de avaliação de `/goal` verifica diretamente arquivos e resultados de testes?","answer":"Não. O modelo de avaliação não chama ferramentas nem lê arquivos diretamente; ele julga as condições do Goal e as evidências que aparecem na conversa. O Claude responsável pela tarefa deve deixar claramente no resultado o comando de teste, o código de saída, os arquivos alterados e a causa da falha."},{"question":"O que deve entrar em boas condições de `/goal`?","answer":"É necessário incluir um estado de conclusão mensurável, o comando ou a ferramenta que comprovará esse estado, o escopo que pode ser alterado e o escopo proibido, além de um Hard stop como máximo de Turn·tempo·falhas consecutivas. Uma condição como “testes e lint com código de saída 0 e sem Diff fora dos caminhos especificados” é melhor do que “refatorar de forma limpa”."},{"question":"`/goal` tem um máximo automático de Turn ou limite de tempo?","answer":"O Goal continua até que o modelo de avaliação determine o sucesso ou o usuário interrompa com `/goal clear`. Para limitar o orçamento de execução, é preciso incluir diretamente nas condições do Goal cláusulas de Turn·tempo, como “interromper após no máximo 12 turnos ou 45 minutos”."},{"question":"Ao usar `/goal`, as permissões de ferramentas também são autorizadas automaticamente?","answer":"Não. `/goal` inicia automaticamente o próximo Turn, mas as políticas de permissão para gravação de arquivos, Shell, Git e Connector externo permanecem as mesmas. Se precisar de execução sem supervisão, considere o Auto mode, mas controle separadamente as operações arriscadas com regras `ask`·`deny`."},{"question":"Qual é a maior diferença entre `/loop` e `/schedule`?","answer":"`/loop` é um meio de Polling de curto prazo que executa repetidamente na sessão atual do Claude Code e no computador atual. `/schedule` salva Prompt, Repository, Connector e Trigger como uma Cloud Routine e executa na infraestrutura gerenciada pela Anthropic, portanto não exige uma sessão aberta nem um notebook ligado."},{"question":"Se eu desligar o computador, `/loop` continua em execução?","answer":"Em geral, não continua em execução. `/loop` é uma tarefa no escopo da sessão e exige que o Claude Code esteja em execução. Para automações de longo prazo, é necessário usar um Scheduler sustentável, como Cloud Routine, Desktop scheduled task ou GitHub Actions."},{"question":"Por que Event Trigger é melhor do que Polling por tempo?","answer":"Porque não cria chamadas desnecessárias ao modelo quando não há mudanças e pode executar logo após uma alteração real. Para sistemas que podem emitir eventos, como falha de CI, atualização de PR ou Alert, conectá-los via GitHub Trigger ou Routine API é melhor tanto em custo quanto em latência."},{"question":"Por que colocar o procedimento de validação em `SKILL.md` em vez de `CLAUDE.md`?","answer":"`CLAUDE.md` é adequado para regras curtas que devem ser aplicadas sempre ao projeto como um todo, enquanto a Skill é adequada para agrupar procedimentos e arquivos de suporte necessários apenas em tarefas específicas. Separar uma checklist longa de validação como Skill permite carregá-la apenas em trabalhos relevantes e executá-la novamente diretamente."},{"question":"Em que Dynamic Workflow é diferente de uma chamada comum de Subagent?","answer":"No método comum de Subagent, Claude escolhe o próximo executor a cada Turn, e os resultados se acumulam no Context. No Dynamic Workflow, um JavaScript Script gerencia execução paralela, ramificações, repetição e resultados intermediários, permitindo organizar grandes Migration·Audit·validações cruzadas de forma mais reproduzível."},{"question":"Usar vários Agent sempre melhora a qualidade?","answer":"Não. Se os papéis e pontos de vista se sobrepõem, eles podem repetir os mesmos erros e apenas aumentar o custo. O valor de Agent paralelos surge quando as responsabilidades são separadas, como implementação, desenho de testes, revisão de segurança, análise de regressão e Judge, e quando se exige evidência independente para cada conclusão."},{"question":"Como evitar trabalho duplicado em Time-based ou Proactive Loop?","answer":"É necessário armazenar chaves de idempotência como Event ID, Commit SHA e Review Comment ID, além do último status de processamento. A etapa de verificação deve incluir regras para não processar novamente mensagens já respondidas, PRs já criados e Commits já processados."},{"question":"Que tipo de tarefa é boa para o primeiro Loop a ser automatizado?","answer":"São boas as tarefas que uma pessoa verifica repetidamente, mas que têm poucos efeitos colaterais perigosos e cujo estado de conclusão pode ser medido com clareza. Por exemplo, é seguro começar pelo resumo das causas de CI com falha em PRs, pela detecção de inconsistências entre documentos e código e pela validação de testes e lint definidos, e depois ampliar gradualmente as permissões de correção e Push."}],"sources":[{"url":"https://claude.com/blog/getting-started-with-loops","title":"Engenharia de loops: primeiros passos com loops | Claude da Anthropic","type":"source"},{"url":"https://code.claude.com/docs/en/skills","title":"Estender Claude com habilidades - Documentação do Claude Code","type":"source"},{"url":"https://code.claude.com/docs/en/goal","title":"Manter Claude trabalhando em direção a uma meta - Documentação do Claude Code","type":"source"},{"url":"https://code.claude.com/docs/en/scheduled-tasks","title":"Executar prompts em uma programação - Documentação do Claude Code","type":"source"},{"url":"https://code.claude.com/docs/en/routines","title":"Automatizar o trabalho com rotinas - Documentação do Claude Code","type":"source"},{"url":"https://code.claude.com/docs/en/workflows","title":"Orquestrar subagentes em escala com fluxos de trabalho dinâmicos - Documentação do Claude Code","type":"source"},{"url":"https://claude.com/blog/claude-model-and-effort-level-in-claude-code","title":"Escolher um modelo Claude e o nível de esforço no Claude Code | Claude da Anthropic","type":"source"},{"url":"https://code.claude.com/docs/en/auto-mode-config","title":"Configurar o modo automático - Documentação do Claude Code","type":"source"}],"images":[{"id":195,"url":"https://injoys.com/rails/active_storage/blobs/redirect/eyJfcmFpbHMiOnsiZGF0YSI6MTg3OSwicHVyIjoiYmxvYl9pZCJ9fQ==--cac49ec584371c2261bd3272e7574ca38ecc1f85/ChatGPT%20Image%202026%E1%84%82%E1%85%A7%E1%86%AB%207%E1%84%8B%E1%85%AF%E1%86%AF%2016%E1%84%8B%E1%85%B5%E1%86%AF%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%2006_56_28.webp","is_representative":true,"generation_method":"upload","mime_type":"image/webp","original_filename":"ChatGPT Image 2026년 7월 16일 오후 06_56_28.png","translations":{"ko":{"alt":"AI 로봇과 코드 화면을 중심으로 반복 화살표, 목표·시간·보안·비용 아이콘이 연결된 자동화 구조","caption":"관찰·실행·검증을 반복하는 AI 에이전트와 목표, 일정, 권한, 강제 종료, 비용 제어 요소를 함께 보여준다.","description":null},"en":{"alt":"AI robot and code dashboard surrounded by loop arrows, goal, schedule, security, and cost control icons","caption":"The illustration shows an AI agent repeating observation, action, and verification within goal, timing, permission, stop, and cost controls.","description":null},"ja":{"alt":"AIロボットとコード画面を中心に、循環矢印、目標、時間、安全、コスト管理のアイコンが連結された構成","caption":"観察・実行・検証を繰り返すAIエージェントを、目標、実行時期、権限、停止、コストの制御要素とともに示している。","description":null},"es":{"alt":"Robot de IA y panel de código rodeados por flechas de ciclo e iconos de objetivo, tiempo, seguridad y coste","caption":"La ilustración muestra un agente de IA que repite observación, acción y verificación bajo controles de objetivo, tiempo, permisos, parada y coste.","description":null},"id":{"alt":"Robot AI dan dasbor kode dikelilingi panah loop serta ikon tujuan, waktu, keamanan, dan biaya","caption":"Ilustrasi menampilkan agen AI yang mengulang observasi, tindakan, dan verifikasi dengan kontrol tujuan, waktu, izin, penghentian, dan biaya.","description":null},"pt":{"alt":"Robô de IA e painel de código cercados por setas de ciclo e ícones de meta, tempo, segurança e custo","caption":"A ilustração mostra um agente de IA repetindo observação, ação e verificação sob controles de objetivo, tempo, permissão, parada e custo.","description":null},"zh-hant":{"alt":"AI 機器人與程式碼面板置於循環箭頭中央，周圍連結目標、時間、安全與成本控制圖示","caption":"圖中呈現 AI 代理在目標、排程、權限、強制停止與成本控制下反覆觀察、執行與驗證。","description":null}}},{"id":196,"url":"https://injoys.com/rails/active_storage/blobs/redirect/eyJfcmFpbHMiOnsiZGF0YSI6MTg4NiwicHVyIjoiYmxvYl9pZCJ9fQ==--e5ead4b7a604375b9c6a192eb3a981cf4c93b3c9/ChatGPT%20Image%202026%E1%84%82%E1%85%A7%E1%86%AB%207%E1%84%8B%E1%85%AF%E1%86%AF%2016%E1%84%8B%E1%85%B5%E1%86%AF%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%2007_02_56.webp","is_representative":false,"generation_method":"upload","mime_type":"image/webp","original_filename":"ChatGPT Image 2026년 7월 16일 오후 07_02_56.png","translations":{"ko":{"alt":"보호 울타리 안의 AI 에이전트가 검증, 중단 장치, 권한 게이트와 비용 계측을 거쳐 작업하는 자동화 구조","caption":"트리거부터 검증과 강제 중단, 자원 관리, 승인된 결과 출력까지 안전하게 통제되는 에이전트 워크플로를 보여준다.","description":null},"en":{"alt":"AI agent inside a guarded workspace with verification, stop controls, permission gates, and resource monitoring","caption":"The illustration shows an agent workflow controlled from triggers through validation, hard stops, resource checks, and approved output.","description":null},"ja":{"alt":"検証、強制停止、権限ゲート、資源監視に囲まれた保護領域内のAIエージェント","caption":"トリガーから検証、停止制御、コスト管理、承認済み出力まで安全に統制されたエージェント処理を表している。","description":null},"es":{"alt":"Agente de IA en un entorno protegido con verificación, parada forzada, permisos y control de recursos","caption":"La ilustración muestra un flujo de agente controlado desde los disparadores hasta la validación, los límites y la salida aprobada.","description":null},"id":{"alt":"Agen AI dalam area terlindungi dengan verifikasi, penghentian paksa, gerbang izin, dan pemantauan sumber daya","caption":"Ilustrasi ini menunjukkan alur agen yang dikendalikan dari pemicu hingga validasi, batas aman, pemantauan biaya, dan keluaran yang disetujui.","description":null},"pt":{"alt":"Agente de IA em área protegida com verificação, parada forçada, controle de permissões e monitoramento de recursos","caption":"A ilustração mostra um fluxo de agente controlado desde os gatilhos até a validação, os limites de segurança e a saída aprovada.","description":null},"zh-hant":{"alt":"受保護工作區中的AI代理，周圍設有驗證、強制停止、權限閘門與資源監控","caption":"圖中呈現從觸發、驗證、停止控制與成本監測，到核准輸出的安全代理工作流程。","description":null}}}],"published_at":"2026-07-17T09:40:17+09:00","updated_at":"2026-07-17T09:40:17+09:00","license":"cc_by","translation_status":"machine","available_locales":["ko","en","ja","es"],"data_locales":["ko","en","ja","es","id","pt","zh-hant"],"url":"https://injoys.com/en/articles/claude-code-loop-engineering-guide"}