import { z } from "zod";
import type { Severity, RuleConfig } from "./rule.js";
import type { PostSynthDiagnostic } from "./post-synth.js";
export { findProjectRoot } from "../project-root.js";
export declare const LintConfigSchema: z.ZodObject<{
    rules: z.ZodOptional<z.ZodRecord<z.ZodString, z.ZodUnion<readonly [z.ZodEnum<{
        error: "error";
        warning: "warning";
        info: "info";
        off: "off";
    }>, z.ZodTuple<[z.ZodEnum<{
        error: "error";
        warning: "warning";
        info: "info";
        off: "off";
    }>, z.ZodRecord<z.ZodString, z.ZodUnknown>], null>]>>>;
    extends: z.ZodOptional<z.ZodArray<z.ZodString>>;
    overrides: z.ZodOptional<z.ZodArray<z.ZodObject<{
        files: z.ZodArray<z.ZodString>;
        rules: z.ZodRecord<z.ZodString, z.ZodUnion<readonly [z.ZodEnum<{
            error: "error";
            warning: "warning";
            info: "info";
            off: "off";
        }>, z.ZodTuple<[z.ZodEnum<{
            error: "error";
            warning: "warning";
            info: "info";
            off: "off";
        }>, z.ZodRecord<z.ZodString, z.ZodUnknown>], null>]>>;
    }, z.core.$strip>>>;
    plugins: z.ZodOptional<z.ZodArray<z.ZodString>>;
    policies: z.ZodOptional<z.ZodArray<z.ZodString>>;
}, z.core.$strip>;
/**
 * Per-file rule override
 */
export interface LintOverride {
    /** Glob patterns to match file paths */
    files: string[];
    /** Rule overrides for matched files */
    rules: Record<string, RuleConfig>;
}
/**
 * Lint configuration
 */
export interface LintConfig {
    /** Rule configurations: rule ID -> severity string or [severity, options] tuple */
    rules?: Record<string, RuleConfig>;
    /** Array of config file paths to extend from */
    extends?: string[];
    /** Per-file rule overrides via glob patterns */
    overrides?: LintOverride[];
    /** Array of plugin file paths to load custom rules from (project-local, not inherited) */
    plugins?: string[];
    /**
     * Array of file paths to load project-authored organizational policy checks
     * from — each exporting one or more {@link PostSynthCheck} objects. They run
     * during `chant build` over the resolved resources, with the current `env` in
     * context. Distinct from `plugins` (declarative lint rules) by authorship and
     * phase; same engine.
     */
    policies?: string[];
}
/**
 * Parsed rule configuration with severity and optional options
 */
export interface ParsedRuleConfig {
    severity: "off" | Severity;
    options?: Record<string, unknown>;
}
/**
 * Parse a rule config value into severity and options
 */
export declare function parseRuleConfig(value: RuleConfig): ParsedRuleConfig;
/**
 * Resolve one check/rule id's effective severity (and options) against an
 * already-resolved `lint.rules` map — the ONE place `"off"`/severity-override
 * resolution happens, so a rule id behaves identically regardless of which
 * phase produced it.
 *
 * chant #1138 — before this, the same `lint.rules: { ID: "off" }` config was
 * resolved by two independent call sites that had grown their own copy of
 * this logic (`../cli/commands/lint.ts`'s `getDefaultRules` for AST COR/EVL
 * rules, and its `runComponentCheckDiagnostics` for whole-component COMP*
 * checks) — identical in effect, but a rule id's suppression having two
 * places to (potentially, eventually) diverge is itself the bug class #1138
 * is about. Both were converted to call this instead, and post-synth checks/
 * policies (`./post-synth.ts`'s `applyConfiguredSeverity`) now go through it
 * too, closing the gap the issue reports: a post-synth check id honors
 * `lint.rules` exactly like an AST rule id does.
 *
 * `rules` takes the already-resolved map (`config.rules`, or
 * `resolveRulesForFile`'s per-file merge) rather than a whole `LintConfig` —
 * callers that need per-file `overrides` resolve that first; post-synth
 * checks have no per-file scope to begin with (see {@link
 * ./post-synth.ts!PostSynthDiagnostic}'s doc for why), so they always pass
 * `config.rules` directly.
 */
export declare function resolveConfiguredSeverity(rules: Record<string, RuleConfig> | undefined, id: string, defaultSeverity: Severity): ParsedRuleConfig;
/**
 * Default configuration with all rules enabled at strict preset severities
 */
export declare const DEFAULT_CONFIG: LintConfig;
/**
 * Load lint configuration from a directory.
 *
 * Tries `chant.config.ts` first (extracts `lint` property from ChantConfig),
 * then falls back to `chant.config.json` (legacy LintConfig format).
 * Returns default configuration if neither exists.
 *
 * chant #1113 — the `chant.config.ts` branch executes project-authored code,
 * so it goes through `../config-sandbox.ts` like every other config load
 * rather than `require`-ing the file itself. Unarmed (which is every `chant
 * lint` invocation today — `lint` has no `--sandbox` flag) that is the
 * identical `createRequire` path this used before, moved one module over.
 *
 * @param dir - Directory path to search for config file
 * @returns Loaded and merged configuration, or default config if not found
 */
export declare function loadConfig(dir: string): LintConfig;
/**
 * Resolve the effective rules for a specific file path by applying overrides.
 *
 * Starts with the base config rules, then iterates through overrides in order.
 * For each override whose file globs match the given path, merges override rules on top.
 *
 * @param config - The loaded lint configuration
 * @param filePath - The file path to resolve rules for (relative to project root)
 * @returns Merged rule configuration with overrides applied
 */
export declare function resolveRulesForFile(config: LintConfig, filePath: string): Record<string, RuleConfig>;
/** Result of applying `lint.rules` to a set of post-synth diagnostics. */
export interface PostSynthSeverityResult {
    /** Diagnostics after config resolution — `"off"`-suppressed ones removed, everything else at its resolved severity. */
    diagnostics: PostSynthDiagnostic[];
    /**
     * Diagnostics `lint.rules` turned `"off"`, unaltered — present so a caller
     * can report a count (chant #1138) rather than the finding simply
     * vanishing, mirroring `../lint/engine.ts`'s `LintRunResult.suppressed` for
     * AST rules.
     */
    suppressed: PostSynthDiagnostic[];
}
/**
 * Apply `lint.rules` severity overrides to already-produced post-synth
 * diagnostics — one lexicon-shipped check's findings, or one project's
 * `lint.policies` findings, it doesn't matter which: both are plain
 * `PostSynthDiagnostic[]` by the time they reach this function, so both go
 * through the identical resolution an AST rule id or a COMP* check id gets
 * (`resolveConfiguredSeverity`, above), keyed by `diag.checkId` instead of
 * `LintRule.id`/`ComponentCheck.id`. `"off"` suppresses (moved to
 * `suppressed`); any other configured severity replaces `diag.severity`,
 * exactly as a config override changes an AST diagnostic's reported level.
 *
 * Lives here rather than in `./post-synth.ts` (where `PostSynthDiagnostic` is
 * declared) on purpose: `post-synth.ts` is a leaf every lexicon's checks
 * import as a real runtime module, and this file resolves built-in preset
 * paths via the runtime adapter at module scope — pulling that into every
 * lexicon's check barrel merely to share one filter function would be the
 * wrong trade. Only this file's TYPE (`PostSynthDiagnostic`) crosses back,
 * which costs nothing at runtime.
 *
 * chant #1138 — deliberately does NOT also honor `chant-disable` source
 * comments. `PostSynthDiagnostic` has no source anchor to disable AT — see
 * its doc comment (`./post-synth.ts`) for why `entity` doesn't supply one —
 * so there is no coherent site to check for a directive. Even in the one case
 * a real anchor sometimes exists (a live, in-process `ctx.entities` value
 * stamped with build provenance, `../provenance.ts`'s `getProvenance`), it
 * would not generalize: not every check sets `entity`, `entity` isn't
 * guaranteed to be an entities-map key (it's a name in the synthesized
 * OUTPUT — a CFN logical id, a k8s `metadata.name` — which a serializer is
 * free to have derived, prefixed, or renamed from the source-level entity
 * name), and that provenance never crosses the `--sandbox` policy child's
 * JSON wire (`../discovery/entity-wire-codec.ts` doesn't carry it, and
 * re-deriving it on the far side would mean sending source file paths into a
 * channel that's supposed to carry only the resolved build). Building
 * directive suppression on a sometimes-present, sometimes-not anchor would
 * make `chant build` and `chant build --sandbox` disagree about the
 * identical finding depending on which path happened to still have the
 * entity object around — precisely the kind of inconsistency #1138 exists to
 * remove. Config severity (`"off"`) is the one suppression surface this can
 * offer uniformly; a check that wants a per-instance escape hatch can read
 * `ctx.env`/its own options to decide not to emit a diagnostic at all.
 */
export declare function applyConfiguredSeverity(diagnostics: readonly PostSynthDiagnostic[], rules: Record<string, RuleConfig> | undefined): PostSynthSeverityResult;
//# sourceMappingURL=config.d.ts.map