AI tool · Anysphere
QA for teams writing with Cursor
Cursor's Agent edits files and runs commands on the developer's machine. The code it produces needs the same release checks as any other; the run modes decide how much of that has to happen in CI instead of the editor.
Termscritical flow (a path a user takes that costs money or trust if it breaks: sign-up, checkout, invite, export) · verdict (a one-word release result (pass, pass with findings, fail) with the findings and the checklist version behind it) · CI (the pipeline that builds and tests every change before it can be merged or deployed) · client bundle (the JavaScript your app sends to the browser or ships inside the mobile app; anyone can read it) · protected branch (the git branch that cannot be pushed to directly and is the only source of production deploys) · LLM feature (a product feature that calls a large language model, such as an assistant or a summariser)
What Cursor changes in a codebase
An editor whose Agent edits files and runs terminal commands on the developer's machine. Rules in .cursor/rules shape what it writes; run modes decide what it may execute without asking.
A Cursor team ships faster than its review can read. The checklist does not slow the editor down; it sits at the release, runs the same items every time, and reports what the review missed. Rules in .cursor/rules can carry the pass criteria so generated code starts closer to passing.
Defaults, from the docs verified 2026-09-21
| Default, from the docs | Why it matters for release testing | Source |
|---|---|---|
| Agent "can complete complex coding tasks independently, run terminal commands, and edit code." | Commands the agent runs locally can touch any environment the developer's shell can reach, including production if credentials are present. | docs verified 2026-09-21 |
| Auto-review is the recommended default run mode: "Allowlisted calls run immediately. Other shell commands run in the sandbox when possible." Run Everything: "Every tool call runs automatically." | A team on Run Everything has no approval step between the model and the shell; the release gate has to be in CI, not in the editor. | docs verified 2026-09-21 |
| "Cloud Agents run inside their own dedicated machine, so the agent never asks you to approve an action." | Cloud agent output arrives as changes with no human in the loop until review; the checklist run is that review. | docs verified 2026-09-21 |
| "Project rules live in .cursor/rules as .mdc files and are version-controlled" and "rule contents are included at the start of the model context." | Rules are the place to encode the checklist's pass criteria so generated code starts closer to passing; they shape output but enforce nothing. | docs verified 2026-09-21 |
| "Checkpoints save snapshots of your codebase during an Agent session" and can be restored to revert all files. | Checkpoints cover the working tree, not the database or a deployed environment; rollback of data still needs DM-01 and DR-02. | docs verified 2026-09-21 |
Each row was read on the linked page on the date shown. Docs change; the date tells you how current the row is. Cursor documentation.
Failure patterns most associated
- criticalAPI key shipped in the client bundle
A key meant for the server ends up in JavaScript the browser downloads, so anyone can read it and call the service as the app.
- criticalService-role key used from the front end
The database's bypass-everything key is used in client code, so row-level rules no longer protect anything.
- criticalSecret committed to the repository
A key or token is in git history, where it stays readable to anyone with repository access even after the file changes.
- criticalRow-level security off on a new table
A table created by a migration or SQL has no row-level security, so the anonymous key can read and write every row through the public API.
- criticalPolicy that allows everything
Row-level security is enabled but the policy condition is true for everyone, so isolation exists in name only.
- criticalList endpoint returns other tenants' rows
A list or search endpoint filters by the wrong column or none, so a user sees records belonging to other accounts.
- criticalObject fetched by id without an ownership check
An endpoint checks that the caller is logged in, then returns whatever id was requested.
- criticalAdmin gate enforced only in the UI
The admin page hides its buttons from ordinary users, but the underlying route or action accepts calls from anyone logged in.
How the checklist adapts
- Deploy and rollback items (DR-01, DR-03) are read against the team's run mode: on Run Everything, the production gate must be in CI and the credential inventory matters more.
- Secrets items run on every release because agent sessions paste keys where the call is written; SC-01 scans the built bundle, not the source.
- Access control items run as a second user on every table the release touched, since generated policies optimise for the query working.
- Error handling items get a fault-injection pass on any flow the agent wrote end to end, where the failure branch is most often absent.
Release checklist, five of the published items
v1.0 · verified on 2026-09-21Agents and tools hold no write credentials to production
manual Inventory every credential available to coding agents, CI jobs and developer machines.
No agent or developer session credential can write to production data or trigger a production deploy without a human approval step.
Development and production data stores are separate
manual Read the connection configuration for every environment and every tool or agent with database access.
No development, preview or agent environment holds a production connection string.
Production deploys are triggered only from the reviewed branch in CI
manual Read the deployment configuration and the last 10 production deploy records.
Every production deploy in the sample originates from CI on the protected branch; no local push or agent session deployed to production.
No secret keys in client bundles
automated Scan the built client assets (JS, source maps, HTML) for known key prefixes and for every value present in the server environment file.
Zero matches for key prefixes (sk_, service_role, AKIA, whsec_, private keys) and zero server-only env values found in client assets.
Every table exposed to the client has row-level security enabled
automated Query the database catalog for tables in exposed schemas and their RLS flag (Supabase, Postgres) or list collections against rules (Firebase).
Every exposed table reports RLS enabled; the list of exemptions is empty or each exemption is a public read-only table named in the release notes.
Which plan fits
Growth $5,900/mo
Most Cursor teams release daily and have an API or an LLM feature, which puts them on Growth. A 3-8 person web-only team releasing weekly fits Starter.
For 8-15 engineers, daily releases, web plus API or one mobile platform. Limits, cadence and what is not included.
Questions
QA for Cursor codebase
Cursor generated code testing strategy
Testing AI generated code in production
Get a risk list for your codebase
5 business days, $1,200, credited to the first month.