Name: WS11 addendum — the close and chevron buttons belong on the controls row
Author: danielomazarino

Prompt file imported from danielomazarino/Min-SR-radio (.github/prompts/min-radio-ws11a-corner-buttons.prompt.md). Copyright stays with the author.

WS11 addendum — move the close and chevron onto the controls row

This is an addendum to the WS11 prompt, not a replacement. Do the WS11 work first; this is an additional, self-contained change.

What the owner asked for, precisely

In the expanded (mid) player, the close ✕ and the chevron currently sit in their own row above the transport buttons. The owner wants them on the same row as the transport buttons, at the right-hand end — i.e. the same relative position they already occupy in the minimised player, where the order is thumb · meta · play · chevron · close.

Put the chevron first and the close last, so the right-hand order reads … play · chevron · close, mirroring the minimised bar.

The current structure (verified)

// app.js:2894 — expanded player, a header row of its own
const headerLine = el('div', { class: 'player-header' },
  closeBtn,
  el('div', { class: 'player-title', text: cur.title || '' }),
  el('div', { class: 'player-sub', text: cur._srProgramTitle || cur.subtitle || (live ? 'Direkt' : '') }),
  expandBtn);

// app.js:2123 — minimised bar, buttons on the right already
const mini = el('div', { class: 'player-mini' },
  miniThumb,
  el('div', { class: 'player-meta', onclick: restorePlayer }, /* … */),
  miniPlay, miniExpand, miniStop);

The transport row is built separately (app.js:2231 defines expandBtn; the controls row is assembled around it — read the surrounding code, do not assume the line numbers are the row).

The critical constraint — read before editing

.player-header is load-bearing for the WS5b alignment. The text column's position is not a padding-left literal: .player-header .player-btn-close is given the artwork's own width via --player-art (styles.css:758-762), so the gap after it equals --player-gap and the title and programme land on the artwork's right edge — the same left edge as the quality pill and the song line. The measured result is title / quality / song all at left=72, spread 0px.

If you simply delete closeBtn from the header, that alignment collapses and you will have broken WS5b. Removing the spacer does not remove the space; it removes the thing that creates the space.

So the correct approach is to replace the button with an equivalent spacer of the same width (--player-art), not to delete it. A visually identical, non-interactive element sized to the same custom property preserves the alignment by construction and removes the button. Then append the real closeBtn and expandBtn to the controls row.

Alternatively, if the header keeps the chevron, you must re-establish the spacer explicitly — do not rely on a fixed pixel width, or the layout will drift when --player-art changes.

Required outcome to verify and report:

title, player-quality and .now-playing-line all still share the same left edge (report the measured pixels, and the spread between them).
The player height does not grow — the owner is removing a row, so it should get shorter by roughly the header's height.
No horizontal overflow at 390px, and none at 340px.
The minimised player is completely unchanged — same child order, same alignment, same tap targets.

Hard boundaries

Do not touch setExpandOpen(), playerMinimized, or the minimised bar. setExpandOpen() is the sole writer of aria-expanded and has several call sites; the mini-bar has its own buttons that must keep working.
paintProgramTitle() writes to $player.querySelector('.player-sub') and paintNowPlaying() to .now-playing-line. Keep both inside $player and keep those class names — renaming or reparenting them silently breaks painting while the tests stay green. This has happened before.
Preserve each button's aria-label and its onclick exactly.
Do not reintroduce the DVR window readout or anything else on the seek row — WS11 Part A removes that.
Do not restore the WS5 attribution footer.

Tests — non-vacuous, as in WS11

The alignment property is the one that must not regress, and it is the one a careless edit breaks. Assert:

the header still contains a spacer whose width derives from --player-art;
both buttons are attached to the controls row, not the header;
aria-labels and handlers survive the move;
a mutation that deletes the spacer without replacing it turns the suite red — that is the exact regression this addendum is guarding against;
a mutation that moves a button back to the header turns the suite red.

Browser evidence, pasted as real output: the measured left edges of title, quality and song; player height before vs after; overflow at 390px and 340px; and a screenshot-sized check of both the expanded and minimised players.

Chromium cannot load SR's DVR stream, so verify on a non-DVR live channel and say so. No iPhone is available to you.

Report and deploy

Status roughly every 5 minutes, and no more often. Paste the mutation table, the alignment numbers, and the before/after height.

Commit together with WS11 if it is still in flight; otherwise commit separately. Do not push either — I verify all four deploy checks before the owner is told anything is live.

Install WS11 addendum — the close and chevron buttons belong on the controls row and it becomes one more candidate the router can pick - when it fits.

A listing is a routing target with a manifest: what it does, which domains it covers, what it costs and who publishes it. Once installed it sits beside your own models and tools, is scored like any other candidate for each request, and shows up in the trace when it wins. Ratings come from workspaces that installed it, one per account.

# WS11 addendum — move the close and chevron onto the controls row **This is an addendum to the WS11 prompt, not a replacement.** Do the WS11 work first; this is an additional, self-contained change. ## What the owner asked for, precisely In the **expanded (mid) player**, the close ✕ and the chevron currently sit in their own row **above** the transport buttons. The owner wants them **on the same row as the transport buttons, at the right-hand end** — i.e. the same relative position they already occupy in the **minimised** player, where the order is thumb · meta · play · chevron · close. Put the chevron first and the close last, so the right-hand order reads `… play · chevron · close`, mirroring the minimised bar. ## The current structure (verified) ```js // app.js:2894 — expanded player, a header row of its own const headerLine = el('div', { class: 'player-header' }, closeBtn, el('div', { class: 'player-title', text: cur.title || '' }), el('div', { class: 'player-sub', text: cur._srProgramTitle || cur.subtitle || (live ? 'Direkt' : '') }), expandBtn); ``` ```js // app.js:2123 — minimised bar, buttons on the right already const mini = el('div', { class: 'player-mini' }, miniThumb, el('div', { class: 'player-meta', onclick: restorePlayer }, /* … */), miniPlay, miniExpand, miniStop); ``` The transport row is built separately (`app.js:2231` defines `expandBtn`; the controls row is assembled around it — read the surrounding code, do not assume the line numbers are the row). ## The critical constraint — read before editing `.player-header` is **load-bearing for the WS5b alignment.** The text column's position is not a `padding-left` literal: `.player-header .player-btn-close` is given the artwork's own width via `--player-art` (styles.css:758-762), so the gap after it equals `--player-gap` and **the title and programme land on the artwork's right edge — the same left edge as the quality pill and the song line.** The measured result is `title / quality / song all at left=72, spread 0px`. **If you simply delete `closeBtn` from the header, that alignment collapses and you will have broken WS5b.** Removing the spacer does not remove the space; it removes the thing that *creates* the space. **So the correct approach is to replace the button with an equivalent spacer of the same width** (`--player-art`), not to delete it. A visually identical, non-interactive element sized to the same custom property preserves the alignment by construction and removes the button. Then append the real `closeBtn` and `expandBtn` to the controls row. Alternatively, if the header keeps the chevron, you must re-establish the spacer explicitly — do not rely on a fixed pixel width, or the layout will drift when `--player-art` changes. **Required outcome to verify and report:** - `title`, `player-quality` and `.now-playing-line` all still share the same left edge (report the measured pixels, and the spread between them). - The player height does not grow — the owner is removing a row, so it should get **shorter** by roughly the header's height. - No horizontal overflow at 390px, and none at 340px. - The minimised player is **completely unchanged** — same child order, same alignment, same tap targets. ## Hard boundaries - **Do not touch `setExpandOpen()`, `playerMinimized`, or the minimised bar.** `setExpandOpen()` is the sole writer of `aria-expanded` and has several call sites; the mini-bar has its own buttons that must keep working. - `paintProgramTitle()` writes to `$player.querySelector('.player-sub')` and `paintNowPlaying()` to `.now-playing-line`. **Keep both inside `$player` and keep those class names** — renaming or reparenting them silently breaks painting while the tests stay green. This has happened before. - Preserve each button's `aria-label` and its `onclick` exactly. - Do not reintroduce the DVR window readout or anything else on the seek row — WS11 Part A removes that. - Do not restore the WS5 attribution footer. ## Tests — non-vacuous, as in WS11 The alignment property is the one that must not regress, and it is the one a careless edit breaks. Assert: - the header still contains a spacer whose width derives from `--player-art`; - both buttons are attached to the **controls row**, not the header; - `aria-label`s and handlers survive the move; - a mutation that deletes the spacer **without** replacing it turns the suite red — that is the exact regression this addendum is guarding against; - a mutation that moves a button back to the header turns the suite red. **Browser evidence, pasted as real output:** the measured left edges of title, quality and song; player height before vs after; overflow at 390px and 340px; and a screenshot-sized check of both the expanded and minimised players. Chromium cannot load SR's DVR stream, so verify on a non-DVR live channel and say so. No iPhone is available to you. ## Report and deploy Status roughly every 5 minutes, and **no more often**. Paste the mutation table, the alignment numbers, and the before/after height. **Commit together with WS11 if it is still in flight; otherwise commit separately. Do not push either** — I verify all four deploy checks before the owner is told anything is live.

{ "prompt": "# WS11 addendum — move the close and chevron onto the controls row\n\n**This is an addendum to the WS11 prompt, not a replacement.** Do the WS11 work\nfirst; this is an additional, self-contained change.\n\n## What the owner asked for, precisely\n\nIn the **expanded (mid) player**, the close ✕ and the chevron currently sit in\ntheir own row **above** the transport buttons. The owner wants them **on the\nsame row as the transport buttons, at the right-hand end** — i.e. the same\nrelative position they already occupy in the **minimised** player, where the\norder is thumb · meta · play · chevron · close.\n\nPut the chevron first and the close last, so the right-hand order reads\n`… play · chevron · close`, mirroring the minimised bar.\n\n## The current structure (verified)\n\n```js\n// app.js:2894 — expanded player, a header row of its own\nconst headerLine = el('div', { class: 'player-header' },\n closeBtn,\n el('div', { class: 'player-title', text: cur.title || '' }),\n el('div', { class: 'player-sub', text: cur._srProgramTitle || cur.subtitle || (live ? 'Direkt' : '') }),\n expandBtn);\n```\n\n```js\n// app.js:2123 — minimised bar, buttons on the right already\nconst mini = el('div', { class: 'player-mini' },\n miniThumb,\n el('div', { class: 'player-meta', onclick: restorePlayer }, /* … */),\n miniPlay, miniExpand, miniStop);\n```\n\nThe transport row is built separately (`app.js:2231` defines `expandBtn`; the\ncontrols row is assembled around it — read the surrounding code, do not assume\nthe line numbers are the row).\n\n## The critical constraint — read before editing\n\n`.player-header` is **load-bearing for the WS5b alignment.** The text column's\nposition is not a `padding-left` literal: `.player-header .player-btn-close` is\ngiven the artwork's own width via `--player-art` (styles.css:758-762), so the\ngap after it equals `--player-gap` and **the title and programme land on the\nartwork's right edge — the same left edge as the quality pill and the song\nline.** The measured result is `title / quality / song all at left=72, spread\n0px`.\n\n**If you simply delete `closeBtn` from the header, that alignment collapses and\nyou will have broken WS5b.** Removing the spacer does not remove the space; it\nremoves the thing that *creates* the space.\n\n**So the correct approach is to replace the button with an equivalent spacer of\nthe same width** (`--player-art`), not to delete it. A visually identical,\nnon-interactive element sized to the same custom property preserves the\nalignment by construction and removes the button. Then append the real\n`closeBtn` and `expandBtn` to the controls row.\n\nAlternatively, if the header keeps the chevron, you must re-establish the\nspacer explicitly — do not rely on a fixed pixel width, or the layout will drift\nwhen `--player-art` changes.\n\n**Required outcome to verify and report:**\n\n- `title`, `player-quality` and `.now-playing-line` all still share the same\n left edge (report the measured pixels, and the spread between them).\n- The player height does not grow — the owner is removing a row, so it should\n get **shorter** by roughly the header's height.\n- No horizontal overflow at 390px, and none at 340px.\n- The minimised player is **completely unchanged** — same child order, same\n alignment, same tap targets.\n\n## Hard boundaries\n\n- **Do not touch `setExpandOpen()`, `playerMinimized`, or the minimised bar.**\n `setExpandOpen()` is the sole writer of `aria-expanded` and has several call\n sites; the mini-bar has its own buttons that must keep working.\n- `paintProgramTitle()` writes to `$player.querySelector('.player-sub')` and\n `paintNowPlaying()` to `.now-playing-line`. **Keep both inside `$player` and\n keep those class names** — renaming or reparenting them silently breaks\n painting while the tests stay green. This has happened before.\n- Preserve each button's `aria-label` and its `onclick` exactly.\n- Do not reintroduce the DVR window readout or anything else on the seek row —\n WS11 Part A removes that.\n- Do not restore the WS5 attribution footer.\n\n## Tests — non-vacuous, as in WS11\n\nThe alignment property is the one that must not regress, and it is the one a\ncareless edit breaks. Assert:\n\n- the header still contains a spacer whose width derives from `--player-art`;\n- both buttons are attached to the **controls row**, not the header;\n- `aria-label`s and handlers survive the move;\n- a mutation that deletes the spacer **without** replacing it turns the suite\n red — that is the exact regression this addendum is guarding against;\n- a mutation that moves a button back to the header turns the suite red.\n\n**Browser evidence, pasted as real output:** the measured left edges of title,\nquality and song; player height before vs after; overflow at 390px and 340px;\nand a screenshot-sized check of both the expanded and minimised players.\n\nChromium cannot load SR's DVR stream, so verify on a non-DVR live channel and\nsay so. No iPhone is available to you.\n\n## Report and deploy\n\nStatus roughly every 5 minutes, and **no more often**. Paste the mutation table,\nthe alignment numbers, and the before/after height.\n\n**Commit together with WS11 if it is still in flight; otherwise commit\nseparately. Do not push either** — I verify all four deploy checks before the\nowner is told anything is live.", "variables": [], "notes": "Small correction to WS11. In the expanded player the close and chevron sit in a header row above the controls; the owner wants them on the same row as the transport buttons, at the right, matching the minimised player.", "metadata": { "source": { "provider": "github-prompts", "repository": "https://github.com/danielomazarino/Min-SR-radio", "path": ".github/prompts/min-radio-ws11a-corner-buttons.prompt.md", "ref": "edac3b153c4a679c9473a86a0db94379844d1b52", "url": "https://github.com/danielomazarino/Min-SR-radio/blob/edac3b153c4a679c9473a86a0db94379844d1b52/.github/prompts/min-radio-ws11a-corner-buttons.prompt.md", "key": "danielomazarino/Min-SR-radio/.github/prompts/min-radio-ws11a-corner-buttons.prompt.md" } } }

WS11 addendum — the close and chevron buttons belong on the controls row

About

WS11 addendum — move the close and chevron onto the controls row

What the owner asked for, precisely

The current structure (verified)

The critical constraint — read before editing

Hard boundaries

Tests — non-vacuous, as in WS11

Report and deploy

Install WS11 addendum — the close and chevron buttons belong on the controls row and it becomes one more candidate the router can pick - when it fits.

Use it

Manifest

Reviews