import { type EpCaller } from "./endpoint-subjects.js";
/**
 * The RUN-STABLE caller triple a run's durable actions ride, derived from the run id and nothing
 * else. Goal facts key on the submitting triple, so a resume on any host must re-derive the same
 * one or it polls terminals its own submissions never wrote. The grant rows and the mesh handler
 * both call this, so the credential's rails and the subjects the handler publishes on cannot
 * disagree. Grammar: the actor is `[A-Za-z0-9_]+` and the uid `[a-z0-9]{26,32}`, both satisfied
 * by hex slices of the digest.
 */
export declare function runDriverCaller(runId: string): EpCaller;
/** Coordinates for the driver/host pair: replay is takeover-pinned; host schedules also pin instance and epoch. */
export interface RunDriverGrantArgs {
    /** The endpoint hosting the driver: the manager daemon. Leads every record key. */
    endpoint: string;
    runId: string;
    /** The takeover attempt this credential is minted for; names the replay durable (SPEC 14.6). */
    takeoverId: string;
    /** The driving instance's id and epoch: the coordinates its timer schedules are addressed by. */
    instanceId: string;
    epoch: number;
    /** EXPLICIT PLACEMENT TARGET (#1616): the manager endpoint-instance the program named for a
     *  `cwd` spawn. The descriptor is the one the existing instance-dispatch API already accepts —
     *  `{ endpoint, instanceId }`, routed as `EpRoute { mode: "inst", instanceId }`
     *  (endpoint-invoke.ts) — not a new field. Absent ⇒ legacy cwd-omitted behavior, unchanged. */
    placement?: {
        instanceId: string;
    };
}
export declare function runDriverGrants(space: string, args: RunDriverGrantArgs, connId: string): {
    publish: string[];
    subscribe: string[];
};
/** The ONLY operations explicit placement adds reach for (#1616). `describe` is listed because the
 *  baseline describe row is class-rail only, so a PINNED resolve is broker-refused without it. */
export declare const PLACEMENT_COMMANDS: readonly string[];
/** Trusted, per-run host connection. The endpoint-wide checkpoint writes and body-selected
 *  records/fact/timer/chat reads are its residual authority. The runtime confines those verbs
 *  behind journal-checked operations; this profile must never be given to the run driver.
 *  It can replay this run's journal to authorize effects, but cannot append a journal entry. */
export declare function runMediatorGrants(space: string, args: RunDriverGrantArgs, connId: string): {
    publish: string[];
    subscribe: string[];
};
/** One served run-surface call's coordinates (SPEC 14.3). */
export interface RunOperatorGrantArgs {
    /** The endpoint hosting the runs: the manager daemon. Leads every record key. */
    endpoint: string;
    /** The ONE run this call replays. Absent for `run-ps`, which walks records and replays no
     *  journal, and for the answering form, which replays nothing (the pause was already found). A
     *  replay durable's name is one token, so no pattern spans runs: the run is pinned at mint or
     *  there is no journal row at all. */
    runId?: string;
    /** The takeover id this call's journal replay durable is named by, one per call. */
    takeoverId: string;
    /** Present for the SECOND half of `run-answer` and NOTHING else: the call files an answer record
     *  and settles ONE checkpoint, named by its token. The token is found first, under the read form,
     *  by replaying the run's journal; only then is this form minted, so the write rows are pinned to
     *  the one pause being answered and reach no other pause on the endpoint. */
    answers?: {
        token: string;
    };
}
/**
 * The RUN OPERATOR's rows (SPEC 14.3): what the hosting manager needs to SERVE a run's reads and
 * answers without driving it. Minted per served call on its own connection so the serve rails
 * never carry a run's journal or records reach.
 *
 * `run-ps` walks the run records consumer-free; `run-status` also replays the named run's journal
 * through a per-call durable. Both are READS and hold no write row at all. `run-answer` is two
 * calls on two credentials: a READ that replays the journal to find the open pause's token, then
 * an ANSWERING form (`answers: { token }`) that files the answer record and settles that ONE
 * checkpoint. Its three writes are pinned to the token, so an answering credential reaches no
 * other pause of the endpoint, and it holds no replay row at all. The records and EPF reads are
 * stream-wide by the store's own design (a KV point read is `STREAM.MSG.GET` on the one backing
 * stream, and a fact read the same on EPF), the same as every commit-side profile's fencing read.
 * No publish on any journal subject, no run or program record write, no consumer verb on the
 * records store.
 */
export declare function runOperatorGrants(space: string, args: RunOperatorGrantArgs, connId: string): {
    publish: string[];
    subscribe: string[];
};
//# sourceMappingURL=run-driver-grants.d.ts.map