import type { RunResult, WorkflowSource } from "../../engine/types.ts";
import type { WorkflowDefinition } from "../../flow/types.ts";
import type { ActiveRuns } from "../active-runs.ts";
import { type ProgressFor, type ProgressSink } from "../progress-sink.ts";
import type { RunStore } from "../types.ts";
import { type CommandCtx, type StartAgent } from "./context.ts";
/** A parsed `run` argument line (spec §6.1): the target, the optional `--result-out` path, and `--input`'s raw, unparsed payload. */
export interface ParsedRunArgs {
    readonly target: string | undefined;
    /** Everything after `--input`, verbatim: either inline JSON or `@<path>`. `undefined` when the flag was absent. */
    readonly inputArg: string | undefined;
    /** The `--result-out` path when the flag was present (result-artifact.ts), `undefined` otherwise. */
    readonly resultOut: string | undefined;
    /** Set only when a flag was typed with nothing after it, or duplicated — a syntax error, not a resolution failure. */
    readonly error: string | undefined;
}
/**
 * Parse `run <file-name|file.ts> [--input <json>|@<file>] [--result-out <path>]` (spec §6.1). One
 * grammar for both surfaces: the in-session `/workflow run` and the headless CLI's
 * `kimchi workflow run`.
 *
 * `--input`'s own payload is deliberately NOT tokenized the way the rest of `/workflow`'s arguments
 * are (`extension.ts` splits on `/\s+/` for every other subcommand): a JSON object routinely contains
 * spaces (`{"branch": "release notes"}`), and re-joining post-split tokens would already have
 * collapsed repeated whitespace the payload may have meant literally. So the caller hands this the RAW
 * text after `run` (whitespace-trimmed at the ends only), and everything from `--input` to the end of
 * the line is taken verbatim as the payload.
 *
 * `--result-out` is extracted FIRST, wherever it sits on the line, because its own value ends at the
 * next whitespace; the remainder keeps the target/`--input` grammar above intact. Keeping `--input`
 * last is still the sane habit: its payload runs to the end of the line, and a payload containing the
 * literal flag text would be disturbed by the extraction.
 */
export declare function parseRunArgs(raw: string): ParsedRunArgs;
/** What `--input` resolved to (spec §6.1), or why it could not — bad JSON, an unreadable file, or a
 * schema violation are every one of them reported the same way: a notification, and no run started. */
export type InitialInputResolution = {
    readonly ok: true;
    readonly value: unknown;
} | {
    readonly ok: false;
    readonly error: string;
};
/**
 * Turn `--input`'s raw argument into a validated initial input (spec §6.1).
 *
 * Validation reuses {@link describeSchemaViolations} — the SAME TypeBox check the engine itself runs
 * on a workflow's declared input schema (`engine/run-workflow.ts`) — rather than hand-rolling a second
 * one that could drift from it. Doing it here, before `startRun` mints a run-id, is what makes a
 * malformed payload cost nothing: no run-id is burned and no `run-meta`/`run-crashed` pair lands in
 * the store. Letting the engine's own (still-present, §orig.)
 * check catch it would technically be correct too, but only after paying for all three.
 */
export declare function resolveInitialInput(cwd: string, inputArg: string, workflow: Pick<WorkflowDefinition, "name" | "inputSchema">): Promise<InitialInputResolution>;
/**
 * `/workflow run <file-name|file.ts> [--input <json>|@<file>]` — start a workflow by its installed
 * filename identity or an explicit path, optionally seeded with initial input (spec §6.1).
 *
 * With no `inputArg`, a workflow that declares no top-level schema keeps its pre-`--input` behaviour
 * (`undefined` initial input). One that DOES declare a schema treats the omitted flag as `--input {}`:
 * `undefined` can never satisfy a declared schema, so passing it through would only reach the engine's
 * post-mint input crash — a failure the progress card cannot even render (no `run-started` event
 * precedes it). Routing the empty payload through the same gate keeps the failure surface identical
 * to a typed payload: all-optional schemas start cleanly, required fields are a notification and no
 * run id is ever minted.
 */
/** A target that survived preparation, resolution, and input validation — everything the in-session `startRun` and the batch host need to enter the engine. */
export interface ResolvedRunInvocation {
    readonly workflow: WorkflowDefinition;
    readonly workflowSource: WorkflowSource;
    readonly initialInput: unknown;
}
/**
 * The shared front half of `/workflow run` and the batch CLI's `run`: prepare the project workflow
 * package, resolve the target through the catalog, and validate the initial input — including the
 * omitted-`--input`-means-`{}` rule for schema-declaring workflows (spec §6.1). Returns `undefined`
 * after notifying the failure, so the caller's only decision is what its own surface charges for it
 * (nothing for `/workflow run`, exit code 4 for the batch CLI).
 */
export declare function resolveRunInvocation(ctx: Pick<CommandCtx, "cwd" | "ui">, target: string, inputArg?: string): Promise<ResolvedRunInvocation | undefined>;
export declare function handleRun(ctx: CommandCtx, store: RunStore, activeRuns: ActiveRuns, startAgent: StartAgent, target: string, inputArg?: string, progressFor?: ProgressFor, resultOut?: string): Promise<void>;
/**
 * `/workflow create` — run the built-in meta-workflow (src/host/builtin/create.workflow.ts) through
 * exactly the same machinery as any other run. It differs only in receiving the project root as its
 * initial input, which its steps use to resolve where the generated file should land.
 */
export declare function handleCreate(ctx: CommandCtx, store: RunStore, activeRuns: ActiveRuns, startAgent: StartAgent, progressFor?: ProgressFor): Promise<void>;
/** The outcome of one engine pass, with the sink still attached (spec §7, §8.9). The CALLER owns `progress` disposal. */
export interface ExecutedRun {
    readonly runId: string;
    readonly progress: ProgressSink;
    readonly result: RunResult;
}
/** Optional observation points for callers that must react while the run is still in flight. */
export interface ExecuteRunHooks {
    /** Called as soon as the run-id is minted — before the first event — so a signal handler can target it. */
    onRunId?: (runId: string) => void;
}
/**
 * The shared run lifecycle for `/workflow run`, `/workflow create`, and the headless CLI's batch
 * `kimchi workflow run` (spec §7, §8.9): mint the id, record provenance, drive the engine once under
 * the tracked-execution lease. Everything AFTER the engine returns — the attended Q&A loop, exit
 * codes, result artifacts — is each surface's own; that is why the sink is handed back undisposed.
 */
export declare function executeRun(store: RunStore, activeRuns: ActiveRuns, startAgent: StartAgent, workflow: WorkflowDefinition, workflowSource: WorkflowSource, initialInput: unknown, progressFor: ProgressFor, hooks?: ExecuteRunHooks): Promise<ExecutedRun>;
//# sourceMappingURL=run.d.ts.map