Editorial review pendingon version support under review
Action boundary
Before you act
- Expected result
- Four deterministic fixtures show success, validation failure, unavailable source, and blocked side effect without touching real accounts.
- Failure mode
- The test suite proves only a happy path or a kill switch that cannot be used when the normal integration is failing.
- Rollback
- Disable the capability through its documented control, revoke disposable credentials, preserve redacted logs, and restore the known-good fixture-only configuration.
A dry run must be capable of saying no
A “dry run” that reaches the live destination, logs in, or creates a draft is not dry. It is a live run with a hopeful label. Your dry-run mode must stop before the authority boundary and return the evidence it would have used.
Minimum fixture suite:
| Case | Expected result | Must not happen |
|---|---|---|
| Valid bounded request | ok with cited fixture evidence |
External write or personal-account access |
| Invalid input | invalid_request with field-level reason |
Tool, MCP, or browser invocation |
| Source unavailable | source_unavailable with retry/owner note |
Silent substitute or invented finding |
| Proposed side effect | side_effect_blocked with confirmation requirement |
Submission, message, deletion, credential mutation |
Add a timeout and a bounded retry policy. A retry must not multiply side effects. Every run needs a non-secret run ID, timestamps, source/tool name, policy decision, and result status.
Kill-switch drill
Document the fastest safe disable action for your chosen surface. Then test it while the fixture target is intentionally unavailable. Evidence is a timestamped result that the next invocation is denied—not an assertion that the feature flag exists somewhere.
Recovery checklist: disable; revoke/disconnect disposable credentials; preserve redacted logs and the triggering input; state whether any write occurred; notify the named 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
Create a failure-state diagram: validate → policy deny / invoke → timeout / source failure → no-side-effect proof → operator recovery. Use patterned connectors and labels so it does not rely on colour alone.
Lesson checkpoint
Ready to move on?
Mark this lesson complete when you can apply its outcome without relying on the examples above.