import type { BrowserActions } from "./actions.js";
import type { LlmClient } from "../llm/types.js";
import type { ExecutionLogger } from "../logging/logger.js";
import type { StoreManager } from "../agent/store.js";
export interface SkillStep {
    action: string;
    params: Record<string, unknown>;
    description?: string;
}
export interface SkillScript {
    name: string;
    description: string;
    steps: SkillStep[];
    notes?: string[];
}
/** Result of executing a single step */
export interface StepResult {
    index: number;
    action: string;
    success: boolean;
    usedFallback: boolean;
    /** What the LLM actually did when falling back */
    fallbackAction?: string;
    error?: string;
}
/** Structured report of a full skill execution */
export interface ExecutionReport {
    skillName: string;
    totalSteps: number;
    successCount: number;
    fallbackCount: number;
    failedCount: number;
    steps: StepResult[];
    /** Overall success — all steps completed (with or without fallback) */
    completed: boolean;
}
/**
 * Runs a skill script step-by-step.
 * Each step tries direct execution first; on failure, falls back to LLM.
 */
export declare class ScriptRunner {
    private fallbackInstructions;
    /**
     * Optional store handle. When present, the fallback LLM gets the
     * `storeTool` exposed so it can read and record structured cross-run
     * state while recovering a failed step. Tasks
     * that don't go through TaskRunner (e.g. legacy callers) can leave it
     * undefined; fallback then runs browser-only as before.
     *
     * Note: this only helps the *fallback* path. The deterministic script
     * step loop (executeStepInner) still routes everything through the
     * browser dispatch — adding native `store.*` step types is a separate
     * change that needs skill-generator support and isn't required until
     * skill auto-generation is re-enabled (currently TODO'd in task-runner).
     */
    private store?;
    private actions;
    private llmClient;
    private logger;
    constructor(actions: BrowserActions, llmClient: LlmClient, logger: ExecutionLogger, fallbackInstructions?: string, 
    /**
     * Optional store handle. When present, the fallback LLM gets the
     * `storeTool` exposed so it can read and record structured cross-run
     * state while recovering a failed step. Tasks
     * that don't go through TaskRunner (e.g. legacy callers) can leave it
     * undefined; fallback then runs browser-only as before.
     *
     * Note: this only helps the *fallback* path. The deterministic script
     * step loop (executeStepInner) still routes everything through the
     * browser dispatch — adding native `store.*` step types is a separate
     * change that needs skill-generator support and isn't required until
     * skill auto-generation is re-enabled (currently TODO'd in task-runner).
     */
    store?: StoreManager | undefined);
    run(script: SkillScript, variables?: Record<string, string>): Promise<ExecutionReport>;
    /**
     * Detect BrowserActions failure strings via the centralized predicate
     * shared with dispatch.ts so prefix changes never drift between modules.
     * Used only for the CSS-selector replay path that calls BrowserActions
     * methods directly (no dispatch, so no `expect` block can run, so the
     * leading-prefix predicate is sufficient there).
     */
    private isFailureResult;
    /**
     * Execute a step and throw on failure.
     *
     * Failure detection runs against the structured `BrowserActionResult.ok`
     * so post-action `expect` mismatches (which appear as
     * "[verification failed]" mid-string, NOT as a leading "Error:" prefix)
     * are surfaced. Otherwise a click that succeeded at the Playwright level
     * but failed its expectation would be miscounted as success and pollute
     * skill stats.
     */
    private executeStep;
    /**
     * Inner dispatch. Routes through `dispatchBrowserActionDetailed` for
     * everything except the skill-only `sleep` action, so:
     *   - CSS-shaped refs persisted in `ref` are auto-routed to the
     *     selector slot by dispatch's splitRefOrSelector.
     *   - `expect` blocks attached to step params are honored via
     *     dispatchActKind's verification step (covers both modern
     *     {action:"act", kind:"click"} and legacy {action:"click"} shapes).
     *
     * Earlier versions of this file kept hand-written CSS-replay wrappers
     * (clickBySelector et al.) that called BrowserActions directly. That
     * path bypassed the `expect` machinery, so old skills with mid-step
     * verification were silently unverified. Removed in favor of the
     * unified dispatch path.
     */
    private executeStepInner;
    /**
     * LLM fallback: ask LLM to accomplish the step goal, then actually execute
     * the tool calls it returns.
     */
    private llmFallback;
    private resolveVariables;
}
