NS Flow Kit — Esteira de Qualidade

Os três gates

Cada gate é determinístico: passa com exit 0 e evidência, ou bloqueia. Auto-avaliação não conta. Os thresholds vivem na qa-policy, configuráveis por severidade.

Gate 1 — Cobertura + Execução no dev (1a+1b) /run-regression

1a — Cobertura: escreve os testes (RED→GREEN) e mede a cobertura do código alterado (diff); abaixo do threshold da severidade → bloqueia e lista as linhas sem teste — ou N/A-por-ADR quando o stack não permite unit. 1b — Execução no dev/stg: o QA Plan (CTs) roda via Playwright no ambiente dev/stg (nunca HML — HML é o Gate 3), reusando o motor do qa-expert com ambiente=dev.

test-validator · estende o gate existente

Gate 2 — Smoke /smoke

Roda o caminho crítico do sistema afetado. Rápido e barato — se o fluxo principal caiu, bloqueia antes de gastar E2E.

smoke-runner · config-driven por stack

Gate 3 — E2E /validacao-testes

Valida os FEAT-{N} na UI de HML (Playwright/Voidr) com evidência visual. "Se não está na tela, não aconteceu." Alimenta o Checkpoint 3 (homologação).

qa-expert · anti-falso-positivo/negativo

Meta-gate /qa-gate

Consolida os três num veredito único. Verde libera /open-pr e /release-check; vermelho bloqueia o release.

hard stop da qa-policy

Shift-left: a qualidade nasce no discovery

O mesmo FEAT-{N} atravessa toda a esteira. No discovery, cada critério já sai testável e com a camada de gate que o cobre (DoR-for-QA). Os gates downstream só cobram o que foi definido lá.

Discovery

/qa-plan

FEAT-{N} testável + estratégia de teste por camada

Dev

Gate 1 + 2

cobertura do diff e smoke durante a implementação

Pré-deploy

Gate 3

E2E por FEAT-{N} → Checkpoint 3 (homologação)

Deploy

learning-agent

métricas + deltas para a base de qualidade

O squad de agentes

Cada agente é o runner de uma responsabilidade única. O dev os aciona; eles executam e param no que a política manda.

qa-strategist

Shift-left: transforma os FEAT-{N} em estratégia de teste por camada e checa testabilidade.

/qa-plan

test-validator

Gate 1 — 1a (Cobertura): escreve testes, roda o build gate e mede a cobertura do diff (ou N/A-por-ADR quando o stack não permite unit). Já existia — agora cobra cobertura. 1b (Execução no dev/stg): roda o QA Plan (CTs) via Playwright no ambiente dev/stg (nunca HML — HML é o Gate 3), reusando o motor do qa-expert com ambiente=dev.

/run-regression

smoke-runner

Gate 2: executa o caminho crítico e devolve veredito determinístico.

/smoke

qa-expert

Gate 3: E2E/homologação na UI com evidência. Config-driven — sem path nem credencial hardcoded.

/validacao-testes

O QA vira owner

O dev roda os gates; o QA não executa CT — ele é dono da régua e a melhora a cada sprint. Esse é o loop que faz os agentes ficarem melhores com o tempo.

dev roda os gates → learning-agent grava métricas + propõe deltas → QA owner revisa, calibra thresholds, promove regressivo → próximo ticket: gates mais precisos

Cura a base de homologação

Seletores, mensagens exatas e navegação validados em .speckit/quality/ — o "Features" unificado no Speckit.

Define os thresholds

Cobertura por severidade e escopo do smoke por sistema. Aperta conforme o legado amadurece.

Revisa o que o gate não pega

Flaky, edge cases, exploratório, UX e regra de negócio ambígua continuam com julgamento humano.

Promove regressivo

E2E estável (2+ sprints) vira cobertura permanente. Script com falha nunca é promovido.

Definições honestas

Para a robustez não ser frágil, o que "100%" significa de verdade — e onde o humano continua.

100% cobertura = do código alterado

Diff coverage, não o repo legado inteiro. Configurável por severidade.

E2E 100% = dos FEAT-{N} tocados

100% dos critérios de aceite do ticket, não 100% da UI.

Tooling é por projeto

Sem comando no bloco quality, o gate reporta "não configurado" — nunca passa silencioso.

O QA não some — vira owner

Os gates cobrem o determinístico; o exploratório e o julgamento seguem humanos.