@zaip-ai/cli 1.0.8 → 1.3.1

package/templates/.agents/skills/zaip-skill-brand-governance/references/brandbook-standards.md

@@ -6,7 +6,7 @@ Use este roteiro quando o pedido exigir a plataforma ou o Brandbook da marca.
 
 Registre os treze domínios: cultura da empresa e da marca; posicionamento e plataforma; Brandbook interno e externo; arquitetura e portfólio; modelo e diretrizes de gestão; RACI e equipe de marca; procedimentos; sistema de identidade; manuais de identidade; pontos de contato; stakeholders; métricas e avaliações; e brand equity.
 
-O Brandbook Mestre também registra controle do documento; história; mercado; público e personas; promessa e diferenciais; DNA, atributos e personalidade; tom de voz; arquitetura; identidade verbal e visual; evidências e decisões.
+O Brandbook também registra controle do documento; história; mercado; público e personas; promessa e diferenciais; DNA, atributos e personalidade; tom de voz; arquitetura; identidade verbal e visual; evidências e decisões.
 
 Cada decisão material deve informar proprietário, aprovador, versão, data, evidência e classificação de confidencialidade. Conteúdo proprietário de terceiros serve como referência metodológica, nunca como conteúdo reutilizável.
 

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

@@ -9,7 +9,7 @@ description: Maintain Change narrative, decisions, evidence, rollback, and resul
 2. Antes da primeira mutação, confirme que a Change existe e que sua origem é Task, SPEC ou PRD real.
 3. Mantenha `change.md` como narrativa viva: plano, implementação, decisões, evidências, evals, testes e resultado.
 4. Atualize em marcos relevantes, não a cada comando; derive a lista final de arquivos do Git diff.
-5. Relacione cada evidência à Task e aos Acceptance Criteria que ela comprova.
+5. Relacione cada evidência à Task e aos Acceptance Criteria que ela comprova. Para planejar, registrar ou avaliar prova de entrega, leia [o contrato de prova observável](references/observable-evidence.md); concentre ali cenários, estados, fallbacks e validade, sem duplicar relatórios.
 6. Registre decisões curtas na seção principal; use `decisions/` ao lado da Change somente para decisões consequenciais que mereçam histórico próprio.
 7. Para risco `critical`, mantenha anexos de threat model, rollout e rollback; para riscos menores, prefira seções inline.
 8. Antes de concluir, elimine placeholders, registre desvios/rework, comprove todos os ACs e resuma o resultado observado.

package/templates/.agents/skills/zaip-skill-change/references/observable-evidence.md

@@ -0,0 +1,83 @@
+# Prova observável por critério de aceite
+
+Contrato operacional de `REQ-WORK-002`, compartilhado por execução, frontend, backend e revisão. Use para entregas novas ou verificações explicitamente retomadas; não reabra nem reclassifique entregas históricas.
+
+## Preparar a prova
+
+Antes de implementar, identifique para cada AC o cenário discriminante, a expectativa, a modalidade necessária e o ambiente autorizado. Comece pelo cenário de maior risco quando isso permitir detectar uma direção errada cedo. Não exija uma bateria completa por captura nem use duração isolada como prova de falha.
+
+Registre uma observação com vínculos Task/Change/Execution/Run/AC, procedimento ou cenário, expectativa, resultado observado, momento real da observação, ambiente, candidato efetivamente executado, locators e limitações. Dados indisponíveis permanecem explícitos; horário de registro não deve ser apresentado como horário de execução.
+
+Uma observação é produzida uma vez e referenciada pela Validation/Evidence existente. Não duplique logs, screenshots ou relatórios. Uma mesma execução pode apoiar vários ACs, desde que seu resultado seja explicado para cada um. Quantidade, screenshot existente, banco com uma linha ou ausência de erro não comprovam o resultado solicitado isoladamente.
+
+## Escolher o procedimento pelo impacto
+
+| Impacto do AC | Observação necessária |
+| --- | --- |
+| Visual | Captura real da aplicação atualizada, preferencialmente pelo navegador integrado disponível. Reproduza rota, aba, filtros, período e estado pedidos; registre URL, horário, viewport e versão carregada. Examine a imagem contra a expectativa e registre quem examinou e o resultado. Imagem gerada, render de teste, API e código não substituem essa prova. |
+| Interação frontend | Execute a interação e confira o efeito. Persistência, dados, acessibilidade e desempenho exigem comprovação própria quando fazem parte do AC; screenshot é complementar. |
+| Estrutura/migração | Compare metadados reais com o contrato: colunas, tipos, índices e restrições pertinentes. |
+| Persistência | Execute o fluxo autorizado e consulte somente os registros necessários, incluindo valores, relacionamentos e ausências esperadas. |
+| Correção de erro | Reproduza o cenário, examine logs disponíveis e correlacione o resultado com os logs posteriores. Ausência de prova anterior é limitação explícita, não um resultado inventado. |
+| API/fila/cache/integração | Observe diretamente entrada, saída e efeito no componente. Não exija SQL quando ele não se aplica. |
+| Fluxo entre frontend e backend | Relacione a ação da interface ao efeito correspondente por identificador de cenário, requisição, operação ou registro. Testes isolados continuam sendo provas de camada, não E2E automático. |
+
+Não imponha produção se o AC admitir ambiente representativo. Se exigir produção, prova de outro ambiente permanece limitada. Para ambiente representativo ou dependências reais isoladas, declare as diferenças que podem afetar o resultado. Mocks e análise estática só confirmam as alegações que realmente exercitam.
+
+## Estados e aprovação
+
+| Estado da observação | Consequência |
+| --- | --- |
+| `confirmed` | Prova suficiente para a alegação e ambiente declarados; pode complementar a aprovação, mas não substitui os gates existentes. |
+| `limited` | Prova parcial; explicitar o que confirmou e o que falta. Não aprova a parcela sem comprovação. |
+| `pending` | Verificação ainda não realizada ou indisponível. Informar motivo, ACs, tentativas, dependência e próximo procedimento. |
+| `failed` | Resultado observado diverge da expectativa. Exige correção governada e nova prova; não trocar de ambiente só para obter verde. |
+| `not_applicable` | Modalidade sem relação com o AC/escopo, com justificativa objetiva; não equivale a aprovar o AC. |
+
+Falha de ferramenta é pendência, não reprovação do produto. Não registre `passed` para ausência de captura, timeout de ferramenta, mocks insuficientes ou N/A. Se faltar prova obrigatória, mantenha o aceite dependente pendente e encerre a tentativa como `blocked` quando necessário; preserve a implementação e prossiga apenas com trabalho independente. Não deixe uma Task em execução indefinida para ocultar o bloqueio.
+
+## Fallback finito
+
+Para a mesma capacidade e condição bloqueadora, registre no máximo três tentativas: uma inicial, no máximo uma repetição após ação concreta de recuperação e no máximo uma alternativa já disponível e permitida. A repetição sem mudança observável não é autorizada. Uma alternativa não exige repetir antes um mecanismo sabidamente indisponível.
+
+| Indisponibilidade | Alternativa e resultado |
+| --- | --- |
+| Navegador integrado | Após recuperação concreta e única repetição, tente uma captura real por outro mecanismo disponível e permitido; registre qual. Não instale ferramentas, altere permissões ou contorne controles. |
+| Nenhuma captura possível | Registre “validação visual pendente por indisponibilidade da ferramenta”; preserve prova técnica sem chamá-la visual. |
+| Banco/serviço/log | Uma alternativa representativa ou integração com dependências reais isoladas, dentro da autoridade existente. Se a equivalência não satisfizer o AC original, registre prova limitada e pendência restante. |
+| Somente mocks/estática | Registre alcance limitado para alegações de funcionamento real; não transforme falta de acesso em N/A. |
+| Limite atingido | Registre dependência, procedimento de retomada e ACs afetados; não entre em loop nem repita pedidos de confirmação. |
+
+ACs que compartilham a mesma falha de ferramenta compartilham o diagnóstico e não multiplicam tentativas. Trocar de Run não zera esse histórico. Verificação longa ainda em progresso não é uma nova tentativa nem deve ser interrompida só pelo relógio; use os limites operacionais existentes.
+
+## Proteção e retomada
+
+Use somente ambientes autorizados, dados mínimos e locators sanitizados. Remova credenciais, tokens, parâmetros sensíveis de URLs, dados pessoais desnecessários e segredos dos materiais antes do registro. Não execute escritas em produção para obter prova sem autoridade específica. Hash identifica conteúdo, não demonstra autenticidade da observação.
+
+Reavalie validade quando mudarem candidato executável, schema, configuração, permissões, flags, dependências, dados relevantes, período, viewport, cenário ou AC. Não infira ambiente equivalente apenas do commit. Preserve observações antigas como histórico e registre o delta, sem reescrever horários ou autoria.
+
+O recorte atual não autoriza reuso aprovador entre Runs, nova rota de retomada nem dispensa revisão/finalização. `task resume` e `execution run --recheck-blocked-state` conservam seus contratos; a rechecagem autônoma exige candidato novo e não reinicia orçamento. Se apenas uma ferramenta voltou com candidato igual, registre a pendência resolvida na tentativa autorizada e mantenha os vínculos exigidos; não finja que uma prova antiga foi executada de novo.
+
+## Limite de automação
+
+A política define o que o executor e o revisor devem comprovar. O registro CLI valida estrutura e vínculos; ele não executa o comando declarado, não examina pixels e não consulta banco automaticamente. Observações referenciadas por uma aprovação devem ser confirmadas e compatíveis; observação isolada não aprova. Históricos V2 sem observações permanecem legíveis e não são promovidos retroativamente a prova visual ou de produção.
+
+## Registrar sem duplicar a prova
+
+`validation observe` aceita um objeto JSON `EvidenceObservationV1` diretamente em `--observation`, com limite de 256 KiB UTF-8 (o shell pode impor limite menor). A CLI não abre arquivos de entrada; `--observation-file` não é suportado. Essa escolha evita introduzir uma nova superfície de leitura de arquivos/reparse points nesta fatia. O comando grava exclusivamente um novo `artifacts/observations/OBS-*.md` na Change vinculada, sem alterar o estado da Task ou criar Validation aprovada. IDs e vínculos devem existir; exemplos abaixo são placeholders, não resultados executados.
+
+```text
+zaip validation observe --observation '<objeto JSON sanitizado com os campos abaixo>' --json
+zaip validation record --id TEST-CENARIO --task TASK-ID --acceptance AC-ID --command "procedimento realmente executado" --outcome passed --locators caminho/relatorio --run RUN-ID --commit SHA --executed-at ISO --asserted-outcome "resultado observado para o AC" --json
+zaip evidence record --id EVD-CENARIO --task TASK-ID --summary "alcance comprovado" --outcome passed --run RUN-ID --validation TEST-CENARIO --observations OBS-CENARIO --json
+```
+
+O JSON usa `schema_version: 1`, `id`, `task_id`, `change_id`, `execution_id`, `run_id`, `acceptance_ids`, `proof_kind`, `state`, `scenario`, `expected`, `observed`, `observed_at`, `examiner_id`, `commit_sha`, `candidate_version`, `environment`, `visual`, `correlation_ids`, `locators`, `limitations`, `not_applicable_reason`, `pending_reason`, `dependency`, `resume_plan` e `attempts`. Consulte o schema e os exemplos testados em `packages/specs/src/assurance/artifacts.ts` e `assurance-contract.test.ts`; não invente campos V2. A versão candidata identifica o artefato efetivamente observado; o SHA Git continua sendo o vínculo exigido pelo assurance.
+
+`environment` descreve classe, identificador e versão. Estado `confirmed` exige versões observadas do candidato e do ambiente; sem elas, registre limitação/pendência, não um valor presumido. Integração confirmada exige `correlation_ids` do cenário; API ou persistência isoladas não exigem correlação artificial. Prova visual confirmada também exige `visual.url`, `viewport` no formato `1366x768`, `captured_at`, `loaded_version` igual a `candidate_version` e `examination`. Use URL base sem credenciais, query ou fragmento; registre filtros e estado relevantes no cenário sanitizado, nunca tokens de acesso. Preencha indisponibilidade com `null` nos campos permitidos, sem atribuir uma observação inexistente a produção.
+
+`validation record` também admite `failed` e `not_applicable` (este exige `--reason`); esses registros não alimentam Evidence aprovada. Informe `--executed-at` e `--asserted-outcome` nas novas entregas. A omissão desses campos conserva o comportamento legado e não demonstra que a CLI executou um teste naquele horário. Pendência de ferramenta usa `validation observe`, não `failed` de produto.
+
+`evidence record --observations` e a leitura de assurance conferem estado confirmado, identidade do arquivo e os vínculos de Task/Change/Execution/Run/AC/candidato. A lista de ACs da observação pode ser um subconjunto da Evidence: uma observação não comprova implicitamente os demais ACs. Observações sem referência ficam como histórico e não contam para aprovação. A seleção e suficiência de todas as modalidades obrigatórias continuam sendo responsabilidades do executor/revisor; este recorte não implementa detecção automática de obrigação visual, invalidação global por ambiente ou contador de tentativas entre Runs.
+
+A compatibilidade preserva o formato V2 e a leitura histórica, não a aplicação deste contrato por clientes antigos. Não use um downgrade da CLI para qualificar observações novas nem interprete um `passed` legado como certificação deste contrato.

package/templates/.agents/skills/zaip-skill-dashboard-diagnostics/SKILL.md

@@ -0,0 +1,22 @@
+---
+name: zaip-skill-dashboard-diagnostics
+description: Diagnose a served ZAIP dashboard incident across launcher, SQLite snapshot, API, UI preset, and browser evidence; use for stale, slow, or inconsistent dashboard behavior.
+---
+
+# Diagnose a served dashboard
+
+Use for a reported dashboard regression, not for generic database rebuilding.
+
+1. Capture the affected route, tab, filter/preset, expected value, and time range.
+   Validate that exact path rather than a generic health response.
+2. Identify the launcher-owned process and runtime generation without terminating
+   another task's healthy session. Check health, served artifact, API payload, and
+   SQLite snapshot as distinct evidence layers.
+3. Rebuild or compare the disposable read model only when source/snapshot drift is
+   evidenced. Use `$zaip-skill-sqlite-read-model` for that operation.
+4. Compare displayed metrics with factual telemetry/read-model facts, explaining
+   rounding and unavailable values. Do not invent missing work or duration.
+5. Measure the served launcher/runtime flow for performance. A source-only query or a
+   failed browser setup is not browser proof.
+6. If code changes are requested, use the appropriate delivery skill; diagnostics do
+   not authorize a mutation or lifecycle closure.

package/templates/.agents/skills/zaip-skill-dashboard-diagnostics/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "ZAIP Dashboard Diagnostics"
+  short_description: "Trace served dashboard failures with layered evidence."
+  default_prompt: "Use $zaip-skill-dashboard-diagnostics to diagnose this ZAIP dashboard regression using the exact affected tab, preset, API, snapshot, and browser evidence."

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

@@ -5,6 +5,8 @@ description: Enforce ZAIP module boundaries, dependency direction, composition r
 
 # Enforce architecture
 
+O documento canônico de arquitetura é `.agents/architecture/software-architecture.md`. Ao criar ou atualizar a arquitetura, crie `.agents/architecture/` quando ausente e escreva somente esse arquivo, sempre com o nome em minúsculas. Em qualquer pergunta, auditoria ou necessidade de consultar arquitetura, abra primeiro esse arquivo exato. Jamais infira seu conteúdo nem crie cópias ou duplicatas em `docs/` ou em outro local.
+
 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.

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

@@ -12,7 +12,7 @@ Use esta skill somente quando o usuário pedir execução. `prepare` não autori
 3. A partir da tentativa explícita de `execute`, classifique uso como `execution`; inicie Execution, Changes, Tasks elegíveis e Runs com atribuição ao nível de entrada (`task`, `spec` ou `prd`). Ausência de diff não retroage a fase: registre `changed_files` vazio e o resultado real.
 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.
+6. Registre decisões humanas/IA, uso por fase, evidências por AC, testes, evals e arquivos alterados. Antes de implementar, aplique [o contrato de prova observável](../zaip-skill-change/references/observable-evidence.md): cenário, expectativa, ambiente autorizado, prova necessária e fallback finito. Falta de prova obrigatória impede aceite, não trabalho independente.
 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.

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

@@ -1,10 +1,11 @@
 ---
 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.
+description: Implement accessible frontend experiences in apps/frontend and dashboard React surfaces, without changing runtime or SQLite.
 ---
 
 # Entregar frontend
 
-1. Confirmar que o escopo está em `apps/frontend/**`; encaminhar tokens, componentes centrais e `DESIGN.md` para o agente de design.
+1. Confirmar `apps/frontend/**` ou dashboard React (`.agents/dashboard/apps/frontend/**`, `.agents/dashboard/modules/**/src/react/**`); nunca autoriza runtime, SQLite ou server.
 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.
+3. Aplicar [o contrato de prova observável](../zaip-skill-change/references/observable-evidence.md): definir cenário/expectativa por AC, executar a interação afetada e conferir seu efeito; teste, typecheck e build são proporcionais e não substituem comportamento observado.
+4. Se houver impacto visual, obter e examinar screenshot real da versão carregada no estado pedido. No dashboard, preservar render determinístico e verificação do bundle servido. Indisponibilidade segue o fallback finito: mantém o AC visual pendente, não invalida prova técnica independente nem autoriza aprovação integral.

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

@@ -1,4 +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."
+  short_description: "Implement accessible apps/frontend and dashboard React surfaces."
+  default_prompt: "Use $zaip-skill-frontend for apps/frontend or dashboard React; never runtime, SQLite, or server."

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

@@ -12,11 +12,11 @@ Treat deploy as Git-only publication. An explicit current-turn request to `deplo
 ## Authorization
 
 - 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, reconciliation needed to publish the selected branch, commits covering all versionable pending changes in the selected worktree, and up to five repair cycles needed to make required local and remote GitHub checks pass.
+- The request authorizes the initial publication, automatic reconciliation needed to publish the selected branch, commits covering all versionable pending changes in the selected worktree, and up to five repair cycles needed to make required local and remote GitHub checks pass. Do not stop merely because the worktree is dirty, history is behind/diverged, generated files are pending, or a local gate has a repairable failure.
 - 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. The deploy authorization permits staging the complete selected worktree with `git add -A` after secret, size, and ignore checks; it never authorizes changes outside that worktree.
-- 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. Broad staging is authorized only by the exact current-turn deploy request; force, destructive reset, history rewrite, and credential changes remain prohibited.
+- Do not create lifecycle artifacts for an explicit Git-only publication request. The deploy authorization permits staging every inventoried versionable path in the selected worktree after secret, size, and ignore checks; it never authorizes changes outside that worktree.
+- 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. Complete inventoried-path staging is authorized only by the exact current-turn deploy request; force, destructive reset, history rewrite, and credential changes remain prohibited.
 
 ## Mandatory authorization record
 
@@ -37,19 +37,19 @@ The conversation and terminal deploy report are the authority record for Git-onl
 2. Select exactly one publishing worktree. A clean worktree on another branch or a detached verification worktree does not join the deploy. The selected worktree is the complete publication scope.
 3. Report concurrent activity, but do not block solely because the selected worktree is dirty or contains mixed changes; the explicit “faça deploy” authorization includes those changes. Stop only for an unresolved index conflict, secret/oversize file, authentication failure, or destructive/rewrite requirement.
 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.
+5. Fetch once and compute ahead/behind for the publishing branch. If it is behind or diverged, automatically reconcile only the selected branch under this deploy authorization and continue; divergence is not a blocker by itself.
 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.
+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. For ordinary textual conflicts, combine both sides when safe; use the selected worktree's intended version only when the diff and commit history establish that it supersedes the remote version.
+8. After restoration, prove that no unmerged paths remain, re-inventory the diff, and only then begin functional partitioning. Continue automatically through recoverable conflicts and pending repairs; stop only for a genuine terminal blocker defined below.
 
 ## Repair-loop integrity
 
 - 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.
-- Inventory the complete pending diff, run the safety gates, then stage the selected worktree with `git add -A` and commit it. Do not require functional partitioning for this explicit broad-deploy mode.
+- Inventory the complete pending diff, run the safety gates, then stage the reviewed inventory with `git add -- <explicit-pathspecs>` and commit it. Generate pathspecs from the reviewed tracked and untracked inventory; do not use `git add -A`, broad globs, or paths outside the selected worktree. Do not require functional partitioning for this explicit broad-deploy mode.
 - 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, unauthorized branch divergence, secret exposure, destructive changes, GitHub outages, and ambiguous scope expansion as terminal blockers.
+- Treat authentication, unavailable credentials, unresolved conflicts after bounded repair, secret exposure, destructive changes, GitHub outages, and ambiguous scope expansion as terminal blockers. Ordinary branch divergence, dirty state, untracked versionable files, generated projections, lint/format failures, and other repairable pending work are not blockers: repair them within the selected worktree and continue under the same authorization.
 
 ## Prove folder-scoped SSH first
 
@@ -71,11 +71,11 @@ 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 required local gates pass, stage the complete selected worktree with `git add -A`. If a file is secret, oversized, ignored by policy, or outside the selected worktree, exclude it and report the reason; otherwise include it.
+5. After all required local gates pass, stage each reviewed selected-worktree path with `git add -- <explicit-pathspecs>`. If a file is secret, oversized, ignored by policy, or outside the selected worktree, exclude it and report the reason; otherwise include it.
 
 ## 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. When local is behind or diverged, apply the recorded bounded reconciliation strategy; stop if it cannot be completed safely. Never 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 and continue after successful verification; stop only if it cannot be completed safely within the bounded repair cycles. 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.
 

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

@@ -5,6 +5,12 @@ description: Guide data-driven growth strategy, RevOps decisions, experiments, a
 
 # Orientar Growth e RevOps
 
+## Localização canônica
+
+Salve diagnósticos, estratégias, decisões de RevOps, hipóteses de experimento e recomendações de Growth em `.agents/growth/`. Não salve esses artefatos em `docs/`, na raiz do repositório ou em diretórios de brand, marketing ou sales.
+
+O arquivo central da área é `.agents/growth/strategy.md`; atualize-o quando uma decisão mudar a estratégia de Growth ou RevOps. Diagnósticos e experimentos específicos podem ser arquivos adicionais na mesma pasta.
+
 1. Delimite a decisão de negócio, período, segmentos, funil, métricas, restrições e impacto financeiro esperado. Separe fatos observados, cálculo determinístico, hipótese e recomendação.
 2. Examine a ponta a ponta do funil e dos handoffs de RevOps: aquisição, qualificação, conversão, receita, retenção, expansão, custos e capacidade. Não declare causalidade sem desenho ou evidência adequados.
 3. Proponha testes com hipótese, população, métrica primária, guardrails, duração, critério de decisão, risco e responsável. Não execute campanhas, alterações comerciais externas ou experimentos sem a autorização e o escopo correspondentes.

package/templates/.agents/skills/zaip-skill-lifecycle-closure/SKILL.md

@@ -0,0 +1,27 @@
+---
+name: zaip-skill-lifecycle-closure
+description: Diagnose and safely reconcile ZAIP delivery closure when a Task, Change, Execution, or Run is stuck, missing evidence, or receives a late finalizer.
+---
+
+# Close ZAIP lifecycle safely
+
+Use for a named Task, Change, Execution, or Run that failed to converge. Start from
+the supplied ID and canonical record; never scan ordinary history to guess a target.
+
+1. Separate read-only diagnosis from repair. Inspect terminal states, typed Evidence,
+   finalization barrier, observed sub-runs, and lifecycle mutation-lock ownership.
+2. Preserve fast-path execution evidence. A technical test, a finished Run, or a late
+   finalizer alone does not close delivery: missing eligible executor, finalizer, or
+   typed Evidence remains `blocked`.
+3. For a late finalizer, reconcile its exact root and `agent_path`; do not replace it
+   with a shared-session scan. Release lifecycle mutation locking before any
+   usage-attribution reconciliation to avoid capture deadlocks.
+4. Before a mutating recovery, confirm the installed CLI supports the command and
+   require explicit authorization. Reconciliation must be idempotent, scoped to the
+   named active root, and must not create agents or fabricate telemetry.
+5. Persist observed evidence before terminal Task, Change, and Execution state; refresh
+   manifests before the root Run outcome. Report technical success and formal closure
+   separately.
+
+Use `$zaip-skill-reconcile-telemetry` only for missing observed usage after lifecycle
+identity is correct; it is not a substitute for closure.

package/templates/.agents/skills/zaip-skill-lifecycle-closure/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "ZAIP Lifecycle Closure"
+  short_description: "Diagnose and reconcile stuck delivery lifecycle closure."
+  default_prompt: "Use $zaip-skill-lifecycle-closure to diagnose a named ZAIP Task, Change, Execution, or Run that is stuck or missing finalization evidence."

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

@@ -5,6 +5,12 @@ description: Plan evidence-grounded marketing strategy, copy, campaigns, assets,
 
 # Planejar marketing
 
+## Localização canônica
+
+Salve estratégias, campanhas, calendários, briefings, copy aprovada e ativos de marketing em `.agents/marketing/`. Não salve entregáveis de marketing em `docs/`, na raiz do repositório ou em diretórios de brand, sales ou growth.
+
+O arquivo central da área é `.agents/marketing/strategy.md`; atualize-o quando uma decisão mudar a estratégia de marketing. Campanhas e planos específicos podem ser arquivos adicionais na mesma pasta.
+
 1. Delimitar público, objetivo, canal, mensagem, Brandbook aprovado como input somente-leitura, evidência disponível e métrica de sucesso.
 2. Produzir estratégia, copy, campanha, conteúdo, aplicação de marca ou ativo proporcionais ao objetivo; distinguir fatos fornecidos de hipóteses. Copy de marketing ambígua permanece com Lúcia.
 3. Escalar Sarah somente se uma decisão de marca estiver ausente, contraditória ou precisar ser criada; um Brandbook aprovado não redireciona a entrega para Branding. Encaminhar script voltado a vendas para Aaron, estratégia empresarial/RevOps para Robert, website para Jonny, frontend de produto para Doug e regra visual central para Manu.

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

@@ -58,3 +58,7 @@ Durante essa etapa, a Execution universal `interaction` e sua Run raiz continuam
 1. Antes de entregar um PRD, construa a matriz parental completa de ACs e outcomes e produza pelo menos três validações e três Evidences próprias.
 2. As modalidades mínimas são cross-SPEC E2E, spec review e quality review por autor/Run independente, todas no commit final esperado.
 3. Cada outcome possui Evidence explícita. SPECs e Tasks aprovadas são pré-condições, não substitutos para a prova de integração e de resultado no nível do PRD.
+
+# Referência visual condicional
+
+Quando a PRD citar UI ou referência visual, registre rota/aba, família de componente, colunas/linhas/paginação, estados e responsividade como invariantes observáveis, sem prometer prova visual inexistente.