Checking preview and dry-run modes with a side-effect ledger

Goal

Verify a product’s promise that a preview does not commit protected changes. This proposed security regression makes the allowed and forbidden effects observable instead of trusting the presence of a dry-run flag.

Prerequisites

Use an isolated deployment with synthetic records and controllable substitutes for external delivery. List the effects the preview may produce, such as a temporary plan, and the effects that require final authorization.

Steps

1. Create a ledger of observable state before the preview: relevant records, queued work, delivered messages, and granted capabilities. Limit the inventory to the operation’s declared scope.

2. Run an ordinary committed action as a positive control in a separate disposable fixture. Confirm that the ledger detects the effects the application claims to perform.

3. Run the preview with equivalent synthetic input and compare its ledger with the baseline. Investigate unexpected jobs, notifications, or permission changes even if the main record stayed unchanged.

4. Exercise a preview that reaches a late validation error. Confirm that cleanup follows the same side-effect contract and does not accidentally commit an earlier part of the proposed action.

5. After a repair, compare committed, preview, and failing-preview cases. Preserve intentional preview artifacts explicitly so that harmless planning output does not become an unexplained test exception.

Expected result

The evidence should connect the preview promise to observable effects and distinguish a genuine no-commit path from a response that merely describes itself as a preview.

Limits and test basis

The ledger is only as complete as the identified side effects. This procedure does not establish that external systems can undo work; real external actions must be replaced or explicitly authorized. This is an original proposed method; no execution or empirical result is claimed.