adi_dev_workflow 1.0.0 → 1.1.1

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

@@ -6,7 +6,19 @@ 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.
 
-Voce domina completamente o framework: template, regras, guardrails, convencoes de nomenclatura, estrutura de diretorios e fluxos de geracao/execucao.
+Você domina completamente o framework: template, regras, guardrails, convenções de nomenclatura, estrutura de diretórios e fluxos de geração/execução.
+
+---
+
+# Regra de Acentuação
+
+Todo artefato gerado por esta skill é um documento em português brasileiro. Todo conteúdo textual (títulos, descrições, instruções, regras, mensagens) deve usar acentuação correta do pt-BR:
+
+- Títulos e seções: `Descrição`, `Restrições`, `Instruções`, `Validação`, `Configuração`
+- Corpo do texto: `não`, `é`, `está`, `será`, `também`, `através`, `após`, `até`, `único`
+- Termos técnicos em português: `autenticação`, `paginação`, `migração`, `funcionalidade`
+
+Apenas nomes de código (funções, variáveis, structs, pacotes) permanecem sem acento por serem em inglês.
 
 ---
 
@@ -38,17 +50,17 @@ O template completo esta em: [template.md](templates/template.md)
 
 ---
 
+## Perfil do Projeto (pre-carregado)
+
+O `CLAUDE.md`, `.claude/rules/` e `project-profile.md` ja estao no contexto — NAO releia.
+Use essas informacoes para adaptar a TaskCard ao perfil do projeto.
+Se `project-profile.md` NAO existir, execute `/generate-project-profile` antes de prosseguir.
+
 ## PONTO CRITICO: Analise Obrigatoria do Projeto
 
 **ANTES de planejar ou escrever qualquer TaskCard**, voce DEVE:
 
-1. **Ler as rules do projeto** — entender padroes, convencoes e restricoes vigentes. Procure em todos os locais conhecidos:
-   - `.claude/rules/` (Claude Code)
-   - `.cursor/rules/` (Cursor)
-   - `.github/copilot-instructions.md` (GitHub Copilot)
-   - `.gemini/` (Google Gemini)
-   - `.antigravity/` (Antigravity)
-   - `CLAUDE.md`, `.cursorrules`, ou arquivos equivalentes na raiz
+1. **Consultar regras e perfil do projeto** (ja no contexto) — padroes, convencoes e restricoes vigentes
 2. **Explorar o codebase** — buscar implementacoes existentes, padroes ja estabelecidos e codigo reutilizavel
 3. **Identificar o que ja existe** — funcoes, tipos, classes, interfaces e componentes existentes em cada camada do projeto que podem ser reaproveitados
 4. **Mapear dependencias reais** — verificar o que ja esta implementado e o que realmente precisa ser criado do zero
@@ -60,74 +72,18 @@ O template completo esta em: [template.md](templates/template.md)
 
 ---
 
-## PASSO ZERO: Deteccao de Linguagem e Arquitetura
-
-**ANTES DE QUALQUER COISA**, voce DEVE identificar a stack tecnica do projeto:
-
-### 1. Ler CLAUDE.md e rules do projeto
-- `CLAUDE.md` na raiz do projeto
-- `.claude/rules/` (todas as regras do Claude Code)
-- Qualquer arquivo de regras/convencoes existente
-
-### 2. Detectar linguagem e framework
-A partir do CLAUDE.md, rules e exploracao do projeto, identifique:
-
-| O que detectar | Como descobrir | Exemplo |
-|---------------|----------------|---------|
-| **Linguagem** | `go.mod`, `package.json`, `pubspec.yaml`, `requirements.txt`, `Cargo.toml` | Go, TypeScript, Dart, Python, Rust |
-| **Framework** | Imports, estrutura de pastas, CLAUDE.md | gRPC, Express, FastAPI, Gin, Flutter, React |
-| **Banco de dados** | Migracoes, config, ORM | SQLite, PostgreSQL, MongoDB |
-| **ORM / Query builder** | Imports, arquivos gerados | SQLC, GORM, Prisma, TypeORM, Drift |
-| **Framework de teste** | Arquivos de teste, dependencias | testify, jest, pytest, flutter_test |
-| **Padrao de mock** | Imports, arquivos mock | gomock, mockito, jest.mock, mocktail |
-| **Arquitetura** | Estrutura de pastas, CLAUDE.md | Clean Arch, MVC, Hexagonal, BLoC, Layered |
-
-### 3. Construir o Perfil do Projeto
-
-Com base na deteccao, monte mentalmente (e aplique) o perfil:
-
-```
-Perfil do Projeto:
-- Linguagem: [detectada]
-- Framework: [detectado]
-- Arquitetura: [detectada] (camadas: [lista])
-- Framework de teste: [detectado]
-- Padrao de mock: [detectado]
-- Extensao de teste: [detectada] (ex: _test.go, .test.ts, _test.dart)
-- Padrao de arquivos de teste: [detectado] (ex: mesmo dir, pasta __tests__, pasta test/)
-```
-
-> **Toda a TaskCard DEVE ser adaptada ao perfil detectado.**
-> NAO assuma Go, gRPC, testify ou qualquer stack especifica sem antes confirmar.
-
----
-
-## PONTO CRITICO: Analise Obrigatoria de Testes
-
-> **Nota**: Para uma analise aprofundada de testes com rigor de QA Senior, use o **taskcard-qa-expert** via `/taskcard:generate-tests`. Ele gera a secao 10 completa (10.1 a 10.6) com rastreabilidade, cenarios de erro detalhados e mapeamento por camada.
-
-**ANTES de preencher a secao 10 (Testes) de qualquer TaskCard**, voce DEVE:
+## Seção 10 (Testes): Delegação ao qa-staff-engineer
 
-1. **Buscar testes existentes** — encontrar todos os arquivos de teste no projeto usando o padrao detectado no Passo Zero (ex: `*_test.go`, `*.test.ts`, `*_test.dart`, `test_*.py`, etc.) relacionados as camadas impactadas pela task
-2. **Ler os testes encontrados** — entender quais cenarios ja estao cobertos, quais mocks existem, e como os testes estao estruturados
-3. **Identificar testes a modificar** — se a task altera interfaces, assinaturas de funcoes, modelos de dominio ou comportamento de negocio, os testes existentes dessas camadas precisam ser atualizados
-4. **Identificar testes a criar** — se a task cria novos endpoints, services, repositories, componentes ou funcoes de negocio, testes correspondentes DEVEM ser criados
-5. **Mapear padroes de teste do projeto** — identificar framework de teste, convencao de nomes, padroes de mock, fixtures e helpers reutilizaveis a partir do Passo Zero
+A seção 10 (Testes) NÃO é preenchida diretamente pelo gerador da TaskCard. O fluxo é:
 
-### Regras para a secao 10
+1. O orquestrador (`generate-taskcard`) dispara o agente `qa-staff-engineer` (modo GERAR_TESTES)
+2. O agente retorna um **JSON estruturado** com casos de teste, rastreabilidade e padrões detectados
+3. O orquestrador **transforma o JSON** no formato do template oficial (subseções 10.1 a 10.6) e edita o arquivo
 
-| Situacao | Acao obrigatoria |
-|----------|-----------------|
-| Task cria componente de **apresentacao** (handler, controller, widget, page) | Criar testes de validacao de entrada, mapeamento de dados e codigos de resposta. Mock da camada de negocio |
-| Task cria componente de **negocio** (service, use case, cubit, bloc) | Criar testes unitarios com mocks da camada de dados, cobrindo regras de negocio e erros de dominio |
-| Task cria componente de **dados** (repository, DAO, data source) | Criar testes de integracao cobrindo CRUD, queries e casos de borda |
-| Task modifica **interface/contrato** existente | Atualizar mocks e testes de todas as camadas que dependem do contrato |
-| Task adiciona **campo em modelo/entidade** | Atualizar fixtures, factory functions e assertions nos testes existentes |
-| Task altera **regra de negocio** | Atualizar cenarios de teste na camada de negocio e adicionar novos cenarios |
-| Task cria **migracao/schema** de banco | Testar migracao up e down, verificar schema resultante |
+O agente QA é compartilhado entre processos (SDD, miniStack, TaskCard) e sempre retorna JSON — a adaptação ao formato do template é responsabilidade do orquestrador.
 
-> **Nunca gere uma TaskCard sem a secao 10 preenchida.**
-> Se nao ha testes a modificar nem a criar (raro), justifique explicitamente em 10.1/10.2.
+> **Nunca gere uma TaskCard sem disparar o qa-staff-engineer para a seção 10.**
+> Salve o arquivo com seções 1-9 e 11 primeiro, depois dispare o agente e formate o resultado.
 
 ---
 
@@ -139,7 +95,7 @@ Perfil do Projeto:
 2. **Sem vagueza** — proibido termos como "ajustar conforme necessario", "melhorar se possivel"
 3. **Sem invencao** — se faltar informacao, pergunte ao usuario
 4. **Escopo fechado** — toda TaskCard deve ser executavel sem novas decisoes
-5. **Template completo** — todas as 11 secoes devem ser preenchidas
+5. **Template completo** — secoes 1-9 e 11 preenchidas pelo gerador; secao 10 (Testes) delegada ao agente `qa-staff-engineer`
 6. **Processo interativo** — faca uma pergunta por vez para preencher lacunas
 7. **Gerar sem pedir aprovacao** — NUNCA peca aprovacao para gerar os arquivos. Gere os arquivos da TaskCard imediatamente e apresente apenas um resumo curto do que foi criado (IDs, nomes, arquivos gerados)
 
@@ -234,12 +190,14 @@ docs/
 ```
 Contexto do usuario
   -> Identificar lacunas (perguntar 1 a 1)
-  -> Analisar testes existentes no projeto (buscar arquivos de teste usando o padrao detectado no Passo Zero nas camadas impactadas)
-  -> Preencher template (todas as 11 secoes, incluindo secao 10 de Testes)
+  -> Preencher template (secoes 1-9 e 11)
+  -> Remover todos os comentarios <!-- LLM-ONLY: ... --> do conteudo antes de salvar
   -> Salvar em docs/<feature>/vN/ (GERAR ARQUIVOS IMEDIATAMENTE, SEM PEDIR APROVACAO)
+  -> Disparar qa-staff-engineer (modo GERAR_TESTES) → recebe JSON
+  -> Transformar JSON no formato do template (subseções 10.1 a 10.6)
+  -> Editar arquivo da TaskCard com a seção 10 formatada
   -> Se multiplas: gerar task-plan.md
   -> Apresentar resumo curto do que foi criado (arquivos gerados, IDs, nomes)
-  -> (Opcional) Usar /taskcard:generate-tests para enriquecer a secao 10 com rigor de QA Senior
 ```
 
 ### Executar TaskCard
@@ -252,7 +210,12 @@ Ler TaskCard completa
   -> Validar guardrails (secao 6) a cada passo
   -> Rodar testes (make test) e garantir que passam
   -> Validar aceite tecnico (secao 9)
-  -> Produzir relatorio final
+  -> Gate 1: qa-staff-engineer (VALIDAR_IMPLEMENTACAO)
+     APROVADO → Gate 2 | REJEITADO → loop correcao
+  -> Gate 2: tech-review-conformance
+     approved → concluido | rejected → loop → volta Gate 1
+  -> Loop correcao (max 3 tentativas → Blocked + escalar)
+  -> Produzir relatorio final com vereditos QA + Tech Review
 ```
 
 ### Relatorio de Execucao (formato padrao)

package/frameworks/skills/taskcard-expert/templates/template.md

@@ -126,8 +126,6 @@ Mapeamento entre criterios de aceite (secao 9) e testes que os validam:
 |---|------------------------------|---------------------------|------|
 | 1 | [criterio] | [TestNome] | [Unitario/Integracao/E2E] |
 
-> Para analise aprofundada com rigor de QA Senior, use `/taskcard:generate-tests`.
-
 ---
 
 ## 11. Notas / Observacoes

package/frameworks/templates/prompt_template.md

@@ -152,10 +152,53 @@ Saída esperada: [Descreva a saída]
 
 ---
 
+## 9. 📂 Arquivos Envolvidos *(opcional)*
+
+[Liste os arquivos que devem ser criados, modificados ou consultados durante a tarefa]
+
+**Arquivos a criar:**
+- [Ex: `internal/service/order_service.go` — lógica de negócio de pedidos]
+- [Ex: `internal/handler/grpc/order_handler.go` — handler gRPC de pedidos]
+
+**Arquivos a modificar:**
+- [Ex: `internal/infra/di/fx.go` — registrar novos módulos no DI]
+- [Ex: `api/proto/v1/order.proto` — definir mensagens e RPCs de pedidos]
+
+**Arquivos de referência (consultar, não alterar):**
+- [Ex: `internal/service/user_service.go` — seguir mesmo padrão de implementação]
+- [Ex: `internal/handler/grpc/user_handler.go` — referência de como mapear DTOs]
+
+---
+
+## 10. 🧪 Testes de Unidade *(opcional)*
+
+[Defina expectativas sobre testes que devem acompanhar a implementação]
+
+**Escopo dos testes:**
+- [Ex: Testar apenas a camada de service]
+- [Ex: Cobrir fluxos de sucesso e erro]
+- [Ex: Incluir testes de integração com banco real]
+
+**Cenários obrigatórios:**
+- [Ex: Criação com dados válidos → sucesso]
+- [Ex: Criação com email duplicado → erro de conflito]
+- [Ex: Busca por ID inexistente → erro not found]
+- [Ex: Atualização sem permissão → erro de autorização]
+
+**Padrão de testes:**
+- [Ex: Table-driven tests com `testify`]
+- [Ex: Mocks para dependências externas]
+- [Ex: Nomenclatura: `TestNomeDoService_MetodoTestado_Cenario`]
+
+**Arquivo de referência:**
+- [Ex: `internal/service/user_service_test.go` — seguir mesmo padrão]
+
+---
+
 ## 💡 Dicas de Uso
 
 * ✅ **Mínimo obrigatório:** Seções 1–6 (Contexto + Objetivo + Instruções + DEVE/NÃO DEVE + Formato + Persona)
-* ⭐ **Para 6 estrelas:** Adicione seções 7–8 (Critérios de Aceite + Exemplos)
+* ⭐ **Para 6 estrelas:** Adicione seções 7–10 (Critérios de Aceite + Exemplos + Arquivos + Testes)
 * 🎯 **Seja específico:** Quanto mais detalhes relevantes, melhor a resposta
 * 🎭 **Use DEVE/NÃO DEVE:** Esta seção é crucial para evitar comportamentos indesejados
 * 🔄 **Itere:** Ajuste o prompt baseado nos resultados obtidos

package/package.json

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

package/frameworks/commands/ministack/generate-tests.md

@@ -1,37 +0,0 @@
----
-description: Gera estrategia de testes completa com vies de QA Senior para uma feature ou task do miniStack
-argument-hint: [caminho do SCOPE ou descricao da task]
----
-
-Use a skill **ministack-qa-expert** para gerar a estrategia de testes.
-
-## Contexto
-
-Voce deve atuar como um **QA Engineer Senior / SDET** e seguir todo o processo definido na skill ministack-qa-expert para gerar testes com qualidade profissional.
-
-## Modos de Uso
-
-### Modo 1: Estrategia completa para uma feature
-```
-/ministack:generate-tests docs/nome-feature/v1/scope.md
-```
-Gera a estrategia de testes completa (unitarios, integracao, e2e, cenarios de erro) baseada no SCOPE aprovado.
-
-### Modo 2: Testes para uma task especifica
-```
-/ministack:generate-tests docs/nome-feature/v1/tasks.md T1
-```
-Gera a secao de testes completa para uma task especifica (unitarios, integracao, e2e, cenarios de erro).
-
-## Regras Adicionais
-
-- **Claude Code**: use a ferramenta `AskUserQuestion` para esclarecer duvidas com o usuario
-- **NUNCA** gere testes genericos — cada teste deve ter cenario especifico e verificavel
-- **SEMPRE** pesquise padroes de teste existentes no projeto antes de gerar
-- **SEMPRE** mapeie criterios de aceite do SCOPE para testes
-- **SEMPRE** considere cenarios de erro, boundary values e edge cases
-- Todo fluxo de sucesso deve ter **pelo menos 2 cenarios de falha** correspondentes
-
-## Entrada
-
-$ARGUMENTS

package/frameworks/commands/sdd/generate-spec-tech.md

@@ -1,37 +0,0 @@
----
-description: Gera um SPEC_TECH completo a partir de um PRD aprovado
-argument-hint: [caminho do PRD]
----
-
-Use a skill **sdd-spec-tech-expert** para gerar o SPEC_TECH.
-
-## Contexto
-
-Voce deve atuar como um **Arquiteto de Software Senior** e seguir todo o processo interativo definido na skill sdd-spec-tech-expert para transformar o PRD aprovado em uma especificacao tecnica completa.
-
-O $ARGUMENTS deve conter:
-1. **PRD aprovado** ou caminho para o arquivo (obrigatorio)
-
-## Tech Direction (Opcional)
-
-Antes de iniciar, verifique se existe um arquivo `tech_direction.md` na pasta da feature (`docs/[nome-feature]/tech_direction.md`).
-
-- Se existir, use como **ponto de partida** para decisoes tecnicas — nao como verdade absoluta
-- O arquivo contem decisoes ja tomadas, tecnologias sugeridas, padroes preferidos e restricoes tecnicas
-- Voce pode complementar, ajustar ou questionar qualquer item
-- Se NAO existir, siga o fluxo normal
-
-## Regras Adicionais
-
-- **Claude Code**: use a ferramenta `AskUserQuestion` para esclarecer duvidas com o usuario
-- **NUNCA** deduza escopo ou invente informacoes — na **DUVIDA PERGUNTE AO USUARIO**
-- Foque exclusivamente no **COMO** sera implementado, nunca repita o **O QUE** do PRD
-- **ANTES de definir o SPEC_TECH**, pesquise as rules do projeto (`.claude/rules/`, `CLAUDE.md`) e as camadas existentes para propor a melhor solucao
-- Se houver **tech_direction.md**, considere-o como ponto de partida para decisoes arquiteturais — nao ignore, mas valide contra o codebase existente e levante conflitos se houver
-- Liste **TODOS** os arquivos envolvidos e as acoes (criar/modificar/referencia) — economiza tokens e scans
-- Mapeie cada **User Story do PRD** para definicoes tecnicas correspondentes
-- A estrategia de **testes** (secao 14) deve ser delegada a um **subagente QA especializado** em contexto isolado, conforme definido na skill
-
-## Entrada
-
-$ARGUMENTS

package/frameworks/commands/taskcard/generate-tests.md

@@ -1,37 +0,0 @@
----
-description: Gera/enriquece a secao 10 (Testes) de uma TaskCard com rigor de QA Senior / SDET
-argument-hint: [caminho da TaskCard individual — ex: docs/feature/v1/task-01-slug.md]
----
-
-Use a skill **taskcard-qa-expert** para gerar/enriquecer a secao 10 (Testes) da TaskCard.
-
-## Contexto
-
-Voce deve atuar como um **QA Engineer Senior / SDET** e seguir todo o processo definido na skill taskcard-qa-expert para gerar testes com qualidade profissional.
-
-## Modo de Uso
-
-```
-/taskcard:generate-tests docs/nome-feature/v1/task-01-slug.md
-```
-
-Gera a secao 10 completa da TaskCard (10.1 a 10.6):
-- 10.1 Testes Existentes a Modificar
-- 10.2 Testes a Criar (unitarios, integracao, e2e)
-- 10.3 Cenarios Obrigatorios
-- 10.4 Padroes de Teste
-- 10.5 Cenarios de Erro
-- 10.6 Rastreabilidade: Aceite Tecnico -> Testes
-
-## Regras Adicionais
-
-- **Claude Code**: use a ferramenta `AskUserQuestion` para esclarecer duvidas com o usuario
-- **NUNCA** gere testes genericos — cada teste deve ter cenario especifico e verificavel
-- **SEMPRE** pesquise padroes de teste existentes no projeto antes de gerar
-- **SEMPRE** mapeie criterios de Aceite Tecnico (secao 9) para testes (secao 10.6)
-- **SEMPRE** considere cenarios de erro, boundary values e edge cases
-- Todo fluxo de sucesso deve ter **pelo menos 2 cenarios de falha** correspondentes
-
-## Entrada
-
-$ARGUMENTS