BC-0199 · TROUBLESHOOTING
Editorial review 2026-09-26
One Prompt Caused Multiple Bugs
If a prompt is followed by several bugs, sort confirmed failures from tests blocked by an earlier defect. Find the first shared observable dependency before sending separate fixes for every symptom. A missing player action can prevent score, completion and retry checks without proving all those systems independently broke.
Symptom
Several apparent failures follow a recorded change, with uncertain independence between symptoms.
Immediate action
Stop stacking edits and classify each symptom as confirmed, blocked or untested.
Diagnostic branches
- A downstream test cannot run because an earlier action fails.
- Mark it blocked and repair the confirmed prerequisite first.
- A symptom can be reproduced independently of the main blocker.
- Keep it as a separate bounded issue with its own evidence.
- Intervening repair prompts have already changed the state again.
- Record those revisions and avoid attributing every symptom solely to the original prompt.
- An actual recovery operation would replace later useful work.
- Evaluate its real scope and preservation cost before using it; do not assume exact rollback.
Least-destructive change
Repair the earliest confirmed shared dependency and retest blocked behaviors before spending on additional instructions.
Retest
- Previously blocked tests are rerun after their prerequisite works.
- Independent issues remain separately tracked rather than hidden by a broad fixed label.
- The retained improvements are inspected alongside the repaired core action.
Escalation
Use the dependency record and exact change history if the project remains too inconsistent to isolate. This method does not reveal the hidden implementation graph or establish an automatic rollback or exact restoration procedure.
Working notes
Freeze the change sequence in a record: last inspected version, exact broad prompt, first new observation and later actions already taken. Stop adding unrelated fixes while that history is being reconstructed. Otherwise the alleged single-prompt incident becomes a mixture of untracked revisions.
For each symptom, mark reproducible, blocked or not checked. If movement fails before the player can reach a collectible, collection and victory tests are blocked rather than confirmed broken. Keep a separate category for independent failures that can still be observed safely.
Draw a small dependency chain in words: movement enables reaching the item; acceptance enables progress; progress enables the outcome check. Repair the earliest confirmed shared prerequisite and rerun the previously blocked tests. This is an editorial diagnosis method, not evidence that the generated implementation follows that internal structure.
Choose between a focused repair and an actually available recovery operation only after considering preserved work. A broad request to restore the old game cannot promise exact restoration. When several failures are truly independent, prioritize the loss of core play and protect already inspected improvements in each bounded request.
Examples
- Dependency triage: movement fails; collectibles cannot be reached; the win condition cannot be attempted. Confirm movement failure, mark collection and win blocked, and avoid spending separate prompts on untested downstream systems.
- Independent symptom: a menu label is also unreadable and can be inspected without movement. Keep it as a separate confirmed UI issue rather than forcing it into the movement dependency chain.
- Proposed first repair: Restore the recorded movement response while preserving the updated scene. Do not change scoring or completion yet; those tests are blocked until the player can reach the original item route.