@zaip-ai/cli 1.0.6 → 1.0.7

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

@@ -6,10 +6,10 @@ description: Configure and validate project-owned ZAIP settings without editing
 # Configurar o projeto
 
 1. 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. Preserve o contrato: `schema_version: 1`; `project.id/name` não vazios; timezone IANA; `stack.profile` 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`.
+2. 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`.
 3. Nunca edite `framework.lock.yaml` manualmente: ele é estado resolvido e gerenciado pelo setup/upgrade.
 4. Preserve valores desconhecidos apenas quando o schema os permitir; não invente providers, comandos ou credenciais.
-5. Valide config e paths com `zaip doctor`; quando o profile mudar, delegue a adaptação para `$zaip-skill-adapt-stack` e valide-o com `zaip profile validate --path <profile.json>`.
+5. Valide config e paths com `zaip doctor`; quando a stack mudar, delegue a adaptação para `$zaip-skill-adapt-stack` e valide-a com `zaip profile validate`.
 6. Se a mudança afetar adapters, delegue a `$zaip-skill-adapters` e rode `zaip adapters build` seguido de `zaip adapters check`.
 7. Informe campos alterados, validações executadas e qualquer reinicialização necessária.
 8. Para `model_orchestration.mode: auto`, exija `automatic_sources: [spec, prd]`. Não inclua `task`: Tasks avulsas devem continuar usando o modelo e o esforço escolhidos manualmente no host.
@@ -18,5 +18,5 @@ description: Configure and validate project-owned ZAIP settings without editing
 ## Limites
 
 - Segredos não pertencem ao config versionado.
-- Rules do projeto pertencem a `.agents/rules/project`, não ao config.
+- Rules locais do projeto pertencem a `.agents/rules/`, fora do `framework.lock.yaml`, não ao config.
 - Upgrade de arquivos gerenciados pertence a `$zaip-skill-setup`.

package/templates/.agents/skills/zaip-skill-data-analyst/SKILL.md

@@ -0,0 +1,23 @@
+---
+name: zaip-skill-data-analyst
+description: Analyze bounded datasets, diagnose metrics, and produce reproducible evidence-backed findings. Use when a Task has a declared dataset, metric definitions, or a quantitative question; do not use for product implementation or unsupported conclusions.
+---
+
+# Analisar dados delimitados
+
+1. Confirmar o dataset, período, unidade de análise, definições de métrica e decisão que a análise deve informar. Quando qualquer insumo não estiver disponível, registrar a limitação e não preencher a lacuna com suposição.
+2. Inspecionar a qualidade antes da conclusão: cobertura, duplicidade, nulos, granularidade, filtros e proveniência. Separar dado observado, derivação determinística e inferência.
+3. Declarar método reproduzível: arquivos ou fontes usados, filtros, transformações, agregações, fórmula e intervalo temporal. Executar checks ou testes proporcionais quando houver código analítico.
+4. Reportar achados com incerteza, exceções e limites. Não converter indisponibilidade em zero, causalidade ou certeza; distinguir descrição, comparação e hipótese.
+5. Produzir evidência vinculada aos Acceptance Criteria e retornar somente resultados sustentados pelo dataset delimitado. Escalar alterações de produto, dashboard ou esquema para o executor apropriado.
+
+## Casos de análise
+
+- Para uma análise pontual, responder à pergunta delimitada com o filtro, numerador, denominador e período usados.
+- Para variação de métrica, comparar a mesma definição entre períodos ou coortes e separar mudança absoluta, percentual e base de comparação.
+- Para segmentação, declarar a dimensão, os critérios de inclusão e o tamanho de cada grupo; não generalizar segmentos pequenos ou incompletos.
+- Para qualidade ou anomalias, verificar cobertura, duplicidade, nulos, quebras de série e valores fora do padrão antes de atribuir causa.
+- Para comparação temporal, alinhar janelas, timezone, granularidade e eventos que alterem a comparabilidade.
+- Para resposta executiva, sintetizar decisão, evidência, incerteza e próximo passo, sem ocultar limites técnicos.
+
+Aplicar escopo proporcional: uma pergunta pontual pede inspeção e cálculo mínimo reproduzível; diagnóstico, segmentação ou tendência pede verificações de qualidade e comparabilidade adicionais. Não ampliar para implementar produto, alterar dashboard ou redesenhar métricas sem Task e escopo próprios.

package/templates/.agents/skills/zaip-skill-data-analyst/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "ZAIP Data Analysis"
+  short_description: "Analyze bounded datasets with reproducible evidence."
+  default_prompt: "Use $zaip-skill-data-analyst to analyze a bounded dataset with methods, uncertainty, and reproducible findings."

package/templates/.agents/skills/zaip-skill-design-system/SKILL.md

@@ -0,0 +1,50 @@
+---
+name: zaip-skill-design-system
+description: Govern canonical design-system tokens, catalog specimens and anchored design pages.
+---
+
+# Design System
+
+Use this skill when creating or editing the central design language. Manu owns
+`.agents/design/DESIGN.md`, `.agents/design/tokens.json`,
+`.agents/design/apps/catalog/**`, canonical component specimens, and the frontend of
+the framework pages `design-system` and `componentes`.
+
+## Mandatory routing
+
+Call Manu whenever a change creates or edits a central design rule, design token,
+canonical component contract, or either design catalog page. A feature component that
+merely lives in a directory named `components` is not central design work and remains
+with the delivery specialist unless it changes the shared contract.
+
+## Workflow
+
+1. Read the current `DESIGN.md`, tokens, catalog specimens, and consuming pages.
+2. State the design problem, affected products, accessibility constraints, and
+   compatibility impact.
+3. Update `DESIGN.md` as the human-readable source of principles, voice, layout,
+   typography, color, motion, interaction, accessibility, and component rules.
+4. Update machine-readable tokens without duplicating contradictory values.
+5. Implement or update the canonical specimen and both catalog presentations when the
+   rule is user-visible.
+6. Check representative consumers for regressions; coordinate with Doug or Jonny when
+   their product surfaces must adopt the new contract.
+7. Verify design artifacts and rendered catalog pages before recording evidence.
+
+## Required outcomes
+
+- `DESIGN.md` explains intent and usage, not only raw token values.
+- Tokens have stable semantic names and do not encode a single page's implementation.
+- Canonical components document anatomy, states, variants, content rules, keyboard
+  behavior, focus, contrast, responsiveness, and do/don't guidance.
+- The `design-system` page exposes foundations and tokens.
+- The `componentes` page exposes reusable component specimens and states.
+- Both pages consume the same central source instead of maintaining independent copies.
+- Breaking changes include migration guidance and affected consumers.
+
+## Verification
+
+Run schema/format validation for design artifacts, frontend typecheck and tests, and a
+production build. Preview both catalog pages at desktop and narrow widths; check
+keyboard navigation, visible focus, contrast, empty/error/loading/disabled states, and
+the absence of console errors. A source-only review is insufficient for a visual rule.

package/templates/.agents/skills/zaip-skill-design-system/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: Design System
+  short_description: Govern design tokens and canonical components.
+  default_prompt: Use $zaip-skill-design-system only for canonical design artifacts and explicitly anchored specimens.

package/templates/.agents/skills/zaip-skill-design-system/references/scope.md

@@ -0,0 +1,21 @@
+# Scope
+
+## Owned by Manu
+
+- `.agents/design/DESIGN.md`
+- `.agents/design/tokens.json`
+- `.agents/design/apps/catalog/**`
+- Canonical component or Storybook specimens explicitly referenced by the design
+  catalog
+- The framework routes/pages named `design-system` and `componentes`
+- Central rules for color, typography, spacing, layout, motion, voice, interaction, and
+  accessibility
+
+## Not automatically owned by Manu
+
+- A feature-local component merely because its directory is named `components`
+- Business logic, API behavior, persistence, or ordinary feature delivery
+- A website page that only consumes unchanged central rules
+
+If a Task touches both categories, split the design contract from its product adoption
+or coordinate Manu with the relevant frontend/website specialist.

package/templates/.agents/skills/zaip-skill-enforce-architecture/SKILL.md

@@ -5,10 +5,10 @@ description: Enforce ZAIP module boundaries, dependency direction, composition r
 
 # Enforce architecture
 
-1. Load `RULE-ARCHITECTURE` and `REQUIREMENTS-SOFTWARE-ARCHITECTURE`, then run `zaip architecture validate` and `zaip modules validate`. Validate a non-default profile with `zaip profile validate --path <profile.json>`; in the framework source repository, also run `node scripts/validate-source-size.mjs`.
+1. Load `RULE-ARCHITECTURE` and `REQUIREMENTS-SOFTWARE-ARCHITECTURE`, then run `zaip architecture validate`, `zaip modules validate` and `zaip profile validate`; in the framework source repository, also run `node scripts/validate-source-size.mjs`.
 2. Classify product surfaces before moving code: `apps/frontend` is product UI, `apps/backend` is APIs/workers, and `apps/site` is the public site. Never use the ZAIP dashboard as one of those apps.
 3. Enforce `apps -> modules -> packages`, inward Clean Architecture dependencies, one explicit composition root per module and private module storage.
-4. For `.agents/dashboard`, require local read-only V2 projections and the `apps/frontend`, `modules/{operations,cost-monitor,traceability}`, `packages`, `tests/e2e` boundaries. The loopback projection server belongs to `packages/local-runtime`; reject dashboard `apps/backend`.
+4. For `.agents/dashboard`, require manifest-first local read models and the `apps/frontend`, `modules/{operations,cost-monitor,traceability}`, `packages`, `tests/e2e` boundaries. The loopback server belongs to `packages/local-runtime`; it reads `.agents/records/lifecycle` and must not recreate a local projection. Reject dashboard `apps/backend`.
 5. Keep unit tests co-located and cross-app journeys in the relevant `tests/e2e` root.
 6. Treat 401–800 source lines as warning and 801+ as error. Accept a baseline exception only for preexisting non-dashboard code while it is unexpired and has not exceeded `max_lines`.
 7. Report severity, rule, file, line, impact and the smallest compliant remediation; do not suppress findings by moving code to an unrelated folder.

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

@@ -13,12 +13,15 @@ Use esta skill somente quando o usuário pedir execução. `prepare` não autori
 4. Execute a ordem topológica. Paralelize apenas Tasks independentes cujos arquivos, módulos, migrations, ambientes e recursos não conflitem.
 5. Antes de integrar agentes paralelos, compare diffs, testes e efeitos; reconcilie o resultado no workspace canônico.
 6. Registre decisões humanas/IA, uso por fase, evidências por AC, testes, evals e arquivos alterados.
-7. Respeite a política do plano: use `zaip verify --changed --risk <risk>` no modo `scoped`; reserve `pnpm verify` para `full`, risco critical ou gate final exigido.
-8. Em cada `run usage`, leia `budget.context_refresh_required` e `budget.checkpoint_required`. O runtime grava o checkpoint sanitizado em `.agents/projections/runtime/checkpoints/`; quando sinalizado, reconstrua contexto somente de IDs ativos, diff e findings, descarte outputs brutos antigos e continue apenas com autoridade.
-9. Em falha operacional, use retry limitado; em falha lógica, crie repair/rework explícito. Nunca esconda uma tentativa.
-10. Cada tentativa usa uma Run raiz do `zaip-agent-orchestrator`; subagentes e fases materialmente distintas usam Sub-Runs relacionadas por `parent_run_id`. Cada Run/Sub-Run fixa agente, modelo e effort; retry técnico preserva a configuração e qualquer mudança deliberada abre outra chamada de agente.
-11. Depois que todos os Sub-Runs de trabalho terminarem, invoque `zaip-agent-finalizer` como último filho de qualquer Execution com propósito `finalization`. Não inicie novos filhos depois dele. A CLI aplica seu resultado restrito; ausência, interrupção ou falha deixa a Execution inconclusiva como `blocked`.
-12. SPEC/PRD permanece `active` entre Runs filhas e só entra em verificação após todas as Tasks; a Run filha não entrega nem bloqueia automaticamente o pai.
+7. Para toda Task com mutação, produza um commit canônico isolado antes de `completed`, com provider efetivo exclusivamente `CODEX` ou `CLAUDE` e sem `AUTO`. Linhagem evidenciada usa `[CODEX|CLAUDE] [P:XXXX] [S:XXXX] [T:XXXX] <título da Task>` com blocos disponíveis; Task sem PRD/SPEC usa `[CODEX|CLAUDE] [Task-first:XXXX] <título da Task>`. Limite o assunto a 96 caracteres sem cortar palavras, preserve IDs completos disponíveis nos trailers `ZAIP-PRD`, `ZAIP-SPEC`, `ZAIP-Task`, `ZAIP-Change`, `ZAIP-Execution` e `ZAIP-Agent`, e não combine Tasks no mesmo commit. Commit funcional sem Task só é permitido na exceção explícita de deploy particionado e usa `[CODEX] <título funcional>` sem `ZAIP-Task`.
+8. Respeite a política do plano: use `zaip verify --changed --risk <risk>` no modo `scoped`; reserve `pnpm verify` para `full`, risco critical ou gate final exigido.
+9. Em cada `run usage`, leia `budget.context_refresh_required` e `budget.checkpoint_required`. O runtime grava o checkpoint sanitizado em `.local/checkpoints/`; quando sinalizado, reconstrua contexto somente de IDs ativos, diff e findings, descarte outputs brutos antigos e continue apenas com autoridade.
+10. Em falha operacional, use retry limitado; em falha lógica, crie repair/rework explícito. Nunca esconda uma tentativa.
+11. Cada tentativa usa uma Run raiz do `zaip-agent-orchestrator`; subagentes e fases materialmente distintas usam Sub-Runs relacionadas por `parent_run_id`. Cada Run/Sub-Run fixa agente, modelo e effort; retry técnico preserva a configuração e qualquer mudança deliberada abre outra chamada de agente.
+12. Interaction read-only sem descendentes termina após a resposta, sem executor/finalizador. Para interaction com descendente delegado e para delivery, depois que todos os Sub-Runs de trabalho terminarem invoque `zaip-agent-finalizer` como último filho com propósito `finalization`. Não inicie novos filhos depois dele; auto-settlement nunca fecha interaction com descendente ativo. A CLI aplica seu resultado restrito; ausência, interrupção ou falha deixa a Execution inconclusiva como `blocked`.
+13. SPEC/PRD permanece `active` entre Runs filhas e só entra em verificação após todas as Tasks; a Run filha não entrega nem bloqueia automaticamente o pai.
+14. Resolva execução no menor grão explicitado: Task executa um nó elegível, SPEC executa sua DAG interna e PRD executa todas as SPECs selecionadas. Nunca amplie Task para SPEC/PRD por inferência.
+15. “Conclua a execução” ou “finalize a implementação” em macro ativo continua Tasks e gates até resultado verdadeiro; não força `deliver`. “Desenvolva/melhore/aprimore” interrompe execução implícita, registra diagnóstico e cria plano/rework antes de nova promoção.
 
 ## Paralelismo
 
@@ -30,7 +33,7 @@ Use esta skill somente quando o usuário pedir execução. `prepare` não autori
 
 1. Leia `execution.runtime`. Ausente ou `manual` preserva a execução materializada tradicional; somente `autonomous` autoriza invocar o provider configurado.
 2. Injete `model_orchestration` somente quando `mode` for `auto` e a origem da Execution estiver em `automatic_sources`. O contrato canônico permite apenas `spec` e `prd`; uma Execution de `task` preserva a seleção manual do host.
-3. Em autonomia, exija raiz Git limpa, worktree registrada por Task, commit final sem alterações pendentes, diff dentro dos write scopes e merge abortável em conflito.
+3. Em autonomia, exija raiz Git limpa, worktree registrada por Task, commit final canônico sem alterações pendentes, diff dentro dos write scopes e merge abortável em conflito. A integração cria outro commit canônico por Task no histórico first-parent e referencia o SHA do candidato em `ZAIP-Product-Commit`.
 4. Use o menor limite de paralelismo entre projeto, plano, provider e squad. Tasks `lite` têm uma tentativa; `standard` e `critical` no máximo três tentativas de desenvolvimento/reparo.
-5. Checkpoints opacos ficam somente em `.zaip-aios/local-data`; não copie token de retomada para records rastreados. Critical recebe contexto fresco e verificador independente.
+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.

package/templates/.agents/skills/zaip-skill-execution/references/prepared-plan.md

@@ -19,6 +19,7 @@ Use este contrato quando o prepare exigir uma DAG externa. Para uma Task manual
 - `policy`: `failure_policy` (`stop_on_terminal_failure` ou `continue_independent`), `max_parallelism` positivo, `max_operational_retries` e `max_repair_cycles_per_task` não negativos.
 - `blueprints.changes[]`: `key`, `id`, `title`, `short_name`, `risk`, `source`, Requirements/AC e `requirement_impact`.
 - `blueprints.tasks[]`: `key`, `id`, `change_id`, `title`, `short_name`, `objective`, `risk`, `priority`, `owner`, Requirements/AC e `write_scopes`.
+- Em plano novo de PRD, `blueprints.specs[]` é obrigatório e contém cada SPEC técnica completa: ID, título, objetivo/resumo, risco, escopo incluído/excluído, Requirements/AC, snapshot exato da stack, rollout/fallback e `model_signals`. Em criação explícita de SPEC, a coleção contém exatamente o blueprint da SPEC de origem e permite `spec create --plan` atômico.
 - `dag.nodes[]`: um nó por Task com `task_id` e `depends_on`.
 
 ## Invariantes
@@ -26,6 +27,7 @@ Use este contrato quando o prepare exigir uma DAG externa. Para uma Task manual
 - Use IDs reais de Requirements/AC e IDs pré-alocados únicos; nunca invente referências durante o prepare.
 - Cada Task aponta para uma Change do mesmo plano e aparece exatamente uma vez na DAG.
 - Em plano de PRD, toda Change usa `source: {type: "prd", prd_id, spec_id}` com uma SPEC filha real; `spec_id` não pode ser nulo.
+- SPECs de um novo plano de PRD são independentes: nenhuma aresta da DAG atravessa `spec_id`. Se uma Task depende de resultado produzido por outra SPEC, componha ambas em uma única SPEC. Integração de outcomes é gate parental do PRD.
 - Em plano de SPEC ou Task, a origem da Change deve coincidir com a origem do plano.
 - Use paths workspace-relative em `write_scopes`. Tasks independentes não podem disputar scopes; modele dependência quando o compartilhamento for intencional.
 - Não calcule hash ou ordem manualmente e não edite o PreparedPlan depois de persistido. Gere nova revisão antes da execução; após materialização, trate correção como rework.

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

@@ -0,0 +1,10 @@
+---
+name: zaip-skill-frontend
+description: Implement accessible frontend experiences and component integration inside apps/frontend. Use for declared frontend delivery that consumes the central design contract without changing it.
+---
+
+# Entregar frontend
+
+1. Confirmar que o escopo está em `apps/frontend/**`; encaminhar tokens, componentes centrais e `DESIGN.md` para o agente de design.
+2. Ler o contrato visual aplicável antes de alterar componentes e preservar acessibilidade, semântica e estados de carregamento/erro.
+3. Validar a interação afetada com teste focado, typecheck ou build proporcional e relatar as evidências do critério de aceite.

package/templates/.agents/skills/zaip-skill-frontend/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "ZAIP Frontend Delivery"
+  short_description: "Implement accessible frontend inside declared product scope."
+  default_prompt: "Use $zaip-skill-frontend to implement an accessible frontend change inside its declared scope."

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

@@ -1,27 +1,53 @@
 ---
 name: zaip-skill-github-deploy
-description: Use only when the user explicitly asks to publish to GitHub with folder-scoped SSH or repair a failed publication in bounded cycles; the policy-authorized demo branch may activate it automatically.
+description: Use only when the user explicitly asks in the current turn to deploy, push, publish, or make a GitHub publication with folder-scoped SSH; it is Git-only and never grants publication automatically.
 ---
 
 # Deploy and repair GitHub publication
 
-Treat deploy as Git-only publication. Provider deployment is separate and requires explicit authorization.
+Treat deploy as Git-only publication. An explicit current-turn request to `deploy`, `push`, `publicar`, `publicação` or GitHub publication selects this skill; it authorizes only the bounded Git publication described below, never a provider deployment or automatic publication.
 
 ## Authorization
 
-- Require an explicit deploy, push, publication, or failed-deploy repair request in the current conversation, unless the current branch is `demo` and the project configuration explicitly grants standing automatic deployment for that branch.
-- The request authorizes the initial publication and up to five repair cycles needed to make required local and remote GitHub checks pass.
+- Require an explicit deploy, push, publicar, publicação, GitHub publication, or failed-deploy repair request in the current turn.
+- The request authorizes the initial publication, bounded reconciliation needed to publish the selected branch, functional commits for the evidenced intended pending scope, and up to five repair cycles needed to make required local and remote GitHub checks pass.
 - Limit repairs to the intended repository state and the evidenced failure. Do not add unrelated features or broaden product scope.
 - Never force push, rewrite history, replace remotes, change credentials or Git/SSH configuration, bypass checks, or deploy to another service.
-- Do not create lifecycle artifacts for an explicit Git-only publication request. A pure deploy/push only performs the deploy preflight, stages/commits the requested pending files, pushes, and verifies the remote hash. If the request also asks to repair code or CI, that repair is separate work and may use the normal ZAIP lifecycle.
+- Do not create lifecycle artifacts for an explicit Git-only publication request. The deploy authorization may stage and commit only the evidenced intended pending scope with explicit pathspecs before publication; it never authorizes unrelated product work.
+- Map a functional group to PRD/SPEC/Task only when evidence exists; otherwise use `[CODEX] <functional title>` without `ZAIP-Task`. Omit nonexistent lineage blocks and trailers. Deploy authorization never permits `git add -A`, broad staging, force, destructive reset, squash, or publication outside the current explicit request.
+
+## Mandatory authorization record
+
+Before the first Git mutation, retain a sanitized authorization record in the task's visible progress and terminal report. It must state:
+
+1. the user's current-turn publication intent;
+2. repository, remote, branch and selected worktree;
+3. whether the grant is simple push or partitioned commit plus push;
+4. the bounded history-reconciliation strategy (`rebase` by default, or user-selected `merge`);
+5. allowed repair cycles, excluded worktrees/scopes and prohibited actions;
+6. the preflight result and the recoverable preservation reference used before reconciliation.
+
+The conversation and terminal deploy report are the authority record for Git-only publication; do not create lifecycle artifacts or store credentials, private-key contents, tokens or environment values. If any required permission is absent, stop at the read-only diagnosis and request only the missing authority.
+
+## Multiple worktrees and divergent history
+
+1. Run `git worktree list --porcelain` and inspect `git status --porcelain` in every existing worktree before staging.
+2. Select exactly one publishing worktree. A clean worktree on another branch or a detached verification worktree does not join the deploy. Preserve a stable dirty worktree and partition only its evidenced intended scope; exclude its alien paths unless the user explicitly includes them.
+3. Stop when another process or agent is actively mutating a shared branch, index, canonical source or generated projection, or when scope is ambiguous.
+4. Prunable or missing worktrees are reported but never pruned automatically. Dirty detached or temporary worktrees are never deleted, reset, stashed or copied into the publishing worktree implicitly.
+5. Fetch once and compute ahead/behind for the publishing branch. If it is behind or diverged, reconcile only the selected branch under this deploy authorization.
+6. Before reconciliation, create a recoverable branch reference and preserve tracked plus untracked changes in a named stash. Verify both references before proceeding. Use `rebase` unless the user explicitly selected `merge`.
+7. Apply the bounded reconciliation without force. Restore with `git stash apply`, retain the stash until publication succeeds, and resolve generated aggregate conflicts by regenerating them from canonical sources.
+8. After restoration, prove that no unmerged paths remain, re-inventory the diff, and only then begin functional partitioning.
 
 ## Repair-loop integrity
 
-- A pure publication cycle is: run deploy preflight, stage, synchronize, commit, push, and verify the remote hash. Do not run project tests, builds, lint, or GitHub checks as part of deploy unless the user explicitly requests validation or a separate repair is in scope.
+- A publication cycle is: run deploy preflight, inventory the intended pending diff, synchronize, create any required functional commits with explicit pathspecs, push, and verify the remote hash. When no intended pending diff exists, publish already-formed commits. Run only gates required or evidenced by repository Rules, the active Change, or failed remote CI.
+- First prove each functional group and its pathspecs from the intended pending diff; stage only that group with explicit paths, commit it, then continue with the next group. A stable mixed worktree is partitioned and preserved; only a moving worktree, ambiguous scope, or unresolved conflict is a terminal blocker.
 - Run each diagnostic, gate, fetch, stage, commit, push, and hash verification at most once per cycle.
 - Start a new cycle only after a repository change or new remote evidence. Never repeat an unchanged failing command hoping for a different result.
 - Continue until all required checks pass or a terminal blocker occurs. Stop after five repair cycles, or when the same root cause remains after two repairs.
-- Treat authentication, unavailable credentials, branch divergence, secret exposure, destructive changes, GitHub outages, and ambiguous scope expansion as terminal blockers.
+- Treat authentication, unavailable credentials, unauthorized branch divergence, secret exposure, destructive changes, GitHub outages, and ambiguous scope expansion as terminal blockers.
 
 ## Prove folder-scoped SSH first
 
@@ -43,20 +69,20 @@ Run preflight once at the start of the authorized deployment. On failure, stop.
    - Turbo cache hits are valid only when the active work did not originate from a failed remote CI gate.
    - When repairing failed CI, reproduce the exact failed gate once per repair cycle with Turbo cache bypassed when applicable.
 4. If a local gate fails, capture the exact failing command and error, make the smallest authorized repair, update lifecycle evidence, and start the next cycle without asking for another deploy authorization.
-5. After all local gates pass, run `git add -A` once for that publication cycle. Inspect `git diff --cached --name-status`, `git diff --cached --stat`, and `git diff --cached --check`. Never force-add ignored files.
+5. After all required local gates pass, partition only the evidenced intended pending diff with explicit pathspecs. If tracked or untracked changes remain outside that scope, stop and identify the Task that must own them; never stage or combine alien changes during deploy.
 
 ## Synchronize and publish each cycle
 
-Fetch the selected remote and current branch once per publication cycle, without SSH overrides. Compute ahead/behind against the fetched ref. Stop when local is behind or diverged; do not merge, rebase, reset, or force.
+Fetch the selected remote and current branch once per publication cycle, without SSH overrides. Compute ahead/behind against the fetched ref. When local is behind or diverged, apply the recorded bounded reconciliation strategy; stop if it cannot be completed safely. Never reset or force.
+
+Commits created during Task execution use `[CODEX|CLAUDE] [P:XXXX] [S:XXXX] [T:XXXX] <Task title>`: the effective executing-agent prefix followed by compact lineage.
 
-Use the executing-agent commit prefix:
+- Codex: `[CODEX] [P:XXXX] [S:XXXX] [T:XXXX] <Task title>`
+- Claude: `[CLAUDE] [P:XXXX] [S:XXXX] [T:XXXX] <Task title>`
 
-- Codex: `[AUTO][CODEX]`
-- Claude: `[AUTO][CLAUDE]`
-- Gemini: `[AUTO][GEMINI]`
-- Roo: `[AUTO][ROO][15 AGENTS]`
+The effective provider is exclusively `CODEX` or `CLAUDE`; `AUTO` is not part of a Task subject. P/S/T blocks are emitted only when their evidence exists; a Task with no PRD or SPEC uses `[Task-first:XXXX]`, and an unattributed functional commit uses `[CODEX] <functional title>` without `ZAIP-Task`. The subject remains ≤96 characters and only its title may truncate at a word boundary. Complete available PRD, SPEC, Task, Change, and Execution IDs remain in `ZAIP-*` trailers. An explicit deploy may create only its evidenced functional commits, without broad staging, force, destructive reset, or squashing.
 
-Commit once and push once per publication cycle. With an upstream, use `git push`; for first publication, use `git push -u <remote> <branch>`. If the index is empty and there is no unpushed commit, report a no-op.
+Push once per publication cycle. With an upstream, use `git push`; for first publication, use `git push -u <remote> <branch>`. If there is no unpushed commit after the bounded reconciliation and functional-commit review, report a no-op.
 
 - If push fails, treat it as terminal unless repository content caused a documented server-side rejection that can be repaired locally.
 - Never switch keys, accounts, remotes, or transport, and never pass SSH/config overrides or force options.

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 com reparos controlados"
-  default_prompt: "Use $zaip-skill-github-deploy para publicar este repositório via SSH da pasta, corrigindo falhas locais ou do CI em ciclos controlados até os checks passarem."
+  short_description: "Publicação GitHub explícita, Git-only e verificável"
+  default_prompt: "Use $zaip-skill-github-deploy somente para um pedido explícito neste turno de deploy, push, publicar ou publicação GitHub; registre a autorização, inventarie todos os worktrees, reconcilie com segurança apenas o worktree selecionado e publique somente o escopo evidenciado via SSH da pasta."
 policy:
   allow_implicit_invocation: true

package/templates/.agents/skills/zaip-skill-github-deploy/scripts/github-deploy-contract.test.mjs

@@ -0,0 +1,80 @@
+import assert from "node:assert/strict";
+import { readFile } from "node:fs/promises";
+import { resolve } from "node:path";
+import test from "node:test";
+
+const root = resolve(import.meta.dirname, "..", "..", "..");
+const skillRoot = resolve(root, "skills", "zaip-skill-github-deploy");
+
+test("explicit Git publication verbs select the guarded deploy skill", async () => {
+  const [skill, openai, core] = await Promise.all([
+    readFile(resolve(skillRoot, "SKILL.md"), "utf8"),
+    readFile(resolve(skillRoot, "agents", "openai.yaml"), "utf8"),
+    readFile(resolve(root, "rules", "core.md"), "utf8"),
+  ]);
+
+  assert.match(
+    skill,
+    /explicit current-turn request to `deploy`, `push`, `publicar`, `publicação`/,
+  );
+  assert.match(skill, /never grants publication automatically/);
+  assert.doesNotMatch(skill, /standing automatic deployment|activate it automatically/);
+  assert.match(openai, /\$zaip-skill-github-deploy/);
+  assert.match(
+    openai,
+    /pedido explícito neste turno de deploy, push, publicar ou publicação GitHub/,
+  );
+  assert.match(
+    core,
+    /Pedido explícito no turno de `deploy\|push\|publicar\|publicação GitHub` seleciona `\$zaip-skill-github-deploy`/,
+  );
+});
+
+test("deploy guidance preserves the canonical Task subject and Git-only boundary", async () => {
+  const [skill, workflow] = await Promise.all([
+    readFile(resolve(skillRoot, "SKILL.md"), "utf8"),
+    readFile(resolve(root, "rules", "workflow.md"), "utf8"),
+  ]);
+  const subject = "[CODEX|CLAUDE] [P:XXXX] [S:XXXX] [T:XXXX] <Task title>";
+
+  assert.ok(skill.includes(subject));
+  assert.match(skill, /exclusively `CODEX` or `CLAUDE`; `AUTO` is not part/);
+  assert.match(skill, /P\/S\/T blocks are emitted only when their evidence exists/);
+  assert.match(skill, /\[Task-first:XXXX\]/);
+  assert.match(skill, /Git-only publication/);
+  assert.match(workflow, /assunto é ≤96 e só o título reduz por palavra/);
+  assert.match(workflow, /formar commits funcionais apenas do diff pretendido\/evidenciado/);
+  assert.doesNotMatch(workflow, /deploy\/push simples publica somente commits formados/);
+});
+
+test("every explicit deploy authorizes bounded reconciliation and functional commits with pathspecs", async () => {
+  const skill = await readFile(resolve(skillRoot, "SKILL.md"), "utf8");
+
+  assert.match(skill, /bounded reconciliation needed to publish the selected branch/);
+  assert.match(skill, /functional commits for the evidenced intended pending scope/);
+  assert.match(skill, /Use `rebase` unless the user explicitly selected `merge`/);
+  assert.match(skill, /explicit pathspecs/);
+  assert.match(skill, /without `ZAIP-Task`/);
+  assert.match(skill, /never permits `git add -A`/);
+  assert.match(skill, /stable mixed worktree is partitioned and preserved/);
+  assert.match(
+    skill,
+    /moving worktree, ambiguous scope, or unresolved conflict is a terminal blocker/,
+  );
+});
+
+test("deploy permission and multi-worktree reconciliation are explicit and recoverable", async () => {
+  const [skill, openai] = await Promise.all([
+    readFile(resolve(skillRoot, "SKILL.md"), "utf8"),
+    readFile(resolve(skillRoot, "agents", "openai.yaml"), "utf8"),
+  ]);
+
+  assert.match(skill, /Mandatory authorization record/);
+  assert.match(skill, /repository, remote, branch and selected worktree/);
+  assert.match(skill, /`rebase` by default, or user-selected `merge`/);
+  assert.match(skill, /recoverable branch reference/);
+  assert.match(skill, /preserve tracked plus untracked changes in a named stash/);
+  assert.match(skill, /Restore with `git stash apply`/);
+  assert.match(skill, /Prunable or missing worktrees are reported but never pruned automatically/);
+  assert.match(openai, /registre a autorização, inventarie todos os worktrees/);
+});

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

@@ -69,7 +69,7 @@ Back up a configuration file before changing it, bound edits to the selected ide
 
 ## Create the first commit
 
-An explicit request for initialization or first commit authorizes `git add -A` and one local commit, including new files, after ignore/secret/size/diff gates pass. Use the agent prefix table from the repository's deploy policy, defaulting to `[AUTO][<AGENT>]`. Do not push merely because a commit was created.
+An explicit request for initialization or first commit authorizes `git add -A` and one local commit, including new files, after ignore/secret/size/diff gates pass. When that commit closes a Task, use the repository's canonical Task subject (`[CODEX|CLAUDE] [P:XXXX] [S:XXXX] [T:XXXX] <Task title>`); an initialization commit without a Task must not pretend to satisfy the Task-commit contract. Do not push merely because a commit was created.
 
 ## Publish only when explicit
 

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

@@ -0,0 +1,10 @@
+---
+name: zaip-skill-marketing
+description: Plan evidence-grounded marketing strategy, copy, campaigns, assets, and image briefs. Use for a declared marketing objective; do not use for generic website, product frontend, or central design-system implementation.
+---
+
+# Planejar marketing
+
+1. Delimitar público, objetivo, canal, mensagem, evidência disponível e métrica de sucesso.
+2. Produzir estratégia, copy, campanha, ativos ou briefing de imagem proporcionais ao objetivo; distinguir fatos fornecidos de hipóteses.
+3. Encaminhar website para Jonny, frontend de produto para Doug e regra visual central para Manu quando o escopo não for marketing.

package/templates/.agents/skills/zaip-skill-marketing/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "ZAIP Marketing Strategy"
+  short_description: "Plan grounded marketing strategy, copy, and campaign assets."
+  default_prompt: "Use $zaip-skill-marketing to plan a grounded marketing strategy, copy, or campaign asset."

package/templates/.agents/skills/zaip-skill-move-prd/SKILL.md

@@ -15,9 +15,9 @@ Use apenas comandos canônicos ZAIP. Não edite status diretamente no frontmatte
 
 ## Identificar o movimento
 
-1. Resolva o PRD por ID e inspecione seu estado com `node .zaip-aios/bin/zaip.mjs prd show <PRD-ID> --json`.
-2. Trate “finalizar”, “concluir” e “entregar” como `deliver`; trate “cancelar” e “abandonar” como `cancel`.
-3. Trate “mova/coloque em Pronto para Executar” como `prd ready`. Trate “execute/inicie a execução” como autorização para preparar, se necessário, e então usar `prd execute`; não simule transições com edição de arquivo.
+1. Resolva o PRD por ID e inspecione seu estado com `node .agents/runtime/bin/zaip.mjs prd show <PRD-ID> --json`.
+2. Trate “entregar” como `deliver`; “finalizar”, “concluir”, `finalize` e `conclude` são aliases sensíveis ao estado: em `draft|ready` lapidam PRD/SPECs/blueprints e levam somente a `ready`; em `active` continuam Tasks e gates. Nunca pule para `deliver`; trate “cancelar” e “abandonar” como `cancel`.
+3. Trate “mova/coloque em Pronto para Executar”, `pronto` e `ready-to-execute` como `prd ready`. Trate “execute/inicie a execução” como autorização para preparar, se necessário, e então usar `prd execute`; não simule transições com edição de arquivo.
 
 ## Aplicar a política parental
 
@@ -25,13 +25,17 @@ Use apenas comandos canônicos ZAIP. Não edite status diretamente no frontmatte
 - Descendentes já `delivered`, `completed`, `failed` ou `cancelled` permanecem imutáveis.
 - `prd deliver <PRD-ID>` entrega SPECs ativas somente após os gates provarem que Changes, Tasks, Executions, Runs, Acceptance Criteria e Evidences estão concluídos. Nunca converta descendentes incompletos em sucesso.
 - `prd prepare <PRD-ID> --plan <plano>` valida e persiste o plano, mas preserva `draft` e a coluna Definição.
-- `prd ready <PRD-ID>` exige PreparedPlan, move o PRD para `ready` e promove somente as SPECs selecionadas pelo plano.
-- `prd execute <PRD-ID>` materializa o PreparedPlan e ativa apenas as SPECs selecionadas; um pedido explícito de execução permite esse caminho a partir de `draft` preparado.
+- `prd ready <PRD-ID>` exige PreparedPlan, move o PRD para `ready`, promove somente as SPECs selecionadas pelo plano e, na mesma operação idempotente, materializa Execution, Changes e Tasks `planned`, sem ativá-las.
+- `prd execute <PRD-ID>` persiste a continuação da materialização já pronta e ativa apenas as SPECs selecionadas; um pedido explícito de execução permite esse caminho a partir de `draft` preparado.
 - Um PRD `draft` precisa ser preparado antes de `ready` ou `execute`; não force `active` sem plano e SPECs válidas.
+- `execute` no PRD executa todas as SPECs selecionadas; pedido dirigido a uma SPEC ou Task usa esse menor grão.
+- `implemente`: sem PRD em foco cria planejamento; em `draft` finaliza o plano sem executar; em `ready` autoriza `execute`; em `active` continua; em `blocked|failed` usa resume/rework.
+- `desenvolva|melhore|aprimore` sempre cria refinamento ou rework e nunca executa automaticamente. Preserve snapshots e tentativas; depois do novo plano, exija nova promoção.
+- PRD `cancelled` é imutável. Use `prd rework <ID-CANCELADO>` para criar sucessor `draft` com tag `rework` e vínculo `rework_of_prd_id`; nunca reabra ou reescreva o cancelado.
 
 ## Verificar
 
 1. Leia novamente o PRD e liste SPECs com `spec list --prd <PRD-ID> --json`.
-2. Após `prepare`, confirme que PRD e SPECs continuam `draft`; após `ready`, confirme que apenas as selecionadas ficaram `ready`.
+2. Após `prepare`, confirme que PRD e SPECs continuam `draft`; após `ready`, confirme que apenas as selecionadas ficaram `ready` e que Execution, Changes e Tasks permanecem `planned`.
 3. Confirme no resultado do cancelamento os arrays `cascade.specs`, `cascade.tasks`, `cascade.changes` e `cascade.executions`.
 4. Se um descendente aberto permanecer fora da cascata, pare e reporte vínculo quebrado; não o associe por semelhança de título.

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

@@ -15,9 +15,9 @@ Use apenas comandos canônicos ZAIP. Não edite status diretamente no frontmatte
 
 ## Identificar o movimento
 
-1. Resolva a SPEC por ID e inspecione seu estado com `node .zaip-aios/bin/zaip.mjs spec show <SPEC-ID> --json`.
-2. Trate “finalizar”, “concluir” e “entregar” como `deliver`; trate “cancelar” e “abandonar” como `cancel`.
-3. Trate “mova/coloque em Pronto para Executar” como `spec ready`. Trate “execute/inicie a execução” como autorização para preparar, se necessário, e então usar `spec execute`.
+1. Resolva a SPEC por ID e inspecione seu estado com `node .agents/runtime/bin/zaip.mjs spec show <SPEC-ID> --json`.
+2. Trate “entregar” como `deliver`; “finalizar”, “concluir”, `finalize` e `conclude` são aliases sensíveis ao estado: em `draft|ready` lapidam a SPEC e seus blueprints e levam somente a `ready`; em `active` continuam Tasks e gates. Nunca pule para `deliver`; trate “cancelar” e “abandonar” como `cancel`.
+3. Trate “mova/coloque em Pronto para Executar”, `pronto` e `ready-to-execute` como `spec ready`. Trate “execute/inicie a execução” como autorização para preparar, se necessário, e então usar `spec execute`.
 
 ## Aplicar a política parental
 
@@ -25,14 +25,17 @@ Use apenas comandos canônicos ZAIP. Não edite status diretamente no frontmatte
 - Descendentes já `completed`, `failed` ou `cancelled` permanecem imutáveis.
 - `spec deliver <SPEC-ID>` só entrega após os gates provarem conclusão das Tasks, Changes, Executions, Runs, Acceptance Criteria e Evidences. Nunca marque Tasks incompletas como concluídas.
 - `spec prepare <SPEC-ID> --plan <plano>` valida e persiste o plano, mas preserva `draft` e a coluna Planejamento.
-- `spec ready <SPEC-ID>` exige PreparedPlan e move somente a SPEC para `ready`.
-- `spec execute <SPEC-ID>` materializa seu PreparedPlan; um pedido explícito de execução permite esse caminho a partir de `draft` preparado, e uma SPEC governada pelo plano global de um PRD não cria uma Execution duplicada.
+- `spec ready <SPEC-ID>` exige PreparedPlan, move somente a SPEC para `ready` e, na mesma operação idempotente, materializa seu PreparedPlan em Execution, Changes e Tasks `planned`, sem ativá-las.
+- `spec execute <SPEC-ID>` persiste a continuação da materialização pronta e a ativa; um pedido explícito de execução permite esse caminho a partir de `draft` preparado, e uma SPEC governada pelo plano global de um PRD não cria uma Execution duplicada.
 - Não altere o PRD pai ao mover apenas uma SPEC.
+- `execute` na SPEC executa somente sua DAG interna; pedido dirigido a uma Task usa esse menor grão.
+- `implemente` em `draft` finaliza o plano sem executar; em `ready` autoriza `execute`; em `active` continua; em `blocked|failed` usa resume/rework.
+- `desenvolva|melhore|aprimore` sempre cria refinamento ou rework, preserva snapshots/tentativas e nunca executa automaticamente.
 
 ## Verificar
 
 1. Leia novamente a SPEC após o comando.
-2. Após `prepare`, confirme que a SPEC continua `draft`; após `ready`, confirme que somente ela ficou `ready`.
+2. Após `prepare`, confirme que a SPEC continua `draft`; após `ready`, confirme que somente ela ficou `ready` e que Execution, Changes e Tasks permanecem `planned`.
 3. Confirme no resultado do cancelamento os arrays `cascade.tasks`, `cascade.changes` e `cascade.executions`.
 4. Verifique que SPECs irmãs e suas Tasks não mudaram.
 5. Se uma Task aberta permanecer fora da cascata, pare e reporte vínculo quebrado; não a associe por título.

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

@@ -20,5 +20,5 @@ Escolha um modo: `record`, `analyze` ou `reconcile`.
 1. Filtre primeiro com `zaip run list --prd|--spec|--task|--execution|--change ... --status ... --from ... --to ... --limit ...`; use `run show` apenas nas Runs selecionadas.
 2. Agregue sem dupla contagem com `zaip run aggregate` e o mesmo filtro de escopo. Task soma Runs atribuídas; SPEC e PRD somam descendentes identificados.
 3. Exponha conversa, planejamento, execução, total, `new/rework`, cobertura de tokens e cobertura de preço. Compare resultado, duração, tentativas, AC/evidência e assertividade junto do custo.
-4. Reconcilie a mesma semântica no dashboard/Kanban e Zaip Cost Monitor, incluindo abas e contagens separadas de Runs e Sub-Runs, finalizadores, identidade `zaip-agent-*`, modelo/effort planejados, configuração efetiva, Calls conhecidas, tokens por segmento e concentração top-10. Divergência é finding; não injete JSONL bruto nem crie índice de conteúdo persistente. As projeções lifecycle descartáveis em `.agents/projections/runtime` são autorizadas.
+4. Reconcilie a mesma semântica no dashboard/Kanban e Zaip Cost Monitor, incluindo abas e contagens separadas de Runs e Sub-Runs, finalizadores, identidade `zaip-agent-*`, modelo/effort planejados, configuração efetiva, Calls conhecidas, tokens por segmento e concentração top-10. Divergência é finding; não injete JSONL bruto. Use somente os manifests Git-native em `.agents/records/lifecycle` e os manifests de telemetria; temporários ficam em `.local`.
 5. Reconciliação de telemetria pode ser auditada separadamente; reconciliação global de lifecycle só roda pelo popup confirmado ou por comando humano explícito. Nunca adicione varredura por turno, intervalo ou abertura do dashboard.