/**
 * ADR-333 D5 — building a catalogue for a client and handing it over, for
 * assistants (plan #2808 §10).
 *
 * Organisation side: pica_handover_create, pica_handover_send. Client side:
 * pica_handover_answer, which only says where to answer.
 *
 * Each organisation-side tool calls one /api/admin/handovers route, which
 * holds no rules of its own: lib/services/catalogue-handovers.ts decides
 * every step and refuses with a code and a plain sentence, passed on as is.
 *
 * Sending emails a client and offers them a catalogue, so it is the person's
 * own decision (plan §10, "sending needs a human confirm"):
 *  - from a connected app or agent grant, pica_handover_send is
 *    `approvalMode: "human"`: the MCP route stages an approval, and on
 *    approval lib/services/handover-approvals.ts sends through the service,
 *    never this file;
 *  - from a credential the route refuses as HUMAN_CONFIRMATION_REQUIRED, the
 *    tool gives the screen to send it on.
 *
 * Accepting ownership is a person's own act (Orchestrator ruling 2026-10-12,
 * option A): the client's routes take a signed-in session only, and no key
 * reads them. pica_handover_answer therefore reads nothing and changes
 * nothing; it gives the screen where the person answers.
 */
import { type PicaClient } from "@withpica/mcp-sdk";
import type { ToolDefinition, ToolExecutor } from "./index.js";
/** The relationship the organisation keeps once the client accepts. */
export declare const HANDOVER_KEPT_TYPES: readonly ["administrator", "representative", "viewer"];
export declare class HandoverTools {
    private readonly pica;
    private readonly origin;
    constructor(pica: PicaClient, apiUrl?: string);
    getTools(): Array<{
        definition: ToolDefinition;
        executor: ToolExecutor;
    }>;
    private create;
    private send;
    private answer;
}
//# sourceMappingURL=handovers.d.ts.map