/**
 * The skill-resource verdict engine (issue #129, slice 3).
 *
 * `evaluate(ctx)` is a **pure** function: it takes an intent-aware
 * {@link RuleContext} and returns at most one validation code (or `null` when
 * the resource/edge is fine). It never touches the filesystem — all I/O lives
 * in the per-path extraction front-ends. `materializeIssue(code, …)` is the
 * single place that turns a code into a {@link ValidationIssue}, sourcing
 * `description` / `fix` / `reference` / `defaultSeverity` from
 * `CODE_REGISTRY` so docs, runtime, and tests cannot drift (the runtime
 * `message` is the registry `description` plus per-issue detail).
 *
 * Determinism + non-aliasing are enforced by the scenario harness: every
 * constructed context maps to exactly one expected code, and no two distinct
 * intents may share a context signature while expecting different codes.
 */
import { type IssueCode, type ValidationIssue } from '@vibe-agent-toolkit/agent-schema';
import type { RuleContext } from './rule-context.js';
/**
 * Evaluate a single intent-aware context to at most one validation code.
 *
 * @returns the code that fires, or `null` when the resource/edge is acceptable.
 */
export declare function evaluate(ctx: RuleContext): IssueCode | null;
/**
 * Options for {@link materializeIssue}.
 *
 * `location` / `line` / `field` / `link` are the four independent anchors of
 * {@link ValidationIssue} and are passed through verbatim — see the anchor
 * contract on that type. In particular `location` is ALWAYS the
 * project-relative path of the file to open; a link target belongs in `link`.
 */
export interface MaterializeOpts {
    /** Project-relative POSIX path of the file the issue is in. */
    location?: string | undefined;
    /** 1-based line within `location`. */
    line?: number | undefined;
    /** Dotted document-internal pointer, e.g. `frontmatter.description`. */
    field?: string | undefined;
    /** A link href/target the issue concerns — never the file to open. */
    link?: string | undefined;
    /**
     * Per-issue detail appended to the registry `description` to form the runtime
     * `message` (e.g. the link href). The registry `description` stays the stable,
     * doc-asserted headline; `message` is treated as dynamic.
     */
    detail?: string | undefined;
    /**
     * Full runtime `message` override. Use when a code needs a bespoke message
     * that isn't `description (detail)` — severity/fix/reference still come from
     * the registry. Takes precedence over {@link MaterializeOpts.detail}.
     */
    message?: string | undefined;
}
/**
 * Build a {@link ValidationIssue} for a code, sourcing severity / description /
 * fix / reference from {@link CODE_REGISTRY}. The single construction site for
 * skill-resource issues — eliminates the duplicated `{severity, code, message,
 * fix, reference}` literals that previously lived in walker-to-issues,
 * deferredAssetsToIssues, and post-build-checks.
 */
export declare function materializeIssue(code: IssueCode, opts?: MaterializeOpts): ValidationIssue;
//# sourceMappingURL=rule-engine.d.ts.map