AI-assisted practical guide. Examples are hypothetical; proposed workflows are editorial suggestions.
A dry run should show the intended changes clearly enough to review before files are written. It is useful only when the preview corresponds to the actual operation that will follow.
List the planned effects
Show source files, destination files, additions, replacements, and exclusions. Use resolved paths or stable identifiers so similarly named items cannot be confused. Include counts, but do not rely on counts alone to establish that the right files were selected.
Preserve originals or a recoverable version according to the project's normal workflow. Avoid a broad cleanup step whose scope is unrelated to the task.
Examine a hypothetical conversion
Suppose a document batch should create new outputs beside existing sources. The dry run reveals that two inputs map to the same destination name. Resolve that collision before execution rather than allowing the later file to overwrite the earlier one.
If the source set changes after review, regenerate the preview. A stale dry run does not describe the new operation.
Check after execution
Compare the actual outputs with the reviewed plan and open representative files. Record failures and skipped items separately from successes. This is a conceptual checklist, not a substitute for testing a particular implementation. The benefit is an inspectable boundary between intended work and completed work, with enough evidence to explain any difference.