31ffe084f5cc34121678a431cefe324c598e1990
Andre wants to log out and log back in against a single server, so this takes outdc6b623and my token-resolution change with it — the latter first, because it was written against useServerClient, whichdc6b623introduced. Gone: the connections store, the server chips, the per-server client and the per-server socket url. `useClient()` is back to one origin, `/api`, and the session it already holds. The chat socket url is back to what it was: const token = localStorage.getItem('BEARER_TOKEN'); const wsUrl = `${protocol}//${window.location.host}/api/chat/ws?token=${token}`; Verified: the staged tree is byte-identical to dc6b623^ across all of src/. Two things he should know rather than discover. The old line reads localStorage and nothing else — the same single spelling I widened an hour ago and have now removed again. If his token is NOT in localStorage, this code fails exactly as before, and worse: a missing one interpolates as the literal string "null" rather than an empty value. Reverting cannot fix that class of problem; it restores it. `officer.connections.v1` stays in his browser's localStorage with alpha's API key in it. Nothing reads it now, so it is inert, but it is a credential sitting in a store nobody owns any more and should be cleared by hand. Typecheck clean. 600 pass, 2 fail — cliamp and pty, unchanged all evening and unrelated. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Description
No description provided
42 MiB
Languages
TypeScript
90.9%
Shell
4.7%
JavaScript
4.1%
CSS
0.2%
HTML
0.1%