/**
 * @fileoverview Configuration scope policy — determines where config writes go.
 *
 * Why a dedicated module: config writes can target either the global config
 * (`~/.lovrabet.json`) or the project config (`.lovrabet.json`). The rules for
 * choosing the correct scope are subtle:
 * - `--global` → always global (explicit user intent)
 * - `--project` → project if inside a project, else error
 * - No flag → depends on the command's implicit policy
 *
 * Rather than duplicating these rules in `auth` and `config set`, this module
 * provides a single `resolveConfigScope()` function that
 * encapsulates the logic. Commands call this function and get back the
 * correct scope without knowing the details.
 *
 * Design decision: `ImplicitScopePolicy` has two variants to cover the main
 * use cases:
 * - `global-default`: commands that should write globally by default (e.g. `auth`)
 * - `project-or-global-explicit`: project if in a project, else error (explicit --global required outside projects)
 *
 * Why `project-or-global-explicit` for commands that fundamentally require a project:
 * commands like `config set` without `--global` should not silently write to `~/.lovrabet.json`
 * when the user is outside a project directory. Requiring `--global` explicitly outside
 * projects prevents accidental global config pollution.
 */
export { DEFAULT_APP_PROFILE_NAME, DEFAULT_CONFIG_VALUES, } from "../../constant/defaults.js";
export { RUNTIME_ENV_VALUES } from "../../constant/env.js";
export { OUTPUT_FORMAT_VALUES } from "../../constant/output.js";
export { buildAppProfileListFields, CONFIG_ENUM_VALUES, CLI_PROTECTED_CONFIG_KEYS, IMPORTABLE_RUNTIME_CONFIG_KEYS, TOP_LEVEL_CONFIG_KEYS, getConfigCommandKeyDescription, getConfigDefaultValue, getConfigEnumValues, getTopLevelConfigKeyList, getTopLevelConfigKeySummary, isLegacyCompatConfigKey, isCliProtectedConfigKey, isTopLevelConfigKey, normalizeLocale, } from "../../config/schema.js";
/** Config write scope: either global or project. */
export type ConfigScope = "global" | "project";
/**
 * Policy for determining the implicit scope when neither `--global` nor `--project` is passed.
 *
 * Why two policies: different commands have different safety profiles.
 * `auth` writing globally by default is appropriate (system-wide credential).
 * `config set` outside a project should error rather than silently writing globally.
 */
export type ImplicitScopePolicy = 
/** Write to global config by default. */
"global-default"
/** Write to project config if inside a project; error if outside (require --global). */
 | "project-or-global-explicit";
export interface ResolveScopeOptions {
    explicitGlobal?: boolean;
    explicitProject?: boolean;
    policy: ImplicitScopePolicy;
    inProject?: boolean;
}
/**
 * Resolves the effective config scope from flags and policy.
 *
 * Why `--global` and `--project` are mutually exclusive: allowing both would make
 * the intent ambiguous. We explicitly check for this and throw a validation
 * error rather than defining precedence.
 *
 * Why `options.inProject` is optional: callers may pass the pre-computed value
 * to avoid calling `isInProject()` again (which involves a filesystem check).
 *
 * @throws CliError with code `"validation_error"` when both flags are set
 *         or when `--project` is used outside a project without `--global`.
 */
export declare function resolveConfigScope(options: ResolveScopeOptions): ConfigScope;
/** Converts a `ConfigScope` back to the equivalent `--global` flag value. */
export declare function toScopeFlags(scope: ConfigScope): {
    global: boolean;
};
/**
 * Formats a scope for human-readable output (e.g. in confirmation messages).
 *
 * Why `" (global)"` for global and empty string for project: this is used in
 * console output to annotate the target scope. Showing "(project)" would be
 * redundant (most operations are project-scoped). Showing "(global)" only
 * when relevant draws attention to the less common case.
 */
export declare function formatScopeLabel(scope: ConfigScope): string;