export declare const isObservabilityUpgradeRequiredError: (error: unknown) => boolean;
export declare const getObservabilityUpgradeRequiredMessage: () => string;
/**
 * True for a client-side argument rejection from the World
 * (`code: 'INVALID_ARGUMENT'`).
 *
 * These carry no HTTP status because no request was made, which is exactly
 * why they need naming: status-based branches let them fall through to be
 * rethrown as an unhandled exception, which prints nothing.
 */
export declare const isInvalidArgumentError: (error: unknown) => boolean;
export declare const errorMessage: (error: unknown) => string;
export declare const checkAndHandleVercelAccessError: (error: unknown, backend?: string) => boolean;
/**
 * Report the error classes that are actionable whichever read path produced
 * them: a project-access failure, a plan gate, or an argument the World
 * rejected locally. Returns true when one matched and was logged.
 *
 * Three callers need exactly this set, for the same reason in each case —
 * the message names something the caller can fix, so swallowing it or
 * retrying past it replaces an actionable error with a silent one:
 *
 *   - `handleApiError` composes it with its HTTP-status arms;
 *   - `listSleeps` uses it alone, to decide what it must report rather than
 *     degrade to the event log;
 *   - `workflow cancel` uses it alone, having no fallback at all.
 *
 * One definition rather than three, so the set cannot drift between them.
 */
export declare const reportActionableApiError: (error: unknown, backend?: string) => boolean;
//# sourceMappingURL=errors.d.ts.map