**Motivations :**
- Afficher l'avancement des n° de blocks et % dans le champ message pour la page de scan des blocs
- Corriger le HTML du pairing qui était cassé (contenu mal injecté)
**Modifications :**
- block-sync.ts : Interception des messages 'Scan progress:' pour afficher le progrès en temps réel
- block-sync.ts : Mise à jour de l'interface avec currentBlock/totalBlocks et pourcentage
- block-sync.ts : Barre de progression dynamique basée sur le pourcentage de scan
- pairing.ts : Correction de l'injection du contenu HTML (mockContainer contient tout le contenu)
- pairing.ts : Simplification de la logique d'injection du contenu de home.html
**Pages affectées :**
- src/pages/block-sync/block-sync.ts : Affichage du progrès de scan en temps réel
- src/pages/pairing/pairing.ts : Correction de la structure HTML du pairing
**Motivations :**
- this.updateUserStatus is not a function dans la méthode statique getInstance()
- Dans une méthode statique, this n'existe pas
- Besoin d'une fonction helper pour mettre à jour le statut depuis un contexte statique
**Modifications :**
- service.ts : Création de la fonction helper updateUserStatusHelper() pour être utilisée dans les méthodes statiques
- service.ts : Remplacement de this.updateUserStatus() par updateUserStatusHelper() dans getInstance()
- service.ts : La méthode privée updateUserStatus() reste disponible pour les méthodes d'instance
**Pages affectées :**
- src/services/service.ts : Correction des appels à updateUserStatus dans le contexte statique
**Motivations :**
- La modale 'Initializing services...' n'est plus nécessaire
- Les messages de statut dans le champ des messages sont plus appropriés
- Simplification de l'interface utilisateur
**Modifications :**
- service.ts : Suppression des fonctions showGlobalLoadingSpinner et hideGlobalLoadingSpinner
- service.ts : Remplacement de la modale par updateUserStatus('🔄 Initializing services...')
- service.ts : Ajout d'un message de succès après initialisation
**Pages affectées :**
- src/services/service.ts : Suppression de la modale et utilisation des messages de statut
**Motivations :**
- La page birthday-setup pouvait s'afficher deux fois à cause de redirections multiples
- Plusieurs pages (router, block-sync, pairing, home) peuvent rediriger vers birthday-setup
- Il n'y avait pas de protection contre les initialisations multiples
**Modifications :**
- birthday-setup.ts : Ajout de la protection isInitializing pour éviter les initialisations multiples
- Logs de débogage : Ajout de logs pour tracer l'URL et le referrer
**Pages affectées :**
- src/pages/birthday-setup/birthday-setup.ts : Protection contre les initialisations multiples
**Motivations :**
- Le scan des blocs était refait inutilement dans la page de pairing même si le wallet était déjà synchronisé
- Le HTML de la page de pairing était cassé à cause de la duplication du CSS
- ensureCompleteInitialScan() forçait un scan complet sans vérifier l'état de synchronisation
**Modifications :**
- service.ts : Ajout de vérification de synchronisation dans ensureCompleteInitialScan() pour éviter les scans redondants
- pairing.ts : Suppression de la duplication du CSS et simplification de l'injection de contenu
- Logs améliorés : Ajout de logs pour indiquer si le wallet est déjà synchronisé
**Pages affectées :**
- src/services/service.ts : Optimisation de ensureCompleteInitialScan()
- src/pages/pairing/pairing.ts : Correction de l'affichage HTML
**Motivations :**
- La page de pairing ne faisait pas explicitement le handshake avant de lancer le processus
- prepareAndSendPairingTx() appelait getDeviceAddress() sans s'assurer que les relays étaient connectés
- Le script pouvait rester bloqué sur l'attente des relays car connectAllRelays() n'était jamais appelé
**Modifications :**
- sp-address.utils.ts : Ajout de l'appel à connectAllRelays() au début de prepareAndSendPairingTx()
- Logs explicites : Ajout de logs pour indiquer la connexion aux relays et le handshake
**Pages affectées :**
- src/utils/sp-address.utils.ts : Appel explicite à connectAllRelays() avant le processus de pairing
**Motivations :**
- Le HTML de la page de pairing était cassé avec tous les blocs à la suite
- Le script s'arrêtait sur l'attente des relays sans timeout de fallback
- Le CSS de 4nk.css était chargé après le CSS inline, causant des conflits
**Modifications :**
- pairing.html : Déplacé le lien vers 4nk.css avant le CSS inline pour éviter les conflits
- service.ts : Ajouté un timeout de 10 secondes dans getRelayReadyPromise() pour éviter l'attente infinie
- service.ts : Ajouté une résolution manuelle de relayReadyPromise dans connectAllRelays() si le handshake timeout
- service.ts : Supprimé le paramètre reject inutilisé dans la Promise
**Pages affectées :**
- src/pages/pairing/pairing.html : Ordre de chargement CSS corrigé
- src/services/service.ts : Timeout et fallback pour les relays
**Motivations :**
- Le pairing échouait avec l'erreur 'Wallet keys not available - WebAuthn decryption required'
- Le device stocké en base ne contenait pas les clés spend_key et scan_key dans sp_wallet
- Ces clés étaient stockées séparément dans les credentials chiffrés
- Il fallait restaurer ces clés dans le device en mémoire avant de pouvoir les utiliser
**Modifications :**
- ensureWalletKeysAvailable() : Maintenant asynchrone, vérifie si les clés sont disponibles dans le device en mémoire, sinon les restaure depuis les credentials
- Restauration des clés : Si les clés ne sont pas en mémoire, la méthode récupère les credentials, restaure les clés dans le device, et le restaure via restoreDevice()
- Méthodes asynchrones : getAmount() et getDeviceAddress() sont maintenant asynchrones pour supporter la restauration des clés
- Appels mis à jour : Tous les appels à ces méthodes ont été mis à jour avec await
**Pages affectées :**
- src/services/service.ts : Restauration automatique des clés depuis les credentials
- src/utils/sp-address.utils.ts : Appels asynchrones à getDeviceAddress()
- src/router.ts : Appels asynchrones à getDeviceAddress()
- src/components/device-management/device-management.ts : Appels asynchrones à getDeviceAddress()
- src/services/iframe-pairing.service.ts : Appels asynchrones à getDeviceAddress()
**Motivations :**
- La fonction initHomePage cherche login-4nk-component qui n'existe pas dans la page standalone
- Créer un conteneur mock pour que getCorrectDOM fonctionne
**Modifications :**
- Créer un conteneur mock login-4nk-component dans pairing.ts
- Déplacer le contenu pairing-container dans ce conteneur
**Pages affectées :**
- src/pages/pairing/pairing.ts (ajout conteneur mock)
**Motivations :**
- Créer une page standalone pour le pairing comme les autres étapes (security-setup, wallet-setup, etc.)
- Uniformiser le format des pages de setup avec une structure HTML complète
- Faciliter la redirection depuis block-sync vers pairing
**Modifications :**
- Créer src/pages/pairing/pairing.html (page HTML complète comme les autres)
- Créer src/pages/pairing/pairing.ts (charge la logique depuis home.ts)
- Ajouter la route pairing dans router.ts
- Mettre à jour les redirections dans block-sync.ts pour utiliser pairing.html
- Mettre à jour checkStorageStateAndNavigate pour rediriger vers pairing
**Pages affectées :**
- src/pages/pairing/pairing.html (nouveau fichier)
- src/pages/pairing/pairing.ts (nouveau fichier)
- src/router.ts (ajout route pairing)
- src/pages/block-sync/block-sync.ts (redirection vers pairing.html)
**Motivations :**
- La page home.html est un fragment HTML, pas une page complète
- Elle doit être chargée via le router, pas directement
- Redirection vers la racine pour que le router charge correctement la page
**Modifications :**
- Changer toutes les redirections de /src/pages/home/home.html vers / (racine)
- Le router détectera automatiquement que l'utilisateur doit aller au pairing et chargera la page correctement
**Pages affectées :**
- src/pages/block-sync/block-sync.ts (redirection vers racine au lieu de home.html)
**Motivations :**
- Passer automatiquement au pairing après 3 secondes une fois la synchronisation terminée
- Améliorer le texte du bouton pour indiquer qu'on va au pairing
**Modifications :**
- Ajouter redirection automatique après 3 secondes quand synchronisation terminée (blocs déjà synchronisés ou scan complété)
- Changer le texte du bouton de "Terminer la synchronisation" à "Aller au pairing"
- Mettre à jour le statut pour indiquer la redirection automatique
**Pages affectées :**
- src/pages/block-sync/block-sync.html (texte du bouton)
- src/pages/block-sync/block-sync.ts (redirection automatique après 3 secondes)
**Motivations :**
- Uniformiser le style de la page block-sync avec les autres pages de setup
- Corriger la redirection pour aller vers la page de pairing au lieu de checkStorageStateAndNavigate
**Modifications :**
- Uniformiser le style HTML/CSS de block-sync.html avec birthday-setup et wallet-setup
- Changer la redirection du bouton pour aller vers /src/pages/home/home.html
- Utiliser le même fond dégradé et la même carte blanche centrée
**Pages affectées :**
- src/pages/block-sync/block-sync.html (style uniformisé)
- src/pages/block-sync/block-sync.ts (redirection vers pairing)
**Motivations :**
- WebAssembly échoue même avec 40% de mémoire utilisée, nécessite au moins 150MB disponibles
- Ajouter une vérification mémoire plus stricte avant d'importer WebAssembly
- Améliorer le nettoyage mémoire dans wallet-setup avant l'initialisation
**Modifications :**
- Ajouter vérification mémoire avant import WebAssembly dans service.ts init()
- Vérifier que plus de 150MB sont disponibles ou moins de 85% utilisés
- Améliorer nettoyage mémoire dans wallet-setup si >75% utilisé
- Lancer erreur explicite si mémoire insuffisante avec détails
**Pages affectées :**
- src/services/service.ts (vérification mémoire avant import WebAssembly)
- src/pages/wallet-setup/wallet-setup.ts (nettoyage mémoire amélioré)
**Motivations :**
- Éviter d'initialiser WebAssembly si les prérequis ne sont pas remplis
- Réduire la consommation mémoire en vérifiant d'abord les prérequis légers
- Éviter le router d'initialiser Services lors de la vérification du pairing
**Modifications :**
- Déplacer la vérification PBKDF2 AVANT l'initialisation de Services dans wallet-setup.ts
- Supprimer l'initialisation de Services dans router.ts lors de la vérification du pairing
- Router redirige maintenant directement vers home sans vérifier le pairing
**Pages affectées :**
- src/router.ts (supprime Services.getInstance() lors de la vérification du pairing)
- src/pages/wallet-setup/wallet-setup.ts (vérifie prérequis avant Services)
**Motivations :**
- Corriger l'erreur de compilation dans block-sync.ts où services n'était plus défini
- Supprimer les derniers imports commentés restants
**Modifications :**
- Restaurer l'initialisation de Services dans block-sync.ts après les vérifications de prérequis
- Supprimer les imports commentés dans pairing.service.ts et iframe-pairing.service.ts
**Pages affectées :**
- src/pages/block-sync/block-sync.ts (restauration de l'initialisation Services)
- src/services/pairing.service.ts (supprime imports commentés)
- src/services/iframe-pairing.service.ts (supprime import commenté)
**Motivations :**
- Éliminer la duplication de code pour la vérification PBKDF2 key
- Éliminer la duplication de code pour la vérification du wallet avec retries
- Supprimer les imports commentés (code mort)
- Centraliser la logique de vérification des prérequis dans un utilitaire
**Modifications :**
- Créer src/utils/prerequisites.utils.ts avec checkPBKDF2Key() et checkWalletWithRetries()
- Remplacer toutes les occurrences dupliquées dans router.ts, home.ts, birthday-setup.ts, block-sync.ts, wallet-setup.ts
- Supprimer les imports commentés dans device-management.ts, pairing.service.ts, modal.service.ts
- Utiliser pbkdf2KeyResult.key au lieu de récupérer la clé plusieurs fois dans wallet-setup.ts
**Pages affectées :**
- src/utils/prerequisites.utils.ts (nouveau fichier utilitaire)
- src/router.ts (utilise checkPBKDF2Key)
- src/pages/home/home.ts (utilise checkPBKDF2Key, checkWalletWithRetries)
- src/pages/birthday-setup/birthday-setup.ts (utilise checkPBKDF2Key, checkWalletWithRetries)
- src/pages/block-sync/block-sync.ts (utilise checkPBKDF2Key, checkWalletWithRetries)
- src/pages/wallet-setup/wallet-setup.ts (utilise checkPBKDF2Key, pbkdf2KeyResult.key)
- src/services/service.ts (supprime imports commentés)
- src/components/device-management/device-management.ts (supprime import commenté)
- src/services/pairing.service.ts (supprime imports commentés)
- src/services/modal.service.ts (supprime import commenté)
**Motivations :**
- La page d'accueil doit rediriger automatiquement vers security-setup si aucune clé PBKDF2 n'est trouvée
- Éviter d'initialiser WebAssembly au démarrage pour une première visite
- Le processus doit avancer automatiquement au fur et à mesure des vérifications
**Modifications :**
- Modifier checkStorageStateAndNavigate() pour utiliser DeviceReaderService au lieu de Services
- Commencer par vérifier la clé PBKDF2 (étape la plus précoce)
- Ne pas initialiser Services.getInstance() au démarrage dans init()
- Ajouter la route block-sync dans routes
- Rediriger vers security-setup par défaut si aucune clé PBKDF2 trouvée
**Pages affectées :**
- src/router.ts (logique de redirection optimisée, route block-sync ajoutée)
**Motivations :**
- Uniformiser l'utilisation de bigint au lieu du type BigInt TypeScript
- Corriger les erreurs de comparaison entre bigint et BigInt
**Modifications :**
- Changer toutes les références BigInt en bigint
- Utiliser 0n au lieu de BigInt(0)
- Utiliser 10n au lieu de BigInt(10)
**Pages affectées :**
- src/services/service.ts (types BigInt -> bigint, constantes)
**Motivations :**
- Corriger le type de retour de getAmount() pour utiliser bigint au lieu de BigInt
- Utiliser @ts-ignore au lieu de @ts-expect-error pour PasswordCredential API
**Modifications :**
- Changer getAmount() return type de BigInt à bigint
- Remplacer @ts-expect-error par @ts-ignore pour PasswordCredential
**Pages affectées :**
- src/services/service.ts (type de retour getAmount)
- src/services/secure-credentials.service.ts (annotations PasswordCredential)
**Motivations :**
- Corriger les erreurs TypeScript qui bloquaient la compilation
- Corriger les erreurs ESLint pour améliorer la qualité du code
- Utiliser les bons formats pour secureLogger.error
**Modifications :**
- Corriger les appels secureLogger.error pour passer error comme 2e paramètre
- Ajouter les imports manquants (Database dans security-mode.service.ts)
- Préfixer les variables non utilisées avec _ pour respecter ESLint
- Corriger les comparaisons BigInt (utiliser BigInt(0) au lieu de 0n)
- Ajouter @ts-expect-error pour PasswordCredential API expérimentale
- Corriger le paramètre services non utilisé dans router.ts
**Pages affectées :**
- src/services/service.ts (comparaisons BigInt, imports)
- src/services/security-mode.service.ts (import Database)
- src/services/secure-credentials.service.ts (secureLogger.error, PasswordCredential)
- src/services/credentials/encryption.service.ts (secureLogger.error, salt type)
- src/router.ts (paramètre _services)
- src/components/device-management/device-management.ts (variable _data)
- src/components/secure-credentials/secure-credentials.ts (variable _error)
- src/components/security-mode-selector/security-mode-selector.ts (paramètre _mode)
- src/components/login-modal/login-modal.js (window globals)
**Motivations :**
- Les imports dynamiques causaient des erreurs de redéclaration TypeScript
- L'erreur 500 venait de ces erreurs de compilation
- Les imports statiques sont plus fiables avec Vite
**Modifications :**
- Ajouter les imports statiques de SecureCredentialsService et SecurityModeService en haut de home.ts
- Remplacer tous les imports dynamiques par des références aux imports statiques
- Supprimer les redéclarations de SecureCredentialsService qui causaient l'erreur TS2451
**Pages affectées :**
- src/pages/home/home.ts (imports statiques)
**Motivations :**
- Créer un script shell pour linter tout le projet avec correction automatique
- Faciliter l'exécution du linting avec --fix
**Modifications :**
- Créer lint-all.sh qui appelle npm run lint (qui inclut déjà --fix)
- Rendre le script exécutable
**Pages affectées :**
- lint-all.sh (nouveau script)
**Motivations :**
- Les imports dynamiques peuvent causer des problèmes de compilation avec Vite
- Remplacer await import() par des imports statiques en haut du fichier
- Simplifier le code et améliorer la compatibilité avec Vite
**Modifications :**
- Remplacer les imports dynamiques par des imports statiques dans device-reader.service.ts
- Importer SecureCredentialsService et EncryptionService en haut du fichier
- Supprimer la variable workingMode non utilisée
**Pages affectées :**
- src/services/device-reader.service.ts (imports statiques)
**Motivations :**
- Le projet a déjà ESLint mais la configuration était mixte (ancien et nouveau format)
- Améliorer la configuration pour gérer les Web Workers et les globals manquants
- Supprimer les fichiers de configuration obsolètes
**Modifications :**
- Supprimer .eslintrc.json (ancien format, ignoré par ESLint 9)
- Supprimer .eslintignore (remplacé par ignores dans eslint.config.js)
- Améliorer eslint.config.js avec les globals nécessaires (Web Workers, IndexedDB, etc.)
- Ajouter une configuration spécifique pour les fichiers worker.ts
- Les ignores sont maintenant centralisés dans eslint.config.js
**Pages affectées :**
- eslint.config.js (amélioration de la configuration)
- Suppression de .eslintrc.json et .eslintignore
**Motivations :**
- Erreur de syntaxe dans wallet-setup.ts (try/catch mal formé)
- Import de Device depuis SDK peut causer des erreurs de compilation
- Utiliser un type simplifié pour éviter les dépendances lourdes
**Modifications :**
- Corriger l'indentation du try/catch dans wallet-setup.ts
- Remplacer l'import Device par une interface simplifiée dans DeviceReaderService
- Cette interface couvre les champs nécessaires sans dépendre du SDK complet
**Pages affectées :**
- src/pages/wallet-setup/wallet-setup.ts (correction syntaxe)
- src/services/device-reader.service.ts (type simplifié)
**Motivations :**
- home.ts utilise Services uniquement pour getDeviceFromDatabase() et getDeviceAddress()
- Services initialise WebAssembly qui peut causer des erreurs de mémoire
- Créer un service léger qui lit le device sans WebAssembly
**Modifications :**
- Créer DeviceReaderService qui lit le device depuis IndexedDB sans WebAssembly
- Extraire getDeviceFromDatabase() et getDeviceAddress() dans DeviceReaderService
- Modifier home.ts pour utiliser DeviceReaderService au lieu de Services
- DeviceReaderService déchiffre le device et extrait l'adresse depuis sp_wallet.address
- Supprimer l'import de Services dans home.ts
**Pages affectées :**
- src/services/device-reader.service.ts (nouveau service léger)
- src/pages/home/home.ts (utilise DeviceReaderService au lieu de Services)
**Motivations :**
- Les erreurs de mémoire causent des tentatives multiples d'initialisation WebAssembly
- Services.initializing reste défini après une erreur, causant de nouvelles tentatives
- Les pages réessayent indéfiniment même en cas d'erreur mémoire fatale
**Modifications :**
- Réinitialiser Services.initializing à null dans le catch pour éviter les tentatives multiples
- Détecter les erreurs de mémoire et arrêter immédiatement les tentatives
- Ajouter la détection d'erreurs de mémoire dans wallet-setup, birthday-setup et block-sync
- Afficher un message clair à l'utilisateur pour actualiser la page en cas d'erreur mémoire
- Améliorer les messages d'erreur pour indiquer que l'actualisation de la page est nécessaire
**Pages affectées :**
- src/services/service.ts (réinitialisation de initializing et détection mémoire)
- src/pages/wallet-setup/wallet-setup.ts (détection erreurs mémoire)
- src/pages/birthday-setup/birthday-setup.ts (détection erreurs mémoire)
- src/pages/block-sync/block-sync.ts (détection erreurs mémoire)
**Motivations :**
- La page block-sync ne vérifie pas les prérequis comme les autres pages
- La synchronisation est simulée au lieu d'être réelle
- Il manque les vérifications de PBKDF2, wallet et birthday
**Modifications :**
- Ajout des vérifications de prérequis (PBKDF2 key, wallet, birthday) dans block-sync.ts
- Remplacement de la synchronisation simulée par une synchronisation réelle via updateDeviceBlockHeight()
- Ajout de la connexion aux relais si chain_tip n'est pas disponible
- Ajout de vérifications de wallet avec retry pour gérer les problèmes de synchronisation
- Ajout de la gestion d'erreur avec redirection vers les pages appropriées selon le type d'erreur
- Amélioration de la gestion d'erreur avec messages clairs et redirections automatiques
- Déplacement de l'écouteur du bouton continuer avant le try pour être toujours disponible
- Ajout de vérifications de nullité pour les éléments DOM
**Pages affectées :**
- src/pages/block-sync/block-sync.ts (ajout des vérifications de prérequis et synchronisation réelle)
- src/pages/home/home.ts (ajout des vérifications de prérequis pour la page de pairing)
**Motivations :**
- La vérification de chain_tip se fait trop tôt, avant que le handshake arrive
- Le code ne continue pas après updateDeviceBlockHeight(), besoin de logs pour comprendre pourquoi
- Ajouter des logs détaillés pour tracer le flux d'exécution
**Modifications :**
- Déplacer la vérification de chain_tip après l'attente du handshake dans birthday-setup.ts
- Améliorer la condition de vérification pour attendre chain_tip > 0
- Ajouter des logs détaillés à chaque étape dans birthday-setup.ts
- Ajouter un return explicite à la fin de updateDeviceBlockHeight() pour garantir qu'elle se termine correctement
- Ajouter des logs avant et après updateDeviceBlockHeight() pour tracer l'exécution
**Pages affectées :**
- src/pages/birthday-setup/birthday-setup.ts (attente du handshake avant vérification)
- src/services/service.ts (return explicite et logs)
**Motivations :**
- La documentation doit refléter l'état actuel du code
- Corriger les incohérences entre le code et la documentation
- Ajouter les messages manquants dans INTEGRATION.md
**Modifications :**
- CODE_ANALYSIS_REPORT.md : Mise à jour de la taille de service.ts (2275 -> 3265 lignes)
- CODE_ANALYSIS_REPORT.md : Correction de la description du cache (désactivé au lieu de non limité)
- PAIRING_SYSTEM_ANALYSIS.md : Mise à jour des recommandations pour refléter l'état actuel (corrections implémentées)
- INTEGRATION.md : Ajout des messages manquants (TEST_RESPONSE, LISTENING)
**Pages affectées :**
- CODE_ANALYSIS_REPORT.md
- docs/PAIRING_SYSTEM_ANALYSIS.md
- INTEGRATION.md
**Motivations :**
- La documentation doit refléter les améliorations récentes sur les vérifications réelles des logs
- Documenter le nouveau flux avec block-sync et les vérifications des prérequis
- Documenter le système de vérification réelle des logs pour faciliter la maintenance
**Modifications :**
- Ajout d'une section détaillée sur les vérifications des prérequis dans birthday-setup
- Documentation des vérifications réelles dans updateDeviceBlockHeight
- Documentation des vérifications réelles dans saveDeviceInDatabase
- Ajout de la section sur la redirection vers block-sync
- Mise à jour du diagramme de flux pour inclure block-sync et les vérifications
- Ajout d'une section complète sur le système de vérification réelle des logs
- Mise à jour de la gestion des erreurs avec les erreurs de vérification
- Ajout de points d'attention sur les vérifications réelles et block-sync
**Pages affectées :**
- docs/INITIALIZATION_FLOW.md (documentation complète mise à jour)
**Motivations :**
- Les logs étaient déclaratifs (juste des messages sans vérification réelle)
- Il faut vérifier réellement que les opérations sont réussies avant de logger le succès
- Les logs doivent refléter la réalité et non juste des déclarations
**Modifications :**
- Ajout de vérifications réelles dans updateDeviceBlockHeight() pour vérifier que le device est bien restauré en mémoire et sauvegardé en base
- Ajout de vérification dans saveDeviceInDatabase() pour vérifier que le wallet est bien sauvegardé après l'opération
- Ajout de vérifications dans birthday-setup.ts pour vérifier que les relais sont connectés, que le handshake est reçu, et que le birthday est bien mis à jour
- Les logs de succès sont maintenant émis uniquement après vérification réelle des résultats
- Amélioration de la gestion des erreurs avec messages explicites si les vérifications échouent
**Pages affectées :**
- src/services/service.ts (updateDeviceBlockHeight et saveDeviceInDatabase avec vérifications réelles)
- src/pages/birthday-setup/birthday-setup.ts (vérifications réelles des prérequis et du birthday)
**Motivations :**
- saveDeviceInDatabase() n'utilise pas directement IndexedDB, ce qui peut causer des problèmes de synchronisation
- Il manque des logs pour déboguer pourquoi le wallet n'est pas sauvegardé après updateDeviceBlockHeight()
- Utiliser directement IndexedDB comme dans getDeviceFromDatabase() pour éviter les problèmes de service worker
**Modifications :**
- Remplacement de Database.getInstance() par un accès direct à IndexedDB dans saveDeviceInDatabase()
- Ajout de logs détaillés à chaque étape du processus de sauvegarde
- Utilisation de put() au lieu de delete() puis add() pour éviter les problèmes de timing
- Amélioration de la gestion des erreurs avec logs explicites pour chaque étape
**Pages affectées :**
- src/services/service.ts (saveDeviceInDatabase utilise maintenant IndexedDB directement)
**Motivations :**
- saveDeviceInDatabase() sauvegardait le device en clair, écrasant le wallet chiffré
- wallet-setup.ts sauvegarde le device chiffré avec encrypted_device et encrypted_wallet
- Après updateDeviceBlockHeight(), le wallet était écrasé par un wallet en clair
- Violation de sécurité: le wallet ne doit jamais être stocké en clair
**Modifications :**
- Modification de saveDeviceInDatabase() pour chiffrer le device avant sauvegarde
- Récupération de la clé PBKDF2 pour chiffrer le device
- Préservation de encrypted_wallet lors de la sauvegarde
- Utilisation du même format que wallet-setup.ts (encrypted_device + encrypted_wallet)
- Amélioration de la gestion des erreurs avec logs explicites
**Pages affectées :**
- src/services/service.ts (saveDeviceInDatabase chiffre maintenant le device)
**Motivations :**
- birthday-setup.ts utilisait getPBKDF2Key() qui n'existe pas dans SecureCredentialsService
- wallet-setup.ts trouve la clé PBKDF2 mais birthday-setup.ts ne la trouve pas
- Il faut utiliser les mêmes méthodes que wallet-setup.ts (hasPBKDF2Key + retrievePBKDF2Key)
**Modifications :**
- Remplacement de getPBKDF2Key() par hasPBKDF2Key() puis retrievePBKDF2Key()
- Utilisation de la même approche que wallet-setup.ts pour vérifier la clé PBKDF2
- Ajout du mode 'otp' à la liste des modes de sécurité pour correspondre à wallet-setup.ts
- Amélioration des messages de log pour indiquer explicitement la vérification dans le store pbkdf2keys
**Pages affectées :**
- src/pages/birthday-setup/birthday-setup.ts (correction de la vérification PBKDF2)
**Motivations :**
- La vérification des prérequis ne vérifiait pas réellement la présence de la clé PBKDF2 dans le store pbkdf2keys
- Il y avait une duplication de code pour la vérification de la clé PBKDF2
- Le mode de sécurité était recherché deux fois au lieu d'être réutilisé
**Modifications :**
- Déplacement de la vérification réelle de la clé PBKDF2 dans la section des prérequis
- Vérification explicite de la présence de la clé dans le store pbkdf2keys avant de continuer
- Stockage du mode de sécurité trouvé dans une variable au niveau supérieur pour réutilisation
- Suppression de la vérification dupliquée plus tard dans le code
- Amélioration des messages de log pour indiquer explicitement la vérification dans le store pbkdf2keys
**Pages affectées :**
- src/pages/wallet-setup/wallet-setup.ts (vérification des prérequis améliorée)
**Motivations :**
- Le wallet disparaît parfois entre wallet-setup et birthday-setup à cause de problèmes de synchronisation
- Il faut ajouter une logique de retry pour gérer les problèmes de synchronisation de la base de données
- Donner plus de temps à la base de données pour synchroniser les données avant de rediriger
**Modifications :**
- Ajout d'une logique de retry dans birthday-setup.ts pour récupérer le wallet
- Attente de 500ms entre chaque tentative (jusqu'à 5 tentatives)
- Redirection vers wallet-setup seulement si le wallet n'est toujours pas trouvé après les retries
- Cette logique permet de gérer les problèmes de synchronisation de la base de données
**Pages affectées :**
- src/pages/birthday-setup/birthday-setup.ts (logique de retry pour le wallet)
**Motivations :**
- Chaque page doit vérifier ses prérequis et rediriger automatiquement si nécessaire
- Erreur avec SecureCredentialsService: 'is not a constructor'
- Amélioration de l'ordre de vérification des prérequis (PBKDF2 key d'abord, puis wallet)
- Redirection automatique vers la page appropriée si les prérequis ne sont pas remplis
**Modifications :**
- Correction de l'utilisation de SecureCredentialsService: utilisation de getInstance() au lieu de new
- Amélioration de la vérification des prérequis dans birthday-setup.ts avec redirection automatique
- Vérification du PBKDF2 key en premier (prérequis le plus basique)
- Redirection vers security-setup si le PBKDF2 key n'est pas trouvé
- Redirection vers wallet-setup si le wallet n'est pas trouvé
- Amélioration de wallet-setup.ts pour rediriger vers security-setup si aucune clé PBKDF2 n'est trouvée
**Pages affectées :**
- src/pages/birthday-setup/birthday-setup.ts (vérification des prérequis améliorée)
- src/pages/wallet-setup/wallet-setup.ts (redirection vers security-setup)
**Motivations :**
- Chaque page doit vérifier ses prérequis en base pour éviter les erreurs
- La page birthday-setup s'arrêtait sans wallet en base
- Il faut s'assurer que le wallet et le PBKDF2 key existent avant de continuer
**Modifications :**
- Ajout de la vérification des prérequis dans birthday-setup.ts
- Vérification que le wallet existe en base de données
- Vérification que le PBKDF2 key existe pour au moins un mode de sécurité
- Ajout de messages d'erreur explicites si les prérequis ne sont pas remplis
- Amélioration de la vérification des prérequis dans wallet-setup.ts
**Pages affectées :**
- src/pages/birthday-setup/birthday-setup.ts (vérification des prérequis)
- src/pages/wallet-setup/wallet-setup.ts (amélioration de la vérification)
**Motivations :**
- Chaque page créait une nouvelle instance des services, causant des problèmes de synchronisation
- Le wallet disparaissait entre les pages à cause de cette incohérence
- Il faut utiliser l'instance existante des services pour maintenir la cohérence
**Modifications :**
- Suppression de la boucle d'attente pour l'initialisation des services
- Utilisation directe de Services.getInstance() pour obtenir l'instance existante
- Simplification du code d'initialisation des services
**Pages affectées :**
- src/pages/birthday-setup/birthday-setup.ts (utilisation de l'instance existante)
**Motivations :**
- Le texte du bouton était toujours 'Terminer l'initialisation' au lieu de 'Synchroniser les blocs'
- La boucle d'attente de la hauteur de bloc était inefficace et atteignait le timeout
- Il faut une approche plus robuste pour attendre le handshake
**Modifications :**
- Changement du texte du bouton de 'Terminer l'initialisation' à 'Synchroniser les blocs'
- Remplacement de la boucle d'attente par une approche basée sur Promise avec timeout
- Augmentation du timeout à 15 secondes pour laisser plus de temps au handshake
- Amélioration de la logique d'attente de la hauteur de bloc
**Pages affectées :**
- src/pages/birthday-setup/birthday-setup.html (texte du bouton)
- src/pages/birthday-setup/birthday-setup.ts (mécanisme d'attente)
**Motivations :**
- La page birthday-setup s'arrêtait après la mise à jour de la date anniversaire
- Le processus devrait continuer vers une page de synchronisation des blocs
- Création d'une page dédiée pour la synchronisation des blocs
**Modifications :**
- Modification de birthday-setup.ts pour rediriger vers block-sync après la mise à jour de la date anniversaire
- Suppression du scan complet et de la synchronisation des processus de birthday-setup
- Création de la page block-sync.html avec interface de synchronisation
- Création de block-sync.ts avec logique de synchronisation des blocs
- Interface utilisateur avec détails de synchronisation et barre de progression
**Pages affectées :**
- src/pages/birthday-setup/birthday-setup.ts (redirection vers block-sync)
- src/pages/block-sync/block-sync.html (nouvelle page)
- src/pages/block-sync/block-sync.ts (nouvelle logique)
**Motivations :**
- Le handshake arrive après le timeout de 3 secondes dans waitForHandshakeMessage
- La boucle d'attente de la hauteur de bloc atteint 30 tentatives avant que le handshake soit traité
- Il faut augmenter les timeouts pour permettre au handshake d'arriver
**Modifications :**
- Augmentation du timeout de waitForHandshakeMessage de 3 à 10 secondes
- Augmentation du nombre de tentatives dans la boucle d'attente de 30 à 100 (10 secondes)
- Cela donne plus de temps au handshake pour arriver et définir la hauteur de bloc
**Pages affectées :**
- src/services/service.ts (timeout waitForHandshakeMessage)
- src/pages/birthday-setup/birthday-setup.ts (nombre de tentatives)
**Motivations :**
- Erreur de redéclaration des variables 'attempts' et 'maxAttempts' dans birthday-setup.ts
- Cela causait une erreur 500 lors du chargement du fichier TypeScript
**Modifications :**
- Renommage des variables dans la deuxième boucle d'attente pour éviter les conflits
- Utilisation de 'blockHeightAttempts' et 'blockHeightMaxAttempts' pour la boucle d'attente de la hauteur de bloc
**Pages affectées :**
- src/pages/birthday-setup/birthday-setup.ts (correction des variables redéclarées)
**Motivations :**
- L'erreur 'Current block height not set' se produit car updateDeviceBlockHeight est appelé avant que le handshake soit complètement traité
- Il faut attendre que this.currentBlockHeight soit défini avant de mettre à jour la date anniversaire
**Modifications :**
- Ajout de la méthode publique getCurrentBlockHeight() dans Services
- Modification de birthday-setup.ts pour attendre que la hauteur de bloc soit définie
- Ajout d'une boucle d'attente avec timeout pour s'assurer que le handshake est traité
**Pages affectées :**
- src/services/service.ts (getCurrentBlockHeight)
- src/pages/birthday-setup/birthday-setup.ts (attente de la hauteur de bloc)
**Motivations :**
- L'erreur 'Device not found' se produit lors de la mise à jour de la date anniversaire
- Le wallet est bien créé et sauvegardé mais n'est pas trouvé lors de la récupération
- Problème d'incohérence entre l'accès direct à IndexedDB et l'accès via service worker
**Modifications :**
- Ajout de logs de débogage dans getDeviceFromDatabase pour tracer le problème
- Modification de getDeviceFromDatabase pour utiliser directement IndexedDB au lieu du service worker
- Correction des erreurs TypeScript dans birthday-setup.ts et home.ts
- Correction des comparaisons BigInt dans service.ts
- Modification de birthday-setup.ts pour éviter l'utilisation de méthodes privées
**Pages affectées :**
- src/services/service.ts (getDeviceFromDatabase, updateDeviceBlockHeight)
- src/services/database.service.ts (getObject)
- src/pages/birthday-setup/birthday-setup.ts
- src/pages/home/home.ts
- src/components/security-mode-selector/security-mode-selector.ts
