import { type RapierFlavor } from '@bitmagic/world-forger/physics-mode.js';
/**
 * The configs the scaffold vendors alongside `engine/`, one per bundle mode.
 *
 * The default leaves three.js, Rapier and the rest of the import map's packages to the CDN, which
 * is what every production publish from the Creator does. The standalone one inlines them, for a
 * game that has to run with no network at all.
 */
export declare const VITE_PUBLISH_CONFIG = "vite.publish.config.js";
export declare const VITE_PUBLISH_STANDALONE_CONFIG = "vite.publish-standalone.config.js";
/** The vendored config a build of this mode loads. */
export declare function publishConfigFor(singleFile: boolean): string;
/**
 * The single Rapier flavor this project's bundle ships — the game's EFFECTIVE
 * physics mode (src/work/game.json genre + physicsMode + physics2d, clamped
 * exactly the way the engine clamps at boot), not the raw declared value.
 *
 * A build ships exactly one physics engine, never both: a game.json that
 * cannot be read fails the build here, before `tsc` runs, rather than guessing
 * which engine to drop. (The vendored config applies the same rule itself when
 * the variable is unset, so a hand-run `vite build` is single-flavor too.)
 */
export declare function resolveRapierFlavor(root: string): RapierFlavor;
/**
 * What was built, and from what.
 *
 * `fingerprint` is the same value `verify` records, which is what lets `publish` reuse an
 * existing bundle instead of rebuilding: same inputs, same bundle.
 */
export interface BuildManifest {
    engineVersion: string;
    fingerprint: string;
    /**
     * Whether this bundle inlines the CDN packages (`--single-file`) or leaves them external.
     *
     * Recorded because nothing else can tell the two apart. The mode changes no file on disk, so it
     * does not move the fingerprint — and `publish` reuses a build on the fingerprint alone. Without
     * this field, `bitmagic publish --single-file` straight after a default build would happily ship
     * the external one, and the reverse.
     */
    singleFile: boolean;
    bytes: number;
    /** Recorded for the publish audit trail. The server stores it; it cannot verify it. */
    sha256: string;
    builtAt: string;
}
export declare function buildBundlePaths(root: string): {
    dir: string;
    htmlPath: string;
    manifestPath: string;
};
export declare function writeBuildManifest(root: string, manifest: BuildManifest): void;
/** The last build's manifest, or null if there is none to trust — same contract as readVerifyRecord. */
export declare function readBuildManifest(root: string): BuildManifest | null;
/**
 * Compile and bundle the project into one HTML file, and record what was built.
 *
 * One file either way — `bitmagic publish` PUTs a single object and api-server range-reads that
 * same object to confirm the meta block, so there is nowhere for a second file to go. What the
 * mode changes is what is INSIDE it: by default the engine, the game and its data are inlined
 * while three.js, Rapier and the other CDN packages are fetched at runtime, matching what the
 * Creator publishes; `singleFile` inlines those too, for a game that must run with no network.
 *
 * Exit code 1 on failure, matching the table in the spec: a build failure is the creator's own
 * code, and the compiler's output has already been printed.
 *
 * The pre-flight below runs BEFORE `tsc`, not after: a project scaffolded before the config it
 * needs existed has none for vite to load, and without this check the creator pays a full
 * type-check and then reads a raw vite "config not found" that names no remedy. `bitmagic upgrade`
 * is the remedy — it vendors the file without touching game code — so the error says so. It names
 * the config for the mode actually asked for, since a project can easily have one and not the
 * other: the standalone config was added later than the default one.
 */
export declare function runBuild(root: string, engineVersion: string, options?: {
    singleFile?: boolean;
}): BuildManifest;