Work out what the jukebox becomes
A player that keeps going while you walk off and read something else.
Press something, then leave the page and go read an article while it keeps playing, for as long as you are on the domain. The page stops being a player and becomes a picker.
This is the thinking ticket. Notes below rather than a plan.
The mechanism is positional, not clever
Everything rendered in src/app/layout.tsx survives client-side navigation —
only the page slot swaps out. So an <audio> element in a client component in
the layout keeps playing through every link click, with no handling at all. The
old ribbon worked for that reason and no other.
The cost is furniture, not code
A player bar on every page, permanently, on a site this spare. That is the decision worth arguing about. Open: a ribbon at the top or a bar at the bottom, and whether it appears at all before anything is playing.
It dies on a hard refresh
A typed URL, a reload, or a return from an external link is a fresh document and
the audio stops. sessionStorage can hold the track and the position and resume
quietly, which makes "as long as you are on the domain" true in practice — but
the honest version is "as long as you do not reload."
It has to yield to the video room
Two soundtracks at once is the failure case. Simplest rule: starting a video pauses the jukebox, and the jukebox does not resume on its own. Anything cleverer is guessing what someone wanted.