jarvis-ai-framework 2.1.0 → 3.0.0

package/rules/engineering/eng.downstream-flow-rules.md

@@ -1,297 +0,0 @@
----
-trigger: always_on
-env_file: "@/ENV.md"
----
-
-> **Applies to:** HUB: all | POSITION: all | AREA: all | SQUAD: all
-
-# Regras de Fluxo Downstream — Responsáveis e Critérios
-
-> Referência obrigatória ao mover cards no board (Jira, GitLab, Linear ou equivalente).
-> Consultar antes de orientar o usuário sobre transição de status.
-
----
-
-> Fonte de cargos: `taxonomy.md`. Este arquivo define o fluxo. Autonomia: o profissional que assumiu o card conduz ponta-a-ponta.
-
-## Princípio de autonomia
-
-Quem assumiu o card é o **owner** e pode avançar **todas** as transições abaixo.
-TECH LEAD, PM e pares **revisam e apoiam** — não precisam clicar para o trabalho continuar.
-
-Papéis no fluxo (ainda existem; não são cadeado):
-
-| Papel no Fluxo | Positions | Papel |
-|---|---|---|
-| **Owner** | quem pegou o card: DEV, TECH LEAD ou PM | Conduz ponta-a-ponta |
-| **DEV** | `JUNIOR`, `PLENO`, `SENIOR`, `SPECIALIST` | Entrega técnica |
-| **TECH LEAD** | `TECH LEAD` | Apoia priorização, review e deploy quando pedido |
-| **PM** | `PM`, `TPM`, `GPM` | Apoia aceite de produto quando pedido |
-| **QA** | `QA-ENGINEER` | Executa testes em apoio; não bloqueia o owner |
-| **N2** | Suporte N2 | Validação operacional se o time tiver esse papel |
-
-## Diagrama do Fluxo
-
-```mermaid
-graph TD
-    A[A fazer] -->|Owner puxa| B[Pronto para desenvolvimento]
-    B -->|Owner assume| C[Em progresso]
-    C -->|Owner abre MR| D[Review de código]
-    D -->|Owner após merge/review| E[Pronto para QA]
-    E -->|Owner inicia testes| F[Em QA]
-    F -->|Owner se negativo +flag| B
-    F -->|Owner se positivo| G[Pronto para produto]
-    G -->|Owner ou PM se ajuste +flag| B
-    G -->|Owner ou PM se OK| H[Pronto para deploy]
-    H -->|Owner inicia deploy| I[Em rollout]
-    I -->|Owner quando estável| J[Validação]
-    J -->|Owner/PM/N2 se problema| B
-    J -->|Owner/PM/N2 se OK| K[Pronto/Cancelado]
-    A -.->|Owner/TL/PM cancelam| K
-```
-
----
-
-## Matriz de Transições (Quem move o quê)
-
-Default: **Owner do card**. TL/PM podem mover também (apoio), nunca como bloqueio.
-
-| De | Para | Quem move | Quando mover |
-|---|---|---|---|
-| **A fazer** | Pronto para desenvolvimento | **Owner** (DEV, TL ou PM) | Quando o card estiver claro o bastante para puxar |
-| **Pronto para desenvolvimento** | Em progresso | **Owner** | Quando assumir e começar |
-| **Em progresso** | Review de código | **Owner** | Quando abrir MR pronto para revisão |
-| **Review de código** | Pronto para QA | **Owner** | Após merge ou review (qualquer revisor; TL não é obrigatório) |
-| **Pronto para QA** | Em QA | **Owner** | Quando iniciar testes |
-| **Em QA** | Pronto para produto | **Owner** | Resultado positivo |
-| **Em QA** | Pronto para desenvolvimento | **Owner** | Resultado negativo — flag + comentário |
-| **Pronto para produto** | Pronto para deploy | **Owner ou PM** | Aceite (owner pode auto-aceitar se PM não estiver no fluxo) |
-| **Pronto para produto** | Pronto para desenvolvimento | **Owner ou PM** | Ajustes — flag + comentário |
-| **Pronto para deploy** | Em rollout | **Owner** | Quando iniciar deploy |
-| **Em rollout** | Validação | **Owner** | Deploy estável |
-| **Validação** | Pronto/Cancelado | **Owner, PM ou N2** | Validação ok |
-| **Validação** | Pronto para desenvolvimento | **Owner, PM ou N2** | Problema — comentário |
-| **Qualquer etapa** | Pronto/Cancelado | **Owner, TL ou PM** | Cancelar com motivo |
-
----
-
-## Responsabilidades no Fluxo
-
-### Owner (DEV, TECH LEAD ou PM — quem assumiu)
-- Puxa, implementa, abre MR, faz merge, valida, aceita e faz deploy do **próprio** card.
-- Pede review/ajuda quando quiser — não é obrigatório esperar.
-
-### TECH LEAD
-- Apoia priorização, review e deploy **quando pedido**.
-- Pode mover qualquer card (destravar, cancelar, cobrir férias).
-- Não é gate: o DEV não espera o TL para avançar.
-
-### DEV
-- Dono da entrega ponta-a-ponta dos cards que assumiu.
-- Pode escrever spec de produto, tech spec e subtarefas.
-
-### QA
-- Executa testes e reporta bugs em apoio ao owner.
-- Não bloqueia o owner de avançar depois de registrar o resultado.
-
-### PM / TPM / GPM
-- Pode escrever spec, priorizar e aceitar.
-- Pode assumir um card e conduzi-lo (incluindo handoff técnico).
-- Aceite de produto é desejável, não cadeado: owner avança se PM não estiver no fluxo.
-
-### N2
-- Validação operacional pós-deploy **se o time tiver esse papel**.
-- Owner pode encerrar o card se não houver N2.
-
----
-
-## Detalhamento dos Estágios
-
-### 1) A fazer — Owner: quem for puxar
-
-**Objetivo:** fila saudável e "puxável".
-
-**Pronto para entrar:**
-- Contexto mínimo existe (objetivo, escopo, restrições, critérios de aceite).
-- Dependências mapeadas (ou explicitamente "nenhuma").
-
-**Saídas:** *Pronto para desenvolvimento* quando o profissional puxar (DEV, TL ou PM).
-
-**Responsabilidades:**
-- Owner (ou TL/PM se estiver refinando o backlog) deixa o card puxável.
-- Não esperar o TL para puxar um card já claro.
-
----
-
-### 2) Pronto para desenvolvimento — Owner: DEV
-
-**Objetivo:** sinalizar que pode ser iniciado imediatamente.
-
-**Pronto para entrar:**
-- Critérios de aceite claros.
-- Definição de "feito" acordada (testes, logs, métricas, migração, feature flag, etc.).
-
-**Saídas:** *Em progresso* quando alguém pegar.
-
-**Responsabilidades do DEV:**
-- Assumir a entrega ponta-a-ponta do card (inclui QA/ajustes até pronto).
-
-> O owner move para "Em progresso" ao assumir. Se o card ficar parado, qualquer DEV/TL/PM pode puxá-lo.
-
----
-
-### 3) Em progresso — Owner: DEV
-
-**Objetivo:** implementação ativa.
-
-**Pronto para entrar:** card já assumido, branch/MR iniciados.
-
-**Saídas:** *Review de código* quando houver MR pronto.
-
-**Responsabilidades do DEV:**
-- Comunicar riscos cedo (bloqueios, escopo estourando, dependências).
-- Garantir checklist básico (lint/test/build, migrações, logs/telemetria quando aplicável).
-
----
-
-### 4) Review de código — Owner: DEV
-
-**Objetivo:** MR em revisão até merge.
-
-**Pronto para entrar:**
-- MR aberto, descrevendo mudança, riscos, como testar, rollback/flag quando aplicável.
-- Link do ticket no MR.
-
-**Saídas:** *Pronto para QA* após merge ou review.
-
-**Responsabilidades do owner (autor do MR):**
-- Pedir review quando fizer sentido; responder comentários; manter MR pequeno.
-- Se review travar, o owner desbloqueia (pede ajuda ao TL/par — não fica parado esperando).
-
-**Quem move para próxima etapa:** o owner (após merge ou revisão).
-
----
-
-### 5) Pronto para QA — Owner: DEV
-
-**Objetivo:** pacote pronto para validação (ambiente e instruções).
-
-**Pronto para entrar:**
-- Mudança disponível em ambiente de teste (ou release candidate preparado).
-- Passo-a-passo de validação e critérios de aceite listados.
-
-**Saídas:** *Em QA* quando DEV iniciar os testes e validação.
-
-**Responsabilidades do DEV:**
-- Garantir que existe build/ambiente e dados/seed (se necessário).
-- Garantir instruções de teste.
-- Mover para *Em QA* quando iniciar a validação.
-
----
-
-### 6) Em QA — Owner: DEV
-
-**Objetivo:** validar e corrigir até ficar ok.
-
-**Pronto para entrar:** DEV executando testes ou validação em andamento.
-
-**Saídas:**
-- Volta para *Pronto para desenvolvimento* (se resultado negativo) — DEV adiciona flag e comentário.
-- Vai para *Pronto para produto* quando resultado positivo.
-
-**Responsabilidades do DEV:**
-- Executar testes e validação (pode contar com apoio do QA).
-- Se encontrar bugs/problemas, voltar para *Pronto para desenvolvimento* com flag e comentário claro.
-- Manter ciclo curto (fix → reteste).
-- Não jogar o card para outra pessoa só para mudar status — o owner avança.
-
-> Se QA atuar, manter Owner: DEV (accountability de entrega) e definir "Executor: QA". Isso evita o limbo "QA é o dono então dev não corre".
-
----
-
-### 7) Pronto para produto — Owner: quem entregou (PM apoia)
-
-**Objetivo:** validação funcional/negócio.
-
-**Pronto para entrar:**
-- Validação técnica ok.
-- Evidências quando fizer sentido.
-
-**Saídas:** *Pronto para deploy* quando aprovado (pelo PM **ou** pelo owner se PM não estiver no fluxo).
-
-**Responsabilidades:**
-- PM valida comportamento quando estiver no fluxo.
-- Owner pode auto-aceitar em times pequenos / se o aceite de produto não for um papel separado.
-- Ajustes: volta para *Pronto para desenvolvimento* com flag e comentário.
-
----
-
-### 8) Pronto para deploy — Owner: quem vai publicar
-
-**Objetivo:** deploy consciente (rollback/flag quando necessário).
-
-**Pronto para entrar:**
-- Aceite feito (PM ou owner).
-- Plano de deploy/rollback/flag quando o risco pedir.
-
-**Saídas:** *Em rollout* quando iniciar deploy.
-
-**Responsabilidades do owner:**
-- Executar ou coordenar o deploy do próprio card.
-- Pedir apoio ao TL em janela de risco — não é obrigatório.
-
----
-
-### 9) Em rollout — Owner: quem publicou
-
-**Objetivo:** rollout em execução e monitorado.
-
-**Pronto para entrar:** deploy iniciado.
-
-**Saídas:** *Validação* quando a mudança estiver ativa e estável.
-
-**Responsabilidades do owner:**
-- Monitorar métricas/logs/alertas; rollback se necessário.
-- Comunicar status. Pedir ajuda ao TL em incidente.
-
----
-
-### 10) Validação — Owner: quem publicou (PM/N2 apoiam)
-
-**Objetivo:** validação operacional e de suporte (pós-deploy).
-
-**Pronto para entrar:** feature ativa, checklist de validação disponível.
-
-**Saídas:** *Pronto/Cancelado* quando validado (ou encerrado).
-
-**Responsabilidades do N2:**
-- Confirmar que a feature está funcionando no "mundo real".
-- Se encontrar problema: voltar para *Pronto para desenvolvimento* com comentário objetivo do que falhou.
-- Se validação OK: mover para *Pronto/Cancelado*.
-
----
-
-### 11) Pronto/Cancelado — Owner: quem fechou o card
-
-**Objetivo:** fechamento formal.
-
-**Pronto para entrar:**
-- Validado com sucesso **ou**
-- Cancelado com motivo registrado.
-
-**Responsabilidades:**
-- Owner, TL ou PM registram motivo de cancelamento ou evidência de entrega.
-- Qualquer um deles pode cancelar com motivo (prioridade/escopo).
-
----
-
-## RACI
-
-| Papel | Ação no fluxo |
-|---|---|
-| **Owner (DEV, TL ou PM)** | Conduz o card ponta-a-ponta. Move todas as transições do próprio trabalho. |
-| **TECH LEAD** | Apoia. Pode mover qualquer card para destravar — não é gate. |
-| **DEV** | Entrega técnica completa, inclusive spec/PR/deploy dos cards que assumiu. |
-| **QA** | Testa e reporta. Não bloqueia o owner. |
-| **PM / TPM / GPM** | Spec, priorização e aceite. Pode assumir e conduzir um card. |
-| **N2** | Validação operacional se existir no time. |

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

@@ -1,137 +0,0 @@
-# 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

@@ -1,181 +0,0 @@
-> **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.