@zaip-ai/cli 4.7.0 → 4.9.0

package/templates/.agents/skills/zaip-skill-testing-strategy/SKILL.md

@@ -28,6 +28,21 @@ requires its relevant integrity and regression checks outside release. Consumer
 its own project checks, without builder npm, signing-key or protected-policy requirements.
 Preparation is evidence, never publication authority.
 
+When defining PRD, SPEC and ACs, map each changed behavior to focused code
+checks and dashboard flows actually affected. Integrate modified contracts
+before release, then qualify the full package once on the final candidate
+before publication. Reuse proof only when candidate identity, environment,
+contract and impact still match; code checks do not establish served behavior.
+
+For the 4.9 consolidation, the recovery Task proves changed code with focused
+regressions, independent review and finalization. Operational collection and
+project settings without served proof remain `unverified`. Integrate only
+changed flows and contracts in the integration phase; run full package
+qualification once on the final candidate before publication. Preserve exact
+candidate and applicable critical assurance requirements. See Decisions
+`DEC-AI-2026-10-03-22-18-TAREFA2-ACEITE-CODIGO-XFQFBLLYRN` and
+`DEC-AI-2026-10-03-22-16-QUALIFICACAO-FINAL-UNICA-UPQGEC6JJV`.
+
 Keep failure evidence and recover within the frozen Task profile. Balanced allows 10 executions
 total and 3 replans; individual tests, tool calls and elapsed time are not executions, and a
 continuation does not reset the ledger. Individual test/tool timeouts remain technical limits;

package/templates/.agents/zaip-aios/VERSION

@@ -1 +1 @@
-4.7
+4.9

package/templates/.agents/zaip-aios/guides/11-observabilidade-e-custos.md

@@ -19,6 +19,28 @@ exportações e contas preservam `null`/cobertura, sem somar esse zero visual.
 
 ## Contagem de autonomia e consultas compactas
 
+### Tempo observado, duração ativa e distribuição por dia
+
+O Top 5 SPECs usa a união dos intervalos observados das Runs-raiz vinculadas a
+cada SPEC. Não soma novamente os filhos e não substitui o tempo decorrido pela
+duração ativa atribuída a tokens. O subtítulo é **“Tempo observado por SPEC.”**;
+as explicações de cálculo pertencem ao guia e aos detalhes da métrica.
+SPECs distintas podem compartilhar intervalos: a soma por SPEC não é tempo
+global exclusivo. Nenhuma hora é criada a partir do tempo de processamento do
+print sem timestamps e vínculo observáveis.
+
+No Monitor de Custos, o tempo diário é a união dos intervalos das atividades
+elegíveis, divididos nas viradas de dia de São Paulo, sem duplicar sobreposições.
+Filtros de dimensão são aplicados antes da união; atividades sem duração
+conhecida mantêm cobertura parcial. Uma execução de cerca de 21 horas que cruza
+a meia-noite pode aparecer distribuída em dois dias, sem exigir 21 horas em cada
+linha. Tempo decorrido, duração ativa e soma de invocações são métricas diferentes.
+
+A correção entregue na v4.7 e preservada na v4.8 percorre fonte canônica,
+SQLite, API e UI. Regressões incluem uma Run-raiz de aproximadamente 21 horas,
+seus filhos e a divisão diária. Números e screenshots históricos continuam
+vinculados à execução observada; não são prova automática de um novo candidato.
+
 ### Leitura dos números do Dashboard
 
 O total operacional de Tasks, a distribuição por risco e as contagens temporais

package/templates/.agents/zaip-aios/guides/14-troubleshooting.md

@@ -44,12 +44,12 @@ com o hook ativo e compare o motivo, a sessão e o turno da nova execução.
 | Caso | Comportamento esperado e teste |
 | --- | --- |
 | Stop com `invalid stop hook JSON output` | A saída usa `{}` ou `decision: block` com `reason`, nunca um `hookSpecificOutput` de Stop. Testar todos os caminhos de saída, inclusive erro e continuação. |
-| Resposta útil substituída por aviso de telemetria no Stop | Pendência de transcript, contabilização, lock ou CLI fica no recibo e retorna `{}`, sem criar outro prompt. Somente estado de Task própria comprovado nesta invocação pode pedir uma continuação; `stop_hook_active` impede repetição. |
+| Resposta útil substituída por aviso de telemetria no Stop | Pendência de transcript, contabilização, lock ou CLI fica no recibo e retorna `{}`, sem criar outro prompt. Stop nunca pede continuação automática nem substitui a resposta; o responsável recupera a execução autorizada antes de encerrar, ou informa um bloqueio real com condição de retomada. |
 | Transcript local `\\?\C:\...` | Normalizar o namespace local nas duas camadas de verificação. UNC de rede, devices, links e sessão divergente continuam recusados. |
 | Executor nativo bloqueado por correlação | Conferir sessão do pai + turno do filho, além da sessão nativa do filho. Registrar somente vínculo comprovado; não usar a Task global mais recente. |
 | Busca textual por `AC-...`, `Remove-Item` ou `;` | Diferenciar argumento literal de comando executável. Leituras literais não viram mutação por palavras na pesquisa; redirecionamentos e composição destrutiva continuam protegidos. |
 | Git com separadores | Um separador dentro de argumento entre aspas é texto. Separadores fora das aspas continuam exigindo chamadas Git separadas. |
-| Hook repetido em Usuário e Projeto | O instalador só retira registro global reconhecidamente ZAIP após verificar os hooks canônicos do projeto; preserva terceiros e mantém fallback quando não houver confirmação. |
+| Hook repetido em Usuário e Projeto | O instalador retira registros globais reconhecidamente ZAIP com backup somente depois de verificar os hooks do projeto, preserva hooks de terceiros e mantém os hooks ZAIP em `.codex/config.toml` e `.codex/hooks/` do projeto. Se a verificação local falhar, preserva o hook global legado e informa o bloqueio. Se a migração não reconhecer um hook antigo, revise apenas esse registro; não instale fallback global. |
 
 O vínculo local do executor é conferido contra os escopos e o estado da Task
 canônica. Ele não permite que o filho edite seus próprios bindings ou registros

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

@@ -30,9 +30,12 @@ impacto; instalador/segurança diretamente alterados mantêm seus testes discrim
 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.
+No GitHub, os workflows separados de fonte (`quality.yml`), commits
+(`commit-policy.yml`) e matriz completa (`qualify-cli.yml`) ficam manuais.
+Isso não desativa `pre-main-candidate.yml`: cada push em `main` dispara checks de
+integridade, lint, tipos, identidade dos commits e regressões selecionadas por impacto.
+Os checks locais antecedem o push; o CI do SHA enviado precisa terminar verde
+antes de publicar a Release, sem criar branch remota candidata.
 
 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
@@ -250,6 +253,12 @@ defina uma medição independente com artefatos identificados e falhas observada
 
 O manifesto versionado `.agents/config/release-cycle.json` identifica `current_release` e estado `open`/`frozen` (4.5 e 4.5.0 são normalizados). Drafts de PRD/SPEC futuros são permitidos; ready/execução, novas Tasks e código exigem o release corrente. Depois de conciliar Tasks atuais, prove `main`, branches, worktrees e registros antes do candidato. Branch/worktree isolados são fechados com backup local recuperável; checkout compartilhado com diff de proveniência mista bloqueia. A existência de `main` ou de um teste verde isolado não qualifica a release.
 
-Para congelar, use `node scripts/release-cycle-gate.mjs freeze --repository ROOT --version 4.5`. Se uma Task de coordenação de release precisa ficar em execução durante o corte, ela deve ser crítica, alvo corrente, ter escopos exclusivos de release e Run raiz ativa; declare seus IDs com `--release-task TASK-ID --release-run RUN-ID`. Esses IDs ficam no manifesto frozen. Finalize Task/Run e inclua seus records no commit candidato final antes de `audit`; `audit` e `advance` verificam estado concluído e conteúdo exato desses records no SHA. Uma Task genérica com escopos amplos não recebe exceção.
+Para congelar, use `node scripts/release-cycle-gate.mjs freeze --repository ROOT --version VERSAO`. A exceção da Task de coordenação exige risco crítico, alvo corrente, IDs explícitos `--release-task TASK-ID --release-run RUN-ID` e vínculos canônicos válidos. O manifesto frozen registra esses IDs. Há três contratos distintos:
 
-Com candidato limpo em SHA exato, execute `node scripts/release-cycle-gate.mjs audit --repository ROOT --version 4.5 --sha SHA`. O deploy crítico/de release executa os checks locais fixos nesse SHA, envia apenas `main` ao GitHub e espera o workflow `pre-main-candidate` verde para o push exato antes de publicar a Release. Falha dos checks locais bloqueia o push; falha de CI ou credenciais indisponíveis bloqueia a Release e exige reparo em `main`. Após tag, GitHub Release, main e CI exatos serem observados e todas as Tasks correntes ficarem terminais, `node scripts/release-cycle-gate.mjs advance --repository ROOT --from 4.5 --to 4.6 --sha SHA --ci-run-id ID` registra a transição. Isso não afirma deploy de provedor nem publicação npm; cada superfície tem prova própria. Esta seção descreve o contrato, não declara 4.5 congelada ou publicada.
+- **Coordenação simples:** escopos exclusivos de release e Run raiz; após freeze, conclua Task/Run e integre os records antes de `audit`. `audit` e `advance` exigem estado concluído.
+- **Coordenação integrada:** acrescente `--integrated-task` ao freeze. A Task raiz de delivery fica `executing`, sua Run permanece ativa e os escopos incluem a configuração do ciclo. O manifesto registra `release_mode: integrated_task`; `audit` e `advance` verificam os records da Task no SHA e excluem somente a coordenação declarada do gate de trabalho aberto. Essa modalidade admite ajustes do corte nos escopos autorizados, sem fingir conclusão antes da publicação.
+- **Coordenação delegada de SPEC:** o gate verifica ancestralidade, Execution, SPEC e predecessores concluídos. A Task/Run responsável permanece ativa durante publicação/avanço; os records de coordenação exigidos precisam estar integrados no SHA. A exceção não se estende a outras Tasks ou SPECs abertas.
+
+Nos modos ativos, depois das provas de publicação, registre validações e Evidence, realize revisão quando exigida e obtenha Gui como último filho. O host autorizado persiste a decisão real e o fechamento. Um commit posterior somente de records/metadata pode guardar esse encerramento; ele não requalifica o produto nem move a tag. O contrato executável está em `scripts/release-cycle-coordination.mjs` e `scripts/release-cycle-gate.mjs` no repositório mantenedor.
+
+Com candidato limpo em SHA exato, execute `node scripts/release-cycle-gate.mjs audit --repository ROOT --version VERSAO --sha SHA`. O deploy crítico/de release executa os checks locais nesse SHA, envia apenas `main` ao GitHub e espera `pre-main-candidate.yml` verde para o push exato antes da Release. Falha local bloqueia o push; falha de CI ou credenciais bloqueia a Release e exige reparo autorizado em `main`. Após observar tag, GitHub Release, main e CI exatos, `node scripts/release-cycle-gate.mjs advance --repository ROOT --from VERSAO --to PROXIMA --sha SHA --ci-run-id ID` registra a transição. As outras Tasks correntes devem estar terminais; somente a coordenação ativa validada acima pode permanecer aberta. Cada superfície, inclusive npm ou provedor, tem prova própria. O avanço não conclui automaticamente a Task de coordenação nem permite iniciar trabalho futuro antes da transição auditada.