jarvis-ai-framework 1.0.0

package/rules/engineering/qa/eng.qa.cypress-standards-rules.md

@@ -0,0 +1,259 @@
+# Regras de Padrões Cypress — QA Engineering
+
+> **Applies to:** HUB: QA | POSITION: all | AREA: ENGINEERING | SQUAD: all
+
+Convenções obrigatórias para a escrita e manutenção da suíte de testes E2E em Cypress + TypeScript.
+Estas regras são carregadas automaticamente pelo `warm-up` quando `HUB=QA`.
+
+> **Fonte de verdade**: este arquivo define o padrão para toda a sessão.
+> A skill `eng-qa-cypress-e2e` assume que estas regras foram carregadas — não as redescobre.
+
+---
+
+## 1. Estrutura de Pastas
+
+```
+$TEST_FOLDER/
+├── e2e/                        ← specs organizados por domínio/feature
+│   ├── {dominio}/
+│   │   └── {feature}.cy.ts
+├── fixtures/                   ← dados de teste tipados
+│   └── {dominio}/
+│       └── {entidade}.json
+├── support/
+│   ├── commands/               ← custom commands por domínio
+│   │   └── {dominio}.commands.ts
+│   ├── pages/                  ← Page Objects
+│   │   └── {Dominio}Page.ts
+│   ├── commands.ts             ← barrel de imports dos commands
+│   └── e2e.ts                  ← configuração global
+└── cypress.config.ts
+```
+
+> `$TEST_FOLDER` é definido no `ENV.md` do projeto.
+> Se não definido, inferir do `cypress.config.ts` na raiz.
+
+---
+
+## 2. Nomenclatura de Arquivos
+
+| Tipo | Padrão | Exemplo |
+|------|--------|---------|
+| Spec | `{feature}.cy.ts` | `login.cy.ts` |
+| Page Object | `{Dominio}Page.ts` (PascalCase) | `LoginPage.ts` |
+| Custom command | `{dominio}.commands.ts` | `auth.commands.ts` |
+| Fixture | `{entidade}.json` | `usuario.json` |
+| Intercept fixture | `{endpoint}-{metodo}.json` | `usuarios-get.json` |
+
+---
+
+## 3. Estrutura de Spec (describe/it)
+
+```typescript
+describe('{Domínio} — {Feature}', () => {
+  beforeEach(() => {
+    // setup comum: autenticação, navegação inicial
+  })
+
+  afterEach(() => {
+    // limpeza se necessário
+  })
+
+  context('quando {condição}', () => {
+    it('deve {comportamento esperado}', () => {
+      // Arrange → Act → Assert
+    })
+  })
+})
+```
+
+**Regras de nomenclatura:**
+- `describe`: `{Domínio} — {Feature}` (domínio sempre em PascalCase)
+- `context`: `quando {condição}` — descreve o estado/pré-condição
+- `it`: `deve {comportamento}` — verifica um único comportamento
+- Nunca usar `it('test 1')`, `it('cenário A')` ou nomes vagos
+
+---
+
+## 4. Page Object Pattern
+
+```typescript
+// support/pages/LoginPage.ts
+export class LoginPage {
+  visit() {
+    cy.visit('/login')
+    return this
+  }
+
+  fillEmail(email: string) {
+    cy.get('[data-testid="input-email"]').type(email)
+    return this
+  }
+
+  fillPassword(password: string) {
+    cy.get('[data-testid="input-password"]').type(password)
+    return this
+  }
+
+  submit() {
+    cy.get('[data-testid="btn-submit"]').click()
+    return this
+  }
+
+  // Asserções ficam no Page Object quando são reutilizáveis
+  shouldShowError(message: string) {
+    cy.get('[data-testid="alert-error"]').should('contain', message)
+    return this
+  }
+}
+```
+
+**Regras do Page Object:**
+- Retornar `this` em todos os métodos de ação (fluent interface)
+- Métodos de asserção começam com `should`
+- Nunca colocar lógica de negócio — apenas interação com a UI
+- Um Page Object por página ou componente de alto nível
+- Importar e instanciar no topo da spec: `const page = new LoginPage()`
+
+---
+
+## 5. Seletores — Uso de `data-testid`
+
+**Hierarquia de preferência de seletores:**
+
+```
+1. cy.get('[data-testid="..."]')       ← PADRÃO — sempre preferir
+2. cy.get('[aria-label="..."]')        ← acessibilidade — segundo recurso
+3. cy.get('[role="..."]')              ← semântico — terceiro recurso
+4. cy.contains('Texto visível')        ← apenas para elementos de texto
+5. cy.get('.classe') / cy.get('#id')   ← PROIBIDO em specs novas
+```
+
+**Convenção de nomes para `data-testid`:**
+
+```
+{tipo}-{dominio}-{identificador}
+
+Exemplos:
+  btn-auth-login
+  input-form-email
+  table-users-list
+  row-users-{id}          ← para listas dinâmicas
+  modal-confirm-delete
+  alert-error-message
+```
+
+---
+
+## 6. Interceptação de API com `cy.intercept`
+
+```typescript
+// Padrão de intercept com fixture tipada
+cy.intercept('GET', '**/api/usuarios', { fixture: 'usuarios/usuarios-get.json' })
+  .as('getUsuarios')
+
+// Aguardar antes de asserção
+cy.wait('@getUsuarios')
+cy.get('[data-testid="table-users-list"]').should('be.visible')
+```
+
+**Regras de intercept:**
+- Sempre usar `.as('{verbo}{Recurso}')` — ex: `@getUsuarios`, `@postPagamento`
+- Sempre usar `cy.wait('@alias')` antes de asserções que dependem da resposta
+- Fixtures de intercept ficam em `fixtures/{dominio}/{endpoint}-{metodo}.json`
+- Para erros: passar `{ statusCode: 422, body: { message: '...' } }` diretamente (não fixture)
+- Nunca depender do estado real da API em testes E2E — sempre interceptar chamadas externas
+
+---
+
+## 7. Fixtures Tipadas
+
+```typescript
+// cypress/fixtures/usuarios/usuario.json
+{
+  "id": "usr-001",
+  "nome": "Dev Teste",
+  "email": "dev@example.com",
+  "perfil": "admin"
+}
+
+// Uso na spec com tipo
+import type { Usuario } from '../../src/types/usuario'
+
+cy.fixture<Usuario>('usuarios/usuario').then((usuario) => {
+  cy.get('[data-testid="input-email"]').type(usuario.email)
+})
+```
+
+**Regras de fixtures:**
+- Dados sensíveis (senhas, tokens) nunca em fixtures — usar `Cypress.env()`
+- Fixtures refletem contratos reais de API — atualizá-las quando a API muda
+- Usar tipos do projeto (`import type`) para garantir sincronia com o código
+
+---
+
+## 8. Custom Commands
+
+```typescript
+// support/commands/auth.commands.ts
+Cypress.Commands.add('loginAs', (perfil: 'admin' | 'viewer' | 'editor') => {
+  cy.fixture(`usuarios/${perfil}`).then((usuario) => {
+    cy.request('POST', '/api/auth/login', {
+      email: usuario.email,
+      password: Cypress.env('DEFAULT_PASSWORD'),
+    }).then(({ body }) => {
+      window.localStorage.setItem('auth_token', body.token)
+    })
+  })
+})
+```
+
+**Regras de custom commands:**
+- Prefixo do domínio no nome: `loginAs`, `selectCompany`, `fillAddress`
+- Login/autenticação sempre via `cy.request` (não via UI) — mais rápido e estável
+- Tipar os parâmetros com union types quando há opções fixas
+- Registrar em `support/commands.ts` e declarar tipo em `support/index.d.ts`
+
+---
+
+## 9. Cenários Obrigatórios por Spec
+
+Toda spec deve cobrir no mínimo:
+
+| Cenário | Obrigatório? |
+|---------|-------------|
+| Happy Path — fluxo principal com dados válidos | ✅ Sempre |
+| Edge Case — dados limite, campos opcionais | ✅ Se aplicável |
+| Negative Test — dados inválidos, erros esperados | ✅ Se há validação |
+| Estado vazio — lista sem itens, tela inicial | ⚠️ Quando relevante |
+| Permissão — comportamento por perfil de usuário | ⚠️ Quando há controle de acesso |
+
+---
+
+## 10. Antipadrões — Nunca Fazer
+
+```typescript
+// ❌ Seletor frágil
+cy.get('.btn-primary').click()
+cy.get('#submit').click()
+
+// ✅ Correto
+cy.get('[data-testid="btn-auth-submit"]').click()
+
+// ❌ Sleep hardcoded
+cy.wait(3000)
+
+// ✅ Correto — aguardar elemento ou intercept
+cy.wait('@postLogin')
+cy.get('[data-testid="dashboard-title"]').should('be.visible')
+
+// ❌ Lógica condicional no teste
+if (Cypress.env('USE_MOCK')) { ... }
+
+// ✅ Correto — sempre interceptar, nunca depender de flag
+
+// ❌ Dependência entre testes
+// Teste 2 só funciona se Teste 1 rodou antes
+
+// ✅ Correto — cada `it` deve ser independente (usar beforeEach para setup)
+```

package/rules/engineering/qa/eng.qa.exploratory-session-rules.md

@@ -0,0 +1,137 @@
+# Regras de Sessão de Teste Exploratório — QA Engineering
+
+> **Applies to:** HUB: QA | POSITION: all | AREA: ENGINEERING | SQUAD: all
+
+Convenções para planejamento, execução e documentação de sessões de teste exploratório estruturado.
+Carregadas automaticamente pelo `warm-up` quando `HUB=QA`.
+
+---
+
+## 1. Estrutura de Charter
+
+Todo teste exploratório começa com um **charter** — a declaração do objetivo da sessão.
+
+**Formato obrigatório:**
+
+```
+Explorar {área/feature/fluxo}
+para descobrir {tipo de informação / riscos a validar}
+com foco em {dimensão de qualidade}
+```
+
+**Exemplos:**
+
+```
+Explorar o fluxo de cadastro de veículos
+para descobrir comportamentos inesperados em campos opcionais e limites de dados
+com foco em robustez e validação de formulário
+
+Explorar a integração de pagamentos após alteração de plano
+para descobrir regressões introduzidas pela última release
+com foco em consistência de estado e mensagens ao usuário
+```
+
+**Regras do charter:**
+- Máximo 3 linhas — objetivo claro, não um roteiro detalhado
+- Não listar passos no charter — exploração decide o caminho
+- Um charter por sessão (sessões paralelas têm charters independentes)
+
+---
+
+## 2. Time-box Padrão
+
+| Tipo de sessão | Duração | Quando usar |
+|----------------|---------|-------------|
+| Rápida (spot check) | 30 min | Verificação pontual, pós-fix rápido |
+| Padrão | 60 min | Feature nova, área de risco moderado |
+| Profunda | 90 min | Feature crítica, área de alto risco, pré-release |
+
+**Regras de time-box:**
+- Nunca estender uma sessão além do tempo definido — iniciar nova sessão se necessário
+- Os primeiros 10 min são de setup e entendimento — não contam como execução
+- Registrar hora de início e fim no documento de sessão
+- Pausa obrigatória de 15 min entre sessões consecutivas
+
+---
+
+## 3. Classificação de Severidade de Bugs
+
+| Severidade | Label | Critério | Ação imediata |
+|------------|-------|----------|---------------|
+| **Crítico** | `S1` | Sistema inutilizável, perda de dados, falha de segurança | Reportar imediatamente — não esperar fim da sessão |
+| **Alto** | `S2` | Feature principal quebrada, sem workaround óbvio | Reportar ao final da sessão, com evidência |
+| **Médio** | `S3` | Feature funciona mas com comportamento incorreto ou inconsistente | Registrar no doc da sessão, criar card após |
+| **Baixo** | `S4` | UI incorreta, texto errado, comportamento subótimo mas funcional | Registrar no doc da sessão, agrupar em batch |
+| **Melhoria** | `S5` | Não é bug — sugestão de UX ou comportamento melhor | Separar claramente de bugs reais |
+
+**Regras de severidade:**
+- Nunca sub-reportar para "não incomodar" — severidade é objetiva, não subjetiva
+- Um bug S1 interrompe a sessão e é reportado via canal direto ao time
+- Bugs S4 e S5 podem ser agrupados em um card único "ajustes UI/UX — {área}"
+
+---
+
+## 4. Critérios de Parada de Sessão
+
+Encerrar a sessão antes do time-box quando:
+
+| Critério | Ação |
+|----------|------|
+| Bug S1 encontrado | Interromper, reportar imediatamente, documentar contexto |
+| Ambiente instável (falhas de infra, não de software) | Encerrar, registrar causa, reagendar |
+| Charter atingido antes do tempo | Encerrar normalmente, registrar cobertura atingida |
+| Descoberta muda completamente o escopo | Encerrar, definir novo charter para próxima sessão |
+
+**Nunca encerrar uma sessão sem:**
+- Registrar o que foi explorado (mesmo que parcialmente)
+- Classificar cada achado com severidade
+- Marcar se o charter foi atingido (`completo`, `parcial`, `bloqueado`)
+
+---
+
+## 5. Dimensões de Qualidade para Foco
+
+Ao definir o charter, escolher no máximo 2 dimensões de qualidade:
+
+| Dimensão | O que verificar |
+|----------|----------------|
+| **Funcionalidade** | O comportamento faz o que a spec diz? |
+| **Robustez** | Reage bem a entradas inesperadas, limites, dados faltantes? |
+| **Consistência** | Estado do sistema permanece coerente após a ação? |
+| **Performance percebida** | Tempos de resposta aceitáveis para o usuário? |
+| **Acessibilidade** | Navegação por teclado, leitores de tela, contraste? |
+| **Segurança superficial** | Dados expostos indevidamente, autorização correta? |
+| **Integração** | Comunicação correta com outros módulos/serviços? |
+| **Regressão** | Funcionalidades existentes ainda funcionam após mudança? |
+
+---
+
+## 6. Evidências Obrigatórias
+
+Para cada bug reportado:
+
+```
+- Severidade: S{1-5}
+- Passos para reproduzir: numerados, a partir do estado inicial
+- Comportamento observado: o que aconteceu
+- Comportamento esperado: o que deveria acontecer
+- Evidência: screenshot, vídeo ou log (obrigatório para S1/S2)
+- Ambiente: URL/versão/dados usados no momento do bug
+- Reprodutível?: sim / às vezes / não consegui reproduzir novamente
+```
+
+---
+
+## 7. Integração com `eng-qa-bug-report`
+
+Ao final de cada sessão, para cada achado S1–S4, acionar o skill `eng-qa-bug-report`:
+
+```
+/eng-qa-bug-report create
+  --title="{descrição concisa}"
+  --severity="S{1-4}"
+  --session="{id da sessão}"
+  --passos="{passos reproduzidos}"
+```
+
+Achados S5 (melhorias) são registrados apenas no doc da sessão — não viram card automaticamente.

package/rules/engineering/qa/eng.qa.quality-gate-scoring-rules.md

@@ -0,0 +1,181 @@
+> **Applies to:** HUB: QA | POSITION: QA-ENGINEER, SPECIALIST | AREA: ENGINEERING | SQUAD: all
+
+# Regras de Classificação de Score
+
+Sistema de pontuação e bloqueio para quality gates de tech specs.
+
+## Faixas de Score
+
+### 🚫 BLOQUEANTE - Score < 50%
+
+**Status**: Não conforme
+**Label**: `QualityGate::Bloqueado`
+**Ação**: Card **NÃO PODE** prosseguir para breakdown. Deve retornar para refinamento.
+
+#### Quando bloquear:
+- Faltam 3 ou mais critérios obrigatórios
+- Descrição completamente vazia ou genérica
+- SPIKE sem referências de discovery
+- Critérios de aceitação ausentes ou muito vagos
+- Bug sem passos para reproduzir
+- Análise técnica inexistente ou incompleta
+- Subtarefas propostas são fatias horizontais (só enum, só repository, só factory, só DTO, só contratos sem implementação funcional) ou não passam no Teste de Validação de independência
+
+#### Mensagem ao time:
+> ⚠️ **Card bloqueado para breakdown**. Tech spec não atende aos critérios mínimos de qualidade. Refine conforme recomendações e solicite nova análise.
+
+---
+
+### ⚠️ PARCIAL - Score 50-99%
+
+**Status**: Parcialmente conforme
+**Label**: `QualityGate::Parcial`
+**Ação**: Card **PODE** prosseguir, mas com ressalvas. Recomenda-se refinamento antes.
+
+#### Quando classificar como parcial:
+- 1-2 critérios obrigatórios faltando
+- Critérios presentes mas podem ser melhorados
+- Faltam alguns cenários de teste
+- Análise técnica superficial
+- Dependências parcialmente mapeadas
+
+#### Mensagem ao time:
+> ℹ️ **Card pode prosseguir com ressalvas**. A tech spec está funcional mas pode ser melhorada. Considere as recomendações para aumentar qualidade.
+
+---
+
+### ✅ CONFORME - Score 100%
+
+**Status**: Conforme
+**Label**: `QualityGate::Conforme`
+**Ação**: Card está **PRONTO** para breakdown de subtarefas.
+
+#### Quando aprovar:
+- Todos os critérios obrigatórios atendidos
+- Tech spec clara, completa e acionável
+- Equipe pode iniciar implementação sem dúvidas
+- Critérios de aceitação mensuráveis
+- Cenários de teste identificados
+- Análise técnica detalhada
+- Dependências mapeadas
+
+#### Mensagem ao time:
+> ✅ **Tech spec aprovada!** Todos os critérios de qualidade atendidos. Card pronto para breakdown de subtarefas.
+
+---
+
+## Cálculo de Score
+
+### Metodologia
+
+1. **Identificar critérios obrigatórios** do tipo de card (Task/Spike/Bug)
+2. **Verificar cada critério**: Atendido = 1 ponto, Não atendido = 0 pontos
+3. **Calcular percentual**: (Critérios atendidos / Total critérios) × 100
+
+### Exemplo: Task
+
+| Critério | Atendido? | Peso |
+|----------|-----------|------|
+| Descrição Clara | ✅ Sim | 15% |
+| Critérios de Aceitação | ✅ Sim | 20% |
+| Cenários de Teste | ❌ Não | 15% |
+| Análise Técnica | ✅ Sim | 15% |
+| Dependências | ⚠️ Parcial | 10% |
+| **Valor Unitário (fatia vertical)** | ✅ Sim | **25%** |
+
+**Score**: 80/100 → **Parcial**
+
+> **Critério 6 — Valor Unitário (fatia vertical)** é o critério de maior peso. Avalia se as subtarefas propostas são **entregáveis completos e independentes** (endpoint inteiro, modal inteiro, tela inteira) e **não** fatias horizontais (só enum, só repository, só factory, só DTO). Uma subtarefa só é válida se, mergeada isoladamente, a aplicação continua funcionando e a entrega é observável.
+
+---
+
+## Matriz de Decisão
+
+| Score | Status | Label | Pode prosseguir? | Ação requerida |
+|-------|--------|-------|------------------|----------------|
+| 0-49% | 🚫 Não conforme | `QualityGate::Bloqueado` | ❌ Não | Refinamento obrigatório |
+| 50-99% | ⚠️ Parcial | `QualityGate::Parcial` | ⚠️ Com ressalvas | Refinamento recomendado |
+| 100% | ✅ Conforme | `QualityGate::Conforme` | ✅ Sim | Prosseguir para breakdown |
+
+---
+
+## Regras Especiais
+
+### Critérios Críticos (Bloqueantes Automáticos)
+
+Mesmo com score > 50%, o card é **automaticamente bloqueado** se:
+
+#### Para SPIKE:
+- ❌ Ausência completa de referências de discovery
+
+#### Para BUG:
+- ❌ Ausência de passos para reproduzir
+- ❌ Ausência de análise técnica
+
+#### Para TASK:
+- ❌ Ausência de critérios de aceitação
+- ❌ Descrição vazia ou extremamente genérica (< 50 caracteres)
+- ❌ Subtarefas propostas são fatias horizontais (split por camada) — ex: cards separados para "criar enum", "criar repository", "criar factory", "criar DTO", "criar contratos/interfaces" sem implementação funcional
+- ❌ Subtarefas não passam no Teste de Validação de independência (não mergeáveis isoladamente sem quebrar o sistema)
+
+### Exemplo:
+```
+Score calculado: 60% (Parcial)
+Mas: Task sem critérios de aceitação
+Resultado final: BLOQUEADO (critério crítico não atendido)
+```
+
+---
+
+## Processo de Reavaliação
+
+### Após Correções
+
+1. Desenvolvedor corrige problemas apontados
+2. Solicita nova análise (comentário mencionando Quality Champion)
+3. Nova validação é realizada
+4. Score é recalculado
+5. Label é atualizada
+
+### Histórico de Validações
+
+Cada validação deve incluir:
+- Data/hora da análise
+- Score obtido
+- Status resultante
+- Principais gaps identificados
+
+Isso permite rastreabilidade e melhoria contínua do processo.
+
+---
+
+## Exceções e Escalação
+
+### Quando Escalar
+
+Em casos excepcionais, pode-se solicitar aprovação manual:
+
+- Urgência crítica (produção parada)
+- Contexto especial conhecido pelo time
+- Tech spec de spike exploratório inicial
+
+**Processo**:
+1. Adicionar comentário justificando exceção
+2. Mencionar tech lead ou arquiteto
+3. Obter aprovação explícita
+4. Documentar decisão no card
+
+**Label**: `QualityGate::Exceção` (substitui label automática)
+
+---
+
+## Métricas de Qualidade
+
+### KPIs Sugeridos
+
+- **Taxa de conformidade**: % de cards com score 100%
+- **Taxa de bloqueio**: % de cards < 50%
+- **Tempo médio de refinamento**: Tempo entre bloqueio e aprovação
+- **Reincidência**: Cards bloqueados > 1 vez
+
+Essas métricas ajudam a identificar gaps de processo e melhorar qualidade geral das tech specs.

package/rules/engineering/qa/eng.qa.tech-spec-validation-criteria-rules.md

@@ -0,0 +1,120 @@
+> **Applies to:** HUB: QA | POSITION: QA-ENGINEER, SPECIALIST | AREA: ENGINEERING | SQUAD: all
+
+# Critérios de Validação de Tech Spec
+
+Critérios objetivos para validação de especificações técnicas, organizados por tipo de card.
+
+## Para TASKS Normais
+
+### ✅ Obrigatório (Bloqueante)
+
+#### 1. Descrição Clara e Objetiva
+- Contexto do problema/necessidade
+- Objetivo da tarefa bem definido
+- Escopo delimitado
+
+#### 2. Critérios de Aceitação
+- Pelo menos 3 critérios bem definidos
+- Critérios específicos e mensuráveis
+- Formato: "O sistema deve..." ou "Quando... então..."
+
+#### 3. Cenários de Teste
+- Pelo menos 2 cenários identificados
+- Casos de sucesso definidos
+- Casos de erro/exceção identificados
+
+#### 4. Análise Técnica
+- Abordagem técnica documentada
+- Tecnologias/bibliotecas a serem utilizadas
+- Impactos em outras partes do sistema identificados
+
+#### 5. Dependências
+- Dependências técnicas mapeadas
+- Dependências de outros cards identificadas (se houver)
+
+### ⚡ Desejável (Não Bloqueante)
+
+- Estimativa de complexidade (P, M, G)
+- Riscos identificados
+- Alternativas de implementação consideradas
+- Diagrama ou fluxo (quando aplicável)
+
+---
+
+## Para SPIKE (Discovery)
+
+### ✅ Obrigatório (Bloqueante)
+
+#### 1. Objetivo do Spike
+- O que precisa ser investigado/descoberto
+- Perguntas que precisam ser respondidas
+- Escopo bem definido
+
+#### 2. Referência de Discovery
+- **CRÍTICO**: Local onde será realizado o discovery
+- Links para documentação oficial
+- APIs, SDKs ou ferramentas a serem investigadas
+- Exemplo: "Banco Rendimento - https://desenvolvedores.rendimento.com.br/api-portal/"
+
+#### 3. Critérios de Conclusão
+- O que define o spike como concluído
+- Entregáveis esperados (POC, documento, análise comparativa, etc.)
+- Tempo máximo estimado
+
+#### 4. Contexto e Justificativa
+- Por que este spike é necessário
+- Qual decisão depende deste discovery
+
+### ⚡ Desejável (Não Bloqueante)
+
+- Alternativas a serem comparadas
+- Critérios de avaliação
+- Impacto da decisão no projeto
+
+---
+
+## Para BUG
+
+### ✅ Obrigatório (Bloqueante)
+
+#### 1. Descrição do Bug
+- Comportamento esperado
+- Comportamento atual (incorreto)
+- Impacto do bug
+
+#### 2. Passos para Reproduzir
+- Lista numerada e clara
+- Dados de teste necessários
+- Ambiente onde ocorre
+
+#### 3. Análise Técnica
+- Causa raiz identificada (ou hipótese)
+- Arquivos/componentes afetados
+- Solução proposta
+
+#### 4. Severidade e Prioridade
+- Classificação de severidade
+- Justificativa da prioridade
+
+---
+
+## Checklist Rápido por Tipo
+
+### Task
+- [ ] Descrição com contexto, objetivo e escopo
+- [ ] Mínimo 3 critérios de aceitação mensuráveis
+- [ ] Mínimo 2 cenários de teste (sucesso + erro)
+- [ ] Análise técnica com stack e impactos
+- [ ] Dependências mapeadas
+
+### Spike
+- [ ] Objetivo e perguntas definidas
+- [ ] **Referências de discovery** (docs, APIs, SDKs)
+- [ ] Critérios de conclusão e entregáveis
+- [ ] Contexto e justificativa do spike
+
+### Bug
+- [ ] Comportamento esperado vs atual
+- [ ] Passos para reproduzir numerados
+- [ ] Causa raiz e arquivos afetados
+- [ ] Severidade e prioridade justificadas