Small change.
Real build.
Proof.

A practical lab for checking what an AI-assisted Unity change actually did. You get a small playable project, a native-build verifier, two deliberately broken scenarios and a bounded feature exercise.

01 / Play before you prompt

Run Build/BuildGoblin.exe. Click a target to fire. The magazine holds six rounds. R reloads; Space pauses. A shot while paused or reloading must not consume ammunition. Reload must take 1.2 seconds of unpaused time.

Read the setup requirements before running scripts. The source project is qualified on Windows with Unity 6000.3.17f1. Other Editor versions are not claimed compatible.

02 / Run the contract

& ./tools/Verify-Build.ps1 -IncludeSeededFaults

The verifier checks every payload file against the saved build manifest before starting the player. Each run gets a fresh random identifier. The player reports its embedded build identity and the observed assertions. Exit code alone is not enough.

• Reference: all 12 declared assertions must pass and the player must exit successfully.
• Pause fault: deliberately allows firing while paused. The pause assertion must fail.
• Input fault: deliberately disables firing. The shot and hit assertions must fail.

Reports go to Evidence/, outside the sealed Build folder. Each result says what it observed. Synthetic input checks the declared code path; it is not a physical controller test.

03 / Try to fool the report reader

& ./tools/Test-Verifier.ps1

This takes an actual successful report, makes separate in-memory mutations and checks that the reader rejects a stale run ID, wrong build ID, missing assertion, duplicate assertion, zero assertions, inconsistent exit code and a string masquerading as a Boolean. The original report stays intact. Two additional rejection checks cover non-Boolean input provenance and an unrelated failure in the seeded pause case: nine rejection checks in total.

04 / Give the agent one job

Copy the sample to a practice folder. Give your coding agent this bounded feature task: cancel and restart reload without losing the pause guarantees. The task includes acceptance criteria and review questions.

Before editing, ask it to identify the seam, explain how it will test the behavior and preserve the baseline. After editing, inspect the diff. Reject unexplained changes to the required assertion set. An agent changing the test to accept its bug is not a successful implementation.

05 / Build what you reviewed

Open the practice project in the supported Unity Editor. The BuildGoblin → Build Windows sample menu creates the supplied scene and writes a native Windows player to the sibling Build folder. Save other scene work first: this menu intentionally replaces the active scene with the sample.

& ./tools/Seal-Build.ps1
& ./tools/Verify-Build.ps1 -IncludeSeededFaults

Sealing is appropriate after a build you intentionally produced. It is not a repair button for an unexplained changed download. Check the build log and file origin first.

06 / Recover with evidence

Follow the sample-only recovery checklist. Keep the failed candidate's evidence, restore the changed source from your retained baseline, rebuild and run again. A fresh build has a new identity even when its source is restored.

What a useful result looks like

“Build X, run Y: the required assertions passed; the deliberate pause and disabled-input cases failed as expected. Source changes were limited to these files. This does not test the physical keyboard or other Unity versions.”

That tells you more than “the agent said it worked.” It also tells you exactly what is still unknown.

Before using this in your own game

Define your own assertions and connect them to real gameplay paths. Keep the identity and completeness checks, but do not reuse sample-specific expectations blindly. Test on a second small project before trusting an adapted helper with valuable work.

No savings, sales, adoption or unattended-operation claims are made for this preview. It has local engineering checks, not independent buyer validation.