- Shipped
- October 14, 2026 at 12:36 PM UTC
- Author
- Kamo
- Commit
- 511855b
They never had, for anybody. The trigger waited for userInfo.tokenId, which the type declares but the web app's /api/user-info never sends — so it returned before doing anything, every time. The provider test mocked a tokenId and passed. Sign-in is now read where it actually lives: the tab's session token (sessionClient). The tours start once per sign-in on the launchpad, remembering a FINGERPRINT of the session (never the bearer token itself) in localStorage, so a reload does not restart them; a new sign-in does. Sessions are per tab, so a burst of new tabs would each be a 'sign-in' — after the tours start, they do not start again by themselves for 15 minutes. Pure rule in signInTrigger.ts, tested; the provider test now mounts exactly what /api/user-info returns and a real 128-character session token.