android auto: the UI is four tabs and a colour, not a screen — the design, decided

An earlier pass in this repo mocked a car UI from imagination: a tab strip, a
header with search and queue icons, a bottom mini-player, a big-art playback
view with a linear progress bar. None of those exist. Google's line is flat —
"You don't draw your user interface directly on Android Auto; the framework
has two well-defined UIs that are created automatically" — and the reference
frames confirm it. The bottom bar is the SYSTEM's (home, notifications,
Assistant). Progress is a RING around play/pause. The artwork sits small at
the left behind a blur of itself. About THREE rows fit on screen, not eight.

So the artifact that was needed was never a layout. It is the short list of
slots the app actually fills, and this commit decides them:

  tabs      Recent · Albums · Artists · Saved
  style     albums grid, artists and tracks list
  actions   Shuffle · Save, 2 of the 6 allowed
  reach     amber dot on rows that need the app; Save shows a tick when down
  accent    brand teal #31C0CB

Playlists loses its tab because the phone holds exactly one, and an empty tab
is a dead quarter of the only four we get. Saved takes it because it is the
set that plays with the app shut, which is the one thing genuinely different
about this app in a car. Grid-vs-list is not density — the car fits three
either way — it is what identifies the row: a record by its sleeve, an artist
by name, a track only by text. Save is the highest-value button on the screen:
hear it, save it, it plays cold on the way home. The dot marks the RISKY row
rather than the safe one, and thins out on its own as more music is saved.

Auto allows one accent pair, set at build time, and it cannot follow the
artwork the way the app does everywhere else — so it has to be the constant,
the falcon's teal.

None of this can ship before round 48. The card is MediaSessionCompat today,
Auto needs a MediaLibraryService, and two live sessions is not a safe
intermediate. Order is unchanged: 44 → 45 → 46 → 47 → 48, soak, then 49–52
build the table above.

The mockup that settles it is research/auto-mockup (gitignored): both real
libraries — the handset's three albums and the desktop's 418 — inside the real
template, at the three DHU resolutions, with an overlay that outlines which
pixels are the car's and which are ours.

handoff/notes/android-auto-design.md

@@ -262,3 +262,37 @@ The proportions matter more than the total:
 - **Stopping at Fork 2(a)** — browse only, no cold-start playback — lands at about 9 sittings instead of 15, and makes the prober optional, which would trim another 1–2.
 
 Nothing here is blocked on anything outside the repo except the DHU install and two settings taps on the phone. The critical path is strictly sequential from R3 onward; R1, R2 and R3 can run in any order or in parallel.
+
+---
+
+## Decided — 2026-09-15
+
+The earlier document left the car UI as forks. Kyle's direction was to use the
+app's own design language and pick. These are the picks, and the mockup at
+`research/auto-mockup/` is built to them (`CHOSEN` in `auto.js`).
+
+**First, the correction that reframes all of it.** An earlier pass in this repo
+mocked a car UI from imagination — a tab strip, header icons, a bottom
+mini-player, a big-art playback view. None of that exists. Google's line is
+flat: *"You don't draw your user interface directly on Android Auto; the
+framework has two well-defined UIs that are created automatically."* The
+reference frames are saved with this note. What the app actually controls is a
+short list, and everything below is one of those slots.
+
+| slot | decision | why |
+|---|---|---|
+| **Root tabs** | Recent · Albums · Artists · **Saved** | Playlists loses its tab: the phone holds exactly one ("Imported playlist", 3 tracks), and an empty tab is a dead quarter of the only four we get. **Saved** is the set that plays with the app shut, which is the one thing genuinely different about SoulStream in a car — and the only tab that always works. |
+| **Content style** | albums **grid**, artists and tracks **list** | Not a density choice: the car fits ~3 either way. It is about what identifies the row. A record is known by its sleeve — that is the app's whole thesis — so albums get art. An artist is known by name, a track only by text, so those get lists where the type is bigger. |
+| **Playback actions** | **Shuffle · Save** (2 of the 6 allowed) | Shuffle is what a driver reaches for. Save is SoulStream's core verb and the highest-value button on the screen: hear it, save it, it plays cold on the way home. Repeat is rarely touched while driving; Follow is a library action, so it belongs on a browse row, not the transport. |
+| **Reach signal** | an amber dot on rows that **need the app**, plus the Save button showing a tick when already saved | The dot marks the *risky* row, not the safe one — a warning has to appear where the tap can fail. It also thins out on its own as more music is saved, which is the right direction. Group titles were rejected: on today's library they make one block of 3 and one of 415. |
+| **Accent** | brand teal `#31C0CB` | The app derives an accent per cover; Auto allows exactly one pair set at build time and it cannot follow the artwork, so it has to be the constant — the falcon's teal from the desktop icon. It tints the FAB and the ring around play/pause, and nothing else. |
+
+**Deliberately not decided here:** the queue's contents, search ranking and the
+error copy, all of which want the prober in front of them rather than a guess.
+
+### What blocks building it
+
+Nothing in this list can ship before **round 48 (media3)**. The current card is
+`MediaSessionCompat`; Auto needs a `MediaLibraryService`, and two live sessions
+is not a safe intermediate. Order is unchanged: 44 → 45 → 46 → 47 → 48, soak,
+then 49–52 build the table above.