Mode de contrainte d'agent avancé RIPER-5 pour Cursor
RIPER-5 est un framework de contraintes créé par la communauté qui s'est avéré réduire drastiquement les hallucinations de l'IA et les modifications de code non autorisées. Conçu à l'origine pour Claude 3.7, il fonctionne exceptionnellement bien avec le mode Agent de Cursor. Ce guide explique les cinq phases et comment les mettre en œuvre.
Qu'est-ce que RIPER-5 ?
RIPER-5 signifie :
| Phase | Nom | Objectif |
|---|---|---|
| R | Research (Recherche) | Rassembler des informations sans apporter de modifications |
| I | Identify (Identifier) | Cibler exactement le problème ou le besoin |
| P | Plan (Planifier) | Créer un plan détaillé et approuvé |
| E | Execute (Exécuter) | Implémenter UNIQUEMENT le plan approuvé |
| R | Review (Réviser) | Vérifier et tester l'implémentation |
Les cinq phases en détail
Phase 1 : Recherche (R)
Règle : Lecture seule. Aucune modification de fichier autorisée.
Actions :
- Lire les fichiers pertinents
- Rechercher dans la base de code avec Grep
- Analyser les modèles existants
- Comprendre les dépendances
Sortie : Résumé de recherche avec les découvertes
## Phase de recherche terminée
### Fichiers analysés
- `src/auth/login.ts` - Flux d'authentification actuel
- `src/middleware/auth.ts` - Vérification JWT
- `tests/auth.test.ts` - Tests existants
### Découvertes clés
1. L'authentification utilise JWT avec une expiration de 15 min
2. Aucun mécanisme de jeton de rafraîchissement n'existe
3. La réinitialisation du mot de passe n'est pas implémentée
4. Les tests couvrent la connexion mais pas les cas limites
### Dépendances
- jsonwebtoken: ^9.0.0
- bcrypt: ^5.1.0
Phase 2 : Identification (I)
Règle : Définir l'énoncé exact du problème.
Actions :
- Énoncer clairement le problème
- Définir les critères d'acceptation
- Identifier les contraintes
- Noter les risques potentiels
Sortie : Document de définition du problème
## Identification du problème
### Énoncé du problème
Les utilisateurs sont déconnectés après 15 minutes et doivent se réauthentifier.
Cela crée une mauvaise UX pour les sessions de longue durée.
### Cause racine
Les jetons JWT expirent après 15 minutes sans mécanisme de rafraîchissement.
### Critères d'acceptation
- [ ] Les utilisateurs restent connectés pendant 7 jours
- [ ] Les jetons de rafraîchissement tournent à chaque utilisation
- [ ] Les anciens jetons de rafraîchissement sont invalidés
- [ ] Les utilisateurs peuvent révoquer toutes les sessions
### Contraintes
- Doit maintenir la rétrocompatibilité
- Aucune modification cassante de l'API existante
- Doit fonctionner avec le middleware JWT existant
### Risques
- Vol de jeton si les jetons de rafraîchissement sont compromis
- Stockage en base de données pour le suivi des jetons
Phase 3 : Planification (P)
Règle : Créer un plan détaillé, étape par étape.
Actions :
- Lister tous les fichiers à modifier
- Spécifier les changements exacts par fichier
- Définir la stratégie de test
- Planifier la procédure de retour en arrière
Sortie : Plan d'implémentation détaillé
## Plan d'implémentation
### Fichiers à modifier
#### 1. `src/models/refresh-token.ts` (NOUVEAU)
```typescript
// Schéma pour les jetons de rafraîchissement
// Champs : id, userId, token, createdAt, expiresAt, revoked
2. src/services/auth.ts (MODIFIER)
- Ajouter la fonction
createRefreshToken() - Ajouter la fonction
rotateRefreshToken() - Ajouter la fonction
revokeAllUserTokens()
3. src/routes/auth.ts (MODIFIER)
- Ajouter le point de terminaison POST
/refresh - Ajouter le point de terminaison POST
/revoke
4. src/middleware/auth.ts (MODIFIER)
- Mettre à jour la vérification JWT pour prendre en charge des sessions plus longues
Plan de test
- Tests unitaires pour la rotation des jetons
- Tests d'intégration pour le flux de rafraîchissement
- Tests de sécurité pour la révocation des jetons
Plan de retour en arrière
- Supprimer le modèle de jeton de rafraîchissement
- Revenir aux modifications du service d'authentification
- Supprimer les nouveaux points de terminaison
### Phase 4 : Exécution (E)
**Règle** : Implémenter UNIQUEMENT ce qui était prévu.
**Actions** :
- Apporter les modifications prévues
- Suivre exactement le plan
- Signaler les progrès après chaque fichier
- S'arrêter si le plan doit être révisé
**Sortie** : Implémentation avec suivi des progrès
```markdown
## Phase d'exécution
### Progrès
- [x] Créé `src/models/refresh-token.ts`
- [x] Modifié `src/services/auth.ts`
- [ ] Modifier `src/routes/auth.ts` (en cours)
- [ ] Mettre à jour `src/middleware/auth.ts`
### Modifications apportées
1. Ajout du modèle RefreshToken avec les champs
2. Implémentation de la logique de rotation des jetons
3. Ajout du support de révocation
### Prochaines étapes
- Ajouter le point de terminaison de rafraîchissement
- Mettre à jour le middleware
Phase 5 : Révision (R)
Règle : Vérifier que tout fonctionne comme prévu.
Actions :
- Exécuter tous les tests
- Vérifier les régressions
- Vérifier les critères d'acceptation
- Documenter les écarts
Sortie : Rapport de révision
## Phase de révision
### Tests
- [x] Tests unitaires réussis (15/15)
- [x] Tests d'intégration réussis (8/8)
- [x] Tests de sécurité réussis (5/5)
### Critères d'acceptation
- [x] Les utilisateurs restent connectés pendant 7 jours
- [x] Les jetons de rafraîchissement tournent à chaque utilisation
- [x] Les anciens jetons de rafraîchissement sont invalidés
- [x] Les utilisateurs peuvent révoquer toutes les sessions
### Régressions
- Aucune détectée
### Écarts par rapport au plan
- Ajout d'une tâche cron de nettoyage des jetons (pas dans le plan original)
- Raison : Empêche l'enflure de la base de données due aux jetons expirés
Configuration de RIPER-5 dans Cursor
Étape 1 : Créer le fichier de règles
Créez .cursor/rules/riper5-mode.mdc :
---
description: 'Mode de contrainte avancé RIPER-5'
globs: ['**/*']
alwaysApply: true
---
# Mode RIPER-5
Vous DEVEZ suivre le workflow RIPER-5 pour TOUTES les tâches.
## Séquence des phases
1. **Recherche** - Lire et analyser uniquement
2. **Identifier** - Définir le problème
3. **Planifier** - Créer un plan détaillé
4. **Exécuter** - Implémenter uniquement le plan
5. **Réviser** - Vérifier et tester
## Règles des phases
### Phase de recherche
- Utiliser uniquement les outils Read, Grep, Search
- AUCUNE modification de fichier
- AUCUNE génération de code
- Présenter les découvertes dans un format structuré
### Phase d'identification
- Énoncer clairement le problème
- Définir les critères d'acceptation
- Lister les contraintes
- Identifier les risques
### Phase de planification
- Lister TOUS les fichiers à modifier
- Montrer les changements exacts pour chaque fichier
- Inclure la stratégie de test
- Inclure le plan de retour en arrière
- ATTENDRE l'approbation de l'utilisateur
### Phase d'exécution
- Implémenter UNIQUEMENT les modifications prévues
- Signaler après chaque fichier
- Demander des clarifications si bloqué
- AUCUNE modification non prévue
### Phase de révision
- Exécuter tous les tests
- Vérifier les critères d'acceptation
- Vérifier les régressions
- Documenter les écarts
## CRITIQUE
- NE JAMAIS sauter de phases
- NE JAMAIS modifier de fichiers pendant la phase de recherche
- NE JAMAIS ajouter de modifications non prévues pendant la phase d'exécution
- TOUJOURS obtenir l'approbation avant la phase d'exécution
Étape 2 : Ajouter au prompt système
Dans les paramètres de Cursor :
## Workflow RIPER-5
Pour chaque tâche, vous DEVEZ suivre ces 5 phases :
1. **Recherche** : Lire et analyser sans modifications
2. **Identifier** : Définir le problème exact
3. **Planifier** : Créer un plan d'implémentation détaillé
4. **Exécuter** : Implémenter UNIQUEMENT le plan approuvé
5. **Réviser** : Vérifier que tout fonctionne
Vous ne pouvez pas passer à la phase suivante sans avoir terminé la phase actuelle.
Vous ne pouvez pas modifier de fichiers pendant les phases de recherche ou d'identification.
Vous ne pouvez pas ajouter de modifications non prévues pendant la phase d'exécution.
Étape 3 : Pratiquer avec une tâche simple
Commencez par une petite tâche pour vous familiariser :
[Tâche] Ajouter une fonction utilitaire pour formater les dates.
Suivez RIPER-5 :
1. Rechercher la gestion existante des dates
2. Identifier ce qui est nécessaire
3. Planifier l'implémentation
4. Exécuter après mon approbation
5. Réviser le résultat
Avancé : RIPER-5 avec points de contrôle
Intégration Git
# Avant de commencer (phase de recherche)
git checkout -b feature/riper5-task
git commit -m "checkpoint: before RIPER-5 implementation"
# Après la phase de recherche
git add research-notes.md
git commit -m "riper5: research complete"
# Après la phase de planification (avant approbation)
git add plan.md
git commit -m "riper5: plan created, awaiting approval"
# Après la phase d'exécution
git add -A
git commit -m "riper5: implementation complete"
# Après la phase de révision
git commit -m "riper5: review passed, tests green"
Mesurer l'efficacité
Suivez ces métriques :
| Métrique | Avant RIPER-5 | Après RIPER-5 |
|---|---|---|
| Modifications non autorisées | Élevé | Presque zéro |
| Taux d'approbation des plans | N/A | >90% |
| Taux de réussite des tests après modifications | 60% | 95% |
| Fréquence de retour en arrière | Élevé | Faible |
| Satisfaction des utilisateurs | Mitigée | Élevée |
Défis courants
| Défi | Solution |
|---|---|
| L'agent saute des phases | Appliquer avec des règles strictes |
| Les plans sont trop larges | Exiger une spécificité au niveau du fichier |
| La révision est superficielle | Rendre obligatoire l'exécution des tests |
| Ralentit les tâches simples | Autoriser les raccourcis pour les modifications triviales |
Référence rapide
[DÉBUT RIPER-5]
Phase 1/5 : Recherche
[L'agent lit et analyse]
Phase 2/5 : Identification
[L'agent définit le problème]
Phase 3/5 : Planification
[L'agent crée le plan]
[Utilisateur : APPROUVER ou MODIFIER]
Phase 4/5 : Exécution
[L'agent implémente]
Phase 5/5 : Révision
[L'agent vérifie]
[FIN RIPER-5]