BC-0196 · TROUBLESHOOTING
Editorial review 2026-09-26
Restart Loses the Wrong Progress
If restart removes progress that should survive, define the lifetime of each affected state before asking to keep everything. Round score, session unlocks and progress intended to survive leaving are separate contracts. Correct only the over-cleared state; a retry prompt cannot establish a permanent save system.
Symptom
A working restart clears specific progress that the authored lifetime says should survive that boundary.
Immediate action
Name the exact restart boundary and the state intended to persist through it.
Diagnostic branches
- The intended lifetime was never defined.
- Decide the keep/clear contract before declaring data loss.
- A session benefit disappears on an in-session retry.
- Request selective retention of its ownership and usable effect.
- The label remains but its associated ability is lost.
- Repair the dependency between retained status and usable behavior.
- The observed boundary was leaving or starting another session.
- Treat persistent storage as separate unverified work rather than promising a retry-only repair.
Least-destructive change
Retain only the declared longer-lived state while preserving the correct reset of attempt-specific behavior.
Retest
- The named retained state survives the actual tested boundary and remains usable.
- Attempt score, position and hazards still reset as intended.
- Untested cross-session behavior is not represented as a completed save feature.
Escalation
Use the lifetime card and before/after observations if selective retention is not working. No recovery of already lost progress or hidden backup mechanism is asserted.
Working notes
Record the boundary actually crossed: retrying a failed attempt, beginning a new round, leaving the project or returning in another session. A state expected to survive an in-session retry is not automatically expected to survive all of those boundaries. Keep the report limited to the transition you observed.
Write a keep/clear decision for the state that disappeared and its dependencies. Retaining an unlock label without retaining the ability to use that unlock produces an inconsistent result. Conversely, preserving current health or active hazards because a session upgrade should survive can break the new attempt.
Compare the pre-retry observation with the fresh attempt, using existing evidence when reproducing would lose valuable progress. Specify what disappeared, what should have cleared and whether the surviving state remains usable. Do not invent an undo control or repeatedly rebuild the same progress solely to prove it is lost.
Request selective retention across the defined boundary. Preserve the known working reset of attempt state and keep the retained benefit's eligibility and effect together. Treat any later cross-session persistence requirement as separate implementation and verification work.
Examples
- Lifetime card: round score clears on retry; a session-earned route unlock remains usable; long-term progress after leaving is unverified. These are design choices, not assumed platform storage guarantees.
- Proposed repair: On the existing in-session Retry, keep the earned session route unlock and its usable access, while resetting the round score, player position and attempt hazards as before. Do not preserve every temporary value.
- Consistency check: the unlock label survives but the unlocked route becomes inaccessible. Retention has not fulfilled the promised behavior merely because the UI still says owned.