/**
 * Dockerfile synchronization to config directory
 *
 * Copies the bundled Dockerfile and every asset it COPYs at image build time
 * to ~/.ai-support-agent/, so `docker build` (which uses the config dir as
 * its context once a synced Dockerfile exists there — see
 * resolveDockerfile()) can find every COPY source.
 *
 * Assets fall into two groups, handled differently:
 *   - The legacy pair (Dockerfile + entrypoint.sh): hash-protected, so a
 *     user's customisation survives future syncs (see
 *     syncDockerfileToConfigDir()'s own doc comment for the state machine).
 *   - New assets (tmux.conf, bashrc-extra.sh, nvim/init.lua, ...): kept in
 *     sync with the bundle on every run (copied whenever the config-dir
 *     copy is missing OR its content differs from the bundled version), with
 *     no customisation protection — they can't be "customised" the first
 *     time they ever reach a user's config dir, and folding them into the
 *     legacy hash breaks that hash's meaning (see NEW_OPTIONAL_ASSETS' doc
 *     comment). Comparing content (not just existence) is required: a user
 *     who already synced an older version of one of these files must still
 *     receive later bundle updates on their next sync, or the fix in that
 *     later bundle version never reaches them no matter how many times they
 *     upgrade the CLI (see the REGRESSION test in dockerfile-sync.spec.ts).
 */
/**
 * Docker build assets, beyond the Dockerfile itself, that the Dockerfile
 * COPYs from the build context. Each is optional in the bundle (older
 * published versions of this package may not have them yet), but any of
 * these present in the bundle must be synced or the next `docker build`
 * against the config-dir context breaks on a missing COPY source.
 *
 * Only LEGACY_OPTIONAL_ASSET is included in the customisation-protecting
 * hash (see NEW_OPTIONAL_ASSETS below for why the rest are deliberately
 * excluded).
 */
export declare const OPTIONAL_DOCKER_ASSETS: string[];
/**
 * Copy the bundled Dockerfile + entrypoint.sh pair to the config directory.
 * The pair is treated as one sync unit: a combined hash over both files is
 * stored in .dockerfile-sync-hash to detect user customisations:
 *   - No hash file or any destination file missing → overwrite the pair
 *     unconditionally and record the bundled combined hash
 *   - Hash matches current config pair → update if the bundled pair differs
 *   - Hash mismatch → user has customised either file, warn and skip
 * entrypoint.sh may be absent from the bundle, in which case the Dockerfile
 * alone forms the sync unit.
 */
export declare function syncDockerfileToConfigDir(): void;
/**
 * True when `configDir/Dockerfile` exists but was never produced by
 * syncDockerfileToConfigDir() (no `.dockerfile-sync-hash` alongside it) — i.e.
 * a file the user placed there by hand.
 *
 * syncDockerfileToConfigDir() treats a missing hash file as "first run" and
 * overwrites the pair unconditionally, which is fine on the `start` path (it
 * has always done that) but would silently destroy a hand-placed Dockerfile
 * the first time a caller that never synced before starts syncing. Callers use
 * this to skip the sync entirely; isDockerfileCustomized() then reports the
 * file as customised, so the image is built from it rather than pulled.
 */
export declare function hasUnmanagedConfigDockerfile(): boolean;
/**
 * True when the image a local `docker build` would produce differs from the one
 * the release workflow published to the registry — i.e. pulling it is not
 * equivalent, because the user customised something in the build context.
 *
 * Covers the Dockerfile and every asset it COPYs (OPTIONAL_DOCKER_ASSETS:
 * entrypoint.sh, tmux.conf, bashrc-extra.sh, nvim/init.lua, starship.toml), not
 * just the Dockerfile: with `dockerfileSync: false` the sync that normally
 * keeps those assets identical to the bundle never runs, so a customised
 * tmux.conf survives and a pulled image would silently ignore it.
 *
 * An asset counts as customised only when its config-dir copy EXISTS and
 * differs. A missing copy is not a customisation — there is no user content to
 * preserve, and a local build would fail on the missing COPY source anyway, so
 * treating it as customised would trade a working pull for a broken build.
 *
 * Compares bytes against the CURRENT bundle rather than consulting
 * .dockerfile-sync-hash: with `--no-dockerfile-sync` (or after a failed sync)
 * the stored hash can still match a config-dir copy taken from an older CLI
 * version, and "stale" must not be mistaken for "identical to what CI built".
 * Anything unreadable counts as customised, so the fallback is always the safe
 * one — build locally rather than silently ignore a user's edits.
 *
 * This covers the config-dir copies only. An explicitly passed Dockerfile
 * (`--dockerfile` / config.dockerfilePath) is customised by definition and is
 * checked by the caller.
 */
export declare function isDockerfileCustomized(): boolean;
//# sourceMappingURL=dockerfile-sync.d.ts.map