Ir para o conteúdo

Smoke Test Guide — NS Flow Kit v1.2

Guia de validação manual para os 3 capabilities adicionados na v1.2 (Orchestrator, Health Monitor, Parallel Flow).

Execute em qualquer projeto que já tenha o NS Flow Kit instalado via npx.

Pré-requisito

# Confirmar que o kit está instalado no projeto alvo
ls .claude/agents/orchestrator-agent.md     # deve existir
ls .claude/agents/health-monitor-agent.md   # deve existir
ls .claude/commands/manage-queue.md          # deve existir
ls .claude/commands/health-check.md          # deve existir

Se algum arquivo não existir, rode npx @nstechhub/corporate-ns-flow-kit no projeto para atualizar.

Cenário A — /manage-queue (Orchestrator)

Setup

No diretório raiz do projeto alvo, crie dois state files de teste:

mkdir -p .ns-flow/state

cat > .ns-flow/state/ADO-TEST-001-state.md << 'EOF'
# State — ADO-TEST-001
**Fase atual:** analysis
**Severidade:** P2
**Sistema:** CITWEB
**Módulos afetados:** Faturamento, NotaFiscal
**Iniciado em:** 2026-05-17
**Bloqueadores ativos:** nenhum
EOF

cat > .ns-flow/state/ADO-TEST-002-state.md << 'EOF'
# State — ADO-TEST-002
**Fase atual:** delivery
**Severidade:** P1
**Sistema:** CITWEB
**Módulos afetados:** Faturamento
**Iniciado em:** 2026-05-16
**Bloqueadores ativos:** nenhum
EOF

Executar

claude
/manage-queue

Critérios de aceite

  • [ ] Gera .ns-flow/orchestration/queue-{DATA}.md
  • [ ] ADO-TEST-002 (P1, delivery) aparece antes de ADO-TEST-001 (P2, analysis) no backlog
  • [ ] Conflito no módulo Faturamento é detectado e classificado como BLOQUEANTE
  • [ ] Checkpoint é apresentado com lista de ações pendentes antes de encerrar
  • [ ] Não executa nenhum fix, investigação ou código — apenas coordena

Limpeza

rm .ns-flow/state/ADO-TEST-001-state.md
rm .ns-flow/state/ADO-TEST-002-state.md

Cenário B — /health-check (Health Monitor)

Teste 1 — Classificação 🔴 CRÍTICO

Execute o comando abaixo e cole o bloco de log junto na mesma mensagem ao agente:

/health-check CITWEB

Log extraído do sistema CITWEB — 2026-05-17 09:00:
ERROR 500: NullReferenceException em FaturamentoService.cs linha 142
ERROR 500: NullReferenceException em FaturamentoService.cs linha 142
ERROR 500: NullReferenceException em FaturamentoService.cs linha 142
Taxa de erro: 8% nos últimos 15 minutos (baseline normal: < 1%)
Latência p95: 4200ms (baseline normal: ~800ms)
Restarts do processo: 0

Critérios de aceite: - [ ] Classifica o sistema como 🔴 CRÍTICO (8% > threshold padrão de 5%) - [ ] Identifica latência degradada como sinal adicional - [ ] Recomenda acionar critical-incident-flow - [ ] Gera .ns-flow/monitoring/health-CITWEB-{DATA}.md - [ ] Apresenta Checkpoint antes de escalar — aguarda confirmação humana

Teste 2 — Classificação 🟢 NORMAL

/health-check CITWEB

Métricas CITWEB — 2026-05-17 14:00:
Taxa de erro: 0.1% (normal)
Latência p95: 750ms (normal)
Uptime: 99.98%
Sem restarts no período
Sem exceções relevantes nos logs

Critérios de aceite: - [ ] Classifica o sistema como 🟢 NORMAL - [ ] Gera .ns-flow/monitoring/health-CITWEB-{DATA}.md - [ ] Não apresenta Checkpoint — encerra sem solicitar ação - [ ] Sugere cadência de próxima verificação

Teste 3 — Classificação 🟠 ALTO

/health-check CITWEB

Métricas CITWEB — 2026-05-17 11:00:
Taxa de erro: 3% (acima do normal de 0.5%)
Latência p95: 1800ms (normal: ~800ms)
Warnings: timeout em chamadas ao serviço de NF-e (3 ocorrências)
Sem restarts

Critérios de aceite: - [ ] Classifica como 🟠 ALTO (3% > threshold 2%, mas < 5%) - [ ] Recomenda abrir /analyze-bug CITWEB como P2 - [ ] Apresenta Checkpoint antes de escalar

Cenário C — Revisão manual do parallel-flow.md

Este workflow não tem command próprio — é um protocolo de coordenação. A validação é leitura crítica.

Abra .claude/workflows/parallel-flow.md e verifique:

  • [ ] A seção ## Pré-requisito Obrigatório deixa claro que /manage-queue é necessário antes de paralelo?
  • [ ] As regras de lock para arquivos de código (risco ALTO no risk-map) estão não-ambíguas?
  • [ ] As regras de lock para migrations de banco (bloqueante por schema) estão claras?
  • [ ] As regras para interfaces públicas (ATENÇÃO, não BLOQUEANTE) estão distintas das anteriores?
  • [ ] Os anti-padrões ao final cobrem os casos de conflito mais comuns?
  • [ ] O Checkpoint de Merge descreve claramente quando pausar antes do /open-pr?
  • [ ] A seção ## Quando o Paralelo Não Vale a Pena está presente?

Resultado esperado antes da PR

Check Resultado
npm test (validate-kit.sh) ✅ exit 0, todos PASS
Cenário A — /manage-queue ✅ todos os critérios atendidos
Cenário B — 🔴 CRÍTICO ✅ classificação correta + Checkpoint
Cenário B — 🟢 NORMAL ✅ classificação correta + sem Checkpoint
Cenário B — 🟠 ALTO ✅ classificação correta + Checkpoint
Cenário C — parallel-flow.md ✅ todos os itens da checklist

Todos verdes → abrir PR.

Voltar ao topo