Moteur d'auto-réparation et d'apprentissage par correction

Auto-Réparation (Moteur de Règles Auto-Correctif)

Un moteur de mémoire et d'apprentissage auto-correctif qui enregistre les corrections, les conventions de projet et les corrections de bogues dans un fichier de règles persistant (autofix.json). Il garantit que l'agent s'adapte continuellement, élimine les erreurs récurrentes entre les sessions et adhère strictement aux préférences de l'utilisateur.

Pourquoi cela fonctionne : Les agents IA ont tendance à répéter les mêmes hypothèses par défaut ou erreurs stylistiques d'une session à l'autre. En externalisant les connaissances acquises dans un ensemble de règles JSON impératives et versionnées avec une précédence stricte (les règles les plus récentes l'emportent), l'agent conserve des limites strictes adaptées à l'utilisateur et au dépôt spécifiques.

---

Stockage et Configuration

Le skill recherche le fichier de règles dans l'un des emplacements suivants (par ordre de priorité) :

1. .agents/autofix.json
2. autofix.json (à la racine de l'espace de travail)
3. .rules/autofix.json

Si aucun fichier n'existe lorsqu'une nouvelle règle doit être ajoutée, il crée .agents/autofix.json (ou autofix.json à la racine selon la convention du projet).

Schéma d'une Règle

Chaque règle est stockée dans un tableau JSON avec le schéma suivant :

[
  {
    "Rule_number": 1,
    "Category": "CODE",
    "Instruction": "Ne jamais utiliser d'exportations par défaut pour les composants React - toujours utiliser des exportations nommées.",
    "Why": "Garantit la cohérence avec la codebase et simplifie le refactoring."
  }
]

Catégories Autorisées

Catégorie	Description	Exemples
[STYLE]	Formatage du code, conventions de nommage, ordre des imports, commentaires	"Toujours utiliser le camelCase pour les fonctions utilitaires"
[CODE]	Patrons de langage, choix de bibliothèques, définitions de types, gestion d'erreurs	"Ne jamais utiliser any en TypeScript ; utiliser unknown avec des gardes de type"
[ARCH]	Structure des répertoires, limites des modules, couches architecturales	"Les routes API se trouvent dans src/server/routes/, pas dans src/api/"
[TOOL]	Commandes CLI, outils de build, gestionnaires de paquets, frameworks de test	"Toujours utiliser pnpm au lieu de npm ou yarn"
[PROCESS]	Workflow Git, messages de commit, exigences PR, gardes de test	"Ne jamais ajouter d'émojis aux messages de commit"
[DATA]	Schémas de base de données, migrations, stratégies de cache, formes d'état	"Toujours inclure les horodatages created_at et updated_at sur les tables"
[UX]	Comportements UI, conventions de copie, normes d'accessibilité	"Toujours fournir un aria-label explicite pour les boutons avec uniquement une icône"
[OTHER]	Préférences générales du projet ou spécifiques au domaine	"Toujours documenter les points de terminaison de l'API publique au format tableau Markdown"

---

Flux de Travail Opérationnel

[Début de Session / Tâche Reçue]
            │
            ▼
┌───────────────────────────────┐
│ 1. Analyse Pré-Tâche          │ ◄── Lire autofix.json
│    - Charger toutes les règles│
│    - Résoudre les conflits    │
│      (nouveau > ancien)       │
│    - Construire les           │
│      contraintes actives      │
└───────────┬───────────────────┘
            │
            ▼
┌───────────────────────────────┐
│ 2. Exécution de la Tâche      │
│    - Appliquer les contraintes│
│    - Exécuter le code/édits   │
└───────────┬───────────────────┘
            │
            ├─────────────────────────────────────────┐
            │                                         │
     [Aucune Correction]                    [Déclencheur Détecté]
            │                                         │
            ▼                                         ▼
┌───────────────────────────────┐       ┌───────────────────────────────┐
│ Tâche Terminée                │       │ 3. Auto-Réparation & Capture  │
│ Fournir le résultat à         │       │    - Formuler règle impérative│
│ l'utilisateur                 │       │    - Ajouter à autofix.json   │
└───────────────────────────────┘       │    - Accuser réception de     │
                                        │      l'apprentissage          │
                                        └─────────────┬─────────────────┘
                                                      │
                                                      ▼
                                        ┌───────────────────────────────┐
                                        │ 4. Ré-exécuter & Corriger     │
                                        │ Corriger le résultat actuel   │
                                        └───────────────────────────────┘

---

Exécution Pas à Pas Détaillée

1. Analyse Pré-Tâche (Avant de Faire Quoi que Ce Soit)

Avant de planifier ou de modifier des fichiers dans une tâche :

1. Localiser et charger autofix.json.
2. Analyser les règles :
   • Vérifier si une règle s'applique directement aux fichiers, outils ou patrons impliqués dans la demande actuelle.
3. Résoudre les conflits :
   • Si deux règles donnent des directives contradictoires, la règle avec le numéro le plus élevé (la plus récente) l'emporte.
4. Maintenir les contraintes actives :
   • Traiter toutes les règles actives comme des contraintes strictes (équivalentes aux CONSTRAINTES d'un contrat de prompt).

---

2. Quand Ajouter une Règle (Conditions de Déclenchement)

Déclencher immédiatement la capture d'une règle lorsque l'un des événements suivants se produit :

• L'utilisateur corrige explicitement la sortie : par exemple, "Non, n'utilise pas X, fais-le avec Y", "Nous n'utilisons pas de composants de classe ici".
• L'utilisateur rejette un fichier, une approche ou un patron : par exemple, "Ne mets pas les fichiers de test à côté du code source".
• L'utilisateur exprime une préférence personnelle ou d'équipe : par exemple, "Formate toujours les messages de commit comme des Conventional Commits", "N'utilise jamais d'émojis dans la documentation".
• Un bogue a été causé par de mauvaises hypothèses : L'agent a supposé une bibliothèque ou un emplacement de fichier qui a causé un échec.
• L'utilisateur exécute /learn ou demande de se souvenir d'une règle.

---

3. Ajout d'une Nouvelle Règle

Lorsqu'un déclencheur se produit, effectuer la mise à jour atomique suivante :

1. Lire le tableau autofix.json existant.
2. Déterminer le prochain Rule_number séquentiel :
   • Si le numéro de règle existant le plus élevé est $N$, la nouvelle règle est $N + 1$.
   • Si le fichier est vide ou nouveau, commencer à 1.
3. Formater le nouvel objet règle :
   • Rule_number : Entier séquentiel.
   • Category : Une des catégories standard (STYLE, CODE, ARCH, TOOL, PROCESS, DATA, UX, OTHER).
   • Instruction : Rédigée au format impératif strict : "Ne jamais/Toujours faire X - parce que Y."
   • Why : Raison brève (par exemple "préférence utilisateur", "patron de la codebase", "limitation du framework").
4. Ajouter la règle dans le tableau JSON et enregistrer le fichier avec une indentation de 2 espaces.
5. Ne jamais supprimer les règles existantes. Si une ancienne règle est remplacée, écrire la nouvelle règle de sorte que son numéro plus élevé prenne le pas.
6. Notifier brièvement l'utilisateur :

   "Règle apprise n°<N> ([CATÉGORIE]) : <Instruction> — enregistrée dans autofix.json."

---

4. Exemple de Fichier de Règles (autofix.json)

[
  {
    "Rule_number": 1,
    "Category": "PROCESS",
    "Instruction": "Ne jamais ajouter d'émojis aux messages de commit - garder les titres de commit en Conventional Commits simples.",
    "Why": "préférence utilisateur"
  },
  {
    "Rule_number": 2,
    "Category": "ARCH",
    "Instruction": "Toujours placer les gestionnaires de routes API dans 'src/server/routes/', jamais dans 'src/api/' - maintenir une architecture backend cohérente.",
    "Why": "patron existant de la codebase"
  },
  {
    "Rule_number": 3,
    "Category": "CODE",
    "Instruction": "Toujours utiliser les schémas Zod pour la validation des entrées sur tous les points d'entrée externes - empêcher les entrées non typées à l'exécution.",
    "Why": "empêche les erreurs d'exécution et applique les types"
  }
]

---

Meilleures Pratiques et Cas Particuliers

• Écriture Atomique JSON : Toujours analyser le tableau JSON existant, ajouter le nouvel objet et réécrire un JSON valide. Ne jamais corrompre le fichier avec du texte non échappé.
• Concret et Impératif : Écrire des règles qu'un autre IA peut suivre sans ambiguïté. Éviter les conseils vagues comme "Écrire du code propre" ; préférer "Toujours exporter les types à côté des implémentations de composants dans des fichiers .types.ts".
• Pas de Boucles Infinies : Lors de l'enregistrement d'une règle, ne pas déclencher une boucle d'auto-réparation distincte pour le fichier de règles lui-même.
• Règles de Remplacement : Si la règle 1 dit "Utiliser Axios" et que l'utilisateur demande plus tard "Migrer tout vers Fetch", ajouter la règle 4 "Toujours utiliser Fetch natif au lieu d'Axios" avec Why: "migration demandée par l'utilisateur vers fetch natif (remplace la règle 1)".