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.

Planning Gate

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

{
  "requirePlanningReview": true,
  "readinessThreshold": 70,
  "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.

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": 70,
  "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 70. 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