import type { Ruleset } from '@amritk/lint';
import type { RulesetDefinition } from '@amritk/lint/types';
/**
 * Routing a ruleset to the right builder: which names mean a built-in preset,
 * whether a ruleset the CLI loaded off disk names one, and how to build with it.
 * The three live together rather than one per file because they are a single
 * concern — the name table is the whole question — and because the two entry
 * points must agree on it: `--ruleset <name>` and a loaded ruleset's `extends`
 * accept exactly the same preset names.
 */
/**
 * The two built-in presets the CLI can build a ruleset with. They are mutually
 * exclusive: each preset only knows how to resolve its *own* name inside
 * `extends`, and each brings a different format registry, so one ruleset cannot
 * be built with both.
 */
export type PresetName = 'asyncapi' | 'oas';
/**
 * Every name that resolves to a built-in preset — as `--ruleset <name>` and
 * inside a ruleset's `extends` — mapped to the preset it names. The aliases
 * mirror what the presets' own `extends` resolution accepts, including the
 * legacy Spectral ones.
 *
 * A Map, not a record: the key comes straight from user input, and a record
 * lookup on `constructor` would find `Object.prototype`'s.
 */
export declare const PRESET_RULESET_NAMES: ReadonlyMap<string, PresetName>;
/**
 * Builds a *runnable* ruleset with a preset's builder. Built rather than handed
 * to `lintDocument` as data, deliberately: a preset brings its own custom
 * functions and format detectors, which a definition cannot carry — as data,
 * every one of its rules would be silently skipped (unknown functions, a
 * `formats` gate matching nothing).
 *
 * With no `definition` this is the bare `--ruleset asyncapi` case: the preset's
 * recommended rules and nothing else. With one, the caller's ruleset is built by
 * the preset, whose `extends` resolution knows the preset names and whose
 * `basePath` keeps the user's relative `extends` and `functions` resolving next
 * to their own file.
 *
 * No `restrictTo` is passed, which matches what the core path does for a
 * discovered or `--ruleset` file today: the CLI treats a ruleset on the local
 * disk as trusted configuration. (`--allowed-roots` fences `$ref` resolution in
 * the *document*, a separate concern.) See the "Trust boundary" section of
 * `@amritk/lint`'s README.
 */
export declare const buildPresetRuleset: (preset: PresetName, definition?: RulesetDefinition, basePath?: string) => Promise<Ruleset>;
/**
 * Decides what `lintDocument` should run for a ruleset just loaded off disk —
 * whether it came from `--ruleset <file>` or `.lint.*` discovery.
 *
 * A ruleset that extends a built-in preset has to be built *here*, by that
 * preset's builder: handed over as a definition, `lintDocument` builds it with
 * the core `createRuleset`, which knows neither the preset names nor the
 * functions and format detectors a preset brings. Anything else stays a
 * definition and takes the core path exactly as it did before.
 *
 * @param basePath - The ruleset file's own directory, so its relative `extends` and `functions` still resolve there.
 * @param label - How to name the ruleset in an error, e.g. its path.
 */
export declare const buildLoadedRuleset: (definition: RulesetDefinition, basePath: string, label: string) => Promise<RulesetDefinition | Ruleset>;