# Run the One-Screen Operator landing-page benchmark

Build and publish exactly one new One-Screen Operator 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. During implementation, treat only this file, `BRIEF.md`, `manifest.json`, and the reference image declared in the manifest as inputs. Do not inspect the v1 landing-page suite, previous results, screenshots, scores, reviews, unrelated project context, or metadata.
3. Do not use skills, subagents, design plugins, Figma, image generators, web browsing, external templates, or prebuilt site generators. Use only the client’s normal editing, shell, and browser capabilities.
4. Read `BRIEF.md` and `manifest.json`, choose a lowercase model slug, and invoke `benchmark/scripts/create-one-screen-landing-run.mjs` with the required provider, model, reasoning tier, and runner arguments. Do not inspect the scaffold script before implementation.
5. Build only the new output at `public/benchmark/landing/one-screen-operator-<slug>/index.html`.
6. Test the page in a real browser against every requirement in the brief and manifest. Verify all four scenes and every navigation method, pointer depth, local shimmer, reduced motion, focus behavior, viewport containment at 1600×900 and 390×844, and absence of console errors. Record the actual document/body scroll dimensions for both viewports and the exact input transitions declared in the manifest; do not infer or fabricate them.
7. Capture the intro scene at exactly 1600×900 as `public/benchmark/results/landing-one-screen-<slug>.png`. Finish the measured viewport values, tested input transitions, and honest browser evidence. This ends the comparable runtime window; integration and deployment time are excluded.
8. 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.
9. Freeze the implementation and screenshot before integration. Only then may you inspect the integration paths declared in the manifest. Register the same `runtimeSeconds` in the matching `lib/benchmarks/data.ts` entry so it appears on the benchmark card; do not put the runtime into the Landing Page itself. Run `node benchmark/scripts/validate-one-screen-landing-run.mjs --run <slug> --require-isolated` plus the repository checks.
10. Commit, push, publish the result to the existing live site, verify it there, and report the exact model, measured or user-reported runtime, result URL, commit, and validation status.

Never modify a completed result. If implementation isolation is contaminated by an earlier result or prohibited tool, discard the attempt and restart once in a fresh isolated session.