/**
 * pi-repair-layer — tool-input repair for pi's built-in tools.
 *
 * Why this hooks where it does: pi's agent loop runs
 *
 *   tool.prepareArguments(raw) -> validateToolArguments(...) -> tool_call event -> execute
 *
 * A validation failure short-circuits to an error result before the
 * `tool_call` extension event ever fires, so event handlers can never see
 * (let alone repair) malformed input. The only pre-validation seam is
 * `prepareArguments`, which extensions reach by overriding a built-in tool
 * with `pi.registerTool({ same name })`. Each override spreads the original
 * tool definition — renderers, prompt metadata, execution — and replaces only
 * `prepareArguments` (chaining the tool's own shim first) plus thin wrappers
 * around `execute` and `renderResult`.
 *
 * Feedback paths per repaired call:
 *  - Model: `<repair_note>` lines prepended to the tool result content, seen
 *    on the very next inference step of the same agent turn.
 *  - User: a `🔨 ✓ input repaired (...)` line appended to the tool row in the
 *    TUI (plus the note text if enabled) — toggle both via /repair-settings.
 *  - Telemetry: local-only JSONL, summarized by /repair-stats.
 *
 * Unrepairable input (still invalid after repairs) raises a model-readable
 * retry message instead of passing through, because pi's Value.Convert would
 * otherwise coerce it into garbage (null -> "null") and execute it anyway.
 *
 * Env:
 *   PI_TOOL_REPAIR_LOG=1           log repair decisions to stderr
 *   PI_TOOL_REPAIR_TELEMETRY=off   disable telemetry (or =<path> to relocate it)
 *   PI_TOOL_REPAIR_PASSTHROUGH=1   on unrepairable input, defer to pi's native
 *                                  validation instead of raising the retry error
 */
import { type ExtensionAPI } from "@earendil-works/pi-coding-agent";
export default function toolRepairExtension(pi: ExtensionAPI): void;
//# sourceMappingURL=index.d.ts.map