ulw-loop

Use esta habilidade quando o usuário pedir ulw-loop, ulw, execução de meta durável, trabalho baseado em evidências, QA manual ou entrega de longa duração com checkpoints.

Esta habilidade é intencionalmente compacta. O fluxo de trabalho completo está em references/full-workflow.md. Leia apenas as seções necessárias para a fase atual e execute-as exatamente.

Primeiros Passos Necessários

1. Abra references/full-workflow.md.
2. Leia Bootstrap (incluindo sua triagem de nível), Execution Loop, a tabela Manual-QA channels e as Stop Rules antes de executar qualquer comando ULW ou registrar evidências.
3. Abra references/define-goal.md e registre a meta da execução por meio dele. A criação da meta NUNCA é pulada: defina o objetivo e todos os critérios de sucesso de acordo com essa referência antes de qualquer implementação.
4. Se a tarefa envolver edições de código, testes, QA ou trabalho de commit, siga as regras de delegação e evidência do fluxo de trabalho completo. Testes sozinhos nunca provam que algo está feito.

Não Negociáveis

• Use o estado da CLI ulw-loop em .omo/ulw-loop; não edite manualmente o estado da meta.
• Registre as metas antecipadamente, definidas por references/define-goal.md (omo-agent-toolkit ulw-loop create-goals, depois create_goal da entrega impressa), e espelhe cada passo atômico na lista de verificação ativa update_plan: um passo ultra-granular por ação, exatamente um em_progresso, transições marcadas no instante em que ocorrem. Use os recursos de Tarefa e as regras de "todo" da diretiva ultrawork; leia essas seções da habilidade ultrawork agrupada se estiverem ausentes do contexto.
• Após qualquer compactação ou perda de contexto, releia primeiro o resumo + metas + ledger, mais omo-agent-toolkit ulw-loop status --json, e então retome; nunca replane do zero.
• Todo comando ulw-loop precisa do escopo da sessão: passe --session-id <id> (a entrega impressa e a diretiva de retomada o carregam; CODEX_THREAD_ID no ambiente também o resolve). A CLI recusa estado sem escopo (ULW_LOOP_SESSION_SCOPE_REQUIRED) em vez de tocar na raiz compartilhada .omo/ulw-loop.
• Se omo-agent-toolkit ulw-loop create-goals indicar que o agregado desta sessão já está completo, inicie um novo trabalho não relacionado com um novo --session-id <new-id> (passado em todas as chamadas posteriores) em vez de direcionar ou forçar o estado completo. Use --force apenas para sobrescrever intencionalmente evidências completas.
• Cada critério de sucesso precisa de evidências observáveis de uma superfície real: um canal (terminal/TUI via terminal web xterm.js, HTTP, navegador, uso de computador) ou, para critérios em formato de CLI ou dados, uma superfície auxiliar (saída padrão da CLI, diff de DB, dump de configuração analisado).
• Evidências são vinculadas à árvore em que foram capturadas (git rev-parse --short "HEAD^{tree}"); elas se tornam obsoletas apenas quando o conteúdo rastreado muda — um rebase ou amend que mantém a árvore idêntica a mantém válida. Quando a árvore difere, reexecute no HEAD atual e regrave, nunca renomeie ou regenere. Grave apenas após existirem recibos de limpeza.
• Delegue edições de código, escrita de testes, correções e execução de QA para subagentes Codex de tamanho adequado quando o fluxo de trabalho exigir.
• Cada mensagem spawn_agent começa com TASK:, depois nomeia DELIVERABLE, SCOPE e VERIFY; coloque instruções de função e especialidade dentro de message; use fork_turns: "none" (v1: fork_context: false) a menos que o histórico completo seja realmente necessário.
• Agentes de planejamento e revisão podem rodar por muito tempo; spawne-os em segundo plano e continue fazendo trabalho raiz independente. Entre as chamadas wait_agent, recue — dobre o tempo limite até cerca de 5 minutos — em vez de girar ciclos curtos.
• Para trabalho que provavelmente excederá um ciclo de espera, exija que o filho envie WORKING: <task> - <current phase> antes de leituras longas, testes ou passes de revisão, e BLOCKED: <reason> apenas quando não puder progredir.
• Rastreie os nomes dos agentes gerados localmente. Use wait_agent para sinais de caixa de correio, não prova de conclusão. Um tempo limite significa apenas que nenhuma nova atualização da caixa de correio chegou. Trate um filho em execução como vivo.
• Enquanto os filhos estiverem rodando, exiba a contagem de subagentes ativos, nomes dos agentes e a última fase WORKING:.
• Faça fallback apenas quando o filho for concluído sem o entregável, ack-only após followup_task, explicitamente BLOCKED:, ou não estiver mais em execução. Em seguida, registre como inconclusivo e gere uma tarefa fork_turns: "none" menor com o entregável ausente.

…