/**
 * agent_bridge built-in tool — `recall`.
 *
 * Authoritative spec: `docs/tasks/T-warm-agent-chat-bridge.md` WAB.6 §"Tool
 * surface". Wraps the project-scoped RAG backend's `recall(query, k)` method.
 *
 * Responsibility:
 *   1. Validate the agent-supplied `{query, k?}` input.
 *   2. Call the injected `RagBackend.recall(query, k)`.
 *   3. Serialize the hit list into a compact string suitable for feeding
 *      back as a `tool_result.content`.
 *
 * Non-responsibility:
 *   - Does NOT own backend lifecycle. The `RagBackend` is constructed once
 *     per daemon (or per project, depending on WAB.7 wiring) and passed in.
 *   - Does NOT scope by `sessionKey`. Phase-1 RAG backends are project-scoped
 *     by construction (the libsql DB lives under the project's data dir) —
 *     a per-session scope would require a multi-tenant key column that the
 *     `RagBackend` interface does not expose today. The `ToolContext` is
 *     accepted for symmetry with the other tools, but the project scope is
 *     already baked into the backend instance.
 *
 * Output format:
 *   When the backend returns hits, we format them as a small newline-
 *   delimited list with `score: <0.xx>` + `source: <fused|semantic|lexical>`
 *   prefixes — terse enough that the model can copy-paste a quotation
 *   without first parsing JSON. When the backend returns `[]`, we surface
 *   "no results" rather than an empty string so the model doesn't silently
 *   misinterpret a successful-but-empty call as "tool errored".
 *
 * Imports from: zod, ../../../rag/types.js, ../types.js.
 * Imported by: ./index.ts (tools barrel).
 */
import type { RagBackend } from '../../../rag/types.js';
import type { ToolHandler, ToolSpec } from '../types.js';
export declare const recallSpec: ToolSpec;
export declare function makeRecallHandler(backend: RagBackend): ToolHandler;
//# sourceMappingURL=recall.d.ts.map