/**
 * Realize LLM-emit rule manifest.
 *
 * Single source of truth for every post-emit constraint enforced on
 * per-owner LLM output. Replaces the prior model where each rule was
 * authored in THREE places (a regex+correction in `per-owner-emit.ts`,
 * a prose-statement in `realize-owner.prompt.yaml`, and an ad-hoc unit
 * test fixture). That model produced drift — prompt and validator
 * statements got out of sync, fixture coverage was uneven, and adding
 * a rule meant editing three locations consistently.
 *
 * The manifest below declares each rule once. Three consumers read it:
 *
 *   1. Validator pipeline (per-owner-emit.ts) — calls `detect(...)` to
 *      find violations, calls `correction(...)` to build the surgical-
 *      retry prefix, sorts rules by `ordering` to control which fires
 *      first when multiple violations co-occur.
 *
 *   2. Prompt builder — reads `promptStatement` to render the
 *      CONSTRAINTS section of `realize-owner.prompt.yaml` (Phase 2 of
 *      the 2026-05-12-VALIDATOR-MANIFEST-AND-TEST-CORPUS proposal).
 *
 *   3. Test corpus (`engines/src/realize/__tests__/llm-output-fixtures/`)
 *      — each fixture is annotated with the rule IDs it should trigger;
 *      the pipeline harness asserts the manifest's ordering produces
 *      exactly those fires.
 *
 * Adding a new rule is one place: append a new entry to RULES.
 *
 * Why in engines/src/realize/ rather than entities/src/core/realize/:
 *   For the moment, rules are realize-internal — they're regex scans
 *   over LLM-emitted TypeScript, not the kind of bundle-able content
 *   that R12 entity modules manage. If realize rules ever need to be
 *   extended by user specs (e.g. project-specific forbidden imports),
 *   migration to the entity-module pattern would be the next step.
 */
/** Context the rule pipeline carries through the per-owner emit. */
export interface RuleContext {
    /** Owner identifier — e.g. 'AuthController', 'GameStateService'. */
    ownerName: string;
    /** Target runtime declaration — e.g. 'Node.js (backend)'. Some rules
     *  apply only on specific runtimes (see `appliesWhen`). */
    targetRuntime?: string;
}
/** One violation found by a rule. Free-form string for the symbol /
 *  path / shape that triggered the rule (e.g. 'localStorage',
 *  '../services/AuthService'). Multiple violations can be returned
 *  from one detect() call. */
export type RuleViolation = string;
/**
 * A single realize-emit rule. Each field has one purpose:
 *
 *   - `id`: stable identifier for tests and logs. Kebab-case.
 *   - `summary`: one-line human description shown in stderr when
 *     `SPECVERSE_VERBOSE=1`.
 *   - `promptStatement`: human-language form of the rule for the
 *     prompt's CONSTRAINTS section. Phrased as an instruction to the
 *     LLM, NOT as a developer-facing comment.
 *   - `detect`: scan the LLM-emitted file for violations. Returns the
 *     list of distinct violations (cap to 8 for readability). Empty
 *     array = no violations.
 *   - `correction`: build the surgical-retry user-prefix string when
 *     violations are found. The LLM will see this prepended to the
 *     prompt on its second attempt.
 *   - `ordering`: pipeline position. Lower numbers fire first. Used to
 *     resolve which violation gets reported when multiple co-occur.
 *     Rough conventions:
 *       0-9:    structural pre-checks (parse, fence extraction)
 *       10-19:  runtime-API and environment-level constraints
 *       20-29:  import-shape constraints (extensions, scoping)
 *       30-39:  symbol-resolution constraints (sibling .ai, etc.)
 *       40+:    typing / shape constraints (Phase 3+)
 *   - `appliesWhen` (optional): predicate for runtime-conditional
 *     rules. e.g. 'no-browser-apis' applies only on Node target;
 *     'no-node-builtins' applies only on Browser target.
 */
export interface RealizeRule {
    id: string;
    summary: string;
    promptStatement: string;
    detect: (fileContents: string, ctx: RuleContext) => RuleViolation[];
    correction: (violations: RuleViolation[], ctx: RuleContext) => string;
    ordering: number;
    appliesWhen?: (ctx: RuleContext) => boolean;
}
/**
 * Map a target-runtime label to its forbidden-API symbol set. Exported
 * so the prompt builder can render the TARGET RUNTIME section using
 * the same source-of-truth the validator enforces.
 *
 * Targets supported:
 *   - "Node.js (backend)" (default) — browser globals are forbidden
 *   - "Browser (DOM)" — Node builtins are forbidden
 *   - Unknown / unset — treat as Node.js backend
 */
export declare function forbiddenApisForRuntime(targetRuntime?: string): string[];
/**
 * The full rule set, in pipeline order. Sorted by `ordering` field.
 * The exported list is read by:
 *   - per-owner-emit.ts (validator loop)
 *   - prompt-builder (CONSTRAINTS section of realize-owner.prompt.yaml)
 *   - test corpus (fixture-to-rule expected mapping)
 */
export declare const RULES: ReadonlyArray<RealizeRule>;
/** Helper: get a single rule by id. Throws if the id doesn't exist
 *  (catches typos in test fixtures + downstream consumers). */
export declare function getRule(id: string): RealizeRule;
/** Helper: filter RULES to the ones that apply for a given context. */
export declare function rulesApplicableTo(ctx: RuleContext): RealizeRule[];
/** Helper: render the CONSTRAINTS section of the prompt by joining
 *  each rule's promptStatement. */
export declare function renderConstraintsForPrompt(ctx: RuleContext): string;
//# sourceMappingURL=realize-rules.d.ts.map