# agent_deploy.md

Informations critiques à respecter totalement et impérativemment.

## Contexte

Le site est sur @https://dev4.4nkweb.com/lecoffre (`lecoffre_front`).
Il sera redirigé au login des notaires vers un site qui redirige vers local.4nkdev.com qui sera redirigé vers @https://dev4.4nkweb.com/lecoffre avec l'ouverture de l'iframe @https://dev4.4nkweb.com/ (`ihm_client`).

Analyse le contenu de `lecoffre_node/IA_agents/flux.md` pour comprendre les flux.
Met à jour ce flux si tu détecte des incohérences ou pose des questions pour confirmer.

Le déploiement se fait depuis le répertoire **`lecoffre_node/`**, en utilisant les scripts présents dans **`scripts/`**.
Ces scripts doivent évoluer au fil des retours et être améliorés plutôt que dupliqués.

Dans **tous les projets** :

- Une branche Git dédiée `ext` existe.
- Aucun tag Git nommé `ext` n’existe.
- Des images Docker avec le tag `ext` existent.
- Les images Docker ne sont build que via CI qui est la seule à pousser sur le registry ou pour test localement.
- Aucun Dockerfile ne doit utiliser de clés ssh car aucun repos n'est privé, utiliser HTTPS.
- Les services doivent écouter sur 0.0.0.0 (et non sur 127.0.0.1).
- Corrige aussi les erreurs non critiques.

Dépendances :

- image: btcpayserver/tor:0.4.8.10 (pour synchro Bitcoin)
- image: git.4nkweb.com/4nk/bitcoin:latest (pour mainchain et signet custom)
- image: git.4nkweb.com/4nk/blindbit-oracle:dev (pour scan des blocs et détection des secrets dans les transaction silent payment)
- image: containrrr/watchtower (pour la surveillance et mise à jour automatique des images)

Projets locaux avec Dockerfile à déployer par **`lecoffre_node/`** (d'autres projets externes sont ne dépendance dans le `lecoffre_node/docker-compose.yml`):

- **`sdk_relay/`** (relai des transations et messages et oracle)
- **`sdk_signer/`** (signature des processus métier et des identités/profils)
- **`sdk_storage/`** (stockage temporaire)
- **`ihm_client/`** (iframe dans les frontend des projets pour interactions avec les clés privés Bitcoin Silent Payment)
- **`lecoffre-back-mini/`** (backend pour les API tierces du projet lecoffre)
- **`lecoffre-front/`** (frontend du projet lecoffre)

Projets locaux sans Dockerfile à vérifier **`lecoffre_node/`**:

- **`sdk_common/`** (coeur de la gestion des clés)
- **`sdk_client/`** (coeur de l'intégration du système de process)
- **`sdk-signer-client/`**  (coeur de l'intégration du système de process pour l'intégration)

---

## Procédure générale

### Vérifications initiales

1. Vérifier que le dépôt distant est **public** (si possible).
2. Vérifier l’utilisation des **clés SSH** pour le déploiement Git (idéalement ~/.ssh/id_ed25519)
3. Vérifier que la branche courante est bien **`ext`**.
4. Mettre à jour les dépendances et les langages
5. Vérifier les **variables d’environnement**.

### Mise à jour et construction

6. Optimise le build du projet et build le projet.
7. Mettre à jour la **documentation**.
8. Mettre à jour les **tests**.
9. Mettre à jour les **scripts**.
10. Vérifier que la présence et le contenu exhaustif et spécifique de :
    - `.gitignore`
    - `.dockerignore`
    - `.cursorignore`

### Synchronisations

11. Synchroniser les configurations dans `lecoffre_node/conf`.
12. Synchroniser les logs dans `lecoffre_node/logs` (brancher grafana pour un dashboard par projet)

### Sécurité et conformité

13. Vérifier que le code ne fournit pas :
    - de **données personnelles**,
    - de **données sensibles exploitables**,
    - de **failles de sécurité**.

### Gestion Git

14. Pousser toutes les modifications sur la branche Git `ext`.
15. Supprimer les fichiers distants non suivis par Git.

### Analyse et correction

16. Analyser les logs.
17. Corriger toutes les erreurs, petites et grosses, **sans désactivation**, **sans simplification**, **sans contournement**.
18. Tester.
19. Analyser de nouveau les logs.
20. Vérifier que les logs ne contiennent pas de données personnelles ou sensibles.
21. Corriger à nouveau si nécessaire (jusqu'à l'absence totale d'erreurs)

### Boucle d’amélioration

22. Ne pas créer de nouvelles versions de scripts : **améliorer et tester ceux existants**.
23. Mettre à jour la documentation avec le **retour d’expérience** à chaque fois par une mise à jour de `docs/REX.md`.
24. Recommencer si nécessaire pour obtenir un déploiement fluide et parfait.
25. Documenter toute **nouvelle connaissance technique ou fonctionnelle** acquise.
26. Répéter la synchronisation des confs et logs.
27. Pousser toutes les modifications sur la branche `ext`.
28. Supprimer à nouveau les fichiers distants non suivis.
29. Répéter analyse des logs, corrections, tests jusqu'à un déploiement parfait.

---

## Spécificités Dockerfile

Pour tous les projets contenant un **Dockerfile**, avant de pousser sur la branche `ext` :

- Mettre à jour le Dockerfile pour maîtriser les prérequis :
  - inclure `sudo apt update && sudo apt upgrade`,
  - installer `build-essential`, `autoconf`, `automake`, `libtool`, `pkg-config`, `cmake`, `ninja-build`, `clang`, `lldb`, `lld`, `make`, `tree`, `ncdu`, `mc`, `exuberant-ctags`, `cscope`, `vim`, `emacs`, `jq`, `curl`, `sed`, `gawk`, `inetutils-tools`, `iputils-*`, `net-tools`, `iproute2`
  - installer python3 (dernière version) et mettre à jour
  - installer go (dernière version) et mettre à jour
  - installer rust (dernière version) et mettre à jour
  - installer `npm` (dernière version), instaler `wscat` (dernière version) et mettre à jour
- Optimise le build
- Construire l’image pour test.
- Vérifier `.dockerignore`.
- Vérifier à l'absence de dépendances croisées ou dupliquée entre les projets, sinon mutualiser via d'autres projets/docker

Après le push sur la branche Git `ext` :

- Pousser l’image sur le **tag Docker `ext`** via la CI.

---