Interface WorkflowTransaction

Commit the batch. The options bag carries only the request tag (WorkflowFetchOptions.tag — attribution, not the deployment tag). Deliberately no visibility: a transaction rides the client's default visibility — 'sync' in @sanity/client (so a post-spawn listInstances GROQ sees freshly-created children), immediate in the in-memory test fake. This is a standing engine assumption — a consumer that configured an async default would make spawn read-backs racy. Single-document writes state 'sync' explicitly via WorkflowCommitOptions.

Queue a create mutation. Fails the transaction on _id collision, same as client.create.

Queue a document delete. Deliberately a transaction-only capability — the top-level client surface stays delete-free so no engine code path can casually remove documents. Engine-side consumers are guard retraction and deleteDefinition housekeeping; outside the engine the CLI's nuke reset deletes raw engine-owned docs through it. Both the real @sanity/client Transaction and the test fake's TransactionHandle carry this shape.

Queue a patch. Expected argument is a WorkflowPatch handle built via client.patch(id).set(…).ifRevisionId(rev) — pass it without calling .commit().

Typed any so the test-client's TransactionHandle.patch(string | PatchHandle, …) and @sanity/client's Transaction.patch(Patch | string, …) both satisfy the field entry under strictFunctionTypes. The engine call site always passes a WorkflowPatch; both underlying clients drain it structurally.