--- name: bezel-fidelity-pass description: "Owner's standard for the device bezel/casing: the shipped chrome must reach the approved mockup's fidelity, as a RESKIN not a rearrange — plus the mobile-primary discipline that governs how much of a desktop-heavy frame may ever be ported to a phone." metadata: node_type: project originSessionId: 0b7c5f41-bb34-4ab4-93be-fdb363f5eb40 --- *Rewritten 2026-07-20: the shipped-vs-mockup gap inventory and the sequencing/queue notes were removed — that work landed, and current state is in `library/CODE_MAP.md`, `CHANGELOG.md` and git log. What remains is the owner's durable standard and preferences.* ## ⭐ THE OWNER'S STANDARD (2026-07-08, raised with side-by-side screenshots) **The shipped device bezel/casing read as much FLATTER and LESS IMMERSIVE than the approved mockup.** His instruction: bring the shipped casing up to the mockup's fidelity. Two things about how he framed it are durable: 1. **It is a CHROME FIDELITY pass, NOT a rearrange.** KEEP the arrangement that exists — bottom-docked tab keycaps, the screen/casing-top header, the top-right mini-core. Reskin to the mockup's fidelity at the *same layout*. When he says the mockup looks better, he means the **materiality** (framed rounded casing with real depth, physically raised keycaps, glass framing/vignette, hardware details like a governor dial and a serial plate), not the arrangement. 2. **Hardware flavour text is DATA, not chrome.** The serial-plate line comes from the per-game identity definition, so the casing stays game-agnostic. Never hardcode a game's flavour into the frame. ## ⛔ THE CONSTRAINT THAT GOVERNS EVERY CHROME DECISION **The owner is almost exclusively MOBILE** (360/412 widths — [[docked-ideas]] mobile-primary note). Mockup screenshots are **desktop-width**. On mobile the immersive casing must be a **disciplined, non-intrusive edge treatment** that does not steal content space or overflow at 360/412. **Do not just port the desktop-heavy frame onto a phone** — that was the explicit warning, and it is the failure mode to watch for on any future chrome work. Other hard guardrails: **PWA must stay intact** (installable / offline / standalone keep working); curvature and vignette are **frame-only, never distorting text**; verify live at 360, 412 and desktop. ## ⭐ KEYCAP PREFERENCES (owner 2026-07-08, with a mobile screenshot) 1. **Tab labels must NOT WRAP.** He saw labels breaking mid-word on mobile (OPERATO/R, DATABAN/K) and it reads as broken. Each label sits on ONE line — via nowrap plus a font-size/letter-spacing/keycap-width fit. Label text may be smaller than the input-size floor, but keep the tap target and keycap minimums, and never let it overflow the keycap or the nav row. 2. **The active tab stays PRESSED DOWN.** The selected subsystem keycap should read as **physically DEPRESSED** (inset shadow / reduced relief / translate-down), not merely lit. Drive it off the existing selected-state class the tab switcher already sets — **the pressed look is CSS on the selected keycap; the wiring is untouched.** ## ⭐ LOCATION-CHANGE CONFIRMATION CARD (owner 2026-07-08) When the CURRENT location changes — from the map's travel action, from the position panel, from arrival, **from any path** — show a small confirmation CARD that **slides in from the TOP-RIGHT** with the new location, then **auto-dismisses by fading out / sliding back to the right out of view** (owner: *"fades away / slides back to the right out of view"*). Implementation ruling: hook the **SINGLE location-change choke point** so it fires for every source automatically, rather than adding a call at each call site. Reuse the existing toast/annunciator overlay infrastructure if it fits rather than forking a new one. Reduced-motion safe, **zero campaign-state write**, game-agnostic. ## SEQUENCING DISCIPLINE (why these were held, not stacked) Each of these was issued as a **follow-up AFTER the in-flight session landed**, never stacked onto a running one — spec-lock. Do not add scope to a session that is already building.