O GSD tem quatro camadas de qualidade automáticas que funcionam em paralelo. Entenda o que cada gate verifica, quando dispara e como usá-los manualmente para diagnosticar projetos em qualquer estado.
A Nyquist Validation garante que cada funcionalidade da fase tenha ao menos um teste correspondente. O nome é uma referência ao Teorema de Nyquist: para capturar completamente um sinal, a frequência de amostragem deve ser ao menos o dobro da frequência máxima do sinal. Aqui, cada feature precisa de ao menos um test.
Fase de pesquisa
Durante /gsd:plan-phase, o agente nyquist-auditor mapeia cada funcionalidade declarada no ROADMAP e REQUIREMENTS da fase.
Geração do mapa de cobertura
Cria {fase}-VALIDATION.md com a tabela feature → test previsto, identificando gaps antecipadamente.
Verificação retroativa
Após execução, /gsd:validate-phase N audita a cobertura real vs. mapeada e cria planos de fechamento de gap.
Ativado por padrão
"nyquist_validation": true
Roda automaticamente durante /gsd:plan-phase. Para desabilitar (não recomendado): definir false no config.json.
Uso manual
/gsd:validate-phase 2
Auditoria retroativa de cobertura de testes. Útil para fases executadas antes de ativar a validação ou para fechar gaps descobertos em UAT.
Artefato produzido: {fase}-VALIDATION.md — tabela com cada funcionalidade, teste esperado, status de cobertura e gap score. Serve de entrada para /gsd:plan-phase --gaps.
O comando /gsd:health valida a integridade estrutural do diretório .planning/. Use sempre que suspeitar de corrupção, após migração de repos ou antes de compartilhar o projeto com outro dev.
Sintaxe
/gsd:health # Verifica integridade
/gsd:health --repair # Verifica e corrige automaticamente| Verificação | O que checa | Reparável? |
|---|---|---|
| STATE.md | Fase atual, status e checkpoints consistentes | Sim |
| ROADMAP.md | Formato válido, fases numeradas corretamente | Sim |
| Artefatos de fase | PLAN.md, SUMMARY.md, VERIFICATION.md presentes para fases executadas | Parcial |
| config.json | Schema válido, sem chaves desconhecidas | Sim |
| Locks | Arquivos .lock órfãos de execuções interrompidas | Sim |
| Git worktrees | Worktrees pendentes de fases concluídas | Sim |
Quando usar
/gsd:execute-phase/gsd:autonomous em projeto antigo/gsd:next reportar estado inconsistenteO /gsd:debug invoca o agente gsd-debugger, que investiga bugs pelo método científico. Diferente de um debugging ad-hoc, o estado persiste entre resets de contexto — o agente retoma de onde parou.
Exemplo de uso
/gsd:debug "Login não responde no Safari mobile"
/gsd:debug "API retorna 500 em produção mas não local"Persistência entre sessões
O DEBUG.md gerado persiste em .planning/. Se você interromper e retomar o Claude Code, o agente retoma a investigação a partir do estado salvo — hipóteses, evidências e teorias já eliminadas não se perdem.
O Cross-Phase Regression Gate detecta quando uma fase executada quebra algo que funcionava em fases anteriores. É ativado automaticamente ao final de cada /gsd:execute-phase e pode ser auditado manualmente via /gsd:audit-uat.
Automático (por fase)
O verificador pós-execução compara os critérios de aceitação de fases anteriores com o estado atual do código.
Artefato: {fase}-VERIFICATION.md
Manual (cross-phase)
/gsd:audit-uat gera auditoria cruzada de todos os itens UAT e verificação pendentes em todas as fases.
Artefato: relatório categorizado com plano de teste humano
Quando o verificador encontra falhas pós-execução, o node repair tenta corrigir automaticamente antes de escalar para o humano.
// config.json
{
"workflow": {
"node_repair": true,
"node_repair_budget": 2 // máximo de tentativas por task
}
}Com node_repair_budget: 2, o executor tenta reparar cada task falha até 2 vezes antes de marcar como requer intervenção humana.
Resumo dos 4 Quality Gates