Modo de Restrição Avançada de Agente RIPER-5 para Cursor
RIPER-5 é um framework de restrições criado pela comunidade que tem se mostrado reduzir drasticamente as alucinações de IA e modifica ções de código não autorizadas. Originalmente projetado para Claude 3.7, funciona excepcionalmente bem com o modo Agente do Cursor. Este guia explica as cinco fases e como implementá-las.
O que é RIPER-5?
RIPER-5 significa:
| Fase | Nome | Propósito |
|---|---|---|
| R | Research (Pesquisa) | Coletar informações sem fazer alterações |
| I | Identify (Identificar) | Identificar exatamente o problema ou requisito |
| P | Plan (Planejar) | Criar um plano detalhado e aprovado |
| E | Execute (Executar) | Implementar APENAS o plano aprovado |
| R | Review (Revisar) | Verificar e testar a implementação |
As Cinco Fases em Detalhe
Fase 1: Pesquisa (R)
Regra: Somente leitura. Nenhuma modificação de arquivo permitida.
Ações:
- Ler arquivos relevantes
- Pesquisar codebase com Grep
- Analisar padrões existentes
- Entender dependências
Saída: Resumo de pesquisa com descobertas
## Fase de Pesquisa Concluída
### Arquivos Analisados
- `src/auth/login.ts` - Fluxo de autenticação atual
- `src/middleware/auth.ts` - Verificação JWT
- `tests/auth.test.ts` - Testes existentes
### Descobertas Principais
1. Autenticação usa JWT com expiração de 15 min
2. Nenhum mecanismo de token de atualização existe
3. Redefinição de senha não implementada
4. Testes cobrem login mas não casos extremos
### Dependências
- jsonwebtoken: ^9.0.0
- bcrypt: ^5.1.0
Fase 2: Identificar (I)
Regra: Definir a declaração exata do problema.
Ações:
- Declarar o problema claramente
- Definir critérios de aceitação
- Identificar restrições
- Anotar riscos potenciais
Saída: Documento de definição do problema
## Identificação do Problema
### Declaração do Problema
Os usuários são desconectados após 15 minutos e devem se reautenticar.
Isso cria uma UX ruim para sessões de longa duração.
### Causa Raiz
Tokens JWT expiram após 15 minutos sem mecanismo de atualização.
### Critérios de Aceitação
- [ ] Usuários permanecem logados por 7 dias
- [ ] Tokens de atualização são rotacionados a cada uso
- [ ] Tokens de atualização antigos são invalidados
- [ ] Usuários podem revogar todas as sessões
### Restrições
- Deve manter compatibilidade retroativa
- Sem mudanças quebradoras na API existente
- Deve funcionar com middleware JWT existente
### Riscos
- Roubo de token se tokens de atualização forem comprometidos
- Armazenamento em banco de dados para rastreamento de tokens
Fase 3: Planejar (P)
Regra: Criar um plano detalhado, passo a passo.
Ações:
- Listar todos os arquivos a modificar
- Especificar mudanças exatas por arquivo
- Definir estratégia de teste
- Planejar procedimento de reversão
Saída: Plano de implementação detalhado
## Plano de Implementação
### Arquivos a Modificar
#### 1. `src/models/refresh-token.ts` (NOVO)
```typescript
// Esquema para tokens de atualização
// Campos: id, userId, token, createdAt, expiresAt, revoked
2. src/services/auth.ts (MODIFICAR)
- Adicionar função
createRefreshToken() - Adicionar função
rotateRefreshToken() - Adicionar função
revokeAllUserTokens()
3. src/routes/auth.ts (MODIFICAR)
- Adicionar endpoint POST
/refresh - Adicionar endpoint POST
/revoke
4. src/middleware/auth.ts (MODIFICAR)
- Atualizar verificação JWT para suportar sessões mais longas
Plano de Teste
- Testes unitários para rotação de tokens
- Testes de integração para fluxo de atualização
- Testes de segurança para revogação de tokens
Plano de Reversão
- Remover modelo de token de atualização
- Reverter mudanças no serviço de autenticação
- Remover novos endpoints
### Fase 4: Executar (E)
**Regra**: Implementar APENAS o que foi planejado.
**Ações**:
- Fazer mudanças planejadas
- Seguir o plano exatamente
- Reportar progresso após cada arquivo
- Parar se o plano precisar de revisão
**Saída**: Implementação com acompanhamento de progresso
```markdown
## Fase de Execução
### Progresso
- [x] Criado `src/models/refresh-token.ts`
- [x] Modificado `src/services/auth.ts`
- [ ] Modificar `src/routes/auth.ts` (em andamento)
- [ ] Atualizar `src/middleware/auth.ts`
### Mudanças Feitas
1. Adicionado modelo RefreshToken com campos
2. Implementada lógica de rotação de tokens
3. Adicionado suporte a revogação
### Próximos Passos
- Adicionar endpoint de atualização
- Atualizar middleware
Fase 5: Revisar (R)
Regra: Verificar se tudo funciona como planejado.
Ações:
- Executar todos os testes
- Verificar regressões
- Verificar critérios de aceitação
- Documentar quaisquer desvios
Saída: Relatório de revisão
## Fase de Revisão
### Testes
- [x] Testes unitários passaram (15/15)
- [x] Testes de integração passaram (8/8)
- [x] Testes de segurança passaram (5/5)
### Critérios de Aceitação
- [x] Usuários permanecem logados por 7 dias
- [x] Tokens de atualização são rotacionados a cada uso
- [x] Tokens de atualização antigos são invalidados
- [x] Usuários podem revogar todas as sessões
### Regressões
- Nenhuma detectada
### Desvios do Plano
- Adicionado job cron de limpeza de tokens (não no plano original)
- Razão: Previne inchaço do banco de dados por tokens expirados
Configurando RIPER-5 no Cursor
Passo 1: Criar o Arquivo de Regras
Crie .cursor/rules/riper5-mode.mdc:
---
description: 'Modo de restrição avançado RIPER-5'
globs: ['**/*']
alwaysApply: true
---
# Modo RIPER-5
Você DEVE seguir o workflow RIPER-5 para TODAS as tarefas.
## Sequência de Fases
1. **Pesquisa** - Ler e analisar apenas
2. **Identificar** - Definir o problema
3. **Planejar** - Criar plano detalhado
4. **Executar** - Implementar apenas o plano
5. **Revisar** - Verificar e testar
## Regras das Fases
### Fase de Pesquisa
- Usar apenas ferramentas Read, Grep, Search
- SEM modificações de arquivo
- SEM geração de código
- Apresentar descobertas em formato estruturado
### Fase de Identificação
- Declarar problema claramente
- Definir critérios de aceitação
- Listar restrições
- Identificar riscos
### Fase de Planejamento
- Listar TODOS os arquivos a modificar
- Mostrar mudanças exatas para cada arquivo
- Incluir estratégia de teste
- Incluir plano de reversão
- AGUARDAR aprovação do usuário
### Fase de Execução
- Implementar APENAS mudanças planejadas
- Reportar após cada arquivo
- Pedir esclarecimento se travar
- SEM modificações não planejadas
### Fase de Revisão
- Executar todos os testes
- Verificar critérios de aceitação
- Verificar regressões
- Documentar desvios
## CRÍTICO
- NUNCA pular fases
- NUNCA modificar arquivos na fase de Pesquisa
- NUNCA adicionar mudanças não planejadas na fase de Execução
- SEMPRE obter aprovação antes da fase de Execução
Passo 2: Adicionar ao Prompt do Sistema
Nas Configurações do Cursor:
## Workflow RIPER-5
Para cada tarefa, você DEVE seguir estas 5 fases:
1. **Pesquisa**: Ler e analisar sem mudanças
2. **Identificar**: Definir o problema exato
3. **Planejar**: Criar plano de implementação detalhado
4. **Executar**: Implementar APENAS o plano aprovado
5. **Revisar**: Verificar se tudo funciona
Você não pode prosseguir para a próxima fase sem completar a atual.
Você não pode modificar arquivos durante as fases de Pesquisa ou Identificação.
Você não pode adicionar mudanças não planejadas durante a fase de Execução.
Passo 3: Praticar com uma Tarefa Simples
Comece com uma tarefa pequena para se familiarizar:
[Tarefa] Adicione uma função utilitária para formatar datas.
Siga RIPER-5:
1. Pesquisar tratamento existente de datas
2. Identificar o que é necessário
3. Planejar a implementação
4. Executar após minha aprovação
5. Revisar o resultado
Avançado: RIPER-5 com Checkpoints
Integração Git
# Antes de começar (fase de Pesquisa)
git checkout -b feature/riper5-task
git commit -m "checkpoint: before RIPER-5 implementation"
# Após a fase de Pesquisa
git add research-notes.md
git commit -m "riper5: research complete"
# Após a fase de Planejamento (antes da aprovação)
git add plan.md
git commit -m "riper5: plan created, awaiting approval"
# Após a fase de Execução
git add -A
git commit -m "riper5: implementation complete"
# Após a fase de Revisão
git commit -m "riper5: review passed, tests green"
Medindo a Eficácia
Acompanhe estas métricas:
| Métrica | Antes do RIPER-5 | Após o RIPER-5 |
|---|---|---|
| Alterações não autorizadas | Alta | Quase zero |
| Taxa de aprovação de planos | N/A | >90% |
| Taxa de aprovação de testes após mudanças | 60% | 95% |
| Frequência de reversão | Alta | Baixa |
| Satisfação do usuário | Mista | Alta |
Desafios Comuns
| Desafio | Solução |
|---|---|
| Agente pula fases | Aplicar com regras estritas |
| Planos são muito amplos | Exigir especificidade em nível de arquivo |
| Revisão é superficial | Tornar execução de testes obrigatória |
| Torna tarefas simples lentas | Permitir atalhos para mudanças triviais |
Referência Rápida
[INÍCIO RIPER-5]
Fase 1/5: Pesquisa
[Agente lê e analisa]
Fase 2/5: Identificar
[Agente define problema]
Fase 3/5: Planejar
[Agente cria plano]
[Usuário: APROVAR ou MODIFICAR]
Fase 4/5: Executar
[Agente implementa]
Fase 5/5: Revisar
[Agente verifica]
[FIM RIPER-5]