cursor/desk/commands/lintit.md

model

model
inherit

lintit

Vérifie toutes ces règles et liste les actions à mener.

qualité du code

Analyse préalable obligatoire et arbre des fichiers

Avant toute implémentation, une phase d’analyse est obligatoire et doit produire une représentation de l’arbre des fichiers pertinents.

Cette représentation sert à identifier :

• la documentations le plus souvent dans docs/
• le code à rutiliser et les héritages
• les modules déjà disponibles
• les points d’extension existants
• les abstractions en place
• les conventions d’architecture
• les zones attendues de factorisation

Aucun code nouveau ne doit être écrit tant que cette cartographie minimale n’a pas été produite et exploitée pour éviter toute duplication.

Non-duplication et réutilisation systématique

Toute logique nouvelle déclenche une vérification explicite de réutilisation possible dans le code existant.

Sont considérés comme duplication à éviter :

• copier-coller de blocs
• variations mineures d’une même fonction
• traitements parallèles de cas similaires
• conversions de types répétées
• mappings répétés
• gestion d’erreurs répétée
• validations répétées
• constructions d’objets redondantes

Si un comportement est récurrent, il doit être refactoré dans une abstraction partagée : fonction utilitaire ciblée, service, composant, stratégie, adaptateur ou classe de base, selon l’architecture.

Toute extraction doit préserver la lisibilité et la cohésion, sans créer d’utilitaires génériques sans responsabilité claire. Une réutilisation ne doit ni introduire de dépendance circulaire ni dégrader la modularité.

Généricité et isolation des exceptions sans duplication

Le comportement par défaut doit être modélisé de façon générique. Les cas particuliers doivent être isolés dans des unités dédiées, sans répliquer le flux principal.

Les exceptions métier ou techniques doivent être représentées par :

• des types d’erreurs explicites
• des branches clairement identifiées
• des stratégies remplaçables ou des adaptateurs selon le besoin

Les variations doivent être injectées par inversion de dépendance plutôt que codées sous forme de conditions dispersées.

La règle est de minimiser le nombre d’endroits où un cas particulier est connu, idéalement un seul point de spécialisation.

Design patterns et héritage

Les patterns doivent être employés uniquement lorsqu’ils clarifient le découpage et réduisent effectivement la duplication.

Les patterns attendus selon le contexte incluent notamment :

• Factory et Abstract Factory pour instancier selon le contexte sans cascade de conditions
• Strategy pour encapsuler des variations comportementales
• Template Method pour définir un squelette d’algorithme stable avec points d’extension
• Adapter pour interfacer une dépendance externe sans contaminer le domaine
• Decorator pour enrichir un comportement sans abus d’héritage
• Command pour formaliser des actions et leurs paramètres
• Repository ou Gateway pour l’accès aux données ou services externes

L’héritage est autorisé lorsqu’il représente une relation stable de type est-un, avec un contrat clair, et qu’il évite une duplication réelle.

Il est interdit d’utiliser l’héritage pour partager des détails d’implémentation instables ou pour créer une hiérarchie artificielle.

La composition est privilégiée lorsque les variations sont nombreuses ou lorsque des comportements combinables sont requis.

Toute hiérarchie doit rester courte, compréhensible, testable, et ne pas masquer les dépendances.

Gestion des erreurs, traçabilité et journalisation

Tout cas d’erreur doit être journalisé.

Sont inclus :

• erreurs de validation
• erreurs d’entrée-sortie
• erreurs réseau
• erreurs de parsing
• états impossibles
• erreurs de dépendances externes
• timeouts
• conflits
• violations d’invariants

La journalisation doit être structurée et inclure le niveau, le contexte, les identifiants pertinents, la cause, la stack lorsque disponible, et uniquement des données non sensibles.

Les messages doivent permettre un diagnostic en production sans reproduction systématique.

Aucune erreur ne doit être ignorée silencieusement.

Les erreurs doivent remonter avec un type explicite et, si nécessaire, être enrichies par un contexte supplémentaire sans perdre la cause originelle.

Les logs doivent respecter les conventions du projet, notamment l’usage d’un logger centralisé, les mécanismes de corrélation et les formats imposés. L’usage direct de console.log est interdit si un système de journalisation est déjà en place.

Interdiction de fallback

Aucun mécanisme de fallback implicite ne doit être introduit.

Sont considérés comme fallback interdits :

• l’utilisation de valeurs par défaut pour masquer une erreur
• l’attrapage d’une erreur suivi d’une poursuite silencieuse
• le déclenchement d’une voie alternative non explicitement spécifiée
• toute dégradation silencieuse de la qualité, de la sécurité ou de la cohérence

tout fallback et placeholders doivent etre validés avant implémentation

Si un comportement alternatif est requis fonctionnellement, il doit être explicitement défini comme un chemin nominal, avec des conditions d’activation claires, un typage explicite et une observabilité complète.

En l’absence de spécification explicite d’alternative, l’erreur doit être remontée et journalisée.

Interdiction de facilités pour l’IA et anti-optimisations artificielles

Aucune implémentation ne doit être simplifiée pour satisfaire uniquement la compilation ou un cas minimal.

Sont interdits :

• stubs durables et non validés
• hacks temporaires laissés en place et non validés
• branches mortes et non validés
• TODO structurants non résolus et non validés
• implémentations partielles non signalées et non validés
• comportements best effort non spécifiés et non validés

L’optimisation pour l’IA elle-même est interdite. Le code ne doit pas être réorganisé pour faciliter la génération automatique au détriment de la cohérence du projet.

L’optimisation de performance n’est pas un objectif par défaut. Elle n’est permise que si un goulot est identifié, mesurable, documenté, et si l’amélioration ne dégrade ni la clarté ni la sécurité.

Corrige toutes les erreurs des tests de lint

Sans contournement, ni desactivation des règles : corrige toutes les erreurs des tests de lint.

Corrige toutes les warnings des tests de lint

Sans contournement, ni desactivation des règles : corrige toutes les warnings des tests de lint.

Règles de lint par défaut

'''mjs export default [ { ignores: [ "dist/", "node_modules/", "coverage/", "logs/", "tmp/", "prisma/migrations/", "scripts/", "src/scripts/", "src/tests/", "src/test/", "tests/", ".js", ".mjs", "*.d.ts", "/.svg", "/proofTemplate.ts", "/seeders/**", ], }, ...compat.config({ extends: ["plugin:@typescript-eslint/recommended", "prettier"], parser: "@typescript-eslint/parser", parserOptions: { project: "./tsconfig.json", tsconfigRootDir: __dirname, ecmaVersion: 2022, sourceType: "module", }, plugins: ["@typescript-eslint"], env: { node: true, es2022: true, }, rules: { "@typescript-eslint/no-explicit-any": "error", "@typescript-eslint/no-unused-vars": [ "error", { argsIgnorePattern: "^", varsIgnorePattern: "^*", }, ], "@typescript-eslint/explicit-function-return-type": "error", "@typescript-eslint/explicit-module-boundary-types": "error", "@typescript-eslint/no-non-null-assertion": "error", "@typescript-eslint/no-require-imports": "error", "no-console": "off", "max-lines": [ "error", { max: 400, skipBlankLines: true, skipComments: true, }, ], "max-lines-per-function": [ "error", { max: 60, skipBlankLines: true, skipComments: true, }, ], }, }), ]; '''