235 lines
12 KiB
Plaintext
235 lines
12 KiB
Plaintext
# 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 `int-dev` 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 int-dev-dev mais toujours les version int-dev, 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.
|
||
|
||
## 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.
|
||
|
||
# Déploiement
|
||
|
||
Dans lecoffre_node en utilisant les scripts de scripts/ :
|
||
Il y a des branches git "int-dev", des images docker avec le tag "int-dev", pas de tag git "int-dev"
|
||
|
||
pour tous les projets avec des Dockerfile:
|
||
vérifie que le repos distant est public (si possible, non bloquant, pour info)
|
||
vérifie que tu peux utiliser tes clés ssh pour le déploiement sur git
|
||
vérifie que tu es sur la branche int-dev
|
||
met à jour les dépendances
|
||
vérifie les variables d'environnement
|
||
met à jour le Dockerfle pour une bonne maîtrise des pré-requis (intégre l'installation et la mise à jour avec un sudo apt udpate && sudo apt upgrade et jq curl sed awk telnet ping npm (dernière version) et wscat)
|
||
build le projet
|
||
met à jour la documentation
|
||
met à jour les tests
|
||
met à jour les scripts
|
||
vérifie .gitignore
|
||
vérifie .dockerignore
|
||
vérifie .cursorignore
|
||
synchronise les confs sur lecoffre_node/conf
|
||
synchronise les logs sur lecoffre_node/logs
|
||
pousse toutes les modifications sur la branche git "int-dev"
|
||
supprimer les fichiers distants non suivis sur le git
|
||
pousse sur la tag docker "int-dev" via la CI
|
||
analyse les logs
|
||
corrige les erreurs petites et grosses sans déscactivation, sans simplification, sans contournement
|
||
teste
|
||
analyse les logs
|
||
corrige les erreurs petites et grosses sans déscactivation, sans simplification, sans contournement
|
||
ne fait pas d'autres versions des scripts mais améliore ceux existant et teste les
|
||
met à jour avec ce retour d'expérience
|
||
recommence si besoin pour valider un déploiement parfait et fluide
|
||
si tu as appres quelque chose techniquement ou fonctionnement écris le dans les docs
|
||
synchronise les confs sur lecoffre_node/conf
|
||
synchronise les logs sur lecoffre_node/logs
|
||
pousse toutes les modifications sur la branche git "int-dev"
|
||
|
||
|
||
pour tous les projets avec des sans Dockerfile avec sur git:
|
||
vérifie que le repos distant est public (si possible, non bloquant, pour info)
|
||
vérifie que tu peux utiliser tes clés ssh pour le déploiement sur git
|
||
vérifie que tu es sur la branche int-dev
|
||
met à jour les dépendances
|
||
vérifie les variables d'environnement
|
||
met à jour le Dockerfle pour une bonne maîtrise des pré-requis (intégre l'installation et la mise à jour avec un sudo apt udpate && sudo apt upgrade et jq curl sed awk telnet ping npm (dernière version) et wscat)
|
||
build le projet
|
||
met à jour la documentation
|
||
met à jour les tests
|
||
met à jour les scripts
|
||
vérifie .gitignore
|
||
vérifie .dockerignore
|
||
vérifie .cursorignore
|
||
synchronise les confs sur lecoffre_node/conf
|
||
synchronise les logs sur lecoffre_node/logs
|
||
pousse toutes les modifications sur la branche git "int-dev"
|
||
supprimer les fichiers distants non suivis sur le git
|
||
analyse les logs
|
||
corrige les erreurs petites et grosses sans déscactivation, sans simplification, sans contournement
|
||
teste
|
||
analyse les logs
|
||
corrige les erreurs petites et grosses sans déscactivation, sans simplification, sans contournement
|
||
ne fait pas d'autres versions des scripts mais améliore ceux existant et teste les
|
||
met à jour avec ce retour d'expérience
|
||
recommence si besoin pour valider un déploiement parfait et fluide
|
||
si tu as appres quelque chose techniquement ou fonctionnement écris le dans les docs
|
||
synchronise les confs sur lecoffre_node/conf
|
||
synchronise les logs sur lecoffre_node/logs
|
||
pousse toutes les modifications sur la branche git "int-dev"
|