@nodii/onboarding 0.0.1 → 0.1.0-dev.0

package/dist/schema-TfyBU6JW.d.ts

@@ -0,0 +1,107 @@
+import { z } from 'zod/v3';
+
+/**
+ * Contact-form Zod schema — mirrors the LOCKED hub REST contract exactly:
+ *   POST /api/v1/public/onboarding/leads
+ *   Schema: PublicOnboardingLeadsRequest (hub id 8686dd33)
+ *
+ * Constraints (per hub JSON Schema):
+ *   name     — string, 1-200 chars, required
+ *   email    — email format, required
+ *   phone    — string, optional (no server-side constraint beyond string)
+ *   message  — string, ≤4000 chars, optional
+ *   botToken — string, required (reCAPTCHA token, D537)
+ *
+ *   additionalProperties: false
+ *
+ * The schema intentionally does NOT include botToken in the public-facing
+ * ContactFormValues type — that field is injected by the submit client right
+ * before the POST (the widget/form never exposes it to the user).
+ */
+
+/**
+ * The user-visible contact form fields. Validated client-side for UX.
+ * Server re-validates authoritatively (D540 §2).
+ */
+declare const contactFormSchema: z.ZodObject<{
+    name: z.ZodString;
+    email: z.ZodString;
+    phone: z.ZodOptional<z.ZodString>;
+    message: z.ZodOptional<z.ZodString>;
+}, "strip", z.ZodTypeAny, {
+    name: string;
+    email: string;
+    phone?: string | undefined;
+    message?: string | undefined;
+}, {
+    name: string;
+    email: string;
+    phone?: string | undefined;
+    message?: string | undefined;
+}>;
+type ContactFormValues = z.infer<typeof contactFormSchema>;
+/**
+ * The full wire payload — contactFormSchema + botToken.
+ *
+ * STRICT mode: unknown keys are REJECTED (not stripped), mirroring the
+ * server's `additionalProperties: false`. `submitLead` runs every outgoing
+ * payload through this schema before the POST — an extra key never reaches
+ * the wire; it fails fast client-side with OnboardingValidationError.
+ */
+declare const leadsWireSchema: z.ZodObject<{
+    name: z.ZodString;
+    email: z.ZodString;
+    phone: z.ZodOptional<z.ZodString>;
+    message: z.ZodOptional<z.ZodString>;
+} & {
+    botToken: z.ZodString;
+}, "strict", z.ZodTypeAny, {
+    name: string;
+    email: string;
+    botToken: string;
+    phone?: string | undefined;
+    message?: string | undefined;
+}, {
+    name: string;
+    email: string;
+    botToken: string;
+    phone?: string | undefined;
+    message?: string | undefined;
+}>;
+type LeadsWirePayload = z.infer<typeof leadsWireSchema>;
+/**
+ * Validate user-visible form values (no botToken required here).
+ * Returns a Zod SafeParseReturnType (inferred).
+ */
+declare function validateContactForm(values: unknown): z.SafeParseReturnType<{
+    name: string;
+    email: string;
+    phone?: string | undefined;
+    message?: string | undefined;
+}, {
+    name: string;
+    email: string;
+    phone?: string | undefined;
+    message?: string | undefined;
+}>;
+/**
+ * Validate the full wire payload (including botToken) before submission.
+ * STRICT: unknown keys are rejected, matching additionalProperties:false.
+ * This is the exact validation `submitLead` applies on the wire path.
+ * Returns a Zod SafeParseReturnType (inferred).
+ */
+declare function validateLeadsPayload(payload: unknown): z.SafeParseReturnType<{
+    name: string;
+    email: string;
+    botToken: string;
+    phone?: string | undefined;
+    message?: string | undefined;
+}, {
+    name: string;
+    email: string;
+    botToken: string;
+    phone?: string | undefined;
+    message?: string | undefined;
+}>;
+
+export { type ContactFormValues as C, type LeadsWirePayload as L, validateLeadsPayload as a, contactFormSchema as c, leadsWireSchema as l, validateContactForm as v };

package/dist/signup-client-Bl6eUrxR.d.ts

@@ -0,0 +1,259 @@
+import { z } from 'zod/v3';
+import { T as TerminalStage } from './model-IEyDI54w.js';
+import { C as ContactFormValues } from './schema-TfyBU6JW.js';
+
+/**
+ * Submit client for POST /api/v1/public/onboarding/leads.
+ *
+ * Contract per D540 + hub REST interface 8686dd33:
+ *   - Idempotency-Key header REQUIRED (uuid v4, generated ONCE per logical
+ *     submission, REUSED on retries — same key = exactly-once delivery).
+ *   - Outgoing payload validated through leadsWireSchema (STRICT — unknown
+ *     keys rejected, matching additionalProperties:false) BEFORE any fetch.
+ *   - botToken in request body (D537).
+ *   - Response: { accepted: true } on 200/202 (empty/non-JSON 2xx body is
+ *     treated as acceptance; a JSON body that does not confirm acceptance
+ *     throws OnboardingServerError — see parseSuccessBody).
+ *   - 403 bot_challenge_failed  → throw OnboardingBotChallengeError (no retry)
+ *   - 409 spec_stale (D540)     → throw OnboardingSpecStaleError (no retry)
+ *   - 422                       → throw OnboardingValidationError (no retry)
+ *   - 429                       → throw OnboardingRateLimitError (no auto-retry)
+ *   - 5xx                       → retry with SAME idempotency key, capped backoff
+ *   - network error             → retry with SAME idempotency key, capped backoff
+ *
+ * Max retries: 3 attempts total (1 initial + 2 retries).
+ * Backoff: 1s, 2s (capped at 2 retries).
+ */
+
+/**
+ * A bot token, or a provider that mints a FRESH one per attempt.
+ *
+ * reCAPTCHA tokens are SINGLE-USE — the server consumes them at siteverify.
+ * If a 5xx happens AFTER the token was consumed, resending the same token on
+ * retry gets 403. Pass a provider function to mint a fresh token per attempt;
+ * a bare string is back-compat but the caller then OWNS that risk.
+ */
+type BotTokenSource = string | (() => string | Promise<string>);
+declare function resolveBotToken(source: BotTokenSource): Promise<string>;
+interface LeadsSubmitOptions {
+    baseUrl: string;
+    /**
+     * reCAPTCHA token (D537), or a provider called ONCE PER ATTEMPT to mint a
+     * fresh token (recommended — tokens are single-use; a fixed string on a
+     * retried request risks 403 after the first attempt consumed it).
+     */
+    botToken: BotTokenSource;
+    /**
+     * Stable idempotency key for this submission. Generate ONCE with
+     * `generateIdempotencyKey()` and pass the same key for retries.
+     * The server chains this key through to D538 for exactly-once delivery.
+     */
+    idempotencyKey: string;
+    /** Optional custom fetch implementation (defaults to global fetch). */
+    fetch?: typeof globalThis.fetch;
+    /**
+     * Per-attempt request timeout in ms (default 15s). A stalled intake aborts
+     * with OnboardingNetworkError so the widget re-enables instead of hanging.
+     */
+    timeoutMs?: number;
+    /** Optional onAttempt callback for observability (attempt number, 1-based). */
+    onAttempt?: (attempt: number) => void;
+}
+interface LeadsSubmitResult {
+    accepted: true;
+}
+/**
+ * Generate a stable idempotency key for one logical submission.
+ * Uses the Web Crypto API (available in all modern browsers + Bun/Node >= 19).
+ * Call ONCE per user submission, pass the SAME key on retries.
+ */
+declare function generateIdempotencyKey(): string;
+/**
+ * Compute a stable fingerprint of the outgoing lead payload, EXCLUDING
+ * botToken (which is fresh per attempt by design).
+ *
+ * The widget uses this to decide whether a resubmission is a RETRY of the
+ * same logical submission (same fingerprint → reuse the Idempotency-Key)
+ * or a NEW logical submission (fingerprint changed because the user edited
+ * fields → mint a NEW key). This mirrors the server's D538 payload-match
+ * guard: same key + different payload is INVALID_ARGUMENT server-side.
+ *
+ * FNV-1a 32-bit over a stable JSON serialization of [name, email, phone,
+ * message]. Collision risk is irrelevant here — a collision only means an
+ * unnecessary key reuse across two submissions from the same browser tab.
+ */
+declare function computePayloadFingerprint(values: ContactFormValues): string;
+/**
+ * Submit a contact-form lead to the onboarding intake.
+ *
+ * The outgoing payload is validated through leadsWireSchema in STRICT mode
+ * before any network I/O — unknown keys are rejected client-side, exactly
+ * mirroring the server's additionalProperties:false.
+ *
+ * Handles retry semantics: 5xx and network errors are retried up to
+ * MAX_ATTEMPTS total, always with the SAME idempotencyKey to guarantee
+ * exactly-once server-side processing (D538 idempotency chain).
+ *
+ * 403, 409, 422 and 429 are NOT retried — caller handles them.
+ *
+ * @throws {OnboardingValidationError} if the payload fails the strict wire
+ *   schema (unknown keys, constraint violations) — thrown BEFORE any fetch
+ * @throws {OnboardingBotChallengeError} on 403, or if the bot-token provider
+ *   throws (reCAPTCHA unreachable) on any attempt
+ * @throws {OnboardingConflictError} on 409 (leads has no spec_stale concept)
+ * @throws {OnboardingRateLimitError} on 429
+ * @throws {OnboardingServerError} on 5xx after all retries exhausted, or on
+ *   a 2xx whose JSON body does not confirm acceptance
+ * @throws {OnboardingNetworkError} on network failure OR timeout after all
+ *   retries exhausted
+ * @throws {OnboardingValidationError} on 422 (server-side re-validation)
+ */
+declare function submitLead(values: ContactFormValues, options: LeadsSubmitOptions): Promise<LeadsSubmitResult>;
+
+/**
+ * Submit client for POST /api/v1/public/onboarding/submit (D540 §2).
+ *
+ * Contract per the LOCKED hub REST interface (PublicOnboardingSubmitRequest):
+ *   - Body: { specVersion, answers, selectedServices?, botToken,
+ *             consent:{tosAccepted:true, privacyAccepted:true},
+ *             credentials:{email, password(12-256)} }
+ *     additionalProperties: false — validated STRICTLY client-side before
+ *     any fetch (unknown keys are rejected, not stripped).
+ *   - Idempotency-Key header REQUIRED (same D538 discipline as leads:
+ *     stable across retries of the SAME payload; the widget mints a new
+ *     key when the payload fingerprint changes).
+ *   - specVersion policy is reject-stale: 409 → OnboardingSpecStaleError
+ *     carrying the server's current version. The CALLER refetches the spec
+ *     and surfaces re-validation to the user — NEVER silent auto-resubmit.
+ *   - Response: { accepted:true, terminalStage, verificationEmailSent? }.
+ *
+ * Success-body rule for /submit (DIFFERENT from /leads, deliberately):
+ * the response carries REQUIRED routing data (terminalStage decides what
+ * the UI shows next), so a 2xx with an empty/unparseable/garbage body is
+ * an OnboardingServerError — the SDK will not fabricate a terminal stage.
+ * (/leads tolerates body-less 2xx because its only signal IS the status.)
+ */
+
+/**
+ * STRICT wire schema — mirrors PublicOnboardingSubmitRequest exactly
+ * (additionalProperties: false; consent booleans are const-true; password
+ * length 12-256 per the locked schema).
+ */
+declare const signupWireSchema: z.ZodObject<{
+    specVersion: z.ZodString;
+    answers: z.ZodRecord<z.ZodString, z.ZodUnknown>;
+    selectedServices: z.ZodOptional<z.ZodArray<z.ZodString, "many">>;
+    botToken: z.ZodString;
+    consent: z.ZodObject<{
+        tosAccepted: z.ZodLiteral<true>;
+        privacyAccepted: z.ZodLiteral<true>;
+    }, "strict", z.ZodTypeAny, {
+        tosAccepted: true;
+        privacyAccepted: true;
+    }, {
+        tosAccepted: true;
+        privacyAccepted: true;
+    }>;
+    credentials: z.ZodObject<{
+        email: z.ZodString;
+        password: z.ZodString;
+    }, "strict", z.ZodTypeAny, {
+        email: string;
+        password: string;
+    }, {
+        email: string;
+        password: string;
+    }>;
+}, "strict", z.ZodTypeAny, {
+    botToken: string;
+    specVersion: string;
+    credentials: {
+        email: string;
+        password: string;
+    };
+    answers: Record<string, unknown>;
+    consent: {
+        tosAccepted: true;
+        privacyAccepted: true;
+    };
+    selectedServices?: string[] | undefined;
+}, {
+    botToken: string;
+    specVersion: string;
+    credentials: {
+        email: string;
+        password: string;
+    };
+    answers: Record<string, unknown>;
+    consent: {
+        tosAccepted: true;
+        privacyAccepted: true;
+    };
+    selectedServices?: string[] | undefined;
+}>;
+type SignupWirePayload = z.infer<typeof signupWireSchema>;
+/** The payload the caller assembles (botToken attached by the transport). */
+interface SignupSubmitBody {
+    specVersion: string;
+    answers: Record<string, unknown>;
+    selectedServices?: string[];
+    consent: {
+        tosAccepted: true;
+        privacyAccepted: true;
+    };
+    credentials: {
+        email: string;
+        password: string;
+    };
+}
+interface SignupSubmitOptions {
+    baseUrl: string;
+    /**
+     * reCAPTCHA token (D537), or a provider called ONCE PER ATTEMPT to mint a
+     * fresh token. Tokens are single-use (consumed at siteverify), so a fixed
+     * string on a retried request risks 403 after the first attempt consumed
+     * it — pass a provider for retry-safe recovery.
+     */
+    botToken: BotTokenSource;
+    /** Stable idempotency key — same discipline as submitLead. */
+    idempotencyKey: string;
+    fetch?: typeof globalThis.fetch;
+    /**
+     * Per-attempt request timeout in ms (default 15s). A stalled intake aborts
+     * with OnboardingNetworkError so the widget re-enables instead of hanging.
+     */
+    timeoutMs?: number;
+    onAttempt?: (attempt: number) => void;
+}
+interface SignupSubmitResult {
+    accepted: true;
+    /** Stage the existing engine landed the applicant at (D540 §2). */
+    terminalStage: TerminalStage;
+    verificationEmailSent?: boolean;
+}
+/**
+ * Stable fingerprint of a signup submission, EXCLUDING botToken (fresh per
+ * attempt by design). Same role as computePayloadFingerprint for leads:
+ * same fingerprint ⇒ retry (reuse the Idempotency-Key); changed
+ * fingerprint ⇒ new logical submission (mint a new key) — mirroring the
+ * server's D538 payload-match guard.
+ */
+declare function computeSignupFingerprint(body: SignupSubmitBody): string;
+/**
+ * Submit a full signup to the onboarding intake.
+ *
+ * @throws {OnboardingValidationError} strict wire-schema failure — BEFORE any fetch
+ * @throws {OnboardingBotChallengeError} on 403, or if the bot-token provider
+ *   throws (reCAPTCHA unreachable) on any attempt
+ * @throws {OnboardingSpecStaleError} on 409 with code:"spec_stale" (caller
+ *   refetches spec); carries the server's currentSpecVersion
+ * @throws {OnboardingConflictError} on a 409 that is NOT spec_stale
+ * @throws {OnboardingRateLimitError} on 429
+ * @throws {OnboardingValidationError} on 422 (server re-validation)
+ * @throws {OnboardingServerError} on 5xx after retries, or a 2xx without
+ *   the required {accepted:true, terminalStage} body
+ * @throws {OnboardingNetworkError} on network failure OR timeout after retries
+ */
+declare function submitSignup(body: SignupSubmitBody, options: SignupSubmitOptions): Promise<SignupSubmitResult>;
+
+export { type BotTokenSource as B, type LeadsSubmitOptions as L, type SignupSubmitBody as S, type LeadsSubmitResult as a, type SignupSubmitOptions as b, type SignupSubmitResult as c, type SignupWirePayload as d, computePayloadFingerprint as e, computeSignupFingerprint as f, generateIdempotencyKey as g, submitLead as h, submitSignup as i, resolveBotToken as r, signupWireSchema as s };

package/dist/spec/index.d.ts

@@ -0,0 +1,88 @@
+import { a as OnboardingSpec } from '../model-IEyDI54w.js';
+export { F as FIELD_KEY_PATTERN, O as OnboarderTier, P as PiiClass, S as SpecField, b as SpecStage, c as SpecStep, T as TerminalStage, o as onboardingSpecSchema, s as specFieldSchema, d as specStepSchema, v as validateOnboardingSpec } from '../model-IEyDI54w.js';
+import 'zod/v3';
+
+/**
+ * Config-fetch client for GET /api/v1/public/onboarding/spec (D540 §1/§3).
+ *
+ * - The onboarder is derived SERVER-side from the request Host (D536) —
+ *   it is NOT sent by the client. The `onboarder` value here is purely the
+ *   CLIENT-side cache key (D540 §3: "cache key (onboarder, specVersion)").
+ * - The spec response is validated against the LOCKED D540 shape before
+ *   it is returned; a malformed spec throws OnboardingSpecInvalidError.
+ * - Cache semantics: every successful fetch is stored under
+ *   (onboarder, specVersion) and as the onboarder's "latest". The versioned
+ *   entries let the 409 spec_stale flow diff the previously-served version
+ *   against the refetched one (see `diffSpecFields` + the signup widget's
+ *   handleSpecStale, which reads the cached prior version before refetching).
+ */
+
+/**
+ * In-memory spec cache keyed by (onboarder, specVersion), with a "latest"
+ * pointer per onboarder. Purely client-side; no TTL — the reject-stale
+ * policy (409 spec_stale on submit) is the authoritative staleness signal,
+ * and a refetch overwrites "latest".
+ */
+declare class OnboardingSpecCache {
+    private readonly byVersion;
+    private readonly latest;
+    /**
+     * Collision-proof composite key. Uses JSON.stringify of the tuple so an
+     * onboarder or version containing the delimiter can never alias another
+     * entry — and, critically, contains NO control characters (an earlier
+     * NUL-separator made git treat this whole file as binary/undiffable).
+     */
+    private static versionKey;
+    get(onboarder: string, specVersion: string): OnboardingSpec | undefined;
+    getLatest(onboarder: string): OnboardingSpec | undefined;
+    set(onboarder: string, spec: OnboardingSpec): void;
+    clear(): void;
+}
+/** Module-level default cache (one per page). Injectable for tests/apps. */
+declare const defaultSpecCache: OnboardingSpecCache;
+/**
+ * Diff two spec versions' signup field sets — used by the 409 spec_stale
+ * flow to tell the user WHAT changed. Compares by field key across all
+ * signup steps.
+ */
+interface SpecFieldDiff {
+    added: string[];
+    removed: string[];
+    changed: string[];
+}
+declare function diffSpecFields(prev: OnboardingSpec, next: OnboardingSpec): SpecFieldDiff;
+interface SpecFetchOptions {
+    baseUrl: string;
+    /**
+     * Client-side cache key ONLY (never transmitted; trust is host-derived
+     * per D536). Use the onboarder slug/id your embed is configured with.
+     */
+    onboarder: string;
+    /** Custom fetch implementation (defaults to globalThis.fetch). */
+    fetch?: typeof globalThis.fetch;
+    /** Cache to read/write (defaults to the module-level cache). */
+    cache?: OnboardingSpecCache;
+    /**
+     * Request timeout in ms (default 15s). A stalled intake aborts with
+     * OnboardingNetworkError so the boot doesn't hang on "Loading signup form…".
+     */
+    timeoutMs?: number;
+    /**
+     * When true, return the cached "latest" for this onboarder if present
+     * WITHOUT a network round-trip. Default false (spec fetches are cheap
+     * and the server bumps specVersion on any change). The signup widget's
+     * boot passes preferCached:true so a remount reuses the loaded spec.
+     */
+    preferCached?: boolean;
+}
+/**
+ * Fetch (and validate, and cache) the onboarding spec.
+ *
+ * @throws {OnboardingSpecInvalidError} response does not match D540 §1
+ * @throws {OnboardingRateLimitError} on 429
+ * @throws {OnboardingServerError} on any other non-2xx status
+ * @throws {OnboardingNetworkError} on network failure OR timeout
+ */
+declare function fetchOnboardingSpec(options: SpecFetchOptions): Promise<OnboardingSpec>;
+
+export { OnboardingSpec, OnboardingSpecCache, type SpecFetchOptions, type SpecFieldDiff, defaultSpecCache, diffSpecFields, fetchOnboardingSpec };

package/dist/spec/index.js

@@ -0,0 +1,4 @@
+export { FIELD_KEY_PATTERN, OnboardingSpecCache, defaultSpecCache, diffSpecFields, fetchOnboardingSpec, onboardingSpecSchema, specFieldSchema, specStepSchema, validateOnboardingSpec } from '../chunk-34BQX2KR.js';
+import '../chunk-AW7W3HAC.js';
+//# sourceMappingURL=index.js.map
+//# sourceMappingURL=index.js.map

package/dist/spec/index.js.map

@@ -0,0 +1 @@
+{"version":3,"sources":[],"names":[],"mappings":"","file":"index.js"}

package/dist/submit/index.d.ts

@@ -0,0 +1,106 @@
+export { B as BotTokenSource, L as LeadsSubmitOptions, a as LeadsSubmitResult, S as SignupSubmitBody, b as SignupSubmitOptions, c as SignupSubmitResult, d as SignupWirePayload, e as computePayloadFingerprint, f as computeSignupFingerprint, g as generateIdempotencyKey, r as resolveBotToken, s as signupWireSchema, h as submitLead, i as submitSignup } from '../signup-client-Bl6eUrxR.js';
+import 'zod/v3';
+import '../model-IEyDI54w.js';
+import '../schema-TfyBU6JW.js';
+
+/**
+ * Shared HTTP helper: fetch bounded by a timeout via AbortController.
+ *
+ * Every SDK wire call (spec fetch, leads submit, signup submit) MUST be
+ * bounded — the widgets flip to a disabled/"Sending…"/"Loading…" state
+ * BEFORE the await, so an intake that accepts the connection and then stalls
+ * would otherwise hang the UI forever. On timeout the fetch is aborted and a
+ * typed OnboardingNetworkError is raised by the caller (which maps abort/
+ * network failures uniformly).
+ */
+/** Default per-request timeout. Generous enough for a slow-but-alive intake. */
+declare const DEFAULT_REQUEST_TIMEOUT_MS = 15000;
+interface TimeoutFetchOptions extends RequestInit {
+    /** Per-request timeout in ms. Default DEFAULT_REQUEST_TIMEOUT_MS. */
+    timeoutMs?: number;
+    /** The fetch implementation to use (defaults to globalThis.fetch). */
+    fetchImpl?: typeof globalThis.fetch;
+}
+/**
+ * fetch() with a hard timeout. Aborts the request when the deadline elapses;
+ * the resulting AbortError propagates to the caller (who wraps it as an
+ * OnboardingNetworkError). A caller-supplied `signal` is respected too — if
+ * either the caller aborts OR the timeout fires, the request is aborted.
+ */
+declare function fetchWithTimeout(url: string, options?: TimeoutFetchOptions): Promise<Response>;
+/**
+ * Run a promise with a timeout. On timeout, rejects with `onTimeout()`'s
+ * error. Used to bound calls that don't take an AbortSignal (grecaptcha
+ * .execute()). The underlying op is NOT cancelled (grecaptcha has no abort),
+ * but the caller no longer waits on it — the widget re-enables.
+ */
+declare function withTimeout<T>(op: Promise<T>, timeoutMs: number, onTimeout: () => Error): Promise<T>;
+
+/**
+ * Error taxonomy for the onboarding submit client.
+ *
+ * Maps HTTP status codes and server error bodies to typed errors:
+ *   403 bot_challenge_failed  → OnboardingBotChallengeError
+ *   409 spec_stale (SUBMIT)   → OnboardingSpecStaleError  (submit endpoint only,
+ *                               body { error:true, code:"spec_stale",
+ *                               currentSpecVersion })
+ *   409 (other / LEADS)       → OnboardingConflictError    (generic conflict)
+ *   429                       → OnboardingRateLimitError
+ *   5xx                       → OnboardingServerError (retryable)
+ *   network / timeout         → OnboardingNetworkError
+ */
+type OnboardingErrorKind = "bot_challenge_failed" | "spec_stale" | "spec_invalid" | "conflict" | "rate_limited" | "server_error" | "network_error" | "validation_error";
+declare class OnboardingError extends Error {
+    readonly kind: OnboardingErrorKind;
+    readonly statusCode: number | null;
+    constructor(kind: OnboardingErrorKind, message: string, statusCode?: number | null);
+}
+declare class OnboardingBotChallengeError extends OnboardingError {
+    constructor(message?: string);
+}
+/**
+ * A 409 that is NOT spec_stale. On the /leads path there is no spec_stale
+ * concept (the payload carries no specVersion); on /submit, a 409 that
+ * lacks `code:"spec_stale"` also lands here. Distinct from
+ * OnboardingSpecStaleError so headless consumers switching on `kind` get the
+ * correct diagnosis (a generic conflict, e.g. a D538 same-key concurrent
+ * race) rather than a "form has been updated, refresh" recovery message.
+ */
+declare class OnboardingConflictError extends OnboardingError {
+    constructor(statusCode?: number, message?: string);
+}
+declare class OnboardingRateLimitError extends OnboardingError {
+    readonly retryAfterSeconds: number | null;
+    constructor(retryAfterSeconds?: number | null);
+}
+/**
+ * A /submit 409 whose body carries `code:"spec_stale"` (D540 reject-stale).
+ * The PINNED body shape (confirmed against the crm intake) is exactly:
+ *   { error: true, code: "spec_stale", currentSpecVersion: string }
+ * The version is read ONLY from `currentSpecVersion` — no field hedging.
+ * Submit-endpoint only; /leads 409s are OnboardingConflictError.
+ */
+declare class OnboardingSpecStaleError extends OnboardingError {
+    readonly currentSpecVersion: string;
+    constructor(currentSpecVersion: string);
+}
+declare class OnboardingServerError extends OnboardingError {
+    constructor(statusCode: number, message?: string);
+}
+declare class OnboardingNetworkError extends OnboardingError {
+    constructor(cause?: unknown);
+}
+declare class OnboardingValidationError extends OnboardingError {
+    constructor(message: string);
+}
+/**
+ * The spec endpoint returned a body that does not conform to the LOCKED
+ * D540 §1 response shape. This is a server-side contract violation — the
+ * SDK refuses to render a form from a malformed spec (a half-parsed spec
+ * could silently drop required fields).
+ */
+declare class OnboardingSpecInvalidError extends OnboardingError {
+    constructor(detail: string);
+}
+
+export { DEFAULT_REQUEST_TIMEOUT_MS, OnboardingBotChallengeError, OnboardingConflictError, OnboardingError, type OnboardingErrorKind, OnboardingNetworkError, OnboardingRateLimitError, OnboardingServerError, OnboardingSpecInvalidError, OnboardingSpecStaleError, OnboardingValidationError, fetchWithTimeout, withTimeout };

package/dist/submit/index.js

@@ -0,0 +1,6 @@
+import '../chunk-Z4PA6C2Z.js';
+export { computePayloadFingerprint, computeSignupFingerprint, generateIdempotencyKey, resolveBotToken, signupWireSchema, submitLead, submitSignup } from '../chunk-BQCTDU5V.js';
+import '../chunk-BIFANV7M.js';
+export { DEFAULT_REQUEST_TIMEOUT_MS, OnboardingBotChallengeError, OnboardingConflictError, OnboardingError, OnboardingNetworkError, OnboardingRateLimitError, OnboardingServerError, OnboardingSpecInvalidError, OnboardingSpecStaleError, OnboardingValidationError, fetchWithTimeout, withTimeout } from '../chunk-AW7W3HAC.js';
+//# sourceMappingURL=index.js.map
+//# sourceMappingURL=index.js.map

package/dist/submit/index.js.map

@@ -0,0 +1 @@
+{"version":3,"sources":[],"names":[],"mappings":"","file":"index.js"}