# COMMAND CLUSTER REDESIGN — Rationale > **Design mockups only.** Companions to `command-cluster-option-{a,b,c}.html`. Nothing here > touches app code; all interactions are faked. Open each file in a browser — every option shows > a MOBILE (360–412px) frame and a DESKTOP Director-column frame side by side, with live faked > interactions (tap the tools; they emit a `▸ …LAUNCHED` line into the transcript). > > Scope: the UPLINK "COMMAND CLUSTER" tray (target/item input + THREAT · VATS · TRADE · LOOT · > CONSULT · V.A.T.S. CALCULATOR, plus the D-PAD). **TERMLINK and CROSSROADS are retired and > appear in none of the options.** Aesthetic matched to `nv-machine-mockup.html` (amber = the > wire, keycap hardware language, steel casing, etched labels). --- ## The shared diagnosis (why the current tray feels cluttered) The shipped cluster is **three unrelated visual systems stacked**: a collapsible D-PAD details block, a standing full-width TARGET/ITEM input, and a 2-column grid of seven bracket-buttons of three different widths (half / full / full-with-different-font). Nothing shares a row height, the target input takes standing space even though only 2–3 tools ever read it, and the whole thing reads as a *panel of web buttons* rather than part of the machine. All three options attack the same three problems: **one visual system, no standing target field, fewer/regularized rows.** --- ## Option A — "FUNCTION-KEY RAIL" *(recommended)* **Idea:** the cluster collapses to **one slim row of six mini hardware keycaps** (F1–F6: THREAT, VATS, TRADE, LOOT, CONSLT, CALC) docked under the transcript card — the same keycap language as the DO-N bezel nav, so it reads as more of the machine's bezel, not a panel. Tools that take an argument (THREAT ▸, CONSULT ▸) flip the rail **in place** into an ARM state — `THREAT ▸ [target] [⏎] [✕]` — same row, same height, no second surface. Direct tools launch on one tap. - **Footprint:** ~64px standing (etch line + key row). No collapsed/expanded tray state to manage anymore — it is small enough to simply always be there, on mobile and desktop alike. - **Taps:** direct tools = 1 tap (today: expand tray + tap = up to 2). Argument tools = tap + type + fire (same as today's type + tap, but the field only exists while you need it). - **D-PAD: dropped.** Its four macros survive as typed TERMINAL-mode input; the transcript gets the space back. (If the owner objects, a seventh `PAD` keycap could arm a one-row ▲◄►▼ state the same way THREAT arms — noted as a variant, not mocked.) - **Tradeoffs:** six keycaps at 360px means small (8px) labels — legible in the mockup but near the floor; CONSULT abbreviates to CONSLT. The two-stage ARM interaction is new muscle memory for THREAT/CONSULT users. ## Option B — "TOOL DECK" (single launcher, zero standing footprint) **Idea:** the cluster's standing footprint goes to **zero**. One new dashed **◈ key in the composer toolbar** (next to [+]) raises a bottom-sheet TOOL DECK inside the glass: a shared target/topic field on top, six full-width tool rows — each with a plain-English one-line job description and a `USES TARGET` tag — and the D-PAD tucked at the bottom. Scrim-tap / ✕ / Esc close it. - **Footprint:** 0px — below the composer there is nothing but transcript. The cleanest possible mobile read; the "infinite scroll" complaint cannot recur by construction. - **Taps:** every tool costs exactly 2 (◈, then the row). Argument tools are arguably *better* than today: the field, the description, and the launch live in one focused surface. - **D-PAD: tucked** — kept fully functional but out of the standing layout entirely. - **Discoverability bonus:** the descriptions make the deck double as the tools' help surface — good for a returning player who forgot what [CONSULT] does. - **Tradeoffs:** +1 tap on every use, always; the tools are invisible until you know the ◈ key (mitigate with a first-run hint or keeping the key lit). An overlay sheet is also a slightly bigger build than A (focus trap, scrim, Esc — though `openModal()`/the WU-C13 pattern already exists to reuse). ## Option C — "FIRE-CONTROL SELECTOR" (most diegetic) **Idea:** the six tools become **channels on one piece of hardware**: ◂ ▸ steppers around an amber LCD channel window (with six position LEDs, tappable for direct selection), a one-line channel description, one shared TARGET field, and a single **ENGAGE** key. Channels that take no argument dim the target field to a dashed socket reading `NO ARGUMENT — DIRECT LAUNCH`. The selector remembers its channel, so repeat use of one tool is a single ENGAGE tap. - **Footprint:** ~150px standing (selector + engage row + micro-pad row) — bigger than A, far smaller and *calmer* than today: three regular rows of one visual system. - **Taps:** best-in-class for *repeat* use of one tool (1 tap); worst for *hopping* between tools (dial ◂ ▸ up to 3 steps, or tap a 6px LED — small target). Only one tool is visible at a time, so the other five are hidden from a glance. - **D-PAD: shrunk** to four micro keycaps on one slim etched row (28px targets held). - **Tradeoffs:** the dial interaction is charming but slower for tool-switchers; the position LEDs at 6px are below the 28px tap floor (they're a redundant shortcut — the steppers are the compliant path — but that nuance would need care in a real build). --- ## Comparison at a glance | | A · FUNCTION-KEY RAIL | B · TOOL DECK | C · FIRE-CONTROL | |---|---|---|---| | Standing height (mobile) | ~64px | **0px** | ~150px | | Taps: direct tool | **1** | 2 | 1 (if dialed) / 2–4 | | Taps: argument tool | tap → type → fire | 2 + type | type → ENGAGE | | All tools visible at a glance | **yes** | no (behind ◈) | no (one at a time) | | D-PAD | dropped | tucked in deck | shrunk micro-row | | Diegetic fit | keycap bezel language | sheet = least hardware-like | **strongest** | | Build size | small | medium (overlay) | medium (state machine) | ## Recommendation **Option A.** It is the only option that keeps every tool one tap away *and* visible at a glance while cutting the standing footprint by roughly three quarters — and its keycap language means the cluster stops being "a panel of buttons under the chat" and becomes part of the machine's bezel, which is exactly the DO-N/DO-O direction. It also deletes a whole state axis (the open/collapsed tray and its desktop-exception wiring in `_wirePanelPersistence()`). If the owner's priority is strictly "maximum transcript, minimum chrome," **B is the better pick** — zero standing footprint is unbeatable — and A and B compose naturally later (B's deck could become the long-list home if the tool count ever grows past what one rail row holds). C is the most characterful and worth keeping in the idea bank for a hardware-dense surface (e.g. a future OPERATIONS dressing), but for a quick-launch cluster its one-tool-at-a-time window fights the "fast access" goal. ## Open questions for the owner 1. **D-PAD verdict:** the three options model drop / tuck / shrink. Does anyone actually use `[PAD: …]`? If not, retiring it outright (like TERMLINK/CROSSROADS) simplifies every option. 2. **VATS target:** should the quick [VATS] launch accept the target argument (as A/B/C assume, optional) or stay a plain launcher with targeting done inside the V.A.T.S. panel? 3. **Option A label width:** is CONSLT an acceptable abbreviation at 360px, or should the rail drop to five keys by folding CALC into VATS (long-press or a second tap inside the sim)? 4. **Option B entry point:** is the composer toolbar the right home for ◈, or should it sit on the transcript-card border so the composer stays purely conversational? ## Screenshots (headless-rendered, for mobile review) Each option has a mobile frame shot, an interaction-state shot, and a desktop overview: - **Option A:** `command-cluster-option-a-412.png` (mobile, resting rail) · `command-cluster-option-a-412-armed.png` (THREAT armed — inline target field) · `command-cluster-option-a-desktop.png` (full page: blurb + both frames) - **Option B:** `command-cluster-option-b-412.png` (mobile, zero-footprint resting state) · `command-cluster-option-b-412-deck.png` (◈ deck raised, target filled) · `command-cluster-option-b-desktop.png` - **Option C:** `command-cluster-option-c-412.png` (mobile, THREAT channel) · `command-cluster-option-c-412-dialed.png` (dialed to TRADE — dimmed no-argument socket) · `command-cluster-option-c-desktop.png` ## Verification All three files headless-checked at **360 / 412 / 1200px**: `scrollWidth === innerWidth` (no horizontal overflow), zero console errors, and every faked interaction (arm/fire, deck open/launch, channel dial/engage) exercised. Inputs are 16px (no iOS focus-zoom); all primary controls hold ≥28px targets (C's position LEDs are a flagged exception, redundant to the steppers).