/**
 * Launch a workflow run from an already-built `WorkflowState`/`Checkpoint`
 * pair — the shared tail `fork()` (`transition.ts`) drives after planting a
 * new run's durable records. Split out of `transition.ts`, which has no
 * headroom under the repository's 500-line implementation-file ceiling for
 * this logic inline.
 *
 * @module core/engine/lifecycle/checkpoint-launch
 */
import type { Checkpoint, WorkflowState } from '../../types.ts';
import { type WorkflowHandle } from '../handles.ts';
import type { EngineInternals } from '../internals.ts';
import { type LifecycleCallbacks, type RegistrationEntry } from './shared.ts';
export declare function launchWorkflowFromCheckpoint(internals: EngineInternals, workflowId: string, state: WorkflowState, checkpoint: Checkpoint, registration: RegistrationEntry, 
/**
 * The EXACT revision `registration` was resolved against — from the same
 * `resolveExecutableRegistrationForRevision()` call that produced
 * `registration`, threaded through explicitly rather than re-read off
 * `state.revision` (WFT-19 review round 5, Codex, mirroring the identical
 * fix in `lifecycle/resume.ts`). `fork()`'s own `forkState.revision` is
 * now stamped with this same resolved value too (WFT-19 review round 6,
 * Codex — `createForkedWorkflowState()`'s matching fix, so a legacy
 * fork's durable pin agrees with this in-memory one), so `state.revision`
 * and `resolvedRevision` coincide for every current caller; kept as an
 * explicit parameter regardless, since this function's identity-cache
 * write must never depend on that invariant holding at a future call
 * site.
 */
resolvedRevision: string | undefined, callbacks: LifecycleCallbacks): WorkflowHandle;