/**
 * detach/drivers/immediate.ts — Run detached work synchronously inside `schedule()`.
 *
 * Pattern:  Null-object driver for the "no actual deferral" case. Same
 *           intent as a `setTimeout(fn, 0)` shim that just calls `fn()`
 *           — keeps the API surface uniform so consumers can swap drivers
 *           without changing call sites.
 * Role:     Test fixture + opt-in for consumers who want fire-and-forget
 *           ergonomics (the handle API) without actually deferring. Useful
 *           for:
 *
 *             - unit tests where deterministic, synchronous completion
 *               beats microtask gymnastics
 *             - very small detach payloads where the overhead of a
 *               microtask roundtrip exceeds the work itself
 *             - debugging — easier to step through with breakpoints
 *
 * Performance:
 *   - Sync runChild → handle becomes terminal before `schedule()` returns
 *   - Async runChild → handle marks running sync, terminal at runChild's
 *     resolution. The `wait()` Promise is the same one consumers use for
 *     any other driver; behaviour is uniform.
 *
 * Caveat — this is NOT a passive-recorder by default:
 *   When runChild is sync, the parent stage observes the work's side
 *   effects WITHIN its own slice. That's intentional for the test/debug
 *   use case but means consumers should NOT use `immediateDriver` for
 *   long-running work in production hot paths — pick `microtaskBatchDriver`
 *   for that.
 */
import { type ChildRunner } from '../runChild.js';
import type { DetachDriver } from '../types.js';
/**
 * Build an immediate driver wired to a custom child runner. Most
 * consumers want the default singleton `immediateDriver`.
 */
export declare function createImmediateDriver(runChild?: ChildRunner): DetachDriver;
/** Default singleton — most consumers use this. */
export declare const immediateDriver: DetachDriver;