@zaip-ai/cli 2.2.0 → 3.0.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,35 @@ 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.
+
+## Novidades da v3 e qualificação pendente
+
+As fontes em preparação incluem presets, diário durável por Task, replanejamento
+governado, relay de decisão Gui e configuração no Dashboard. Os manifests
+continuam em 2.6.0; este guia não promove versão nem certifica produção.
+
+Para qualificar essas novidades, preserve um candidato ú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 duas fronteiras ainda
+importantes: controle preventivo só no despacho gerenciado e compatibilidade
+do trabalho avulso direto com a barreira de executor capturado. Uma revisão
+documental não resolve esses limites por declaração.

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.

package/templates/scripts/validate-cloud-hostinger-contract.mjs

@@ -10,6 +10,7 @@ const files = {
   terraform: "infra/terraform/main.tf",
   variables: "infra/terraform/variables.tf",
   skill: ".agents/skills/zaip-skill-hostinger-cloudflare-terraform/SKILL.md",
+  aws: ".agents/skills/zaip-skill-hostinger-cloudflare-terraform/references/aws-cli-terraform.md",
   readiness: "infra/terraform/deployment-inputs.example.yaml",
 };
 const source = Object.fromEntries(
@@ -75,6 +76,39 @@ const checks = [
     source.skill.includes("read-after-write") && source.skill.includes("prova estática/local"),
     "skill must require truthful live validation",
   ],
+  [
+    source.aws.includes("aws configure sso") &&
+      source.aws.includes("OIDC") &&
+      source.aws.includes("aws sts get-caller-identity"),
+    "AWS contract must support bounded authentication and identity verification",
+  ],
+  [
+    source.aws.includes("source_profile") &&
+      source.aws.includes("backend") &&
+      source.aws.includes("provider"),
+    "AWS contract must separate backend and provider authentication",
+  ],
+  [
+    source.aws.includes("use_lockfile = true") &&
+      source.aws.includes("Terraform >= 1.10") &&
+      source.aws.includes("lockfile=readonly") &&
+      source.aws.includes("apply"),
+    "AWS contract must require modern S3 locking and authorized saved-plan apply",
+  ],
+  [
+    source.aws.includes("Bootstrap AWS de ambiente zero") &&
+      source.aws.includes("não cria o bucket S3") &&
+      source.aws.includes("versionamento") &&
+      source.aws.includes("recuperação") &&
+      source.aws.includes("criptografia"),
+    "AWS contract must define separate zero-environment S3 bootstrap and recovery",
+  ],
+  [
+    source.skill.includes("**AWS:**") &&
+      source.skill.includes("Não leia, exija ou derive") &&
+      source.skill.includes("**Cloudflare/Hostinger:**"),
+    "skill must keep AWS inputs separate from the Cloudflare/Hostinger runner flow",
+  ],
   [
     source.readiness.includes("deployment_readiness: failed") &&
       source.readiness.includes("image_digests: {}"),