Onda de Agentes
Execute um lote declarado de itens da fila aceitos usando as capacidades que este host realmente expõe. Orçamentos contam itens ou ondas. Um limite opcional de horas interrompe novas ondas, nunca um item em execução. Automação de longa duração usa a facilidade de agendamento do host (veja LEIAME); esta sessão não promete sobreviver a si mesma.
Pré-condições e capacidade do host
Antes de perguntar parâmetros, leia o ponto de entrada do repositório, convenções,
prompt autônomo da fila. Resolva todos os caminhos de artefato, incluindo _agent/,
em relação à raiz gravada. Exija um portão real e a fila que ele percorre.
| Modo gravado | Execução |
|---|---|
| Escritor único | Pare e direcione o operador para o prompt autônomo sequencial, a cada largura solicitada. |
| Checkout compartilhado, integração direta | Um executor por vez naquele checkout, usando status do item e linhas de bloqueio. Sem branch de reivindicação ou árvore de trabalho de integração. |
| Checkout compartilhado, integração PR | Pare antes de reivindicar; exija árvores de trabalho separadas para ondas de PR. |
| Árvores de trabalho separadas | Cada executor usa sua própria árvore de trabalho; a integração segue o modelo gravado. |
Busque/pode o remoto gravado e exija sua branch de integração. Imprima o SHA base buscado. Compare a ref de integração local: relate commits não enviados ou divergência antes de prosseguir, nunca descarte silenciosamente. Um checkout limpo e atrasado pode ser avançado rapidamente quando for seguro; caso contrário, deixe-o como está. O estado e a sonda da onda vêm da base buscada, não de arquivos não consolidados no checkout do operador. Se a fila remota estiver vazia, mas a fila local diferir, explique essa diferença.
Derive se o host pode delegar, isolar checkouts, executar concorrentemente, usar uma facilidade de orquestração já habilitada pelo operador e exigir resultados moldados. Escolha o nível mais alto disponível:
- Facilidade de orquestração habilitada: uma distribuição para esta onda apenas. Mantenha loops de onda, verificações de relógio e perguntas no orquestrador.
- Subagentes comuns: paralelo se disponível, sequencial caso contrário. Use isolamento de árvore de trabalho do host apenas se seu HEAD inicial for igual à base declarada; caso contrário, crie explicitamente cada árvore de trabalho naquela base.
- O orquestrador executa um item por vez, em sua própria árvore de trabalho ou no checkout compartilhado, conforme o modo gravado permitir.
Relate Execução: nível N — motivo. O operador pode abaixar esta escolha;
nunca a eleve além da capacidade observada ou solicite habilitação. Uma
habilidade mencionando uma facilidade não é aceitação do operador. O mesmo
briefing canônico abaixo é usado em todos os níveis. Sem um teto de concorrência comprovado, use um.
Avaliação e declaração
Reutilize respostas aplicáveis já dadas, incluindo profundidade; padrões nunca substituem escolhas explícitas. Uma especificação totalmente fornecida não precisa de seletor ou confirmação repetidos. Pergunte apenas por uma escolha materialmente ausente ou conflitante; uma preferência gravada sozinha não é autoridade de execução atual. Caso contrário, faça uma pergunta de cada vez com uma resposta recomendada e motivo, usando um seletor estruturado se disponível. Quando a profundidade não estiver resolvida, ofereça expressa (padrões), guiada (orçamento/supervisão) ou profundidade total, com a profundidade gravada pré-selecionada. Respeite padrões-daqui ou vá-mais-fundo.
- Largura solicitada: recomende min(profundidade da fila elegível, 3, teto do host).
- Orçamento: itens ou ondas; recomende uma onda. Opcionalmente, um limite de horas flexível.
- Supervisão: checkpoint após cada onda (recomendado), ou contínua.
- Integração: use o perfil do repositório a menos que explicitamente substituído. Integração direta é legítima com barreiras de concorrência gravadas; sua integração é serial. Uma substituição não pode tornar um modo não suportado válido.
Declare e confirme a especificação resultante antes da execução (parâmetros de invocação explícitos já constituem confirmação). Inclua:
- Nome da onda, data, remoto, branch de integração e SHA base buscado.
- Largura solicitada/efetiva, nível/motivo, teto do host e qualquer limite de token.
- Orçamento, supervisão e limite flexível; nunca converta limites de token em contagens de itens.
- Chave de cada item, decisões proprietárias, dependências, variante de reivindicação, artefatos exatos proprietários, identificadores reservados com suas sequências e sinalizador Continuar.
- Perfil de isolamento e integração; ações de integração/merge realmente concedidas.
- Concessão: "Onda atendida: o operador confirmou estes parâmetros e este item em ; implemente apenas o item nomeado, nunca escolha outro."
Reserve apenas identificadores que um item criará, em blocos finitos disjuntos. Inclua reservas vivas existentes; itens continuados mantêm suas originais. Nunca atribua a dois escritores a mesma decisão ou corpo de plano. ÍNDICE é derivado: um executor altera apenas suas próprias linhas, e a integração regenera toda a tabela. Reservas esgotadas param o item; sem roubo de slots.
Após a confirmação, crie uma árvore de trabalho de integração/sonda destacada na base para modo de árvore separada, fora da árvore do operador. Reutilize um resíduo apenas após prová-lo limpo e próprio. Sonda o portão exato lá com arquivos rastreados e ambiente existente apenas. Em falha ambiental, pare antes do despacho e relate o comando, saída e exit; não instale dependências ausentes ou insinue que selecionar o nível três repara o portão. Relate o caminho efetivo dos hooks e a origem da configuração de assinatura.
Coletar antes de cada onda
Busque/pode novamente; leia status do item, dicas de reivindicação, árvores de trabalho e estado PR. Use esta precedência, resolvendo cada item na base e na dica de reivindicação:
| Classe | Evidência e ação |
|---|---|
| Inverificável | Evidência remota/PR necessária indisponível ou contraditória: pare a execução. |
| Enviado | Entrada concluída na branch de integração com commit de rodapé alcançável ou PR mesclado confirmado. Exclua. |
| Mesclado mas não enviado | Trabalho/PR mesclado mas item ainda na fila da base. Exclua e solicite reconciliação. |
| Parado | Campo Parado na base ou dica de reivindicação. Exclua a menos que explicitamente continuado. |
| Vivo | Reivindicação remota não mesclada ou PR em rascunho/pronto, ou proprietário/bloqueios atuais do checkout compartilhado. Exclua a menos que explicitamente continuado. |
| Obsoleto | Propriedade local com suporte de branch após desaparecimento confirmado de ref remota. Relate limpeza; não reassine resíduos incertos. |
| Elegível | Propriedade aceita, dependências satisfeitas, sem conflito de reivindicação/parado/obsoleto. Selecione na ordem da fila. |
Um PR pronto pode ter movido o item para concluído em sua própria branch. Resolva esse movimento através do PR/histórico vinculado; ainda está vivo, não é órfão. Verifique merges de PR confirmados quando squash/rebase torna a ancestralidade da fonte inconclusiva. Reivindicações compartilhadas são avaliadas a partir de item/bloqueios, nunca ausência de reivindicação remota. Árvores de trabalho destacadas não são reivindicações nem obsoletas. Uma ref de reivindicação local adiantada significa trabalho não enviado: retorne desconhecido e preserve-a.
Na profundidade guiada/total, ofereça Continuar apenas para uma reivindicação viva/parada existente; padrão para excluí-la. Expresso exclui e lista como continuar. Uma invocação nomeando a reivindicação ou item é a resposta explícita. Continuar não cria uma nova reivindicação ou reserva; relate qualquer árvore de trabalho residual. Após a seleção, verifique novamente a sobreposição de caminhos próprios e dependências.
Briefing canônico do executor
Passe este briefing completo com a especificação do item, inalterado em todos os níveis:
- Abra e oriente. Verifique ancestralidade da base e o item nomeado. Um checkout continuado deve igualar a dica de reivindicação buscada; o movimento de conclusão de um PR pronto vinculado é contexto válido. Leia o ponto de entrada e o prompt autônomo. Uma incompatibilidade é bloqueada, nunca permissão para trabalhar outro item.
- Reivindique. Busque novamente. Para um item novo de árvore separada, crie
claim/<chave-item>a partir da base; commite Reivindicado por com ator/data/branch e coloque a branch de reivindicação real, onda, reservas e artefatos próprios na sua primeira mensagem de commit. Antes de publicar, leia de voltagit show -s --format=%B HEADegit show HEAD:<caminho-plano-próprio>. Verifique a branch literal real em ambas a mensagem e Reivindicado por, o nome da onda, reservas (incluindo nenhuma) e caminhos próprios exatos. Verifiquegit diff-tree --no-commit-id --name-only -r HEAD: este commit inicial altera apenas o Status do item próprio, sem saída de implementação. Repare metadados ausentes localmente antes da aquisição. Um commit posterior não pode reparar uma reivindicação inicial deficiente. Valide a chave comgit check-ref-format --branch; nunca use um espaço reservado literal. Adquira comgit push --porcelain --force-with-lease=refs/heads/claim/<chave-item>: origin HEAD:refs/heads/claim/<chave-item>. Exija exit zero e o resultado de nova-ref*para aquele destino. Refs existentes, incluindo resultados mesmo-tip/atualizados, não concedem propriedade. Aguarde o término desse push e inspecione seu recebimento bem-sucedido de nova-ref antes de emitir qualquer gravação de implementação. Não agrupe aquisição e implementação na mesma chamada de ferramenta. Uma falha de assinatura/push para antes da implementação; preserve resultados desconhecidos. Nunca sobrescreva outra reivindicação. Configure upstream após aquisição. Para modo PR, abra/reutilize imediatamente o PR rascunho com item, ator, branch, reservas, caminhos próprios e bloco de fechamento; falha bloqueia implementação. Continue destacando na dica remota existente, retendo reservas e atualizando Reivindicado por no primeiro commit, depois envie de volta para aquela ref. Checkout compartilhado: reivindique através do status do item e linhas de bloqueio antes de cada edição, incluindo novos registros; nunca crie ou mude de branch de reivindicação. - Implemente. Siga o prompt autônomo para este um item. Não aceite/substitua decisões, insira ou renumerie itens existentes da fila, exceda reservas, faça bump de versão, marque tag, publique ou pergunte ao operador. Retorne um bloqueador quando o briefing não puder ser honrado.
- Verifique e commite. Execute o portão gravado exatamente. Repare falhas de implementação entendidas e execute novamente. Se o portão não puder ser executado, instale nada que ele mesmo não instale: registre o erro exato em Bloqueadores, commite/pushe trabalho recuperável dentro da concessão e retorne bloqueado, nunca verificado ou enviado. Siga regras de assinatura, Racional e integridade do portão.
- Integre por perfil. Integração direta de árvore separada: pushe a reivindicação verificada e retorne pronto; o orquestrador invoca o modo de integração do enviar-item. Checkout compartilhado: invoque enviar-item na árvore ativa. Modo PR: invoque enviar-item no PR real, incluindo rebase, verificações de colisão, reparo de número próprio, ambos os portões e commit de conclusão. Mantenha seu corpo/relatório atual; pronto requer verificações no HEAD atual. Mescle apenas dentro da concessão e relate enviado apenas após confirmação de aterrissagem. Tente uma base movida no máximo duas vezes; preserve reivindicações não resolvidas em falha.
- Pare e relate. Coloque data/motivo e os três rótulos de relatório no campo Parado do item na fila, ou no corpo do PR se já movido para lá. Commite/pushe apenas dentro da concessão. Retorne os campos abaixo e o bloco final. Nunca crie uma snapshot de coordenação ou delete silenciosamente trabalho sujo.
Execute, integre e colete resultados
Despache a onda declarada com o mecanismo derivado. Largura efetiva é um no nível três e para checkouts compartilhados. No nível três, reivindicar inicia um item: crie branches de reivindicação locais ou remotas e preencha Reivindicado por apenas para o item atual, nunca pré-reivindique o lote restante. Inspecione seu resultado do portão antes de emitir os comandos do próximo item. Uma pré-reivindicação posterior não é um executor já em execução. No nível três, termine e integre cada item antes de iniciar o próximo. Antes de avançar o loop, verifique o resultado do portão do último executor. Um bloqueador ambiental termina toda a onda imediatamente, mesmo que o próximo item seja independente e o orçamento tenha espaço. Não inicie o próximo item ou outra integração. Esta regra tem precedência sobre supervisão contínua e o limite numérico de falhas. Colete executores já em execução sem iniciar novo trabalho, então relate o bloqueador sistêmico. Preserve suas reivindicações recuperáveis. Uma sonda de base bem-sucedida não substitui uma falha de ambiente após a implementação.
Para trabalho direto paralelo, invoque o modo de integração do enviar-item para reivindicações prontas na ordem da fila, usando a árvore de trabalho de integração destacada. A mecânica de integração reside em enviar-item, não em um segundo procedimento aqui. Hosts PR serializam merges de PR autorizados.
Normalize cada retorno para: chave do item; resultado (enviado, pronto, falhou,
bloqueado, parado, desconhecido); branch de reivindicação/real; SHA de integração ou PR;
identificadores usados/renumerados; bloqueador; arquivos de conflito; bloco final literal.
Nenhum retorno significa desconhecido. Resultado é separado do vocabulário de Geral.
Para uma reivindicação pronta aguardando integração, escreva Resultado: pronto e
Geral: parcialmente verificado; pronto e enviado nunca são valores de Geral.
Relate cada item e um resumo da onda com Status de relance; qualquer desconhecido
limita a onda a parcialmente verificado. Inclua reivindicações excluídas/retiradas,
largura efetiva, nível, resultados do portão, origens de hooks/assinatura e trabalho restante.
Na resposta final, mantenha um bloco Status de relance para cada item,
em seguida um bloco separado para a onda. Cada um tem Esta execução, Geral e A fazer.
Uma tabela de resultados por item pode acompanhar estes blocos, mas nunca os substitui,
incluindo no nível sequencial. Verifique sua contagem antes de retornar.
Coloque a chave do item ou "Onda" em um cabeçalho separado acima de seu bloco. Mantenha o
cabeçalho do bloco exatamente Status de relance, sem sufixo de item ou prefixo
de onda. Coloque Onda em seu próprio cabeçalho de escopo, assim como com um item. Por exemplo:
## Item <chave>
### Status de relance
- **Esta execução:** <ações observadas e saída/exit do portão>
- **Geral:** <vocabulário permitido>
- **A fazer:** <trabalho restante ou Nenhum>
Checkpoint pergunta antes de outra onda. Modo contínuo recoleta do git e prossegue dentro do orçamento confirmado. Leia o relógio do shell no primeiro despacho e após cada onda; se indisponível, relate o limite flexível como não imposto. Pare de iniciar ondas além do limite; nunca interrompa um item em andamento.
Pare e limpe
Uma negação explícita de permissão de host/ferramenta para para