@zaip-ai/cli 1.0.7 → 1.3.0

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/zaip-aios/SKILL.md

@@ -1,5 +1,5 @@
 ---
-# zaip-managed generated-do-not-edit source=discovery-skill version=1.0.0 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-brand-governance/SKILL.md

@@ -0,0 +1,22 @@
+---
+name: zaip-skill-brand-governance
+description: Define and govern an evidence-backed brand platform, Brandbook, archetypes, and brand identity decisions. Use for brand strategy and governance; not for product design-system implementation or marketing campaign execution.
+---
+
+# 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. 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) 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/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Branding Specialist"
+  short_description: "Define and govern an evidence-backed brand platform."
+  default_prompt: "Use $zaip-skill-brand-governance to define or govern an evidence-backed brand platform."

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.

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

@@ -0,0 +1,30 @@
+# Padrões de Brandbook e governança
+
+Use este roteiro quando o pedido exigir a plataforma ou o Brandbook da marca.
+
+## Fonte estratégica interna
+
+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 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.
+
+## Versão externa
+
+Derive a publicação externa da fonte interna. Ela pode comunicar propósito, posicionamento aprovado, promessa, diferenciais, personalidade, tom e aplicações autorizadas. Exclua pesquisa bruta, comparativos competitivos, dados pessoais, riscos, negociações, valuation, hipóteses não aprovadas e justificativas confidenciais.
+
+## Instrumentos
+
+- Diferencial semântico: use polos claros, escala explícita de -3 a +3 e zero neutro. Armazene perfil desejado e percepção observada separadamente.
+- Diferencial semântico: para cada perfil, registre versão, fonte, respondente ou amostra, data, confiança e finalidade. Mantenha os perfis intended, internal, external e competitor separados; ausência de amostra é uma limitação, não uma pontuação.
+- Arquétipos: documente papel dominante, papéis de apoio, motivação, comportamento, sombra, evidência, contraevidência e comportamentos do/don't. Pesos devem totalizar 100% somente quando forem usados.
+- Métricas: se não houver dataset ou método validável, registre a métrica como pendente; não infira reconhecimento, preferência ou valor de marca.
+
+## Operação contínua
+
+Mantenha RACI, cadência de revisão, critério de exceção, inventário de touchpoints, matriz de stakeholders e log de versões. Cada mudança de identidade deve ligar a decisão à plataforma, ao manual afetado e ao responsável pela aplicação.
+
+## Handoffs
+
+Sarah decide a estratégia e a governança da marca. Manu traduz decisões aprovadas para o design system digital; Lúcia ativa a marca em marketing; Gabi mede dados; Robert relaciona oportunidades a receita, custo e RevOps; Clara produz artefatos operacionais autorizados.

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

@@ -0,0 +1,25 @@
+---
+name: zaip-skill-dashboard-sqlite
+description: Rebuild and open the isolated SQLite dashboard comparison runtime.
+---
+
+# Dashboard SQLite comparativo
+
+Use esta skill para o dashboard SQLite em `.agents/dashboard`. Ela reconstrói um snapshot descartável
+em `.local/dashboard-sqlite/read-model.sqlite`.
+
+1. Na raiz do repositório, execute `node .agents/dashboard/packages/local-runtime/scripts/rebuild-sqlite-read-model.mjs`.
+2. Para regenerar os artefatos sem depender dos globs do workspace principal, execute
+   `node .agents/dashboard/packages/local-runtime/scripts/build-sqlite-dashboard.mjs`.
+3. Verifique a paridade de all-time/intervalos, zero conhecido e todo-desconhecido/null com
+   `node .agents/dashboard/packages/local-runtime/scripts/test-sqlite-read-model.mjs`.
+4. Abra com `node .agents/dashboard/packages/local-runtime/start-dashboard.mjs` ou com
+   `.agents/dashboard/zaip-dashboard-windows.exe`.
+5. Confirme `GET /api/v2/health`: o retorno deve conter `kind: zaip-dashboard-sqlite-runtime` e
+   `storage.storage_mode: sqlite_read_model`.
+
+O banco é um read model dos registros e da configuração ZAIP. `daily_aggregates` é derivada do
+read model lifecycle diário e alimenta, via SQL, os fatos de primeiro fold de
+`operations?scope=quick` e `cost-monitor?scope=summary` (runs, tokens, custo e cobertura).
+A duração híbrida legada e os detalhes de entidades permanecem no projection/adapter compartilhado
+para preservar semântica. A API é somente leitura para que o snapshot não fique desatualizado.

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

@@ -0,0 +1,4 @@
+interface:
+  display_name: "ZAIP Dashboard SQLite"
+  short_description: "Rebuild and open the isolated SQLite dashboard comparison."
+  default_prompt: "Use $zaip-skill-dashboard-sqlite to rebuild the disposable read model and verify the isolated dashboard."

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-executar-fila-pronta/SKILL.md

@@ -0,0 +1,18 @@
+---
+name: zaip-skill-executar-fila-pronta
+description: Execute the full eligible ready-work snapshot using the canonical queue order.
+---
+
+# Executar fila pronta
+
+Use esta skill para uma rodada idempotente que processa sequencialmente o snapshot elegível da fila. A seleção é estrita: PRD `ready`, depois SPEC `ready` independente, depois Task-first standalone elegível em `Pronto para Executar`.
+
+1. A primeira ação da conversa agendada chama `codex_app set_thread_title` sem `threadId`, usando a hora local `America/Sao_Paulo` no formato exato `[YYYY-MM-DD-T-HH-mm] Tarefa Agendada`. Registre a falha de renomeação observada e continue para a fila; ela não bloqueia a rodada.
+2. Valide o checkout local, `zaip.enabled: true`, registros canônicos e runtime. Leia `.agents/dashboard/work-priority.json` quando existir; ausência ou conteúdo inválido equivale a nenhuma prioridade manual, nunca a uma ordem inventada.
+3. Antes de selecionar, crie atomicamente `.local/automation/ready-queue.lock.json` (diretório local não versionado) com `owner_token` aleatório, `fencing_token`, `acquired_at` e `expires_at`. O `fencing_token` é um inteiro monotônico: toda aquisição que substitui um lock expirado recebe valor maior que o último valor observado. Se existir lock válido de outra rodada, retorne sem efeito; nunca force a sobreposição. Renove o mesmo lock, com token e `owner_token` conferidos, antes de cada candidato. Antes de cada efeito (incluindo iniciar uma Execution), releia o lock e exija ambos os tokens atuais e prazo válido; se a renovação falhar ou o token não for atual, encerre a rodada sem executar mais efeitos. Libere somente ao terminar e apenas se o `owner_token` ainda corresponder; locks expirados podem ser substituídos atomicamente.
+4. Forme os candidatos nesta precedência: (a) PRDs `ready`; (b) SPECs `ready` que não descendem de PRD; (c) Tasks Task-first standalone `prepared`/`planned`, com dependências concluídas e exatamente um PreparedPlan resolvível: `prepared_plan` inline válido **ou** `plan_ref` válido, nunca ambos. A Task ainda não pode ter Execution vinculada e nunca pode ter sido iniciada ou tentada. Para cada candidata, exclua o registro sem `status: planned`, com `started_at`, `attempt_count` diferente de zero, Execution existente, estado de plano ambíguo, ou cujo próprio ID apareça em `task next` ou no conjunto materializado concorrente. Exclua também descendentes de PRD/SPEC e itens `active`, `blocked`, `failed`, `cancelled` ou terminais.
+5. Ordene cada classe por `.agents/dashboard/work-priority.json`: itens enumerados no Kanban vêm primeiro e mantêm a ordem de cima para baixo; os sem enumeração entram depois pelo fallback canônico determinístico. Congele o snapshot ordenado e processe todos os PRDs antes de SPECs, e todos os SPECs antes das Tasks; não misture classes.
+6. Execute cada unidade do snapshot, uma por vez, pelo comando explícito no menor grão (`prd execute`, `spec execute` ou `task execute`). Para uma Task-first elegível, use `task execute` para materializar sua Execution; não crie a Execution por outro atalho. Reavalie o estado antes de cada início e pule o item que deixou de ser elegível. Preserve os gates de write scope, dependências, evidências, testes e finalizador; uma seleção não é autorização para ignorar qualquer gate.
+7. Registre o resultado de cada unidade, as omissões e a ausência de candidatos, e solte o lease. Sem candidato, retorne `no_eligible_work`; com precondição ausente, conflito de lease ou estado ambíguo, falhe fechado e não altere registros.
+
+Esta skill não cria um agendamento. Ela só pode ser chamada pela automação nativa do Codex Desktop ou por um usuário com autoridade explícita para executar o trabalho selecionado.

package/templates/.agents/skills/zaip-skill-executar-fila-pronta/agents/openai.yaml

@@ -0,0 +1,6 @@
+interface:
+  display_name: "ZAIP Executar Fila Pronta"
+  short_description: "Execute o ciclo completo do snapshot elegível da fila pronta."
+  default_prompt: "Use $zaip-skill-executar-fila-pronta para executar o ciclo completo do snapshot elegível, respeitando a prioridade do Kanban e sem promover ou retomar itens inelegíveis."
+policy:
+  allow_implicit_invocation: false

package/templates/.agents/skills/zaip-skill-executar-fila-pronta/scripts/ready-queue-fence.mjs

@@ -0,0 +1,71 @@
+import { mkdir, readFile, rename, rm, writeFile } from "node:fs/promises";
+import { dirname, resolve } from "node:path";
+
+export async function acquireReadyQueueFence(lockPath, input) {
+  return withMutex(lockPath, async () => {
+    const current = await readLease(lockPath);
+    if (current !== null && current.released_at === undefined && current.expires_at > input.now)
+      return null;
+    const lease = {
+      owner_token: input.owner_token,
+      fencing_token: (current?.fencing_token ?? 0) + 1,
+      acquired_at: input.now,
+      expires_at: input.expires_at,
+    };
+    await writeLease(lockPath, lease);
+    return lease;
+  });
+}
+export async function renewReadyQueueFence(lockPath, lease, now, expiresAt) {
+  return withMutex(lockPath, async () => {
+    if (!(await assertReadyQueueFence(lockPath, lease, now))) return null;
+    const renewed = { ...lease, expires_at: expiresAt };
+    await writeLease(lockPath, renewed);
+    return renewed;
+  });
+}
+export async function assertReadyQueueFence(lockPath, lease, now) {
+  const current = await readLease(lockPath);
+  return (
+    current !== null &&
+    current.released_at === undefined &&
+    current.owner_token === lease.owner_token &&
+    current.fencing_token === lease.fencing_token &&
+    current.expires_at > now
+  );
+}
+export async function releaseReadyQueueFence(lockPath, lease, now) {
+  return withMutex(lockPath, async () => {
+    if (!(await assertReadyQueueFence(lockPath, lease, now))) return false;
+    await writeLease(lockPath, { ...lease, expires_at: now, released_at: now });
+    return true;
+  });
+}
+async function withMutex(lockPath, operation) {
+  const mutex = `${lockPath}.mutex`;
+  await mkdir(dirname(lockPath), { recursive: true });
+  try {
+    await mkdir(mutex);
+  } catch (error) {
+    if (error?.code === "EEXIST") return null;
+    throw error;
+  }
+  try {
+    return await operation();
+  } finally {
+    await rm(mutex, { recursive: true, force: true });
+  }
+}
+async function readLease(lockPath) {
+  try {
+    return JSON.parse(await readFile(lockPath, "utf8"));
+  } catch (error) {
+    if (error?.code === "ENOENT") return null;
+    throw error;
+  }
+}
+async function writeLease(lockPath, lease) {
+  const temporary = resolve(dirname(lockPath), `.${lease.owner_token}.ready-queue.tmp`);
+  await writeFile(temporary, `${JSON.stringify(lease)}\n`, "utf8");
+  await rename(temporary, lockPath);
+}

package/templates/.agents/skills/zaip-skill-executar-fila-pronta/scripts/ready-queue-fence.test.mjs

@@ -0,0 +1,60 @@
+import assert from "node:assert/strict";
+import { mkdtemp, rm } from "node:fs/promises";
+import { tmpdir } from "node:os";
+import { join } from "node:path";
+import test from "node:test";
+import {
+  acquireReadyQueueFence,
+  assertReadyQueueFence,
+  releaseReadyQueueFence,
+  renewReadyQueueFence,
+} from "./ready-queue-fence.mjs";
+
+test("fence is exclusive, monotonic, and rejects a stale owner", async () => {
+  const directory = await mkdtemp(join(tmpdir(), "zaip-ready-fence-"));
+  const lock = join(directory, "ready-queue.lock.json");
+  try {
+    const [first, concurrent] = await Promise.all([
+      acquireReadyQueueFence(lock, {
+        owner_token: "owner-a",
+        now: "2026-08-05T18:00:00.000Z",
+        expires_at: "2026-08-05T18:01:00.000Z",
+      }),
+      acquireReadyQueueFence(lock, {
+        owner_token: "owner-b",
+        now: "2026-08-05T18:00:00.000Z",
+        expires_at: "2026-08-05T18:01:00.000Z",
+      }),
+    ]);
+    const owner = first ?? concurrent;
+    assert.equal([first, concurrent].filter((candidate) => candidate !== null).length, 1);
+    assert.equal(owner?.fencing_token, 1);
+    const second = await acquireReadyQueueFence(lock, {
+      owner_token: "owner-b",
+      now: "2026-08-05T18:01:01.000Z",
+      expires_at: "2026-08-05T18:02:00.000Z",
+    });
+    assert.equal(second?.fencing_token, 2);
+    assert.equal(
+      await renewReadyQueueFence(
+        lock,
+        owner,
+        "2026-08-05T18:01:02.000Z",
+        "2026-08-05T18:03:00.000Z",
+      ),
+      null,
+    );
+    assert.equal(await assertReadyQueueFence(lock, owner, "2026-08-05T18:01:02.000Z"), false);
+    assert.equal(await releaseReadyQueueFence(lock, owner, "2026-08-05T18:01:02.000Z"), false);
+    assert.equal(await releaseReadyQueueFence(lock, second, "2026-08-05T18:01:03.000Z"), true);
+    const third = await acquireReadyQueueFence(lock, {
+      owner_token: "owner-c",
+      now: "2026-08-05T18:01:04.000Z",
+      expires_at: "2026-08-05T18:02:00.000Z",
+    });
+    assert.equal(third?.fencing_token, 3);
+    assert.equal(await releaseReadyQueueFence(lock, third, "2026-08-05T18:01:05.000Z"), true);
+  } finally {
+    await rm(directory, { recursive: true, force: true });
+  }
+});