import type { DagStepProgress } from "@agg-build/hooks";
import type { TradingVenue } from "../types";
import type { PlaceOrderSubmissionProgressPhase, PlaceOrderTradingLabels } from "./index.place-order.types";
/**
 * Stable, user-facing phases for the in-flight Place Order submission UI.
 *
 * The DAG executor emits many granular step types (`bridge-fetch-quote`,
 * `polymarket-setup-resolve-need`, `submit-verify-order-status`, etc.) that
 * are an implementation detail of how a route is fulfilled. Surfacing them
 * directly produces noisy, confusing progress and leaks internal architecture
 * to partners. We collapse every raw step into one of a small, fixed set of
 * normalized phases here, then drive rendering off the normalized model.
 *
 * Anything not in this list (bridge, ata, approve, swap, transfer, position,
 * polymarket-setup, hl-fund, wait sentinels) maps to either `checking-balance`
 * (read-only probes) or `submitting`.
 */
export type NormalizedExecutionPhaseKind = "finding-route" | "checking-balance" | "submitting" | "wallet-confirm" | "executing-venue" | "filled" | "failed";
export type NormalizedExecutionPhase = {
    kind: NormalizedExecutionPhaseKind;
    /** Set when the phase is venue-scoped — `executing-venue` and finalize legs. */
    venue?: TradingVenue;
};
export type SubmissionDisplayRow = {
    id: string;
    label: string;
    status: "pending" | "complete";
    venue?: TradingVenue;
};
/**
 * Classify a raw DAG step type into the normalized phase it represents.
 *
 * Returns `null` for wait sentinels and unrecognized step types — the caller
 * should skip these so they don't introduce a fake "Wait" or `Step N of M`
 * row in the UI.
 */
export declare const classifyExecutionStepType: (stepType: string) => NormalizedExecutionPhase | null;
type PhaseTimelineEntry = NormalizedExecutionPhase & {
    firstSeq: number;
    lastSeq: number;
    allCompleted: boolean;
};
/**
 * Walk the DAG sequences in order, classify each, and merge consecutive
 * entries that share the same kind+venue. The result is the
 * presentation-layer timeline of high-level phases.
 *
 * A merged entry is `allCompleted` only when every underlying sequence has
 * finished — so a single in-flight `bridge-submit` keeps the merged
 * "submitting" row pending even if `bridge-fetch-quote` already completed.
 *
 * Post-pass: the DAG only emits `step_completed` for a subset of sequences
 * (record-state steps, position-reserve, etc.) — sub-steps like
 * `polymarket-deposit-wallet-submit` and `wait` never report completion
 * individually. That means a merged "submitting" block can stay
 * `allCompleted=false` forever even after the executor has moved on to a
 * later block. To preserve the "only the last visible row is pending"
 * invariant, force-complete any block that has any later block with at
 * least one completed sequence.
 */
export declare const buildPhaseTimeline: (dag: DagStepProgress) => PhaseTimelineEntry[];
export type BuildSubmissionDisplayRowsArgs = {
    phase: PlaceOrderSubmissionProgressPhase;
    dagProgress: DagStepProgress | null | undefined;
    executionVenue?: TradingVenue;
    /** Whether the active submitting beat is waiting on a wallet signature. */
    isAwaitingWalletConfirmation?: boolean;
    labels: PlaceOrderTradingLabels;
};
/**
 * Produce the rows the in-flight Place Order surface should render.
 *
 * Invariants:
 *   - At most one row has status `pending`.
 *   - Completed rows are kept only when they correspond to a meaningful
 *     user-facing milestone (the normalized phases above).
 *   - The same kind+venue never appears twice — repeated `step_started` /
 *     `step_waiting` events on the same phase don't duplicate rows.
 */
export declare const buildSubmissionDisplayRows: ({ phase, dagProgress, executionVenue, isAwaitingWalletConfirmation, labels, }: BuildSubmissionDisplayRowsArgs) => SubmissionDisplayRow[];
export {};
