**Motivations :**
- restore_device() ne met pas à jour les clés dans le SpClient interne
- create_device_from_sp_wallet() crée un nouveau device avec les clés mises à jour
- Cela force le SDK à reconnaître les nouvelles clés
**Modifications :**
- src/services/service.ts : Remplacé restoreDevice() par create_device_from_sp_wallet()
- Utilise dumpWallet() pour récupérer le JSON du SpClient avec les clés mises à jour
- Supprimé l'injection manuelle des clés dans le device en mémoire
- Fallback vers restoreDevice() si create_device_from_sp_wallet() échoue
**Pages affectées :**
- src/services/service.ts : Amélioration de ensureWalletKeysAvailable() pour forcer la reconnaissance des clés
**Motivations :**
- Les credentials contenaient des clés aléatoires sans lien avec le wallet SDK
- Les vraies clés du wallet (spend_key, scan_key) n'étaient jamais sauvegardées
- Quand on restaurait le wallet, les clés injectées n'étaient pas les bonnes
- Le SDK ne pouvait donc pas détecter les fonds
**Modifications :**
- src/services/secure-credentials.service.ts : generateEncryptedCredentials() extrait maintenant les vraies clés via dumpWallet()
- Les clés sont extraites du wallet SDK (spend_key.Secret et scan_sk)
- Les vraies clés sont chiffrées et stockées dans les credentials
- Lors de la restauration, les vraies clés du wallet sont réinjectées
**Pages affectées :**
- src/services/secure-credentials.service.ts : Correction de generateEncryptedCredentials() pour extraire les vraies clés
**Motivations :**
- Les clés sont injectées correctement mais le SDK ne les reconnaît pas
- has_spend_key: false, has_scan_key: false malgré l'injection des clés
- restoreDevice() ne met pas à jour les clés dans le SDK
**Modifications :**
- src/services/service.ts : Ajout d'appel à dumpWallet() après restoreDevice()
- dumpWallet() force la mise à jour des clés dans le SDK
- Appliqué aux deux endroits où les clés sont injectées
**Pages affectées :**
- src/services/service.ts : Amélioration de ensureWalletKeysAvailable() pour forcer la mise à jour SDK
**Motivations :**
- Le faucet fonctionne mais les clés ne sont pas reconnues par le SDK
- has_spend_key: false, has_scan_key: false malgré l'injection des clés
- Le format des clés n'est pas correct pour le SDK
**Modifications :**
- src/services/service.ts : Correction du format de spend_key en objet {Secret: string}
- Ajout de logs pour vérifier le format des clés injectées
- Cela correspond au format attendu par le SDK
**Pages affectées :**
- src/services/service.ts : Amélioration de ensureWalletKeysAvailable() pour le bon format des clés
**Motivations :**
- Le faucet s'exécute pendant birthday-setup mais les credentials n'existent pas encore
- Cela cause des erreurs 'No credentials found' et 'WebAuthn decryption required'
- Le faucet doit s'exécuter après la création des credentials dans la page de pairing
**Modifications :**
- src/services/service.ts : Désactivation de l'appel automatique du faucet dans updateDeviceBlockHeight()
- src/services/service.ts : Rendre getTokensFromFaucet() public pour l'appeler depuis home.ts
- src/pages/home/home.ts : Ajout de l'appel du faucet après la création des credentials
**Pages affectées :**
- src/services/service.ts : Amélioration de la gestion du faucet
- src/pages/home/home.ts : Ajout de l'appel du faucet au bon moment
**Motivations :**
- Le faucet envoie des fonds mais le wallet ne les détecte toujours pas
- Les clés sont restaurées mais le SDK ne les reconnaît pas
- Besoin d'injecter les clés directement dans le device en mémoire
**Modifications :**
- src/services/service.ts : Injection directe des clés dans le device en mémoire après restauration
- Cela force le SDK à reconnaître les clés restaurées et à détecter les fonds
**Pages affectées :**
- src/services/service.ts : Amélioration de ensureWalletKeysAvailable() pour injection directe des clés
**Motivations :**
- Le faucet envoie des fonds mais le wallet ne les détecte pas
- Les clés sont restaurées mais le SDK ne les reconnaît pas
- Besoin de forcer la régénération du wallet après restauration
**Modifications :**
- src/services/service.ts : Ajout de dump_wallet() après restoreDevice() pour forcer la mise à jour des clés dans le SDK
- Cela permet au SDK de reconnaître les clés restaurées et de détecter les fonds
**Pages affectées :**
- src/services/service.ts : Amélioration de ensureWalletKeysAvailable() pour forcer la régénération du wallet
**Motivations :**
- Les nouveaux wallets n'avaient pas de fonds automatiquement
- Le système de faucet existe mais n'était pas déclenché au démarrage
- Besoin de fonds pour tester les fonctionnalités
**Modifications :**
- src/services/service.ts : Ajout de l'appel automatique au faucet après la synchronisation initiale des nouveaux wallets
- Le faucet est appelé dans updateDeviceBlockHeight() après la création d'un nouveau wallet
- Gestion d'erreur non-critique si le faucet échoue
**Pages affectées :**
- src/services/service.ts : Ajout de la demande automatique de fonds pour les nouveaux wallets
**Motivations :**
- forceWalletGeneration() recréait un wallet vierge au lieu d'utiliser le wallet préparé
- Les pages avaient des styles incohérents et des problèmes d'affichage
- Besoin d'un template standardisé pour toutes les pages d'initialisation
**Modifications :**
- service.ts : Suppression de forceWalletGeneration() dans restoreDevice()
- src/templates/page-template.html : Template HTML standardisé pour toutes les pages
- src/utils/page-template.utils.ts : Classe utilitaire pour gérer le template
- src/pages/pairing/pairing.html : Refonte avec le template standardisé
- src/pages/pairing/pairing.ts : Utilisation du template avec PageTemplate
- src/pages/block-sync/block-sync.html : Refonte avec le template standardisé
- src/pages/block-sync/block-sync.ts : Utilisation du template avec PageTemplate
**Pages affectées :**
- src/services/service.ts : Suppression de la génération forcée de wallet
- src/templates/ : Nouveau template standardisé
- src/utils/page-template.utils.ts : Nouvelle classe utilitaire
- src/pages/pairing/ : Refonte complète avec template
- src/pages/block-sync/ : Refonte complète avec template
**Motivations :**
- Le birthday était réinitialisé à 0 lors de la restauration des clés depuis les credentials dans pairing
- Le device en mémoire ne contenait pas le birthday, seulement le device en base de données
- Le wallet debugging info affichait birthday: 0 alors que birthday-setup avait été fait avec succès
**Modifications :**
- service.ts : ensureWalletKeysAvailable() restaure maintenant le device complet depuis la base de données
- service.ts : Injection des clés depuis les credentials dans le device de la base de données (qui contient birthday, last_scan)
- service.ts : Vérification que le birthday est préservé après restauration avec logs de débogage
**Pages affectées :**
- src/services/service.ts : Correction de la restauration du device avec préservation du birthday
**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 :**
- 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 :**
- É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 :**
- 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 :**
- 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 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 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 :**
- 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 :**
- 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
**Motivations:**
- Corriger les erreurs TypeScript dans secure-credentials.service.ts qui empêchaient le chargement du module
- Résoudre l'affichage cassé des pages de setup en utilisant une redirection directe
- Supprimer le mode 'browser' et nettoyer le code mort
**Modifications:**
- Correction de la méthode inexistante getEncryptedKey() dans secure-credentials.service.ts
- Correction de la redéclaration de variable encryptedKey dans generatePBKDF2Key()
- Suppression des références au mode 'browser' supprimé dans security-mode.service.ts
- Ajout des propriétés requiresOTP et requiresPassword dans l'interface SecurityModeConfig
- Suppression de la méthode retrieveKeyFromBrowser() non utilisée dans storage.service.ts
- Changement de stratégie de routage pour les pages de setup (redirection directe au lieu d'injection)
- Mise à jour des textes des options de sécurité (Proton Pass → Clé de sécurité, OTP → code à usage unique)
**Pages affectées:**
- src/services/secure-credentials.service.ts (correction des erreurs principales)
- src/services/security-mode.service.ts (correction des références au mode browser)
- src/services/credentials/storage.service.ts (suppression de la méthode non utilisée)
- src/router.ts (changement de stratégie de routage)
- src/pages/security-setup/security-setup.html (mise à jour des textes)
- src/pages/wallet-setup/wallet-setup.html (mise à jour des textes)
- src/components/security-mode-selector/ (suppression du mode browser)
- src/pages/home/home.ts (suppression du mode browser)
- src/services/service.ts (suppression du mode browser)
**Motivations :**
- Centralize database configuration to prevent version inconsistencies
- Fix service worker blocking during wallet setup
- Ensure all database stores are created at initialization
**Modifications :**
- Created database-config.ts with centralized DATABASE_CONFIG (name, version, stores)
- Updated storage.service.ts to use DATABASE_CONFIG and create all stores on upgrade
- Updated security-setup.ts to initialize database with complete configuration
- Updated wallet-setup.ts to call SDK directly and bypass service worker blocking
- Updated database.service.ts, webauthn.service.ts, and database.worker.js to use DATABASE_CONFIG
- Removed service worker dependency for wallet setup page
**Pages affected :**
- security-setup.html: Initializes database with all stores on page load
- wallet-setup.html: Saves wallet directly to IndexedDB without service worker dependency
**Motivations :**
- Implémentation du système de sélection de mode de sécurité
- Séparation claire entre les données de sécurité et les données du wallet
- Suppression des duplications entre 'encrypted-pbkdf2-key' et 'pbkdf2-key'
- Architecture modulaire pour la gestion des credentials
**Modifications :**
- Ajout du composant security-mode-selector pour la sélection du mode de sécurité
- Création des pages séquentielles : security-setup, wallet-setup, birthday-setup
- Implémentation des services de credentials (encryption, storage, webauthn)
- Ajout du service security-mode pour la gestion des modes de sécurité
- Correction du stockage des clés PBKDF2 avec le securityMode dynamique
- Suppression des méthodes redondantes dans StorageService
- Nettoyage des appels redondants dans secure-credentials.service.ts
**Pages affectées :**
- src/components/security-mode-selector/ (nouveau composant)
- src/pages/security-setup/ (nouvelle page)
- src/pages/wallet-setup/ (nouvelle page)
- src/pages/birthday-setup/ (nouvelle page)
- src/services/credentials/ (nouveaux services)
- src/services/security-mode.service.ts (nouveau service)
- src/services/secure-credentials.service.ts (modifié)
- src/services/database.service.ts (modifié)
- src/router.ts (modifié)
- src/pages/home/home.ts (modifié)
**Motivations :**
- Correction du problème WebAuthn qui ne se déclenche plus
- Ajout de vérifications pour s'assurer que le SDK est initialisé
- Ajout d'un fallback pour les clés personnalisées si les clés du SDK ne sont pas disponibles
**Modifications :**
- Ajout de vérification SDK dans getDeviceFromSDK()
- Ajout de logs pour diagnostiquer le problème
- Fallback vers generateSpendKey/generateScanKey si les clés du SDK ne sont pas disponibles
- Gestion d'erreur robuste pour éviter que WebAuthn échoue
**Pages affectées :**
- src/services/secure-credentials.service.ts
**Motivations :**
- Ajout de vérifications de blocage pour s'assurer que les clés du wallet sont disponibles
- Empêcher toute opération qui nécessite les clés avant que WebAuthn soit terminé
- Blocage des traitements jusqu'à ce que le wallet soit déchiffré
**Modifications :**
- Ajout de ensureWalletKeysAvailable() pour vérifier les clés avant toute opération
- Ajout de vérifications dans getAmount(), getDeviceAddress(), createProcess()
- Messages d'erreur explicites quand les clés ne sont pas disponibles
**Pages affectées :**
- src/services/service.ts
**Motivations :**
- Correction du chiffrement : PBKDF2 génère les clés du SDK, pas des clés personnalisées
- WebAuthn chiffre maintenant les clés du SDK générées par PBKDF2
- Ajout de getDeviceFromSDK() pour récupérer les clés du SDK
**Modifications :**
- Remplacement de generateSpendKey/generateScanKey par getDeviceFromSDK()
- WebAuthn chiffre maintenant device.sp_wallet.spend_key et device.sp_wallet.scan_key
- Ajout de la méthode getDeviceFromSDK() pour accéder au SDK
**Pages affectées :**
- src/services/secure-credentials.service.ts
**Motivations :**
- Correction de l'ordre des opérations : wallet créé AVANT WebAuthn
- Suppression de l'appel prématuré à get_available_amount dans createNewDevice
- Clarification que PBKDF2 génère les clés du SDK, pas des clés personnalisées
**Modifications :**
- Suppression de l'appel à get_available_amount dans createNewDevice()
- Conservation de dump_wallet() pour forcer la génération des clés
- get_available_amount reste appelé uniquement après les relais dans getAmount()
**Pages affectées :**
- src/services/service.ts
**Motivations :**
- Correction du problème des clés wallet manquantes (has_spend_key: false, has_scan_key: false)
- Ajout de méthodes pour forcer la génération des clés du SDK après création/restauration du device
- Clarification du rôle du PBKDF2 vs clés du SDK
**Modifications :**
- Ajout de dump_wallet() après create_new_device() pour forcer la génération des clés
- Ajout de get_available_amount() pour forcer la génération des clés internes du SDK
- Ajout de logs détaillés pour diagnostiquer la génération des clés
- Application de la même logique dans restoreDevice()
**Pages affectées :**
- src/services/service.ts
**Motivations :**
- Ajout de logs de débogage pour diagnostiquer le problème des clés wallet manquantes
- Optimisation de la logique de scan (scan AVANT faucet, puis APRÈS transaction)
- Extension de la plage de scan à 100 blocs au lieu de 10
**Modifications :**
- Ajout de logs détaillés dans createNewDevice() et updateDeviceBlockHeight()
- Modification de la logique de scan pour éviter les scans redondants
- Extension de la plage de scan pour les nouveaux wallets
- Ajout de logs de débogage pour le wallet state
**Pages affectées :**
- src/services/service.ts
- src/pages/home/home.ts
- src/router.ts
**Motivations :**
- Ajouter des logs de débogage pour comprendre pourquoi le wallet n'a pas de clés (has_spend_key: false, has_scan_key: false)
- Diagnostiquer le problème de génération des clés dans createNewDevice et updateDeviceBlockHeight
**Modifications :**
- src/services/service.ts: Ajout de logs détaillés dans createNewDevice() et updateDeviceBlockHeight() pour tracer la génération des clés
**Pages affectées :**
- Service de création de wallet avec diagnostic des clés
- Logs de débogage pour identifier le problème de génération des clés
**Motivations :**
- Corriger l'ordre des opérations : scan complet AVANT demande faucet, puis scan APRÈS réception transaction
- Éviter la course entre le scan et l'arrivée des transactions faucet
- Optimiser la logique de scan pour éviter les scans inutiles
**Modifications :**
- src/services/service.ts: Ajout de ensureCompleteInitialScan() avant getTokensFromFaucet(), flag hasReceivedTransaction pour tracker les transactions, optimisation de waitForAmount() pour scanner seulement après réception de transaction
**Pages affectées :**
- Service de gestion des tokens faucet avec ordre d'opérations optimisé
- Logique de scan conditionnelle basée sur la réception de transactions
**Motivations :**
- Étendre la plage de scan pour capturer les transactions faucet (100 blocs au lieu de 10)
- Ajouter des logs de débogage détaillés pour comprendre pourquoi le SDK ne détecte pas les tokens
**Modifications :**
- src/services/service.ts: Augmentation de la plage de scan de 10 à 100 blocs pour les nouveaux wallets, ajout de logs de débogage dans getAmount()
**Pages affectées :**
- Service de gestion des tokens faucet avec scan étendu
- Logs de débogage pour diagnostic des problèmes de détection
**Motivations :**
- Corriger l'ordre d'initialisation pour éviter l'erreur 'Current block height not set'
- Ajouter waitForBlockHeight() pour attendre que le handshake soit traité avant la synchronisation
- Corriger la détection des tokens du faucet en forçant un scan complet depuis birthday
- Corriger le birthday des nouveaux wallets pour permettre le scan des transactions faucet
- Ajouter les événements clés dans le champ de messages de l'interface web avec timestamps
**Modifications :**
- src/router.ts: Ajout de waitForBlockHeight() et messages utilisateur pour l'initialisation
- src/services/service.ts: Correction de la logique de scan, birthday antérieur pour nouveaux wallets, scan initial automatique, messages utilisateur avec timestamps
- src/pages/home/home.ts: Messages WebAuthn améliorés et processus de pairing
**Pages affectées :**
- Router d'initialisation avec synchronisation correcte
- Service de gestion des tokens faucet avec scan complet
- Interface utilisateur avec messages détaillés et timestamps
**Motivations :**
- Corriger la détection des tokens du faucet en forçant la synchronisation du wallet
- Ajouter des messages utilisateur compréhensibles pour remplacer les logs techniques
- S'assurer que le scan des blocs est effectué après création/restauration du wallet
**Modifications :**
- Ajout de la méthode updateUserStatus() pour afficher des messages clairs à l'utilisateur
- Messages utilisateur dans waitForAmount() : synchronisation, demande de tokens, confirmation
- Messages utilisateur dans parseNewTx() : transaction reçue, wallet mis à jour
- Synchronisation forcée du wallet après création/restauration dans router.ts
- Messages de statut dans updateDeviceBlockHeight() pour informer l'utilisateur
- Logs de debugging étendus pour diagnostiquer les problèmes de faucet
**Pages affectées :**
- src/services/service.ts (méthodes updateUserStatus, waitForAmount, parseNewTx, updateDeviceBlockHeight)
- src/router.ts (synchronisation après création/restauration du wallet)
**Motivations :**
- Fix WebAssembly serialization error: 'invalid type: map, expected a sequence'
- WebAssembly expects array/sequence format, not object/map format
- Ensure all WebAssembly functions use the same array format consistently
- Convert object members to array format for all WebAssembly calls
**Modifications :**
- create_new_process: Convert members object to array format
- validate_state: Convert members object to array format
- parse_cipher: Convert members object to array format
- request_data: Convert members object to array format
- All functions now consistently use Object.values().map() to create arrays
- Maintained sp_addresses structure in array format
**Pages affectées :**
- src/services/service.ts: Standardized all WebAssembly functions to use array format
