@zaip-ai/cli 1.0.7 → 1.0.8

package/templates/.agents/requirements/kanban-dashboard.md

@@ -4,9 +4,9 @@ id: REQUIREMENTS-KANBAN-DASHBOARD
 area: kanban-dashboard
 title: Projeções operacionais e analíticas
 status: active
-version: 12
+version: 13
 source_change: null
-source_release: "1.0.7"
+source_release: "1.0.8"
 ---
 
 # Kanban and dashboard
@@ -20,7 +20,7 @@ Kanban, dashboard e Cost Monitor devem projetar o estado Git-native e distinguir
 - `AC-DASH-001-03`: SPEC agrega Tasks, Executions e Runs descendentes.
 - `AC-DASH-001-04`: Task-first permanece analisável sem ancestrais sintéticos.
 - `AC-DASH-001-05`: projeções mostram cobertura de uso/preço e não alteram estado canônico silenciosamente.
-- `AC-DASH-001-06`: a UI consulta um snapshot coerente de operações e custos, atualiza-o silenciosamente em intervalo curto e exibe o timestamp real da fonte, não o horário local da consulta.
+- `AC-DASH-001-06`: a UI consulta um snapshot coerente de operações e custos quando a página, período, moeda ou ação explícita de atualização o solicita; não faz polling, prefetch em segundo plano ou hidratação automática. Duração, tokens e custo exibem a soma dos valores persistidos e conhecidos, inclusive duração reconciliada ou `legacy_inferred`, sem aproximar valores ausentes; uma soma conhecida nula é exibida como `0`. O timestamp exibido é o real da fonte, não o horário local da consulta.
 - `AC-DASH-001-07`: Run de `conversation` sem Task permanece nas métricas e na rastreabilidade, mas nunca produz card no TaskBoard.
 - `AC-DASH-001-08`: PRD `draft` permanece em Definição e SPEC `draft` permanece em Planejamento durante criação, revisão, refinamento e `prepare`; somente promoção explícita para `ready` as coloca em Pronto para Executar.
 - `AC-DASH-001-09`: SPEC/PRD `active` permanece em Execução enquanto houver trabalho macro, inclusive entre Runs filhas e quando uma Task filha termina bloqueada ou falhada; somente gates parentais movem o macro para Verificação ou status final.
@@ -28,3 +28,4 @@ Kanban, dashboard e Cost Monitor devem projetar o estado Git-native e distinguir
 - `AC-DASH-001-11`: o popup Reconciliar executa `run reconcile --open` somente após confirmação humana e aplica o resultado canônico; abrir o dashboard, atualizar automaticamente ou enviar novo turno não inicia reconciliação global.
 - `AC-DASH-001-12`: Operação e Monitor de Custos apresentam os filtros “Chamadas do agente orquestrador” (`parent_run_id: null`) e “Chamadas de subagentes” (`parent_run_id` preenchido), exibindo propósito, pai, `zaip-agent-*`, modelo/effort planejados, configuração efetiva, quantidade de Calls conhecida, tokens e custo; Calls não possuem tela própria.
 - `AC-DASH-001-13`: a tabela de Executions apresenta contagens sem dupla contagem de Runs, Sub-Runs, finalizadores, Tasks finalizadas e LLM Calls; ausência de captura completa de Calls é sinalizada como parcial, nunca convertida em zero conhecido.
+- `AC-DASH-001-14`: o Kanban persiste uma fila manual única para PRDs, SPECs e Tasks; itens ranqueados são enumerados de cima para baixo, o próximo elegível é destacado e novos IDs ausentes permanecem após a fila com desempate estável por criação/ID. Drag-and-drop tem alternativa equivalente por teclado ou botões.

package/templates/.agents/requirements/model-orchestration.md

@@ -6,7 +6,7 @@ title: Seleção automática e observável de modelo e effort
 status: active
 version: 7
 source_change: null
-source_release: "1.0.7"
+source_release: "1.0.8"
 ---
 
 # Orquestração de modelos

package/templates/.agents/requirements/public-distribution.md

@@ -3,10 +3,10 @@ schema_version: 2
 id: REQUIREMENTS-PUBLIC-DISTRIBUTION
 area: public-distribution
 title: Distribuição pública e ativação
-status: proposed
-version: 2
+status: active
+version: 3
 source_change: null
-source_release: "1.0.7"
+source_release: "1.0.8"
 ---
 
 # Distribuição pública e ativação
@@ -30,10 +30,13 @@ A distribuição pública só pode ser candidata quando fonte canônica, templat
 
 ## REQ-DIST-003 — Configuração global portátil do Codex
 
-O CLI público deve descobrir o diretório inicial do usuário em execução e instalar uma configuração global do Codex que não contenha paths ou identidades locais fixas.
+O CLI público deve descobrir o diretório inicial do usuário em execução e reconciliar a proteção
+global do Codex sem apagar preferências, integrações ou identidades canônicas do usuário e sem
+introduzir paths ou identidades locais fixas.
 
-- `AC-DIST-003-01`: em uma instalação limpa, o CLI substitui `config.toml` em `<home-do-usuário>/.codex/` por conteúdo idêntico ao arquivo portátil instalado no projeto, sem referência a um nome de usuário ou path absoluto do ambiente de build.
-- `AC-DIST-003-02`: se a escrita global falhar, o CLI conclui a instalação do projeto sem ocultar a falha e informa o destino exato, a origem `<projeto>/.codex/config.toml` e os passos de cópia manual.
+- `AC-DIST-003-01`: em uma instalação limpa ou existente, o CLI preserva as configurações globais e identidades canônicas, remove somente aliases `codex_name` obsoletos declarados pelo catálogo instalado e adiciona o hook portátil canônico, sem referência a nome de usuário ou path absoluto do ambiente de build.
+- `AC-DIST-003-02`: se a escrita global falhar, o CLI conclui a instalação do projeto sem ocultar a falha, informa o destino exato e o erro, e mantém na documentação os passos de reconciliação manual que preservam a configuração existente.
+- `AC-DIST-003-03`: a reconciliação substitui todo hook `PreToolUse` identificado como ZAIP por exatamente um bloco canônico e preserva hooks de terceiros; reexecuções são idempotentes.
 
 ## Verificação
 

package/templates/.agents/requirements/software-architecture.md

@@ -6,7 +6,7 @@ title: Layout modular e limites de código-fonte
 status: active
 version: 5
 source_change: null
-source_release: "1.0.7"
+source_release: "1.0.8"
 ---
 
 # Software architecture

package/templates/.agents/requirements/strategic-improvements.md

@@ -6,7 +6,7 @@ title: Melhorias estratégicas de custo, qualidade e resiliência
 status: active
 version: 1
 source_change: null
-source_release: "1.0.7"
+source_release: "1.0.8"
 ---
 
 # Melhorias estratégicas de custo, qualidade e resiliência

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.0.8"
 ---
 
 # 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.0.8"
 ---
 
 # 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.0.8