Ir para o conteúdo

Small Improvement Flow
Tipo Melhoria pequena (task, P3/P4 sem bug confirmado)
Trigger /analyze-bug <ticket>
Diferença do Bug Flow Processo mais leve; release-check não é obrigatório para P4
Checkpoints humanos 3 (sem release-check obrigatório para P4)

Pré-requisito: instalação concluída — ver 00 — Instalação e Setup.

1. O que é e quando usar

Versão enxuta do Bug Flow para mudanças leves e bem delimitadas.

Use quando: - Melhorias de UX sem impacto em lógica de negócio - Refactoring localizado com escopo bem definido - Ajustes de configuração ou parâmetros - Adição de logging ou monitoramento - Correções de texto, labels, traduções

Não use quando: a mudança afeta lógica de negócio, banco de dados ou integrações → use o Bug Flow.

Qualidade: mesmo no fluxo leve, vale o Gate 1 (1a cobertura do diff + 1b execução no dev) via /run-regression. Smoke/E2E são recomendados conforme o risco — ver Quality Layer. Para P4 trivial (texto/label), o owner pode dispensar E2E no qa-plan.

2. Visão geral do fluxo

/analyze-bug
    └── bug-investigator     → BugReport (+ ImpactReport)
             ↓
    ⚡ CHECKPOINT 1 — humano confirma escopo
             ↓
/generate-fix
    └── builder-agent        → PatchBundle
             ↓
    ⚡ CHECKPOINT 2 — humano revisa
             ↓
/run-regression              (se houver testes relacionados)
             ↓
/open-pr
             ↓
    ⚡ CHECKPOINT 3 — PR aprovado
             ↓
    [deploy — sem release-check obrigatório para P4]
             ↓
    learning-agent           → atualiza Speckit se gerou aprendizado

3. Passo a passo

Passo 1 — BugReport (escopo)

O bug-investigator gera um BugReport (e o /analyze-bug padrão também gera um ImpactReport). Para uma Small Improvement, use o BugReport como “escopo aprovado”: - O que será alterado e por quê - O que está fora do escopo (explicitamente) - Riscos de regressão - Estimativa de complexidade: Simples | Média | Complexa

Se complexidade for Complexa → mude para o Bug Flow completo com architecture-agent. Output: .ns-flow/analysis/<ticket>-bugreport.md

Passo 2 — Patch

O builder-agent segue as mesmas regras do Bug Flow: Minimum Viable Patch, políticas de segurança, sem refactoring além do escopo.

Passo 3 — PR

PR mais simples — sem rollback plan elaborado para P4. Para P3, rollback plan ainda é recomendado.

4. Quando escalar para o Bug Flow

Pare e mude para o Bug Flow se, ao investigar: - O agente encontra um bug real (não apenas melhoria) - A mudança passa a afetar banco de dados - A mudança passa a afetar integrações externas - O architecture-agent sinaliza risco alto

5. Checkpoints humanos

# Quando Quem aprova Verifica
1 Após BugReport Dev/TL Escopo claro? Fora-de-escopo explícito? Complexidade ≠ Complexa?
2 Após patch Dev/Reviewer Patch mínimo? Sem scope creep?
3 No PR Reviewer Mudança corresponde ao escopo aprovado?

6. Pastas e arquivos gerados

Etapa Arquivo
Escopo .ns-flow/analysis/<ticket>-bugreport.md (+ .ns-flow/analysis/<ticket>-impact.md, se necessário)
Patch .ns-flow/delivery/<ticket>-patch.md
Validação (se houver testes) .ns-flow/delivery/<ticket>-validation.md
PR .ns-flow/delivery/<ticket>-pr-description.md
Encerramento (se gerou aprendizado) atualizações em .speckit/

7. Aplicação pelo time (papéis)

Papel Responsabilidade
Dev Dispara /analyze-bug; confirma escopo (CP1); gera patch (CP2)
Reviewer Aprova o PR (CP3)

Mais leve por design: ideal para o backlog de P3/P4 sem sobrecarregar o time com checkpoints de release. Mas a régua de Minimum Viable Patch continua valendo.

Referências

Voltar ao topo