Dry run

A non-mutating execution mode that evaluates inputs and reports proposed effects without committing those effects to the protected system.

In a true dry run, the workflow follows enough of the real path to show what it would target while replacing mutations with recorded proposals. A folder cleaner can enumerate candidate deletions and explain the matching rule without removing files. The implementation, not the agent's promise, must prevent side effects. Some external checks, generated identifiers, timing, and race conditions cannot be reproduced exactly, so the preview is evidence about the simulated path rather than a guarantee of the later run.

Builder example

Dry runs reveal scope errors before a bulk edit, deployment, payment batch, or message send. They are most useful when proposals use stable identifiers, include reasons, and can be compared with the committed run. Automated policy checks can approve routine proposals; unusual or consequential ones can take another route. A separate test environment may be better when realistic execution is necessary.

Common confusion: A dry run should not commit protected side effects, but it may still read data, compute, call explicitly safe validation endpoints, or create local diagnostic output. Confirm the tool's contract instead of assuming every feature named dry run is side-effect free.