ihm_client/IA_agents/all.md

# Lecoffre

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

#### 🧪 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.
* **Script de déploiement :** le déploiment passe par `deploy-remote.sh`, ne masque pas la sortie (pas de 2>&1 pas exemple).
* **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.