Review an implementation

Goal: decide whether a particular Run delivered the requested change. You need a Run with a result; the simulated example is useful for learning the reader, but cannot prove engine behavior.

1. Match the result to the task

Open the issue and its related Run. If there are several Runs, select the one you intend to review. Check whether the issue or source has changed since that attempt began.

2. Inspect the diff

Open the changes. Confirm the requested behavior is represented and that unrelated files were not changed unnecessarily. Read the worker report as an explanation of the work, then compare it with the evidence.

3. Read what was actually checked

A successful command, a successful build and a passing gameplay test are different observations. Check test counts, skipped checks, failure output and anything explicitly not run.

For a numerical or visual result, inspect the retained inputs and output, not only its summary. Results and evidence is the lookup guide.

4. Open the exact result where available

Use the Run’s Open result action when it is available. Check its working copy, engine binding and output. If GDE says the output changed or is incomplete, rebuild or resolve that condition before judging the recorded result.

The project-level editor button opens the ordinary project context; it is not a substitute for selecting a Run’s result.

5. Record the next decision

Review the displayed result, or continue the Run with a focused correction. Say what failed and what you observed. Keep acceptance of gameplay separate from compilation, issue closure and Git integration.

Result: a review of a specific attempt and output, with either a clear disposition or a concrete next correction.