Padrões de Qualidade

Configure gates de revisão, limites de prontidão e requisitos de qualidade para suas especificações.

O SpecForge garante qualidade através de gates de revisão configuráveis em dois checkpoints: Planning Review (antes da implementação começar) e Implementation Review (depois que todos os tickets são completados). Você controla quão rigorosos esses gates são através da configuração de qualidade do projeto.

Configure padrões de qualidade pela página Settings > Quality Standards no painel, ou via CLI e ferramentas MCP.

Como o Processo de Review Funciona

Quando você ou seu agente roda um review (review_planning ou review_implementation), o SpecForge avalia a especificação contra múltiplas dimensões de scoring. Cada dimensão produz um score de 0 a 100. O score geral é a média ponderada.

Se o score atinge ou excede o threshold: a especificação avança para a próxima fase (planning → ready, implementation → completed).

Se o score está abaixo do threshold: o review produz findings específicos — quais tickets estão sem critérios de aceitação, quais dependências estão quebradas, quais arquivos não foram entregues. Você endereça os findings e roda o review novamente.

Se maxReviewAttempts é excedido: o review para e requer intervenção manual. Isso previne loops infinitos em especificações fundamentalmente falhas.

As seções abaixo configuram os thresholds, gates e requisitos de evidência para cada checkpoint de review.

Planning Gate

O Planning Gate avalia se uma especificação está pronta para implementação.

{
  "requirePlanningReview": true,
  "readinessThreshold": 80,
  "epicVerificationSeverity": "error",
  "requireBlueprintCoverage": true,
  "requireDependencyValidation": true,
  "maxFeatureTestRatio": 3
}

Opções

✅ Comece com os padrões. Eles representam um equilíbrio entre rigor e velocidade. Aumente os limites conforme sua equipe ganha confiança com o fluxo de trabalho.

Config do Planning ↔ Dimensões de Scoring

Cada opção de configuração controla quais dimensões de scoring estão ativas e quão estritamente são aplicadas:

🔬 Para engenheiros: Estes são os parâmetros de tuning do loop de controle do planning descrito em Fundamentos de Engenharia. readinessThreshold é a largura da zona de aceitação. maxReviewAttempts é a parada de segurança. Aumentar o threshold aperta a tolerância — o sistema requer menos desvio da spec ideal antes de passar.

Implementation Gate

O Implementation Gate avalia o trabalho completado contra a especificação original.

{
  "requireImplementationReview": true,
  "gates": {
    "steps": true,
    "acceptance_criteria": true,
    "file_delivery": true,
    "git_evidence": true,
    "tests": true
  },
  "gitEvidence": "required",
  "testEvidence": "summary",
  "maxReviewAttempts": 3
}

Opções

Detalhes dos Gates

Cada gate no objeto gates controla uma verificação específica de qualidade durante o Implementation Review:

⚠️ Desabilitar gates reduz a cobertura do review. Se você desabilitar acceptance_criteria, o review não verificará se tickets realmente atendem seus requisitos declarados. Desabilite deliberadamente, não casualmente.

Modos de Evidência Git

Modos de Evidência de Teste

Perfis de Configuração

Diferentes situações pedem diferentes configurações de qualidade. Aqui estão configurações comuns:

Prototipagem

Velocidade importa mais que cerimônia. Limites menores, desabilitar evidência git, pular cobertura de blueprint.

{
  "requirePlanningReview": true,
  "readinessThreshold": 60,
  "requireBlueprintCoverage": false,
  "requireImplementationReview": true,
  "gates": {
    "steps": true,
    "acceptance_criteria": true,
    "file_delivery": true,
    "git_evidence": false,
    "tests": false
  },
  "gitEvidence": "none",
  "testEvidence": "summary",
  "maxReviewAttempts": 5
}

Por que manter o Planning Review habilitado mesmo para protótipos? Porque uma decomposição ruim desperdiça mais tempo do que um review rápido custa. Baixar o limite para 60 permite passar com planos mais brutos enquanto ainda captura dependências circulares e épicos vazios.

Desenvolvimento Padrão

Os padrões. Equilibrado entre rigor e velocidade. Bom para equipes começando com o SpecForge.

{
  "requirePlanningReview": true,
  "readinessThreshold": 80,
  "requireBlueprintCoverage": true,
  "requireDependencyValidation": true,
  "requireImplementationReview": true,
  "gitEvidence": "required",
  "testEvidence": "summary",
  "maxReviewAttempts": 3
}

Nível Produção

Máximo rigor. Limites mais altos, evidência de teste mais rigorosa, proporção feature-para-teste menor. Use para especificações que serão entregues a usuários.

{
  "requirePlanningReview": true,
  "readinessThreshold": 85,
  "epicVerificationSeverity": "error",
  "requireBlueprintCoverage": true,
  "requireDependencyValidation": true,
  "maxFeatureTestRatio": 2,
  "requireImplementationReview": true,
  "gates": {
    "steps": true,
    "acceptance_criteria": true,
    "file_delivery": true,
    "git_evidence": true,
    "tests": true
  },
  "gitEvidence": "required",
  "testEvidence": "discretized",
  "maxReviewAttempts": 3
}

A diferença-chave: readinessThreshold: 85 captura planos marginais que passariam raspando com 80. testEvidence: "discretized" mostra resultados individuais de teste para revisores identificarem cobertura fraca. maxFeatureTestRatio: 2 exige mais tickets de teste relativos a tickets de feature.

Autônomo em Escala

Para especificações grandes (20+ épicos, 100+ tickets) rodando com Agent Teams. Confie na estrutura, verifique o output.

{
  "requirePlanningReview": true,
  "readinessThreshold": 90,
  "requireBlueprintCoverage": true,
  "maxFeatureTestRatio": 2,
  "requireImplementationReview": true,
  "gitEvidence": "required",
  "testEvidence": "verbose",
  "maxReviewAttempts": 5
}

Nessa escala, o limite de planejamento é crítico — um problema estrutural em 100 tickets é exponencialmente mais caro para corrigir pós-implementação do que em 10 tickets. testEvidence: "verbose" dá output completo para debugging de falhas. maxReviewAttempts: 5 dá mais espaço porque specs grandes têm mais probabilidade de precisar de iteração.

Configurando via CLI

Veja a configuração atual:

specforge configure reviewConfig

Defina valores individuais:

# Aumentar o limite do planning
specforge configure reviewConfig.readinessThreshold 85
 
# Desabilitar evidência git para prototipagem
specforge configure reviewConfig.gates.git_evidence false
 
# Mudar nível de evidência de teste
specforge configure reviewConfig.testEvidence verbose

📖 Padrões de qualidade se aplicam no nível do projeto. Todas as especificações dentro de um projeto compartilham a mesma configuração de review. Para o schema completo de configuração, veja Schema de Configuração.

Veja Também

• Gates de Qualidade — Como gates avaliam especificações e o que cada dimensão de pontuação significa
• Schema de Configuração — Referência completa de schema para todos os arquivos de configuração
• Ciclos de Vida — Onde gates se encaixam nos três ciclos