import { type ToolRegistry } from "./core/index.js";
/**
 * Design §12 — "two actions must never read identically on a card."
 *
 * A consent card shows a tool's `title`. If two tools share one, the card cannot
 * tell the person which action they are approving, and `title` is part of the
 * descriptorHash they consented to — so the ambiguity is not cosmetic, it is a
 * consent defect. The contract calls for a BOOT error.
 *
 * `createVendo` is synchronous while the descriptor set is resolved lazily and
 * asynchronously (the portability gate forbids I/O at module scope, so
 * `actions.descriptors()` cannot be awaited at compose). Composition therefore
 * INSTALLS this check, and it fires the instant the descriptor set first becomes
 * known — the earliest moment the fact is knowable at all. A bad deployment
 * fails every call that needs tools and never becomes healthy on retry.
 *
 * The check is memoized per registry: every turn enumerates descriptors, and a
 * whole-registry title scan on that hot path would be waste for a fact that
 * cannot change without a redeploy.
 *
 * The scan runs over the FULL, UNPROJECTED tool set — `tools.descriptors()` with
 * NO context — never over a per-run projection. Title uniqueness is a deployment
 * property: two identically-titled tools collide whether or not a given run is
 * allowed to see both of them. Memoizing a verdict computed against a projected
 * set was a real hole: an unattended tick projects away the two DESTRUCTIVE
 * tools that collide, the collision vanishes from that set, and a "clean" verdict
 * gets cached — after which an attended execute short-circuits and runs a
 * mutating call under an ambiguous consent card.
 */
export declare function withUniqueToolTitles(tools: ToolRegistry): ToolRegistry;