@zaip-ai/cli 1.0.8 → 1.3.1

package/templates/.agents/growth/estrategia-bootstrap-90-dias.md

@@ -0,0 +1,169 @@
+# Estratégia de Growth Bootstrap — 90 Dias
+
+**Data:** 22 de agosto de 2026
+**Horizonte:** 90 dias
+**Estado:** plano operacional; não é projeção realizada nem autorização para campanhas, contratações ou despesas externas.
+
+## Decisão estratégica
+
+Nos próximos 90 dias, a Zaip deve priorizar **repetibilidade comercial e implantação com caixa positivo**, não escala ampla. O foco é validar uma oferta específica para agências de performance que recebem leads de mídia paga e usam o WhatsApp para vender.
+
+O ponto de partida observado é um cliente pagante de **R$ 5 mil de MRR**. O case apresentado no pitch mostra resultado relevante, mas uma única conta não comprova repetibilidade por segmento, canal ou coorte. Portanto, ROI não será prometido como resultado padrão.
+
+## Resultado-alvo conservador
+
+| Cenário | Clientes ativos no dia 90 | MRR ao final do período | Leitura |
+|---|---:|---:|---|
+| Mínimo aceitável | 2 | R$ 7 mil | Um novo contrato pago; tese ainda em validação. |
+| Base conservadora | 3 | R$ 9 mil | Dois novos contratos de R$ 2 mil/mês. |
+| Alvo | 4 | R$ 10–11 mil | Dois contratos de R$ 2 mil e um de R$ 1–2 mil/mês. |
+
+As faixas acima são cenários de planejamento. Elas pressupõem manutenção do cliente atual, ausência de churn e recebimento normal das mensalidades.
+
+## Oferta inicial padronizada
+
+**Proposta de valor**
+
+> A Zaip transforma o WhatsApp em uma operação comercial 24/7: responde, qualifica, acompanha e encaminha oportunidades para fechamento.
+
+**Pacote de entrada**
+
+- R$ 2 mil/mês + setup pago antes do início;
+- implantação de até 30 dias, com escopo e integrações definidos na proposta;
+- configuração do fluxo, base de conhecimento, regras de qualificação e handoff humano;
+- revisão de resultados no dia 30;
+- sem customizações fora do escopo durante o piloto.
+
+O setup pago evita que a Zaip financie a implantação do cliente. Caso a operação exija trabalho não padronizado, a proposta deve separar esse valor da mensalidade.
+
+## ICP e desqualificação
+
+### ICP inicial
+
+- Agência de performance no Brasil;
+- recebe leads de mídia paga pelo WhatsApp;
+- já possui vendedor, closer ou responsável por fechamento;
+- perde velocidade ou consistência no atendimento/follow-up;
+- consegue disponibilizar dados mínimos de origem, atendimento e conversão.
+
+### Não priorizar nos 90 dias
+
+- Empresas sem volume de leads ou sem processo comercial mínimo;
+- projetos que dependem de produto novo, integração inédita ou customização extensa;
+- clientes que exigem garantia de receita;
+- segmentos diferentes do ICP antes de existirem dois casos comparáveis.
+
+## Motores de aquisição
+
+### 1. Outbound do founder — motor de aprendizagem
+
+O fundador conduz o diagnóstico e a venda para aprender linguagem, dor, objeções e critérios de compra. A abordagem oferece uma avaliação objetiva do funil de WhatsApp, não uma promessa genérica de IA.
+
+Meta semanal:
+
+| Atividade | Meta |
+|---|---:|
+| Contas ICP pesquisadas | 25 |
+| Contatos personalizados enviados | 25 |
+| Conversas qualificadas | 5 |
+| Diagnósticos realizados | 2 |
+| Propostas enviadas | 1–2 |
+
+### 2. Parceiros de indicação — motor de distribuição
+
+Mapear consultores comerciais, gestores de tráfego e agências complementares que já atendem o ICP. Nos 90 dias, os acordos devem ser manuais e simples: comissão somente após o recebimento do primeiro pagamento do cliente indicado. O objetivo é aprender qualidade e velocidade do canal, não criar um programa de parceria completo.
+
+### 3. Prova de resultado — motor de conversão
+
+Transformar o caso atual e os próximos pilotos em provas comparáveis. Cada case deve informar contexto, volume, período, baseline, intervenções, resultado observado e limitações. Não usar ganhos estimados como se fossem receita realizada.
+
+## Plano mensal
+
+### Mês 1 — Provar a oferta
+
+**Objetivo:** fechar um cliente de R$ 2 mil/mês e tornar a implantação repetível.
+
+- Definir lista de 100 contas ICP e cadência de outbound;
+- criar diagnóstico comercial, proposta e checklist de onboarding;
+- registrar baseline antes do go-live;
+- fechar um cliente com setup pago;
+- documentar objeções, motivo de ganho/perda e tempo de implantação.
+
+**Gate do mês:** há um contrato novo pago e o onboarding pode ser concluído sem trabalho fora do escopo.
+
+### Mês 2 — Repetir com evidência
+
+**Objetivo:** fechar o segundo cliente de R$ 2 mil/mês e validar a retenção inicial.
+
+- Repetir a mesma oferta e o mesmo ICP;
+- iniciar cinco conversas com potenciais parceiros;
+- publicar uma prova comercial com método e limitações;
+- reduzir o tempo de implantação identificando tarefas repetitivas;
+- realizar a revisão de 30 dias do primeiro novo cliente.
+
+**Gate do mês:** dois clientes novos ou um novo cliente e pipeline qualificado suficiente para compensar o atraso, sem aumento de customização.
+
+### Mês 3 — Escolher o canal vencedor
+
+**Objetivo:** alcançar o cenário base de três clientes ativos ou o alvo de quatro.
+
+- Comparar outbound e indicação por reuniões, propostas, fechamentos, MRR e esforço do founder;
+- fechar um terceiro contrato somente se o onboarding mantiver o padrão;
+- decidir o ICP e o canal para o trimestre seguinte;
+- formalizar playbook mínimo de venda, onboarding e revisão de resultado;
+- manter investimento em aquisição dentro do teto definido.
+
+**Gate do período:** continuar com o canal que mostrou melhor combinação de fechamento, velocidade de ativação e esforço de implantação. Não escalar mídia ou contratação fixa sem esse sinal.
+
+## Caixa e guardrails
+
+| Regra | Limite inicial |
+|---|---|
+| Nova despesa de aquisição | R$ 500–1.000 por mês, em testes reversíveis |
+| Mídia paga | Não iniciar antes de conversão repetível no ICP |
+| Contratação fixa | Não realizar no horizonte de 90 dias |
+| Setup | Cobrado antecipadamente |
+| Customização | Escopo e preço separados da mensalidade |
+
+Esses limites preservam o bootstrap. Devem ser revistos somente com dados de margem, custo de implantação, churn e capacidade, que ainda não estão demonstrados neste plano.
+
+## Painel semanal
+
+| Etapa | Métrica | Definição |
+|---|---|---|
+| Aquisição | Contas ICP contatadas | Contas que atendem aos critérios definidos. |
+| Qualificação | Conversas e diagnósticos | Reuniões com dor e contexto comercial verificáveis. |
+| Conversão | Propostas, fechamentos e taxa de ganho | Pipeline comercial por período. |
+| Receita | MRR novo e MRR total | Receita recorrente contratada, sem confundir setup com MRR. |
+| Implantação | Dias até ativação | Da confirmação do setup ao go-live. |
+| Uso | Leads atendidos e tempo de primeira resposta | Indicadores operacionais do cliente. |
+| Resultado | Qualificados, agendamentos e vendas atribuídas | Sempre com período e método explícitos. |
+| Retenção | Risco de churn e expansão | Sinais qualitativos e financeiros por conta. |
+
+## Experimento prioritário
+
+**Hipótese:** agências de performance com leads de mídia paga converterão uma oferta de implantação assistida de IA Comercial para WhatsApp em contratos de R$ 2 mil/mês quando receberem um diagnóstico concreto de velocidade, atendimento e follow-up.
+
+| Item | Definição |
+|---|---|
+| População | 100 agências de performance que atendam ao ICP inicial. |
+| Alavanca | Outbound personalizado oferecendo diagnóstico e demonstração contextual. |
+| Métrica primária | Novos contratos pagos. |
+| Guardrails | Setup pago, escopo padronizado, sem garantia de receita e sem customização não precificada. |
+| Duração | 30 dias por ciclo; três ciclos no horizonte. |
+| Critério de decisão | Manter o ICP/canal se gerar contrato pago sem ampliar esforço de implantação; caso contrário, revisar mensagem, segmentação ou oferta. |
+| Responsável | Founder / Growth. |
+
+## Condição para escalar depois dos 90 dias
+
+Só ampliar mídia, parceiros ou equipe se houver, ao mesmo tempo:
+
+1. ao menos três clientes ativos;
+2. onboarding controlado e documentado;
+3. pelo menos um canal repetível;
+4. evidência de uso e retenção após 30 dias;
+5. entendimento de margem, custo de implantação e capacidade.
+
+## Fonte de referência
+
+- `C:/Users/david/OneDrive/Zaip/Apresentações/Pitch - Zaip - 2026 - v21.pptx`, especialmente os slides 9 a 15. O material foi usado para contexto de proposta, preços, caso inicial e ambição; não constitui validação independente das fontes, estimativas ou projeções citadas nele.

package/templates/.agents/growth/strategy.md

@@ -0,0 +1,27 @@
+# Estratégia de Growth — Zaip
+
+**Status:** draft estratégico
+**Decisão norteadora:** provar repetibilidade comercial para PMEs e parceiros, preservando eficiência e evidência.
+
+## Tese
+
+A Zaip cresce ao melhorar a conversão de leads que já chegam pelo WhatsApp e ao criar distribuição por agências e consultores que monetizam implantação e recorrência.
+
+## Alavancas prioritárias
+
+- Conversão de tráfego pago existente em PMEs com fit.
+- Cases que conectem operação, processo e resultado observável.
+- Programa de parceiros com oferta, onboarding e retenção claros.
+- Instrumentação de funil: origem, qualificação, oportunidade, venda, retenção e expansão.
+
+## Experimentos candidatos
+
+| Hipótese | Métrica primária | Guardrail |
+|---|---|---|
+| Demonstração do fluxo no WhatsApp aumenta qualificação. | taxa de lead qualificado | custo por lead e taxa de comparecimento |
+| Case contextualizado aumenta confiança comercial. | conversão para reunião | qualidade do lead |
+| Oferta de parceiro aumenta distribuição. | parceiros ativos com pipeline | retenção e suporte por parceiro |
+
+## Lacunas
+
+Não há metas numéricas, baseline de funil ou custos de aquisição fornecidos. Definir essas medidas antes de classificar experimentos como vencedores.

package/templates/.agents/marketing/estrategia-marketing-zaip-90-dias.md

@@ -0,0 +1,197 @@
+# Estratégia de marketing ZAIP-AIOS — 90 dias
+
+**Data do plano:** 22 de agosto de 2026
+**Horizonte:** semanas 1–12
+**Status:** plano interno para validação; não autoriza publicação, contato comercial, coleta de dados pessoais ou promessa comercial.
+
+## 1. Contexto, evidências e limites
+
+### Evidências confirmadas no README
+
+- O ZAIP-AIOS se apresenta como um sistema operacional de execução autônoma com **23 agentes especializados em 6 squads**, operando no Codex.
+- O fluxo relaciona planejamento, execução, revisão, testes, validação e critérios de aceite; uma Task não é concluída somente porque um agente terminou.
+- A fonte de verdade é Git-native: requisitos, decisões, implementações, testes, revisões e evidências permanecem no repositório. O Dashboard usa um SQLite local, descartável e reconstruível como camada de consulta.
+- O Dashboard reúne Kanban, custos, cobertura, bloqueios e rastreabilidade entre PRD, Requirements, SPEC, Change, Task, Execution, Runs e Evidence. Telemetria ausente continua `unknown` ou `null`, sem ser exibida como zero.
+- O README informa uma comparação de amostra: custo médio por Task de R$ 67 para R$ 44 (redução de 34,3%) e custo médio por hora de R$ 410 para R$ 154 (62,4%). O próprio documento restringe esses resultados à amostra, a coortes comparáveis e à metodologia declarada; eles não podem ser generalizados a todo modelo, repositório ou tarefa.
+- O produto também descreve capacidade para Operações, Growth, Marketing, Branding e Vendas, embora sua origem tenha forte foco em desenvolvimento de software.
+
+**Fontes internas:** [README.md](../README.md), seções “Visão rápida”, “Dashboard Local”, “Qualidade e evidências” e “Economia medida e meta central por tarefa” (snapshot consultado em 22/08/2026).
+
+### Hipóteses e assunções a validar
+
+- **H1 — dor prioritária:** líderes técnicos que já usam agentes de código percebem retrabalho, perda de contexto ou dificuldade de auditar entregas como problema relevante.
+- **H2 — entrada:** uma demonstração de uma Task real, com critérios de aceite e evidência, comunica valor melhor que uma apresentação de todos os 23 agentes.
+- **H3 — conversão:** consultorias de software e squads técnicos aceitam um piloto limitado quando há uma definição prévia de sucesso e não há promessa de economia universal.
+- **H4 — canal:** conteúdo técnico em GitHub, LinkedIn e comunidades de engenharia alcança o ICP inicial com qualidade suficiente para entrevistas e pilotos. Esta é uma hipótese de canal, não uma métrica observada.
+- **Assunção de marca:** não foi fornecido Brandbook aprovado para este plano. A aplicação de identidade visual, tom definitivo e ativos gráficos permanecem pendentes de input aprovado.
+
+## 2. Objetivo para os próximos 90 dias
+
+Validar uma proposta de valor repetível para equipes técnicas que usam agentes de IA: **entregas governadas, rastreáveis e verificáveis no Git**, com um caminho mensurável de interesse para ativação/piloto.
+
+Ao fim das 12 semanas, a decisão é escolher uma mensagem, um segmento prioritário e um formato de demonstração com evidência suficiente para repetir a abordagem — ou documentar que a hipótese não se sustentou. O plano não estabelece meta de receita, economia garantida ou automação sem supervisão humana.
+
+## 3. Público e priorização
+
+### ICP prioritário
+
+**Líder técnico (CTO, engineering manager, tech lead ou founder técnico) de equipe de 5–30 pessoas que já usa Codex ou agentes de IA em repositórios Git.**
+
+Sinais de aderência: revisão de PRs, requisitos e testes importam; há demanda por recuperar decisões e evidências; existe alguém capaz de conduzir uma instalação/piloto técnico; a equipe quer analisar custo, cobertura ou rework sem confundir ausência de dados com zero.
+
+### Segmento de foco inicial
+
+**Software houses e consultorias de desenvolvimento** com entregas recorrentes a clientes. A mensagem deve enfatizar previsibilidade, revisão e prova do que foi entregue; não afirmar redução de margem, prazo ou custo antes de medição no contexto do cliente.
+
+### Segmentos posteriores
+
+1. Squads internos de produto/engenharia que necessitam manter o histórico de decisões e evidências no Git.
+2. Times de Operações, Growth, Marketing, Branding e Vendas que tenham trabalho definido, autoridade de execução e condições para usar o fluxo ZAIP; validar em separado, sem extrapolar a evidência de desenvolvimento.
+3. Organizações com requisitos de auditoria e governança, somente após confirmar segurança, permissões, implantação e necessidades regulatórias específicas.
+
+### Exclusões iniciais
+
+Não priorizar equipes sem responsável técnico, sem repositório Git ou que busquem apenas geração instantânea de código sem critérios de aceite, revisão e evidência.
+
+## 4. Posicionamento e mensagens
+
+### Posicionamento proposto
+
+> ZAIP-AIOS organiza o trabalho com agentes de IA para que planejamento, execução, validação e evidências permaneçam conectados no Git até os critérios de aceite serem atendidos.
+
+Evitar “autonomia total”, “substitui desenvolvedores” e qualquer promessa de custo/tempo universal. Preferir **autonomia governada e verificável**; a decisão humana, a revisão e a qualidade são parte do fluxo.
+
+| Dor percebida | Mensagem de campanha | Demonstração/evidência necessária |
+| --- | --- | --- |
+| “A IA produz código, mas não sei se a entrega está pronta.” | Uma Task só encerra com critérios de aceite e evidências objetivas de qualidade. | Fluxo de Task com checks, review/teste e Evidence vinculada. |
+| “Perdemos contexto e repetimos decisões.” | Intenção, decisões, execução e resultado mantêm relações rastreáveis no repositório. | Navegação de PRD/Task/Execution/Evidence e histórico Git. |
+| “Coordenar especialistas virou trabalho manual.” | O sistema organiza dependências e encaminha o trabalho ao especialista necessário. | Demonstração de cadeia limitada a um caso real; sem prometer que toda demanda é automática. |
+| “Não consigo discutir o custo real do trabalho com IA.” | Custos, duração e cobertura podem ser observados por unidade de trabalho; telemetria incompleta permanece explícita. | Cost Monitor com origem e lacunas de cobertura visíveis. |
+
+### Mensagens por estágio
+
+- **Descoberta:** “IA no repositório precisa de uma definição de pronto, não apenas de uma resposta gerada.”
+- **Consideração:** “Conecte requisitos, execução, testes e evidências em uma trilha Git-native.”
+- **Piloto:** “Escolha uma Task real, defina o baseline e compare o fluxo completo de conclusão.”
+- **Prova:** “Relate o resultado observado, a cobertura e os limites da amostra; não transforme uma coorte em promessa.”
+
+## 5. Funil e canais
+
+```text
+Conteúdo técnico / demonstração
+            ↓
+Diagnóstico de aderência (dor, Git, uso de agentes, autoridade)
+            ↓
+Demo orientada a uma Task e critérios de aceite
+            ↓
+Piloto limitado com baseline, qualidade e cobertura definidos
+            ↓
+Relato de resultado observado ou aprendizado de não-aderência
+```
+
+| Etapa | Canal principal | Ativo | Chamada para ação | Sinal de avanço |
+| --- | --- | --- | --- | --- |
+| Descoberta | GitHub, LinkedIn, comunidades técnicas | Post curto, diagrama e vídeo de até 3 minutos | Ver a demonstração / responder à pergunta de dor | Visita qualificada, comentário técnico ou inscrição voluntária |
+| Consideração | Página/README e conversa técnica | Guia de avaliação e demo de fluxo | Solicitar diagnóstico | Perfil confirma repositório, uso de agentes e responsável técnico |
+| Piloto | Sessão remota autorizada | Plano de uma Task, baseline e critérios | Iniciar piloto limitado | Escopo, critérios e fonte de dados aceitos |
+| Prova | Estudo de caso aprovado | Caso com método, população e limites | Avaliar fluxo semelhante | Caso revisado pelo participante; nenhum dado confidencial publicado sem autorização |
+
+Os canais são próprios ou comunitários; qualquer publicação, mensagem direta, formulário, analytics externo ou contato depende de autorização operacional específica.
+
+## 6. Roadmap de execução
+
+### Semanas 1–4 — fundação e diagnóstico
+
+1. Consolidar esta narrativa em uma página de mensagem: problema, fluxo, prova disponível e limites.
+2. Criar uma demo de até três minutos baseada em uma Task de exemplo, mostrando critérios de aceite, execução, verificação e evidência — sem dados sensíveis.
+3. Elaborar roteiro de diagnóstico com cinco perguntas: uso atual de agentes, tipo de trabalho, falha de qualidade/contexto, processo de revisão e capacidade de piloto.
+4. Preparar template de piloto: hipótese, baseline equivalente, fontes de custo/tempo, quality floor, cobertura e condições de interrupção.
+5. Entrevistar apenas contatos que autorizarem a conversa; registrar padrões de dor e objeções de forma agregada.
+
+**Gate da semana 4:** decidir se a dor e a mensagem foram compreendidas por participantes do ICP. Se não, revisar segmento ou mensagem antes de ampliar canais.
+
+### Semanas 5–8 — teste de mensagens e demonstrações
+
+1. Testar duas mensagens: **“entregas verificáveis com IA”** versus **“governança Git-native para agentes”**.
+2. Publicar/compartilhar somente os ativos aprovados, em cadência leve e consistente.
+3. Conduzir demos orientadas ao caso de uso, não ao catálogo completo de agentes.
+4. Qualificar interessados contra o ICP e convidar perfis aderentes a piloto limitado.
+5. Atualizar FAQ com objeções observadas: autonomia, segurança, custo equivalente, telemetria `unknown` e tempo de adoção.
+
+**Gate da semana 8:** selecionar mensagem vencedora pelo avanço qualificado (diagnóstico → demo/piloto), não somente por impressões ou curtidas.
+
+### Semanas 9–12 — pilotos e prova responsável
+
+1. Iniciar pilotos autorizados com uma unidade de trabalho e critérios de aceite definidos antes da execução.
+2. Medir conclusão, cobertura, rework, duração e custo somente quando a fonte e comparabilidade forem adequadas.
+3. Produzir um estudo de caso somente com permissão do participante; anonimizar ou manter interno se necessário.
+4. Documentar resultados inconclusivos e causas (cobertura incompleta, baseline não equivalente, escopo alterado) em vez de convertê-los em ganhos.
+5. Fazer retrospectiva: ICP, mensagem, canal, ativação, segurança percebida e decisão para o próximo ciclo.
+
+**Gate da semana 12:** manter, ajustar ou interromper o movimento de marketing com base nas métricas definidas abaixo e nas limitações observadas.
+
+## 7. Cadência de conteúdo
+
+Cadência inicial: **1 conteúdo técnico principal por semana**, transformado em até dois recortes curtos, mais uma demonstração ou sessão de perguntas a cada duas semanas se houver autorização e demanda. Priorizar qualidade, verificabilidade e aprendizado; não perseguir volume.
+
+| Semana | Tema principal | Formato | Evidência/limite obrigatório |
+| --- | --- | --- | --- |
+| 1 | O que significa “pronto” quando agentes executam trabalho | Post + diagrama | Critérios de aceite e evidências, sem alegação de economia |
+| 2 | Da intenção à Evidence no Git | Demo curta | Dados de exemplo ou autorizados |
+| 3 | Por que telemetria ausente não é custo zero | Artigo técnico | Explicar `unknown`/`null` e custo equivalente estimado |
+| 4 | Checklist para avaliar um piloto com agentes | Guia | Baseline e quality floor antes de comparar |
+| 5–6 | Duas mensagens do teste | Posts/demos A e B | Mesma CTA e janela de observação |
+| 7–8 | Objeções e FAQ | Artigo + sessão | Respostas condicionais, sem promessas absolutas |
+| 9–10 | Como ler resultados de um piloto | Template de caso | Método, cobertura e limites visíveis |
+| 11–12 | Aprendizados do ciclo | Retrospectiva | Separar dado observado, inferência e próxima hipótese |
+
+## 8. Backlog de experimentos
+
+| Prioridade | Experimento | Hipótese | Indicador primário | Critério de decisão |
+| --- | --- | --- | --- | --- |
+| P0 | Mensagem A vs. B | “Entregas verificáveis” gera mais avanço qualificado do que “governança Git-native”, ou o inverso. | Taxa de avanço de diagnóstico para demo/piloto por variante. | Manter a variante com diferença prática e qualitativa consistente após janela e volume definidos; se inconclusivo, registrar empate. |
+| P0 | Demo curta vs. visão de catálogo | Uma Task completa é mais clara que apresentar todos os agentes. | Participantes que descrevem corretamente o critério de pronto após a demo. | Adotar o formato que obtiver compreensão e convite ao próximo passo sem aumentar objeções críticas. |
+| P1 | Segmento: consultoria vs. squad interno | Um dos segmentos declara dor, autoridade e condição de piloto com maior frequência. | Proporção de conversas qualificadas que aceita definir um piloto. | Direcionar a próxima rodada ao segmento com melhor sinal qualitativo e quantitativo; não inferir tamanho de mercado. |
+| P1 | Checklist de piloto | Um checklist reduz escopo indefinido e comparações inválidas. | Pilotos com baseline, quality floor e cobertura definidos antes de iniciar. | Reter se elevar a completude de desenho do piloto sem impedir adesão legítima. |
+| P2 | Estudo de caso com limites explícitos | Transparência metodológica aumenta confiança dos perfis técnicos. | Feedback de confiança e solicitações qualificadas após leitura. | Reutilizar se a maioria do feedback técnico considerar método e limites claros; caso contrário, revisar. |
+
+Para cada experimento, registrar período, público, variante, CTA, fonte de dados, número de observações, resultados, limitações e decisão. Sem tamanho de amostra e período definidos, tratar o resultado como exploratório.
+
+## 9. Métricas e definições
+
+| Métrica | Definição | Fonte mínima | Uso correto |
+| --- | --- | --- | --- |
+| Alcance qualificado | Pessoas/organizações do ICP que tiveram contato identificável e autorizado com o ativo. | Registro de campanha ou conversa, sem dados pessoais desnecessários. | Indicador de distribuição; não prova interesse. |
+| Diagnóstico qualificado | Conversa em que se confirmou ao menos: uso de agentes, repositório Git, dor relevante e responsável técnico. | Formulário/nota autorizada. | Entrada para demo; não é intenção de compra. |
+| Taxa diagnóstico → demo | Demos realizadas ÷ diagnósticos qualificados no mesmo período. | Agenda/registro de campanha. | Comparar canais e mensagens com mesma janela. |
+| Taxa demo → piloto | Pilotos com escopo aceito ÷ demos realizadas. | Documento de piloto. | Sinal de aderência; não equivale a receita. |
+| Ativação de piloto | Pilotos que executam a primeira Task definida com algum registro de verificação ÷ pilotos iniciados. | Registros Git/ZAIP autorizados. | Medir uso real, mantendo lacunas explícitas. |
+| Cobertura de evidências | Itens de critérios de aceite com evidência vinculada ÷ itens aplicáveis. | Task, testes, reviews e Evidence. | Qualidade do piloto; não fingir 100% se algo não foi observado. |
+| Resultado comparável | Diferença observada em coortes equivalentes de custo/duração/rework, com fonte e qualidade definidas. | Dados de coorte e metodologia. | Só comunicar quando as dimensões obrigatórias forem comparáveis; caso contrário, `null`/inconclusivo. |
+| Aprendizado validado | Hipótese com decisão registrada, baseada em dado e feedback rastreáveis. | Log de experimento. | Evita otimizar vaidade ou anedotas isoladas. |
+
+## 10. Instrumentação mínima
+
+1. **Registro de conteúdo:** data, canal, versão da mensagem, CTA, URL/ativo, público pretendido e aprovação de publicação.
+2. **Registro de conversa/piloto:** organização pseudonimizada quando possível, segmento, origem, estágio, dores declaradas, objeções, próxima ação autorizada e consentimento de contato.
+3. **Registro de experimento:** hipótese, variante, período, denominador, fonte, resultado, limitações e decisão.
+4. **Registro de piloto:** Task/escopo, critérios de aceite, baseline, quality floor, fontes de telemetria, cobertura, mudança de escopo e decisão de encerramento.
+5. **Privacidade e integridade:** não registrar prompts, código de cliente, credenciais ou dados pessoais além do necessário; não usar custo equivalente estimado como cobrança real; preservar ausências como indisponíveis.
+
+Começar com planilha/repositório interno controlado e IDs não identificáveis. Adoção de CRM, pixels, automações ou integrações é decisão posterior, com consentimento, segurança e responsável definidos.
+
+## 11. Riscos, limites e decisões pendentes
+
+| Risco ou limite | Mitigação proposta | Decisão pendente |
+| --- | --- | --- |
+| Transformar resultados da amostra em promessa universal de economia. | Em toda copy, citar contexto, método e limites; aprovar casos antes de publicar. | Definir processo de revisão de alegações mensuráveis. |
+| Confundir custo equivalente de API com cobrança real. | Rotular como estimativa e expor cobertura/fonte. | Definir glossário e responsável pela aprovação de métricas. |
+| Atrair público amplo demais, sem condição de adoção. | Qualificar pelo ICP e usar um piloto de uma Task. | Confirmar se consultorias ou squads internos têm prioridade comercial. |
+| Prometer autonomia irrestrita ou segurança não demonstrada. | Falar em fluxo governado, Git-native e evidências; encaminhar requisitos de segurança a validação técnica. | Definir claims de segurança aprovadas e limites de suporte. |
+| Brandbook/tom de voz não fornecido. | Usar linguagem técnica, objetiva e condicional neste plano. | Fornecer Brandbook aprovado ou autorizar decisão de marca. |
+| Dados de piloto incompletos ou coortes não equivalentes. | Tornar cobertura e inconclusão visíveis; não calcular “economia” sem requisitos. | Definir campos mínimos e owner da medição. |
+| Execução externa sem autoridade. | Este arquivo é planejamento interno; publicações, contato e coleta exigem autorização específica. | Nomear responsável, orçamento, canais e calendário de publicação. |
+
+## 12. Próxima decisão recomendada
+
+Aprovar ou ajustar o ICP de entrada — **consultorias de software e líderes de engenharia já usuários de agentes no Git** — e designar o responsável por: (1) validar Brandbook/tom, (2) aprovar ativos e publicação, (3) conduzir entrevistas autorizadas e (4) governar a medição dos pilotos. Com essas decisões, a primeira entrega executável é a demo curta de uma Task real com seus critérios de aceite e evidências.

package/templates/.agents/marketing/strategy.md

@@ -0,0 +1,29 @@
+# Estratégia de Marketing — Zaip
+
+**Status:** draft estratégico
+**Base de marca:** `.agents/branding/brandbook.md`
+
+## Objetivo
+
+Gerar demanda qualificada para a Zaip entre PMEs de serviço e desenvolver o canal de agências e parceiros sem reduzir a marca a automação genérica.
+
+## Público prioritário
+
+1. PMEs com ao menos um vendedor, volume de leads e WhatsApp como canal comercial.
+2. Agências e consultores que desejam criar receita recorrente com implantação de IA comercial.
+
+## Mensagem central
+
+Transforme conversas em receita previsível com IA comercial que segue processo, atualiza CRM, recupera leads e conduz ao próximo passo.
+
+## Pilares de conteúdo
+
+- Processo comercial no WhatsApp.
+- Prova contextualizada: case Moradigna e ROI observado.
+- Antes/depois de chatbot, atendimento e IA comercial.
+- CRM, recuperação de leads e handoff humano.
+- Oferta e capacitação para parceiros.
+
+## Métricas pendentes
+
+Definir CAC, taxa de lead qualificado, conversão por canal, ciclo de venda, retenção, receita por parceiro e atribuição antes de estabelecer metas numéricas.

package/templates/.agents/requirements/autonomous-assurance.md

@@ -4,9 +4,9 @@ id: REQUIREMENTS-AUTONOMOUS-ASSURANCE
 area: autonomous-assurance
 title: Garantia adaptativa e execução autônoma
 status: active
-version: 2
+version: 3
 source_change: null
-source_release: "1.0.8"
+source_release: "1.3.1"
 ---
 
 # Garantia adaptativa e execução autônoma
@@ -40,17 +40,17 @@ O framework deve preservar execução manual como padrão e permitir autonomia s
 - `AC-AUTO-001-03`: cada Task autônoma executa em Git worktree registrada, parte de raiz limpa, produz commit final, altera somente write scopes autorizados e aborta merge conflitante sem deixar merge parcial.
 - `AC-AUTO-001-04`: processos usam command allowlist, `shell: false`, diretório validado, ambiente mínimo allowlisted, limite de linha/stderr, timeout, cancelamento e budget de ferramentas/output.
 - `AC-AUTO-001-05`: checkpoints opacos de Codex ou Claude ficam somente em `.local`, são retomáveis e removidos ao terminar; estado governado usa compare-and-swap.
-- `AC-AUTO-001-06`: Tasks `lite` têm uma tentativa; `standard` e `critical` têm no máximo três tentativas de desenvolvimento/reparo, sem loops ilimitados.
-- `AC-AUTO-001-07`: trabalho `critical` usa contexto fresco por Task e verificador independente; SPEC/PRD também exigem verificador independente mesmo quando suas Tasks são `lite`.
+- `AC-AUTO-001-06`: Tasks `lite` têm uma tentativa; `standard` e `critical` têm no máximo três tentativas totais de desenvolvimento/reparo (`develop + fix`), sem loops ilimitados. Limites de fase e retries operacionais são controles separados e não ampliam esse teto, inclusive quando `max_phase_attempts` é nulo. Esgotamento gera checkpoint `blocked`, preservando estado e worktree; uma rechecagem explícita de candidato novo não reinicia contadores nem libera outro desenvolvimento automático. Verificar por testes de limite, replay e rechecagem.
+- `AC-AUTO-001-07`: toda Task autônoma preserva revisão independente do candidato; trabalho `critical` também usa contexto fresco, e SPEC/PRD mantêm revisão parental mesmo com Tasks `lite`. Reparo exige nova revisão; finding omitido não é resolvido, finding reapresentado reabre, e resolução exige Evidence do mesmo candidato e AC aplicável. QA legado ausente ou candidato desconhecido não concede aprovação. Verificar por testes negativos de QA e de frescor do candidato.
 
 ## REQ-EVOL-001 — Delta, lições e maturidade derivada
 
 Aprendizado e alegações de maturidade devem ser derivados de fatos verificáveis do candidato atual.
 
-- `AC-EVOL-001-01`: rework recebe delta explícito de AC, write scopes, findings e baseline; contexto antigo não é copiado sem relevância observável.
+- `AC-EVOL-001-01`: rework recebe delta explícito de AC, write scopes, findings e baseline; contexto antigo não é copiado sem relevância observável. Observações de convergência distinguem atividade operacional de prova nova: IDs, chamadas e fases não são evidência semântica. O padrão é observacional, sem dispensar gates. Comparação de recomendações exige candidato/política identificados, casos únicos e avaliação independente; divergência ou ausência rejeita a comparação, e seu resultado nunca autoriza automaticamente redução de revisões.
 - `AC-EVOL-001-02`: lesson exige finding e locator verificável; opinião isolada não promove Rule, Requirement ou skill.
 - `AC-EVOL-001-03`: maturidade progride sequencialmente por `declared`, `implemented`, `locally_evidenced`, `cleanroom_validated`, `representative_validated` e `production_observed`.
-- `AC-EVOL-001-04`: Evidence de validação referencia o hash exato do candidato; cleanroom e estados posteriores exigem verificador independente, e produção exige Run observado.
+- `AC-EVOL-001-04`: Evidence de validação referencia o hash exato do candidato; cleanroom e estados posteriores exigem verificador independente, e produção exige Run observado. No runtime autônomo, o candidato é confirmado por Git e por ausência de alterações posteriores de produto no escopo, não somente pelo hash declarado em artefatos. Aprovação independente e Evidence devem referenciar o mesmo candidato. Qualidade conhecida abaixo do piso bloqueia mesmo sem dados de custo disponíveis.
 
 ## REQ-QUALITY-001 — Gates de release e cobertura sem regressão
 

package/templates/.agents/requirements/comparative-audit.md

@@ -6,7 +6,7 @@ title: Auditoria comparativa e plano de evolução
 status: active
 version: 1
 source_change: null
-source_release: "1.0.8"
+source_release: "1.3.1"
 ---
 
 # Auditoria comparativa e plano de evolução

package/templates/.agents/requirements/context-engine.md

@@ -6,7 +6,7 @@ title: Contexto mínimo, seguro e navegável
 status: active
 version: 8
 source_change: null
-source_release: "1.0.8"
+source_release: "1.3.1"
 ---
 
 # Context engine

package/templates/.agents/requirements/cost-observability.md

@@ -6,7 +6,7 @@ title: Tokens, custos e cobertura
 status: active
 version: 10
 source_change: null
-source_release: "1.0.8"
+source_release: "1.3.1"
 ---
 
 # Cost observability

package/templates/.agents/requirements/dashboard-launch.md

@@ -6,7 +6,7 @@ title: Inicialização e hidratação confiável do dashboard
 status: active
 version: 1
 source_change: null
-source_release: "1.0.8"
+source_release: "1.3.1"
 ---
 
 # Inicialização e hidratação confiável do dashboard

package/templates/.agents/requirements/data-export.md

@@ -6,7 +6,7 @@ title: Exportação contextual de dados para Excel
 status: proposed
 version: 2
 source_change: null
-source_release: "1.0.8"
+source_release: "1.3.1"
 ---
 
 # Exportação contextual de dados

package/templates/.agents/requirements/design-system.md

@@ -6,7 +6,7 @@ title: Contrato visual e catálogo executável
 status: active
 version: 3
 source_change: null
-source_release: "1.0.8"
+source_release: "1.3.1"
 ---
 
 # Design system

package/templates/.agents/requirements/execution-engine.md

@@ -4,9 +4,9 @@ id: REQUIREMENTS-EXECUTION-ENGINE
 area: execution-engine
 title: Preparação, materialização e DAG
 status: active
-version: 10
+version: 11
 source_change: null
-source_release: "1.0.8"
+source_release: "1.3.1"
 ---
 
 # Execution engine
@@ -59,4 +59,4 @@ Execuções devem limitar repetição por checkpoints suaves e verificar somente
 - `AC-EXEC-005-04`: risco `lite` executa ao menos uma validação scoped e uma Evidence cobrindo todos os ACs aplicáveis, sem teto de artefatos; `standard` executa ao menos duas validações ou três no perfil elevado, inclui teste executado e uma Evidence consolidada; `critical` aplica quality review independente e somente os controles críticos ativados pelos sinais persistidos. Nenhum perfil exige bateria irrelevante.
 - `AC-EXEC-005-05`: a skill de execução exige refresh seletivo e checkpoint compacto ao atingir os budgets suaves.
 - `AC-EXEC-005-06`: quando um plano visível é útil, cada passo começa com `DEFINE:`, `PLAN:`, `EXECUTE:` ou `VERIFY:`, usa somente fases aplicáveis, contém no máximo 5 passos e combina ações triviais; tarefas simples podem omitir o plano.
-- `AC-EXEC-005-07`: checkpoints são acionados somente por ciclos; telemetria de input não cacheado do provider e contexto observável permanece registrada com sua origem, sem inventar valores ausentes.
+- `AC-EXEC-005-07`: checkpoints suaves de contexto são acionados somente por ciclos; telemetria de input não cacheado do provider e contexto observável permanece registrada com sua origem, sem inventar valores ausentes. Checkpoints de segurança por esgotamento de tentativas semânticas são distintos desse contador. Observações de convergência não concedem aprovação nem cancelam trabalho por duração; tempo não observado permanece indisponível.

package/templates/.agents/requirements/kanban-dashboard.md

@@ -4,13 +4,21 @@ id: REQUIREMENTS-KANBAN-DASHBOARD
 area: kanban-dashboard
 title: Projeções operacionais e analíticas
 status: active
-version: 13
+version: 14
 source_change: null
-source_release: "1.0.8"
+source_release: "1.3.1"
 ---
 
 # Kanban and dashboard
 
+## REQ-TRACE-SELECTOR-OPEN — Opções do seletor de Tasks
+
+O seletor da aba Rastreabilidade deve abrir a lista completa ao clicar no campo, inclusive quando já existe uma Task selecionada, preservando busca, seleção e acessibilidade.
+
+- `AC-TRACE-SELECTOR-OPEN-01`: clicar no campo com Task selecionada abre todas as opções.
+- `AC-TRACE-SELECTOR-OPEN-02`: digitar filtra opções e selecionar continua carregando a Task.
+- `AC-TRACE-SELECTOR-OPEN-03`: o comportamento possui teste focado acessível.
+
 ## REQ-DASH-001 — Estado e visão macro
 
 Kanban, dashboard e Cost Monitor devem projetar o estado Git-native e distinguir planejamento de execução.

package/templates/.agents/requirements/model-orchestration.md

@@ -6,7 +6,7 @@ title: Seleção automática e observável de modelo e effort
 status: active
 version: 7
 source_change: null
-source_release: "1.0.8"
+source_release: "1.3.1"
 ---
 
 # Orquestração de modelos

package/templates/.agents/requirements/public-distribution.md

@@ -6,7 +6,7 @@ title: Distribuição pública e ativação
 status: active
 version: 3
 source_change: null
-source_release: "1.0.8"
+source_release: "1.3.1"
 ---
 
 # Distribuição pública e ativação

package/templates/.agents/requirements/software-architecture.md

@@ -6,7 +6,7 @@ title: Layout modular e limites de código-fonte
 status: active
 version: 5
 source_change: null
-source_release: "1.0.8"
+source_release: "1.3.1"
 ---
 
 # Software architecture

package/templates/.agents/requirements/strategic-improvements.md

@@ -6,7 +6,7 @@ title: Melhorias estratégicas de custo, qualidade e resiliência
 status: active
 version: 1
 source_change: null
-source_release: "1.0.8"
+source_release: "1.3.1"
 ---
 
 # Melhorias estratégicas de custo, qualidade e resiliência

package/templates/.agents/requirements/work-lifecycle.md

@@ -4,9 +4,9 @@ id: REQUIREMENTS-WORK-LIFECYCLE
 area: work-lifecycle
 title: Ciclo de vida do trabalho
 status: active
-version: 23
+version: 24
 source_change: null
-source_release: "1.0.8"
+source_release: "1.3.1"
 ---
 
 # Work lifecycle
@@ -36,8 +36,8 @@ Cada alteração de código deve possuir Change criada antes da mutação, com n
 
 - `AC-WORK-002-01`: `change.md` registra plano, implementação, decisões, evidências, evals, testes e resultado.
 - `AC-WORK-002-02`: decisões distinguem origem `human` e `ai`, inclusive quando não houve decisão.
-- `AC-WORK-002-03`: cada evidência referencia o Acceptance Criterion comprovado.
-- `AC-WORK-002-04`: somente artefatos tipados, aprovados, vinculados à Task/Change/Execution/Run e ao commit esperado contam para assurance; declaração textual ou teste não executado não conta.
+- `AC-WORK-002-03`: cada evidência referencia o Acceptance Criterion comprovado. Nas novas entregas, executor/revisor definem cenário, expectativa, modalidade e ambiente autorizado antes da implementação e registram resultado observado, momento real, candidato/ambiente efetivamente examinados, locators e limitações conforme o contrato compartilhado de prova observável da skill Change. Prova visual exige captura real examinada; integração entre componentes exige correlação do cenário. Verificar por exemplos discriminantes, schema e testes CLI; a CLI registra a observação declarada, não executa o procedimento nem certifica sua veracidade automaticamente.
+- `AC-WORK-002-04`: somente artefatos tipados, aprovados, vinculados à Task/Change/Execution/Run e ao commit esperado contam para assurance; declaração textual ou teste não executado não conta. Observações V1 são sidecars referenciados por locators da Evidence V2, sem novos estados de Task. Registro e leitura de assurance rejeitam referências ausentes, inválidas, não confirmadas ou incompatíveis em identidade, AC e candidato. Estados limited/pending/failed/not_applicable não alimentam aprovação; confirmação exige identidade de candidato/ambiente e contexto pertinente. Preservar V2 sem observações, sem promover históricos, exigir observações retroativamente ou autorizar reuso entre Runs. Verificar caminhos positivos/negativos do writer e reader e compatibilidade de locators legados; seleção de todas as modalidades obrigatórias e invalidação ambiental continuam sob revisão, não são inferidas automaticamente.
 - `AC-WORK-002-05`: entregas originadas de SPEC ou PRD mantêm uma matriz parental de AC, validações de integração e Evidences próprias, sem reutilizar a mera quantidade de artefatos das Tasks como prova da entrega.
 - `AC-WORK-002-06`: cada outcome de PRD possui um `OUT-*` persistido e único, alinhado 1:1 ao texto humano; delivery consome esse campo tipado sem cast estrutural e bloqueia outcome vazio, duplicado, órfão ou sem Evidence parental vinculada ao commit final e a Run independente.