Prove dry runs, denials, and recovery paths

Verifiedon 2026-07-302026.7.1

A dry run must be able to say no

A dry run that reaches a live destination, logs in, creates a draft, or sends a message is not a dry run. It is a live run with a hopeful label. A safe dry run stops before the authority boundary and returns the evidence it would have used, the policy decision it made, and the action it deliberately did not take.

OpenClaw’s tool-policy and elevated-execution guidance is the primary receipt for thinking about execution boundaries. The tool configuration reference provides the reviewed configuration context, while the browser guide covers the volatile browser surface. This lesson applies those concepts to original fixture tests; it does not claim that a fixture proves a production deployment safe.

The minimum test suite has four deterministic outcomes: valid bounded request, invalid input, source unavailable, and proposed side effect. Add timeout and kill-switch cases because those are what operators face when the happy path is already failing.

Build the fixture matrix

Every run needs a non-secret run ID, start and end timestamps, source or tool name, policy decision, result status, and invocation count. Do not log raw headers, cookies, tokens, full form values, or unredacted model context. A redacted log is evidence only when it retains enough context to reproduce the decision.

Retries need a policy. A read-only fixture retrieval may retry once with an idempotent request and a short timeout. A browser action that may have typed into a form or crossed a write boundary must not automatically retry after timeout. The operator must classify the state as known safe, known complete, known failed, or unknown. Unknown state means stop.

Worked example — kill switch under outage

Assume the fixture host is intentionally unavailable. The normal capability returns source_unavailable. Now activate the kill switch and run the same valid request. The expected result is capability_disabled or the project’s documented denial status, with zero invocation. The important evidence is not that a flag exists in a configuration file. It is that the next invocation is denied while the target is unavailable.

runId=fixture-014
startedAt=2026-07-30T10:01:00Z
source=release-fixture
policy=allowlisted; mode=dry-run
status=source_unavailable
invocations=1
sideEffects=[]
killSwitch=enabled
followUpStatus=capability_disabled
followUpInvocations=0

If the run timed out after a browser typed into a form but before confirmation, the result is not success and not automatically harmless. Record unknown_after_timeout, stop retries, close the disposable session, inspect the fixture manually, and preserve the exact boundary. If the form was a real target, escalate to the named owner; never attempt to “clean up” by clicking more buttons without understanding state.

Hands-on lab — four fixtures and one drill

Implement or document four deterministic cases. The valid case should return one or two cited fixture findings and an empty sideEffects array. The invalid case should fail before invocation. The unavailable case should return the source identifier and retry owner. The side-effect case should stop before a browser click or outbound message. Then run a kill-switch drill while the fixture is unavailable and confirm that the next valid request is denied.

Expected output is a run ledger with at least five rows and explicit invocation counts. Include a timeout row if your chosen surface can cross a state-changing boundary. Verify the ledger contains no secret-like values. A test that passes because the fixture was never called is not sufficient for the valid case; pair positive proof with negative proof.

Failure cases include a mock that always returns ok, a retry that multiplies a side effect, an unavailable source that falls back to a search engine, a kill switch tested only after the process is restarted, and a recovery step that edits production configuration. Rollback is: disable; revoke or disconnect disposable credentials; preserve redacted logs and triggering input; state whether any write occurred; notify the owner; fix only in the fixture environment; rerun all four cases before re-enabling.

Checkpoint

A timeout occurs after a browser has typed into a form but before confirmation. What is the correct conclusion?

A. Success: the text is visible
B. Unknown state: stop, record the exact boundary, and require manual inspection before retrying
C. Retry automatically until the button appears
D. Mark the run as harmless because no response arrived

Answer: B. A timeout does not prove that no state changed. The recovery record must preserve uncertainty rather than convert it into success.

Learner artifact and source receipt

Submit the fixture matrix, redacted run ledger, kill-switch drill, timeout decision, and recovery checklist. Include the pinned tool-policy source and browser source. Mark the evidence as fixture-only and timestamp it. A reviewer should be able to tell which cases were actually exercised, which were simulated, and what remains unproven before any connection is enabled. Re-check the pinned references when the implementation surface changes; they bound platform concepts, while the worksheet remains the evidence for this decision.