Per-Cue transport: play, pause, and step a line at a time #16

New issue

Closed

opened 2026-08-10 12:43:10 +00:00 by aiko · 1 comment

aiko commented

2026-08-10 12:43:10 +00:00

Owner

Parent

What to build

The footer gains transport that acts on the Playback Session: previous Cue, play/pause, next Cue.

Steps are Cues, never seconds. ⏮ and ⏭ seek to the previous or next Cue start. Seconds are the unit a video player has because it does not know what a line is; this app does, and that makes it the only thing in the room able to express play that line again — which is the most-used action in a mining session.

Also in this slice, the frozen strip: a slim row above the footer, present only when frozen, carrying the offset and the two jump controls. They are a symmetric pair and should read as one — the phone goes to where the show is, or the show goes to where the phone is.

The footer never changes shape. Frozen adds a strip above it rather than rearranging controls. Muscle memory for a control is worth more than the space saved by moving it.

Transport always acts on the Playback Session, never on the strip, including while frozen. One rule, no exceptions to reason about mid-episode.

Layout

Transport sits right, in the thumb arc — the phone is held one-handed, always. Settings and reading size sit left, where you reach deliberately.

Icons are drawn in the same grammar as everything else. No icon library, no filled Material shapes.

Acceptance criteria

Previous and next seek to Cue starts, not fixed intervals
Next from the last Cue, and previous from the first, do something sensible rather than failing
Play/pause reflects the real state of the Playback Session, including when it is changed on the TV
Transport acts on the Playback Session whether the strip is live or frozen
The frozen strip appears only when frozen and carries the offset plus both jump controls
Footer controls hold their positions in every state
Every interactive control has a visible focus and pressed state, and a hit target of at least 44px
Which Cue previous and next resolve to, at boundaries and mid-Cue, is covered by tests

Blocked by

## Parent #1 ## What to build The footer gains transport that acts on the Playback Session: previous Cue, play/pause, next Cue. **Steps are Cues, never seconds.** `⏮` and `⏭` seek to the previous or next Cue start. Seconds are the unit a video player has because it does not know what a line is; this app does, and that makes it the only thing in the room able to express play that line again — which is the most-used action in a mining session. Also in this slice, the frozen strip: a slim row above the footer, present only when frozen, carrying the offset and the two jump controls. They are a symmetric pair and should read as one — the phone goes to where the show is, or the show goes to where the phone is. **The footer never changes shape.** Frozen adds a strip above it rather than rearranging controls. Muscle memory for a control is worth more than the space saved by moving it. Transport always acts on the Playback Session, never on the strip, including while frozen. One rule, no exceptions to reason about mid-episode. ## Layout Transport sits right, in the thumb arc — the phone is held one-handed, always. Settings and reading size sit left, where you reach deliberately. Icons are drawn in the same grammar as everything else. No icon library, no filled Material shapes. ## Acceptance criteria - [ ] Previous and next seek to Cue starts, not fixed intervals - [ ] Next from the last Cue, and previous from the first, do something sensible rather than failing - [ ] Play/pause reflects the real state of the Playback Session, including when it is changed on the TV - [ ] Transport acts on the Playback Session whether the strip is live or frozen - [ ] The frozen strip appears only when frozen and carries the offset plus both jump controls - [ ] Footer controls hold their positions in every state - [ ] Every interactive control has a visible focus and pressed state, and a hit target of at least 44px - [ ] Which Cue previous and next resolve to, at boundaries and mid-Cue, is covered by tests ## Blocked by - #14 - #15

aiko added the

ready-for-agent

label

2026-08-10 12:43:10 +00:00

aiko referenced this issue

2026-08-10 12:43:34 +00:00

Auto-pause, and letting the show follow the phone #18

aiko referenced this issue

2026-08-10 14:04:38 +00:00

Do not offer transport a client cannot accept #20

aiko referenced this issue

2026-08-10 14:23:07 +00:00

Scrubbing back a Cue at a time actually works #21

aiko referenced this issue from a commit

2026-08-10 16:20:44 +00:00

merge: per-Cue transport (#16)

aiko referenced this issue from a commit

2026-08-10 16:20:44 +00:00

fix(web): scrubbing back a Cue at a time actually works

aiko commented

2026-08-10 16:21:24 +00:00

Author

Owner

This was generated by AI during triage.

Merged to main in af73452. Suites at merge: 79 C#, 335 phone.

Transport that steps by Cue, never by seconds — seconds are the unit a video player has because it does not know what a line is. Plus the frozen strip's symmetric pair: the phone goes to the show, or the show comes to the phone.

Superseded in part by #21: REPLAY_GRACE_TICKS is gone, and repeated presses are now a run.

> *This was generated by AI during triage.* Merged to `main` in af73452. Suites at merge: 79 C#, 335 phone. Transport that steps by Cue, never by seconds — seconds are the unit a video player has because it does not know what a line is. Plus the frozen strip's symmetric pair: the phone goes to the show, or the show comes to the phone. Superseded in part by #21: `REPLAY_GRACE_TICKS` is gone, and repeated presses are now a run.

aiko closed this issue

2026-08-10 16:21:25 +00:00