/**
 * Semantic tokens for the inside of a CEL body.
 *
 * A `!cel "..."` scalar is not a string, and under a stock YAML grammar it is
 * painted as one. Colouring it through the SEMANTIC layer rather than a grammar
 * is what makes one implementation serve both hosts — VS Code and the editor's
 * Monaco already share `buildSemanticTokens`, while a Monarch tokenizer beside
 * the TextMate one would be a second CEL lexer to keep in agreement.
 *
 * It is also the only layer that can be right about NAMES. A grammar knows the
 * seven kernel roots someone hardcoded into it, which is why `request` and
 * `steps` go uncoloured today; the scope query knows what is actually in scope
 * at this exact site. So a name the scope confirms is coloured and a name it
 * cannot is left alone — the quiet signal an unresolved `kind:` already gives.
 */
import { type CelScope, type CelSegment } from "@telorun/analyzer";
import type { SemanticTokenType } from "../types.js";
/** A token before it is placed on a line — document offsets, resolved by the
 *  caller which owns the line table. */
export interface CelTokenSpan {
    range: [number, number];
    type: SemanticTokenType;
}
/**
 * Tokens for one CEL segment.
 *
 * A body that does not parse yields nothing: mid-typing is the normal case
 * here, and the analyzer reports the syntax error itself. Only that failure is
 * tolerated — a defect in the CEL wrapper propagates.
 */
export declare function celSegmentTokens(text: string, segment: CelSegment, scope: CelScope | undefined): CelTokenSpan[];
//# sourceMappingURL=tokens.d.ts.map