Runs and result review

A Run is an implementation attempt associated with an issue and a working location. It brings together the worker’s state, changed files, collected evidence and result.

Follow the actual state

Open Work → Runs or a related Run from an issue. A worker can be running, waiting, failed or stopped. A completed attempt may need review.

Read the result summary first, then inspect the worker report and conversation when you need context. A model’s statement that something works is not the same as a recorded build or test result.

Review the changes

1. Confirm the issue and the Run you are inspecting.
2. Open its changes and check what was actually modified.
3. Read the build and test outcomes, including missing or skipped checks.
4. Inspect the output and its source context.
5. Record a result review or request a correction for that result.

Reviewing a result does not merge its code, close the issue or certify gameplay. Those are separate decisions.

Open the right output

Open result refers to the selected Run’s recorded working copy and output. The ordinary project launcher refers to the selected project binding. They can point at different locations.

GDE rechecks the recorded output before opening it. If it changed, is missing, or belongs to an older source state, inspect that discrepancy first. An editor build is not automatically a packaged game. Results and evidence explains these distinctions.

Continue after interruption

Reopen the existing Run and refresh its observed state. Continuing uses its recorded association; it is not a reason to start a second worker for the same task.

If the working copy, branch or provider thread is unavailable, the Run remains visible with that limitation. Resolve the reported condition before continuing. Uncertain message delivery is retained and checked rather than automatically resent.

Simulated example Runs can be inspected but cannot dispatch or continue real implementation.