- Expédié
- 14 octobre 2026 à 12:36 UTC
- Auteur
- Kamo
- S'engager
- 511855b
Ils n'ont jamais eu, pour personne. Le déclencheur a attendu userInfo.tokenId, qui le type déclare mais l'application web /api/user-info n'envoie jamais — il est donc retourné avant de faire À chaque fois. Le test de fournisseur s'est moqué d'un jeton et a passé. Se connecter est maintenant lu là où il vit réellement: la session de l'onglet jeton (sessionClient). Les visites commencent une fois par connexion sur le lanceur, en se rappelant une FINGERPRINT du session (jamais le porteur se jetonne) dans localStorage, donc un rechargement ne redémarre pas une nouvelle connexion. Les sessions sont par onglet, donc une explosion de nouveaux onglets serait «sign-in» — après le début des tournées, ils ne recommencent pas seuls pendant 15 minutes. Règle pure dans signInTrigger.ts, testé; le test fournisseur monte maintenant exactement ce que /api/user-info retourne et une vraie session 128 caractères.