A video can show a bug without giving anyone enough information to fix it. A tester taps a reward button, closes a popup, and opens it again. The button appears enabled and submits a second claim request. The clip captures the symptom. It does not establish the starting state, the build, or the expected behavior.
For a game studio AI workflow, the useful handoff is a small repair contract: reproducible inputs, a bounded change, and evidence that a reviewer can judge. The agent should not have to invent the product decision before it can investigate the code.
The example below is an executed standalone browser fixture of a mobile-game UI defect. It is synthetic teaching code, not evidence from a shipped game. Its before/after recordings and observed regression results are linked below.
Start with a state transition
Suppose the reward panel has three states: available, claiming, and claimed. After a successful claim, reopening the panel should show the claimed state. If a request fails, the player should be able to retry.
That gives QA two distinct cases. A successful claim must stay claimed after reopening. A failed claim must become available again. “Fix the button” hides that difference and invites a patch that solves one case by breaking the other.
Record the successful case with the panel and input indicator visible:
- Launch the identified build with a fresh test profile and an available reward.
- Open the reward panel and tap Claim once.
- Wait for the success response and the reward confirmation.
- Close the panel, reopen it, and tap the button again.
- Record the visible state and any additional claim request.
The recording should show the whole transition, without cuts between the initial state and the failure. Attach the clip to the task with its build identifier. Keep access tokens, personal data, and internal notifications out of the recording.
Make the environment reproducible
“Android” is not an environment description. Capture the device model, OS version, app build, source revision, backend environment, feature flags, account fixture, and network condition. Say whether the issue reproduces after a clean launch or only after earlier play.
For the fictional case, a useful report would name a test profile with one unclaimed reward and a stubbed success response. A second fixture would return a failure response. The companion fixture executes both responses locally; these are test doubles, not backend measurements.
If QA cannot reproduce the issue consistently, keep that uncertainty in the task. Ask the executor to investigate and report the conditions before promising a repair.
Write the contract before the implementation prompt
Here is a template a QA lead can adapt:
Title: Preserve reward claim state when reopening the panel
Evidence
- Repro clip: https://patilrb.github.io/assets/day10/W-481-faulty.webm
- Fixture source SHA-256: c4790242f821760224eb8e90827bbc525fac94f1895f855e7d73641ffd0353d6
- Environment: Chrome 155 on macOS; standalone local browser model; no backend
- Fixture: one available reward; success and failure responses
Reproduction
1. Open the panel with the reward available.
2. Claim it and wait for a successful response.
3. Close and reopen the panel.
Expected
- The reward remains claimed after reopening.
- The claimed control cannot submit another request.
- A failed request restores a usable retry state.
Allowed scope
- Reward-panel state restoration and its focused tests.
- A shared-state change only if investigation proves necessary;
explain the dependency before expanding the repair.
Excluded scope
- Reward amounts, economy rules, network protocol changes,
account migration, and unrelated UI cleanup.
Required delivery
- Root cause with relevant source references.
- Patch and focused regression test.
- Exact test command, environment, and observed output.
- Before/after clip using the same reproduction steps.
- Remaining uncertainty and any untested device cases.
Acceptance owner
- QA verifies the original reproduction and retry case.
- An engineer reviews correctness and shared-state impact.
- The product owner resolves disputed expected behavior.
The missing evidence fields are deliberate. Filling them with plausible values would make the task look complete while removing the ability to reproduce it.
Give the executor a narrow first move
The execution prompt can now be specific:
Reproduce the attached reward-panel issue in the supplied environment. Trace how claim state survives panel destruction and recreation. Identify the authoritative state before changing code. Make the smallest justified repair within the allowed scope. Add a regression test for reopening after success and for retrying after failure. Report what you observed and what remains untested.
Do not prescribe a boolean reset before the investigation. Clearing a loading flag may restore input while also allowing a second claim. The implementation depends on whether the panel owns transient view state, reads persistent claim state, or receives a stale response.
QA prepares the reproduction and expected behavior. A developer or an agent executes the investigation using tools and repository access that they are individually authorized to use. The reviewing engineer and QA judge the resulting change. Writing the task does not establish who has access to run it.
Ask for proof that can reject the patch
A useful regression test needs to fail for the defect it describes. Arrange the available reward, complete a successful claim, recreate the panel, and assert that the claimed state remains visible and cannot trigger another submission. In a separate case, simulate failure and verify that retry becomes available.
For example, pseudocode can make the intended boundary clear:
await panel.open({ reward: availableReward });
await panel.claim({ response: success });
await panel.close();
await panel.recreate();
expect(panel.claimState()).toBe("claimed");
expect(panel.canSubmitClaim()).toBe(false);
This is a test outline, not runnable code for a particular engine. Adapt it to the project's actual state model and harness. Record the real command and output rather than turning the outline into a claim that tests passed.
The reviewer should also inspect the before/after recording, failed-request retry, and any shared state touched by the patch. An automated assertion cannot prove that the final button label is readable on the original device.
Keep coordination separate from acceptance
For a wider discussion of how these responsibilities fit into a studio stack, the Wagglet article on an AI-native mobile game studio stack provides related context. The repair contract above is usable independently: preparation establishes the inputs, execution produces a candidate change, and acceptance requires human judgment against the evidence.
A bounded task cannot remove an intermittent backend fault or replace device testing. It can make those limits visible before someone mistakes a plausible patch for a verified repair.
Disclosure: This draft was prepared with AI assistance. Its fictional example and test outline need review by someone familiar with the project's implementation before publication or use.
Executed reproduction and regression evidence
The faulty reward view reopens as available even though its persistent claim is already complete. Replaying the same steps sends two requests. The repair changes only reopening: it derives the view from persistent claim state. The corrected run sends one request and keeps the claimed view. A failed request still permits a successful retry.
Watch the faulty reproduction and the repaired replay. Both clips continuously capture the actual fixture canvas, with scripted actions labeled inside the frame. They are not recordings of manual device testing. The interactive example and full source include the model, recording harness and exact checks.
The environment was Node v22.23.2 on macOS arm64 for the assertions, and Chrome 155 for the browser recordings. The model source SHA-256 is c4790242f821760224eb8e90827bbc525fac94f1895f855e7d73641ffd0353d6. Run node check.mjs from the extracted QA source folder. Across the three distinct examples, the faulty models fail the three intended regression assertions; all three neighboring cases pass. After repair, all six checks pass. The machine-readable results record each assertion.
The fixture has no real server, production account or commercial-game integration. Its measurements establish this bounded example. Human acceptance and any real-game repair still require the relevant owner and environment.
Top comments (1)
The two-case split is where this template earns its keep: "success stays claimed after reopen" and "failure returns to available" are a characterization pair, and the failure case is the one a symptom-shaped patch quietly breaks - the button re-enables by forgetting the claim ever succeeded. I'd make the contract say the repair is done only when both fixtures pass, the reported case and its mirror. Two cheap additions to the environment block: the fixture-state hash, so "fresh profile with one unclaimed reward" is verifiable rather than aspirational, and inter-input timings - a tap-tap-close sequence that fails at 200ms but passes at 2s is a race, and the recording already holds that data if the taps are timestamped. On the irreproducible case: the failure rate is itself evidence. "1 in 5" points at ordering or timing; "0 in 20 on clean launch, 5 in 5 after prior play" points at persisted state. Keeping the uncertainty in the task is right; keeping the measured rate next to it makes it actionable.