docs: ajout FONCTIONNEL.md + index; changelog Unreleased mis à jour
This commit is contained in:
Your Name
parent
e72af33252
commit
08e4875087
@ -21,6 +21,7 @@ et ce projet adhère au [Semantic Versioning](https://semver.org/spec/v2.0.0.htm
|
||||
- Documentation d'intégration avec 4NK_node
|
||||
- Tests unitaires pour `sp-address.utils` et `html.utils`
|
||||
- Documentation: `docs/API.md`, `docs/TESTING.md`, `docs/CONFIGURATION.md`
|
||||
- Documentation fonctionnelle: `docs/FONCTIONNEL.md` et index mis à jour
|
||||
- Tests pour `TokenService` et fallback d’environnement pour tests
|
||||
|
||||
### Fixed
|
||||
|
||||
99
docs/FONCTIONNEL.md
Normal file
99
docs/FONCTIONNEL.md
Normal file
@ -0,0 +1,99 @@
|
||||
# Documentation fonctionnelle - ihm_client
|
||||
|
||||
Cette documentation décrit ce que fait fonctionnellement l’interface `ihm_client`, les parcours utilisateurs, les règles de gestion et les contraintes associées. Aucun exemple de code applicatif n’est inclus.
|
||||
|
||||
## Objectif produit
|
||||
|
||||
- Proposer une interface moderne pour la gestion de processus collaboratifs autour des Silent Payments.
|
||||
- Faciliter le pairing sécurisé entre appareils/utilisateurs et la gestion des transactions associées.
|
||||
- Offrir un espace unifié pour la gestion des membres, documents, signatures et échanges (chat/notifications).
|
||||
|
||||
## Personas et rôles
|
||||
|
||||
- Utilisateur standard: initie/participe à des processus, signe des documents, échange des messages.
|
||||
- Administrateur de processus: configure les rôles, vérifie les validations, déclenche des mises à jour.
|
||||
- Observateur (lecture seule): consulte les informations publiques/partagées sans intervenir.
|
||||
|
||||
## Parcours principaux
|
||||
|
||||
### Accueil
|
||||
- Accès rapide aux sections clés (Compte, Processus, Signature, Chat, Pairing).
|
||||
- Indicateurs d’activité: processus actifs, notifications récentes, métriques succinctes.
|
||||
|
||||
### Pairing (mise en relation)
|
||||
- Objectif: établir une relation de confiance entre appareils via adresse Silent Payment.
|
||||
- Étapes:
|
||||
1. Saisir ou scanner l’adresse SP distante (ou URL contenant `sp_address`).
|
||||
2. Vérifier l’empreinte visuelle (emojis) dérivée de l’adresse pour confirmer l’identité.
|
||||
3. Créer et confirmer le processus de pairing (flux guidé, confirmation finale).
|
||||
- Résultat: l’appareil local est appairé; les échanges sécurisés sont possibles.
|
||||
|
||||
### Wallet et relays
|
||||
- Visualiser l’état du wallet (montant disponible, synchro via relays).
|
||||
- Interagir avec le réseau via relays (mise à jour des membres/états, échange de messages techniques).
|
||||
- Disposer d’un mécanisme de “faucet” en environnement de test pour provisionner le wallet.
|
||||
|
||||
### Processus
|
||||
- Créer un nouveau processus (données publiques et privées, rôles, règles de validation).
|
||||
- Mettre à jour un processus existant (évolution des états, validations, preuves).
|
||||
- Consulter l’historique (états validés, états en attente/non committés).
|
||||
|
||||
### Membres et rôles
|
||||
- Gérer les membres impliqués (par adresse SP).
|
||||
- Définir des rôles et règles de validation (quorum, champs soumis à contrôle, seuils).
|
||||
- Vérifier l’appartenance de l’utilisateur à un rôle (autorisation implicite des actions).
|
||||
|
||||
### Documents et signatures
|
||||
- Associer des documents aux processus (hashés et stockés via mécanismes dédiés).
|
||||
- Déclencher des demandes de signature, suivre leur statut (en attente, signé, expiré).
|
||||
- Vérifier/valider les preuves (ex. Merkle) liées aux documents échangés.
|
||||
|
||||
### Chat et notifications
|
||||
- Échanger des messages dans le contexte des processus.
|
||||
- Recevoir des notifications liées aux événements (nouvelle transaction, demande de signature, mise à jour de processus).
|
||||
|
||||
## Règles de gestion clés
|
||||
|
||||
- Pairing
|
||||
- Une empreinte visuelle (emojis) dérivée de l’adresse SP aide à la confirmation utilisateur.
|
||||
- Un processus de pairing doit inclure l’adresse de l’appareil local.
|
||||
- Validation
|
||||
- Les règles de validation (quorum, seuils) s’appliquent aux champs déclarés.
|
||||
- Une mise à jour de processus peut être refusée si les preuves/validations sont insuffisantes.
|
||||
- Données
|
||||
- Les données volumineuses (blobs) sont stockées séparément et référencées par hash.
|
||||
- Les attributs chiffrés nécessitent clés/permissions pour être déchiffrés.
|
||||
- Sécurité
|
||||
- Les échanges sont consolidés via relays; l’appairage conditionne l’accès aux données privées.
|
||||
- Les tokens de session sont temporaires et régénérables (Access/Refresh).
|
||||
|
||||
## Contraintes et limites
|
||||
|
||||
- Dépendance au module WASM pour les opérations de bas niveau (Silent Payments, encodages, preuves).
|
||||
- Nécessité d’un ou plusieurs relays disponibles pour la synchronisation et l’échange d’informations.
|
||||
- Performance dépendant du contexte (navigateur, réseau, taille des données).
|
||||
|
||||
## Indicateurs et métriques
|
||||
|
||||
- Disponibilité des relays et latence observée.
|
||||
- État de synchronisation (hauteur de bloc, mises à jour reçues).
|
||||
- Taille et temps de manipulation des documents.
|
||||
- Taux de succès des signatures et validations.
|
||||
|
||||
## Gestion des erreurs et non-régression
|
||||
|
||||
- Messages d’erreur explicites pour états manquants, adresses invalides, clés indisponibles, connexions relays.
|
||||
- Tests unitaires couvrant conversions (hex/blob), DOM utilitaire et tokens.
|
||||
- Stratégie de test documentée (voir `docs/TESTING.md`).
|
||||
|
||||
## Confidentialité et conformité
|
||||
|
||||
- Pas de stockage permanent de secrets en clair côté client.
|
||||
- Utilisation stricte de variables d’environnement pour les secrets runtime.
|
||||
- Revue régulière des dépendances et audits sécurité (voir `docs/SECURITY_AUDIT.md`).
|
||||
|
||||
## Support et usage
|
||||
|
||||
- Guides d’installation et d’utilisation (voir `docs/INSTALLATION.md`, `docs/USAGE.md`).
|
||||
- Référentiel contractuel des API (voir `docs/API.md`).
|
||||
- Procédures d’intégration 4NK_node (voir `docs/INTEGRATION_4NK_NODE.md`).
|
||||
@ -14,6 +14,8 @@ Guide complet pour installer et configurer l'interface utilisateur ihm_client.
|
||||
- **Dépannage et monitoring**
|
||||
|
||||
### 📖 [Guide d'Utilisation](USAGE.md)
|
||||
### 🧭 [Documentation fonctionnelle](FONCTIONNEL.md)
|
||||
Description fonctionnelle complète (parcours, règles de gestion, contraintes).
|
||||
Guide complet pour utiliser l'interface utilisateur ihm_client au quotidien.
|
||||
- **Démarrage du serveur de développement**
|
||||
- **Utilisation de l'interface utilisateur**
|
||||
|
||||
@ -1,195 +0,0 @@
|
||||
# Résumé final - État de ihm_client
|
||||
|
||||
## 🎯 Statut global
|
||||
|
||||
**✅ PROJET COMPLÈTEMENT OPÉRATIONNEL ET PRÊT POUR LA PRODUCTION**
|
||||
|
||||
**Date** : 25 août 2025
|
||||
**Branche** : `docker-support`
|
||||
**Version** : Production-ready
|
||||
|
||||
## 📊 État des compilations
|
||||
|
||||
### ✅ Compilation WASM
|
||||
- **Module** : `sdk_client` (Rust → WebAssembly)
|
||||
- **Taille** : 3.3 MB
|
||||
- **Dépendances** : `sdk_common` (branche `docker-support`)
|
||||
- **Statut** : ✅ **RÉUSSI**
|
||||
|
||||
### ✅ Compilation TypeScript
|
||||
- **Framework** : Vue.js + TypeScript + Vite
|
||||
- **Bundle** : 4.5 MB (gzippé)
|
||||
- **CSS** : 711 KB (gzippé)
|
||||
- **Statut** : ✅ **RÉUSSI**
|
||||
|
||||
### ✅ Intégration Docker
|
||||
- **Multi-stage build** : Node.js → Nginx
|
||||
- **Optimisation** : Production-ready
|
||||
- **Statut** : ✅ **CONFIGURÉ**
|
||||
|
||||
## 🔧 Configuration des branches
|
||||
|
||||
| Projet | Branche | Statut | Dernière mise à jour |
|
||||
|--------|---------|--------|---------------------|
|
||||
| **ihm_client** | `docker-support` | ✅ Actuelle | 25 août 2025 |
|
||||
| **sdk_client** | `docker-support` | ✅ Compatible | 25 août 2025 |
|
||||
| **sdk_common** | `docker-support` | ✅ Compatible | 25 août 2025 |
|
||||
| **4NK_node** | `main` | ✅ Intégré | 25 août 2025 |
|
||||
|
||||
## 🚀 Fonctionnalités opérationnelles
|
||||
|
||||
### Interface utilisateur
|
||||
- ✅ **Accueil** - Navigation et vue d'ensemble
|
||||
- ✅ **Compte** - Gestion du profil utilisateur
|
||||
- ✅ **Processus** - Création et gestion des processus
|
||||
- ✅ **Signature** - Signatures de documents
|
||||
- ✅ **Chat** - Communication entre membres
|
||||
|
||||
### Fonctionnalités techniques
|
||||
- ✅ **Pairing** - Connexion avec d'autres utilisateurs
|
||||
- ✅ **Wallet** - Gestion des Silent Payments
|
||||
- ✅ **Documents** - Validation et signature
|
||||
- ✅ **Notifications** - Système temps réel
|
||||
- ✅ **QR Code** - Scanner et génération
|
||||
- ✅ **WASM** - Intégration complète avec sdk_client
|
||||
|
||||
## 🔗 Intégration 4NK_node
|
||||
|
||||
### Service configuré
|
||||
```yaml
|
||||
ihm_client:
|
||||
build: ./ihm_client
|
||||
ports: ["8080:80"]
|
||||
environment:
|
||||
- SDK_RELAY_WS_URL=ws://sdk_relay_1:8090
|
||||
- SDK_RELAY_HTTP_URL=http://sdk_relay_1:8091
|
||||
- BITCOIN_RPC_URL=http://bitcoin:18443
|
||||
- BLINDBIT_URL=http://blindbit:8000
|
||||
```
|
||||
|
||||
### URLs d'accès
|
||||
- **Interface utilisateur** : http://localhost:8080
|
||||
- **API SDK Relay** : http://localhost:8091
|
||||
- **Bitcoin RPC** : http://localhost:18443
|
||||
|
||||
## 📚 Documentation complète
|
||||
|
||||
### Documents créés
|
||||
1. **docs/ETAT_ACTUEL.md** - État détaillé du projet
|
||||
2. **docs/INTEGRATION_4NK_NODE.md** - Guide d'intégration
|
||||
3. **docs/SSH_USATE.md** - Configuration SSH automatisée
|
||||
4. **docs/ARCHITECTURE.md** - Architecture technique
|
||||
5. **docs/API.md** - Documentation des APIs
|
||||
6. **docs/RESUME_FINAL.md** - Ce résumé
|
||||
|
||||
### README modernisé
|
||||
- ✅ Statut opérationnel
|
||||
- ✅ Fonctionnalités documentées
|
||||
- ✅ Guide de développement
|
||||
- ✅ Métriques et performances
|
||||
|
||||
## 🛠️ Scripts automatisés
|
||||
|
||||
### Développement
|
||||
```bash
|
||||
npm install # Installation des dépendances
|
||||
npm run dev # Développement local
|
||||
npm run build # Build de production
|
||||
```
|
||||
|
||||
### Intégration
|
||||
```bash
|
||||
./scripts/setup-remote-deps.sh # Configuration des dépendances distantes
|
||||
./scripts/integrate-4nk-node.sh # Intégration dans 4NK_node
|
||||
./scripts/cleanup-deps.sh # Nettoyage des dépendances
|
||||
```
|
||||
|
||||
### SSH automatisé
|
||||
```bash
|
||||
./scripts/init-ssh-env.sh # Configuration SSH
|
||||
./scripts/auto-ssh-push.sh # Push automatique
|
||||
```
|
||||
|
||||
## 📈 Métriques de performance
|
||||
|
||||
### Taille des fichiers
|
||||
- **WASM** : 3.3 MB
|
||||
- **CSS** : 711 KB (gzippé)
|
||||
- **JavaScript** : 4.5 MB (gzippé)
|
||||
- **Total** : ~8.5 MB
|
||||
|
||||
### Temps de compilation
|
||||
- **WASM** : ~22s
|
||||
- **TypeScript** : ~2.5s
|
||||
- **Docker** : ~30s
|
||||
|
||||
## 🔍 Tests et validation
|
||||
|
||||
### Tests effectués
|
||||
1. ✅ **Compilation WASM** - Réussie
|
||||
2. ✅ **Compilation TypeScript** - Réussie
|
||||
3. ✅ **Build Docker** - Configuré
|
||||
4. ✅ **Intégration 4NK_node** - Configurée
|
||||
5. ✅ **Variables d'environnement** - Configurées
|
||||
|
||||
### Problèmes résolus
|
||||
- ❌ ~~Erreur `scan_blocks` manquant~~ → ✅ Corrigé
|
||||
- ❌ ~~Branche `sdk_common` incorrecte~~ → ✅ Corrigé
|
||||
- ❌ ~~Types TypeScript manquants~~ → ✅ Corrigé
|
||||
- ❌ ~~Configuration SSH~~ → ✅ Automatisée
|
||||
|
||||
## 🎯 Prochaines étapes
|
||||
|
||||
### Immédiat
|
||||
1. **Test complet de l'infrastructure 4NK_node**
|
||||
2. **Validation des fonctionnalités en production**
|
||||
3. **Monitoring des performances**
|
||||
|
||||
### Court terme
|
||||
1. **Tests automatisés complets**
|
||||
2. **Documentation utilisateur**
|
||||
3. **Formation des utilisateurs**
|
||||
|
||||
### Moyen terme
|
||||
1. **Optimisation des performances**
|
||||
2. **Monitoring et analytics**
|
||||
3. **Nouvelles fonctionnalités**
|
||||
|
||||
## 🏆 Résultat final
|
||||
|
||||
### ✅ Succès accomplis
|
||||
- **Intégration complète** avec l'infrastructure 4NK_node
|
||||
- **Compilation WASM** fonctionnelle avec sdk_client et sdk_common
|
||||
- **Interface utilisateur** moderne et responsive
|
||||
- **Documentation complète** et à jour
|
||||
- **Scripts automatisés** pour le développement et le déploiement
|
||||
- **Configuration SSH** automatisée pour les pushes
|
||||
|
||||
### 🎉 Prêt pour la production
|
||||
L'interface utilisateur `ihm_client` est maintenant :
|
||||
- ✅ **Fonctionnelle** - Toutes les fonctionnalités opérationnelles
|
||||
- ✅ **Intégrée** - Connectée à l'infrastructure 4NK_node
|
||||
- ✅ **Documentée** - Documentation complète et à jour
|
||||
- ✅ **Automatisée** - Scripts de déploiement et de développement
|
||||
- ✅ **Optimisée** - Build de production optimisé
|
||||
|
||||
## 📞 Support et maintenance
|
||||
|
||||
### En cas de problème
|
||||
1. Vérifier la documentation : `docs/`
|
||||
2. Consulter les logs : `docker-compose logs ihm_client`
|
||||
3. Créer une issue sur Gitea
|
||||
4. Contacter l'équipe de développement
|
||||
|
||||
### Maintenance
|
||||
- **Mises à jour** : Via les scripts automatisés
|
||||
- **Monitoring** : Logs Docker et métriques de performance
|
||||
- **Backup** : Code versionné sur Gitea
|
||||
|
||||
---
|
||||
|
||||
**🎯 CONCLUSION** : Le projet `ihm_client` est **complètement opérationnel** et **prêt pour la production** dans l'infrastructure 4NK_node.
|
||||
|
||||
**État final** : ✅ **SUCCÈS COMPLET**
|
||||
**Dernière mise à jour** : 25 août 2025
|
||||
**Version** : docker-support (Production-ready)
|
||||
Loading…
x
Reference in New Issue
Block a user