import type { OneSdkContext } from '../../sdk/types/oneSDK';
import type { JourneyScreenConfig, ScreenSequence } from './screenSequence';
import type { StepRunner } from '../journeyHandle';
import type { FirstPaintSignal } from '../steps/firstPaint';
import type { StepMachine } from '../steps/stepMachine';
export type EkycStepRunner = {
    run: StepRunner;
    /** a no-op here: eKYC has no vendor — see the implementation */
    /** leave the container clear for the terminal card — see the implementation */
    clearForTerminalScreen: () => void;
};
/**
 * eKYC's own step runner — no vendor, no CAPTURE step. The whole attempt is
 * PERSONAL → DOCUMENT → REVIEW, all human-gated form screens.
 *
 * REVIEW itself is where this flow genuinely diverges from idv/ocr: it does
 * NOT call `submitAndClassify` (`individual().submit({verify:true})`) itself.
 * ReviewDocument.tsx (the `type: 'manual'` REVIEW component) already has its
 * own built-in submit-and-classify — `verify: true` makes it call submit
 * itself, and `customResult: true` makes it emit
 * `form:review:{success|failed|pending|partial}` with the outcome, instead of
 * rendering its own `<Result>` UI. Calling submit a second time here would be
 * redundant at best. See `stepTable.ts`'s REVIEW_VERIFY row for exactly which
 * ReviewDocument.tsx branch produces which event.
 *
 * The data-correction retry (spec §6) uses the dedicated RETRY module
 * (`Retry.tsx`), not a second plain REVIEW mount — it reads the previous
 * submission's `retryPages` and routes the applicant straight to whichever
 * field needs correcting, landing back on `<ReviewDocument/>` to resubmit.
 */
export declare const mkEkycStepRunner: (deps: {
    oneSdk: OneSdkContext;
    config: JourneyScreenConfig;
    machine: StepMachine;
    firstPaint: FirstPaintSignal;
}) => EkycStepRunner;
export type { JourneyScreenConfig, ScreenSequence };
//# sourceMappingURL=ekycFlow.d.ts.map