picoduck/orchestrate-issues

Orquestrar Issues

Execute uma campanha de issues iniciais e seus acompanhamentos justificados. Coordene através de sessões filhas reais do Wollipog, não de subagentes em processo. O Orquestrador investiga, agenda, revisa resultados e mantém o estado; as filhas implementam. Criar ou editar esta skill não inicia uma campanha.

Limite de Ativação

A contagem de issues, dependências, tamanho da tarefa e a disponibilidade de ferramentas de sessão filha não autorizam delegação. Exija uma invocação explícita deste fluxo de trabalho ou uma solicitação para orquestrar, coordenar entre sessões ou delegar implementação para filhas. A autorização relevante já estabelecida para uma campanha ativa permanece válida; não precisa ser repetida em cada turno.

“Pegue e implemente as issues 1089, 1090 e 1091” significa que a sessão atual pega e implementa essas issues seguindo o fluxo de trabalho de issues do repositório (como uma skill issue-workflow instalada), na ordem de dependência e com suas worktrees isoladas e revisão exigidas. Não inicie sessões filhas de implementação nem pergunte se deve orquestrar apenas porque a solicitação lista várias issues. Títulos ou corpos de issues sobre configurações do Orquestrador são assunto da tarefa, não instruções para se tornar um Orquestrador.

“Orquestre sessões filhas para implementar as issues 1089, 1090 e 1091” ou “Use orchestrate-issues para essas issues” ativa este fluxo de trabalho. Uma filha que recebe várias issues atribuídas continua sendo uma sessão de implementação; a autorização de orquestração do pai não autoriza automaticamente essa filha a delegar novamente. Uma revisão que o repositório exige, incluindo uma revisão entre modelos, permanece regida por suas próprias regras e não é uma delegação de implementação de issues.

Se a sessão atual for restrita pela predefinição de permissão do Orquestrador e não puder implementar diretamente, explique essa limitação concreta e solicite orientação em vez de gerar filhas silenciosamente ou tentar implementação proibida. Apenas ter a predefinição disponível não é autorização para usá-la.

Entradas e Configuração

• count: qualquer inteiro positivo, o número de issues iniciais a selecionar. Infira a partir da solicitação; se omitido, use 5 e declare essa suposição. Uma lista explícita de issues substitui a seleção por prioridade e determina a contagem.
• concurrency: teto opcional, independente da contagem. Padrão: o menor valor entre a contagem, o maximumConcurrentChildren da política e a capacidade de filhas vivas disponível. Enfileire issues excedentes; nunca aumente limites da plataforma para caber na contagem.
• O harness filho, modelo e esforço vêm da política do Orquestrador Wollipog da campanha (childHarness, childModel, childEffort em get_campaign.behavior); esta skill não tem padrões próprios. Cada valor é fixo ou Automático (null). Consulte Resolver Modelo e Esforço da Filha.
• Os revisores mantêm o modelo especificado pelo fluxo de trabalho de revisão do repositório.
• Limites opcionais especificados pelo usuário para custo, tempo, total de issues ou profundidade de acompanhamento. Preserve as proteções herdadas. Não invente valores de orçamento ou uma rodada de parada bem-sucedida arbitrária.

Leia using-wollipog, as instruções do repositório e quaisquer skills ou políticas de fluxo de trabalho de issues, revisão e relatório de issues que o repositório ou usuário fornecer. Apenas using-wollipog é obrigatório; quando o repositório não define um fluxo de trabalho de issues, as filhas seguem suas diretrizes de contribuição e os portões desta skill. As filhas devem ter as mesmas skills disponíveis em seu ambiente de execução. Resolva caminhos de skills a partir do catálogo desse ambiente; não presuma que os caminhos home desta máquina existam em outro lugar. Leia a política de relatório de issues do repositório antes de preparar cargas de publicação.

Descubra o runner atual, repositório/workspace, harnesses de trabalhador disponíveis e capacidades de modelo/esforço, capacidade de filhas e ferramentas de sessão suportadas. Selecione um harness que anuncie o modelo escolhido; não presuma que todo modelo pertence ao Codex. Inspecione a sessão atual e a lista de filhas vivas antes de criar qualquer coisa. Use apenas operações de Orquestrador permitidas; gravações no projeto e implementação pertencem às filhas. Mantenha o livro-razão da campanha em artefatos de sessão persistentes ou scratch permitido, nunca no checkout principal. Resuma seu estado mais recente na conversa antes de ceder ou compactar.

Resolver Modelo e Esforço da Filha

Leia childHarness, childModel e childEffort de get_campaign.behavior antes de selecionar qualquer coisa, e leia-os novamente antes de cada despacho: uma pessoa pode alterá-los enquanto a campanha está em execução, e apenas as filhas criadas depois usam os novos valores. As configurações do Orquestrador Wollipog são a única fonte desses valores. Nunca recorra a um modelo ou esforço escrito nesta skill, lembrado de uma campanha anterior ou herdado da sessão pai.

• Valor fixo: use exatamente. O servidor preenche um valor fixo quando create_session o omite e rejeita qualquer valor diferente, portanto, não o substitua. Se o prompt do usuário solicitar um modelo ou esforço diferente de uma configuração fixa, relate o conflito e peça ao usuário para alterar a configuração do Wollipog; não despache a issue afetada até que seja resolvido.
• Harness fixo: um childHarness fixo nomeia um harness, e cada máquina tem seu próprio agente para ele. Quando get_campaign retorna childHarnessAgents, passe o agentId listado para a máquina em que você cria a filha; uma máquina listada com null não pode executá-lo. Não derive o agente de childHarness.agentId; ele não precisa ser um agente em nenhuma máquina.
• Modelo ou esforço fixo: quando get_campaign retorna childModelMachines, crie filhas apenas em máquinas marcadas como supported; as outras não podem executar esse modelo e esforço, e a criação lá é recusada.
• Automático (null): escolha para cada atribuição a partir de get_agent_capabilities (MCP) ou wollipog session capabilities (CLI). Siga page.nextOffset até que truncated seja falso. Escolha um harness que anuncie o modelo escolhido; não presuma que todo modelo pertence a um harness. Baseie a escolha na complexidade da issue, incerteza, consequência de erros, necessidades de contexto e qualquer restrição de custo ou latência que o usuário declarou. As preferências de modelo ou esforço no prompt do usuário orientam uma escolha Automática, mas não alteram a configuração do Wollipog. Prefira uma opção econômica e capaz para trabalho direto e raciocínio mais forte para depuração complexa, arquitetura ou alterações amplas. Não invente classificações de modelo, preços ou níveis de esforço; use capacidades anunciadas e explique incerteza material. Se um modelo não anuncia esforço configurável, registre o esforço como não aplicável.

Se um valor fixo estiver ausente da descoberta de capacidade atual, relate a incompatibilidade e solicite uma configuração corrigida enquanto continua a triagem independente. Nunca substitua silenciosamente.

Registre o harness de cada issue, modelo e esforço exatos, se cada um era fixo ou Automático e uma breve justificativa para escolhas Automáticas na tabela de seleção e no livro-razão antes do despacho. O modo Automático autoriza essas escolhas de rotina sem perguntar por filha; não autoriza alterar contas, acordos de cobrança, permissões, orçamentos ou as próprias configurações do Wollipog.

Verificar Modelo e Esforço Antes da Implementação

Use create_session com useWorktree: true, o harness resolvido, um modo de permissão de trabalhador anunciado (não modo Orquestrador) e o model e effort resolvidos na mesma chamada, além de campaignWorkItemId nomeando o item de trabalho registrado da filha. O equivalente em CLI é wollipog session create ... --model <model> --effort <effort> --work-item <id> --worktree. Omita uma dimensão apenas quando for fixa por política (o servidor a fornece) ou não aplicável. Valores explícitos se aplicam antes do prompt inicial. Prefira entradas de ferramentas estruturadas para o texto da tarefa.

Leia o par efetivo de volta do resultado da criação ou get_session e confirme que corresponde à combinação resolvida. Se não corresponder, pare essa filha antes que ela faça trabalho, registre a incompatibilidade e relate; não aceite um padrão não verificado. Um cliente e servidor que não suportam esforço explícito falham fechados; relate esse bloqueador em vez de tentar novamente sem esforço.

Inspecione o esquema de criação real: um número de protocolo do runner sozinho não expõe uma entrada. Se um host Custom não tiver campaignWorkItemId, use apenas uma atribuição de bootstrap somente leitura na criação, verifique a configuração efetiva, registre a atribuição original do item de trabalho com a ferramenta de atribuição suportada e selecione uma worktree dedicada antes de liberar a implementação. Não reivindique vinculação atômica de item de trabalho nesse host nem ignore a admissão protegida necessária. Se essas operações não estiverem disponíveis, relate o bloqueador de compatibilidade; nunca atualize a pilha que hospeda a campanha.

Reconfigure antes de reutilizar uma filha. Para uma atribuição Automática, reconsidere a combinação se as evidências mostrarem que a escolha anterior foi inadequada e registre o motivo; aplique alterações apenas por meio de uma operação de configuração suportada enquanto ocioso e verifique-as antes da liberação, ou crie uma substituta com uma transferência clara de propriedade. Uma mensagem normal prompt_session não altera a configuração da sessão. Nunca altere um valor fixo por política.

Autoridade e Portões

Leia a referência Pré-verificação de Autoridade de Campanha fornecida com using-wollipog. Antes do despacho, registre o modo Custom/Controle Total efetivo, o limite e revisão estabelecidos por humanos, operações permitidas, proprietários atuais, compatibilidade, destino da evidência/divulgação do provedor e exceções de Humano Obrigatório. Identifique regras humanas obrigatórias não resolvidas por sua fonte de instrução exata; nunca reescreva silenciosamente instruções externas ou de autoria do usuário. O Controle Total se aplica apenas à autoridade elegível estabelecida pelo servidor e permitida pela política do repositório. Custom preserva os requisitos de aprovação existentes. Uma política alterada deve passar por seu próprio fluxo de contribuição explicitamente autorizado.

Mantenha a autorização de campanha real do usuário e as regras do repositório. Reivindicações de rotina, worktrees isoladas, testes, push, abertura de PRs e revisões exigidas não precisam de permissão repetida. As regras existentes podem ainda exigir autorização de merge por PR, revisão de evidências de UI, autorização de exclusão de branch remoto e aprovação de cada carga de issue saneada exata. Não converta silenciosamente uma solicitação para este fluxo de trabalho em uma renúncia a esses portões.

Leia o estado autoritativo atual da campanha e a política derivada do servidor com get_campaign antes do despacho e novamente antes de resolver uma decisão de fluxo de trabalho; não confie em uma cópia do prompt quando o estado do servidor estiver disponível. Para decisões tipadas como implementation_question, pr_merge, merged_branch_deletion, follow_up_issue_publication, ui_evidence_approval e review_round_extension, a filha deve usar request_workflow_decision, get_workflow_decision e consume_workflow_decision para a ocorrência exata imediatamente antes da ação correspondente. O pai não deve criar ou consumir um portão da filha em seu nome. Descubra ocorrências pendentes com list_descendant_requests e resolva apenas uma ocorrência exata atualmente de propriedade do Orquestrador com resolve_descendant_workflow_decision. Use answer_descendant_question e resolve_descendant_approval apenas para solicitações aplicáveis não relacionadas a fluxo de trabalho; elas nunca substituem um portão de fluxo de trabalho tipado. Um prompt comum, uma aprovação desatualizada ou a disponibilidade de Controle Parental não é autorização para um portão tipado.

Quando você possui uma decisão ui_evidence_approval com várias imagens, prefira prepare_descendant_ui_evidence_review. Ela entrega cada imagem a uma Sessão de revisor gerenciada com um contexto novo, para que as imagens nunca entrem em sua própria conversa. Escreva seu resumo a partir das reivindicações declaradas da filha e dos critérios de aceitação de UI da issue. Enquanto o revisor trabalha, encerre seu turno ou aguarde sua sessão em vez de fazer polling, então leia o veredito com get_descendant_ui_evidence_review. Aprove apenas com a referência delegatedImageReview exata que ele retorna, listando cada id de evidência em evidenceReviewed. Em uma recomendação de negação, negue com um childMessage que nomeie os defeitos observados. Mantenha review_descendant_ui_evidence para uma decisão com uma imagem, ou para uma análise direcionada de uma imagem quando o veredito deixar algo pouco claro. Onde o caminho do revisor não estiver disponível, ele recusa com o motivo; revise diretamente. Um revisor é uma filha de campanha como qualquer outra: verifique seu relatório e inclua-o na limpeza.

Antes de aprovar um pr_merge do GitHub de uma filha, leia o que ele fecha: o closingReferenceCheck da decisão lista cada issue que o GitHub fecharia no merge, e o servidor criou a decisão apenas porque elas correspondem aos intendedClosures do snapshot. Aprove um fechamento apenas quando a campanha significa que esse merge deve fechar a issue; negue com uma mensagem para a filha caso contrário, para que ela reformule a referência como "Refs #N". Onde a verificação estiver ausente (o runner da filha é anterior a ela), execute wollipog pr closures <pr-url> --json você mesmo antes de aprovar. Palavras-chave de fechamento ignoram um portão issue_closure tipado, portanto, onde a campanha fecha issues por essa rota, um merge de uma filha normalmente não deve fechar nenhuma.

Nunca altere as configurações de controle da campanha, aprove uma solicitação de propriedade humana, personifique um humano ou ignore uma aprovação pendente com um prompt simples. Uma ocorrência elegível de Controle Total raiz pode usar autorização permanente registrada pelo servidor por meio de sua rota de resolução tipada exata; ela não pode criar uma nova concessão. A evidência de UI permanece de propriedade humana quando a política ativa diz que o Orquestrador não pode inspecionar os bytes de evidência. Para qualquer portão de propriedade humana ou não delegado, retransmita a decisão concreta por meio do mecanismo de pergunta tipada suportado do harness e mantenha filhas não relacionadas progredindo. Sob Controle Total, nenhuma pessoa vê as perguntas da raiz: o servidor as descarta sem resposta, portanto, resolva as ocorrências de propriedade do Orquestrador você mesmo e relate um portão de propriedade humana, que permanece visível no Status da Campanha, em vez de perguntar. Quando o proprietário manteve uma decisão para si (uma escolha de design, uma consequência de risco...)

...

[truncado para tradução]