import { type TerminalStatus } from '#utils/format_workflow_result.js';
export type MonitorStreamOptions = {
    workflowId: string;
    runId?: string;
    includePayloads: boolean;
    interval: number;
    json: boolean;
    color: boolean;
};
/**
 * The command surface the stream needs, kept as a parameter rather than a
 * `Command` instance so `workflow start --monitor` can reuse the loop without
 * constructing (or delegating to) a second oclif command — the repo has no
 * `runCommand` precedent and `Command.run( argv, config )` would need a real
 * oclif `Config` that unit tests don't have. `error` must be typed `never` so
 * callers keep type narrowing after an error branch.
 */
export type MonitorStreamIo = {
    log: (message: string) => void;
    warn: (message: string) => void;
    error: (message: string) => never;
};
/**
 * Adapts an oclif command to the above. Late-bound arrows rather than
 * `command.log.bind( command )`: oclif (and the unit tests) replace these as own
 * properties on the instance, so they must resolve at call time. Structurally
 * typed so a test double satisfies it without a real oclif `Config`.
 */
export declare function commandStreamIo(command: {
    log: (message: string) => void;
    warn: (message: string) => unknown;
    error: (message: string, options: {
        exit: number;
    }) => never;
}): MonitorStreamIo;
/**
 * Polls a workflow run and emits status updates until it reaches a terminal
 * state, following continue-as-new chains. Shared by `workflow monitor` and
 * `workflow start --monitor` so both behave identically; see `MonitorStreamIo`
 * for why output is injected rather than taken from a `Command`.
 *
 * Sets `process.exitCode = 1` on a terminal error status rather than throwing,
 * so the caller's own output (e.g. `start`'s "Workflow started successfully")
 * is still the command's primary result. Returns the terminal status it stopped
 * on — `undefined` if it stopped because the user detached — so a caller can
 * tailor its own follow-up (`workflow result` vs `workflow debug`).
 */
export declare function streamWorkflowUpdates(options: MonitorStreamOptions, io: MonitorStreamIo): Promise<TerminalStatus | undefined>;
/**
 * Shared `catch` handling for both entry points. A 400 is the generic status for
 * several distinct causes (invalid pageToken, a missing runId, an out-of-range
 * longPollTimeoutMs) — only override it with the stale-cursor message when the
 * server actually identifies that specific cause; otherwise let the real
 * validation error surface instead of misdiagnosing an unrelated 400.
 *
 * Deliberately no 404 here: "check the workflow ID" only reads correctly where
 * the user typed the id, so `workflow monitor` adds it and `start --monitor`
 * doesn't — there the id came back from `postWorkflowStart`, and the server's own
 * message is left to surface inside the "started, but monitoring stopped" wrapper
 * instead of advising a fix that isn't the user's to make.
 */
export declare function monitorErrorOverrides(error: Error): Record<number, string>;