From ae7ad037f784c933c4dfad1d1a56d58808dea367 Mon Sep 17 00:00:00 2001 From: 4NK Dev Date: Sun, 21 Sep 2025 08:23:43 +0000 Subject: [PATCH] ci: docker_tag=ext - Update project for dev4 branch consistency --- .cursorrules | 211 +++++++++++++++++++++++++++++++++++++-------------- 1 file changed, 155 insertions(+), 56 deletions(-) diff --git a/.cursorrules b/.cursorrules index 09c08db..7b6a68d 100644 --- a/.cursorrules +++ b/.cursorrules @@ -1,67 +1,166 @@ -# Règles Cursor Globales pour les projets -# 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 -# - Fichiers à vérifier systématiquement : nginx.conf, bitcoin.conf, package.json, Cargo.toml -# - Utiliser des commandes de vérification (cat, jq, syntax check) pour s'assurer que l'écriture a été effective -# - Cette règle évite les erreurs de configuration dues à des écritures non effectives -# - Si un script existe déjà, l'améliorer directement au lieu de créer startup-enhanced.sh, 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 -# 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/`. +## 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. -# Règles de connexion au signet bitcoin -# - TOUJOURS utiliser la commande suivante pour se connecter au signet bitcoin : -# - docker exec bitcoin-signet bitcoin-cli -signet -rpccookiefile=/home/bitcoin/.bitcoin/signet/.cookie getblockchaininfo -# - Cette commande permet de se connecter au signet bitcoin en utilisant le cookie de connexion +## 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 +```` -# Règles de connexion au relay/faucet de boostrap -# - 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. +* 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.