import { type ProviderIdentity } from "./provider.js";
/**
 * Become two real signed-in Clerk users.
 *
 * A Clerk session token is RS256, signed with a key that never leaves Clerk, so
 * minting one is impossible and always will be. Obtaining one is neither
 * impossible nor a trick: Clerk's own testing documentation prescribes exactly
 * this sequence, and its Backend API exposes it.
 *
 *   1. `POST https://api.clerk.com/v1/users` with `Authorization: Bearer
 *      sk_test_…` creates the user. `skip_password_requirement: true` removes
 *      the need for a password, which this flow never uses — the session is
 *      created by user id, not by signing in.
 *      Body: `{ email_address: [".."], skip_password_requirement: true }`.
 *      Response: a `user` object whose `id` is `user_2…`.
 *   2. `POST /v1/sessions` with `{ user_id }` creates an active session with no
 *      credential and no user interaction. Its own description in Clerk's
 *      OpenAPI spec reads: "**This operation is intended only for use in
 *      testing, and is not available for production instances.**" So it works
 *      on a development instance and nowhere else, and a production instance
 *      refusing is a refusal this reports rather than works around.
 *      Response: a `session` object with `id`, `user_id` and `status`.
 *   3. `POST /v1/sessions/{session_id}/tokens` with an optional
 *      `expires_in_seconds` (30 … 315360000) returns `{ object: "token", jwt }`.
 *   4. The application takes it as `Authorization: Bearer <jwt>`, which is what
 *      `clerkMiddleware()` expects — `authenticateRequest`'s `acceptsToken`
 *      defaults to `session_token`.
 *
 * Endpoint shapes read from Clerk's published OpenAPI spec
 * (https://github.com/clerk/openapi-specs, `bapi/2024-10-01.yml`), and the flow
 * from https://clerk.com/docs/guides/development/testing/overview and
 * https://clerk.com/docs/guides/development/making-requests.
 *
 * ## Why the ids come first
 *
 * Clerk assigns `user_2…`. Crossline's personas used to be uuids generated
 * before any of this ran, so a Clerk session would have belonged to somebody
 * who owned none of the planted rows — every probe empty, and empty reads as
 * nothing leaked. So this runs *before* seeding and the ids it returns are the
 * personas' ids. See `provider.ts`.
 *
 * ## What is proven, and what is not
 *
 * The identity is Clerk's own statement: the session object names the
 * `user_id` it was created for, and that has to be the user the create call
 * returned. The token's `sub` is checked against the same id as a second, free
 * cross-check — read, never verified, and never the proof on its own.
 *
 * Two things could not be settled from public documentation and are **not**
 * exercised by Crossline's suite, because they need a live Clerk development
 * instance: whether a Bearer-only request carrying no `__client` cookie
 * resolves to signed-in rather than triggering Clerk's 307 handshake redirect,
 * and whether `expires_in_seconds` is honoured or capped. If the first turns
 * out to need a cookie, the symptom would be an application answering as if
 * signed out — which shows up as the owner check failing, not as a false
 * finding.
 */
export interface ClerkAdminAuth {
    kind: "clerk_admin";
    /** The instance's secret key, `sk_test_…`. Sent to Clerk's API and nowhere else. */
    secretKey: string;
    /** Override for the Backend API root. Defaults to `https://api.clerk.com`. */
    apiUrl?: string;
    /** Session token lifetime. Clerk's default is 60 seconds, which is too short for a run. */
    expiresInSeconds?: number;
}
export declare function becomeClerkUsers(auth: ClerkAdminAuth): Promise<ProviderIdentity>;