docs: record that destinations are configuration

Beside the three navigation paragraphs, since it is the fourth thing
the shell states about where the user can go.

Two notes are measured facts rather than design: a default expressed as
an *absent key* survives an existing seed, where one expressed as a zero
value does not; and a spec can no longer assume a destination has a nav
item.

.pi/skills/yellowjacket-dev/SKILL.md

@@ -195,6 +195,12 @@ Two rules about climbing:
 - **Do not write an e2e spec first.** Drive the flow by hand, then
   promote it with `/e2e`. Specs written blind assert on selectors that
   do not exist.
+- **Not every view has a nav item.** Since #25 the destinations are
+  configurable, Autotag is hidden by default and Downloads is absent
+  until a download client exists — so `getByTestId('nav-<view>')` waits
+  30 s for a locator that will never resolve. `navigateTo(page, view)`
+  (`e2e/support/fixtures.ts`) dispatches the app's own `navigate` event.
+  Click the nav item when the *nav* is what the spec is about.
 
 Before a commit, the gate is `make lint`, `make test`, `make ui-test`,
 `make bindings-check`, `make css-check` and — from `frontend/` —

.planning/NOTES.md

@@ -3696,3 +3696,39 @@ as a tidy-up, a change nothing on a desktop renders differently.
 Related: a width-gated decision **is** testable at both tiers, which is
 why #61's phone mini player is a `matchMedia` stub in the component test
 and needs nothing special.
+
+## A default that is an *absent* key survives an existing seed (2026-08-19)
+
+The skill warns that a seed freezes every default it has already
+persisted, so changing one in `backend/config` is invisible against an
+existing `YJ_HOME` while CI, which seeds by running the app, tests the
+new one. That warning is about defaults stored as *values*.
+
+#25's Autotag-hidden default is stored as the **absence of a key**:
+`GeneralConfig.ViewVisibility` is a map, an id it does not mention takes
+`backend/config.Views`' answer, and only what the user changed is ever
+written. So a seed built before the feature existed showed the new
+default immediately — verified against `.dev/seeds/default.tar`, whose
+`config.toml` has no `[General.ViewVisibility]` table at all, and whose
+sidebar came up without Autotag on the first launch of the new binary.
+After toggling it on and off again the file carries exactly one line,
+`autotag = false`.
+
+The general form is worth keeping: **a default expressed as a zero value
+needs a re-seed to observe; a default expressed as an absent key does
+not**, and it needs no migration for existing installs either. It is the
+same property that makes removing a view later free (an unknown key is
+dropped on load), which is what the `#25 → #27` ordering on #73 rests on.
+
+## A spec cannot assume a destination has a nav item (2026-08-19)
+
+Since #25, `getByTestId('nav-<view>')` is not a reliable way to reach a
+view: Autotag is hidden by default and Downloads is absent without a
+download client, so four existing specs failed on a 30 s timeout waiting
+for a locator that will never resolve. `navigateTo(page, view)` in
+`e2e/support/fixtures.ts` dispatches the app's own `navigate` event
+instead, which is what every nav item, card and detail view dispatches —
+so it is the mechanism and not a test-only door.
+
+Use the nav item when the *nav* is the subject, and `navigateTo` when
+the view is.

CLAUDE.md

@@ -945,7 +945,16 @@ change at all.
 
 Two rules hold it up. The **first** navigation *replaces* the launch
 entry rather than pushing one, or every launch costs a back press before
-the app will close. And the in-app back buttons (`navigate-back`, fired
+the app will close. **There are two launch navigations**, which is what
+defeated that rule for five phases: the eager `navigate → home` at the
+foot of `index.ts` and the configured page `GetDefaultPage()` resolves
+to later. Only the first replaced, so a fresh session was already one
+entry deep, the first back press replayed home over home, and on Android
+`canGoBack()` was true so the press that should have exited the app did
+nothing (#142). The landing-page navigation carries `_replace`, honoured
+only while still at index 0 — past that the user has navigated during
+the backend call, and a slow answer must not overwrite an entry they
+made. And the in-app back buttons (`navigate-back`, fired
 by the detail views and `now-playing-view`) go through `history.back()`
 rather than a stack of their own: the old `navStack` is **deleted**, not
 kept beside it, because two stacks is precisely how a view's own back
@@ -988,6 +997,33 @@ empty rather than defaulting to `home`, which is what `app-sidebar`'s
 field used to do to match the landing view — a default that is correct
 only while `GetDefaultPage()` agrees with it.
 
+**Back and forward are chrome, and the depth is the shell's own
+count.** `<nav-history>` in the top bar is #6: the stack was always
+global — every navigation is an entry and `popstate` restores any of
+them in either direction — so what was missing was an affordance, since
+the only way back was a detail view's own button, which leaves the
+screen with the view it belongs to. The buttons dispatch
+`navigate-back` / `navigate-forward` and the shell owns both guards,
+for the reason the old `navStack` was deleted: a second caller reaching
+for `history` is how two stacks come to disagree.
+
+Three things about it are load-bearing. **Forward is not back
+negated**, so the single `pushedEntries` counter could not express it —
+`popstate` carries no direction and fires identically both ways, so a
+counter decremented on every pop reads a forward as a second back. Each
+entry carries its index (`yjIdx`) and the shell keeps the current one
+and a high-water mark; that also survives a jump of more than one,
+which `history.go(-n)` and a long-press on a browser's back button both
+produce. **A control that cannot act is `disabled` here**, which is the
+documented exception to `library-status-indicator`'s rule: the two are
+a pair whose positions the user learns, and hiding one moves the other
+under the cursor. And **it stands down below 900px** — the top bar is
+what runs out of room first below that (it already overflows 600px by
+11px, #143), and nothing becomes unreachable: `nav.back` / `nav.forward`
+(`Alt+Left` / `Alt+Right`, the browser's own combination, and clear of
+the bare arrows that seek) are global at every width, and the phone has
+the platform's gesture.
+
 The assertion is `aria-current="page"`, in
 `e2e/specs/back-navigation.spec.ts`. That file existed throughout the
 bug, covered exactly these journeys, and asserted only
@@ -996,6 +1032,71 @@ whole way through — so it was green on the broken build. Same trap as
 `layout-overflow.spec.ts` and `page-header`: a spec named for the
 behaviour, measuring the plumbing.
 
+**Which destinations exist is configuration, and hiding one takes away
+the nav item and nothing else.** Eleven sidebar entries is more than
+most libraries need (#25), so each is toggleable from Settings →
+Navigation, Autotag is off until asked for, and Downloads is absent
+until there is a client to download with — a destination for a feature
+that cannot work is worse than none. `navigate` still resolves a hidden
+view, which is not a nicety: detail views navigate into these and the
+launch page is one of them. Nothing needed a special case for the
+highlight either, because the paragraph above moved that onto
+`active-view-store`: the sidebar asks `isActive(id)` per *rendered*
+item, so a hidden view lights nothing exactly as a detail view does.
+
+Five things about it are load-bearing.
+
+**The stored shape is a map keyed by view id, and an absent key means
+that view's own default** (`backend/config.Views`). That is what makes
+this need no migration in either direction, and it is the polarity rule
+`AllowMeteredCatalogDownload` states: the zero value is the intended
+answer. A `HiddenViews []string` cannot express "Autotag off by
+default" at all — its zero value is *hide nothing* — and a struct with
+a boolean per view turns a view that later stops existing into stored
+garbage. Here an unknown key is dropped on load and a view added later
+gets its own default rather than being invisible or forcibly visible.
+It is also what makes #73's `#25 → #27` order safe rather than
+backwards: when Jobs folds into Settings, `jobs = true` in somebody's
+config is a key nothing asks about.
+
+**Two states the user could not get out of are refused, in the config
+and not in the checkbox.** Settings is never hideable and the launch
+page is not hideable while it is the launch page. `config.toml` is
+hand-editable, so a disabled checkbox is the affordance and
+`SetViewVisible` is the rule — an app that can be locked out of its own
+Settings by a typo in TOML is a support problem nobody can debug
+remotely. On *load* the launch page is instead un-hidden rather than
+refused: there is nobody to tell, and the honest reading of "my launch
+page is Autotag" is that this user wants Autotag, not that their launch
+page should be silently reset to something they did not choose.
+
+**Downloads is gated at the nav and not in the config**, on
+`downloadStore.available`, so switching it on in Settings still means
+what it says once a client exists and the tab appears without a restart
+(#37's rule). `available` is false until the providers have loaded,
+which makes the item *appear* on a fresh launch rather than appearing
+and then vanishing.
+
+**The tab bar honours the toggles too, and the reason is local rather
+than a general rule about phones.** `PHONE_COLUMN_IDS` is the precedent
+for "what a phone shows is a different question", and it would apply —
+except that `bottom-nav`'s "More" opens the *same* `<app-sidebar>`,
+which filters, so an unfiltered bar would contradict its own drawer one
+tap away. Which four tabs is still plan 016's committed subset; this
+only removes from it, and "More" is never filtered because it is how
+everything else stays reachable.
+
+**The list of destinations is `services/view-meta.ts`**, on
+`shortcut-meta.ts`'s pattern, because #25 gave it a second reader:
+Settings renders a toggle per view and needs the same labels in the
+same order. Which views exist and what an unconfigured install shows is
+Go's (`backend/config.Views`, which `DefaultPage`'s validation reads
+too, so the launchable set is not a second list); how they are *drawn*
+is the frontend's, beside the rest of the icon vocabulary. The binding
+returns the **resolved** map for every view, so the frontend holds no
+copy of the defaults — which would be the copy that shipped in the
+binary rather than the one being edited.
+
 **A primary view is cached, not unmounted.** `index.ts` keeps every
 primary view in the DOM and toggles a `.view-hidden` class, because that
 is what preserves `scrollTop` across navigation — so

backend/config/config.go

@@ -544,7 +544,7 @@ func (c *Config) SetDefaultPage(page string) error {
 		c.General.ApplyDefaults()
 	}
 
-	c.General.DefaultPage = DefaultPage(page)
+	c.General.DefaultPage = View(page)
 
 	if err := c.General.Validate(); err != nil {
 		return fmt.Errorf(
@@ -666,6 +666,81 @@ func (c *Config) SetAllowMeteredCatalogDownload(allow bool) error {
 	return nil
 }
 
+// GetViewVisibility reports which primary views the sidebar should
+// show, answered for every known view rather than only the ones the
+// config mentions -- so the frontend filters on a value and never has
+// to hold a second copy of the defaults.
+func (c *Config) GetViewVisibility() map[string]bool {
+	if c.General == nil {
+		general := &GeneralConfig{}
+		general.ApplyDefaults()
+
+		return general.ResolvedViewVisibility()
+	}
+
+	return c.General.ResolvedViewVisibility()
+}
+
+// SetViewVisible shows or hides one primary view.
+//
+// Two refusals, both about a state the user cannot get out of from the
+// UI they would be left with: Settings is never hideable, and the
+// launch page is never hideable while it is the launch page (change it
+// first). Hiding a view does not make it unreachable -- `navigate`
+// still resolves it, which detail views depend on -- it only takes the
+// nav item away.
+func (c *Config) SetViewVisible(view string, visible bool) error {
+	spec, known := LookupView(view)
+	if !known {
+		return fmt.Errorf("%w: %q", errUnknownView, view)
+	}
+
+	if c.General == nil {
+		c.General = &GeneralConfig{}
+		c.General.ApplyDefaults()
+	}
+
+	if !visible {
+		if !spec.Hideable {
+			return fmt.Errorf("%w: %q", errViewNotHideable, view)
+		}
+
+		if spec.ID == c.General.DefaultPage {
+			return fmt.Errorf("%w: %q", errViewIsLaunchPage, view)
+		}
+	}
+
+	if c.General.ViewVisibility == nil {
+		c.General.ViewVisibility = make(map[string]bool, len(Views))
+	}
+
+	c.General.ViewVisibility[view] = visible
+
+	if err := c.General.Validate(); err != nil {
+		return fmt.Errorf("invalid view visibility: %w", err)
+	}
+
+	if err := c.Save(); err != nil {
+		return fmt.Errorf("could not save config: %w", err)
+	}
+
+	events.Emit(
+		c.ctx,
+		events.GeneralConfigChanged,
+		map[string]any{
+			"ViewVisibility": c.General.ResolvedViewVisibility(),
+		},
+	)
+
+	c.logger.Info(
+		"view visibility updated",
+		"view", view,
+		"visible", visible,
+	)
+
+	return nil
+}
+
 // GetTrackListColumns returns the configured track-list columns.
 func (c *Config) GetTrackListColumns() []tracklist.Column {
 	if c.TrackList == nil {

backend/config/general.go

@@ -5,27 +5,13 @@ import (
 	"fmt"
 )
 
-// DefaultPage identifies which view the app opens to on launch.
-type DefaultPage string
-
-// Valid DefaultPage values, matching the frontend's top-level route ids.
-const (
-	DefaultPageHome      DefaultPage = "home"
-	DefaultPageTracks    DefaultPage = "tracks"
-	DefaultPageAlbums    DefaultPage = "albums"
-	DefaultPageArtists   DefaultPage = "artists"
-	DefaultPageGenres    DefaultPage = "genres"
-	DefaultPagePlaylists DefaultPage = "playlists"
-	DefaultPageExplore   DefaultPage = "explore"
-	DefaultPageDownloads DefaultPage = "downloads"
-	DefaultPageAutotag   DefaultPage = "autotag"
-	DefaultPageJobs      DefaultPage = "jobs"
-)
-
 // DefaultDefaultPage is the launch page for a fresh install.
-const DefaultDefaultPage = DefaultPageHome
+const DefaultDefaultPage = ViewHome
 
-var errUnknownDefaultPage = errors.New("unknown default page")
+var (
+	errUnknownDefaultPage = errors.New("unknown default page")
+	errViewCannotLaunch   = errors.New("view cannot be the launch page")
+)
 
 // QueueFallback identifies what plays, if anything, once the queue
 // runs out with nothing left to auto-advance to.
@@ -46,8 +32,22 @@ var errUnknownQueueFallback = errors.New("unknown queue fallback")
 // GeneralConfig holds general application preferences that don't
 // belong to a more specific subsystem.
 type GeneralConfig struct {
-	DefaultPage   DefaultPage   `toml:"DefaultPage"`
+	DefaultPage   View          `toml:"DefaultPage"`
 	QueueFallback QueueFallback `toml:"QueueFallback"`
+	// ViewVisibility says which sidebar destinations are shown, keyed by
+	// view id.
+	//
+	// **An absent key means that view's own default** (`Views`), and that
+	// is the whole reason this is a map rather than a `HiddenViews
+	// []string` or a struct of booleans. A list's zero value is "hide
+	// nothing", which cannot express Autotag being off by default without
+	// a migration; a struct field for a view that later stops existing is
+	// stored garbage somebody has to deprecate. Here a view added later
+	// gets its own default rather than being invisible or forcibly
+	// visible, an unknown key is dropped on load, and no install needs
+	// migrating in either direction. Same polarity rule as
+	// AllowMeteredCatalogDownload: the zero value is the intended answer.
+	ViewVisibility map[string]bool `toml:"ViewVisibility"`
 	// AllowMeteredCatalogDownload permits the ~0.6 GB Explore catalog to
 	// be fetched on a connection the platform calls cellular. It defaults
 	// to false, which is the whole point: the zero value is the safe one,
@@ -71,15 +71,17 @@ func (c *GeneralConfig) ApplyDefaults() {
 func (c *GeneralConfig) Validate() error {
 	c.ApplyDefaults()
 
-	switch c.DefaultPage {
-	case DefaultPageHome, DefaultPageTracks, DefaultPageAlbums, DefaultPageArtists,
-		DefaultPageGenres, DefaultPagePlaylists, DefaultPageExplore, DefaultPageDownloads,
-		DefaultPageAutotag, DefaultPageJobs:
-		// Valid.
-	default:
+	spec, known := LookupView(string(c.DefaultPage))
+	if !known {
 		return fmt.Errorf("%w: %q", errUnknownDefaultPage, c.DefaultPage)
 	}
 
+	if !spec.CanLaunch {
+		return fmt.Errorf("%w: %q", errViewCannotLaunch, c.DefaultPage)
+	}
+
+	c.normalizeViewVisibility()
+
 	switch c.QueueFallback {
 	case QueueFallbackStop, QueueFallbackFavorites, QueueFallbackDynamicMix:
 		// Valid.
@@ -89,3 +91,51 @@ func (c *GeneralConfig) Validate() error {
 
 	return nil
 }
+
+// normalizeViewVisibility drops what the stored map may not say, and
+// repairs the one invariant the shell depends on.
+//
+// Three things are dropped or forced, and all three are reachable only
+// from a hand-edited config or from a version that knew different
+// views: an unknown id (a view removed since, e.g. when #27 folds Jobs
+// into Settings) says nothing to anybody; a view that is not Hideable
+// cannot be false; and **the launch page is always visible**, because
+// otherwise an install lands on a page with no nav item pointing at it.
+//
+// That last one is a *repair* here and an *error* at the setter
+// (SetViewVisible), deliberately. On load there is nobody to tell and
+// the honest reading of "my launch page is Autotag" is that this user
+// wants Autotag, so it is un-hidden rather than the launch page being
+// silently reset to something they did not choose. At the setter the
+// user is right there and can act, so it refuses and says why.
+func (c *GeneralConfig) normalizeViewVisibility() {
+	for id := range c.ViewVisibility {
+		spec, known := LookupView(id)
+		if !known || !spec.Hideable {
+			delete(c.ViewVisibility, id)
+		}
+	}
+
+	if visible, ok := c.ViewVisibility[string(c.DefaultPage)]; ok && !visible {
+		c.ViewVisibility[string(c.DefaultPage)] = true
+	}
+}
+
+// ResolvedViewVisibility answers for every known view, so no caller has
+// to know the defaults -- the frontend included, which is why the
+// binding returns this rather than the stored map.
+func (c *GeneralConfig) ResolvedViewVisibility() map[string]bool {
+	resolved := make(map[string]bool, len(Views))
+
+	for _, v := range Views {
+		visible := v.VisibleByDefault
+
+		if stored, ok := c.ViewVisibility[string(v.ID)]; ok && v.Hideable {
+			visible = stored
+		}
+
+		resolved[string(v.ID)] = visible
+	}
+
+	return resolved
+}

backend/config/views.go

@@ -0,0 +1,89 @@
+package config
+
+import "errors"
+
+var (
+	errUnknownView      = errors.New("unknown view")
+	errViewNotHideable  = errors.New("view cannot be hidden")
+	errViewIsLaunchPage = errors.New("view is the launch page")
+)
+
+// View identifies one of the shell's primary destinations -- the
+// things the sidebar lists and `index.ts` knows as `VIEW_TAGS`.
+type View string
+
+// The primary views, in no particular order: the sidebar owns the order
+// it draws them in, because that is presentation.
+const (
+	ViewHome      View = "home"
+	ViewPlaylists View = "playlists"
+	ViewArtists   View = "artists"
+	ViewGenres    View = "genres"
+	ViewAlbums    View = "albums"
+	ViewTracks    View = "tracks"
+	ViewExplore   View = "explore"
+	ViewDownloads View = "downloads"
+	ViewAutotag   View = "autotag"
+	ViewJobs      View = "jobs"
+	ViewSettings  View = "settings"
+)
+
+// ViewSpec is what the backend knows about a destination. The label and
+// the icon are deliberately absent: those are presentation, they live
+// beside the rest of the app's icon vocabulary in
+// `frontend/src/utils/icon-language.ts`, and a Go copy of them would be
+// a second thing to keep in step for nothing.
+type ViewSpec struct {
+	// ID is the view name the frontend navigates by.
+	ID View
+	// VisibleByDefault is what an install gets when the config says
+	// nothing about this view -- which is every install until somebody
+	// changes it, and every view added after this one shipped.
+	VisibleByDefault bool
+	// Hideable is false for Settings alone. It is a property of the
+	// view rather than a check in the setter because `config.toml` is
+	// hand-editable, and an app that can be locked out of its own
+	// Settings by a typo is a support problem nobody can debug
+	// remotely.
+	Hideable bool
+	// CanLaunch reports whether the view may be the launch page.
+	// Settings is the only one that may not, which is the shape the
+	// DefaultPage enum already had.
+	CanLaunch bool
+}
+
+// Views is the one list of primary destinations, in the order Settings
+// offers them.
+//
+// It is the single source for three things that used to be written down
+// separately: which views exist, which of them may be the launch page
+// (`DefaultPage`'s validation reads it), and what an unconfigured
+// install shows.
+//
+// Autotag is the one view hidden by default: it rewrites tags on disk,
+// which is not what most libraries want on day one, and #25 asks for it
+// to be turned on deliberately.
+var Views = []ViewSpec{
+	{ID: ViewHome, VisibleByDefault: true, Hideable: true, CanLaunch: true},
+	{ID: ViewPlaylists, VisibleByDefault: true, Hideable: true, CanLaunch: true},
+	{ID: ViewArtists, VisibleByDefault: true, Hideable: true, CanLaunch: true},
+	{ID: ViewGenres, VisibleByDefault: true, Hideable: true, CanLaunch: true},
+	{ID: ViewAlbums, VisibleByDefault: true, Hideable: true, CanLaunch: true},
+	{ID: ViewTracks, VisibleByDefault: true, Hideable: true, CanLaunch: true},
+	{ID: ViewExplore, VisibleByDefault: true, Hideable: true, CanLaunch: true},
+	{ID: ViewDownloads, VisibleByDefault: true, Hideable: true, CanLaunch: true},
+	{ID: ViewAutotag, VisibleByDefault: false, Hideable: true, CanLaunch: true},
+	{ID: ViewJobs, VisibleByDefault: true, Hideable: true, CanLaunch: true},
+	{ID: ViewSettings, VisibleByDefault: true, Hideable: false, CanLaunch: false},
+}
+
+// LookupView returns the spec for a view id.
+func LookupView(id string) (ViewSpec, bool) {
+	for _, v := range Views {
+		if string(v.ID) == id {
+			return v, true
+		}
+	}
+
+	return ViewSpec{}, false
+}

backend/config/views_test.go

@@ -0,0 +1,255 @@
+package config
+
+import (
+	"errors"
+	"log/slog"
+	"path/filepath"
+	"testing"
+)
+
+// newViewTestConfig builds a Config backed by a temp file, which is all
+// SetViewVisible needs: it saves and emits, and the emit is a no-op
+// without a running app.
+func newViewTestConfig(t *testing.T) *Config {
+	t.Helper()
+
+	c := &Config{
+		logger:   slog.Default(),
+		filePath: filepath.Join(t.TempDir(), "config.toml"),
+	}
+
+	// Load a file that is not there: that is what marks the config
+	// loaded, without which Save refuses on the *second* write.
+	if err := c.Load(); err != nil {
+		t.Fatalf("Load() error: %v", err)
+	}
+
+	return c
+}
+
+// A view the config says nothing about takes its own default, which is
+// what makes this need no migration in either direction: an existing
+// install gets Autotag hidden without a key, and a view added later
+// gets its own answer rather than the list's.
+func TestViewVisibilityDefaults(t *testing.T) {
+	t.Parallel()
+
+	general := &GeneralConfig{}
+	general.ApplyDefaults()
+
+	resolved := general.ResolvedViewVisibility()
+
+	if len(resolved) != len(Views) {
+		t.Fatalf("resolved %d views, want %d", len(resolved), len(Views))
+	}
+
+	if resolved[string(ViewAutotag)] {
+		t.Error("autotag should be hidden by default")
+	}
+
+	for _, v := range Views {
+		if v.ID == ViewAutotag {
+			continue
+		}
+
+		if !resolved[string(v.ID)] {
+			t.Errorf("%s should be visible by default", v.ID)
+		}
+	}
+}
+
+// A stored answer wins over the default, in both directions -- turning
+// Autotag on is the whole user-facing point.
+func TestViewVisibilityStoredWins(t *testing.T) {
+	t.Parallel()
+
+	general := &GeneralConfig{
+		ViewVisibility: map[string]bool{
+			string(ViewAutotag): true,
+			string(ViewJobs):    false,
+		},
+	}
+	general.ApplyDefaults()
+
+	resolved := general.ResolvedViewVisibility()
+
+	if !resolved[string(ViewAutotag)] {
+		t.Error("autotag was switched on and should be visible")
+	}
+
+	if resolved[string(ViewJobs)] {
+		t.Error("jobs was switched off and should be hidden")
+	}
+}
+
+// A key for a view that no longer exists is discarded rather than
+// migrated. This is the property the #25-before-#27 ordering rests on:
+// when Jobs folds into Settings, `jobs = true` in somebody's config is
+// a key nothing asks about, not a cleanup task.
+func TestValidateDropsUnknownAndUnhideableViews(t *testing.T) {
+	t.Parallel()
+
+	general := &GeneralConfig{
+		ViewVisibility: map[string]bool{
+			"a-view-that-was-removed": true,
+			string(ViewSettings):      false,
+			string(ViewAutotag):       true,
+		},
+	}
+
+	if err := general.Validate(); err != nil {
+		t.Fatalf("Validate() error: %v", err)
+	}
+
+	if _, ok := general.ViewVisibility["a-view-that-was-removed"]; ok {
+		t.Error("an unknown view id should be dropped on load")
+	}
+
+	if _, ok := general.ViewVisibility[string(ViewSettings)]; ok {
+		t.Error("settings is not hideable and should not be stored")
+	}
+
+	if !general.ResolvedViewVisibility()[string(ViewSettings)] {
+		t.Error("settings must resolve visible whatever the file said")
+	}
+}
+
+// On load there is nobody to tell, so a launch page hidden by a
+// hand-edited file is un-hidden rather than the launch page being
+// reset to something the user did not choose.
+func TestValidateRevealsAHiddenLaunchPage(t *testing.T) {
+	t.Parallel()
+
+	general := &GeneralConfig{
+		DefaultPage: ViewAutotag,
+		ViewVisibility: map[string]bool{
+			string(ViewAutotag): false,
+		},
+	}
+
+	if err := general.Validate(); err != nil {
+		t.Fatalf("Validate() error: %v", err)
+	}
+
+	if !general.ResolvedViewVisibility()[string(ViewAutotag)] {
+		t.Error("the launch page must be visible")
+	}
+}
+
+// Settings may not be the launch page, which is the shape the old
+// DefaultPage enum had and is now read off the same table.
+func TestValidateRejectsAnUnlaunchablePage(t *testing.T) {
+	t.Parallel()
+
+	general := &GeneralConfig{DefaultPage: ViewSettings}
+
+	err := general.Validate()
+	if !errors.Is(err, errViewCannotLaunch) {
+		t.Fatalf("Validate() error = %v, want errViewCannotLaunch", err)
+	}
+}
+
+// At the setter the user is present and can act, so the two states
+// they could not get out of are refused rather than repaired.
+func TestSetViewVisibleRefusals(t *testing.T) {
+	t.Parallel()
+
+	tests := []struct {
+		name    string
+		view    string
+		visible bool
+		want    error
+	}{
+		{"settings is never hideable", string(ViewSettings), false, errViewNotHideable},
+		{"the launch page is not hideable", string(ViewHome), false, errViewIsLaunchPage},
+		{"an unknown view is not a setting", "nonsense", false, errUnknownView},
+	}
+
+	for _, tt := range tests {
+		t.Run(tt.name, func(t *testing.T) {
+			t.Parallel()
+
+			c := newViewTestConfig(t)
+
+			err := c.SetViewVisible(tt.view, tt.visible)
+			if !errors.Is(err, tt.want) {
+				t.Fatalf("SetViewVisible() error = %v, want %v", err, tt.want)
+			}
+		})
+	}
+}
+
+// Showing a view is never refused, including Settings and the launch
+// page -- there is no state to be stuck in.
+func TestSetViewVisibleShowsAnything(t *testing.T) {
+	t.Parallel()
+
+	c := newViewTestConfig(t)
+
+	for _, v := range Views {
+		if err := c.SetViewVisible(string(v.ID), true); err != nil {
+			t.Fatalf("SetViewVisible(%q, true) error: %v", v.ID, err)
+		}
+	}
+
+	if !c.GetViewVisibility()[string(ViewAutotag)] {
+		t.Error("autotag was switched on and should be visible")
+	}
+}
+
+// The stored map survives a save/load round trip, which is what a
+// map-valued TOML key is worth checking for.
+func TestViewVisibilityRoundTrips(t *testing.T) {
+	t.Parallel()
+
+	path := filepath.Join(t.TempDir(), "config.toml")
+
+	original := &Config{logger: slog.Default(), filePath: path}
+	if err := original.Load(); err != nil {
+		t.Fatalf("Load() error: %v", err)
+	}
+
+	if err := original.SetViewVisible(string(ViewAutotag), true); err != nil {
+		t.Fatalf("SetViewVisible() error: %v", err)
+	}
+
+	if err := original.SetViewVisible(string(ViewJobs), false); err != nil {
+		t.Fatalf("SetViewVisible() error: %v", err)
+	}
+
+	loaded := &Config{logger: slog.Default(), filePath: path}
+	if err := loaded.Load(); err != nil {
+		t.Fatalf("Load() error: %v", err)
+	}
+
+	resolved := loaded.GetViewVisibility()
+
+	if !resolved[string(ViewAutotag)] {
+		t.Error("autotag should have loaded as visible")
+	}
+
+	if resolved[string(ViewJobs)] {
+		t.Error("jobs should have loaded as hidden")
+	}
+}
+
+// Every view the shell can launch into is a view the sidebar can show,
+// or an install could land on a page with no nav item and no setting
+// pointing at it.
+func TestEveryLaunchableViewIsAView(t *testing.T) {
+	t.Parallel()
+
+	for _, v := range Views {
+		if !v.CanLaunch {
+			continue
+		}
+
+		if !v.Hideable {
+			continue
+		}
+
+		if _, ok := LookupView(string(v.ID)); !ok {
+			t.Errorf("%s is launchable but not a known view", v.ID)
+		}
+	}
+}

backend/shortcuts/config.go

@@ -24,10 +24,19 @@ func DefaultBindings() map[string]string {
 		"player.repeat":      "R",
 		"player.mute":        "M",
 
-		// Navigation (Global scope)
+		// Navigation (Global scope).  Back and forward are the browser's
+		// own combination on every platform, which is the whole design
+		// brief for them: the app has one global history and this is the
+		// gesture people already have for it.  The modifier is what keeps
+		// them clear of `player.seekBack`/`seekForward`, which are the
+		// bare arrows -- a binding is matched on its full canonical
+		// string, so "Alt+Left" and "Left" are different keys and not a
+		// conflict.
 		"nav.search":    "/",
 		"nav.searchAlt": "Ctrl+F",
 		"nav.queue":     "Q",
+		"nav.back":      "Alt+Left",
+		"nav.forward":   "Alt+Right",
 
 		// App actions
 		"app.selectAll": "Ctrl+A",

e2e/specs/back-navigation.spec.ts

@@ -79,6 +79,114 @@ async function openAnArtist(app: Page): Promise<void> {
   );
 }
 
+/**
+ * The global back/forward control (#6).
+ *
+ * It is desktop chrome — hidden below 900px, where the sidebar has
+ * already given up its labels — so these set a desktop viewport
+ * explicitly rather than trusting the runner's default.
+ */
+const DESKTOP = { width: 1280, height: 800 };
+
+const backButton = (page: Page) =>
+  page.locator('nav-history').getByRole('button', { name: 'Back' });
+
+const forwardButton = (page: Page) =>
+  page.locator('nav-history').getByRole('button', { name: 'Forward' });
+
+test.describe('global back and forward', () => {
+  test.beforeEach(async ({ app }) => {
+    await app.setViewportSize(DESKTOP);
+  });
+
+  test('offers nothing at launch, in either direction', async ({ app }) => {
+    // The launch entry is *replaced*, not pushed, so there is nothing
+    // of ours behind it — and a Back button that is live at the root
+    // is a press that does nothing on desktop and, on Android, the
+    // press that should have exited the app (#142). This assertion is
+    // what pins that: it failed before the launch navigation stopped
+    // recording two entries.
+    await expect(backButton(app)).toBeDisabled();
+    await expect(forwardButton(app)).toBeDisabled();
+  });
+
+  test('walks the history in both directions, and says which are available', async ({
+    app,
+  }) => {
+    await app.getByTestId('nav-albums').click();
+    await expect(activeView(app)).toHaveAttribute('data-active-view', 'albums');
+    await expect(backButton(app)).toBeEnabled();
+    await expect(forwardButton(app)).toBeDisabled();
+
+    await app.getByTestId('nav-tracks').click();
+    await expect(activeView(app)).toHaveAttribute('data-active-view', 'tracks');
+
+    await backButton(app).click();
+
+    await expect(activeView(app)).toHaveAttribute('data-active-view', 'albums');
+    // Standing in the middle of the list: both directions live, which
+    // is the state a single depth counter cannot express.
+    await expect(backButton(app)).toBeEnabled();
+    await expect(forwardButton(app)).toBeEnabled();
+
+    await forwardButton(app).click();
+
+    await expect(activeView(app)).toHaveAttribute('data-active-view', 'tracks');
+    await expect(forwardButton(app)).toBeDisabled();
+  });
+
+  test('reaches the detail view a tab click left behind', async ({ app }) => {
+    // The report, exactly: the album is one entry away the whole time,
+    // and before this control the only way back to it was a button
+    // that had gone off screen with the view it belonged to.
+    await app.getByTestId('nav-artists').click();
+    await openAnArtist(app);
+
+    await app.getByTestId('nav-tracks').click();
+    await expect(activeView(app)).toHaveAttribute('data-active-view', 'tracks');
+
+    await backButton(app).click();
+
+    await expect(activeView(app)).toHaveAttribute(
+      'data-active-view',
+      'explore-artist-details',
+    );
+  });
+
+  test('drops the forward list when the user navigates from the middle', async ({
+    app,
+  }) => {
+    await app.getByTestId('nav-albums').click();
+    await app.getByTestId('nav-tracks').click();
+    await backButton(app).click();
+    await expect(forwardButton(app)).toBeEnabled();
+
+    // A browser truncates here, and so does this: what was ahead is no
+    // longer reachable, and a Forward button still offering it would
+    // be pointing at an entry that has been overwritten.
+    await app.getByTestId('nav-genres').click();
+
+    await expect(activeView(app)).toHaveAttribute('data-active-view', 'genres');
+    await expect(forwardButton(app)).toBeDisabled();
+    await expect(backButton(app)).toBeEnabled();
+  });
+
+  test('is absent below the desktop band, where nothing needs it', async ({
+    app,
+  }) => {
+    // Alt+Left/Right survive at every width, the detail views keep
+    // their own back buttons and the phone has the platform's gesture
+    // — so this is a control standing down, not an action becoming
+    // unreachable. It is hidden at 899 because the top bar is what
+    // runs out of room first below 900 (#143).
+    await app.setViewportSize({ width: 899, height: 600 });
+    await expect(app.locator('nav-history')).toBeHidden();
+
+    await app.setViewportSize({ width: 390, height: 844 });
+    await expect(app.locator('nav-history')).toBeHidden();
+  });
+});
+
 test.describe('the back gesture', () => {
   test('leaves a detail view for the view it was opened from', async ({
     app,

e2e/specs/page-header.spec.ts

@@ -1,4 +1,4 @@
-import { test, expect } from '../support/fixtures.js';
+import { test, expect, navigateTo } from '../support/fixtures.js';
 
 /**
  * H-19: Playlists, Downloads, Jobs, Settings and Home had a page
@@ -58,8 +58,12 @@ const TAGS: Record<string, string> = {
 
 test.describe('every primary view says what it is', () => {
   test('each one has the shared header, with a heading', async ({ app }) => {
+    // By event rather than by nav item: a destination is not
+    // guaranteed to have one any more (#25 — Downloads is absent
+    // without a download client), and every one of these is still a
+    // primary view with a header, which is what this spec is about.
     for (const [view, heading, hasCount] of VIEWS) {
-      await app.getByTestId(`nav-${view}`).click();
+      await navigateTo(app, view);
       await expect(app.getByTestId('main-content')).toHaveAttribute(
         'data-active-view',
         view,

e2e/specs/settings-reach.spec.ts

@@ -1,4 +1,4 @@
-import { test, expect } from '../support/fixtures.js';
+import { test, expect, navigateTo } from '../support/fixtures.js';
 
 /**
  * Plan 007 phase 5: a11y.1 and a11y.2, frozen against the real app.
@@ -56,7 +56,9 @@ test.describe('Settings is reachable without a mouse', () => {
 
 test.describe("Downloads' tabs are tabs", () => {
   test('arrow keys move the selection and swap the panel', async ({ app }) => {
-    await app.getByTestId('nav-downloads').click();
+    // By event, not by nav item: with no download client configured
+    // there is no Downloads destination to click (#25).
+    await navigateTo(app, 'downloads');
 
     const view = app.locator('downloads-view');
     const requests = view.getByRole('tab', { name: 'Requests' });

e2e/specs/view-lifecycle.spec.ts

@@ -4,6 +4,7 @@ import {
   eventNames,
   resetEvents,
   waitForEvent,
+  navigateTo,
 } from '../support/fixtures.js';
 
 /**
@@ -39,7 +40,9 @@ test.describe('view lifecycle', () => {
   test('a keypress on Settings does not reach the Autotag queue', async ({
     app,
   }) => {
-    await app.getByTestId('nav-autotag').click();
+    // By event, not by nav item: Autotag is hidden by default (#25)
+    // and a hidden view is still reachable.
+    await navigateTo(app, 'autotag');
     await expect(app.getByTestId('main-content')).toHaveAttribute(
       'data-active-view',
       'autotag',
@@ -83,7 +86,9 @@ test.describe('view lifecycle', () => {
     // The other half of the same bug (H-2): two document keydown handlers
     // with no arbitration meant `s` on this page skipped the album *and*
     // toggled shuffle.  As a panel binding it can only mean one thing.
-    await app.getByTestId('nav-autotag').click();
+    // By event, not by nav item: Autotag is hidden by default (#25)
+    // and a hidden view is still reachable.
+    await navigateTo(app, 'autotag');
     await expect
       .poll(() => pendingCount(app))
       .toMatch(/^Pending \(\d+\)$/);

e2e/specs/view-visibility.spec.ts

@@ -0,0 +1,116 @@
+import { test, expect, navigateTo } from '../support/fixtures.js';
+
+/**
+ * Which destinations the navigation offers (#25).
+ *
+ * Eleven sidebar entries is more than most libraries need, so they are
+ * individually toggleable from Settings, Autotag is off until asked for
+ * and Downloads is absent until there is a client to download with.
+ *
+ * **The assertions are about the navigation, not about the setting.**
+ * "The config was saved" is the plumbing, and the two most recent bugs
+ * in this area — #69 and #72 — both shipped green under specs that
+ * measured exactly that. What a person sees is whether the item is in
+ * the accessibility tree, and whether the view is still reachable when
+ * it is not.
+ *
+ * This runs against the seeded app, whose config is defaults and whose
+ * download client list is empty, so the initial state below is what a
+ * fresh install looks like.
+ */
+type Page = import('@playwright/test').Page;
+
+const navItem = (page: Page, label: string) =>
+  page.getByRole('button', { name: label, exact: true });
+
+/** The Navigation section's checkbox for a destination. */
+const viewToggle = (page: Page, label: string) =>
+  page.getByRole('checkbox', { name: `Show ${label} in the navigation` });
+
+async function openNavigationSettings(page: Page): Promise<void> {
+  await page.getByTestId('nav-settings').click();
+
+  const section = page.locator(
+    'config-page config-section[heading="Navigation"] .header',
+  );
+
+  await expect(section).toBeVisible();
+
+  if ((await section.getAttribute('aria-expanded')) === 'false') {
+    await section.click();
+  }
+
+  await expect(section).toHaveAttribute('aria-expanded', 'true');
+}
+
+test.describe('configurable destinations', () => {
+  test('Autotag is off by default and Downloads needs a client', async ({
+    app,
+  }) => {
+    await expect(app.getByTestId('nav-home')).toBeVisible();
+
+    await expect(app.getByTestId('nav-autotag')).toHaveCount(0);
+    await expect(app.getByTestId('nav-downloads')).toHaveCount(0);
+  });
+
+  /**
+   * Hiding takes the item away and nothing else. Detail views navigate
+   * into these and the launch page is one of them, so a destination
+   * with no nav item still has to open.
+   */
+  test('a hidden destination is still reachable', async ({ app }) => {
+    await navigateTo(app, 'autotag');
+
+    await expect(app.getByTestId('main-content')).toHaveAttribute(
+      'data-active-view',
+      'autotag',
+    );
+
+    // And nothing is falsely lit while standing on it -- the same rule
+    // a detail view follows, with no special case for either.
+    await expect(navItem(app, 'Home')).toHaveAttribute('aria-current', 'false');
+  });
+
+  test('switching Autotag on adds it to the sidebar', async ({ app }) => {
+    await openNavigationSettings(app);
+
+    await viewToggle(app, 'Autotag').check();
+
+    await expect(app.getByTestId('nav-autotag')).toBeVisible();
+
+    // Clicking it is the point of having it.
+    await app.getByTestId('nav-autotag').click();
+    await expect(app.getByTestId('main-content')).toHaveAttribute(
+      'data-active-view',
+      'autotag',
+    );
+
+    // Put it back, or the next spec against this app sees a library
+    // this one changed.
+    await openNavigationSettings(app);
+    await viewToggle(app, 'Autotag').uncheck();
+    await expect(app.getByTestId('nav-autotag')).toHaveCount(0);
+  });
+
+  /**
+   * Settings has no toggle at all, rather than a toggle that refuses:
+   * a user who hides it cannot get back to unhide it. The backend
+   * refuses it too, because `config.toml` is hand-editable.
+   */
+  test('Settings cannot be switched off', async ({ app }) => {
+    await openNavigationSettings(app);
+
+    await expect(viewToggle(app, 'Settings')).toBeDisabled();
+    await expect(app.getByTestId('nav-settings')).toBeVisible();
+  });
+
+  /**
+   * The launch page is refused while it is the launch page, which is a
+   * state the user can leave by changing the launch page above it.
+   */
+  test('the launch page cannot be switched off', async ({ app }) => {
+    await openNavigationSettings(app);
+
+    await expect(viewToggle(app, 'Home')).toBeDisabled();
+  });
+});

e2e/support/fixtures.ts

@@ -111,6 +111,35 @@ export async function bindingCalls(page: Page): Promise<string[]> {
   return calls.map(nameOf);
 }
 
+/**
+ * Go to a view without going through the navigation.
+ *
+ * `navigate` is the event the shell listens for and every nav item, card
+ * and detail view dispatches, so this is the app's own mechanism rather
+ * than a test-only door. It exists because a destination is not
+ * guaranteed to have a nav item any more (#25): Autotag is hidden until
+ * the user asks for it and Downloads until a client exists, and a spec
+ * about what a *view* does should not also be asserting that the
+ * sidebar offers it.
+ */
+export async function navigateTo(page: Page, view: string): Promise<void> {
+  await page.evaluate(
+    (v) =>
+      void document.dispatchEvent(
+        new CustomEvent('navigate', {
+          detail: { view: v },
+          bubbles: true,
+          composed: true,
+        }),
+      ),
+    view,
+  );
+
+  await page
+    .getByTestId('main-content')
+    .waitFor({ state: 'attached' });
+}
+
 /** Thin client for the dev-only /__test/ surface (backend/testctl). */
 export class TestCtl {
   constructor(private readonly baseURL: string) {}

frontend/bindings/yellowjacket/backend/config/config.ts

@@ -112,6 +112,16 @@ export function GetTrackListColumns(): $CancellablePromise<tracklist$0.Column[]
     return $Call.ByID(3426289065);
 }
 
+/**
+ * GetViewVisibility reports which primary views the sidebar should
+ * show, answered for every known view rather than only the ones the
+ * config mentions -- so the frontend filters on a value and never has
+ * to hold a second copy of the defaults.
+ */
+export function GetViewVisibility(): $CancellablePromise<{ [_ in string]?: boolean } | null> {
+    return $Call.ByID(2798108026);
+}
+
 /**
  * Load reads and parses the config file from disk.
  */
@@ -247,6 +257,20 @@ export function SetTrackListColumns(columns: tracklist$0.Column[] | null): $Canc
     return $Call.ByID(4226159685, columns);
 }
 
+/**
+ * SetViewVisible shows or hides one primary view.
+ * 
+ * Two refusals, both about a state the user cannot get out of from the
+ * UI they would be left with: Settings is never hideable, and the
+ * launch page is never hideable while it is the launch page (change it
+ * first). Hiding a view does not make it unreachable -- `navigate`
+ * still resolves it, which detail views depend on -- it only takes the
+ * nav item away.
+ */
+export function SetViewVisible(view: string, visible: boolean): $CancellablePromise<void> {
+    return $Call.ByID(1751982648, view, visible);
+}
+
 /**
  * Validate returns errors if there is a breaking issue with the config.
  */

frontend/index.css

@@ -104,6 +104,15 @@ p {
     flex: 0 1 320px;
 }
 
+/* The bar is `justify-content: space-between`, which with four children
+   spreads them evenly and left back/forward floating in the middle of
+   nothing. Collecting the free space *after* this one puts the pair
+   beside the brand, where a browser keeps them, and leaves the
+   right-hand group exactly as it was. */
+.top-bar nav-history {
+    margin-right: auto;
+}
+
 ul {
     list-style-type: none;
 }
@@ -133,6 +142,23 @@ ul {
     .subtitle {
         display: none;
     }
+
+    /* Back/forward is Desktop-band chrome (#6), and 900 is the same
+       line the sidebar's labels and the subtitle are already given up
+       at -- below it the shell is narrow enough that the header is
+       what runs out of room first. Measured at 600, the bottom of the
+       Compact band: the bar is 611px inside a 600px viewport *before*
+       this component exists (filed separately), and 695px with it, so
+       keeping it here would be widening a violation of the promise
+       that nothing scrolls sideways at a supported size.
+
+       Nothing is unreachable as a result, which is the rule that
+       decides it: Alt+Left / Alt+Right are global and every width has
+       them, the detail views keep their own back buttons, and the
+       phone additionally has the platform's gesture. */
+    .top-bar nav-history {
+        display: none;
+    }
 }
 
 body div.sidebar {
@@ -346,7 +372,13 @@ body div.sidebar {
 
     /* The search box is the one header control worth its width; the
        library filter is a rarely-changed setting and reachable from
-       the drawer's Settings. */
+       the drawer's Settings.
+
+       `nav-history` is already gone from 899 down. It would belong
+       here anyway and for a stronger reason than width: the phone has
+       Back as a gesture or a button the OS owns, and this app hooks it
+       (`popstate`), so a second Back in the chrome duplicates a
+       control the platform provides. */
     .top-bar library-filter {
         display: none;
     }

frontend/index.html

@@ -20,6 +20,12 @@
             <!-- a11y.29: a heading level was being used for type size. -->
             <p class="subtitle">Music how it was meant to bee.</p>
         </hgroup>
+        <!-- Global back/forward (#6). Before the library filter so the
+             two navigation controls in this bar are adjacent, and after
+             the brand because that is where a window's chrome ends and
+             the app's begins. Hidden below 600px by index.css: the
+             phone has a system back, and this bar has no room. -->
+        <nav-history></nav-history>
         <library-filter></library-filter>
         <search-bar></search-bar>
         <job-indicator></job-indicator>

frontend/index.ts

@@ -23,6 +23,7 @@ import '@components/now-playing/now-playing.ts';
 import '@components/sidebar/app-sidebar.ts';
 import '@components/bottom-nav/bottom-nav.ts';
 import '@components/queue-panel/queue-panel.ts';
+import '@components/nav-history/nav-history.ts';
 import '@components/search-bar/search-bar.ts';
 import '@components/library-filter/library-filter.ts';
 import '@components/first-run-wizard/first-run-wizard.ts';
@@ -41,6 +42,7 @@ import { registerBundledIcons } from './src/icons';
 import { queueStore } from '@store/queue-store';
 import { searchStore } from '@store/search-store';
 import { activeViewStore } from '@store/active-view-store';
+import { historyStore } from '@store/history-store';
 import * as Player from '@go/player/player.js';
 import * as Queue from '@go/queue/queue.js';
 import { GetDefaultPage } from '@go/config/config.js';
@@ -215,45 +217,101 @@ document.addEventListener('navigate', (e: Event) => {
 // go through `history.back()` rather than popping `navStack`
 // themselves, so one press cannot consume two entries.
 
-/** The navigation an entry stands for. `undefined` on the entry that
- *  predates the app's own routing, which is the one back exits from. */
-type NavState = { yjNav?: { view: string; [key: string]: any } };
+/** The navigation an entry stands for, and where it sits in this
+ *  session's list. `undefined` on the entry that predates the app's own
+ *  routing, which is the one back exits from. */
+type NavState = { yjNav?: { view: string; [key: string]: any }; yjIdx?: number };
 
 /** Whether the app's first navigation has been recorded. It *replaces*
  *  the launch entry rather than pushing, or every launch would cost one
  *  back press before the app would exit. */
 let historyStarted = false;
 
-/** How many entries this session has pushed beyond that first one --
- *  i.e. how deep back can go while staying inside the app. */
-let pushedEntries = 0;
+// Back and forward are the *same* `popstate` event -- it carries no
+// direction, and the History API exposes neither the current position
+// nor a reachable depth. So the shell numbers its own entries: the
+// index of the one showing, and the highest index reachable from here.
+//
+// The counter this replaced (`pushedEntries`, one number decremented on
+// every pop) could not express forward at all: going forward looked
+// exactly like going back again, so two presses of a Forward button
+// would have claimed the app was at its root.
+
+/** Index of the entry now showing. 0 is the launch entry, which is
+ *  replaced rather than pushed -- so this is also how deep back can go
+ *  while staying inside the app. */
+let currentIndex = 0;
+
+/** The highest index reachable from here: how far forward is left.
+ *  A new navigation truncates the forward list, exactly as a browser
+ *  does, so this is reset to the entry being pushed. */
+let maxIndex = 0;
+
+function publishDepth(): void {
+    historyStore.setDepth(currentIndex > 0, currentIndex < maxIndex);
+}
 
 function recordNavigation(detail: { view: string; [key: string]: any }): void {
-    // `_isBack` is bookkeeping, not destination: keeping it in the entry
-    // would make a replayed navigation claim to be a back-navigation.
-    const { _isBack: _ignored, ...nav } = detail;
-    const state: NavState = { yjNav: nav };
+    // `_isBack` and `_replace` are bookkeeping, not destination: keeping
+    // either in the entry would make a replayed navigation claim to be
+    // one.
+    const { _isBack: _ignored, _replace: replace, ...nav } = detail;
+
+    // Still launching: the configured landing page is not a navigation
+    // *away* from the eager one, it is the same arrival arriving late
+    // (#142). Pushing it left the app one entry deep before the user
+    // had touched anything, so the first back press replayed home over
+    // home -- invisible on desktop until #6 drew a Back button, and on
+    // Android the press that should have exited the app instead did
+    // nothing, because `canGoBack()` was true.
+    //
+    // Guarded on being at the root rather than on a flag, because
+    // `GetDefaultPage()` is a backend call and the user can navigate
+    // while it is in flight: past index 0 this is an ordinary
+    // navigation, or a slow answer would overwrite an entry they made.
+    if (historyStarted && replace && currentIndex === 0) {
+        history.replaceState({ yjNav: nav, yjIdx: 0 }, '');
+        maxIndex = 0;
+        publishDepth();
+
+        return;
+    }
 
     // Same URL, deliberately: the app has no routes, and a path a
     // reload cannot resolve is worse than no path at all.
     if (historyStarted) {
-        history.pushState(state, '');
-        pushedEntries += 1;
+        currentIndex += 1;
+        // Navigating from the middle of the list drops what was ahead
+        // of it -- there is no longer a forward to go to.
+        maxIndex = currentIndex;
+        history.pushState({ yjNav: nav, yjIdx: currentIndex }, '');
     } else {
-        history.replaceState(state, '');
+        currentIndex = 0;
+        maxIndex = 0;
+        history.replaceState({ yjNav: nav, yjIdx: 0 }, '');
         historyStarted = true;
     }
+
+    publishDepth();
 }
 
 window.addEventListener('popstate', (e: PopStateEvent) => {
-    const nav = (e.state as NavState | null)?.yjNav;
+    const state = e.state as NavState | null;
+    const nav = state?.yjNav;
 
     // Before the app's first navigation, or an entry somebody else
     // pushed: nothing to restore, and the activity should be free to
     // finish.
     if (!nav) return;
 
-    pushedEntries = Math.max(0, pushedEntries - 1);
+    // The entry says where it is, so this works in both directions and
+    // across a jump of more than one -- which a long-press on a
+    // browser's back button, and `history.go(-n)`, both produce.
+    // The fallback is for an entry pushed before this numbering
+    // existed; it can only be wrong about a control's disabled state,
+    // never about which view is restored.
+    currentIndex = state?.yjIdx ?? Math.max(0, currentIndex - 1);
+    publishDepth();
 
     void handleNavigate({ ...nav, _isBack: true });
 });
@@ -512,7 +570,18 @@ function schedule(fn: () => void): void {
 // anyway would leave the app: the depth check is what stops a stray
 // `navigate-back` closing it.
 document.addEventListener('navigate-back', () => {
-    if (pushedEntries > 0) history.back();
+    if (currentIndex > 0) history.back();
+});
+
+// Forward: the other half of #6. The stack was always global -- every
+// navigation is an entry and `popstate` restores any of them -- so what
+// was missing is a way to ask for one, and a truthful answer to whether
+// there is one to ask for. It is guarded for the same reason back is:
+// `history.forward()` at the end of the list is silent, so a button
+// that offers it when there is nothing there is a button that does
+// nothing.
+document.addEventListener('navigate-forward', () => {
+    if (currentIndex < maxIndex) history.forward();
 });
 
 // Navigate to the user's configured launch page.  Falls back to 'home'
@@ -522,14 +591,17 @@ GetDefaultPage()
         document.dispatchEvent(new CustomEvent('navigate', {
             bubbles: true,
             composed: true,
-            detail: { view: view || 'home' },
+            // Part of launching, not a navigation away from the eager
+            // 'home' above: it replaces that entry rather than
+            // stacking on it (#142).
+            detail: { view: view || 'home', _replace: true },
         }));
     })
     .catch(() => {
         document.dispatchEvent(new CustomEvent('navigate', {
             bubbles: true,
             composed: true,
-            detail: { view: 'home' },
+            detail: { view: 'home', _replace: true },
         }));
     });
 

frontend/src/assets/icons/fa/solid/arrow-right.svg

@@ -0,0 +1 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 512 512"><!--! Font Awesome Free 7.3.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License) Copyright 2026 Fonticons, Inc. --><path fill="currentColor" d="M502.6 278.6c12.5-12.5 12.5-32.8 0-45.3l-160-160c-12.5-12.5-32.8-12.5-45.3 0s-12.5 32.8 0 45.3L402.7 224 32 224c-17.7 0-32 14.3-32 32s14.3 32 32 32l370.7 0-105.4 105.4c-12.5 12.5-12.5 32.8 0 45.3s32.8 12.5 45.3 0l160-160z"/></svg>

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

@@ -8,6 +8,7 @@ import '../sidebar/app-sidebar.js';
 import { nameDialog } from '@utils/name-dialog';
 import { ICON_PLAYLIST } from '@utils/icon-language';
 import { ActiveViewController } from '@store/controllers/active-view-controller';
+import { ViewVisibilityController } from '@store/controllers/view-visibility-controller';
 
 type View = 'home' | 'albums' | 'tracks' | 'playlists';
 
@@ -129,6 +130,22 @@ export class BottomNav extends LitElement {
      */
     private activeCtrl = new ActiveViewController(this);
 
+    /**
+     * The tab bar honours the sidebar's toggles (#25), and the reason is
+     * inside this component rather than a general rule about phones.
+     * `PHONE_COLUMN_IDS` is the precedent for "what a phone shows is a
+     * different question", and it would apply here too -- except that
+     * "More" opens the *same* `<app-sidebar>`, which filters. An
+     * unfiltered bar would therefore contradict its own drawer, one tap
+     * apart, and a destination the user switched off is off wherever it
+     * is offered.
+     *
+     * Which four tabs remains plan 016's committed subset; this only
+     * removes from it. Hiding all four leaves "More", which is always
+     * present and reaches everything.
+     */
+    private visibilityCtrl = new ViewVisibilityController(this);
+
     /**
      * Whether the drawer has been asked for.
      *
@@ -211,7 +228,9 @@ export class BottomNav extends LitElement {
         return html`
             <nav aria-label="Primary">
                 <ul>
-                    ${BottomNav.TABS.map((tab) => html`
+                    ${BottomNav.TABS
+                        .filter((tab) => this.visibilityCtrl.visible(tab.id))
+                        .map((tab) => html`
                         <li>
                             <button
                                 type="button"

frontend/src/components/config-page/config-page.ts

@@ -27,6 +27,9 @@ import type * as library from '@go/library/models.js';
 import { ThemeController } from '@store/controllers/theme-controller';
 import { TrackListController } from '@store/controllers/tracklist-controller';
 import { FavoritesController } from '@store/controllers/favorites-controller';
+import { ViewVisibilityController } from '@store/controllers/view-visibility-controller';
+import { VIEW_META } from '../../services/view-meta';
+import { downloadStore } from '@store/download-store';
 import { GetAllPlaylists } from '@go/playlist/service.js';
 import type * as playlist from '@go/playlist/models.js';
 import { Events } from '../../events';
@@ -71,6 +74,9 @@ export class ConfigPage extends ViewLifecycleMixin(LitElement) {
     // --- Favorites controller ---
     private favCtrl = new FavoritesController(this);
 
+    /** Which destinations the navigation offers (#25). */
+    private viewsCtrl = new ViewVisibilityController(this);
+
     // --- Shortcuts controller ---
     private shortcutsCtrl = new ShortcutsController(this);
 
@@ -469,6 +475,12 @@ export class ConfigPage extends ViewLifecycleMixin(LitElement) {
             flex: 1;
         }
 
+        .view-note {
+            color: var(--yj-text-tertiary, #888);
+            font-size: var(--yj-font-size-sm, 0.85rem);
+            margin-left: auto;
+        }
+
         .column-arrows {
             display: flex;
             gap: 0.15em;
@@ -1084,6 +1096,25 @@ export class ConfigPage extends ViewLifecycleMixin(LitElement) {
         }
     }
 
+    private handleViewToggle = (
+        view: string,
+        visible: boolean,
+    ): void => {
+        this.viewsCtrl
+            .setVisible(view, visible)
+            .catch((err: unknown) => {
+                console.error('Failed to save view visibility:', err);
+                notificationStore.transient({
+                    key: 'view-visibility',
+                    text: `Could not change which views are shown. ${describeError(err)}`,
+                    detail: String(err),
+                });
+                // The checkbox has already flipped itself; the store is
+                // the truth, so redraw from it.
+                this.requestUpdate();
+            });
+    };
+
     private handleDefaultPageChange = (
         e: CustomEvent<ConfigFieldChangeEvent>,
     ): void => {
@@ -1428,6 +1459,7 @@ export class ConfigPage extends ViewLifecycleMixin(LitElement) {
             -->
             ${this.renderLibrarySection()}
             ${this.renderGeneralSection()}
+            ${this.renderNavigationSection()}
             ${this.renderNowPlayingSection()}
             ${this.renderThemeSection()}
             ${this.renderTrackListSection()}
@@ -1678,6 +1710,79 @@ export class ConfigPage extends ViewLifecycleMixin(LitElement) {
         `;
     }
 
+    // --- Navigation section ---
+
+    /**
+     * Which destinations the sidebar and the phone's tab bar offer.
+     *
+     * Two items are drawn but not editable, and both say why in place
+     * rather than being silently inert. Settings is never hideable --
+     * the backend refuses it too, because `config.toml` is
+     * hand-editable. The launch page is not hideable *while it is the
+     * launch page*, which is a state the user can leave by changing the
+     * launch page above; refusing is preferable to the alternatives,
+     * since resetting their launch page silently changes a second thing
+     * they chose and allowing it lands the app on a page nothing points
+     * at.
+     */
+    private renderNavigationSection() {
+        return html`
+            <config-section
+                heading="Navigation"
+                description="Choose which destinations the sidebar and the phone's tab bar offer. Hiding one does not remove it — links and the launch page still open it."
+            >
+                <ul class="column-list">
+                    ${repeat(VIEW_META, (v) => v.id, (v) => {
+            const checked = this.viewsCtrl.enabled(v.id);
+            const isLaunchPage = this.defaultPage === v.id;
+            const locked = v.alwaysShown === true || isLaunchPage;
+
+            let note = '';
+
+            if (v.alwaysShown === true) {
+                note = 'Always shown.';
+            } else if (isLaunchPage) {
+                note = 'This is the launch page.';
+            } else if (
+                v.id === 'downloads' &&
+                checked &&
+                !downloadStore.available
+            ) {
+                // The config says show it and the nav does not, which
+                // would otherwise read as the checkbox not working.
+                note = 'Hidden until a download client is configured.';
+            }
+
+            return html`
+                            <li
+                                class="column-item ${checked ? 'enabled' : 'disabled'}"
+                            >
+                                <input
+                                    type="checkbox"
+                                    class="column-toggle"
+                                    aria-label="Show ${v.label} in the navigation"
+                                    .checked=${checked}
+                                    ?disabled=${locked}
+                                    @change=${(e: Event) =>
+                    this.handleViewToggle(
+                        v.id,
+                        (e.target as HTMLInputElement).checked,
+                    )}
+                                />
+                                <span class="column-label">
+                                    ${v.label}
+                                </span>
+                                ${note
+                    ? html`<span class="view-note">${note}</span>`
+                    : nothing}
+                            </li>
+                        `;
+        })}
+                </ul>
+            </config-section>
+        `;
+    }
+
     // --- Theme section ---
 
     private renderThemeSection() {

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

@@ -0,0 +1,133 @@
+import { LitElement, html, css } from 'lit';
+import { customElement } from 'lit/decorators.js';
+import '@awesome.me/webawesome/dist/components/icon/icon.js';
+import { designTokens } from '../../styles/tokens.css';
+import { HistoryController } from '@store/controllers/history-controller';
+
+/**
+ * Global back and forward, in the top bar (#6).
+ *
+ * **The stack was already global; the affordance was not.** Every
+ * navigation has been a history entry since the Android back gesture
+ * landed, and `popstate` restores any of them in either direction --
+ * `back-navigation.spec.ts` has asserted `goForward()` since it was
+ * written. What the report describes as "back is tab-scoped" is that
+ * the *only* way back was a detail view's own button, which vanishes
+ * the moment you leave for another tab: the album you were reading is
+ * still one entry away, and nothing on screen says so or offers it.
+ *
+ * Four things about this are load-bearing.
+ *
+ * **It asks the shell rather than the History API.** `history.length`
+ * counts entries this app did not push and never shrinks, and there is
+ * no way to ask where in the list you are -- so a control derived from
+ * it is confidently wrong at both ends. `historyStore` is the shell's
+ * own numbering.
+ *
+ * **A control that cannot act is `disabled`, not hidden.** This is the
+ * one place in the app where that is right rather than the fault
+ * `library-status-indicator` was: back and forward are a *pair* whose
+ * positions the user learns, and a button that disappears at the end
+ * of the list moves the other one under the cursor. It is also what
+ * every browser does, which is the whole design brief here.
+ *
+ * **The buttons dispatch the events the rest of the app already
+ * dispatches**, `navigate-back` and `navigate-forward`, rather than
+ * calling `history.back()` themselves. The shell owns the guard -- one
+ * press is one entry, and at the root there is nothing of ours to go
+ * back to -- and a second caller reaching for `history` directly is
+ * how the old `navStack` came to disagree with the platform.
+ *
+ * **It is desktop chrome.** Below 600px the phone has a system back
+ * gesture (and, on Android, a hardware/gesture Back that this app
+ * hooks), the top bar is 3.25em with three other things in it, and two
+ * more 32px targets there would be the first thing to overflow. Hidden
+ * by `index.css` at that width, next to the rest of the phone header's
+ * concessions.
+ */
+@customElement('nav-history')
+export class NavHistory extends LitElement {
+    private historyCtrl = new HistoryController(this);
+
+    static override styles = [designTokens, css`
+        :host {
+            display: flex;
+            align-items: center;
+            gap: 0.25em;
+            /* A grid item's implicit minimum is its content; this one
+               genuinely cannot shrink, so it says so rather than
+               letting the header widen the body. */
+            flex: 0 0 auto;
+        }
+
+        button {
+            display: flex;
+            align-items: center;
+            justify-content: center;
+            width: 2em;
+            height: 2em;
+            padding: 0;
+            border: none;
+            border-radius: 50%;
+            background: transparent;
+            color: var(--yj-text-primary, #f8f9fa);
+            cursor: pointer;
+            font-size: 1em;
+        }
+
+        button:hover:not(:disabled) {
+            background-color: var(--yj-bg-overlay, #495057);
+        }
+
+        button:focus-visible {
+            outline: 2px solid var(--yj-accent, #ffd43b);
+            outline-offset: 2px;
+        }
+
+        button:disabled {
+            /* Not a contrast failure: a disabled control is exempt from
+               1.4.3, and the pair has to read as unavailable rather
+               than merely quiet. */
+            color: var(--yj-text-tertiary, #868e96);
+            cursor: default;
+        }
+    `];
+
+    private go(direction: 'back' | 'forward') {
+        this.dispatchEvent(new CustomEvent(`navigate-${direction}`, {
+            bubbles: true,
+            composed: true,
+        }));
+    }
+
+    override render() {
+        const { canBack, canForward } = this.historyCtrl.depth;
+
+        return html`
+            <button
+                type="button"
+                data-testid="history-back"
+                aria-label="Back"
+                ?disabled=${!canBack}
+                @click=${() => this.go('back')}
+            >
+                <wa-icon name="arrow-left"></wa-icon>
+            </button>
+            <button
+                type="button"
+                data-testid="history-forward"
+                aria-label="Forward"
+                ?disabled=${!canForward}
+                @click=${() => this.go('forward')}
+            >
+                <wa-icon name="arrow-right"></wa-icon>
+            </button>
+        `;
+    }
+}
+
+declare global {
+    interface HTMLElementTagNameMap {
+        'nav-history': NavHistory;
+    }
+}

frontend/src/components/sidebar/app-sidebar.ts

@@ -5,19 +5,9 @@ import { designTokens } from '../../styles/tokens.css';
 
 import type { DragActiveDetail } from '@utils/drag-controller';
 import { ActiveViewController } from '@store/controllers/active-view-controller';
-import {
-    ICON_PLAYLIST,
-    ICON_AUTOTAG,
-    ICON_REQUESTED,
-} from '@utils/icon-language';
-
-type View = 'home' | 'playlists' | 'artists' | 'genres' | 'albums' | 'tracks' | 'explore' | 'downloads' | 'autotag' | 'jobs' | 'settings';
-
-interface NavItem {
-    id: View;
-    label: string;
-    icon: string;
-}
+import { ViewVisibilityController } from '@store/controllers/view-visibility-controller';
+import { VIEW_META } from '../../services/view-meta';
+import type { View } from '../../services/view-meta';
 
 const MIN_WIDTH = 56;
 const MAX_WIDTH = 400;
@@ -210,19 +200,15 @@ export class AppSidebar extends LitElement {
         typeof setTimeout
     > | null = null;
 
-    private navItems: NavItem[] = [
-        { id: 'home', label: 'Home', icon: 'house' },
-        { id: 'playlists', label: 'Playlists', icon: ICON_PLAYLIST },
-        { id: 'artists', label: 'Artists', icon: 'user-group' },
-        { id: 'genres', label: 'Genres', icon: 'masks-theater' },
-        { id: 'albums', label: 'Albums', icon: 'compact-disc' },
-        { id: 'tracks', label: 'Tracks', icon: 'music' },
-        { id: 'explore', label: 'Explore', icon: 'globe' },
-        { id: 'downloads', label: 'Downloads', icon: ICON_REQUESTED },
-        { id: 'autotag', label: 'Autotag', icon: ICON_AUTOTAG },
-        { id: 'jobs', label: 'Jobs', icon: 'list-check' },
-        { id: 'settings', label: 'Settings', icon: 'gear' },
-    ];
+    /**
+     * Which destinations the user has kept (#25). The list below is
+     * still the whole set and its order -- this only filters it, and
+     * only for drawing: a hidden view is still reachable by `navigate`,
+     * which is what detail views and the launch page depend on.
+     */
+    private visibilityCtrl = new ViewVisibilityController(this);
+
+    private navItems = VIEW_META;
 
     override connectedCallback() {
         super.connectedCallback();
@@ -283,7 +269,9 @@ export class AppSidebar extends LitElement {
             ></div>
             <nav aria-label="Main">
             <ul>
-                ${this.navItems.map((item) => {
+                ${this.navItems
+            .filter((item) => this.visibilityCtrl.visible(item.id))
+            .map((item) => {
             const active = this.activeCtrl.isActive(item.id);
             const classes = [
                 active

frontend/src/icons/names.txt

@@ -19,6 +19,7 @@ regular/heart
 regular/star
 solid/arrow-down-wide-short
 solid/arrow-left
+solid/arrow-right
 solid/arrow-rotate-right
 solid/arrows-rotate
 solid/arrow-up-short-wide

frontend/src/services/keyboard-shortcut-service.ts

@@ -400,6 +400,20 @@ async function dispatch(action: string): Promise<void> {
             break;
         }
 
+        // The keyboard half of #6. It dispatches the same events the
+        // header's buttons and the detail views' own back buttons do,
+        // rather than calling `history.back()` here: the shell owns the
+        // guard that stops a press at the root leaving the app, and a
+        // second caller reaching for `history` directly is how the old
+        // `navStack` came to disagree with the platform.
+        case 'nav.back':
+            document.dispatchEvent(new CustomEvent('navigate-back'));
+            break;
+
+        case 'nav.forward':
+            document.dispatchEvent(new CustomEvent('navigate-forward'));
+            break;
+
         case 'nav.queue': {
             const queuePanel = document.getElementById(
                 'queue-panel',

frontend/src/services/shortcut-meta.ts

@@ -103,6 +103,18 @@ export const SHORTCUT_META: Record<string, ShortcutMeta> = {
             scope: 'global',
             defaultKey: 'Q',
         },
+        'nav.back': {
+            label: 'Back',
+            category: 'Navigation',
+            scope: 'global',
+            defaultKey: 'Alt+Left',
+        },
+        'nav.forward': {
+            label: 'Forward',
+            category: 'Navigation',
+            scope: 'global',
+            defaultKey: 'Alt+Right',
+        },
         'app.shortcuts': {
             label: 'Keyboard Shortcuts',
             category: 'App',

frontend/src/services/view-meta.ts

@@ -0,0 +1,66 @@
+import {
+    ICON_PLAYLIST,
+    ICON_AUTOTAG,
+    ICON_REQUESTED,
+} from '@utils/icon-language';
+
+/** A primary destination. Mirrors `backend/config.View`. */
+export type View =
+    | 'home'
+    | 'playlists'
+    | 'artists'
+    | 'genres'
+    | 'albums'
+    | 'tracks'
+    | 'explore'
+    | 'downloads'
+    | 'autotag'
+    | 'jobs'
+    | 'settings';
+
+export interface ViewMeta {
+    id: View;
+    label: string;
+    icon: string;
+    /**
+     * Views that are never offered as a toggle. Settings alone, because
+     * a user who hides it cannot get back to unhide it.
+     *
+     * This is the *affordance*; the rule is `backend/config.ViewSpec`'s
+     * `Hideable`, which refuses at the setter and drops the key on load.
+     * `config.toml` is hand-editable, so the checkbox being absent is
+     * not what makes this safe — it is only what stops the question
+     * being asked.
+     */
+    alwaysShown?: boolean;
+}
+
+/**
+ * The app's primary destinations, in the order the navigation draws
+ * them and Settings lists them.
+ *
+ * It is here rather than inside `app-sidebar` because #25 gave it a
+ * second reader: Settings renders a toggle per view and needs the same
+ * labels in the same order. Same shape as `services/shortcut-meta.ts`,
+ * which moved out of `config-page` for the same reason -- a private
+ * static that two surfaces need is a private static that is about to be
+ * copied.
+ *
+ * The labels and icons deliberately do not exist in Go. Which views
+ * exist and what an unconfigured install shows is `backend/config.Views`
+ * and is asked for over the binding; how they are *drawn* is the
+ * frontend's, and lives beside the rest of the icon vocabulary.
+ */
+export const VIEW_META: ViewMeta[] = [
+    { id: 'home', label: 'Home', icon: 'house' },
+    { id: 'playlists', label: 'Playlists', icon: ICON_PLAYLIST },
+    { id: 'artists', label: 'Artists', icon: 'user-group' },
+    { id: 'genres', label: 'Genres', icon: 'masks-theater' },
+    { id: 'albums', label: 'Albums', icon: 'compact-disc' },
+    { id: 'tracks', label: 'Tracks', icon: 'music' },
+    { id: 'explore', label: 'Explore', icon: 'globe' },
+    { id: 'downloads', label: 'Downloads', icon: ICON_REQUESTED },
+    { id: 'autotag', label: 'Autotag', icon: ICON_AUTOTAG },
+    { id: 'jobs', label: 'Jobs', icon: 'list-check' },
+    { id: 'settings', label: 'Settings', icon: 'gear', alwaysShown: true },
+];

frontend/src/store/controllers/history-controller.ts

@@ -0,0 +1,40 @@
+import type {
+    ReactiveController,
+    ReactiveControllerHost,
+} from 'lit';
+import { historyStore, type HistoryDepth } from '../history-store';
+
+/**
+ * HistoryController connects a Lit component to the HistoryStore.
+ *
+ * Usage in a component:
+ *
+ *   private historyCtrl = new HistoryController(this);
+ *
+ *   render() {
+ *     const { canBack } = this.historyCtrl.depth;
+ *   }
+ */
+export class HistoryController implements ReactiveController {
+    private host: ReactiveControllerHost;
+    private unsubscribe?: () => void;
+
+    constructor(host: ReactiveControllerHost) {
+        this.host = host;
+        host.addController(this);
+    }
+
+    hostConnected(): void {
+        this.unsubscribe = historyStore.subscribe(() => {
+            this.host.requestUpdate();
+        });
+    }
+
+    hostDisconnected(): void {
+        this.unsubscribe?.();
+    }
+
+    get depth(): HistoryDepth {
+        return historyStore.get();
+    }
+}

frontend/src/store/controllers/view-visibility-controller.ts

@@ -0,0 +1,54 @@
+import type {
+    ReactiveController,
+    ReactiveControllerHost,
+} from 'lit';
+import { viewVisibilityStore } from '../view-visibility-store';
+
+/**
+ * ViewVisibilityController connects a Lit component to the
+ * ViewVisibilityStore.
+ *
+ * It reads through to the store rather than copying the map into a
+ * `@state()` field, for the reason `ActiveViewController` does: there
+ * are two live `<app-sidebar>` instances the moment `bottom-nav`'s
+ * "More" drawer opens, and two components holding their own idea of
+ * which destinations exist is how they come to disagree.
+ */
+export class ViewVisibilityController implements ReactiveController {
+    private host: ReactiveControllerHost;
+    private unsubscribe?: () => void;
+
+    constructor(host: ReactiveControllerHost) {
+        this.host = host;
+        host.addController(this);
+    }
+
+    hostConnected(): void {
+        this.unsubscribe = viewVisibilityStore.subscribe(() => {
+            this.host.requestUpdate();
+        });
+
+        void viewVisibilityStore.init();
+    }
+
+    hostDisconnected(): void {
+        this.unsubscribe?.();
+    }
+
+    /** Whether the navigation should offer this destination. */
+    visible(view: string): boolean {
+        return viewVisibilityStore.visible(view);
+    }
+
+    /**
+     * What the config says, ignoring the download-client gate — the
+     * state Settings' own checkbox shows.
+     */
+    enabled(view: string): boolean {
+        return viewVisibilityStore.enabled(view);
+    }
+
+    setVisible(view: string, visible: boolean): Promise<void> {
+        return viewVisibilityStore.setVisible(view, visible);
+    }
+}

frontend/src/store/download-store.ts

@@ -189,6 +189,8 @@ class DownloadStore {
 
     private initialized = false;
 
+    private providersLoaded = false;
+
     constructor() {
         EventsOn(Events.DownloadProvidersChanged, () => {
             void this.refreshProviders();
@@ -285,6 +287,25 @@ class DownloadStore {
         }
     }
 
+    /**
+     * Loads the providers, and only those, once.
+     *
+     * `init()` additionally fetches the descriptors, the downloads and
+     * the request list, which is right for a page about downloading and
+     * wrong for the sidebar: it only needs `available`, to decide
+     * whether the Downloads destination exists at all (#25), and that
+     * is one query. `DownloadProvidersChanged` keeps it current
+     * afterwards, so configuring a client makes the tab appear without
+     * a restart.
+     */
+    async ensureProviders(): Promise<void> {
+        if (this.providersLoaded) return;
+
+        this.providersLoaded = true;
+
+        await this.refreshProviders();
+    }
+
     async refreshProviders(): Promise<void> {
         try {
             this.providersValue = (await ListProviders()) ?? [];

frontend/src/store/history-store.ts

@@ -0,0 +1,66 @@
+/**
+ * How far the session can go back and forward.
+ *
+ * The History API exposes `length` and nothing useful: it counts
+ * entries the app did not push, does not say where in the list the
+ * current entry is, and `popstate` fires *identically* whether the
+ * user went back or forward. So a control that wants to grey itself
+ * out has to be told, and the shell is the only thing in a position to
+ * know (#6).
+ *
+ * Two rules follow from how the shell counts, and both are the reason
+ * this is a pair of booleans rather than one depth:
+ *
+ * **Forward is not "back, negated".** `pushedEntries` -- the counter
+ * this replaces -- decremented on every `popstate`, which made a
+ * forward navigation look like a second back. The shell keeps an index
+ * per entry and a high-water mark instead, and publishes the two
+ * answers rather than the arithmetic.
+ *
+ * **Back stops at the app's own floor.** The launch entry is
+ * *replaced*, not pushed, so that one back press from the root exits
+ * the app on Android; `canBack` is false there, which is what stops
+ * the header's own button being the thing that quits.
+ */
+
+type Subscriber = () => void;
+
+export interface HistoryDepth {
+    canBack: boolean;
+    canForward: boolean;
+}
+
+class HistoryStore {
+    private depth: HistoryDepth = { canBack: false, canForward: false };
+
+    private subscribers = new Set<Subscriber>();
+
+    get(): HistoryDepth {
+        return this.depth;
+    }
+
+    /** Called by the shell whenever an entry is pushed or restored. */
+    setDepth(canBack: boolean, canForward: boolean): void {
+        if (
+            canBack === this.depth.canBack &&
+            canForward === this.depth.canForward
+        ) {
+            return;
+        }
+
+        this.depth = { canBack, canForward };
+        this.notify();
+    }
+
+    subscribe(fn: Subscriber): () => void {
+        this.subscribers.add(fn);
+
+        return () => this.subscribers.delete(fn);
+    }
+
+    private notify(): void {
+        this.subscribers.forEach((fn) => fn());
+    }
+}
+
+export const historyStore = new HistoryStore();

frontend/src/store/index.ts

@@ -11,6 +11,9 @@ export { searchStore } from './search-store';
 export { SearchController } from './controllers/search-controller';
 export { activeViewStore } from './active-view-store';
 export { ActiveViewController } from './controllers/active-view-controller';
+export { historyStore } from './history-store';
+export type { HistoryDepth } from './history-store';
+export { HistoryController } from './controllers/history-controller';
 export { shortcutsStore } from './shortcuts-store';
 export type { ShortcutsState } from './shortcuts-store';
 export { ShortcutsController } from './controllers/shortcuts-controller';

frontend/src/store/view-visibility-store.ts

@@ -0,0 +1,119 @@
+import { EventsOn } from '@runtime/runtime';
+import { GetViewVisibility, SetViewVisible } from '@go/config/config.js';
+import { dictByName } from '@utils/binding';
+import { downloadStore } from './download-store';
+import { Events } from '../events';
+
+type Subscriber = () => void;
+
+/**
+ * Which primary destinations the navigation offers.
+ *
+ * Eleven sidebar entries is more than most libraries need, so #25 makes
+ * them individually toggleable. Three rules about this are load-bearing.
+ *
+ * **Hidden is not unreachable.** This decides what the *nav* draws and
+ * nothing else: `navigate` still resolves a hidden view, which is not a
+ * nicety — detail views navigate into these, and the shell's launch
+ * page is one of them. Nothing here needs a special case for the
+ * highlight either, because #72 moved that onto `active-view-store`:
+ * `app-sidebar` asks `isActive(id)` per *rendered* item, so a hidden
+ * view lights nothing exactly as a detail view does.
+ *
+ * **The defaults live in Go**, in `backend/config.Views`, and this asks
+ * for the *resolved* answer rather than the stored map. A config that
+ * says nothing about a view means "that view's own default", so a copy
+ * of the defaults here would be a second thing to keep in step — and
+ * the one that shipped in the artifact, not the one being edited.
+ *
+ * **Downloads is a second question**, answered by the download client
+ * rather than by the config: a destination for a feature that cannot
+ * work is worse than an absent one. It is gated at `visible()` and not
+ * in the config, so switching it on in Settings still means what it
+ * says once a client exists. `available` is false until the providers
+ * have loaded, which makes the tab *appear* on a fresh launch rather
+ * than appearing and then vanishing — the less jarring half of a race
+ * that resolves in one query.
+ */
+class ViewVisibilityStore {
+    /** The backend's resolved answer, empty until the first load. */
+    private configured: Record<string, boolean> = {};
+
+    private loaded = false;
+
+    private subscribers = new Set<Subscriber>();
+
+    constructor() {
+        EventsOn(Events.GeneralConfigChanged, () => {
+            void this.refresh();
+        });
+
+        // A client configured later has to add the destination without a
+        // restart -- #37's rule, one surface over.
+        downloadStore.subscribe(() => this.notify());
+    }
+
+    /** Loads the visibility map once. Safe to call from every mount. */
+    async init(): Promise<void> {
+        if (this.loaded) return;
+
+        this.loaded = true;
+
+        await Promise.all([
+            this.refresh(),
+            downloadStore.ensureProviders(),
+        ]);
+    }
+
+    /**
+     * Whether the navigation should offer this destination.
+     *
+     * An unknown id is visible: the caller is drawing it from its own
+     * list, and a view this store has not heard of (or has not loaded
+     * yet) is better shown than silently dropped.
+     */
+    visible(view: string): boolean {
+        if (view === 'downloads' && !downloadStore.available) return false;
+
+        return this.configured[view] ?? true;
+    }
+
+    /**
+     * What the *config* says, ignoring the download-client gate — which
+     * is what Settings' own checkbox has to show, or a user with no
+     * client would see Downloads switched off and be unable to switch
+     * it on.
+     */
+    enabled(view: string): boolean {
+        return this.configured[view] ?? true;
+    }
+
+    async setVisible(view: string, visible: boolean): Promise<void> {
+        await SetViewVisible(view, visible);
+
+        // The backend emits GeneralConfigChanged, but the caller is
+        // owed the new state by the time this resolves.
+        await this.refresh();
+    }
+
+    subscribe(fn: Subscriber): () => void {
+        this.subscribers.add(fn);
+
+        return () => this.subscribers.delete(fn);
+    }
+
+    private async refresh(): Promise<void> {
+        try {
+            this.configured = await dictByName(GetViewVisibility());
+            this.notify();
+        } catch (err) {
+            console.error('Failed to load view visibility:', err);
+        }
+    }
+
+    private notify(): void {
+        this.subscribers.forEach((fn) => fn());
+    }
+}
+
+export const viewVisibilityStore = new ViewVisibilityStore();

frontend/test/components/chrome.test.ts

@@ -26,7 +26,26 @@ import {
   ICON_REQUESTED,
 } from '@utils/icon-language';
 
+/** A configured, enabled download client. */
+const PROVIDER = {
+  id: 1,
+  kind: 'slskd',
+  name: 'Sound',
+  enabled: true,
+  priority: 50,
+};
+
 describe('<app-sidebar>', () => {
+  // Downloads is offered only where there is a client to download with
+  // (#25), so "all eleven destinations" is a statement about a
+  // configured install. `view-visibility.test.ts` owns the rule itself;
+  // this states the world these cases are describing.
+  beforeEach(async () => {
+    stub('download.Service.ListProviders', [PROVIDER]);
+    emit(Events.DownloadProvidersChanged);
+    await flush();
+  });
+
   it('renders a testid per destination, which is how e2e navigates', async () => {
     const el = await fixture('app-sidebar');
 

frontend/test/components/keyboard-reach.test.ts

@@ -11,7 +11,8 @@ import { describe, expect, it, beforeEach } from 'vitest';
 import '@components/sidebar/app-sidebar';
 import '@components/queue-panel/queue-panel';
 import '@components/track-list/track-list';
-import { stub } from '@test/support/harness';
+import { stub, emit, flush } from '@test/support/harness';
+import { Events } from '../../src/events';
 import { fixture, shadow, shadowAll, update } from '@test/support/render';
 
 /** Two fixture tracks, enough to move a focus ring between. */
@@ -33,6 +34,16 @@ const TRACKS = [
 ] as never[];
 
 describe('<app-sidebar> is reachable', () => {
+  // Eleven destinations assumes a configured download client, since
+  // Downloads is not offered without one (#25).
+  beforeEach(async () => {
+    stub('download.Service.ListProviders', [
+      { id: 1, kind: 'slskd', name: 'Sound', enabled: true, priority: 50 },
+    ]);
+    emit(Events.DownloadProvidersChanged);
+    await flush();
+  });
+
   it('renders every destination as a button, not a bare list item', async () => {
     const el = await fixture('app-sidebar');
 

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

@@ -0,0 +1,91 @@
+/**
+ * The global back/forward control (#6).
+ *
+ * The interesting half of this component is what it does when it
+ * *cannot* act. The app's rule is that a control which cannot do
+ * anything should not be a button at all — `library-status-indicator`
+ * spent a release as a `<button>` whose handler was a comment — and
+ * this is the documented exception: back and forward are a pair whose
+ * positions the user learns, so the unavailable one greys out rather
+ * than disappearing and moving the other one under the cursor.
+ */
+import { describe, expect, it, beforeEach } from 'vitest';
+
+import '@components/nav-history/nav-history';
+import { fixture, shadow, update } from '@test/support/render';
+import { historyStore } from '@store/history-store';
+
+const back = (el: HTMLElement) =>
+  shadow<HTMLButtonElement>(el, '[data-testid="history-back"]');
+
+const forward = (el: HTMLElement) =>
+  shadow<HTMLButtonElement>(el, '[data-testid="history-forward"]');
+
+describe('nav-history', () => {
+  beforeEach(() => {
+    historyStore.setDepth(false, false);
+  });
+
+  it('offers both directions, named', async () => {
+    const el = await fixture('nav-history');
+
+    // The name is the whole control: two arrows side by side are
+    // indistinguishable to anything not looking at them.
+    expect(back(el)?.getAttribute('aria-label')).toBe('Back');
+    expect(forward(el)?.getAttribute('aria-label')).toBe('Forward');
+  });
+
+  it('disables what cannot be done, in both directions independently', async () => {
+    const el = await fixture('nav-history');
+
+    expect(back(el)?.disabled).toBe(true);
+    expect(forward(el)?.disabled).toBe(true);
+
+    historyStore.setDepth(true, false);
+    await update(el, {});
+
+    expect(back(el)?.disabled).toBe(false);
+    expect(forward(el)?.disabled).toBe(true);
+
+    // Standing in the middle of the list, which is what a back press
+    // followed by a look at the toolbar produces.
+    historyStore.setDepth(true, true);
+    await update(el, {});
+
+    expect(back(el)?.disabled).toBe(false);
+    expect(forward(el)?.disabled).toBe(false);
+  });
+
+  it('asks the shell rather than reaching for history itself', async () => {
+    const el = await fixture('nav-history');
+    const seen: string[] = [];
+
+    for (const name of ['navigate-back', 'navigate-forward']) {
+      document.addEventListener(name, () => seen.push(name));
+    }
+
+    historyStore.setDepth(true, true);
+    await update(el, {});
+
+    back(el)?.click();
+    forward(el)?.click();
+
+    // Composed and bubbling, or index.ts's document listener — which
+    // owns the guard that stops a press at the root leaving the app —
+    // never hears them. A second caller reaching for `history`
+    // directly is how the old `navStack` came to disagree with the
+    // platform.
+    expect(seen).toEqual(['navigate-back', 'navigate-forward']);
+  });
+
+  it('says nothing when it cannot act', async () => {
+    const el = await fixture('nav-history');
+    const seen: string[] = [];
+
+    document.addEventListener('navigate-back', () => seen.push('back'));
+
+    back(el)?.click();
+
+    expect(seen).toEqual([]);
+  });
+});

frontend/test/components/view-visibility.test.ts

@@ -0,0 +1,191 @@
+/**
+ * Which destinations the navigation offers (#25).
+ *
+ * Eleven sidebar entries is more than most libraries need, so they are
+ * individually toggleable. The assertions here are about the **nav**
+ * and not about the setting being saved: "the config was written" is
+ * the plumbing, and a spec that measures the plumbing is how #69 and
+ * #72 both shipped green on a broken build.
+ *
+ * Two singletons make ordering matter, and both are driven the way the
+ * app drives them rather than reset: `GeneralConfigChanged` is what the
+ * backend emits when a toggle is saved, and `DownloadProvidersChanged`
+ * is what it emits when a client is configured. So each case states the
+ * world it wants and is independent of which one ran first.
+ */
+import { describe, expect, it, beforeEach } from 'vitest';
+
+import '@components/sidebar/app-sidebar';
+import '@components/bottom-nav/bottom-nav';
+import { activeViewStore } from '@store/active-view-store';
+import { stub, emit, flush, resetHarness } from '@test/support/harness';
+import { Events } from '../../src/events';
+import { fixture, shadowAll } from '@test/support/render';
+import type { LitElement } from 'lit';
+
+const PROVIDER = {
+  id: 1,
+  kind: 'slskd',
+  name: 'Sound',
+  enabled: true,
+  priority: 50,
+};
+
+/** Every view id the sidebar is currently drawing, in order. */
+const navIDs = (el: HTMLElement) =>
+  shadowAll<HTMLButtonElement>(el, 'nav button')
+    .map((b) => b.dataset.testid?.replace(/^nav-/, ''))
+    .filter((id): id is string => id !== undefined);
+
+const tabIDs = (el: HTMLElement) =>
+  shadowAll<HTMLButtonElement>(el, 'nav button')
+    .map((b) => b.dataset.testid?.replace(/^tab-/, ''))
+    .filter((id): id is string => id !== undefined);
+
+/**
+ * State the backend's resolved answer and push the event that says it
+ * changed. The map is *resolved* — every known view, defaults already
+ * applied — because that is what the binding returns and the whole
+ * reason the frontend holds no copy of the defaults.
+ */
+async function setViews(views: Record<string, boolean>): Promise<void> {
+  stub('config.Config.GetViewVisibility', views);
+  emit(Events.GeneralConfigChanged, {});
+  await flush();
+  await flush();
+}
+
+async function setClientConfigured(configured: boolean): Promise<void> {
+  stub('download.Service.ListProviders', configured ? [PROVIDER] : []);
+  emit(Events.DownloadProvidersChanged);
+  await flush();
+  await flush();
+}
+
+const ALL_VISIBLE = {
+  home: true,
+  playlists: true,
+  artists: true,
+  genres: true,
+  albums: true,
+  tracks: true,
+  explore: true,
+  downloads: true,
+  autotag: true,
+  jobs: true,
+  settings: true,
+};
+
+describe('view visibility', () => {
+  beforeEach(async () => {
+    resetHarness();
+    await setViews(ALL_VISIBLE);
+    await setClientConfigured(true);
+  });
+
+  it('draws every destination the config keeps', async () => {
+    const el = await fixture<LitElement>('app-sidebar');
+
+    expect(navIDs(el)).toEqual([
+      'home',
+      'playlists',
+      'artists',
+      'genres',
+      'albums',
+      'tracks',
+      'explore',
+      'downloads',
+      'autotag',
+      'jobs',
+      'settings',
+    ]);
+  });
+
+  it('drops the ones the user switched off', async () => {
+    const el = await fixture<LitElement>('app-sidebar');
+
+    await setViews({ ...ALL_VISIBLE, autotag: false, jobs: false });
+    await el.updateComplete;
+
+    expect(navIDs(el)).not.toContain('autotag');
+    expect(navIDs(el)).not.toContain('jobs');
+    expect(navIDs(el)).toContain('settings');
+  });
+
+  /**
+   * Hiding is about the nav item, not about the view. Detail views
+   * navigate into these and the launch page is one of them, so the
+   * shell's own statement of where the user is has to survive a
+   * destination that draws no item — and it does so with no special
+   * case here, because #72 moved the highlight onto `active-view-store`
+   * and this only filters what is rendered.
+   */
+  it('lights nothing when the active view is a hidden one', async () => {
+    const el = await fixture<LitElement>('app-sidebar');
+
+    await setViews({ ...ALL_VISIBLE, autotag: false });
+    activeViewStore.setView('autotag', true);
+    await el.updateComplete;
+
+    const lit = shadowAll<HTMLButtonElement>(el, 'nav button')
+      .filter((b) => b.getAttribute('aria-current') === 'page');
+
+    expect(lit).toHaveLength(0);
+    expect(navIDs(el)).not.toContain('autotag');
+
+    activeViewStore.setView('albums', true);
+  });
+
+  /**
+   * A destination for a feature that cannot work is worse than an
+   * absent one, so Downloads asks the download client rather than the
+   * config — and it appears when one is configured, without a restart
+   * (#37's rule, one surface over).
+   */
+  it('hides Downloads until a client is configured', async () => {
+    const el = await fixture<LitElement>('app-sidebar');
+
+    await setClientConfigured(false);
+    await el.updateComplete;
+
+    expect(navIDs(el)).not.toContain('downloads');
+
+    await setClientConfigured(true);
+    await el.updateComplete;
+
+    expect(navIDs(el)).toContain('downloads');
+  });
+
+  /**
+   * The tab bar honours the toggles too, and the reason is local: its
+   * "More" drawer opens the same `<app-sidebar>`, which filters. An
+   * unfiltered bar would contradict its own drawer one tap away.
+   */
+  it('drops a hidden destination from the phone tab bar', async () => {
+    const el = await fixture<LitElement>('bottom-nav');
+
+    expect(tabIDs(el)).toEqual(['home', 'albums', 'tracks', 'playlists', 'more']);
+
+    await setViews({ ...ALL_VISIBLE, albums: false });
+    await el.updateComplete;
+
+    expect(tabIDs(el)).toEqual(['home', 'tracks', 'playlists', 'more']);
+  });
+
+  /** "More" is not a destination and is never filtered away: it is how
+   *  everything else is still reachable. */
+  it('keeps More when every tab is hidden', async () => {
+    const el = await fixture<LitElement>('bottom-nav');
+
+    await setViews({
+      ...ALL_VISIBLE,
+      home: false,
+      albums: false,
+      tracks: false,
+      playlists: false,
+    });
+    await el.updateComplete;
+
+    expect(tabIDs(el)).toEqual(['more']);
+  });
+});

frontend/test/stores/view-stores.test.ts

@@ -8,6 +8,7 @@ import { describe, expect, it, beforeEach } from 'vitest';
 
 import { searchStore } from '@store/search-store';
 import { activeViewStore } from '@store/active-view-store';
+import { historyStore } from '@store/history-store';
 import { trackListStore } from '@store/tracklist-store';
 import { exploreCache, ARTIST_IMAGE_CACHE_LIMIT } from '@store/explore-cache';
 import { Events } from '../../src/events';
@@ -133,6 +134,46 @@ describe('active view store', () => {
   });
 });
 
+describe('history store', () => {
+  beforeEach(() => {
+    historyStore.setDepth(false, false);
+  });
+
+  it('holds both answers, because forward is not back negated', () => {
+    historyStore.setDepth(true, false);
+
+    expect(historyStore.get()).toEqual({ canBack: true, canForward: false });
+
+    // The middle of the list: both directions available at once, which
+    // a single depth counter cannot express and which is the state the
+    // old `pushedEntries` got wrong.
+    historyStore.setDepth(true, true);
+
+    expect(historyStore.get()).toEqual({ canBack: true, canForward: true });
+  });
+
+  it('does not notify when neither answer changed', () => {
+    let notifications = 0;
+    const off = historyStore.subscribe(() => {
+      notifications += 1;
+    });
+
+    historyStore.setDepth(true, true);
+    historyStore.setDepth(true, true);
+    off();
+
+    expect(notifications).toBe(1);
+  });
+
+  it('starts with both unavailable, which is the truth at launch', () => {
+    // A fresh session is one entry deep and that entry is *replaced*,
+    // not pushed, so there is nothing of ours behind it. A control
+    // that assumed otherwise would offer a press that does nothing --
+    // and on Android, one the OS would have used to exit the app.
+    expect(historyStore.get()).toEqual({ canBack: false, canForward: false });
+  });
+});
+
 describe('track list store', () => {
   it('starts from the default column set', () => {
     expect(trackListStore.getState().columnIds.length).toBeGreaterThan(0);