# 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. * **Données vérifiées :** Vérifiant que les logs reflètent des vérifications réelles et non des déclarations. * **Log abondamment :** Log les informations et étapes ou états clés ainsi que les identifiants clés. #### 🌐 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 , 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.