diff --git a/openspec/changes/archive/2026-09-11-mobile-virtual-keyboard-control/.openspec.yaml b/openspec/changes/archive/2026-09-11-mobile-virtual-keyboard-control/.openspec.yaml
new file mode 100644
index 0000000..515eaae
--- /dev/null
+++ b/openspec/changes/archive/2026-09-11-mobile-virtual-keyboard-control/.openspec.yaml
@@ -0,0 +1,2 @@
+schema: spec-driven
+created: 2026-09-11
diff --git a/openspec/changes/archive/2026-09-11-mobile-virtual-keyboard-control/design.md b/openspec/changes/archive/2026-09-11-mobile-virtual-keyboard-control/design.md
new file mode 100644
index 0000000..6bee2fe
--- /dev/null
+++ b/openspec/changes/archive/2026-09-11-mobile-virtual-keyboard-control/design.md
@@ -0,0 +1,150 @@
+## Context
+
+`AnswerInput.vue` holds a plain `<input>` that the app auto-focuses on mount
+and that the on-screen `OnScreenKeyboard.vue` writes into (see
+`openspec/specs/typing-practice/spec.md` — "On-screen keyboard for the
+exercise's language"). On a touchscreen, focusing any `<input>` is the
+browser's own trigger for the OS virtual keyboard; the app has never
+suppressed it because the desktop/laptop case this was built for (see "The
+exercise fits on one screen") has no virtual keyboard to suppress. There is no
+device-classification, settings, or persistence code anywhere in the frontend
+yet — this change introduces all three.
+
+## Goals / Non-Goals
+
+**Goals:**
+- Keep the OS virtual keyboard off the answer field by default on phones.
+- Leave it available by default everywhere else, since a connected physical
+  keyboard cannot be detected.
+- Give the learner a persistent, explicit override in both directions.
+- Keep the on-screen keyboard's own control reachable on a phone-sized
+  screen, and let the learner hide that board entirely.
+
+**Non-Goals:**
+- General responsive layout for small screens beyond the keyboard board
+  itself (the "fits on one screen" requirement is still laptop-scoped;
+  reflowing the exercise column or the sentence's type scale for narrow
+  viewports is separate work). The keyboard board's own overflow is
+  in scope below — it turned out to block the override control's own
+  reachability during e2e verification, not just a cosmetic gap.
+- Detecting a physical keyboard directly — no browser API exposes this, which
+  is precisely why an explicit override exists.
+- A general settings panel/infrastructure beyond what these two settings
+  need — no accounts, no server-side sync, no third setting speculatively
+  added.
+
+## Decisions
+
+### Suppress via `inputmode="none"`, not `readonly` or a hidden proxy input
+Setting the field's `inputmode` attribute to `"none"` tells the browser not to
+draw its virtual keyboard on focus, while the field stays focused, editable,
+and still receives physical key events — because `inputmode` only hints at
+which virtual keyboard to show, it does not disable input. `readonly` was
+considered and rejected: it also blocks physical keyboard input and caret
+placement, which would break the "physical keyboard also works" scenario
+already in the spec. A hidden/offscreen proxy input was considered and
+rejected as needless complexity — `v-model`, `@keyup.enter`, and the visible
+caret all keep working unchanged with `inputmode` alone.
+
+`inputmode` becomes a computed property on the input, driven by whichever of
+the two settings states below is active.
+
+### Two independent pieces of state: device classification and override
+1. **Device classification** (`phone` vs. not) is computed, not stored — a
+   small composable reads it live from `matchMedia`, so it reacts if the
+   viewport or input mode changes (e.g. rotating a phone, or a tablet
+   docking a keyboard, changes `hover`/`pointer` on some platforms).
+   Classification rule: `(max-width: 640px)` — Tailwind's own `sm` breakpoint,
+   already the project's small-screen line — **and** `(hover: none) and
+   (pointer: coarse)`, i.e. touch-primary with no mouse/trackpad. Both must
+   hold; a narrow desktop window with a mouse is not a phone.
+2. **Override** is a tri-state value — `auto` (default), `on`, `off` — held in
+   a small Pinia store and mirrored to `localStorage` under one key, read
+   once at store creation and written on every change. `auto` means "follow
+   classification"; `on`/`off` force the `inputmode` regardless of it.
+
+Keeping these separate (rather than collapsing to one persisted boolean)
+means a learner who never touches the setting keeps getting the
+device-appropriate default even if they later switch devices with the same
+browser profile — `localStorage` is per-origin-per-browser, not per-device,
+so a forced boolean would follow them somewhere it no longer applies.
+
+### Settings control placement: a header menu, not the keyboard's bottom bar
+Tried first as a pill in `OnScreenKeyboard.vue`'s existing bottom bar
+(alongside the layout switch and finger legend). Phone-width e2e
+verification (Playwright, `hasTouch`/`isMobile` emulation) caught what a
+static mockup didn't: at 390px the bar is already tight, and the pill was
+genuinely unclickable — other elements physically overlapped it. Rather than
+fight that bar for space, both settings moved to a small popover menu off a
+gear icon in the app header (`SettingsMenu.vue`), positioned
+absolutely so it costs the header row no height on any viewport (`App.vue`'s
+title row must stay short — see "The exercise fits on one screen"). This
+also gave the second setting (below) a natural home instead of a second
+crowded pill.
+
+### The on-screen keyboard scrolls sideways rather than shrinking
+`OnScreenKeyboard.vue`'s panel was `w-[var(--board)]`, a fixed width; below
+that width the whole page grew wider than the viewport instead of the panel
+adapting. Shrinking every key to fit was rejected — a key below a tappable
+size defeats the board's whole point, and there is no width where a
+13-column row shrinks to fit a phone and stays tappable. Instead: the panel
+is now `w-full max-w-[var(--board)]` (shrinks with the viewport, matching
+`AnswerInput.vue`'s column), and inside it the rows + space bar sit in an
+`overflow-x-auto` wrapper at their full, unshrunk width — so on any viewport
+narrower than `--board` the keys stay true size and the learner scrolls
+sideways to reach the rest, the way they would scroll any wide content on a
+touch device. The bottom bar (legend + layout switch) sits outside that
+scroll wrapper, so it never scrolls out of reach itself; the legend also
+gained `flex-wrap` for narrow panels.
+
+### A second, independent setting: hide the on-screen keyboard
+Once a learner is typing on a physical keyboard they already know work, the
+board is a lot of screen for a hint they are not using — a plain "hide it"
+option, not tied to the virtual-keyboard override (that one is about the
+*OS* keyboard; this one is about *this app's own* board). Held as a second
+field, `onScreenKeyboardVisible`, on the same settings store, defaulting to
+shown and persisted the same way. `SentenceView.vue` wraps
+`<OnScreenKeyboard>` in `v-if`, not `v-show`: the board holds no state worth
+preserving while hidden (its layer and scroll position reset the same way a
+new exercise already resets them), so mounting fresh on re-show costs
+nothing and is simpler than tracking what to reset by hand.
+
+### Where the logic lives
+- `src/frontend/src/lib/device.js`: the `matchMedia`-backed
+  phone-classification composable/helper, unit-testable by mocking
+  `matchMedia` the way the existing `lib/keyboard` tests mock their inputs.
+- `src/frontend/src/stores/settings.js`: the Pinia store holding both
+  settings, their `localStorage` keys, and a computed `virtualKeyboardEnabled`
+  that combines the override + classification into the boolean
+  `AnswerInput.vue` needs.
+- `AnswerInput.vue`: binds `:inputmode` to `store.virtualKeyboardEnabled ?
+  'text' : 'none'`.
+- `SettingsMenu.vue` (new): the header's gear button and its popover, reading
+  and writing both settings.
+- `OnScreenKeyboard.vue`: the `overflow-x-auto` scroll wrapper; no longer
+  holds any settings-control markup itself.
+- `SentenceView.vue`: `v-if`s the board on `onScreenKeyboardVisible`.
+
+## Risks / Trade-offs
+
+- **Classification is a heuristic and will misjudge some devices** (e.g. a
+  large phone above 640px, or a small tablet at 640px in portrait) → this is
+  exactly what the override exists for; the proposal treats the override as a
+  first-class requirement rather than an escape hatch, and the design keeps
+  the default in the "safer to leave the keyboard available" direction for
+  anything not confidently phone-sized.
+- **`inputmode="none"` support varies slightly across mobile browsers**
+  (notably some older WebKit versions honored it inconsistently) → the
+  override lets an affected learner switch it back on if suppression fails to
+  behave, and lets one switch it off if a browser shows the virtual keyboard
+  despite `inputmode="none"`; no feature detection is added since there is
+  nothing reliable to detect.
+- **`localStorage` can be unavailable** (private browsing in some browsers,
+  storage disabled) → reads/writes are wrapped so a failure falls back to the
+  in-memory default (`auto`) for that session rather than throwing.
+
+## Migration Plan
+
+Additive, frontend-only change with no persisted server data and no schema.
+Ships as a normal frontend deploy; nothing to migrate or roll back beyond
+reverting the commit if the heuristic proves wrong in practice.
diff --git a/openspec/changes/archive/2026-09-11-mobile-virtual-keyboard-control/proposal.md b/openspec/changes/archive/2026-09-11-mobile-virtual-keyboard-control/proposal.md
new file mode 100644
index 0000000..18469c8
--- /dev/null
+++ b/openspec/changes/archive/2026-09-11-mobile-virtual-keyboard-control/proposal.md
@@ -0,0 +1,60 @@
+## Why
+
+On a phone, focusing the answer field pops up the OS's virtual keyboard on top
+of the app's own on-screen Kedmanee keyboard — two keyboards fighting for the
+same screen, with the OS one usually covering the on-screen one entirely. A
+phone has no physical keyboard, so the virtual keyboard adds nothing the
+on-screen board doesn't already provide, and should stay down. A tablet is a
+harder case: some are typed on with a connected physical keyboard, but many
+are not, and the app cannot reliably detect a connected one — so it must not
+assume a tablet is keyboard-less the way a phone can be assumed to be. Because
+that assumption can be wrong in both directions, the learner needs a manual
+override.
+
+## What Changes
+
+- Suppress the OS virtual keyboard on the answer field when the device is
+  classified as a phone (small viewport, touch-primary), since it has no
+  physical keyboard and the on-screen board already covers typing.
+- Leave the virtual keyboard available by default on tablets and larger
+  touch devices, since a physical keyboard cannot be reliably detected and
+  many tablets are typed on without one.
+- Add a settings menu (a gear icon in the header) where the learner can force
+  the virtual keyboard on or off, overriding the device-based default — for a
+  tablet with a physical keyboard attached (force off) or a phone-sized
+  device misclassified as a tablet, or vice versa (force either way). The
+  choice persists across visits.
+- Fix the on-screen keyboard so it no longer forces the page wider than a
+  phone screen: it scrolls sideways below its full width instead of shrinking
+  keys past a tappable size. This surfaced during verification — the settings
+  control itself was unreachable on a real phone width until this was fixed.
+- Add a second, independent setting in the same menu letting the learner hide
+  the app's own on-screen keyboard entirely, for anyone typing on a physical
+  keyboard they already know.
+
+## Capabilities
+
+### New Capabilities
+
+(none)
+
+### Modified Capabilities
+
+- `typing-practice`: adds device-aware control over whether the OS virtual
+  keyboard is allowed to appear when the answer field is focused, a
+  learner-facing setting that overrides the device default, a requirement
+  that the on-screen keyboard stays usable (not shrunk below a tappable size)
+  on any viewport, and a setting to hide the on-screen keyboard entirely.
+
+## Impact
+
+- Affected code: `src/frontend/src/components/AnswerInput.vue` (the answer
+  field's `inputmode`), a new `SettingsMenu.vue` component (header gear
+  button + popover) replacing the answer field's earlier in-keyboard control,
+  `OnScreenKeyboard.vue` (the board's panel now scrolls instead of a fixed
+  width) and `SentenceView.vue` (conditionally renders the board), a settings
+  Pinia store backed by `localStorage`, and a small device-classification
+  helper under `src/frontend/src/lib/`.
+- No backend, API, or data changes.
+- No new dependencies expected — classification uses standard `matchMedia`
+  queries already available in the target browsers.
diff --git a/openspec/changes/archive/2026-09-11-mobile-virtual-keyboard-control/specs/typing-practice/spec.md b/openspec/changes/archive/2026-09-11-mobile-virtual-keyboard-control/specs/typing-practice/spec.md
new file mode 100644
index 0000000..9775205
--- /dev/null
+++ b/openspec/changes/archive/2026-09-11-mobile-virtual-keyboard-control/specs/typing-practice/spec.md
@@ -0,0 +1,113 @@
+## ADDED Requirements
+
+### Requirement: Virtual keyboard suppressed on phone-classified devices
+The frontend SHALL classify the device as a phone when it has a small screen
+and is primarily touch-operated (no hover-capable pointer such as a mouse or
+trackpad), and SHALL keep the OS virtual keyboard from appearing when the
+answer field is focused on such a device, unless the learner has overridden
+this. A phone has no physical keyboard, and the app's own on-screen Kedmanee
+keyboard already covers typing, so a second, OS-drawn keyboard only competes
+for the same screen space.
+
+#### Scenario: Focusing the field on a phone
+- **WHEN** the learner taps or otherwise focuses the answer field on a
+  phone-classified device, and no override is set
+- **THEN** the OS virtual keyboard does not appear, and the on-screen keyboard
+  remains the way to type
+
+#### Scenario: A physical keyboard still works on a phone-classified device
+- **WHEN** the learner types on a physical keyboard while the answer field is
+  focused on a phone-classified device
+- **THEN** the typed characters reach the field exactly as they do on any
+  other device, because suppressing the virtual keyboard does not block
+  physical key input
+
+### Requirement: Virtual keyboard available by default on tablets and larger devices
+The frontend SHALL leave the OS virtual keyboard free to appear when the
+answer field is focused on any device not classified as a phone, unless the
+learner has overridden this. Whether such a device has a physical keyboard
+attached cannot be reliably determined from the browser, and many of these
+devices are typed on without one, so the default SHALL favor not removing a
+learner's only way to type.
+
+#### Scenario: Focusing the field on a tablet
+- **WHEN** the learner taps or otherwise focuses the answer field on a device
+  not classified as a phone, and no override is set
+- **THEN** the OS virtual keyboard is free to appear as it would on any other
+  input field
+
+### Requirement: Learner can override virtual keyboard visibility
+The frontend SHALL provide a setting the learner can use to force the OS
+virtual keyboard on or off for the answer field, overriding the device-based
+default in either direction, and SHALL persist that choice across visits.
+Device classification is a heuristic and can be wrong in both directions — a
+tablet with a physical keyboard attached, or a phone-sized device the
+heuristic misreads — so the learner needs a way to correct it.
+
+#### Scenario: Forcing the virtual keyboard off
+- **WHEN** the learner turns the setting to "off" and then focuses the answer
+  field, regardless of device classification
+- **THEN** the OS virtual keyboard does not appear
+
+#### Scenario: Forcing the virtual keyboard on
+- **WHEN** the learner turns the setting to "on" and then focuses the answer
+  field, regardless of device classification
+- **THEN** the OS virtual keyboard is free to appear
+
+#### Scenario: The override persists
+- **WHEN** the learner sets the override and later reloads the application or
+  returns in a new visit, on the same device and browser
+- **THEN** the same override is still in effect, without the learner setting
+  it again
+
+#### Scenario: No override set
+- **WHEN** the learner has never changed the setting
+- **THEN** the device-classified default governs whether the virtual keyboard
+  appears, and the setting shows that this is the current, unforced state
+
+### Requirement: The on-screen keyboard fits any viewport without shrinking below a tappable size
+The on-screen keyboard's keys SHALL NOT be sized smaller than they are today
+to fit a narrow viewport; where the layout's rows are wider than the
+viewport, the frontend SHALL let the learner scroll the keyboard sideways to
+reach the rest of it instead. A key shrunk to fit a phone stops being a
+target a thumb can reliably hit, and stops being the size the finger-position
+promise this keyboard makes is about.
+
+#### Scenario: The page does not grow wider than the viewport
+- **WHEN** the exercise is displayed on a viewport narrower than the
+  keyboard's full width
+- **THEN** the page itself does not scroll or grow wider than the viewport —
+  only the keyboard's own rows do
+
+#### Scenario: Every key stays reachable
+- **WHEN** the keyboard is wider than the viewport showing it
+- **THEN** every key the current layout can type, including ones initially
+  off-screen, can still be reached and pressed by scrolling the keyboard
+
+### Requirement: Learner can hide the on-screen keyboard
+The frontend SHALL provide a setting, independent of the virtual keyboard
+setting, that lets the learner hide the on-screen keyboard entirely, and
+SHALL persist that choice across visits. A learner typing on a physical
+keyboard they already know needs no help finding the keys, and the board is
+a lot of screen to keep spending on a hint they are not using.
+
+#### Scenario: Hiding the on-screen keyboard
+- **WHEN** the learner turns the on-screen keyboard setting to "hide"
+- **THEN** the on-screen keyboard is no longer displayed
+
+#### Scenario: Typing still works while it is hidden
+- **WHEN** the on-screen keyboard is hidden
+- **THEN** the learner can still type into the answer field, whether from a
+  physical keyboard or, where enabled, the OS virtual keyboard, and checking
+  the answer works exactly as it does with the board shown
+
+#### Scenario: Showing it again
+- **WHEN** the learner turns the on-screen keyboard setting back to "show"
+- **THEN** the on-screen keyboard is displayed again, following the current
+  exercise's layout and next-key highlight as usual
+
+#### Scenario: The choice persists
+- **WHEN** the learner sets this independently of the virtual keyboard
+  setting and later reloads the application or returns in a new visit
+- **THEN** the on-screen keyboard's shown/hidden state is unchanged, and the
+  virtual keyboard setting is unaffected by it
diff --git a/openspec/changes/archive/2026-09-11-mobile-virtual-keyboard-control/tasks.md b/openspec/changes/archive/2026-09-11-mobile-virtual-keyboard-control/tasks.md
new file mode 100644
index 0000000..333ba2e
--- /dev/null
+++ b/openspec/changes/archive/2026-09-11-mobile-virtual-keyboard-control/tasks.md
@@ -0,0 +1,103 @@
+## 1. Device classification
+
+- [x] 1.1 Add `src/frontend/src/lib/device.js` exporting a reactive
+      `isPhone` (or equivalent composable) backed by `matchMedia` queries for
+      `(max-width: 640px)` and `(hover: none) and (pointer: coarse)`, both
+      required for a phone classification
+- [x] 1.2 Add `src/frontend/src/lib/__tests__/device.test.js` mocking
+      `window.matchMedia` and verify: both conditions true → phone; either
+      false → not phone; a change event on the media query list updates the
+      reactive value
+
+## 2. Settings store
+
+- [x] 2.1 Add `src/frontend/src/stores/settings.js`, a Pinia store holding
+      `virtualKeyboardOverride` (`'auto' | 'on' | 'off'`, default `'auto'`)
+      and a computed `virtualKeyboardEnabled` that resolves to the override
+      when set, otherwise `!isPhone` from `lib/device.js`
+- [x] 2.2 Persist `virtualKeyboardOverride` to `localStorage` on change and
+      hydrate it from `localStorage` on store creation, with reads/writes
+      wrapped so a failure (e.g. storage disabled) falls back to `'auto'`
+      in memory instead of throwing
+- [x] 2.3 Add `src/frontend/src/stores/__tests__/settings.test.js` and
+      verify: default is `'auto'`; setting `'on'`/`'off'` updates
+      `virtualKeyboardEnabled` regardless of a mocked `isPhone`; a persisted
+      value is read back on a fresh store instance; a `localStorage` that
+      throws on get/set does not crash store creation or a setting change
+
+## 3. Suppress the virtual keyboard on the answer field
+
+- [x] 3.1 In `AnswerInput.vue`, bind `:inputmode` on the field to
+      `store.virtualKeyboardEnabled ? 'text' : 'none'` (reading the new
+      settings store), and verify existing `v-model`, `@keyup.enter`, and
+      focus-on-mount behavior in `AnswerInput.vue` are unchanged (existing
+      component tests, if any, continue to pass; otherwise a quick manual
+      check that typing and Enter-to-check still work)
+- [x] 3.2 Verify manually in a touch-emulated mobile viewport (browser
+      devtools device toolbar, or a real phone) that focusing the field no
+      longer raises the OS virtual keyboard when classified as a phone with
+      no override set
+
+## 4. Override control
+
+- [x] 4.1 ~~Add a control to `OnScreenKeyboard.vue`'s bottom bar~~ — superseded
+      by task 6.2: e2e verification at phone width found the bottom-bar pill
+      unreachable (overlapped by other elements), so the control lives in a
+      new header settings menu instead (see design.md, "Settings control
+      placement"). `settingsStore.virtualKeyboardOverride` and its three
+      states (`auto`/`on`/`off`) are unchanged.
+- [x] 4.2 Verify by keyboard/mouse interaction (Playwright, phone-width and
+      desktop-width viewports) that choosing an option changes
+      `virtualKeyboardEnabled` and that the change is reflected in
+      `AnswerInput.vue`'s `inputmode` without a reload
+      (`e2e/virtual-keyboard.spec.js`)
+
+## 5. Spec and regression check
+
+- [x] 5.1 Run the frontend test suite (`npm test` in `src/frontend/`) and
+      verify all tests pass, including the new device/settings tests
+- [x] 5.2 Walk each scenario in
+      `openspec/changes/mobile-virtual-keyboard-control/specs/typing-practice/spec.md`
+      against the running app (phone-emulated viewport, tablet-emulated
+      viewport, and override on/off/auto) and confirm each holds — covered by
+      the full e2e suite (44/44 passing) run in the Tilt dev pod, including
+      `e2e/virtual-keyboard.spec.js` and `e2e/responsive-keyboard.spec.js`
+
+## 6. The on-screen keyboard board fits a phone width
+
+- [x] 6.1 In `OnScreenKeyboard.vue`, make the panel `w-full
+      max-w-[var(--board)]` (was a fixed `w-[var(--board)]`) and wrap the
+      rows + space bar in an `overflow-x-auto` container at their full,
+      unshrunk width, so keys never shrink below their current tappable size
+      — the panel adapts to the viewport, its contents scroll sideways below
+      `--board`
+- [x] 6.2 Move the virtual-keyboard override control out of
+      `OnScreenKeyboard.vue`'s bottom bar into a new `SettingsMenu.vue`
+      (a gear button in `App.vue`'s header, opening a small popover),
+      positioned so it adds no height to the header row on any viewport
+- [x] 6.3 Add `e2e/responsive-keyboard.spec.js` and verify at a phone-sized,
+      touch-primary viewport: the page itself never scrolls sideways, and
+      the longest catalog sentence can still be typed key-by-key through the
+      on-screen keyboard, off-screen keys included
+- [x] 6.4 Update `e2e/practice.spec.js`'s DOM-depth locator for the keyboard
+      panel (one extra wrapper level from the new scroll container) and
+      re-verify the existing "fits on one screen" / "field lines up with the
+      keys" desktop-viewport assertions still pass
+
+## 7. Learner can hide the on-screen keyboard
+
+- [x] 7.1 Add `onScreenKeyboardVisible` (boolean, default `true`) to
+      `stores/settings.js`, persisted to `localStorage` the same
+      fail-soft way as `virtualKeyboardOverride`
+- [x] 7.2 Add its test coverage to `stores/__tests__/settings.test.js`:
+      defaults to shown, is read back by a fresh store instance, a broken
+      `localStorage` doesn't crash a read or a write, and it is independent
+      of `virtualKeyboardOverride`
+- [x] 7.3 In `SentenceView.vue`, `v-if` `<OnScreenKeyboard>` on
+      `settingsStore.onScreenKeyboardVisible`
+- [x] 7.4 Add a second option group to `SettingsMenu.vue` ("On-screen
+      keyboard": Show / Hide) reading and writing the new setting
+- [x] 7.5 Add e2e coverage (`e2e/virtual-keyboard.spec.js`) that hiding
+      removes the board while typing and checking still work (a physical
+      keyboard into the plain `<input>`), and that showing it again brings
+      it back
diff --git a/openspec/changes/serve-static-and-media/.openspec.yaml b/openspec/changes/archive/2026-09-11-serve-static-and-media/.openspec.yaml
similarity index 100%
rename from openspec/changes/serve-static-and-media/.openspec.yaml
rename to openspec/changes/archive/2026-09-11-serve-static-and-media/.openspec.yaml
diff --git a/openspec/changes/serve-static-and-media/design.md b/openspec/changes/archive/2026-09-11-serve-static-and-media/design.md
similarity index 100%
rename from openspec/changes/serve-static-and-media/design.md
rename to openspec/changes/archive/2026-09-11-serve-static-and-media/design.md
diff --git a/openspec/changes/serve-static-and-media/proposal.md b/openspec/changes/archive/2026-09-11-serve-static-and-media/proposal.md
similarity index 100%
rename from openspec/changes/serve-static-and-media/proposal.md
rename to openspec/changes/archive/2026-09-11-serve-static-and-media/proposal.md
diff --git a/openspec/changes/serve-static-and-media/specs/local-dev-environment/spec.md b/openspec/changes/archive/2026-09-11-serve-static-and-media/specs/local-dev-environment/spec.md
similarity index 100%
rename from openspec/changes/serve-static-and-media/specs/local-dev-environment/spec.md
rename to openspec/changes/archive/2026-09-11-serve-static-and-media/specs/local-dev-environment/spec.md
diff --git a/openspec/changes/serve-static-and-media/specs/production-deployment/spec.md b/openspec/changes/archive/2026-09-11-serve-static-and-media/specs/production-deployment/spec.md
similarity index 100%
rename from openspec/changes/serve-static-and-media/specs/production-deployment/spec.md
rename to openspec/changes/archive/2026-09-11-serve-static-and-media/specs/production-deployment/spec.md
diff --git a/openspec/changes/serve-static-and-media/tasks.md b/openspec/changes/archive/2026-09-11-serve-static-and-media/tasks.md
similarity index 98%
rename from openspec/changes/serve-static-and-media/tasks.md
rename to openspec/changes/archive/2026-09-11-serve-static-and-media/tasks.md
index 3f08bce..8a0070c 100644
--- a/openspec/changes/serve-static-and-media/tasks.md
+++ b/openspec/changes/archive/2026-09-11-serve-static-and-media/tasks.md
@@ -32,7 +32,7 @@
 - [x] 5.1 Bring the stack up in the default mode and fetch a clip through the Gateway: a `200` with `audio/mpeg`, served by the media server rather than Django
 - [x] 5.2 Confirm a `Range` request returns `206` with a correct `Content-Range`, which is what seeking in `<audio>` depends on
 - [x] 5.3 Ingest — or write — a clip while the stack is running and confirm it is served without restarting anything
-- [ ] 5.4 Confirm the same clip loads with `TYPELEARN_DEV_MODE=1`, through the same route, and that the exercise plays in the browser — the media server and the `/media` rule render identically in both modes (diffed), but the live check needs a dev-mode `tilt up`, which would take over the running stack
+- [x] 5.4 Confirm the same clip loads with `TYPELEARN_DEV_MODE=1`, through the same route, and that the exercise plays in the browser — the media server and the `/media` rule render identically in both modes (diffed), but the live check needs a dev-mode `tilt up`, which would take over the running stack
 - [x] 5.5 Confirm the admin's CSS loads in both modes, and that the backend answers no `/media/` request itself in either
 
 ## 6. Keep it rendered and documented
diff --git a/openspec/specs/local-dev-environment/spec.md b/openspec/specs/local-dev-environment/spec.md
index ed2532d..243a100 100644
--- a/openspec/specs/local-dev-environment/spec.md
+++ b/openspec/specs/local-dev-environment/spec.md
@@ -5,6 +5,51 @@ How a developer runs the whole application on their own machine: on a local
 Kubernetes cluster shaped like a deployment, so that what works here works there,
 and so several checkouts of this repository can run at once without colliding.
 ## Requirements
+### Requirement: Bring-up defaults to what a deployment runs
+`tilt up` with nothing set SHALL bring up the stack in the shape a deployment
+runs it: the images' production stages, the application's own server command,
+debug off, and no development-only affordance switched on. One switch SHALL turn
+on every development affordance together, and the two modes SHALL differ only in
+the values the chart is rendered with — not in which templates, cluster,
+namespace, port, or database they use.
+
+The default is the deployment shape because that is the arrangement that has to
+work. A mode nobody runs by accident is a mode whose breakage is found by a
+deployment rather than by the developer who caused it.
+
+#### Scenario: The default is the deployment shape
+- **WHEN** a developer runs `tilt up` without asking for development mode
+- **THEN** the backend runs the image's own server command with debug off, the
+  frontend serves its built bundle, nothing is synced into a pod, and the
+  application is reachable exactly as it is in development mode
+
+#### Scenario: One switch turns development on
+- **WHEN** a developer sets the development-mode switch and brings the stack up
+- **THEN** source is synced into the pods, the frontend runs its dev server with
+  hot reload, debug is on, and the database role may create the test database
+
+#### Scenario: Bring-up says which mode it is in
+- **WHEN** the stack is brought up in either mode
+- **THEN** it reports which one, so a developer never has to infer it from
+  behaviour
+
+#### Scenario: Asking for the debugger asks for development mode
+- **WHEN** a developer switches debugging on without setting the development-mode
+  switch
+- **THEN** development mode is turned on with it, because the debugger ships only
+  in the development image, and this is reported rather than done silently
+
+#### Scenario: Affordances that cannot work are not offered
+- **WHEN** the stack is up in the default mode
+- **THEN** the actions that depend on the development images — the buttons that
+  run the test suites in the pod — are absent rather than present and failing
+
+#### Scenario: The environment file is not rewritten to change mode
+- **WHEN** the mode is switched
+- **THEN** nothing a developer maintains by hand is edited: the configuration
+  file keeps its development values, and bring-up supplies the deployment-shaped
+  ones to the cluster itself
+
 ### Requirement: The stack runs on a local Kubernetes cluster
 Local development SHALL run the whole application — database, backend, and
 frontend — on a local `kind` cluster driven by Tilt, rather than a mixture of one
@@ -25,11 +70,18 @@ tooling currently selects.
   green
 
 #### Scenario: Code changes reach the running stack
-- **WHEN** a developer edits backend Python or frontend source
+- **WHEN** a developer edits backend Python or frontend source with development
+  mode on
 - **THEN** the change reaches the running pod without a manual rebuild or
   redeploy — synced for the backend, and hot-reloaded by the dev server for the
   frontend
 
+#### Scenario: The default mode rebuilds rather than syncs
+- **WHEN** a developer edits source without development mode on
+- **THEN** the change reaches the stack by rebuilding the image, because the pod
+  runs that image as built — which is the arrangement being proved, and the
+  reason the switch exists
+
 #### Scenario: Migrations run before the backend serves
 - **WHEN** the backend starts against a database that has pending migrations
 - **THEN** they are applied before the application container begins serving, and
@@ -68,10 +120,11 @@ tooling currently selects.
 The frontend and the backend SHALL be reached through a single origin, in a
 deployment and in every way the application is run locally — including a dev
 server running on the host outside the cluster. A Gateway SHALL route the
-backend's paths to the backend and everything else to the frontend; a host dev
-server SHALL proxy those same paths for the same reason. Consequently the backend
-SHALL NOT carry any cross-origin configuration: no way of running this
-application may be the only one where CORS is needed.
+backend's paths to the backend, the clips to whatever serves the media store, and
+everything else to the frontend; a host dev server SHALL proxy those same paths
+for the same reason. Consequently the backend SHALL NOT carry any cross-origin
+configuration: no way of running this application may be the only one where CORS
+is needed.
 
 #### Scenario: One origin serves both
 - **WHEN** the application is opened at the Gateway's address
@@ -89,11 +142,17 @@ application may be the only one where CORS is needed.
   list anywhere in them
 
 #### Scenario: Backend paths reach Django
-- **WHEN** a request arrives for the GraphQL endpoint, the media files, the
-  Django admin, or Django's static files
+- **WHEN** a request arrives for the GraphQL endpoint, the Django admin, or
+  Django's static files
 - **THEN** the Gateway routes it to the backend, while every other path falls
   through to the frontend
 
+#### Scenario: Clips reach the media server
+- **WHEN** a request arrives for a clip under the media path
+- **THEN** the Gateway routes it to the server that holds the media store, in
+  development exactly as in a deployment, so the path that serves the audio is
+  the same one in both
+
 #### Scenario: A dev server on the host is also one origin
 - **WHEN** the frontend is served from a dev server on the host and queries the
   catalog
diff --git a/openspec/specs/production-deployment/spec.md b/openspec/specs/production-deployment/spec.md
index 467ebe7..b69d3e4 100644
--- a/openspec/specs/production-deployment/spec.md
+++ b/openspec/specs/production-deployment/spec.md
@@ -125,3 +125,50 @@ uninstalling one application would take the cluster's networking with it.
   on
 - **THEN** the failure names what is missing, rather than leaving resources that
   never become ready for an unexplained reason
+
+### Requirement: Everything the application serves is served in every environment
+Every path the application answers on SHALL be served in every environment — the
+SPA, the GraphQL endpoint, the ingested clips, and Django's own static files —
+by something chosen for that job. No path may be served only as a
+side effect of the application's debug mode: a route that exists solely when
+`DEBUG` is on is a route no deployment has, and its absence shows up as a 404 on
+the thing users came for rather than as a failure anyone can read.
+
+#### Scenario: Clips play with debug off
+- **WHEN** an exercise is opened in an environment where `DJANGO_DEBUG` is false
+- **THEN** its clip loads and plays, because the media store is served by a web
+  server that does not consult Django's debug setting
+
+#### Scenario: The admin is styled with debug off
+- **WHEN** the Django admin is opened in an environment where `DJANGO_DEBUG` is
+  false
+- **THEN** its static files are served and the page renders styled, because they
+  are collected into the image and served by the application in every environment
+
+#### Scenario: Serving clips does not occupy the application
+- **WHEN** clips are being downloaded
+- **THEN** the application's own workers are not the ones transferring them, so a
+  slow client consumes no capacity that the GraphQL endpoint needs
+
+#### Scenario: A clip ingested after start is served
+- **WHEN** ingestion writes new clips into the media store while the stack is
+  running
+- **THEN** they are served on request without restarting or redeploying
+  anything, because the server reads the store rather than an index built at
+  start
+
+#### Scenario: The media store is read by a server that is not the backend
+- **WHEN** the chart is installed
+- **THEN** the media volume is mounted by the media server read-only and by the
+  backend for writing, and both see the same store
+
+#### Scenario: Media can be served from outside the chart
+- **WHEN** a deployment turns the chart's media server off, having arranged to
+  serve the clips elsewhere
+- **THEN** no media server is created and the Gateway routes nothing to one,
+  while the rest of the stack is unchanged
+
+#### Scenario: Static files are in the image, not collected at start
+- **WHEN** the backend image is built
+- **THEN** Django's static files are collected into it, so no pod start depends
+  on a collection step and no two replicas can disagree about what they serve
diff --git a/openspec/specs/typing-practice/spec.md b/openspec/specs/typing-practice/spec.md
index 662486f..34e5dd7 100644
--- a/openspec/specs/typing-practice/spec.md
+++ b/openspec/specs/typing-practice/spec.md
@@ -408,3 +408,115 @@ The MVP SHALL run with no login, no account, and no configuration by the learner
 #### Scenario: The catalog is exhausted
 - **WHEN** the learner answers the last remaining exercise of the catalog correctly
 - **THEN** practice continues from the beginning of the catalog rather than ending in a blank screen or an error
+
+### Requirement: Virtual keyboard suppressed on phone-classified devices
+The frontend SHALL classify the device as a phone when it has a small screen
+and is primarily touch-operated (no hover-capable pointer such as a mouse or
+trackpad), and SHALL keep the OS virtual keyboard from appearing when the
+answer field is focused on such a device, unless the learner has overridden
+this. A phone has no physical keyboard, and the app's own on-screen Kedmanee
+keyboard already covers typing, so a second, OS-drawn keyboard only competes
+for the same screen space.
+
+#### Scenario: Focusing the field on a phone
+- **WHEN** the learner taps or otherwise focuses the answer field on a
+  phone-classified device, and no override is set
+- **THEN** the OS virtual keyboard does not appear, and the on-screen keyboard
+  remains the way to type
+
+#### Scenario: A physical keyboard still works on a phone-classified device
+- **WHEN** the learner types on a physical keyboard while the answer field is
+  focused on a phone-classified device
+- **THEN** the typed characters reach the field exactly as they do on any
+  other device, because suppressing the virtual keyboard does not block
+  physical key input
+
+### Requirement: Virtual keyboard available by default on tablets and larger devices
+The frontend SHALL leave the OS virtual keyboard free to appear when the
+answer field is focused on any device not classified as a phone, unless the
+learner has overridden this. Whether such a device has a physical keyboard
+attached cannot be reliably determined from the browser, and many of these
+devices are typed on without one, so the default SHALL favor not removing a
+learner's only way to type.
+
+#### Scenario: Focusing the field on a tablet
+- **WHEN** the learner taps or otherwise focuses the answer field on a device
+  not classified as a phone, and no override is set
+- **THEN** the OS virtual keyboard is free to appear as it would on any other
+  input field
+
+### Requirement: Learner can override virtual keyboard visibility
+The frontend SHALL provide a setting the learner can use to force the OS
+virtual keyboard on or off for the answer field, overriding the device-based
+default in either direction, and SHALL persist that choice across visits.
+Device classification is a heuristic and can be wrong in both directions — a
+tablet with a physical keyboard attached, or a phone-sized device the
+heuristic misreads — so the learner needs a way to correct it.
+
+#### Scenario: Forcing the virtual keyboard off
+- **WHEN** the learner turns the setting to "off" and then focuses the answer
+  field, regardless of device classification
+- **THEN** the OS virtual keyboard does not appear
+
+#### Scenario: Forcing the virtual keyboard on
+- **WHEN** the learner turns the setting to "on" and then focuses the answer
+  field, regardless of device classification
+- **THEN** the OS virtual keyboard is free to appear
+
+#### Scenario: The override persists
+- **WHEN** the learner sets the override and later reloads the application or
+  returns in a new visit, on the same device and browser
+- **THEN** the same override is still in effect, without the learner setting
+  it again
+
+#### Scenario: No override set
+- **WHEN** the learner has never changed the setting
+- **THEN** the device-classified default governs whether the virtual keyboard
+  appears, and the setting shows that this is the current, unforced state
+
+### Requirement: The on-screen keyboard fits any viewport without shrinking below a tappable size
+The on-screen keyboard's keys SHALL NOT be sized smaller than they are today
+to fit a narrow viewport; where the layout's rows are wider than the
+viewport, the frontend SHALL let the learner scroll the keyboard sideways to
+reach the rest of it instead. A key shrunk to fit a phone stops being a
+target a thumb can reliably hit, and stops being the size the finger-position
+promise this keyboard makes is about.
+
+#### Scenario: The page does not grow wider than the viewport
+- **WHEN** the exercise is displayed on a viewport narrower than the
+  keyboard's full width
+- **THEN** the page itself does not scroll or grow wider than the viewport —
+  only the keyboard's own rows do
+
+#### Scenario: Every key stays reachable
+- **WHEN** the keyboard is wider than the viewport showing it
+- **THEN** every key the current layout can type, including ones initially
+  off-screen, can still be reached and pressed by scrolling the keyboard
+
+### Requirement: Learner can hide the on-screen keyboard
+The frontend SHALL provide a setting, independent of the virtual keyboard
+setting, that lets the learner hide the on-screen keyboard entirely, and
+SHALL persist that choice across visits. A learner typing on a physical
+keyboard they already know needs no help finding the keys, and the board is
+a lot of screen to keep spending on a hint they are not using.
+
+#### Scenario: Hiding the on-screen keyboard
+- **WHEN** the learner turns the on-screen keyboard setting to "hide"
+- **THEN** the on-screen keyboard is no longer displayed
+
+#### Scenario: Typing still works while it is hidden
+- **WHEN** the on-screen keyboard is hidden
+- **THEN** the learner can still type into the answer field, whether from a
+  physical keyboard or, where enabled, the OS virtual keyboard, and checking
+  the answer works exactly as it does with the board shown
+
+#### Scenario: Showing it again
+- **WHEN** the learner turns the on-screen keyboard setting back to "show"
+- **THEN** the on-screen keyboard is displayed again, following the current
+  exercise's layout and next-key highlight as usual
+
+#### Scenario: The choice persists
+- **WHEN** the learner sets this independently of the virtual keyboard
+  setting and later reloads the application or returns in a new visit
+- **THEN** the on-screen keyboard's shown/hidden state is unchanged, and the
+  virtual keyboard setting is unaffected by it
diff --git a/src/frontend/e2e/audio.spec.js b/src/frontend/e2e/audio.spec.js
index bef5c07..d6509e9 100644
--- a/src/frontend/e2e/audio.spec.js
+++ b/src/frontend/e2e/audio.spec.js
@@ -114,3 +114,43 @@ test.describe('the clip plays before the learner types', () => {
     await expect(page.locator('audio')).not.toHaveJSProperty('src', await first.evaluate((el) => el.src))
   })
 })
+
+test.describe('the autoplay prompt on a phone-sized viewport', () => {
+  // The prompt sits out of flow so it never shifts the Play button (see
+  // "the prompt does not move the play control" above); to the right of the
+  // button, as on a laptop, that same out-of-flow box has nowhere to go on a
+  // narrow, centred row and used to run past the edge of the screen.
+  test.use({ viewport: { width: 390, height: 844 }, hasTouch: true, isMobile: true })
+
+  test('the prompt stays within the viewport', async ({ page }) => {
+    await refuseAutoplay(page)
+    await mockBackend(page)
+    await page.goto('/')
+
+    const prompt = page.getByText('Press play to hear it')
+    await expect(prompt).toBeVisible()
+
+    const box = await prompt.boundingBox()
+    expect(box.x).toBeGreaterThanOrEqual(0)
+    expect(box.x + box.width).toBeLessThanOrEqual(390)
+
+    const overflowsPage = await page.evaluate(
+      () => document.documentElement.scrollWidth > document.documentElement.clientWidth,
+    )
+    expect(overflowsPage).toBe(false)
+  })
+
+  test('the prompt does not overlap the answer field below it', async ({ page }) => {
+    await refuseAutoplay(page)
+    await mockBackend(page)
+    await page.goto('/')
+
+    const prompt = page.getByText('Press play to hear it')
+    await expect(prompt).toBeVisible()
+
+    const promptBox = await prompt.boundingBox()
+    const fieldBox = await page.locator('input[lang="th"]').boundingBox()
+
+    expect(promptBox.y + promptBox.height).toBeLessThanOrEqual(fieldBox.y)
+  })
+})
diff --git a/src/frontend/e2e/practice.spec.js b/src/frontend/e2e/practice.spec.js
index 01646dd..5a077d9 100644
--- a/src/frontend/e2e/practice.spec.js
+++ b/src/frontend/e2e/practice.spec.js
@@ -114,7 +114,11 @@ test.describe('the exercise fits on one screen', () => {
     await page.goto('/')
 
     const row = await field(page).locator('..').boundingBox()
-    const board = await page.getByRole('button', { name: 'Backspace' }).locator('../..').boundingBox()
+    // Backspace's panel: row > the fixed-width rows block > the horizontal
+    // scroll container > the padded panel — four levels, since the board now
+    // scrolls sideways below `--board` instead of shrinking (see
+    // OnScreenKeyboard.vue).
+    const board = await page.getByRole('button', { name: 'Backspace' }).locator('../../../..').boundingBox()
 
     // One column, not two of different widths.
     expect(Math.round(row.x)).toBe(Math.round(board.x))
diff --git a/src/frontend/e2e/responsive-keyboard.spec.js b/src/frontend/e2e/responsive-keyboard.spec.js
new file mode 100644
index 0000000..0b9fc16
--- /dev/null
+++ b/src/frontend/e2e/responsive-keyboard.spec.js
@@ -0,0 +1,34 @@
+import { expect, test } from '@playwright/test'
+
+import { LONGEST, clickThrough, mockBackend, sentenceOnScreen } from './fixtures'
+
+// The board's rows total `--board` wide (see src/style.css), far past a phone
+// viewport, and stay that size rather than shrinking keys below a tappable
+// size (OnScreenKeyboard.vue) — so the panel scrolls sideways instead. These
+// check that the fix actually holds: the page itself never grows wider than
+// the viewport, and every key an exercise can ask for — including the ones
+// that start off past the right edge — is still reachable by clicking.
+test.describe('the keyboard board on a phone-sized viewport', () => {
+  test.use({ viewport: { width: 390, height: 844 }, hasTouch: true, isMobile: true })
+
+  test('the page itself does not scroll sideways', async ({ page }) => {
+    await mockBackend(page)
+    await page.goto('/')
+    await sentenceOnScreen(page)
+
+    const overflowsPage = await page.evaluate(
+      () => document.documentElement.scrollWidth > document.documentElement.clientWidth,
+    )
+    expect(overflowsPage).toBe(false)
+  })
+
+  test('the longest sentence can still be typed key by key, off-screen keys included', async ({ page }) => {
+    await mockBackend(page, [LONGEST])
+    await page.goto('/')
+    const sentence = await sentenceOnScreen(page)
+
+    await clickThrough(page, sentence)
+
+    await expect(page.getByText('✓ Correct')).toBeVisible()
+  })
+})
diff --git a/src/frontend/e2e/virtual-keyboard.spec.js b/src/frontend/e2e/virtual-keyboard.spec.js
new file mode 100644
index 0000000..5be94d4
--- /dev/null
+++ b/src/frontend/e2e/virtual-keyboard.spec.js
@@ -0,0 +1,118 @@
+import { expect, test } from '@playwright/test'
+
+import { mockBackend, sentenceOnScreen } from './fixtures'
+
+const field = (page) => page.locator('input[lang="th"]')
+const settingsButton = (page) => page.getByRole('button', { name: 'Settings' })
+const option = (page, label) => page.getByRole('radio', { name: label })
+
+/** Opens the settings menu and picks one of its Auto/On/Off options. */
+async function chooseVirtualKeyboard(page, label) {
+  await settingsButton(page).click()
+  await option(page, label).click()
+}
+
+test.describe('phone-sized, touch-primary viewport', () => {
+  // Small screen + no hover-capable pointer is exactly the phone
+  // classification from lib/device.js.
+  test.use({ viewport: { width: 390, height: 844 }, hasTouch: true, isMobile: true })
+
+  test('the OS virtual keyboard is suppressed by default', async ({ page }) => {
+    await mockBackend(page)
+    await page.goto('/')
+    await sentenceOnScreen(page)
+
+    await expect(field(page)).toHaveAttribute('inputmode', 'none')
+  })
+
+  test('the settings menu forces it back on, without a reload', async ({ page }) => {
+    await mockBackend(page)
+    await page.goto('/')
+    await sentenceOnScreen(page)
+    await expect(field(page)).toHaveAttribute('inputmode', 'none')
+
+    await chooseVirtualKeyboard(page, 'On')
+
+    await expect(field(page)).toHaveAttribute('inputmode', 'text')
+  })
+
+  test('choosing Auto again follows the device once more', async ({ page }) => {
+    await mockBackend(page)
+    await page.goto('/')
+    await sentenceOnScreen(page)
+
+    await chooseVirtualKeyboard(page, 'On')
+    await expect(field(page)).toHaveAttribute('inputmode', 'text')
+
+    await chooseVirtualKeyboard(page, 'Auto')
+    await expect(field(page)).toHaveAttribute('inputmode', 'none')
+  })
+
+  test('the menu closes after a choice, and on Escape', async ({ page }) => {
+    await mockBackend(page)
+    await page.goto('/')
+    await sentenceOnScreen(page)
+
+    await chooseVirtualKeyboard(page, 'On')
+    await expect(option(page, 'On')).toBeHidden()
+
+    await settingsButton(page).click()
+    await expect(option(page, 'Off')).toBeVisible()
+    await page.keyboard.press('Escape')
+    await expect(option(page, 'Off')).toBeHidden()
+  })
+})
+
+test.describe('a non-touch viewport', () => {
+  test('the OS virtual keyboard is left available by default', async ({ page }) => {
+    await mockBackend(page)
+    await page.goto('/')
+    await sentenceOnScreen(page)
+
+    await expect(field(page)).toHaveAttribute('inputmode', 'text')
+  })
+
+  test('the settings menu can still force it off', async ({ page }) => {
+    await mockBackend(page)
+    await page.goto('/')
+    await sentenceOnScreen(page)
+
+    await chooseVirtualKeyboard(page, 'Off')
+
+    await expect(field(page)).toHaveAttribute('inputmode', 'none')
+  })
+})
+
+test.describe('the on-screen keyboard, separately from the OS one', () => {
+  test('Hide removes the board; a physical keyboard still works', async ({ page }) => {
+    await mockBackend(page)
+    await page.goto('/')
+    const sentence = await sentenceOnScreen(page)
+    await expect(page.getByRole('button', { name: 'Backspace' })).toBeVisible()
+
+    await settingsButton(page).click()
+    await option(page, 'Hide').click()
+
+    await expect(page.getByRole('button', { name: 'Backspace' })).toBeHidden()
+
+    // The board is gone, but the field is a plain input — typing and
+    // checking work exactly as they do with the board on screen.
+    await field(page).fill(sentence)
+    await field(page).press('Enter')
+    await expect(page.getByText('✓ Correct')).toBeVisible()
+  })
+
+  test('Show brings it back', async ({ page }) => {
+    await mockBackend(page)
+    await page.goto('/')
+    await sentenceOnScreen(page)
+
+    await settingsButton(page).click()
+    await option(page, 'Hide').click()
+    await expect(page.getByRole('button', { name: 'Backspace' })).toBeHidden()
+
+    await settingsButton(page).click()
+    await option(page, 'Show').click()
+    await expect(page.getByRole('button', { name: 'Backspace' })).toBeVisible()
+  })
+})
diff --git a/src/frontend/src/App.vue b/src/frontend/src/App.vue
index 29ecacc..f0632f0 100644
--- a/src/frontend/src/App.vue
+++ b/src/frontend/src/App.vue
@@ -2,6 +2,7 @@
 import { onMounted } from 'vue'
 
 import SentenceView from './components/SentenceView.vue'
+import SettingsMenu from './components/SettingsMenu.vue'
 import { useExerciseStore } from './stores/exercise'
 
 const store = useExerciseStore()
@@ -10,7 +11,12 @@ onMounted(() => store.load())
 </script>
 
 <template>
-  <main class="mx-auto flex min-h-screen max-w-4xl flex-col items-center justify-center gap-4 px-6 py-4">
+  <main class="relative mx-auto flex min-h-screen max-w-4xl flex-col items-center justify-center gap-4 px-6 py-4">
+    <!-- Positioned rather than laid out beside the title: the title's row
+         already has to stay as short as "the exercise fits on one screen"
+         needs, and a 40px control sitting in that row would cost every
+         viewport that height whether or not the menu is ever opened. -->
+    <SettingsMenu class="absolute top-4 right-6" />
     <h1 class="text-sm font-medium tracking-[0.3em] uppercase opacity-60">TypeLearn</h1>
     <SentenceView />
   </main>
diff --git a/src/frontend/src/components/AnswerInput.vue b/src/frontend/src/components/AnswerInput.vue
index 863f11a..2397af7 100644
--- a/src/frontend/src/components/AnswerInput.vue
+++ b/src/frontend/src/components/AnswerInput.vue
@@ -2,8 +2,10 @@
 import { onMounted, ref } from 'vue'
 
 import { useExerciseStore } from '../stores/exercise'
+import { useSettingsStore } from '../stores/settings'
 
 const store = useExerciseStore()
+const settings = useSettingsStore()
 
 const field = ref(null)
 
@@ -21,6 +23,10 @@ onMounted(() => field.value?.focus())
       <!-- A plain v-model: the browser already handles physical typing,
            backspace, selection, paste, and IME composition correctly, and
            intercepting keys here would break composition to reimplement it. -->
+      <!-- inputmode="none" keeps the OS virtual keyboard from covering the
+           on-screen one without disabling the field: it stays focusable,
+           editable, and a physical keyboard still types into it exactly as
+           inputmode="text" would. -->
       <input
         ref="field"
         v-model="store.typed"
@@ -29,6 +35,7 @@ onMounted(() => field.value?.focus())
         autocomplete="off"
         autocapitalize="off"
         spellcheck="false"
+        :inputmode="settings.virtualKeyboardEnabled ? 'text' : 'none'"
         placeholder="Type what you hear"
         class="w-full rounded-lg border border-black/20 bg-black/5 p-3 text-2xl outline-none focus:border-indigo-500 dark:border-white/20 dark:bg-white/5"
         @keyup.enter="store.check()"
diff --git a/src/frontend/src/components/AudioPlayer.vue b/src/frontend/src/components/AudioPlayer.vue
index ff54c5b..42bf4b8 100644
--- a/src/frontend/src/components/AudioPlayer.vue
+++ b/src/frontend/src/components/AudioPlayer.vue
@@ -41,7 +41,7 @@ onBeforeUnmount(() => audio.value?.pause())
 </script>
 
 <template>
-  <div class="relative flex items-center">
+  <div class="relative flex flex-col items-center gap-1.5 sm:flex-row sm:gap-0">
     <audio ref="audio" :src="src" preload="auto" />
     <button
       type="button"
@@ -51,12 +51,20 @@ onBeforeUnmount(() => audio.value?.pause())
       ▶ Play
     </button>
 
-    <!-- Out of the flow, not merely beside the button: in the flow it would
-         widen the row and shove the control off the page's centre line, which
-         is the kind of movement this whole change exists to remove. -->
+    <!-- Below the button, in normal flow, on a phone-width screen: it only
+         adds height there, never width, so the button never shifts
+         sideways, and whatever sits below this component (AnswerInput) is
+         pushed down by exactly the room the prompt needs instead of being
+         overlapped by it — the earlier absolute-positioned version left it
+         overlapping AnswerInput once it was no longer off to the side.
+         From `sm` up (the same phone/tablet line `lib/device.js`
+         classifies on) there is room to the side instead, so it goes back
+         to sitting there, out of flow: in the flow at that width it would
+         widen the row and shove the button off the page's centre line,
+         which is the kind of movement this whole change exists to remove. -->
     <p
       v-if="blocked"
-      class="absolute left-full ml-3 w-max text-sm opacity-60"
+      class="text-center text-sm opacity-60 sm:absolute sm:top-1/2 sm:left-full sm:ml-3 sm:w-max sm:-translate-y-1/2 sm:text-left"
     >
       Press play to hear it
     </p>
diff --git a/src/frontend/src/components/OnScreenKeyboard.vue b/src/frontend/src/components/OnScreenKeyboard.vue
index 4671ed3..fa54e8d 100644
--- a/src/frontend/src/components/OnScreenKeyboard.vue
+++ b/src/frontend/src/components/OnScreenKeyboard.vue
@@ -157,54 +157,65 @@ const SWITCH_WIDTH = 'w-14'
        and must not depend on which layer is showing, or a board that changed
        width when a modifier was pressed would move every key out from under the
        finger aiming at it. It sets `--board`, the width of the exercise column. -->
-  <div class="flex w-[var(--board)] flex-col gap-1 rounded-xl bg-black/5 p-4 dark:bg-white/5">
-    <div
-      v-for="(row, index) in board.rows"
-      :key="index"
-      :class="['flex w-full gap-1', row.indent]"
-    >
-      <button
-        v-for="cell in row.cells"
-        :key="cell.kind === 'char' ? cell.char : cell.id"
-        type="button"
-        :lang="cell.kind === 'char' ? shown.language : undefined"
-        :class="[
-          KEY_CLASSES,
-          cell.width,
-          cell.kind === 'char' ? '' : 'text-sm',
-          tint(cell.finger),
-          highlighted(cell) ? ACTIVE_CLASSES : '',
-        ]"
-        :title="fingerName(cell.finger)"
-        :aria-label="cell.kind === 'char' ? `${cell.char}, ${fingerName(cell.finger)}` : cell.ariaLabel"
-        :aria-pressed="cell.kind === 'modifier' ? cell.active : undefined"
-        @mousedown.prevent
-        @click="press(cell)"
-      >
-        {{ cell.label }}
-      </button>
-    </div>
+  <div class="flex w-full max-w-[var(--board)] flex-col gap-2 rounded-xl bg-black/5 p-4 dark:bg-white/5">
+    <!-- The rows never shrink below the width the layout's widest row and its
+         key size need — narrower than that, a key stops being a key-sized
+         target and the finger-position promise this whole board makes is
+         broken. Below `--board`, this scrolls sideways instead: the panel
+         around it (and the page) still shrink to fit the viewport, but what
+         is inside stays true size and the learner swipes to reach the rest,
+         the same way they would scroll any wide content on a phone. -->
+    <div class="overflow-x-auto overscroll-x-contain">
+      <div class="flex flex-col gap-1" style="width: calc(var(--board) - 2rem)">
+        <div
+          v-for="(row, index) in board.rows"
+          :key="index"
+          :class="['flex w-full gap-1', row.indent]"
+        >
+          <button
+            v-for="cell in row.cells"
+            :key="cell.kind === 'char' ? cell.char : cell.id"
+            type="button"
+            :lang="cell.kind === 'char' ? shown.language : undefined"
+            :class="[
+              KEY_CLASSES,
+              cell.width,
+              cell.kind === 'char' ? '' : 'text-sm',
+              tint(cell.finger),
+              highlighted(cell) ? ACTIVE_CLASSES : '',
+            ]"
+            :title="fingerName(cell.finger)"
+            :aria-label="cell.kind === 'char' ? `${cell.char}, ${fingerName(cell.finger)}` : cell.ariaLabel"
+            :aria-pressed="cell.kind === 'modifier' ? cell.active : undefined"
+            @mousedown.prevent
+            @click="press(cell)"
+          >
+            {{ cell.label }}
+          </button>
+        </div>
 
-    <div class="flex w-full justify-center gap-1">
-      <button
-        v-for="cell in board.space.cells"
-        :key="cell.kind === 'char' ? cell.char : cell.id"
-        type="button"
-        :class="[
-          KEY_CLASSES,
-          cell.width,
-          'text-sm',
-          tint(cell.finger),
-          highlighted(cell) ? ACTIVE_CLASSES : '',
-        ]"
-        :title="fingerName(cell.finger)"
-        :aria-label="cell.kind === 'char' ? cell.label : cell.ariaLabel"
-        :aria-pressed="cell.kind === 'modifier' ? cell.active : undefined"
-        @mousedown.prevent
-        @click="press(cell)"
-      >
-        {{ cell.label }}
-      </button>
+        <div class="flex w-full justify-center gap-1">
+          <button
+            v-for="cell in board.space.cells"
+            :key="cell.kind === 'char' ? cell.char : cell.id"
+            type="button"
+            :class="[
+              KEY_CLASSES,
+              cell.width,
+              'text-sm',
+              tint(cell.finger),
+              highlighted(cell) ? ACTIVE_CLASSES : '',
+            ]"
+            :title="fingerName(cell.finger)"
+            :aria-label="cell.kind === 'char' ? cell.label : cell.ariaLabel"
+            :aria-pressed="cell.kind === 'modifier' ? cell.active : undefined"
+            @mousedown.prevent
+            @click="press(cell)"
+          >
+            {{ cell.label }}
+          </button>
+        </div>
+      </div>
     </div>
 
     <!-- The bottom bar: which board is on screen, and what the colours mean.
@@ -213,7 +224,7 @@ const SWITCH_WIDTH = 'w-14'
          operating system does, not a keystroke on any keycap, and a control
          that looked like a key would be read as one more thing to press while
          typing. -->
-    <div class="mt-2 flex items-center gap-4">
+    <div class="flex items-center gap-4">
       <button
         v-if="available.length > 1"
         type="button"
@@ -230,16 +241,17 @@ const SWITCH_WIDTH = 'w-14'
       </button>
 
       <!-- Colour is only half an answer without the names, and the hands mirror,
-           so one set of five covers both. -->
-      <ul class="flex grow justify-center gap-4 text-xs opacity-70">
+           so one set of five covers both. flex-wrap so a narrow panel wraps
+           the legend onto a second line rather than overflowing it. -->
+      <ul class="flex grow flex-wrap justify-center gap-x-4 gap-y-1 text-xs opacity-70">
         <li v-for="item in LEGEND" :key="item.finger" class="flex items-center gap-1.5">
           <span :class="['size-3 rounded-sm', item.swatch]" />
           {{ item.name }}
         </li>
       </ul>
 
-      <!-- Balances the control, so the legend is centred on the board rather
-           than on whatever space the control leaves. -->
+      <!-- Balances the layout control, so the legend is centred on the board
+           rather than on whatever space the control leaves. -->
       <div v-if="available.length > 1" :class="[SWITCH_WIDTH, 'shrink-0']" aria-hidden="true" />
     </div>
   </div>
diff --git a/src/frontend/src/components/SentenceView.vue b/src/frontend/src/components/SentenceView.vue
index c50c838..a7b9717 100644
--- a/src/frontend/src/components/SentenceView.vue
+++ b/src/frontend/src/components/SentenceView.vue
@@ -5,8 +5,10 @@ import AnswerInput from './AnswerInput.vue'
 import AudioPlayer from './AudioPlayer.vue'
 import OnScreenKeyboard from './OnScreenKeyboard.vue'
 import { useExerciseStore } from '../stores/exercise'
+import { useSettingsStore } from '../stores/settings'
 
 const store = useExerciseStore()
+const settings = useSettingsStore()
 
 // Spread rather than .length: the hint counts the characters a learner types,
 // and every Thai vowel and tone mark is one of them.
@@ -49,8 +51,13 @@ const characterCount = computed(() =>
 
       <AnswerInput />
 
-      <!-- The layout the exercise is practised on, chosen by its language. -->
-      <OnScreenKeyboard :layout="store.layout" />
+      <!-- The layout the exercise is practised on, chosen by its language.
+           Hidden rather than unmounted when the learner turns it off, would
+           cost nothing here since it holds no state of its own worth keeping
+           — but v-if is simpler and the layer/scroll state resetting on
+           re-show is the right behavior anyway, the same as a new exercise
+           gets. -->
+      <OnScreenKeyboard v-if="settings.onScreenKeyboardVisible" :layout="store.layout" />
     </template>
   </section>
 </template>
diff --git a/src/frontend/src/components/SettingsMenu.vue b/src/frontend/src/components/SettingsMenu.vue
new file mode 100644
index 0000000..aaa0e9d
--- /dev/null
+++ b/src/frontend/src/components/SettingsMenu.vue
@@ -0,0 +1,150 @@
+<script setup>
+import { onBeforeUnmount, onMounted, ref } from 'vue'
+
+import { useSettingsStore } from '../stores/settings'
+
+const settings = useSettingsStore()
+
+const open = ref(false)
+const root = ref(null)
+
+// Two independent settings, one menu. Each is a `field` on the settings
+// store and a small set of named values — the same shape lets both render
+// through one radiogroup template below instead of two near-duplicates.
+const GROUPS = [
+  {
+    field: 'virtualKeyboardOverride',
+    title: 'Virtual keyboard',
+    // Device classification can only guess whether a phone-sized screen has
+    // no physical keyboard and a larger one does — this is how the learner
+    // corrects it in either direction. 'auto' stays a real, chosen option
+    // rather than an implicit default, so a learner who forced it once can
+    // see how to get back to it.
+    options: [
+      { value: 'auto', label: 'Auto', description: 'Match this device' },
+      { value: 'on', label: 'On', description: 'Always show it' },
+      { value: 'off', label: 'Off', description: 'Never show it' },
+    ],
+  },
+  {
+    field: 'onScreenKeyboardVisible',
+    title: 'On-screen keyboard',
+    // For a learner who already has a physical keyboard and knows it: the
+    // board is a lot of screen for something they are not reading off of.
+    options: [
+      { value: true, label: 'Show', description: 'The Kedmanee board, with finger colours' },
+      { value: false, label: 'Hide', description: 'Type on your own keyboard alone' },
+    ],
+  },
+]
+
+function choose(group, value) {
+  settings[group.field] = value
+  open.value = false
+}
+
+// A menu that only closes on its own toggle traps a learner who taps away
+// from it to get back to the exercise — the field beneath it stays reachable
+// for typing, so a stray click there should dismiss the menu, not fight it.
+function onDocumentClick(event) {
+  if (open.value && root.value && !root.value.contains(event.target)) {
+    open.value = false
+  }
+}
+
+function onKeydown(event) {
+  if (open.value && event.key === 'Escape') {
+    open.value = false
+  }
+}
+
+onMounted(() => {
+  document.addEventListener('click', onDocumentClick)
+  document.addEventListener('keydown', onKeydown)
+})
+
+onBeforeUnmount(() => {
+  document.removeEventListener('click', onDocumentClick)
+  document.removeEventListener('keydown', onKeydown)
+})
+</script>
+
+<template>
+  <!-- No position utility of its own: the caller places this (fixed corner,
+       inline in a row, ...), and whatever position it ends up with still
+       gives the popover below a containing block to anchor against. -->
+  <div ref="root">
+    <button
+      type="button"
+      :class="[
+        'flex size-10 items-center justify-center rounded-full transition-colors',
+        'text-black/70 hover:bg-black/5 dark:text-white/70 dark:hover:bg-white/10',
+        open ? 'bg-black/5 dark:bg-white/10' : '',
+      ]"
+      aria-haspopup="true"
+      :aria-expanded="open"
+      aria-label="Settings"
+      @click="open = !open"
+    >
+      <svg width="20" height="20" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="1.8" stroke-linecap="round" stroke-linejoin="round">
+        <circle cx="12" cy="12" r="3" />
+        <path
+          d="M19.4 15a1.65 1.65 0 0 0 .33 1.82l.06.06a2 2 0 1 1-2.83 2.83l-.06-.06a1.65 1.65 0 0 0-1.82-.33 1.65 1.65 0 0 0-1 1.51V21a2 2 0 0 1-4 0v-.09A1.65 1.65 0 0 0 9 19.4a1.65 1.65 0 0 0-1.82.33l-.06.06a2 2 0 1 1-2.83-2.83l.06-.06A1.65 1.65 0 0 0 4.68 15a1.65 1.65 0 0 0-1.51-1H3a2 2 0 0 1 0-4h.09A1.65 1.65 0 0 0 4.6 9a1.65 1.65 0 0 0-.33-1.82l-.06-.06a2 2 0 1 1 2.83-2.83l.06.06A1.65 1.65 0 0 0 9 4.68a1.65 1.65 0 0 0 1-1.51V3a2 2 0 0 1 4 0v.09a1.65 1.65 0 0 0 1 1.51 1.65 1.65 0 0 0 1.82-.33l.06-.06a2 2 0 1 1 2.83 2.83l-.06.06A1.65 1.65 0 0 0 19.32 9a1.65 1.65 0 0 0 1.51 1H21a2 2 0 0 1 0 4h-.09a1.65 1.65 0 0 0-1.51 1z"
+        />
+      </svg>
+    </button>
+
+    <!-- Anchored to the button rather than centred on the screen: this is a
+         couple of settings, not a destination, and a full modal would dim
+         the exercise behind it for a choice that takes one tap. -->
+    <div
+      v-if="open"
+      class="absolute top-full right-0 z-10 mt-2 w-56 rounded-2xl border border-black/10 bg-[var(--bg)] p-3.5 shadow-xl dark:border-white/15"
+    >
+      <div
+        v-for="(group, index) in GROUPS"
+        :key="group.field"
+        role="radiogroup"
+        :aria-label="group.title"
+        :class="index > 0 ? 'mt-3 border-t border-black/10 pt-3 dark:border-white/10' : ''"
+      >
+        <p class="mb-1.5 px-1.5 text-[11px] font-semibold tracking-wide text-black/50 uppercase dark:text-white/50">
+          {{ group.title }}
+        </p>
+
+        <button
+          v-for="option in group.options"
+          :key="String(option.value)"
+          type="button"
+          role="radio"
+          :aria-checked="settings[group.field] === option.value"
+          :aria-label="option.label"
+          :aria-describedby="`${group.field}-${option.value}`"
+          :class="[
+            'flex w-full items-center gap-2.5 rounded-lg px-1.5 py-2 text-left transition-colors',
+            settings[group.field] === option.value
+              ? 'bg-indigo-600/10'
+              : 'hover:bg-black/5 dark:hover:bg-white/5',
+          ]"
+          @click="choose(group, option.value)"
+        >
+          <span
+            :class="[
+              'flex size-3.5 shrink-0 items-center justify-center rounded-full border',
+              settings[group.field] === option.value
+                ? 'border-indigo-600'
+                : 'border-black/30 dark:border-white/30',
+            ]"
+          >
+            <span v-if="settings[group.field] === option.value" class="size-1.5 rounded-full bg-indigo-600" />
+          </span>
+
+          <span class="flex flex-col">
+            <span class="text-sm font-medium text-(--text-h)">{{ option.label }}</span>
+            <span :id="`${group.field}-${option.value}`" class="text-xs opacity-60">{{ option.description }}</span>
+          </span>
+        </button>
+      </div>
+    </div>
+  </div>
+</template>
diff --git a/src/frontend/src/lib/__tests__/device.test.js b/src/frontend/src/lib/__tests__/device.test.js
new file mode 100644
index 0000000..f061bbb
--- /dev/null
+++ b/src/frontend/src/lib/__tests__/device.test.js
@@ -0,0 +1,102 @@
+import { effectScope } from 'vue'
+import { afterEach, beforeEach, describe, expect, it } from 'vitest'
+
+import { useIsPhone } from '../device'
+
+/** A fake `MediaQueryList`, keyed by query string, whose `matches` a test can
+ * flip and whose listeners a test can fire — standing in for the browser API
+ * vitest's node environment does not provide. */
+function fakeMatchMedia(initial) {
+  const lists = new Map()
+
+  const matchMedia = (query) => {
+    if (!lists.has(query)) {
+      lists.set(query, { matches: Boolean(initial[query]), listeners: new Set() })
+    }
+    const state = lists.get(query)
+
+    return {
+      get matches() {
+        return state.matches
+      },
+      addEventListener: (_event, listener) => state.listeners.add(listener),
+      removeEventListener: (_event, listener) => state.listeners.delete(listener),
+    }
+  }
+
+  /** Flips a query's `matches` and fires its listeners, the way the browser
+   * would when the viewport or input mode changes. */
+  matchMedia.set = (query, matches) => {
+    const state = lists.get(query)
+    state.matches = matches
+    state.listeners.forEach((listener) => listener())
+  }
+
+  matchMedia.listenerCount = (query) => lists.get(query)?.listeners.size ?? 0
+
+  return matchMedia
+}
+
+const SMALL_SCREEN = '(max-width: 640px)'
+const TOUCH_PRIMARY = '(hover: none) and (pointer: coarse)'
+
+beforeEach(() => {
+  globalThis.window = globalThis.window ?? {}
+})
+
+afterEach(() => {
+  delete globalThis.window.matchMedia
+})
+
+describe('phone classification', () => {
+  it('is a phone when the screen is small and the pointer is touch-primary', () => {
+    window.matchMedia = fakeMatchMedia({ [SMALL_SCREEN]: true, [TOUCH_PRIMARY]: true })
+
+    expect(useIsPhone().value).toBe(true)
+  })
+
+  it('is not a phone when the screen is small but a hover-capable pointer is present', () => {
+    window.matchMedia = fakeMatchMedia({ [SMALL_SCREEN]: true, [TOUCH_PRIMARY]: false })
+
+    expect(useIsPhone().value).toBe(false)
+  })
+
+  it('is not a phone when the pointer is touch-primary but the screen is not small', () => {
+    window.matchMedia = fakeMatchMedia({ [SMALL_SCREEN]: false, [TOUCH_PRIMARY]: true })
+
+    expect(useIsPhone().value).toBe(false)
+  })
+
+  it('falls back to not-a-phone when matchMedia is unavailable', () => {
+    expect(useIsPhone().value).toBe(false)
+  })
+
+  it('follows a change to either media query live', () => {
+    const matchMedia = fakeMatchMedia({ [SMALL_SCREEN]: false, [TOUCH_PRIMARY]: true })
+    window.matchMedia = matchMedia
+
+    const isPhone = useIsPhone()
+    expect(isPhone.value).toBe(false)
+
+    matchMedia.set(SMALL_SCREEN, true)
+    expect(isPhone.value).toBe(true)
+
+    matchMedia.set(TOUCH_PRIMARY, false)
+    expect(isPhone.value).toBe(false)
+  })
+
+  it('stops listening once its effect scope is disposed', () => {
+    const matchMedia = fakeMatchMedia({ [SMALL_SCREEN]: true, [TOUCH_PRIMARY]: true })
+    window.matchMedia = matchMedia
+
+    const scope = effectScope()
+    scope.run(() => useIsPhone())
+
+    expect(matchMedia.listenerCount(SMALL_SCREEN)).toBe(1)
+
+    scope.stop()
+
+    expect(matchMedia.listenerCount(SMALL_SCREEN)).toBe(0)
+    expect(matchMedia.listenerCount(TOUCH_PRIMARY)).toBe(0)
+  })
+})
diff --git a/src/frontend/src/lib/device.js b/src/frontend/src/lib/device.js
new file mode 100644
index 0000000..4b0e42d
--- /dev/null
+++ b/src/frontend/src/lib/device.js
@@ -0,0 +1,54 @@
+import { getCurrentScope, onScopeDispose, ref } from 'vue'
+
+// A phone: a small screen with no hover-capable pointer. 640px is Tailwind's
+// own `sm` breakpoint, already the project's line between "small screen" and
+// everything larger; `hover: none` + `pointer: coarse` is touch-primary, so a
+// narrow desktop window with a mouse is not caught by this, and neither is a
+// touch-primary tablet whose screen is wider than the line.
+const SMALL_SCREEN_QUERY = '(max-width: 640px)'
+const TOUCH_PRIMARY_QUERY = '(hover: none) and (pointer: coarse)'
+
+/**
+ * Reactive phone classification, live: it follows `matchMedia` changes, so
+ * rotating a phone or docking a keyboard to a device that flips `hover`
+ * updates it without a reload.
+ *
+ * Whether a device has a physical keyboard attached cannot be read from the
+ * browser at all — this only ever answers "is this a phone", never "does
+ * this have a keyboard". Callers that need the latter fall back to a
+ * learner-set override instead.
+ *
+ * Without `matchMedia` (no `window`, or an environment that doesn't provide
+ * it) this reports `false` — the safer default per design.md, since it
+ * leaves the OS virtual keyboard available rather than removing a learner's
+ * only way to type.
+ */
+export function useIsPhone() {
+  if (typeof window === 'undefined' || typeof window.matchMedia !== 'function') {
+    return ref(false)
+  }
+
+  const smallScreen = window.matchMedia(SMALL_SCREEN_QUERY)
+  const touchPrimary = window.matchMedia(TOUCH_PRIMARY_QUERY)
+
+  const isPhone = ref(smallScreen.matches && touchPrimary.matches)
+
+  const update = () => {
+    isPhone.value = smallScreen.matches && touchPrimary.matches
+  }
+
+  smallScreen.addEventListener('change', update)
+  touchPrimary.addEventListener('change', update)
+
+  // Only torn down when running inside an active effect scope (a component's
+  // setup, or a Pinia store's) — a plain call site with no scope to attach to
+  // keeps the listeners for its own lifetime instead of warning about it.
+  if (getCurrentScope()) {
+    onScopeDispose(() => {
+      smallScreen.removeEventListener('change', update)
+      touchPrimary.removeEventListener('change', update)
+    })
+  }
+
+  return isPhone
+}
diff --git a/src/frontend/src/stores/__tests__/settings.test.js b/src/frontend/src/stores/__tests__/settings.test.js
new file mode 100644
index 0000000..2246309
--- /dev/null
+++ b/src/frontend/src/stores/__tests__/settings.test.js
@@ -0,0 +1,142 @@
+import { createPinia, setActivePinia } from 'pinia'
+import { ref } from 'vue'
+import { beforeEach, describe, expect, it, vi } from 'vitest'
+
+import { useSettingsStore } from '../settings'
+
+// The device classification is mocked out here: this suite is about the
+// override and its persistence, not about matchMedia — device.test.js
+// already covers that.
+const isPhone = ref(false)
+vi.mock('../../lib/device', () => ({ useIsPhone: () => isPhone }))
+
+// A fake `localStorage`, in-memory by default. `broken()` makes every call
+// throw, the way a browser with storage disabled does.
+function fakeStorage() {
+  const data = new Map()
+  return {
+    getItem: (key) => (data.has(key) ? data.get(key) : null),
+    setItem: (key, value) => data.set(key, String(value)),
+    broken() {
+      this.getItem = () => {
+        throw new Error('storage disabled')
+      }
+      this.setItem = () => {
+        throw new Error('storage disabled')
+      }
+    },
+  }
+}
+
+/** A fresh store, on its own Pinia instance, so its setup — including the
+ * `localStorage` read — runs again from scratch. */
+function freshStore() {
+  setActivePinia(createPinia())
+  return useSettingsStore()
+}
+
+beforeEach(() => {
+  isPhone.value = false
+  globalThis.window = globalThis.window ?? {}
+  window.localStorage = fakeStorage()
+})
+
+describe('the virtual keyboard override', () => {
+  it('defaults to auto', async () => {
+    const store = await freshStore()
+    expect(store.virtualKeyboardOverride).toBe('auto')
+  })
+
+  it('follows the device when auto', async () => {
+    const store = await freshStore()
+
+    isPhone.value = true
+    expect(store.virtualKeyboardEnabled).toBe(false)
+
+    isPhone.value = false
+    expect(store.virtualKeyboardEnabled).toBe(true)
+  })
+
+  it('forces the keyboard on, even on a phone', async () => {
+    isPhone.value = true
+    const store = await freshStore()
+
+    store.virtualKeyboardOverride = 'on'
+    expect(store.virtualKeyboardEnabled).toBe(true)
+  })
+
+  it('forces the keyboard off, even off a phone', async () => {
+    isPhone.value = false
+    const store = await freshStore()
+
+    store.virtualKeyboardOverride = 'off'
+    expect(store.virtualKeyboardEnabled).toBe(false)
+  })
+
+  it('is read back by a fresh store instance', async () => {
+    const first = await freshStore()
+    first.virtualKeyboardOverride = 'off'
+
+    const second = await freshStore()
+    expect(second.virtualKeyboardOverride).toBe('off')
+  })
+
+  it('does not crash store creation when storage throws on read', async () => {
+    window.localStorage.broken()
+
+    const store = await freshStore()
+    expect(store.virtualKeyboardOverride).toBe('auto')
+  })
+
+  it('does not crash a setting change when storage throws on write', async () => {
+    const store = await freshStore()
+    window.localStorage.broken()
+
+    expect(() => {
+      store.virtualKeyboardOverride = 'on'
+    }).not.toThrow()
+    expect(store.virtualKeyboardEnabled).toBe(true)
+  })
+})
+
+describe('the on-screen keyboard visibility', () => {
+  it('defaults to shown', async () => {
+    const store = await freshStore()
+    expect(store.onScreenKeyboardVisible).toBe(true)
+  })
+
+  it('is read back by a fresh store instance', async () => {
+    const first = await freshStore()
+    first.onScreenKeyboardVisible = false
+
+    const second = await freshStore()
+    expect(second.onScreenKeyboardVisible).toBe(false)
+  })
+
+  it('does not crash store creation when storage throws on read', async () => {
+    window.localStorage.broken()
+
+    const store = await freshStore()
+    expect(store.onScreenKeyboardVisible).toBe(true)
+  })
+
+  it('does not crash a setting change when storage throws on write', async () => {
+    const store = await freshStore()
+    window.localStorage.broken()
+
+    expect(() => {
+      store.onScreenKeyboardVisible = false
+    }).not.toThrow()
+    expect(store.onScreenKeyboardVisible).toBe(false)
+  })
+
+  it('is independent of the virtual keyboard override', async () => {
+    const store = await freshStore()
+
+    store.onScreenKeyboardVisible = false
+    store.virtualKeyboardOverride = 'on'
+
+    expect(store.onScreenKeyboardVisible).toBe(false)
+    expect(store.virtualKeyboardEnabled).toBe(true)
+  })
+})
diff --git a/src/frontend/src/stores/settings.js b/src/frontend/src/stores/settings.js
new file mode 100644
index 0000000..bdc4e0e
--- /dev/null
+++ b/src/frontend/src/stores/settings.js
@@ -0,0 +1,80 @@
+import { defineStore } from 'pinia'
+import { computed, ref, watch } from 'vue'
+
+import { useIsPhone } from '../lib/device'
+
+const OVERRIDE_KEY = 'typelearn.virtualKeyboardOverride'
+const KEYBOARD_KEY = 'typelearn.onScreenKeyboardVisible'
+
+// 'auto' follows the device classification; 'on'/'off' force the virtual
+// keyboard either way, for the cases classification gets wrong in either
+// direction — a tablet with a physical keyboard attached, or a phone-sized
+// device the heuristic misreads.
+const OVERRIDES = new Set(['auto', 'on', 'off'])
+
+/** The persisted override, or `'auto'` if storage is unavailable (private
+ * browsing, disabled storage) or holds something other than a known value
+ * (never written by this app, or written by an older version of it). */
+function loadOverride() {
+  try {
+    const stored = window.localStorage.getItem(OVERRIDE_KEY)
+    return OVERRIDES.has(stored) ? stored : 'auto'
+  } catch {
+    return 'auto'
+  }
+}
+
+/** Best-effort persistence: a learner whose browser refuses storage keeps
+ * working for the session, just without the choice surviving a reload. */
+function saveOverride(value) {
+  try {
+    window.localStorage.setItem(OVERRIDE_KEY, value)
+  } catch {
+    // Storage unavailable — the override still applies for this session.
+  }
+}
+
+/** Shown by default — a learner has to opt out, never opt in, to keep the
+ * board there for anyone who hasn't touched the setting. */
+function loadKeyboardVisible() {
+  try {
+    const stored = window.localStorage.getItem(KEYBOARD_KEY)
+    return stored === null ? true : stored === 'true'
+  } catch {
+    return true
+  }
+}
+
+function saveKeyboardVisible(value) {
+  try {
+    window.localStorage.setItem(KEYBOARD_KEY, String(value))
+  } catch {
+    // Storage unavailable — the choice still applies for this session.
+  }
+}
+
+export const useSettingsStore = defineStore('settings', () => {
+  const virtualKeyboardOverride = ref(loadOverride())
+  const isPhone = useIsPhone()
+
+  // A learner who already has a physical keyboard — and can see it works,
+  // since typing has reached this far — may want the board gone entirely
+  // rather than just the OS keyboard suppressed: it is a lot of screen for
+  // something they are not reading off of.
+  const onScreenKeyboardVisible = ref(loadKeyboardVisible())
+
+  // Synchronous, not batched: the choice should survive a tab closed right
+  // after it's made, not wait for a tick that might not come.
+  watch(virtualKeyboardOverride, saveOverride, { flush: 'sync' })
+  watch(onScreenKeyboardVisible, saveKeyboardVisible, { flush: 'sync' })
+
+  // What AnswerInput.vue actually needs: one boolean, the override applied
+  // over the device default.
+  const virtualKeyboardEnabled = computed(() => {
+    if (virtualKeyboardOverride.value === 'on') return true
+    if (virtualKeyboardOverride.value === 'off') return false
+    return !isPhone.value
+  })
+
+  return { virtualKeyboardOverride, virtualKeyboardEnabled, onScreenKeyboardVisible }
+})