import type { StepDefinition, WorkflowDefinition, WorkflowNode } from "../flow/types.ts";
import { type ExecOutcome, type PendingBlock, type Reentry, type RunState } from "./context.ts";
import { type NodePath } from "./node-path.ts";
import type { HostPort, RunResult } from "./types.ts";
export type { AnswerResume, Reentry } from "./context.ts";
/**
 * Where execution begins plus the state recovered before it. A fresh run starts at the top with empty
 * `stepOutputs` and `previousOutput === initialInput`; a resume seeds these from the log (see
 * `resume-workflow.ts`). `startIndex` is a *top-level node* index (spec §8.2/§8.3's node-atomic
 * restart); `reentry`, when present, takes priority and navigates to an exact blocked position
 * (spec §8.4/§8.5) instead.
 */
export interface ExecutionCursor {
    readonly runId: string;
    readonly initialInput: unknown;
    readonly stepOutputs: Map<string, unknown>;
    readonly previousOutput: unknown;
    readonly startIndex: number;
    readonly foreachItemHistory?: ReadonlyMap<string, ReadonlyMap<number, unknown>>;
    readonly reentry?: Reentry;
    /**
     * Resume-only (spec §8.6): every step currently `blocked` elsewhere in the log at the moment this
     * resume began, keyed by static key. Lets a concurrent construct's re-entry recognize a sibling of
     * the re-entry target that is ALSO still pending — left untouched rather than restarted or dropped.
     */
    readonly pendingBlocks?: ReadonlyMap<string, PendingBlock>;
}
/**
 * Top-level driver: walk `workflow.nodes` from `cursor.startIndex` (or `cursor.reentry`), then emit
 * the terminal event. The caller has already emitted the opening event (`run-started` / `run-resumed`).
 */
export declare function execute(workflow: WorkflowDefinition, host: HostPort, cursor: ExecutionCursor, signal?: AbortSignal): Promise<RunResult>;
/**
 * Walk a node sequence with linear hand-off (spec §3.6): each node's output feeds the next. Used at
 * the top level (with `startIndex`/`reentry` from resume) and recursively for branch arms /
 * loop-iteration / foreach-item / parallel-arm / nested-workflow bodies (always `startIndex` 0,
 * `reentry` popped one segment per level by the caller). A node's output is recorded under its own
 * STATIC path (spec §5.4) for `ctx.getStepResult`. Exported for concurrent-nodes.ts, which recurses
 * back into this for each arm's/item's own body.
 */
export declare function runNodeSequence(nodes: readonly WorkflowNode[], host: HostPort, state: RunState, previousOutput: unknown, signal: AbortSignal, parentPath: NodePath, startIndex?: number, reentry?: Reentry): Promise<ExecOutcome>;
/** The name a re-entry's next hop must match: its own leading segment's name. Exported for concurrent-nodes.ts. */
export declare function leafNameOf(reentry: Reentry): string;
/**
 * Run one step to a settled outcome, holding a run-wide concurrency slot and tracking it in-flight for
 * the full duration (spec §3.6/§3.9). Exported for concurrent-nodes.ts (parallel arms).
 *
 * The gate is held HERE, by the step, rather than by the enclosing construct: spec §3.6 bounds "steps
 * executing at once", and a step is a leaf — it never waits on another step — so a slot can never be
 * held by something waiting for a slot. A construct holding the slot instead would deadlock as soon as
 * constructs nest (a `.foreach` at the ceiling occupying every slot while its items wait for slots of
 * their own). A blocked step (spec §8.6) settles and releases like any other: nothing holds a slot
 * while waiting on a human.
 */
export declare function runStepNode(step: StepDefinition, input: unknown, host: HostPort, state: RunState, signal: AbortSignal, parentPath: NodePath, reentry?: Reentry): Promise<ExecOutcome>;
//# sourceMappingURL=execute.d.ts.map