` carries `tabindex="-1"`, or the fragment moves the scroll, leaves the tab sequence exactly where it was, and looks like it worked. The subtitle beside it is a `

`, which is also what an `hgroup` is supposed to contain — and dropping the `

`'s bottom margin shortened the flex-centred title block enough to move it down into the 4em bar's clip, so `.title` zeroes both margins. A selectable grid is a listbox. The four grids that ctrl/shift-select (`artists-view`, `genres-view`, `cover-grid`, and the queue) are `role="listbox" aria-multiselectable` over `role="option"` cards, not rows of `role="button"`: `aria-selected` on a button is invalid and is dropped outright, so the state the whole ctrl/shift interaction exists to produce was invisible to anything but a sighted user. `track-list`'s column headers carry `aria-sort` (Phase 1 added `role="columnheader"` without it) and are activated by Enter/Space as well as by a click. One keyboard authority. No component owns a document keydown listener for its own shortcuts; it registers panel-scoped bindings (`autotag.`, `tracklist.` in `backend/shortcuts/config.go`) and claims a scope by setting `shortcutScope` on the mixin, which publishes `data-shortcut-scope` and claims it as the ambient scope (`services/shortcut-scope.ts`) while it is on screen. The shortcut service resolves focus → panel → global, and yields a key to a focused control that owns it (button/select/slider/checkbox, or anything inside an open dialog) so the unmodified single-key global bindings do not steal Space and the arrows. A list owns the arrows it moves on, which is the vertical ones. Granting a `row`/`option`/`grid` all six took `←`/`→` away from seeking and gave them to nobody: `track-list`'s own handler and `utils/roving-rows.ts` both take Up/Down/Home/End and ignore Left/Right, so a focused track row produced zero `Player.Seek` calls against one per press from the body. Grant them back in `keysOwnedBy` if a list ever moves horizontally. The keys are written down in one place and shown in two. `services/shortcut-meta.ts` is the label, category, scope and default for every action; `?` opens `` and Settings edits the same table. It used to be a private static in `config-page`, which listed three of the four categories by hand — so the autotag bindings were written down nowhere. The overlay is not a toggle: a dialog owns every unmodified key while it is up, so a second `?` never reaches the service; Escape closes it. And a shifted character does not report Shift (`?`, not `Shift+?`) — the character already carries it. Two cross-cutting pieces of that UI are worth knowing before touching a list or a detail view: - `utils/explore-link.ts` renders every track/album/artist name in the app. A name always navigates: to the MusicBrainz page when the entity is tagged, and to the library page for the same thing when it is not (`explore-album-details` and `explore-artist-details` both accept a local id instead of an MBID). It fires on a genuine single click only — the navigation is held for one double-click interval and dropped if a second click arrives, because the title is the widest thing in a row and double-clicking a row plays it. Rows do not need to know links exist. - `` is how a detail page admits what it is showing: catalog data (silent), a library stand-in while a fetch is in flight, library-only because the entity has no MBID, or a failed/ empty catalog answer with a retry. Both detail views track `catalogPending`/`catalogLoaded` separately from their loading flags, since "something is renderable" and "this is the catalog's answer" are different questions. Icons are bundled, and the app works offline. `src/icons/` overrides Web Awesome's `default` icon library, whose resolver fetches every `` from `ka-f.fontawesome.com` at runtime — so the app had no icons at all offline, and `setBasePath()` does not affect it (only the component autoloader reads that). Overriding the library fixes all 165 call sites without changing one of them. Three things about it are load-bearing. The set is Font Awesome Free (CC BY 4.0, vendored with its licence by `frontend/scripts/fetch-icons.mjs`) because the kit CDN serves Pro, which cannot be redistributed. The names are a committed list (`src/icons/names.txt`) rather than anything derived, because twenty call sites compute their icon name from state and no static pass can enumerate them. And a name that is not bundled is therefore reported at runtime to `window.__yjIconMisses` and drawn as a fallback — an e2e sweep asserts there are none — since a missing icon used to be impossible, the CDN having had everything. **What each icon means is a second table, and it is `utils/icon-language.ts`. Bundling answers "does this name resolve"; nothing answered "does this name mean what the one next to it means", and a wrong-but-real icon renders perfectly. So `plus` came to mean add to the queue, add to a playlist, make a new playlist and** you do not own this — the first two adjacent in the same context menu — while `list` meant the queue, the Playlists destination and adding to the queue. The rule the table is built on: an icon names the noun it acts on, not the verb. "Add to queue" and "add to playlist" are one verb on two nouns, so the noun is what has to differ — which is why adding to a playlist wears the Playlists destination's own icon, and why the queue got `bars-staggered` and stopped wearing Playlists'. `plus` keeps the one meaning it is unambiguous about, making something that is not there yet. Four things about it are load-bearing: - The request toggle is one glyph in two weights (`regular/bookmark` → `solid/bookmark`), because two states of a toggle have to read as each other's opposite and a plus against a bookmark does not. The pair was already in the app and already right on `explore-album-details`'s "Request this" button while the badge forty pixels away showed a plus — `utils/library-status.ts`'s fault one layer down, having made the two agree on what wanting means and left them disagreeing on what it looks like. - Downloads keeps the solid bookmark, deliberately. That is the same word twice, not two words: the badge says "this is on your list" and the nav item is that list. - `icon-language.test.ts` sweeps the source, because the rule is about every call site and checking one checks nothing — the same shape as `TestNoDirectRuntimeEmits`. It reads every `src/**/*.ts` as raw text and fails on a literal `name="plus"` or `icon: 'list'` outside the table, and its first assertion is that it read anything at all, since a sweep over an empty glob passes. - **It also asserts every `ICON_*` is bundled, which closes the loop the runtime cannot: `bookmark-check` is Font Awesome Pro and sat on `explore-artist-details`'s Follow button, drawn for every followed artist as a circled question mark. `offline-icons.spec.ts` sweeps `__yjIconMisses` and could not see it, because no spec had ever followed an artist — the same fault `requested-badge.spec.ts` was written for, one component over, still live. A name computed from state was only checkable from the state; now it is checkable from the table. An album page says how much of the album is yours.** `explore-album-details` is a catalog page and there is no library-side album detail page at all, so the album on it may be wholly the user's, partly theirs, or not theirs — and its primary action has to mean the same thing in each case. It says which: Play when the whole release is owned, Play 7 of 12 when some of it is, and no play button at all when none is, because a Play button that plays nothing (or seven tracks of forty) is worse than none. The page asks one question, once, and it is "is there a file". Ownership used to be several claims of decreasing confidence OR'd together — a local album id, the backend's cross-reference, a cached MBID match, and finally any single track flagged `inLibrary` — none of which is "there is a file to play", which is why the tick could be green on an album whose every action did nothing, and why the tracklist's context menu asked the backend on hover whether the row it was drawing was owned. `filePaths` is the one answer: a map from a displayed track to its path, filled once from `updated()` by a single batched `GetFilePathsByRecordingMBIDs`, and read by the badge, the Play button's count, the dimmed rows and every menu item. `askedFor` is a separate set from `filePaths` because the guard has to be asked, not answered — an unowned MBID never lands in the map, so guarding on the map re-requests it on every render, forever. The other half is that the displayed tracklist is also one thing. `buildVersionEntries` synthesises the "Your Library" entry from `localTracks`, so an album the catalog cannot answer for is exactly the case that needs the version list rebuilt — `loadLocalTracks` guarded that rebuild on `releases.length > 0` and so rendered "No release data available" over a tracklist it was holding in memory. And the key it plays by is not the key it looks owned by. The local album id is used wherever there is one, because a library-only album has no recording MBIDs — its tracks are synthesised from `GetAlbumTracks` with `mbid: RecordingMBID || ''` — so an MBID-keyed lookup on an untagged library resolves to nothing and Play queues nothing while looking entirely correct. Those synthesised tracks carry their `FilePath` from the same rows, so they populate `filePaths` directly and cost no lookup at all; the batched `GetFilePathsByRecordingMBIDs` is what answers for a catalog tracklist. It is the third member of the `GetFilePathsBy…` family: one query, paths only, grouped so the caller keeps the tracklist's order. It exists rather than a lookup by track id because `MBTrack.LocalID` is declared and nothing in the backend ever writes it. How much of an album is here is a question the files can answer. `ownership()` above counts the displayed tracklist, which for a library copy is a tautology — every local track has a file, so owned always equals total and "do I have all of this" had no local answer. The album page therefore asked MusicBrainz, and `BrowseReleases` is the most expensive call the app makes: releases plus every version's full tracklist, on a 1 req/s limiter shared with `PrefetchReleases`, which fires up to eight when an artist page renders. The denominator was already on disk. `metadata` has read the "5/12" totals off every file since forever (`m.Track()`, `m.Disc()`) and discarded them; they persist to `audio_files.total_tracks` now, and `GetAlbumCompleteness` sums them. A complete, MBID-matched album makes no catalog call at all — identity from the MBID, tracklist from the tags, which between them are what the browse was being spent on. Three things about it are load-bearing. Totals are declared per disc, so the expectation is a sum over discs and not one number, and a disc whose files declared nothing leaves the whole album unknowable rather than being covered by the discs that did. Unknown is a third state and must render as neither — a great deal of any untagged library has no total, and a ring drawn from its absence would mark most of a library incomplete on no evidence; `Known` is what guards that, and the badge falls back to the plain tick. And complete is `>=`, not `==`, because bonus and hidden tracks routinely put a folder over its declared total and that is a complete album, not a broken one. Owned counts distinct track numbers for the same reason in reverse: this app detects duplicates, and counting two files of track 3 twice would report a short album as complete. Where the tags have no total, the catalog does. `explore_index` carries a per-release-group `total_tracks` — ~2 bytes across 400,677 rows, about 800 kB of artifact — and `completenessAnswer()` merges the two: the numerator stays local (distinct track numbers on disk) and only the denominator is borrowed, because a catalog total describes the canonical release while the files' own total, where they declare one, describes the release the user actually has. Zero still means "the catalog does not say", so an album neither side can total keeps the plain tick. Two rules hold up the column itself. It is counted before the popularity filter: `cmd/indexbuild` counts the canonical dump's rows per kept release, and counting only the kept recordings would say "9" about a twelve-track album whose other three nobody has played — the same confident lie that kept whole tracklists out of the artifact. And adding a column to the importer's SELECT is how you break every artifact already published, so `artifactHasTotals()` asks the attached artifact whether the column is there (on the writer, where `core` is attached) and selects a literal `0` when it is not — the same shape as the encoding probe beside it. What neither side can give is which tracks are missing, only how many — so an incomplete album still browses, and that is now the exception rather than every album load. One smaller consequence: existing databases read "unknown" until a rescan repopulates the column, which degrades to exactly the old behaviour, so nothing breaks. And our own writers declare the total, because for a long time they did not. `tagwriter` wrote track and disc numbers and dropped the totals, so autotagging an album actively erased the evidence this rests on: the release became MBID-matched — a green tick — while the field `GetAlbumCompleteness` reads stayed absent, which is exactly the "2 of 10 tracks, reported as in your library" the report described. `FieldTotalTracks` / `FieldTotalDiscs` are written by the autotag apply pass and by the download importer, and `dbsync` persists the track total to the row so the album page agrees with the file without waiting for a rescan. Five things about it are load-bearing, and four of them fail silently: - **The total is per disc, not per release, because that is what the tag form declares and what `GetAlbumCompleteness` sums per disc — a release total written on every file multiplies a two-disc album's expectation by two, and no library can then satisfy it. `backend/tagtotals` is that derivation, once, because the two callers must not import each other or the writer. - The Vorbis names are `TRACKTOTAL` and `DISCTOTAL` and no other spelling.** `dhowden/tag`'s Vorbis reader looks at exactly those two keys, so a perfectly reasonable `TOTALTRACKS`, or a `1/12` inside `TRACKNUMBER`, is written successfully and reads back as no total at all. The tests assert the round trip through the reader the scan uses rather than through the bytes, for that reason. - ID3's number and total share one frame, so writing either alone has to read the other off the existing tag or it silently discards it. A total with no number is not written: `/12` is what a reader parses as track 0. - The totals are written unconditionally, not on a diff. The case this exists for is a file that declares no total, which compares equal to nothing and is exactly what a "only if it changed" guard skips. - A single-track download must not be totalled. A `RecordingMBID` anchor resolves `Expected` to that one track, so the same code would tag a track off a twelve-track album "1 of 1" — and a declared total outranks the catalog total that would otherwise have answered correctly. Confidently wrong is worse than absent here, which is the same rule `Known` exists for. One gap this did not close, and it is older: `dhowden/tag` has no RIFF reader, so nothing the tag writer puts in a WAV's `id3 ` chunk is visible to `metadata.ExtractTags` — not the totals and not the title either. `wav_test.go` reads that chunk itself, which is why no test ever noticed. The absence is what gets marked, not the presence. The tracklist put a green tick against every owned track and a legend underneath explaining the tick — a positive mark on the common case, so an album you own outright wore a column of circles and a key for them. It is the streaming-service treatment now: rows not in the library are dimmed in place, and nothing marks the ones that are. Two things follow. Dimming is a colour, so it cannot be the only signal — the row carries `aria-disabled`, which is what reaches anyone not seeing it. And the dimmed rows are why the `loading` banner could go: tracks arriving dimmed reads as the album filling in, so a line of text about the page's own plumbing earns nothing. `unavailable` survives because it is not about plumbing — it says rows may be missing from the page altogether, which nothing on screen can show. (`explore-artist-details` still uses `loading`; it has no equivalent per-row signal.) And that treatment is the app's, not the page's. `utils/ownership.ts` is the rule written once, because it was written at eight call sites and so none of them had the whole of it: Explore's cards, `top-results-row` and the artist page's three card shapes all mixed owned and unowned with a small badge as the only difference, and the badge on the owned ones was a green tick — the mark on the common case this tracklist removed. Owned is plain and draws no badge at all; unowned is dimmed, says so in its accessible name, and keeps its request affordance; a partly-held album says how partly. Four things about it are load-bearing. Ownership is `localId`, and `inLibrary` is deliberately not consulted. The album page answers with `filePaths`, a real file per displayed track, and a card grid cannot afford that — but it does not need to, because `explore_index.local__id` is built by `collectLibraryEntities` from queries that every one join `audio_files` and cleared by `pruneStaleLocalCrossReferences`, whose existence test is a file test in all three cases. That is the same "ownership is a file" rule computed once per scan instead of once per screenful. `in_library` is written by the same pass, so the two agree in a healthy database, but it is a one-way ratchet (`MAX(in_library, excluded.in_library)`) whose only clearing pass is gated on a non-null local id: it cannot be un-set on its own (#118). One is a fact with an owner; the other is a flag that happens to agree. Both `explore-view` and `explore-artist-details` additionally kept a `libraryMBIDs` set that accumulated every MBID ever seen with the flag and cleared it never, in views that never unmount; both are gone. The two answers used to sit on one card. `renderReleaseMenuItems` gates Play on `release.localId > 0` while the badge used `inLibrary`, so an album with the flag and no local row drew a tick saying it was in your library, offered no Play, and — the request item being gated on not* owned — offered no way to ask for it either. Any new surface that asks the question twice will reproduce it. `aria-disabled` goes on rows and not on cards. An unowned row cannot be activated; an unowned card still navigates to the catalog page for it, which is a perfectly good thing to do with something you do not own. The accessible name carries the state either way, which is why it is one helper and not a class. The count is batched, not looked up. `store/completeness-store.ts` is `credit-store` one question over: `request()` is per-card and coalesces a screenful into one `GetAlbumsCompleteness`, absence is cached as an answer (or the albums with no totals re-ask forever), and the whole cache is dropped on a scan, a retag or a removal rather than aged. `library-status.ts`'s `albumBadgeFor` is where that meets `Known`: a total that was never declared is a plain `in-library`, never a ring at 0%. One consequence in the badge itself — a `partial` badge is actionable, and a control named after its action alone dropped the count from the one state the ring exists for, so its name is both. A partly-owned album draws the release, not the part. Once the tags say nine of twelve, `buildLibraryEntry` shows the catalog's twelve with three dimmed, rather than the nine on disk — the missing tracks are the useful information and a tracklist trimmed to what is owned cannot show them. It is guarded on `completeness.known` rather than on "fewer tracks than the cluster", which would swap a catalog tracklist in for every album whose tags simply never declared a total. A side-effect worth knowing: this is what finally makes `ownership()` say something true here, since counting the displayed tracklist of a library-only entry could only ever produce "9 of 9". And it can be asked, because the rule alone reaches too few albums. That guard depends on two inputs the user does not control: the files declaring a per-disc total, and the catalog's own `total_tracks`. Where neither says — which is a great deal of any library, and every library until an artifact carrying the column is published — a partly-owned album showed only the tracks on disk with nothing to say the rest existed. `renderTracklistScope()` is the explicit route: a "Show the whole album" switch that flips the synthetic "Your Library" entry between the local files and the release, which is the rendering the page could already do and could only be triggered automatically. Three things about it are load-bearing. `showFullTracklist` is a tri-state, `null` meaning "follow the automatic rule": the rule is right when it fires and the switch has to be able to agree with the page it sits on rather than starting out contradicting it, which a plain boolean would need recomputed every time the completeness answer moved underneath it. `fullReleaseCluster()` falls back to the highest-scoring cluster, because `findLibraryCluster` is a guess over the `inLibrary` flags and returns nothing when none are set — which is exactly the untagged library the switch exists for, so without the fallback the control would be absent precisely where it is needed. And it is shown only where it can change what is on screen: against the library entry, with a release to switch to, and only when the two tracklists differ — the same test the version dropdown answers, one control over. A dropdown is only a choice if the choices differ. The version selector tested `versionEntries.length`, but a release group routinely has several releases — reissues, regional pressings, a remaster — whose tracklists are identical, and the synthetic "Your Library" entry is often a third name for the same one, so the control appeared with every option showing the same rows. `distinctTracklistCount()` is the real test. It deliberately does not use `fingerprint()`, which keys on recording MBIDs alone: a library entry built from untagged files has none, so every such tracklist fingerprints to the same run of empty strings and compares equal to every other. It falls back to the title, which is what lets a local copy be recognised as the same tracklist the catalog is describing. Say which version you own, not that you own one. A synthetic "Your Library" entry used to stand in for the matching release, which hid the thing worth knowing: you could see that you owned a version but not which, while the real release — its date, country and release count — sat underneath under a different name. The matching release carries `inLibrary` and is marked (★ and the words "in your library", since a `