Pular para o conteúdo

Agentes

Os dois agentes do Archgate — developer e planner — que orquestram o desenvolvimento por IA em conformidade com os ADRs, lendo decisões antes de codificar e validando depois.

Onde as skills são capacidades focadas, os agentes são os orquestradores. Um agente do Archgate governa uma interação inteira com sua ferramenta de codificação por IA: ele conhece o loop de governança, invoca a skill certa no momento certo e trata seus ADRs como restrições absolutas. Os plugins de editor instalam dois agentes — um que escreve código e um que apenas planeja.

O agente developer é o agente padrão que o plugin instala. Ele é um agente de desenvolvimento de propósito geral que impõe a conformidade com os ADRs em cada alteração de código, seguindo um fluxo de trabalho fixo:

  1. UNDERSTAND — ler primeiro os ADRs aplicáveis. O agente roda archgate review-context para obter briefings condensados de Decisão e Faça e Não Faça para os arquivos em escopo, de modo que conheça as restrições antes de escrever qualquer coisa.
  2. PLAN — projetar uma abordagem que esteja em conformidade com cada ADR aplicável. Se uma restrição entrar em conflito com a tarefa, o agente a sinaliza em vez de violá-la silenciosamente.
  3. WRITE — implementar o código respeitando as restrições que acabou de ler.
  4. VALIDATE — rodar archgate check para uma validação determinística rápida e, em seguida, invocar a skill reviewer para revisão estrutural e baseada em julgamento. As violações são corrigidas antes de prosseguir; os avisos são apresentados ao usuário.
  5. CAPTURE — invocar a skill lessons-learned para codificar quaisquer novos padrões da sessão.

O agente developer é criterioso quanto ao custo: ele roda o ciclo completo de validar e capturar para a conclusão inicial da tarefa, mas pula as etapas mais pesadas de reviewer e lessons-learned para pequenos ajustes de acompanhamento (uma renomeação, uma mudança de valor) onde apenas o archgate check basta.

O comportamento mais importante do agente developer é que os ADRs são bloqueadores rígidos. Se uma tarefa exigir código que viole um ADR, o agente recusa, nomeia o ADR que seria violado e sugere uma alternativa em conformidade que atinge o mesmo objetivo. Se o usuário insistir em contorná-lo, o agente recusa novamente — a conformidade com os ADRs é obrigatória, não consultiva. É isso que torna a prevenção real, em vez de aspiracional: o agente não escreverá código não conforme em primeiro lugar.

O agente planner é uma contraparte somente leitura. Ele lê ADRs e explora a base de código, mas nunca escreve, edita ou cria arquivos. Seu trabalho é produzir um plano de implementação detalhado e em conformidade com os ADRs que você — ou o agente developer — pode então executar.

A saída de um planner inclui um resumo de conformidade com ADRs (quais ADRs se aplicam e como a abordagem satisfaz cada um), uma estratégia de implementação em nível de arquivo, dependências e sequenciamento, áreas de risco de ADR, lacunas de governança onde ainda não há ADR aplicável e uma estratégia de verificação. Como o agente developer, o planner se recusa a propor qualquer abordagem que viole um ADR.

A restrição de somente leitura é o ponto central: você pode explorar opções e compromissos com o planner com risco zero de alterações não intencionais e, em seguida, entregar o plano aprovado ao agente developer para implementação.

Os agentes não duplicam a lógica das skills — eles invocam as skills. O agente developer chama reviewer e lessons-learned como as etapas VALIDATE e CAPTURE; ambos os agentes se apoiam em cli-reference para carregar a sintaxe exata dos comandos em vez de adivinhar, e em adr-author sempre que um ADR precisa ser escrito. Essa separação mantém cada peça focada: os agentes são donos do fluxo de trabalho, as skills são donas das capacidades.