smart_ide/services/ia_dev/.smartIde/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

Preparer au maximum à l'aide d'outils et de scripts

En tant qu'agent, avant de solliciter l'ia, regarde ce que tu peux scripter (importe/install les outils nécessaires si besoin) l'ia est la derniere priorité par rapport à l'outillage, les outils sont lancés dans des scripts dans /home/desk/code/ia_dev/tools et rendus le plus générique possible afin de les réutilisé plus tard dans d'autres contextes, par contre l'ia peut serveur à développer ces scripts.

Rationalisation tokens

• Contexte minimal : ne charger que les fichiers nécessaires à l'étape en cours ; recherches ciblées (dossier/fichier) plutôt qu'exploration large.
• Référencer les procédures longues (clôture, déploiement) par fichier/section au lieu de les recopier.
• Sous-agents : uniquement si nécessaire ; descriptions courtes ; éviter « explore » si grep/read/chemin connu suffit.
• Réponses concises, sans répéter règles ou docs déjà référencées.

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 et tous les warnings (même priorité ; warnings = erreurs). Exécuter npm run lint dans chaque répertoire du périmètre (backend, frontend, ressources) ; comptabiliser erreurs et warnings. Interdit : conclure « lint non applicable » sans justification stricte (tâche sans code source) — avec des sources, le lint est normalement toujours applicable. Interdit : laisser des diagnostics sous prétexte qu’ils sont « hors session » ou « préexistants » : voir .smartIde/rules/cloture-lint.mdc — section Diagnostics préexistants / hors périmètre de la session. Si au moins un diagnostic : corriger au moins 5 problèmes (cumul erreurs + warnings) dans l’exécution, sauf moins de 5 diagnostics au total (alors tout corriger). En clôture, « Lint : Réalisées » uniquement si 0 erreur et 0 warning pour chaque répertoire ; sinon « Non réalisées encore » avec le détail par répertoire (voir .smartIde/rules/cloture-lint.mdc, dont la même section).
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 .smartIde/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 .smartIde/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 docs/repo/ia-dev-project-conf-schema.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 et tous les warnings de lint du projet (chaque répertoire : backend, frontend, ressources partagées) sans contournement ni désactivation des règles. Warnings = erreurs. Ne jamais conclure « lint non applicable » sans justification stricte. Si des diagnostics existent : au moins 5 corrections par exécution sauf moins de 5 diagnostics au total. Ne négliger aucun projet.

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

Lint renforcé (clôture et exécution)

• Voir .smartIde/rules/cloture-lint.mdc : pas de « non applicable » par convenance, warnings = erreurs, minimum 5 corrections lorsqu’il existe des diagnostics (sauf moins de 5 au total → tout corriger), décompte erreurs et warnings en clôture ; section Diagnostics préexistants / hors périmètre de la session : corriger tout diagnostic du périmètre même sans lien avec le diff du run.

Contrainte absolue

NE JAMAIS modifier ni ce fichier ni aucun fichier dans ~/.smartIde/. Ta tâche est UNIQUEMENT de corriger les erreurs et warnings 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.

Priorité en amont (règles de qualité et absence de bypass)

Avant toute correction de lint par lot :

1. Vérifier que les règles et exigences de qualité sont paramétrées dans chaque sous-projet (backend, frontend, ressources) : fichiers de config présents et cohérents (ESLint, TypeScript, Prettier) ; règles attendues activées et non désactivées globalement. Si une règle ou un outil manque ou est désactivé, corriger ou documenter avant d'enchaîner.

2. Vérifier qu'il n'y a pas de bypass dans le code : rechercher et traiter tout eslint-disable, eslint-disable-next-line, @ts-ignore, @ts-expect-error sans justification valide, // @ts-nocheck, désactivation locale de règles. Pour chaque bypass : soit supprimer le bypass en corrigeant le code pour respecter la règle, soit documenter une exception justifiée (référence issue ou décision validée). Aucun bypass pour « résoudre » une erreur de lint : toujours corriger le code. Si une règle exige un refactor (max-params, max-lines-per-function, complexity, max-lines), faire le refactor (objets d'options, extraction de fonctions, découpage de fichiers) ; ne pas laisser de bypass en invoquant « refactor prévu » ou « exception temporaire ».

Priorité centralisation / optimisation

À chaque correction de lint, identifier les duplications et patterns répétés ; centraliser la logique dans des helpers ou modules partagés ; réutiliser les helpers existants avant d'en créer de nouveaux. Pour chaque périmètre (backend, frontend, ressources), si aucune centralisation ou optimisation n'est réalisée alors que des duplications sont repérées, documenter la raison (voir .smartIde/agents/closure-point-7-justification.md). En clôture, si le point 7 (Optimisation / mutualisation / centralisation) est « Non réalisées encore », fournir la justification par composant selon ce fichier.

Première action obligatoire

Exécuter immédiatement npm run lint dans chaque application du périmètre (chaque build_dir : backend, frontend, ressources partagées pour LeCoffre) pour lister erreurs et warnings — tout le périmètre déclaré, pas seulement le sous-projet modifié dans la session. Ne pas modifier de fichiers avant d'avoir la liste complète (erreurs + warnings) pour chaque répertoire. Ne négliger aucun projet.

Périmètre

Les répertoires à traiter (backend, frontend, ressources partagées, etc.) 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). Interdit de réduire ce périmètre au seul arbre touché par la tâche en cours.

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 erreurs et warnings (comptabiliser les deux).
8. Corriger par lots (erreurs en priorité, puis warnings). Contrainte : exécuter la boucle au moins 3 fois de façon complète tant qu'il reste des erreurs ; poursuivre la réduction des warnings jusqu'à 0 ou documenter les restants. Une boucle complète = lots traités, chaque lot avec toutes les étapes ci-dessous. Étapes obligatoires à chaque lot :
   • Corriger les erreurs et les warnings du lot (erreurs en priorité)
   • 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 .smartIde/agents/docupdate.md. L'appel à l'agent docupdate est centralisé dans .smartIde/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 .smartIde/rules/cloture-evolution.mdc : points 1 à 19. Pour le point 7 (Optimisation / mutualisation / centralisation), si « Non réalisées encore » : justifier par composant sollicité (voir .smartIde/agents/closure-point-7-justification.md). 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.