@zaip-ai/cli 2.6.0 → 3.1.0

package/templates/.agents/zaip-aios/guides/19-assurance-e-autonomia.md

@@ -1,6 +1,179 @@
-# Assurance adaptativa e autonomia opt-in
+# Assurance adaptativa e perfis de autonomia
 
-O ZAIP-AIOS separa duas decisões que não devem ser confundidas: quanto de prova uma entrega exige e quem executa a DAG. A primeira é governada por `assurance`; a segunda por `execution`. O modo manual continua sendo o padrão seguro e econômico.
+Este guia descreve `autonomy-v1`, implementado nas fontes em preparação para a
+v3. Não significa que `@latest` já distribua essas mudanças ou que a release
+esteja qualificada. Confira a versão instalada e o caminho de execução.
+
+## Quatro configurações independentes
+
+| Controle | Valores | O que decide |
+| --- | --- | --- |
+| Instalação | `full`, `dev-lite`, `lite` | Ferramentas instaladas, não orçamento de IA |
+| Assurance | risco `lite`, `standard`, `critical` e sinais persistidos | Provas necessárias para aceitar a entrega |
+| Autonomia | `essential`, `balanced`, `persistent` | Persistência e replanejamento por Task |
+| Runtime | `manual`, `managed` ou `autonomous` | Sem provider, PRD/SPEC gerenciados ou também Task gerenciada explícita |
+
+`model_orchestration` é a política de seleção, não o botão de ativação do
+runtime. Salvar um preset não inicia uma Task, não altera o seletor do Codex e
+não concede permissão externa.
+
+## Perfis por Task
+
+| Perfil | Execuções máximas | Replanejamentos máximos | Rota dos replanejamentos |
+| --- | --- | --- | --- |
+| Essencial (`essential`) | **4**: 1 inicial + 3 reparações | **1** | Sol/high; nunca Astra automático |
+| Equilibrado (`balanced`, padrão novo) | **10**: 1 inicial + 9 reparações | **3** | Sol/high → Astra/high → Astra/high |
+| Persistente (`persistent`, opt-in) | **Sem teto** | **Sem teto** | Sol/high primeiro; Astra/high nos seguintes |
+
+Cada replanejamento válido libera até três reparações. São tetos, não uma
+obrigação de falhar ou gastar todas as tentativas. Se o aceite passar antes,
+siga para revisão e fechamento. No Equilibrado não existe quarto
+replanejamento; no Persistente não existe teto oculto de 10, 24 ou três planos.
+
+Exemplo máximo do Equilibrado:
+
+1. Execução inicial: tentativa 1.
+2. Replanejamento 1 com Sol/high: reparações nas tentativas 2–4.
+3. Replanejamento 2 com Astra/high: reparações nas tentativas 5–7.
+4. Replanejamento 3 com Astra/high: reparações nas tentativas 8–10; Astra/high
+   também pode executar nesse bloco, se selecionado pela rota válida.
+5. Sem aceite, registrar entrega parcial e resultado verdadeiro; não abrir
+   outra rodada gratuita.
+
+Uma SPEC com dez Tasks Equilibradas admite até **100 execuções** (10 iniciais
++ 90 reparações) e **30 replanejamentos**. A quota pertence a cada Task estável,
+não ao PRD, à SPEC, à Execution ou ao subagente. Calls internas, ferramentas,
+testes individuais, revisões e finalização não são dez execuções de produto:
+o teto não significa dez chamadas totais ao modelo.
+
+Persistente pode continuar indefinidamente e consumir créditos até
+cancelamento humano; fica desligado por padrão. Não promete ultrapassar
+indisponibilidade do host, falta de autorização, segurança ou ausência de prova.
+
+## Configurar no projeto e no Dashboard
+
+Mescle este bloco na raiz de `.agents/config/project.yaml`, sem substituir
+as demais configurações:
+
+```yaml
+autonomy:
+  version: 1
+  preset: balanced
+```
+
+No Dashboard, abra **Configurações do projeto**, escolha **Perfil de autonomia**
+e salve. A UI explica os limites e o consumo potencial do Persistente; API e
+YAML usam a mesma enumeração. Recarregue e confira o valor persistido.
+`essential` e `persistent` são as outras escolhas válidas. Não invente campos
+para alterar cotas ou modelos da tabela: o schema desse bloco é estrito.
+
+A mudança vale para **novas Tasks**. Tasks já iniciadas conservam seu perfil e
+consumo. Projetos antigos sem `autonomy` conservam comportamento legado;
+selecionar/salvar um perfil não migra silenciosamente estados já materializados.
+
+## Contagem determinística e recuperação
+
+O coordenador gerenciado reserva a operação **antes** de chamar o provider em
+`.local/autonomous/recovery/<hash-da-task>/ledger.json`. O diário é durável,
+privado e vinculado à Task, com escrita exclusiva e transições idempotentes.
+Não é cache descartável nem deve ser removido para liberar uma nova tentativa.
+
+- Reinício, nova Execution, `resume`, `rework` ou alteração do YAML não zeram
+  esse consumo. O `attempt_count` do lifecycle não substitui o diário de
+  tentativas/replanejamentos do coordenador.
+- Replay compatível reutiliza a reserva; resultado conflitante é rejeitado.
+  Resultado desconhecido permanece pendente até recuperação observável.
+- Replanejamento inválido consome sua reserva e não autoriza reparação de
+  produto. Pode consumir o orçamento antes de alcançar dez execuções.
+- O relógio, tokens, contagem de testes e `budget.soft_cycles` não calculam
+  tentativas. Tempo continua útil para diagnóstico, não para desistir da Task.
+- Timeout de comando, lease, lock ou ausência de resposta do provider é um
+  problema operacional a investigar; não prova defeito do produto.
+- Preserve logs sanitizados e a hipótese já tentada; não repita testes caros
+  inalterados apenas por demora, nem diminua ACs para obter aprovação.
+
+## Tarefas avulsas e modelos
+
+A Task avulsa prioriza execução direta com o modelo/esforço escolhido pelo
+usuário. Exemplo: Astra/ultra manual no principal não é uma escalada automática.
+No Essencial essa é a única exceção Astra: não se estende a filhos, herança ou
+fallback.
+
+Delegação só por necessidade concreta, como especialidade, isolamento ou
+revisão/finalização exigida. Antes de delegar, informe que a orquestração ZAIP
+pode selecionar modelo/esforço diferentes para os subagentes. Não prometa que
+filhos usam Astra só porque o usuário selecionou Astra no principal.
+A configuração efetivamente observada permanece separada da planejada.
+
+O replanejador recebe contexto delimitado e não implementa produto. Fora do
+Essencial, Astra/high torna-se elegível como **executor a partir do terceiro
+replanejamento**, sem ampliar escopo, autoridade ou orçamento. Ele não
+substitui revisão independente nem Gui. Veja o [guia 23](23-orquestracao-de-modelos.md).
+
+## Quando continuar e quando encerrar
+
+| Situação após recuperação aplicável | Resultado |
+| --- | --- |
+| Resultado, ACs, gates e evidências suficientes | `completed`, após fechamento canônico |
+| Falta de verificação, evidência, acesso, decisão ou conclusão segura | `blocked`, com condição objetiva de retomada |
+| Impedimento técnico ou de integridade comprovado | `failed`, com causa e rework necessário |
+| Pedido humano explícito para cancelar | `cancelled` |
+
+Não reduza critérios de aceite ao esgotar tentativas. Preserve o que foi feito,
+liste ACs sem prova e informe quantas execuções/replanejamentos ocorreram.
+“Falhou após três replanejamentos” só é correto com causa técnica comprovada;
+sem prova suficiente o resultado é bloqueado. Tempo decorrido não escolhe
+entre esses estados.
+
+Na DAG, continue ramos independentes elegíveis; não execute dependentes de
+Task não concluída nem entregue o macro sem seus gates. Uma Task bloqueada
+não deve causar repetição de Tasks já concluídas.
+
+## Limites atuais e adoção
+
+A garantia de contagem/modelo vale **no despacho gerenciado**, antes da
+invocação. `spawn_agent` chamado diretamente pelo Codex fora desse caminho
+não é interceptado por prompt, hook best-effort ou captura posterior.
+Sem observar o caminho real, não alegue controle determinístico universal.
+
+Novos projetos usam Equilibrado e `execution.runtime: managed`: PRDs/SPECs
+passam pelo executor gerenciado e avulsas permanecem diretas. `manual` e
+configuração legada ausente continuam sem provider. `autonomous` permite
+também Task avulsa gerenciada por comando explícito. Salvar não executa.
+
+A captura direta usa `conversation start ... --direct-authorization REFERÊNCIA`
+ou `run start` com a mesma opção, somente para raiz de delivery atribuída a
+Task/Change/Execution e turno/modelo observados. O contrato fica imutável no
+início; não converte raízes antigas nem cria executor fictício. Gui, Evidence,
+revisão aplicável e sua barreira continuam obrigatórios. O [guia 16](16-lifecycle-e-reconciliacao.md) descreve o relay.
+
+Migração explícita: `task migrate-autonomy TASK --execution EXEC --expected-revision N
+--legacy-attempts N --legacy-replans N --reason MOTIVO` mostra o preview;
+acrescente `--confirm` somente após revisar a contagem histórica. Exige Task
+inativa, inventário de Runs terminado, contagens não inferiores ao histórico
+observado e motivo. Preserva registros, estados e Evidence; congela o diário
+durável por Task. Não reaproveita planos antigos como autorização atual: exige
+novo plano dentro da quota restante. Se a quota acabou, continua esgotada.
+
+Se o número histórico de replanejamentos não foi registrado, use
+`--legacy-replans unknown --future-replans N` com uma concessão humana explícita
+dentro do preset (até 3 no Equilibrado). O total histórico permanece desconhecido;
+`N` limita somente os replanejamentos futuros. `--legacy-attempts N` continua
+preservando as execuções já consumidas: a concessão não reinicia o limite de dez.
+No Persistente, `--future-replans unlimited` exige a escolha explícita desse perfil.
+
+Não há economia financeira garantida pelos presets. Compare custo/tokens por
+Task aceita com cobertura real, incluindo reparos, revisão e replanejamento.
+Testes simulados de modelos não comprovam cobrança nem execução paga no host.
+
+## Assurance por domínio
+
+O preset não escolhe o rigor. Desenvolvimento exige testes comportamentais,
+regressões, segurança e rollback conforme risco. Conteúdo de Marketing,
+Branding ou Vendas exige fidelidade a fontes/briefing e revisão apropriada;
+Growth e Ops exigem dados, premissas e critérios de decisão explícitos.
+Não imponha teste de código a uma peça textual, nem use “texto” para dispensar
+segurança, autorização externa ou validação factual.
 
 ## Matriz de validação
 
@@ -65,11 +238,14 @@ execution:
 
 O projeto ZAIP-AIOS limita a concorrência produtiva a `max_parallelism: 3`, mas inicia em 1. A elevação só ocorre quando existem ramos sem dependência e sem sobreposição de write scope; o coordenador reivindica cada lote novamente com os locks do scheduler. O paralelismo efetivo é sempre o menor limite entre projeto, plano independente, provider e squad. `budget.soft_cycles` é aplicado ao agente escolhido em cada Task; tokens permanecem telemetria e custo, não checkpoint. `zaip run aggregate --agent agent-ID` filtra a identidade e retorna duração, ciclos observados, tokens, custo, cobertura e rework. Telemetria não capturada permanece indisponível, nunca zero.
 
-O runtime cria Executions-filhas determinísticas somente para SPECs com dependências internas e write scopes globalmente disjuntos. Cada filha possui coordinator, estado, quota de orçamento e handoff próprios, mas todas compartilham a fila limitada pelo paralelismo efetivo e o ledger de invocações do PRD. A filha termina antes do fan-in e o pai não reexecuta suas Tasks. A Execution do PRD integra os commits das filhas, executa as modalidades parentais sobre o commit combinado e bloqueia o finalizer enquanto houver filha ativa. SPECs inelegíveis continuam na DAG global, preservando locks, orçamento e segurança do coordenador.
+O runtime cria Executions-filhas determinísticas somente para SPECs com dependências internas e write scopes globalmente disjuntos. Cada filha possui coordinator, estado e handoff próprios; em `autonomy-v1`, o orçamento de recuperação continua no diário estável de cada Task, mas todas compartilham a fila limitada pelo paralelismo efetivo e o ledger de invocações do PRD. A filha termina antes do fan-in e o pai não reexecuta suas Tasks. A Execution do PRD integra os commits das filhas, executa as modalidades parentais sobre o commit combinado e bloqueia o finalizer enquanto houver filha ativa. SPECs inelegíveis continuam na DAG global, preservando locks, orçamento e segurança do coordenador.
 
 O driver autônomo:
 
-- usa protocolo nativo JSONL de Codex ou Claude, sem shell;
+- usa protocolo nativo JSONL, sem shell. O contrato legado suporta Codex ou Claude;
+  o despacho gerenciado com `autonomy-v1` atualmente exige Codex e rejeita Claude
+  antes de invocar o provider. Conversas diretas continuam disponíveis no provider
+  escolhido; isso não comprova suporte Claude à orquestração autônoma v1;
 - cria worktree Git por Task a partir de uma raiz limpa;
 - limita alterações aos write scopes;
 - exige commit final e valida os artefatos tipados dentro da worktree;
@@ -77,7 +253,7 @@ O driver autônomo:
 - persiste estado com compare-and-swap;
 - serializa somente transições do estado durável e rebaseia cada Task, permitindo que invocações de ramos independentes executem em paralelo com segurança;
 - mantém checkpoints opacos somente em `.local`;
-- limita `lite` a uma tentativa e `standard`/`critical` a no máximo três tentativas de desenvolvimento ou reparo;
+- em `autonomy-v1`, usa exclusivamente os tetos por Task da tabela acima; somente no legado sem esse bloco mantém as quotas antigas por risco;
 - usa verificador independente para critical, SPEC e PRD.
 
 Na Task autônoma, o adapter respeita o mesmo rigor calculado: `lite` não exige
@@ -92,4 +268,9 @@ Ativar `autonomous` não afirma que o runtime está validado em produção. A ma
 
 ## Cobertura e release
 
+Gui também pode registrar bloqueio/falha quando nenhum executor conseguiu iniciar.
+Isso evita fabricar trabalho apenas para fechar o estado. Não permite sucesso:
+`executor_missing` rejeita conclusão sem executor elegível ou raiz Task direta
+explicitamente autorizada, mesmo que existam Evidences aprovadas.
+
 O ratchet de cobertura nunca reduz o piso: 80% para lines, functions e statements e 75% para branches. Uma medição atual abaixo disso pode ser registrada como baseline observada para diagnóstico, mas o gate continua vermelho. Release crítica também exige unit, E2E, arquitetura, CQRS, módulos, profile, segurança, testes negativos, paridade da distribuição e cleanroom do candidato exato.

package/templates/.agents/zaip-aios/guides/20-instalacao-detalhada.md

@@ -38,10 +38,15 @@ O instalador preserva os READMEs do projeto na raiz. Os perfis `full`, `dev-lite
 e `lite` selecionam ferramentas de instalação; eles não classificam a dificuldade
 de uma tarefa nem ativam um modelo mais caro.
 
-O default de seleção de modelos é `manual`. O modo `auto` exige opt-in do projeto,
-permanece restrito a SPEC/PRD e mantém Astra como consultor diagnóstico opcional em
-`high`, com teto de três invocações por Task e devolução aos executores.
-Veja o [contrato de modelos e seus limites](23-orquestracao-de-modelos.md).
+Novos templates mantêm a seleção do principal em `manual` e configuram
+`execution.runtime: managed` para PRD/SPEC, com
+`autonomy: { version: 1, preset: balanced }`. São controles diferentes:
+instalar/salvar o preset não inicia provider. O [guia 19](19-assurance-e-autonomia.md)
+explica Essencial, Equilibrado e Persistente; o [guia 23](23-orquestracao-de-modelos.md)
+detalha Astra/high nos replanejamentos e sua execução elegível no terceiro bloco.
+O Essencial nunca usa Astra automático. Principal avulso preserva a seleção
+manual; filhos necessários seguem política divulgada. Projetos e estados legados
+não recebem migração silenciosa de quotas.
 
 ## Construir o CLI
 
@@ -138,8 +143,8 @@ zaip task execute TASK-ID
 Task-first não cria PRD nem SPEC sintéticas. `create` persiste somente a Task `draft`; `prepare` persiste o plano na Task; `execute` materializa Change e Execution rastreáveis antes da mutação. O prepare automático acima só aceita Task sem `depends_on`.
 
 Task-first registra objetivo, Requirements e Acceptance Criteria sem ocupar artificialmente as
-colunas Definição ou Planejamento. Uma Task criada ou preparada, mas não iniciada, aparece em Pronto
-para executar. Em pedidos diretos de ação, Change, Execution, Task e Run raiz são materializados
+colunas Definição ou Planejamento. Uma Task materializada como `planned`, nunca iniciada ou tentada, aparece em Pronto
+para executar; `task create` isolado ainda produz `draft`. Em pedidos diretos de ação, Change, Execution, Task e Run raiz são materializados
 antes da primeira mutação. Verificação e evidências sempre refletem registros reais.
 
 Para uma Task manual com dependências, modele a DAG completa em um draft de plano e gere o contrato canônico antes do prepare:
@@ -194,20 +199,21 @@ Para coleções grandes, use listagens compactas: `--status`, `--from`, `--to`,
 
 ## Executar e acompanhar a DAG
 
+Consultas de acompanhamento:
+
 ```bash
-zaip execution list
 zaip execution show EXEC-ID
-zaip execution start EXEC-ID
-zaip task next
-zaip task start TASK-ID
-zaip run start --short-name orquestrar-task --phase execution --run-purpose orchestration --entrypoint task --work-type new --client codex --agent zaip-agent-orchestrator --model MODEL --reasoning-effort EFFORT --conversation CONV-ID --execution EXEC-ID --task TASK-ID --change CHG-ID
-# execute e verifique o trabalho
-zaip run start --short-name finalizar-execution --phase execution --run-purpose finalization --entrypoint task --work-type new --client codex-subagent --agent zaip-agent-finalizer --model MODEL --reasoning-effort EFFORT --conversation CONV-ID --parent RUN-RAIZ-ID --execution EXEC-ID --task TASK-ID --change CHG-ID
-zaip run finish RUN-FINALIZADOR-ID --status completed
-zaip run finish RUN-ID --status completed --task-outcome completed --summary "Resultado" --evidence EVD-ID --changed-files src/arquivo.ts
+zaip task show TASK-ID
+zaip run show RUN-ID
 zaip run closure RUN-ID
 ```
 
+A execução deve reutilizar a identidade real capturada do turno e seu alvo.
+Não crie um `run start --agent zaip-agent-finalizer` para simular a existência
+de Gui, nem interprete `run finish --status completed` como aprovação.
+O host captura spawn/terminal reais e persiste a decisão observada antes do
+Stop canônico, conforme o [guia 16](16-lifecycle-e-reconciliacao.md).
+
 Tasks `planned` cujas dependências estejam concluídas podem rodar em paralelo. Declare conflitos de arquivos, módulos, migrations, recursos ou ambientes como bloqueios da DAG; paralelismo não deve depender apenas de pertencerem a SPECs diferentes.
 
 Cada Run raiz representa a orquestração de uma Execution. Seus filhos são Sub-Runs: ao menos um executor elegível vem do catálogo, e o último deve ser `zaip-agent-finalizer`; ele só inicia depois dos demais descendentes e impede novos filhos. A CLI aplica sua decisão como `completed`, `blocked`, `failed` ou `cancelled`; finalizador ausente ou falho produz `blocked`. `executing` e `verifying` nunca são estados válidos depois do término da Run raiz. Uma Task bloqueada continua pela mesma identidade com `task resume`. Uma Task falhada exige `task rework`, preserva a identidade e incrementa a tentativa. Tasks concluídas ou canceladas são imutáveis.

package/templates/.agents/zaip-aios/guides/21-telemetria-monitor-custos.md

@@ -8,7 +8,12 @@ O Monitor de Custos é uma visão financeira da população de Runs de Operaçã
 
 ## Fonte e proveniência
 
-A projeção é **manifest-first**: usa os manifests e registros Git como fonte canônica e a telemetria local apenas para uma reconciliação com correspondência exata. O Dashboard não usa SQLite como fonte de dados do Monitor de Custos.
+Os registros e manifests Git-native são canônicos. No runtime atual, o Monitor
+também consulta o SQLite reconstruível: o resumo recebe agregados compactos,
+enquanto páginas de Runs combinam fatos com manifests canônicos atuais.
+Caminhos de compatibilidade preservam a leitura manifest-first.
+SQLite não é outra fonte de verdade; consulta não autoriza reconciliação
+global nem alteração do histórico.
 
 Tokens, custo e duração devem exibir sua proveniência. Tokens e configuração efetiva de modelo/effort só são observados quando a fonte os informa; defaults planejados não preenchem esses campos. A projeção pode exibir duração `observed`, `reconciled`, `legacy_inferred` ou `estimated`. Apenas `observed` é medição da fonte; as demais são derivadas e não satisfazem um critério que exija duração capturada.
 
@@ -20,9 +25,20 @@ Os agregados de Conversas, Providers, Agentes, Modelos, Diário, Mensal e Anual
 
 Não use contagens, totais ou percentuais de auditorias passadas como diagnóstico atual. Consulte o período e os filtros da execução auditada; uma lacuna de coleta continua sendo lacuna, mesmo quando há estimativa ou reconciliação exibida.
 
+Na Visão geral de Tasks, cobertura incompleta produz **Subtotal estimado
+conhecido**, com valor e contagem conhecida/total. Médias de custo por item/hora
+ficam indisponíveis nessa condição para não misturar populações.
+Cobertura completa permite o rótulo **Custo estimado**. Sem soma
+conhecida, o valor continua indisponível; um zero conhecido não é ocultado.
+Esses três estados não equivalem a saldo, fatura ou custo integral do provider.
+
 ## Filtros e totais
 
-Filtros preenchidos somente com data são inclusivos: a data inicial começa em `00:00:00.000Z` e a final termina em `23:59:59.999Z`. O card de custo da Visão geral recebe o mesmo conjunto ativo do Monitor de Custos; por isso card, tabela e total devem coincidir para o mesmo período e moeda.
+Filtros preenchidos somente com data são inclusivos pelo calendário IANA
+`America/Sao_Paulo`: início à meia-noite local e fim imediatamente antes do
+próximo dia local, convertidos para UTC. Considere DST histórico; não fixe
+`-03:00` nem use o dia UTC como substituto. Timestamps explícitos conservam
+seu instante. O card de custo da Visão geral recebe o mesmo conjunto ativo do Monitor de Custos; por isso card, tabela e total devem coincidir para o mesmo período e moeda.
 
 ## Verificação operacional
 

package/templates/.agents/zaip-aios/guides/22-fluxos-e-roteamento.md

@@ -25,7 +25,14 @@ atalho de aprovação: o registro não executa o procedimento, não transforma
 resultado pendente em verde e não dispensa review/finalizador. Consulte o
 [contrato canônico](../../skills/zaip-skill-change/references/observable-evidence.md).
 
-Em PRD/SPEC com `model_orchestration.mode:auto`, trabalho simples e delimitado pode usar Luna/low, execução padrão Terra/medium e ambiguidade, transversalidade ou rework estrutural Sol/high ou xhigh. Conversation e Task-first preservam a seleção manual do host/Codex. Criticidade amplia assurance; não eleva modelo mecanicamente.
+Com `autonomy-v1`, a recuperação segue o preset congelado por Task:
+Essencial 4/1 sem Astra automático, Equilibrado 10/3 e Persistente ilimitado.
+Replanejamentos usam Sol/high primeiro e Astra/high nos seguintes permitidos;
+Astra/high pode executar a partir do terceiro bloco fora do Essencial.
+Principal avulso preserva a seleção manual e prefere trabalho direto;
+delegação necessária informa que filhos podem usar outra configuração.
+Criticidade amplia assurance; não define a quota.
+Veja [autonomia](19-assurance-e-autonomia.md) e [modelos](23-orquestracao-de-modelos.md).
 
 ## Entradas e planejamento
 
@@ -63,7 +70,12 @@ Task em execução → Orchestrator → Executor → Evidence e Decisions
                   → Auditor (quando necessário) → Finalizer → resultado
 ```
 
-O resultado pode ser concluído, bloqueado, falhado, cancelado ou exigir rework. Bloqueio e rework iniciam um novo ciclo controlado; cancelamento é uma decisão humana explícita. O finalizador fecha a Run somente depois da revisão e de qualquer auditoria exigida.
+O resultado pode ser concluído, bloqueado, falhado ou cancelado; rework é uma
+continuação autorizada, não outro estado terminal nem reset do orçamento.
+Sem evidência suficiente, bloqueie; com impedimento técnico comprovado, falhe.
+O host persiste a decisão de Gui e fecha pela CLI. Gui é último filho direto
+do responsável da Task, não de cada trabalhador; não aguarda recibos em loop.
+O controle de quotas depende do despacho gerenciado, não do desenho do fluxo.
 
 ## Lifecycle e operação