/**
 * The naming pass: decide which occurrences are the same point.
 *
 * This is the stage the pipeline was missing. Mining is a map over sessions and
 * counting is a reduce over labels, but nothing sat in between to agree on what
 * the labels *are*. The miner was asked to produce them from inside a single
 * session — to hit a shared vocabulary it had never seen — and on a real corpus
 * it agreed with itself 3 times in 188 candidates. `use-bun-not-npm` and
 * `prefer-bun-over-npm` are the same rule and never met.
 *
 * So naming happens once, with everything visible at the same time. That is a
 * different question than the miner was being asked: not "what is a good name
 * for this sentence" but "which of these sentences are the same point", which
 * is only answerable in the presence of the others.
 *
 * Two properties matter more than elegance here:
 *
 * - **Stability across runs.** State keys are `directive:<label>`, so a label
 *   that drifts between runs silently breaks suppression — every proposal you
 *   already decided on comes back forever. The labels already on record are
 *   therefore sent as a preferred vocabulary, and reusing one is the first
 *   instruction the model gets.
 * - **Degrading in order.** A window too large for one call is processed in
 *   sequence, with the names assigned so far carried into the next call. That is
 *   worse than seeing everything at once, but it is worse in a predictable
 *   direction: later candidates join earlier clusters rather than starting
 *   rival ones.
 */
import { type Model } from "@kolisachint/hoocode-ai";
import type { MinedCandidate } from "./mine.js";
/**
 * Trim the vocabulary to what fits, keeping both ends.
 *
 * The list is ordered: labels already on record first, then names invented
 * earlier in this run. Those are two different anchors — the first keeps the
 * bookmark matching across runs, the second keeps a split window from starting
 * rival names for one point — and taking a plain prefix silently drops the
 * second exactly when batching makes it necessary.
 */
export declare function trimVocabulary(labels: string[], max?: number): string[];
/** One candidate to be named, with the identity the caller needs to put the label back. */
export interface ClusterInput {
    /** Caller's handle for this candidate; returned untouched. */
    id: number;
    kind: MinedCandidate["kind"];
    text: string;
}
/**
 * Assign a label to each input. Missing entries are left for the caller to
 * handle; a clusterer may legitimately decline to name something.
 */
export type Clusterer = (inputs: ClusterInput[], knownLabels: string[], signal?: AbortSignal) => Promise<Map<number, string>>;
/** Render the numbered list the prompt describes. */
export declare function renderClusterRequest(inputs: ClusterInput[], knownLabels: string[]): string;
/**
 * Read the label assignments out of a model response.
 *
 * Same forgiving parse as the miner: models fence JSON they were told not to
 * fence, and one unparseable response should cost the run its grouping, not its
 * life. An id the caller never asked about is dropped rather than trusted.
 */
export declare function parseClusterLabels(response: string, known: Set<number>): Map<number, string>;
export interface ClustererDeps {
    model: Model<any>;
    apiKey?: string;
    headers?: Record<string, string>;
}
export declare function createLlmClusterer(deps: ClustererDeps): Clusterer;
/**
 * Fallback naming for a candidate the clusterer did not label.
 *
 * A run whose clustering call failed should still propose something, so an
 * unlabelled candidate falls back to a slug of its own text. That groups
 * identical wording and nothing else — the behaviour the pipeline had before
 * clustering existed, which is the right floor to fail to.
 */
export declare function fallbackLabel(text: string): string;
//# sourceMappingURL=cluster.d.ts.map