import '../assert_dev_env.js';
/**
 * Test-binary RPC actions for cross-process integration tests.
 *
 * Four daemon-token-authed actions, bundled by `create_testing_actions`:
 * **`_testing_reset`** (DB wipe + keeper re-seed), **`_testing_drain_effects`**
 * (audit barrier), **`_testing_mint_session`** (forge an
 * expired-by-construction server-side session for the expiry conformance
 * cases), and **`_testing_schema_snapshot`** (introspect the live schema for
 * cross-impl parity diffing against a Rust backend's `fuz_db` snapshot).
 *
 * `_testing_reset` — full DB wipe + keeper re-seed + optional
 * secondary-account seeding. The
 * handler wipes every auth-namespace row (no keeper-preserve filter),
 * flips `bootstrap_lock` back to its post-bootstrap shape, seeds a
 * fresh keeper account inline (reusing `create_test_account_with_credentials`
 * so cross-process matches in-process write semantics), seeds any
 * caller-requested `extra_accounts` (also direct-inserted at this
 * setup step), refreshes the daemon-token cache to point at the new
 * keeper, and fires the consumer-supplied domain-state callback. The
 * new keeper + secondary credentials return as the action output so
 * the per-test fixture closes over them.
 *
 * The redesign converges in-process and cross-process keeper
 * lifetimes: both modes now run against a freshly bootstrapped keeper
 * per test. Mutation-cascade tests (password change, revoke-all,
 * hardcoded-username signup uniqueness) and direct keeper-vs-admin
 * probes work uniformly cross-process.
 *
 * **Keeper ≠ admin.** The `keeper` and `admin` roles are independent.
 * Keeper authorizes daemon-token / bootstrap paths; admin authorizes
 * the user-facing admin RPC surface. `_testing_reset` seeds the keeper
 * account with `[ROLE_KEEPER, ROLE_ADMIN]` by default — matching the
 * production `bootstrap_account` flow — plus any roles passed via
 * `extra_keeper_roles`. Tests probing the keeper-vs-admin separation
 * (a keeper-only account must 403 on admin RPCs) declare a secondary
 * via `extra_accounts: [{username, roles: [ROLE_KEEPER]}]` so the
 * account is seeded at this same bootstrap-equivalent step.
 *
 * **No free-form runtime bypass.** Earlier drafts considered a separate
 * `_testing_seed_role_grant` action for arbitrary direct grants; that
 * was rejected because a runtime bypass would let tests skip the
 * production consent flow's side-effects (audit emit, WS fan-out) and
 * silently mask bugs in those paths. The bypass that does exist —
 * `extra_accounts` — is framed as bootstrap-time seeding, the same
 * shape `bootstrap_account` itself uses to grant the initial
 * `KEEPER` + `ADMIN` pair. Tests that want a role on a *post-bootstrap*
 * account must route through `role_grant_offer_create` +
 * `role_grant_offer_accept` (the production path); they observe the
 * full event chain.
 *
 * Production safety: this module lives under `cross_backend/` and starts
 * with `import '../assert_dev_env.js';` — production bundles either
 * tree-shake the module out or throw at startup. The Rust mirror
 * (`fuz_testing` crate) ships a parallel action; `cargo xtask
 * check-release` blocks `fuz_testing` from entering production dep
 * graphs.
 *
 * @module
 */
import { z } from 'zod';
import { type RpcAction } from '../../actions/action_rpc.js';
import type { AppDeps } from '../../auth/deps.js';
import type { SessionOptions } from '../../auth/session_cookie.js';
import type { DaemonTokenState } from '../../auth/daemon_token.js';
import type { Db } from '../../db/db.js';
/**
 * The `_testing_reset` action spec.
 *
 * Input:
 * - `extra_keeper_roles` — roles to grant the fresh keeper *in addition
 *   to* `[ROLE_KEEPER, ROLE_ADMIN]` (matching production bootstrap).
 * - `extra_accounts` — additional accounts to seed at this same
 *   bootstrap-equivalent step. Each entry's `roles` are direct-granted
 *   (bypassing offer/accept) because the seed is *part of bootstrap*,
 *   not a post-bootstrap action. Use this for accounts whose required
 *   roles aren't admin-grantable via offer/accept (e.g. `ROLE_KEEPER`,
 *   whose `RoleSpec.grant_paths` is bootstrap-only). For
 *   admin-grantable roles, prefer `fixture.create_account({roles})`
 *   (offer/accept production path).
 *
 * Output: keeper credentials plus a parallel array of seeded
 * `extra_accounts` (same order as input). The per-test fixture closes
 * over the returned values; subsequent calls in the same test see the
 * fresh keeper and any requested secondaries.
 *
 * `auth` gates on the daemon-token credential — the keeper holds it
 * exclusively. The action is internally privileged (it runs direct
 * DB writes the production wire never exposes); daemon-token auth is
 * the structural fence.
 */
export declare const testing_reset_action_spec: {
    readonly method: "_testing_reset";
    readonly kind: "request_response";
    readonly initiator: "frontend";
    readonly auth: {
        readonly account: "required";
        readonly actor: "none";
        readonly credential_types: readonly ["daemon_token"];
    };
    readonly side_effects: true;
    readonly input: z.ZodObject<{
        extra_keeper_roles: z.ZodOptional<z.ZodArray<z.ZodString>>;
        extra_accounts: z.ZodOptional<z.ZodArray<z.ZodObject<{
            username: z.ZodString;
            password_value: z.ZodOptional<z.ZodString>;
            roles: z.ZodArray<z.ZodString>;
        }, z.core.$strict>>>;
    }, z.core.$strict>;
    readonly output: z.ZodObject<{
        account: z.ZodObject<{
            id: z.core.$ZodBranded<z.ZodUUID, "Uuid", "out">;
            username: z.ZodString;
        }, z.core.$strict>;
        actor: z.ZodObject<{
            id: z.core.$ZodBranded<z.ZodUUID, "Uuid", "out">;
        }, z.core.$strict>;
        api_token: z.ZodString;
        session_cookie: z.ZodString;
        extra_accounts: z.ZodArray<z.ZodObject<{
            account: z.ZodObject<{
                id: z.core.$ZodBranded<z.ZodUUID, "Uuid", "out">;
                username: z.ZodString;
            }, z.core.$strict>;
            actor: z.ZodObject<{
                id: z.core.$ZodBranded<z.ZodUUID, "Uuid", "out">;
            }, z.core.$strict>;
            api_token: z.ZodString;
            session_cookie: z.ZodString;
        }, z.core.$strict>>;
    }, z.core.$strict>;
    readonly async: true;
    readonly description: "Test-binary only — wipe auth tables, re-bootstrap a fresh keeper (+ optional extras), fire the domain-state reset.";
};
/**
 * `_testing_drain_effects` — await in-flight fire-and-forget audit writes so
 * a following `audit_log_list` is authoritative. The deterministic barrier
 * the cross-backend conformance suite uses in place of a poll/sleep before
 * asserting on audit rows.
 *
 * On the TS spine the barrier is **satisfied by construction**: the test
 * binary runs `await_pending_effects: true`, so every mutation's fire-and-
 * forget audit emits are awaited before its response returns — by the time
 * a later drain call runs, prior emits are already durable. The action still
 * exists so the cross-backend test body calls the same method on every
 * backend; the Rust spine (whose audit writes are detached tokio tasks)
 * does the real await in `AuditEmitter::drain_inflight`.
 *
 * `auth` gates on the daemon-token credential, matching `_testing_reset`.
 */
export declare const testing_drain_effects_action_spec: {
    readonly method: "_testing_drain_effects";
    readonly kind: "request_response";
    readonly initiator: "frontend";
    readonly auth: {
        readonly account: "required";
        readonly actor: "none";
        readonly credential_types: readonly ["daemon_token"];
    };
    readonly side_effects: false;
    readonly input: z.ZodVoid;
    readonly output: z.ZodObject<{
        ok: z.ZodBoolean;
    }, z.core.$strict>;
    readonly async: true;
    readonly description: "Test-binary only — await in-flight fire-and-forget audit writes so a following audit_log_list read is authoritative.";
};
/**
 * `_testing_mint_session` — mint an expired-by-construction server-side
 * session for an existing account and return its signed cookie value.
 *
 * The minted `auth_session` row's `expires_at` is backdated (negative
 * `expires_in_seconds`) while the returned cookie's own signed payload
 * stays valid (future). Cross-process auth resolution therefore passes the
 * cookie-payload gate (`parse_session`) and is refused by the authoritative
 * DB-row gate (`query_session_get_valid` — `WHERE expires_at > NOW()`) —
 * the gate the in-process payload-expiry tests never reach and the one that
 * structurally needs a server-side mint (the cross-process driver has no
 * keyring / DB access). The `expired_session` conformance principal drives
 * this.
 *
 * `auth` gates on the daemon-token credential, matching `_testing_reset` —
 * effectively keeper-only. Like its siblings the action is internally
 * privileged (a direct `auth_session` insert the production wire never
 * exposes); daemon-token auth is the structural fence and the module's
 * `assert_dev_env` import (TS) plus the Rust `cargo xtask check-release`
 * dep-graph audit keep the `_testing_` surface out of every shipped build.
 */
export declare const testing_mint_session_action_spec: {
    readonly method: "_testing_mint_session";
    readonly kind: "request_response";
    readonly initiator: "frontend";
    readonly auth: {
        readonly account: "required";
        readonly actor: "none";
        readonly credential_types: readonly ["daemon_token"];
    };
    readonly side_effects: true;
    readonly input: z.ZodObject<{
        account_id: z.core.$ZodBranded<z.ZodUUID, "Uuid", "out">;
        expires_in_seconds: z.ZodNumber;
    }, z.core.$strict>;
    readonly output: z.ZodObject<{
        session_cookie: z.ZodString;
    }, z.core.$strict>;
    readonly async: true;
    readonly description: string;
};
/**
 * Build the standalone `_testing_drain_effects` action. No deps — on TS the
 * barrier is satisfied by `await_pending_effects` (see the spec doc), so the
 * handler just returns `{ok: true}`. Mount it on any test endpoint whose
 * suite asserts on audit rows (the spine binary bundles it via
 * `create_testing_actions`; in-process suites mount it directly).
 */
export declare const create_testing_drain_effects_action: () => RpcAction;
/**
 * `_testing_schema_snapshot` — introspect the live database into a normalized
 * `SchemaSnapshot` for cross-impl parity diffing. The cross-backend harness
 * calls this on each backend, then `assert_schema_snapshots_equal`s the
 * results (a Rust backend answers from `fuz_db::query_schema_snapshot`; the
 * shapes match by design). Optional `exclude_tables` drops documented
 * divergences from both sides before comparison.
 *
 * `auth` gates on the daemon-token credential, matching `_testing_reset`.
 */
export declare const testing_schema_snapshot_action_spec: {
    readonly method: "_testing_schema_snapshot";
    readonly kind: "request_response";
    readonly initiator: "frontend";
    readonly auth: {
        readonly account: "required";
        readonly actor: "none";
        readonly credential_types: readonly ["daemon_token"];
    };
    readonly side_effects: false;
    readonly input: z.ZodObject<{
        exclude_tables: z.ZodOptional<z.ZodArray<z.ZodString>>;
    }, z.core.$strict>;
    readonly output: z.ZodObject<{
        tables: z.ZodRecord<z.ZodString, z.ZodObject<{
            columns: z.ZodRecord<z.ZodString, z.ZodObject<{
                data_type: z.ZodString;
                udt_name: z.ZodString;
                is_nullable: z.ZodBoolean;
                column_default: z.ZodNullable<z.ZodString>;
                is_identity: z.ZodBoolean;
            }, z.core.$strip>>;
            indexes: z.ZodArray<z.ZodObject<{
                name: z.ZodString;
                definition: z.ZodString;
            }, z.core.$strip>>;
            constraints: z.ZodArray<z.ZodObject<{
                name: z.ZodString;
                type: z.ZodString;
                definition: z.ZodString;
            }, z.core.$strip>>;
        }, z.core.$strip>>;
        sequences: z.ZodRecord<z.ZodString, z.ZodObject<{
            data_type: z.ZodString;
        }, z.core.$strip>>;
    }, z.core.$strip>;
    readonly async: true;
    readonly description: "Test-binary only — introspect the live schema into a normalized snapshot for cross-impl parity diffing.";
};
/**
 * Build the standalone `_testing_schema_snapshot` action. No deps —
 * introspects `ctx.db` via `query_schema_snapshot`. Bundled by
 * `create_testing_actions`; mount directly for in-process use.
 */
export declare const create_testing_schema_snapshot_action: () => RpcAction;
/** Options for `create_testing_actions`. */
export interface CreateTestingActionsOptions {
    /**
     * Session cookie options — the reset action uses these when signing
     * the fresh keeper's (and any extra accounts') session cookies.
     * Pass the same `SessionOptions` the live `create_app_server` call
     * was wired with.
     */
    readonly session_options: SessionOptions<string>;
    /**
     * Daemon-token runtime state — the reset action mutates
     * `state.keeper_account_id` to point at the freshly seeded keeper
     * after the old row is wiped. Pass the same `DaemonTokenState`
     * instance the daemon-token middleware reads.
     */
    readonly daemon_token_state: DaemonTokenState;
    /**
     * Consumer-supplied callback invoked after the auth-table reset, passed
     * the same transactional `Db` the auth wipes ran on. DB-domain consumers
     * (e.g. fuz_forge truncating its cell / fact / file tables) MUST use this
     * `db` rather than a separately-pooled connection — under PGlite's single
     * connection a second connection deadlocks against this still-open
     * transaction. `testing_zzz_server` clears in-memory workspace registry +
     * terminals + scoped-FS scratch (ignores `db`); `testing_spine_stub` has
     * no domain layer and omits the option. Runs inside the same RPC dispatch
     * as the auth-table writes, so a throw surfaces to the caller as a
     * JSON-RPC error and the per-test fixture short-circuits.
     */
    readonly reset_state?: (db: Db) => Promise<void> | void;
}
/**
 * Build the testing RPC actions for a test binary's registry.
 *
 * Returns `_testing_reset` — the single privileged action test binaries
 * register. The test binary calls this at server-assembly time and
 * registers the result on its dispatcher.
 *
 * The reset action's table-wipe list mirrors
 * `auth_integration_truncate_tables` from `testing/db.ts` — the
 * canonical "auth tables a between-test reset must clear" set.
 * `testing_reset_actions.coverage.test.ts` enforces the set-equality
 * invariant so a future auth migration that adds a table to that list
 * without updating this handler fails CI.
 */
export declare const create_testing_actions: (deps: AppDeps, options: CreateTestingActionsOptions) => Array<RpcAction>;
/** Set of auth-namespace tables `_testing_reset` wipes. Mirrored by the coverage test. */
export declare const testing_reset_wiped_tables: string[];
//# sourceMappingURL=testing_reset_actions.d.ts.map