4nk/ia_dev
3
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
ia_dev/.cursor/agents/fix-lint.md
Nicolas Cantu 2f23357460 full exec
2026-03-17 19:26:38 +01:00

12 KiB
Raw Blame History

name description model is_background
fix-lint Corriger les erreurs de lint backend, frontend et ressources partagées. À utiliser quand des erreurs de lint sont à corriger dans le monorepo. inherit false

Corriger les erreurs de lint (backend, frontend, ressources)

Règle d'exécution intégrale (obligatoire, non négociable)

  • Tout dérouler : exécuter toutes les étapes décrites dans cet agent dans l'ordre, sans en omettre aucune. Tout doit se dérouler effectivement.
  • Sans priorisation : aucune étape n'est optionnelle ou "secondaire" ; chacune est obligatoire.
  • Sans jugement d'intérêt : ne jamais juger de la pertinence d'une étape pour la sauter ; tout appliquer tel que décrit, sans exception.
  • Vérification en fin d'agent : avant clôture, cocher explicitement chaque étape (réalisée / non réalisée).

Actions obligatoires et à traiter de façon significative

Chacune des actions ci-dessous est obligatoire et doit être réalisée de façon significative (concrète, mesurable, sans contenu factice ou minimal). Aucune ne peut être omise ni réduite à une simple mention.

Action Obligation
Helpers Créer ou réutiliser des helpers dès que la logique est réutilisable ; pas de duplication.
i18n / env-full Textes sous i18n ; variables sensibles et env dans .secrets/<env>/env-full ; pas de chaînes en dur.
Fallback interdits Aucun fallback implicite ; erreurs remontées et journalisées ; chemins alternatifs explicites uniquement.
Modifications similaires Appliquer les mêmes corrections à tous les endroits concernés (parcourir le code, pas seulement le fichier courant).
Optimisation / mutualisation Centraliser la logique dupliquée, mutualiser constantes et helpers, optimiser où pertinent.
Réduction de complexité Réduire complexité cyclomatique, profondeur, paramètres ; extraire fonctions/composants.
Sécurité Validation des entrées, pas de secrets en dur, logging sans données sensibles, règles d'accès respectées.
Code mort Supprimer tout code inutilisé, branches mortes, imports inutiles.
Lint Corriger toutes les erreurs de lint sans désactiver les règles.
Types Types explicites, pas de any non justifié ; corriger toutes les erreurs de type.
Compilation Build et typecheck OK sur chaque répertoire du périmètre.
Documentation Mise à jour réelle de la doc (docs/, wiki) selon .cursor/agents/docupdate.md.
Reste à faire Lister explicitement ce qu'il reste à faire (puces) en fin de processus.
« Non réalisées encore » Pour chaque point des questions de clôture, traiter et réaliser les « Non réalisées encore » avant clôture.
Push Exécuter .cursor/agents/push-by-script.md en fin d'agent si pas déjà fait ; afficher le texte du commit.

Contexte projet : La configuration et la documentation du projet sont dans projects/<id>/. L'identifiant <id> est résolu uniquement par MAIL_TO (adresse « to » des mails) ou AI_AGENT_TOKEN (token des requêtes) ; pas de fallback. Voir projects/README.md. Rappeler ce chemin en début d'exécution.

Documentation : La doc des projets gérés est dans projects/<id>/docs ; la doc ia_dev est dans projects/ia_dev/docs.

Corrige toutes les erreurs de lint du projet sans contournement ni désactivation des règles.

Horodatage et contexte : appliquer intégralement le bloc défini dans .cursor/rules/cloture-evolution.mdc (début et fin d'exécution, lancement et retour des sub-agents).

Contrainte absolue

NE JAMAIS modifier ni ce fichier ni aucun fichier dans ~/.cursor/. Ta tâche est UNIQUEMENT de corriger les erreurs de lint dans le code du projet. Les répertoires à linter (backend, frontend, ressources partagées, etc.) sont définis par le projet : soit par convention (ex. backend, frontend, shared), soit dans projects/<id>/conf.json (clé build_dirs ou documentation du projet). Ne pas modifier ni améliorer la définition de cet agent.

  • Résolution directe : En cas de problème (toutes criticités), ne jamais simplifier, contourner, forcer un résultat en dur, ou créer des bouchons. Le problème doit être résolu à sa racine.

Première action obligatoire

Exécuter immédiatement npm run lint dans chaque application pour lister les erreurs. Ne pas modifier de fichiers avant d'avoir la liste des erreurs.

Périmètre

Les répertoires à traiter (backend, frontend, ressources partagées) sont ceux du projet courant. Consulter projects/<id>/conf.json (clé build_dirs) ; l'id est résolu par MAIL_TO ou AI_AGENT_TOKEN. Sinon, suivre la structure du dépôt (ex. backend, frontend, shared ou noms définis dans la doc du projet).

Concurrence

Ne pas lancer si un déploiement est en cours. Si un déploiement est demandé pendant l'exécution, s'arrêter proprement.

Processus à suivre obligatoirement

  1. Mettre à jour les dépendances de chaque répertoire du périmètre (build_dirs ou structure du projet)
  2. Vérifier que les règles de lint n'ont pas été réduites, dégradées ou désactivées dans les configurations et dans le code pour chaque répertoire
  3. Lancer un lint fix sur chaque répertoire
  4. Lancer un test de build/typecheck et corriger les erreurs de type pour chaque répertoire
  5. Pour chaque répertoire : Lister les variables préfixées de "_" (inutiles) et supprimer
  6. Pour chaque répertoire : Lister les constantes non utilisées ou à mutualiser, les mutualiser et remplacer les valeurs en dur par les constantes
  7. Exécuter npm run lint dans chaque application pour lister les erreurs
  8. Corriger par lots de 20 erreurs (5 lots de 4 erreurs). Contrainte : exécuter cette boucle au moins 3 fois de façon complète tant qu'il reste des erreurs (une boucle complète = 5 lots traités, chaque lot avec toutes les étapes ci-dessous). Étapes obligatoires à chaque lot :
    • Corriger les erreurs du lot
    • Mettre en place l'utilisation exclusive de next/font via variables CSS et optimiser le chargement (pas de FOIT/FOUT, pas de CLS, pas de double téléchargement)
    • Lister les mutualisations/centralisations/simplifications et les réaliser
    • Lister les textes à passer sous i18n ou à intégrer à .secrets/test/seed-site-texts-test.ts et migrer
    • Lister le code mort et le supprimer
    • Vérification en fin de boucle : avant de passer à la boucle suivante, s'assurer que les 5 étapes ci-dessus ont été exécutées pour les 5 lots de la boucle ; répéter jusqu'à avoir effectué au moins 3 boucles complètes (15 lots minimum au total).
  9. Lancer un lint fix sur chaque répertoire du périmètre
  10. S'il y a des mutualisations/optimisations/centralisations possibles, les faire
  11. Lancer un test de build/typecheck et corriger les erreurs de type pour chaque répertoire
  12. Compléter la documentation selon .cursor/agents/docupdate.md. L'appel à l'agent docupdate est centralisé dans .cursor/rules/cloture-evolution.mdc (étape 12) — l'exécuter en clôture selon cette étape.

Ordre de priorité des règles applicables

  • Autres règles du projet
  • max-params : 4
  • complexity : 8
  • max-nested-callbacks : 3
  • max-depth : 4
  • max-lines-per-function : 40
  • max-lines : 250

Stratégies de correction obligatoires

  1. Ne jamais contourner : pas de eslint-disable, pas de désactivation de règles, pas de "_" sur les variables inutiles
  2. centralisations : Appliquer les patterns du projet : extraction de helpers, découpage de fichiers, objets de configuration pour réduire les paramètres
  3. max-params : regrouper dans un objet de configuration typé
  4. complexity : extraire des branches dans des fonctions dédiées
  5. max-depth : aplatir les imbrications avec early return
  6. max-lines / max-lines-per-function : extraire des helpers, découper en sous-composants

Autres règles

  • Règles automatiques : Respecter les règles ESLint configurées dans eslint.config.mjs :
    • TypeScript :
      • @typescript-eslint/no-explicit-any : warn
      • @typescript-eslint/no-unused-vars : warn (ignorer les variables et arguments commençant par _)
      • @typescript-eslint/explicit-function-return-type : warn
      • @typescript-eslint/explicit-module-boundary-types : warn
      • @typescript-eslint/no-unused-expressions : error (autorise short-circuit, ternary et tagged templates)
    • React :
      • react/react-in-jsx-scope : warn
      • react/no-unescaped-entities : warn
      • react/no-children-prop : off
      • react-hooks/rules-of-hooks : error
      • react-hooks/exhaustive-deps : warn
    • Générales :
      • no-console : warn
      • max-lines : warn (front) / error (back), max 250 lignes par fichier (lignes vides et commentaires exclus)
      • max-lines-per-function : warn (front) / error (back), max 40 lignes par fonction (lignes vides et commentaires exclus)
      • max-params : max 4 paramètres par fonction
      • max-depth : profondeur d'imbrication max 4
      • complexity : complexité cyclomatique max 10
      • max-nested-callbacks : max 3 callbacks imbriqués
  • TypeScript : Toujours exécuter un build avant commit.
  • Build : Vérifier que le build passe sans erreurs.
  • Dépassements : Si un fichier/fonction dépasse les limites :
    1. Découper immédiatement si faisable
    2. Sinon, documenter dans la page wiki Operations du projet (URL dans projects/<id>/conf.json → git.wiki_url) avec plan de refactor + échéance
    3. Ajouter commentaire // TODO(MAX_LINES) avec justificatif
  • Référence : Consulter la page wiki Code-Standards ou la doc qualité du projet (wiki ou docs/).

🔒 Sécurité

  • Validation des entrées : Toujours valider les entrées utilisateur (class-validator pour DTOs backend, validation frontend).
  • Authentification : Utiliser les middlewares existants (authHandler, ruleHandler, PermissionContextInjector).
  • Secrets : Jamais de secrets en dur. Utiliser system_configuration en base de données.
  • Logging sensible : Ne jamais logger de données sensibles (RIB, tokens, OTP). Utiliser Winston uniquement.
  • Rate limiting : Respecter les niveaux configurés (public/strict/auth/global).
  • Accès base : Toujours vérifier deleted_at: null pour les entités soft-delete.
  • Référence : Consulter la page wiki Code-Standards et la doc sécurité du projet (wiki ou docs/).

Après l'exécution

  • Si le script sort avec 0, rapporter le succès et le SHA aligné final si affiché.
  • Si le script sort avec un code non nul, rapporter le message d'erreur (stderr) et ne pas réessayer sans instruction utilisateur.

Clôture complète obligatoire (tous les cas, sans exception)

En fin d'exécution de cet agent, toujours appliquer intégralement .cursor/rules/cloture-evolution.mdc : points 1 à 19. Les actions obligatoires et significatives (section ci-dessus : Helpers, i18n/env-full, fallback interdits, modifications similaires, optimisation/mutualisation, réduction de complexité, sécurité, code mort, lint, types, compilation, documentation, reste à faire, « Non réalisées encore », push) doivent toutes être traitées de façon significative avant clôture. Toutes les étapes (agent + clôture) doivent être réellement passées, sans jugement de pertinence ; tout doit se dérouler. (horodatage, 5 sub-agents par projet, questions 3-13, docupdate, reste à faire, push-by-script si pas déjà fait, affichage du texte du commit). Aucune exception : même si le lint n'a pas été modifié, la clôture complète est obligatoire. Lister les actions réalisées et non réalisées pour chaque point.