Save state and clean retests
The save is part of the candidate. Replacing an archive does not rewind facts, journal state, active quest nodes, checkpoints, scenes, communities, or device persistent state.
Choose the right save class
| Save class | Suitable use | Not suitable for |
|---|---|---|
| Untouched pre-install original | First activation and clean replay | Routine play or destructive diagnosis |
| Closed-game full-slot clone of the original | Independent clean cases | Claiming a mid-flow resume state |
| Named mid-flow seed made under one exact candidate | Reload/stream/interruption cases defined at that point | First-install claims or a different candidate hash |
| Completed seed | Guard/reinstall/removal isolation | Replaying first activation |
| Old or unknown save | Negative diagnosis only | Positive acceptance evidence |
An eligible original is created before any version of the scoped quest was installed or registered. Preserve it unchanged and run tests on clones.
Clone a save safely
- Exit to desktop and wait for the game process to close.
- Record the source slot-directory name and visible save label.
- Hash the source slot’s canonical save artifact and record any metadata used by the lab acceptance form.
- Copy the complete slot directory, not selected files, to a new unique slot.
- Hash the clone and verify it matches the source capture before launch.
- Assign that clone to one execution only.
- Never refresh a failed case by copying files while the game is running.
Do not publish private save files. Retain hashes, labels, slot names, and privacy-reviewed metadata or notes sufficient to identify the input.
Inventory state domains before editing
| Domain | Example symptom after replacement |
|---|---|
| Fact database | Completion guard still bypasses the quest |
| Journal | Objective remains active/succeeded or a message stays visited |
| Quest graph/checkpoint | Execution resumes after the edited node instead of entering it |
| Scene | Active/interrupted state restores an older section or actor acquisition |
| Community | Entry remains active, spawned, or already cleaned up |
| Streaming world | Active world-dependent stage restores at a different load boundary |
| Device persistent state | Controller remembers interaction under the same NodeRef identity |
Resetting one fact does not clear the other rows. A save editor or console is useful for a clearly labelled diagnostic, but its result is not a clean-save acceptance case.
Diagnose “works only on an old save”
Run a two-input comparison without changing installed bytes:
- Hash the exact installed candidate and logs.
- Load a clone of the untouched pre-install original and follow the shortest route to the symptom.
- Exit fully; preserve observations and fresh logs.
- Relaunch the same bytes and load the old/unknown save.
- Compare the first visible divergence in facts, journal, active objective, actor/world state, or device state.
| Result | Interpretation |
|---|---|
| Clean clone passes, old save fails | Saved lifecycle is the leading boundary; do not rewrite structurally identical resources yet |
| Both fail at the same point | Save contamination is not sufficient to explain the failure |
| Old save passes, clean clone fails | Old state may bypass a broken first-run route |
| Results differ across launches with the same save and bytes | Preserve logs; investigate timing/streaming or duplicate installed resources |
An old completed save can make a broken first-run graph look healthy by taking the completion guard directly to termination.
Minimum lifecycle matrix
For a one-shot root, retain independent cases for:
- Clean activation: untouched clone enters the first-run route once.
- Mid-flow reload: a named seed resumes without duplicate activation or skipped required work.
- Completed reload: completion state persists and the root guard bypasses replay.
- Identical reinstall: reinstalling byte-identical candidate files does not erase completion.
- Clean replay: another clone of the original repeats the first-run route.
- Removal isolation: where the lab defines it, remove only the canonical candidate with the game closed and load an appropriate clone to prove the observed behavior depends on those mounted files.
World, scene, community, device, interruption, and stream-away cases add separate seeds and oracles. Do not claim them from the five core cases or the optional removal-isolation control.
When a fresh NodeRef is also required
A clean save is the primary test for a stateful device. When a revision deliberately changes the device’s persistent identity or invalidates prior controller state, author a fresh mod-owned NodeRef and test from a clean save. Record that this is identity migration, not a generic fix for every device problem.
Reusing the old NodeRef is appropriate when testing compatibility with old state. Renaming it merely to escape an unexplained failure discards that compatibility question.
Keep candidate and save lineage together
Every runtime row should identify:
- archive and loose-file hashes;
- full required/absent mod inventory;
- framework and game versions;
- source capture and execution clone;
- expected and observed result;
- complete relevant log hashes;
- retained privacy-reviewed evidence;
- whether the run passed, failed, or could not be executed.
A seed created under candidate A is not positive evidence for candidate B, even if their filenames match. If bytes change, regenerate the seed through the documented route or explicitly test compatibility as a different case.
Safe reset order
- Preserve the failing candidate, save metadata, and logs.
- Close the game.
- Restore the exact intended installed files and verify hashes.
- Restore or clone the correct save capture.
- Launch once and collect a fresh complete log bundle.
- Run only the assigned case.
Changing frameworks, candidate bytes, unrelated mods, and starting saves together destroys the comparison.
Previous: Journal, localization, and audio. Next: Controlled isolation and evidence.