ci(skill-check): scan the docs a contributor reads

The check asserts that every make target named in a doc exists, and its
scanned set was .pi/ plus CLAUDE.md.  Since #50, CONTRIBUTING.md is the
document a *human* goes to for a build command, and it names 21 targets
that nothing verified; README.md names none today and is in for the same
reason.  The script's own header sentence is the argument — a renamed
target sends a person off the same cliff it sends an agent off.

The file list is now one `docs` variable used twice, because the failure
message carried a second copy of it and a second list is a second thing
to forget.  The `[ -d .pi ]` guard went with it: gating the whole run on
.pi/ would make the human-facing half conditional on the agent-facing
one, and an empty list is the same "nothing to scan" exit without the
coupling.

The lefthook glob is that scanned set now rather than
{Makefile,.pi/**/*.md} — #220's smaller half, and it did not fire on
CLAUDE.md either, which the script had read for months.

Verified by planting a bad target rather than by reading the diff: both
matched forms in each of the four scanned surfaces, each naming the
right file; the same two plants pass on the pre-change script; unfenced
prose still does not match; and the hook fires on a staged
CONTRIBUTING.md under the new glob where the old one skipped it.  The
count is unchanged at 47 — the set is a union — so coverage is the only
thing that moved.

Closes #220

.planning/NOTES.md

@@ -5029,3 +5029,52 @@ Findings offer it for the 300ms tap delay; this app's viewport is
 the stated benefit is not there to win. What it would change is the
 gesture stack #63 tuned by measurement on the device (`pan-y` plus a
 non-passive `preventDefault`), and that is not measurable from here.
+
+## Art pop-in is measurable in a browser, if you count frames rather than milliseconds (measured 2026-08-24)
+
+#65 is an Android report ("scrolling through albums, the art pops in")
+and the desktop harness can measure it, which was not obvious: the
+first attempt waited 220 ms after each scroll jump and found **zero**
+blank covers on either build. The metric only discriminates at one and
+two animation frames after the jump, which is where a pop-in actually
+lives.
+
+Protocol, on `make dev-headless SEED=bulk` (4 988 albums), ten
+2 400px jumps of `.grid-scroll-container`, counting covers whose rect
+intersects the viewport with `naturalWidth === 0`:
+
+| build | blank at frame 1 | at frame 2 | at 50 ms |
+|---|---|---|---|
+| `main` | 254 / 258 | 214 / 258 | 0 |
+| `main`, second run | 254 / 258 | 190 / 258 | 0 |
+| prefetch | 117 / 258 | 77 / 258 | 0 |
+| prefetch, second run | 118 / 258 | 96 / 258 | 0 |
+
+Two things this protocol gets wrong if repeated carelessly. **A second
+run in the same browser session measures the HTTP cache**, not the
+build — the skill already warns about this for `make perf`, and it
+applies to any image measurement; every row above is a fresh
+`playwright-cli close` + `open`. And **the frontend is embedded**, so
+comparing builds is a `git stash` *and* a rebuild, not a stash.
+
+**The bulk library's covers are 300x300 and ~3.7 kB**, which is why
+both builds are clean by 50 ms here and why the phone's number cannot
+be inferred from this one — same caveat the skill already records
+about full-size artwork.
+
+**`rangeChanged` and `visibilityChanged` are different ranges**, and
+the difference is the whole of this fix's value.
+`@lit-labs/virtualizer` reports `_first`/`_last` (rendered, including
+the ~1000px overhang) on the former and `_firstVisible`/`_lastVisible`
+on the latter. Both grids listen to `visibilityChanged` for scroll
+persistence, which wants the visible range and is correct; a prefetch
+window measured from it lands mostly on cards that already exist.
+Anchored there, the component test could see only one row past the
+last rendered card.
+
+**`_overhang` is not configurable.** It is a `protected` field set to
+1000 in `BaseLayout` and read by every layout; there is no option on
+`grid()`/`flow()` and no property on the element. The issue's Direction
+("ask the virtualizer for a larger overscan") is therefore not
+available without patching a private, which is why the request is
+issued ahead of the element instead.

CLAUDE.md

@@ -6,6 +6,22 @@ This file provides guidance to Claude Code (claude.ai/code) when working with co
 
 YellowJacket is a cross-platform desktop music player built with Go (backend) and TypeScript/Lit (frontend), using the Wails framework to bridge them. It supports MP3, FLAC, OGG Vorbis, and WAV playback.
 
+**The three prose documents are split by reader, not by topic** (#50).
+`README.md` is the landing page and answers *a user's* questions only —
+what it does, which channel installs it on which platform, where its
+data lives — with three screenshots in `docs/images/`, captured from the
+fixture library (`make sandbox-seed NAME=default` → `make dev-headless
+SEED=default`) so they can be retaken by anyone. `CONTRIBUTING.md` holds
+what used to be the second half of that README — prerequisites, the
+system libraries, the build and codegen commands, which verification
+tier a change demands, the tracker workflow and the commit grammar. This
+file stays the deep reference both of them point at, and is the only one
+of the three that explains *why* a shape is what it is. A fact that
+belongs to a user goes in one place; the packaging channels keep their
+own documents (`packaging/*/README.md`, `docs/android-release.md`) and
+are linked rather than summarised, because a version-restart note copied
+into the README is a second copy to keep true.
+
 ## Issues
 
 **The tracker is the source of truth for what is wanted and what is
@@ -145,7 +161,7 @@ make ui-test          # Vitest component/store suite in a real browser (no app)
 make ui-visual        # Same, including toMatchScreenshot comparisons
 make ui-setup         # Install the Vitest provider's own Chromium (once)
 make bindings-check   # Fail if frontend/bindings is stale vs the Go bindings
-make skill-check      # Fail if .pi/ documents a make target that doesn't exist
+make skill-check      # Fail if a doc names a make target that doesn't exist
 make commit-check     # Fail if a commit subject is not a Conventional Commit
 make lint             # golangci-lint v2 (strict), all three build configurations
 make test             # All tests with race detector, all three build configurations
@@ -1470,6 +1486,28 @@ live**: a scrim over a menu item is that item's text surface, and the
 14px spends its weight below the last legible label, measured at 9.9:1
 on the light ramp, whose `bgElevated` is `#e9ecef`.
 
+**And the phone has two sheets, so that rule is one file both read**
+(#210). `bottom-nav`'s "More" is capped at the same 85vh and overflows
+for the same reason — measured at 424x439 with eight destinations,
+`scrollHeight` 412 against `clientHeight` 373, and eleven items at 48px
+would be 528, since #25 makes the count the user's. So the two layers
+live in `styles/sheet-scroll.css.ts` and each host says only what is
+local to it: the colour, handed over as `--yj-sheet-surface` on the same
+box, because the nav sheet paints the sidebar's `--yj-bg-surface` and
+the context sheet the menus' `--yj-bg-elevated` — a shared rule that
+hard-coded either would draw that seam across the other one.
+
+The half that is not the fade is what makes it visible: **nothing inside
+the sheet may repaint the surface**, because these are background layers
+on the scroller and an opaque child covers them. `menu-surface` already
+had it from the other side (`.context-menu-panel[data-sheet]` is
+`background-color: transparent`); `app-sidebar`'s host paints
+`--yj-bg-surface`, which in the shell is its own background and in the
+sheet is a second copy of the sheet's, so `bottom-nav` turns it off.
+Measured at 424x439 with the fade adopted and that rule missing: a flat
+52,58,64 to the bottom edge with 39px still below, which is the defect
+unchanged and every assertion about `background-attachment` passing.
+
 **The playlist submenu is a sheet too, and it had to be.** It is a
 `placement="right-start"` flyout, and making the menu full-width moved
 its anchor — measured at x −182 to 0, entirely off-screen, so "Add to
@@ -1832,6 +1870,21 @@ is not it.** A `placeholder` is an accname fallback, so an
 Explore's search box — the audit's own `a11y.26` — as clean. A sweep
 for *empty* names cannot see a *weak* one.
 
+**`title` is the same trap one rung lower, and it defeats the obvious
+spec as well as the obvious sweep.** `queue-panel`'s Clear queue and
+Add queue to playlist were named by `title` alone, so
+`getByRole('button', { name: 'Clear queue' })` matched them **before**
+the fix as well as after — a `getByRole` assertion, which is what
+catches every other nameless control in this app, would have been
+green on the broken build. `title` is the *last* fallback in the
+accname order, so content put inside the button later silently
+outranks it, and it is the one name a phone cannot show, having no
+hover. The property is therefore asserted as *the name is not the
+tooltip*: `queue-overlay.spec.ts` removes the `title` attributes and
+asks again, which is 1 and 1 with `aria-label` and was measured at 0
+and 0 without it. The `title`s stay, because on a desktop they are
+also the tooltip for an icon-only control and that is a different job.
+
 **The shell scrolls sideways and not down.** `body` is
 `overflow-x: auto; overflow-y: hidden`, and both halves are measured.
 Vertically there is nothing to fix: the middle grid row is `1fr` and
@@ -3403,6 +3456,46 @@ rather than searching it — the store replaces that array when its
 contents change and shares the unchanged members, which is the same
 signal `track-list`'s memoized caches key on.
 
+**And the right tier arriving late still reads as no art at all**, so
+the two grids ask for it before the card exists (#65).
+`utils/image-prefetch.ts` warms the images a scroll is about to reach,
+from `cover-grid`'s and `artists-view`'s virtualizers. Measured on the
+50 000-track bulk seed over ten 2 400px jumps: of 258 covers arriving
+in view, **254 were still blank one frame later and 214 two frames
+later**; with the prefetch, 117 and 77. Both builds are clean by 50 ms
+on a desktop with 3.7 kB fixture covers, which is where the reference
+device's slower engine and 27 kB covers spend their pop-in.
+
+Four things about it are load-bearing.
+
+**The overscan the obvious fix asks for does not exist.**
+`@lit-labs/virtualizer`'s `_overhang` is a hard-coded 1000px
+`protected` field on `BaseLayout` with no configuration surface, so
+raising it means monkey-patching a private. 1000px is about two
+screens on a 439px viewport, and the *image* cannot be requested until
+the card it lives in is rendered — which is what this asks for
+instead.
+
+**It hangs off `rangeChanged`, not `visibilityChanged`.** Those report
+different ranges: visibility is what is on screen, and the virtualizer
+has already rendered that 1000px past it. Anchored to the visible
+range the window is spent on cards that already exist and have already
+asked for their own art — measured as the difference between the
+prefetch reaching one row past the last card and reaching a full
+window past it.
+
+**It is not the `LRUMap` path, and saying so is the bound.** That
+ceiling holds Explore's base64 data URLs in JS; a library cover is a
+plain URL under `Cache-Control: immutable` (the filenames are content
+hashes), so what retains the bytes is the browser's own cache. What
+this module retains is the *set of URLs already asked for*, capped at
+512 and reported to `window.__yjCacheStats()` — 497 entries and 15 407
+chars after the run above.
+
+**The prefetch asks for what the card will draw.** `artists-view`'s
+tier ladder moved into `artistAvatarURL()` so the two cannot disagree;
+a second copy would be a warm cache for a tier nothing renders.
+
 **The same rule, on the selection path, was the worst stall in the
 app.** Five components turned selected file paths back into tracks with
 `filePaths.map(fp => tracks.find(…))`, so "Select all → Edit tags" at

CONTRIBUTING.md

@@ -0,0 +1,173 @@
+# Contributing to YellowJacket
+
+This is the contributor's half of the [README](README.md): how to build it, how
+to check a change, and how a change gets in. [`CLAUDE.md`](CLAUDE.md) is the
+deep reference — the architecture, and the reasons behind the shape of it —
+and is worth reading before a change of any size, because most of this
+codebase's traps are written down there and nowhere else.
+
+## Building from source
+
+YellowJacket is [Go](https://go.dev/) with a [Lit](https://lit.dev/)/TypeScript
+frontend, bridged by [Wails v3](https://wails.io/).
+
+| Tool | Version |
+|------|---------|
+| Go | 1.25+ |
+| Node.js | 22+ |
+| pnpm | 10+ |
+| Wails CLI | v3 — vendored, no install needed (`go tool wails3`) |
+
+The Wails v3 CLI resolves from the `tool` block in `go.mod`, so there is nothing
+to install globally; `make setup` fetches it with the rest of the tooling.
+
+On Linux, install the system libraries Wails needs. v3 builds against GTK4 +
+WebKitGTK 6.0 by default:
+
+```bash
+sudo apt-get install libasound2-dev libgtk-4-dev libwebkitgtk-6.0-dev   # Debian/Ubuntu
+sudo pacman -S alsa-lib gtk4 webkitgtk-6.0                              # Arch
+```
+
+A machine without `webkitgtk-6.0` can still build with `-tags gtk3` against the
+older WebKit2GTK 4.1 stack, but that is an escape hatch, not what CI or a
+release builds. macOS and Windows need no extra system packages. Run
+`go tool wails3 doctor` to check your environment.
+
+```bash
+make setup        # install tooling, frontend packages and the git hooks
+make dev          # run with hot-reload
+make build-dev    # debug build with symbols
+make build-prod   # production build (stripped and trimmed)
+make android      # the arm64 APK, into bin/
+```
+
+The `Makefile` is the front door and carries a one-line description against
+each target; `Taskfile.yml` and `build/<platform>/Taskfile.yml` are the build
+implementation behind it and are not called directly.
+
+## Generated code
+
+Two generators run from `go generate ./...`, which `make generate` wraps:
+**sqlc** turns `backend/database/sql/queries/` into Go in
+`backend/database/sql/sqlcgen/`, and **templ** turns `.templ` files into
+`*_templ.go` beside them. Never edit either output by hand — run
+`make generate` after touching a `.sql` or a `.templ` file.
+
+The TypeScript bindings in `frontend/bindings/` are generated by `wails3`
+rather than by `go generate`, so they are a separate step: `make bindings`
+regenerates them and `make bindings-check` fails if they are stale.
+`frontend/src/events.ts` is generated too, from `backend/events/events.go`.
+
+A pre-commit hook checks that all of this is fresh, so the usual way to meet it
+is a failing commit rather than a bug.
+
+## Checking a change
+
+Run the tier the change actually demands, not the cheapest one.
+
+| Change | Command |
+|---|---|
+| Go | `make lint` and `make test` — both cover all three build configurations |
+| A frontend component or store | `make ui-test` (Vitest in a real Chromium, no backend) |
+| A user-visible flow | `make e2e`, against a running `make dev-headless` |
+| CSS | `make css-check` — see the Chrome 113 note below |
+| Anything cosmetic | look at a screenshot; several bugs here were invisible to every assertion and obvious in an image |
+
+`make test` needs the fixture library, which is generated rather than
+committed — it runs `make testdata` itself (about a second).
+
+The end-to-end tier drives the real app with no display at all: `make
+dev-headless` starts it in the background on `:34115` (add `SEED=<name>` for a
+seeded library, built by `make sandbox-seed NAME=<name>`), `make dev-logs` tails
+it and `make dev-stop` stops it. **Check the port before starting one** — if
+`:34115` is already answering, someone else's app is there, and a green result
+about their build is worse than no result.
+
+Two smaller checks exist because the failure they catch is silent:
+`make bindings-check` (stale generated bindings) and `make css-check`, which is
+two passes — one fails on a `css` literal ended early by a backtick inside a
+comment, the other on a nested CSS rule that begins with a bare element
+selector. Chrome 113 is what the reference Android device renders with, and it
+drops such a rule without a word.
+
+`make vulncheck` runs govulncheck over the module.
+
+## The issue tracker is the source of truth
+
+Work is described by issues before it is described by branches, and the tracker
+is shared with people who cannot see your terminal.
+
+- **Search before starting**, closed issues included: `./scripts/issue.sh search
+  <terms>`. "That was fixed three weeks ago" is the cheapest possible answer.
+- **Claim before the first edit**, not before the commit:
+  `./scripts/issue.sh claim <n>` sets the assignee, applies `Status/In Progress`
+  and comments with the branch, so the work is visibly taken *while it is being
+  done*. It refuses if somebody else holds it — talk to them rather than working
+  around it.
+- **If no issue covers the work, open one first** (`./scripts/issue.sh new`).
+- **Findings get filed.** A bug tripped over on the way to something else is an
+  issue with a reproduction, not a wider diff and not a sentence in a chat log.
+- **#73 is the roadmap** and states the order the backlog should be worked in.
+
+`scripts/issue.sh` is the whole interface (`list`, `mine`, `search`, `show`,
+`new`, `claim`, `unclaim`, `comment`, `close`, `label`, `depends`, `labels`) and
+wants a `GITEA_TOKEN` with `write:issue`. The labels are a taxonomy rather than
+tags: `Kind/*`, `Area/*`, `Priority/*`, `Platform/*`, plus `Reviewed/*` and
+`Status/*`, of which the last two are exclusive scopes.
+
+## Commits and pull requests
+
+`main` is protected, so a branch and a PR are the only way in. Branch from
+`origin/main`, and name the branch after the issue (`fix/140-…`, `feat/25-…`).
+
+Commit subjects are [Conventional Commits](https://www.conventionalcommits.org/)
+— `type(scope): subject`, imperative, ≤72 characters — and are enforced by a
+`commit-msg` hook and by CI (`make commit-check`). This is load-bearing rather
+than decorative: semantic-release reads the **type** to decide the next version,
+so a CI-only change is `ci:` and never `fix(ci):`, which would ship a patch
+release. `make release-dry` prints what a release would cut right now.
+
+**The closing keyword goes in the commit body**, one issue per line, because
+Gitea parses commit messages that reach `main` and does not parse the PR body:
+
+```
+docs: rewrite the README as a landing page
+
+<why>
+
+Closes #50
+```
+
+A PR body carries a commit-to-issue table, the verification you actually ran
+(with results), and a `Closes` list for whoever reads it.
+
+## Style
+
+- **Go** — golangci-lint v2, strict: `err113` (static errors), `nlreturn`,
+  `wsl_v5`, `godot`, `sloglint`, `perfsprint`, and imports grouped stdlib →
+  third-party → `yellowjacket/…` by gci.
+- **TypeScript** — strict mode, no implicit `any`, no unused locals or
+  parameters.
+- Match the surrounding code. Where `CLAUDE.md` explains why something is shaped
+  the way it is, that shape is load-bearing and there is usually a test pinning
+  it.
+
+Hooks do most of the enforcing (`lefthook.yml`, installed by `make setup`):
+pre-commit runs vet, lint, the codegen checks, the frontend typecheck and the
+two CSS checks in parallel; pre-push runs the Go suite and the UI tier,
+deliberately one after the other rather than together.
+
+## Where the rest of the documentation is
+
+- [`CLAUDE.md`](CLAUDE.md) — architecture and constraints, in depth.
+- [`docs/PROFILING.md`](docs/PROFILING.md) — Go pprof and frontend profiling.
+- [`docs/android-release.md`](docs/android-release.md) — the APK, its signing
+  key, and what the release workflow checks.
+- [`docs/index-cache.md`](docs/index-cache.md) — the search-index build cache
+  and why it has a snapshot.
+- [`packaging/arch/README.md`](packaging/arch/README.md),
+  [`packaging/homebrew/README.md`](packaging/homebrew/README.md) — the two
+  package channels.
+- `.planning/` — design documents and measured history, not a queue. The queue
+  is the tracker.

Makefile

@@ -192,7 +192,7 @@ css-check: ## Fail on a css`` literal ended early by a backtick, or a nested rul
 # Every command in them is a make target on purpose, so this is
 # checkable.  It also asserts AGENTS.md is a symlink to CLAUDE.md, so the
 # two harnesses cannot drift onto two descriptions of one project.
-skill-check: ## Fail if the agent docs name a missing make target, or AGENTS.md is not a symlink
+skill-check: ## Fail if the docs name a missing make target, or AGENTS.md is not a symlink
 	@./scripts/skill-check.sh
 
 # Conventional Commits, which CLAUDE.md claimed CI enforced for a long

README.md

@@ -2,112 +2,139 @@
 
 *Music how it was meant to bee.*
 
-YellowJacket is a fast, cross-platform desktop music player for your local
-collection. It plays your files, keeps your library tidy, and helps you discover
-and organize your music — all in a clean, responsive interface. No accounts, no
-streaming, no telemetry: just your music on your machine.
+YellowJacket plays the music you already own. Point it at your folders and it
+scans them, reads the tags and the cover art, and gives you a library you can
+browse, search, queue and tidy up — on your own machine, with no account, no
+streaming service and no telemetry.
 
-Runs on **Linux**, **macOS**, and **Windows**.
+It plays **MP3**, **FLAC**, **OGG Vorbis** and **WAV**, on **Linux** and
+**Android**, and builds from source on **macOS**.
 
-## Features
+![The track list, with something playing](docs/images/library.png)
 
-### Play your music
-- Plays **MP3, FLAC, OGG Vorbis, and WAV**
-- Play, pause, seek, and volume control with a mute toggle
-- Gapless, glitch-free seeking backed by a read-ahead buffer
-- A queue you can add to, reorder, and shuffle, with play-next support
-- Shuffle and repeat (off / all / one)
-- Picks up right where you left off — remembers your track, position, and volume between sessions
-- Media-key and MPRIS support on Linux, so your desktop's playback controls just work
+## What it does
 
-### Keep your library organized
-- Point it at your music folders and it scans them automatically
-- Reads tags and embedded cover art, and de-duplicates artwork so it isn't stored twice
-- Incremental sync — only new or changed files get reprocessed, and deleted files are cleaned up
-- Browse by **album**, **artist**, or **genre**, or search across everything
-- Mark favorites and see what you've been listening to with play history
-- Edit track tags directly when something's off
+**Plays your files.** Play, pause, seek and volume with a mute toggle; a
+read-ahead buffer so seeking is instant rather than gappy; a queue you can add
+to, reorder and shuffle, with play-next; shuffle and repeat (off / all / one).
+It remembers the track, the position and the queue between sessions, and it
+answers your desktop's media keys — MPRIS on Linux, a media notification and
+lock-screen controls on Android.
 
-### Playlists
-- Create playlists, drag tracks in, and reorder them
-- **Smart playlists** that build themselves from rules (by genre, rating, play count, and more)
-- Pin a default playlist and spot duplicate tracks at a glance
+**Keeps the library tidy.** It scans the folders you give it and rescans only
+what changed, so a big library costs its full scan once. It de-duplicates
+embedded cover art rather than storing the same image a hundred times, notices
+files that have gone away, and spots duplicate tracks. Browse by album, artist
+or genre, search across everything, mark favourites, and see what you have been
+playing.
 
-### Discover and clean up (powered by MusicBrainz)
-- **Explore** — browse artists, releases, and genres from the MusicBrainz catalog, not just what's already in your library
-- **Auto-tag** — match your files against MusicBrainz to fill in correct artist, album, and track metadata, with a review step before anything is written
-- **Lyrics search** — find a track by a line you remember
+**Playlists, and playlists that write themselves.** Drag tracks in and reorder
+them, or describe what you want — genre, play count, how long since you played
+it — and let a smart playlist keep itself up to date.
+
+**Explore and auto-tag, from the MusicBrainz catalog.** Explore browses artists,
+releases and genres from the catalog rather than only from what you own, so an
+album page can tell you that you have nine of its twelve tracks. Auto-tag
+matches your files against MusicBrainz and fills in the metadata that is
+missing, with a review step before anything is written to disk. Lyrics search
+finds a track from a line you remember.
+
+Explore needs its catalog, which is a one-off ~0.6 GB download from
+**Settings → Search Index**. It asks first on a metered connection, and
+everything else in the app works without it.
 
 ## Install
 
-Download the latest build for your platform from the
+Every download comes from the
 [releases page](https://git.ljones.me/yonlu/yellowjacket/releases).
 
-| Platform | Download |
-|----------|----------|
-| Linux | `yellowjacket-linux-amd64` |
-| macOS | `yellowjacket-darwin-universal.app.zip` (Apple Silicon + Intel) |
-| Windows | `yellowjacket-windows-amd64.exe` |
+### Linux
 
-Prefer to build it yourself? See [Building from source](#building-from-source).
+Download `yellowjacket-<version>-linux-amd64.tar.gz` from the latest release and
+unpack it. It holds the binary, a `.desktop` entry and an icon.
 
-## Getting started
+On **Arch**, install it from the package registry instead and get updates with
+the rest of your system — the one-time key import and `pacman.conf` block are in
+[`packaging/arch/README.md`](packaging/arch/README.md):
+
+```bash
+sudo pacman -Sy yellowjacket
+```
+
+### Android
+
+Install the APK from the release page, or from the URL below, which always
+points at the newest build:
+
+```
+https://git.ljones.me/api/packages/yonlu/generic/yellowjacket-android/latest/yellowjacket.apk
+```
+
+That URL needs no credentials, so [Obtainium](https://obtainium.imranr.dev/) can
+poll it directly and keep the app up to date. The build is `arm64-v8a` only, and
+[`docs/android-release.md`](docs/android-release.md) says why.
+
+### macOS
+
+Homebrew builds it from source on your own Mac — there is no prebuilt `.app`,
+because a signed macOS bundle needs a macOS machine to produce it and the
+release runner is a Linux container.
+
+```bash
+brew install shadow-puppet/yellowjacket/yellowjacket
+```
+
+See [`packaging/homebrew/README.md`](packaging/homebrew/README.md).
+
+### Windows
+
+Not published. It cross-compiles cleanly, but no Windows build of this app has
+ever been *run*, and nothing here can exercise one — so shipping it would be a
+promise that cannot be kept. You can still build it yourself: see
+[`CONTRIBUTING.md`](CONTRIBUTING.md).
+
+### Coming from a 1.x install?
+
+Versions restarted at **0.0.1** when releases became automatic, which every
+package manager reads as a downgrade. It costs one reinstall, once — the details
+are with each channel: [Homebrew](packaging/homebrew/README.md#upgrading-from-1x-needs-a-reinstall-once),
+[Android](docs/android-release.md#the-1x-installs-cannot-be-upgraded-to-00x).
+
+## First run
 
 1. Launch YellowJacket.
-2. Open **Settings** and add the folder(s) where your music lives.
-3. Let the initial scan finish — you'll see progress as it works.
-4. Browse by album, artist, or genre, queue something up, and press play.
+2. Add the folder your music lives in — the first-run wizard asks, and
+   **Settings → Libraries** is where you add more later.
+3. Watch the scan finish. It reports progress, and you can browse while it runs.
+4. Queue something and press play.
 
-Your library and settings are stored locally:
+Your library and settings stay on your machine:
 
 | | Linux / macOS | Windows |
 |---|---|---|
 | Config | `~/.config/yellowjacket/` | `%LOCALAPPDATA%\yellowjacket\config` |
 | Library data | `~/.local/share/yellowjacket/` | `%LOCALAPPDATA%\yellowjacket\data` |
 
-## Building from source
+Setting `YJ_HOME` moves both, which is how you keep a second library separate.
 
-YellowJacket is built with [Go](https://go.dev/) and a
-[Lit](https://lit.dev/)/TypeScript frontend, bridged by the
-[Wails](https://wails.io/) framework.
+## More screenshots
 
-**Prerequisites**
+An album page knows what you own, and says so:
 
-| Tool | Version |
-|------|---------|
-| Go | 1.25+ |
-| Node.js | 22+ |
-| pnpm | 10+ |
-| Wails CLI | v3 — vendored, no install needed (`go tool wails3`) |
+![An album page, with two discs and the transport playing](docs/images/album.png)
 
-The Wails v3 CLI resolves from the `tool` block in `go.mod`, so there is nothing
-to install globally; `make setup` fetches it with the rest of the tooling.
+The home page suggests somewhere to start rather than opening on a wall of
+everything:
 
-On Linux, install the system libraries Wails needs. v3 builds against GTK4 +
-WebKitGTK 6.0 by default:
+![The home page's shelves](docs/images/home.png)
 
-```bash
-sudo apt-get install libasound2-dev libgtk-4-dev libwebkitgtk-6.0-dev   # Debian/Ubuntu
-sudo pacman -S alsa-lib gtk4 webkitgtk-6.0                              # Arch
-```
+## Contributing, and the rest of the documentation
 
-A machine without `webkitgtk-6.0` can still build with `-tags gtk3` against the
-older WebKit2GTK 4.1 stack, but that is an escape hatch, not what CI or a
-release builds.
-
-macOS and Windows need no extra system packages. Run `go tool wails3 doctor` to
-check your environment.
-
-**Build**
-
-```bash
-make setup        # install tooling and git hooks
-make dev          # run with hot-reload
-make build-prod   # produce a release binary
-```
-
-More detail for contributors lives in [`CLAUDE.md`](./CLAUDE.md) — the
-architecture, the conventions and the reasons behind them. What is
-being worked on is [the issue
-tracker](https://git.ljones.me/yonlu/yellowjacket/issues); #73 is the
-roadmap.
+- [`CONTRIBUTING.md`](CONTRIBUTING.md) — build it from source, run the tests,
+  and how a change gets in.
+- [`CLAUDE.md`](CLAUDE.md) — the deep reference: the architecture and the reasons
+  behind the shape of it.
+- [The issue tracker](https://git.ljones.me/yonlu/yellowjacket/issues) is what
+  is wanted and what is being worked on; **#73** is the roadmap.
+- [Releases](https://git.ljones.me/yonlu/yellowjacket/releases) double as the
+  changelog — every one is generated from the commits it contains.

backend/riff/riff.go

@@ -63,12 +63,15 @@ func Parse(r io.Reader) ([]Chunk, error) {
 			return nil, err
 		}
 
-		data := make([]byte, size)
-		if _, err := io.ReadFull(r, data); err != nil {
+		// Copied rather than allocated up front, as ID3Chunk does: the
+		// size is four bytes off the file, so a truncated one is free to
+		// declare a chunk larger than the whole of itself.
+		var data bytes.Buffer
+		if _, err := io.CopyN(&data, r, int64(size)); err != nil {
 			return nil, fmt.Errorf("read chunk data for %q: %w", id, err)
 		}
 
-		chunks = append(chunks, Chunk{ID: id, Data: data})
+		chunks = append(chunks, Chunk{ID: id, Data: data.Bytes()})
 
 		// Odd-length chunks have a padding byte.  Lenient: if the
 		// read fails (e.g. EOF), just break rather than error.

backend/riff/riff_test.go

@@ -4,6 +4,7 @@ import (
 	"bytes"
 	"encoding/binary"
 	"errors"
+	"runtime"
 	"testing"
 
 	"yellowjacket/backend/riff"
@@ -209,3 +210,45 @@ func TestParse_ReadsEveryChunkInOrder(t *testing.T) {
 		t.Errorf("odd chunk data: got %q, want %q", chunks[1].Data, "INFOodd")
 	}
 }
+
+// A chunk size is four bytes read off the file, so a truncated or
+// malformed WAV is free to declare a chunk larger than the whole of
+// itself.  Parse must grow with what arrives rather than with what was
+// claimed.
+//
+// This measures the allocation instead of the error because the error
+// is the same either way: a build sizing its buffer from the header
+// reports the truncation correctly, having asked the allocator for a
+// gigabyte on the way.  Deliberately not parallel — TotalAlloc is
+// process-wide, and a test paused beside another one is measuring it
+// too.
+func TestParse_DoesNotAllocateWhatAChunkClaims(t *testing.T) {
+	// Large enough that a header-sized buffer is unmistakable, in a
+	// container of a few dozen bytes.
+	const declared = 1 << 30
+
+	var raw bytes.Buffer
+
+	raw.WriteString("RIFF")
+	_ = binary.Write(&raw, binary.LittleEndian, uint32(declared+12))
+	raw.WriteString("WAVE")
+	raw.WriteString("data")
+	_ = binary.Write(&raw, binary.LittleEndian, uint32(declared))
+	raw.WriteString("and then the file ends")
+
+	var before, after runtime.MemStats
+
+	runtime.GC()
+	runtime.ReadMemStats(&before)
+
+	if _, err := riff.Parse(bytes.NewReader(raw.Bytes())); err == nil {
+		t.Fatal("Parse: got nil error for a chunk larger than the file holding it")
+	}
+
+	runtime.ReadMemStats(&after)
+
+	if grew := after.TotalAlloc - before.TotalAlloc; grew > 1<<20 {
+		t.Errorf("Parse allocated %d bytes reading a %d-byte file whose chunk header claimed %d",
+			grew, raw.Len(), declared)
+	}
+}

e2e/specs/queue-overlay.spec.ts

@@ -157,6 +157,62 @@ test.describe('an overlaid queue says it is over the content', () => {
   });
 });
 
+/**
+ * #170 — the other two buttons in that same row.
+ *
+ * Clear queue and Add queue to playlist predate the close button and
+ * were named by a `title` attribute and nothing else. Unlike the
+ * sliders in `control-names.spec.ts`, that is not a *missing* name:
+ * `title` is the last fallback in the accname order, so
+ * `getByRole('button', { name: 'Clear queue' })` matched them before
+ * this fix as well as after it — measured, 1 and 1. A sweep for empty
+ * names cannot see a weak one, which is `a11y.26`'s complaint and the
+ * reason this file could have grown a green test that proved nothing.
+ *
+ * So the name is asserted twice, and the second assertion is the one
+ * that fails on the broken build. Taking the tooltip away and asking
+ * again is the property in words: **the name is not the tooltip**. It
+ * is what makes the button survive content being put inside it later,
+ * and it is the only one of the two a phone has — there is no hover on
+ * the surface #55 turned into a full screen. Measured on `main` before
+ * the fix: 0 and 0.
+ *
+ * Both buttons are disabled here, because the queue starts empty and
+ * naming is not enablement. A disabled button is still in the
+ * accessibility tree, which is exactly where the complaint was.
+ */
+test.describe('the queue header says what its actions do', () => {
+  const ACTIONS = ['Clear queue', 'Add queue to playlist'];
+
+  test('names both of the older actions', async ({ app }) => {
+    await openQueue(app);
+
+    for (const name of ACTIONS) {
+      await expect(
+        app.getByRole('button', { name, exact: true }),
+      ).toHaveCount(1);
+    }
+  });
+
+  test('and the names do not come from the tooltip', async ({ app }) => {
+    await openQueue(app);
+
+    await app.locator('#queue-panel').evaluate((el) => {
+      for (const button of el.shadowRoot!.querySelectorAll(
+        '.header-action-button',
+      )) {
+        button.removeAttribute('title');
+      }
+    });
+
+    for (const name of ACTIONS) {
+      await expect(
+        app.getByRole('button', { name, exact: true }),
+      ).toHaveCount(1);
+    }
+  });
+});
+
 /**
  * The inline panel is the mode that already worked, and the one every
  * other queue spec is written against. It keeps its resize handle and

e2e/specs/queue-selection.spec.ts

@@ -103,12 +103,17 @@ async function queueSixAndOpen(app: Page): Promise<void> {
      *
      * `explore-link` routes a track name to its *album's* page, so a
      * track with no album renders a name that navigates nowhere — and
-     * the fixture library deliberately contains two (`01 Tone A`,
-     * `02 Tone B`). Which tracks arrive first is `audio_files.id`
-     * order, i.e. the order the **scan** inserted them, which depends
-     * on concurrency and directory traversal: locally the first eight
-     * all had albums and the spec passed twice over, and CI rebuilds
-     * its seed with a real scan and got a different eight.
+     * the fixture library deliberately contains two,
+     * `unsorted/no-tags-at-all.mp3` and `unsorted/title-only.mp3`.
+     * (It contained four until #104: the two WAVs under `Field
+     * Recordings/Test Tones` had been tagged on disk all along and
+     * scan in with their album now, so they are ordinary tracks and
+     * not examples of this.) Which tracks arrive first is
+     * `audio_files.id` order, i.e. the order the **scan** inserted
+     * them, which depends on concurrency and directory traversal:
+     * locally the first eight all had albums and the spec passed twice
+     * over, and CI rebuilds its seed with a real scan and got a
+     * different eight.
      *
      * Asking for what the test needs is the fix. It is not a
      * narrowing: every assertion here wants an ordinary track, and

frontend/src/components/artists-view/artists-view.ts

@@ -7,6 +7,7 @@ import {
 import '@lit-labs/virtualizer';
 import type {
     LitVirtualizer,
+    RangeChangedEvent,
     VisibilityChangedEvent,
 } from '@lit-labs/virtualizer';
 import { grid } from '@lit-labs/virtualizer/layouts/grid.js';
@@ -30,6 +31,7 @@ import type { ContextMenuHost, MenuTarget } from '@utils/context-menu-controller
 import { FavoritesController } from '@store/controllers/favorites-controller';
 import { ViewLifecycleMixin } from '@utils/view-lifecycle';
 import { RovingGridController } from '@utils/roving-grid';
+import { prefetchImageWindow } from '@utils/image-prefetch';
 
 import '@awesome.me/webawesome/dist/components/icon/icon.js';
 import '@awesome.me/webawesome/dist/components/popup/popup.js';
@@ -582,6 +584,26 @@ export class ArtistsView
      * Scroll position persistence
      * ================================================================ */
 
+    /**
+     * Warm the avatars just past the rendered range (#65).
+     *
+     * `rangeChanged` is the rendered range and `visibilityChanged` is
+     * what is on screen; the virtualizer has already drawn about
+     * 1000px past the latter, so that is the wrong anchor to measure a
+     * prefetch window from. It is deliberately outside the
+     * `restoringScroll` guard below: a restored scroll lands in the
+     * middle of the grid, which is exactly when nothing around it is
+     * cached.
+     */
+    private onRangeChanged = (e: RangeChangedEvent) => {
+        prefetchImageWindow(
+            this.cachedGridEntries,
+            e.first,
+            e.last,
+            (entry) => this.artistAvatarURL(entry.artist),
+        );
+    };
+
     /**
      * Save the first visible item index on scroll.
      */
@@ -1145,7 +1167,16 @@ export class ArtistsView
      * Helpers
      * ================================================================ */
 
-    private renderArtistAvatar(artist: library.Artist) {
+    /**
+     * The image this artist's card will draw, or `''` for the initial
+     * placeholder.
+     *
+     * Split out of `renderArtistAvatar` so the prefetch (#65) asks for
+     * exactly what the card is going to ask for — a second copy of the
+     * tier ladder would be a second thing to keep in step, and warming
+     * the wrong tier is a download that buys nothing.
+     */
+    private artistAvatarURL(artist: library.Artist): string {
         const needed = (this.imageSize ?? 176) * window.devicePixelRatio;
         let imageURL = '';
 
@@ -1172,6 +1203,12 @@ export class ArtistsView
             ) ?? '';
         }
 
+        return imageURL;
+    }
+
+    private renderArtistAvatar(artist: library.Artist) {
+        const imageURL = this.artistAvatarURL(artist);
+
         if (imageURL) {
             return html`<img
                 class="avatar-image"
@@ -1531,6 +1568,7 @@ export class ArtistsView
                     .keyFunction=${(entry: ArtistEntry) => entry.artist.ID}
                     .layout=${this.gridLayout}
                     @visibilityChanged=${this.onVisibilityChanged}
+                    @rangeChanged=${this.onRangeChanged}
                 ></lit-virtualizer>
             </div>
             ${this.renderContextMenu()}

frontend/src/components/bottom-nav/bottom-nav.ts

@@ -4,6 +4,7 @@ import '@awesome.me/webawesome/dist/components/icon/icon.js';
 import '@awesome.me/webawesome/dist/components/drawer/drawer.js';
 import type WaDrawer from '@awesome.me/webawesome/dist/components/drawer/drawer.js';
 import { designTokens } from '../../styles/tokens.css';
+import { sheetScrollFade } from '../../styles/sheet-scroll.css';
 import '../sidebar/app-sidebar.js';
 import { nameDialog } from '@utils/name-dialog';
 import { ICON_PLAYLIST } from '@utils/icon-language';
@@ -167,6 +168,15 @@ export class BottomNav extends LitElement {
             overflow: hidden;
         }
 
+        /* And this list does not fit (#210): measured at 424x439 with
+           the seed's eight destinations, the body is scrollHeight 412
+           against clientHeight 373, and eleven items at 48px would be
+           528 -- the count is the user's since #25. So the sheet says
+           where the fold is, with styles/sheet-scroll.css's two layers
+           rather than a second answer to the question #207 settled for
+           the context sheet. The colour is the local half: the sidebar
+           paints --yj-bg-surface, so the cover does too, or the fade
+           draws the menus' grey across the bottom of this one. */
         wa-drawer::part(body) {
             padding: 0;
             /* A scroll that reaches the end of this list must not
@@ -177,6 +187,23 @@ export class BottomNav extends LitElement {
                on a gesture-navigation phone -- the same allowance the
                bar itself makes above. */
             padding-bottom: env(safe-area-inset-bottom, 0);
+            --yj-sheet-surface: var(--yj-bg-surface, #212529);
+            ${sheetScrollFade}
+        }
+
+        /* And the sheet paints that surface once. The sidebar's host
+           paints the same grey -- which in the shell is the sidebar's
+           own background and here is a second, opaque copy of the
+           sheet's, drawn *over* the body's layers. So the fade was
+           painted and then covered: measured at 424x439 before this
+           rule, the last 32px read a flat 52,58,64 with 39px still
+           below. menu-surface meets the same requirement from the
+           other side, where .context-menu-panel[data-sheet] is
+           background-color: transparent; nothing changes visually
+           here, because the colour underneath is the one being
+           removed. */
+        app-sidebar {
+            background-color: transparent;
         }
 
         /* A sheet is dragged at with a thumb, so it says where its top

frontend/src/components/cover-grid/cover-grid.ts

@@ -8,6 +8,7 @@ import {
 import '@lit-labs/virtualizer';
 import type {
     LitVirtualizer,
+    RangeChangedEvent,
     VisibilityChangedEvent,
 } from '@lit-labs/virtualizer';
 import { grid } from '@lit-labs/virtualizer/layouts/grid.js';
@@ -30,6 +31,7 @@ import '@awesome.me/webawesome/dist/components/icon/icon.js';
 import '@components/playlist-picker/playlist-picker.js';
 import { loadTrackDetails } from '@utils/lazy-track-details.js';
 import { tracksByFilePath, tracksForPaths } from '@utils/track-index.js';
+import { prefetchImageWindow } from '@utils/image-prefetch.js';
 import type { TrackDetails } from '@components/track-details/track-details.js';
 import type { CoverArtUrls } from '@components/track-details/track-details.js';
 import { AlbumSelectionManager } from './album-selection.js';
@@ -910,6 +912,31 @@ export class CoverGrid
         );
     };
 
+    /**
+     * Warm the covers just past the rendered range (#65).
+     *
+     * `rangeChanged` rather than `visibilityChanged`, because the two
+     * report different ranges and only one of them is the right
+     * anchor: visibility is what is on screen, and the virtualizer has
+     * already rendered about 1000px past that. Measured from the
+     * visible range this would spend most of its window on cards that
+     * already exist and have already asked for their own art.
+     *
+     * The entry lists are memoized, so asking for one here costs a
+     * reference compare.
+     */
+    private onRangeChanged = (e: RangeChangedEvent) => {
+        const entries = this.splitMode
+            ? this.getBeforeEntries()
+            : this.buildGridEntries();
+
+        prefetchImageWindow(entries, e.first, e.last, (entry) =>
+            entry.album.CoverArtPath
+                ? this.getCoverUrl(entry.album)
+                : '',
+        );
+    };
+
     /* ====================================================================
      * Virtualizer items
      * ==================================================================== */
@@ -2003,6 +2030,7 @@ export class CoverGrid
                 @keydown=${this.onGridAlbumKeydown}
                 @contextmenu=${this.onGridAlbumContextMenu}
                 @visibilityChanged=${this.onVisibilityChanged}
+                @rangeChanged=${this.onRangeChanged}
             ></lit-virtualizer>
         `;
     }
@@ -2037,6 +2065,7 @@ export class CoverGrid
                 @keydown=${this.onGridAlbumKeydown}
                 @contextmenu=${this.onGridAlbumContextMenu}
                 @visibilityChanged=${this.onVisibilityChanged}
+                @rangeChanged=${this.onRangeChanged}
             ></lit-virtualizer>
 
             <album-dropdown

frontend/src/components/menu-surface/menu-surface.ts

@@ -65,6 +65,7 @@ import '@awesome.me/webawesome/dist/components/popup/popup.js';
 import '@awesome.me/webawesome/dist/components/dialog/dialog.js';
 import type WaPopup from '@awesome.me/webawesome/dist/components/popup/popup.js';
 
+import { sheetScrollFade } from '../../styles/sheet-scroll.css';
 import { PHONE_QUERY } from '@utils/breakpoints';
 import { nameDialogsIn } from '@utils/name-dialog';
 
@@ -164,46 +165,17 @@ export class MenuSurface extends LitElement {
            and worse when the cut lands on a row boundary, where the
            sheet ends in a clean edge that reads as the end of the list.
 
-           Two layers, and the *order* is what asks the question: a
-           shadow pinned to the bottom of the box (attachment scroll),
-           and over it a cover of the sheet's own colour painted at the
-           end of the *content* (attachment local), which therefore
-           scrolls up over the shadow and hides it exactly when there is
-           nothing more to see. So the affordance is absent on a menu
-           that fits, present the moment one does not, and gone again at
-           the end of the list -- with no scroll listener, no
-           measurement, and nothing reaching into wa-dialog's shadow
-           root for the scroller. background-attachment is Chrome 4;
-           the reference device is Chrome 113.
-
-           **The curve is steep because the rows under it stay live.**
-           A scrim over a menu item is that item's text surface, and
-           this app's rule is that text clears 4.5:1 on every surface it
-           can sit on -- which the light ramp, whose bgElevated is
-           #e9ecef, is what makes non-theoretical. A row is 48px with
-           its label centred, so 32px of scrim that is already down to
-           a quarter strength at 14px reaches y-centre at about 0.06 and
-           spends its weight on the strip below the last legible label.
-           Measured on the dark ramp at x=300, flat 52,58,64 throughout
-           before: 50,56,62 at y=330, 33,37,40 at y=350 and 22,24,27 at
-           the bottom edge, and flat again at the end of the list. The
-           light ramp puts 9.9:1 on the last label. */
+           The two layers that say it live in styles/sheet-scroll.css
+           (#210), because the phone has a second sheet -- bottom-nav's
+           "More" -- which overflows for the same reason and must not
+           arrive at its own answer for what a fold looks like. What is
+           local to this sheet is the colour the cover is painted in:
+           the menus' elevated grey, handed over as --yj-sheet-surface
+           on the same box. */
         wa-dialog::part(body) {
             padding: 0;
-            overflow-y: auto;
-            background:
-                linear-gradient(
-                        var(--yj-bg-elevated, #343a40),
-                        var(--yj-bg-elevated, #343a40)
-                    )
-                    bottom / 100% 32px no-repeat local,
-                linear-gradient(
-                        to top,
-                        rgba(0, 0, 0, 0.6) 0%,
-                        rgba(0, 0, 0, 0.25) 45%,
-                        rgba(0, 0, 0, 0) 100%
-                    )
-                    bottom / 100% 32px no-repeat scroll;
+            --yj-sheet-surface: var(--yj-bg-elevated, #343a40);
+            ${sheetScrollFade}
         }
 
         /* A sheet is dragged at with a thumb, so it says where its top

frontend/src/components/queue-panel/queue-panel.ts

@@ -2201,11 +2201,25 @@ export class QueuePanel
                             `
                             : nothing}
                     </div>
+                    <!-- **Every action here is named by aria-label**, like
+                         the close button #24 added beside them (#170). A
+                         title alone *is* a name, which is why a sweep for
+                         empty names reports these clean and why an
+                         assertion by role and name is green either way --
+                         but it is the weakest one: title is the last
+                         fallback in the accname order, so any content put
+                         inside the button later silently outranks it, and
+                         a phone has no hover to show it as a tooltip.
+
+                         The titles stay. On a desktop they are the tooltip
+                         for an icon-only control, which is a different job
+                         from naming it, and aria-label does not do it. -->
                     <div class="header-actions">
                         <button
                             class="header-action-button"
                             @click=${() => void this.handleClearQueue()}
                             ?disabled=${tracks.length === 0}
+                            aria-label="Clear queue"
                             title="Clear queue"
                         >
                             <wa-icon
@@ -2216,6 +2230,7 @@ export class QueuePanel
                             class="header-action-button add-to-playlist-button"
                             @click=${this.handleAddToPlaylist}
                             ?disabled=${tracks.length === 0}
+                            aria-label="Add queue to playlist"
                             title="Add queue to playlist"
                         >
                             <wa-icon

frontend/src/styles/sheet-scroll.css.ts

@@ -0,0 +1,68 @@
+import { css } from 'lit';
+
+/**
+ * A bottom sheet whose body scrolls says so, in one rule both sheets
+ * read.
+ *
+ * The app has two sheets — `menu-surface`'s context menu (#60) and
+ * `bottom-nav`'s "More" navigation (#71) — and both are capped at 85vh,
+ * because a surface covering the whole screen is a page rather than a
+ * sheet. So both overflow, and both used to overflow *silently*: the
+ * menu at 424x439 with eight items ending at y=470 (#207), the nav
+ * sheet at the same viewport with `scrollHeight` 412 against
+ * `clientHeight` 373 (#210). Where the cut lands on a row boundary the
+ * sheet ends in a clean edge that reads as the end of the list.
+ *
+ * The mechanism is #207's and is unchanged by being shared: two
+ * background layers on the scrolling box, whose *attachments* are the
+ * conditionality. A cover of the sheet's own colour is painted at the
+ * end of the *content* (`local`) over a shadow pinned to the box
+ * (`scroll`), so the cover scrolls up over the shadow exactly when
+ * there is nothing more to see. The fade is therefore absent on a sheet
+ * that fits, present the moment one does not, and gone again at the end
+ * of the list — with no scroll listener, no measurement and nothing
+ * reaching into another component's shadow root for the scroller.
+ * `background-attachment` is Chrome 4; the reference device is
+ * Chrome 113.
+ *
+ * Three things about it are load-bearing.
+ *
+ * **The cover takes the sheet's own colour, from a custom property.**
+ * The two sheets are different greys — the nav sheet paints
+ * `--yj-bg-surface`, because it holds the sidebar and two greys in one
+ * sheet is a seam across the middle of it, while the context sheet
+ * paints the menus' `--yj-bg-elevated`. A shared rule that hard-coded
+ * either would put that seam back on the other one, so the host sets
+ * `--yj-sheet-surface` on the same box and this reads it.
+ *
+ * **The curve is steep because the rows under it stay live.** A scrim
+ * over a menu item is that item's text surface, and this app's rule is
+ * that text clears 4.5:1 on every surface it can sit on — which the
+ * light ramp, whose `bgElevated` is `#e9ecef`, makes non-theoretical. A
+ * row is 48px with its label centred, so 32px of scrim already down to
+ * a quarter strength at 14px spends its weight on the strip below the
+ * last legible label: measured at 9.9:1 on that label on the light ramp,
+ * against 5.0:1 for a linear 48px draft at 0.8. The dark-ramp pixel
+ * table is in `.planning/NOTES.md` (2026-08-23).
+ *
+ * **The box is declared a scroller here too.** `overflow-y: auto` is
+ * part of the same statement rather than left to each host: a fade over
+ * a box that is not the scroller is a fade that never moves, and the
+ * component tier asserts the pair together for that reason.
+ */
+export const sheetScrollFade = css`
+    overflow-y: auto;
+    background:
+        linear-gradient(
+                var(--yj-sheet-surface, #343a40),
+                var(--yj-sheet-surface, #343a40)
+            )
+            bottom / 100% 32px no-repeat local,
+        linear-gradient(
+                to top,
+                rgba(0, 0, 0, 0.6) 0%,
+                rgba(0, 0, 0, 0.25) 45%,
+                rgba(0, 0, 0, 0) 100%
+            )
+            bottom / 100% 32px no-repeat scroll;
+`;

frontend/src/utils/image-prefetch.ts

@@ -0,0 +1,156 @@
+/**
+ * Warm the browser's image cache for the cards a scroll is about to
+ * reach.
+ *
+ * #65: album art pops in while scrolling. The rule this app already
+ * follows is that a row image is `loading="lazy" decoding="async"` and
+ * draws the smallest adequate tier, and both halves are in place —
+ * `cover-grid.getCoverUrl()` and `artists-view`'s avatar both pick
+ * `_sm`/`_md`/`_lg` from the card size and the device pixel ratio. What
+ * is left is *when* the fetch starts: the grids are virtualized, so the
+ * `<img>` does not exist at all until the virtualizer decides to render
+ * its card, and only then can the browser ask for anything.
+ *
+ * The issue's Direction asks for a larger overscan, and that is not
+ * available: `@lit-labs/virtualizer`'s `_overhang` is a hard-coded
+ * 1000px `protected` field on `BaseLayout` with no configuration
+ * surface, so raising it means monkey-patching a private. 1000px is
+ * about two screens on the reference device's 439px viewport, which is
+ * a fraction of a second at speed.
+ *
+ * So the request is issued ahead of the element instead. Cover art and
+ * artist images are plain URLs served by `coverart.Handler` /
+ * `explore`'s image handler under `Cache-Control: public,
+ * max-age=31536000, immutable` — the filenames are content hashes — so
+ * a prefetched image is a cache hit by the time the card is drawn, and
+ * a second pass over the same rows costs nothing at all.
+ *
+ * Three things about it are load-bearing.
+ *
+ * **This is not the `LRUMap` path the issue's Findings warn about.**
+ * That ceiling (`ARTIST_IMAGE_CACHE_LIMIT` and friends) bounds
+ * Explore's base64 data URLs, which are held in JS. A library cover is
+ * a URL, and what retains the bytes is the browser's own HTTP cache,
+ * which evicts on its own terms. What this module retains is the *set
+ * of URLs already asked for*, which is why that set has a cap and
+ * reports itself to `window.__yjCacheStats()` — the measurement the
+ * issue asks for.
+ *
+ * **A window is warmed on both sides of the rendered range.** The
+ * event carries no direction, and scrolling back up needs the same
+ * treatment; the rows behind are already in `requested` from the pass
+ * that rendered them, so the backward half issues nothing in the
+ * common case and is free.
+ *
+ * **An in-flight image is held.** `new Image().src = url` and drop it
+ * is the usual idiom and usually survives, but "usually" is an engine
+ * detail and the engine that matters here is a two-year-old WebView.
+ * The element is kept until it loads or fails, and no longer — nothing
+ * here holds a decoded bitmap on purpose.
+ */
+
+import { registerCacheProbe } from './cache-stats.js';
+import { LRUMap } from './lru-map.js';
+
+/**
+ * How many entries past each edge of the rendered range to warm.
+ *
+ * Entries rather than pixels, because that is what the event reports
+ * and what the caller has an array of. Twelve rows on the phone's
+ * two-column grid and four on a desktop's six, on top of the
+ * virtualizer's own 1000px — enough to cover a flick, and bounded so a
+ * fast scroll through 5 000 albums cannot ask for 5 000 covers.
+ */
+export const PREFETCH_AHEAD = 24;
+
+/** Ceiling on the record of what has already been asked for. */
+export const PREFETCH_MEMORY = 512;
+
+/** URLs already requested; the value is a placeholder, the key is the record. */
+const requested = new LRUMap<string, true>(PREFETCH_MEMORY);
+
+/** Images still loading, held so the request cannot be collected. */
+const inFlight = new Set<HTMLImageElement>();
+
+registerCacheProbe('imagePrefetch', () => {
+    let chars = 0;
+
+    for (const url of requested.keys()) chars += url.length;
+
+    return { entries: requested.size, chars, limit: PREFETCH_MEMORY };
+});
+
+/** Whether this URL has already been asked for. */
+export function imagePrefetched(url: string): boolean {
+    return requested.has(url);
+}
+
+/**
+ * Ask the browser for `url` unless it has already been asked for.
+ * Returns whether a request was issued.
+ */
+export function prefetchImage(url: string): boolean {
+    if (!url || requested.has(url)) return false;
+
+    requested.set(url, true);
+
+    const img = new Image();
+
+    inFlight.add(img);
+
+    const done = () => {
+        inFlight.delete(img);
+    };
+
+    img.addEventListener('load', done, { once: true });
+    img.addEventListener('error', done, { once: true });
+    img.decoding = 'async';
+    img.src = url;
+
+    return true;
+}
+
+/**
+ * Warm the images either side of a virtualizer's rendered range.
+ *
+ * `first`/`last` are the indices the `visibilityChanged` event
+ * reported; `urlOf` returns the image the card at that index will
+ * draw, or `''` where it draws a placeholder. Returns how many
+ * requests were issued, which is what a test can assert on and what
+ * makes "a second run does approximately nothing" checkable.
+ */
+export function prefetchImageWindow<T>(
+    items: readonly T[],
+    first: number,
+    last: number,
+    urlOf: (item: T) => string,
+    ahead: number = PREFETCH_AHEAD,
+): number {
+    if (items.length === 0 || first < 0 || last < first) return 0;
+
+    const from = Math.max(0, first - ahead);
+    const to = Math.min(items.length - 1, last + ahead);
+    let issued = 0;
+
+    // Forward first: it is the direction a scroll is usually going, so
+    // it is the half that has to win the race.
+    for (let i = last + 1; i <= to; i++) {
+        const item = items[i];
+
+        if (item !== undefined && prefetchImage(urlOf(item))) issued++;
+    }
+
+    for (let i = from; i < first; i++) {
+        const item = items[i];
+
+        if (item !== undefined && prefetchImage(urlOf(item))) issued++;
+    }
+
+    return issued;
+}
+
+/** Forget what has been asked for. For tests; the app never needs it. */
+export function resetImagePrefetch(): void {
+    requested.clear();
+    inFlight.clear();
+}

frontend/test/components/art-prefetch.test.ts

@@ -0,0 +1,190 @@
+/**
+ * The grids ask for the art below the fold before the card exists
+ * (#65).
+ *
+ * Reported as "scrolling through albums, the art pops in". The cards
+ * already draw the smallest adequate tier and are already
+ * `loading="lazy"`, so what was left is *when*: `<lit-virtualizer>`
+ * renders about 1000px past the viewport and the `<img>` — and
+ * therefore the request — does not exist until it does. On the
+ * reference device that is about two screens.
+ *
+ * These assert the mechanism, since no tier here can photograph a
+ * pop-in: that the rows past the rendered range are requested, that
+ * the request is for the same tier the card will draw, and that the
+ * window has an end — an unbounded prefetch of a 5 000-album library
+ * is the failure this trades against.
+ *
+ * What is *not* asserted here is that a rendered card was never
+ * prefetched. It often was, honestly: the grid lays out more than once
+ * on mount, so a row warmed by the first pass is drawn by the second,
+ * which is the whole point. The rule that a single pass skips its own
+ * rendered range is `image-prefetch.test.ts`'s, where one call can be
+ * looked at on its own.
+ */
+import { describe, expect, it, beforeEach } from 'vitest';
+import type { LitElement } from 'lit';
+
+import '@components/cover-grid/cover-grid';
+import '@components/artists-view/artists-view';
+import { emit, stub, flush, resetHarness } from '@test/support/harness';
+import { Events } from '../../src/events';
+import { fixture, shadowAll } from '@test/support/render';
+import {
+  PREFETCH_AHEAD,
+  imagePrefetched,
+  resetImagePrefetch,
+} from '@utils/image-prefetch';
+
+/** Enough albums that the virtualizer's own window is nowhere near the end. */
+const ALBUMS = Array.from({ length: 400 }, (_, i) => {
+  const n = String(i + 1).padStart(4, '0');
+
+  return {
+    ID: i + 1,
+    Name: `Album ${n}`,
+    ArtistName: 'Aurora Fields',
+    Year: 2020,
+    CoverArtPath: `/covers/${n}.jpg`,
+    CoverArtSmall: `/covers/${n}_sm.jpg`,
+    CoverArtMedium: `/covers/${n}_md.jpg`,
+    CoverArtLarge: `/covers/${n}_lg.jpg`,
+  };
+});
+
+const ARTISTS = Array.from({ length: 400 }, (_, i) => {
+  const n = String(i + 1).padStart(4, '0');
+
+  return {
+    ID: i + 1,
+    Name: `Artist ${n}`,
+    AlbumCount: 2,
+    TrackCount: 9,
+    ImageSmall: `/artists/${n}_sm.jpg`,
+    ImageMedium: `/artists/${n}_md.jpg`,
+    ImageLarge: `/artists/${n}_lg.jpg`,
+  };
+});
+
+/** Give the virtualizer a viewport; a zero-height host renders nothing. */
+function sized(el: HTMLElement): void {
+  el.style.display = 'block';
+  el.style.height = '600px';
+  el.style.width = '900px';
+}
+
+async function settle(el: LitElement): Promise<void> {
+  await flush();
+  await el.updateComplete;
+  await new Promise((r) => setTimeout(r, 200));
+}
+
+/** The `src` of every card the grid actually rendered. */
+function renderedSources(el: LitElement, selector: string): string[] {
+  return shadowAll(el, selector)
+    .map((img) => (img as HTMLImageElement).getAttribute('src') ?? '')
+    .filter(Boolean);
+}
+
+/**
+ * The last index the virtualizer has rendered, read off the cards
+ * rather than counted: the rendered range is what the prefetch window
+ * is measured from, and a count assumes it starts at 0 and has no
+ * gaps.
+ */
+function lastRenderedIndex(el: LitElement, selector: string): number {
+  const indices = shadowAll(el, selector).map((card) =>
+    Number(card.getAttribute('data-index')),
+  );
+
+  return Math.max(...indices);
+}
+
+/**
+ * The tier the cards chose, read off a rendered card rather than
+ * recomputed — the point of the assertion is that the prefetch and the
+ * card agree, so deriving both from the same ladder here would prove
+ * nothing.
+ */
+function tierSuffix(src: string): string {
+  const m = /_(sm|md|lg)\.jpg$/.exec(src);
+
+  return m ? `_${m[1]}` : '';
+}
+
+beforeEach(() => {
+  resetHarness();
+  resetImagePrefetch();
+  localStorage.clear();
+  stub('library.Library.GetAlbums', ALBUMS);
+  stub('library.Library.GetArtists', ARTISTS);
+  stub('library.Library.GetTracks', []);
+  stub('library.Library.GetGenres', []);
+  emit(Events.LibraryScanComplete);
+});
+
+describe('the albums grid warms the covers below the fold', () => {
+  it('asks for the covers past the rendered range, in the tier the card draws', async () => {
+    const el = await fixture<LitElement>('cover-grid');
+
+    sized(el);
+    await settle(el);
+
+    const rendered = renderedSources(el, 'img.cover-image');
+
+    expect(rendered.length).toBeGreaterThan(0);
+
+    const tier = tierSuffix(rendered[0]!);
+    const url = (index: number) =>
+      `/covers/${String(index + 1).padStart(4, '0')}${tier}.jpg`;
+
+    // The grid starts at the top and never scrolls here, so the whole
+    // window lies past the last card drawn.
+    const last = lastRenderedIndex(el, '.album-card');
+
+    expect(imagePrefetched(url(last + 1))).toBe(true);
+    expect(imagePrefetched(url(last + PREFETCH_AHEAD))).toBe(true);
+  });
+
+  it('stops at the end of the window rather than warming the library', async () => {
+    const el = await fixture<LitElement>('cover-grid');
+
+    sized(el);
+    await settle(el);
+
+    const rendered = renderedSources(el, 'img.cover-image');
+    const tier = tierSuffix(rendered[0]!);
+    const url = (index: number) =>
+      `/covers/${String(index + 1).padStart(4, '0')}${tier}.jpg`;
+
+    // Not "exactly `last + PREFETCH_AHEAD`": the grid lays out more
+    // than once on mount and each pass warms a window from wherever
+    // the rendered range was then, so the reachable set is a few
+    // windows wide. The property that matters is that it is a window
+    // at all rather than the library.
+    expect(imagePrefetched(url(399))).toBe(false);
+    expect(window.__yjCacheStats?.()['imagePrefetch']?.entries ?? 0)
+      .toBeLessThan(ALBUMS.length / 2);
+  });
+});
+
+describe('the artists grid warms its avatars the same way', () => {
+  it('asks for the avatars past the rendered range', async () => {
+    const el = await fixture<LitElement>('artists-view');
+
+    sized(el);
+    await settle(el);
+
+    const rendered = renderedSources(el, 'img.avatar-image');
+
+    expect(rendered.length).toBeGreaterThan(0);
+
+    const tier = tierSuffix(rendered[0]!);
+    const last = lastRenderedIndex(el, '.artist-card');
+    const url = (index: number) =>
+      `/artists/${String(index + 1).padStart(4, '0')}${tier}.jpg`;
+
+    expect(imagePrefetched(url(last + 1))).toBe(true);
+    expect(imagePrefetched(url(399))).toBe(false);
+  });
+});

frontend/test/components/bottom-nav.test.ts

@@ -243,6 +243,62 @@ describe('bottom-nav', () => {
     expect(getComputedStyle(body).overscrollBehaviorY).toBe('contain');
   });
 
+  it('says where the fold is, in the sheet\'s own colour', async () => {
+    const el = await fixture<Nav>('bottom-nav');
+    const drawer = shadow<HTMLElement & { open: boolean }>(el, 'wa-drawer');
+
+    if (!drawer) throw new Error('no drawer');
+
+    const shown = once(drawer, 'wa-after-show');
+
+    shadow<HTMLButtonElement>(el, '[data-testid="tab-more"]')?.click();
+    await shown;
+
+    const body = drawer.shadowRoot?.querySelector('[part~="body"]');
+
+    if (!body) throw new Error('no body part to scroll');
+
+    const style = getComputedStyle(body);
+
+    // #210. This list does not fit the phone — measured at 424x439,
+    // `scrollHeight` 412 against `clientHeight` 373 with the seed's
+    // eight destinations — and said nothing about it, which where the
+    // cut lands on a row boundary reads as the end of the list.
+    //
+    // The mechanism is #207's and is asserted the same way: the pair of
+    // attachments *is* the feature. A cover of the sheet's own colour
+    // painted at the end of the content (`local`) over a shadow pinned
+    // to the box (`scroll`), so the fade is absent on a sheet that
+    // fits, present the moment one does not, and gone again at the end.
+    expect(
+      style.backgroundAttachment,
+      'the cover must be local and the shadow must not',
+    ).toBe('local, scroll');
+    expect(style.backgroundPosition).toBe('50% 100%, 50% 100%');
+    expect(style.backgroundSize).toBe('100% 32px, 100% 32px');
+
+    // And the colour is the local half of a shared rule: this sheet
+    // paints the sidebar's `--yj-bg-surface` (#212529) rather than the
+    // menus' elevated grey, or the fade draws the *other* sheet's
+    // colour across the bottom of this one — which is the seam a
+    // shared fragment would otherwise reintroduce.
+    expect(style.backgroundImage).toMatch(
+      /^linear-gradient\(rgb\(33, 37, 41\), rgb\(33, 37, 41\)\)/,
+    );
+
+    // And nothing paints over it. The sidebar's host carries the same
+    // grey, which inside the sheet is a second opaque copy of the
+    // surface drawn on top of these layers -- measured at 424x439 with
+    // the rule removed, the last 32px read a flat 52,58,64 with 39px
+    // still below, so the fade was painted and covered. That is
+    // `.context-menu-panel[data-sheet]`'s transparency, one sheet over.
+    const sidebar = shadow<HTMLElement>(el, 'app-sidebar');
+
+    if (!sidebar) throw new Error('no sidebar');
+
+    expect(getComputedStyle(sidebar).backgroundColor).toBe('rgba(0, 0, 0, 0)');
+  });
+
   it('gives the sheet the whole width, which the sidebar does not take', async () => {
     const el = await fixture<Nav>('bottom-nav');
 

frontend/test/components/menu-surface.test.ts

@@ -254,6 +254,15 @@ describe('menu-surface', () => {
       // Both sit at the bottom, or the cover hides nothing.
       expect(style.backgroundPosition).toBe('50% 100%, 50% 100%');
       expect(style.backgroundSize).toBe('100% 32px, 100% 32px');
+
+      // The layers are shared with `bottom-nav`'s sheet since #210, and
+      // the colour is what each host still says for itself: this one
+      // paints the menus' `--yj-bg-elevated` (#343a40). A shared rule
+      // that hard-coded one grey would draw a seam across the other
+      // sheet, which is why the fragment reads a custom property.
+      expect(style.backgroundImage).toMatch(
+        /^linear-gradient\(rgb\(52, 58, 64\), rgb\(52, 58, 64\)\)/,
+      );
     });
 
     /**

frontend/test/support/pixel.svg

@@ -0,0 +1,2 @@
+<!-- A real, servable image for the prefetch tests: one transparent pixel. -->
+<svg xmlns="http://www.w3.org/2000/svg" width="1" height="1"></svg>

frontend/test/utils/image-prefetch.test.ts

@@ -0,0 +1,113 @@
+/**
+ * What the grids ask for ahead of the scroll (#65).
+ *
+ * The virtualizer renders about 1000px past its viewport and nothing
+ * else can be asked for, because the `<img>` does not exist until the
+ * card does — two screens on the reference device, which is a fraction
+ * of a second at speed. `prefetchImageWindow` issues the request
+ * before the element, so the assertions here are about *which* rows
+ * are asked for, that none is asked for twice, and that a request is
+ * really made rather than merely recorded.
+ */
+import { describe, expect, it, beforeEach } from 'vitest';
+
+import {
+  PREFETCH_MEMORY,
+  imagePrefetched,
+  prefetchImage,
+  prefetchImageWindow,
+  resetImagePrefetch,
+} from '@utils/image-prefetch';
+
+/** A hundred cards, each with its own cover URL. */
+const CARDS = Array.from({ length: 100 }, (_, i) => ({ url: `/covers/${i}_sm.jpg` }));
+
+const urlOf = (card: { url: string }) => card.url;
+
+beforeEach(() => {
+  resetImagePrefetch();
+});
+
+describe('warming the images a scroll is about to reach', () => {
+  it('asks for the rows just past the rendered range, and no further', () => {
+    const issued = prefetchImageWindow(CARDS, 40, 50, urlOf, 3);
+
+    // Three past each edge: 51-53 and 37-39.
+    expect(issued).toBe(6);
+    expect(imagePrefetched('/covers/51_sm.jpg')).toBe(true);
+    expect(imagePrefetched('/covers/53_sm.jpg')).toBe(true);
+    expect(imagePrefetched('/covers/54_sm.jpg')).toBe(false);
+    expect(imagePrefetched('/covers/39_sm.jpg')).toBe(true);
+    expect(imagePrefetched('/covers/37_sm.jpg')).toBe(true);
+    expect(imagePrefetched('/covers/36_sm.jpg')).toBe(false);
+  });
+
+  it('leaves the rendered rows alone — they have their own <img>', () => {
+    prefetchImageWindow(CARDS, 40, 50, urlOf, 3);
+
+    expect(imagePrefetched('/covers/45_sm.jpg')).toBe(false);
+  });
+
+  it('asks for nothing twice, so a scroll back over the same rows is free', () => {
+    prefetchImageWindow(CARDS, 40, 50, urlOf, 3);
+
+    expect(prefetchImageWindow(CARDS, 40, 50, urlOf, 3)).toBe(0);
+  });
+
+  it('clamps at both ends of the list', () => {
+    // At the top of a five-item list nothing precedes the range, and
+    // the tail runs out after two.
+    expect(prefetchImageWindow(CARDS.slice(0, 5), 0, 2, urlOf, 10)).toBe(2);
+  });
+
+  it('asks for nothing when the virtualizer reports an empty range', () => {
+    // `visibilityChanged` reports -1/-1 before anything is laid out.
+    expect(prefetchImageWindow(CARDS, -1, -1, urlOf)).toBe(0);
+  });
+
+  it('skips a card that draws a placeholder rather than an image', () => {
+    expect(prefetchImageWindow(CARDS, 40, 50, () => '', 3)).toBe(0);
+  });
+
+  it('really issues the request, rather than only recording it', async () => {
+    // A served file, so the load succeeds and the resource timing entry
+    // is unambiguous; the query string keeps it distinct per run.
+    const url = `/test/support/pixel.svg?prefetch=${Date.now()}`;
+    const href = new URL(url, location.href).href;
+
+    expect(prefetchImage(url)).toBe(true);
+
+    for (let i = 0; i < 100; i++) {
+      if (performance.getEntriesByName(href).length > 0) break;
+
+      await new Promise((r) => setTimeout(r, 20));
+    }
+
+    expect(performance.getEntriesByName(href)).toHaveLength(1);
+    expect(prefetchImage(url)).toBe(false);
+    expect(performance.getEntriesByName(href)).toHaveLength(1);
+  });
+
+  it('reports what it is holding, with its cap, to the cache stats', () => {
+    prefetchImageWindow(CARDS, 40, 50, urlOf, 3);
+
+    const stat = window.__yjCacheStats?.()['imagePrefetch'];
+
+    expect(stat).toBeTruthy();
+    expect(stat!.entries).toBe(6);
+    expect(stat!.limit).toBe(PREFETCH_MEMORY);
+    // It holds URLs, not images — the bytes are the browser's cache.
+    expect(stat!.chars).toBe(6 * '/covers/51_sm.jpg'.length);
+  });
+
+  it('keeps its record bounded, so a 50 000-album scroll cannot grow it', () => {
+    const many = Array.from(
+      { length: PREFETCH_MEMORY * 2 },
+      (_, i) => ({ url: `/covers/bulk-${i}_sm.jpg` }),
+    );
+
+    prefetchImageWindow(many, 0, 0, urlOf, many.length);
+
+    expect(window.__yjCacheStats?.()['imagePrefetch']?.entries).toBe(PREFETCH_MEMORY);
+  });
+});

lefthook.yml

@@ -38,10 +38,14 @@ pre-commit:
       glob: "*.go"
       run: ./scripts/bindings-check.sh
 
-    # .pi/ documents make targets; a stale one sends an agent off a
-    # cliff with total confidence.  Instant.
+    # The docs document make targets; a stale one sends an agent — or a
+    # contributor reading CONTRIBUTING.md — off a cliff with total
+    # confidence.  The glob is the script's own scanned set, because a
+    # hook that does not fire on a file the check reads is the drift the
+    # check exists to prevent: it was `{Makefile,.pi/**/*.md}` while the
+    # script already read CLAUDE.md.  Instant.
     skill-check:
-      glob: "{Makefile,.pi/**/*.md}"
+      glob: "{Makefile,.pi/**/*.md,AGENTS.md,CLAUDE.md,README.md,CONTRIBUTING.md}"
       run: ./scripts/skill-check.sh
 
     frontend-typecheck:

scripts/skill-check.sh

@@ -14,6 +14,11 @@
 # missing: CLAUDE.md names 27 targets and nothing verified one of them,
 # so the file the agents trust most was the file least checked.
 #
+# README.md and CONTRIBUTING.md are in it too, and the header sentence
+# above is why: a person who has *not* read the Makefile goes looking in
+# the contributor-facing doc, so a renamed target sends them off the
+# same cliff it sends an agent off.  CONTRIBUTING.md names 21 targets.
+#
 # **AGENTS.md is a symlink to CLAUDE.md.**  This repo is worked on by
 # two agent harnesses that read different files by convention — Claude
 # Code reads CLAUDE.md, others read AGENTS.md — and two harnesses
@@ -43,7 +48,19 @@ if [ -e AGENTS.md ] || [ -L AGENTS.md ]; then
 	fi
 fi
 
-[ -d .pi ] || exit 0
+# The scan is over the docs that are actually there: a checkout without
+# .pi/ still has README.md and CONTRIBUTING.md to check, and gating the
+# whole run on .pi/ would have made the human-facing half conditional on
+# the agent-facing one.  This list is used twice — once to read the
+# mentions out and once to say which file a missing target came from —
+# because a second list is a second thing to forget.
+# `ls` exits non-zero when *any* of its arguments is missing while still
+# printing the ones that are there, and under `set -e` that would sink
+# the assignment rather than scanning what exists, so swallow it.
+docs="$({ find .pi -name '*.md' 2>/dev/null
+	ls CLAUDE.md README.md CONTRIBUTING.md 2>/dev/null || true; })"
+
+[ -n "$docs" ] || exit 0
 
 # `make -pq` prints the database including every rule, without running
 # anything.  It exits non-zero when a target is out of date, and under
@@ -68,7 +85,7 @@ targets="$({ make -pqRr 2>/dev/null || true; } |
 # AGENTS.md is deliberately not in this list: it is a symlink to
 # CLAUDE.md, asserted above, so scanning it would report every failure
 # twice under two names.
-mentioned="$({ find .pi -name '*.md' 2>/dev/null; echo CLAUDE.md; } |
+mentioned="$(printf '%s\n' "$docs" |
 	xargs awk '
 		FNR == 1 { fence = 0 }
 		/^```/   { fence = !fence; next }
@@ -93,10 +110,10 @@ for t in $mentioned; do
 done
 
 if [ -n "$missing" ]; then
-	echo "skill-check: the agent docs name make targets that do not exist:" >&2
+	echo "skill-check: the docs name make targets that do not exist:" >&2
 	for t in $missing; do
 		echo "  make $t" >&2
-		grep -rln "make $t" .pi CLAUDE.md --include='*.md' | sed 's/^/      /' >&2
+		printf '%s\n' "$docs" | xargs grep -ln "make $t" | sed 's/^/      /' >&2
 	done
 	echo "Fix the docs, or restore the target." >&2
 	exit 1