deepdrft/product-notes/phase-17-player-queue-view.md at fe3819f378fcb087d35aacb7844277f862cecb83

Files

T

daniel-c-harvey ebbaa3f84f docs: resolve four Phase 17 open questions (OQ1/OQ4/OQ8/OQ10), defer ReleaseGallery card affordance

2026-06-19 13:42:19 -04:00

28 KiB

Raw Blame History

Status: design spec — 4 of 11 open questions resolved (Daniel, 2026-06-19); 7 still pending. Author: product-designer. Date: 2026-06-19. Plan only — no code has been written by this doc.

Resolved (Daniel, 2026-06-19): OQ1 → Option A, conditional (collapse/expand toggle if dynamic iframe resize is achievable in the embed snippet; else fall back to Option B, omit the button — feasibility call made during 17.3). OQ4 → MudDropContainer for now (pivot to a touch-viable mechanism later if mobile issues surface; C6 softened — touch-viability is a known risk, not a pre-ship blocker). OQ8 → pure append, confirmed (add ≠ play; first add into a dormant queue leaves a coherent CurrentIndex via a small additive engine affordance, landing with wave 17.1). OQ10 → deferred, confirmed (cards get no Add-to-Queue in Phase 17; the deferred card work is captured in TODO.md). The remaining seven (OQ2, OQ3, OQ5, OQ6, OQ7, OQ9, OQ11) are still pending — their §10 recommendations stand but are not confirmed.

This phase makes the play-queue visible and manipulable. Phase 11 (wave 11.F) built the queue engine (IQueueService / QueueService) and wired auto-advance, skip-prev/next, and release embeds — but the queue itself has no UI. A listener can start an album and skip through it, but cannot see what is next, reorder it, drop a track, or hand-build a queue. This phase surfaces it.

Cross-references (read before implementing):

PLAN.md §17 — the concise phase entry.
DeepDrftPublic.Client/Services/IQueueService.cs / QueueService.cs — the engine this phase drives. Its docstrings already anticipate reorder + removal as additive members (see §1).
DeepDrftPublic.Client/Controls/AudioPlayerBar/AudioPlayerBar.razor[.cs] — the bar that gains the Queue button + (Fixed) the embedded panel.
DeepDrftPublic.Client/Controls/AudioPlayerBar/PlayerControls.razor / PlayerTransportZone.razor — where transport buttons live; the Queue button sits relative to these.
DeepDrftPublic.Client/Controls/AudioPlayerProvider.razor[.cs] — cascades the queue (IsFixed). Player + queue state stays here, at layout level (project memory; do not move into pages).
DeepDrftPublic.Client/Pages/FramePlayer.razor + Layout/EmbedLayout.razor — the Fixed/embed surface; the iframe-host sizing constraint lives here (§4).
DeepDrftPublic.Client/Controls/SharePopover.razor / WaveformVisualizerControlPopover.razor — the established overlay/dismissal idioms to borrow for the non-Fixed overlay (§3).
DeepDrftPublic.Client/Pages/CutDetail.razor, Controls/ReleaseHeroOverlay.razor, Controls/ReleaseGallery.razor, Controls/StreamNowButton.razor — the play-affordance sites the "Add to Queue" button (§5) attaches beside.

0. State it inherits (verified 2026-06-19)

The queue engine is mature and complete for orchestration:

IQueueService exposes Items (IReadOnlyList<TrackDto>), CurrentIndex, Current, HasNext, HasPrevious, IsArmed, the QueueChanged event, and commands PlayRelease, Arm, Start, Enqueue, EnqueueRange, Next, Previous, Clear. There is no reorder or remove member yet — but the interface docstring explicitly reserves them as additive ("reordering mutates Items and re-emits QueueChanged"). This phase adds them.
The queue is cascaded from AudioPlayerProvider as an IsFixed cascade alongside the player.
AudioPlayerBar already subscribes to QueueChanged to re-render skip affordances, and reads HasNext/HasPrevious. Adding a Queue button + panel is the same subscription, more rendering.
Fixed (AudioPlayerBar.Fixed) is the embed flag, set true by FramePlayer via EmbedLayout. In Fixed mode the bar is in normal flow (no minimize/spacer/clip); the host iframe is sized by the embed snippet (EmbedSnippetBuilder). Today a release embed arms a shared queue; a single-track embed leaves the queue empty.
"Shared queue" today = a multi-track release loaded via PlayRelease (docked) or Arm/Start (embed). The queue is populated from one release's ordered tracks. There is no hand-assembled multi-source queue yet — Enqueue/EnqueueRange exist on the interface but no UI calls them.

The gap this phase closes: the queue is a black box. You can drive it (skip) but not inspect or edit it. Item 4 ("Add to Queue") also activates the dormant Enqueue path — the first time the queue becomes a thing a listener builds, not just a release they play.

1. Goal

Make the queue a first-class, visible, editable object in the player bar — without moving any player or queue state out of the layout-level provider, and without changing the streaming/playback seam.

Three user-visible capabilities, gated by a single new Queue toggle button in the bar:

See the queue — an ordered list of what is queued, with the current track marked.
Edit the queue (where editing is allowed) — drag-reorder and per-track removal.
Grow the queue — an "Add to Queue" affordance everywhere there is a play button.

The two view modes (overlay vs. embedded panel) differ only in presentation and edit-permission, not in the data they read — both bind the same cascaded IQueueService.Items (project memory: one source, multiple views).

2. Constraints (hard)

C1 — Player/queue state stays at layout level. The Queue view reads the cascaded IQueueService; it does not own or relocate queue state. No page-level player state. (Project memory.)
C2 — No new playback semantics. Reorder/remove mutate Items + CurrentIndex and re-emit QueueChanged; they must not restart, re-stream, or interrupt the currently-playing track (matching the engine's existing "the player stays a single-track device" posture). Reordering the currently-playing item or items around it must keep playback uninterrupted.
C3 — Embed = read-only shared queue. In Fixed (embed) mode, a shared (release) queue is fixed-order and non-editable: no drag, no remove. The panel is a display of the up-next list.
C4 — The engine is extended additively, never reshaped. New members (Move/RemoveAt) are added to IQueueService; existing members and their contracts are untouched. Consumers written against today's surface keep working (the interface's stated open/closed posture).
C5 — Reorder/remove are interop-free state mutations. Like Enqueue/Arm, they touch only the in-memory list + index + QueueChanged. They run safely during prerender. Only PlayRelease/ Start/Next/Previous touch JS.
C6 — Drag-and-drop should be touch-viable (softened — OQ4 resolved). The public site's primary listening surface includes mobile (per PLAN.md §1.7). Resolved (Daniel, 2026-06-19): ship with MudDropContainer now. Touch-viability is no longer a hard pre-ship blocker — it is a known risk with a planned pivot path: if mobile/touch issues surface in practice, pivot to a touch-viable mechanism (pointer-interop reorder, matching RadialKnob's capturePointer, or an up/down-arrow fallback) in a later pass. See OQ4 (resolved).
C7 — Embedded panel must not break the iframe host. Adding the panel in Fixed mode grows the player's intrinsic height; the embed snippet's iframe dimensions must account for it (§4, OQ6).

3. Item 1+2 — Queue button & non-Fixed (overlay) mode

3.1 The Queue button

A new icon button in the player bar, shown only when a queue is loaded (Items.Count > 0). Mirror the existing skip-affordance gating: with no queue (null) or empty queue, the button is absent, so the bar is byte-for-byte its pre-queue self for single-track play.

Placement (Daniel): to the left of the timestamps and below the other player control buttons. Today PlayerTransportZone is a vertical MudStack of (transport-button row) over (TimestampLabel). The Queue button sits between those two — a second row below the play/skip controls and above the timestamp. That literally satisfies "below the control buttons, to the left of the timestamps."
Glyph: Icons.Material.Filled.QueueMusic (or a bespoke DDIcons queue glyph if Daniel wants the hand-rolled aesthetic — OQ7). Color.Primary to match the transport row.
Active state: when the overlay/panel is open, the button reads active (filled/highlighted), matching the visualizer popover idiom.

3.2 Non-Fixed overlay panel

When the bar is not Fixed (the docked public player), clicking Queue toggles a screen-centered overlay — borrow the exact idiom Phase 15 settled on for the visualizer controls: MudOverlay (DarkBackground, Modal), panel stops click propagation, scrim-click closes, drag-safe (a position:fixed drag capture sits above the scrim so a drag that ends outside the panel does not dismiss). Not a MudPopover anchored to the bar — a centered modal is the proven pattern here and avoids anchor math against a position:fixed dock.

Shape: "mostly square" (Daniel) — a panel roughly min(90vw, 520px) square, scrollable track list inside. Chrome matches NowPlayingCard / the visualizer panel (square corners, lighter-navy, thin border) for family resemblance.
Contents: ordered list of Items. Each row: drag handle, track number/position, track name + artist, a now-playing marker on Current (index == CurrentIndex), a remove (×) button. Clicking a row's body jumps playback to that track (PlayRelease(Items, thatIndex) — reuses the existing "play from index" semantics; OQ2 confirms this is desired vs. a dedicated jump).
Reorder: drag-and-drop reordering of rows → IQueueService.Move(from, to) (new member, §6).
Remove: per-row × → IQueueService.RemoveAt(index) (new member, §6).
Header: title ("Queue" / "Up Next"), optional "Clear" action (calls existing Clear(); OQ5 — does Clear belong in the UI, and does it stop playback?).
Empty state: the button is hidden when empty, so the overlay is never opened empty by the button. But removal can empty a non-empty queue mid-session — define the terminal state (OQ3).

3.3 Borrowed precedent

The overlay shell, dismissal, and drag-safety are a direct lift of WaveformVisualizerControlPopover (Phase 15 §4). The "mostly square panel, family chrome" is the NowPlayingCard look. Reuse, don't reinvent.

4. Item 3 — Fixed (embedded) mode

When the bar is Fixed (the /FramePlayer iframe embed), the queue list is always shown below the existing player-bar controls — not a toggle overlay. It is part of the embed's standing layout.

Permissions (C3): the embedded shared (release) queue is fixed-order, non-editable — no drag handles, no remove buttons. It is a read-only up-next display: ordered track list, current track marked, future tracks listed. Tapping a future row may jump to it (OQ2 — even read-only queues could allow jump-to-track; reorder/remove are the forbidden ops, jump is arguably fine).
Container resize (C7): the Fixed bar gains vertical height for the panel. Two coupled changes:
1. The EmbedLayout / FramePlayer Fixed bar renders the panel inline below the controls.
2. EmbedSnippetBuilder.ForRelease(...) must mint an iframe tall enough to show the panel. ForTrack(...) stays at today's compact height (single-track embeds have no queue, so no panel). This makes the two embed snippets diverge in height — track-embed compact, release-embed taller. That is correct: only release embeds have a queue to show. (OQ6 — fixed taller height for all release embeds, vs. a height that scales with track count up to a cap. Recommend: a fixed sensible height with the panel internally scrollable past N rows.)

4.1 The Queue button in embed mode (Daniel asked to clarify)

Recommendation: in Fixed mode the panel is always shown, so the Queue button is not needed for toggling — but rather than hide it, repurpose it as a collapse/expand control for the panel so a listener can reclaim the iframe space. Two viable readings, pick one:

Option A (resolved — preferred) — collapse toggle. Queue button is present in Fixed mode and collapses/expands the always-default-open panel. Default = expanded. Gives the embedder's viewer control. Consistent button meaning across modes ("toggle the queue view").
Option B (fallback) — omit the button in Fixed mode entirely. Panel is always open, no toggle. Simpler, but the button's meaning then differs by mode (present+toggles-overlay when docked, absent when embedded), and a viewer can't reclaim space.

OQ1 — RESOLVED (Daniel, 2026-06-19): Option A, conditional on feasibility. Use Option A if the iframe can be dynamically resized appropriately for collapse/expand — e.g. an embed-snippet postMessage → host resize handshake so the host iframe shrinks when the panel collapses and grows when it expands. Otherwise fall back to Option B (omit the button, panel always open at fixed height). A is preferred; B is the fallback; the deciding factor is whether dynamic iframe resize is achievable in the embed snippet. This A-vs-B determination is made during 17.3 implementation — record it there. Note the interaction with OQ6 (embed panel height): a collapse/expand that does not resize the iframe (the earlier "iframe stays sized for expanded; collapsed just shows less" reading) is not Option A under this resolution — Option A requires the iframe to actually resize. A non-resizing collapse is cosmetic and does not let the viewer reclaim space, so it collapses into Option B's value.

5. Item 4 — "Add to Queue" affordance

An "Add to Queue" icon button with a tooltip beside every play button for a release or track.

Glyph + tooltip: Icons.Material.Filled.QueueMusic / PlaylistAdd with MudTooltip "Add to queue" (track) / "Add release to queue" (release). (OQ7 — Material vs. bespoke glyph.)
Behavior:
- Track context: IQueueService.Enqueue(track) — appends without disturbing current playback (existing member, no UI calls it today; this lights it up).
- Release context: IQueueService.EnqueueRange(orderedTracks) — appends the whole release's ordered track list (existing member).
First-add semantics — RESOLVED (Daniel, 2026-06-19): pure append (option (a)). Add-to-Queue is explicitly not play; keep the verbs distinct. If the queue is empty/dormant (CurrentIndex == -1), the first add appends and leaves a coherent CurrentIndex (the small additive engine affordance) so the next play/skip behaves correctly — but does not auto-play. The listener still presses play to start. (Options (b) "first add also stages/sets current without auto-playing" and (c) "first add behaves like PlayRelease/play" are declined — they blur add vs. play.) This engine tweak belongs with wave 17.1 (it is part of the Enqueue-into-empty index handling, alongside the Move/RemoveAt additions). See OQ8 (resolved).

5.1 Where the button attaches (inventory)

Every site that currently has a play affordance:

Site	Current play affordance	Add-to-Queue target
`CutDetail` header	"Play" `MudButton` (whole album)	release → `EnqueueRange`
`CutDetail` track rows	per-row `PlayStateIcon`	track → `Enqueue`
`SessionDetail` / `MixDetail`	`PlayContent` slot in `ReleaseHeroOverlay` (single track)	track → `Enqueue`
`StreamNowButton`	random-track stream trigger	edge case — OQ9 (random has no fixed track until resolved)
`ReleaseGallery` cards	none today (cards are pure links)	scope question — OQ10

ReleaseGallery cards have no play button today — they navigate to detail. Adding an Add-to-Queue button there is new affordance, out of the literal brief ("anywhere there is a play button"). OQ10 — RESOLVED (Daniel, 2026-06-19): deferred, confirmed. Cards get no Add-to-Queue affordance in Phase 17. Scope item 4 to the detail-page play sites (rows 1–3 above) where a play button genuinely exists today. The deferred work — giving cards a play + Add-to-Queue affordance (a card-redesign question) — is captured as a TODO.md entry.
StreamNowButton is a "surprise me" trigger, not a fixed track — Add-to-Queue has no concrete item until a track resolves. Recommend: exclude it from item 4. OQ9.

So the grounded scope of item 4: the CutDetail header + track rows, and the Session/Mix hero play slot. That is "every play button that targets a known release or track."

6. Engine additions (the only `IQueueService` changes)

Two new members, both interop-free state mutations that re-emit QueueChanged:

void Move(int fromIndex, int toIndex) — reorders Items; adjusts CurrentIndex so the same track stays current across the move (find current track's new position). No re-stream (C2). No-op on out-of-range or equal indices.
void RemoveAt(int index) — removes Items[index].
- Removing a track after current: just remove; CurrentIndex unchanged.
- Removing a track before current: remove + decrement CurrentIndex (current track stays the same item, new lower index). Playback uninterrupted.
- Removing the current track: define — recommend stop is not triggered (C2 says mutations don't touch playback), so the playing track keeps playing to its natural end even though it's no longer in the list, and CurrentIndex points at what is now at that slot (the next track) so the next auto-advance / skip is coherent. Edge: removing current when it's the last item → queue becomes shorter; auto-advance simply has nothing to advance to (existing behavior). OQ3/OQ11.
- Removing the last remaining track → empty queue (CurrentIndex = -1, dormant). The Queue button disappears; if the overlay is open it closes (or shows empty state then closes). OQ3.

Both are additive (C4). Unit-testable against the existing QueueServiceTests fake-player harness with no container (the engine's stated design intent).

7. Use cases

UC1 — Inspect up-next (docked). Listener playing an album opens the Queue overlay, sees the ordered remaining tracks with the current one marked, closes it. No edit.
UC2 — Reorder (docked). Listener drags track 5 above track 2; playback continues uninterrupted; the new order drives the next auto-advance.
UC3 — Remove (docked). Listener removes a track they don't want; if it was upcoming, it's gone from the up-next; if it was current, current keeps playing to natural end (per §6).
UC4 — Build a queue (docked). Listener on a Cut detail page clicks "Add to Queue" on three individual tracks across two albums, then opens the queue and plays from the top.
UC5 — Embed up-next (Fixed). A blog embeds a release; the iframe shows the player and the fixed-order track list below it; viewer sees what's coming, cannot reorder/remove; (Option A) collapses the panel to reclaim space.
UC6 — Single-track embed unchanged. A single-track embed shows no Queue button and no panel — the compact iframe is byte-for-byte today's.
UC7 — Jump to track. Listener clicks a queued row → playback jumps to that track and continues from there (if OQ2 = yes).

8. Acceptance criteria

AC1 — When Items.Count == 0, the Queue button is absent and the docked bar renders exactly as it does today (no layout shift, no empty panel).
AC2 — When Items.Count > 0 and not Fixed, the Queue button appears below the transport controls and to the left of the timestamp; clicking it opens a centered, mostly-square overlay listing the queue with the current track marked.
AC3 (docked) — Drag-reordering a row changes the queue order and is reflected in subsequent skip/auto-advance; the currently-playing track is not re-streamed or interrupted by any reorder.
AC4 (docked) — Removing an upcoming track removes it from the list and from auto-advance; removing a track before the current one keeps the same track playing; removing the current track does not stop playback (per §6 decision).
AC5 (Fixed) — In a release embed, the queue panel renders below the controls by default, shows the ordered tracks with the current marked, and exposes no drag handles or remove buttons.
AC6 (Fixed) — The release embed iframe (via EmbedSnippetBuilder.ForRelease) is tall enough to show the panel without clipping; the single-track embed (ForTrack) height is unchanged.
AC7 — An "Add to Queue" button with tooltip appears beside the Cut header Play, each Cut track row's play, and the Session/Mix hero play; clicking it appends the track/release to the queue without disturbing the currently-playing track.
AC8 — Add-to-Queue on a dormant (empty) queue leaves the queue populated with a coherent CurrentIndex such that the next play/skip behaves correctly (per OQ8 resolution).
AC9 — Move and RemoveAt are additive to IQueueService; all existing QueueServiceTests pass unchanged; no existing member's behavior changes.
AC10 — All queue-view rendering and the new engine mutations run during prerender without JS interop (no prerender exceptions); only playback transitions touch JS.

9. Test cases

Engine (QueueServiceTests, fake-player harness — no container):

T1 Move(2, 0) on a 4-item queue reorders correctly; Items reflects new order; QueueChanged fired once.
T2 Move keeps the current track current: with CurrentIndex at track X, moving other items around it leaves Current == X; moving X itself updates CurrentIndex to X's new slot.
T3 Move does not call the player's stream method (assert fake player saw no SelectTrackStreaming).
T4 RemoveAt after current: CurrentIndex unchanged, item gone.
T5 RemoveAt before current: CurrentIndex decremented, same track current.
T6 RemoveAt of current: player not stopped (per §6); CurrentIndex resolves to the new occupant or -1 if it was last.
T7 RemoveAt of last remaining item → empty + dormant (CurrentIndex == -1, Items empty, QueueChanged fired).
T8 Move/RemoveAt out-of-range / no-op cases do not throw and do not fire QueueChanged.
T9 Enqueue into a dormant queue then play behaves per OQ8 resolution.
T10 Reordering the currently-playing item to a new slot leaves auto-advance pointing at the correct next track when the current ends.

Component (if/when component test coverage is in scope — today none exists for the client, per DeepDrftPublic.Client/CLAUDE.md):

T11 Queue button absent when queue empty (render assertion).
T12 Overlay opens/closes via button + scrim; a simulated drag that ends on the scrim does not dismiss.
T13 Fixed-mode panel renders inline with no drag/remove controls.
T14 EmbedSnippetBuilder.ForRelease height differs from ForTrack (unit test on the builder).

10. Open questions for Daniel

Four resolved (Daniel, 2026-06-19): OQ1, OQ4, OQ8, OQ10. Seven still pending: OQ2, OQ3, OQ5, OQ6, OQ7, OQ9, OQ11 — their recommendations below stand but are not confirmed.

OQ1 — Queue button in embed (Fixed) mode. RESOLVED → Option A, conditional. Use Option A (collapse/expand toggle) if the iframe can be dynamically resized for collapse/expand (embed-snippet postMessage → host resize handshake); else fall back to Option B (omit the button). A preferred, B fallback; deciding factor = whether dynamic iframe resize is achievable in the embed snippet; determination made during 17.3 (see §4.1).
OQ2 — Click-to-jump. Does clicking a queued row jump playback to that track? Recommend yes in both modes (reuses PlayRelease(Items, index)); jump is not a forbidden edit, only reorder/ remove are. Confirm for the read-only embed too.
OQ3 — Terminal/empty states. When removal empties the queue mid-session: close the overlay? Show an empty state then auto-close? And when the current track is removed, what should the panel and the player show?
OQ4 — Drag-and-drop mechanism & touch. RESOLVED → MudDropContainer for now. Ship with MudBlazor's MudDropContainer. If mobile/touch issues surface in practice, pivot to a touch-viable mechanism later (pointer-based interop reorder matching RadialKnob's capturePointer, or an up/down-arrow fallback). C6 softened: touch-viability is a known risk with a planned pivot path, not a hard pre-ship blocker (see §2 C6).
OQ5 — "Clear queue" in the UI. Include a Clear action in the overlay header? Does Clear stop playback or just empty the up-next (engine's Clear does not stop the player today)?
OQ6 — Embed panel height. Fixed sensible height with internal scroll past N rows (recommend), vs. height that grows with track count up to a cap. Affects EmbedSnippetBuilder.ForRelease.
OQ7 — Glyph. Material QueueMusic/PlaylistAdd, or a bespoke hand-rolled DDIcons queue glyph to match the gas-lamp/lava-lamp family aesthetic?
OQ8 — Add-to-Queue into a dormant (empty) queue. RESOLVED → pure append. Add ≠ play; first add into a dormant queue appends and leaves a coherent CurrentIndex (small additive engine affordance) so the next play/skip behaves correctly, but does not auto-play. The engine tweak lands with wave 17.1. (first-add-stages and first-add-plays both declined — see §5.)
OQ9 — StreamNowButton. Exclude from Add-to-Queue (recommend — no fixed track until resolved)?
OQ10 — ReleaseGallery cards. RESOLVED → deferred, confirmed. Browse-grid cards get no Add-to-Queue affordance in Phase 17. Item 4 is scoped to the detail-page play sites (Cut header, Cut track rows, Session/Mix hero). The deferred card work (play + Add-to-Queue, a card-redesign question) is captured in TODO.md.
OQ11 — Removing the current track. Confirm the recommended "keep playing to natural end, don't stop" behavior (C2-consistent) vs. "removing current skips to next immediately."

11. Wave decomposition (implementation sequencing)

Three waves; 17.1 is the load-bearing prerequisite (engine + the shared queue-list view that both modes render). 17.2 and 17.3 then hang off it and are largely parallel.

17.1 — Engine additions + shared queue-list view. Add Move/RemoveAt to IQueueService/ QueueService (+ QueueServiceTests). Plus the OQ8 affordance: Enqueue into a dormant/empty queue leaves a coherent CurrentIndex (pure append, no auto-play) so the next play/skip is correct. Build a single presentational QueueList component that renders Items with the current marked and takes an Editable flag (drag/remove on when true; reorder via MudDropContainer per OQ4). This is the one source both modes consume. Cold-start. Gates 17.2 + 17.3. No bar changes yet.
17.2 — Non-Fixed overlay. Queue button in the bar (gated on Items.Count > 0, placed per §3.1), the centered overlay borrowing the visualizer-popover idiom, hosting QueueList Editable. Reorder/remove/jump wired. Depends on 17.1.
17.3 — Fixed embed panel + snippet resize + Add-to-Queue. Inline QueueList (non-editable) below the Fixed bar; the OQ1 feasibility determination is made here — implement Option A (collapse/expand button + iframe resize handshake) if dynamic iframe resize proves achievable in the embed snippet, else fall back to Option B (omit the button); EmbedSnippetBuilder.ForRelease height bump; the Add-to-Queue buttons at the detail-page play sites (§5.1 grounded scope — cards excluded per OQ10). Depends on 17.1. (Add-to-Queue could split into its own wave 17.4 if Daniel wants it shipped independently — it only needs the existing Enqueue/EnqueueRange, not 17.1's new members.)

Dependency shape: 17.1 → {17.2, 17.3}. The cold-start item is 17.1. Most open questions (OQ1–OQ11) must be resolved before 17.2/17.3 land, but 17.1 can begin immediately — the engine contract for Move/RemoveAt is settled (§6) and independent of the UI decisions.

28 KiB Raw Blame History Unescape Escape

Phase 17 — Player-Bar Queue View