@zaip-ai/cli 4.8.0 → 5.0.0

package/templates/.agents/skills/zaip-skill-release-qualification/SKILL.md

@@ -5,10 +5,20 @@ description: Qualify a release candidate after deploy mode resolution or an expl
 
 # Qualify a release candidate
 
+For new release evaluations, use the versioned binary `proportional-acceptance-v1` contract in `@zaip-ai/specs` and `docs/quality/production-readiness.md` through `zaip plan acceptance --input <contract.json>`. This command only checks self-reported data and never authorizes publication; authenticated pipeline receipts remain the gate. Map each mandatory outcome to its origin, applicability, sufficient proof, owner and stop condition; bind release proof to the exact candidate. Optional improvements do not block. The historical technical grade remains informative and unchanged. Local qualification uses the declared Windows host; the GitHub Linux smoke is a remote publication check. Do not require local Docker, WSL or another OS by inference.
+
 Use after `$zaip-skill-github-deploy` resolves release mode, or when local preparation/qualification is explicitly requested. Resolve deploy mode first using [the deployment contract](../zaip-skill-github-deploy/references/deployment-workflow.md). Generic consumer deploy under auto and explicit commits mode use scoped checks and `guarded-commits.mjs`; they do not acquire a release gate from this skill.
 
 Preparation, verification and dry-run do not publish. The request's resolved route supplies publication authority separately.
 
+For readiness grades, load `RULE-PRODUCTION-READINESS` and apply
+`technical-essential-v1` from `docs/quality/production-readiness.md`. Grade 9
+requires the six essential criteria; grade 10 adds reviewed concurrency,
+process interruption/recovery and representative load. There is no minimum
+observation period or production-cycle count. This technical assessment never
+waives the distribution gates below, changes a historical audit, or proves
+long-term stability. Keep operational history and publication status separate.
+
 ## Select the distribution surface
 
 - Verified ZAIP builder requires approved `zaip-ai/zaip-aios` origin and both `@zaip-ai/aios` root/`@zaip-ai/cli` public CLI package identities. Apply `zaip-skill-update-version-doc`; root manifest defines candidate `N.N.0`, aligned to GitHub `vN.N`.
@@ -23,8 +33,16 @@ Local builder preparation defaults to signed `essential-v3`: deterministic sourc
 
 These dense distribution checks are release gates. Change validation outside release remains targeted, with installer/security checks selected when directly impacted. Do not automatically run the full suite for generic commits, impose a test-count ceiling or classify a Task by wallclock duration.
 
+For a multi-Task delivery, verify changed code and affected dashboard flows by
+impact during the Tasks, integrate modified contracts, and run full package
+qualification once against the final candidate before publication. Reuse
+prior evidence only when candidate identity, environment and contract remain
+valid; later changes revalidate affected proof.
+
 Use `--profile full` for explicitly requested extended `full-v2` qualification, including full source, browser and XLSX coverage. Changed dashboard/export behavior still needs its relevant tests in the current Change. Rapid impact checks emit no signed release receipt and cannot substitute for release qualification.
 
+Post-receipt rapid group reuse follows `docs/quality/v49-deploy-cache-controls.md`. Only a reviewed Git-versioned group proof may yield a HIT; promote a failed result as the latest tombstone before retry. This never replaces signed candidate qualification.
+
 The framework helper uses an isolated exact-SHA clone, builds once, verifies the exact TGZ and signs a receipt. Cache validity requires matching candidate, policy, gate definitions, runtime, channel, version, trusted key, expiry and artifact digests. Failed/timed-out gates emit no successful receipt; changed candidates or invalid evidence require new qualification.
 
 Resolve builder signing material from the configured stable private directory and run `scripts/local-release-key.mjs preflight` before expensive gates. Inspect actual key/trust/policy configuration before claiming absence. Missing/mismatched required material fails closed; never generate replacement keys, rotate trust or remove signatures during routine deploy.
@@ -43,10 +61,18 @@ Where the legacy path remains configured, retain its separate exact-candidate qu
 
 Recover under the frozen Task autonomy profile: balanced permits 10 executions total and 3 replans. Individual tests/tool calls and elapsed time are not executions, and continuation never resets the ledger.
 
+Use eligible recovery before a terminal block: the three balanced replans use
+Sol/high, Sol/high and Astra/high and each releases up to three repairs. A real
+authority/access/capability blocker may stop earlier; do not manufacture three
+attempts against an unchanged unavailable prerequisite. Keep the exhausted
+ledger, actual findings and resume condition; never lower acceptance criteria.
+
 The framework release cut uses `node scripts/release-cycle-gate.mjs freeze --repository ROOT --version N.N --release-task TASK-ID --release-run RUN-ID`. The exceptional coordinator is the critical, release-only Task at the end of the owner SPEC's exact Execution DAG. Every predecessor Task must be completed; only the release Task may still execute. Its delegated Task orchestrator Run must be active under that SPEC's active macro Run. `audit` and `advance` recheck predecessor status and authenticate the same Task, Run, SPEC, Execution and committed candidate records; only the release Task and owner SPEC are exempt from the open-work gate. Unrelated work remains blocked. The candidate commits the frozen cycle before qualification. The deploy helper checks its exact SHA, pushes only `main`, and requires successful CI on that SHA before publication.
 
 For an authorized Task-first request that combines a product fix and its release in one direct Task root, use the explicit `--integrated-task` freeze option with that Task and active root Run. The Task must be critical, target the current release, own the release-cycle config scope and have a delivery Execution bound to its Change. `audit` and `advance` authenticate its committed Task and Run start, while all other current-release work, secondary worktrees and remote branches still block. This route avoids creating a second root Run or asking the user for a new turn solely to publish already authorized work. Do not use it for a delegated SPEC release Task or as a general waiver for release checks.
 
+For an authorized SPEC whose final critical Task combines implementation and publication, use the separate explicit `--integrated-spec-task` option with its delegated delivery Run. It requires the exact active macro Run, SPEC, Change and delivery Execution, a unique terminal Task in the committed DAG, all predecessors completed, the current target release and the literal `.agents/config/release-cycle.json` write scope. The persisted `integrated_spec_task` mode is rechecked at audit and advance; unknown modes fail closed. It cannot be combined with `--integrated-task`, which remains exclusive to direct Task roots. Broad product scopes alone never grant this mode. Clean candidate, committed coordinator records, unrelated open-work exclusion, exact-SHA CI, signed artifact and npm gates remain mandatory.
+
 For the one-time 4.5→4.6 recovery, `adopt-published` requires the published 4.5 tag to be an ancestor of remote `main`, remote `main` to be an ancestor of clean local `main`, and observed stable GitHub Release/npm integrity. Pass the exact owner `--owner-spec`, `--owner-execution`, `--owner-run`, planned `--release-task` and active delegated Task orchestrator `--actor-run`. That actor must own the release Task's unique direct predecessor; all earlier DAG Tasks must be completed. Only the actor Task, planned release Task and owner SPEC are exempt from the open-work gate. After review/Evidence and a clean metadata checkpoint, perform adoption while that predecessor Task and its actor Run are still active. Then use `spec retarget-release SPEC --from 4.5 --to 4.6 --run DELEGATED_TASK_RUN` with the same actor Run. Close the predecessor Task through Gui only after retarget; start the release Task afterward. The revision records adoption SHA and actor Run, and the release Task's missing target resolves through its owner SPEC. Do not edit records directly to retarget.
 
 After exact Release, npm and candidate CI are observed, `advance --from N.N --to NEXT --sha CANDIDATE --ci-run-id ID` opens the next cycle while the coordinator remains active. Bind Task/SPEC Evidence to the immutable published candidate before Gui, then close Task and parent SPEC. Make one reviewed metadata-only closure commit; push that exact local main SHA through `scripts/local-release-deploy.mjs push-closure` with published SHA, expected remote SHA and the exact metadata path inventory. The tag remains on the published candidate. Confirm CI on the new main SHA; local closure alone is not complete publication. This contract does not prove provider deployment.

package/templates/.agents/skills/zaip-skill-release-qualification/references/local-preparation.md

@@ -6,7 +6,7 @@ Preparation does not authorize publication. Use guarded delivery only for the re
 
 The project-owned `.agents/config/deploy-policy.json` (schema version 1, `default_mode: auto|commits|release`) is separate from the builder's signed qualification policy below. Installing skills in a consumer never grants builder capability or requires builder keys/protected settings.
 Store keys, trust stores, receipts and artifacts outside the repository. Commit and synchronize first;
-every gate is bound to the resulting clean SHA. Repair changes require a new candidate.
+every gate is bound to the resulting clean SHA. Before expensive gates, validate the active coordinator route: release-only, direct `--integrated-task`, or final SPEC `--integrated-spec-task` as defined in the canonical qualification skill. Repair changes require a new candidate.
 Qualification uses an independent local Git clone at that exact SHA, with copied
 objects and complete commit history, not a worktree sharing the caller's registry.
 This prevents dashboard source discovery from importing the main checkout or other
@@ -15,7 +15,7 @@ unchanged. Cleanup retries transient Windows locks and preserves the original ga
 error if cleanup also fails. A cleanup failure never produces a success receipt.
 
 When the ZAIP Codex PreToolUse hook is enabled, run release preparation, verification and
-guarded delivery as separate literal commands. Its external-path exception is limited to
+guarded delivery as separate literal commands. In repository-restricted profiles, its external-path exception is limited to
 the reviewed release helpers, the declared SHA and version, the matching candidate
 directory under `~/.codex/release-candidates/zaip-aios/`, and key material under
 `~/.codex/release-keys/zaip-aios/<key-id>/`. It does not permit arbitrary home
@@ -24,10 +24,19 @@ unrelated path or compound command is an intentional safety decision, not a fail
 release gate. Persistent repository edits additionally require a current Task Run with
 the exact Codex thread and turn correlation.
 
+The configured `zaip-aios-full-access` profile also permits ordinary external
+read/write/execute, working-directory, and network access. The restrictions above
+describe the narrow exception for repository-restricted profiles, not a blanket
+denial of configured full access. Neither profile bypasses secret protection,
+destructive-operation controls, lifecycle authority, stricter child permissions,
+or the ban on computer power/session actions. Release helpers still verify
+their exact repository, candidate, signing material, receipt, and authorization.
+
 For native `exec_command`, the hook validates both the chat's `cwd` and the command's
 explicit absolute `workdir`. A registered worktree may be the execution root even
 when the chat remains in the primary checkout. Unregistered roots, links, relative
-overrides and missing exact worktree Run authority remain blocked; a primary
+overrides remain subject to the configured access profile. Missing exact worktree
+Run authority for governed product mutations remains blocked; a primary
 checkout's Task is never a global fallback for mutations in another checkout.
 
 Some hosts present these commands as `Bash` without exposing a workdir override.
@@ -35,14 +44,15 @@ In that case, invoke the literal reviewed helper from the chat checkout and pass
 the registered worktree in `--repository`. Only the helper may target that explicit
 root, after physical-root, Git registration and common-directory verification;
 its own preflight checks the exact clean SHA before any gate. This is not an
-exception for arbitrary commands or filesystem access.
+exception for arbitrary commands or filesystem access in a restricted profile.
 
 ## Verified builder signing material
 
 The following key and protected-policy requirements apply only to the verified ZAIP builder, not ordinary consumer GitHub releases.
 
 The signing key ID is the trusted identity, not a filename. Resolve it with
-`gh variable get ZAIP_LOCAL_RELEASE_TRUSTED_KEY_ID --repo zaip-ai/zaip-aios`.
+`gh variable get ZAIP_LOCAL_RELEASE_TRUSTED_KEY_ID` from the verified builder
+checkout after checking its configured origin.
 By default, the private key lives at
 `~/.codex/release-keys/zaip-aios/<key-id>/release-private.pem` and its local
 trust store at `~/.codex/release-keys/zaip-aios/<key-id>/trust/` on the current
@@ -121,6 +131,9 @@ doctor/SQLite/API smoke. It does not run browser navigation across every dashboa
 exports. `--profile full` explicitly selects `full-v2`, which also runs the full source suite,
 browser and XLSX qualification. Dense distribution checks belong to builder release; a normal
 Change runs targeted validation, including installer/security regressions when directly impacted.
+The essential source-size gate reports 401–800-line debt and stale warning ceilings as visible
+warnings, while files above 800 lines and provenance or baseline tampering remain blocking.
+The explicit `full-v2` profile keeps the strict source-size debt gate.
 Individual process/test timeouts remain technical limits, not a Task wallclock or abandonment rule.
 Retain failed-gate evidence and cleanup outcomes; a failed/timed-out gate emits no success receipt.
 Receipts bind the selected profile and fixed gate list, so stale receipts require requalification.
@@ -131,9 +144,12 @@ critical baseline and affected consumers without a test-count cap. An unmapped i
 an evidenced broader selection; it does not make every generic commits deploy run the full suite.
 Rapid checks never prove full release qualification. Observe pending commands through the host's
 wait mechanism instead of treating elapsed Task time as a result.
-Retain Windows/Linux Node 22.16.0 and 24.x matrix outcomes against the same exact TGZ,
-recording the actual Node patch version and digest. A configured matrix is not proof that
-its jobs ran; unavailable runtime execution remains unverified, never passed.
+Qualify the exact TGZ on the authorized local host and record its actual OS, Node patch
+version and digest. The GitHub publisher performs the bounded Linux smoke on that same
+digest before npm publication. A configured matrix is not proof that its jobs ran;
+unavailable runtime execution remains unverified, never passed. The Windows/Linux
+Node 22.16.0 and 24.x matrix remains historical v4.6 evidence, not a default gate
+for each later release.
 Reuse an existing output directory only with its complete valid signed candidate; an invalid cache
 is refused. Choose a new output path after repair instead of deleting or overwriting evidence.
 
@@ -167,8 +183,11 @@ node scripts/local-release-preparation.mjs stage-inputs --sha <40-character-sha>
 
 `stage-inputs` accepts no source, receipt, output, home, key or policy path flags. It
 derives the candidate directory, verifies clean `main`, canonical origin, the signed
-receipt, v4.6 essential profile, trusted `maintainer-v4` key and policy digest, the
-exact release inventory, and a direct human request resolved as builder Release 4.6.
+receipt, the selected essential profile, trusted `maintainer-v4` key and policy digest,
+the exact release inventory, and a direct human request resolved as that builder Release.
+Explicit major transitions such as `4.9 → 5.0` are supported. The inventory must
+start at the highest canonical stable ancestor tag below the requested version;
+prerelease, unmerged, future and stale-range tags cannot substitute for it.
 It installs `deploy-request.txt`, `release-notes.md`, `release-inventory.json` and
 `deploy-contract.json` inside that candidate directory with complete-byte readback,
 idempotent retry and conflict rejection. The protected release helper reads the
@@ -185,11 +204,27 @@ node scripts/local-release-deploy.mjs --repository <absolute-repository> --expec
 `--dry-run` prepares and verifies without sending. The live command verifies again around
 delivery, sends the exact SHA, verifies the remote, creates a draft GitHub Release, uploads all
 four assets and publishes the release. Existing incompatible tags/assets fail without overwrite.
-The helper never invokes local npm publication.
+The helper never invokes local npm publication. Durable `release-stage-*.json`
+observations bind SHA/version/receipt digest and never replace fresh verification.
+A retry recognizes an exact remote push, uploads only absent matching assets and
+does not republish an already public matching Release. Conflicts fail closed.
+The four assets must be regular files in the real candidate directory. The helper
+observes npm version, latest and exact TGZ SRI with bounded propagation retries.
 Notes and inventory must satisfy [the release notes contract](../../zaip-skill-github-deploy/references/release-notes.md).
 For the first release, replace `--from` with explicit `--initial`. The helper validates the notes
 against the Git range before push and compares the draft and published bodies with those notes.
 
+After release-cycle advancement and formal closure, the single metadata-only commit uses:
+
+```text
+node scripts/local-release-deploy.mjs push-closure --repository ROOT --expected-repository zaip-ai/zaip-aios --branch main --version N.N --published-sha CANDIDATE --closure-sha CLOSURE --expected-remote-sha CANDIDATE --metadata-paths-file REVIEWED_JSON --receipt RECEIPT --tarball TGZ --policy POLICY --trust-store TRUST --notes-file NOTES --output-dir CANDIDATE_DIR
+```
+
+This rechecks the valid signed receipt against the immutable published Git tree,
+exact Release assets/body/latest, registry SRI/latest, recorded published CI and
+reviewed metadata diff. Remote main may already equal CLOSURE after interruption;
+retry then observes its CI without another push. Receipt expiry remains enforced.
+
 ## Installed consumer: independent GitHub release
 
 Auto mode defaults to commits plus push in a consumer. It needs scoped project checks and

package/templates/.agents/skills/zaip-skill-spec/SKILL.md

@@ -5,6 +5,13 @@ description: Create, refine, prepare, or analyze a technical ZAIP SPEC on explic
 
 # Trabalhar com SPECs
 
+Antes de promover uma SPEC ou sua DAG nova, avalie suficiência pelo contrato binário `proportional-acceptance-v1` de `@zaip-ai/specs` (`docs/quality/production-readiness.md`) via `zaip plan build --acceptance <contrato.json>` e valide o plano embutido. Cada AC obrigatório registra origem, aplicabilidade, resultado observável, prova suficiente, responsável e parada; toda dependência da DAG tem resultado verificável. Critério local fora do ambiente declarado falha no preparo. Pendência opcional não bloqueia; finding novo ou candidato alterado justifica outra rodada. Snapshots antigos só mudam por migração explícita versionada e atribuída.
+
+Mapeie cada mudança da DAG a testes de código e aos fluxos de dashboard
+afetados. Integre contratos modificados antes do release; qualifique o pacote
+completo uma vez no candidato final antes de publicar, revalidando provas
+atingidas por correções posteriores.
+
 SPEC é opcional para trabalho técnico amplo; Task-first continua válida para uma mudança pontual. A SPEC permanece em Planejamento com `status: draft` durante criação, revisão, refinamento e `prepare`.
 
 ## Limite de autoridade
@@ -25,6 +32,8 @@ SPEC é opcional para trabalho técnico amplo; Task-first continua válida para
 6. A criação, o rework e o prepare da SPEC exigem uma Run delegada e ativa do Rafa (`zaip-agent-builder`), com propósito `execution`, sob o orquestrador do turno raiz atual; passe essa Run em `--run`, ou em `--spec-run` quando a SPEC for materializada por `prd create --plan`. Não aceite replay histórico nem a Run da Bia como autoria técnica. Não crie registros Task, Change ou Execution antes de `ready|execute`; vincule sempre a Run realmente observada e o `creation_run_id` à SPEC e agregue telemetria somente quando observada ou reconciliada.
 7. Depois de materialização, use rework rastreável e preserve snapshots/tentativas.
 
+Para o defeito específico de versão de `pnpm` em snapshot já materializado, a [revisão controlada](../zaip-skill-execution/references/controlled-release-recovery.md) altera somente a versão comprovada em `package.json` e sua descrição, com Decision humana exata, revisão esperada e histórico de implementação. Não edite o frontmatter diretamente.
+
 ## Prepare
 
 1. Valide referências, cobertura de AC, IDs, ciclos, conflitos de paralelismo, comandos de verificação e o snapshot de stack contra a configuração atual do projeto.

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.8
+5.0

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,7 +44,7 @@ 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. |

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
@@ -61,6 +64,18 @@ inválida ou integridade diferente impedem publicar. Após uma publicação
 autorizada, a confirmação do mesmo tarball usa retry finito de propagação.
 Esse controle não publica automaticamente quando a qualificação local passa.
 
+Na v5.0, o publisher mantém checkpoints por SHA, versão e hash do recibo para
+prepare/push/CI/assets/Release/npm/closure. A retomada sempre consulta o estado
+remoto e revalida a assinatura: efeitos já confirmados não são reenviados.
+Assets são quatro arquivos regulares no diretório real do candidato, com digest
+exato no GitHub; links simbólicos e conflitos bloqueiam. A transição explícita
+`4.9 → 5.0` usa a maior tag estável canônica ancestral como início do inventário.
+O fechamento exige recibo/TGZ/política/trust/notas/diretório, confere a árvore Git
+publicada e SRI/latest npm e aceita somente um commit revisado de metadados.
+Se `main` já estiver nesse fechamento, apenas observa seu CI. A validade temporal
+do recibo permanece obrigatória. Consulte a referência canônica
+`zaip-skill-release-qualification/references/local-preparation.md` para os comandos.
+
 | Objetivo | Comando da raiz e alcance |
 | --- | --- |
 | Preparar artefatos | `corepack pnpm release:artifacts` compila e gera runtime/template. Não publica nem qualifica por si só. |
@@ -246,10 +261,42 @@ 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.
 
+## Evolução de confiabilidade e documentação
+
+A [matriz de evolução](https://github.com/zaip-ai/zaip-aios/blob/main/docs/quality/v50-documentacao-editorial.md)
+vincula as dez frentes aos seus comandos, provas, rollback e limitações.
+READMEs PT/EN descrevem o mesmo contrato: `essential-v3` por padrão,
+`full-v2` somente quando selecionado, CI na `main` exata antes da Release,
+smoke Linux do TGZ assinado antes do npm e confirmação da integridade publicada.
+Preparar e validar localmente não comprovam publicação ou ativação dos hooks.
+
+Uma Task explicitamente editorial `lite` aceita README literal ou Markdown
+em escopo documental estreito, como `docs/quality/**`; `docs/**` amplo,
+código, configuração e controles de agente não recebem a exceção. A dispensa
+da Decision de seis etapas conserva candidato, check, Evidence, revisão e Gui.
+Alterar esse mecanismo continua sendo trabalho crítico quando houver sinal de
+segurança. `draft` persiste blueprints; `ready` materializa Tasks `planned`;
+`execute` inicia o menor grão autorizado, sem inferir conclusão dos blueprints.
+
+O resolver reconhece o pedido direto de retomar a SPEC até finalizar as Tasks
+e publicar a versão explícita. Citação, negação, pergunta ou condição de
+aprovação não concedem publicação. O override vale somente para o pedido.
+Manutenção usa o mesmo `maintenance.mjs` da skill de entrada com `enter|exit`;
+tracking fica ligado e a saída exige observação nativa. `full-access` conserva
+proteções de segredos, destruição, lifecycle, filhos restritos e energia do PC.
+
 ## Ciclo corrente, limpeza e CI da main antes da Release
 
 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:
+
+- **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.
 
-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.
+Uma Task final de SPEC que combine implementação e publicação usa o modo explícito `--integrated-spec-task`, descrito na skill canônica de qualificação. Verifique essa elegibilidade antes dos gates caros; mantenha os predecessores concluídos e as provas válidas. Consulte [o diagnóstico v5.0](https://github.com/zaip-ai/zaip-aios/blob/main/docs/quality/v50-retrabalho-e-publicacao.md).