@zaip-ai/cli 1.0.7 → 1.3.0

package/templates/.agents/requirements/work-lifecycle.md

@@ -6,7 +6,7 @@ title: Ciclo de vida do trabalho
 status: active
 version: 23
 source_change: null
-source_release: "1.0.7"
+source_release: "1.3.0"
 ---
 
 # Work lifecycle
@@ -74,13 +74,19 @@ Cada Execução ZAIP possui uma Invocação do Orquestrador. `interaction` read-
 
 - `AC-WORK-006-01`: uma Run raiz de `orchestration` governa exatamente uma tentativa de Task e permanece aberta enquanto seus Sub-Runs executam; antes de a Run terminar, a Task deve estar `completed`, `blocked`, `failed` ou `cancelled`. `executing` e `verifying` nunca são estados válidos no fim da tentativa.
 - `AC-WORK-006-02`: `RUN-*` continua a chave física compatível do ledger, mas representa uma Invocação de Agente. `parent_run_id: null` e `invocation_kind: orchestrator` identificam exclusivamente a Invocação do Orquestrador; toda Invocação Delegada exige pai, raiz e profundidade positivos. Valores históricos permanecem legíveis e são normalizados na borda. A invocação raiz não pode terminar enquanto qualquer descendente estiver ativo.
-- `AC-WORK-006-03`: em `delivery` ou interaction com descendente delegado, o último filho é um Sub-Run `finalization` executado por `zaip-agent-finalizer`. Ele só inicia depois que um executor elegível e os demais descendentes terminam, impede novos filhos e retorna uma decisão restrita; reviewer, auditor e integrator são permitidos antes da barreira. Uma `interaction` read-only sem descendentes não inicia filhos e a CLI a conclui deterministicamente após a resposta entregue.
+- `AC-WORK-006-03`: em `delivery` ou interaction com descendente delegado, o último filho é um Sub-Run `finalization` executado por `zaip-agent-finalizer`. Ele só inicia depois que um executor elegível e os demais descendentes terminam, impede novos filhos e retorna uma decisão restrita; reviewer, auditor e integrator são permitidos antes da barreira. Quando o host observa o evento terminal, pai, agent_path e identidade catalogada, mas não expõe session/turn filhos, a captura terminal idempotente é permitida somente para o finalizador ou para executor elegível a delivery com capacidade `task-delivery`, exigindo `parent-agent-id` e `parent-run-id` da raiz ativa exata, além de agent_path terminado no `codex_task_name` canônico, e mantendo session, turn, modelo, provider e usage indisponíveis. Uma `interaction` read-only sem descendentes não inicia filhos e a CLI a conclui deterministicamente após a resposta entregue.
 - `AC-WORK-006-04`: uma Run raiz de SPEC/PRD pode terminar sem terminalizar o macro. O pai passa a `active` quando uma Task filha inicia, permanece em Execução durante intervalos e só entra em Verificação depois de todas as Tasks concluírem; delivery exige gates parentais próprios.
 - `AC-WORK-006-05`: status técnico de Run/Sub-Run (`completed`, `failed`, `cancelled`) é independente do resultado da Task (`completed`, `blocked`, `failed`, `cancelled`); a orquestração pode concluir tecnicamente e bloquear a Task por falha de gate.
 - `AC-WORK-006-06`: continuação não preserva Task em `executing` ou `verifying`, e fechamento da tentativa não pode ser adiado. Retomada de `blocked` usa `resume`; `failed` usa `rework` na mesma Task e incrementa a tentativa; `completed` e `cancelled` são imutáveis.
 - `AC-WORK-006-07`: `run reconcile --open` executa somente após confirmação humana no popup Reconciliar, nunca ao abrir o dashboard, em cada turno ou por intervalo. Ele fecha apenas o `task_complete` local exato ou Run órfã após dez minutos sem invocação ativa; órfã termina como falha técnica.
 - `AC-WORK-006-08`: a reparação histórica é idempotente: conclusão só é inferida de `task_complete` exato e gates suficientes; gate insuficiente usa `blocked`; órfã usa `failed`; `cancelled` nunca é inferido.
-- `AC-WORK-006-09`: toda mutação de fechamento projeta Run, Sub-Runs e trabalhos alterados; dashboard e projeções exibem o status canônico sem reviver Task terminal por heurística de invocação local.
+- `AC-WORK-006-09`: toda mutação de fechamento projeta Run, Sub-Runs e trabalhos alterados; dashboard e projeções exibem o status canônico sem reviver Task terminal por heurística de invocação local. `run finish --status cancelled` conserva a mesma barreira Gui de qualquer terminalização; nenhum comando direto de Task/SPEC/PRD pode dispensar Gui.
+
+### Acceptance Criteria tipados da convergência Gui
+
+- `AC-FECHA-001`: a convergência de fechamento implementa e prova `AC-WORK-006-09`; toda mutação terminal atualiza Run, Sub-Runs, Task, Change, Execution e projeções canônicas sem reviver estado aberto.
+- `AC-FECHA-002`: a convergência de fechamento implementa e prova `AC-WORK-006-03`; em delivery, Gui (`zaip-agent-finalizer`) é o último Sub-Run e a CLI aplica sua decisão restrita somente por `run finish`.
+- `AC-FECHA-003`: a qualificação da convergência Gui preserva `AC-DIST-002-03`; pacote, runtime, templates, README e comandos documentados descrevem o mesmo contrato, sem prometer bypass de finalização.
 
 ## REQ-WORK-007 — Commit canônico isolado por Task
 

package/templates/.agents/requirements/zaip-strategic-95.md

@@ -6,7 +6,7 @@ title: Evidências, custo por Task e autonomia por SPEC
 status: active
 version: 1
 source_change: null
-source_release: "1.0.7"
+source_release: "1.3.0"
 ---
 
 # Evidências, custo por Task e autonomia por SPEC
@@ -15,6 +15,6 @@ source_release: "1.0.7"
 
 As capacidades estratégicas devem ser verificáveis por estado persistido e testes reproduzíveis. Nenhuma métrica de produção, economia percentual ou autonomia é inferida de configuração, contagem de artefatos ou tentativa incompleta.
 
-- AC-ZAIP-STRATEGIC-95-001: uma execução com Sub-Run executor elegível e finalizer concorrentes preserva uma única captura terminal por Sub-Run, não permite finalizer antes do executor terminal e só persiste `finalization_barrier.satisfied: true` depois da Evidence exigida e do finalizer real concluído. Testes devem reproduzir a corrida create/capture/close e confirmar que replay idempotente não cria Evidence, terminal ou Sub-Run duplicados.
-- AC-ZAIP-STRATEGIC-95-002: uma coorte reproduzível de Tasks concluídas define população, intervalo temporal, timezone e chave de equivalência; cada linha inclui Task, tentativa, modelo, effort, custo/uso observados, quality floor, resultado de qualidade e rework. Agregação só compara custo quando baseline equivalente e ambos os custos são observados; exclusões e campos ausentes são explícitos, e não há percentual de economia sem numerador e denominador observados. Testes cobrem coorte vazia, dados incompletos, rework e agregação determinística.
-- AC-ZAIP-STRATEGIC-95-003: cada SPEC autônoma recebe execução isolada com DAG e write scopes próprios, orçamento/cancelamento próprios e executor/finalizer próprios. Cancelamento ou falha de uma SPEC não encerra nem consome o orçamento de SPEC independente; cada finalizer valida somente o candidato integrado da sua SPEC e encerra por último. Testes cobrem duas SPECs paralelas, colisão de scope, cancelamento isolado, budget esgotado e ordem de finalização.
+- `AC-ZAIP-STRATEGIC-95-001`: uma execução com Sub-Run executor elegível e finalizer concorrentes preserva uma única captura terminal por Sub-Run, não permite finalizer antes do executor terminal e só persiste `finalization_barrier.satisfied: true` depois da Evidence exigida e do finalizer real concluído. Testes devem reproduzir a corrida create/capture/close e confirmar que replay idempotente não cria Evidence, terminal ou Sub-Run duplicados.
+- `AC-ZAIP-STRATEGIC-95-002`: uma coorte reproduzível de Tasks concluídas define população, intervalo temporal, timezone e chave de equivalência; cada linha inclui Task, tentativa, modelo, effort, custo/uso observados, quality floor, resultado de qualidade e rework. Agregação só compara custo quando baseline equivalente e ambos os custos são observados; exclusões e campos ausentes são explícitos, e não há percentual de economia sem numerador e denominador observados. Testes cobrem coorte vazia, dados incompletos, rework e agregação determinística.
+- `AC-ZAIP-STRATEGIC-95-003`: cada SPEC autônoma recebe execução isolada com DAG e write scopes próprios, orçamento/cancelamento próprios e executor/finalizer próprios. Cancelamento ou falha de uma SPEC não encerra nem consome o orçamento de SPEC independente; cada finalizer valida somente o candidato integrado da sua SPEC e encerra por último. Testes cobrem duas SPECs paralelas, colisão de scope, cancelamento isolado, budget esgotado e ordem de finalização.

package/templates/.agents/rules/autonomy-decision.md

@@ -0,0 +1,15 @@
+---
+id: RULE-AUTONOMY-DECISION
+load: auto
+priority: high
+max_context_tokens: 500
+requires:
+  - RULE-CORE
+---
+
+# Decisao autonoma proporcional
+
+- Aja por padrao somente quando a acao for reversivel, estiver dentro do escopo e a evidencia permitir uma decisao tecnica delegavel.
+- Pergunte quando uma escolha humana alterar materialmente objetivo, custo, autoridade, dados externos ou o risco aceito.
+- Bloqueie e registre a lacuna quando faltar credencial, autorizacao externa/destrutiva, requisito legal/seguranca, ou evidencia factual necessaria; nunca invente dados, resultados ou chaves de configuracao.
+- O limite `execution.autonomous.max_total_invocations` e um circuito finito: ao atingi-lo, pare com estado resumivel e evidencia do motivo; nao reinicie nem contorne o contador.

package/templates/.agents/rules/core.md

@@ -15,7 +15,7 @@ requires: []
 - Faça no máximo cinco perguntas por turno e três turnos; depois registre decisões delegáveis. Autoridade, credencial, lei e segurança não delegáveis bloqueiam. Resolva verbos por alvo/status em `RULE-WORKFLOW`: `execute` usa o menor grão, `implemente` sem alvo conversa, `desenvolva|melhore|aprimore` planeja/rework. Nunca invente tokens, custo, decisão, Evidence, teste ou resultado.
 - Em modo manual carregue `RULE-MODEL-ORCHESTRATION` antes da primeira resposta visível; aviso não bloqueia nem altera seleção. Com Codex/delegação use apenas `codex_name` do catálogo, formato `zaip-agent-NOME`, recursivamente; proíba `default`, `worker`, `explorer` e tipos ad-hoc.
 - Cada `client_turn_id` observável tem uma Execution idempotente/claim atômico; sem ele use identidade local sem prometer idempotência. `interaction` read-only sem descendentes é conversa sem Task artificial e termina após a resposta entregue, sem executor ou finalizador; interaction com trabalho delegado e `delivery` exigem executor/finalizador. `delivery` é trabalho materializado e reuso exige kind/origem compatíveis. A raiz é `zaip-agent-orchestrator`; quando a barreira é exigida escolha executor por capacidade, permita reviewer/auditor/integrator e termine com `zaip-agent-finalizer` em `finalization`, após descendentes, bloqueando novas chamadas.
-- Hooks são best-effort: após cada spawn/terminal o orquestrador também executa `zaip subagent capture` idempotente com metadados reais. Use session/turn filhos, `agent-id=agent_path`, `parent-agent-id=client_thread_id` da raiz e turn distinto por chamada. Só terminal sem metadata do `zaip-agent-finalizer` usa `capture-terminal`, criando/fechando Sub-Run `finalization` com session/turn/model/provider/usage indisponíveis; nunca substitui captura rica nem inventa modelo, effort, tokens ou custo.
+- Hooks são best-effort: após cada spawn/terminal o orquestrador também executa `zaip subagent capture` idempotente com metadados reais. Use session/turn filhos, `agent-id=agent_path`, `parent-agent-id=client_thread_id` da raiz e turn distinto por chamada. Quando um evento terminal observado expõe somente agent_path, status, identidade catalogada e pai exato, `capture-terminal` aceita apenas `zaip-agent-finalizer` ou executor elegível para delivery com capacidade `task-delivery`; exige também `parent-run-id` igual ao `run_id` da raiz ativa exata, pois um client thread pode conter raízes concorrentes. O último segmento do agent_path deve ser seu `codex_task_name` canônico. O propósito deriva da identidade validada e session/turn/model/provider/usage permanecem indisponíveis; o fallback nunca substitui captura rica nem inventa modelo, effort, tokens ou custo.
 - Em `model_orchestration.mode:auto`, selecione automaticamente apenas origens em `automatic_sources` (`spec`,`prd`); fixe modelo/effort no início de cada Run/Sub-Run distinta, herde nas calls internas e exija nova chamada para mudar. Task avulsa preserva seleção manual, sem inferir `default_model`.
 - Todo PreparedPlan PRD/SPEC traz `model_signals` por Task; o framework persiste `model_profile`, `task-risk-v1` e motivos, usando `runtime_defaults`, `runtime`, política/defaults sem `standard` silencioso. Não infira fase/complexidade/transversalidade/ambiguidade/rework/custo/capacidade por contagem de arquivos; use sinais, fase/agente e capacidades. Cabeçalho e `model.selection.recorded` repetem a seleção enviada.
 - Quando útil, plano visível usa `DEFINE:`, `PLAN:`, `EXECUTE:` ou `VERIFY:`, 3–4 passos (máximo 5); omita fase sem ação e combine trivialidades.

package/templates/.agents/rules/run-lifecycle-closure.md

@@ -17,7 +17,7 @@ requires:
 - O finalizador avalia gates e Evidence e retorna somente `completed`, `blocked`, `failed` ou `cancelled`, com motivo e referências. A CLI aplica o estado terminal canônico. Finalizador ausente, incompleto ou falho bloqueia a Task antes de a Run raiz terminar.
 - O resultado da Task é separado do status técnico da Run/Sub-Run: uma orquestração tecnicamente `completed` pode produzir Task `blocked` se gate, validação ou Evidence não passar.
 - Use `completed` somente com gates e Evidences aprovados; `blocked` para dependência externa, autoridade ou informação ausente, gate/teste pendente, falta de Evidence, limite de tempo/contexto ou outra inconclusão. Registre o motivo e a condição objetiva de retomada.
-- Use `failed` somente para erro técnico ou de integridade comprovadamente impeditivo. Nunca use `failed` por tempo, silêncio do usuário, escopo incompleto ou gate pendente; esses casos são `blocked`. `cancelled` requer pedido humano explícito e nunca é inferido.
+- Use `failed` somente para erro técnico ou de integridade comprovadamente impeditivo. Nunca use `failed` por tempo, silêncio do usuário, escopo incompleto ou gate pendente; esses casos são `blocked`. `cancelled` requer pedido humano explícito e nunca é inferido. Toda terminalização, inclusive cancelamento de Task/SPEC/PRD ou Run, só é aplicada pelo orquestrador após Gui concluir o Sub-Run finalizador.
 - `blocked` retoma com `task resume`; `failed` exige `task rework` na mesma Task, incrementa a tentativa e inicia nova Run. A continuação não preserva Task em `executing` ou `verifying`; `completed` e `cancelled` são imutáveis.
 - Uma Run de SPEC/PRD não terminaliza o macro a cada turno ou Task: o pai fica `active` durante a execução, inclusive nos intervalos, e somente passa à Verificação depois de todas as Tasks terminarem, antes dos gates parentais de delivery.
 - `run reconcile --open` é reparação manual: só ocorre após confirmação humana no popup Reconciliar, nunca ao abrir/atualizar o dashboard, em cada turno ou por intervalo. Fecha somente `task_complete` local exato; Run órfã sem invocação ativa por dez minutos falha tecnicamente; gates ausentes bloqueiam; conclusão e cancelamento nunca são inferidos.

package/templates/.agents/rules/specialist-routing.md

@@ -0,0 +1,19 @@
+---
+id: RULE-SPECIALIST-ROUTING
+load: always
+priority: high
+max_context_tokens: 650
+requires:
+  - RULE-CORE
+---
+
+# Roteamento por decisão e entrega primária
+
+- Escolha o executor pelo resultado ou decisão primária solicitada, nunca apenas por referência, input, arquivo citado ou contexto disponível. Convenções `reference:` e `input:` não selecionam especialista.
+- Uma unidade delimitada recebe exatamente um executor de domínio por padrão. Um especialista secundário só entra quando a decisão do seu domínio permanece sem resolver e é necessária ao resultado principal.
+- Dois resultados independentes — por exemplo, editar um Brandbook e criar uma campanha — são Tasks sequenciais, não codispatch da mesma unidade. Conflitos de outputs independentes devem permanecer explícitos.
+- Sarah resolve plataforma de marca, posicionamento, Brandbook, arquétipos, diferencial semântico, arquitetura, governança e auditoria de consistência que exige decisão de marca. Aplicação ordinária de marca aprovada não é trabalho de Sarah.
+- Lúcia resolve marketing, campanhas, conteúdo, assets, copy e aplicação de Brandbook aprovado. Escale Sarah somente quando a decisão de marca estiver ausente, contraditória ou precisar ser criada.
+- Aaron resolve metodologia, processo, script voltado a vendas, qualificação, negociação, enablement e handoffs comerciais. Copy de campanha pertence a Lúcia; estratégia empresarial e RevOps pertencem a Robert.
+- Robert resolve estratégia de negócio, planejamento, advisory executivo, Growth/RevOps, modelo de negócio, priorização de portfólio e decisões econômicas; ele não produz campanha, Brandbook ou playbook de vendas.
+- Trabalho genérico sem domínio obrigatório vai para Clara. Em ambiguidade de marketing/copy, escolha Lúcia. Em Interaction de domínio inequívoco, escolha o especialista elegível; analista é fallback para pedido genérico ou não classificado.

package/templates/.agents/rules/workflow.md

@@ -12,7 +12,7 @@ requires:
 - Pensar/explorar PRD/SPEC é Conversation sem artefato. Criar/refinar explicitamente persiste PRD/SPEC `draft`, PreparedPlan, Run e `creation_run_id` em Execution `interaction`, sem Task, Change ou delivery; agregue duração/tokens/custo só observados/reconciliados. `ready` explícito materializa DAG, Execution, Changes e Tasks `planned` sem iniciá-las; `execute` materializa e inicia. A interaction não rebaixa a visibilidade `draft`.
 - Fluxos: `PRD -> SPECs independentes -> PreparedPlan -> ready Tasks`, `SPEC standalone -> PreparedPlan -> ready`, ou Task-first. Use uma SPEC por padrão; outra requer paralelismo verificável, contrato estável e write scopes sem conflito. Dependências pertencem à SPEC; integração cross-SPEC é gate parental do PRD.
 - Colunas: Definição só PRD `draft`; Planejamento só SPEC `draft`; Pronto para Executar recebe macro `ready` e Task `planned`, não ativa/nunca iniciada ou tentada. Task `draft` não entra; iniciada/tentada fica em Execução, Verificação ou terminal e não retorna.
-- Todo turno tem Execution/Run raiz, mas só trabalho executável tem Task. Pergunta, explicação, status, análise pontual ou baixa confiança usa `interaction`, `phase: conversation`, `entrypoint: conversation`, sem Task/Change artificial. Continuação, resposta, aprovação, refinamento e rework reutilizam o alvo/thread; nova Task explícita prevalece. Fora da exceção draft, mutação persistente ou resultado independente cria Task antes de `prepare -> execute`; deploy/push/publicação puros são Git-only.
+- Todo turno tem Execution/Run raiz, mas só trabalho executável tem Task. Pergunta, explicação, status, análise pontual ou baixa confiança usa `interaction`, `phase: conversation`, `entrypoint: conversation`, sem Task/Change artificial. Mencionar ou discutir PRD/SPEC não autoriza criação: somente pedido humano explícito de criar, com autorização estruturada de definição, materializa macro. Sem esse pedido, leitura permanece Conversation; mutação persistente ou resultado independente cria Task-first sem ancestrais PRD/SPEC sintéticos. Continuação, resposta, aprovação, refinamento e rework só reutilizam foco na mesma `client_thread_id`; nova Task explícita prevalece. Fora da exceção draft, mutação persistente ou resultado independente cria Task antes de `prepare -> execute`; deploy/push/publicação puros são Git-only.
 - PRD pode ser draft sem SPEC, mas `prepare|execute|deliver` exige SPEC e veda Change direta fora dela; só SPECs selecionadas pelo PreparedPlan contam. `task create` só persiste draft; Run de captura é separado. `prepare` pré-aloca IDs/valida DAG sem produto, Change, Execution ou Run de execução; em PRD/SPEC não cria Task nem promove draft. Task auto-prepare só sem `depends_on`; dependência exige `zaip plan build` completo.
 - Só pedido humano explícito move PRD/SPEC a `ready`; executar autoriza `prepare` necessário e `execute`. Criação, revisão, refinamento, aprovação de conteúdo ou planejamento genérico não promovem. Até cinco perguntas críticas no primeiro turno e três de esclarecimento; depois decisão técnica IA delegável. Não presuma credencial, autoridade externa/destrutiva, obrigação legal ou segurança não delegável.
 - Resolva verbo por alvo/status: `finalize|conclua|deixe pronto` em `draft|ready` significa `ready`; conclusão de implementação em `active` continua Tasks/gates; `execute` usa o menor grão nomeado. `implemente` sem alvo conversa; em draft finaliza plano, ready executa, active|blocked|failed continua/retoma/rework. `desenvolva|melhore|aprimore` planeja/refina/rework e requer nova promoção. PRD cancelado é imutável; sucessor draft usa `tags:[rework]` e `rework_of_prd_id`.

package/templates/.agents/runtime/VERSION

@@ -1 +1 @@
-1.0.0
+1.3.0