/**
 * P6.3 transactional step (Postgres tier only) — the SDK-side half of the
 * `GetSqlContract` handshake (see `proto/memoflow/v1/worker_service.proto`
 * and `crates/server/src/store/postgres.rs::CHECKPOINT_SQL_CONTRACT_VERSION`).
 *
 * DBOS's strongest guarantee is that a step's checkpoint commits in the SAME
 * database transaction as the step's own writes — exactly-once for that
 * step, under the precondition that the step writes to the same Postgres
 * database DBOS itself uses as its durability store. memoflow's ordinary
 * activity path is at-least-once everywhere (Design Law 6); `ctx.transaction()`
 * closes that gap for the Postgres tier under the EXACT SAME precondition:
 * the guarantee is "exactly-once for database steps when the step writes to
 * the same Postgres database that stores memoflow checkpoints" — never
 * broader than that. See README.md's Execution guarantees section.
 *
 * Mechanism: the worker opens a transaction against the user's own Postgres
 * database (via the caller-supplied `pg` client). If (and only if) that
 * database is the SAME physical database as the configured memoflow store
 * (verified via the `postgres_target_fingerprint` the server reports at
 * startup — never guessed, never assumed), the SDK issues a plain INSERT
 * into `step_checkpoints` using THIS module's versioned SQL, inside that
 * same transaction, right alongside the user's own writes. When the
 * transaction commits, both commit atomically or neither does.
 *
 * Versioning contract: `CHECKPOINT_SQL_CONTRACT_VERSION` in
 * `crates/server/src/store/postgres.rs` is bumped every time the
 * `step_checkpoints` INSERT's column list, order, or semantics change in a
 * way that would make an old version of this file write a non-conformant
 * row. `SUPPORTED_CONTRACT_VERSIONS` below must be extended (never mutated
 * in place — old entries stay so a mixed-version rolling deploy doesn't
 * suddenly become an error) every time the server bumps its version. A
 * worker whose highest supported version is below what the server reports
 * has a STALE SQL CONTRACT and must fail loudly at startup (see
 * `Worker.run()`'s call to `assertSqlContractCompatible`) — writing with an
 * out-of-date INSERT statement against a newer schema could silently produce
 * a checkpoint that isn't "indistinguishable from a server-written one",
 * which is the whole point of this feature.
 */
/** One version's-worth of the `step_checkpoints` INSERT contract. */
export interface CheckpointSqlContract {
    version: number;
    /**
     * Parameterized INSERT (Postgres `$1..$n` placeholders) that writes a
     * COMPLETED activity checkpoint indistinguishable from one the server
     * itself would write via `CHECKPOINT_UPSERT` in postgres.rs — same table,
     * same columns that matter for correctness (namespace/workflow_id/run_id/
     * step_seq identity, step_key, status, output, timestamps), with
     * `is_exactly_once_tx` set to true so the dashboard can badge it
     * EXACTLY_ONCE_TX and the server's CompleteActivity path can recognize
     * it as already-done (never re-checkpointed, never treated as a
     * conflict).
     *
     * Columns intentionally left server-default / null here (retry_policy,
     * next_retry_at, task_queue, timeouts, blob refs, meta) are exactly the
     * ones that only matter for STARTED/RETRYING checkpoints or claim-check —
     * irrelevant for a step that goes straight to COMPLETED in one write.
     */
    insertSql: string;
    /** Builds the positional parameter array matching `insertSql`'s placeholders. */
    buildParams(args: {
        namespace: string;
        workflowId: string;
        runId: string;
        stepSeq: number;
        stepKey: string;
        stepName: string;
        output: Buffer;
        startedAt: Date;
    }): unknown[];
}
/** Highest contract version this SDK build supports. */
export declare const HIGHEST_SUPPORTED_CONTRACT_VERSION: number;
/**
 * Thrown at worker startup when the server's `GetSqlContract.contract_version`
 * exceeds every version this SDK build carries — i.e. this worker's SQL
 * contract is stale relative to the server's schema. FAILS LOUDLY: the
 * worker must not start (never guess at a "close enough" INSERT statement
 * against a schema it doesn't fully understand).
 */
export declare class StaleSqlContractError extends Error {
    readonly serverContractVersion: number;
    readonly highestSupportedVersion: number;
    constructor(serverContractVersion: number, highestSupportedVersion: number);
}
/**
 * Look up the contract this SDK build would use to satisfy a server
 * reporting `serverContractVersion`. Throws `StaleSqlContractError` if the
 * server's version is newer than anything this SDK supports.
 *
 * Note: this SDK always writes using its OWN highest supported version that
 * is `<= serverContractVersion`... in practice there is exactly one
 * currently-shipping version, so this resolves to `CONTRACT_V1` today. The
 * indirection exists so a future v2 can be added without an API break here.
 */
export declare function resolveSqlContract(serverContractVersion: number): CheckpointSqlContract;