Define observable behaviour that must remain unchanged before delegating a refactor. If the work alters pricing, validation, permissions, or user-visible outcomes, treat that portion as a separate product change requiring explicit review.
Separate autonomy from correctness
Cursor documents Run Modes governing how agent tool calls run and when approval is requested. Auto-review, Allowlist, and Run Everything differ in approval, sandboxing, and classifier behaviour.
That establishes configurable, mode-dependent autonomy, not a guarantee that an approved action preserves product behaviour. As editorial advice, decide which shell, MCP, or Fetch actions need approval and keep that decision separate from the code acceptance criteria. Consult current mode documentation rather than assuming all actions receive identical scrutiny.
Create a behaviour-preservation ledger
For each affected function, record:
- Existing input: a reproducible synthetic case.
- Existing output: the result agreed as the baseline.
- Invariant: what must remain true after restructuring.
- Permitted change: the internal organisation being improved.
- Prohibited change: behaviour that is outside this assignment.
- Evidence: the comparison needed before accepting the result.
A useful prohibited-change list might exclude new dependencies, changed public response fields, altered rounding, modified access checks, and unrelated file cleanup. Tailor it to the task rather than copying every restriction blindly. Known defects should be labelled explicitly: preserving a baseline is not the same as declaring it desirable forever.
Hypothetical delivery-fee refactor
Suppose a fictional shop's agreed rule charges ₹40 delivery below ₹500 and zero delivery at ₹500 or above. The assignment is to move repeated calculation logic into one function without changing outcomes.
Use synthetic basket values of ₹499, ₹500, and ₹501. Expected delivery fees are ₹40, ₹0, and ₹0. Add a zero-value basket and document the existing agreed behaviour before work begins; do not let the agent invent a new empty-basket policy.
The prohibited-change list forbids altering the threshold, adding a membership exemption, changing amount precision, or rewriting checkout copy. Evaluate the result by comparing the ledger cases and inspecting whether unrelated files or dependencies changed.
If an existing defect emerges, record it as separate feature or bug work. Mixing its correction into the refactor makes the preservation claim harder to evaluate.
Stop when the diff exceeds the boundary
Pause if the proposed changes introduce new behaviour, unexplained dependency changes, or actions outside the agreed approval boundary. Next, split the work into a smaller refactor and a separately authorised behaviour change.
If choosing access for this workflow, check the coding catalog for access format and saved terms before buying. Marketplace account/code/token offers are not proof of official subscription equivalence or identical agent controls.
Sources and scope
Source material checked 29 October 2026; features/policies may change. Cursor Run Modes establishes configurable execution and approval behaviour. The preservation ledger and delivery-fee case are hypothetical editorial review methods, not hands-on mode tests.