NicolasCantu
9b5e1b68b6
**Motivations :** - La documentation doit refléter les améliorations récentes sur les vérifications réelles des logs - Documenter le nouveau flux avec block-sync et les vérifications des prérequis - Documenter le système de vérification réelle des logs pour faciliter la maintenance **Modifications :** - Ajout d'une section détaillée sur les vérifications des prérequis dans birthday-setup - Documentation des vérifications réelles dans updateDeviceBlockHeight - Documentation des vérifications réelles dans saveDeviceInDatabase - Ajout de la section sur la redirection vers block-sync - Mise à jour du diagramme de flux pour inclure block-sync et les vérifications - Ajout d'une section complète sur le système de vérification réelle des logs - Mise à jour de la gestion des erreurs avec les erreurs de vérification - Ajout de points d'attention sur les vérifications réelles et block-sync **Pages affectées :** - docs/INITIALIZATION_FLOW.md (documentation complète mise à jour)
122 lines
8.0 KiB
Markdown
122 lines
8.0 KiB
Markdown
# 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 <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.
|