import type { Command } from '../args.js';
import type { CaptureHeaderDecl } from '@fetchproxy/protocol';
import type { Profile } from '../profiles.js';
import { type Io } from '../output.js';
import { type VerbServerFactory } from './fetch.js';
/**
 * `header@host[/path]` — byte for byte how the declaration is written on the
 * command line, and how it is keyed in output.
 *
 * The PATH is part of the key, not decoration. `--capture-header` accepts a
 * path, so a profile may legitimately declare the same header on the same host
 * twice with different paths — and keying on `header@host` alone collapsed
 * them, so the second result overwrote the first and one capture vanished from
 * the JSON with nothing to say it had.
 */
export declare const captureKey: (d: CaptureHeaderDecl) => string;
/**
 * `fpx capture` — snapshot a header off a request the PAGE makes.
 *
 * The CLI could already DECLARE `--capture-header`, which derives the
 * `capture_request_header` capability and puts it in the pair prompt, and then
 * had no way to use it: the user approved a scope nothing could exercise.
 * Diagnosing chrischall/fetchproxy#324 needed exactly this verb and had to be
 * done with a throwaway script instead, which is how the gap surfaced.
 *
 * All requested headers are captured CONCURRENTLY on purpose. A capture
 * resolves on the NEXT matching request, so one window serves every
 * declaration — asking for them in sequence would wait for a separate page
 * request per header and usually time out on all but the first.
 *
 * A header that does not arrive is reported as `null` rather than failing the
 * command, because a partial answer is the useful one: knowing WHICH of three
 * headers the page sends is the point of asking for three.
 */
export declare function runCapture(cmd: Extract<Command, {
    kind: 'capture';
}>, profile: Profile, io: Io, makeServer?: VerbServerFactory): Promise<number>;