@zaip-ai/cli 4.5.0 → 4.7.0

package/templates/.agents/runtime/checksums.sha256

@@ -1,11 +1,11 @@
 b146bd0c7c60b1ab43c4f71e0b1d2262c6df6da6f7053a0425f834ccb77a6b48  LICENSE
 bc02cba77e8d51e5c580f43668863dc868eda66f1ff663bfaa49fcf3ca16320e  THIRD_PARTY_NOTICES.md
-195790f73af85f22cd306965e5fa5f5a73399c51b74065aa3ee1d4d571d6eef4  VERSION
-5bc51c65313ac4eb5d6fbef2717901a883b057c7897a7897bcdca7c3485e9c59  bin/zaip.mjs
-2a76e763486caa19ce461df30020850f2bfcae60e672eb2a662af9c68bcf8562  manifest.json
+ef3193df6d68bc7ef70fda62056eba15f0ef668fc9c21b487ae7fd56a562bfd6  VERSION
+8732989380e59d4890a8ccd7a27e6b974e28af5bfe5d65c9ddd21bbdbd4f485b  bin/zaip.mjs
+c6f46b86e46b2c14fcdc49ea2b8b1cf1f816f25c22bc9246f8b4a85c9a871120  manifest.json
 7f89219d7c567c82a51679ad136d84364bded7ac659492537e125d33b1d58a7a  migrations/001-layout-v1.json
 5f8c48b286d0b44d8fbb57a9a5d009a8a500439aa3148d750b8f193f72995c9f  migrations/002-layout-v2.json
 33c98d5dc506bba4b8b3ca612706d9eb05ef13d9e03c33a4f9e65ca7804be9d1  pnpm-lock.sha256
-5654931854d207c010531ca77c518c228727b2527cb001531b20b8474cd41b1c  provenance.json
-4b0e237c0d357af52e9baea8ad3abc8b6a6b4d7ba444dbcfd94b97523349aac7  sbom.cdx.json
+3c589ae6cf792da2d5045fd63260fea252f79a7844eab680c474f1b9a6363832  provenance.json
+7b566eefe84980f4cc7b88a0c504f2286fb8968e916fb212f8a7ef3ec1267a47  sbom.cdx.json
 b3ffedf9e146be802a15b4009f33e031dec3071ca1525e12c67606fd964a3067  schemas/contracts.schema.json

package/templates/.agents/runtime/manifest.json

@@ -1,7 +1,7 @@
 {
   "schemaVersion": 2,
   "name": "zaip-aios",
-  "version": "4.5.0",
+  "version": "4.7.0",
   "node": ">=22",
   "files": [
     "LICENSE",

package/templates/.agents/runtime/provenance.json

@@ -2,10 +2,10 @@
   "schema_version": 1,
   "statement_type": "self_reported_build_integrity",
   "authenticity": "unverified",
-  "version": "4.5.0",
+  "version": "4.7.0",
   "source_origin": "zaip-aios:local-build",
   "lockfile_sha256": "03d08e5bbb198d74014ea4a806fcdeb350db23ec2bf0c2886a2265066555d418",
-  "sbom_sha256": "4b0e237c0d357af52e9baea8ad3abc8b6a6b4d7ba444dbcfd94b97523349aac7",
-  "runtime_sha256": "16c4d182430d58a886f68c63f31cdd5fe0596a1683de57dce7b1374d25e1e6f1",
-  "statement_sha256": "2a216c3ed8b3d97e24b205b154dfe9719d5a5557b668487441985b2af2338332"
+  "sbom_sha256": "7b566eefe84980f4cc7b88a0c504f2286fb8968e916fb212f8a7ef3ec1267a47",
+  "runtime_sha256": "0849009f992e81c5c878dcd496628525f41e929c11c578ea1f0c4af1e7a6638e",
+  "statement_sha256": "50e637a687d5bc3386c2eafbb6571e035550ebf027c8b9c001bcab3e74ab1e41"
 }

package/templates/.agents/runtime/sbom.cdx.json

@@ -6,7 +6,7 @@
     "component": {
       "type": "application",
       "name": "zaip-aios",
-      "version": "4.5.0"
+      "version": "4.7.0"
     }
   },
   "components": [

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

@@ -7,7 +7,7 @@ description: Guide first steps and configure an installed ZAIP-AIOS project with
 
 Use esta skill para pedidos como “me ajude a configurar meu projeto”, “primeiros passos”, personalização ou edição de configurações ZAIP-AIOS. Um pedido ambíguo de configuração de projeto pertence a esta skill.
 
-Escopo de configuração: nome, timezone, stack, clients, tracking e destinos de deploy; Rules locais pertencem a `$zaip-skill-rules`.
+Escopo de configuração: nome, timezone, stack, clients, tracking, destinos de deploy e preferência de publicação; Rules locais pertencem a `$zaip-skill-rules`.
 
 ## Onboarding após instalação
 
@@ -22,7 +22,7 @@ Agrupe até cinco perguntas necessárias por turno; mostre os valores atuais par
 Depois de aplicar e validar as escolhas autorizadas, informe o que foi configurado e encerre o onboarding de instalação, sem outro CTA de setup, publicação automática ou retorno à pergunta sobre GitHub. Se houver recusa ou adiamento, encerre sem insistência; se houver falha, descreva a pendência sem declarar configuração concluída.
 
 1. Confirme que ZAIP-AIOS já está instalado por meio de `.agents/config/project.yaml`. Se estiver ausente, explique que a instalação é um pré-requisito e encaminhe para `$zaip-skill-setup`; não instale nem reinstale durante a configuração.
-2. Leia `.agents/config/project.yaml`, o schema vigente e somente as Rules ligadas ao ajuste solicitado; não existe comando `config set`, portanto edite o YAML canônico diretamente.
+2. Leia `.agents/config/project.yaml`, o schema vigente e somente as Rules ligadas ao ajuste solicitado; não existe comando `config set`, portanto edite o YAML canônico diretamente. A preferência de modo de deploy pertence ao JSON separado descrito abaixo; não adicione campos não suportados em `project.yaml#deploy`.
 3. Para primeiros passos, apresente as opções de personalização pertinentes antes de alterar valores e só aplique a configuração autorizada pelo usuário.
 4. Preserve o contrato: `schema_version: 1`; `project.id/name` não vazios; timezone IANA; `stack.id` não vazio; `stack.overrides` objeto; `clients.codex/claude` booleanos; `tracking.enabled` booleano; `currency` ISO 4217 em maiúsculas; `storage_mode` em `tracked_sanitized` ou `local_only`. `deploy.frontend.branch` e `deploy.backend.branch` são autorização persistida e podem ser `main`; `deploy.database.branch` é sempre `beta`.
 5. Nunca edite `framework.lock.yaml` manualmente: ele é estado resolvido e gerenciado pela instalação do release. Preserve valores desconhecidos apenas quando o schema os permitir; não invente providers, comandos ou credenciais.
@@ -33,10 +33,32 @@ Depois de aplicar e validar as escolhas autorizadas, informe o que foi configura
 10. Ao liberar escolha manual no Codex, remova `model` e `model_reasoning_effort` do `.codex/config.toml` do projeto, pois essa camada prevalece sobre a preferência pessoal. Preserve no `~/.codex/config.toml` o default escolhido manualmente pelo usuário; remova-o somente quando o usuário quiser voltar ao modelo recomendado. Informe que edições externas exigem reinício.
 11. Para configurar, personalizar, corrigir ou validar os perfis Codex `zaip-aios-security` e `zaip-aios-full-access`, leia `.agents/zaip-aios/guides/10-seguranca.md` antes de alterar arquivos. Preserve os limites nativos, as camadas compensatórias e as validações descritas no guia; o perfil completo continua sendo de maior risco.
 12. Para uma aplicação planejada, valide que layout, comandos, componentes e hosting declarados podem sustentar os módulos, runtime e operação escolhidos; encaminhe divergências para `$zaip-skill-adapt-stack` antes de gerar código.
-13. Configure `deploy.frontend.branch`, `deploy.backend.branch` e `deploy.database.branch` explicitamente. O instalador inicia os três com `beta`. Frontend e backend podem usar `main` quando esse for o valor literal salvo pelo usuário; essa escolha passa a ser a autorização de destino e não pede confirmação repetida. Banco de dados nunca aceita `main`, a produção ou fallback: ele exige uma branch beta distinta e promoção humana posterior.
+13. Configure `deploy.frontend.branch`, `deploy.backend.branch` e `deploy.database.branch` explicitamente, preservando os destinos já autorizados. Frontend e backend podem usar `main`; o valor literal salvo autoriza esse destino sem confirmação repetida. Não infira criação de beta nem sobrescreva main por um default de instalação. Banco de dados exige `beta` distinta e promoção humana posterior; configuração não provisiona uma branch hospedada.
 14. Antes de registrar uma integração Supabase hospedada, informe que uma branch beta persistente pode gerar custo adicional conforme plano/uso. Não crie projeto, branch hospedada, integração GitHub, secret ou workflow nessa etapa sem confirmação explícita para aquele provisionamento.
 15. O modo manual é permitido somente após recusa explícita da beta hospedada. Ele exporta SQL para execução humana no SQL Editor; agente, pipeline e startup não aplicam migrations. Retome dependências após sucesso humano registrado, distinguindo esse relato de comprovação independente.
 
+## Preferência de deploy
+
+A instalação semeia silenciosamente uma vez `.agents/config/deploy-policy.json`, project-owned,
+com `schema_version: 1`, `default_mode: auto` e `default_scope: current-work`;
+upgrades preservam a escolha existente. Modos válidos
+são `auto|commits|release`. Não acrescente essa preferência ao bloco `deploy` do YAML.
+
+Em auto, “faça deploy” significa Release + npm via Actions somente no builder verificado por
+origin e identidades dos manifests; em consumidores significa commits + push. Scope padrão
+`current-work` cobre o trabalho autorizado atual; `all-worktree` exige “deploy de tudo”.
+Targets de aplicação continuam os branches literais configurados, inclusive main.
+
+“apenas commits/sem release” e “deploy com release/próxima versão/novo release” substituem
+o modo somente para aquele pedido. Discussão, citação ou negação de release não autoriza
+publicação. Só altere `default_mode` quando o usuário pedir uma preferência permanente;
+um override isolado nunca a altera. Para um ajuste explicitamente solicitado, explique os
+modos pertinentes e aplique a escolha já autorizada, sem nova confirmação rotineira.
+
+Use o resolver revisado de `$zaip-skill-github-deploy` para validar o contrato de modo/escopo.
+Preparar ou configurar não publica. Consumidor permanece GitHub-only, inclusive no modo
+release, sem requisitos npm, chave ou política protegida do builder.
+
 ## Limites
 
 - Segredos não pertencem ao config versionado.

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

@@ -77,3 +77,7 @@ Antes de encerrar com trabalho pendente ou responder a uma falha, aplique [conti
 4. Use o menor paralelismo entre projeto, plano, provider e squad. Em `autonomy-v1`, orçamento por Task vem exclusivamente do preset congelado: Essencial 4/1, Equilibrado 10/3, Persistente ilimitado (execuções/replans); tempo não encerra Task. Risco/domain definem assurance, não esse orçamento. Só no contrato legado use as quotas anteriores por risco.
 5. Checkpoints opacos ficam somente em `.local`; não copie token de retomada para records rastreados. Critical recebe contexto fresco e verificador independente.
 6. A validação tipada acontece dentro da worktree no commit candidato antes da integração. Falha de assurance não pode ser convertida em sucesso pelo coordenador.
+
+## Posse e encerramento do checkout
+
+Antes de delegar edições, o orquestrador da Task obtém `task workspace TASK --run RUN`. A posse serial usa a raiz Git comum a todos os chats; mensagens entre chats coordenam, mas somente o claim e os records centrais autorizam escrita. Sem claim válido, o hook recusa mutação de produto. Só uma DAG PRD/SPEC com `independent_branches`, `max_parallelism > 1`, outra frente pronta, sem dependência transitiva e com escopos disjuntos gera worktree/branch por frente. Na Run terminal, backup Git e snapshot local são verificados por restauração antes da remoção; histórico fica em `.local/backup-branchs` e `.local/backup-worktrees`. Para diff compartilhado sem proveniência segura, bloqueie transferência e reconcilie os arquivos concretos.

package/templates/.agents/skills/zaip-skill-execution/references/autonomous-continuation.md

@@ -11,6 +11,10 @@ O desenvolvimento autorizado continua automaticamente. Antes de terminar um turn
 
 ## Saídas e papéis
 
+- Captura rejeitada não encerra uma entrega por si só. Preserve o filho pendente e diagnostique a rejeição: identidade nativa é metadado, não um caminho de arquivo. Uma correção específica já autorizada continua até validar captura e retomar o executor; nunca desative proteções gerais nem invente identidade para liberar a edição.
+- Antes de iniciar o último filho Gui, conclua e registre todos os gates exigidos para o SHA final, incluindo lock gerado, checks locais, Evidence, assurance e revisão independente quando aplicáveis. Um gate conhecido como pendente ou falho exige reparo na Run raiz ainda ativa; não capture o Gui para obter um bloqueio que obrigará outro turno. Reexecute provas vinculadas ao SHA se o reparo gerar commit novo.
+- Antes de responder com impedimento real, persista a decisão do finalizador e o estado canônico da Task/Execution. Não deixe uma Task em `executing` apenas com uma promessa no chat de corrigir depois. Se a própria persistência falhar, informe os IDs afetados, o erro observado e o recibo recuperável, sem alegar encerramento ou sucesso. Uma solicitação de autorização pendente deve permanecer uma pergunta explícita, e não ser apresentada como conclusão da Task.
+
 - Em progresso, informe o resultado observado e a próxima ação que está executando. Não termine com “envie continue”, “posso prosseguir?” ou “aguardo autorização” quando a autorização e a recuperação aplicável já existem.
 - Em parada real, informe Task/Execution afetada, motivo comprovado, perfil e consumo observado quando disponíveis, recuperação tentada, condição objetiva de retomada e a única ação humana necessária, se houver. Não sugira uma nova tentativa que ultrapasse o perfil.
 - Executor termina sua unidade e devolve evidências ao orquestrador; reviewer/finalizer devolvem sua decisão e não implementam nem criam filhos. O término de um filho não autoriza o orquestrador a abandonar a entrega.

package/templates/.agents/skills/zaip-skill-execution/references/candidate-workflow.md

@@ -1,6 +1,6 @@
 # Candidato, isolamento e preparo de validações
 
-Antes da primeira edição de uma Task interativa com trabalho concorrente, execute `zaip task workspace TASK --run RUN --workspace RAIZ_CANONICA --json`. O comando prepara uma branch local por Task/Execution e devolve o checkout do produto, base e raiz canônica. Uma nova chamada reutiliza o checkout registrado, preservando rascunhos. Claim incompleto ou branch trocada exige diagnóstico; nunca apague ou substitua silenciosamente. Continue gravando lifecycle com `--workspace RAIZ_CANONICA`; não grave novas Tasks/Runs nas cópias históricas do checkout.
+Antes da primeira edição de uma Task interativa com trabalho concorrente, execute `zaip task workspace TASK --run RUN --workspace RAIZ_CANONICA --json`. Em Task avulsa ou PRD/SPEC serial, o comando concede posse exclusiva no checkout compartilhado sem criar branch. Apenas frentes paralelas independentes de PRD/SPEC, com escopos disjuntos e estratégia explícita, recebem branch/worktree próprios. Uma nova chamada reutiliza o checkout registrado, preservando rascunhos. Claim incompleto ou checkout trocado exige diagnóstico; nunca apague ou substitua silenciosamente. Continue gravando lifecycle com `--workspace RAIZ_CANONICA`; não grave novas Tasks/Runs nas cópias históricas do checkout.
 
 Prepare o contrato com `zaip task assurance TASK --json` antes de delegar a implementação. Planeje as modalidades, cobertura de ACs e revisão independente indicadas; o comando de consulta não concede aceite.
 Nas novas Tasks, declare fatos conhecidos em `--assurance-risk-signals JSON` no create ou na captura `new-work`. Sem declaração, apenas o escopo conservador de verificação deriva do risco: scoped para lite, package para standard e full para critical. A origem fica registrada como `risk_default`; isso não afirma impacto em segurança, produção ou dados. Use os sinais para escolher as modalidades antes do trabalho, sem inferi-los do número de arquivos nem alterar a seleção manual de modelo. Registros históricos permanecem com a regra compatível anterior.

package/templates/.agents/skills/zaip-skill-execution/references/runtime-governance.md

@@ -7,11 +7,11 @@ Carregue antes de executar uma entrega ou delegar. Este contrato detalha o kerne
 - Para delegação Codex, Sub-Run ZAIP é somente subagente nativo de colaboração (`spawn_agent`). `create_thread` e `fork_thread` criam chats independentes e exigem pedido explícito do usuário; nunca são Sub-Run, fallback, retry ou prova de delegação. Se delegação nativa estiver indisponível, relate a limitação em vez de criar chat independente. Nome de catálogo, `task_name`, título ou prompt não prova ancestralidade nativa. Antes de repetir a mesma delegação limitada, aguarde ou reutilize seu filho pendente e capture somente ancestralidade/metadados observados em resultados nativos de spawn/terminal do host ou eventos SubagentStart/SubagentStop.
 - Cada `client_turn_id` observável tem uma Execution idempotente/claim atômico; sem ele use identidade local sem prometer idempotência. `interaction` read-only sem descendentes é conversa sem Task artificial e termina após a resposta entregue, sem executor ou finalizador; interaction com trabalho delegado e `delivery` exigem executor/finalizador. `delivery` é trabalho materializado e reuso exige kind/origem compatíveis. A raiz é `zaip-agent-orchestrator`; quando a barreira é exigida escolha executor por capacidade, permita reviewer/auditor/integrator e termine com `zaip-agent-finalizer` em `finalization`, após descendentes, bloqueando novas chamadas.
 - Hooks são best-effort: após cada spawn/terminal, o host autorizado a serviço do orquestrador executa `zaip subagent capture` idempotente com metadados reais. Na captura rica, preserve session/turn observados, `agent-id` com a identidade nativa retornada e `parent-agent-id`/`parent-run-id` do pai imediato exato; cada invocação preserva seu turn. Quando um evento terminal observado expõe somente agent_path, status, identidade catalogada e pai exato, `capture-terminal` aceita apenas `zaip-agent-finalizer` ou executor elegível para delivery com capacidade `task-delivery`; exige também `parent-run-id` igual ao `run_id` da raiz ativa exata, pois um client thread pode conter raízes concorrentes. O último segmento do agent_path deve ser seu `codex_task_name` canônico. O propósito deriva da identidade validada e session/turn/model/provider/usage permanecem indisponíveis; o fallback nunca substitui captura rica nem inventa modelo, effort, tokens ou custo.
-- Antes da primeira edição do executor nativo, capture seu início observado. O PreToolUse pode receber a sessão do pai junto com o turno do filho: a CLI grava correlações locais exatas para esse formato e para a sessão nativa do filho, somente após verificar ancestralidade, modelo/effort, Task e Execution ativos. A autorização de patch fica limitada aos write scopes da Task; reviewers, identidades desconhecidas, outro turno e Runs terminais não recebem essa capacidade. Não copie nem fabrique recibos. Ao reutilizar um subagente, capture seu novo turno ativo; o recibo anterior não autoriza a retomada.
+- Antes da primeira edição do executor nativo, capture seu início observado. Na captura manual de executor cujo pai é orquestrador de Task delegado por uma SPEC, `--session` continua sendo o UUID físico da raiz macro; informe também `--native-session CHILD_UUID` com o UUID do filho observado no retorno do spawn. O PreToolUse pode receber a sessão do pai junto com o turno do filho: a CLI grava correlações locais exatas para esse formato e para a sessão nativa do filho, somente após verificar ancestralidade, modelo/effort, Task e Execution ativos. A autorização de patch fica limitada aos write scopes da Task; reviewers, identidades desconhecidas, outro turno e Runs terminais não recebem essa capacidade. Não copie nem fabrique recibos. Ao reutilizar um subagente, capture seu novo turno ativo; o recibo anterior não autoriza a retomada.
 - Em `autonomy-v1`, carregue `RULE-AUTONOMY-DECISION`. Conversation sem entrega responde diretamente; Task avulsa no padrão `codex_native` usa executor e Gui nativos. O principal preserva a seleção manual do host; cada filho segue a seleção ZAIP por papel/risco/fase, registrada conforme o modelo/esforço efetivamente observados. Capacidade ausente bloqueia a tentativa, nunca é substituída por prompt. Sem `autonomy`, preserve o contrato legado de `automatic_sources` (`spec`,`prd`).
 - Escaladas seguem o perfil congelado: Essencial nunca Astra automático; Equilibrado Sol/high, Sol/high, Astra/high, com execução Astra/high elegível no terceiro bloco; Persistente sem quota total. `RULE-ASTRA-DIAGNOSTIC` descreve também compatibilidade legada. Não use título/volume como prova nem alegue mudança de modelo apenas pelo prompt.
 - Perfis nativos de orquestração e entrega não devem transformar preferências do catálogo em travas TOML de modelo/esforço. O host seleciona explicitamente a configuração da invocação conforme a política congelada, valida capacidade e reserva antes do despacho; ausência de trava não autoriza herança silenciosa, Astra antecipado ou ampliação de permissões. Revisores e finalizador conservam seus contratos próprios. Depois de regenerar os perfis, confira o schema efetivamente carregado pelo Codex: editar o arquivo não comprova recarga nem uma invocação Astra. Se o schema ainda fixa Sol, preserve o bloqueio e solicite recarga da sessão, nunca use `default` ou prompt como substituto.
-- Todo PreparedPlan PRD/SPEC traz `model_signals` por Task; o framework persiste `model_profile`, `task-risk-v1` e motivos, usando `runtime_defaults`, `runtime`, política/defaults sem `standard` silencioso. Não infira fase/complexidade/transversalidade/ambiguidade/rework/custo/capacidade por contagem de arquivos; use sinais, fase/agente e capacidades. Cabeçalho e `model.selection.recorded` repetem a seleção enviada.
+- Todo PreparedPlan PRD/SPEC traz `model_signals` por Task; o framework persiste `model_profile`, `task-risk-v1` e motivos. Task avulsa fornece `--model-signals JSON` em `conversation start --intent new-work` ou `task prepare`, conservando o perfil no preparo. Sinais ausentes não são inferidos de risco/título/volume. No modo `auto`, execução simples, local e delimitada usa Luna/low; padrão Sol/medium; complexidade ou ambiguidade alta usa Sol/high. `native-next --host-capabilities PATH` exige capacidades observadas para a seleção automática; não invente esse arquivo a partir da allowlist. Recuperação usa o plano congelado validado, com investigação somente de leitura. Cabeçalho e `model.selection.recorded` repetem a seleção enviada; só telemetria observada comprova a efetiva.
 - Plano visível: `DEFINE:`, `PLAN:`, `EXECUTE:` ou `VERIFY:`, 3–4 passos (máximo 5); omita fase sem ação e combine trivialidades.
 
 ## Limites do host e relay de persistência

package/templates/.agents/skills/zaip-skill-general-operations/SKILL.md

@@ -8,6 +8,7 @@ description: Answer operational questions and deliver bounded documents, present
 - Responda consultas, explicações e resumos no formato pedido, usando fontes e incertezas explícitas, sem arquivo ou questionário obrigatório.
 - Para entrega persistente, carregue [o fluxo de entrega](references/extended-workflow.md): resultado, público, fontes, formato, escopo e verificação proporcional.
 - Domínios obrigatórios seguem o especialista; referência citada não muda o dono da entrega. Não invente dados ou aprovação.
+- Quando a consulta ou entrega depender de um serviço conectado do usuário, aplique `$zaip-skill-use-connectors`; para e-mail, aplique também `$zaip-skill-send-email`.
 - Ato externo exige autoridade vigente; prepare a minuta e indique pendências quando faltar autorização. Interaction read-only não cria Task/Change; entrega segue lifecycle e ACs. Engenharia só se aplica ao trabalho técnico.
 
 Para documento, resumo salvo ou organização de contexto simples, delimitada e de baixo impacto, use o [perfil editorial `lite`](../zaip-skill-task/SKILL.md#assurance-proporcional) e selecione `--risk lite`. Não o use para código, configuração, instruções de agentes, dado sensível, migração, decisão crítica ou ato externo.

package/templates/.agents/skills/zaip-skill-github-deploy/SKILL.md

@@ -1,72 +1,62 @@
 ---
 name: zaip-skill-github-deploy
-description: Use only when the user explicitly asks to deploy, push or publish to GitHub; in the zaip-aios builder, a full deploy includes a GitHub Release and npm publication through GitHub Actions.
+description: Use only when the user explicitly asks to deploy, push or release on GitHub; resolve project policy, scope commits and verify the exact SHA, with builder npm releases only through Actions.
 ---
 
 # Deploy and repair GitHub publication
 
-An explicit current-turn request to `deploy`, `push`, `publicar`, `publicação` or GitHub publication selects this skill; discussing or editing deployment does not authorize publication. In the `zaip-ai/zaip-aios` builder, “faça deploy” means the guarded push, GitHub Release and observation of the GitHub Actions npm publication. Consumer repositories follow their own GitHub-only policy. Neither route authorizes a hosting-provider deployment.
+Use for an affirmative request to deploy, push, publish to GitHub or recover an authorized publication. Discussing, quoting, editing or negating a release is not publication authority. Resolve the mode before qualification or Git mutation; a generic “faça deploy” follows the project's policy.
 
-Read [the deployment workflow](references/deployment-workflow.md) for the detailed operational contract before publication. The steps below retain its authority, identity and completion boundaries.
+## Resolve mode and scope
 
-## Authorization and scope
+Read [the deployment workflow](references/deployment-workflow.md) and run the portable reviewed resolver:
 
-- The exact command “faça deploy” authorizes commits covering all versionable pending changes in the selected worktree, followed by push and Release, after secret, size and ignore checks. In the verified framework source, publishing that Release triggers the npm workflow; follow it to terminal status and verify the registry. The selected worktree is the complete publication scope; other worktrees remain outside it. An explicit push-only request stops after the verified push and does not create a Release or publish npm.
-- Resolve dirty state, untracked files, generated projections, branch divergence and repairable local/remote failures automatically within that scope. Limit repairs to the evidenced cause, with up to five repair cycles; stop when the same root cause remains after two repairs.
-- Treat the selected worktree's local branch, recovery branch or detached state as the source candidate only. The configured deploy branch is the remote target; a mismatch between source and target is not a blocker and never requires checking out the target locally.
-- Stop only for an unresolved index conflict after bounded repair, secrets, files at or above GitHub's 100 MB limit, unavailable authentication/authority, external outage, destructive requirement, or ambiguous scope expansion.
-- Never force push, rewrite history, replace remotes, change credentials or Git/SSH configuration, bypass checks, or deploy to another service.
-- Git-only publication of existing commits needs no artificial Task. Product edits or new product commits require real Task ownership; materialize missing authorized work before editing. Records/local-only snapshots are exempt.
+```text
+node .agents/skills/zaip-skill-github-deploy/scripts/deploy-contract.mjs --repository <ROOT> --request-file <FILE> [--plan-file <FILE>]
+```
 
-## Mandatory authorization record
+The request file is UTF-8 plain text containing the actual human request. The resolver reads policy and repository identity itself and writes the mode/scope contract to the plan file. Retain authorized paths, commit inventory and configured target separately as observed evidence.
 
-Before the first Git mutation, retain sanitized authority in progress and the terminal report: current-turn intent; repository, remote, branch and selected worktree; push-only versus commit plus push; bounded rebase (default) or user-selected merge; allowed repairs and excluded scopes; preflight result and preservation reference. Never record credentials or environment values.
+- The project-owned `.agents/config/deploy-policy.json` has `schema_version: 1`, `default_mode: auto|commits|release` (default `auto`) and `default_scope: current-work`. In auto, verified builder means Release plus npm through Actions; a consumer means commits plus push. Installation seeds the preference silently once and preserves it on update. Mode preferences do not belong inside `project.yaml#deploy`; `all-worktree` is only a request override.
+- “apenas commits”, “sem release” or explicit push-only selects commits for this request. “deploy com release”, “próxima versão” or “novo release” selects release when affirmatively requested. A one-shot override never changes the permanent preference; only an explicit preference change does.
+- Preparation alone does not publish. A mention of release, including a question or negated example, is not an affirmative release request.
+- Default scope is `current-work`: only evidenced files and commits of the current authorized work. `all-worktree` requires explicit “deploy de tudo”. Inspect pending files to prove the scope; a dirty worktree does not enlarge it.
+- Builder classification requires the approved `zaip-ai/zaip-aios` origin and the `@zaip-ai/aios` root and `@zaip-ai/cli` public CLI package identities. A name, folder or installed framework alone is insufficient; contradictory identity is an integrity blocker.
+- Frontend/backend target the literal configured application branch, including `main`; database retains its separate `beta` and human-promotion policy. Never infer beta creation from this request.
 
-## Prepare the selected worktree
+The requested deploy is sufficient authorization for the selected mode. Continue without a routine confirmation or an extra warning about an existing pipeline. Integrity, authentication, destructive operations and a required scope expansion remain real blockers.
 
-1. Inspect Git status, pending paths and diff summary. Review every inventoried versionable file for secrets, size and ignore policy.
-2. Read `.agents/config/project.yaml`. Resolve the explicit frontend/backend target from `deploy.frontend.branch` or `deploy.backend.branch`; configured `main` is permitted. `deploy.database.branch` must remain literal `beta`. The legacy `deploy.branch` fallback remains non-production. Record the local source branch or detached state separately from this target.
-3. Prove folder-scoped SSH using `scripts/preflight.mjs --repository . --remote origin --scope frontend` (or the actual authorized scope). Run at most once per cycle; recheck only after an evidenced repair or changed target. Require SSH origin, configured key, Git identity and successful `ls-remote`; no process overrides or credential/config edits. Preflight accepts a named recovery branch or detached source and returns it separately from the configured target.
-4. Fetch once per cycle and compute ahead/behind between the source candidate and configured remote target. Before reconciliation, create and verify a recoverable branch reference, including for detached HEAD, and preserve tracked plus untracked changes in a named stash. Use bounded rebase by default without switching to the target branch. Restore with `git stash apply`; verify preservation, retain the stash until success, and combine conflicts from observed intent. Never reset or force.
-5. Re-inventory after reconciliation. Stage the reviewed paths with `git add -- <explicit-pathspecs>`; never use `git add -A`, `git add -u`, broad globs or ignored files. Explicit deploy permits the whole inventoried selected worktree, without mandatory functional partitioning.
-6. Run required or evidenced gates only. Reuse unchanged valid evidence; bypass Turbo cache for the failed remote gate when repairing CI. A failed gate starts a new cycle only after a concrete repair or new remote evidence.
+## Preserve and prepare
 
-## Task identity in commits
+1. Record sanitized intent, resolved mode/scope, selected checkout, source SHA/branch, configured remote target, reviewed paths, preflight and preservation reference in evidence. Keep the chat result brief.
+2. Inspect status, intended diff, ignore policy, secrets and file sizes. Preserve concurrent files and index entries; never stage unrelated work implicitly. Stage with `git add -- <explicit-pathspecs>`; never `git add -A`, broad globs, force, credential edits or history rewriting.
+3. Run folder-scoped SSH `scripts/preflight.mjs` with the explicit application scope, at most once per unchanged cycle. Source recovery branches and detached HEAD are valid candidates; the configured branch is only the remote target.
+4. Fetch and reconcile the authorized source, using a verified recovery ref and named stash before rebase (default) or an authorized merge. Restore with `stash apply` and verify preservation. Do not switch locally to the target just to publish.
+5. Run checks selected by changed behavior, governing ACs and observed failures. New product commits need real Task/Change/Execution ownership and matching scopes. Publish existing commits without an artificial Task; records/local-only snapshots retain their exception.
 
-Use `[CODEX|CLAUDE] [P:XXXX] [S:XXXX] [T:XXXX] <Task title>` with evidenced lineage. The effective prefix is exclusively `CODEX` or `CLAUDE`; `AUTO` is not part of this policy.
+Commit subjects retain `[CODEX|CLAUDE] [P:XXXX] [S:XXXX] [T:XXXX] <Task title>` or evidenced `[Task-first:XXXX]`, at most 96 characters, with full IDs in `ZAIP-*` trailers. Use `task commit TASK --run RUN --files PATHS`, preserve the commit-msg hook and validate the range. See [commit policy](../zaip-skill-task/references/commit-policy.md).
 
-Standalone Tasks use `[Task-first:XXXX]` followed by the canonical Task title; do not invent PRD/SPEC lineage. Keep the subject within 96 characters and full IDs in `ZAIP-*` trailers. Use `task commit TASK --run RUN --files PATHS`, retain the commit-msg hook, and validate the range with `commit validate`.
+## Deliver the resolved mode
 
-Every product commit requires causal Task/Change/Execution records and matching write scopes. Only `.agents/records/**` and `.local/**` changes are exempt. Conversation capture alone does not authorize a product commit; never borrow the latest global Task. See [commit policy](../zaip-skill-task/references/commit-policy.md).
+- **Commits:** use `scripts/guarded-commits.mjs` with its reviewed CLI and valid scoped checks to push the exact SHA to the configured branch. Do not enter release qualification, change a version or create a Release merely for this mode. Installer/security work still runs checks directly required by its impact.
+- **Release:** read [release identity](references/release-identity.md), then compose `$zaip-skill-release-qualification` and [local preparation](../zaip-skill-release-qualification/references/local-preparation.md) for the actual distribution surface. Verified builder uses `scripts/local-release-deploy.mjs`; consumers create only their GitHub Release under their own checks, without builder npm, signing-key or protected-policy requirements.
+- Before release versioning, verify whether the candidate SHA is already published. The same published SHA is a no-op, never an empty new Release. Resume a verified draft or retry only observed incomplete delivery with the exact same SHA and identity. A changed candidate requires new identity/evidence.
+- Review detailed UTF-8 notes only for the Release, following [release notes](references/release-notes.md). Observe the complete previous-Release-to-candidate Git range as source/evidence, including changes beyond the current chat. Validate the inventory and compare the published body byte-for-byte; never use generated notes alone.
 
-## Qualify the exact candidate and deliver
+Dense source/template/package/TGZ gates belong to builder release qualification. Generic commits use targeted validation, without an automatic full suite, test-count cap or Task wallclock limit. Apply the frozen autonomy profile: balanced permits 10 executions total and 3 replans; tests/tool calls are not executions and resumption does not reset the budget. Do not add an independent five-cycle limit.
 
-1. Compose `$zaip-skill-release-qualification` and follow [local preparation](../zaip-skill-release-qualification/references/local-preparation.md). Synchronize and commit before preparing the clean exact SHA. Failed or stale evidence is not qualification.
-2. Resolve the previous Release, next canonical version and package identity using [release identity](references/release-identity.md). For the framework, `vN.N` maps to package `N.N.0`; only GitHub Actions publishes `@zaip-ai/cli` to npm.
-3. For the verified `zaip-ai/zaip-aios` source, use `scripts/local-release-deploy.mjs`. It prepares/verifies, pushes the exact SHA to configured `main`, uploads verified assets to a draft, then publishes the Release. The `publish-cli.yml` workflow is triggered by `release: published` and alone performs npm publication. Enable the thin publisher only after explicit rollout authority, public trust enrollment and signed local qualification. It validates published assets and runs one read-only installation smoke before npm; no private-draft pilot or local npm write token is needed. Inspect the configured signing key, trust store, policy and protected workflow settings before reporting a missing credential; do not confuse the release-signing private key with the Git SSH key or npm token in a local `.env`, and never rotate trust or bypass a gate without separate authorization. The user authorized routine per-version updates of **only** `ZAIP_LOCAL_RELEASE_POLICY_B64` for this builder on 2026-09-23. Prepare a reviewed version-matched policy, qualify the exact SHA, enroll those exact public policy bytes and verify readback before publishing the Release; do not ask again merely because the previous version is still enrolled. This standing authorization never covers trust-key rotation, other protected variables, or weaker gates. GitHub Release publication and npm completion remain separate.
-4. Consumers use `scripts/consumer-release-preparation.mjs guarded-push` with their own policy and explicit branch, SHA and trusted receipt. They have no framework npm/TGZ requirement. See the preparation guide for bootstrap and guarded commands.
-5. Immediately before delivery, reread the configured target; if changed, restart preparation. Helpers bind the exact candidate to `HEAD:refs/heads/<configured branch>` (or its equivalent immutable-SHA refspec) independently of the local source branch; do not bypass them with a manual push.
-6. After qualification, a missing Release is normal. Unless explicitly push-only, automatically create the draft for that SHA or resume a verified draft for the same SHA. Verify an already-published exact Release as a no-op; an API/authentication error never proves absence. Refuse conflicting tags/assets without overwrite.
-7. Review complete categorized UTF-8 notes and their exact-range inventory under [release notes](references/release-notes.md). Never use `--generate-notes` as the Release body. Validate the notes, publish with the reviewed notes file, and compare the published body byte-for-byte on readback. Preserve a configured human-only review policy where applicable.
+## Verify and report
 
-## Proportional validation
+Compare the exact pushed SHA with the configured remote ref. If a push result is uncertain, read remote state before retrying. Observe required checks for that SHA, inspect failed steps and repair their evidenced cause within the frozen profile; do not repeat unchanged failures or bypass a gate.
 
-Guarded local framework delivery requires a valid `essential-v3` receipt for the exact candidate.
-It runs the fixed essential integrity, build/type, package and clean-consumer doctor/SQLite/API
-smoke checks. Dashboard-per-tab and XLSX certification are reserved for explicit `--profile full`.
-Without explicit thin-path activation, the default GitHub publisher separately requires the legacy workflow's
-exact-candidate qualification receipt after its full gate and TGZ matrix.
-Rapid impact checks have no test-count ceiling and cannot substitute for release evidence.
-Use the budgets and failure rules in [local preparation](../zaip-skill-release-qualification/references/local-preparation.md).
-Consumer projects retain their own reviewed policy commands. Report qualification and
-publication separately; neither preparation nor this policy grants publication authority.
+Commits success requires the scoped exact-SHA push and its required checks. Consumer release success additionally requires the verified tag, SHA and reviewed body. Builder release success additionally requires its verified signed assets, terminal `publish-cli.yml` success and registry version, dist-tag and integrity for `@zaip-ai/cli@N.N.0`. A Release with failed or unobserved npm is partial. An unavailable check stays unconfirmed.
 
-## Verify and close
+Give a brief chat result with the delivered mode, branch/SHA, Release link when applicable and any actual pending gate. Keep detailed change notes in the Release and sanitized evidence in the owned lifecycle. Formal closure belongs to the responsible orchestrator/finalizer. This GitHub workflow grants no provider deploy, database production, SQL application or host power action.
 
-- After push, compare the local SHA with the configured remote ref. If the push result is uncertain, read remote state first; only one documented transient transport retry is allowed per cycle.
-- Observe required GitHub checks for that exact SHA, waiting up to 20 minutes with concise progress at least once per minute. Read the exact failed step before repairing. Never repeat an unchanged failing command or disable a gate for green status.
-- Reconcile recoverable prerequisites and continue through the same bounded repair policy; do not stop merely because a Release or generated file was absent.
-- Full framework deploy success requires matching local/remote hashes, successful required checks, verified Release identity/body, a clean intended worktree, terminal success of the exact `publish-cli.yml` run, and registry confirmation of `@zaip-ai/cli@N.N.0` with the intended dist-tag and artifact integrity. The local `.env` does not automatically provide GitHub Actions credentials; use only the workflow's configured secret/environment. If npm fails or cannot be observed, report the GitHub Release as published but the deploy as partial or blocked, with the exact failed/pending gate. Consumer deploys have no framework npm gate. Formal lifecycle closure remains separate.
-- Retain terminal evidence and close every owned Task/Change/Execution correctly through the finalizer. Never finish with an owned Task executing/verifying; use completed, blocked, cancelled or failed according to observed outcome.
+## Pre-main candidate and release-cycle audit
 
-Database request-branch PRs retain their separate policy. This Git-only skill never applies SQL, provisions paid resources or publishes database production. Read-only identities cannot substitute for deploy credentials.
+For the verified framework builder, release delivery requires `.agents/config/release-cycle.json` frozen at the version being released, a clean candidate SHA, remote `main` as its ancestor, and no stale branch/worktree. Every owner SPEC DAG predecessor must be completed. The sole open exception is the critical release-only Task coordinator delegated from the owner SPEC/Execution/macro Run; its exact lineage, predecessor states and candidate records are authenticated at freeze, audit and advance. Other current-release Task/PRD/SPEC work blocks. `scripts/local-release-deploy.mjs` runs fixed local checks at the exact SHA without creating a remote candidate branch. It then pushes only `main` and waits for the exact successful `main` push run of `pre-main-candidate.yml` before publishing a Release. A critical framework commit follows the same branch-free sequence through `guarded-commits.mjs`. Failed local checks block the push; failed or unavailable remote CI blocks Release publication and requires repair on `main`.
+
+When the same authorized direct Task root implements the product repair and release, the explicit integrated coordinator mode in `$zaip-skill-release-qualification` can freeze while that Task and Run are active. It keeps the clean exact-SHA, only-main, no-other-work, independent validation and publication gates. Record this selection in the frozen cycle; it does not create a second Task or client turn.
+
+After a published release, use `node scripts/release-cycle-gate.mjs advance --repository ROOT --from N.N --to NEXT --sha CANDIDATE --ci-run-id RUN_ID` while the release coordinator remains active. This checks remote main, tag, published Release, exact successful CI, local branch/worktree cleanup and owner lineage before recording the transition. Bind Evidence to that immutable candidate, close Task and SPEC, then make one metadata-only closure commit. `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` verifies tag, public Release, npm, the candidate's recorded exact CI run, one descendant metadata commit, exact remote main and only-main before pushing; it waits for CI on the closure SHA. The reviewed JSON is an array of exact changed metadata paths, including causal telemetry when present. `--metadata-paths EXACT,PATHS` is available for a short list. Do not retag or treat local lifecycle closure as remotely published. It does not prove provider deployment. Future drafts can remain in `draft`; executable future work cannot.

package/templates/.agents/skills/zaip-skill-github-deploy/agents/openai.yaml

@@ -1,6 +1,6 @@
 interface:
   display_name: "ZAIP GitHub Deploy"
-  short_description: "Deploy GitHub; npm via Actions no builder ZAIP"
-  default_prompt: "Use $zaip-skill-github-deploy para o pedido explicito 'faca deploy': no builder zaip-aios, publique a Release pelo fluxo protegido e confirme o workflow npm e o registro; em consumidores, siga a politica GitHub-only, respeitando pedidos push-only."
+  short_description: "Deploy por política: commits ou Release verificada"
+  default_prompt: "Use $zaip-skill-github-deploy para executar o deploy solicitado pela política do projeto, respeitar overrides e escopo do trabalho atual, verificar o SHA e resumir o resultado; publique npm via Actions somente em release do builder verificado."
 policy:
   allow_implicit_invocation: true