kkestell/xauto

Orquestre o fluxo de trabalho x completo

A sessão atual é o coordenador pai. Leia references/workflow.md antes de despachar. Leia as outras três habilidades conforme necessário; suas semânticas de estágio e o contrato compartilhado se aplicam a todos os trabalhadores. Não execute um fluxo de trabalho kauto não relacionado devido a um erro de digitação em uma solicitação.

Prepare e aloque

1. Estabeleça o resultado solicitado, restrições e escopo. Encontre a raiz do Git, branch/HEAD atual, instruções aplicáveis e estado sujo/index. Git é obrigatório; pare ao invés de inicializá-lo silenciosamente. Escolha um checkout de tarefa limpo e exclusivo. Preserve o trabalho não relacionado; isole quando possível, caso contrário, pergunte sobre a disposição necessária. Não prometa um commit no branch original do usuário ao trabalhar em um branch separado.
2. Aloque o ID da tarefa e os caminhos canônicos dos artefatos. Um planejador pode propor múltiplas unidades limitadas mais design compartilhado; o pai atribui IDs adicionais centralmente e preserva a cobertura da solicitação completa.
3. Descubra as ferramentas de delegação disponíveis. Use sessões filhas primeiro; apenas quando indisponíveis use subagentes. Siga as regras de delegação/ciclo de vida do host. Não presuma um nome de ferramenta nem finja contexto novo com outra mensagem no pai. Se nenhum mecanismo existir, pare e explique que o fluxo de trabalho orquestrado independente está indisponível; não execute silenciosamente todas as funções inline.
4. Herde modelo/harness/esforço a menos que o usuário ou instruções aplicáveis os selecionem. Use contexto de revisor novo, não uma bifurcação contendo o raciocínio privado do autor. O revisor pode ver a solicitação, código, artefatos e descobertas públicas anteriores, mas não é o trabalhador que escreveu o plano/implementação revisado.
5. Capture a proveniência da sessão do pai usando o contrato compartilhado. Solicite o ID do coordenador de cada trabalhador e o ID nativo da conversa em sua entrega; preserve-os no registro de trabalho antes da limpeza, não apenas nomes de trabalhadores transitórios.

Despache briefs de estágio explícitos

Cada trabalhador recebe o objetivo, restrições relevantes do usuário, habilidade e invocação, ID da tarefa, checkout exato e HEAD inicial, caminhos de entrada/saída, edições permitidas, autoridade de commit, requisitos de verificação e evidências de verificação existentes, entrega esperada (incluindo proveniência da sessão) e condição de parada. Inclua onde o resultado será usado. Forneça um plano ou solicitação, não suposições que o trabalhador deve verificar independentemente.

Os estágios são sequenciais em um checkout compartilhado. Padrão é um escritor por vez; execute unidades separadas concorrentemente apenas quando seus arquivos e dependências forem verdadeiramente independentes e a propriedade de integração/revisão for explícita. Confirme o diretório/HEAD real de cada filho; integre commits de entrega de trabalhadores isolados antes do próximo estágio, conforme descrito no contrato compartilhado. Nunca exclua um resultado não transferido.

Plano → revise o plano

• Inicie um planejador com xplan <solicitação> e nenhuma autoridade de edição de código de produção. O planejador pesquisa questões complicadas, resolve decisões de engenharia e retorna planos prontos, um brief de micro-tarefa ou bloqueadores concretos.
• Inspecione os artefatos retornados e a cobertura. Faça commit dos registros do plano/design compartilhado como plan, então envie cada plano de execução para um trabalhador independente usando xreview plan .agents/plans/ID.md. Faça commit de sua rodada de revisão como plan-review.
• Para descobertas, retorne uma atribuição de correção concreta ao planejador. Faça commit do plano revisado. O pai verifica as correções em relação às descobertas e evidências relevantes, registra sua disposição e os blobs finais do plano/orientação, e prossegue quando nenhum defeito consequente permanecer. Esta é a decisão de execução do pai, não uma afirmação de que o revisor aprovou revisões não vistas. Não envie cada revisão por outra revisão completa do plano. Avaliação independente adicional precisa de uma questão consequente específica que a revisão anterior e a verificação de correção não podem resolver; nomeie essa questão e solicite apenas a avaliação necessária. Redação, metadados e correções de rotina não justificam reiniciar a revisão. Edições de design compartilhado exigem verificar unidades afetadas, não comissionar automaticamente outra revisão de cada uma.
• Para trabalho verdadeiramente pequeno, mantenha o brief limitado do planejador para xwork e pule os artefatos separados de plano/revisão; o registro de trabalho posterior registra o motivo. Não ignore a normalização chamando uma grande atribuição não resolvida de brief.
• Uma solicitação dividida não é concluída após sua primeira unidade. Rastreie dependências de unidades no design compartilhado, execute cada unidade solicitada em ordem e verifique novamente interfaces/estados intermediários compartilhados quando uma dependência mudar.

Trabalho → revise a implementação

• Despache um implementador com xwork .agents/plans/ID.md, ou o brief de micro-tarefa explícito. Forneça a revisão/plano aceitos e os blobs de orientação vinculados. Autorize apenas código de propriedade da tarefa e commits de registro. xwork registra uma base de Código fixa, faz commit do código verificado, então faz commit separadamente de seu registro com um head de Código conhecido.
• Verifique a entrega em relação ao Git e à saída de teste registrada; a mensagem "concluído" de um filho não é evidência da árvore correta, verificações concluídas ou arquivos commitados. Resolva mapeamentos de integração e use hashes de checkout de tarefa no registro final.
• Inicie um revisor independente com xreview work .agents/work/ID.md. Forneça a solicitação, plano/brief, intervalo completo de base de Código..head de Código, registro de trabalho e instruções relevantes do repositório. O revisor lê código e testes, não apenas o registro, e escreve uma revisão sem corrigir a implementação. Faça commit de sua revisão como work-review.
• Passe por resultados de verificação inspecionáveis para o head de Código registrado. Peça ao revisor para inspecionar/reutilizar essa evidência primeiro e identificar qualquer incerteza restante antes de selecionar verificações novas. Não solicite rotineiramente repetições focadas, uma execução completa do pacote e a suíte do repositório novamente para o mesmo código inalterado. Requisitos explícitos de execução nova ainda se aplicam.
• Envie descobertas acionáveis ao implementador. Ele faz commit de correções e uma entrada de registro anexada, retendo a base original. Retorne a alteração completa atualizada ao revisor independente; descobertas anteriores precisam de evidência de resolução, não de uma lista de verificação vazia e nova. Preserve todas as rodadas de revisão. O revisor pode ser reutilizado enquanto independente do autor; nenhuma função pode aprovar código que acabou de escrever.
• Se a implementação expor um design inválido, encaminhe a decisão de volta através do planejador e pai antes de continuar. Aplique a mesma verificação de correção a unidades dependentes afetadas; avaliação independente adicional precisa de uma incerteza consequente específica, não meramente um blob de plano alterado. Não deixe xwork expandir silenciosamente o escopo ou deixar a escolha difícil até a codificação.

Resolva descobertas e termine honestamente

Prosiga sem confirmação de rotina, mas pergunte quando a intenção, escopo, permissões ou uma compensação material realmente exigirem o usuário. Pare com ferramentas/verificações necessárias indisponíveis ou decisões contestadas. Continue reparos comuns enquanto eles fizerem progresso; se uma rodada repetir a mesma abordagem fracassada, precisar de uma decisão do usuário ou exceder um orçamento explícito, pare e relate a evidência não resolvida em vez de gerar um loop de revisão infinito. Nunca aceite um defeito para concluir o ciclo.

Antes do sucesso, o pai verifica:

1. Cada unidade de execução solicitada está implementada, as verificações necessárias realmente passaram, e seu código final tem uma revisão de trabalho independente aceita.
2. Toda alteração de código/teste/configuração após o head de Código revisado de uma unidade é coberta por um intervalo de revisão aceito de uma unidade posterior no checkout de tarefa integrado, ou passa novamente por verificação e revisão de trabalho. Alterações conhecidas apenas de registro de workflow não precisam de re-revisão de código. Considere todos os commits/diffs, não apenas nomes de caminhos correspondentes. Correções de conflitos de integração e contratos anteriores quebrados exigem verificações/revisão renovadas; uma unidade posterior aceita não os desculpa automaticamente.
3. Os registros de trabalho contêm o plano/brief aceito, base fixa, head revisado final, commits reais, IDs de conversa nativos do pai/trabalhador (ou razões explícitas de indisponibilidade), evidências de verificação executadas/reutilizadas e caminhos de revisão. Defina-os como complete e faça commit dos registros restantes de propriedade da tarefa como complete.
4. Todas as alterações de propriedade da tarefa e novos registros são commitados no branch relatado. Verifique com Git, preserve trabalho não relacionado e não faça push ou mescle automaticamente em um branch diferente. Heads de código originais não precisam ser iguais ao HEAD final porque commits posteriores contêm registros ou outras unidades aceitas independentemente.
5. Salve a proveniência da sessão de cada filho e integre/salve cada resultado antes de encerrar sessões que removam seus branches/worktrees. Deixe um resultado commitado acessível e siga as regras de limpeza do host. Ciclos fracassados relatam commits parciais e bloqueadores, não sucesso.

Retorne um resultado conciso, IDs de tarefa, caminhos de artefatos, branch e IDs de commit final, verificações, vereditos de revisão e quaisquer limitações restantes. O pai possui esta verificação e relatório final; não apenas concatene resumos de trabalhadores.