# Règles globales Cursor pour les projets ## 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. ## 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/`. ## Configuration critique des services - Mempool du réseau signet : `https://mempool2.4nkweb.com/fr/docs/api/rest` ## 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. ## 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.). ## Images Docker (règles critiques) - Ajouter systématiquement `apt update && apt upgrade` dans les Dockerfiles. - Installer en arrière-plan dans les images Docker : `curl, git, sed, awk, nc, wget, jq, telnet, tee, wscat, ping, npm (dernière version)` - Appliquer à tous les Dockerfiles et `docker-compose.yml`. - N'utilise pas les version test ou dev ou ext-dev mais toujours les version ext, relance leur compilation si nécessaire ## Fichiers de configuration (règles critiques) - Vérifier l’écriture effective après chaque modification. - Fichiers concernés : `nginx.conf`, `bitcoin.conf`, `package.json`, `Cargo.toml`. - Utiliser `cat`, `jq` ou vérificateurs de syntaxe. ## Connexion au réseau Bitcoin signet Commande unique et obligatoire : ```bash docker exec bitcoin-signet bitcoin-cli -signet -rpccookiefile=/home/bitcoin/.bitcoin/signet/.cookie getblockchaininfo ```` ## Connexion au relay/faucet bootstrap * Test via WSS : `wss://dev3.4nkweb.com/ws/` * Envoi Faucet, réponse attendue avec `NewTx` (tx hex et tweak\_data). ## 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. * Toujours tout corriger sans contournement, sans desactivation, sans simplification ## 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` : * Inclure : `LICENSE` (MIT, Apache 2.0 ou GPL), `CONTRIBUTING.md`, `CHANGELOG.md`, `CODE_OF_CONDUCT.md`. * Aligner documentation et tests avec `4NK_node`. ## Versioning et documentation * Mettre à jour documentation et tests systématiquement. * Gérer versioning avec changelog. * Demander validation avant tag. * Documenter les hypothèses testées dans un REX technique. * Tester avant tout commit. * Tester les buildsavant tout tag. ## Bonnes pratiques de confidentialité et sécurité ### Docker - Ne jamais stocker de secrets (clés, tokens, mots de passe) dans les Dockerfiles ou docker-compose.yml. - Utiliser des fichiers `.env` sécurisés (non commités avec copie en .env.example) pour toutes les variables sensibles. - Ne pas exécuter de conteneurs avec l’utilisateur root, privilégier un utilisateur dédié. - Limiter les capacités des conteneurs (option `--cap-drop`) pour réduire la surface d’attaque. - Scanner régulièrement les images Docker avec un outil de sécurité (ex : Trivy, Clair). - Mettre à jour en continu les images de base afin d’éliminer les vulnérabilités. - Ne jamais exposer de ports inutiles. - Restreindre les volumes montés au strict nécessaire. - Utiliser des réseaux Docker internes pour la communication inter-containers. - Vérifier et tenir à jour les .dockerignore. ### Git - Ne jamais committer de secrets, clés ou identifiants (même temporairement). - Configurer des hooks Git (pre-commit) pour détecter automatiquement les secrets et les failles. - Vérifier l’historique (`git log`, `git filter-repo`) pour s’assurer qu’aucune information sensible n’a été poussée. - Signer les commits avec GPG pour garantir l’authenticité. - Utiliser systématiquement SSH pour les connexions à distance. - Restreindre les accès aux dépôts (principes du moindre privilège). - Documenter les changements sensibles dans `CHANGELOG.md`. - Ne jamais pousser directement sur `main` ou `master`, toujours passer par des branches de feature ou PR. - Vérifier et tenir à jour les .gitignore. - Vérifier et tenir à jour les .gitkeep. - Vérifier et tenir à jour les .gitattributes. ### Cursor - Toujours ouvrir une session en commençant par relire le fichier `.cursorrules`. - Vérifier que Cursor ne propose pas de commit contenant des secrets ou fichiers sensibles. - Ne pas exécuter dans Cursor de commandes non comprises ou copiées sans vérification. - Préférer l’utilisation de scripts audités dans `scripts/` plutôt que des commandes directes dans Cursor. - Fermer et relancer Cursor régulièrement pour éviter des contextes persistants non désirés. - Ne jamais partager le contenu du terminal ou des fichiers sensibles via Cursor en dehors du périmètre du projet. - Vérifier et tenir à jour les .cursorrules. - Vérifier et tenir à jour les .cursorignore.