@rapidmx/activesync 1.0.0-beta.0

package/dist/types/commands/ItemOperationsCommand.d.ts

@@ -0,0 +1,72 @@
+import { type WbxmlElement } from "../codec/WbxmlElement.js";
+import type { EasCommandContext, EasCommandHandler } from "../EasCommandHandler.js";
+/**
+ * Handles EAS `ItemOperations`: `Fetch` (a `Message`'s full body or an `Attachment`'s binary content, by the
+ * same `ServerId`/uid this library already exposes elsewhere) and `EmptyFolderContents`.
+ *
+ * Per the published [MS-ASCMD] `ItemOperations` request schema (confirmed directly, not assumed), the command
+ * is a strict choice of exactly three operations - `Fetch` (unbounded), `EmptyFolderContents`, and `Move` -
+ * with no fourth "write a new item" capability anywhere in it; `Store` is a required *child* of `Fetch`
+ * (`"Mailbox"` or `"DocumentLibrary"`, the same store-selector role it plays in `SearchCommand`), not a
+ * separate write/upload command as its name might suggest.
+ *
+ * **Pragmatic subset, deliberately not the full MS-ASCMD `ItemOperations` semantics**:
+ * - `Move` moves an entire *conversation* (by `ConversationId`, opaque binary - see `EmailSyncAdapter`'s
+ * `encodeConversationId`/`decodeConversationId`) to a destination folder - unrelated to the standalone
+ * `MoveItems` command's per-message `SrcFldId`/`SrcMsgId`/`DstFldId` shape. Every `Message` sharing the
+ * decoded `conversationId` across the whole mailbox (not just one folder) that the caller has `UPDATE` on is
+ * relocated to `DstFldId`; one lacking permission is silently skipped rather than failing the whole move (a
+ * conversation can legitimately span folders the caller doesn't control, e.g. a shared mailbox's Inbox). An
+ * optional `MoveAlways` (a hint to keep auto-moving future messages in this conversation) is accepted but not
+ * acted on - this library's `MailFilterRule` has no conversation-scoped condition to key an ongoing rule off
+ * of, a documented simplification, not silent data loss (the move itself still happens).
+ * - `Store: "DocumentLibrary"` is rejected per-`Fetch` - matches `SearchCommand`'s own GAL-only scope decision;
+ * this library has no document-library model.
+ * - A `Fetch` failure (not found, no permission, malformed) aborts the whole request via an HTTP-level error
+ * rather than an embedded per-`Fetch` `Status` code the way `Sync`/`MoveItems`/`ResolveRecipients` report
+ * their own per-item failures - a deliberate, documented simplification carried over unchanged from this
+ * command's original single-`Fetch` design, not a new gap introduced by adding multi-`Fetch` support.
+ * - Only the "inline" delivery method is used (content embedded directly in the WBXML response) - the real
+ * spec's "multipart" alternative (WBXML as one part, binary content as a separate part) is not implemented;
+ * every attachment this library's own `ScanPipeline` already accepts is assumed to fit comfortably in memory
+ * for one response, the same assumption `BaseAttachmentRoute.download()` already makes.
+ * - `Options/BodyPreference`'s `Type`/`TruncationSize` are honored for a `Message` body fetch (plain text,
+ * HTML, or - `Type 4` - the raw MIME source verbatim); byte-range fetching (`Range`) is not implemented.
+ * - `EmptyFolderContents`'s `DeleteSubFolders` option is rejected outright rather than silently ignored -
+ * recursive subfolder deletion is out of scope for this pragmatic subset; emptying a single folder's own
+ * `Message`s is the common case this implements.
+ *
+ * `folderClass`/`messageClass`/`attachmentClass` are supplied by the Mongo/SQL concrete subclasses.
+ *
+ * @author Jean-Philippe Steinmetz
+ */
+export declare abstract class ItemOperationsCommand implements EasCommandHandler {
+    readonly command = "ItemOperations";
+    protected abstract folderClass: any;
+    protected abstract messageClass: any;
+    protected abstract attachmentClass: any;
+    private _objectFactory?;
+    private folderRepo?;
+    private messageRepo?;
+    private attachmentRepo?;
+    private blobStore?;
+    private aclUtils?;
+    private maxFetchesPerRequest;
+    private batchSize;
+    init(): Promise<void>;
+    handle(ctx: EasCommandContext): Promise<WbxmlElement | undefined>;
+    private fetchMessage;
+    private emptyFolderContents;
+    /**
+     * Handles `ItemOperations`' `Move`: relocates every `Message` sharing a decoded `ConversationId` to
+     * `DstFldId`. Unlike `emptyFolderContents`/`fetchMessage` (which fail the whole request via a thrown
+     * `ApiError`), this reports failure through the embedded `Status` the same way `MoveItemsCommand` does for
+     * its own per-item results - a malformed/unresolvable `Move` is a normal outcome for this operation, not an
+     * exceptional one. Reports failure (`Status 3`) if not even one message was actually moved - including when
+     * every message sharing the conversation sits in a folder the caller lacks `UPDATE` on, which would
+     * otherwise silently fall through to a false "success" with nothing having moved.
+     */
+    private moveConversation;
+    private moveResponse;
+    private fetchAttachment;
+}

package/dist/types/commands/MeetingResponseCommand.d.ts

@@ -0,0 +1,32 @@
+import { type WbxmlElement } from "../codec/WbxmlElement.js";
+import type { EasCommandContext, EasCommandHandler } from "../EasCommandHandler.js";
+/**
+ * Handles EAS `MeetingResponse`: records the caller's own accept/tentative/decline response to a meeting on
+ * the referenced `CalendarEvent`. `RequestId` is the same `Message`/`CalendarEvent.uid` this library already
+ * exposes as `ServerId` elsewhere (Sync/FolderSync) - no separate lookup table is needed.
+ *
+ * **Pragmatic subset**: only the first `<Request>` in the command is processed (the real spec allows several
+ * per request, matching `Sync`'s own single-`Collection`-per-request scope in this library). A **decline**
+ * soft-deletes the `CalendarEvent` (matching real Exchange behavior) rather than merely flipping the caller's
+ * own `Attendee.responseStatus` - each attendee has their own row already (`CalendarEvent.mailboxUid` scopes
+ * every event to a single mailbox, per this library's architecture), so deleting *this* row only removes the
+ * meeting from the declining attendee's own calendar, leaving the organizer's and every other attendee's own
+ * copy untouched. Accept/Tentative still update `Attendee.responseStatus` in place. The response omits
+ * `CalendarId` for a decline either way, matching the spec's own convention, so a client relying on that
+ * signal isn't misled into thinking a new item was created.
+ *
+ * `calendarEventClass`/`mailboxClass` are supplied by the Mongo/SQL concrete subclasses.
+ *
+ * @author Jean-Philippe Steinmetz
+ */
+export declare abstract class MeetingResponseCommand implements EasCommandHandler {
+    readonly command = "MeetingResponse";
+    protected abstract calendarEventClass: any;
+    protected abstract mailboxClass: any;
+    private _objectFactory?;
+    private calendarEventRepo?;
+    private mailboxRepo?;
+    private aclUtils?;
+    init(): Promise<void>;
+    handle(ctx: EasCommandContext): Promise<WbxmlElement | undefined>;
+}

package/dist/types/commands/MoveItemsCommand.d.ts

@@ -0,0 +1,29 @@
+import { type WbxmlElement } from "../codec/WbxmlElement.js";
+import type { EasCommandContext, EasCommandHandler } from "../EasCommandHandler.js";
+/**
+ * Handles the standalone EAS `MoveItems` command: moves one or more `Message`s between folders in the caller's
+ * own mailbox by `ServerId`/`uid`.
+ *
+ * **Pragmatic subset**: `Message` only - `Contacts`/`Calendar`/`Tasks` moves are rare in practice (unlike
+ * `Message`, whose Inbox-to-subfolder filing is a real, common client action) and would each need their own
+ * ACL/ownership verification path for comparatively little value; a client attempting one gets `Status 3`
+ * rather than being silently ignored. `DstMsgId` in the response is always the same `uid` as `SrcMsgId` - this
+ * library never mints a new identifier on move, unlike a real Exchange server, which sometimes does.
+ *
+ * `messageClass`/`folderClass` are supplied by the Mongo/SQL concrete subclasses.
+ *
+ * @author Jean-Philippe Steinmetz
+ */
+export declare abstract class MoveItemsCommand implements EasCommandHandler {
+    readonly command = "MoveItems";
+    protected abstract messageClass: any;
+    protected abstract folderClass: any;
+    private _objectFactory?;
+    private messageRepo?;
+    private folderRepo?;
+    private aclUtils?;
+    init(): Promise<void>;
+    handle(ctx: EasCommandContext): Promise<WbxmlElement | undefined>;
+    private moveOne;
+    private responseElement;
+}

package/dist/types/commands/PingCommand.d.ts

@@ -0,0 +1,33 @@
+import { type WbxmlElement } from "../codec/WbxmlElement.js";
+import type { EasCommandContext, EasCommandHandler } from "../EasCommandHandler.js";
+/**
+ * Handles EAS `Ping`: a long-poll HTTP request that blocks for up to `HeartbeatInterval` seconds waiting for a
+ * change in any of the client-specified folders, then reports which (if any) actually changed. No websocket
+ * needed - subscribes a plain, request-scoped Redis client (the same construction `BasePushRoute.connect()`
+ * uses, minus its own per-socket bookkeeping this one-shot request doesn't need) directly to the requested
+ * `folderUid` channels. Every `Message`/`CalendarEvent`/etc. mutation already publishes to exactly these
+ * channels via `BaseScopedChildRoute.notify()`/`RepoUtils`'s own push - `Ping` needs no new publish call site
+ * of its own, only a subscriber.
+ *
+ * Requested folder uids are filtered down to only those the caller currently has `READ` on before subscribing -
+ * matching every other command's ownership check on a client-supplied id, since without it a device could
+ * long-poll indefinitely on any folder uid it happens to know (including one it used to have legitimate access
+ * to and no longer does) and learn purely from this channel when that other mailbox's data changes.
+ *
+ * @author Jean-Philippe Steinmetz
+ */
+export declare class PingCommand implements EasCommandHandler {
+    readonly command = "Ping";
+    private redisConfig;
+    private minHeartbeatSeconds;
+    private maxHeartbeatSeconds;
+    private aclUtils?;
+    handle(ctx: EasCommandContext): Promise<WbxmlElement | undefined>;
+    private statusResponse;
+    /** Subscribes to `folderUids` and resolves with whichever of them published a change first, or `[]` if
+     * `timeoutSeconds` elapses with no publish. A missing `datastores:events` config (Redis pub/sub not set up
+     * for this deployment) fails open to "no changes" rather than blocking forever or throwing - `Ping` is a
+     * best-effort low-latency notification path, not the only way a client ever discovers new mail (it will
+     * eventually poll a real `Sync`/`FolderSync` regardless). */
+    private waitForChange;
+}

package/dist/types/commands/ProvisionCommand.d.ts

@@ -0,0 +1,54 @@
+import { type WbxmlElement } from "../codec/WbxmlElement.js";
+import type { EasCommandContext, EasCommandHandler } from "../EasCommandHandler.js";
+/**
+ * Handles the two-request EAS `Provision` handshake (MS-ASPROV) every client must complete before any other
+ * command is honored (see `BaseEasRoute`'s provisioning gate), plus the three-step `RemoteWipe` sub-flow that
+ * rides the same command.
+ *
+ * **Policy issuance/enforcement**: the password/encryption requirements sent back in request 1's policy
+ * document are sourced from `@Config("mail:eas:provision:*")` (defaults below are permissive but not
+ * `0`/`false` across the board, unlike the old hardcoded document) - a deployment can tighten them without
+ * code changes. Enforcement itself is honest but shallow: request 2 must carry back `Status: 1` on its own
+ * `Policy` (a device that reports it could *not* apply the policy, or omits `Status` entirely, is rejected
+ * without provisioning) - this library does not itself verify the device's actual password/encryption state
+ * beyond trusting that self-reported status, matching MS-ASPROV's own protocol design (the wire protocol has
+ * no way for the server to inspect device state directly either).
+ *
+ * - **Request 1** (no `PolicyKey` in the body): mint a new policy key, store it on `DeviceSyncState` (not yet
+ * provisioned), and send back the policy document under that key. If a `RemoteWipe` was requested for this
+ * device (`DeviceSyncState.remoteWipeRequested`, set by an admin - see the remote-wipe route), skip normal
+ * policy issuance entirely and send the `RemoteWipe` directive instead.
+ * - **Request 2** (client echoes the `PolicyKey` back, acknowledging the policy): if the key matches what was
+ * minted in request 1 *and* the client's own `Status` is `1`, mark the device provisioned and re-confirm the
+ * same key; anything else (a stale/replayed key, a device that never actually saw request 1's response, or a
+ * device reporting it could not comply) is rejected without provisioning.
+ * - **RemoteWipe acknowledgement**: after wiping itself, a device sends a bare `<Provision><RemoteWipe>
+ * <Status>1</Status></RemoteWipe></Provision>` (no `Policies`). Detected first, ahead of the normal
+ * issue/acknowledge branching. Clears `remoteWipeRequested` and stamps `remoteWipeAcknowledgedAt` for audit,
+ * but deliberately leaves `provisioned` untouched (`false`, from when the wipe was requested) - the device
+ * must complete a genuine fresh Provision handshake to re-add the account, it does not fall straight back into
+ * "provisioned". `remoteWipeAccountOnly` is recorded for admin audit only; the wire directive sent to the
+ * device is identical either way (a real "wipe just this account's data" vs. "wipe the whole device"
+ * distinction would require an MDM-capable client extension this library doesn't implement).
+ *
+ * @author Jean-Philippe Steinmetz
+ */
+export declare class ProvisionCommand implements EasCommandHandler {
+    readonly command = "Provision";
+    private passwordEnabled;
+    private minPasswordLength;
+    private maxFailedAttempts;
+    private requireDeviceEncryption;
+    private allowSimplePassword;
+    handle(ctx: EasCommandContext): Promise<WbxmlElement | undefined>;
+    /** Request 1: mint and store a new policy key, send the policy document - or, if a remote wipe is
+     * pending for this device, the `RemoteWipe` directive instead. */
+    private issuePolicy;
+    /** Request 2: the client acknowledges the policy key it was handed in request 1, self-reporting whether
+     * it actually applied the policy via its own `Status`. */
+    private acknowledgePolicy;
+    /** The device has wiped itself and is acknowledging - clear the pending flag but leave `provisioned`
+     * alone (still `false`, from when the wipe was requested) so a genuine re-provision is required. */
+    private acknowledgeRemoteWipe;
+    private persist;
+}

package/dist/types/commands/ResolveRecipientsCommand.d.ts

@@ -0,0 +1,34 @@
+import { type WbxmlElement } from "../codec/WbxmlElement.js";
+import type { EasCommandContext, EasCommandHandler } from "../EasCommandHandler.js";
+/**
+ * Handles EAS `ResolveRecipients`: resolves each `<To>` value (a display name, partial name, or address) the
+ * client is unsure how to reach against the mailbox's own `Contact` (GAL) store - the same substring-match
+ * approach `SearchCommand` uses for its own `Store Name="GAL"` lookups, duplicated rather than shared (see
+ * `escapeForLikeQuery`'s own doc comment).
+ *
+ * **Pragmatic subset**: no free-busy `Availability`, no S/MIME `Certificates`/`Options` handling at all - this
+ * command's real-world use is overwhelmingly enterprise S/MIME certificate lookup, which this library doesn't
+ * implement elsewhere either (`ComposeMailCommand` sends plain MIME, never signed/encrypted). A `<To>` value
+ * that already looks like an email address (`LOOKS_LIKE_EMAIL`) is echoed straight back as its own single
+ * exact match rather than searched for, matching a real client's own common case of resolving an address it
+ * already typed correctly.
+ *
+ * `contactClass` is supplied by the Mongo/SQL concrete subclasses.
+ *
+ * @author Jean-Philippe Steinmetz
+ */
+export declare abstract class ResolveRecipientsCommand implements EasCommandHandler {
+    readonly command = "ResolveRecipients";
+    protected abstract contactClass: any;
+    /** Same two-backend `like()` quirk `SearchCommand.likePattern` documents - supplied by the Mongo/SQL
+     * concrete subclasses. */
+    protected abstract likePattern(escaped: string): string;
+    private maxMatches;
+    private _objectFactory?;
+    private contactRepo?;
+    init(): Promise<void>;
+    handle(ctx: EasCommandContext): Promise<WbxmlElement | undefined>;
+    private resolveOne;
+    private recipientElement;
+    private responseElement;
+}

package/dist/types/commands/SearchCommand.d.ts

@@ -0,0 +1,39 @@
+import { type WbxmlElement } from "../codec/WbxmlElement.js";
+import type { EasCommandContext, EasCommandHandler } from "../EasCommandHandler.js";
+/**
+ * Handles EAS `Search` for the `GAL` store only - this library's `Contact` records are also the source of
+ * truth for GAL lookups against a mailbox's own address book (see the architecture note on `Contact` itself);
+ * searching a mailbox's item contents or a document library (the other two `Search` store types the real spec
+ * defines) is out of scope for this pragmatic subset.
+ *
+ * Per the plan's own scope: a simple case-insensitive substring match via `RepoUtils.find()` directly, not the
+ * heavier `SearchProvider` full-text index - GAL lookups are small-scale exact/prefix matching against a
+ * personal address book, not relevance-ranked full text over large content. Only `displayName`/`givenName`/
+ * `surname`/`company` are matched - `Contact.emails`/`phones` are embedded arrays of objects, which a plain
+ * per-field regex query can't reach into on either backend (confirmed: MongoDB's `$regex` against an
+ * array-of-objects field matches nothing useful, and this library's own query-injection guard rejects
+ * dot-notation field paths like `"emails.address"` outright) - a documented gap, not an oversight.
+ *
+ * `contactClass` is supplied by the Mongo/SQL concrete subclasses.
+ *
+ * @author Jean-Philippe Steinmetz
+ */
+export declare abstract class SearchCommand implements EasCommandHandler {
+    readonly command = "Search";
+    protected abstract contactClass: any;
+    /** Wraps an already regex-escaped substring for this backend's `like()` operator. A second real
+     * cross-backend gap (confirmed by reading both implementations, not assumed): Mongo's `like()` compiles to
+     * an unanchored `$regex` (a substring match with no wrapping needed), but the SQL backend's compiles to
+     * TypeORM's `ILike()` (a plain SQL `LIKE`, which is an *exact* case-insensitive match unless the pattern
+     * itself carries `%` wildcards) - so the same escaped pattern needs `%pattern%` on SQL but must NOT get
+     * literal `%` characters on Mongo, where they'd be matched as themselves in the regex and never found.
+     * Supplied by the Mongo/SQL concrete subclasses. */
+    protected abstract likePattern(escaped: string): string;
+    private _objectFactory?;
+    private contactRepo?;
+    private defaultRangeEnd;
+    private maxRangeEnd;
+    init(): Promise<void>;
+    handle(ctx: EasCommandContext): Promise<WbxmlElement | undefined>;
+    private contactToResult;
+}

package/dist/types/commands/SendMailCommand.d.ts

@@ -0,0 +1,10 @@
+import { ComposeMailCommand } from "./ComposeMailCommand.js";
+/**
+ * Handles EAS `SendMail`: relays a freshly composed message with no referenced original - see
+ * `ComposeMailCommand`'s own doc comment for the full shared implementation.
+ *
+ * @author Jean-Philippe Steinmetz
+ */
+export declare abstract class SendMailCommand extends ComposeMailCommand {
+    readonly command = "SendMail";
+}

package/dist/types/commands/SettingsCommand.d.ts

@@ -0,0 +1,37 @@
+import { type WbxmlElement } from "../codec/WbxmlElement.js";
+import type { EasCommandContext, EasCommandHandler } from "../EasCommandHandler.js";
+/**
+ * Handles EAS `Settings`: the first-run/general-purpose device<->server settings exchange. This pragmatic
+ * subset supports the sub-elements every real client actually depends on:
+ *
+ * - `UserInformation`/`Get`: returns the mailbox's `primarySmtpAddress`/`aliasAddresses` as `EmailAddresses`.
+ * - `DeviceInformation`/`Set`: acknowledged with `Status 1` but not persisted anywhere - `DeviceSyncState` has
+ * no fields for a device's model/IMEI/OS/friendly name, and nothing else in this library currently consumes
+ * them. A real client only requires the acknowledgement to proceed past first-run setup, not that the values
+ * are retrievable later.
+ * - `Oof`/`Get` and `Oof`/`Set`: reads/writes `Mailbox.oofEnabled`/`oofMessage`/`oofStartTime`/`oofEndTime`.
+ * `StartTime`/`EndTime` use MS-ASDTYPE's plain `dateTime` type (`Date.prototype.toISOString()`), not Compact
+ * DateTime - confirmed against MS-ASSETTINGS directly, unlike `Calendar`/`Tasks`' timestamp fields (see
+ * `CompactDateTime.ts`'s own doc comment on that exact distinction). A single combined reply message is stored
+ * rather than the spec's three audience-specific `OofMessage` variants (internal/external-known/
+ * external-unknown) - matches this codebase's existing "one thing, not three" simplification precedent (e.g.
+ * `ContactsSyncAdapter`'s single-slot phone/email handling).
+ * - `RightsManagementInformation` is not implemented - deferred, matching this library's "pragmatic subset"
+ * precedent elsewhere (e.g. `ComposeMailCommand`'s own documented gaps).
+ *
+ * `mailboxClass` is supplied by the Mongo/SQL concrete subclasses.
+ *
+ * @author Jean-Philippe Steinmetz
+ */
+export declare abstract class SettingsCommand implements EasCommandHandler {
+    readonly command = "Settings";
+    protected abstract mailboxClass: any;
+    private _objectFactory?;
+    private mailboxRepo?;
+    init(): Promise<void>;
+    handle(ctx: EasCommandContext): Promise<WbxmlElement | undefined>;
+    /** `OofState`: `0`=disabled, `1`=enabled indefinitely, `2`=time-based (only while now is within
+     * `StartTime`/`EndTime`). */
+    private getOof;
+    private setOof;
+}

package/dist/types/commands/SmartForwardCommand.d.ts

@@ -0,0 +1,17 @@
+import { ComposeMailCommand } from "./ComposeMailCommand.js";
+import type { EasCommandContext } from "../EasCommandHandler.js";
+import type { Message } from "@rapidmx/restapi";
+/**
+ * Handles EAS `SmartForward`: relays a freshly composed message threaded to (and referencing) the original via
+ * `<Source>`, then flips the original's `Forwarded` flag - see `ComposeMailCommand`'s own doc comment for the
+ * full shared implementation and this pragmatic subset's scope.
+ *
+ * @author Jean-Philippe Steinmetz
+ */
+export declare abstract class SmartForwardCommand extends ComposeMailCommand {
+    readonly command = "SmartForward";
+    protected markOriginal(ctx: EasCommandContext, original: Message & {
+        uid: string;
+        version: number;
+    }): Promise<void>;
+}

package/dist/types/commands/SmartReplyCommand.d.ts

@@ -0,0 +1,17 @@
+import { ComposeMailCommand } from "./ComposeMailCommand.js";
+import type { EasCommandContext } from "../EasCommandHandler.js";
+import type { Message } from "@rapidmx/restapi";
+/**
+ * Handles EAS `SmartReply`: relays a freshly composed message threaded to (and referencing) the original via
+ * `<Source>`, then flips the original's `Answered` flag - see `ComposeMailCommand`'s own doc comment for the
+ * full shared implementation and this pragmatic subset's scope.
+ *
+ * @author Jean-Philippe Steinmetz
+ */
+export declare abstract class SmartReplyCommand extends ComposeMailCommand {
+    readonly command = "SmartReply";
+    protected markOriginal(ctx: EasCommandContext, original: Message & {
+        uid: string;
+        version: number;
+    }): Promise<void>;
+}

package/dist/types/commands/SyncCommand.d.ts

@@ -0,0 +1,100 @@
+import { type RecoverableBaseEntity } from "@rapidrest/service-core";
+import { type WbxmlElement } from "../codec/WbxmlElement.js";
+import type { EasCommandContext, EasCommandHandler } from "../EasCommandHandler.js";
+/** Binds one MS-ASCMD `Class` value (`"Email"`, `"Contacts"`, ...) to the concrete entity class `SyncCommand`
+ * should build a `RepoUtils` for, and the adapter class that maps that entity to/from `ApplicationData`.
+ * Supplied by the Mongo/SQL concrete subclasses, one map entry per supported collection type.
+ *
+ * `adapterClass`, not a pre-built `adapter` instance: `SyncCommand.init()` instantiates each one itself via
+ * `ObjectFactory`, so an adapter can `@Inject` its own dependencies (`EmailSyncAdapter` needs `BlobStore` for a
+ * Draft's body) exactly like any other DI-managed class in this library - a bare `new EmailSyncAdapter()` has
+ * no way to satisfy that. */
+export interface SyncCollectionBinding<T extends RecoverableBaseEntity> {
+    entityClass: any;
+    adapterClass: any;
+}
+/**
+ * Handles EAS `Sync`: enumerates `Add`/`Change`/`Delete`s for a single folder's contents since the device's last
+ * `Sync` of that folder, using the same watermark-based cursor mechanism `FolderSyncCommand` uses (via
+ * `EasSyncKeyUtils`), scoped by `folderUid` instead of `mailboxUid`, and keyed per-folder in
+ * `DeviceSyncState.folderSyncKeys` (the `CollectionId` a client sends *is* the `folderUid` - this library never
+ * invents a separate collection identifier).
+ *
+ * **Multi-collection requests**: every `<Collection>` in a request's `<Collections>` is processed and gets its
+ * own `<Collection>` entry in the response, each with its own independent `SyncKey`/`Status` - a client
+ * syncing several folders in one round trip (the common case once the initial per-folder backlog is done)
+ * gets one response covering all of them. All per-collection `SyncKey`/remembered-`Class` writes for the whole
+ * request are batched into a single `persistDeviceSyncState` call after every collection has been processed
+ * (never one call per collection) - see `EasSyncKeyUtils.persistDeviceSyncState`'s own doc comment for why a
+ * second write to the same `DeviceSyncState` within one request must never be built off a stale copy.
+ *
+ * **`Class` is only required on a collection's first (`SyncKey "0"`) request**, per `[MS-ASCMD]` - once seen,
+ * it's remembered in `DeviceSyncState.folderCollectionClasses` (keyed by `folderUid`) so a later request may
+ * omit it; omitting it for a folder never previously synced still gets `Status 4` (nothing to fall back to).
+ *
+ * **Every `CollectionId` is ACL-checked against the caller before it's touched**: `processCollection()` requires
+ * `ACLAction.READ` on the folder before enumerating or accepting any Commands for it at all (a folder the caller
+ * can't read is reported the same as an unrecognized collection - Status `4` - rather than leaking whether it
+ * exists); `applyAdd`/`applyChange`/`applyDelete` additionally require `CREATE`/`UPDATE`/`DELETE` respectively,
+ * and `applyChange`/`applyDelete` re-verify the resolved item's own `folderUid` actually matches the collection
+ * being synced (treating a mismatch identically to "not found" - Status `8` - never revealing that the
+ * `ServerId` resolves to something real elsewhere). Without this, a client could supply any other mailbox's
+ * folder/item uid as its own `CollectionId`/`ServerId` and read or mutate that mailbox's data directly - the
+ * same ownership-verification-after-an-`ignoreACL`-lookup pattern `ItemOperationsCommand`/`MoveItemsCommand`
+ * already use, applied consistently here too.
+ *
+ * **Pragmatic subset, deliberately not the full MS-ASCMD `Sync` surface**:
+ * - **Client-originated `Add`/`Change`/`Delete` commands are accepted for every collection type**, including
+ * `Email` (a device creating/editing a Draft, or deleting a message locally - see `applyAdd`/`applyChange`/
+ * `applyDelete`). `[MS-ASCMD]` itself disallows `Add`/`Change` for any *non-draft* `Email` item - this library
+ * doesn't verify a Sync `Email` Add/Change actually targets the caller's own Drafts folder *specifically*
+ * (only that it's a folder the caller actually owns/can write to - see above), matching how Contacts/Calendar/
+ * Tasks folder targeting is equally unchecked beyond ownership elsewhere. A collection whose adapter has no
+ * `fromApplicationData` at all would get Status `6` for `Add`/`Change` instead, but every adapter today
+ * implements it. Per `[MS-ASCMD]`'s own "Add (Sync)"/"Status (Sync)" pages: `Add` always gets a `Responses`
+ * entry (it must report the assigned `ServerId`); `Change`/`Delete` only get one on **failure** - a silent
+ * success means "assume it worked."
+ * - Only a body preview is returned per item (see `EmailSyncAdapter`'s own doc comment) - full body content is
+ * fetched separately via `ItemOperationsCommand`. A Draft's `Email` Add/Change is plain-text-only, with no
+ * attachment support (mirrors `ComposeMailCommand`'s own already-documented attachment gap).
+ *
+ * @author Jean-Philippe Steinmetz
+ */
+export declare abstract class SyncCommand implements EasCommandHandler {
+    readonly command = "Sync";
+    protected abstract collectionBindings: Record<string, SyncCollectionBinding<any>>;
+    /** Supplied by the Mongo/SQL concrete subclasses so a client-originated `Add`'s `newEntityDefaults()` can
+     * be given the caller's own `Mailbox` (`EmailSyncAdapter` needs it for a new Draft's `from`) - same
+     * one-line-per-backend pattern `MeetingResponseCommand`/`SettingsCommand` already use. */
+    protected abstract mailboxClass: any;
+    private windowSize;
+    private _objectFactory?;
+    private aclUtils?;
+    private repos;
+    private adapters;
+    private mailboxRepo?;
+    init(): Promise<void>;
+    /** Resolves the caller's own `Mailbox` at most once per request, and only if actually needed - most `Sync`
+     * requests contain no client-originated `Add` at all, so most requests never pay this extra round trip. */
+    private mailboxLoader;
+    handle(ctx: EasCommandContext): Promise<WbxmlElement | undefined>;
+    /** Processes one `<Collection>` from the request into its own `<Collection>` response element, plus (when
+     * this round advanced anything) the `folderUid`/new `SyncKey`/remembered `Class` for `handle()` to fold
+     * into its single end-of-request `persistDeviceSyncState` call - this method itself never persists
+     * anything, so it's safe to call once per collection in a request without the write-batching hazard
+     * `EasSyncKeyUtils.persistDeviceSyncState`'s doc comment describes. */
+    private processCollection;
+    private itemToCommandElement;
+    /** One client-originated command's outcome: `response` is a `Responses/{Add,Change,Delete}` entry to
+     * include (per MS-ASCMD, always present for `Add`, only present on failure for `Change`/`Delete`);
+     * `writtenAt` is the resulting `dateModified` of whatever was actually written, used to advance the
+     * persisted watermark past this round's own writes (see `handle()`'s own comment on why). */
+    private addResponseElement;
+    private statusResponseElement;
+    private applyAdd;
+    private applyChange;
+    private applyDelete;
+    /** Builds one `<Collection>` response element - `handle()` collects one of these per request `<Collection>`
+     * and wraps the whole set in a single `<Sync><Collections>`. */
+    private collectionResponse;
+}

package/dist/types/commands/mongo/FolderSyncCommandMongo.d.ts

@@ -0,0 +1,8 @@
+import { FolderMongo } from "@rapidmx/restapi/mongo";
+import { FolderSyncCommand } from "../FolderSyncCommand.js";
+/**
+ * @author Jean-Philippe Steinmetz
+ */
+export declare class FolderSyncCommandMongo extends FolderSyncCommand<FolderMongo> {
+    protected folderClass: any;
+}

package/dist/types/commands/mongo/GetItemEstimateCommandMongo.d.ts

@@ -0,0 +1,7 @@
+import { GetItemEstimateCommand, type EstimateCollectionBinding } from "../GetItemEstimateCommand.js";
+/**
+ * @author Jean-Philippe Steinmetz
+ */
+export declare class GetItemEstimateCommandMongo extends GetItemEstimateCommand {
+    protected collectionBindings: Record<string, EstimateCollectionBinding>;
+}

package/dist/types/commands/mongo/ItemOperationsCommandMongo.d.ts

@@ -0,0 +1,9 @@
+import { ItemOperationsCommand } from "../ItemOperationsCommand.js";
+/**
+ * @author Jean-Philippe Steinmetz
+ */
+export declare class ItemOperationsCommandMongo extends ItemOperationsCommand {
+    protected folderClass: any;
+    protected messageClass: any;
+    protected attachmentClass: any;
+}

package/dist/types/commands/mongo/MeetingResponseCommandMongo.d.ts

@@ -0,0 +1,8 @@
+import { MeetingResponseCommand } from "../MeetingResponseCommand.js";
+/**
+ * @author Jean-Philippe Steinmetz
+ */
+export declare class MeetingResponseCommandMongo extends MeetingResponseCommand {
+    protected calendarEventClass: any;
+    protected mailboxClass: any;
+}

package/dist/types/commands/mongo/MoveItemsCommandMongo.d.ts

@@ -0,0 +1,8 @@
+import { MoveItemsCommand } from "../MoveItemsCommand.js";
+/**
+ * @author Jean-Philippe Steinmetz
+ */
+export declare class MoveItemsCommandMongo extends MoveItemsCommand {
+    protected messageClass: any;
+    protected folderClass: any;
+}

package/dist/types/commands/mongo/ResolveRecipientsCommandMongo.d.ts

@@ -0,0 +1,8 @@
+import { ResolveRecipientsCommand } from "../ResolveRecipientsCommand.js";
+/**
+ * @author Jean-Philippe Steinmetz
+ */
+export declare class ResolveRecipientsCommandMongo extends ResolveRecipientsCommand {
+    protected contactClass: any;
+    protected likePattern(escaped: string): string;
+}

package/dist/types/commands/mongo/SearchCommandMongo.d.ts

@@ -0,0 +1,8 @@
+import { SearchCommand } from "../SearchCommand.js";
+/**
+ * @author Jean-Philippe Steinmetz
+ */
+export declare class SearchCommandMongo extends SearchCommand {
+    protected contactClass: any;
+    protected likePattern(escaped: string): string;
+}

package/dist/types/commands/mongo/SendMailCommandMongo.d.ts

@@ -0,0 +1,8 @@
+import { SendMailCommand } from "../SendMailCommand.js";
+/**
+ * @author Jean-Philippe Steinmetz
+ */
+export declare class SendMailCommandMongo extends SendMailCommand {
+    protected folderClass: any;
+    protected messageClass: any;
+}

package/dist/types/commands/mongo/SettingsCommandMongo.d.ts

@@ -0,0 +1,7 @@
+import { SettingsCommand } from "../SettingsCommand.js";
+/**
+ * @author Jean-Philippe Steinmetz
+ */
+export declare class SettingsCommandMongo extends SettingsCommand {
+    protected mailboxClass: any;
+}

package/dist/types/commands/mongo/SmartForwardCommandMongo.d.ts

@@ -0,0 +1,8 @@
+import { SmartForwardCommand } from "../SmartForwardCommand.js";
+/**
+ * @author Jean-Philippe Steinmetz
+ */
+export declare class SmartForwardCommandMongo extends SmartForwardCommand {
+    protected folderClass: any;
+    protected messageClass: any;
+}

package/dist/types/commands/mongo/SmartReplyCommandMongo.d.ts

@@ -0,0 +1,8 @@
+import { SmartReplyCommand } from "../SmartReplyCommand.js";
+/**
+ * @author Jean-Philippe Steinmetz
+ */
+export declare class SmartReplyCommandMongo extends SmartReplyCommand {
+    protected folderClass: any;
+    protected messageClass: any;
+}

package/dist/types/commands/mongo/SyncCommandMongo.d.ts

@@ -0,0 +1,8 @@
+import { SyncCommand, type SyncCollectionBinding } from "../SyncCommand.js";
+/**
+ * @author Jean-Philippe Steinmetz
+ */
+export declare class SyncCommandMongo extends SyncCommand {
+    protected mailboxClass: any;
+    protected collectionBindings: Record<string, SyncCollectionBinding<any>>;
+}

package/dist/types/commands/mongo/index.d.ts

@@ -0,0 +1,9 @@
+export * from "./FolderSyncCommandMongo.js";
+export * from "./SyncCommandMongo.js";
+export * from "./SendMailCommandMongo.js";
+export * from "./SmartForwardCommandMongo.js";
+export * from "./SmartReplyCommandMongo.js";
+export * from "./ItemOperationsCommandMongo.js";
+export * from "./SearchCommandMongo.js";
+export * from "./MeetingResponseCommandMongo.js";
+export * from "./SettingsCommandMongo.js";

package/dist/types/commands/sql/FolderSyncCommandSQL.d.ts

@@ -0,0 +1,8 @@
+import { FolderSQL } from "@rapidmx/restapi/sql";
+import { FolderSyncCommand } from "../FolderSyncCommand.js";
+/**
+ * @author Jean-Philippe Steinmetz
+ */
+export declare class FolderSyncCommandSQL extends FolderSyncCommand<FolderSQL> {
+    protected folderClass: any;
+}