/**
 * The wire format used between the injected `@lensmcp/client-runtime`
 * and the bridge's WebSocket. Now owned by `@lensmcp/bridge` (it became
 * build-agnostic when the bridge was decoupled from Vite); re-exported
 * here so existing `@lensmcp/vite-plugin` importers keep working.
 */
export type { ClientEnvelope } from '@lensmcp/bridge';
export interface LensmcpViteOptions {
    /** Whether the plugin should attach anything. Production: false. */
    enabled?: boolean;
    /** Override the WS port. By default an ephemeral port is selected. */
    wsPort?: number;
    /** Bind address for the WS. Localhost by default. */
    wsHost?: string;
    /**
     * Browser origins the WS admits beyond the defaults (issues/closed/codex-security-68). Rarely needed:
     * loopback origins are admitted, and so is every origin this dev server itself serves the runtime
     * to — the LensMCP gateway's hosts and LAN addresses included. Name the page's origin here only when
     * it loads the runtime cross-origin from a host that is neither (`https://app.test:8443`, `app.test`,
     * `.app.test` for subdomains, `*` for any). `LENSMCP_BRIDGE_ALLOWED_ORIGINS` adds to this list.
     *
     * Every connection must also carry the per-start token baked into the served runtime.
     */
    wsAllowedOrigins?: string[];
    /** Inject the client runtime via <script>. Default true. */
    injectClient?: boolean;
    /** Alias `valtio` → the instrumented drop-in in dev. Default true. */
    aliasValtio?: boolean;
    /** Run the LensMCP source transform (root-wrap + hooks + JSX ids). Default true. */
    transformSource?: boolean;
    /**
     * When Vite gives up opening its HMR socket at page load ("[vite] failed to connect to websocket"), the
     * page still works but never gets another hot update or reload notice — it silently runs the code it
     * loaded. The injected runtime always reports that (`hmr` `ws-failed`). With this on (the default) it
     * also RELOADS the page once, but only in a tab whose HMR socket worked earlier in its session (the
     * case a dev-server handoff leaves behind — issues/closed/foodguard-49), and at most once per two
     * minutes, so a setup where the socket never connects is reported, never looped. `false` = report only.
     */
    hmrRecovery?: boolean;
    /**
     * Session replay: the page records itself with rrweb (`/@lensmcp/replay`, injected after the runtime) and streams
     * the recording to the bridge (planning/replay/00-plan.md). On by default; `LENSMCP_REPLAY=0` in the dev server's
     * env wins over this, and without either, Settings › Features (`.lensmcp/capture.json`) decides.
     */
    replay?: boolean;
    /**
     * Also attach during `vite build`. Default **false** — everything this plugin does (the WS
     * bridge, the injected client runtime, `data-agent-source` on every element, source paths in
     * `originNodeId`) is a development tool, and `enabled` defaulting to `true` meant a plain
     * `lensmcpVitePlugin()` shipped all of it in a production bundle (issues/closed/codex-security-39).
     *
     * Set it, or `LENSMCP_VITE_APPLY_ON_BUILD=1`, when you deliberately want an instrumented build —
     * a staging deploy you intend to point the lens at.
     */
    applyOnBuild?: boolean;
}
export interface LensmcpViteRuntime {
    /**
     * The WS port the plugin is listening on. Available after Vite's
     * `configureServer` hook fires.
     */
    wsPort(): number | undefined;
}