Agentes paralelos econômicos para Codex
Invocação: este skill é executado apenas quando o usuário o invoca pelo nome; nunca é aplicado automaticamente. Nenhum skill de orquestração invoca o outro, e os workers não invocam nenhum deles. Quando o usuário invoca tanto escalating-subagents quanto este skill para uma tarefa, pergunte qual deles se aplica antes de despachar.
Coordenador assumido: o modelo pai conforme selecionado pelo usuário, tipicamente GPT-6.1 Sol; high é uma recomendação inicial de esforço para avaliação, não uma configuração que este skill altera. Um pai em ultra pode delegar proativamente: informe isso na primeira linha de progresso, recomende high, delegue apenas através dos despachos deste skill e contabilize qualquer atribuição extra em "Pinning". Registre o modelo pai real e o esforço no cabeçalho do registro de orquestração. O coordenador orquestra: classifica o tier, escreve os critérios "Feito significa", decompõe em itens, fixa interfaces e decisões, prepara briefings para workers, despacha lotes, captura snapshots, inspeciona todos os registros de aceitação, faz triagem e relata. Ele nunca edita código de produção e nunca lê transcrições dos workers. Ele lê trechos de evidências conforme exigido pela aceitação, e o patch integrado para aceitação do tier D, validação contestada e violações de escopo.
Os workers são executados em um único modelo econômico e executam cada um um item atribuído. Eles nunca delegam, nunca invocam este skill ou qualquer skill de orquestração e nunca executam o helper de snapshot. Respeite as permissões do host e o modo de colaboração; o modo Plano não permite implementação ou descoberta que produza mutações.
Cada critério possui um ID e um tipo de evidência obrigatório: behavioral (teste executado, build ou execução que exercite a alteração), static (type-check ou lint), parse (verificação de sintaxe ou análise), format (verificação de formatação) ou inspection (diff revisado). Evidência mais fraca que o tipo do critério nunca o satisfaz; uma verificação de análise (parse) satisfaz um critério parse e nada mais.
Tiers e matriz de atribuição
Nomeie o tier na primeira linha de progresso. Qualquer estágio pode promovê-lo; nunca rebaixe. A promoção mantém contadores, adota o orçamento mais alto e revisa os critérios para os workers afetados. Dimensione os itens de acordo com a matriz: um worker pode possuir vários arquivos, portanto mescle itens em vez de descartar trabalho. A validação é executada uma vez por ciclo, após o ciclo completo de implementação ser congelado, nunca por lote; lotes intermediários recebem um post-N capturado e verificado antes do próximo lote começar, e apenas registros provisórios dos workers.
| Tier | Trabalho | Mapa (somente leitura) | Implementar | Validar por ciclo (V) | Orçamento |
|---|---|---|---|---|---|
| A | Trivial, totalmente especificado, edição de baixo risco com uma verificação concreta | 0 | 1 em low | 0; verificação pós-captura pelo coordenador | 3 |
| B | Alteração clara | 0 | ≤ 4 em medium | 1 em medium | 7 |
| C | Bug obscuro ou funcionalidade substancial; padrão | ≤ 3 em low/medium | ≤ 4 em medium | 1 em medium | 10 |
| D | Auth, isolamento de tenant, migrações, fila/sincronização, alterações em dados de produção | ≤ 3 em medium | ≤ 4 em medium | 2 em medium com briefs distintos (testes + critérios; especificação + regressões); coordenador lê o patch | 12 |
Cada nova atribuição, nova tentativa ou continuação custa uma chamada; workers paralelos contam individualmente; mensagens de status e esperas não custam nada. Seja M o número de shards no lote de mapa sendo admitido (0 para um lote de implementação), U o número de itens de implementação necessários ainda não despachados, incluindo aqueles neste lote (antes do mapeamento, a contagem planejada, pelo menos 1), e V o número de validadores por ciclo; a reserva é um reparo com sua revalidação, 1 + V. Admissão de qualquer lote requer remaining ≥ M + U + V + (1 + V); se falhar, reduza a largura, mescle itens ou ambos. A serialização altera a concorrência, não a contagem de chamadas: a admissão conta cada item necessário restante. As novas tentativas do validador (PASS não suportado, INCONCLUSIVE) gastam chamadas da reserva. Após um FAIL em r itens: quando remaining ≥ r + V, execute os r reparos e o conjunto completo de validação fresco, sem reserva adicional, e outro FAIL encerra a execução com o relatório; quando 1 + V ≤ remaining < r + V, repare remaining − V itens, valide e relate o restante como não resolvido; quando remaining < 1 + V, pare e relate os itens com falha como não resolvidos sem revalidar um patch não alterado. Exemplos práticos: tier B, quatro itens com largura 4: 7 → 3 após implementadores → 2 após validação → um FAIL em dois itens admite um reparo mais um validador → 0, um item não resolvido. Tier B com um PASS não suportado: 7 → 3 → 2 → validador fresco → 1 → FAIL → 1 < 2, pare. Tier C, um lote de mapa de 3 com 4 itens planejados: 3 + 4 + 1 + 2 = 10 admite → 7 → implementar 4 → 3 → validar → 2 → FAIL em um item → reparar e validar → 0. Tier D: 3 + 4 + 2 + 3 = 12 → 9 → 5 → 3 → FAIL em um item → 0. A escada está disponível apenas enquanto o orçamento admitir; na largura máxima, a reserva admite um reparo, não cada degrau, e o coordenador diz isso ao escolher a largura. A decomposição nunca adiciona orçamento.
Escada de esforço
O modelo do worker nunca muda; o esforço sim. medium é o padrão e o lugar para ficar.
| Degrau | Modelo | reasoning_effort | Uso |
|---|---|---|---|
| 0 | gpt-6-luna | low | Trabalho mecânico: shards de mapa somente leitura, renomeações, movimentos, formatação, execução de um comando nomeado e relatório; sem julgamentos |
| 1 | gpt-6-luna | medium | Padrão para todos os itens de Descoberta, Implementação e Validação |
| 2 | gpt-6-luna | medium | Worker novo com uma correção concreta e o caminho do registro anterior; a única nova tentativa de omissão |
| 3 | gpt-6-luna | max | Apenas após uma falha de raciocínio confirmada no degrau 1 ou 2, ou um segundo PARCIAL sem progresso |
Níveis ignorados: high é ignorado porque seu ganho observado sobre medium em avaliações independentes de codificação não justificou um degrau, e xhigh porque a escada mantém um degrau de escalonamento e max comprou mais pontuação por dólar. Não preencha a lacuna.
Briefs do degrau 0 dizem: sem julgamentos; retorne BLOQUEADO quando um for necessário. Validadores começam em medium em todos os tiers. Um FAIL correto nunca escala um validador. Falhas ambientais nunca avançam degraus. Não há escalonamento de modelo: quando a escada está esgotada, o coordenador para e relata.
| Constatação | Ação | Conta |
|---|---|---|
| Worker do degrau 0 retorna BLOQUEADO porque um julgamento é necessário | Pré-tome a decisão quando possível; redespache o item no degrau 1 | chamada; degrau → 1, não uma falha |
| Worker do degrau 1 omite um requisito ou interpreta mal o briefing | Degrau 2: worker novo com a correção e o caminho do registro anterior | chamada |
| Falha de raciocínio confirmada no degrau 1 ou 2, ou segundo PARCIAL sem progresso | Degrau 3 | chamada + degrau |
| PARCIAL com abordagem sólida e progresso | Continue no mesmo degrau | chamada |
| Validador retorna PASS não suportado (tipo de evidência muito fraco, snapshot desatualizado ou uma verificação que não foi executada) | Rejeite; validador novo no degrau 2 com requisitos de evidência explícitos; segunda ocorrência → degrau 3; Implementação intocada | chamada cada |
| Validador retorna um FAIL correto | Validação bem-sucedida; entre no ciclo de reparo: itens com falha escalam por sua própria escada, depois o conjunto completo de validação fresco | chamadas r + V |
| FAIL do validador refutado pelo coordenador com evidência registrada | Registre a correção; nenhuma alteração na Implementação; revalide apenas se o patch mudar | nenhuma |
| Validador INCONCLUSIVO ou BLOQUEADO por razões ambientais | Corrija dentro da autorização, tente novamente uma vez no mesmo degrau; verificações não resolvidas são levadas para o relatório como bloqueadas | chamada; nenhuma mudança de degrau |
| Degrau 3 falha em um item | Uma vez por item: reduza o item (escopo menor, decisões pré-tomadas) e tente novamente no degrau 1 se a admissão permitir; o item reduzido herda histórico e orçamento | chamada |
| Falha no ciclo de reparo final | Pare; relate itens não resolvidos, evidências e próximo passo; nenhum despacho adicional | nenhuma |
| Ambiguidade bloqueadora altera "feito" ou risco do tier D | Pergunte ao usuário; nomeie o bloqueador | nenhuma |
Lotes paralelos
Um item entra em um lote apenas quando todos os três se aplicam: propriedade disjunta (arquivos ou globs); dependências satisfeitas (interfaces fixas no briefing, nenhum item consome a saída inacabada de outro); sem efeitos colaterais conflitantes (arquivos gerados, esquema ou migrações, bancos de dados, portas, caches, fixtures de teste, configuração de CI). Caso contrário, serializar ou mesclar. Limites padrão, ajustáveis pelo usuário, são 4 escritores e 3 shards somente leitura por lote; são heurísticas de pesquisa sobre delegação assíncrona, não limites. A capacidade vem do runtime: use os slots anunciados pelo host e sua semântica de contagem, e despache min(cap, slots disponíveis). Despache um lote inteiro em uma mensagem. Em um despacho parcial, mantenha os workers gerados, registre-os por nome e despache o restante quando slots ficarem livres; nunca gere novamente um item já em execução.
Cada briefing carrega a lista de decisões do coordenador (nomes, interfaces, convenções escolhidas até o momento) porque ações incorporam decisões e workers paralelos, caso contrário, divergem. A execução em workspace compartilhado sem worktrees é uma troca deliberada: a propriedade mais as verificações de escopo do snapshot substituem o isolamento físico.
Ciclo de vida da evidência e congelamento
Os lotes são numerados ao longo da execução, lotes de mapa, implementação e reparo igualmente. Capture base uma vez e pre-N imediatamente antes do lote N; coloque o nome do snapshot e o ID da árvore em todos os briefs desse lote. Workers de mapa relatam contra pre-N. As verificações dos implementadores são provisórias até a validação; seus registros dizem isso e nomeiam pre-N. Depois que todos os escritores e comandos em segundo plano do lote N pararem, capture post-N e verifique names0 pre-N post-N contra a propriedade desse lote (vazio para um lote de mapa) antes de despachar qualquer outra coisa; names0 post-N pre-N+1 também deve estar vazio, e qualquer alteração lá é uma edição fora do escopo. Um ciclo é congelado quando seu último lote de implementação passa nesta verificação: os validadores novos recebem o post-N desse lote e produzem registros de aceitação contra esse estado congelado, o coordenador também verifica a união do ciclo desde seu primeiro pre até aquele post, e nenhuma escrita acontece durante a validação. Barreira: os validadores de um ciclo são despachados juntos e aguardados juntos, e nenhum reparo começa até que cada um deles tenha retornado, ou tenha sido interrompido e confirmado como terminado. Um reparo é um lote próprio: capture seu post-N, verifique-o e execute o conjunto completo de validadores do zero. Antes da aceitação, capture final; names0 entre o snapshot validado e final deve estar vazio.