EXAMPLE / Execution
Stop a write before it runs
Trace a REST request through an approval gate and inspect the zero-handler-call denial assertion.
Follow the pattern. Inspect its limits.
Explore the source walkthrough, its evidence and the choices you would make in your own application.
Declare the boundary
The fixture defines a command with execution.effects set to write and external-side-effect, and execution.approval.required set to true.
An exploration of the inspected source; no example is executed here.
The situation.
A synthetic rest.approval.protected command has write and external-side-effect declarations. The fixture sends a request first without approval evidence, then with a receipt bound to the operation and input.
What you will learn
- Declare effect and approval requirements on an operation.
- Pass receipt evidence through the transport adapter rather than changing operation input.
- Check that a denial happens before the handler runs.
See the boundary first.
The homepage illustration makes the approval sequence visible. It is separate from the source fixture described here.
Open the interactive illustration →Follow the operation.
- 01
Declare the boundary
The fixture defines a command with execution.effects set to write and external-side-effect, and execution.approval.required set to true.
- 02
Inspect the denied request
The first test binds a handler with a call counter. Without a receipt, it expects HTTP 403, APPROVAL_REQUIRED with reason missing_receipt, and calls equal to zero.
- 03
Inspect the approved request
The second test provides a receipt through createFetchHandler's approvalReceipt option and an approval port with a controlled clock. The response is expected to be 200 with value ran.
- 04
Apply the pattern to your side effect
Replace the synthetic handler with your operation and trusted receipt source. Add tests for the exact subject, operation, input, expiry, and effect requirements your application uses.
What the source demonstrates.
- The inspected denial test asserts that the handler is not invoked when a required receipt is missing.
- The approved case adapts receipt evidence outside the operation input.
- The fixture has an inspectable positive and negative request path.
What it does not establish.
- A fresh successful execution in this review.
- An end-to-end human approval UI or trusted production receipt issuer.
- A real external write: the approved handler only returns a fixture value.
Bring it into your environment.
Use the exact source context and prerequisites below. A source walkthrough is not a verified public-package installation recipe.
- Access to the inspected source repository and a checkout at the cited revision.
- The repository's Bun workspace dependencies and required generated package exports. These instructions were inspected; the examples were not executed in this review.
Working directory: packages/platform/delivery/contracts-runtime-server-rest
bun test src/rest-approval-enforcement.test.tsThe source assertions require a 403 denial before invocation and a 200 response for the controlled valid-receipt case.
Test source inspected; not executed here.
Read the related guide →Make the pattern your own.
- Use a trusted application boundary to resolve approval evidence.
- Keep authorization and approval validation at execution time.
- Preserve a negative test that measures whether the handler ran.
Inspect the evidence.
Reviewed 2026-10-27 · b67c376f
Pinned source links require repository access; publication and anonymous package availability were not checked for this example.
- Declared maturity
- experimental fixture metadata
- Catalogue registration
- Library test; not an example catalog entry
- Inline preview
- None
- Execution in this review
- Not rerun
- Production qualification
- Not assessed