import type { CompletionHandler } from '@crouton-kit/humanloop';
export declare const DECK_SCHEMA_HINT: string;
/**
 * Crouter's private per-interaction record. Reduced to the delivery essentials:
 * the mode `_deliver` dispatches on and the bridge node id it delivers back to.
 * Humanloop owns every public request/result/output path (deck.json,
 * response.json, review.json); crouter never records pane ids or output paths.
 *
 * Every ask records an immutable conversation-fork disposition before ticket
 * publication. A failed capture never suppresses the primary ask: it records an
 * explicit unavailable reason instead of falling back to live-session reads.
 */
export type ConversationFork = {
    status: 'ready';
    source_node_id: string;
    source_file: string;
    source_session_id: string;
    leaf_id: string;
    model_spec: string;
    branch_point: 'branch-point.jsonl';
    captured_at: string;
} | {
    status: 'unavailable';
    reason: 'no_origin' | 'broker_unavailable' | 'invalid_coordinates' | 'invalid_model' | 'materialization_failed';
    detail?: string;
    captured_at: string;
};
export interface RunRecord {
    mode: 'ask' | 'notify' | 'review';
    job_id?: string;
    conversation_fork?: ConversationFork;
}
export declare function resolveMaxPanes(): number;
/**
 * The direct-exec completion handler humanloop runs when a crouter ticket
 * resolves, fed the completion event on stdin. The argv is absolute and
 * PATH/cwd-independent — never a `crtr` shell string — and, critically, must
 * actually EXECUTE in both crouter contexts:
 *
 * - Built (`dist/cli.js` present): `node <abs>/dist/cli.js human _deliver`.
 * - Dev/tsx (only `src/cli.ts` on disk): plain `node` cannot run the `.ts`
 *   entry — its mandatory `.js`-extension ESM imports have no `.js` sibling on
 *   disk, so Node's type-stripping fails at the first relative import. So we
 *   register tsx's ESM loader first (`node --import <abs tsx/esm> src/cli.ts …`),
 *   with the tsx entry resolved to an absolute file URL so the handler stays
 *   cwd-independent when humanloop invokes it. tsx is necessarily present here
 *   because crouter itself is running under it.
 *
 * Throws loudly when neither entry exists rather than registering an argv that
 * humanloop would retry forever.
 */
export declare function crouterDeliverHandler(): CompletionHandler;
/**
 * The direct-exec follow-up handler humanloop runs when the human presses `?`
 * on a pending crouter ticket (design-followup-consult-v2.md §B.5/§B.7) —
 * mirrors `crouterDeliverHandler()` exactly (same dual dist/tsx entry
 * resolution) but targets the hidden `human _consult` leaf. Its presence on
 * the root registration is the ONLY signal humanloop's UI uses to offer `?`,
 * and `human _consult`'s own trust check (M3) requires the registration's
 * `followUpHandler` to be this exact argv shape — a `human _consult` entry
 * inside some sealed runtime generation — so this must stay the same shape as
 * what `registerCrouterRoot` attaches.
 */
export declare function crouterConsultHandler(): CompletionHandler;
/** The focus handler invoked when the human asks the inbox popup to return to
 * the conversation that created its selected ticket. */
export declare function crouterFocusHandler(): CompletionHandler;
/** The frozen Visual handler. Like the other root handlers, this resolves the
 * actual installed or tsx CLI entry rather than depending on PATH. */
export declare function crouterVisualHandler(): CompletionHandler;
/**
 * Register the canvas node root with humanloop as owner `crouter`, attaching
 * the completion, follow-up, Visual, and focus handlers. Every ticket is a
 * direct child named for its bridge node, so node lifetime is ticket lifetime.
 * This also completes the hard cut from stale per-cwd registrations — but
 * never by stranding live tickets: unresolved tickets in an outgoing root are
 * swept into the current root first, and a root that cannot be fully swept
 * stays registered so its tickets remain reachable.
 */
export declare function registerCrouterRoot(): string;