import type { WorkflowServicesResolverInfo, WorkflowState } from '../../types.ts';
import type { EngineInternals } from '../internals.ts';
/**
 * Re-provide a recovered inline workflow's non-serialized `services` before its
 * generator is driven forward, and decide whether execution should proceed.
 *
 * Both recovery entry points use this: `resumeWorkflowFromStorage` (for a run
 * left `running`) and the delayed-start timer handler (for a `startAfter`/
 * `startAt` run that crashed `pending` before its timer fired). On a fresh
 * process the in-memory `workflowServices` map is empty, so without this a
 * recovered run that originally had services would silently execute with
 * `ctx.services === undefined`.
 *
 * The resolver is only consulted for runs launched WITH services, detected by
 * the durable `KEYS.workflowHasServices` marker. A run that never had services
 * has no marker and proceeds without touching the resolver — so a fail-closed
 * resolver does not fail healthy no-services runs.
 *
 * Returns `false` to proceed (services available or none expected). Returns
 * `true` to STOP — the run was terminally
 * failed (services unavailable), or the terminal commit faulted and the run was
 * left for a later boot to retry. Either way the generator must not advance:
 * driving it without services would crash the body and that throw would escape
 * into the recovery loop, aborting sibling runs.
 *
 * Worker mode skips this (services are inline-only, rejected at `engine.start()`).
 * A resolver throw is treated as `unavailable` with the error as the reason,
 * for the same sibling-isolation reason.
 *
 * @param failRun - Terminally fails just this run with `reason`. Supplied by the
 *   caller because the two entry points reach the termination machinery through
 *   different callback bundles. It receives the canonical terminal error built
 *   by {@link unavailableServicesError}, so both recovery paths fail the run
 *   with an identical message and (via `failWorkflow`'s default) the `system`
 *   failure category.
 * @param onCommitError - Records a fail-warn when `failRun` itself throws, so the
 *   swallowed terminal-commit fault is still observable.
 */
export declare function reprovideRecoveredServices(internals: EngineInternals, state: WorkflowState, failRun: (workflowId: string, error: Error) => Promise<void>, onCommitError: (source: string, error: unknown, workflowId: string) => void, dispatchDiagnostic?: (event: Event) => void, resolverInfo?: WorkflowServicesResolverInfo): Promise<boolean>;
/** Build the durable recovery context shared by the services resolver and recovery hook. */
export declare function workflowServicesResolverInfoFromState(internals: EngineInternals, state: WorkflowState): Promise<WorkflowServicesResolverInfo>;
/**
 * The canonical terminal error for any run whose services could not be provided —
 * both recovery re-provision paths and a scheduled-occurrence launch. Shared so
 * every caller fails with an identical message (the failure category is `system`,
 * the default for `failWorkflow`). The message is recovery-agnostic because a
 * freshly launched scheduled occurrence has never been recovered.
 */
export declare function unavailableServicesError(workflowId: string, reason: string): Error;