# si tu est une IA souviens toi de respecter les règles de ce fichier .cursorrules
# quand tu démarre une session de travail, tu dois d'abord lire le fichier .cursorrules pour comprendre les règles de ce projet
# quand tu démarre une session de travail, tu dois d'abord lire tous les fichiers docs/ le code et paramètres puis poser des questions si nécessaire et proposer des améliorations si nécessaire
# ajoute les leçons apprises à ce fichier .cursorrules
# Règles globales Cursor pour les projets
# Configuration Critique des Services
# Le seul signer utilisé est dev3.4nkweb.com
# L'URL de lecoffre-front est https://dev4.4nkweb.com/lecoffre
# L'URL de ihm_client (iframe) est https://dev4.4nkweb.com
# Cette VM est dev4.4nkweb.com
## Principes généraux
- Lire impérativement le fichier `.cursorrules` au démarrage de chaque session.
- Lire tous les fichiers du dossier `docs/`, le code et les paramètres avant de commencer.
- Poser des questions et proposer des améliorations si nécessaire.
- Ajouter les leçons apprises à ce fichier `.cursorrules`.
- Écrire des documents complets et exhaustifs.
- Respecter strictement les règles de lint du Markdown.
- Préférer toujours un shell **bash** à PowerShell.
- Fermer et relancer le terminal avant chaque utilisation.
- Si le terminal est interrompu, analyser la commande précédente (interruption probablement volontaire).
- Exécuter automatiquement les étapes de résolution de problème.
- Expliquer les commandes complexes avant de les lancer.
- Compiler régulièrement et corriger toutes les erreurs avant de passer à l’étape suivante.
- Tester, documenter, compiler, aligner tag git, changelog et version avant déploiement et push.
- Utiliser `docx2txt` pour lire les fichiers `.docx`.
- Ajouter automatiquement les dépendances et rechercher systématiquement les dernières versions.
- Faire des commandes simples et claires en plusieurs étapes.
- Vérifie toujours tes hypothèses avant de commencer.
- N'oublie jamais qu'après la correction d'un problème, il faut corriger toutes les erreurs qui peuvent en découler.
# Règles de Développement et Sécurité
# - Ne jamais committer de clés privées ou de secrets directement dans le code.
# - Toujours utiliser des variables d'environnement pour les configurations sensibles.
# - Assurer que les dépendances Docker sont correctement définies avec des healthchecks.
# - Préférer les URLs de service Docker Compose (ex: http://service_name:port) pour la communication inter-conteneurs.
# - Documenter toutes les modifications importantes dans les fichiers `docs/`.
# - Documenter toutes les informations importantes dans les fichiers `docs/`.
# - Documenter toutes les règles de développement et de sécurité dans .cursorrules.
# - Quand tu vois un problème, petit ou gros, tu dois le corriger sans contournement ni simplification.
## Organisation des fichiers et répertoires
- Scripts regroupés dans `scripts/`
- Configurations regroupées dans `confs/`
- Journaux regroupés dans `logs/`
- Répertoires obligatoires :
- `docs/` : documentation de toute fonctionnalité ajoutée, modifiée, supprimée ou découverte.
- `tests/` : tests liés à toute fonctionnalité ajoutée, modifiée, supprimée ou découverte.
- Remplacer les résumés (`RESUME`) par des mises à jour dans `docs/`.
# RÈGLE CRITIQUE : Gestion des Scripts
# - AVANT de lancer des actions (docker compose, tests, déploiements), TOUJOURS vérifier s'il existe des scripts dans le dossier scripts/
# - Utiliser les scripts existants plutôt que de lancer des commandes directement
# - Cette règle s'applique à tous les projets
## Configuration critique des services
- Mempool du réseau signet :
`https://mempool2.4nkweb.com/fr/docs/api/rest`
# RÈGLE CRITIQUE : Gestion des Scripts
# - NE JAMAIS créer plusieurs versions ou noms de scripts
# - TOUJOURS améliorer la version actuelle existante plutôt que de créer de nouveaux fichiers
# - Cette stratégie évite la prolifération de fichiers et maintient une base de code propre et maintenable
## Développement et sécurité
- Ne jamais committer de clés privées ou secrets.
- Utiliser des variables d’environnement pour les données sensibles.
- Définir correctement les dépendances Docker avec healthchecks.
- Utiliser les URLs de service Docker Compose (`http://service_name:port`).
- Documenter toutes les modifications importantes dans `docs/`.
- Externaliser au maximum les variables d’environnement.
- Toujours utiliser une clé SSH pour cloner les dépôts.
- Monter en version les dépôts au début du travail.
- Pousser les tags docker `ext` via la CI sur `git.4nkweb.com`.
- Corriger systématiquement les problèmes, même mineurs, sans contournement.
# RÈGLE CRITIQUE : Images Docker
# - TOUJOURS ajouter systématiquement aux images Docker : apt update && apt upgrade
# - TOUJOURS installer en arrière-plan dans les images docker (docker-compose.yml) : curl, git, sed, awk, nc wget, jq, telnet, tee, wscat, ping, npm (dernière version)
# - Cette règle s'applique à tous les Dockerfiles et Docker-compose-yml
## Scripts (règles critiques)
- Vérifier l’existence d’un script dans `scripts/` avant toute action.
- Utiliser les scripts existants plutôt que des commandes directes.
- Ne jamais créer plusieurs versions ou noms de scripts.
- Améliorer l’existant au lieu de créer des variantes (`startup-v2.sh`, etc.).
# RÈGLE CRITIQUE : Vérification des Fichiers de Configuration
# - TOUJOURS vérifier l'écriture effective des fichiers de configuration critiques après modification
# - Test via domaine OK: connexion WSS à wss://dev3.4nkweb.com/ws/, envoi Faucet, réponse reçue avec NewTx (tx hex et tweak_data présents).
# - Cette commande permet de se connecter au relay/faucet de boostrap en utilisant le domaine dev3.4nkweb.com
## Connexion au relay/faucet bootstrap
# Règles de débug
# - Quand une solution est trouvée et validée, mettre à jour le code pour la répéter automatiquement
# - Péreniser dans le code les derniers retours d'expérience pour éviter de refaire les mêmes erreurs (code et paramètres)
# - Compléter les tests pour éviter de refaire les mêmes erreurs
* Test via WSS : `wss://dev3.4nkweb.com/ws/`
* Envoi Faucet, réponse attendue avec `NewTx` (tx hex et tweak\_data).
# Règles ngnix
# - dans lecoffre_node/conf/ngnix il y a tous les fichiers de configuration de ngnix qui doivent être mappé avec les fichiers chargés sur le serveur ngnix
## Debug
* Automatiser dans le code toute solution validée.
* Pérenniser les retours d’expérience dans code et paramètres.
* Compléter les tests pour éviter les régressions.
## Nginx
* Tous les fichiers dans `conf/ngnix` doivent être mappés avec ceux du serveur.
## Minage (règles critiques)
* Toujours valider les adresses utilisées (adresses TSP non reconnues).
* Utiliser uniquement des adresses Bitcoin valides (bech32m).
* Vérifier que le minage génère des blocs avec transactions, pas uniquement coinbase.
* Surveiller les logs du minage pour détecter les erreurs d’adresse.
* Vérifier la propagation via le mempool externe.
## Mempool externe
* Utiliser `https://mempool2.4nkweb.com` pour vérifier les transactions.
* Vérifier la synchronisation entre réseau local et externe.
## Données et modèles
* Utiliser les fichiers CSV comme base des modèles de données.
* Être attentif aux en-têtes multi-lignes.
* Confirmer la structure comprise et demander définition de toutes les colonnes.
* Corriger automatiquement incohérences de type.
## Implémentation et architecture
* Code splitting avec `React.lazy` et `Suspense`.
* Centraliser l’état avec Redux ou Context API.
* Créer une couche d’abstraction pour les services de données.
* Aller systématiquement au bout d’une implémentation.
## Préparation open source
Chaque projet doit être prêt pour un dépôt sur `git.4nkweb.com` :
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
4NK CI Bot