Eixo vertical
Rigor — quanta cerimônia
Lean, Standard ou Strict. Calibra a profundidade da análise, quantas lentes o review usa e quais verificações entram — pelo risco do que está em jogo.
Metodologia e rigor
Trocar um rótulo de botão e reescrever o motor de cobrança não merecem a mesma cerimônia. E um time que fala em sprint e story points não deveria ter que traduzir tudo para adotar uma ferramenta. O Spaccy tem dois controles para isso, e eles são independentes.
Eixo vertical
Lean, Standard ou Strict. Calibra a profundidade da análise, quantas lentes o review usa e quais verificações entram — pelo risco do que está em jogo.
Eixo horizontal
Standard, Agile ou Enterprise. Troca o vocabulário, os artefatos, o agrupamento e a tela que o cockpit abre — para bater com o processo que o time já roda.
São ortogonais: um time ágil pode subir para Strict numa feature de pagamento sem deixar de falar em story e sprint. Escolher um não amarra o outro.
O eixo vertical
O mesmo conjunto de comandos, com mais ou menos profundidade. Cada nível contém o anterior — subir nunca troca uma verificação por outra, só acrescenta.
CRUD, ajuste, correção de baixo risco
O essencial e nada mais: a intenção, os critérios de aceitação e o review estrutural. As seções de análise profunda, matriz de risco e verificação cruzada ficam de fora — não porque não importam, mas porque para trocar um label elas custam mais do que valem.
O trabalho do dia a dia
O equilíbrio padrão: proposta completa, especificação com invariantes e rastreabilidade, review em três lentes independentes — estrutural, caçador de casos-limite e detector de lacuna de verificação. É o nível em que a maioria das features nasce.
Pagamento, dado sensível, o que não pode falhar
Tudo do Standard mais a lente adversarial: o revisor assume que o código está errado e tenta provar. Para cada critério de aceitação, procura o caminho que o viola. Entram também as seções de ameaça, privacidade e rastreabilidade completa requisito → teste.


O eixo horizontal
Metodologia não é um tema de cores: muda o comando com que você especifica, o nome de cada artefato, o que é agrupado por quê e a tela em que o cockpit abre. Tudo isso é configuração — nenhuma linha do produto muda.
| Aspecto | Standard | Agile | Enterprise |
|---|---|---|---|
| Você especifica com | /proposal | /story | /proposal |
| A unidade se chama | Feature · Fase | Story · Incremento | RFC · Work item |
| Agrupamento temático | Tema (desligado) | Epic | Capability |
| Agrupamento temporal | Milestone | Sprint (2 semanas) | Program Increment |
| Backlog priorizado por | — (desligado) | MoSCoW | WSJF |
| Estimativa | — (desligada) | Story points (Fibonacci) | Esforço (camiseta) |
| O cockpit abre em | Lista | Kanban + velocidade | Rastreabilidade + compliance |
| Rigor que vem junto | Standard | Lean | Strict |
Cada metodologia é um arquivo de configuração que herda de outra e liga ou desliga papéis — criar a sua custa um arquivo, não um fork. O rigor da última linha é apenas o ponto de partida: os dois eixos continuam independentes.
O que muda para o time
Num time ágil o painel abre em kanban, com velocidade e story points; num time enterprise, em matriz de rastreabilidade e compliance. Não é tema visual: é a unidade de trabalho, o agrupamento e a métrica mudando junto. Ninguém precisa traduzir "fase" para "sprint" de cabeça na reunião.
O que o time já chama de story continua story — nos artefatos, no cockpit e nos comandos. Adotar o Spaccy deixa de custar uma migração de linguagem, que é onde a maioria das ferramentas de processo morre: o time volta ao vocabulário antigo em duas semanas e a ferramenta vira teatro.
A daily sai pronta do repositório — ontem, hoje e bloqueios lidos do git e do histórico, não da memória de cada um. Uma incerteza técnica vira experimento com prazo fechado, que reporta o achado e não gera especificação nenhuma. O ritual deixa de depender de quem lembrou de preparar.
/standup/spike
O nível de rigor tem três camadas de configuração: o padrão do produto, a convenção do time — versionada em git, revisada em code review como qualquer arquivo — e a sua preferência pessoal, que fica na sua máquina e não vai para o repositório. Discordar do time não exige convencer o time.
O que muda para os agentes de IA
A dosagem não é um pedido educado ao modelo — é a instrução que ele recebe mudando de tamanho. O agente não decide o próprio rigor.
Não existe uma versão ágil e outra enterprise de cada comando para manter em sincronia — existe uma, com cada seção marcada pelo nível em que entra. Subir ou descer o rigor liga e desliga trechos da mesma instrução. É o que evita o destino comum desse tipo de sistema: três variantes divergindo em silêncio até nenhuma estar certa.
Strict contém Standard, que contém Lean. Subir o rigor só acrescenta — nunca troca uma verificação por outra. Você pode subir o nível de uma feature crítica sabendo que nada que já era verificado deixou de ser.
A especificação — venha de uma proposta formal ou de uma user story — emite o mesmo contrato de intenção. O resto do caminho (especificar, implementar, revisar) lê o contrato e não sabe de qual origem veio. É por isso que a metodologia é um arquivo de configuração e não um fork do produto.
Seis motores são imunes ao nível de rigor: os que rotacionam histórico, reorganizam módulos, preparam ambiente, criam branch de sessão e removem código obsoleto. São exatamente os que escrevem por cima de trabalho existente — neles, "mais leve" significaria "sem a verificação que impede perda". Rigor dosa cerimônia, nunca segurança.
Os dois eixos vêm configurados em Standard — se você não mexer em nada, é isso que roda. Peça acesso antecipado e ajuste quando o trabalho pedir.