/**
 * Re-express a shipped `ToolRegistry` as tool definitions.
 *
 * This exists so a capability block that already owns a registry can arrive
 * through the public `tools` slot instead of being added to the tool registry by
 * a privileged path. The tools themselves are untouched: the whole
 * call — arguments and anything riding on it, like the app-create view-stream
 * bridge — is handed to the registry exactly as it arrived, and the OUTCOME
 * comes back exactly as the registry authored it.
 *
 * That last part is why {@link BACKING_REGISTRY} exists. A tool definition's own
 * `execute` answers with output or throws, because the denial statuses belong to
 * the guard; squeezing a registry's five-status outcome through that channel
 * flattens `blocked`, `connect-required` and `pending-approval` into errors and
 * rewrites every error code as "validation". Codes reach the model and the audit
 * row, so the merge dispatches straight to the backing registry when this marker
 * is present. `execute` stays implemented as an honest lossy fallback, for any
 * consumer that reads the definition without knowing about the marker.
 */
import { type ToolDefinition, type ToolDescriptor, type ToolRegistry } from "../core/index.js";
/** The registry behind a tool definition, when there is one. */
export declare const backingRegistry: (definition: ToolDefinition) => (() => ToolRegistry) | undefined;
/** `registry` is a thunk because the block that owns it is usually composed
 *  after the merge; it is resolved when a tool actually runs. */
export declare const toolsFromRegistry: (registry: () => ToolRegistry, descriptors: readonly ToolDescriptor[]) => ToolDefinition[];