Six bugs in the single transport and in how a browser registers as a device,
then the feature the fourth one was hiding.
A watching device keeps its own audio paused, so every control that read
`isPlaying` from the store drew a Play button while the desktop played — and
sent `play` when it was pressed. The transport now carries one `playing` value:
the remote state while presses are being forwarded, the local one otherwise.
Two tabs of one browser shared a stored device id, which made them one device
that ran every command twice and played two copies of the audio. A device id is
now held by whichever stream has it open: registration refuses to hand back a
busy id, and each tab keeps its own in `sessionStorage`.
A device that was only showing what another one plays still pointed an audio
element at the stream, downloading tracks it would never play. It now loads
nothing while the audio is elsewhere, and reloads the moment it comes back.
Commands were accepted for an owner with no stream to receive them on, so a
killed tab answered a press with a success it never got. Ownership outlives a
closed stream deliberately; delivery does not.
The event stream never called `reply.hijack()`, leaving Fastify waiting on a
handler that resolves with nothing.
And the Vibe: `setQueue` is an ownership handoff, so a snapshot from another
device dropped the advance handler that asks the server for the next track. A
session moved to a phone became a fixed list of the hundred tracks that
happened to be synced. Vibe control now follows the audio — the snapshot
carries the session id, the device losing the audio stops driving, and the one
gaining it resumes the durable session and takes over replanning.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
A pass over the whole app against the Ethos laws, then a focused pass on
Vibe with the operator reviewing each change.
Across the app:
- The player bar restores the last track it played, paused at zero, so a
fresh tab opens on where the listener was instead of "nothing playing".
- Track titles link to their album, matching the artist links beside them.
Playback stays on the artwork tile; a title that played was the surprise.
- The search field is bg-bg2. Tailwind cannot alpha-modify these var()
colors, so bg-surface0/70 emitted no rule at all and the input fell back
to the UA's white.
- Row hover is light falling off to the right, not a flat slab.
- The artwork placeholder can drop its note glyph, so TrackRow no longer
layers a play icon on top of one.
Vibe:
- A seeded Vibe plays its seed first. The seed sits in front of the durable
plan without being part of it, so the first advance consumes it locally
and reports no plan feedback.
- The queue drops a second recording of a song it already holds — same
title, different track id, which id-based dedup let through.
- Up next is read from the queue rather than the plan preview, since the
seed is not a plan item.
- The header carries the live profile (energy, discovery, goal) and both
verbs. Keep is gone: letting a track finish already reports `completed`,
which the director weighs the same.
- The aura is one warm diffuse blob in the page background, warm-hued only
and quieter on mobile.
- Compact artwork is 32px. It was h-8 w-8, which this remapped spacing
scale renders as 64px inside a 44px row, and that overflow was the
"stacked" look.
Verified by render at 1440x900 and 390x844, no horizontal overflow at
either. 26 frontend and 122 backend tests pass.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The isPlaying subscriber is unselected. Every store write during Vibe's
feedback/replan handshake called play() on the element that had just ended.
That replayed its final buffered milliseconds until the next source loaded.
Gate that subscriber and the seek subscriber on an actual value change, and
never resume a finished element.
Then close the gap the handshake leaves behind. The engine now drives two
<audio> elements. The next track buffers into the idle one 20s early. The
handover starts before `ended`, so the round-trip happens under the outgoing
tail. With a crossfade, that tail fades out under the new track. With crossfade
off, the new track waits in silence and starts the moment the tail ends.
Both are configurable under Settings -> Transitions and persist to
localStorage. Preload is on and crossfade is 400ms by default.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
next() did `queue.slice(idx + 1)`, so the current track was always
queue[0]. prev()'s `idx > 0` guard could therefore never pass after an
auto-advance — Previous did nothing, ever — and repeat: 'all' jumped to
queue[0], which is the track that just finished, looping the last track of
an album instead of restarting it.
Replaced with a currentIndex cursor; the queue is no longer trimmed behind
the playhead. The old slice did serve a purpose — bounding Vibe-prefetch
growth — so that is preserved as a MAX_HISTORY = 50 cap that drops the
oldest entries and re-bases the index, rather than dropped outright.
setQueue/playTrack/setCurrentTrack recompute the cursor, next()/prev() fall
back to findIndex if it drifts, and shuffle now picks by index so the
cursor stays valid.
Consumer audit: NowPlayingPanel and Vibe.tsx already derived position via
findIndex and needed no change. TrackRow.handlePlay did
`setQueue(queue.slice(index))`, which re-broke prev at the point of click
even with the store fixed; it now passes the intact queue.
This commit also includes a pre-existing uncommitted fix from the working
tree (not authored by Claude): the end-of-queue auto-resume loop, which
stops playback at the end of the queue instead of restarting. It is correct
and independent of the cursor bug, and is preserved verbatim here.
REVIEW-2026-07-30.md finding 7.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
kami