**Motivations:**
• Fix syntax errors in commented code that caused parsing issues
• Ensure proper parentheses and object syntax even in comments
**Modifications:**
• Fixed getAllMembers() call syntax in commented code at line 959
• Fixed object property syntax in commented code at line 960
**Pages affected:**
• service.ts
**Motivations :**
- La page de pairing avait des problèmes d'affichage dus à des conflits de styles
- Le contenu de home.html était injecté de manière incorrecte
- La structure HTML n'était pas cohérente avec les autres pages
**Modifications :**
- Refactorisé pairing.html avec une structure complète et des styles cohérents
- Ajouté des styles spécifiques pour le contenu de pairing (cards, status indicators, etc.)
- Modifié pairing.ts pour injecter le contenu dans le bon conteneur (pairingContainer)
- Amélioré la lisibilité et l'organisation du code
**Pages affectées :**
- src/pages/pairing/pairing.html
- src/pages/pairing/pairing.ts
**Motivations :**
- create_device_from_sp_wallet() créait un nouveau device, effaçant birthday et last_scan
- restoreDevice() préserve toutes les données existantes du device
- Le faucet est temporairement désactivé car le relay n'a pas de wallet Bitcoin Core configuré
**Modifications :**
- src/services/service.ts : Remplacé create_device_from_sp_wallet() par restoreDevice()
- src/pages/home/home.ts : Désactivé temporairement le faucet avec message explicatif
- Supprimé la vérification du birthday qui n'est plus nécessaire
**Pages affectées :**
- src/services/service.ts : Correction de ensureWalletKeysAvailable() pour préserver les données du device
- src/pages/home/home.ts : Désactivation temporaire du faucet
**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 échoue avec 'Cannot read properties of undefined (reading 'readyState')'
- La connexion WebSocket n'est pas prête quand le faucet est appelé
- Il faut s'assurer que les relays sont connectés avant d'appeler le faucet
**Modifications :**
- src/pages/home/home.ts : Ajout de connectAllRelays() avant l'appel du faucet
- Cela garantit que la connexion WebSocket est prête
**Pages affectées :**
- src/pages/home/home.ts : Amélioration de la gestion du faucet avec connexion des relays
**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 :**
- Les fichiers template n'étaient pas utilisés
- Éviter le code mort dans le projet
- Garder le codebase propre
**Modifications :**
- Suppression de src/templates/page-template.html
- Suppression de src/utils/page-template.utils.ts
- Suppression du dossier src/templates/
**Pages affectées :**
- Aucune page affectée (code mort supprimé)
**Motivations :**
- block-sync.ts avait une erreur ReferenceError: Services is not defined
- Le template standardisé créait des problèmes d'affichage
- Besoin de garder l'interface existante qui fonctionnait
**Modifications :**
- src/pages/block-sync/block-sync.ts : Ajout de l'import manquant Services
- src/pages/block-sync/block-sync.html : Retour à l'interface originale qui fonctionnait
- src/pages/pairing/pairing.html : Simplification de l'interface
- src/pages/pairing/pairing.ts : Simplification de la logique d'injection
**Pages affectées :**
- src/pages/block-sync/ : Correction de l'erreur d'import et retour à l'interface originale
- src/pages/pairing/ : Simplification de l'interface pour éviter les problèmes d'affichage
**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 :**
- 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)
