--- name: nv-test-save-fixture description: "Owner-requested fully-populated New Vegas test campaign, loaded by a staging-only dev-menu button. Unbuilt. Carries a hard two-gate constraint on the dev console." metadata: node_type: project originSessionId: 0b7c5f41-bb34-4ab4-93be-fdb363f5eb40 --- ⭐ **OWNER REQUEST (2026-07-08): a New Vegas test campaign that lets him test EVERYTHING for NV at once.** The point is to remove hand-building state. He wants one fully-populated campaign that exercises every feature, panel, command and animation simultaneously, so he can verify the whole NV overhaul from a single campaign instead of assembling the preconditions by hand each time. **The fixture should populate every state field**, including the awkward ones that are easy to skip — varied values rather than uniform ones, and states near their boundaries (thresholds, near-expiry effects, failed as well as completed) — because **a fixture full of tidy default values doesn't exercise the feedback it's meant to reveal.** Build it game-agnostically (a fixture generator) if that's cheap, but the deliverable he asked for is specifically NV. ## ⭐ DELIVERY FORMAT — CHOSEN Owner (2026-07-08): *"do the load NV test campaign button, that's a good idea."* A **dev-menu button that builds and loads the populated campaign in one tap**, generated in code — no external save file to keep in sync. It overwrites current state, so it is confirm-gated like any other destructive action. An importable save file was considered and is at most optional/secondary; the button won. ## ⭐ HARD CONSTRAINT — THE TWO-GATE SPLIT The dev console has **two distinct visibility gates, and they must not be merged:** 1. **The STAGING-ENV gate** — the owner's tooling. Full dev/debug capability, including the test-campaign loader and the inline reset controls. 2. **The MINIGAME-UNLOCK gate** — the in-fiction console that *production players* can earn by beating the hacking minigame. **The test-campaign button must NEVER be reachable through the minigame-unlock path.** Same for anything else destructive or testing-only. It is gated strictly on the staging-environment signal. The requirement, stated plainly: **a player who unlocks the console in production must not be able to load the test fixture or wipe their own campaign.** Build the split this way from the start — retrofitting a gate onto an already-shared surface is how the wrong control leaks out. ## PLACEMENT Owner-locked (2026-07-08): *"after dev menu overhaul, before fo3."* It is part of the dev-console overhaul work. Actual sequencing authority is `QUEUE.md` — check there rather than trusting this line. *Correction 2026-07-20: removed the exhaustive state-field enumeration (duplicated from the code map), protocol numbers, and internal gate-function identifiers. The constraint is stated by role instead, so it survives a rename.* See [[per-game-device-form]], [[docked-ideas]].