4NK_env/IA_agents/prompts/prompt-deploy.md

# Prompt de Déploiement LeCoffre Node

## 🎯 Prompt pour l'Agent IA

```
Déploie l'architecture LeCoffre Node complète en respectant strictement les consignes de déploiement.
Arrete et nettoie tous les services, images, tests, commandes, éditions... encore actives avant de relancer proprement.
Toujours veiller à supprimer les fichiers distants non suivis
A la fin met bien à jour les documents de `IA_agents/` et ses sous dossiers.
Si un processus est en attente alors utiliser les scripts de monitoring, si ils sont peu utiles pour comprendre la raison de l'attente ou la progression, alors améliore les.

## Contexte obligatoire
- Consulte attentivement `IA_agents/context.md` pour le contexte technique
- Consulte attentivement `IA_agents/flux.md` pour l'architecture des services
- Consulte attentivement `IA_agents/deploy.md` pour les procédures détaillées
- Consulte attentivement `CI_TRIGGER_PROCESS.md` pour les CI détaillées
- Consulte attentivement `monitoring-progress.md` pour le monitoring détaillé
- Consulte attentivement `quick-reference-monitoring.md` pour les références du monitoring
- Reste TOUJOURS sur la branche git "ext"
- Déclenche TOUJOURS les builds via CI avec des images docker tagées "ext"
- Corrige aussi les problèmes de code

## Objectifs de déploiement
1. Déployer depuis le répertoire `lecoffre_node/` en utilisant les scripts présents dans `scripts/`
2. Assurer que tous les services écoutent sur 0.0.0.0 et soient accessibles depuis l'extérieur via le nom de domaine
3. Vérifier chaque projet un par un (analyse du dossier, du code, branche Git `ext`, pas de tag Git `ext`)
4. Corriger toutes les erreurs sans désactivation, simplification ou contournement

## Procédure de déploiement

A mettre dans ta TODO (vérifie que tout est fait à la fin):

### Phase 1: Vérifications initiales
- [ ] Vérifier que le dépôt distant est public (si possible)
- [ ] Vérifier l'utilisation des clés SSH pour le déploiement Git
- [ ] Vérifier que la branche courante est bien `ext`
- [ ] Mettre à jour les dépendances et les langages
- [ ] Vérifier les variables d'environnement centralisées dans `.env.master`

### Phase 2: Construction et optimisation
- [ ] Supprimer les caches et optimiser le build de chaque projet
- [ ] Mettre à jour la documentation
- [ ] Mettre à jour les tests
- [ ] Mettre à jour les scripts
- [ ] Vérifier les fichiers .gitignore, .dockerignore, .cursorignore

### Phase 3: Synchronisation
- [ ] Synchroniser les configurations dans `lecoffre_node/conf`
- [ ] Synchroniser les logs dans `lecoffre_node/logs`
- [ ] Brancher Grafana pour un dashboard par projet

### Phase 4: Sécurité et conformité
- [ ] Vérifier que le code ne fournit pas de données personnelles ou sensibles
- [ ] Vérifier qu'il n'y a pas de failles de sécurité

### Phase 5: Gestion Git
- [ ] Pousser toutes les modifications sur la branche Git `ext`
- [ ] Supprimer les fichiers distants non suivis par Git

### Phase 6: Tests et corrections
- [ ] Analyser les logs
- [ ] Corriger toutes les erreurs (sans désactivation, simplification, contournement)
- [ ] Tester
- [ ] Analyser à nouveau les logs
- [ ] Vérifier que les logs ne contiennent pas de données sensibles
- [ ] Corriger à nouveau si nécessaire (jusqu'à l'absence totale d'erreurs)

### Phase 7: Déploiement des services
- [ ] **IMPORTANT** : Utiliser UNIQUEMENT les scripts spécialisés, JAMAIS docker compose directement
- [ ] **Ordre de déploiement OBLIGATOIRE** :
  - [ ] **Phase 1** : Services de base (parallèle) avec `./scripts/start-with-progress.sh`
  - [ ] **Phase 2** : Services blockchain (séquentiel) avec `./scripts/start-with-progress.sh`
  - [ ] **Phase 3** : Services applicatifs (séquentiel) avec `./scripts/start-with-progress.sh`
  - [ ] **Phase 4** : Services de monitoring (indépendant) avec `./scripts/start-monitoring.sh`
  - [ ] **Phase 5** : Services utilitaires avec `./scripts/start-with-progress.sh`
- [ ] **Scripts OBLIGATOIRES à utiliser** :
  - [ ] `./scripts/start-with-progress.sh` : Démarrage complet avec phases
  - [ ] `./scripts/start-monitoring.sh` : Démarrage monitoring indépendant
  - [ ] `./scripts/monitor-progress.sh` : Aperçu des services
  - [ ] `./scripts/watch-progress.sh` : Surveillance temps réel
  - [ ] `./scripts/logs-with-progress.sh` : Logs avec progression
- [ ] **Architecture de déploiement** :
  - [ ] **Services applicatifs** : Démarrent indépendamment des services de monitoring
  - [ ] **Services de monitoring** : Loki → Promtail → Grafana (séquentiel)
  - [ ] **Dépendances** : Seules les dépendances métier sont respectées
- [ ] **Surveiller la progression des services critiques** :
  - [ ] **Bitcoin IBD** : Suivre la progression des blocs téléchargés
  - [ ] **BlindBit** : Surveiller l'état du scan des blocs
  - [ ] **SDK Relay** : Attendre la synchronisation Bitcoin avant le démarrage
  - [ ] **Services LeCoffre** : Vérifier les dépendances avant démarrage
- [ ] Corriger toutes les erreurs rencontrées
- [ ] Tester la connectivité externe

### Phase 8: Monitoring et validation
- [ ] S'assurer que Grafana est à jour
- [ ] Synchroniser la configuration Nginx et relancer le serveur
- [ ] Vérifier que Loki, Promtail et Grafana sont OK avec des dashboards alimentés
- [ ] Vérifier qu'il n'y a aucun conflit de ports
- [ ] Tester toutes les URLs publiques depuis l'extérieur
- [ ] Tester spécifiquement les WebSockets et services HTTP(S)
- [ ] Vérifier que tous les imports sont présents
- [ ] **Utiliser les outils de monitoring** pour suivre la progression et diagnostiquer les problèmes

## Variables d'environnement centralisées (2024-09-21)
Utilise TOUJOURS le fichier `.env.master` centralisé :
```bash
docker compose --env-file .env.master up -d
```

Variables disponibles :
- SDK_RELAY_* : Configuration du service relay
- SIGNER_* : Configuration du service signer
- VITE_* : Configuration des applications frontend
- IDNOT_* : Configuration des APIs notaires
- STRIPE_* : Configuration des paiements
- MAILCHIMP_* : Configuration des emails
- OVH_* : Configuration des SMS

## Architecture Docker optimisée
- Base standardisée : `debian:bookworm-slim` pour tous les services
- Packages minimaux : ca-certificates, curl, jq, git
- Utilisateurs non-root : appuser (UID 1000)
- Images optimisées : 120-300MB selon le service
- Tag Docker : `ext` pour tous les déploiements

## Tests fonctionnels obligatoires
1. **Login notaire** : Tenter un login notaire avec redirection IdNot et validation dans l'iframe
2. **Connexion Stripe** : Arriver connecté après vérification du compte Stripe
3. **Création dossier** : Créer un dossier en tant que notaire et ajouter un client
4. **Email Mailchimp** : Vérifier l'envoi du lien par email
5. **Login client** : Se connecter avec le lien email et confirmer le code SMS (API OVH)
6. **Accès dossier** : Accéder au dossier en tant que client

## Tests techniques obligatoires
1. **Page de statut** : https://dev4.4nkweb.com/status/
2. **Dashboard Grafana** : https://dev4.4nkweb.com/grafana/
3. **Connectivité WebSocket** : Test spécifique des WebSockets
4. **Services HTTP(S)** : Test spécifique des services HTTP(S)

## Commandes essentielles

### 🚫 INTERDIT - Ne jamais utiliser ces commandes
```bash
# ❌ JAMAIS utiliser directement
docker compose --env-file .env.master up -d
docker compose up -d
docker compose start
```

### ✅ OBLIGATOIRE - Utiliser uniquement ces scripts
```bash
# Démarrage complet avec phases (OBLIGATOIRE)
./scripts/start-with-progress.sh

# Démarrage monitoring indépendant (OBLIGATOIRE)
./scripts/start-monitoring.sh

# Surveillance générale
./scripts/monitor-progress.sh

# Surveillance en temps réel
./scripts/watch-progress.sh

# Logs avec progression
./scripts/logs-with-progress.sh bitcoin -p -f

# Test de configuration
./scripts/test-env-config.sh

# Test monitoring
./scripts/test-monitoring.sh

# Synchronisation config
./scripts/sync-monitoring-config.sh
```

## Points d'attention critiques
- N'attends pas infiniment le résultat des curls
- Si le terminal est interrompu, analyse la sortie
- Teste TOUTES les URLs publiques depuis l'extérieur avant de dire qu'elles sont OK
- Vérifie spécifiquement les WebSockets et services HTTP(S)
- Vérifie que tous les imports sont présents
- Déclenche les builds via CI
- Vérifie les droits et résultats d'écriture sur les fichiers de conf Nginx et Bitcoin
- **Utilise les outils de monitoring** pour suivre la progression et diagnostiquer les problèmes
- **Surveille la progression Bitcoin IBD** : Le processus peut prendre du temps
- **Attends la synchronisation Bitcoin** avant de démarrer SDK Relay
- **Vérifie les dépendances** avant de démarrer les services LeCoffre

## Architecture de déploiement (CRITIQUE)

### 🏗️ Ordre de démarrage par phases
**Phase 1: Services de base (parallèle)**
1. tor
2. sdk_storage  
3. sdk_signer
4. status-api

**Phase 2: Services blockchain (séquentiel)**
5. bitcoin (attend tor)
6. blindbit (attend bitcoin)
7. sdk_relay (attend blindbit)

**Phase 3: Services applicatifs (séquentiel)**
8. lecoffre-back (attend sdk_relay)
9. lecoffre-front (attend lecoffre-back)
10. ihm_client (attend sdk_relay + sdk_storage)

**Phase 4: Services de monitoring (séquentiel, indépendant)**
11. loki (base de données logs)
12. promtail (collecte logs → dépend de loki)
13. grafana (visualisation → dépend de loki + promtail)

**Phase 5: Services utilitaires**
14. watchtower

### 🔧 Principe architectural
- **Services applicatifs** : Fonctionnent indépendamment du monitoring
- **Services de monitoring** : Observent sans impacter les applications
- **Dépendances** : Seules les dépendances métier sont respectées
- **Scripts spécialisés** : Chaque phase utilise le script approprié

## Validation finale
- [ ] Tous les services démarrés et fonctionnels
- [ ] Toutes les URLs publiques accessibles depuis l'extérieur
- [ ] Tests fonctionnels validés
- [ ] Tests techniques validés
- [ ] Monitoring opérationnel
- [ ] Aucune erreur dans les logs
- [ ] Configuration centralisée opérationnelle
- [ ] **Système de monitoring et progression opérationnel** :
  - [ ] Healthchecks informatifs fonctionnels
  - [ ] Scripts de monitoring opérationnels
  - [ ] Progression Bitcoin IBD visible
  - [ ] Progression BlindBit visible
  - [ ] Progression SDK Relay visible

## En cas de problème
1. Arrête-toi pour corriger chaque problème rencontré avant de passer à la suite
2. Analyse les logs en détail
3. Corrige sans désactivation, simplification ou contournement
4. Documente toute nouvelle connaissance technique ou fonctionnelle acquise
5. Mets à jour la documentation avec le retour d'expérience

Déploie maintenant l'architecture LeCoffre Node complète en suivant cette procédure étape par étape.
```

---

## 📋 Instructions d'utilisation

### Pour l'agent IA
1. Copie le prompt ci-dessus
2. Colle-le dans votre conversation avec l'agent IA
3. L'agent suivra automatiquement la procédure de déploiement

### Pour l'utilisateur
1. Assure-toi que tous les prérequis sont remplis
2. Vérifie que la branche `ext` est active
3. Lance le prompt de déploiement
4. Suis l'exécution étape par étape

## 🔧 Personnalisation

Ce prompt peut être adapté selon les besoins :
- Modifier les phases selon l'environnement
- Ajouter des tests spécifiques
- Personnaliser les commandes selon l'infrastructure

## 📊 Suivi

Le prompt inclut des cases à cocher pour suivre l'avancement :
- [ ] Phase 1: Vérifications initiales
- [ ] Phase 2: Construction et optimisation
- [ ] Phase 3: Synchronisation
- [ ] Phase 4: Sécurité et conformité
- [ ] Phase 5: Gestion Git
- [ ] Phase 6: Tests et corrections
- [ ] Phase 7: Déploiement des services
- [ ] Phase 8: Monitoring et validation

---

**Note** : Ce prompt est basé sur `deploy.md` et respecte toutes les consignes de déploiement du projet LeCoffre Node.