/**
 * One verify at a time, machine-wide.
 *
 * `bitmagic verify` reads the game's frame rate off a real browser (browser.ts `measureFps`), and
 * a creator making several games at once runs several verifies at once — each in its own folder,
 * often started by an agent that has no idea about the others. Two headless Chromes settling on
 * one laptop starve each other, and the verdict is then about the machine, not the game: "58 fps"
 * becomes "23 fps" with nothing in the project to explain it.
 *
 * So every browser run takes the `verify` machine lock (machine-lock.ts) and the rest wait,
 * visibly — the waiting line names who holds it, because an agent watching a verify that prints
 * nothing for a minute concludes it hung. The hold is the browser run only, not the build in
 * front of it; builds are short and a dev's `tsc --watch` runs unlocked beside every verify anyway.
 *
 * `BITMAGIC_NO_VERIFY_LOCK` opts out, for a CI matrix that parallelises on purpose and does not
 * grade fps. It mirrors `BITMAGIC_NO_OPEN`: an env var rather than a flag, because the machine is
 * what decides, not the run.
 */
import { acquireMachineLock, type MachineLockDeps } from '../machine-lock.js';
import type { Output } from '../output.js';
export declare const NO_VERIFY_LOCK_ENV = "BITMAGIC_NO_VERIFY_LOCK";
export interface VerifyLockDeps {
    env?: Record<string, string | undefined>;
    acquire?: typeof acquireMachineLock;
    lock?: MachineLockDeps;
}
/**
 * Run `fn` as the only browser-driving verify on this machine.
 *
 * `command` is what a WAITER will be told is running — `verify`, `verify --watch`, `publish`.
 */
export declare function withVerifyLock<T>(root: string, command: string, output: Pick<Output, 'info'>, fn: () => Promise<T>, deps?: VerifyLockDeps): Promise<T>;