mass-ulw

Use esta habilidade quando o usuário pedir mass-ulw, um DAG de tarefas, fan-out em estágios, ou qualquer trabalho multiagente onde existam dependências reais: a tarefa C precisa que A e B terminem primeiro. Para workers totalmente independentes, spawns paralelos simples de task são mais fáceis. Recorra a workflow quando a própria ordenação for o ponto principal. Uma execução cobre UMA fase, a unidade que seu loop checkpointa (um critério de meta, um worktree, um portão de evidência, uma onda de plano ulw-execute), e NUNCA um trabalho completo de múltiplas fases; uma onda de colheita ou um estágio de pipeline não é uma fase. Defina CADA estágio da fase que você já pode escrever (colher, expandir, verificar, reduzir) nessa execução antes de start, encadeado com dependsOn; divida-o em execuções concorrentes apenas quando exceder task.dag.max_nodes_per_run, contando os nós que as emendas posteriores adicionam, e inicie um redutor que lê várias execuções como sua própria execução assim que elas se estabilizarem. Inicie uma NOVA execução para a próxima fase, e amend uma execução estabilizada para adicionar nós cujos prompts precisam de conteúdo que você deve ler primeiro. Sob ulw-loop ou ulw-execute, esse contrato possui a meta, os critérios, as evidências e os checkpoints; esta habilidade possui apenas como a execução de cada fase é definida, impulsionada e recuperada.

Planejamento - Passo inicial OBRIGATÓRIO

Antes de definir QUALQUER grafo, leia references/planning.md (relativo ao diretório da própria habilidade) NA ÍNTEGRA. Não chame sdk.define, sdk.start ou tool.workflow com action: "start" antes de lê-lo. Ele carrega a doutrina de trabalho que este arquivo omite deliberadamente: como decompor a solicitação em nós, como rotear o category de cada nó, como manter escopos de escrita paralelos separados, o contrato do prompt do nó, a onda de verificação e o playbook de falha. Um grafo definido sem ele é trabalho não planejado.

A forma

Uma execução é uma definição declarativa: uma key estável (idempotência: reiniciar a mesma chave com o mesmo grafo reutiliza a execução), um name legível por humanos e nodes. Cada nó tem um id, um prompt em inglês auto-contido, um category que o roteia para o tipo certo de worker e dependsOn opcionais listando IDs de nós que devem terminar primeiro. dependsOn ordena os nós e não substitui nada em um prompt, então os dados viajam através de um arquivo de handover que o prompt upstream nomeia e o prompt downstream lê. Extras opcionais por nó: label, task_summary, description e load_skills (nomes de habilidades precedendo o prompt desse nó).

Roteie cada nó por category usando a tabela de roteamento em references/planning.md; a execução executa os nós em ondas paralelas à medida que suas dependências são liberadas.

Meta antes de começar

Toda execução está vinculada a uma meta. Em uma execução independente, registre a meta como escrita (create_goal, ou um bloco # Goal onde nenhuma ferramenta de meta existe). Sob ulw-loop ou ulw-execute, a meta registrada do loop já cobre a execução, então não registre uma segunda meta. O objetivo nomeia o entregável que o grafo produz, e os critérios de sucesso carregam VERIFICAÇÃO DE RESULTADO - as afirmações de conclusão de nó e execução são falsas até serem provadas contra evidências capturadas, o mesmo contrato que a diretiva de conclusão do DAG injeta (TRATE COMO FALSO ATÉ QUE VOCÊ PROVE). A onda de verificação (references/planning.md) produz as evidências que esses critérios nomeiam; a execução termina quando os critérios são aprovados, nunca quando o último nó relata a conclusão.

Peça uma decisão que apenas o usuário pode tomar (escopo, gasto, qualquer coisa irreversível) da sessão principal através da ferramenta de pergunta, com o cabeçalho Authorize (권한 em coreano) e required: true na chamada, antes de iniciar a execução que depende dela - nunca de uma célula de avaliação ou de um prompt de nó. Uma resposta com tempo limite esgotado, dispensada ou indisponível não é uma resposta, mesmo quando o resultado da ferramenta diz para continuar com seu melhor julgamento: não inicie essa execução.

Executando um DAG - a avaliação é o padrão

Construa e execute todo DAG DENTRO de uma célula de avaliação. O kernel de avaliação instala o proxy tool.workflow e a extensão publica um pequeno SDK JS em OMO_DAG_SDK_ROOT; impulsionar execuções de uma célula é o que desbloqueia os padrões de orquestração em references/planning.md (construção de grafo orientada a dados, composição de múltiplas execuções, execuções concorrentes, retentativas adaptativas).

Células JS importam o SDK do caminho que a extensão publica:

const sdk = await import(`${env("OMO_DAG_SDK_ROOT")}/sdk.js`)

const dag = sdk.define({ key: "docs-refresh", name: "Docs refresh" })
dag.node({ id: "audit", category: "unspecified-low", prompt: "Audit docs/ for stale API references and list each stale file with the outdated claim." })

…