@oxygen-agent/cli 1.377.3 → 1.591.1

package/node_modules/@oxygen/shared/dist/sequences.d.ts

@@ -27,7 +27,7 @@ import { type RenderTemplateOptions } from "./sequence-template.js";
  * and inbox rotation while Oxygen owns the cross-channel timeline + reply
  * suppression.
  */
-export declare const SEQUENCE_CHANNELS: readonly ["linkedin", "email", "whatsapp"];
+export declare const SEQUENCE_CHANNELS: readonly ["linkedin", "email", "whatsapp", "call", "crm"];
 export type SequenceChannel = (typeof SEQUENCE_CHANNELS)[number];
 /**
  * Signals an enrollment accumulates from provider webhooks. wait_for_signal gates
@@ -36,7 +36,7 @@ export type SequenceChannel = (typeof SEQUENCE_CHANNELS)[number];
  * a signal — it's resolved on demand by the dispatcher via a connection branch,
  * `condition: "already_connected"`.)
  */
-export declare const SEQUENCE_SIGNALS: readonly ["linkedin_connected", "linkedin_replied", "whatsapp_replied", "email_sent", "email_opened", "email_clicked", "email_replied", "email_bounced", "meeting_booked", "email_unsubscribed", "company_hiring", "company_raised_funds", "job_change", "new_hire", "web_visit", "intent"];
+export declare const SEQUENCE_SIGNALS: readonly ["linkedin_connected", "linkedin_replied", "whatsapp_replied", "email_sent", "email_opened", "email_clicked", "email_replied", "email_bounced", "meeting_booked", "email_unsubscribed", "call_connected", "call_no_answer", "call_voicemail", "company_hiring", "company_raised_funds", "job_change", "new_hire", "web_visit", "intent"];
 export type SequenceSignal = (typeof SEQUENCE_SIGNALS)[number];
 /**
  * Email engagement signals that ONLY arrive via the Instantly webhook
@@ -49,6 +49,27 @@ export type SequenceSignal = (typeof SEQUENCE_SIGNALS)[number];
  */
 export declare const SEQUENCE_NATIVE_UNTRACKED_SIGNALS: readonly ["email_opened", "email_clicked"];
 export type SequenceNativeUntrackedSignal = (typeof SEQUENCE_NATIVE_UNTRACKED_SIGNALS)[number];
+/**
+ * Signals that ALWAYS terminalize the enrollment the moment they fire, so no
+ * later step can ever observe them. A reply on any channel unconditionally stops
+ * the replying lead's enrollment (`status: 'replied'`, reason `lead_replied` —
+ * see the LinkedIn / WhatsApp / email inbound paths), and the one-click
+ * List-Unsubscribe webhook stops it too (`unsubscribed_one_click`).
+ *
+ * They are still RECORDED on the enrollment (analytics, the timeline, and the
+ * reply-rate rollups all read them), but a branch or wait_for_signal gated on one
+ * is dead code: the enrollment is already terminal when the signal lands, so the
+ * gate always times out / always takes the `else` arm. The builder therefore does
+ * not offer them as branch or gate conditions — reply-stop is built in.
+ */
+export declare const SEQUENCE_TERMINAL_SIGNALS: readonly ["linkedin_replied", "whatsapp_replied", "email_replied", "email_unsubscribed"];
+export type SequenceTerminalSignal = (typeof SEQUENCE_TERMINAL_SIGNALS)[number];
+export declare function isTerminalSequenceSignal(value: string): value is SequenceTerminalSignal;
+/**
+ * The signals a branch / wait_for_signal condition can meaningfully read — every
+ * signal except the terminal ones above. This is what authoring surfaces offer.
+ */
+export declare const SEQUENCE_BRANCHABLE_SIGNALS: readonly SequenceSignal[];
 /** External GTM signals (the non-engagement subset of SEQUENCE_SIGNALS). */
 export declare const SEQUENCE_EXTERNAL_SIGNALS: readonly ["company_hiring", "company_raised_funds", "job_change", "new_hire", "web_visit", "intent"];
 export type SequenceExternalSignal = (typeof SEQUENCE_EXTERNAL_SIGNALS)[number];
@@ -67,17 +88,20 @@ export declare const SEQUENCE_EMAIL_COLUMN_KEYS: readonly ["email", "email_addre
  * complaint loop (the address a bounce/opt-out suppresses), so they can't drift.
  * Returns the trimmed raw value (callers normalize/lowercase as needed) or null.
  */
-export declare function recipientEmailFromRow(rowValues: Record<string, unknown> | null | undefined): string | null;
+export declare function recipientEmailFromRow(rowValues: Record<string, unknown> | null | undefined, emailColumnKey?: string | null): string | null;
 /**
  * ESP (email service provider) MATCHING mode for a sequence (settings.esp_matching).
  * Deliverability lore: a send lands better when the SENDING mailbox and the
  * RECIPIENT sit on the same provider (Google→Google, Microsoft→Microsoft), so at
  * mailbox-pick the dispatcher can bias rotation toward a same-ESP mailbox.
- *   - "off"    — no ESP bias (default); rotation is pure LRU / domain-spread.
- *   - "prefer" — pick a same-ESP mailbox when one is available, else fall back to
- *     any sendable mailbox (never blocks a send).
+ *   - "off"    — no ESP bias; rotation is pure LRU / domain-spread.
+ *   - "prefer" — (DEFAULT) pick a same-ESP mailbox when one is available, else
+ *     fall back to any sendable mailbox (never blocks a send). On by default
+ *     because it only ever improves deliverability and cannot starve sends.
  *   - "strict" — require a same-ESP mailbox; when none is available the action is
  *     DEFERRED with a visible skipped_reason rather than sent cross-provider.
+ *     Power-user setting, reachable via CLI/MCP; the web "Provider Matching"
+ *     checkbox toggles off↔prefer only.
  */
 export declare const ESP_MATCHING_MODES: readonly ["off", "prefer", "strict"];
 export type EspMatchingMode = (typeof ESP_MATCHING_MODES)[number];
@@ -92,28 +116,78 @@ export declare function isEspMatchingMode(value: unknown): value is EspMatchingM
  */
 export declare function validateEspMatchingSetting(value: unknown): void;
 /**
- * The email-provider FAMILY a recipient (or sending mailbox) routes through. Kept
- * intentionally aligned with EMAIL_MAILBOX_PROVIDERS in tenant-db so a mailbox's
- * `provider` and an inferred recipient ESP compare directly.
+ * The MATCHABLE email-provider a recipient routes through — the narrow set ESP
+ * matching can act on. Kept intentionally aligned with EMAIL_MAILBOX_PROVIDERS in
+ * tenant-db so a mailbox's `provider` and a resolved recipient ESP compare
+ * directly: we can only bias rotation toward a provider we can actually SEND
+ * from, and the pool is Google/Microsoft only.
+ *
+ * This is deliberately NARROWER than RECIPIENT_ESP_FAMILIES (what we DISPLAY).
+ * A domain behind Proofpoint has family "proofpoint" but may still be matchable
+ * as "microsoft" — see resolveEspFamily.
  */
 export declare const RECIPIENT_ESPS: readonly ["google", "microsoft"];
 export type RecipientEsp = (typeof RECIPIENT_ESPS)[number];
 /**
- * Infer a recipient's ESP from its email domain, DETERMINISTICALLY, for the
- * well-known consumer domains (gmail/googlemail → google; outlook/hotmail/live/
- * msn → microsoft). Returns null for any other domain — the caller then resolves
- * the ESP via a cached MX lookup (custom domains fronted by Google Workspace /
- * Microsoft 365 aren't decidable from the domain string alone). Pure and
- * side-effect-free so it's the single source of truth for the deterministic map.
+ * The DISPLAY taxonomy: the mail-infrastructure family a recipient domain sits
+ * on. Wider than RecipientEsp because "everything that isn't Google or Microsoft"
+ * is not one thing — a list that is 23% Proofpoint is a very different
+ * deliverability problem from one that is 23% self-hosted, and collapsing both to
+ * null (today's behavior) hides that. Split into three groups:
+ *
+ *   - MAILBOX providers (google, microsoft) — imply a matchable ESP.
+ *   - GATEWAY vendors (proofpoint, mimecast, ...) — security filters that sit IN
+ *     FRONT of a mailbox provider. Their MX tells you the filter, NOT where the
+ *     mailbox lives; the SPF fallback is what sees behind them.
+ *   - OTHER mailbox hosts (zoho, yahoo, fastmail, ...) and self_hosted — real
+ *     destinations we simply cannot send as, so never matchable.
+ */
+export declare const RECIPIENT_ESP_FAMILIES: readonly ["google", "microsoft", "proofpoint", "mimecast", "barracuda", "cisco", "zscaler", "trendmicro", "sophos", "zoho", "yahoo", "apple", "proton", "fastmail", "gmx", "amazon", "self_hosted"];
+export type RecipientEspFamily = (typeof RECIPIENT_ESP_FAMILIES)[number];
+export declare function isRecipientEspFamily(value: unknown): value is RecipientEspFamily;
+export declare function isEspGatewayFamily(family: RecipientEspFamily | null | undefined): boolean;
+/**
+ * The matchable ESP a display family implies, or null when the family is a
+ * gateway (unknown until SPF) or a provider we cannot send as. The ONLY place
+ * family → esp is decided, so display and matching can't drift.
+ */
+export declare function matchableEspFromFamily(family: RecipientEspFamily | null | undefined): RecipientEsp | null;
+/**
+ * Map a domain's resolved MX exchange hostnames to a DISPLAY family. Returns null
+ * when no host matches any known vendor — the caller records that as
+ * "self_hosted" only once it is sure the lookup itself succeeded (an empty/failed
+ * answer is "unknown", which is a different fact).
+ */
+export declare function familyFromMxHosts(hosts: readonly string[] | null | undefined): RecipientEspFamily | null;
+/**
+ * Resolve the matchable ESP from a domain's TXT records by reading its SPF
+ * mechanisms. Scans every `v=spf1` record's include:/redirect= targets.
+ *
+ * AMBIGUITY IS NOT GUESSED: a domain mid-migration (or running Workspace
+ * alongside an Office tenant) can include BOTH vendors. Returning either one
+ * would be a coin flip that strict matching then acts on, so a both-match
+ * degrades to null ("unknown") and the caller falls back / defers honestly.
+ */
+export declare function espFromSpfRecords(records: readonly string[] | null | undefined): RecipientEsp | null;
+/**
+ * Infer a recipient's DISPLAY family from its domain string alone,
+ * DETERMINISTICALLY, for the well-known consumer/freemail domains. Returns null
+ * for any other domain — the caller then resolves via the cached MX (+ SPF)
+ * lookup, because a custom domain fronted by Workspace / M365 / a gateway is not
+ * decidable from the string. Pure: the single source of truth for the map.
+ */
+export declare function inferRecipientEspFamily(domain: string | null | undefined): RecipientEspFamily | null;
+/**
+ * Infer a recipient's MATCHABLE ESP from its domain string. Narrow by design:
+ * only the Google/Microsoft consumer domains resolve here, everything else
+ * (including yahoo/proton/icloud, which are real but unsendable-as) is null.
+ * Unchanged contract — the dispatcher's fast path still calls this.
  */
 export declare function inferRecipientEsp(domain: string | null | undefined): RecipientEsp | null;
 /**
- * Map a domain's resolved MX exchange hostnames to an ESP family, for the MX-cache
- * path (custom domains on Google Workspace / Microsoft 365). Google MX hosts end
- * in `google.com` / `googlemail.com` (e.g. aspmx.l.google.com); Microsoft 365 MX
- * hosts end in `outlook.com` / `protection.outlook.com` (e.g.
- * acme-com.mail.protection.outlook.com). Returns null when no host matches either
- * family. Pure so both the resolver and its tests share one mapping.
+ * Back-compat narrow view of familyFromMxHosts: MX hosts → matchable ESP. Now
+ * derived from the family table so the two can't drift, and gateway MX hosts
+ * correctly yield null here (they need the SPF signal to become matchable).
  */
 export declare function espFromMxHosts(hosts: readonly string[] | null | undefined): RecipientEsp | null;
 /**
@@ -142,6 +216,35 @@ export declare function whatsAppAttendeeIdForPhone(phone: string): string | null
  * enroll/plan path and any preview count can't drift.
  */
 export declare function whatsAppAttendeeIdFromRow(rowValues: Record<string, unknown> | null | undefined, phoneColumnKey?: string | null): string | null;
+/**
+ * Normalize a raw phone number to strict E.164 (`+` then 2-15 digits, no leading
+ * zero) for the CALL channel. Deliberately stricter than
+ * whatsAppAttendeeIdForPhone, which accepts any 7-15 bare digits: on WhatsApp a
+ * bad guess fails an API call, but on the phone it rings a real stranger.
+ *
+ * Rules — anything ambiguous returns null rather than guessing:
+ *   - already "+…"                      -> strip separators, validate, keep.
+ *   - 10 bare digits                    -> NANP national number, prefix "+1".
+ *   - 11 bare digits starting with "1"  -> NANP with country code, prefix "+".
+ *   - anything else                     -> null.
+ *
+ * SCOPE: bare (non-"+") input is completed ONLY for the NANP, where the national
+ * number is always exactly 10 digits. Every other country has a variable national
+ * length (UK 10, Germany 6-11, …), so a bare string genuinely cannot be resolved
+ * to one number — those callers must supply full E.164. That matches v1, which
+ * provisions US/Canada numbers only.
+ *
+ * When international dialing lands, replace this with libphonenumber-js rather
+ * than extending the heuristic — per-country national-number rules are a lookup
+ * table, not something to hand-roll against live prospects.
+ */
+export declare function callPhoneForLead(phone: string): string | null;
+/**
+ * Resolve a lead's dialable E.164 number from its row_values, reusing the SAME
+ * column precedence WhatsApp uses (SEQUENCE_PHONE_COLUMN_KEYS) so the two phone
+ * channels can never disagree about which column holds the number.
+ */
+export declare function callPhoneFromRow(rowValues: Record<string, unknown> | null | undefined, phoneColumnKey?: string | null): string | null;
 /**
  * A per-step / per-sequence send window. `days` are ISO weekdays (1=Mon … 7=Sun)
  * on which sends are allowed; `start`/`end` are "HH:MM" local times. The window
@@ -215,7 +318,7 @@ export type SequenceAutoOptimizeConfig = {
     min_sends_per_variant: number;
     min_conversions: number;
 };
-export declare const SEQUENCE_STEP_KINDS: readonly ["visit_profile", "invite", "wait_for_connection", "message", "inmail", "follow", "like_post", "comment_post", "withdraw_invite", "email_send", "email_reply", "email_enroll", "email_move", "email_stop", "whatsapp_message", "wait", "wait_for_signal", "branch", "stop"];
+export declare const SEQUENCE_STEP_KINDS: readonly ["visit_profile", "invite", "wait_for_connection", "message", "inmail", "follow", "like_post", "comment_post", "withdraw_invite", "email_send", "email_reply", "email_enroll", "email_move", "email_stop", "whatsapp_message", "call_task", "crm_task", "wait", "wait_for_signal", "branch", "stop"];
 export type SequenceStepKind = (typeof SEQUENCE_STEP_KINDS)[number];
 export type SequenceLinkedInVisitProfileStep = {
     id: string;
@@ -384,6 +487,137 @@ export type SequenceWhatsAppMessageStep = {
     /** Opt-in reversible auto-winner over the variants (metric: reply | click | open; reply recommended). */
     auto_optimize?: SequenceAutoOptimizeConfig;
 };
+/**
+ * Queue a call for a human. The one step kind Oxygen does not execute itself.
+ *
+ * Planning it inserts an ox_sequencer.call_tasks row and parks the enrollment
+ * awaiting a call signal, exactly like wait_for_signal — dispositioning the call
+ * writes call_connected / call_no_answer / call_voicemail, which resumes it. That
+ * is why `timeout_days` and `on_timeout` mirror the wait_for_signal shape: a lead
+ * nobody ever calls must not sit in a sequence forever.
+ *
+ * `note` is talking points shown to the rep on the dial screen, NOT a message —
+ * it is never sent anywhere, so it is optional and a blank one does not block a
+ * launch the way empty message copy does.
+ */
+export type SequenceCallTaskStep = {
+    id: string;
+    channel: "call";
+    kind: "call_task";
+    /** Talking points for the rep. Supports {{column}}. Never transmitted. */
+    note?: string;
+    /** Queue ordering; higher dials first. Defaults to 0. */
+    priority?: number;
+    /** Days to wait for a disposition before acting on on_timeout. */
+    timeout_days: number;
+    /** "stop" ends the sequence if nobody calls; "continue" advances. Defaults to "continue". */
+    on_timeout: "stop" | "continue";
+};
+export declare const SEQUENCE_CRM_TASK_PROVIDERS: readonly ["hubspot"];
+export type SequenceCrmTaskProvider = (typeof SEQUENCE_CRM_TASK_PROVIDERS)[number];
+/**
+ * Provider-property value mapping for a CRM task. Keeping the source shape
+ * provider-neutral means a future Salesforce/Pipedrive adapter can consume the
+ * exact same sequence definition while mapping different destination property
+ * names.
+ */
+export type SequenceCrmTaskValueMapping = {
+    source: "literal";
+    value: string | number | boolean;
+} | {
+    source: "row";
+    key: string;
+} | {
+    source: "template";
+    template: string;
+} | {
+    source: "relative_time";
+    offset_minutes: number;
+};
+export declare const SEQUENCE_CRM_IDENTITY_KINDS: readonly ["provider_id", "email", "domain", "linkedin_url", "exact"];
+export type SequenceCrmIdentityKind = (typeof SEQUENCE_CRM_IDENTITY_KINDS)[number];
+/**
+ * One exact identity used to resolve an existing provider record. `kind`
+ * controls normalization while `property` remains provider-configurable (for
+ * example HubSpot's `email` or a customer's custom LinkedIn URL property).
+ */
+export type SequenceCrmRecordIdentityMapping = {
+    kind: SequenceCrmIdentityKind;
+    /** Destination property internal name. Omitted only for provider_id. */
+    property?: string;
+    value: SequenceCrmTaskValueMapping;
+};
+/**
+ * A named person/account/deal binding resolved before the task is created.
+ * Names are local sequence references; object/property names are deliberately
+ * dynamic so another CRM adapter can consume the same lifecycle.
+ */
+export type SequenceCrmRecordMapping = {
+    /** Destination object type, e.g. contacts, companies, people, or deals. */
+    object_type: string;
+    /** Ordered exact identities. Name-only matching is intentionally unsupported. */
+    identities: SequenceCrmRecordIdentityMapping[];
+    /** Dynamic provider properties applied on create/update. */
+    property_mappings: Record<string, SequenceCrmTaskValueMapping>;
+    /** Missing records are only created when explicitly authorized. */
+    on_missing: "fail" | "create";
+    /** Existing records are reused by default; update must be explicit. */
+    on_match: "reuse" | "update";
+};
+export type SequenceCrmRecordLink = {
+    from_record: string;
+    to_record: string;
+    /**
+     * Optional provider association type. HubSpot's default relation is used when
+     * absent; custom labels/types can be supplied without changing the DSL.
+     */
+    association_type_id?: number;
+    association_category?: "HUBSPOT_DEFINED" | "USER_DEFINED";
+};
+type SequenceCrmTaskAssociationOptions = {
+    association_type_id?: number;
+    association_category?: "HUBSPOT_DEFINED" | "USER_DEFINED";
+};
+export type SequenceCrmTaskAssociation = SequenceCrmTaskAssociationOptions & ({
+    /** Attach the task to a record resolved by record_mappings. */
+    record_ref: string;
+    /** Optional override; otherwise the referenced record's object_type wins. */
+    object_type?: string;
+    object_id?: never;
+} | {
+    /** Destination CRM object type, e.g. contacts, companies, or deals. */
+    object_type: string;
+    /** Provider record id resolved from a literal, source-row field, or template. */
+    object_id: SequenceCrmTaskValueMapping;
+    record_ref?: never;
+});
+/**
+ * Create one task in a connected CRM and advance after the provider confirms
+ * creation. Unlike call_task this is an external write, not a human wait gate.
+ */
+export type SequenceCrmTaskStep = {
+    id: string;
+    channel: "crm";
+    kind: "crm_task";
+    provider: SequenceCrmTaskProvider;
+    /** Optional explicit connection; absent resolves the workspace's active one. */
+    connection_id?: string;
+    /**
+     * Destination property internal-name → value source. Property names remain
+     * dynamic so custom CRM fields do not require a new Oxygen release.
+     */
+    property_mappings: Record<string, SequenceCrmTaskValueMapping>;
+    /**
+     * Optional named provider records to resolve/upsert before creating the task.
+     * Exact identity matches are reused, conflicting identities fail closed, and
+     * provider writes are checkpointed independently by the runtime.
+     */
+    record_mappings?: Record<string, SequenceCrmRecordMapping>;
+    /** Optional links between named records, e.g. person → account. */
+    record_links?: SequenceCrmRecordLink[];
+    /** Optional records to associate the newly-created task with. */
+    associations?: SequenceCrmTaskAssociation[];
+};
 export type SequenceWaitStep = {
     id: string;
     kind: "wait";
@@ -501,7 +735,7 @@ export type SequenceSignalCondition = {
 } | {
     not: SequenceSignalCondition;
 };
-export type SequenceStep = SequenceLinkedInVisitProfileStep | SequenceLinkedInInviteStep | SequenceLinkedInWaitForConnectionStep | SequenceLinkedInMessageStep | SequenceLinkedInInMailStep | SequenceLinkedInFollowStep | SequenceLinkedInLikePostStep | SequenceLinkedInCommentPostStep | SequenceLinkedInWithdrawInviteStep | SequenceEmailSendStep | SequenceEmailReplyStep | SequenceEmailEnrollStep | SequenceEmailMoveStep | SequenceEmailStopStep | SequenceWhatsAppMessageStep | SequenceWaitStep | SequenceWaitForSignalStep | SequenceBranchStep | SequenceStopStep;
+export type SequenceStep = SequenceLinkedInVisitProfileStep | SequenceLinkedInInviteStep | SequenceLinkedInWaitForConnectionStep | SequenceLinkedInMessageStep | SequenceLinkedInInMailStep | SequenceLinkedInFollowStep | SequenceLinkedInLikePostStep | SequenceLinkedInCommentPostStep | SequenceLinkedInWithdrawInviteStep | SequenceEmailSendStep | SequenceEmailReplyStep | SequenceEmailEnrollStep | SequenceEmailMoveStep | SequenceEmailStopStep | SequenceWhatsAppMessageStep | SequenceCallTaskStep | SequenceCrmTaskStep | SequenceWaitStep | SequenceWaitForSignalStep | SequenceBranchStep | SequenceStopStep;
 export type SequenceDefinition = {
     steps: SequenceStep[];
 };
@@ -526,7 +760,35 @@ export type ValidateSequenceOptions = {
      * the gate would silently dead-end).
      */
     nativeTrackingEnabled?: boolean;
+    /**
+     * This definition is a DRAFT being authored, so permit an incomplete authoring
+     * state: a sequence with no steps yet, and steps whose copy has not been
+     * written. Default false — a launch-ready definition must have both.
+     *
+     * The web builder autosaves on every edit, so it necessarily persists states no
+     * launch-ready sequence may have: the moment you delete the last step, or drop a
+     * "Send message" before typing it. Rejecting those wedged autosave — the
+     * definition could not be stored at all, so the edit was lost on navigate.
+     *
+     * Completeness is a LAUNCH concern, not a storage one. `sequenceStepsMissingCopy`
+     * and an empty-steps check are the gates the start route runs before a sequence
+     * may go active, and draft -> active is the only route to sending (the status
+     * route refuses that transition outright).
+     */
+    draft?: boolean;
 };
+/** One step whose copy is still empty, for the launch-readiness blocker. */
+export type SequenceMissingCopy = {
+    stepId: string;
+    kind: SequenceStepKind;
+    field: string;
+};
+/**
+ * Steps that still have empty copy — the launch gate for definitions stored
+ * stored under `draft`. Empty means nothing to send, so starting would
+ * either dispatch a blank message or fail per lead at send time.
+ */
+export declare function sequenceStepsMissingCopy(steps: readonly SequenceStep[]): SequenceMissingCopy[];
 /**
  * Validate + normalize a raw sequence definition. Assigns stable ids to steps
  * that omit one (s{index}), verifies branch/gate targets resolve, and enforces
@@ -556,7 +818,8 @@ export declare function sequenceWaitStepDelayWithJitterMs(step: SequenceWaitStep
 /**
  * Render a sequence-copy template against a row's values. Delegates to the shared
  * deterministic engine (sequence-template.ts): `{{column}}` substitution plus
- * `{{column|fallback}}`, `{{RANDOM|…}}` spintax, and `{% if … %}` conditionals.
+ * `{{column|fallback}}`, `{{RANDOM|…}}` and bare `{a|b|c}` spintax (nestable), and
+ * `{% if … %}` conditionals.
  * Pass `{ seed }` to make spintax choices replayable across retries/crash-replays.
  */
 export declare function renderSequenceTemplate(template: string, values: Record<string, unknown>, options?: RenderTemplateOptions): string;