SkillEngenhariaDiagnostica
Registro de Riscos e Guardrails
Identifica invariantes de negócio, dados sensíveis e fluxos intocáveis, e define guardrails que impedem regressão durante a refatoração.
Ações
PerfilDev
ProfundidadeAlta
Idiomapt-BR
Objetivo
Em uma frase.
Produzir um registro formal de riscos da refatoração e uma lista de guardrails técnicos que devem existir antes, durante e depois de cada mudança — transformando "sabemos que é arriscado" em um inventário concreto de o que pode dar errado, qual é o impacto e como se proteger.
Aplicação
Quando
faz sentido.
Usar
- Como Etapa 4 do workflow de Diagnóstico de Dívida Técnica Crítica, após análise de complexidade.
- Como Etapa 4 do workflow de Planejamento de Refatoração, para definir critérios de aceitação e guardrails por fatia.
- Quando o time quer refatorar mas tem medo justificado de quebrar o sistema em produção.
- Quando há dados financeiros, médicos ou pessoais (LGPD/GDPR) no módulo e qualquer regressão tem impacto legal.
Não usar
- Para risk assessment de features novas — esta skill é sobre riscos de mudar código existente.
- Quando o módulo não toca fluxos de negócio críticos e não processa dados sensíveis — o risco pode ser gerido informalmente.
Prompt
Instruções
para a IA.
Passo 1 — Identificar invariantes de negócio
Invariantes são condições que NUNCA podem deixar de ser verdadeiras, independentemente de qualquer refatoração:
- **Invariantes financeiras:** "Toda transação aprovada deve gerar um registro de pagamento." "Saldos nunca podem ficar negativos sem autorização de crédito."
- **Invariantes de dados:** "E-mails de usuário são únicos." "Pedidos concluídos não podem ser editados."
- **Invariantes de fluxo:** "Após autenticação, o token tem validade de X horas." "Notificações de pagamento devem ser enviadas em até 5 minutos."
- **Invariantes regulatórias:** "Dados pessoais devem ser anonimizáveis." "Logs de auditoria não podem ser apagados."Para cada invariante: descrever a condição, onde no código ela é garantida atualmente e qual seria o impacto de violá-la.
Passo 2 — Mapear dados sensíveis e zonas de risco
Identificar onde dados sensíveis fluem pelo módulo:
- **PII (Personally Identifiable Information):** Nomes, e-mails, CPFs, endereços.
- **Dados financeiros:** Números de cartão, saldos, transações.
- **Credenciais:** Tokens, API keys, senhas (mesmo que hasheadas).
- **Dados de saúde:** Se aplicável (HIPAA).Para cada tipo de dado: em quais componentes ele aparece, como é protegido hoje (criptografia, masking, access control) e qual é o risco se a refatoração expor ou corromper esse dado.
Passo 3 — Classificar riscos por impacto e probabilidade
Para cada risco identificado, classificar sistematicamente:
| Risco | Impacto | Probabilidade | Risco Calculado |
|-------|---------|---------------|-----------------|
| ... | 1-5 | 1-5 | I × P |**Impacto:** - 5 = Perda de dados, violação regulatória, indisponibilidade total - 4 = Degradação severa de funcionalidade para muitos usuários - 3 = Bug visível com workaround possível - 2 = Degradação menor, poucos usuários afetados - 1 = Impacto cosmético ou apenas interno
**Probabilidade:** - 5 = Quase certo (mudança toca diretamente o código que garante a invariante) - 4 = Provável (mudança é adjacente ao código crítico) - 3 = Possível (dependência indireta) - 2 = Improvável (proteções existem mas não são testadas) - 1 = Raro (múltiplas camadas de proteção)
Riscos com score ≥ 15 exigem mitigação obrigatória antes de qualquer mudança.
Passo 4 — Definir guardrails técnicos
Para cada categoria de risco, definir guardrails que devem existir antes de iniciar a refatoração:
**Guardrails de teste:**
- Testes de integração que cobrem os fluxos críticos (end-to-end).
- Testes de contrato para APIs consumidas e expostas.
- Testes de regressão automatizados para invariantes de negócio.
- Snapshot ou golden-file tests para saídas críticas.**Guardrails de monitoria:** - Alertas de anomalia em métricas-chave (latência, error rate, throughput). - Dashboards de comparação antes/depois disponíveis. - Logging estruturado nos pontos de decisão do módulo.
**Guardrails de rollback:** - Feature flags para isolar a mudança. - Blue-green ou canary deployment configurado. - Procedimento de rollback documentado e testado. - Backup de dados quando aplicável.
**Guardrails de processo:** - Aprovação de code review por engenheiro sênior para cada PR da refatoração. - Validação em staging com dados representativos antes de produção. - Janela de deploy definida (fora de pico, fora de freezes).
Passo 5 — Produzir registro de riscos consolidado
```
## Registro de Riscos — [Nome do Módulo]Invariantes de Negócio
| # | Invariante | Onde é garantida | Impacto de violação | |---|-----------|------------------|---------------------| | 1 | ... | ... | ... |Dados Sensíveis
| Tipo | Componentes | Proteção atual | Risco na refatoração | |------|-------------|---------------|---------------------| | ... | ... | ... | ... |Matriz de Riscos
| # | Risco | Impacto | Probabilidade | Score | Mitigação | |---|-------|---------|---------------|-------|-----------| | 1 | ... | ... | ... | ... | ... |Guardrails Requeridos
| Categoria | Guardrail | Status atual | Ação necessária | |-----------|-----------|-------------|-----------------| | Teste | ... | ✅/❌ | ... | | Monitoria | ... | ✅/❌ | ... | | Rollback | ... | ✅/❌ | ... | | Processo | ... | ✅/❌ | ... | ```---
Constelação
Onde
ela vive.
Workflows que usam
Bundles que incluem