--- name: parked-deferred-work-program description: "The \"Round 2\" deferred-work program — the enumerated slate has moved to QUEUE.md; what remains here is the owner's curation decisions, the hard invariants, and the metaphor-lane rule that exist nowhere else." metadata: node_type: memory originSessionId: 0b7c5f41-bb34-4ab4-93be-fdb363f5eb40 --- Set 2026-06-29. The owner accepted the master-plan recommendations wholesale ("go with recs") and directed that anything held for a different release go to parked/docked, then *"combine them all and add synthesis and parallel again."* So this was the COMBINED future-work program: combine all the deferred inputs into ONE planning effort, then a SYNTHESIS stage (reconcile into one integrated backlog) → a PARALLELIZATION stage — so the whole deferred batch builds coherently in one go, not piecemeal. That structure is the durable part; it's the pattern the owner wants for any future batch of parked work. *This file previously carried the full enumerated slate (lettered candidate items, per-item specs, phase/unit build status, commit hashes, test counts, "Phase 0 complete" claims). All of that is roadmap state — stripped 2026-07-20; it belongs in `QUEUE.md`, with shipped work in `CHANGELOG.md` + git log. What remains is the reasoning behind the decisions, which does not exist in the repo.* ## Scope rulings the owner made - **Fallout 4 support is SEPARATE — its own later program, NOT part of this one** (owner 2026-06-29). This round is deferred polish/feature/AI work on the EXISTING games. The one overlap (vendor/item data) is handled WITHOUT merging: design the vendor-stock structure GAME-AGNOSTIC so a new game reuses the exact same format later. See [[parked-fallout4-support]]. - **★ Build FNV and FO3 to a strong, distinct per-game identity BEFORE FO4** (owner 2026-07-01). His reasoning: FO4 is the most game-specific and gets built LAST with the fullest vision, so without this the earlier games would feel "behind" once FO4 lands. Give each its OWN signature panels and feel, leaning into what makes it unmistakably that game — **NOT copy-paste, NOT feature-parity for features they lack.** Scope discipline: each game's genuine SIGNATURE elements only (the few things that scream that game), not exhaustive parity. Paired with a POST-FO4 "parity retrofit" that backports any gold-standard ideas discovered while building FO4 back into the earlier games. - **Per-vendor stock: the owner chose REALISM over convenience** — constrain trading to what a given vendor would actually carry, rather than a browse-the-whole-item-DB catalog. - **IndexedDB: the owner wants a FULL migration, not incremental** (2026-06-29) — *"one persistence layer instead of two,"* everything off localStorage. HARD REQUIREMENT: a bulletproof migration where all existing data (campaign state, save slots, rolling backups, settings/flags/key) moves over and can be read, written, updated and MERGED with **zero data loss**, with save-integrity, cloud-sync and migration invariants all still holding. This is a foundational data-safety change — the entire save/backup/cloud path sits on the old store — so it must be a **standalone, reversible unit** with exhaustive migration tests and a rollback path, never bundled with features. That's why it was deferred rather than done inline. - **★ GOVERNING PRINCIPLE for every "make it game-agnostic" item** (owner 2026-07-01): the goal is that adding a new game is EASY and NON-BREAKING — well-organized integration points so you can *"drop the code in without breaking other things."* It is NOT a dogmatic zero-code/pure-data mandate. His exact framing: *"the labor is not the problem; dropping the code in without breaking other things should be easy."* Authoring each game's CONTENT is expected to be significant labor and that's fine; what must be easy is the plumbing — clean per-game hooks, no fragile hardcoded assumptions, no painful refactor to slot a game in. Some per-game code is acceptable where it keeps things clean. Judge every such item by this pragmatic bar. - **Onboarding, if built (owner 2026-07-01):** (1) ALWAYS SKIPPABLE. (2) The seen/completed/skipped flag MUST live in PERSISTENT campaign state (cloud-synced where possible), **NOT in the service-worker cache** — so clearing the cache or rebooting the terminal does NOT re-trigger the tutorial. Only a full site-data wipe should, and for a signed-in account cloud sync should survive even that. (3) Establish a **new-feature onboarding rule** at the same time: every feature shipped afterward gets surfaced to returning users — first-run users get the full tour, returning users get just the *new* bits since they last saw it (track a last-seen feature marker alongside the seen flag). - **UX clarity pass** (owner 2026-06-30): audit for ambiguous UI and add inline explanations so nothing is unclear. His specific ask: the **playthrough-type selector must EXPLAIN what each type is** — right now it's options with no description. He suggested repurposing one of the kept template warnings ([[owner-templates]]) as the explanation element, which is a good reuse of those preserved templates. - **Voice input — SIDELINED** (owner 2026-07-01): shelved, not pursued. Browser speech is finicky and the real scope is larger than it looks. On file as a future wildcard only. - **Holotape/cassette library — CUT, not revived** (owner 2026-07-01). It re-proposed an idea already dropped as *"too many, feature not many would use."* - **Gyroscope CRT tilt — kept but SUBTLE / optional / off-by-default / low priority** (risks feeling like a phone gimmick). **Ambient-light optic calibration — DEPRIORITIZED** (low value, not very diegetic). Both delayed rather than cut. ## Sequencing reasoning that outlives the queue - **Decompose the biggest, most-touched functions FIRST, before piling features on them.** Every AI/boot feature layers onto them; splitting them up front means later features attach to clean seams instead of making two giant functions bigger. Refactoring later, with features already bolted on, is far more risk and merge pain. (Same logic drove doing the tool-launcher redesign before adding tools to it.) - **Ship the state-import behavioral test BEFORE any AI-residue feature.** Those features write imported state through that path; lock the test around it first so everything built after lands on a proven-safe import path. - **Run the DATA lane early.** Pure data entry is the ONLY genuinely parallelizable work — it touches no shared code — so start it early to fill parallel capacity while serial code work proceeds. - **Consolidate rather than build parallel systems.** Standing merge rulings: milestone snapshots unify with the incident log / reputation timeline / calendar into ONE "terminal's record of your campaign," not a fourth timeline. Terminal condition EXPANDS the already-planned emergent CRT condition rather than becoming a separate system. Meta-stats + diagnostics + maintenance logs live in ONE system-info home, not scattered. ## ★ "HARDWARE LIFE" — the machine remembers ITSELF, not just the player A distinct second axis from player-continuity features: the terminal as a piece of hardware with its own past and physical life (randomized POST codes, a hardware-sound layer, self-acknowledgment chatter, cosmetic diagnostics, maintenance logs, service bulletins, quirks, screensaver variants, chained transmissions). Almost entirely fabricated atmosphere with no gameplay effect. - **Elevate it to a FIRST-CLASS DESIGN PRINCIPLE, not a feature cluster** — codify when built. The rule as stated: *"The terminal exists as a persistent machine independent of any campaign. It may remember its own operation, wear, maintenance, uptime, diagnostics, broadcasts, and history — but it never alters or invents gameplay state."* This is the guiding rule for every future immersive feature. - **⚠ HARD INVARIANT:** machine-history features may persist their OWN small meta-store (boot count, condition, seen-logs) but must **NEVER touch game saves or state**; fabricated diagnostics **never gate anything real**; everything toggleable and reduced-motion/perf-safe. The clarity rule is naturally satisfied — this content is unambiguously about the TERMINAL, never mistakable for an in-game event. - **★ ONE CANONICAL "TERMINAL RECORD," with my reconciliation attached.** The proposal was to unify ALL history systems (campaign, incidents, faction, quest, calendar, sessions, hardware events) into one record with multiple views — one source of truth, not four parallel history systems. **My refinement, which is the load-bearing part: the terminal record is a unified VIEW layer that SPANS the two stores WITHOUT merging them.** Gameplay history persists in the campaign SAVE; hardware history persists in the separate META store. One presented record on the surface, the two-store boundary preserved underneath. This is what keeps "one canonical record" from quietly violating "hardware-meta never touches game state." - **Build order reasoning:** highest charm-per-effort first — boot codes, the sound layer, self-chatter, chained transmissions — before condition/screensavers/filesystem integration. ## ⚠ THE METAPHOR-LANE RULE (required — keep each metaphor in ONE lane or it's soup) Four organizing metaphors now exist. Each has exactly one job: - **Launcher / command palette** = navigate and run tools. - **Filesystem (`DIR`)** = the diegetic skin over that navigation, and the home for logs / archives / intercepts. - **Module Bay** = enable and configure CAPABILITIES (the settings replacement — "open the service panel and install boards" instead of "toggle options"). - **Hardware Life** = the machine's living self-history and personality. Distinct roles reinforce each other; overlap is confusion. The filesystem specifically must be **functional navigation, not decorative** — it's the skin over the launcher, and the real home for machine-history and transmission content, not a dead end. Related consolidation ruling: presentation presets (terminal personalities, hardware shells, desk mode, keyboard feel, environmental skins) are ALL "change the look/sound/feel" — collapse into ONE presentation-preset layer riding on the existing identity and Hardware-Life systems, NOT five new systems. ## The adaptive launcher — the design the owner locked The native-tools row is fine at a handful of tools but bloats as more land; a flat button row doesn't scale. Redesign the launcher EARLY, before piling new tools on. **The owner's decision (2026-07-01): MERGE four directions into ONE adaptive launcher** — consolidation + grouping/categories + progressive disclosure + contextual/per-game surfacing — **plus a command palette / type-to-run over the top** (confirmed as a committed component, not an option). Type-to-run is both the power-user path and the discoverability safety net, so nothing is ever buried too deep; and it's on-theme (typing commands into a RobCo terminal). **⚠️ CLARIFICATION the owner insisted on: consolidation is ADDITIVE, not a replacement.** A consolidated flow is an EXTRA "super-button" alongside the individual tool buttons, which REMAIN directly pressable. Inside a group you see BOTH the unified flow AND its individual pieces. **The owner must always be able to press the individual tools directly** — the consolidated flow is an extra front door for the common case, never the only one. **The one risk of stacking all four layers is DISCOVERABILITY** (over-nesting hides tools) — which is exactly what the command palette mitigates by jumping straight to any tool regardless of depth. ## ★ ROBCO IDENTITY ANCHORS (owner-approved 2026-07-01, all 5) — the frame that makes it a RobCo MACHINE, not a skinned tracker 1. **The emulated DEVICE is PER-GAME** (owner REVISED this from "it's always a terminal"). Each game's overhaul can be a fundamentally DIFFERENT device form, not a bezel reskin: **New Vegas = a salvaged RobCo desk TERMINAL** you operate (it holds your data because it syncs with your Pip-Boy — operator, not wearer); **Fallout 3 and 4 = the PIP-BOY itself** (a wrist unit where data is native to the device, with its own layout, chrome and interaction feel). "What is this device?" is answered per game, not globally. Foundational — settle each game's device form before its identity build, because it drives that game's whole shell. 2. **OPERATOR CLEARANCE identity — ⚠️ but NO repeated fake-login friction.** Owner: *"make sure the user doesn't have to perform fake logins all the time, that's annoying."* A PERSISTENT clearance identity reframing the EXISTING real auth into one coherent thread. Establish clearance ONCE and PERSIST it — you're just logged in, clearance shown as identity, NOT re-prompted with a fake password gate every session. It's an identity thread, not a recurring nag. (The hacking minigame is about breaking into OTHER systems; this is your relationship with your OWN.) 3. **PHYSICAL HARDWARE SHELL** — an explicit physical frame around the screen; you look INTO a machine, not at a webpage. Per-game it's a different device form (desk-terminal chassis vs Pip-Boy body), driven by per-game data per the governing principle above — a device form is data + a shell, not a code fork. 4. **TWO VOICES kept distinct.** The **RobCo SYSTEM voice** (terse, institutional, cheerful-dystopian, deterministic — ALL native UI copy, boot text, diagnostics, warnings) and the **AI OVERSEER/GM** (the storyteller the player summons) are separate characters, never blended. Plus a cheap, very-RobCo touch: a pre-war corporate handshake on first boot (registration / warranty / "thank you for choosing RobCo" boilerplate). Ties to [[parked-diegetic-audit]]. 5. **SHUTDOWN ritual — the bookend to cold-boot** (CRT collapse-to-a-dot, fan spin-down) to complete the "this is real hardware" illusion. Anchors 1 and 2 are FOUNDATIONAL identity decisions to settle first; 3/4/5 slot into existing overhauls. ## ★ ROUND-4 additions the owner approved (2026-07-01) - **PLAY-ALONG / QUICK-ENTRY as a top-priority feature** — one line typed (`killed deathclaw`, `+50 caps`, `arrived novac`) parsed and routed to the right system WITHOUT leaving your current view. The biggest usability win for a companion app you update WHILE playing. Rides on the type-to-run palette — same input surface — and reinforces the terminal fiction. - **GLOBAL IMMERSION-LEVEL DIAL (Full / Balanced / Minimal) — a required change, not optional.** ONE master control scaling the whole atmosphere layer at once, so per-feature toggles don't become death-by-a-thousand-switches and immersion never becomes friction. Cheap, and essential given how immersion-heavy the roadmap is. Build the dial BEFORE the features that consume it. - **Build the ORGANIZING LAYER first** — the launcher, palette, filesystem skin and Module Bay are the HOMES every later feature slots into; do them before the tool-heavy features (same "decompose before adding" logic as the code monoliths). - **[[player-control-principle]] governs everything** — the player has full control; the AI assists only when invoked (opt-in, never authority); RNG mode is the one sanctioned exception. Audit every AI touchpoint to keep it assistance-on-demand, non-authoritative, and fully editable/off-able. ## GENERAL CONSTRAINTS (owner 2026-06-30 — apply to ALL ambient features) 1. Any ambient/broadcast feature MUST clearly frame itself as TERMINAL-side and never confuse the player about in-GAME vs in-TERMINAL events. 2. The dev/staging build must be able to TRIGGER/TEST these time- and probability-gated features, since they otherwise rarely fire on demand. Also on file: a **user-facing on-site ROADMAP display** the owner asked for (2026-06-30) — a diegetic "upcoming transmissions" panel showing a *curated public view* of what's coming, never the raw internal plan. Offline-safe (ships static, optionally refreshed live so it can update without a redeploy). The recreation "for fun" prompt [[parked-recreation-funprompt]] stays analysis-only and dead-last, on owner go only. Docked items live in [[docked-ideas]]. Per [[parked-task-workflow]]: do NOT start any of this until the owner explicitly says go.