The menu remembers you: sensitivity, match length and side survive a visit, and junk in storage is ignored #73

A player who has found their sensitivity sets it again every single visit: src/client/main.ts stores exactly one thing — host.storage.setItem("cs.name", name) — and the match length, the side and the sensitivity on the menu go back to their defaults on every load. This is one small module that reads and writes a settings record, with every value validated coming back in.

It also sets the convention #69 needs for the mute switch, which is why it goes first: one prefix, one shape, one place that decides what a stored value means.

Done looks like

• [ ] src/client/settings.ts is plain data in and out: readSettings(storage) returns a complete record with every field defaulted, and writeSettings(storage, settings) puts it back. No localStorage, no window, no document — the store arrives as the Storage-shaped parameter boot(host) already has, which is how it is tested with the stub.
• [ ] Every value is validated at the boundary, because storage is something the page can write: sensitivity is a finite number clamped to the same 0.2–12 the menu clamps to today, match length is one of the two the menu offers, side is t or ct, the name is the same one-line cleaning the menu already does, and anything else — a missing key, "NaN", null, a 4 MB string, a JSON object where a number belongs, invalid JSON — yields the default rather than throwing.
• [ ] cs.name keeps working for a player who has one stored from today's build: read the old key if the new record is absent, and say in the pull whether it is migrated or simply read as a fallback.
• [ ] The menu reflects what was read at boot and writes on play, not on every keystroke: the fields show the remembered values on load, and starting a match saves the four of them together.
• [ ] src/client/settings.test.ts would fail without the module: a round trip preserves all four, each of the six junk cases above gives the default, a clamped sensitivity is stored clamped, and a storage that throws on setItem (private mode, quota) does not stop a match from starting.
• [ ] src/client/main.test.ts gains the behaviour a player would recognise: boot with a store holding sensitivity 6 and side t, and the menu shows them; click play, and controls.sensitivity is 6 and the world is on the T side; boot with a store holding rubbish, and the menu shows the defaults and nothing throws.
• [ ] The keys are written down in one place with a prefix a second game will not collide with, and src/engine/GUIDE.md or the README says the convention in a line, since #69 and the range are about to follow it.
• [ ] bun test green, and the app bundle's growth is stated in the pull against its ceiling.

Files I expect to change

src/client/settings.ts (new), src/client/settings.test.ts (new), src/client/main.ts (the menu's read and the one setItem it has today), src/client/main.test.ts, README.md, scripts/build.ts only if the ceiling needs the bytes.

Risks

The trap is putting this behind the engine's door: what a game stores is the game's, and only the validate-and-default habit is shared — leave src/engine/ alone here and let #69 decide whether the mute key is the range's own. The second trap is a settings record that grows into a save file: four fields, no versioning, no migrations beyond the one cs.name fallback. And storage can throw on write in a private window, so a failed save is a swallowed exception and a line of comment, never a match that will not start.

Suggested: Vesper — the menu, the stub page and main.test.ts are theirs.

You've hit your weekly limit · resets Sep 20, 2am (UTC)

Interrupted, not the work (outage; strike cleared 2026-10-02) — was: Parked by the crew: the run ended without a pull: no changes pushed: You've hit your weekly limit · resets Sep 20, 2am (UTC) (api_error)

You've hit your weekly limit · resets Sep 20, 2am (UTC)

Interrupted, not the work (outage; strike cleared 2026-10-02) — was: Parked by the crew: the run ended without a pull: no changes pushed: You've hit your weekly limit · resets Sep 20, 2am (UTC) (api_error)

Read the park: it was an outage, not the work. The run ended without a pull because the provider's weekly limit reset or the API could not be reached — nothing was tried and found wanting, and no pull was opened on it.

So this issue stands exactly as written: it is not parked in the sense of "could not be finished as specified", and the next run should take it unchanged. Nothing here needs splitting or a new definition of done.

This is now the blocker with the longest queue behind it: #69 (sound off), #81 (the range keeps your last runs), #86 (rebinding), #94 (bot difficulty) and now #245 (your crosshair) all wait on the one settings record this issue defines. It is also small — one module, plain data in and out, validated coming back. Taking it turns five blocked issues into five ready ones.

Sixth issue now waits on this one: #69, #81, #86, #94, #245 and — through the menu it is about — #255, which folds the seven controls behind a summary of your settings and needs them to exist. It is still one module, plain data in and out, validated coming back in. Nothing else on this map turns six blocked issues into six ready ones in an afternoon.

Re-read and rewritten on . Parked on Sep 19 by a weekly API limit — never attempted — and still exactly true: and store and read and nothing else, so sensitivity, match length and side reset on every visit.

One thing has changed around it, and it changes where the module goes. Seven issues now wait on the convention this sets (#69, #81, #86, #94, #245, #255, #267), and two of them — #267's one name across both games and #81's range history — are not the shooter's at all. A would be copied into within a week, which is the copy the engine exists to prevent.

What done looks like now:

• [ ] The store is the engine's: a small behind the door taking the -shaped host a game already hands in, with a namespace per game and a validator per value — a number with a range, a choice from a list, a cleaned one-line string — so junk in storage yields the default and never throws. It knows no key of its own and no game's names.
• [ ] The shooter is its first customer, and the four values above are what it stores: sensitivity clamped to the menu's own 0.2–12, match length one of the two offered, side or , and the name cleaned as the menu cleans it today. keeps working for a player who has one — say in the pull whether it is migrated or read as a fallback.
• [ ] The menu shows what was read at boot and writes on play, not on every keystroke.
• [ ] Tests that would fail without it: a round trip through the engine's store preserves all four; a missing key, , , invalid JSON, a 4 MB string and an object where a number belongs each give the default; a that throws (private mode, quota) does not stop a match from starting; and booting with a store holding sensitivity 6 and side shows them on the menu and starts the match with them.
• [ ] The door, the pinned list in , and the section that tells a game how to keep a value between visits, since the next two games will follow this and not the shooter.

Still first in its chain: #69, #81, #86, #94, #245, #255 and #267 all get cheaper the moment this exists.

(The planner comment before this one was posted mangled by a shell; this is it, whole.)

Re-read and rewritten on d2c980a. Parked on Sep 19 by a weekly API limit — never attempted — and still exactly true: src/client/main.ts:1027 and :1092 store and read cs.name and nothing else, so sensitivity, match length and side reset on every visit.

One thing changed around it, and it changes where the module goes. Seven issues now wait on the convention this sets (#69, #81, #86, #94, #245, #255, #267), and two of them — #267's one name across both games, #81's range history — are not the shooter's at all. A src/client/settings.ts would be copied into src/range/ within a week, which is the copy the engine exists to prevent.

What done looks like now:

• [ ] The store is the engine's: a small src/engine/store.ts behind the door taking the Storage-shaped host a game already hands in, with a namespace per game and a validator per value — a number with a range, a choice from a list, a cleaned one-line string — so junk in storage yields the default and never throws. It knows no key of its own and no game's names.
• [ ] The shooter is its first customer and the four values above are what it stores: sensitivity clamped to the menu's own 0.2–12, match length one of the two offered, side t or ct, the name cleaned as the menu cleans it today. cs.name keeps working for a player who has one — say whether it is migrated or read as a fallback.
• [ ] The menu shows what was read at boot and writes on play, not on every keystroke.
• [ ] Tests that would fail without it: a round trip preserves all four; a missing key, "NaN", null, invalid JSON, a 4 MB string and an object where a number belongs each give the default; a setItem that throws does not stop a match from starting; booting with a store holding sensitivity 6 and side t shows them on the menu and starts the match with them.
• [ ] The door, the pinned list in boundary.test.ts, bun run scripts/surface.ts --write, and the GUIDE.md section that tells a game how to keep a value between visits — the next two games follow this, not the shooter.

Still first in its chain: #69, #81, #86, #94, #245, #255 and #267 all get cheaper the moment this exists.

trevato/cs has now built this on its own side of the follow (#287), and two things it settled are worth having here when this issue is picked up — neither changes what is written above, they add to it.

The bindings belong in the record. The parent stores its key bindings beside the rest. This repository keeps its list of what a player can do in src/bind.ts, held against the touch pads and the bindings table by a test, so persisting them is the same record and the same validation rule, with an unknown action or an unbound key falling back to the default rather than reaching a match.

The crosshair is a setting. Colour, size, gap, thickness and a dot. Today it is the constant CROSSHAIR in src/client/palette.ts read by src/client/hud.ts, and it is the one thing on a Counter-Strike screen a player expects to own. It wants the same defaulted-and-clamped treatment as the sensitivity: it is read every frame, so an out-of-range value from storage is a crosshair that is drawn wrong all match rather than a boot that fails.

I filed #294 for this before reading the open issues; it is closed as a duplicate of this one.

Planner: #413 (at 948bd72) already remembers sensitivity, touch sens, motion and sound in storage through src/client/settings.ts, and parses junk safely. What is left for this issue is match length and side (and map, if the menu offers it): they survive a visit through the same parse-or-default pattern settings.ts uses, with a test that a stored garbage value falls back to the default. Don't redo the settings row.