adi_dev_workflow 1.2.0 → 1.3.0

package/frameworks/skills/sdd-tech-spec-expert/evals/evals.json

@@ -0,0 +1,199 @@
+{
+  "skill_name": "sdd-tech-spec-expert",
+  "evals": [
+    {
+      "id": 1,
+      "name": "prd-usuario-existente",
+      "prompt": "Preciso gerar o SPEC_TECH para a feature de usuario. O PRD aprovado esta em docs/feature-user/v1/prd.md",
+      "expected_output": "A skill deve: (1) ler o PRD aprovado em docs/feature-user/v1/prd.md, (2) pesquisar o codebase (CLAUDE.md, .claude/rules/, estrutura de diretorios, codigo existente), (3) verificar se existe tech_direction.md na pasta da feature, (4) iniciar o processo de coleta fazendo UMA pergunta por vez ao usuario, (5) NAO bombardear com multiplas perguntas de uma vez",
+      "files": [
+        "docs/feature-user/v1/prd.md"
+      ],
+      "assertions": [
+        {
+          "name": "leu-prd-aprovado",
+          "type": "tool_usage",
+          "description": "Deve ler o arquivo PRD aprovado antes de fazer qualquer pergunta",
+          "check": "A skill usou Read para ler docs/feature-user/v1/prd.md"
+        },
+        {
+          "name": "pesquisou-codebase",
+          "type": "tool_usage",
+          "description": "Deve pesquisar regras do projeto e estrutura do codebase",
+          "check": "A skill leu CLAUDE.md e/ou arquivos em .claude/rules/"
+        },
+        {
+          "name": "verificou-tech-direction",
+          "type": "tool_usage",
+          "description": "Deve verificar se existe tech_direction.md na pasta da feature",
+          "check": "A skill tentou ler ou verificar a existencia de docs/feature-user/v1/tech_direction.md"
+        },
+        {
+          "name": "uma-pergunta-por-vez",
+          "type": "output_quality",
+          "description": "Deve fazer apenas UMA pergunta tecnica por vez, nao bombardear o usuario",
+          "check": "A primeira interacao com o usuario contem no maximo 1 pergunta tecnica clara (pode ter sub-opcoes, mas e 1 topico)"
+        },
+        {
+          "name": "resumo-do-prd",
+          "type": "output_content",
+          "description": "Deve apresentar um resumo do que entendeu do PRD antes de iniciar perguntas",
+          "check": "A skill apresenta um resumo do objetivo da feature (modulo de usuario, cadastro, login, consulta, atualizacao)"
+        }
+      ]
+    },
+    {
+      "id": 2,
+      "name": "spec-tech-completo-16-secoes",
+      "prompt": "Gere o SPEC_TECH para a feature de usuario. PRD em docs/feature-user/v1/prd.md. Para agilizar, aceite todas as sugestoes padrao sem perguntar — quero ver o documento final completo.",
+      "expected_output": "A skill deve gerar um SPEC_TECH completo com TODAS as 16 secoes do template, salvar o arquivo fisico em docs/feature-user/v1/spec_tech.md ANTES de apresentar ao usuario, e NAO iniciar o TASK PLAN automaticamente",
+      "files": [
+        "docs/feature-user/v1/prd.md"
+      ],
+      "assertions": [
+        {
+          "name": "todas-16-secoes",
+          "type": "output_content",
+          "description": "O SPEC_TECH gerado deve conter todas as 16 secoes do template",
+          "check": "O documento contem secoes 1 (Identificacao), 2 (Resumo Tecnico), 3 (Arquitetura), 4 (Estruturas de Dados), 5 (Regras Tecnicas), 6 (Fluxos Tecnicos), 7 (APIs/Endpoints), 8 (Frontend/Mobile), 9 (Banco Local/Cache), 10 (Dependencias), 11 (Requisitos Nao Funcionais), 12 (Criterios Tecnicos), 13 (Riscos), 14 (Estrategia de Testes), 15 (Arquivos Envolvidos), 16 (Checklist Final)"
+        },
+        {
+          "name": "arquivo-salvo-antes-de-apresentar",
+          "type": "tool_usage",
+          "description": "Deve salvar o arquivo fisico ANTES de apresentar ao usuario",
+          "check": "A skill usou Write para salvar em docs/feature-user/v1/spec_tech.md antes de mostrar o conteudo ao usuario"
+        },
+        {
+          "name": "nao-iniciou-task-plan",
+          "type": "output_content",
+          "description": "NAO deve sugerir ou iniciar a proxima etapa (TASK PLAN) automaticamente",
+          "check": "A skill NAO menciona executar /sdd:generate-task-plan nem inicia geracao de tasks. Apenas pergunta se o SPEC esta aprovado"
+        },
+        {
+          "name": "mapeamento-user-stories-secao-5-1",
+          "type": "output_content",
+          "description": "A secao 5.1 deve mapear TODAS as user stories do PRD para definicoes tecnicas",
+          "check": "A secao 5.1 contem mapeamento de US-01, US-02, US-03 e US-04 para definicoes tecnicas correspondentes"
+        },
+        {
+          "name": "secao-15-tres-subsecoes",
+          "type": "output_content",
+          "description": "A secao 15 deve ter 3 subsecoes: Criar, Modificar e Referencia",
+          "check": "A secao 15 contem 15.1 (Arquivos a Criar), 15.2 (Arquivos a Modificar) e 15.3 (Arquivos de Referencia)"
+        },
+        {
+          "name": "delegou-secao-14-qa",
+          "type": "tool_usage",
+          "description": "A secao 14 (Estrategia de Testes) deve ser delegada a um subagente QA",
+          "check": "A skill disparou um subagente (Task tool) para gerar a secao 14 com contexto de QA expert"
+        }
+      ]
+    },
+    {
+      "id": 3,
+      "name": "respeita-arquitetura-existente",
+      "prompt": "Gere o SPEC_TECH para a feature de usuario. O PRD esta em docs/feature-user/v1/prd.md. Quero que a solucao use a arquitetura ja existente no projeto.",
+      "expected_output": "A skill deve pesquisar profundamente o codebase, identificar a arquitetura existente (gRPC, Clean Architecture, SQLite, Uber FX, SQLC) e propor solucoes que seguem os padroes ja estabelecidos — NAO propor REST quando o projeto usa gRPC, NAO propor PostgreSQL quando o projeto usa SQLite, etc.",
+      "files": [
+        "docs/feature-user/v1/prd.md"
+      ],
+      "assertions": [
+        {
+          "name": "identificou-grpc",
+          "type": "output_content",
+          "description": "Deve identificar que o projeto usa gRPC e propor endpoints gRPC (nao REST)",
+          "check": "O SPEC_TECH propoe endpoints/servicos gRPC, NAO endpoints REST (GET/POST/PUT/DELETE)"
+        },
+        {
+          "name": "identificou-sqlite",
+          "type": "output_content",
+          "description": "Deve identificar que o projeto usa SQLite e propor migracoes SQLite",
+          "check": "O SPEC_TECH referencia SQLite como banco de dados, com migracoes no padrao do projeto"
+        },
+        {
+          "name": "identificou-clean-architecture",
+          "type": "output_content",
+          "description": "Deve seguir a Clean Architecture do projeto (handler -> service -> repository)",
+          "check": "O SPEC_TECH propoe componentes nas camadas handler, service e repository conforme a arquitetura existente"
+        },
+        {
+          "name": "identificou-uber-fx",
+          "type": "output_content",
+          "description": "Deve mencionar Uber FX para injecao de dependencias",
+          "check": "O SPEC_TECH referencia Uber FX ou modulos fx.Module para DI dos novos componentes"
+        },
+        {
+          "name": "convencao-idioma-banco-portugues",
+          "type": "output_content",
+          "description": "Deve seguir a convencao do projeto: tabelas/colunas em portugues, codigo em ingles",
+          "check": "Tabelas e colunas propostas estao em portugues (ex: usuarios, nome, email, senha_hash) e nomes de structs/funcoes em ingles"
+        }
+      ]
+    },
+    {
+      "id": 4,
+      "name": "com-tech-direction-existente",
+      "prompt": "Preciso do SPEC_TECH para a feature de pedidos (orders). O PRD esta em docs/feature-order/v1/prd.md. Ja criei um tech_direction.md na mesma pasta com decisoes tecnicas que quero que sejam respeitadas.",
+      "expected_output": "A skill deve detectar o tech_direction.md, apresentar os direcionamentos encontrados, respeitar as decisoes do usuario como ponto de partida, e levantar conflitos se houver incompatibilidade com o codebase existente",
+      "files": [
+        "docs/feature-order/v1/prd.md",
+        "docs/feature-order/v1/tech_direction.md"
+      ],
+      "assertions": [
+        {
+          "name": "detectou-tech-direction",
+          "type": "tool_usage",
+          "description": "Deve buscar e ler o tech_direction.md na pasta da feature",
+          "check": "A skill leu o arquivo docs/feature-order/v1/tech_direction.md"
+        },
+        {
+          "name": "apresentou-direcionamentos",
+          "type": "output_content",
+          "description": "Deve apresentar um resumo dos direcionamentos encontrados no tech_direction",
+          "check": "A skill lista ou resume as decisoes tecnicas encontradas no tech_direction.md antes de iniciar perguntas"
+        },
+        {
+          "name": "respeitou-decisoes-usuario",
+          "type": "output_content",
+          "description": "Deve usar as decisoes do tech_direction como ponto de partida, nao propor alternativas conflitantes",
+          "check": "As propostas tecnicas da skill sao consistentes com o tech_direction — nao propoe alternativas que contradizem decisoes firmes do usuario"
+        },
+        {
+          "name": "registrou-no-resumo-tecnico",
+          "type": "output_content",
+          "description": "Deve incluir as decisoes do tech_direction na secao 2 do SPEC_TECH",
+          "check": "A secao 2 (Resumo Tecnico) do SPEC_TECH referencia ou incorpora decisoes do tech_direction.md"
+        }
+      ]
+    },
+    {
+      "id": 5,
+      "name": "nao-inventa-nao-deduz",
+      "prompt": "Gere o SPEC_TECH para a feature de usuario. PRD em docs/feature-user/v1/prd.md. Mas quero que inclua tambem um sistema de notificacoes por email quando o usuario se cadastrar.",
+      "expected_output": "A skill deve identificar que 'notificacoes por email' NAO esta no PRD aprovado e NAO deve adicionar ao escopo. Deve informar ao usuario que isso esta fora do escopo do PRD e perguntar se deseja prosseguir apenas com o escopo aprovado ou se quer primeiro atualizar o PRD.",
+      "files": [
+        "docs/feature-user/v1/prd.md"
+      ],
+      "assertions": [
+        {
+          "name": "identificou-escopo-fora-prd",
+          "type": "output_content",
+          "description": "Deve identificar que notificacoes por email nao esta no PRD aprovado",
+          "check": "A skill menciona que notificacoes por email nao faz parte do PRD aprovado ou esta fora do escopo definido"
+        },
+        {
+          "name": "nao-adicionou-ao-spec",
+          "type": "output_content",
+          "description": "NAO deve adicionar funcionalidade fora do PRD ao SPEC_TECH sem aprovacao",
+          "check": "A skill NAO inclui notificacoes por email no SPEC_TECH gerado, ou pergunta ao usuario antes de incluir"
+        },
+        {
+          "name": "sugeriu-atualizar-prd",
+          "type": "output_content",
+          "description": "Deve sugerir que o usuario atualize o PRD se quiser incluir a funcionalidade",
+          "check": "A skill sugere atualizar o PRD primeiro ou pergunta ao usuario como deseja proceder com o item fora do escopo"
+        }
+      ]
+    }
+  ]
+}

package/frameworks/skills/sdd-tech-spec-expert/templates/spec_tech_template.md

@@ -0,0 +1,290 @@
+# SPEC_TECH -- Especificação Técnica
+
+## 1. Identificação
+- **Feature/Projeto**:
+- **Autor**:
+- **Data**:
+- **Versão**:
+- **Status**: Draft | Refinando | Aprovado
+- **PRD Relacionado**:
+
+---
+
+## 2. Resumo Técnico da Solução
+
+(Visão geral do COMO será implementado. Descreva em 3-5 linhas a abordagem técnica escolhida, as principais decisões arquiteturais e o resultado técnico esperado.)
+
+---
+
+## 3. Arquitetura da Solução
+
+### 3.1 Visão Geral
+(Diagrama ou descrição da arquitetura geral da solução. Como os componentes se conectam.)
+
+### 3.2 Componentes/Módulos
+(Lista de componentes envolvidos com descrição da responsabilidade de cada um.)
+
+| Componente | Responsabilidade | Camada |
+|------------|-----------------|--------|
+|            |                 |        |
+
+### 3.3 Interações entre componentes
+(Descreva como os componentes se comunicam. Fluxo de dados entre camadas.)
+
+---
+
+## 4. Estruturas de Dados
+
+### 4.1 Models / DTOs
+(Structs, tipos e modelos de domínio que serão criados ou modificados.)
+
+### 4.2 Entidades de Banco de Dados
+(Tabelas, colunas, índices, constraints. Inclua SQL de migrações quando aplicável.)
+
+### 4.3 Schemas adicionais
+(Protocol Buffers, mensagens gRPC, schemas de validação ou outros formatos de dados.)
+
+---
+
+## 5. Regras Técnicas de Negócio
+
+(Implementação técnica das regras definidas no PRD. Cada regra do PRD deve ter uma definição técnica correspondente.)
+
+### 5.1 Mapeamento de User Stories para Definições Técnicas
+
+| User Story (PRD) | Definição Técnica | Componentes Envolvidos |
+|------------------|-------------------|----------------------|
+| US-01            |                   |                      |
+| US-02            |                   |                      |
+
+<!-- LLM-ONLY: Cada user story do PRD deve ter pelo menos uma definicao tecnica correspondente. Isso garante rastreabilidade completa entre o PRD e a especificacao tecnica. -->
+
+---
+
+## 6. Fluxos Técnicos
+
+### 6.1 Fluxo Principal (técnico)
+(Sequência de chamadas, processamento e respostas do fluxo principal. Descreva camada por camada.)
+
+### 6.2 Fluxos Alternativos
+(Variações do fluxo principal: dados opcionais, caminhos condicionais, etc.)
+
+### 6.3 Tratamento de Erros
+(Como erros serão tratados em cada camada. Mapeamento de erros de negócio para códigos de status.)
+
+| Erro de Negócio | Código de Status | Mensagem | Camada de Origem |
+|----------------|-----------------|----------|-----------------|
+|                |                 |          |                 |
+
+---
+
+## 7. APIs / Endpoints
+
+### 7.1 Endpoints Backend
+
+| Ação | Método | Rota | Payload | Resposta Esperada |
+|------|--------|------|---------|-------------------|
+|      |        |      |         |                   |
+
+### 7.2 Erros e Códigos de Status
+
+| Código | Situação | Mensagem |
+|--------|----------|----------|
+|        |          |          |
+
+---
+
+## 8. Frontend / Mobile
+
+### 8.1 Telas
+(Telas envolvidas, layouts e componentes visuais.)
+
+### 8.2 Estados e Gerência de Estado
+(Gerenciamento de estado: loading, success, error, empty. Solução de state management.)
+
+### 8.3 Navegação
+(Fluxo de navegação entre telas. Rotas e parâmetros.)
+
+### 8.4 Validações
+(Validações de formulário, campos obrigatórios, máscaras, limites.)
+
+### 8.5 Comportamentos específicos
+(Animações, transições, comportamentos offline, responsividade.)
+
+---
+
+## 9. Banco Local / Cache
+
+### 9.1 Estrutura de Tabelas
+(Tabelas locais, colunas, tipos. Diferentes do banco remoto se aplicável.)
+
+### 9.2 Estratégia de Sincronização
+(Como dados locais sincronizam com o backend. Conflitos, prioridade, frequência.)
+
+### 9.3 Estratégia de Versionamento
+(Como lidar com mudanças de schema local. Migrações locais, rollback.)
+
+---
+
+## 10. Dependências Técnicas
+
+| Tipo | Nome | Versão | Motivo |
+|------|------|--------|--------|
+| Pacote |    |        |        |
+| Biblioteca | | |    |
+| Ferramenta | | |    |
+| SDK |        |        |        |
+
+---
+
+## 11. Requisitos Não Funcionais (COMO serão atendidos)
+
+### Segurança
+(Autenticação, autorização, criptografia, validação de input, sanitização.)
+
+### Performance
+(Metas de tempo de resposta, paginação, índices, cache, otimizações.)
+
+### Escalabilidade
+(Limites conhecidos, estratégia de crescimento, gargalos potenciais.)
+
+### Observabilidade
+(Logs estruturados, métricas, alertas, tracing distribuído.)
+
+### Resiliência
+(Tratamento de falhas, retry, circuit breaker, graceful degradation.)
+
+---
+
+## 12. Critérios Técnicos de Aceite
+
+- [ ] Implementação cobre todas as regras do PRD
+- [ ] Estruturas de dados criadas e funcionais
+- [ ] Fluxos técnicos implementados e testados
+- [ ] API funcionando conforme especificado
+- [ ] Erros tratados em todas as camadas
+- [ ] Logs/monitoramento implementados
+- [ ] Validações aplicadas (input, negócio, dados)
+- [ ] Código segue padrões e convenções do projeto
+
+---
+
+## 13. Riscos Técnicos
+
+| Risco | Probabilidade | Impacto | Mitigação |
+|-------|--------------|---------|-----------|
+|       |              |         |           |
+
+---
+
+## 14. Estratégia de Testes
+
+> **Resumo**: X casos de teste | Unitários: Y | Integração: Z | E2E: W
+> **Padrão**: [framework de teste, padrão de mock, convenção de nomes]
+
+### Rastreabilidade: Critérios de Aceite → Testes
+
+| CA (PRD) | Descrição Resumida | Testes |
+|----------|-------------------|--------|
+| CA-01    | (descrição curta do CA no PRD) | CT-01, CT-10, CT-20, CT-30 |
+| CA-02    | (descrição curta do CA no PRD) | CT-02, CT-22 |
+
+<!-- LLM-ONLY: Cada CA-XX do PRD deve ter pelo menos um teste correspondente. Esta tabela deve ser preenchida PRIMEIRO — guia toda a estrategia. -->
+
+---
+
+### 14.1 Testes Unitários
+
+<!-- LLM-ONLY: Coluna "Objetivo": Descreva em 1 frase O QUE o teste valida e POR QUE importa. Use o padrao: Verbo + comportamento especifico + condicao. Exemplo: "Verificar que apenas categorias com ativo=1 sao retornadas, ordenadas pelo campo 'ordem'". NAO repita o nome do teste — o objetivo deve dar contexto que o nome sozinho nao da. -->
+
+#### Service: [NomeService] (`arquivo_test.go`)
+
+Mock: [interfaces mockadas]
+
+| CT | Teste | CA | Objetivo | Input | Expected | Mock |
+|----|-------|----|----------|-------|----------|------|
+| CT-01 | TestMetodo_Sucesso | CA-01 | Verificar que [comportamento esperado] quando [condição do cenário] | dados válidos | resultado esperado | repo retorna dados |
+| CT-02 | TestMetodo_ErroValidacao | CA-03 | Verificar que [erro específico] é retornado quando [condição inválida] | dados inválidos | ErrEspecifico | — |
+
+#### Apresentação: [NomeHandler] (`arquivo_test.go`)
+
+Mock: [interfaces mockadas]
+
+| CT | Teste | CA | Objetivo | Input | Expected | Mock |
+|----|-------|----|----------|-------|----------|------|
+| CT-10 | TestHandler_Sucesso | CA-01 | Verificar que handler converte [modelo domínio] para [formato response] corretamente | request válido | response proto | service retorna sucesso |
+
+### 14.2 Testes de Integração
+
+#### [CamadaA + CamadaB] (`arquivo_test.go`)
+
+Setup: [banco in-memory, migrações, fixtures]
+
+| CT | Teste | CA | Objetivo | Fluxo | Validação |
+|----|-------|----|----------|-------|-----------|
+| CT-20 | TestIntegracao_CRUD | CA-01 | Verificar que dados persistidos são recuperados integralmente via [camada] | Create → Get | dados consistentes |
+| CT-22 | TestIntegracao_Unique | CA-02 | Verificar que constraint unique impede duplicação de [campo] | Insert duplicado | erro constraint |
+
+### 14.3 Testes End-to-End (E2E)
+
+#### Fluxo: [Nome do Fluxo Crítico] (CT-30)
+- **CA**: CA-01, CA-03, CA-06
+- **Objetivo**: (1 frase descrevendo o que este fluxo E2E valida de ponta a ponta)
+- **Pré-condições**: (estado inicial do sistema)
+- **Passos**:
+  1. Cliente envia request X
+  2. Sistema processa e retorna Y
+  3. Verificar estado do banco
+- **Validações**: (assertions sobre dados e estado final)
+
+### 14.4 Cenários de Erro
+
+| Cenário | CA | Objetivo | Trigger | Código/Status | Log Esperado |
+|---------|----|----------|---------|---------------|-------------|
+| Dados duplicados | CA-02 | Verificar que [constraint] impede [operação] e retorna erro adequado | Insert duplicado | [erro conflito] | "registro já existe..." |
+| Recurso inexistente | CA-05 | Verificar que acesso a [recurso] inexistente retorna [código] sem expor dados internos | ID não encontrado | [erro not found] | "não encontrado..." |
+
+---
+
+## 15. Arquivos Envolvidos e Ações
+
+### 15.1 Arquivos a Criar
+
+| Arquivo | Descrição | Camada |
+|---------|-----------|--------|
+|         |           |        |
+
+### 15.2 Arquivos a Modificar
+
+| Arquivo | Modificação | Motivo |
+|---------|------------|--------|
+|         |            |        |
+
+### 15.3 Arquivos de Referência (somente leitura)
+
+| Arquivo | Motivo da Consulta |
+|---------|-------------------|
+|         |                   |
+
+<!-- LLM-ONLY: Esta secao economiza tokens e scans durante a implementacao, pois lista exatamente quais arquivos serao impactados. -->
+
+---
+
+## 16. Checklist Final
+
+- [ ] SPEC_TECH cobre todo o PRD
+- [ ] Resumo técnico claro e objetivo (seção 2)
+- [ ] Arquitetura definida com componentes e interações (seção 3)
+- [ ] Estruturas de dados definidas (seção 4)
+- [ ] User Stories mapeadas para definições técnicas (seção 5.1)
+- [ ] Fluxos técnicos descritos com tratamento de erros (seção 6)
+- [ ] Endpoints mapeados com payloads e respostas (seção 7)
+- [ ] Telas e fluxos de frontend/mobile definidos (seção 8)
+- [ ] Banco local/cache especificado se aplicável (seção 9)
+- [ ] Dependências técnicas listadas (seção 10)
+- [ ] Requisitos não funcionais endereçados (seção 11)
+- [ ] Critérios técnicos de aceite definidos (seção 12)
+- [ ] Riscos técnicos identificados com mitigações (seção 13)
+- [ ] Estratégia de testes definida com rastreabilidade CA→testes no topo (seção 14)
+- [ ] Arquivos envolvidos listados — criar, modificar, referência (seção 15)
+- [ ] Pronto para geração das TASKS

package/frameworks/skills/sdd-tech-spec-expert/templates/tech_direction-template.md

@@ -0,0 +1,23 @@
+# TECH DIRECTION (Opcional)
+
+> Direcionamento técnico inicial para a feature. Serve como ponto de partida para o SPEC_TECH, não como decisão final.
+> O Arquiteto (tech-spec-expert) pode complementar, ajustar ou questionar qualquer item aqui.
+
+## Decisões técnicas já tomadas
+- (ex: Usar JWT com refresh token para autenticação)
+- (ex: Criar gateway separado para integração externa)
+
+## Tecnologias/Libs sugeridas
+- (ex: biblioteca X para integração com serviço Y)
+- (ex: framework Z para testes)
+
+## Padrões ou abordagens preferidas
+- (ex: Seguir o pattern Gateway já usado no projeto)
+- (ex: Implementar como CQRS)
+
+## Restrições técnicas
+- (ex: Precisa ser stateless para rodar em k8s)
+- (ex: Não temos message broker disponível)
+
+## Observações
+- (qualquer contexto técnico relevante que o arquiteto deve considerar)

package/frameworks/skills/taskcard-expert/SKILL.md

@@ -6,12 +6,8 @@ argument-hint: [pergunta, contexto ou caminho da taskcard]
 
 Voce e um **Especialista no Framework TaskCard** — o sistema de planejamento e execucao de tasks deste projeto.
 
-> **Paths**: Leia `.claude/config/ai-framework-config.yaml` secao `taskcard` antes de salvar artefatos. Os paths abaixo sao exemplos — o path real vem do config.
-
 Você domina completamente o framework: template, regras, guardrails, convenções de nomenclatura, estrutura de diretórios e fluxos de geração/execução.
 
-> **Paths**: Leia `.claude/config/ai-framework-config.yaml` secao `taskcard` antes de salvar artefatos. Os paths abaixo sao exemplos — o path real vem do config.
-
 ---
 
 # Regra de Acentuação

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "adi_dev_workflow",
-  "version": "1.2.0",
+  "version": "1.3.0",
   "description": "Install SDD, miniStack and TaskCard development frameworks for Claude Code and Cursor",
   "type": "module",
   "bin": {