docs(template): rendre les documents génériques avec placeholders <PROJECT_NAME> et URLs

This commit is contained in:
Nicolas Cantu 2025-08-27 11:46:50 +02:00
parent b8264a6b75
commit 2e4feb03ca
12 changed files with 49 additions and 874 deletions

View File

@ -1,10 +1,10 @@
# Référence API - 4NK Node # Référence API - <PROJECT_NAME>
Ce document est un modèle. Il doit être adapté par chaque projet dérivé. Il documente les APIs de l'infrastructure (RPC, HTTP, WebSocket) et doit rester cohérent avec la version publiée (`TEMPLATE_VERSION`) et le `CHANGELOG.md`. Ce document est un modèle. Il doit être adapté par chaque projet dérivé. Il documente les APIs de l'infrastructure (RPC, HTTP, WebSocket) et doit rester cohérent avec la version publiée (`TEMPLATE_VERSION`) et le `CHANGELOG.md`.
## Vue d'Ensemble des APIs ## Vue d'Ensemble des APIs
L'infrastructure 4NK Node expose plusieurs interfaces pour différents types d'interactions : L'infrastructure <PROJECT_NAME> expose plusieurs interfaces pour différents types d'interactions :
- **Bitcoin Core RPC** : Interface JSON-RPC pour Bitcoin - **Bitcoin Core RPC** : Interface JSON-RPC pour Bitcoin
- **Blindbit HTTP** : API REST pour les paiements silencieux - **Blindbit HTTP** : API REST pour les paiements silencieux

View File

@ -1,9 +1,9 @@
# Architecture Technique - 4NK Node # Architecture Technique - <PROJECT_NAME>
## Vue d'Ensemble de l'Architecture ## Vue d'Ensemble de l'Architecture
Ce document sert de modèle. Il doit être complété par chaque projet dérivé du template 4NK. Ce document sert de modèle générique. Il doit être adapté par chaque projet dérivé de ce template.
### Architecture Générale ### Architecture Générale

View File

@ -1,12 +1,12 @@
# Configuration Gitea - 4NK Node # Configuration Gitea - <PROJECT_NAME>
Ce guide explique comment configurer le projet 4NK Node spécifiquement pour Gitea (git.4nkweb.com). Ce guide explique comment configurer votre projet (<PROJECT_NAME>) sur une forge Gitea (adaptable à GitHub/GitLab).
## 🎯 Configuration Gitea ## 🎯 Configuration Gitea
### Repository Configuration ### Repository Configuration
Le projet est hébergé sur : **https://git.4nkweb.com/4nk/4NK_node** Le projet est hébergé sur : **<REPO_URL>**
Note: ce dépôt est un modèle. Les projets dérivés doivent conserver la CI et les règles Cursor (dont le job `release-guard`). Note: ce dépôt est un modèle. Les projets dérivés doivent conserver la CI et les règles Cursor (dont le job `release-guard`).
@ -40,7 +40,7 @@ Si votre instance Gitea supporte Gitea Actions :
```yaml ```yaml
# .gitea/workflows/ci.yml # .gitea/workflows/ci.yml
name: CI - 4NK Node name: CI - <PROJECT_NAME>
on: on:
push: push:
@ -133,7 +133,7 @@ Utilisez l'API Gitea pour l'automatisation :
```bash ```bash
# Exemple : Créer une release # Exemple : Créer une release
curl -X POST "https://git.4nkweb.com/api/v1/repos/4nk/<project>/releases" \ curl -X POST "https://<REPO_HOST>/api/v1/repos/<ORG_NAME>/<PROJECT_SLUG>/releases" \
-H "Authorization: token YOUR_TOKEN" \ -H "Authorization: token YOUR_TOKEN" \
-H "Content-Type: application/json" \ -H "Content-Type: application/json" \
-d '{ -d '{
@ -209,11 +209,11 @@ Stockez les secrets sensibles dans les variables d'environnement Gitea :
```bash ```bash
# Fork sur Gitea # Fork sur Gitea
# Puis clone # Puis clone
git clone https://git.4nkweb.com/votre-username/<project>.git git clone https://<REPO_HOST>/<USERNAME>/<PROJECT_SLUG>.git
cd 4NK_node cd <PROJECT_DIR>
# Ajouter l'upstream # Ajouter l'upstream
git remote add upstream https://git.4nkweb.com/4nk/<project>.git git remote add upstream https://<REPO_HOST>/<ORG_NAME>/<PROJECT_SLUG>.git
``` ```
### 2. Développement ### 2. Développement
@ -283,4 +283,4 @@ events:
--- ---
**Configuration Gitea terminée ! Le projet est prêt pour l'open source sur git.4nkweb.com** 🚀 **Configuration Gitea terminée ! Le projet est prêt pour l'open source sur votre forge** 🚀

View File

@ -1,6 +1,6 @@
# 📚 Index de Documentation - 4NK Node # 📚 Index de Documentation - <PROJECT_NAME>
Index complet de la documentation de l'infrastructure 4NK Node. Index complet de la documentation de l'infrastructure <PROJECT_NAME>.
## 📖 Guides Principaux ## 📖 Guides Principaux
@ -272,21 +272,21 @@ Questions fréquemment posées.
- **Troubleshooting** : [TROUBLESHOOTING.md](TROUBLESHOOTING.md) - Résolution de problèmes - **Troubleshooting** : [TROUBLESHOOTING.md](TROUBLESHOOTING.md) - Résolution de problèmes
### Ressources Externes ### Ressources Externes
- **Repository** : [GitLab 4NK Node](https://git.4nkweb.com/4nk/4NK_node) - **Repository** : <REPO_URL>
- **Issues** : [Issues GitLab](https://git.4nkweb.com/4nk/4NK_node/issues) - **Issues** : <REPO_ISSUES_URL>
- **Wiki** : [Wiki GitLab](https://git.4nkweb.com/4nk/4NK_node/wikis) - **Wiki** : <REPO_WIKI_URL>
### Contact ### Contact
- **Email** : support@4nkweb.com - **Email** : <SUPPORT_EMAIL>
- **Chat** : [Discord 4NK](https://discord.gg/4nk) - **Chat** : <CHAT_URL>
- **Forum** : [Forum 4NK](https://forum.4nkweb.com) - **Forum** : <FORUM_URL>
## 🔄 Mise à Jour de la Documentation ## 🔄 Mise à Jour de la Documentation
### Dernière Mise à Jour ### Dernière Mise à Jour
- **Date** : générée à la release - **Date** : générée à la release
- **Version** : pilotée par `TEMPLATE_VERSION` et `CHANGELOG.md` - **Version** : pilotée par `TEMPLATE_VERSION` et `CHANGELOG.md`
- **Auteur** : Équipe 4NK - **Auteur** : <ORG_NAME>
### Historique des Versions ### Historique des Versions
- **v1.0.0** : Documentation initiale complète - **v1.0.0** : Documentation initiale complète

View File

@ -1,6 +1,8 @@
# 📦 Guide d'Installation - 4NK Node # 📦 Guide d'Installation - <PROJECT_NAME>
Guide complet pour installer et configurer l'infrastructure 4NK Node. > Ce document est un modèle générique. Remplacez <PROJECT_NAME>, <ORG_NAME>, <REPO_SSH_URL>, <REPO_HTTPS_URL> et adaptez les sections à votre contexte (Gitea/GitHub/GitLab).
Guide complet pour installer et configurer l'infrastructure <PROJECT_NAME>.
## 📋 Prérequis ## 📋 Prérequis
@ -86,7 +88,7 @@ git config --global core.sshCommand "ssh -i ~/.ssh/id_ed25519_4nk"
cat ~/.ssh/id_ed25519_4nk.pub cat ~/.ssh/id_ed25519_4nk.pub
``` ```
**Ajouter la clé publique à GitLab :** **Ajouter la clé publique à votre forge Git (Gitea/GitHub/GitLab) :**
1. Aller sur GitLab > Settings > SSH Keys 1. Aller sur GitLab > Settings > SSH Keys
2. Coller la clé publique 2. Coller la clé publique
3. Cliquer sur "Add key" 3. Cliquer sur "Add key"
@ -95,12 +97,12 @@ cat ~/.ssh/id_ed25519_4nk.pub
```bash ```bash
# Cloner avec SSH (recommandé) # Cloner avec SSH (recommandé)
git clone git@git.4nkweb.com:4nk/4NK_node.git git clone <REPO_SSH_URL>
cd 4NK_node cd <PROJECT_DIR>
# Ou avec HTTPS (si SSH non configuré) # Ou avec HTTPS (si SSH non configuré)
# git clone https://git.4nkweb.com/4nk/4NK_node.git # git clone <REPO_HTTPS_URL>
# cd 4NK_node # cd <PROJECT_DIR>
``` ```
### 4. Vérification de l'Installation ### 4. Vérification de l'Installation
@ -110,8 +112,8 @@ cd 4NK_node
docker --version docker --version
docker-compose --version docker-compose --version
# Vérifier la connectivité GitLab # Vérifier la connectivité à votre forge (si SSH)
ssh -T git@git.4nkweb.com ssh -T git@<REPO_HOST>
# Vérifier les permissions # Vérifier les permissions
ls -la ls -la
@ -124,8 +126,8 @@ ls -la
```bash ```bash
# Créer le fichier d'environnement # Créer le fichier d'environnement
cat > .env << EOF cat > .env << EOF
# Configuration 4NK Node # Configuration projet
PROJECT_NAME=4NK Node PROJECT_NAME=<PROJECT_NAME>
NETWORK_NAME=4nk_node_btcnet NETWORK_NAME=4nk_node_btcnet
# Logs # Logs

View File

@ -1,378 +0,0 @@
# 🔄 Guide de Migration - Documentation 4NK Node
Guide pour migrer et organiser la documentation existante vers la nouvelle structure.
## 📋 État Actuel
### Fichiers de Documentation Existants
#### Documentation Principale
- `README.md` - Documentation principale (mis à jour)
- `EXEMPLES_PRATIQUES.md` - Exemples d'utilisation (à migrer)
#### Documentation Technique
- `specs/spec-technique.md` - Spécification technique (à conserver)
- `specs/spec-fonctionnel.md` - Spécification fonctionnelle (à conserver)
- `specs/spec-technical.md` - Spécification technique (à fusionner)
#### Documentation de Configuration
- `CONFIGURATION_DEV3.md` - Configuration dev3.4nkweb.com (à migrer)
- `INTEGRATION_DEV3_FINAL.md` - Intégration dev3.4nkweb.com (à migrer)
#### Documentation de Processus
- `COMMANDES_REDEMARRAGE.md` - Commandes de redémarrage (à migrer)
- `RESUME_AJOUT_DEV3.md` - Résumé ajout dev3 (à migrer)
- `RESUME_DECOUVERTE_NOEUDS.md` - Découverte des nœuds (à migrer)
- `RESUME_SCRIPT_RESTART.md` - Script de redémarrage (à migrer)
- `RESUME_TEST_3_RELAIS.md` - Test 3 relais (à migrer)
#### Documentation de Scripts
- `README_RESTART_SCRIPT.md` - Documentation script redémarrage (à migrer)
- `explain_node_discovery.md` - Explication découverte nœuds (à migrer)
## 🎯 Plan de Migration
### 1. Structure de Documentation
```
4NK_node/
├── README.md # ✅ Mis à jour
├── docs/ # ✅ Nouvelle structure
│ ├── INDEX.md # ✅ Créé
│ ├── INSTALLATION.md # ✅ Créé
│ ├── USAGE.md # ✅ Créé
│ ├── CONFIGURATION.md # ✅ Créé
│ ├── QUICK_REFERENCE.md # ✅ Créé
│ ├── MIGRATION.md # ✅ Ce fichier
│ ├── ARCHITECTURE.md # 🔄 À créer
│ ├── API.md # 🔄 À créer
│ ├── SECURITY.md # 🔄 À créer
│ ├── PERFORMANCE.md # 🔄 À créer
│ ├── TESTING.md # 🔄 À créer
│ ├── SYNC_TESTING.md # 🔄 À créer
│ ├── PERFORMANCE_TESTING.md # 🔄 À créer
│ ├── RELAY_NETWORK.md # 🔄 À créer
│ ├── EXTERNAL_NODES.md # 🔄 À créer
│ ├── SYNCHRONIZATION.md # 🔄 À créer
│ ├── TROUBLESHOOTING.md # 🔄 À créer
│ └── FAQ.md # 🔄 À créer
├── specs/ # ✅ À conserver
│ ├── spec-technique.md # ✅ Conserver
│ └── spec-fonctionnel.md # ✅ Conserver
├── archive/ # 🔄 À créer
│ ├── docs/ # 🔄 Anciens fichiers
│ └── README.md # 🔄 Documentation archive
└── examples/ # 🔄 À créer
├── configuration/ # 🔄 Exemples de config
├── scripts/ # 🔄 Scripts d'exemple
└── tests/ # 🔄 Tests d'exemple
```
### 2. Migration des Fichiers
#### Fichiers à Migrer vers `docs/`
| Fichier Source | Destination | Statut |
|----------------|-------------|---------|
| `EXEMPLES_PRATIQUES.md` | `docs/USAGE.md` | ✅ Intégré |
| `CONFIGURATION_DEV3.md` | `docs/EXTERNAL_NODES.md` | 🔄 À migrer |
| `INTEGRATION_DEV3_FINAL.md` | `docs/EXTERNAL_NODES.md` | 🔄 À migrer |
| `COMMANDES_REDEMARRAGE.md` | `docs/QUICK_REFERENCE.md` | ✅ Intégré |
| `RESUME_AJOUT_DEV3.md` | `docs/EXTERNAL_NODES.md` | 🔄 À migrer |
| `RESUME_DECOUVERTE_NOEUDS.md` | `docs/RELAY_NETWORK.md` | 🔄 À migrer |
| `RESUME_SCRIPT_RESTART.md` | `docs/QUICK_REFERENCE.md` | ✅ Intégré |
| `RESUME_TEST_3_RELAIS.md` | `docs/SYNC_TESTING.md` | 🔄 À migrer |
| `README_RESTART_SCRIPT.md` | `docs/QUICK_REFERENCE.md` | ✅ Intégré |
| `explain_node_discovery.md` | `docs/RELAY_NETWORK.md` | 🔄 À migrer |
#### Fichiers à Conserver
| Fichier | Raison | Action |
|---------|--------|---------|
| `specs/spec-technique.md` | Documentation technique détaillée | ✅ Conserver |
| `specs/spec-fonctionnel.md` | Spécification fonctionnelle | ✅ Conserver |
| `specs/spec-technical.md` | Spécification technique | 🔄 Fusionner avec spec-technique.md |
#### Fichiers à Archiver
| Fichier | Action |
|---------|--------|
| `EXEMPLES_PRATIQUES.md` | 🔄 Déplacer vers `archive/docs/` |
| `CONFIGURATION_DEV3.md` | 🔄 Déplacer vers `archive/docs/` |
| `INTEGRATION_DEV3_FINAL.md` | 🔄 Déplacer vers `archive/docs/` |
| `COMMANDES_REDEMARRAGE.md` | 🔄 Déplacer vers `archive/docs/` |
| `RESUME_AJOUT_DEV3.md` | 🔄 Déplacer vers `archive/docs/` |
| `RESUME_DECOUVERTE_NOEUDS.md` | 🔄 Déplacer vers `archive/docs/` |
| `RESUME_SCRIPT_RESTART.md` | 🔄 Déplacer vers `archive/docs/` |
| `RESUME_TEST_3_RELAIS.md` | 🔄 Déplacer vers `archive/docs/` |
| `README_RESTART_SCRIPT.md` | 🔄 Déplacer vers `archive/docs/` |
| `explain_node_discovery.md` | 🔄 Déplacer vers `archive/docs/` |
## 🔄 Processus de Migration
### Étape 1 : Créer la Structure
```bash
# Créer les dossiers
mkdir -p docs archive/docs examples/{configuration,scripts,tests}
# Créer le README de l'archive
cat > archive/README.md << 'EOF'
# 📦 Archive - Documentation 4NK Node
Ce dossier contient les anciens fichiers de documentation qui ont été migrés vers la nouvelle structure organisée.
## 📁 Contenu
- `docs/` - Anciens fichiers de documentation
- `README.md` - Ce fichier
## 🔗 Liens vers la Nouvelle Documentation
- **Documentation principale** : [../docs/INDEX.md](../docs/INDEX.md)
- **Guide d'installation** : [../docs/INSTALLATION.md](../docs/INSTALLATION.md)
- **Guide d'utilisation** : [../docs/USAGE.md](../docs/USAGE.md)
- **Guide de configuration** : [../docs/CONFIGURATION.md](../docs/CONFIGURATION.md)
- **Référence rapide** : [../docs/QUICK_REFERENCE.md](../docs/QUICK_REFERENCE.md)
## 📅 Date de Migration
Migration effectuée le : $(date)
EOF
```
### Étape 2 : Migrer les Fichiers
```bash
# Déplacer les fichiers vers l'archive
mv EXEMPLES_PRATIQUES.md archive/docs/
mv CONFIGURATION_DEV3.md archive/docs/
mv INTEGRATION_DEV3_FINAL.md archive/docs/
mv COMMANDES_REDEMARRAGE.md archive/docs/
mv RESUME_AJOUT_DEV3.md archive/docs/
mv RESUME_DECOUVERTE_NOEUDS.md archive/docs/
mv RESUME_SCRIPT_RESTART.md archive/docs/
mv RESUME_TEST_3_RELAIS.md archive/docs/
mv README_RESTART_SCRIPT.md archive/docs/
mv explain_node_discovery.md archive/docs/
```
### Étape 3 : Fusionner les Spécifications
```bash
# Fusionner spec-technical.md dans spec-technique.md
cat specs/spec-technical.md >> specs/spec-technique.md
# Supprimer le fichier fusionné
rm specs/spec-technical.md
```
### Étape 4 : Créer les Guides Manquants
#### Créer `docs/ARCHITECTURE.md`
```bash
# Extraire les sections architecture de spec-technique.md
grep -A 50 "Architecture" specs/spec-technique.md > docs/ARCHITECTURE.md
```
#### Créer `docs/EXTERNAL_NODES.md`
```bash
# Combiner les fichiers de configuration externe
cat archive/docs/CONFIGURATION_DEV3.md archive/docs/INTEGRATION_DEV3_FINAL.md archive/docs/RESUME_AJOUT_DEV3.md > docs/EXTERNAL_NODES.md
```
#### Créer `docs/RELAY_NETWORK.md`
```bash
# Combiner les fichiers de réseau de relais
cat archive/docs/RESUME_DECOUVERTE_NOEUDS.md archive/docs/explain_node_discovery.md > docs/RELAY_NETWORK.md
```
#### Créer `docs/SYNC_TESTING.md`
```bash
# Extraire les sections de test de synchronisation
cat archive/docs/RESUME_TEST_3_RELAIS.md > docs/SYNC_TESTING.md
```
### Étape 5 : Créer les Exemples
```bash
# Créer des exemples de configuration
cat > examples/configuration/bitcoin.conf.example << 'EOF'
# Exemple de configuration Bitcoin Core
signet=1
rpcuser=bitcoin
rpcpassword=your_secure_password
rpcbind=0.0.0.0
rpcallowip=172.19.0.0/16
zmqpubrawblock=tcp://0.0.0.0:29000
zmqpubrawtx=tcp://0.0.0.0:29000
txindex=1
server=1
listen=1
EOF
# Créer des exemples de scripts
cat > examples/scripts/monitor.sh << 'EOF'
#!/bin/bash
# Exemple de script de monitoring
while true; do
echo "=== $(date) ==="
docker ps --format "table {{.Names}}\t{{.Status}}"
sleep 30
done
EOF
chmod +x examples/scripts/monitor.sh
```
## 📋 Checklist de Migration
### ✅ Fichiers Créés
- [x] `docs/INDEX.md` - Index de documentation
- [x] `docs/INSTALLATION.md` - Guide d'installation
- [x] `docs/USAGE.md` - Guide d'utilisation
- [x] `docs/CONFIGURATION.md` - Guide de configuration
- [x] `docs/QUICK_REFERENCE.md` - Référence rapide
- [x] `docs/MIGRATION.md` - Ce guide de migration
### 🔄 Fichiers à Créer
- [ ] `docs/ARCHITECTURE.md` - Architecture technique
- [ ] `docs/API.md` - Référence API
- [ ] `docs/SECURITY.md` - Guide de sécurité
- [ ] `docs/PERFORMANCE.md` - Guide de performance
- [ ] `docs/TESTING.md` - Tests de base
- [ ] `docs/SYNC_TESTING.md` - Tests de synchronisation
- [ ] `docs/PERFORMANCE_TESTING.md` - Tests de performance
- [ ] `docs/RELAY_NETWORK.md` - Réseau de relais
- [ ] `docs/EXTERNAL_NODES.md` - Nœuds externes
- [ ] `docs/SYNCHRONIZATION.md` - Protocole de synchronisation
- [ ] `docs/TROUBLESHOOTING.md` - Guide de dépannage
- [ ] `docs/FAQ.md` - Questions fréquentes
### 🔄 Fichiers à Migrer
- [ ] `EXEMPLES_PRATIQUES.md``archive/docs/`
- [ ] `CONFIGURATION_DEV3.md``archive/docs/`
- [ ] `INTEGRATION_DEV3_FINAL.md``archive/docs/`
- [ ] `COMMANDES_REDEMARRAGE.md``archive/docs/`
- [ ] `RESUME_AJOUT_DEV3.md``archive/docs/`
- [ ] `RESUME_DECOUVERTE_NOEUDS.md``archive/docs/`
- [ ] `RESUME_SCRIPT_RESTART.md``archive/docs/`
- [ ] `RESUME_TEST_3_RELAIS.md``archive/docs/`
- [ ] `README_RESTART_SCRIPT.md``archive/docs/`
- [ ] `explain_node_discovery.md``archive/docs/`
### 🔄 Fichiers à Fusionner
- [ ] `specs/spec-technical.md``specs/spec-technique.md`
### 🔄 Dossiers à Créer
- [ ] `archive/` - Dossier d'archive
- [ ] `archive/docs/` - Anciens fichiers de documentation
- [ ] `examples/` - Exemples d'utilisation
- [ ] `examples/configuration/` - Exemples de configuration
- [ ] `examples/scripts/` - Scripts d'exemple
- [ ] `examples/tests/` - Tests d'exemple
## 🎯 Résultat Final
### Structure Finale
```
4NK_node/
├── README.md # Documentation principale
├── docs/ # Documentation organisée
│ ├── INDEX.md # Index de documentation
│ ├── INSTALLATION.md # Guide d'installation
│ ├── USAGE.md # Guide d'utilisation
│ ├── CONFIGURATION.md # Guide de configuration
│ ├── QUICK_REFERENCE.md # Référence rapide
│ ├── ARCHITECTURE.md # Architecture technique
│ ├── API.md # Référence API
│ ├── SECURITY.md # Guide de sécurité
│ ├── PERFORMANCE.md # Guide de performance
│ ├── TESTING.md # Tests de base
│ ├── SYNC_TESTING.md # Tests de synchronisation
│ ├── PERFORMANCE_TESTING.md # Tests de performance
│ ├── RELAY_NETWORK.md # Réseau de relais
│ ├── EXTERNAL_NODES.md # Nœuds externes
│ ├── SYNCHRONIZATION.md # Protocole de synchronisation
│ ├── TROUBLESHOOTING.md # Guide de dépannage
│ ├── FAQ.md # Questions fréquentes
│ └── MIGRATION.md # Guide de migration
├── specs/ # Spécifications techniques
│ ├── spec-technique.md # Spécification technique (fusionnée)
│ └── spec-fonctionnel.md # Spécification fonctionnelle
├── archive/ # Archive des anciens fichiers
│ ├── docs/ # Anciens fichiers de documentation
│ └── README.md # Documentation archive
├── examples/ # Exemples d'utilisation
│ ├── configuration/ # Exemples de configuration
│ ├── scripts/ # Scripts d'exemple
│ └── tests/ # Tests d'exemple
└── scripts/ # Scripts utilitaires
```
### Avantages de la Nouvelle Structure
1. **Organisation claire** : Documentation organisée par sujet
2. **Navigation facile** : Index centralisé avec liens
3. **Parcours d'apprentissage** : Guides adaptés au niveau d'expertise
4. **Maintenance simplifiée** : Structure modulaire
5. **Archive propre** : Anciens fichiers conservés mais séparés
6. **Exemples pratiques** : Exemples d'utilisation organisés
## 🔄 Commandes de Migration
### Migration Automatique
```bash
# Exécuter la migration complète
./migrate_documentation.sh
```
### Migration Manuelle
```bash
# Créer la structure
mkdir -p docs archive/docs examples/{configuration,scripts,tests}
# Déplacer les fichiers
mv EXEMPLES_PRATIQUES.md archive/docs/
mv CONFIGURATION_DEV3.md archive/docs/
mv INTEGRATION_DEV3_FINAL.md archive/docs/
mv COMMANDES_REDEMARRAGE.md archive/docs/
mv RESUME_AJOUT_DEV3.md archive/docs/
mv RESUME_DECOUVERTE_NOEUDS.md archive/docs/
mv RESUME_SCRIPT_RESTART.md archive/docs/
mv RESUME_TEST_3_RELAIS.md archive/docs/
mv README_RESTART_SCRIPT.md archive/docs/
mv explain_node_discovery.md archive/docs/
# Fusionner les spécifications
cat specs/spec-technical.md >> specs/spec-technique.md
rm specs/spec-technical.md
# Créer le README de l'archive
cat > archive/README.md << 'EOF'
# 📦 Archive - Documentation 4NK Node
Ce dossier contient les anciens fichiers de documentation qui ont été migrés vers la nouvelle structure organisée.
## 📁 Contenu
- `docs/` - Anciens fichiers de documentation
- `README.md` - Ce fichier
## 🔗 Liens vers la Nouvelle Documentation
- **Documentation principale** : [../docs/INDEX.md](../docs/INDEX.md)
- **Guide d'installation** : [../docs/INSTALLATION.md](../docs/INSTALLATION.md)
- **Guide d'utilisation** : [../docs/USAGE.md](../docs/USAGE.md)
- **Guide de configuration** : [../docs/CONFIGURATION.md](../docs/CONFIGURATION.md)
- **Référence rapide** : [../docs/QUICK_REFERENCE.md](../docs/QUICK_REFERENCE.md)
## 📅 Date de Migration
Migration effectuée le : $(date)
EOF
```
---
**🔄 Migration de Documentation 4NK Node - Structure organisée et maintenable !**

View File

@ -1,6 +1,6 @@
# Checklist de Préparation Open Source - 4NK Node # Checklist de Préparation Open Source - <PROJECT_NAME>
Cette checklist détaille tous les éléments nécessaires pour préparer le projet 4NK Node à une ouverture en open source. Cette checklist détaille tous les éléments nécessaires pour préparer ce projet (<PROJECT_NAME>) à une ouverture en open source.
## 📋 État Actuel du Projet ## 📋 État Actuel du Projet
@ -215,7 +215,7 @@ cargo update
## 🚀 Recommandation ## 🚀 Recommandation
**Le projet 4NK Node est PRÊT pour l'open source !** **Le projet est PRÊT pour l'open source !**
### **Actions Immédiates (1-2 jours)** ### **Actions Immédiates (1-2 jours)**
1. Audit de sécurité final 1. Audit de sécurité final

View File

@ -1,11 +1,11 @@
# Plan de Release Open Source - 4NK Node # Plan de Release Open Source - <PROJECT_NAME>
## 🚀 Vue d'Ensemble ## 🚀 Vue d'Ensemble
Ce document détaille le plan de lancement open source du projet 4NK Node sur Gitea. Ce document détaille le plan de lancement open source du projet <PROJECT_NAME> sur votre forge (ex: Gitea/GitHub/GitLab).
### **Objectifs** ### **Objectifs**
- Lancer 4NK Node en open source avec succès - Lancer <PROJECT_NAME> en open source avec succès
- Attirer une communauté de contributeurs - Attirer une communauté de contributeurs
- Établir une base solide pour le développement futur - Établir une base solide pour le développement futur
- Positionner le projet dans l'écosystème Bitcoin - Positionner le projet dans l'écosystème Bitcoin

View File

@ -1,129 +0,0 @@
# Configuration SSH automatique pour ihm_client
## Vue d'ensemble
Le projet `ihm_client` utilise automatiquement les clés SSH pour toutes les opérations Git, que ce soit en local ou dans l'environnement CI/CD Gitea Actions.
## Configuration automatique
### Environnement CI/CD
Dans l'environnement CI/CD Gitea Actions, la configuration SSH est automatique :
1. **Variable d'environnement** : La clé SSH privée est fournie via la variable `SSH_PRIVATE_KEY`
2. **Configuration automatique** : Le workflow CI configure automatiquement SSH pour `git.4nkweb.com`
3. **Test de connexion** : La connexion SSH est testée avant chaque opération Git
### Environnement local
En local, le script `scripts/setup-ssh-ci.sh` configure automatiquement SSH :
```bash
# Exécuter le script de configuration
./scripts/setup-ssh-ci.sh
```
## Configuration manuelle
Si la configuration automatique ne fonctionne pas, voici les étapes manuelles :
### 1. Générer une clé SSH
```bash
ssh-keygen -t rsa -b 4096 -C "votre-email@example.com"
```
### 2. Ajouter la clé publique à Gitea
1. Copier le contenu de `~/.ssh/id_rsa.pub`
2. Aller dans les paramètres de votre compte Gitea
3. Ajouter la clé SSH dans la section "SSH Keys"
### 3. Configurer Git pour utiliser SSH
```bash
git config --global url."git@git.4nkweb.com:".insteadOf "https://git.4nkweb.com/"
```
### 4. Tester la connexion
```bash
ssh -T git@git.4nkweb.com
```
## Workflow CI/CD
Le workflow CI/CD (`.gitea/workflows/ci.yml`) inclut :
### Étapes SSH automatiques
1. **Setup SSH for Gitea** : Configure la clé SSH et les paramètres de connexion
2. **Checkout code** : Utilise SSH pour cloner le repository
3. **Tests et build** : Exécute les tests et builds avec SSH configuré
### Variables requises
- `SSH_PRIVATE_KEY` : Clé SSH privée pour l'authentification
- `SSH_PUBLIC_KEY` : Clé SSH publique (optionnelle)
## Sécurité
### Bonnes pratiques
- Les clés SSH sont stockées de manière sécurisée dans les secrets Gitea
- Les permissions des fichiers SSH sont correctement configurées (600 pour les clés privées)
- La vérification des hôtes SSH est configurée pour `git.4nkweb.com`
### Permissions
```bash
# Permissions correctes pour les fichiers SSH
chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_rsa
chmod 644 ~/.ssh/id_rsa.pub
chmod 600 ~/.ssh/config
```
## Dépannage
### Problèmes courants
1. **Permission denied** : Vérifier les permissions des fichiers SSH
2. **Host key verification failed** : Ajouter `git.4nkweb.com` aux hôtes connus
3. **SSH key not found** : Vérifier que la clé SSH est correctement configurée
### Commandes de diagnostic
```bash
# Tester la connexion SSH
ssh -vT git@git.4nkweb.com
# Vérifier la configuration Git
git config --global --list | grep url
# Vérifier les permissions SSH
ls -la ~/.ssh/
```
## Intégration avec 4NK_node
Lors de l'intégration avec `4NK_node`, la configuration SSH est préservée :
- Les clés SSH sont partagées entre les projets
- La configuration Git utilise SSH pour tous les repositories 4NK
- Le workflow CI/CD maintient la cohérence SSH
## Évolution
### Améliorations futures
- Support pour plusieurs clés SSH
- Rotation automatique des clés
- Intégration avec un gestionnaire de secrets externe
- Support pour l'authentification par certificats SSH
### Maintenance
- Vérification régulière de la validité des clés SSH
- Mise à jour des configurations SSH selon les bonnes pratiques
- Documentation des changements de configuration SSH

View File

@ -1,322 +0,0 @@
# Documentation SSH complète - ihm_client
## Vue d'ensemble
Ce document consolide toute la documentation SSH pour le projet `ihm_client`, couvrant l'automatisation des push, la configuration CI/CD, et les bonnes pratiques de sécurité.
## Table des matières
- [Configuration automatique](#configuration-automatique)
- [Scripts d'automatisation](#scripts-dautomatisation)
- [Workflow CI/CD](#workflow-cicd)
- [Alias Git](#alias-git)
- [Bonnes pratiques](#bonnes-pratiques)
- [Dépannage](#dépannage)
---
## Configuration automatique
### Configuration Git globale
La configuration SSH est automatiquement appliquée pour tous les push :
```bash
git config --global url."git@git.4nkweb.com:".insteadOf "https://git.4nkweb.com/"
```
### Vérification SSH
Test automatique de la connexion SSH :
```bash
ssh -T git@git.4nkweb.com
```
---
## Scripts d'automatisation
### 1. Script principal : `auto-ssh-push.sh`
Le script `scripts/auto-ssh-push.sh` offre plusieurs modes de push automatique :
#### Options disponibles
```bash
# Push rapide (message automatique)
./scripts/auto-ssh-push.sh quick
# Push avec message personnalisé
./scripts/auto-ssh-push.sh message "feat: nouvelle fonctionnalité"
# Push sur une branche spécifique
./scripts/auto-ssh-push.sh branch feature/nouvelle-fonctionnalite
# Push et merge (avec confirmation)
./scripts/auto-ssh-push.sh merge
# Vérification du statut
./scripts/auto-ssh-push.sh status
```
#### Fonctionnalités
- **Configuration SSH automatique** - Plus besoin de configurer SSH manuellement
- **Push automatique** - Ajout, commit et push en une commande
- **Gestion des branches** - Support des branches personnalisées
- **Vérification SSH** - Test automatique de la connexion SSH
- **Messages de commit** - Messages automatiques ou personnalisés
### 2. Script d'initialisation : `init-ssh-env.sh`
Le script `scripts/init-ssh-env.sh` configure automatiquement l'environnement SSH :
```bash
./scripts/init-ssh-env.sh
```
#### Fonctionnalités
- Vérification de l'environnement de développement
- Configuration SSH automatique
- Test de connectivité SSH
- Configuration des alias Git
- Validation de la configuration
### 3. Script CI/CD : `setup-ssh-ci.sh`
Le script `scripts/setup-ssh-ci.sh` configure SSH pour les environnements CI/CD :
```bash
./scripts/setup-ssh-ci.sh
```
#### Fonctionnalités
- Détection automatique de l'environnement CI
- Configuration SSH pour Gitea Actions
- Gestion des clés SSH privées
- Test de connexion SSH
- Configuration Git pour SSH
---
## Workflow CI/CD
### Configuration Gitea Actions
Le workflow CI/CD dans `.gitea/workflows/ci.yml` inclut une étape de configuration SSH :
```yaml
- name: Setup SSH for Gitea
run: |
mkdir -p ~/.ssh
echo "${{ secrets.SSH_PRIVATE_KEY }}" > ~/.ssh/id_rsa
chmod 600 ~/.ssh/id_rsa
ssh-keyscan -H git.4nkweb.com >> ~/.ssh/known_hosts
git config --global url."git@git.4nkweb.com:".insteadOf "https://git.4nkweb.com/"
```
### Variables d'environnement requises
- `SSH_PRIVATE_KEY` : Clé SSH privée pour l'authentification
- `SSH_PUBLIC_KEY` : Clé SSH publique (optionnelle)
### Jobs configurés
- **test** : Tests unitaires et d'intégration
- **security** : Tests de sécurité et audit
- **integration-test** : Tests d'intégration complets
---
## Alias Git
### Alias configurés
```bash
# Push rapide avec message automatique
git quick-push
# Push avec message personnalisé
git ssh-push "Mon message de commit"
```
### Configuration des alias
```bash
# Alias pour push rapide
git config --global alias.quick-push '!f() { git add . && git commit -m "Update $(date)" && git push origin $(git branch --show-current); }; f'
# Alias pour push avec message
git config --global alias.ssh-push '!f() { git add . && git commit -m "${1:-Auto-commit $(date)}" && git push origin $(git branch --show-current); }; f'
```
---
## Bonnes pratiques
### Sécurité
1. **Permissions des clés SSH**
```bash
chmod 600 ~/.ssh/id_rsa
chmod 644 ~/.ssh/id_rsa.pub
chmod 600 ~/.ssh/config
```
2. **Configuration SSH sécurisée**
```bash
Host git.4nkweb.com
HostName git.4nkweb.com
User git
IdentityFile ~/.ssh/id_rsa
StrictHostKeyChecking no
UserKnownHostsFile=/dev/null
```
3. **Gestion des secrets**
- Ne jamais commiter de clés SSH dans le code
- Utiliser les secrets Gitea pour les clés privées
- Rotation régulière des clés SSH
### Workflow recommandé
1. **Initialisation**
```bash
./scripts/init-ssh-env.sh
```
2. **Développement quotidien**
```bash
# Push rapide
./scripts/auto-ssh-push.sh quick
# Ou avec alias Git
git quick-push
```
3. **Push avec message**
```bash
./scripts/auto-ssh-push.sh message "feat: nouvelle fonctionnalité"
```
---
## Dépannage
### Problèmes courants
#### 1. Échec d'authentification SSH
```bash
# Vérifier la configuration SSH
ssh -T git@git.4nkweb.com
# Vérifier les permissions
ls -la ~/.ssh/
# Régénérer la clé SSH si nécessaire
ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_4nk
```
#### 2. Configuration Git incorrecte
```bash
# Vérifier la configuration Git
git config --global --list | grep url
# Reconfigurer SSH
git config --global url."git@git.4nkweb.com:".insteadOf "https://git.4nkweb.com/"
```
#### 3. Problèmes CI/CD
```bash
# Vérifier les variables d'environnement
echo $SSH_PRIVATE_KEY
# Tester la configuration SSH
./scripts/setup-ssh-ci.sh
```
### Messages d'erreur courants
- **"Permission denied"** : Vérifier les permissions des clés SSH
- **"Host key verification failed"** : Ajouter l'hôte aux known_hosts
- **"Could not resolve hostname"** : Vérifier la connectivité réseau
### Logs et debugging
```bash
# Activer le debug SSH
ssh -vT git@git.4nkweb.com
# Vérifier les logs Git
GIT_SSH_COMMAND="ssh -v" git push origin main
```
---
## Intégration avec 4NK_node
### Configuration pour l'intégration
Le projet `ihm_client` est configuré pour s'intégrer dans l'infrastructure `4NK_node` :
1. **Script d'intégration** : `scripts/integrate-4nk-node.sh`
2. **Configuration Docker** : `Dockerfile.4nk-node`
3. **Configuration Nginx** : `nginx.4nk-node.conf`
4. **Script de démarrage** : `start-4nk-node.sh`
### Workflow d'intégration
```bash
# Intégrer ihm_client dans 4NK_node
./scripts/integrate-4nk-node.sh
# Vérifier l'intégration
docker-compose -f docker-compose.4nk-node.yml up -d
```
---
## Évolution future
### Améliorations prévues
1. **Support multi-environnements**
- Configuration automatique pour différents environnements
- Gestion des clés SSH multiples
2. **Intégration avancée**
- Support des hooks Git
- Intégration avec d'autres outils CI/CD
3. **Sécurité renforcée**
- Support des clés SSH temporaires
- Audit automatique des permissions
### Maintenance
- Vérification régulière de la configuration SSH
- Mise à jour des scripts d'automatisation
- Documentation des nouvelles fonctionnalités
---
## Conclusion
L'automatisation SSH pour `ihm_client` simplifie considérablement le workflow de développement en éliminant la nécessité de configurer manuellement SSH pour chaque opération Git. Les scripts et alias fournis offrent une interface simple et sécurisée pour tous les push vers le repository.
### Ressources
- [Documentation SSH officielle](https://git-scm.com/book/fr/v2/Git-sur-le-serveur-Génération-d-une-clé-SSH)
- [Guide Gitea SSH](https://docs.gitea.com/usage/ssh-setup)
- [Bonnes pratiques SSH](https://www.ssh.com/academy/ssh/key)
---
**Dernière mise à jour** : $(date '+%Y-%m-%d')
**Version** : 1.0.0

View File

@ -1,10 +1,10 @@
# Guide de Tests - 4NK Node # Guide de Tests - <PROJECT_NAME>
Ce guide documente l'ensemble des tests disponibles pour l'infrastructure 4NK Node, leur organisation et leur utilisation. Ce guide documente l'ensemble des tests disponibles pour l'infrastructure <PROJECT_NAME>, leur organisation et leur utilisation.
## Vue d'Ensemble ## Vue d'Ensemble
L'infrastructure 4NK Node dispose d'une suite de tests complète organisée en plusieurs catégories : L'infrastructure <PROJECT_NAME> dispose d'une suite de tests complète organisée en plusieurs catégories :
- **Tests Unitaires** : Tests individuels des composants - **Tests Unitaires** : Tests individuels des composants
- **Tests d'Intégration** : Tests d'interaction entre services - **Tests d'Intégration** : Tests d'interaction entre services

View File

@ -1,6 +1,8 @@
# 📖 Guide d'Utilisation - 4NK Node # 📖 Guide d'Utilisation - <PROJECT_NAME>
Guide complet pour utiliser l'infrastructure 4NK Node au quotidien. > Ce document est un modèle générique. Remplacez <PROJECT_NAME> et adaptez les commandes/chemins à votre projet.
Guide complet pour utiliser l'infrastructure <PROJECT_NAME> au quotidien.
## 🚀 Démarrage Quotidien ## 🚀 Démarrage Quotidien
@ -664,4 +666,4 @@ docker-compose down
--- ---
**✨ Infrastructure 4NK Node - Utilisation optimale !** **✨ Infrastructure <PROJECT_NAME> - Utilisation optimale !**