/**
 * The "what do I land on" queue for one reel.
 *
 * When a reel enters its stop phase, the `SpinController` loads the
 * target frame (the exact list of symbol ids that should appear on
 * screen, top-to-bottom, including the off-screen buffers). As the reel
 * keeps scrolling downward during deceleration, every `ReelMotion` wrap
 * event asks this sequencer for the next symbol. and it hands them back
 * from the END of the frame first, because new symbols arrive at the
 * top of a reel scrolling downward.
 *
 * After the last symbol is consumed the reel lands, and what you see on
 * screen matches the loaded frame exactly.
 */
export declare class StopSequencer {
    private _frame;
    private _remaining;
    private _cursor;
    private _step;
    /**
     * Load a target frame in start-to-end order (top-to-bottom for a vertical
     * reel). `feedEdge` is the strip edge new symbols enter from during the stop:
     * `'start'` for a forward reel (symbols arrive at the start edge and are
     * pushed toward the end, so the frame is consumed end-first) and `'end'` for
     * a reverse reel (symbols arrive at the end edge, so the frame is consumed
     * head-first). Getting this backwards lands a correct-looking frame reversed.
     */
    setFrame(frame: string[], feedEdge?: 'start' | 'end'): void;
    /**
     * Deliver the next symbol, consumed from the feed-appropriate end.
     *
     * Throws when the frame is exhausted. Every caller is expected to gate on
     * {@link hasRemaining} first (the library's only one, `Reel._replaceSymbol`,
     * does). The old behaviour returned `_frame[0]`, or `''` after a `reset()` —
     * a symbol id that resolves to nothing, so an over-consuming caller landed a
     * silently wrong frame instead of failing where the bug was.
     */
    next(): string;
    get hasRemaining(): boolean;
    get remaining(): number;
    /** Drop the loaded frame and return to the just-constructed state. */
    reset(): void;
}
//# sourceMappingURL=StopSequencer.d.ts.map