diff --git a/.cursorrules b/.cursorrules index e411ba3..12756f2 100644 --- a/.cursorrules +++ b/.cursorrules @@ -1,63 +1,165 @@ -# Règles Cursor pour SDK Relay +# Règles globales Cursor pour les projets -## Configuration du Service +## 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. -### Dépendances -- **sdk_common** : Doit être cloné depuis la branche `dev` -- **blindbit-oracle** : Service oracle local -- **bitcoin-signet** : Nœud Bitcoin Signet +## 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/`. -### Dockerfile -```dockerfile -# Cloner sdk_common depuis la branche dev (OBLIGATOIRE) -RUN --mount=type=ssh git clone -b dev ssh://git@git.4nkweb.com/4nk/sdk_common.git /sdk_common -``` +## Configuration critique des services +- Mempool du réseau signet : + `https://mempool2.4nkweb.com/fr/docs/api/rest` -### Configuration -- **Fichier** : `sdk_relay.conf` -- **blindbit_url** : `http://blindbit-oracle:8000` +## 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. -### Variables d'Environnement -```yaml -environment: - - SDK_RELAY_SCAN_TIMEOUT=300 - - SDK_RELAY_STARTUP_MODE=async -``` +## 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.). -### Ports -- **8090** : WebSocket server -- **8091** : Health server +## 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 -### Healthcheck -```yaml -healthcheck: - test: ["CMD", "sh", "-c", "curl -f http://localhost:8091/ | grep -q '\"status\":\"ok\"'"] - interval: 15s - timeout: 10s - retries: 5 - start_period: 60s -``` +## 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 Développement +## 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 +```` -### Build CI -- Le CI doit cloner sdk_common depuis Git (pas de COPY local) -- Utiliser la branche `dev` de sdk_common -- Vérifier que toutes les features nécessaires sont disponibles +## Connexion au relay/faucet bootstrap -### Problèmes Connus -1. **Scan bloquant** : Le service peut se bloquer pendant le scan des blocs - - Solution : Modifier `last_scan` dans `/home/bitcoin/.4nk/default` - - Solution : Utiliser des healthchecks avec start_period approprié +* Test via WSS : `wss://dev3.4nkweb.com/ws/` +* Envoi Faucet, réponse attendue avec `NewTx` (tx hex et tweak\_data). -2. **Build context** : Le CI échoue si sdk_common n'est pas dans le contexte - - Solution : Cloner depuis Git au lieu de COPY local +## Debug -### Documentation -- Mettre à jour docs/CONFIGURATION.md après chaque modification -- Documenter les problèmes résolus et leurs solutions -- Conserver l'historique des changements +* 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. -## Historique -- Créé le 20/09/2025 -- Configuration SDK Relay +## 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. diff --git a/.cursorrules copy b/.cursorrules copy deleted file mode 100644 index 09c08db..0000000 --- a/.cursorrules copy +++ /dev/null @@ -1,67 +0,0 @@ -# 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 - -# 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 - -# 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. - -# 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 - -# 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 - -# 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 - -# 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. - -# 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/`. - -# 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 - -# 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 - -# 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 - -# 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 diff --git a/.gitea/workflows/build-ext.yml b/.gitea/workflows/build-ext.yml index 476e578..1214a3f 100644 --- a/.gitea/workflows/build-ext.yml +++ b/.gitea/workflows/build-ext.yml @@ -71,6 +71,3 @@ jobs: run: | set -euo pipefail docker push git.4nkweb.com/4nk/sdk_relay:${{ steps.tag.outputs.TAG }} - - - diff --git a/CHANGELOG.md b/CHANGELOG.md index 544ae7a..6f86920 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -34,3 +34,6 @@ Format inspiré de Keep a Changelog et versionnage SemVer. ## [0.1.1] - 2025-09-19 - Alignement initial pour publication interne et préparation open source +## [0.1.3] - 2025-09-21 +- Fix: Gestion des fichiers JSON vides dans StateFile::load() +- Fix: Résolution de l'erreur 'invalid type: sequence, expected a map' diff --git a/src/main.rs b/src/main.rs index 1f92638..a03f982 100644 --- a/src/main.rs +++ b/src/main.rs @@ -141,6 +141,11 @@ impl StateFile { let mut content = vec![]; f.read_to_end(&mut content)?; + // Handle empty files or invalid JSON gracefully + if content.is_empty() { + return Ok(serde_json::Value::Object(serde_json::Map::new())); + } + let res: Value = serde_json::from_slice(&content)?; Ok(res)