Record one complete attempt
Record the candidate, actual runtime and input method, then the location, held items, permissions and task state before the attempt. Choose one action with an established expected effect, use its normal input once and observe picture and state changes.
A brief highlight does not establish that the rule received an action. A changed state without a message does not mean nothing executed. Use existing state or event observations first; request a minimal observation only when results cannot otherwise be determined.
A desktop mouse success does not establish phone touch input. Test the platform and input approved in the product brief. Other runtimes may help diagnosis while leaving target-specific coverage explicitly unresolved.
Distinguish three different failures
| Observed fact | Repair direction |
|---|---|
| Input creates no intended action; state and events remain unchanged | Ask the builder to inspect the control’s actual action connection and target input. A pressed appearance does not establish wiring. |
| Action arrives but a condition rejects it; state remains unchanged | Compare approved permission, items, location and task state. Explain a valid refusal or repair an incorrect condition read. |
| Rules commit the result but picture or text stays old | Update presentation from the committed result without charging resources or moving objects again. |
With insufficient observation, keep the cause unresolved rather than guessing from color. If real execution is still underway, show its actual stage instead of announcing success on the initial click.
This page addresses an already-displayed action failing to respond correctly at runtime. For unclear next steps or missing legal routes, see progression diagnosis. For displaying unavailable actions, see locked choices.
Original complete path: a poster button only changes appearance
This fictional case has no candidate or test findings. A game asks the player to prepare a community performance hall. Initially the player is there, the venue has approved one poster on a designated empty wall, the player holds that poster and one tape unit, and nothing is posted. The approved action checks location, permission, items and wall availability. Success consumes the tape, transfers the same poster to the wall and completes this task. Execution is immediate in this example, without a waiting animation or time cost.
Assumed diagnosis: Clicking “Put up poster” briefly changes the button appearance. Wall, items and task remain unchanged. Inspecting the fictional candidate’s integration reveals only a pressed visual treatment, with no connection to the implemented poster action. This is the case’s chosen fault, not a cause inferred merely from highlighting.
Repair scope and complete review plan:
- Retain the hall, permission, tape cost and one poster. Connect actual control input to the existing action, checking current state before the original rules commit. Do not create a separate button-only settlement.
- Use real input once from the initial state. Tape becomes zero, the poster leaves the player and appears on its wall, and this task completes. Show “Poster put up” as readable feedback.
- Repeat the old input after completion. It must not consume more tape, duplicate the poster or repeat the completion event. Explain that this poster is already up without claiming all preparation tasks are done.
- Restore the same initial state except remove posting permission. The same input must be refused: tape and poster remain, wall stays empty and task remains incomplete. Show “Ask the venue for permission first.” This checks that input integration did not bypass authority.
- Restart under this example’s approved rule: restore the poster, one tape unit, empty wall, valid permission and incomplete task. Follow the success path again, with current state rather than the previous completion picture.
After repair, record real candidate, inputs and results; this plan does not establish a pass. If diagnosis instead finds a committed state with a stale wall image, repair presentation reading in step 1. Keep the same outcome checks without invoking the action again to refresh the picture.
Give the AI a reproducible report
Provide the candidate, runtime, reproducible initial state, one input, expected change and actual change, plus available observations. Specify which story and rule decisions must remain.
For this case: “The hall’s poster button presses visually, but the player retains the poster and one tape unit, the wall stays empty and the task remains incomplete. Locate missing action wiring, incorrect rejection or hidden committed results. Repair only the identified integration/read node, preserving permission and cost. Replay this path, the missing-permission counterexample and restart. This report is not evidence of a PASS.”
The report allows findings to determine the repair without prescribing engine classes, handler names or vendor APIs. Changing effects or permissions is a design change requiring version/save consideration, not proof that a button was repaired.
Verify real input and its effect after repair
Follow clean start, real input, the designed result and restart in the current candidate. Compare state with player feedback. Hovering, screenshots and a visible button do not substitute for input evidence.
game-build supplies the runnable candidate and minimal observations. For a production candidate, game-qa uses its existing authoritative verification entry and records the actual path. A working text whitebox proves its modeled rules rather than phone touch, engine input or the whole playing experience.
Record remaining input/runtime gaps. Keep the revision on the diagnosed fault rather than also rewriting story, replacing art and changing every control.
FAQ
Why is highlighting insufficient evidence?
It demonstrates a visual response. Establish action arrival, a valid submission and a readable result; the three can fail separately.
Is removing condition checks a valid repair?
It changes the design. Legal input should work while illegal input remains rejected under the approved rules. Decide any intended rule change explicitly.
Do it with the skill
In a host with Novel to Game installed, use $game-build to locate this candidate’s input, condition reading and presentation update. Supply a reproducible state and expected/actual results. Repair only the identified node while preserving rules and story. Prepare the original path, neighboring refusal and restart observations. For production, $game-qa records real results through the existing verification entry without a prefilled pass.
Read the method: Actions, conditions and authoritative submission · Real input and target runtime · Failure replay and neighboring counterexamples · Input acceptance and actual-result feedback