import type { Api } from "@cargo-ai/api";
import type { State } from "../compile.js";
import type { StateBackend } from "./types.js";
/**
 * What the calling command is allowed to do to a project that is not yet bound
 * to a state.
 *
 * - `read` — plan / check / refresh. An unbound project simply has nothing
 *   deployed, and the diff is all-creates.
 * - `write` — deploy / destroy / import / pull / rollback. Works against
 *   whatever the file names, a pre-remote resource map included, and stops
 *   when the project has no state at all rather than inventing one.
 *
 * Neither creates. `cdk init` and `cdk state create` are the two commands that
 * do, and they call `createCloudState` directly.
 */
export type StateBackendMode = "read" | "write";
export type StateResolution = {
    backend: StateBackend;
    /** `local` is a project still holding its own map — one to nudge. */
    kind: "local" | "cloud";
};
export type ResolveStateBackendInput = {
    root: string;
    mode: StateBackendMode;
    getApi: () => Api;
};
export declare function resolveStateBackend(input: ResolveStateBackendInput): Promise<StateResolution>;
/**
 * Create this project's state and point the repo at it: the uuid goes straight
 * into cargo.state.json, so the pointer travels with the repo from the first
 * commit and every later run resolves the same state.
 *
 * The GitHub fields are display metadata for `cdk state list`, read from the
 * checkout when there is one and left unset otherwise. They are never a lookup
 * key — the uuid in git is the only identity a state has. Reusing a state
 * because its repo matches would hand the second CDK project in a monorepo the
 * first one's resource map, and a `deploy --prune` there would then delete
 * every resource of the first that the second does not declare.
 */
export declare function createCloudState(input: {
    root: string;
    api: Api;
    contents?: State;
}): Promise<string>;
//# sourceMappingURL=resolve.d.ts.map