Skip to content

Rulvar API reference


Rulvar API reference / @rulvar/effects

@rulvar/effects

The effect lane runtime (rfcs/effects.md): the adapter seam that cannot send without an open attempt record, the provider capability matrix (idempotency-key, qualified lookup, neither), the crash-window recovery that is licensed exclusively by provider-side fencing, the reconciler, receipt verification against a declared trust envelope, and the kill point conformance kit. Consumption semantics (the fold and the writer) live in @rulvar/core; hosts that do not run effects pay nothing for this package.

Docs: https://docs.rulvar.com/guide/effects

Classes

ClassDescription
EffectDispatcher-
EffectReconciler-
FakeEffectProvider-

Interfaces

InterfaceDescription
EffectAdapter-
EffectDispatcherOptions-
EffectDispatchRequest-
EffectLookupRequest-
EffectProviderDescriptorOne provider row of the capability matrix (RFC section 6).
EffectReceiptObservationWhat a provider hands back as evidence of an effect.
EffectReconcilerOptions-
EffectsConformanceOptions-
EffectsTelemetry-
EffectSweepReport-
EffectTrustEnvelope-
EffectTrustKey-
RestorationReport-

Type Aliases

Type AliasDescription
EffectDispatchReport-
EffectDispatchResult-
EffectLookupAnswer-
EffectRecoveryReport-
FakeDispatchBehavior-
ReceiptVerification-
ReceiptVerifierTrust-envelope verification of one receipt observation (the full envelope machinery is the reconciler train's; the seam is here). The default fails closed: an unverified receipt routes the machine to unknown, never to confirmed.

Variables

VariableDescription
EFFECTS_KILL_EXCLUSIONSRows that do not apply per effect class (part of the kit contract).

Functions

FunctionDescription
effectIdempotencyKeyThe stable idempotency key: the logical key bound to its epoch.
effectsConformanceThe kill point catalog as named checks (RFC section 8).
effectsTelemetryOf-
envelopeVerifierAdapts an envelope to the dispatcher's ReceiptVerifier seam.
verifyReceiptObservationVerifies one receipt observation against the envelope. The order of checks is the RFC's: issuer identity, content bindings, key resolution with validity windows, revocation, then the signature itself. A receipt that binds fewer fields than its class requires verifies unverified no matter how good its signature is.