/**
 * Reading the engine's HUD-theme verdict out of the console verify already captures.
 *
 * A bad `hud.theme` in world.json is one of the quietest failures a project can carry. The engine
 * never throws over it — `resolveWorldTheme` deliberately treats a broken theme as recoverable and
 * a blocked game load as not — so it logs one warning and renders the DEFAULT look. The game runs,
 * the screenshot is fine, verify passes, and the only symptom is that the theme the author asked
 * for never appeared. That reads as "theming is broken" rather than "the name was misspelled", and
 * it survives for as long as nobody diffs the intended look against the shipped one.
 *
 * The hosted agent is protected from this by `write-hud-theme`, which validates before it writes
 * and answers with a closest-match suggestion. `bitmagic theme set|patch` now gives the CLI lane the
 * same write-time guard over a gate-enforced mirror of that validator — but only for edits made
 * THROUGH it. A hand edit to world.json, a vendored engine older than the CLI's copy, or a theme
 * that validates yet still fails in the browser all land here, which is why this check stays: it is
 * the only one that reads what the engine itself said.
 *
 * WHY PARSE THE CONSOLE rather than validate statically here. The obvious alternative is to read
 * world.json and check it against the engine's own validator, and it is not available: the vendored
 * engine emits with its path-mapped specifiers intact (`from 'engine/hud/ThemeTokens.js'`), which
 * resolve only through the browser import map, so `validateAndResolveTheme` cannot be imported from
 * Node. The remaining static option is a hand-mirrored preset list in the CLI, i.e. a third copy of
 * the same list to keep in sync. Parsing what the engine already said costs no mirror, cannot drift,
 * and inherits the engine's own error text — including the field paths from an invalid inline theme
 * and the live list of known presets, neither of which a mirror would have.
 *
 * The cost is honest and worth naming: this only sees a theme on a game that actually booted. A
 * project whose game fails to load has bigger findings in the same run.
 */
/** The engine's marker on every theme-resolution warning. Also what a reader greps for. */
export declare const HUD_THEME_MARKER = "[HUD]";
export interface HudThemeProblem {
    /**
     * `preset` — the name matched nothing, so the game silently rendered the default.
     * `custom` — an inline theme was structurally invalid and was dropped whole.
     */
    kind: 'preset' | 'custom';
    /**
     * The engine's own sentence, minus the marker. Carries the detail a re-implementation here
     * would have had to invent: the offending name and the live preset list, or the failing field
     * paths.
     */
    detail: string;
}
/**
 * The theme problem the engine reported during this run, or null when it reported none.
 *
 * Null is "not observed" and never a failure. Three legitimate ways to get it: the theme resolved
 * cleanly, the project sets no theme at all, or the engine predates the warning.
 *
 * The LAST matching line wins, for the same reason it does in the mobile-parity reader: a run that
 * starts gameplay more than once logs the check once per start, and the newest verdict describes
 * the game as it ended up.
 */
export declare function parseHudThemeProblem(consoleLines: string[]): HudThemeProblem | null;