import { Command } from '@oclif/core';
/**
 * Unlike `run`/`status`/`result` (migrated to oclif's native `--json` in
 * OUT-419, #281), this command deliberately keeps a custom `--format json`
 * instead of `enableJsonFlag`. Native `--json` suppresses all `this.log()`
 * calls and prints exactly one JSON object — the command's return value —
 * after `run()` resolves. `monitor` has no single "return value": it emits a
 * live stream of discrete events (span status changes, a continue-as-new
 * notice, a final summary) while the workflow is still in progress, and
 * `--format json` prints each as its own NDJSON line as it happens. That's
 * the point — a caller (often another automated/agent process, not a human)
 * can tail and parse the stream incrementally, which native `--json`'s
 * "one object at the end" model can't do. See docs/guides/packages/cli.mdx
 * ("output workflow monitor") for the same rationale written up for users.
 *
 * The polling loop itself lives in `#services/monitor_stream.js` so
 * `workflow start --monitor` (OUT-537) streams through the same code path.
 */
export default class WorkflowMonitor extends Command {
    static description: string;
    static examples: string[];
    static args: {
        workflowId: import("@oclif/core/interfaces").Arg<string, Record<string, unknown>>;
    };
    static flags: {
        'include-payloads': import("@oclif/core/interfaces").BooleanFlag<boolean>;
        interval: import("@oclif/core/interfaces").OptionFlag<number, import("@oclif/core/interfaces").CustomOptions>;
        color: import("@oclif/core/interfaces").BooleanFlag<boolean>;
        'run-id': import("@oclif/core/interfaces").OptionFlag<string | undefined, import("@oclif/core/interfaces").CustomOptions>;
        format: import("@oclif/core/interfaces").OptionFlag<string, import("@oclif/core/interfaces").CustomOptions>;
    };
    run(): Promise<void>;
    catch(error: Error): Promise<void>;
}