@zaip-ai/cli 4.8.0 → 5.0.0

package/templates/.agents/requirements/execution-engine.md

@@ -4,9 +4,9 @@ id: REQUIREMENTS-EXECUTION-ENGINE
 area: execution-engine
 title: Preparação, materialização e DAG
 status: active
-version: 11
+version: 13
 source_change: null
-source_release: "4.8.0"
+source_release: "5.0.0"
 ---
 
 # Execution engine
@@ -25,6 +25,13 @@ source_release: "4.8.0"
 `execute` deve materializar Changes, Tasks e Execution antes da primeira mutação, preservando snapshot da DAG para retomada e auditoria. A tentativa explícita já pertence à fase `execution`, independentemente de produzir diff.
 
 - `AC-EXEC-002-01`: repetir `execute` não duplica artefatos, e cada tentativa explicitamente iniciada possui Run atribuído.
+
+Se uma definição de SPEC no mesmo turno físico já terminou com Gui e uma
+autorização explícita observada manda executar aquela SPEC pronta, `spec execute`
+pode registrar um segmento lógico sucessor de delivery. A Run de definição
+permanece imutável; claim, alvo e hash da autorização vinculam a sucessora,
+sem dois proprietários ativos ou contagem dupla de uso quando a fronteira de
+tokens não é observável. Sem esses fatos, vale o guard normal de turno único.
 - `AC-EXEC-002-02`: cada Task executável possui dependências e Execution explícitas; Task encerrada como conversa read-only não materializa DAG sintética.
 - `AC-EXEC-002-03`: falha parcial pode ser retomada sem corromper o plano.
 - `AC-EXEC-002-04`: início da fase `execution` não implica mutação; `changed_files` e `result` registram separadamente se houve mudança real e qual foi o desfecho.
@@ -60,3 +67,5 @@ Execuções devem limitar repetição por checkpoints suaves e verificar somente
 - `AC-EXEC-005-05`: a skill de execução exige refresh seletivo e checkpoint compacto ao atingir os budgets suaves.
 - `AC-EXEC-005-06`: quando um plano visível é útil, cada passo começa com `DEFINE:`, `PLAN:`, `EXECUTE:` ou `VERIFY:`, usa somente fases aplicáveis, contém no máximo 5 passos e combina ações triviais; tarefas simples podem omitir o plano.
 - `AC-EXEC-005-07`: checkpoints suaves de contexto são acionados somente por ciclos; telemetria de input não cacheado do provider e contexto observável permanece registrada com sua origem, sem inventar valores ausentes. Checkpoints de segurança por esgotamento de tentativas semânticas são distintos desse contador. Observações de convergência não concedem aprovação nem cancelam trabalho por duração; tempo não observado permanece indisponível.
+
+Para novas avaliações de PRD/SPEC/DAG e release, a política `proportional-acceptance-v1` de `@zaip-ai/specs` exige critério obrigatório rastreável a pedido humano, Requirement ativo ou risco concreto, com aplicabilidade, resultado observável, prova suficiente, responsável e condição de parada. Todos os obrigatórios precisam passar no candidato aplicável; melhoria opcional pendente não bloqueia. Uma Task avulsa conserva o assurance proporcional existente, sem escala nova. Snapshots antigos não são recalculados: adoção retroativa exige migração explícita, versionada e atribuída.

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

@@ -6,7 +6,7 @@ title: Projeções operacionais e analíticas
 status: active
 version: 14
 source_change: null
-source_release: "4.8.0"
+source_release: "5.0.0"
 ---
 
 # Kanban and dashboard

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: 10
 source_change: null
-source_release: "4.8.0"
+source_release: "5.0.0"
 ---
 
 # Orquestração de modelos

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

@@ -6,7 +6,7 @@ title: Distribuição pública e ativação
 status: active
 version: 10
 source_change: null
-source_release: "4.8.0"
+source_release: "5.0.0"
 ---
 
 # Distribuição pública e ativaçã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: "4.8.0"
+source_release: "5.0.0"
 ---
 
 # 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: "4.8.0"
+source_release: "5.0.0"
 ---
 
 # 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: 26
 source_change: null
-source_release: "4.8.0"
+source_release: "5.0.0"
 ---
 
 # Work lifecycle
@@ -75,6 +75,7 @@ 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 todos os descendentes existentes terminam, impede novos filhos e retorna uma decisão restrita. O resultado `completed` exige executor elegível ou a autorização direta válida de `AC-WORK-001-09`, além dos demais gates. Sem executor ou autorização válida, Gui pode avaliar e devolver `blocked`/`failed`, mas não conceder sucesso; não se cria executor cerimonial para contornar a barreira; 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 manutenção autorizada para reparar o fechamento pós-publicação pode emitir recibo canônico na própria Change enquanto sua Run delivery permanece ativa. Após Task de manutenção e Gui terminarem `completed`, a CLI pública consome o recibo somente para a Task/SPEC/Execution histórica exata, com revisões, autorização humana observada, provas de candidato/publicação/CI/ciclo e conteúdo de Evidence revalidados. O claim exclusivo permite uma raiz sucessora da SPEC no mesmo turno observado ou em turno novo autenticamente observado; crash parcial não cria outra raiz ou aprovação. A Task histórica não ganha escrita de produto nem reutiliza o Gui da manutenção: seu fechamento precisa de executor elegível, Evidence e seu último finalizador próprios. Testes de mutação devem matar a remoção da barreira de Gui e da verificação da fronteira de produto.
 - `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.

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: "4.8.0"
+source_release: "5.0.0"
 ---
 
 # Evidências, custo por Task e autonomia por SPEC

package/templates/.agents/rules/cloud-hostinger-autonomy.md

@@ -17,7 +17,7 @@ domains: [terraform, hostinger, cloudflare, ssh]
 - `.env` na raiz é a fonte local preferida; `.agents/.env` é alternativa configurável. Ambos são ignorados e só fornecem credenciais e identificadores ao subprocesso mínimo. Eles nunca autorizam alvo. Antes de operação remota, confira perfil `autonomous-cloud`, conta+zona Cloudflare, conta Hostinger, IDs das VPS e fingerprints SSH contra a execução ativa. Ausência, diferença ou ambiguidade bloqueia.
 - Quando a Task registrar autorização permanente e o `.env` da raiz contiver identificadores deliberados, descoberta somente de leitura pode derivar e registrar esse escopo antes da configuração; não exija JSON manual nem nova autorização. Fora desse contexto, credencial sem mandato e alvos delimitados permanece insuficiente.
 - Autonomia autorizada pelo usuário começa somente após esse preflight. Não peça a mesma autorização novamente para recursos já delimitados: abrir portas aprovadas, alterar firewall, rotacionar chave, configurar DNS, criar/editar recursos e testar são autônomos dentro da arquitetura e do orçamento aprovados. Nova zona, conta, VPS, destino, plano, datacenter, teto de custo, recurso desconhecido ou efeito irreversível ainda não aprovado exige escopo atualizado.
-- VPS 1 recebe somente ingress público Cloudflare; VPS 2 recebe somente transporte privado autenticado da VPS 1 e administração permitida. Redis, BullMQ, exporters, Grafana, Prometheus, Uptime Kuma e painéis não expõem DNS ou portas públicas. Produção e beta têm dados e redes independentes.
+- Se o contrato de infraestrutura aprovado declarar a topologia de duas VPS, VPS 1 recebe somente ingress público Cloudflare e VPS 2 somente transporte privado autenticado da VPS 1 e administração permitida. Para outra topologia, derive limites de rede do contrato aprovado antes de agir; não crie uma segunda VPS por inferência. Redis, BullMQ, exporters, Grafana, Prometheus, Uptime Kuma e painéis não expõem DNS ou portas públicas. Produção e beta têm dados e redes independentes quando ambos os ambientes estiverem no escopo.
 - O provider Hostinger não prova firewall, malha privada ou configuração de containers. Declare o executor e valide essas camadas por observação; não invente recursos ou campos de provider não verificados.
 - Exija backend remoto com criptografia, versionamento e locking antes de apply compartilhado. Execute `fmt`, `validate`, plano revisado, apply do arquivo de plano e read-after-write. Nunca persista segredo, state, plano binário ou material de chave.
 - Só declare infraestrutura funcional após evidência observada de DNS, TLS, health checks, portas privadas negadas e restauração. Sem acesso/execução observada, reporte apenas validação estática/local.

package/templates/.agents/rules/production-readiness.md

@@ -0,0 +1,24 @@
+---
+id: RULE-PRODUCTION-READINESS
+load: auto
+priority: high
+max_context_tokens: 850
+requires:
+  - RULE-CORE
+  - RULE-AUTONOMY-DECISION
+triggers: [prontidão, readiness, nota, estabilidade, qualificação, qualification, release]
+phases: [planning, execution, verification, evidence]
+---
+
+# Qualificação técnica essencial
+
+- Para avaliações novas de PRD/SPEC/DAG/release, use o aceite binário `proportional-acceptance-v1` em `@zaip-ai/specs` e o contrato de `docs/quality/production-readiness.md`: origem, aplicabilidade, resultado, prova, responsável e parada por critério obrigatório. Falta de obrigatório bloqueia; melhoria opcional pendente não bloqueia. Não recalcule snapshots antigos sem migração explícita. A nota histórica é informativa, não gate adicional.
+- Declare Windows como ambiente local obrigatório do candidato atual; Linux no GitHub é smoke remoto do pacote exato. Não crie Docker, WSL ou outro SO local para satisfazer preferência. Segurança e integridade aplicáveis permanecem gates.
+- A API técnica de notas `technical-essential-v1` continua compatível, documentada em `docs/quality/production-readiness.md`. Notas 9 e 10 avaliam o candidato no escopo declarado de uso, plataformas e runtimes. Não exigem dias de observação nem contagem mínima de ciclos reais; não são garantia de ausência de defeitos nem certificação de estabilidade prolongada.
+- Nota 9 exige todos os seis critérios: instalação/upgrade com preservação, comportamento principal, agentes/rastreabilidade, falha/retomada/idempotência, segurança/rollback/reaplicação e integridade/revisão independente. Critérios essenciais não admitem N/A. Nota 10 acrescenta concorrência, interrupção/recuperação de processo do projeto e carga representativa. N/A somente nesses extras, com justificativa técnica e revisão independente, exibido como N/A.
+- Defina escopo antes dos testes. Prova ausente, falha impeditiva, candidato/ambiente incompatível ou revisão não independente impede aprovação. Não omita plataforma anunciada nem estreite escopo para apagar falha. O avaliador checa consistência: o chamador examina a Evidence real; fixtures não comprovam prontidão do produto.
+- Teste o impacto durante implementação e qualifique a integração pertinente no candidato final. Reutilize preparo válido, repita testes afetados após correção e amplie conforme risco. Não imponha repetição sem motivo nem remova gates aplicáveis de segurança, distribuição, CI, assinatura ou lifecycle para acelerar.
+- Para reuso de grupos rapid após recibo assinado, siga `docs/quality/v49-deploy-cache-controls.md`: prova versionada e revisada por grupo; promova falha como tombstone antes de retry, sem reaproveitar PASS anterior.
+- Recuperação usa o perfil congelado e seu ledger. No padrão configurado `balanced`, mantenha até 3 replans (Sol/high, Sol/high, Astra/high) e 10 execuções totais; cada replan libera até 3 reparações. Continue automaticamente enquanto a recuperação for elegível, sem quarto replan, sem reset em retomada e sem contar testes/tool calls/relógio como tentativas. Preserve contratos `essential` e `persistent`.
+- Falta real de autoridade, acesso ou informação essencial pode bloquear antes do esgotamento; não execute três tentativas inúteis. Bloqueio terminal registra causa, provas, tentativas e condição de retomada. Nunca reduza ACs para encerrar.
+- A janela histórica permanece somente na API legada. Preserve auditorias antigas sem recalcular notas. Acompanhe incidentes e uso real separadamente; incidente impeditivo conhecido bloqueia aceite. Nota técnica, publicação e fechamento canônico são estados distintos.

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

@@ -14,6 +14,7 @@ phases: [execution, verification, evidence]
 
 - Toda Execution tem raiz `zaip-agent-orchestrator`. Interaction read-only sem descendentes conclui após resposta sem executor/finalizador; delegada e delivery aguardam a árvore. Sucesso exige executor elegível ou raiz Task direta com `--direct-authorization` explícita desde captura e turno/modelo observados, além de Evidence e Gui. Gui pode avaliar bloqueio/falha sem executor; `executor_missing` impede completed, não o registro verdadeiro de inconclusão.
 - Cada tentativa de Task tem um orquestrador responsável; ao terminar, concilia `completed`, `blocked`, `failed` ou `cancelled`. Falha de persistência mantém recibo recuperável, nunca sucesso fictício. Terminar executor não termina Task.
+- Retomada pós-publicação exige manutenção e seu último Gui concluídos. O recibo na Change fixa autorização humana, Task/SPEC/Execution, revisões e provas; o consumo revalida publicação, ciclo e proprietário único. O handoff tipado preserva uma raiz ativa por invocação. A Task histórica exige Evidence, revisão aplicável e novo Gui.
 - Se a raiz física já possui a Task, ela é esse responsável e despacha executor/revisor e Gui diretamente, sem Dave adicional. Uma raiz macro delega um orquestrador por Task; não cria outro proprietário para a mesma tentativa.
 - Raiz física tem `run_role: orchestrator`, pai nulo/profundidade zero. Orquestrador de Task delegado preserva `run_role: subagent`, propósito `orchestration` e ancestralidade real; papel de agente não redefine raiz física.
 - Em delivery e interaction delegada, o último filho é exatamente um Sub-Run do `zaip-agent-finalizer` do orquestrador responsável, irmão dos executores, nunca filho deles. Aguarda descendentes; sua barreira impede novos Sub-Runs. Fechamento parental é separado.
@@ -21,7 +22,7 @@ phases: [execution, verification, evidence]
 - 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.
 - Gui read-only não precisa permanecer vivo esperando recibo. O host pode transmitir sua decisão real em `subagent capture --event stop` com `--task-outcome`, `--summary`, `--evidence` e `--changed-files`: a CLI autentica a identidade rica e persiste a decisão imutável antes de Stop/fechamento. Aceita Gui já terminal apenas enquanto o responsável está aberto; responsável fechado aceita somente replay da decisão já existente, não nova aprovação. Ausência de decisão continua fail-closed.
 - Use `completed` somente com gates e Evidences aprovados; `blocked` para dependência externa, autoridade ou informação ausente, gate/teste pendente, falta de Evidence ou outra inconclusão após recuperação. Duração não determina abandono. 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. A exigência de finalizador aplica-se somente a `delivery` e `interaction` com descendente delegado; interaction read-only sem descendentes conclui após a resposta. Nesses fluxos, toda terminalização é aplicada pelo orquestrador após Gui concluir o Sub-Run finalizador.
+- Use `failed` somente para erro técnico ou de integridade impeditivo. Tempo, silêncio, escopo incompleto ou gate pendente não são falha técnica; inconclusões são `blocked`. `cancelled` exige pedido humano explícito. Nos fluxos que exigem Gui, o orquestrador terminaliza após sua conclusão.
 - `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.
 - Run de SPEC/PRD não terminaliza o macro a cada turno/Task: o pai fica `active`, inclusive nos intervalos, até todas as Tasks terminarem; depois passa à Verificação e aos gates parentais.
 - `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/security.md

@@ -5,8 +5,8 @@ priority: critical
 max_context_tokens: 325
 requires:
   - RULE-CORE
-triggers: [segurança, security, "security review", vulnerabilidade, credential, credencial]
-domains: [segurança, security, vulnerabilidade, credential, credencial]
+triggers: [segurança, security, "security review", vulnerabilidade, credential, credencial, login, autenticação, authentication, auth]
+domains: [segurança, security, vulnerabilidade, credential, credencial, login, autenticação, authentication, auth]
 ---
 
 # Segurança e infraestrutura canônicas

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

@@ -20,10 +20,11 @@ phases: [planning, execution, verification, evidence]
 - 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`.
 - `execute` é explícito/idempotente e materializa DAG antes da primeira mutação; `execution` inicia na tentativa mesmo sem diff, comprovado separadamente por `changed_files`/`result`. Pedido avulso de ação materializa/inicia Task, Change, Execution e Run raiz antes da mutação; só fica pronto se o usuário autorizou apenas planejamento/preparo. Refinamento draft é Git-native, incrementa `revision`/`updated_at`; após prepare gere revisão/rework, sem Task extra salvo pedido/resultado independente.
 - Toda mudança de código tem Change antes da implementação; `change.md` registra plano, decisão, Evidence, eval, teste e resultado. Requirements são verdade funcional/técnica; Change aplica delta só após AC/Evidence. Task é trabalho executável, Execution tem snapshot DAG, invocação orquestradora é inicial, delegada é subagente e chamada LLM é evento observável.
-- `RUN-*` identifica invocação física: raiz `orchestrator`, pai nulo/profundidade zero; filha `delegated`, pai/raiz/profundidade positiva, mesmo quando o agente filho orquestra uma Task. Task é a unidade de tentativa; PRD/SPEC coordenam dependências e aceite parental. `MCALL-*` pertence a uma invocação; fechamento e retomada seguem `RULE-RUN-LIFECYCLE-CLOSURE`.
+- `RUN-*` identifica por padrão uma invocação física: raiz `orchestrator`, pai nulo/profundidade zero; filha `delegated`, pai/raiz/profundidade positiva, mesmo quando o agente filho orquestra uma Task. A exceção versionada de `spec execute` após definição terminal+Gui e autorização explícita observada cria um segmento lógico sucessivo da mesma invocação física, com claim e predecessor exatos; nunca dois proprietários ativos, turno inventado ou child sem spawn nativo. Task é a unidade de tentativa; PRD/SPEC coordenam dependências e aceite parental. `MCALL-*` pertence à invocação física; uso sem fronteira observável não é duplicado entre segmentos. Fechamento e retomada seguem `RULE-RUN-LIFECYCLE-CLOSURE`.
 - Reconciliação global só após confirmação humana no popup, nunca abrir dashboard/turno/intervalo; usa `task_complete` exato ou falha órfã após dez minutos, sem inferir cancelamento/sucesso. Risco é `lite|standard|critical`; anexos só por risco/Evidence. Assurance V1: standalone lite uma validação/Evidence e teste só lógica/regressão; standard 2–3 validações, teste e Evidence consolidada; critical 3+ e quality review independente. Mutação, rollback, commit final e Evidence/AC dependem de sinais persistidos; sem sinal preserve gate conservador. SPEC/PRD adicionam matriz parental, 3 validações/Evidences, integração e revisão independente.
 - Novos projetos usam `execution.runtime: codex_native`: a execução fica no host Codex, com subagentes nativos observados também para Task avulsa. Ausente/manual não invoca provider; `managed` e `autonomous` são contratos explícitos de compatibilidade, não o padrão da v4. Commit exige Task real e título: `[CODEX|CLAUDE] [P:XXXX] [S:XXXX] [T:XXXX]`, ou `[Task-first:XXXX]` sem PRD/SPEC. Assunto ≤96, título reduz por palavra, IDs completos em trailers `ZAIP-*`. Somente `.agents/records/**` e `.local/**` dispensam identidade; `.agents` inteira não. Nunca escolher última Task global. Política: `.agents/skills/zaip-skill-task/references/commit-policy.md`.
-- Pedido explícito de deploy/push/publicação GitHub resolve modo antes de qualificação em `$zaip-skill-github-deploy`: política project-owned `.agents/config/deploy-policy.json`, schema 1, `default_mode: auto|commits|release`; auto usa Release + npm via Actions no builder verificado e commits + push no consumidor. “apenas commits/sem release” e “deploy com release/próxima versão/novo release” são overrides do pedido, não preferência permanente; discussão/negação não autoriza publicação e prepare não publica. Escopo padrão `current-work`; só “deploy de tudo” amplia para `all-worktree`. Preserve trabalho/index concorrentes e causalidade de todos os commits publicados. Não peça confirmação rotineira nem aviso extra de pipeline existente; mantenha bloqueios reais de integridade/auth/destruição/expansão. Aplicação segue frontend/backend literal, inclusive main, sem criar beta; só banco mantém beta e promoção humana. Origem local/detached é separada do alvo remoto; use ref recuperável, stash nomeado, rebase padrão ou merge autorizado e refspec SHA explícito. Commits usam `guarded-commits.mjs` e checks por impacto; release usa qualificação pertinente/protected helper, com gates densos do builder só em release salvo impacto direto installer/segurança. Sem suíte completa automática, teto de testes ou regra de relógio da Task; balanced mantém 10 execuções/3 replanos. Consumidor release é GitHub-only, sem npm/chave/política protegida do builder. Release inicia v1.0, minor numérico, major explícito; retry conserva SHA/identidade, SHA já publicado é no-op. Builder vN.N = N.N.0. Notas detalhadas só na Release, fonte/Evidence no range Git completo; chat breve. Produto exige Task atribuída; commits existentes seguem Git-only. Nunca staging amplo, force, segredos, squash, feature alheia ou outro worktree.
+- Pedido explícito de deploy/push/publicação GitHub segue `$zaip-skill-github-deploy` e `.agents/config/deploy-policy.json`. Resolva modo e escopo pelo pedido: `auto` publica Release + npm via Actions somente no builder verificado e faz commits + push no consumidor; `apenas commits` e `deploy com release` são overrides, não preferência permanente. `prepare`, discussão ou negação não publicam. Preserve trabalho, index, causalidade, SHA, integridade e autorização; nunca faça staging amplo, force, publique segredos ou inclua feature alheia. O procedimento de refs, checks, versão, rollback e publicação está na skill canônica; gates densos do pacote ficam na release, com testes por impacto antes dela, sem teto de relógio da Task.
 - Executar uma entrega autoriza seu commit local via `task commit TASK --files PATH[,PATH] --run RUN` antes da prova final; preserve o index alheio e resolva sobreposição de autoria. Git, HEAD e identidade devem estar prontos antes de iniciar. Conversas não criam commits artificiais. `validation execute` usa o Node do host e script relativo versionado/revisado no SHA, sem código inline/loaders; a worktree comprova o candidato, não é sandbox do SO. Só essa prova separa alterações concorrentes da entrega intacta; registros manuais mantêm o gate conservador. Documento externo exige revisão identificada ou exportação versionada. Commit não autoriza push nem substitui revisão/finalizador.
-- Ciclo de release: `.agents/config/release-cycle.json` define a versão `major.minor` corrente e `open|frozen`. PRD/SPEC futura pode permanecer `draft`; `ready`, `execute` e início de Task exigem alvo corrente explícito. Para cortar release, encerre Tasks correntes, reconcilie fronts, congele o ciclo e audite SHA/main/branches/worktrees. Execute os checks locais fixos no SHA candidato; publique apenas `main` e exija CI remoto bem-sucedido para esse mesmo SHA antes da Release. Nunca crie branch remota candidata para commit crítico ou release. Exceção única de coordenação do corte requer `release_task_id` e `release_run_id` explícitos no manifesto frozen, Task crítica em execução com alvo corrente, Run raiz ativa e escopos só de release no `freeze`. Antes de `audit`, finalize essa Task/Run, integre seus records no SHA final e mantenha o checkout limpo; `audit` e `advance` revalidam ambos no SHA exato. Após Release e CI exatas observadas, avance a versão com histórico; falha mantém bloqueio e trabalho recuperável.
+- Ciclo de release: `.agents/config/release-cycle.json` define a versão `major.minor` corrente e `open|frozen`; início exige alvo corrente, futuros ficam draft. Reconcilie frentes, encerre trabalho corrente, congele e audite SHA/main/branches/worktrees. Checks locais precedem push somente de `main`; CI verde no SHA precede Release. Nunca crie branch remota candidata. A exceção da coordenação exige Task crítica e IDs explícitos no frozen. Coordenação simples com escopos só de release conclui Task/Run antes de `audit`. Raiz delivery com `--integrated-task` registra `release_mode: integrated_task` e escopo da configuração; ou coordenação delegada de SPEC com ancestralidade/predecessores validados: nesses modos Task executando e Run ativa atravessam `audit`/`advance`, com records exigidos no SHA limpo e exclusão só da coordenação declarada. Após provas de publicação, complete Evidence/revisão aplicável/Gui e persista fechamento; metadata posterior não muda produto/tag. Avance só com Release/CI exatas e demais Tasks terminais; falha preserva bloqueio recuperável. Detalhes no guia 26, seção de ciclo corrente.
+- Fechamento pós-publicação de uma Task histórica bloqueada usa somente `task recover-post-publication` e `task resume-post-publication` com recibo emitido pela Change da manutenção e prova imutável da publicação. O novo responsável recebe a Execution/SPEC original, revisões exatas e claim exclusivo; se a mesma invocação humana continuar após a manutenção terminada com Gui, o handoff tipado preserva ambas as raízes e seus turnos observados. O ciclo já avançado permanece aberto na versão corrente, sem novo grant, refreeze, reetiquetagem de SHA, produto novo ou segunda publicação. Task histórica não recebe claim de escrita de produto; apenas records e o avanço já comprovado podem integrar o fechamento. Guie-se pelo contrato canônico de recuperação da skill execution.
 - Plano visível: `DEFINE:` contexto/resultado/critério, `PLAN:` ciclo/DAG, `EXECUTE:` mudança, `VERIFY:` valida/Evidence/encerra; não use artefato como fase nem narre comandos internos. Registre decisão humana/IA com origem junto de Change/Execution; derive ledger do Git diff e preserve alterações do usuário. Estado novo fica em `.agents/records/<kind>/<ano>/<mês>`; diário, `.agents/data` e V1 são legado só leitura até migração explícita.

package/templates/.agents/runtime/VERSION

@@ -1 +1 @@
-4.8.0
+5.0.0