/**
 * V3 CLI Command Parser
 * Advanced argument parsing with validation and type coercion
 */
import type { Command, CommandOption, ParsedFlags } from './types.js';
export interface ParseResult {
    command: string[];
    flags: ParsedFlags;
    positional: string[];
    raw: string[];
}
export interface ParserOptions {
    stopAtFirstNonFlag?: boolean;
    allowUnknownFlags?: boolean;
    booleanFlags?: string[];
    stringFlags?: string[];
    arrayFlags?: string[];
    aliases?: Record<string, string>;
    defaults?: Record<string, unknown>;
}
export declare class CommandParser {
    private options;
    private commands;
    private lazyCommandNames;
    private globalOptions;
    constructor(options?: ParserOptions);
    private initializeGlobalOptions;
    registerCommand(command: Command): void;
    /**
     * Register a lazy-loaded command's name so Pass 1/Pass 2 can recognize it as
     * a command position even though its full definition hasn't been loaded yet.
     * Fix for #1596: without this, lazy commands like `daemon start` were
     * mis-routed because Pass 1 walked past `daemon` and greedy-matched `start`.
     */
    registerLazyCommandName(name: string): void;
    /**
     * #1791.2 — true when `name` is a lazy command that hasn't been promoted
     * to a fully registered Command yet. The CLI uses this to eagerly load
     * the module before parsing so its subcommand flags (e.g. `-d` for
     * `hive-mind task --description`) are scoped into the alias map. Without
     * this, lazy commands' short flags silently fall through to global
     * resolution and the action handler sees an empty `flags.description`.
     */
    isLazyOnly(name: string): boolean;
    private isKnownCommandName;
    getCommand(name: string): Command | undefined;
    getAllCommands(): Command[];
    parse(args: string[]): ParseResult;
    private parseFlag;
    /**
     * Decide whether `arg` should be consumed as the VALUE of the preceding flag,
     * rather than treated as the next flag.
     *
     * Bug fix (audit #1, follow-up to #2222): a negative numeric value such as
     * `-1.0` starts with '-', so the old `!arg.startsWith('-')` test rejected it
     * as a value and parsed it as a (bogus) short flag. For `route feedback
     * -r -1.0` this silently dropped the value and coerced reward to `true` → 1.0,
     * so NEGATIVE feedback REINFORCED the agent. Only `--reward=-1.0` worked.
     *
     * Anything not starting with '-' is a value (unchanged). Anything that starts
     * with '-' is a value ONLY if it is a pure negative number (e.g. `-1`, `-1.0`,
     * `-3.14`, `-1e3`). Real flags like `-r`, `--reward`, `-abc` are never numeric
     * after the leading dash, so they are still correctly treated as flags.
     */
    private isFlagValue;
    /** True for the literal tokens `true`/`false` (case-insensitive). Used so a
     * boolean flag can take an explicit value in the space form, e.g.
     * `--explore false` / `-e true`. */
    private isBooleanLiteral;
    private parseValue;
    private normalizeKey;
    private buildAliases;
    /**
     * Build aliases scoped to a specific command/subcommand.
     * The resolved command's short flags take priority over global ones,
     * fixing collisions where multiple subcommands use the same short flag (e.g. -t).
     */
    private buildScopedAliases;
    /**
     * Get boolean flags scoped to a specific command/subcommand.
     *
     * `getBooleanFlags()` walks EVERY command + subcommand in the registry
     * and adds their boolean options into one flat set. That's convenient
     * for the common case but causes cross-subcommand pollution: if `swarm
     * start --parallel` is boolean AND `hooks route --parallel` is numeric,
     * the flat set marks `parallel` as boolean, and `hooks route --parallel 7`
     * drops the `7` as a positional (parseFlag treats booleanFlags-hit as
     * "consume no value"). This is the exact bug that forced the
     * --moa-parallel rename in the 2026-07-26 dream-cycle #2778 fix.
     *
     * Fix: if the resolved subcommand declares the flag as a non-boolean
     * type, REMOVE it from the boolean set. Narrowest scope wins.
     * (Documented via in-tree comment in commands/hooks.ts and the #2778
     * commit message.)
     */
    private getScopedBooleanFlags;
    private getBooleanFlags;
    private applyDefaults;
    validateFlags(flags: ParsedFlags, command?: Command): string[];
    getGlobalOptions(): CommandOption[];
}
export declare const commandParser: CommandParser;
//# sourceMappingURL=parser.d.ts.map