/**
 * Job-grouped `openlore --help` (change: refine-happy-path-and-defaults /
 * CommandSurfaceGroupedByJob).
 *
 * OpenLore has ~49 top-level commands. Commander's default help lists them in one
 * flat block, so `install` and `orient` sit beside the experimental `panic-*`
 * suite and `gryph-watch` with no altitude marker — a new user can't tell the
 * front door from the basement. This module groups the Commands section of the
 * top-level help by JOB (set up · navigate · govern a change · inspect · multi-repo
 * · advanced/experimental), mirroring the capability families.
 *
 * It only changes PRESENTATION. Every command stays invocable, and any command not
 * yet categorized falls through to an "Other" group, so a newly-added command is
 * never hidden — it just shows ungrouped until it is placed.
 *
 * Grouping is delegated to Commander's own `.helpGroup()` support (added in
 * Commander 14): each subcommand is tagged with its job heading and Commander renders
 * the groups. We previously hand-reproduced Commander 12's `formatHelp` to do this,
 * which broke on upgrade when `Help.wrap()` was removed. Tagging instead of
 * reproducing means every other part of help rendering — wrapping, padding, styling,
 * usage, options — stays Commander's, so it cannot drift again.
 *
 * The one thing Commander does not decide for us is group ORDER: it emits groups in
 * the order subcommands were registered. `orderCommandGroups` reorders them into the
 * job order declared below.
 */
import { Help, type Command, type Option } from 'commander';
/** Job groups, in display order. Each lists the command names it contains. */
export declare const COMMAND_GROUPS: ReadonlyArray<{
    title: string;
    commands: readonly string[];
}>;
/** Resolve which group a command name belongs to, or the Other group. */
export declare function groupForCommand(name: string): string;
/**
 * Commander renders a group heading verbatim, so match its built-in section style
 * ("Commands:", "Options:") and give every job group a trailing colon.
 */
export declare function groupHeading(title: string): string;
/**
 * A Commander `groupItems` override that emits our job groups — and the commands
 * inside them — in declared order rather than in subcommand-registration order.
 *
 * Member order matters as much as group order: `install` is the front door and is
 * declared first in "Set up & run" for that reason, but it is registered late in
 * `index.ts`. A command not named in the group (the "Other" catch-all) keeps its
 * registration order, after any named ones.
 *
 * Headings we do not own (Commander's own "Options:", or any option group) keep their
 * original position and member order, so this only touches the Commands section.
 */
export declare function orderCommandGroups<T extends Command | Option>(this: Help, unsortedItems: T[], visibleItems: T[], getGroup: (item: T) => string): Map<string, T[]>;
/**
 * Tag every registered subcommand with its job group and install the ordering
 * override. Call once, AFTER all subcommands have been added to `program`.
 */
export declare function applyJobGroupedHelp(program: Command): void;
//# sourceMappingURL=help-groups.d.ts.map