--- name: design-overhaul-direction description: "The owner's standing design charter for the visual/identity overhaul — the unlock charter, the north star, and the standing UI rules, in his own words. Build status and protocol numbering stripped; see QUEUE.md and rules/." metadata: node_type: project originSessionId: design-overhaul-direction --- **Owner direction, from 2026-07-02 onward. This is the charter that governs the design overhaul.** *This file previously tracked which units were built, which mockups had shipped, protocol numbers/names, plan-doc line counts, and a phase order. All derivable and some of it stale; stripped 2026-07-20. Sequencing lives in `QUEUE.md`; protocols in `CLAUDE.md` + `rules/`; what shipped in `CHANGELOG.md` + git log. What remains here is the owner's direction and reasoning, which exists nowhere else.* **000. ⭐⭐⭐ THE UNLOCK CHARTER — the assumptions the owner has LIFTED (greenlit all 6, 2026-07-03).** All ON THE TABLE: 1. **The AI/chat's FORM is reimaginable** — not assumed to be a text box. It can be a diegetic Overseer presence (CRT face, voice, character readout) that differs per game. 2. **Navigation can be an EXPERIENCE, not tabs** — move through the terminal like a place (boot into a shell, browse a filesystem, insert cartridges). The whole IA can be diegetic. 3. **Per-game can differ STRUCTURALLY, not just visually** — a salvaged terminal vs a Pip-Boy vs an Institute interface can be organized and operated differently, not just re-palette'd. 4. **First-boot / game-start is a real CEREMONY** — a full "powering on 2077 hardware" sequence (highest-impact seconds). 5. **The whole app is a physical DEVICE, not a webpage** — bezels, screen curvature, device chrome, custom cursor; the phone/browser BECOMES the RobCo hardware. 6. **Permission to BREAK webapp conventions for immersion** — custom scrollbars/cursors, non-standard interactions, audio-forward-by-default (mutable) — **⚠ HARD GUARDRAIL (owner): as long as the PWA isn't broken.** Installability, offline operation, service worker, add-to-home-screen / standalone mode MUST all still work. Immersive convention-breaking is fine; breaking the PWA is not. (Ties to [[project-must-stay-free]] / offline-first.) Say "all on the table" = this charter. The more unlocked, the bolder Fable goes. **00. ⭐⭐⭐ NORTH STAR — THE WHOLE SITE TRANSFORMS** (owner 2026-07-03: *"this site should not be the same at all when we're done with it. ofc it's based off old stuff and we made that the foundation, but the settings mockup from fable is the direction I want to go. so much cooler. ofc directions will have to change per game to adapt to the games and they're settings tho ya know? log that"*). When the overhaul is done the site should be **completely different** — a total transformation, not a reskin. The old app is the FOUNDATION (data layer, systems, correctness), NOT the destination look. The Fable Module Bay mockup IS the bar for the ENTIRE site: that level of diegetic, "you're operating real 2077 hardware" maximalist immersion is what every screen aims for. And it is **PER-GAME** — even "the settings" isn't one design; it becomes each game's own version (NV salvaged terminal / FO3 Pip-Boy / FO4 Institute holo-terminal — see [[per-game-device-form]]). **The PANEL/TAB LAYOUT ITSELF IS NOT SACRED** (owner 2026-07-03: *"the panel layout does not have to remain but if is immersive so I'm not against it either. but definitely not against better / cooler / more immersive designs at all"*). The panel/tab structure and navigation are fully on the table — reimagine the whole layout/IA if a more immersive design calls for it. Don't constrain ideation to "restyle within the existing panels." The owner is unreservedly FOR better/cooler/more-immersive designs. **0. ⭐ OVERHAUL-ERA MANDATE** (owner 2026-07-02, after seeing the Module Bay: *"for the upcoming design overhauls, fable 5 for mockups for sure and forget the no un-prompted redesigns rule. everything should be so much more immersive. take this settings redesign and x2 maybe even x3 it type shit"*): - The old "no unprompted redesigns" restriction is **RETIRED for the overhaul era** — full immersive reinvention is the DEFAULT, not something needing per-instance permission. Preserve muscle memory / a fallback where reasonable, but the blanket "don't redesign" gate is gone. - **Fable does ALL mockups** — every overhaul opens with a Fable mockup for owner approval. - **Crank immersion 2–3× beyond the Module Bay.** The Module Bay is the BASELINE/intro bar; the bigger overhauls should be 2× or 3× more ambitious than that. **0a. ⭐ OVERHAUL-ERA PRINCIPLES (owner adopted all 7 of my brainstorm 2026-07-02, with his nuances):** 1. **Every immersive redesign keeps a LEGACY/classic look available as a low-friction fallback** — you opt INTO the ceremony, never trapped in it. **⚠ BUT during the overhaul the fallback is DEPRIORITIZED** (owner 2026-07-03: *"maybe get rid of schematic view or just hold off and making it compatible until the end of the update… the new UI should take massive priority"*). Do NOT maintain the flat fallback in lockstep as each screen is overhauled — that's a drag competing with the new UI. Let it fall out of date, then either DROP it or RECONCILE it all at once at the END. 2. **Performance + battery = a "back of mind" consideration, NOT a core philosophy.** Keep maximalist visuals smooth on mid-range phones, but don't let perf dominate the design. 3. **A shared RobCo house visual language UNDER the per-game themes** (distinct machines, same build quality) — BUT still SURFACE genuinely divergent per-game ideas; don't suppress a bold unique idea for consistency's sake. Consistency is the default; standout uniqueness gets flagged for the owner's call. 4. **Sound design is a first-class pillar** — hardware sounds, per-game boot/radio audio, tactile SFX. Always mutable + dial-gated, but core to immersion, not garnish. 5. **Accessibility floor = back-burner** (owner's call — keep it in mind, don't let a11y DRIVE the design). Note: the gate's a11y baseline still auto-runs, so a floor holds mechanically regardless. 6. **Mobile as its OWN immersive experience, not a shrunk desktop** — lean into phone-native immersion (the phone literally BEING the Pip-Boy: haptics, tilt/orientation, gestures). 7. **First-boot & game-switch are SHOWCASE moments** — the highest-impact seconds; make them memorable intros, not loading screens. **0b. ⭐⭐ IMPLEMENTATION MUST MATCH THE APPROVED MOCKUP *EXACTLY*** (owner 2026-07-02, a hard lesson from a build he rejected: *"fable gave this as the mockup, I don't see this… I want this exactly"*). When a mockup is approved, the BUILD is a pixel-faithful port of it — the full rich diegetic visuals, not a simplified "reuse-the-existing-plain-control" approximation. That approximation is exactly what the owner rejected: functional but visually far simpler than the mockup. **The gap he saw was VISUAL RICHNESS, not control type — and both are achievable:** style the native accessible control (checkbox/input/select) to LOOK exactly like the mockup's hardware (a checkbox CAN be drawn as a DIP chip / jumper / eject switch). Only drop to a custom control if a native one genuinely can't achieve a specific visual. Every build brief must say "match the approved mockup exactly (rich visuals), keep native controls styled to match." **BUT mockups are a LIVING baseline, not frozen** (owner 2026-07-02: *"add that mockups should be expected to be improved upon on user request"*). "Match exactly" governs fidelity to what's approved; it does NOT freeze the design. Owner-requested refinements are always welcome and expected — the design evolving, not scope creep. **0c. ⭐ EVERYTHING REMEMBERS ON RELOAD** (owner 2026-07-02: *"everything should always remember on reload. add to protocols/rules"*). ALL user-facing state and choices persist across reloads — view toggles, selected tabs/sub-panels, filters, any UI mode the user set. Persist via device prefs; never lose a user's choice on reload. Exceptions: genuinely transient/one-shot states (a mid-animation, a just-opened modal). Any deliberate user CHOICE persists. **0d. TEST-CHURN IS EXPECTED + OK during the overhaul** (owner 2026-07-03: *"there will probably have to be a lot of test updates with the design overhaul. that's expected to me and okay with me, just need proven mockups first and the tests to be adapted to the new code"*). Don't be shy about heavy test rewrites — pre-cleared. The ORDER matters: (1) approved mockup FIRST, (2) build to it, (3) adapt the tests to the new code. Big test updates = fine; skipping the gate = not fine. **0e. 📐 CENTERING RULE** (owner 2026-07-03: *"anytime something is off centered, it should be centered… the last option should be in the middle of the bottom row, if there were only two options, they should be centered too"* / *"the centered thing should be a rule for sure"*). An incomplete final row in any grid CENTERS its remaining items — never left-aligned with an empty gap. More broadly: anything that would sit visibly off-center gets centered. Applies to every grid/layout, present and future. **0f. MOCKUP-FIRST, VERTICAL-SLICE-FIRST.** Every design unit runs mockup → owner approval → deep-reasoning audit → implementation → audit. And prove ONE machine end-to-end (the NV machine) before replicating the pattern to other games. (The specific unit order lives in `QUEUE.md`.) **0g. 🗂️ COLLAPSIBLE SECTIONS ARE STANDARD EVERYWHERE** (owner 2026-07-03: *"collapsing sections should be there regardless, so when we make the changes to make mobile better, we'll be adding those back to everything"*). Every section/panel in the overhauled UI is COLLAPSIBLE, default-OPEN. Not just one panel, not a mobile-only option — a standard across ALL screens (aids density and navigation, especially on mobile). **0h. 📱 MOBILE MUST WORK BEFORE RELEASE — a release gate** (owner 2026-07-03: *"when we implement the actual UI changes, we should make them work on mobile before releasing"*). Every UI change must be genuinely WORKING on mobile before it ships to production, not just desktop. Dev/staging is where mobile is tested and tuned; mobile-working is a hard gate on the production release. Don't leave any overhauled screen mobile-broken or bloated when we ship. **0i. 📱⭐ MOBILE MUST NOT BE AN INFINITE SCROLL — heavy per-view mobile redesign** (owner 2026-07-03, showing the NV desktop mockup as the quality bar: *"by the end of the UI overhauls everything should look so much better / different. remember the mockups? like this. but mobile needs to be heavily adjusted so things look good but don't feel like an infinite scroll"*). Mobile is NOT the desktop layout stacked into one long column — that reads as an endless scroll and the owner explicitly rejects that feel. Mobile needs a genuine, heavy per-view REDESIGN: as polished as desktop but COMPACT and navigable — collapsible sections (0g), paging/tabbing between subsystems, condensing/reflowing dense panels, progressive disclosure — so any single mobile screen is a self-contained good-looking view. This sharpens 0a.6 and 0h: "works on mobile" specifically means "doesn't feel like infinite scroll." Bring the owner concrete density OPTIONS to pick from once the visible pieces are on staging. The mockup screenshots the owner sent (2026-07-03) show the Overseer's LIVING states — a jagged "ESTABLISHING DIRECTOR LINK" waveform vs a calm "LISTENING" sine — confirming the AI presence must be an animated, reactive oscilloscope, not a static graphic. **0j. ✨ DIEGETIC *AND* GENUINELY GOOD-LOOKING/USABLE** (owner 2026-07-03: *"yes this is based on fallout hardware, but the site needs to look good as well ya know?"*). The Fallout-hardware diegesis is the theme, NOT an excuse for clunky, broken, or dated-looking controls. When a literal-retro treatment hurts looks or usability (e.g. a bracket "[?]" help button that wrapped and broke on PC — the owner wants a clean modern round "?" instead), favor the clean modern control that still fits the theme. "It's Fallout hardware" never justifies shipping something that looks bad or works badly. **⭐ THE CRISP ARTICULATION (owner loved this framing 2026-07-04):** RobCo isn't trying to be a literal 1997/2077 terminal — it's *"If RobCo engineers in 2281 somehow had access to modern UX research."* Everything should be **fast, accessible, discoverable, information-dense, and beautiful — while never breaking the illusion.** That's the north star for every design call: modern UX quality, delivered inside the fiction. (Stronger than "copy Bethesda / strip modern features" — which is exactly why the "What would Bethesda do" framing was scrapped. See [[prompt-library-campaign-framings]].) **0k. 🔧 NO FUNCTIONALITY REGRESSION FROM THE OVERHAUL** (owner 2026-07-03: *"everything that can currently be edited, should remain editable after ui changes"* + *"bars should remain movable"*). HARD release-gate rule for EVERY unit: (a) every field/control that is currently EDITABLE (SPECIAL, skills, HP, caps, level, inventory, notes, every tracker the player can change) MUST remain editable — the reskin changes how it LOOKS, never whether it WORKS; (b) interactive value BARS remain movable/draggable, not re-rendered as static display-only graphics. Immersive reskins are authorized; functional regressions are NOT. Every unit's definition-of-done must actually exercise the pre-overhaul edit/interaction affordances. **0l. 🎯 CONSISTENCY BASELINE — the built pieces set the bar** (owner 2026-07-04: *"the settings & configs, comm-link, and tool deck are the baseline. mockups should be better than those but everything needs to hold a consistent theme ya know? might even change the settings & configs to match how the director link looks"*). The already-built overhaul pieces are the QUALITY BASELINE; every future mockup must **meet or exceed** them AND stay thematically CONSISTENT with them — one cohesive machine, not a patchwork. The owner is considering restyling the Module Bay to match the Director Uplink look for full consistency; treat that as a likely future refinement (a living baseline, not frozen — see point 8). **⭐ 0l-REFINED — BASELINE + CONSISTENCY (owner 2026-07-04, across four messages):** *"we redesign EVERYTHING · all designs for a game must MATCH + COMPLEMENT each other · the Comm-Link terminal and Settings menu MERGED TOGETHER is the LOWEST baseline standard."* Two hard rules: (1) the overhaul redesigns the WHOLE app — every subsystem and screen, then per-game machines; nothing left in the old style. (2) CONSISTENCY IS A HARD REQUIREMENT — all of a game's designs MATCH + COMPLEMENT each other. ⭐ **The FLOOR = the Comm-Link (Director Uplink) + the Settings menu (Module Bay) COMBINED.** Evaluate every screen: does it meet that combined bar AND complement this game's other screens? **0m. 🖱️ "NO ADDED CLICKS" IS ON THE BACKBURNER DURING MOCKUP EXPLORATION** (owner 2026-07-04: *"put the no added clicks protocol on the backburner (don't forget, but allow). I want to see what the fable mockups can produce. Ofc don't be obsessive tho"*). The "no increase in tap-count vs the workflow it replaces" guardrail is RELAXED during design exploration. Fewer taps is still better all else equal, but an extra tap no longer hard-blocks a good design. A temporary exploration allowance, not a permanent repeal — tap count stays a design-review criterion. **0n. 🗂️ SUBSYSTEM DIRECTORY → FILE-SYSTEM / FILE-EXPLORER design** (owner 2026-07-04). The flat subsystem index should be reimagined to look like a FILE SYSTEM / file explorer (owner: *"like file explorer for example"*), where pressing a subsystem takes you to a VIEW OF ALL PANELS in it (*"if you know what I mean"*) — each subsystem reads like a folder, opening it shows its panels as "files." Fits the RobCo-OS Filesystem philosophy ([[robco-os-architecture]]). Owner: *"Maybe add that to design and mockup stage."* Must preserve the flat directory's purpose — a plain one-tap way to reach every subsystem — plus hotkeys/routing. **0o. 🧭 TWO PHILOSOPHY CRYSTALLIZATIONS (from the ChatGPT dialogue, owner-endorsed 2026-07-04):** 1. **"EXTEND, don't GAMIFY."** RobCo does NOT add achievements/streaks/badges/arbitrary out-of-game progression — its best features make the player say *"that feels like it should have been in Fallout."* Deepen the existing fiction, don't build a parallel game. (Nuance: the real filter is "would this exist on a RobCo machine IN-UNIVERSE" — which INCLUDES OS/device features like uptime/diagnostics/telemetry, so it extends the FICTION, broader than just the GAME.) 2. **"The TERMINAL becomes proactive; the AI stays a VOLUNTARY interpretation layer over DETERMINISTIC systems."** The correct resolution of the AI-proactivity tension (vs [[player-control-principle]]): the NOTICING is deterministic and native (the timeline sees a run of same-faction quests, reputation consequences, build-archetype detection, quest dependencies, travel history — all computed and authoritative), and the AI only EXPLAINS / roleplays / summarizes those facts WHEN the player chooses to engage. ⭐ CRISP NAME (owner-endorsed 2026-07-04): **"RobCo U.O.S. owns the truth. AI provides perspective."** — expanded: *all persistent state, gameplay logic, calculations, and progression are deterministic and owned by RobCo; the AI never becomes the authority — it's an optional layer for interpretation, explanation, planning, and roleplay.* Use it as the one-line guide for any AI-touching feature. Crisp one-liner for the whole project: *"an offline-first, AI-assisted RobCo OS that extends a Fallout playthrough into a persistent immersive campaign — deterministic systems preserve player control, optional AI adds interpretation/atmosphere/roleplay without becoming the source of truth."* **0p. ⭐ CUSTOM-1-OF-1 PER SCREEN + ESCALATE AMBITION** (owner 2026-07-04: *"take this design, the settings redesign, and the comm link redesign. see how we're making everything feel custom 1 of 1 to itself while all connecting? we need to keep doing that but go bigger and more ambitious for the next redesigns. We might even touch back up on 'the big three' afterwards"*). The proven through-line: each screen earns its OWN custom, 1-of-1 identity while all sharing the same machine language (bezel, BUS-ids, amber-on-phosphor, connector strips, status rows) so it reads as ONE device, not a theme reused. Two standing directives: (1) KEEP doing custom-per-screen-but-cohesive — never copy-paste another screen's layout; (2) GO BIGGER on each subsequent redesign — the built pieces are the FLOOR, the next ones escalate beyond them. Already-built screens may get a further polish pass afterward — living baseline, not frozen. **0q. 🔧 DRESSED CONTROLS MUST BE GENUINELY OPERABLE** (owner 2026-07-04): a reskinned control must be as INTERACTIVE as the plain one it replaces, not display-only — bars draggable, faders draggable, diagram zones clickable — all routed through the EXISTING setters, with editable number fields kept alongside (drag OR type). Standing expectation for every future dressed control: if the old control could be dragged or clicked to change a value, the new immersive version must be too, through the same handler. This is 0k applied to new metaphors. **0r. 📇 COLLAPSED-SUMMARY-LINE IS A STANDARD FOR ALL REDESIGNS** (owner 2026-07-05, seeing the collapsed boards: *"See how there's text under the category title when it's collapsed? Should we do that to settings too? I like it and think I might want to keep that around for all the redesigns"*). Every collapsible board shows a concise, dynamically-accurate ONE-LINE STATUS SUMMARY under its title when collapsed (e.g. "HP 100% · LVL 1 · 0 CAPS"). Owner confirmed: apply it everywhere and KEEP it as a standard. Never hardcoded, always game-agnostic, reusing the existing status-row styling rather than forking. Aids the mobile-density / no-infinite-scroll goal. **1. Full visual overhaul is AUTHORIZED.** The owner is *"entirely okay with the design overhauls changing how the site looks entirely… even if it changes how everything looks including panels."* The look, panels, layout, and CRT/identity treatment can all change substantially for immersion. Keep the *spirit* of UX stability — don't gratuitously break how users actually do things where muscle memory is easy to preserve — but the visual language is open to full reinvention. **2. Native-first, AI-second — BUT the AI stays a PROMINENT, large part of the screen.** Priority order is native-first (the player drives; native panels/tools lead), AI-second. BUT the AI interface is NOT to be shoved into a corner — *"the AI takes up a big part of the screen."* The owner wants BALANCE: native panels get prominent space AND the AI keeps a large, important presence. Don't minimize the AI to make room for native. (Consistent with [[player-control-principle]]: AI is opt-in and never authoritative, but it remains big and visible.) **2a. The AI/chat is DESIGNED INTO each game's device metaphor** (owner 2026-07-02: *"fnv is a terminal, it should have a chat presence ya know? think like that"*). Not a generic chatbox bolted on: on FNV (a salvaged RobCo TERMINAL) the chat should feel like a terminal session (teletype/CRT command-response presence — a terminal *has* a console presence by nature); on FO3 (Pip-Boy) and FO4 (Institute holo-terminal) it's framed to fit those devices. The AI's prominent screen space is realized diegetically and DIFFERENTLY per game. **2b. 💬 CHAT/TRANSCRIPT LOOK (owner 2026-07-04).** The owner found the transcript messy — text bouncing between center/right/left with poor space usage. He wants it **cleaner with better space usage**: consistent, left-anchored, tidy terminal-log feel. Fable mocked a side-by-side comparison (tag-above vs inline `OVERSEER:`) and the **owner chose the tag-above style with the chevron on user lines and log prefixes** — NOT Fable's recommended inline style. The real win is the shared cleanup: every line left-anchored and full-width, hanging indent on wrapped rows, sender voice carried by color/weight/size. The label is derived from the sender at render time, display-only, never written into stored history (no double-prefix on replay). **3. Games should TRULY feel game-specific + immersive.** Per-game identity should be deep, not a palette swap — NV vs FO3 vs FO4 should feel like genuinely different machines (see [[per-game-device-form]]). **4. PROTOCOL CHANGES ALLOWED — but ASK FIRST.** The overhauls *"might have to change protocols to adapt, that's okay but ASK ME FIRST and tell me what changes and why."* Before amending or relaxing ANY protocol to accommodate the overhaul, surface the specific change + rationale and get approval. NEVER silently change a protocol. This is about UI/UX-stability protocols that would otherwise block visual reinvention — mobile/a11y invariants and safety/data protocols are not the target. **5. MOBILE + PC BOTH FULLY WORK — designs MAY differ per platform** (owner 2026-07-02: *"everything needs to work on mobile as well, even if designs are different on PC vs mobile"*). Mobile is a hard requirement, never an afterthought. The nuance: PC and mobile may have GENUINELY DIFFERENT designs/layouts — not merely one responsive layout that scales — as long as BOTH are fully functional and hold the mobile invariants (no horizontal overflow at 360px, readable focusable inputs, adequate tap targets, touch-first, no hover-only). Platform-tailored designs are fine; a mobile-broken design is not. **6. INTENSITY — the per-game overhaul must be BIG + VERY NOTICEABLE** (owner 2026-07-02: *"I want the per game overhaul to be very big and noticeable ya know"* / *"I want this to be major but it must be done right"*). Not subtle, not a palette tweak — each game must look and feel DRAMATICALLY distinct. Bold and immersive. But "done right" — big AND rigorous, not big-and-broken. **7. MODEL ASSIGNMENT.** ⭐ **FABLE-AT-WILL** (owner 2026-07-03: *"remember you are allowed to use fable at will as well, change the ai protocol / rule to include that"*). I am explicitly authorized to spin up Fable WHENEVER a creative/aesthetic/immersive/writing task benefits from it — not only at a formal "design pass." No need to ask first. Applies to mockups, diegetic copy, visual exploration, naming, atmosphere/voice text, ideation. Standing model-selection rule (mirror in [[session-management-rule]]): **Fable = creative, Opus = deep reasoning/audit, Sonnet = implementation, Haiku = cheap/mechanical** — pick per task automatically, and reach for Fable freely. The split exists because it delivers both halves of point 6: Fable's vision gives "major," rigorous audit gives "done right." **8. COMPREHENSIVE — every menu/panel/screen is accounted for** (owner 2026-07-02: *"the design planning / audits should take every menu into consideration… everything should fit, nothing should be left behind. if something doesn't need editing, that's fine. just keep everything in mind"*). Every design pass must ENUMERATE every menu, panel, sub-panel, modal, and screen and state how each fits. Items that don't need changing are explicitly noted as "no change," but everything is considered. A design that redoes some panels and silently leaves others in the old style is a fail. **Already-built pieces are BASELINE but NOT frozen** (owner 2026-07-03: *"when the UI overhaul hits… this should be baseline. but I want settings to be included in the audit as well since everything is on the table and so much more could change"*). Don't treat any shipped overhaul piece as done-and-locked when a bigger overhaul comes through — it's a living baseline the overhaul can elevate. **9. DEV-CONSOLE TRIGGER RULE** (owner 2026-07-02: *"it's fold in to add protocols/rules to add features to the dev menu where possible right?"* / *"maybe add that to the design audit"*). Whenever a new ambient/atmosphere/conditional/hard-to-trigger feature lands (broadcasts, weather, boot flavors, encounters), it ALSO gets a trigger/control in the staging-only dev console so it stays testable on demand — the console is the standing test surface that GROWS with the app. The comprehensive UI-surface inventory (point 8) includes verifying every testable feature has or gets a console trigger. Ties to [[docked-ideas]] and [[session-management-rule]]. **10. PLAY-ALONG FOLDS INTO THE COMMAND LINE — no separate quick-log bar** (owner 2026-07-02: *"play-along should just go into the terminal no? shouldn't need a whole new bar?"*). Correct and more diegetic: a terminal has ONE command line. Quick-logging ("killed deathclaw", "+50 caps", "arrived novac", "rep ncr up") becomes a CAPABILITY OF THE COMMAND LANGUAGE on the existing input, NOT a new UI bar. **The problem it creates:** the single input already routes freeform → AI and native commands → the router; quick-log is a THIRD route needing fast, unambiguous disambiguation. **The owner's mechanism, LOCKED** (2026-07-02, *"lock that in"*): an **INLINE MODE PILL** inside the command input — his reference was *"like how Claude is"* (the model-selector chip): - Tap the pill to swap `TERMINAL` mode (native commands + quick-log routing) ⟷ `OVERSEER`/AI mode (freeform → narrator). The prompt glyph changes per mode so you always know where text goes. Explicit mode beats fragile auto-guessing. - **One-off override prefix (owner-refined):** a leading `/` sends THAT ONE message to the other mode, and only when it is the FIRST character (a `/` mid-message, in a URL or date, is literal text). Must work both as `/msg` and `/ msg`. The reverse `@` ping is treated IDENTICALLY (owner: *"same popup and space rule for @ ping as well"*). - **Hint popup for BOTH `/` and `@`:** when the input starts with either override char, show a small popup indicating the message will route to the other mode (e.g. "→ sending to OVERSEER") so it's obvious before hitting enter. - Last-used mode persists. Obvious native command tokens still work regardless of mode. The AI stays prominent — the pill only routes the INPUT, it doesn't hide the AI. **11. POPUP MENUS MUST BE SKIPPABLE — close/X on every one** (owner 2026-07-02, on the combat/encounter flow: *"make sure menus that popup have an X so they can be closed if not needed (like loot, sometimes you don't want to loot anything)"*). Each popped menu (especially LOOT) needs an explicit close/X so the player can skip a step without being forced through it. **12. MODULE BAY — the approved design + owner's decisions (2026-07-02).** Settings reframed as installable hardware: a service hatch → chassis backplane with board slots + a service tray; every device pref is a physical module (VDU optics, sonic processor with per-channel chips + eject-as-mute-all, power cell bay, atmospheric regulator/immersion dial, AI uplink co-processor). Owner's five decisions, all locked: 1. The hatch ceremony is **FIRST-VISIT ONLY**, then the bay just opens on expand (no repeated unscrew). 2. **FLIP the mute chips to "installed = audible"** — invert the presentation; the underlying stored pref is unchanged. Test carefully. 3. **KEEP the flat-list fallback view permanently — but it is an AFTERTHOUGHT, NOT priority** (owner: *"we're full force on new UI"*). Build the hardware UI as the star; don't over-polish the fallback. 4. **KEEP the amber AI-uplink slot identity** — it's the external/network piece, distinct from local hardware. 5. **YES to install/eject SFX** (socket thunk / chip click), wired through the audio system so master-mute and a toggle turn them off. **Protocol sign-offs the owner gave at the same time:** approved adding a sanctioned-exception clause for owner-approved redesigns (guardrails: same location/tab, no extra taps, fallback preserved, stored semantics unchanged); approved the internal-heading convention; and **overrode my recommendation on collapsible sub-panels** — they STAY collapsible with persistence, but DEFAULT to ALL-OPEN on first boot. Owner: *"immersion is the reason, but ease of accessibility/annoyance should be considered too… remain collapsible, all open on first boot."* **Structural lesson from that build:** the risky part was that a desktop two-column layout had to be gated on CONTAINER width, not a viewport media query, because the panel lives in a narrow shell column. Both the dressed view and the flat fallback are regenerated projections of the same stored prefs — one truth, no drift. **13. 🪟 MOVABLE / REARRANGEABLE PANELS** (owner 2026-07-03: *"pc should be considered too, I want the panels to be moveable like a tab is ya know?, but they should be able to snap back into place and be rearranged too. rearranging should be allowed on mobile too even if it's just through a menu, I don't want movable panels on mobile tho bc that wouldn't do well"*). A platform split: - **DESKTOP: panels are MOVABLE (drag, like a tab/window)**, and CAN be **free-floating** (owner: *"they can be free floating, but should be able to be snapped back in too"*) — not forced into slots, but able to SNAP back. ⭐ When a drag is over a valid snap position, **HIGHLIGHT where it will land** (a drop-zone/insertion preview, like modern browser tab-drag or window managers). - **MOBILE: NO drag-to-move** (owner: *"wouldn't do well"* on touch) — but rearranging IS allowed **through a MENU** (a reorder list with move-up/down or a drag-handle list). Same capability, different mechanism. - **Persist the arrangement across reload** (per 0c) as a device pref. - **The bottom bezel nav does NOT rearrange itself** (owner: *"bottom bezel nav shouldn't rearrange, but still works for rearranged menus ya know?"*). The subsystem keycaps stay in FIXED order and are not part of the drag system — but must still correctly route to whatever the user has moved. The nav bar is a stable anchor operating rearranged content. - **Hotkeys follow the KEY, not the position** (owner: *"1 - 5 should follow key, not order"*). Each hotkey stays bound to its subsystem regardless of layout. - **⭐ ADOPTED refinements** (owner 2026-07-03: *"add everything you said. layout is per game, layout can stay local for now, do diegetic framing too"*): per-game layout (each machine has its own saved arrangement and default); layout stays a LOCAL device pref for now, not cloud-synced (revisit cloud-travel later); diegetic framing per machine (on the NV salvaged terminal, "rearranging" is re-seating CRT modules on the bus, not a generic window manager); reset-to-default per game + named layout presets; a Lock Layout toggle; off-screen clamp so floating panels are never lost on resize + bring-to-front on click; resizing, minimize-to-title-bar, hide/show subsystems; a drag-handle so dragging never fights clicking inside a panel; snap zones with the live drop preview; a first-time discovery hint; a mobile arrange menu with live preview, reset and the same lock; and keyboard-move for accessibility. **14. ⚙️ SETTINGS/CONFIG IS ITS OWN DEDICATED TAB** (owner 2026-07-03: *"settings and configs should be removed from all the bottom tabs and turned into it's own separate tab"*). ALL settings/configuration consolidates OUT of the other tabs into ONE dedicated SETTINGS destination in the bezel nav. **Owner re-resolved this after first saying CHASSIS could absorb it:** *"make settings and configs its own tab, I forgot there is other stuff in chassis"* — CHASSIS holds other system content, so settings gets its own keycap and CHASSIS keeps its non-settings content. **Owner's decisions on the approved mockup (2026-07-04):** SAVES **move into Settings** (all account/config/saves in one place); the keycap word is plain **"SETTINGS"**; the account slot is framed as a registry port; the hatch ceremony **REPLAYS on first visit to the new tab** (kept as a showcase moment). **+ CAMPAIGN CONFIGS also go in Settings** (owner 2026-07-04: *"campaign configs needs to go in there too. Can't forget to modernize it either tho"*) — campaign mode, RNG mode, playthrough type, difficulty. And they get MODERNIZED, not merely relocated: don't move the old plain controls over, bring them up to the Module-Bay/Director-Uplink aesthetic and the 2281-modern-UX north star. **+ CHASSIS reorganization (owner 2026-07-04, "your recs is good"):** the Overseer's Log is really two halves — device telemetry (uptime, power-on, boot count, session length) and campaign record (kills, caps, damage, collectibles, visits, plus a reset). SPLIT them: CHASSIS becomes SYSTEM STATUS (device health, version/cache, connection, feature-flag status) + the firmware revision log (changelog viewer) + error-log access; the CAMPAIGN half moves to the databank as its own panel, because it's campaign record data, not system data. **⭐ ACCOUNT BOARD — adopt the whole mockup, BUT its status WORDS must DYNAMICALLY UPDATE** (owner 2026-07-04: *"the whole design actually, words need to dynamically update though"*). Every diegetic status string (no-operator-on-record, offline/online, the sign-in prompt, the operator identity line) must reflect REAL auth and cloud-sync state and update LIVE. Do NOT ship it with hardcoded status strings. **15. 🔁 IMMERSION SETTINGS — user-facing "replay one-time events every time" toggles** (owner 2026-07-03: *"there should be immersion settings for one time events so you can make them happen every time. they should always be automatically off but save to the users settings and should stay updated with new features of the sort"*). A USER-facing settings section (distinct from the dev-console replay triggers in point 9) with toggles that make normally-once events REPEAT — the hatch ceremony, cold-start/degraded boot, first-visit ceremonies, game-switch showcase, and any future one-time moment. Rules: (a) every toggle DEFAULTS OFF; (b) the choice PERSISTS to the user's settings; (c) the section AUTO-GROWS — any new view-once/ceremony feature registers both its dev-console trigger (point 9) AND a user immersion toggle here. This is the player-control, opt-in way to re-experience showcase moments without a reload. Applies mainly to the organizing-layer and game-identity work, and any panel/layout work. Related: [[robco-os-architecture]] (diegetic OS philosophy), [[per-game-device-form]], [[player-control-principle]], [[queued-fixes]].