/**
 * Pre-wire validator for inline `InlineGraphSpec` payloads — walks the
 * dict-keyed QAR-native shape.
 *
 * Runs synchronously inside `client.tasks.startWithGraph(...)` so a malformed
 * graph is rejected before it crosses the WebSocket. The check set mirrors
 * the SDK-enforceable subset of QAR's wire rules — anything requiring
 * server-side state (model registry, tenant catalog, AgentSpec
 * composition against the live agent table, transitive budget caps) is left
 * to QAR's `task.start` validator or the opt-in
 * `client.specs.validate(...)` pre-flight.
 *
 * Output: a `QodoInlineGraphValidationError` carrying every failure observed,
 * with the same `{ rule_id, path, message }` shape as `SpecValidationError`
 * so consumers can route SDK-side and server-side rejections through the same
 * branch logic.
 */
import type { InlineGraphEdge, InlineGraphSpec } from '../qar/specs.js';
/**
 * Default cap for graph depth (longest acyclic path from entry).
 *
 * Matches QAR's `MAX_GRAPH_DEPTH` operator default (4). Operators running a
 * higher-limit deployment can raise this per-call via the
 * `maxDepth` option; the pre-flight `client.specs.validate(...)` is
 * the path for non-default deployment caps.
 */
export declare const DEFAULT_INLINE_GRAPH_MAX_DEPTH = 4;
/** Options accepted by `validateInlineGraphSpec`. */
export interface InlineGraphValidationOptions {
    /** Override the depth cap. Default `DEFAULT_INLINE_GRAPH_MAX_DEPTH`. */
    readonly maxDepth?: number;
}
/**
 * Validate `graph` against the SDK-side rule subset. Throws
 * `QodoInlineGraphValidationError` when any rule fails — every failure is
 * carried on `.failures`, in stable depth-first order. Returns void on
 * success.
 *
 * Stable order matters: consumers gating CI on a sorted failure dump don't
 * want spurious diffs from set / map iteration nondeterminism. Object key
 * iteration in JS follows insertion order for non-integer string keys, so
 * agent traversal mirrors the consumer's source-text order.
 */
export declare function validateInlineGraphSpec(graph: InlineGraphSpec, opts?: InlineGraphValidationOptions): void;
/**
 * Compute the longest acyclic path length (edge count) starting at `entry`.
 *
 * Exported so `TaskClient` can reuse the same impl for the `qar.graph.depth`
 * OTel span attr — keeping one implementation prevents the two copies from
 * drifting on cycle-handling semantics.
 *
 * Iterative postorder DFS with a visited stack — addresses two failure modes:
 *
 *   1. Cycles through undeclared endpoints. `findCycle` only walks
 *      declared-node cycles, so an edge to/from an undeclared node could
 *      shape a cycle that slipped past R6/R7. The `onStack` set short-
 *      circuits any back-edge before it re-enters an in-flight node — the
 *      back-edge contributes `0` so the longest-path search still
 *      terminates.
 *   2. Stack overflow on deeply nested chains. Recursive DFS blows the
 *      JS stack when an operator raises `maxDepth` and supplies a deep
 *      graph. Iterative postorder (enter / exit phases on an explicit
 *      stack) keeps the heap bounded by graph size instead of call depth.
 */
export declare function longestPathFrom(entry: string, edges: readonly InlineGraphEdge[]): number;
//# sourceMappingURL=inlineGraph.d.ts.map