@zaip-ai/cli 1.0.8 → 1.3.1

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

@@ -1,11 +1,11 @@
 b146bd0c7c60b1ab43c4f71e0b1d2262c6df6da6f7053a0425f834ccb77a6b48  LICENSE
 bc02cba77e8d51e5c580f43668863dc868eda66f1ff663bfaa49fcf3ca16320e  THIRD_PARTY_NOTICES.md
-326dd5d8641f399990de42def50ac29eb4c9222601c0a0a3fc3c947dd3bec65d  VERSION
-18dfb11e9ead5ef64ed7da673ec4495e89191b3bf688a762f95b5c481780dd4c  bin/zaip.mjs
-8494e48216496928938b8fbb81c257e8d3fab28eb7a67efda179a21a3767c56c  manifest.json
+64d23f858ef51b0f996e4966d4e27c0371b437e2d2787890b1f7ad22d4ec5663  VERSION
+1e9e3713401dbc4f58f4411a3ff426fe1527c911afe6156a38f9dec18a89f85a  bin/zaip.mjs
+bed6ab1fda844209edc628c2a675021ad6acb9a2f7ecb7ae017b5a916712da24  manifest.json
 7f89219d7c567c82a51679ad136d84364bded7ac659492537e125d33b1d58a7a  migrations/001-layout-v1.json
 5f8c48b286d0b44d8fbb57a9a5d009a8a500439aa3148d750b8f193f72995c9f  migrations/002-layout-v2.json
-98651b1f2883420c624f8d23d05f8de5f2e7cc2d7a21ddce52a30b73966a97bb  pnpm-lock.sha256
-39557a18fa909aab8290cd9812bde0963b76b214f0a361bebaa4804d73f9eb43  provenance.json
-d584b6c4499773b200b0ab5e65f757a51699814614a5cab27c1b34fc604b95fa  sbom.cdx.json
+182a587dca8080f732cb387dbdeff4c12034a4a116efe35b4cd3c1c0a21ad10b  pnpm-lock.sha256
+d2563419aaec124d758f6ff97619ec362eb2b8fd6ea43e0bc50eafe0fbebf97e  provenance.json
+b64130fccf5d6a3a0b33a15efb1ebf1ba8969342da26f4e77d410ed66af60b82  sbom.cdx.json
 b3ffedf9e146be802a15b4009f33e031dec3071ca1525e12c67606fd964a3067  schemas/contracts.schema.json

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

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

package/templates/.agents/runtime/pnpm-lock.sha256

@@ -1 +1 @@
-457d23f9f21aba035f07125d08499bd5476426bf617d1c668e0b412761fb7cc9  pnpm-lock.yaml
+382ebb27a2a951eb61280171c27116233762370d9093ab516caef216475ba4fc  pnpm-lock.yaml

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

@@ -2,10 +2,10 @@
   "schema_version": 1,
   "statement_type": "self_reported_build_integrity",
   "authenticity": "unverified",
-  "version": "1.0.8",
+  "version": "1.3.0",
   "source_origin": "zaip-aios:local-build",
-  "lockfile_sha256": "457d23f9f21aba035f07125d08499bd5476426bf617d1c668e0b412761fb7cc9",
-  "sbom_sha256": "d584b6c4499773b200b0ab5e65f757a51699814614a5cab27c1b34fc604b95fa",
-  "runtime_sha256": "bbc0e89fd10c9d00bf972c76a9f50452e4aa459314e7613516cc33de553a0f27",
-  "statement_sha256": "eb4fb62b34020f90afc6312705f5d20b1c8bc915df9d00ca9ba496817772b879"
+  "lockfile_sha256": "382ebb27a2a951eb61280171c27116233762370d9093ab516caef216475ba4fc",
+  "sbom_sha256": "b64130fccf5d6a3a0b33a15efb1ebf1ba8969342da26f4e77d410ed66af60b82",
+  "runtime_sha256": "bbcdb68da07ece9966046e2d6ce1b54c5218d1318074c65e2de966b8280c02a4",
+  "statement_sha256": "391a666ed4dbc4ce18b481773a40a338bb3298e0bd503e75a0bfc4dea30f6e9c"
 }

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

@@ -6,7 +6,7 @@
     "component": {
       "type": "application",
       "name": "zaip-aios",
-      "version": "1.0.8"
+      "version": "1.3.0"
     }
   },
   "components": [
@@ -4951,8 +4951,8 @@
     {
       "type": "library",
       "name": " nanoid",
-      "version": "3.3.17",
-      "purl": "pkg:npm/%20nanoid@3.3.17"
+      "version": "3.3.18",
+      "purl": "pkg:npm/%20nanoid@3.3.18"
     },
     {
       "type": "library",

package/templates/.agents/sales/playbook.md

@@ -0,0 +1,32 @@
+# Playbook de Sales — Zaip
+
+**Status:** draft interno
+**Oferta:** IA comercial para WhatsApp com processo, CRM e fechamento inteligente.
+
+## ICP inicial
+
+PMEs prestadoras de serviço com pelo menos um vendedor, leads recorrentes e necessidade de converter melhor o tráfego já adquirido. Canal parceiro: agências e consultores próximos da operação comercial do cliente.
+
+## Descoberta
+
+Objetivo: entender origem dos leads, velocidade de resposta, processo atual, gargalos, CRM, volume, ticket, decisão e próximo passo.
+
+Perguntas essenciais:
+
+- Onde os leads se perdem hoje?
+- Quanto tempo a equipe leva para responder?
+- Como qualificam, acompanham e registram oportunidades?
+- Qual etapa comercial mais trava?
+- Quando um humano precisa assumir a conversa?
+
+## Narrativa de valor
+
+A Zaip não é chatbot ou FAQ automático: ela segue o processo comercial, recupera conversas, atualiza o CRM e conduz o lead até pagamento, agendamento ou handoff humano.
+
+## Prova
+
+Usar o case Moradigna como resultado contextualizado — até 11x de ROI no primeiro mês em operação real — sem apresentar como garantia.
+
+## Handoff
+
+Registrar problema, contexto, etapa, decisor, necessidade, timing e próximo compromisso no CRM antes de transferir para closer, implantação ou suporte.

package/templates/.agents/sales/roteiro-comercial-zaip.md

@@ -0,0 +1,252 @@
+# Roteiro comercial da ZAIP
+
+> **Uso interno.** Este roteiro organiza a conversa comercial; ele não autoriza promessa de resultado, desconto, proposta, contrato ou condição comercial. Preencha os campos entre colchetes somente com informações confirmadas e aprovadas.
+
+## Configuração antes do contato
+
+| Campo | Preencher antes da conversa |
+| --- | --- |
+| Oferta | `[oferta ZAIP aprovada]` |
+| ICP e persona | `[segmento, porte, cargo]` |
+| Origem | `[inbound/outbound/parceiro/evento]` |
+| Hipótese inicial | `[problema a explorar, sem presumir que existe]` |
+| Prova autorizada | `[demo, case, documentação ou evidência aprovada]` |
+| Escopo/preço aprovado | `[se aplicável; não inventar]` |
+| Participantes esperados | `[prospect, decisor, técnico, closer]` |
+| Awareness observado | `[desconhecido / problema / solução / produto; registrar fonte]` |
+| Limites de compliance e autoridade | `[limites conhecidos; escalar lacunas]` |
+
+**Regra de evidência:** cada campo do CRM deve registrar `confirmado`, `desconhecido` ou `não aplicável`, além da fonte (pessoa/documento) e da data. Uma hipótese do SDR não vira fato, urgência, budget, autoridade ou prova.
+
+## Etapa 1 — ligação SDR de pré-qualificação (10 minutos)
+
+**Objetivo:** confirmar contexto, dor ou oportunidade, prioridade, contato adequado e permissão para uma conversa de diagnóstico.
+**Dono:** SDR.
+**Saída:** reunião de 60 minutos agendada; nurture; ou not-qualified.
+
+### Agenda de tempo
+
+| Tempo | Objetivo |
+| --- | --- |
+| 0–1 min | Permissão e contexto |
+| 1–3 min | Papel, empresa e cenário atual |
+| 3–7 min | Problema, impacto e prioridade |
+| 7–9 min | Processo decisório e próximo passo |
+| 9–10 min | Recapitulação e encaminhamento |
+
+### Script literal
+
+#### 0–1 min — abertura
+
+> “Oi, [Nome], tudo bem? Aqui é [Seu nome], da ZAIP. Você teve contato com a gente por [origem]. Ainda é um bom momento para conversarmos por até 10 minutos?”
+
+> “Quero entender rapidamente o contexto de vocês e verificar se uma conversa mais aprofundada faz sentido. Se não fizer, eu serei transparente e não vamos forçar um próximo passo. Tudo bem?”
+
+#### 1–3 min — situação
+
+> “Para eu não partir de suposições: qual é sua função e quais áreas ou resultados você influencia?”
+
+> “Como vocês lidam hoje com [tema ligado à oferta]?”
+
+> “O que fez você considerar este assunto agora?”
+
+#### 3–7 min — problema, impacto e valor
+
+> “Há alguma dificuldade ou oportunidade específica que vocês querem resolver nesse processo?”
+
+> “Quando isso acontece, o que muda na operação, no time ou nas decisões?”
+
+> “Essa é uma prioridade imediata, para este trimestre, ou ainda estão explorando possibilidades?”
+
+> “Se encontrassem uma solução adequada, o que precisaria melhorar para ela valer a atenção de vocês?”
+
+#### 7–9 min — decisão e qualificação
+
+> “Além de você, quem normalmente participa da avaliação de uma solução como essa?”
+
+> “Como costuma funcionar a decisão: critérios, validações e próximos responsáveis?”
+
+> “Existe alguma data, iniciativa ou marco interno que influencie o timing?”
+
+> “Vocês já têm orçamento ou uma faixa definida para esse tipo de iniciativa? Se ainda não houver, sem problema; registro como algo a validar.”
+
+#### 9–10 min — recapitulação e CTA
+
+> “Deixe-me confirmar se entendi: vocês estão olhando para [dor/oportunidade confirmada], que hoje afeta [impacto confirmado], e a prioridade é [timing confirmado]. Está correto?”
+
+> “Pelo que você trouxe, faz sentido uma reunião de 60 minutos com [closer/especialista] para aprofundarmos o cenário e verificarmos aderência da ZAIP. Vale agendar com [participantes necessários]?”
+
+> “Para essa próxima conversa render, há alguma informação ou pessoa que seria importante incluir?”
+
+### Registro obrigatório no CRM
+
+| Campo | Estado possível |
+| --- | --- |
+| Empresa, cargo, área e origem | Confirmado / desconhecido |
+| Situação atual | Fato relatado |
+| Problema e impacto | Confirmado / desconhecido |
+| Need (necessidade) | Confirmado / desconhecido / não aplicável |
+| Authority (autoridade) | Confirmado / desconhecido / não aplicável |
+| Budget (orçamento) | Confirmado / desconhecido / não aplicável |
+| Timing | Confirmado / desconhecido / não aplicável |
+| Próximo passo | Data, dono e participantes |
+
+### Banco de perguntas SPIN (usar de forma adaptativa)
+
+Escolha as perguntas necessárias ao contexto; não siga esta lista como interrogatório e não repita algo já confirmado.
+
+| Campo | Perguntas possíveis | Evidência a registrar |
+| --- | --- | --- |
+| **S — Situation** | “Como isso é tratado hoje?” / “Qual área participa?” | Contexto, processo e participantes relatados |
+| **P — Problem** | “Onde há dificuldade ou oportunidade?” | Problema declarado, ou ausência de problema aplicável |
+| **I — Implication** | “Quando isso ocorre, o que muda para o time ou operação?” | Consequência relatada; não inferir perda, risco ou urgência |
+| **N — Need-payoff** | “O que precisaria melhorar para valer uma análise?” | Critério de valor descrito pelo prospect |
+
+### Gate BANT para encaminhar ao closer
+
+| Campo | Evidência mínima | Se não confirmado |
+| --- | --- | --- |
+| **Budget** | Faixa, processo ou condição de orçamento relatada | Registrar `desconhecido`; não pressionar nem estimar |
+| **Authority** | Papel do contato e participantes/decisores conhecidos | Pedir inclusão da pessoa adequada na próxima reunião |
+| **Need** | Dor, oportunidade ou critério de melhoria relatado | Seguir em exploração, nurture ou not-qualified conforme contexto |
+| **Timing** | Marco, prioridade ou janela relatada | Registrar `desconhecido`; não criar urgência artificial |
+
+### Rotas de saída
+
+- **Qualificado:** contexto, necessidade ou oportunidade, prioridade e contato adequado confirmados; reunião aceita.
+- **Nurture:** tema relevante, mas sem prioridade ou timing atual.
+- **Not-qualified:** ausência de aderência, ausência de problema aplicável ou recusa clara em avançar.
+- **Lacuna de dados:** informação ainda não confirmada; não inferir interesse, orçamento ou autoridade.
+
+**SLA de encaminhamento:** o SDR registra o handoff no CRM antes do convite ou, se a agenda já foi aceita, até o fim do mesmo dia útil. O closer confirma o recebimento e eventuais lacunas antes da reunião; não presume informações ausentes.
+
+---
+
+## Etapa 2 — reunião de diagnóstico e fechamento (60 minutos)
+
+**Objetivo:** aprofundar o diagnóstico, validar fit, conectar a ZAIP somente às necessidades confirmadas, tratar objeções e acordar um próximo passo autorizado.
+**Dono:** closer/AE, com SDR responsável pelo handoff completo.
+**Saída:** próxima ação acordada; proposta apenas pelo fluxo aprovado; nurture, no-decision ou encerramento.
+
+### Agenda de tempo
+
+| Tempo | Objetivo |
+| --- | --- |
+| 0–5 min | Alinhar participantes, objetivo e agenda |
+| 5–25 min | Diagnóstico de contexto, dor, impacto e prioridade |
+| 25–35 min | Confirmar problema, critérios e processo de decisão |
+| 35–45 min | Apresentar a ZAIP ligada às dores confirmadas |
+| 45–52 min | Tratar dúvidas e objeções |
+| 52–60 min | Definir próximo passo ou saída honesta |
+
+**Entrada obrigatória:** handoff do SDR disponível no CRM, com fonte e estado dos campos conhecidos. Se ele não existir, o closer usa os primeiros minutos para preencher as lacunas, sem alegar que elas foram confirmadas previamente.
+
+### Script literal
+
+#### 0–5 min — abertura e contrato de conversa
+
+> “Obrigado pelo tempo. Minha proposta para esta reunião é entender o cenário de vocês, confirmar se existe aderência real e mostrar somente o que for relevante da ZAIP. No final, decidimos juntos se vale avançar, manter em acompanhamento ou encerrar por aqui. Faz sentido?”
+
+> “Antes de começarmos: quem participa hoje, qual é o papel de cada pessoa e o que faria esta reunião valer a pena para vocês?”
+
+#### 5–25 min — diagnóstico
+
+> “Como funciona hoje [processo/tema] do início ao fim?”
+
+> “O que motivou vocês a olhar para isso neste momento?”
+
+> “Onde o processo tende a travar, gerar retrabalho ou exigir mais esforço?”
+
+> “Quais consequências práticas isso traz para a equipe, a operação ou a tomada de decisão?”
+
+> “Como vocês saberiam que a situação melhorou? Que critérios uma solução precisaria atender?”
+
+> “Que alternativas já usam ou já avaliaram?”
+
+> “Há uma data, projeto ou prioridade interna que define a decisão?”
+
+#### 25–35 min — alinhamento
+
+> “Quero checar se compreendi corretamente: hoje vocês enfrentam [dores confirmadas], isso afeta [impactos confirmados], e uma solução precisa atender [critérios confirmados]. O que eu ajustaria?”
+
+> “Quem precisa estar confortável com essa decisão e como a avaliação costuma acontecer?”
+
+> “O que ainda não conversamos que seria essencial antes de vocês considerarem uma mudança?”
+
+#### 35–45 min — apresentação direcionada da ZAIP
+
+> “Com base no que vocês confirmaram, vou mostrar apenas as partes da ZAIP que se conectam a esse cenário.”
+
+Para cada capacidade, use este formato:
+
+> “Para a necessidade de [dor confirmada], a ZAIP oferece [capacidade aprovada]. Na prática, isso se aplicaria a [fluxo aderente].”
+
+> “O ponto que ainda precisamos validar é [integração, escopo, requisito ou dependência]. Não vou assumir que está resolvido antes dessa confirmação.”
+
+Apresente somente demonstrações, casos, métricas, integrações e materiais aprovados.
+
+Antes de demonstrar, valide o nível de awareness sem supor: para quem ainda explora o tema, use contexto e hipótese aberta; para quem já compara soluções, alinhe critérios; para quem avalia a ZAIP, confirme fit e lacunas. A chamada à ação continua sendo apenas o próximo passo permitido.
+
+#### 45–52 min — objeções
+
+> “Antes de falarmos de próximos passos, o que ainda impediria vocês de considerar essa solução viável?”
+
+> “Existe alguma preocupação sobre implementação, adoção, integração, segurança ou escopo?”
+
+> “O que precisaria estar claro para avançarmos com segurança?”
+
+Resposta-base:
+
+> “Faz sentido levantar esse ponto. O que consigo confirmar hoje é [fato autorizado]. O que exigir validação ficará registrado como próximo passo, com responsável e prazo.”
+
+#### 52–60 min — fechamento
+
+Se houver fit e interesse:
+
+> “Pelo que validamos, existe aderência em [itens confirmados]. O próximo passo recomendado é [demonstração técnica, discovery adicional ou proposta aprovada], com [participantes]. Podemos combinar isso para [data]?”
+
+Se houver pedido de preço:
+
+> “Posso apresentar preço e escopo somente dentro de uma proposta aprovada para o cenário de vocês. Antes, preciso confirmar [variáveis reais de escopo].”
+
+Se ainda não houver decisão:
+
+> “Parece que faltam [itens]. Em vez de forçar um avanço, vamos registrar isso e definir [próxima ação] até [data].”
+
+Se não houver fit:
+
+> “Pelo que entendemos, a ZAIP não parece ser a melhor resposta para [motivo confirmado]. Prefiro ser transparente e encerrar esta oportunidade por agora. Posso manter contato caso o contexto mude?”
+
+## Handoff SDR → closer
+
+O SDR deve enviar antes da reunião:
+
+- contexto e origem do lead;
+- fatos confirmados sobre situação, problema, impacto e timing;
+- participantes e processo decisório conhecidos;
+- BANT com cada campo marcado como confirmado, desconhecido ou não aplicável;
+- objeções iniciais, lacunas e microcompromisso assumido;
+- convite, data e objetivo da reunião.
+
+### Contrato de aceite do closer
+
+O closer aceita a oportunidade quando há origem, contexto mínimo, motivo da reunião, próximo passo aceito e campos BANT com seus estados explícitos. Não exige que todos os campos estejam confirmados: lacunas são parte do plano de descoberta. Se faltar contexto mínimo, devolve ao SDR com a pergunta necessária ou reabre a descoberta na reunião, registrando o motivo.
+
+O closer devolve ao CRM o resultado da reunião, fatos confirmados, lacunas, objeções, próximos passos, responsável, data e rota final. A devolução ocorre até o fim do mesmo dia útil após a reunião.
+
+### Rotas após a reunião do closer
+
+| Rota | Condição observada | Ação e registro |
+| --- | --- | --- |
+| **Próximo passo autorizado** | Fit e microcompromisso confirmados | Registrar ação, dono, data, participantes e pré-requisitos; proposta só no fluxo aprovado |
+| **Nurture** | Relevância reconhecida, sem prioridade ou timing atual | Registrar motivo, gatilho de retorno e responsável; não fabricar data de compra |
+| **No-decision** | Não há decisão, patrocinador ou passo concreto no momento | Registrar a lacuna e o critério para retomar; não tratar como proposta em andamento |
+| **Encerramento / not-qualified** | Sem aderência, necessidade aplicável ou interesse em avançar | Registrar motivo factual e encerrar respeitosamente |
+
+## Checklist rápido de qualidade
+
+- A conversa usou perguntas e fatos confirmados, sem pressionar ou criar urgência artificial.
+- O SDR vendeu somente a próxima conversa; o closer acordou somente um próximo passo autorizado.
+- Nenhum preço, ROI, desconto, case ou claim foi inventado.
+- BANT foi registrado como evidência ou lacuna, não como instrumento de pressão.
+- Toda oportunidade teve uma saída explícita e um registro no CRM.

package/templates/.agents/skills/criar-pasta-obsidian/scripts/generate-obsidian-vault.test.mjs

@@ -1,9 +1,18 @@
 import assert from "node:assert/strict";
 import { spawnSync } from "node:child_process";
-import { mkdir, mkdtemp, readFile, writeFile } from "node:fs/promises";
+import { access, mkdir, mkdtemp, readFile, writeFile } from "node:fs/promises";
 import { tmpdir } from "node:os";
 import { resolve } from "node:path";
 
+async function exists(path) {
+  try {
+    await access(path);
+    return true;
+  } catch {
+    return false;
+  }
+}
+
 const root = await mkdtemp(resolve(tmpdir(), "zaip-obsidian-test-"));
 const records = resolve(root, ".agents/records/lifecycle");
 await mkdir(records, { recursive: true });
@@ -111,22 +120,17 @@ for (const [kind, folder] of [
   assert.match(css, new RegExp(`data-path="${folder}"`));
   assert.match(index, new RegExp(`zaip-kind-${kind}`));
 }
-assert.equal(
-  await readFile(
-    resolve(
-      process.cwd(),
-      ".agents/skills/criar-pasta-obsidian/scripts/generate-obsidian-vault.mjs",
-    ),
-    "utf8",
-  ),
-  await readFile(
-    resolve(
-      process.cwd(),
-      "public-cli/packages/cli/templates/.agents/skills/criar-pasta-obsidian/scripts/generate-obsidian-vault.mjs",
-    ),
-    "utf8",
-  ),
+const sourceScript = resolve(
+  process.cwd(),
+  ".agents/skills/criar-pasta-obsidian/scripts/generate-obsidian-vault.mjs",
 );
+const templateScript = resolve(
+  process.cwd(),
+  "public-cli/packages/cli/templates/.agents/skills/criar-pasta-obsidian/scripts/generate-obsidian-vault.mjs",
+);
+if ((await exists(sourceScript)) && (await exists(templateScript))) {
+  assert.equal(await readFile(sourceScript, "utf8"), await readFile(templateScript, "utf8"));
+}
 assert.match(await readFile(resolve(vault, "PRDs/PRD-1.md"), "utf8"), /PRD summary/);
 
 const evidence = await readFile(resolve(vault, "Evidence/EVD-1.md"), "utf8");

package/templates/.agents/skills/zaip-aios/SKILL.md

@@ -1,5 +1,5 @@
 ---
-# zaip-managed generated-do-not-edit source=discovery-skill version=1.0.8 sha256=72e09e90f33f9ed2543daf8dfc09ee5b10fca74d7fa077db030b8b048301d806
+# zaip-managed generated-do-not-edit source=discovery-skill version=1.3.0 sha256=72e09e90f33f9ed2543daf8dfc09ee5b10fca74d7fa077db030b8b048301d806
 name: zaip-aios
 description: Discover and apply the repository-local ZAIP-AIOS framework.
 ---

package/templates/.agents/skills/zaip-skill-agent-catalog/SKILL.md

@@ -0,0 +1,22 @@
+---
+name: zaip-skill-agent-catalog
+description: Create or change ZAIP agent catalog entries, capabilities, scopes, eligibility, and skill bindings while preserving adapter and distribution parity.
+---
+
+# Maintain the agent catalog
+
+Use when an agent identity or its operational contract changes.
+
+1. Inventory the intended capability, least-privilege write scope, execution
+   eligibility, tools, model policy, and escalation boundary before editing.
+2. Use only cataloged `codex_name` and `codex_task_name` values. Do not add ad-hoc
+   identities, task labels, or a mandatory dependency on a non-distributed skill.
+3. Bind each delivery specialty to its matching local ZAIP skill and keep `change`
+   evidence support where delivery is allowed.
+4. Validate YAML, catalog-to-skill references, specialist routing, and generated
+   Codex/Claude adapters. Update framework lock and public template only for framework
+   source changes.
+5. Report routing behavior and compatibility impact. Catalog maintenance does not
+   authorize a delivery, deployment, or approval of the agent's own work.
+
+For a new skill, use `$zaip-skill-author-skills` first.

package/templates/.agents/skills/zaip-skill-agent-catalog/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "ZAIP Agent Catalog"
+  short_description: "Maintain agent roles, skills, scopes, and adapter parity."
+  default_prompt: "Use $zaip-skill-agent-catalog to create or update this ZAIP agent catalog entry and validate its skill, scope, routing, and adapter bindings."

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

@@ -15,7 +15,8 @@ description: Create and audit portable ZAIP skills, triggers, resources, and rel
 6. No frontmatter aceite somente `name` e `description`. A descrição deve dizer o que faz e quando dispara.
 7. Mantenha o corpo operacional e curto. Coloque schemas/exemplos extensos em `references/`, scripts determinísticos em `scripts/` e assets somente quando reutilizáveis.
 8. Gere metadata com nome legível, descrição curta específica e prompt que mencione `$nome-da-skill`; evite prompts genéricos.
-9. Valide links relativos, encoding UTF-8, placeholders, tamanho, políticas de invocação, triggers sobrepostos e comandos citados.
-10. No framework source, rode `pnpm sync:framework-lock`, validação, testes relevantes, sync do template público, build e parity; no consumer, rode somente validação da skill, `zaip doctor` e adapters aplicáveis.
+9. Rode `scripts/audit-skill-catalog.mjs` para validar referências do catálogo, bindings obrigatórios, comandos conhecidos e contratos técnicos que não podem ser duplicados em documentação; rode `scripts/run-skill-tests.mjs` para executar todos os testes de skills descobertos.
+10. Valide links relativos, encoding UTF-8, placeholders, tamanho, políticas de invocação, triggers sobrepostos e comandos citados.
+11. No framework source, rode `pnpm sync:framework-lock`, validação, testes relevantes, sync do template público, build e parity; no consumer, rode somente validação da skill, `zaip doctor` e adapters aplicáveis.
 
 Não copie paths pessoais, portas, credenciais, integrações específicas do projeto ou runners inexistentes para uma skill core.

package/templates/.agents/skills/zaip-skill-author-skills/scripts/audit-skill-catalog.mjs

@@ -0,0 +1,49 @@
+import { readdir, readFile } from "node:fs/promises";
+import { resolve } from "node:path";
+import { parseDocument } from "yaml";
+
+const root = resolve(import.meta.dirname, "..", "..", "..", "..");
+const skillsRoot = resolve(root, ".agents/skills");
+const skillDirectories = (await readdir(skillsRoot, { withFileTypes: true }))
+  .filter((entry) => entry.isDirectory())
+  .map((entry) => entry.name);
+const knownSkills = new Set(skillDirectories);
+const errors = [];
+const catalog = parseYaml(
+  await readFile(resolve(root, ".agents/config/agents/catalog.yaml"), "utf8"),
+);
+
+for (const agent of catalog.agents ?? []) {
+  for (const skill of agent.skills ?? []) {
+    if (!knownSkills.has(skill)) errors.push(`${agent.id}: references unavailable skill ${skill}`);
+  }
+}
+for (const [agentId, requiredSkill] of [
+  ["agent-frontend", "zaip-skill-frontend"],
+  ["agent-backend", "zaip-skill-backend"],
+  ["agent-designer", "zaip-skill-design-system"],
+]) {
+  const agent = (catalog.agents ?? []).find((entry) => entry.id === agentId);
+  if (!agent?.skills?.includes(requiredSkill))
+    errors.push(`${agentId}: must load ${requiredSkill}`);
+}
+const rulesSource = await readFile(resolve(skillsRoot, "zaip-skill-rules/SKILL.md"), "utf8");
+if (/\bcontext validate\b/i.test(rulesSource))
+  errors.push("zaip-skill-rules: cites unavailable context validate command");
+const sqliteSource = await readFile(
+  resolve(skillsRoot, "zaip-skill-sqlite-read-model/SKILL.md"),
+  "utf8",
+);
+if (/schema version \d+|schema \d+|requiredIndexCount|exactly these tables/i.test(sqliteSource))
+  errors.push("zaip-skill-sqlite-read-model: duplicates volatile runtime schema contract");
+
+if (errors.length > 0) throw new Error(`Skill catalog audit failed:\n${errors.join("\n")}`);
+process.stdout.write(
+  `Audited ${skillDirectories.length} skills and ${(catalog.agents ?? []).length} agents.\n`,
+);
+
+function parseYaml(source) {
+  const document = parseDocument(source, { strict: true, uniqueKeys: true });
+  if (document.errors.length > 0) throw new Error(document.errors.map(String).join("\n"));
+  return document.toJS();
+}

package/templates/.agents/skills/zaip-skill-author-skills/scripts/author-skill-scripts.test.mjs

@@ -0,0 +1,27 @@
+import assert from "node:assert/strict";
+import { execFile } from "node:child_process";
+import { resolve } from "node:path";
+import test from "node:test";
+import { promisify } from "node:util";
+
+const run = promisify(execFile);
+const root = resolve(import.meta.dirname, "..", "..", "..", "..");
+const scripts = resolve(root, ".agents/skills/zaip-skill-author-skills/scripts");
+
+test("skill test discovery lists every checked-in skill test without executing recursively", async () => {
+  const { stdout } = await run(
+    process.execPath,
+    [resolve(scripts, "run-skill-tests.mjs"), "--list"],
+    { cwd: root },
+  );
+  assert.match(stdout, /author-skill-scripts\.test\.mjs/);
+  assert.match(stdout, /github-deploy-contract\.test\.mjs/);
+  assert.match(stdout, /refactor-scripts\.test\.mjs/);
+});
+
+test("skill catalog audit validates the checked-in catalog and technical contracts", async () => {
+  const { stdout } = await run(process.execPath, [resolve(scripts, "audit-skill-catalog.mjs")], {
+    cwd: root,
+  });
+  assert.match(stdout, /Audited \d+ skills and \d+ agents/);
+});

package/templates/.agents/skills/zaip-skill-author-skills/scripts/run-skill-tests.mjs

@@ -0,0 +1,37 @@
+import { spawn } from "node:child_process";
+import { readdir } from "node:fs/promises";
+import { resolve } from "node:path";
+
+const skillsRoot = resolve(import.meta.dirname, "..", "..");
+const tests = (await files(skillsRoot))
+  .filter((path) => /(?:^|[\\/])[^\\/]+\.(?:test|tests)\.(?:mjs|cjs|js)$/i.test(path))
+  .sort();
+
+if (tests.length === 0) {
+  process.stdout.write("No ZAIP skill tests found.\n");
+  process.exit(0);
+}
+
+if (process.argv.includes("--list")) {
+  process.stdout.write(`${tests.join("\n")}\n`);
+  process.exit(0);
+}
+
+await new Promise((resolveRun, reject) => {
+  const child = spawn(process.execPath, ["--test", ...tests], { stdio: "inherit" });
+  child.once("error", reject);
+  child.once("exit", (code) =>
+    code === 0 ? resolveRun() : reject(new Error(`Skill tests failed (${code})`)),
+  );
+});
+
+async function files(directory) {
+  const entries = await readdir(directory, { withFileTypes: true });
+  const nested = await Promise.all(
+    entries.map(async (entry) => {
+      const path = resolve(directory, entry.name);
+      return entry.isDirectory() ? files(path) : entry.isFile() ? [path] : [];
+    }),
+  );
+  return nested.flat();
+}

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

@@ -8,3 +8,4 @@ description: Implement backend APIs, persistence, and integration boundaries ins
 1. Confirmar contrato de entrada e saída, limites de persistência e dependências antes da alteração.
 2. Preservar a direção de dependências e manter detalhes de infraestrutura atrás da fronteira do módulo.
 3. Aplicar arquitetura e CQRS proporcionalmente ao contrato alterado: não introduzir camadas, migrações ou gates pesados quando a mudança local não os exige. Cobrir o comportamento alterado com testes focados e registrar incompatibilidades, migrações ou riscos de integração.
+4. Aplicar [o contrato de prova observável](../zaip-skill-change/references/observable-evidence.md): metadados para estrutura/migração, fluxo autorizado e registros específicos para persistência, logs correlacionados para correções e observação direta de API/fila/cache/integração. SQL não é obrigatório quando inaplicável. Correlacionar UI e backend quando o AC exigir o fluxo completo; registrar ambiente, versão, limitações e fallback finito sem expor dados sensíveis.

package/templates/.agents/skills/zaip-skill-brand-governance/SKILL.md

@@ -5,11 +5,18 @@ description: Define and govern an evidence-backed brand platform, Brandbook, arc
 
 # Governar a marca
 
+## Localização canônica
+
+Salve Brandbooks, plataformas de marca, decisões de identidade, arquétipos, escalas de diferencial semântico e materiais de governança em `.agents/branding/`. Todo Brandbook salvo como `.docx` deve ter, na mesma pasta e com o mesmo nome-base, uma fonte canônica `.md` com o conteúdo estratégico equivalente; mantenha os dois arquivos sincronizados a cada revisão. Use `.agents/branding/archive/` somente para versões substituídas. Não crie esses artefatos em `docs/`, na raiz do repositório ou em diretórios de outra disciplina.
+
+O arquivo central da área é `.agents/branding/brandbook.md`; atualize-o quando a decisão afetar a plataforma de marca. A versão Word correspondente é `.agents/branding/brandbook.docx`.
+
 1. Delimite objetivo, públicos, contexto de negócio, fontes e autoridade de aprovação. Classifique cada afirmação como evidência, hipótese ou decisão; não apresente hipótese como fato.
-2. Construa ou atualize a plataforma: cultura, propósito, posicionamento, proposta de valor, promessa, diferenciais, atributos, personalidade, arquitetura de marca e pontos de contato.
+2. Construa ou atualize a plataforma: cultura, propósito, posicionamento, proposta de valor, promessa, diferenciais, atributos, personalidade, arquitetura de marca e pontos de contato. Para Brandbooks completos, use o framework de domínios em [referências do Brandbook](references/brandbook-framework.md).
 3. Quando o trabalho incluir um Brandbook, mantenha uma fonte estratégica interna e derive uma versão externa somente com conteúdo autorizado. Preserve versão, proprietário, aprovadores, confidencialidade e histórico de decisão.
+   - A primeira versão oficial de um Brandbook é sempre `v1.0`; não use versões `v0.x`. Incrementos posteriores seguem versionamento semântico editorial (`v1.1`, `v1.2` para evolução aprovada; `v2.0` para mudança material de plataforma ou arquitetura).
 4. Para arquétipos, registre evidência, comportamento esperado, limites e implicações para linguagem e experiência. Se houver pesos, valide que o total é 100%; se não houver pesquisa, registre como hipótese de trabalho.
 5. Para diferencial semântico, registre dimensões, polos, escala, fonte, data, amostra e diferença entre identidade desejada e percebida. Não fabrique respostas, baseline, validação estatística ou brand equity.
 6. Encaminhe aplicação ordinária de Brandbook aprovado, campanhas, copy e ativos para Lúcia; scripts e playbooks sales-facing para Aaron; análise quantitativa para Gabi; impacto de receita/custo e RevOps para Robert; e produção operacional genérica para Clara. Um Brandbook aprovado é input, não motivo para assumir a aplicação.
 
-Consulte [padrões de Brandbook](references/brandbook-standards.md) ao estruturar entregáveis internos ou externos.
+Consulte [padrões de Brandbook](references/brandbook-standards.md) e o [framework de domínios](references/brandbook-framework.md) ao estruturar entregáveis internos ou externos.

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

@@ -0,0 +1,39 @@
+# Framework de domínios do Brandbook
+
+Use este framework para um Brandbook interno. Ele organiza a estratégia; não autoriza apresentar hipóteses como fato nem copiar o conteúdo de uma referência externa.
+
+## Versionamento
+
+Inicie todo Brandbook aprovado em `v1.0`. Use `v1.x` para complementos ou revisões aprovadas que preservam a plataforma e `v2.0` para uma mudança material de propósito, posicionamento ou arquitetura. Versões de trabalho internas não devem usar `v0.x`.
+
+## Formatos canônicos
+
+Para cada Brandbook, mantenha obrigatoriamente uma fonte estratégica em Markdown e uma versão Word com o mesmo nome-base na pasta `.agents/branding/`; por exemplo, `Brandbook v1.0.md` e `Brandbook v1.0.docx`. Atualize ambos na mesma alteração. O Markdown é a fonte de revisão Git-native; o DOCX é a versão de leitura e apresentação.
+
+## Fundação
+
+Defina propósito, porquê, visão futura, quem somos, história, proposta de valor, manifesto, crenças e DNA. Para cada domínio, registre fonte, data, proprietário e classificação: evidência, decisão ou hipótese.
+
+## Ecossistema
+
+Mapeie mercado, categorias de concorrência, stakeholders, públicos, personas, parceiros, canais e marcas de inspiração. Mantenha concorrentes observados separados de percepções competitivas não pesquisadas.
+
+## Identidade
+
+Registre atributos, autoimagem do público, reflexo desejado, personalidade, relação com clientes, tom de voz e prisma de identidade. O prisma deve cobrir físico, personalidade, cultura, relação, reflexo e autoimagem.
+
+## Arquétipos e diferencial semântico
+
+Para arquétipos, indique dominante, apoios, pesos que totalizem 100%, motivação, comportamentos esperados, sombra, limites e implicações de linguagem e experiência. Sem pesquisa, os pesos são hipótese de trabalho.
+
+Para diferencial semântico, use dimensões com polos claros e escala de -3 a +3, zero neutro. Registre separadamente perfil desejado, percepção interna, percepção externa e concorrentes, com fonte, data, amostra e confiança. Ausência de amostra não recebe nota.
+
+## Estratégia
+
+Defina arquitetura entre: casa com marca (branded house), casa de marcas, marcas endossadas ou híbrida. Registre postura estratégica, estratégia competitiva, estratégia de posicionamento, frase de definição, promessa, lema, diferencial competitivo, vantagem injusta e experiência emocional.
+
+Uma vantagem injusta só pode ser afirmada como fato se houver evidência de difícil replicação, valor e sustentação. Caso contrário, trate-a como hipótese ou ativo a desenvolver.
+
+## Publicação
+
+A versão externa deriva somente dos domínios aprovados. Exclua dados brutos, pesquisa, projeções, justificativas confidenciais, comparativos competitivos internos e hipóteses não aprovadas.