ihm_client/IA_agents/all.md

IHM_CLIENT

voir README.md

voir docs/INITIALIZATION_FLOW.md

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