/**
 * The three verbs that let an authorized workstream say what it is about to
 * expect.
 *
 * This is the half of §2 that turns a rule into a mechanism. Mail has no
 * command authority and never will; the only thing an arriving message may do
 * is SATISFY an expectation that an already-authorized workstream registered
 * in advance. Until these verbs existed there was no way to register one, so
 * the rule was enforced by there being nothing to enforce.
 *
 * Registration is explicit, never inferred
 * ────────────────────────────────────────
 * A caller states the service domain, the recipient address and the purpose
 * before it submits the form. Nothing watches a page and decides an
 * expectation ought to exist. That distinction is the whole authority model:
 * an expectation created by inference is an expectation created by CONTENT,
 * and content is exactly what must never be able to create one.
 *
 * What these handlers do NOT do
 * ─────────────────────────────
 * Validate. The window ceiling, the open-expectation cap, the address and
 * domain normalisation, the refusal when email holds command authority, all
 * of it belongs to `VerificationExpectationBook` and is reached through
 * `InboundExpectationRegistry`. These read arguments, refuse the ones that are
 * missing or the wrong shape with an honest status, and hand the rest over. A
 * second copy of a clamp is a second clamp that can drift from the first.
 *
 * No `http` binding
 * ─────────────────
 * Deliberate, and it is why these live in their own file rather than beside
 * the mail verbs. The callers are inside the daemon. Advertising an
 * `/api/email/expectations` path that no route serves is precisely what the
 * route-reconcile gate reddens, and inventing a REST surface nothing consumes
 * would be inventing a promise to keep.
 */
import type { GatewayMethodCatalog, GatewayMethodHandler } from '../method-catalog.js';
import type { InboundExpectationRegistry } from '../../email/inbound/expectation-registry.js';
/**
 * What a backend must be able to do to serve these verbs.
 *
 * Structurally satisfied by `InboundExpectationRegistry`, so the daemon wiring
 * passes the registry itself rather than an adapter, one implementation of
 * these three operations, not two.
 */
export type EmailExpectationService = Pick<InboundExpectationRegistry, 'open' | 'list' | 'cancel'>;
export declare function createEmailExpectationOpenHandler(service: EmailExpectationService): GatewayMethodHandler;
export declare function createEmailExpectationListHandler(service: EmailExpectationService): GatewayMethodHandler;
export declare function createEmailExpectationCancelHandler(service: EmailExpectationService): GatewayMethodHandler;
/** Attach the expectation handlers to their descriptors (missing = no-op). */
export declare function registerEmailExpectationGatewayMethods(catalog: GatewayMethodCatalog, service: EmailExpectationService): void;
//# sourceMappingURL=email-expectations.d.ts.map