# SETTINGS Tab — Design Notes (mockup for owner review) **Files:** `settings-tab.html` (self-contained mockup) + the `settings-tab-*.png` screenshots in this folder. ## What this is The approved direction made concrete: settings/config gets its **own dedicated tab** on the bezel — a **7th keycap, `[6] SETTINGS`** — and that tab is the one home for **everything config + account**: 1. **ACCOUNT — Operator Registry** (Google sign-in / sign-out, shown as an amber "REG PORT" board with an ID-card motif; both signed-out and signed-in states are mocked). 2. **The Module Bay, unchanged** — SLOT 01 (optics/tubes/high-lumen), SLOT 02 (13 audio chips + radio + print-rate trim), SLOT 03 (power cell + haptic solenoid), SLOT 04 (immersion dial), SLOT 05 (AI uplink / Gemini key, amber), SVC TRAY (maintenance tools). The shipped hardware design is reused verbatim — not redesigned. Settings/config is **removed from every other tab**. CHASSIS `[5]` keeps its non-settings SYSTEM content — the mockup's CHASSIS placeholder proposes: save archive, Overseer's Log, firmware/system readouts (see open question 1). ## The 7th keycap - **Position:** after CHASSIS, before DIR — so the row reads `[1][2][3][4][5][6] · [0]`, keeping the number order literal and DIR at its familiar end seat. - **Hotkey:** `[6]`. DIR stays `[0]`. - **Label:** `SETTINGS` with sub-label `CONFIG·ACCT` (real plain-English label rides along, per the redesign guardrails). A thin amber service-stripe on the cap face marks it as the "open the service panel" key without breaking the keycap family. - **Centering rule:** keycap widths are tightened (`clamp(46px, 12.2vw, 88px)` vs the 6-key bezel's `15vw/96px`) so **seven caps hold a single centered row at 360–412px** (verified: no horizontal overflow at 412). The cluster keeps `flex-wrap + justify-content:center`, so if it ever wraps, the incomplete row centers. - **DIRECTORY fallback** gains a matching 7th row (`SETTINGS — config & account · [6]`). ## How the tab is organized (mobile-compact, no infinite scroll) Every board is a **collapsible section** whose *closed* state is a one-line status row (LED + title + live status + slot tag) — so the phone view is a short stack of 7 rows, and a collapsed board is never information-free: - **Mobile default:** ACCOUNT + SLOT 01 open, everything else collapsed. Whole tab ≈ two screens tall. - **Desktop:** all boards open in the existing two-column bay grid (ACCOUNT and SVC TRAY span both columns); the Overseer column stays on the right as on every subsystem. - **Order:** ACCOUNT first (small, and the thing you look for by name), then SLOT 01→05, then SVC TRAY. SLOT 05's key-sync jumper cross-references "SEE REG PORT ABOVE," which is the payoff of having account and the AI key on the same tab. - **SCHEMATIC VIEW** stays in the tab header — the flat muscle-memory fallback is unchanged. ## Build invariants (noted in the mockup banner; this file is design-only) Hotkeys `[1]`–`[6]` + `[0]`, `role=tab`/`aria-selected` ARIA, `#go=` deep-links, MetaStore persistence (`robco_bezel_subsystem`, per-board `data-sub-id` open/closed memory per Protocol UI-2/UI-6), ≥28px tap targets, ≥16px inputs, and the Schematic fallback must all be preserved when this is built. Board summaries are `<details>/<summary>` (44px min row height). Copper edge-connector strips use `background-repeat: round` (Suite 160 stray-pin rule). ## Open questions for the owner 1. **What exactly stays on CHASSIS `[5]`?** The mockup proposes: SAVE ARCHIVE (slots/cloud/version history/import-export), OVERSEER'S LOG, and firmware/system readouts. But the save archive could arguably belong on SETTINGS too ("everything account + data" in one place). Current mockup keeps saves on CHASSIS so SETTINGS stays purely device-config + identity — confirm or flip. 2. **Keycap wording:** `SETTINGS` is the plain, safe label. If a more diegetic cap is preferred, `SERVICE` (service panel fiction, matches the hatch) or `CONFIG` both fit the 46px cap — the plain label would then move to the sub-label. Mockup ships with `SETTINGS`. 3. **Account board slot fiction:** mocked as `REG PORT` (a registry port above the numbered slots) rather than `SLOT 06`, so the bay's five-slot hardware fiction stays intact. Alternative: make it `SLOT 00`. 4. **Hatch ceremony:** with the bay now living on its own tab, does the first-visit hatch ceremony play on first SETTINGS visit (same `robco_bay_opened` pref), or retire? Mockup omits the hatch (assumed: keep, triggered on first `[6]` visit). ## Screenshots | File | What it shows | | --- | --- | | `settings-tab-bezel-412.png` | The new 7-keycap bezel at phone width, SETTINGS `[6]` lit | | `settings-tab-bezel-desktop.png` | The same bezel at desktop width | | `settings-tab-412.png` | Full SETTINGS tab at 412px — Account open + SLOT 01 open, rest collapsed | | `settings-tab-412-audio-open.png` | 412px with SLOT 02 expanded — 13 chips, odd chip centered | | `settings-tab-412-account-signedin.png` | 412px, signed-in registry state, all boards collapsed (the shortest view) | | `settings-tab-desktop.png` | Full desktop desk-terminal — 2-col bay grid + Overseer column + bezel | All shots verified: no horizontal overflow at 412px; incomplete rows (tubes, chips, keycaps) center.