jarvis-ai-framework 2.1.1 → 3.2.0

package/bin/lib/docs/publish-file.sh

@@ -1,284 +0,0 @@
-#!/bin/bash
-# Publica documento no central-docs (GitLab / GitHub / Bitbucket) via branch + MR/PR
-
-set -e
-
-LOCAL_FILE="$1"      # Ex: ./docs/engineering/ard-api-wallet.md
-TIPO="$2"            # prd|frd|ard|rfc
-FEATURE="$3"         # Ex: api-wallet-auth-jwt
-
-# Resolver path absoluto do script (independente de cwd)
-SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
-
-if [ -z "$LOCAL_FILE" ] || [ -z "$TIPO" ] || [ -z "$FEATURE" ]; then
-  echo "Uso: publish-file.sh <local-file> <tipo> <feature>" >&2
-  echo "Tipos válidos: prd, frd, ard, rfc, swagger, qa-report" >&2
-  exit 1
-fi
-
-if [ ! -f "$LOCAL_FILE" ]; then
-  echo "Erro: Arquivo não encontrado: $LOCAL_FILE" >&2
-  exit 1
-fi
-
-# Detectar IDE directory
-if [ -d ".windsurf" ]; then
-  IDE=".windsurf"
-elif [ -d ".claude" ]; then
-  IDE=".claude"
-elif [ -d ".cursor" ]; then
-  IDE=".cursor"
-elif [ -d ".vscode" ]; then
-  IDE=".vscode"
-else
-  echo "Erro: IDE directory não encontrado (.windsurf, .claude, .cursor, .vscode)" >&2
-  exit 1
-fi
-
-# 1. Ler ENV.md (se não houver override)
-if [ -n "$SQUAD_OVERRIDE" ] && [ -n "$WORKSPACE_OVERRIDE" ]; then
-  # Usar override das variáveis de ambiente
-  SQUAD="$SQUAD_OVERRIDE"
-  WORKSPACE="$WORKSPACE_OVERRIDE"
-else
-  # Ler do ENV.md
-  if [ ! -f "$IDE/ENV.md" ]; then
-    echo "Erro: ENV.md não encontrado em $IDE/" >&2
-    echo "Ou passe --squad e --workspace via CLI" >&2
-    exit 1
-  fi
-
-  SQUAD=$(grep '^SQUAD=' "$IDE/ENV.md" | cut -d'=' -f2 | tr -d ' ')
-  WORKSPACE=$(grep '^WORKSPACE=' "$IDE/ENV.md" | cut -d'=' -f2 | tr -d ' ')
-  
-  if [ -z "$SQUAD" ] || [ -z "$WORKSPACE" ]; then
-    echo "Erro: SQUAD ou WORKSPACE não definidos no ENV.md" >&2
-    echo "Ou passe --squad e --workspace via CLI" >&2
-    exit 1
-  fi
-fi
-
-TARGET_BRANCH="${CENTRAL_DOCS_TARGET_BRANCH:-dev}"
-
-if [ -z "$CENTRAL_DOCS_REPO" ]; then
-  echo "Erro: CENTRAL_DOCS_REPO não definido no ENV.md" >&2
-  exit 1
-fi
-
-# 2. Validar frontmatter
-echo "Validando frontmatter..."
-node --input-type=module -e "
-  import { validateFrontmatter } from 'file://${SCRIPT_DIR}/validate-frontmatter.js';
-  try {
-    validateFrontmatter('$LOCAL_FILE', '$TIPO');
-    console.log('✅ Frontmatter válido');
-  } catch (error) {
-    console.error(error.message);
-    process.exit(1);
-  }
-"
-
-if [ $? -ne 0 ]; then
-  exit 1
-fi
-
-# 3. Extrair metadados
-METADATA=$(node --input-type=module -e "
-  import { extractMetadata } from 'file://${SCRIPT_DIR}/validate-frontmatter.js';
-  const metadata = extractMetadata('$LOCAL_FILE');
-  console.log(JSON.stringify(metadata));
-")
-
-VERSION=$(echo "$METADATA" | jq -r '.version // "1.0.0"')
-STATUS=$(echo "$METADATA" | jq -r '.status // "draft"')
-JIRA=$(echo "$METADATA" | jq -r '.jira // ""')
-DOC_NAME=$(echo "$METADATA" | jq -r '.name // ""')
-
-# 4. Definir paths
-if [ "$TIPO" = "prd" ] || [ "$TIPO" = "frd" ]; then
-  DEST_PATH="${SQUAD}/${WORKSPACE}/product/${TIPO}-${FEATURE}.md"
-  AREA="product"
-elif [ "$TIPO" = "ard" ]; then
-  DEST_PATH="${SQUAD}/${WORKSPACE}/engineering/ARD/${TIPO}-${FEATURE}.md"
-  AREA="engineering"
-elif [ "$TIPO" = "rfc" ]; then
-  DEST_PATH="${SQUAD}/${WORKSPACE}/engineering/RFC/${TIPO}-${FEATURE}.md"
-  AREA="engineering"
-elif [ "$TIPO" = "swagger" ]; then
-  # Detectar extensão do arquivo (yaml, json ou md)
-  FILE_EXT="${LOCAL_FILE##*.}"
-  if [ "$FILE_EXT" = "yaml" ] || [ "$FILE_EXT" = "yml" ]; then
-    DEST_PATH="${SQUAD}/${WORKSPACE}/engineering/swagger/api-${FEATURE}.yaml"
-  elif [ "$FILE_EXT" = "json" ]; then
-    DEST_PATH="${SQUAD}/${WORKSPACE}/engineering/swagger/api-${FEATURE}.json"
-  else
-    # Default para .md (wrapper com metadados)
-    DEST_PATH="${SQUAD}/${WORKSPACE}/engineering/swagger/swagger-${FEATURE}.md"
-  fi
-  AREA="engineering"
-elif [ "$TIPO" = "qa-report" ]; then
-  DEST_PATH="${SQUAD}/${WORKSPACE}/engineering/qa/qa-report-${FEATURE}.md"
-  AREA="engineering"
-else
-  echo "Erro: Tipo inválido: $TIPO" >&2
-  echo "Tipos válidos: prd, frd, ard, rfc, swagger, qa-report" >&2
-  exit 1
-fi
-
-INDEX_PATH="${SQUAD}/${WORKSPACE}/index.md"
-BRANCH_NAME="docs/${SQUAD}/${WORKSPACE}/${TIPO}-${FEATURE}"
-
-echo ""
-echo "📋 Resumo da Publicação:"
-echo "  Squad: $SQUAD"
-echo "  Workspace: $WORKSPACE"
-echo "  Tipo: $TIPO"
-echo "  Feature: $FEATURE"
-echo "  Destino: $DEST_PATH"
-echo "  Branch: $BRANCH_NAME → $TARGET_BRANCH"
-echo ""
-
-# 5–6. Token e parse do repo ficam no adapter VCS (api.js)
-
-# 7. Ler conteúdo do arquivo local e encodar em base64
-FILE_CONTENT=$(cat "$LOCAL_FILE" | base64)
-
-# 8. Buscar index.md atual
-echo "Buscando index.md do workspace..."
-INDEX_CONTENT=$(bash "${SCRIPT_DIR}/fetch-file.sh" "$INDEX_PATH" "$TARGET_BRANCH" 2>/dev/null || echo "")
-
-if [ -z "$INDEX_CONTENT" ]; then
-  echo "⚠️  index.md não encontrado, será criado"
-  INDEX_ACTION="create"
-  INDEX_CONTENT="# $WORKSPACE
-
-**Squad:** $SQUAD
-
-## $AREA
-
-"
-else
-  INDEX_ACTION="update"
-fi
-
-# 9. Adicionar nova linha ao index.md
-NEW_LINE="- [${TIPO}-${FEATURE}.md](${AREA}/${TIPO}-${FEATURE}.md) | v${VERSION} | ${STATUS}"
-[ -n "$JIRA" ] && NEW_LINE="${NEW_LINE} | jira: ${JIRA}"
-[ -n "$DOC_NAME" ] && NEW_LINE="${NEW_LINE} | ${DOC_NAME}"
-
-# Adicionar linha na seção correta
-UPDATED_INDEX=$(echo "$INDEX_CONTENT" | awk -v line="$NEW_LINE" -v area="$AREA" '
-  /^## (product|engineering)/ {
-    print
-    if ($2 == area) {
-      found = 1
-      getline
-      print line
-    }
-    next
-  }
-  { print }
-  END {
-    if (!found) {
-      print ""
-      print "## " area
-      print line
-    }
-  }
-')
-
-UPDATED_INDEX_B64=$(echo "$UPDATED_INDEX" | base64)
-
-# 10. Criar commit via adapter VCS
-echo "Criando branch e commit..."
-
-COMMIT_JSON=$(mktemp)
-cat > "$COMMIT_JSON" <<EOF
-{
-  "branch": $(printf '%s' "$BRANCH_NAME" | jq -Rs .),
-  "startBranch": $(printf '%s' "$TARGET_BRANCH" | jq -Rs .),
-  "message": $(printf '%s' "docs(${SQUAD}): add ${TIPO} ${FEATURE}" | jq -Rs .),
-  "files": [
-    {
-      "path": $(printf '%s' "$DEST_PATH" | jq -Rs .),
-      "contentBase64": $(printf '%s' "$FILE_CONTENT" | jq -Rs .),
-      "action": "create"
-    },
-    {
-      "path": $(printf '%s' "$INDEX_PATH" | jq -Rs .),
-      "contentBase64": $(printf '%s' "$UPDATED_INDEX_B64" | jq -Rs .),
-      "action": $(printf '%s' "$INDEX_ACTION" | jq -Rs .)
-    }
-  ]
-}
-EOF
-
-COMMIT_RESULT=$(node --input-type=module -e "
-  import { readFileSync } from 'node:fs';
-  import { commitFiles } from 'file://${SCRIPT_DIR}/../vcs/api.js';
-  const opts = JSON.parse(readFileSync('$COMMIT_JSON', 'utf-8'));
-  const result = await commitFiles(process.env.CENTRAL_DOCS_REPO, opts);
-  console.log(JSON.stringify(result));
-" 2>&1)
-COMMIT_EXIT=$?
-rm -f "$COMMIT_JSON"
-
-if [ $COMMIT_EXIT -ne 0 ]; then
-  echo "❌ Erro ao criar commit:" >&2
-  echo "$COMMIT_RESULT" >&2
-  exit 1
-fi
-
-COMMIT_SHA=$(echo "$COMMIT_RESULT" | jq -r '.sha')
-echo "✅ Commit criado: $COMMIT_SHA"
-
-# 11. Criar MR/PR
-echo "Criando Merge/Pull Request..."
-
-MR_DESCRIPTION="## Documento
-
-- **Tipo**: ${TIPO}
-- **Workspace**: ${WORKSPACE}
-- **Feature**: ${FEATURE}"
-
-[ -n "$JIRA" ] && MR_DESCRIPTION="${MR_DESCRIPTION}
-- **Card**: ${JIRA}"
-
-[ -n "$DOC_NAME" ] && MR_DESCRIPTION="${MR_DESCRIPTION}
-- **Nome**: ${DOC_NAME}"
-
-BODY_FILE=$(mktemp)
-printf '%s' "$MR_DESCRIPTION" > "$BODY_FILE"
-
-MR_RESULT=$(node "${SCRIPT_DIR}/../vcs/create-merge.js" \
-  --repo "$CENTRAL_DOCS_REPO" \
-  --source "$BRANCH_NAME" \
-  --target "$TARGET_BRANCH" \
-  --title "docs(${SQUAD}): ${TIPO} ${FEATURE}" \
-  --body-file "$BODY_FILE" 2>&1)
-MR_EXIT=$?
-rm -f "$BODY_FILE"
-
-if [ $MR_EXIT -ne 0 ]; then
-  echo "❌ Erro ao criar MR/PR:" >&2
-  echo "$MR_RESULT" >&2
-  exit 1
-fi
-
-MR_URL=$(echo "$MR_RESULT" | tail -1 | jq -r '.url // empty')
-MR_IID=$(echo "$MR_RESULT" | tail -1 | jq -r '.iid // empty')
-
-echo ""
-echo "✅ Merge/Pull Request criado com sucesso!"
-echo ""
-echo "  #${MR_IID}: ${BRANCH_NAME} → ${TARGET_BRANCH}"
-echo "  URL: ${MR_URL}"
-echo ""
-
-# 12. Invalidar cache Redis
-redis-cli DEL "docs:${INDEX_PATH}:${TARGET_BRANCH}" >/dev/null 2>&1 || true
-redis-cli DEL "docs:${INDEX_PATH}:main" >/dev/null 2>&1 || true
-
-echo "🔄 Cache Redis invalidado"
-echo ""
-echo "✅ Publicação concluída!"

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.