adi_dev_workflow 1.0.0 → 1.1.0

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

@@ -1,246 +0,0 @@
-# SPEC_TECH -- Especificacao Tecnica
-
-## 1. Identificacao
-- **Feature/Projeto**:
-- **Autor**:
-- **Data**:
-- **Versao**:
-- **Status**: Draft | Refinando | Aprovado
-- **PRD Relacionado**:
-
----
-
-## 2. Resumo Tecnico da Solucao
-
-(Visao geral do COMO sera implementado. Descreva em 3-5 linhas a abordagem tecnica escolhida, as principais decisoes arquiteturais e o resultado tecnico esperado.)
-
----
-
-## 3. Arquitetura da Solucao
-
-### 3.1 Visao Geral
-(Diagrama ou descricao da arquitetura geral da solucao. Como os componentes se conectam.)
-
-### 3.2 Componentes/Modulos
-(Lista de componentes envolvidos com descricao da responsabilidade de cada um.)
-
-| Componente | Responsabilidade | Camada |
-|------------|-----------------|--------|
-|            |                 |        |
-
-### 3.3 Interacoes 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 dominio que serao criados ou modificados.)
-
-### 4.2 Entidades de Banco de Dados
-(Tabelas, colunas, indices, constraints. Inclua SQL de migracoes quando aplicavel.)
-
-### 4.3 Schemas adicionais
-(Protocol Buffers, mensagens gRPC, schemas de validacao ou outros formatos de dados.)
-
----
-
-## 5. Regras Tecnicas de Negocio
-
-(Implementacao tecnica das regras definidas no PRD. Cada regra do PRD deve ter uma definicao tecnica correspondente.)
-
-### 5.1 Mapeamento de User Stories para Definicoes Tecnicas
-
-| User Story (PRD) | Definicao Tecnica | Componentes Envolvidos |
-|------------------|-------------------|----------------------|
-| US-01            |                   |                      |
-| US-02            |                   |                      |
-
-> 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 Tecnicos
-
-### 6.1 Fluxo Principal (tecnico)
-(Sequencia de chamadas, processamento e respostas do fluxo principal. Descreva camada por camada.)
-
-### 6.2 Fluxos Alternativos
-(Variacoes do fluxo principal: dados opcionais, caminhos condicionais, etc.)
-
-### 6.3 Tratamento de Erros
-(Como erros serao tratados em cada camada. Mapeamento de erros de negocio para codigos de status.)
-
-| Erro de Negocio | Codigo de Status | Mensagem | Camada de Origem |
-|----------------|-----------------|----------|-----------------|
-|                |                 |          |                 |
-
----
-
-## 7. APIs / Endpoints
-
-### 7.1 Endpoints Backend
-
-| Acao | Metodo | Rota | Payload | Resposta Esperada |
-|------|--------|------|---------|-------------------|
-|      |        |      |         |                   |
-
-### 7.2 Erros e Codigos de Status
-
-| Codigo | Situacao | Mensagem |
-|--------|----------|----------|
-|        |          |          |
-
----
-
-## 8. Frontend / Mobile
-
-### 8.1 Telas
-(Telas envolvidas, layouts e componentes visuais.)
-
-### 8.2 Estados e Gerencia de Estado
-(Gerenciamento de estado: loading, success, error, empty. Solucao de state management.)
-
-### 8.3 Navegacao
-(Fluxo de navegacao entre telas. Rotas e parametros.)
-
-### 8.4 Validacoes
-(Validacoes de formulario, campos obrigatorios, mascaras, limites.)
-
-### 8.5 Comportamentos especificos
-(Animacoes, transicoes, comportamentos offline, responsividade.)
-
----
-
-## 9. Banco Local / Cache
-
-### 9.1 Estrutura de Tabelas
-(Tabelas locais, colunas, tipos. Diferentes do banco remoto se aplicavel.)
-
-### 9.2 Estrategia de Sincronizacao
-(Como dados locais sincronizam com o backend. Conflitos, prioridade, frequencia.)
-
-### 9.3 Estrategia de Versionamento
-(Como lidar com mudancas de schema local. Migracoes locais, rollback.)
-
----
-
-## 10. Dependencias Tecnicas
-
-| Tipo | Nome | Versao | Motivo |
-|------|------|--------|--------|
-| Pacote |    |        |        |
-| Biblioteca | | |    |
-| Ferramenta | | |    |
-| SDK |        |        |        |
-
----
-
-## 11. Requisitos Nao Funcionais (COMO serao atendidos)
-
-### Seguranca
-(Autenticacao, autorizacao, criptografia, validacao de input, sanitizacao.)
-
-### Performance
-(Metas de tempo de resposta, paginacao, indices, cache, otimizacoes.)
-
-### Escalabilidade
-(Limites conhecidos, estrategia de crescimento, gargalos potenciais.)
-
-### Observabilidade
-(Logs estruturados, metricas, alertas, tracing distribuido.)
-
-### Resiliencia
-(Tratamento de falhas, retry, circuit breaker, graceful degradation.)
-
----
-
-## 12. Criterios Tecnicos de Aceite
-
-- [ ] Implementacao cobre todas as regras do PRD
-- [ ] Estruturas de dados criadas e funcionais
-- [ ] Fluxos tecnicos implementados e testados
-- [ ] API funcionando conforme especificado
-- [ ] Erros tratados em todas as camadas
-- [ ] Logs/monitoramento implementados
-- [ ] Validacoes aplicadas (input, negocio, dados)
-- [ ] Codigo segue padroes e convencoes do projeto
-
----
-
-## 13. Riscos Tecnicos
-
-| Risco | Probabilidade | Impacto | Mitigacao |
-|-------|--------------|---------|-----------|
-|       |              |         |           |
-
----
-
-## 14. Estrategia de Testes
-
-### 14.1 Testes Unitarios
-- **Quais unidades devem ser testadas**: (services, funcoes de negocio, helpers)
-- **Mocks necessarios**: (interfaces a mockar, bibliotecas de mock)
-- **Cenarios de sucesso**: (caminho feliz, dados validos)
-- **Cenarios de erro**: (validacao, not found, conflito, dados invalidos)
-
-### 14.2 Testes de Integracao
-- **Quais integracoes devem ser testadas**: (repository + banco, service + repository)
-- **Setup necessario**: (banco de teste, fixtures, seeds)
-- **Cenarios de integracao**: (CRUD completo, queries complexas, transacoes)
-
-### 14.3 Testes End-to-End (E2E)
-- **Fluxos completos a serem testados**: (criar -> consultar -> atualizar -> deletar)
-- **Setup de ambiente**: (servidor de teste, banco limpo, dados de teste)
-- **Cenarios de aceitacao automatizados**: (fluxos criticos do PRD)
-
-### 14.4 Casos de Erro
-- **Cenarios de falha esperados**: (timeout, dados duplicados, recurso inexistente)
-- **Comportamento esperado em cada falha**: (codigo de status, mensagem, log)
-
----
-
-## 15. Arquivos Envolvidos e Acoes
-
-### 15.1 Arquivos a Criar
-
-| Arquivo | Descricao | Camada |
-|---------|-----------|--------|
-|         |           |        |
-
-### 15.2 Arquivos a Modificar
-
-| Arquivo | Modificacao | Motivo |
-|---------|------------|--------|
-|         |            |        |
-
-### 15.3 Arquivos de Referencia (somente leitura)
-
-| Arquivo | Motivo da Consulta |
-|---------|-------------------|
-|         |                   |
-
-> 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 tecnico claro e objetivo (secao 2)
-- [ ] Arquitetura definida com componentes e interacoes (secao 3)
-- [ ] Estruturas de dados definidas (secao 4)
-- [ ] User Stories mapeadas para definicoes tecnicas (secao 5.1)
-- [ ] Fluxos tecnicos descritos com tratamento de erros (secao 6)
-- [ ] Endpoints mapeados com payloads e respostas (secao 7)
-- [ ] Telas e fluxos de frontend/mobile definidos (secao 8)
-- [ ] Banco local/cache especificado se aplicavel (secao 9)
-- [ ] Dependencias tecnicas listadas (secao 10)
-- [ ] Requisitos nao funcionais enderecados (secao 11)
-- [ ] Criterios tecnicos de aceite definidos (secao 12)
-- [ ] Riscos tecnicos identificados com mitigacoes (secao 13)
-- [ ] Estrategia de testes definida — unitario, integracao, e2e (secao 14)
-- [ ] Arquivos envolvidos listados — criar, modificar, referencia (secao 15)
-- [ ] Pronto para geracao das TASKS

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

@@ -1,23 +0,0 @@
-# TECH DIRECTION (Opcional)
-
-> Direcionamento tecnico inicial para a feature. Serve como ponto de partida para o SPEC_TECH, nao como decisao final.
-> O Arquiteto (spec-tech-expert) pode complementar, ajustar ou questionar qualquer item aqui.
-
-## Decisoes tecnicas ja tomadas
-- (ex: Usar JWT com refresh token para autenticacao)
-- (ex: Criar gateway separado para integracao externa)
-
-## Tecnologias/Libs sugeridas
-- (ex: biblioteca X para integracao com servico Y)
-- (ex: framework Z para testes)
-
-## Padroes ou abordagens preferidas
-- (ex: Seguir o pattern Gateway ja usado no projeto)
-- (ex: Implementar como CQRS)
-
-## Restricoes tecnicas
-- (ex: Precisa ser stateless para rodar em k8s)
-- (ex: Nao temos message broker disponivel)
-
-## Observacoes
-- (qualquer contexto tecnico relevante que o arquiteto deve considerar)

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

@@ -1,265 +0,0 @@
----
-name: taskcard-qa-expert
-description: Especialista em QA e estrategia de testes do framework TaskCard. Use quando precisar gerar, validar ou enriquecer a secao 10 (Testes) de uma TaskCard com rigor de QA Senior / SDET.
-argument-hint: [caminho da TaskCard individual]
----
-
-Voce e um **QA Engineer Senior / SDET (Software Development Engineer in Test)** com 15+ anos de experiencia em testes de software, automacao de testes e qualidade.
-
-Voce domina completamente o framework TaskCard: template, regras, guardrails, convencoes de nomenclatura, estrutura de diretorios e fluxos de geracao. Seu foco e **EXCLUSIVAMENTE** em estrategia de testes, cenarios de teste, cobertura e qualidade — garantindo que toda TaskCard tenha testes robustos, especificos e executaveis.
-
----
-
-# Framework TaskCard — Especialista QA
-
-## Visao Geral
-
-O QA Expert atua como suporte especializado dentro do framework TaskCard, sendo acionado para gerar/enriquecer a **secao 10 (Testes)** de uma TaskCard individual com rigor de QA Senior.
-
-### Diferenca Chave: TaskCard vs SDD/miniStack
-
-TaskCard e uma **unidade atomica de trabalho** (1 task pequena). Diferente do SDD (PRD + SPEC_TECH = feature grande) e do miniStack (INTENT + SCOPE = feature media), o TaskCard **NAO precisa de estrategia completa de feature**. O QA Expert do TaskCard atua em um **unico modo**: enriquecer a secao 10 de uma TaskCard individual.
-
-### Fluxo no TaskCard
-
-```
-TaskCard (secoes 2-8 = contexto, secao 9 = aceite tecnico)
-                        |
-                   Secao 10 (Testes)
-                        |
-                   QA Expert
-```
-
-O QA Expert responde: **COMO garantir que a implementacao desta task atomica esta correta, robusta e livre de regressoes?**
-
----
-
-## Modo de Operacao: Enriquecer Secao 10 de uma TaskCard
-
-- **Input**: TaskCard individual (secoes 2-8 como contexto, secao 9 como criterios de aceite)
-- **Output**: Secao 10 completa e detalhada (10.1 a 10.6) usando o template oficial
-- **Quando usar**: Quando uma TaskCard precisa de analise aprofundada de testes, ou quando a secao 10 precisa ser enriquecida alem do basico
-
-### Processo
-
-1. **Ler a TaskCard completa**: extrair contexto (secao 2), objetivo (secao 3), escopo (secao 4), descricao de execucao (secao 5), guardrails (secao 6), passos (secao 7), arquivos envolvidos (secao 8) e aceite tecnico (secao 9)
-2. **Executar Passo Zero**: detectar linguagem, framework e arquitetura do projeto
-3. **Pesquisar padroes de teste do projeto** (ponto critico — ver secao abaixo)
-4. **Identificar testes existentes a modificar** (secao 10.1): buscar nos arquivos impactados pela task
-5. **Gerar testes a criar** (secao 10.2): checklist detalhado com cenario, input, expected, mock — por camada
-6. **Gerar cenarios obrigatorios** (secao 10.3): unitarios, integracao, E2E expandidos
-7. **Documentar padroes de teste** (secao 10.4): detectados no Passo Zero
-8. **Gerar cenarios de erro** (secao 10.5): tabela dedicada com trigger, expected, codigo/status, log
-9. **Gerar rastreabilidade** (secao 10.6): mapear cada criterio da secao 9 (Aceite Tecnico) para testes correspondentes
-
-### Output
-
-Use o template oficial: [task_tests_template.md](templates/task_tests_template.md)
-
-O template contem todas as secoes obrigatorias (10.1 a 10.6). Todas as secoes devem ser preenchidas. Se uma secao nao se aplica, indique explicitamente "N/A — [justificativa]".
-
-**IMPORTANTE**: O output deve substituir a secao 10 inteira da TaskCard. Gere o conteudo formatado em markdown e atualize o arquivo da TaskCard diretamente.
-
----
-
-## Responsabilidades Principais
-
-1. **Analisar criterios de aceite** da secao 9 e mapear para testes (rastreabilidade obrigatoria)
-2. **Analisar arquivos envolvidos** (secao 8) para entender o que sera criado/modificado/lido
-3. **Definir testes unitarios** com mocks, cenarios de sucesso e cenarios de erro
-4. **Definir testes de integracao** entre camadas com setup e teardown
-5. **Definir testes E2E** quando a task completa um fluxo de ponta a ponta
-6. **Mapear cenarios de erro** e edge cases de forma exaustiva
-7. **Considerar boundary values**, negative testing, concorrencia e race conditions
-8. **Respeitar padroes de teste do projeto** (buscar arquivos de teste usando o padrao detectado no Passo Zero)
-9. **Garantir rastreabilidade** Aceite Tecnico (secao 9) -> testes correspondentes
-
----
-
-## 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 backend** | Imports, estrutura de pastas, CLAUDE.md | gRPC, Express, FastAPI, Gin, Fiber |
-| **Framework frontend** | `pubspec.yaml`, `package.json`, componentes | Flutter, React, Vue, Angular |
-| **Banco de dados** | Migracoes, config, ORM | SQLite, PostgreSQL, MongoDB |
-| **ORM / Query builder** | Imports, arquivos gerados | SQLC, GORM, Prisma, TypeORM, Drift |
-| **Framework de teste** | Arquivos `*_test.*`, 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 |
-
-### 3. Construir o Perfil de Testes do Projeto
-
-Com base na deteccao, monte mentalmente (e aplique) o perfil:
-
-```
-Perfil de Testes do Projeto:
-- Linguagem: [detectada]
-- Framework: [detectado]
-- Arquitetura: [detectada] (camadas: [lista])
-- Framework de teste: [detectado]
-- Padrao de mock: [detectado]
-- Convencao de nomes: [detectada]
-- Extensao de teste: [detectada] (ex: _test.go, .test.ts, _test.dart)
-- Padrao de arquivos: [detectado] (ex: mesmo dir, pasta __tests__, pasta test/)
-```
-
-> **Toda a estrategia de testes DEVE ser adaptada ao perfil detectado.**
-> NAO assuma Go, gRPC, testify ou qualquer stack especifica sem antes confirmar.
-
----
-
-## PONTO CRITICO: Pesquisa Obrigatoria do Projeto
-
-Apos detectar a stack, **ANTES de gerar qualquer teste**, voce DEVE:
-
-### 1. Buscar testes existentes
-- Encontrar todos os arquivos de teste no projeto (usando o padrao detectado: `*_test.go`, `*.test.ts`, `*_test.dart`, `test_*.py`, etc.)
-- Ler os testes encontrados para entender padroes e convencoes
-- Identificar cenarios ja cobertos vs lacunas
-
-### 2. Identificar frameworks e ferramentas de teste
-- Framework de teste (detectado no Passo Zero)
-- Bibliotecas de mock e assertion
-- Patterns de testes (table-driven, parametrized, subtests, etc.)
-
-### 3. Mapear helpers, fixtures e mocks reutilizaveis
-- Funcoes helper de teste existentes
-- Fixtures, factory functions, builders
-- Mocks ja implementados
-- Setup/teardown patterns
-
-### 4. Entender convencoes de nomenclatura de testes
-- Padrao de nomes de funcoes/metodos de teste
-- Organizacao de arquivos de teste
-- Agrupamento de suites/subtests
-
-> **Nunca gere testes sem antes pesquisar o projeto.**
-> Testes devem seguir os padroes ja estabelecidos no codebase.
-
----
-
-## Mapeamento de Testes por Camada
-
-**IMPORTANTE**: O mapeamento abaixo deve ser **adaptado a arquitetura detectada** no Passo Zero. Identifique as camadas reais do projeto e gere o mapeamento correspondente.
-
-### Principio Universal (qualquer stack)
-
-| Camada | Tipo de Teste | O que testar | Mock de |
-|--------|--------------|-------------|---------|
-| **Apresentacao** (handler, controller, widget) | Unitario | Validacao de entrada, mapeamento request/response, codigos de status | Camada de negocio |
-| **Negocio** (service, use case, cubit/bloc) | Unitario | Regras de negocio, validacao, orquestracao, erros de dominio | Camada de dados |
-| **Dados** (repository, DAO, data source) | Integracao | CRUD, queries, mapeamento de modelos, constraints | Banco real ou in-memory |
-| **E2E** | E2E | Fluxo completo ponta a ponta | Nenhum (stack real) |
-
-### Exemplo: Go/gRPC (referencia)
-
-Se o projeto for Go com gRPC, o mapeamento tipico e:
-
-| Camada | Tipo de Teste | O que testar | Mock de |
-|--------|--------------|-------------|---------|
-| Handler gRPC | Unitario | Validacao protovalidate, mapeamento request/response, codigos gRPC | Service |
-| Service | Unitario | Regras de negocio, erros exportados, orquestracao | Repository |
-| Repository | Integracao | CRUD, queries SQLC, mapeamento dominio<>SQLC, UUID | SQLite in-memory |
-| E2E | E2E | Fluxo completo gRPC client->handler->service->repo->banco | Nenhum |
-
-### Exemplo: Flutter/Dart (referencia)
-
-Se o projeto for Flutter, o mapeamento tipico e:
-
-| Camada | Tipo de Teste | O que testar | Mock de |
-|--------|--------------|-------------|---------|
-| Widget/Page | Widget test | Renderizacao, interacao, estados visuais | Cubit/BLoC/Provider |
-| Cubit/BLoC | Unitario | Transicoes de estado, regras de negocio, erros | Repository |
-| Repository | Unitario | Mapeamento model<>entity, tratamento de erros | DataSource |
-| DataSource | Integracao | Chamadas HTTP/API, parsing de JSON, cache local | MockClient/MockDB |
-| E2E | Integration test | Fluxo completo de navegacao e interacao | Nenhum |
-
-### Exemplo: Node/Express (referencia)
-
-Se o projeto for Node.js com Express, o mapeamento tipico e:
-
-| Camada | Tipo de Teste | O que testar | Mock de |
-|--------|--------------|-------------|---------|
-| Route/Controller | Unitario | Validacao, status codes, response format | Service |
-| Service | Unitario | Regras de negocio, erros customizados | Repository |
-| Repository | Integracao | Queries, ORM operations, constraints | DB real ou in-memory |
-| E2E | E2E (supertest) | Fluxo HTTP completo | Nenhum |
-
-> **Use o exemplo mais proximo da stack detectada como referencia, mas SEMPRE adapte ao projeto real.**
-
----
-
-## Guardrails QA (Inviolaveis)
-
-### DEVE
-
-1. **NUNCA gere testes genericos** — cada teste deve ter cenario especifico, input concreto e resultado esperado verificavel
-2. **NUNCA pule cenarios de erro** — todo fluxo de sucesso deve ter pelo menos 2 cenarios de falha correspondentes
-3. **SEMPRE mapeie criterios de Aceite Tecnico (secao 9)** para testes (rastreabilidade obrigatoria na secao 10.6)
-4. **SEMPRE considere boundary values** e edge cases (limites de string, valores nulos, zero, negativos)
-5. **SEMPRE respeite os padroes de teste existentes** no projeto (nomenclatura, estrutura, frameworks)
-6. **NUNCA invente funcionalidades** nao mencionadas na TaskCard
-7. **Quando usado como subagente**, retorne APENAS o conteudo da secao 10 (sem introducao, sem explicacao extra)
-8. **SEMPRE identifique testes existentes a modificar** com base nos arquivos da secao 8
-9. **SEMPRE preencha todas as 6 subsecoes** (10.1 a 10.6) — use "N/A — [justificativa]" quando nao aplicavel
-
-### NAO DEVE
-
-1. **NUNCA** gere testes sem pesquisar o projeto primeiro
-2. **NUNCA** use nomes de testes vagos como "testa funcionalidade X"
-3. **NUNCA** omita o campo Mock/Setup — explique o que deve ser mockado ou preparado
-4. **NUNCA** gere testes que dependam de estado externo nao controlado
-5. **NUNCA** ignore testes de concorrencia quando a task envolve acesso concorrente
-6. **NUNCA** escreva cenarios sem input e output esperado concretos
-
----
-
-## Regras de Teste por Tipo de Task
-
-| 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 |
-| Task cria/modifica **navegacao ou rota** | Testar que a navegacao funciona corretamente com parametros |
-
----
-
-## Checklist de Qualidade Pre-Entrega
-
-Antes de entregar a secao 10 enriquecida, valide que:
-
-- [ ] Todos os criterios de Aceite Tecnico (secao 9) tem pelo menos um teste correspondente na secao 10.6
-- [ ] Cada componente de apresentacao tem testes de validacao, mapeamento e codigos de resposta
-- [ ] Cada componente de negocio tem testes de regras de negocio e erros de dominio
-- [ ] Cada componente de dados tem testes de CRUD e constraints
-- [ ] Cenarios de erro cobrem: timeout, duplicidade, not found, validacao, auth (secao 10.5)
-- [ ] Boundary values foram considerados (string vazia, tamanho maximo, zero, nulo)
-- [ ] Testes usam o framework e padroes detectados no Passo Zero (secao 10.4)
-- [ ] Mocks e setup estao claramente definidos para cada teste
-- [ ] Nomenclatura segue padroes do projeto
-- [ ] Testes existentes a modificar foram identificados (secao 10.1)
-- [ ] Rastreabilidade Aceite Tecnico -> Testes esta preenchida (secao 10.6)
-- [ ] Todas as 6 subsecoes (10.1 a 10.6) estao preenchidas ou marcadas N/A
-
----
-
-## Entrada
-
-$ARGUMENTS

package/frameworks/skills/taskcard-qa-expert/templates/task_tests_template.md

@@ -1,78 +0,0 @@
-# Secao 10. Testes
-
-## 10.1 Testes Existentes a Modificar
-Testes que ja existem e precisam ser atualizados por causa das mudancas desta task:
-
-| Arquivo de Teste | O que Modificar | Motivo |
-|-----------------|-----------------|--------|
-| `path/to/existing_test` | [descrever mudanca: novos cenarios, mocks atualizados, fixtures alteradas] | [interface alterada, novo campo, regra de negocio modificada] |
-
-> Se nenhum teste existente precisa ser modificado, indicar "Nenhum teste existente impactado — [justificativa]."
-
-## 10.2 Testes a Criar
-Novos testes que devem ser criados para cobrir as mudancas desta task:
-
-### Unitarios
-- [ ] **[arquivo_teste] TestNomeFuncao_Sucesso** — Cenario: [descricao precisa]. Input: [dados concretos]. Expected: [resultado especifico]. Mock: [o que mockar e retorno]
-- [ ] **[arquivo_teste] TestNomeFuncao_ErroValidacao** — Cenario: [descricao]. Input: [dados invalidos]. Expected: [erro especifico]. Mock: [se aplicavel]
-- [ ] **[arquivo_teste] TestNomeFuncao_ErroDependencia** — Cenario: [descricao]. Input: [dados validos]. Expected: [erro wrapped]. Mock: [dependencia retorna erro]
-
-### Integracao
-- [ ] **[arquivo_teste] TestIntegracao_FluxoCompleto** — Setup: [banco in-memory, migracoes, seed data]. Fluxo: [create -> get -> verify]. Validacao: [dados consistentes]
-- [ ] **[arquivo_teste] TestIntegracao_ErroConstraint** — Setup: [registro existente]. Fluxo: [insert duplicado]. Validacao: [erro de constraint]
-
-### E2E
-- [ ] **[arquivo_teste] TestE2E_FluxoPrincipal** — Pre-condicao: [estado inicial]. Passos: [request -> validar response -> verificar banco]. Pos-condicao: [estado final]
-
-> Se uma categoria nao se aplica a esta task, indicar "N/A — [justificativa]."
-
-## 10.3 Cenarios Obrigatorios
-Lista de cenarios que DEVEM ser cobertos pelos testes:
-
-### Sucesso (caminho feliz)
-- [ ] [descricao do cenario de sucesso principal]
-- [ ] [descricao de variacao de sucesso, se aplicavel]
-
-### Erro e Validacao
-- [ ] [cenario de erro de validacao de entrada]
-- [ ] [cenario de recurso nao encontrado]
-- [ ] [cenario de duplicidade/conflito]
-
-### Edge Cases e Boundary Values
-- [ ] [valor nulo ou vazio]
-- [ ] [valor no limite maximo]
-- [ ] [valor no limite minimo]
-- [ ] [caracteres especiais ou Unicode]
-
-### Concorrencia (se aplicavel)
-- [ ] [cenario de acesso concorrente]
-
-## 10.4 Padroes de Teste
-Referencia dos padroes de teste a seguir (identificados no Passo Zero):
-- **Framework**: [detectado — ex: testify, jest, pytest, flutter_test]
-- **Convencao de nomes**: [detectada — ex: Test<Layer>_<Function>_<Scenario>, describe/it, test_<function>]
-- **Fixture/Setup**: [detectado — ex: banco in-memory, factory functions, fixtures, beforeEach]
-- **Mocks**: [detectado — ex: interfaces com mock, jest.mock, mocktail, mockito]
-- **Patterns**: [detectado — ex: table-driven tests, parametrized, subtests, AAA]
-
-## 10.5 Cenarios de Erro
-Mapeamento exaustivo de cenarios de erro com detalhes tecnicos:
-
-| Cenario | Trigger | Expected | Codigo/Status | Log |
-|---------|---------|----------|---------------|-----|
-| [descricao do erro] | [o que causa o erro] | [comportamento esperado] | [codigo gRPC, HTTP status, excecao] | [mensagem de log esperada] |
-| [validacao invalida] | [input fora do esperado] | [rejeitar com mensagem clara] | [codes.InvalidArgument / 400 / ValidationError] | [log de warn com detalhes] |
-| [recurso nao encontrado] | [ID inexistente] | [retornar not found] | [codes.NotFound / 404 / NotFoundException] | [log de info com ID buscado] |
-| [dependencia falha] | [banco/servico externo indisponivel] | [erro wrapped com contexto] | [codes.Internal / 500 / InternalError] | [log de error com stack] |
-
-## 10.6 Rastreabilidade: Aceite Tecnico -> Testes
-Mapeamento entre cada criterio de aceite (secao 9) e os testes que o validam:
-
-| # | Criterio de Aceite (secao 9) | Teste(s) Correspondente(s) | Tipo |
-|---|------------------------------|---------------------------|------|
-| 1 | [criterio copiado da secao 9] | [TestNomeFuncao_Sucesso, TestIntegracao_FluxoCompleto] | [Unitario, Integracao] |
-| 2 | [criterio copiado da secao 9] | [TestNomeFuncao_ErroValidacao] | [Unitario] |
-| 3 | [criterio copiado da secao 9] | [TestE2E_FluxoPrincipal] | [E2E] |
-
-> **Todo criterio de aceite DEVE ter pelo menos um teste correspondente.**
-> Se um criterio nao e testavel automaticamente, justifique e indique como sera validado manualmente.