/**
 * resource-handler.ts — handles resource_request commands from the frontend.
 *
 * Dispatches list/read/write/delete/search operations to the ConnectorManager.
 * Tool-face connectors are served through the manager's CRUD dispatch;
 * filesystem-face (mountable) connectors are served directly from their
 * projected mount directory. Emits resource_response events back through the
 * transport.
 */
import type { ConnectorManager } from "@skaile/workspaces/connectors";
import type { AgentEvent, ConnectorRequestCommand } from "@skaile/workspaces/types";
/**
 * Handle a resource_request command by dispatching to the ConnectorManager
 * and emitting a resource_response event.
 * @docLink packages/runner/dev-guide#flow-execution-turn-based-model
 */
export declare function handleResourceRequest(command: ConnectorRequestCommand, manager: ConnectorManager, emit: (event: AgentEvent) => void): Promise<void>;
/**
 * Maximum directory depth a recursive mount listing descends.
 *
 * Guards against a symlink/junction cycle on a remote mount turning one folder
 * open into an unbounded walk.
 */
export declare const MOUNT_LIST_MAX_DEPTH = 32;
/**
 * Maximum number of entries a single mount listing returns.
 *
 * A recursive walk issues one round-trip per directory and one per file on a
 * cloud mount, so an unbounded listing is an unbounded request.
 */
export declare const MOUNT_LIST_MAX_ENTRIES = 10000;
/**
 * Deadline multiplier for the recursive delete.
 *
 * The single-op deadline exists to catch a *wedged* mount, where nothing
 * returns. A recursive `rm` on a healthy mount is not that: rclone issues one
 * remote DELETE per object with no write-back cache to hide the latency, so a
 * few hundred files legitimately outlast a single `stat`. Charging that the
 * single-op deadline would report "delete failed" while the uncancellable `rm`
 * carries on and the folder does disappear — a wrong error with a real side
 * effect. Matches the tree-op factor used by the catalog deployer and the
 * workspace-config tree copy.
 */
export declare const MOUNT_TREE_OP_DEADLINE_FACTOR = 4;
/**
 * Deadline multiplier for reading one whole file off the mount.
 *
 * A cold rclone VFS serves the first read of a large file straight from the
 * remote, so honest duration scales with file size, not with mount health. The
 * write path stays on the single-op default deliberately: writes land in the
 * VFS write-back cache and return locally, so a slow write really does mean a
 * sick mount.
 */
export declare const MOUNT_READ_DEADLINE_FACTOR = 4;
/**
 * Length of the run of `0x00` bytes a text buffer ends with.
 *
 * A cloud mount served through an rclone VFS cache can hand back a text file
 * whose declared size exceeds the bytes the remote actually serves (SharePoint
 * metadata sizes are known to drift from content length); the unfilled tail
 * of the cache item reads back as zeros. Those zeros are not content. A text
 * file whose real content ends in NUL bytes does not occur in practice, so the
 * caller strips the run before decoding; binary buffers must never go through
 * this (a zip's end-of-central-directory record legitimately ends in zeros).
 */
export declare function nulTailPaddingLength(buf: Buffer): number;
/**
 * Handle a resource request against a filesystem-face (mountable) connector.
 *
 * All filesystem work is async and deadline-bounded, so a wedged mount fails
 * this one request (`resource_response` with `error`) instead of parking the
 * event loop. Listings are additionally capped by {@link MOUNT_LIST_MAX_DEPTH}
 * and {@link MOUNT_LIST_MAX_ENTRIES}; exceeding either is an error, never a
 * silently truncated result.
 *
 * @docLink packages/runner/dev-guide#flow-execution-turn-based-model
 */
export declare function handleMountResourceRequest(command: ConnectorRequestCommand, manager: ConnectorManager, emit: (event: AgentEvent) => void): Promise<void>;
//# sourceMappingURL=resource-handler.d.ts.map