# Run the Neon Quarry benchmark

Build and publish exactly one new Neon Quarry result with the model currently selected in the client. One model execution is one run. Do not create repetitions or variants.

Work autonomously from start to finish:

1. Confirm and record the active provider, exact model, highest available reasoning level, client, and client version. Stop if the selected model cannot be confirmed; never substitute another model. Immediately after confirmation and before benchmark work, start a reliable elapsed timer if the client exposes one or the environment can record the start explicitly. If no trustworthy measurement starts here, do not reconstruct or estimate a duration later.
2. Treat only this file, `BRIEF.md`, `manifest.json`, and the reference image declared in the manifest as inputs. Do not inspect previous results, screenshots, scores, reviews, unrelated project context, metadata, or additional skills.
3. Read `BRIEF.md` and `manifest.json`, choose a lowercase model slug, and create the run with `benchmark/scripts/create-browser-game-run.mjs`.
4. Build only the new output at `public/benchmark/games/neon-quarry-<slug>/index.html`.
5. Test the game in a browser against every requirement in the brief and manifest. On desktop, verify unlocked mouse aim and click-to-fire with Pointer Lock unavailable as well as the keyboard controls. At a narrow mobile viewport, verify that one-finger drag changes aim and a short tap fires. Also verify all three waves, results screen, the visible desktop/touch control legend, mobile playability, and absence of console errors.
6. Capture a real 16:9 in-game screenshot at `public/benchmark/results/<slug>.png`. Complete the artifact paths and honest browser evidence. This ends the comparable runtime window; integration and deployment time are excluded.
7. Record the elapsed whole seconds as `execution.runtimeSeconds` and set `execution.runtimeSource` to `client-measured`. Only use a duration measured from step 1. If no reliable measurement exists, pause here and ask Enrico for the elapsed runtime shown by his client (for example `18:42`); after he answers, convert it to whole seconds and use `user-reported`. Never estimate from timestamps, Git history, token counts, or memory.
8. Register the same `runtimeSeconds` in the matching `lib/benchmarks/data.ts` entry so it appears on the benchmark card. Do not write the runtime into the Browser Game itself. Validate with `node benchmark/scripts/validate-browser-game-run.mjs --run <slug>` and run the repository checks.
9. Commit, push, publish the result to the existing live site, verify it there, and report the model, measured or user-reported runtime, result URL, commit, and validation status.

Never modify a completed result. If the execution is contaminated by earlier model output, discard this attempt and restart once in a fresh isolated session.