import type { ChildSelectionInput, RuntimeSelection, SelectionRefusal } from "./runtime-selection.js";
/**
 * R-7b-1: the child's runtime, decided by the CHILD's slot, never inherited from the parent.
 *
 * The `parent` argument is read for nothing at all in this function — see
 * `selectChildRuntimePairing` for the one thing it IS for. It stays in the signature because the
 * plan, the spine's pinned interface and every call site name it, and because a caller holding a
 * parent record is exactly the caller who must be told, at the type level, that the parent does not
 * decide.
 */
export declare function selectChildRuntime(parent: RuntimeSelection, child: ChildSelectionInput): RuntimeSelection | SelectionRefusal;
/**
 * How a parent and its child can talk (WS-15 §6.1, R-7b-1's last clause).
 *
 * `channel` is the bit Lane B's messaging router branches on: a same-runtime pair reaches its child
 * through that runtime's own adapter (a Winter session's `Query.messaging` facet, an official
 * session's own child handles), while a CROSS-RUNTIME pair "talks only through the RuntimeDirectory"
 * — neither runtime can see into the other, so the address must be resolved centrally and the
 * delivery must go through the router's own adapter for the child's runtime.
 */
export interface ChildRuntimePairing {
    /** The child's own record — the thing that gets persisted with the child. */
    child: RuntimeSelection;
    /** The parent's runtime at spawn time, recorded for the pairing only. */
    parentRuntime: RuntimeSelection["runtimeKind"];
    /** True when parent and child ended up on different runtimes. */
    crossRuntime: boolean;
    /** `directory` exactly when `crossRuntime` — the two are one fact, spelled for the two readers. */
    channel: "in-runtime" | "directory";
}
/** `selectChildRuntime` plus the cross-runtime bit, for the messaging lane. */
export declare function selectChildRuntimePairing(parent: RuntimeSelection, child: ChildSelectionInput): ChildRuntimePairing | SelectionRefusal;
/** WS-10's Phase 6.6 amendment: the exact reason prefix a drifted or credential-less child reports. */
export declare const CHILD_PROVIDER_UNAVAILABLE = "child-provider-unavailable";
/**
 * The answer to "can this child be resumed on its own record?" (WS-13c §8, WS-10 §15 amendment).
 *
 * `resumed` carries the child's OWN persisted record, by identity — a resume never re-decides and
 * never rewrites. `unavailable` is `retryable: false` because the two things that produce it (a
 * credential that is gone, a mapping that drifted to a different provider) are not transient, and
 * Lane B maps it straight onto `DeliveryOutcome`'s `{ status: "unavailable"; retryable: false; reason }`
 * with NO generation started.
 */
export type ChildResumeOutcome = {
    kind: "resumed";
    selection: RuntimeSelection;
} | {
    kind: "unavailable";
    retryable: false;
    reason: string;
};
/**
 * Re-resolves a child under its OWN recorded model and provider, for a resume or a SendMessage.
 *
 * WHAT IT ASKS, precisely: "is the row this child is RECORDED on still servable?" — not "which row
 * would a fresh decision pick". WS-10's Phase 6.6 amendment requires that "the resolved provider id
 * must equal the recorded one", and the recorded provider is PINNED into the resolution
 * (`provider: record.providerId`), so `candidatesFor` drops every other provider's rows before this
 * function ever sees them: provider equality is enforced by the pin, not by a comparison afterwards.
 * (It used to be a comparison afterwards, which review r1's M1 measured as unreachable — a live-looking
 * guard that no drifted catalog could fire.)
 *
 * The two things the pin does NOT enforce, and which this function therefore checks:
 *
 *   1. THE ROW ITSELF. One provider can serve two rows for one canonical model, so "the pinned
 *      provider still serves this model" is weaker than "the recorded row is still there". The
 *      recorded `modelRef` is a provider-qualified row key (row 17's whole point), and it must appear
 *      among the servable candidates.
 *   2. THE FAMILY. A row key can move between families across a catalog regeneration, and continuing
 *      a `claude` child on a row that is now in another family would be "a substitution… a different
 *      family", which WS-13c §4 forbids in exactly those words.
 *
 * Either miss is a refusal, never a fall-back onto whichever sibling row still has a credential — that
 * silent re-routing is what would strand a session's continuation on a backend it never ran on.
 *
 * THE RUNTIME IS NEVER RE-DECIDED EITHER. Even when the resolution succeeds, the returned selection is
 * the persisted record, not a new one — "resume and SendMessage follow the child's record, never the
 * parent's current runtime" (R-7b-1), and a resume that re-ran the D13 table could move a live child
 * between runtimes on a credential change.
 */
export declare function resumeChildSelection(record: RuntimeSelection, context: Omit<ChildSelectionInput, "slot" | "model" | "provider">): ChildResumeOutcome;