Como uma execução funciona

Dentro de um único turno de um loop: um sandbox isolado, um agente de código de verdade numa branch dedicada, e uma nota de passagem que torna o próximo turno mais barato que o anterior.

Todo turno de um loop funciona igual, seja disparado por webhook, por relógio, ou por alguém mencionando o goblin diretamente. Esta página é o que acontece entre esse gatilho e o merge request.

1. O gatilho chega

O TaskGoblin encontra ou cria a thread daquele trabalho — a conversa de uma issue, um merge request, um loop — e registra o turno como uma mensagem nela. Um acompanhamento sobre trabalho já em andamento entra na thread existente em vez de abrir uma nova. É por isso que o goblin nunca pede que você explique tudo de novo.

2. O sandbox sobe

A execução recebe um contêiner isolado na nuvem com uma cópia do seu repositório. Sandboxes são persistentes e reaproveitados entre turnos da mesma thread, então um acompanhamento cai num ambiente que já tem o repositório e o estado do turno anterior — o goblin retoma em vez de começar de uma caixa vazia.

Eles costumam vir pré-aquecidos, e é por isso que uma execução normalmente começa a trabalhar em segundos em vez de esperar um contêiner frio. O sandbox na nuvem cobre isolamento, persistência e self-hosting a fundo.

3. Ele lê antes de escrever

Antes de tocar em código, o goblin reúne contexto: a issue ou o diff que o disparou, o histórico da thread, a nota de passagem deixada pelo goblin anterior, e as convenções da sua organização. Num loop de evento, sua instrução permanente é sobreposta ao contexto do próprio evento.

Esse é o passo que separa uma mudança útil de uma apenas plausível. Um agente que enxerga como a última mudança foi revisada, e por que uma abordagem anterior foi revertida, decide melhor do que um que começa numa sala vazia.

4. Um agente de código de verdade faz o trabalho

Dentro do sandbox roda um agente de código real — Claude Code, Codex ou Gemini, conforme a conta de modelo daquela execução. Ele tem as ferramentas de um desenvolvedor: lê e edita arquivos, roda comandos e roda seus testes. Não está autocompletando um diff, está trabalhando o problema.

5. Branch, commit, push, merge request

O goblin segue o fluxo que seu time já usa:

  1. Trabalha numa branch dedicada — 142-taskgoblin para a issue 142 no GitLab ou GitHub, proj-123-taskgoblin para uma chave do Jira — nunca na sua branch padrão.
  2. Faz commit assinando o trabalho para o rastro ficar legível, e empurra a branch.
  3. Abre um merge request (GitLab) ou pull request (GitHub) e reporta o link de volta onde o trabalho começou.

A exceção é uma execução disparada em cima de um merge request existente: aí ela empurra para a branch daquele MR em vez de abrir uma branch concorrente.

Como a saída é uma branch e um merge request, revisar é exatamente o que já é para contribuições humanas. Nada faz merge sem seu aval.

6. Ele reporta onde você já está olhando

Durante a execução, o goblin responde pela superfície à qual o trabalho pertence: atividade numa issue do Linear, comentários inline num merge request, um card que se atualiza sozinho no Slack ou Teams. Você não fica olhando um terminal, e não há um painel separado que precise lembrar de abrir.

7. Ele anota o que aconteceu

A última coisa que um goblin faz — depois de enviar a resposta, nunca antes — é registrar uma nota de passagem: o que aprendeu, o que decidiu, o que ficou em aberto. O turno seguinte lê isso primeiro.

É por isso que um loop acumula em vez de repetir. Veja O cérebro.

Segredos ficam fora do agente

O goblin nunca vê suas credenciais. O acesso git dentro do sandbox é provisionado por organização em tempo de execução — um token OAuth do GitLab ou um token de instalação do GitHub recém-emitido — e injetado no ambiente em volta do agente em vez de entregue a ele para ler. Ele consegue usar o acesso necessário para clonar e empurrar sem que seus segredos entrem no contexto nem na transcrição dele.

Esse token é só para transporte git. Comentários, reviews e atualizações de issue passam pelas integrações do próprio TaskGoblin, para saírem como o goblin e não como você.

Quando algo dá errado

Uma execução que falha não desaparece. O goblin reporta com clareza na superfície de onde você disparou, a falha fica registrada na execução, e a nota de passagem carrega a parede em que ele bateu, para o turno seguinte não redescobrir. Uma execução que nunca chegou a ter sandbox — bloqueada por saldo zerado, por exemplo — nunca é cobrada.

Para onde ir agora