BC-0210 · TROUBLESHOOTING
Editorial review 2026-09-26
Build Removed a Working Feature
When a working feature seems removed after a prompt, distinguish actual missing behavior from lost access to it. A vanished button, blocked route or missing prerequisite can make an intact feature unreachable. Preserve the new improvement while identifying what access or behavior needs restoration; do not assume a universal Undo exists.
Symptom
A previously useful feature is no longer accessible or no longer produces its recorded result after a change.
Immediate action
Separate evidence of previous behavior from the current first missing access or action boundary.
Diagnostic branches
- The ordinary entry control or route is missing.
- Restore clear access before claiming the deeper feature was removed.
- Access exists but its prerequisite is no longer attainable.
- Repair the prerequisite relationship without replacing the whole feature.
- The same qualified action no longer produces its recorded result.
- Restore that behavior while preserving the desired new improvement.
- A possible restore would discard other useful changes.
- Make the recovery scope and tradeoff explicit before using it.
Least-destructive change
Restore the first missing access or functional boundary rather than rebuilding the entire project.
Retest
- The feature can be reached through a clear legitimate path.
- Its previously recorded useful result works in the qualifying state, or remains unverified.
- The desired recent improvement is checked for preservation.
Escalation
Use the before-and-after evidence and recovery tradeoff if a targeted repair fails. No universal history, Undo or lossless restoration capability is established.
Working notes
Name the feature by the action and result it previously provided, using existing evidence if available. A remembered label is weaker than an observed interaction. If the earlier behavior was never tested, describe it as desired functionality rather than a proven regression.
Trace the entry path without risky reproduction. Is its ordinary control still available? Can the player reach the required place or state? Does the action acknowledge input but fail to produce the result? These distinguish missing access, blocked qualification and missing function. Stop before paid, destructive or progress-losing actions.
Choose restoration scope from that first missing boundary. Restoring a menu entry is different from recreating the whole inventory behavior behind it. If the menu now leads somewhere else, preserve the legitimate new destination while explicitly restoring access to the older useful action; do not overload a single unlabeled control with both jobs.
Use a restore or version option only if it is actually available and its scope is understood. An older version may discard the desired improvement that prompted the change. Compare that cost with a targeted repair, and keep unknown recovery guarantees out of the recommendation.
Examples
- Access loss: the collection summary no longer has an entry button after a HUD redesign, but the actual summary behavior has not been tested. Request an accessible labeled entry first; do not claim the underlying collection system was deleted.
- Behavior loss: the same available summary action opens the panel but the previously observed carried-item information is absent. Request that missing information while preserving the new readable panel layout.