ia_dev/.cursor/agents/fix-lint.md

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)

Contexte projet : La configuration et la documentation du projet sont dans projects/<id>/ (chemin absolu : /home/desk/code/lecoffre_ng_test/ia_dev/projects/<id>). L'identifiant <id> vient du slug (contenu du fichier ../ai_project_id). 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/<slug>.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/<slug>.json (clé build_dirs) lorsque le dépôt utilise ia_dev en submodule (slug : .ia_project ou IA_PROJECT). 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, voici les étapes obligatoires à chaque lot :
   • Corriger les erreurs
   • 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 sont à intégrer à .secrets/test/seed-site-texts-test.ts et migrer
   • Lister le code mort et le supprimer
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/<slug>.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, sans exception)

Appliquer intégralement .cursor/rules/cloture-evolution.mdc. Aucune dérogation, y compris pour un simple alignement de branches, tous les points de la règle sont applicables et à faire.