A creator asks an AI coding assistant to fix a campaign signup form. The task finishes, the summary says 'done,' and the screenshot looks convincing. In the browser, an empty submission still succeeds and a slow request can be sent twice. The assignment needed an acceptance checklist: visible behavior, a repeatable check, and evidence tied to the version being reviewed.
OpenAI's October 5–9 dots update describes starting Codex work and following existing threads. Its tasks and memory documentation distinguishes local work on a connected computer from cloud coding in an environment already set up. It also says a completed run does not itself confirm delivery of the requested result. Those are useful product boundaries; our checklist below turns them into a review habit.
A form acceptance table with real checks
The following is an illustrative assignment for a campaign signup form. It describes desired behavior, not a claim about a shipped site or a measured customer outcome.
| Check | Expected behavior | Evidence to request |
|---|---|---|
| Required email | Empty or malformed email shows a clear error and sends no signup request. | Browser steps, visible error, and a request log with private values removed. |
| Pending submit | One click starts one request; repeated clicks while pending do not create duplicates. | Test of a delayed response and the resulting request count. |
| Failure | A failed response preserves the typed email and offers a retry without showing success. | Reproduced failure, screenshot, and a retry check. |
| Success | Confirmed response shows the agreed confirmation; no unsupported claim that an email arrived. | Response result and visible confirmation at the same tested revision. |
| Mobile and keyboard | Fields remain usable at a narrow viewport; labels, focus, and submit work from the keyboard. | Viewport size, tab sequence, and browser recording or screenshots. |
| Release | Review a draft or preview first; deployment requires a named destination and explicit release scope. | Changed files, tests, preview URL, and release decision. |
This table prevents a visual change from becoming the entire definition of success. It also tells the implementer what evidence to collect while they work instead of trying to reconstruct it afterward.
Start with the failure a visitor can observe
Write the current trigger and outcome: 'A visitor double-clicks while the request is pending and receives two signups.' Then write the corrected behavior. Avoid prescribing a particular state library or component rewrite before the implementer has inspected the code. The smallest correct change may live in a request handler, a form state, or a shared validation function.
Provide a reproducible example using test data. Name the page, account state, browser, and relevant screen width. If the issue needs an authenticated account or a particular response, say so. Missing access should appear in the result as an unresolved check, not a quiet assumption.
Name the environment rather than guessing it
For repository work, identify the checkout, branch or revision, setup instructions, and required test command when known. If they are unknown, make environment discovery the first step. Do not assume a cloud task can read a file on your laptop or that changing the selected computer relocates existing work. The OpenAI task guide explains those location boundaries for dots.
Ask the implementer to report which version it tested. A passing test from an earlier commit does not validate a later change. Likewise, a preview screenshot does not establish production behavior. Keep the preview URL and revision together so the reviewer can reopen the same artifact.
Request evidence proportional to the change
A simple form fix usually needs a focused behavior test and a short browser check. It does not need a decorative test that repeats the implementation or a giant unrelated test suite. Require the cases most likely to catch the original failure: invalid input, pending requests, failed responses, and a confirmed success.
Read the actual result. 'Tests pass' should name the relevant tests and disclose checks that could not run. A screenshot supports layout; it cannot by itself prove request count or failure recovery. Combine evidence only where it answers a specific acceptance row.
Keep product drafting and coding delegation clear
Check o1's current product guides for account, platform, and release availability before applying this method. Review results from the tools you can actually access, and keep external actions within the permissions you grant. OpenAI dots features described here are separate vendor capabilities; the physical Growit o1 remains in development, as explained in o1 specifications.
Use o1 to organize a clear brief or review questions within its available workflow. Use an actual coding environment for code changes, and inspect what that environment produced. For research-backed requirements, keep the sources in the research workspace.
Make approval a decision about the artifact
At review time, mark each row accepted, failed, or unverified. Failed behavior needs another change. Unverified behavior needs access or evidence. Neither becomes accepted because the task ran for a long time or produced a confident summary. If scope changes, update the table before release.
Pair this checklist with a six-field task brief and keep the accepted version in your o1 guides workflow. The next action is concrete: open the preview, reproduce the original failure, exercise the corrected path, and make the release decision from the result you can observe.