/**
 * The `process` capability: a controller for long-lived background commands.
 *
 * Where {@link bashTool} runs a single command to completion and blocks, this
 * tool starts a command that keeps running between turns — a dev server, a file
 * watcher, a log tail — and lets the model check in on it later. It owns a small
 * in-module registry of live jobs (the {@link ProcessTable}); each registry
 * entry pairs the kernel {@link ShellHandle} with a rolling capture of whatever
 * the job has printed so far.
 *
 * Four verbs drive it:
 *   - `start` launches a command in the background and hands back its job id.
 *   - `list`  enumerates every tracked job with its current status.
 *   - `poll`  drains the output buffered since the last look and reports whether
 *             the job is still alive or how it ended.
 *   - `stop`  signals a running job to terminate and forgets it.
 *
 * The kernel {@link ShellHandle} exposes no output streams of its own — only a
 * pid, a kill, and an exit subscription. To capture what a background job prints
 * without ever touching `node:child_process`, the launcher wraps the command so
 * the platform shell redirects both streams into per-job scratch files, then
 * reads those files back through the {@link ToolContext.fs} seam. Every side
 * effect therefore flows through `ctx.shell` and `ctx.fs`; this module reaches
 * for no Node API of its own.
 */
/** Clear the background-job registry; intended for test setup/teardown. */
export declare function resetProcessTable(): void;
/**
 * The `process` tool: a registry-backed controller for background commands.
 *
 * Exported as a named {@link DefinedTool} so a host can register it directly.
 */
export declare const processTool: import("..").DefinedTool;
