/**
 * How two approvals of the same interrupt combine.
 *
 * When several handlers in a chain approve one interrupt, their approval
 * values have to become one value. Historically that was "the outermost
 * approval overwrites" — which was never designed, it just fell out of the
 * chain loop, and it breaks the first time an approval carries data that
 * should accumulate (a guard trip's budget grants). The merge is now a
 * per-effect definition, looked up here.
 *
 * The table is TOTAL: every effect has a merge, and the default IS the
 * historical behavior, so effects without an entry are byte-compatible
 * with the old chain. `inner` is always the approval from the handler
 * closer to the interrupt; merges need not be commutative (message
 * concatenation is not).
 *
 * This is deliberately a CONSTANT, not a registration surface. A runtime
 * registry would be per-run state in a module global (banned), it would
 * silently diverge across the subprocess boundary (child registers a
 * merge, parent does not → the same interrupt merges differently in-process
 * and over IPC), and user-supplied merge closures would sit on the
 * function-refs-across-checkpoints problem surface (#513/#544). A user
 * registration surface arrives with typed interrupt payloads (#555).
 */
export type ApprovalMerge = (inner: any, outer: any) => any;
/** The merge for an effect's approvals within one process's chain. */
export declare function mergeFor(effect: string): ApprovalMerge;
/** The merge for combining a child process's approval with the parent's
 *  (mergeChainOutcomes). Same table; only the DEFAULT differs — see the
 *  two default constants above for why. */
export declare function mergeForIpc(effect: string): ApprovalMerge;