ihm_client/.cursor/rules/all.mdc

---
description: Règles pour tous aussi pour l'IA et pour Cursor
alwaysApply: true
---

# IHM_CLIENT

voir les fichiers README.md

## Instructions for Claude

### General

* Répond en français
* Code, documente le code, et fait les commits en anglais

### Règles Obligatoires

### Préparation

* **Répertoires :** Les application du services sont dans les autres dossiers à part `logs/`, `test-browser/`.
* **Analyse fine :** Analyse du `README.md` et des `README.md` des applications.
* **Analyse fine :** Analyse finement tous le documents de `IA_agents/`, `docs/`, de `todo/` et le code chaque application.

#### ⚙️ Getion de projet

* **Chiffrages :** Ne fait pas d'estimation du temps de réalisation.
* **Planning :** Ne fait pas de roadmap.

#### 🤝 Collaboration et Workflow

* **Ouverture aux modifications externes :** Comprendre et accepter que le projet puisse évoluer via des contributions extérieures.
* **Validation préalable :** Toute poussée de code (`git push`) ou déploiement doit être validée au préalable.
* **Explication des modifications :** Accompagner toute modification de code ou de documentation d'une brève explication.
* **Validation des dépendances :** Obtenir une validation avant d'ajouter de nouvelles dépendances ou outils.
* **Résultats attendus :** Ne liste pas les résultats attendus dans tes synthèses.
* **Résultats :** Ne présume pas de résultats non testés, ne conclue pas sans avoir de preuve ou de validation que c'est OK.
* **Commits :** Les commits doivent être exhaustifs et synthétiques avec `**Motivations :**` `**Modifications :**`, `**Page affectées :**` en bullets points, aucun besoin de totaux par exemple de fichiers modifiés ou de nombre de lignes.
* **Résumés et synthèses :** Les résumés d'actions et tes synthèses doivent être exhaustifs et synthétiques avec `**Motivations :**` `**Modifications :**`, `**Page affectées :**` en bullets points, aucun besoin de totaux par exemple de fichiers modifiés ou de nombre de lignes.
* **Rapports :** Ne fait pas de rapports apres tes actions.

#### ⚙️ Gestion de l'Environnement et des Configurations

* **Accès aux `.env` :** Les fichiers `.env` de production sont inaccessibles et ne doivent pas être modifiés.
* **Mise à jour de `env.example` :** Maintenir `env.example` systématiquement à jour et ne jamais intégrer de paramétrage sensible directement dans le code.
* **Ports :** Ne modifie jamais les ports même si il ne sont pas ceux par défaut.
* **Nginx :** Ne modifie jamaisles configurations Nginx
* **Configurations :** Privilégie les configuations en base de données plutôt que dans les `.env`.

#### 💻 Qualité du Code et Bonnes Pratiques

* **Respect des conventions :** Adhérer au style de code et aux conventions existantes du projet.
* **Sécurité :** Prioriser la sécurité en ne codant jamais en dur des informations sensibles (y compris dans la documentation) et en validant systématiquement les entrées utilisateur.
* **Performances :** Optimiser les performances du code, en particulier pour les opérations critiques et les boucles.
* **Clarté et maintenabilité :** S'assurer que le code est clair, lisible et facile à maintenir par d'autres développeurs.

#### Code

* **Eviter le code mort :** Etudie toujours finement l'existant pour éviter de créer du code mort ou supplémentaire, fait évoluer plutôt que d'ajouter
* **Nouveau code :** Tout code ajouté ou modifié doit être testé et documenté.
* **Lint :** Corrige les erreurs de lint, vérifie apres chaque fichier modifié
* **Fallbacks :** Ne fait pas et supprime les fallbacks
* **Fichiers de définition :** Génère automatiquement les fichiers de définition de type pour chaque fichier TypeScript compilé. Chaque module doit exposer explicitement ses types publics pour permettre l’interopérabilité et l’analyse statique par d’autres projets.
* **Répertoire de sortie des fichiers compilés :** la structure du code source doit être reproduite à l’identique des dossiers compilés afin d’assurer la traçabilité et la reproductibilité des builds.
* **Version ECMAScript :** le code doit rester compatible avec les navigateurs ou environnements qui supportent les fonctionnalités ESNext, ou être transpilé si nécessaire.
* **Bibliothèques et environnements :** Définit les bibliothèques intégrées utilisées par le compilateur pour fournir des types globaux (ex. objets DOM, APIs Web Worker). Tout code doit respecter les interfaces standardisées des environnements navigateur et worker.
* **types propres à Vite et à Node.js :** garantir que les modules supportent à la fois le contexte serveur (Node) et client (navigateur).
* **JavaScript (.js) :** Permet l’inclusion de fichiers JavaScript (.js) dans la compilation. Le code JavaScript inclus doit respecter les conventions TypeScript (noms, exports, compatibilité de types).
* **skipLibCheck :** Désactive la vérification de type interne des fichiers .d.ts des bibliothèques externes. Les dépendances doivent être validées manuellement lors des mises à jour pour éviter des erreurs de typage masquées.
* **Compatibilité automatique entre modules CommonJS et ESModules desactivée** tous les imports doivent être conformes à la sémantique native ECMAScript.
* **allowSyntheticDefaultImports** Autorise les imports par défaut même lorsque le module n’en expose pas formellement. Cette option simplifie la migration depuis CommonJS, mais doit être utilisée avec modération.
* **Mode strict :** Active le mode strict global, qui regroupe plusieurs sous-vérifications (null, any, this, etc.). Tout code doit passer sans avertissement en mode strict pour garantir la robustesse du typage.
* **noImplicitAny :**: Interdit l’utilisation implicite du type any. Tout type doit être explicitement déclaré ou inféré, garantissant la traçabilité sémantique.
* **noImplicitReturns :** Impose que toutes les branches de fonction retournent une valeur. Elimine les comportements indéterminés liés à des retours manquants.
* **noUnusedParameters :** Autorise les paramètres non utilisés. Ces paramètres doivent être nommés avec un préfixe conventionnel (_) pour indiquer l’intention d’ignorance.
* **exactOptionalPropertyTypes :**  Ne pas permettre une correspondance souple des propriétés optionnelles ({ a?: string } peut accepter {} ou { a: undefined }).
* **forceConsistentCasingInFileNames :**: Impose une casse cohérente entre les noms de fichiers importés et ceux présents sur le disque. Empêche les erreurs de casse entre systèmes de fichiers sensibles et insensibles (Windows, Linux).
* **ESNext :**  Utilise la syntaxe modulaire la plus récente. La structure des imports doit suivre le format standard ECMAScript, y compris pour les chemins relatifs.
* **Module Resolution :** la hiérarchie des node_modules doit être stable et conforme aux conventions de résolution.
* **resolveJsonModule :** Autorise l’import direct de fichiers JSON en tant que modules. Les JSON importés doivent être statiquement typés (via interfaces ou as const).
* **isolatedModules :** Oblige chaque fichier à pouvoir être transpilé indépendamment. Empêche les dépendances implicites entre fichiers et améliore la compatibilité.
* **experimentalDecorators :** Active le support expérimental des décorateurs (@decorator). Les décorateurs doivent être documentés et limités aux contextes maîtrisés (injection de dépendances, métaprogrammation contrôlée).
* **Chemins :** Utiliser des chemin relatifs et indiquer la racine du projet en configuration. Toutes les références internes doivent être relatives à la racine du projet. Vérifier de limiter l'acces en dehors du projet.

#### 🧪 Tests

* **Couverture des tests :** Rédiger des tests unitaires et d'intégration pour toute nouvelle fonctionnalité ou correction de bug.
* **Outils de test disponibles :** Utiliser `test-browser/` pour la simulation de navigateur et les commandes `curl` pour les tests d'API.
* **Playwright :** Pour chaque parcour impacter, créer des tests Playwright associés dans `test-browser/`.

#### 📚 Documentation

* **Objectif des travaux :** Se concentrer sur la réalisation de la liste des tâches décrite dans `todo/` dans des documents de type `todoX-desc.md`.
* **Travaux en cours:** Lorsqu'une todo est en cous `todo/` mettre à jour l'avancement de l'implémentation dans `TODOX-desc_IMPLEMENTATION.md`.
* **Travaux terminés :** Lorsqu'une todo est en cous `todo/` mettre à jour la desription finale de l'implémentation dans `TODOX-desc_IMPLEMENTATION_COMPLTE.md` et supprimer `TODOX-desc_IMPLEMENTATION.md`.
* **Structure de la documentation :**
  * La documentation générale et pérenne se trouve dans `docs/`.
  * La documentation spécifique à une situation ou un avancement se trouve dans `todo/`.
* **Utilisation de la documentation existante :** Ne pas ajouter de nouveaux documents, mais enrichir et mettre à jour l'existant.
* **Mise à jour continue :** Mettre à jour toute la documentation (`todo/`, `docs/` et commentaires dans le code) après les modifications ou pour clarifier.
* **Changelog :** Le fichier `CHANGELOG.md` de cette version en cours intègre toutes les todo dans todo/. Ce contenu est repris dans la slash notice de l'application front. Le `CHANGELOG.md` présente toutes les modifications de la version principale et les mises à jour mineurs sont ajoutée à l'update du `CHANGELOG.md` sans enlever d'élément.

#### 📊 Logging et Gestion des Erreurs

* **Centralisation des logs :** Centraliser les logs dans les répertoires `logs/` des applications et dans le répertoire `logs/` du projet pour les logs hors applications (déploiement par exemple)
* **Système de logging :** Implémenter une gestion d'erreurs robuste et utiliser le système de logging Winston pour toutes les sorties (info, warn, error, debug, etc.).
* **Traçabilité :** Logger toutes les valeurs, états clés et retours d'API.

#### 🌐 Interactions Externes (BDD, API, Emails)
* **APIs externes :** Gérer les interactions avec les API de manière appropriée, en respectant les limites d'utilisation et en gérant les erreurs.
* **Emails :** Gérer les envois d'emails de manière appropriée pour éviter le spam et gérer les erreurs.

### Base de données

* **Vigilence :** Être vigilant lors des interactions avec la base de données, notamment pour les migrations et les requêtes complexes.
* **Lecture seule :** N'écrit jamais en base, c'est la logique de code ou d'intégration/migration qui doit le faire.

#### 🚀 Déploiement

* **Préparation du déploiement :** Décrire et préparer le déploiement des correctifs et des évolutions.
* **Bilan de déloploiement :** ne fait pas de bilan de déploiement.
* **Lancement :** ne lance aucun déploiement sans demander avant

#### 🚨 Gestion des Problèmes

* **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.

#### 🗄️ Gestion des Fichiers

* **Versions uniques :** Ne pas créer de versions alternatives des fichiers.
* **Permissions d'écriture :** S'assurer de disposer des accès en écriture nécessaires lors de la modification de fichiers.

### Mise à jour de ces règles

* **Propositions d'ajouts :** Quand tu apprends de nouvelles instructions qui te semblent pertinentes pour ces règles, propose de les ajouter.

* **Lecture seule :** Tu n'a pas le droit de modifier ces règles, tu peux seulement proposer des ajouts, modifications

* **`CLAUDE.MD` :** Il s'agit de ce fichier la documentation est ici <https://claudecode.io/tutorials/claude-md-setup>, c'est ce fichier que tu peux mettre à jour au fil de l'eau.

### Application

* Indique l'IA que tu utilise
* Ce document constitue la check list que tu dois appliquer obligatoirement en amont et en aval de tes réponses.