--- name: "" description: "The DOCK (the owner's term for shelved-but-not-discarded ideas) — what's currently docked, and the durable design rulings that came out of the dev-tooling work." metadata: node_type: memory originSessionId: 0b7c5f41-bb34-4ab4-93be-fdb363f5eb40 --- **"DOCK" (owner term, 2026-06-28) = shelve an idea for now:** keep it recorded and revisitable, but NOT in the active backlog and NOT permanently discarded. Lighter than a parked task — these are ideas, not committed work. The owner cleared the dock once (2026-06-29, *"remove my docked items"*) and the items he removed then — push notifications, in-browser Python/WASM, geolocation, NFC — are **DISCARDED, not docked.** Don't re-propose them. *This file previously held a long dev-console/Diagnostic-Shell build spec with per-item status. That's queue state — stripped 2026-07-20; sequencing lives in `QUEUE.md`, what shipped in `CHANGELOG.md` + git log. The design rulings below are kept because the reasoning behind them isn't recoverable from the code.* ## Currently docked - **Optional auto-karma-from-actions** (2026-07-06). Karma is manual or AI-set today; it does NOT auto-change from logged actions, because the app is a tracker, not the game engine. The owner floated *"shouldn't it change dynamically based on the things you do?"* — deterministic rules that shift karma from logged deeds would be player-control-safe if they stayed deterministic. Offer only if he wants it. - **Themed DEVICE SKINS per game** (2026-07-06). Owner: *"I like device skin, we should have themed skins per game… back burner for now."* The per-game device chrome/framing layer over the shared panels (see [[per-game-device-form]]). He endorses it, and explicitly back-burnered it until the current panel overhaul is complete. - **A "useful still-working glitches" reference** (2026-07-05). The owner sent a clip of duping a SPECIAL book and wondered about an in-app reference for real Fallout glitches that still work. Owner: *"bottom of the barrel for priorities but still a thought ya know."* Fits the in-universe RobCo reference-content angle ([[robco-os-architecture]]). ## Standing owner preferences from this strand - **⭐ THE OWNER IS NOW ALMOST EXCLUSIVELY ON MOBILE** (2026-07-08). ALL UI work must look good and be usable on mobile FIRST; the mobile baseline is the floor, not the target. Verify at real mobile widths as the primary surface, desktop second. - **Reactive feedback / "juice"** (2026-07-06): the owner wants event-driven animation across the app so things feel alive when they change — *"there needs to be more animations that happen for different things like leveling up (stat changes)."* ⭐ His refinement matters more than the request: *"it doesn't have to be animations FROM the core — be creative but in theme for Fallout."* So don't limit it to one component's idiom — invent Fallout-native feedback (Vault-Boy flashes, SPECIAL needle kicks, XP fills, radiation ticks, holotape/CRT effects), each in-theme, each reduced-motion-safe. - **Dev affordances must be INLINE, not only buried in a menu** (2026-07-07): *"the map should be reset-able without a different save for testing ya know?"* — a small reset button ON the thing itself, each confirm-gated, so he can re-test a feature from a clean slate on the same campaign while looking at it. Every inline dev control carries a consistent **dev-marker icon** so it's obvious at a glance that it's a staging-only control, not a normal user control. - **Dev tools must LEAVE THE APP SCREEN VISIBLE** (2026-07-08, with a screenshot). A full-screen tool drawer defeats the entire point of a trigger catalogue — you can't watch the effect fire. It must be a partial overlay (a bottom sheet, ideally resizable, or a side panel on wider screens). Related: it must **float over** content rather than sit in document flow, because taking flow space shoves the underlying layout out of the position it was designed for. He likes it being above everything and one tap away; he does not like it displacing the layout. - **Device CHROME stays a constant size** (2026-07-08): the bottom nav dock must NOT scale or get trimmed by a density pass or by which subsystem is active. It's chrome; pin it. - **SPEC-LOCK:** never stack a new request onto an in-flight session — dispatch it as the next unit. Repeated as a sequencing instruction whenever new feedback arrived mid-build. ## The two-tier dev-console design (the reasoning, which is the durable part) The core reframe: it is **TWO products in one panel.** - **STAGING** = the owner's full QA/debug toolbench — everything, including destructive tools, cheats, and internals. - **PRODUCTION**, reached by an in-fiction unlock = a non-destructive **presentation/immersion sandbox** (fire animations, force ambient states, boot flavours, time-of-day) — fun and safe, NEVER cheats, internals, or destructive actions. It ships to players as a reward for hacking the terminal, so it must feel earned. Same panel, tier-filtered. Consequences that must not be lost: - **Cheats are staging-tier BY CONSTRUCTION** so they can never leak to a production player — the reason is **honest-tracker integrity**: cheats touching a player's own campaign would undermine the app's whole premise as a truthful record. (They are not a *security* risk — a cheat only touches that user's own data.) - **⚠ FAIL-SAFE, hard constraint:** any unlock flag defaults to ABSENT = locked/production. An absent, unknown, or stale value must **NEVER** resolve to unlocked. - **⚠ HONEST CAVEAT the owner was told:** client-side JS is inspectable, so a determined user reading the source can find any hidden unlock. Hiding is a CONVENIENCE for casual users, **not a security boundary.** On that basis an owner backdoor to enable staging tools on production is acceptable — as a secret, undocumented command kept out of the visible command list — and it needs a symmetric **disable/re-lock** command (owner 2026-07-08: *"make sure there are commands to DISABLE dev/staging dev tools as well in CLI"*). - **A data-driven tool REGISTRY is the backbone** — each tool declares its tier and whether it's destructive, and the panel renders from that, auto-filtering by environment and auto-confirm-gating destructive entries. Adding a tool is one entry. This is what makes the tier guarantee structural rather than remembered. - **Organization rules the owner approved:** categorised COLLAPSIBLE sections rather than a flat wall, **every** group collapsible (not just top-level categories) with big groups defaulting closed so it opens compact, persisted open/closed state, a search filter, a clear environment banner so the tier is never ambiguous, plain-language sub-labels, and per-tool help — *because the owner forgets what things do.* - **⭐ INSPECT NEVER DISPLAYS RAW JSON — anywhere.** The owner decided this in two steps: first *"no raw on production,"* then *"don't show raw on staging either, just ensure it uses the raw text and makes it into readable."* It TAKES the raw data and ALWAYS renders a readable, formatted, diegetic diagnostics readout with labelled human fields — the same presentation everywhere; a staging build may expose extra FIELDS, never a raw blob. Its section also sorts to the BOTTOM of the panel, because it changes nothing. - **NAME: "DIAGNOSTIC SHELL"** (owner 2026-07-08 — he typed "GOAGNOSTIC SHELL," read as DIAGNOSTIC). His rationale: *"since the tests are RobCo Diagnostic"* — it ties to the diagnostics runners. Since it ships to players it needed a first-class in-fiction name; staging can show raw labels, production wears the fiction. - **Cheats/state-setup:** the owner approved the full set when asked for ideas (*"all"*) — vitals, progression, SPECIAL, skills, karma, economy, inventory, factions, collectibles, perks/traits, quests, map fog, conditions, companions, time, plus god-mode and fresh-start presets. Constraints on all of them: route through the **existing native setters**, validate and clamp, stay game-agnostic, stay staging-tier, and confirm-gate the destructive ones. - **Proposed maintainability rule:** every new ambient/conditional/hard-to-trigger feature registers its console trigger in the SAME commit, gate-guarded so a feature lacking a trigger fails the build. The self-enforcing version of the standing dev-console-trigger rule in [[design-overhaul-direction]] point 9. ## Gotcha worth not rediscovering **Sticky `:hover` on touch.** A tapped control stays visually highlighted because touch fires no `pointerleave`. This bit the same way on more than one control. Fix: drive the highlight off real state (an open/closed class) rather than `:hover`, scope any true hover styling to fine-pointer devices, and blur on tap.