/**
 * A boolean per source line (0-based): `true` when the line lies inside a fenced
 * code block (` ``` ` or `~~~`), the delimiter lines included — matching the
 * scope of the hand-rolled `FENCE` regexes this replaces. Indented code blocks
 * are deliberately NOT flagged, to preserve the prior detectors' behavior (they
 * only ever recognized fenced blocks). Correct on nested and unbalanced fences,
 * which the naive toggle was not.
 *
 * Pass the SAME string the caller iterates with `.split("\n")` so the returned
 * indices line up 1:1 with the caller's line array.
 */
export declare function fencedLineFlags(src: string): boolean[];
/**
 * The document's PROSE, as CommonMark sees it: one entry per source line that
 * carries author text, with fenced code, indented code, raw HTML blocks, inline
 * code spans and inline HTML removed, and blank lines dropped.
 *
 * 🔴 WHY A CALLER MUST NOT DO THIS BY SPLITTING LINES. The module header already
 * records that the naive `inFence = !inFence` toggle was copy-pasted into five
 * detectors and is wrong on nested or unbalanced fences. The same applies to
 * every other part of "what is the author actually saying here": a `<!-- -->`
 * spanning three lines, a four-backtick block containing a bare three-backtick
 * line, an indented continuation. The parser has all of it.
 *
 * What it also does, and what a hand-written reader gets wrong quietly: block
 * parsing strips the leading INDENT, normalises CRLF, and drops trailing
 * whitespace and trailing blank lines — so `@AGENTS.md`, `  @AGENTS.md`,
 * `@AGENTS.md  ` and a CRLF-terminated copy all arrive as the same string
 * (measured against this repo's markdown-it, 2026-09-21).
 *
 * ⚠️ THE ONE THING IT DOES NOT NORMALISE IS A UTF-8 BOM: markdown-it hands back
 * `"\uFEFF@AGENTS.md"` for a BOM-prefixed first line, so this strips it. That is
 * a measurement, not a precaution.
 */
export declare function proseLines(src: string): readonly string[];
/** One fenced code block: its BODY (delimiters excluded) and where the body starts. */
export interface FencedBlock {
    /** The block's contents, without the opening/closing fence lines. */
    readonly body: string;
    /** 1-BASED line number of the body's first line, for a caller's messages. */
    readonly start: number;
}
/**
 * Every fenced code block in `src`, in document order — the same parser
 * {@link fencedLineFlags} uses, for callers that want the CONTENTS rather than a
 * per-line flag.
 *
 * 🔴 THE CLOSING FENCE MUST MATCH THE OPENING ONE, and every hand-rolled version
 * of this in the repo got that wrong the same way: any line beginning with three
 * backticks TOGGLED. CommonMark says a closing fence uses the same CHARACTER as
 * the opener and is at least as LONG, so a four-backtick block wrapping an
 * ordinary ``` example closes early — the block is cut in half, and the prose
 * after it becomes "another block" whose text is then read as commands. That
 * makes a document-rule check both MISS commands and JUDGE prose. `~~~` fences
 * were not recognized at all.
 *
 * Backed by markdown-it (CommonMark), so delimiter character, delimiter length,
 * `~~~`, indented fences inside list items and an unterminated final fence are
 * all decided by the grammar rather than re-derived here. Measured 2026-08-12 on
 * each of those shapes.
 *
 * One deliberate difference from a hand-rolled toggle, and it is the grammar's:
 * a fence indented FOUR or more spaces at top level is an indented code block,
 * not a fence, and is not returned. Line numbers count from the ORIGINAL source,
 * so a caller's message points at the real line.
 */
export declare function fencedCodeBlocks(src: string): FencedBlock[];
/**
 * How a reference appeared in the markdown.
 *
 * `link` is a DESTINATION — the thing the reader follows: an inline link's
 * target, or an image's `src`. `code` is a bare backtick span standing on its
 * own in prose.
 */
export type MarkdownRefKind = "link" | "code";
/** One reference recovered from markdown STRUCTURE. */
export interface MarkdownRef {
    readonly kind: MarkdownRefKind;
    /**
     * For `link`, the destination exactly as written. For `code`, the span's
     * content. Never the display text of a link — see {@link markdownRefs}.
     */
    readonly value: string;
    /** 1-based source line the reference sits on. */
    readonly line: number;
}
/**
 * Every reference a markdown body makes, taken from the PARSE rather than from
 * the characters.
 *
 * 🔴 WHY THIS EXISTS: A LINK'S TEXT IS NOT A REFERENCE. The detector this
 * replaces ran two regexes over each line — one for `[..](..)`, one for
 * `` `..` `` — and the second one could not see that it was standing inside the
 * first. Measured 2026-08-17 on `microsoft/power-platform-skills`:
 *
 *     See [`references/dataverse-reference.md` § Setting Lookups](../add-dataverse/references/dataverse-reference.md#setting-lookups)
 *
 * The DESTINATION resolves — the file is 23KB and present. The backtick span in
 * the link's TEXT is a human-readable label for it. vigiles reported the label
 * as a missing bundled resource, i.e. it accused a correct link of being broken
 * by reading the half of it that is display. The same shape cost
 * `rohitg00/pro-workflow` a second false accusation.
 *
 * So a code span nested inside a link's (or an image's) text is NOT emitted.
 * The destination is right there, it is what the agent follows, and it is
 * returned instead. The bug is not fixed here so much as made unsayable: a
 * caller of this function is never handed link text at all.
 *
 * Fenced and indented code blocks contribute nothing ({@link fencedLineFlags}
 * decides which lines those are, so no caller re-derives it).
 *
 * ⚠️ ONE LINE AT A TIME, and the reason is the line number. Callers report a
 * reference by source line, and markdown-it's inline tokens carry no line
 * information — only the enclosing block does — so a paragraph-wide parse would
 * point every reference in a paragraph at the paragraph's first line. Parsing
 * each line's inline content keeps the number exact. The cost is a construct
 * split across two source lines (a link whose `](` sits on the next line),
 * which is not recovered — the regexes this replaces did not recover it either.
 */
export declare function markdownRefs(src: string): MarkdownRef[];
/**
 * The fragment ids a markdown file defines — what `file.md#<id>` can land on.
 *
 * Two sources, because both are how real files are linked into:
 *
 * - every HEADING, slugged the way GitHub slugs it (lowercase; drop everything
 *   that is not a letter, number, space, `-` or `_`; spaces to `-`; a repeated
 *   slug gets `-1`, `-2`, …), with the heading's text taken from the parser's
 *   inline token, so emphasis and code spans do not leak their markers in;
 * - every explicit `id="…"` / `name="…"` on raw HTML (`<a id="why"></a>`), which
 *   is how a file in a non-Latin language gives its sections stable ASCII ids.
 *
 * Other renderers slug differently (GitLab, mkdocs). A link that resolves on
 * GitHub and nowhere else is still a link this accepts; one that resolves
 * NOWHERE — a renamed heading — is what it exists to catch.
 */
export declare function markdownAnchors(src: string): ReadonlySet<string>;
//# sourceMappingURL=markdown.d.ts.map