@zaip-ai/cli 2.6.0 → 3.1.0

package/templates/.agents/zaip-aios/guides/26-qualidade-e-release.md

@@ -17,18 +17,32 @@ O ratchet usa o maior valor entre o floor atual e o baseline versionado. Uma med
 
 ## Gates agregados e diagnósticos
 
-O gate de PR é o job único `github-equivalent` de
-`.github/workflows/quality.yml`, em `ubuntu-latest`: instala dependências,
-instala Chromium e executa `validate:github:prepared`, auditoria de produção,
-cobertura, release E2E e dashboard E2E. Esses subchecks são etapas desse gate
-agregado; não são uma receita adicional que, isoladamente, aprove uma release.
-
-O workflow `.github/workflows/publish-cli.yml` é separado: seu job `verify`
-usa matriz real Node 22 e 24 para `pnpm verify`; a auditoria e o artefato de
-release ocorrem somente na linha Node 24, ambas em Ubuntu. Publicação e smoke
-só seguem após a matriz aprovada. Esse `verify` roda dentro de `public-cli`,
-não é o script homônimo da raiz. Os comandos abaixo são do checkout mantenedor;
-não presuma que existam no `package.json` do projeto consumidor.
+A preparação local do mantenedor executa a bateria completa `full-v2`, incluindo
+`pnpm qualify:full`, cobertura com ratchet, contratos, clean-room, Dashboard E2E
+e identidade do consumidor. Somente o SHA limpo aprovado recebe recibo assinado,
+manifesto, SBOM e TGZ. Falha ou dados incompletos não produzem aprovação.
+
+No GitHub, checks de fonte (`quality.yml`), commits (`commit-policy.yml`) e matriz
+completa (`qualify-cli.yml`) ficam manuais. As mesmas validações principais são
+executadas localmente pelo Codex/scripts antes da release.
+
+Após qualificação local assinada e cadastro autorizado da chave pública/política,
+o mantenedor ativa `ZAIP_LOCAL_RELEASE_ENABLED=true`. O deploy publica os quatro
+artefatos assinados no GitHub; `publish-cli.yml` confere assinatura, versão e SHA,
+executa um único smoke automático (instalação + doctor do runtime) sem credenciais
+de escrita e só então publica o mesmo TGZ no npm. A integridade no registry continua
+obrigatória; outra instalação remota é opcional por `extended_verification=true`
+no despacho manual. Não há teste de acesso ao rascunho privado.
+
+Chave privada nunca sai da máquina. Sem flag, o caminho legado exige qualificação
+remota manual; não é fallback para assinatura ausente. Uma Release GitHub publicada
+não prova publicação npm: acompanhe o job até a confirmação do registry. Os comandos
+abaixo são do mantenedor; não presuma que existam no projeto consumidor.
+
+Dados históricos incompletos do Dashboard conservam `null`/indisponível e sua
+cobertura conhecida. Não se exige reconstruir fatos que nunca foram capturados.
+Isso não dispensa paridade entre records, API e UI para o mesmo conjunto conhecido,
+testes dos dados novos, nem fechamento canônico de Tasks sem sucesso inventado.
 
 A publicação compara `dist.integrity` do registro com o SHA-512 do tarball
 verificado. Uma versão já existente só é aceita quando o conteúdo é idêntico.
@@ -63,7 +77,9 @@ contra o manifest do próprio pacote, incluindo a Rule Astra, e verifica que
 os READMEs da raiz do consumidor sobrevivem à instalação e à reinstalação.
 O relatório registra a quantidade de arquivos documentais conferidos.
 
-Novas instalações continuam em `manual`; a documentação não deve confundir
+Novos templates mantêm seleção do principal em `manual`, runtime `managed`
+para PRD/SPEC e preset Equilibrado; avulsas preferem execução direta.
+A documentação não deve confundir
 perfil de instalação com modelo/effort nem apresentar estimativas de tokens
 como economia financeira medida. O escopo automático e os limites Astra
 devem coincidir com o [guia 23](23-orquestracao-de-modelos.md).
@@ -174,3 +190,46 @@ Testes passando comprovam validação técnica. Maturidade formal máxima exige
 - CI terminal correspondente ao commit publicado.
 
 Ausência de uma dessas provas permanece explícita; não é convertida em sucesso.
+
+## Linha v3: implementação, qualificação e publicação
+
+A v3.0 foi publicada como `@zaip-ai/cli@3.0.0`, no commit
+`ffc6c13867ec703211b7bba90c26b10a105c19fb`. Presets, diário durável por Task,
+replanejamento governado, relay da decisão Gui e configuração no Dashboard estão
+implementados. A publicação possui qualificação local do candidato; não equivale
+a certificar todo workload de produção nem a concluir o PRD histórico.
+
+Consulte a [matriz de implementação e prova](https://github.com/zaip-ai/zaip-aios/blob/main/docs/quality/v3-delivery-status.md).
+A versão atual vem dos manifests e de `.agents/zaip-aios/VERSION`; cada manutenção
+gera novo candidato e recibo, sem reutilizar aprovação ou mover a tag anterior.
+
+Para qualificar uma nova candidata dessa linha, preserve um SHA único e comprove:
+
+- Essencial 4/1 sem Astra automático, Equilibrado 10/3 e Persistente sem teto;
+- reservas antes do provider, replay/restart sem reset e resultado desconhecido
+  sem despacho duplicado;
+- plano inválido sem reparação gratuita, ausência de abandono por tempo e
+  preservação dos ACs;
+- API/UI/YAML dos três presets com reload, além de isolamento e modelos efetivos;
+- decisão real imutável antes do Stop, fechamento pendente sem repetir agentes
+  e casos negativos de Evidence/identidade/candidato;
+- instalação/reinstalação/rollback pelo TGZ exato, preservação do consumidor e
+  matriz de upgrade com origem publicada ou build de tag identificada;
+- performance real e comparação equivalente, sem transformar redução de payload
+  em economia financeira.
+
+A qualificação local dessa manutenção foi delimitada a Windows por decisão
+humana. Linux/macOS/Docker não executados não contam como aprovados; isso não
+altera silenciosamente matrizes de CI publicadas. Relatórios de candidatos
+anteriores, testes simulados de modelos e evidência local não certificam
+o candidato final nem seu uso em produção.
+
+O [guia 19](19-assurance-e-autonomia.md) registra as fronteiras atuais: controle
+preventivo de cotas/modelos somente no despacho gerenciado; avulsa direta exige
+autorização explícita desde a captura e identidade observada, sem executor
+cerimonial. Revisão aplicável, Evidence e Gui continuam obrigatórios.
+
+O benchmark comparativo histórico T08 permanece sem aprovação. Otimizações
+com testes de correção e uma release publicada não comprovam economia ou SLA.
+Não repita automaticamente a matriz histórica falha: preserve o diagnóstico e
+defina uma medição independente com artefatos identificados e falhas observadas.

package/templates/.agents/zaip-aios/guides/27-telemetria-git-native.md

@@ -170,3 +170,21 @@ node scripts/validate-text-encoding.mjs
 
 Os comandos acima são gates de desenvolvimento. A confirmação operacional continua sendo a
 combinação de hashes válidos, cobertura explícita e leitura do período real no Dashboard.
+
+## Caminho atual de consulta e limites de performance
+
+A descrição manifest-first acima inclui o caminho de compatibilidade.
+No runtime SQLite, a primeira dobra do Monitor usa agregados compactos;
+detalhes de Runs ficam em endpoints paginados explícitos. Queries preservam
+os mesmos filtros, moeda e população, sem reabrir streams canônicos de Run
+indiscriminadamente. O SQLite é derivado, não substitui Git-native.
+
+O spool e o diário de autonomia são diferentes. O primeiro guarda uso
+sanitizado; o segundo reserva tentativas/replanejamentos antes do provider.
+Não derive quota de tokens ou duração nem apague um deles para renovar consumo.
+
+Existência de índice/cache não comprova leitura O(1) por invocação. Escritores
+legados, substituição, truncamento, exclusão e concorrência exigem verificações
+de integridade e fallback completos. Redução mensurada, baseline equivalente,
+cobertura e carga concorrente precisam constar do benchmark; não declarar a
+matriz de performance aprovada apenas porque consultas focadas passaram.

package/templates/.agents/zaip-aios/guides/28-lifecycle-completo.md

@@ -64,7 +64,7 @@ Quando o host expõe Calls, a Run/Sub-Run agrega quantidade conhecida, terminais
 
 ### Barreira do finalizador
 
-Cada Execution usa uma Run raiz do `zaip-agent-orchestrator`. Um executor é escolhido pelas capacidades e pela elegibilidade declarada no catálogo: `zaip-agent-builder` e `zaip-agent-task-executor` podem executar delivery, e `zaip-agent-analyst` pode executar interaction. Revisão, auditoria e integração podem participar. Depois que todos os demais descendentes terminarem, o orquestrador deve chamar `zaip-agent-finalizer` como último Sub-Run, com propósito `finalization`.
+Cada tentativa de Task tem um orquestrador responsável. Uma raiz física Task-scoped é esse responsável; uma raiz macro delega um por Task, preservando ancestry real. Um executor é escolhido pelas capacidades e pela elegibilidade declarada no catálogo: `zaip-agent-builder` e `zaip-agent-task-executor` podem executar delivery, e `zaip-agent-analyst` pode executar interaction. Revisão, auditoria e integração podem participar. Depois que todos os demais descendentes terminarem, o orquestrador deve chamar `zaip-agent-finalizer` como último Sub-Run, com propósito `finalization`, como filho direto do responsável da Task, não do executor.
 
 O finalizador é read-only: avalia resultados, gates e Evidence e retorna somente o status terminal proposto, motivo e referências. A CLI aplica deterministicamente a transição. O início do finalizador cria uma barreira: ele não pode começar com descendentes ativos e nenhum filho novo pode iniciar depois dele. Finalizador ausente, incompleto ou falho resulta em `blocked`, nunca em Task presa em `executing` ou `verifying`.
 
@@ -147,3 +147,20 @@ Cobertura é independente por métrica. Tokens, Calls, custo, duração e latên
 diferentes na mesma invocação. `known_sum`, `unknown_count` e `coverage_ratio` precisam viajar
 juntos; `null` nunca é normalizado para zero. Detalhes de armazenamento, integridade, fallback e
 recuperação estão em [Telemetria Git-native do Codex](27-telemetria-git-native.md).
+
+## Recuperação e autonomia v1
+
+O [guia 16](16-lifecycle-e-reconciliacao.md) detalha a decisão imutável do Gui
+e o relay antes do Stop: não exija que um finalizador read-only permaneça
+ativo esperando recibos. Ele é último filho direto do responsável da Task,
+não de cada executor. Um orquestrador delegado conserva a ancestry real.
+
+Os [presets](19-assurance-e-autonomia.md) pertencem à Task estável:
+Essencial 4/1, Equilibrado 10/3, Persistente ilimitado. Reinício e `resume`
+não renovam quota; `attempt_count` do lifecycle não substitui o diário
+de reservas do runtime. Ausência de Evidence é bloqueio, erro técnico
+comprovado é falha e tempo não determina abandono.
+
+Fechamento técnico, estado canônico da Task, projeções e entrega parental
+precisam ser confirmados separadamente. A preferência avulsa direta não remove
+o gate de executor capturado ainda exigido pelo contrato atual.