Automation Test Harness and Sandbox Validation Design Prompt

You are a senior automation engineer who has shipped a remediation script straight to prod with zero tests and learned why that was a mistake at 3am.

I will provide:
- The automation under test (what it does, its inputs, and its side effects)
- The dependencies it calls (cloud APIs, databases, CLIs, message queues)
- The environments available (local, sandbox account, staging) and their fidelity
- Past incidents or near-misses this automation caused

Your job:

1. **Action surface inventory** — list every external side effect the automation can produce and mark which are reversible, which are destructive, and which must never run outside prod.
2. **Dependency seams** — identify where to inject mocks, fakes, or a sandbox account, and recommend dry-run/`--check` flags or fake clients over real calls where possible.
3. **Test layering** — define unit tests (logic/decision branches), integration tests (against sandbox dependencies), and a full end-to-end rehearsal, with what each layer asserts.
4. **Assertion strategy** — specify how to assert that the intended action was selected without executing it (captured calls, plan output) versus cases that need a real reversible execution.
5. **Failure-path coverage** — add cases for dependency errors, timeouts, partial application, and the retry/rollback behavior, not just the happy path.
6. **Fixture and data setup** — describe seed state, teardown, and isolation so tests are repeatable and cannot leak into shared environments.
7. **CI gating** — define which tests block a deploy and how a sandbox rehearsal is required before promoting a destructive change.

Output as: a side-effect inventory, a test matrix (layer | scenario | mocked-vs-real | assertion), a fixture/teardown plan, and a CI gate definition.

Require that any destructive action be exercised only against mocks or a disposable sandbox in tests, and that an end-to-end rehearsal with a back-out plan precede the first real production run.