/**
 * fitnessTool — fitness as a Tool plugin.
 *
 * Owns the `fit` primary plus its nested `fit list`, `fit recipes`, and
 * `fit export` subcommands. Since release 2.11.0 (Phase 4) the Commander wiring is no longer
 * hand-rolled: the tool exports declarative {@link CommandSpec}s
 * (`commandSpecs`) and the host's `mountCommandSpec` mounts them
 * (name/description/aliases, the ADR-0021 common flags, each command's options)
 * and owns the parse→handler→error→exit pipeline. This file owns only the
 * fitness command-spec assembly + the live-view renderer wiring; the spec
 * modules under `cli/fit/` own the option declarations and handler bodies. (The
 * standalone `report` subcommand is owned by the CLI, which composes it from
 * every tool's contributed data — see
 * packages/cli/src/commands/host-command-specs.ts — and migrates with the host
 * commands in Phase 6.)
 *
 * Two-key registration invariant
 * ------------------------------
 * Fitness contributes TWO distinct identifiers to the CLI's registries
 * and the mismatch is intentional — do not collapse them:
 *
 *   - `metadata.id = 'fitness'` is the package-wide tool identifier
 *     (conflict-detection key in the CLI-managed tool registry).
 *
 *   - `FIT_LIVE_VIEW_KEY = 'fit'` is the live-view key. Used to call
 *     `cli.registerLiveView('fit', renderer)` and consumed by
 *     `cli.renderLive('fit', args)` in `runLiveMode`. The key matches
 *     the `fit` subcommand name so the dispatcher's `renderLive(key)`
 *     reads naturally next to the command that triggers it.
 *
 * Layer 5 Phase 3 (closes audit 2026-05-23 F3): fitness now ships its
 * own Ink/React renderer (`renderFitLive` in `cli/fit-runner.tsx`)
 * and registers it directly via `cli.registerLiveView`. The prior
 * `cli.builtinLiveViews` self-lookup handshake is gone.
 *
 * In the spec-mounted world there is no `register()` mount hook, so the live-view
 * renderer is registered lazily on the host context (via {@link setUpFitLiveView})
 * the first time a live `fit` run needs it. `registerLiveView` is an idempotent
 * map write, so doing this once per run — only on the interactive path that needs
 * it — is equivalent to the old mount-time registration.
 *
 * Module layout
 * -------------
 * - This file owns the command-spec assembly + the tool descriptor.
 * - `cli/fit/fit-command-spec.ts` owns the primary `fit` command spec + handler.
 * - `cli/fit/fit-aux-command-specs.ts` owns the nested `fit list` / `fit recipes`
 *   / `fit export` command specs.
 * - `cli/fit-modes.ts` owns the dispatch branches (gate/list/recipes/json/live).
 */
import './scope-augmentation.js';
import type { Tool } from '@opensip-cli/core';
/**
 * Per-tool contract version for the fitness-specific surface
 * (defineCheck, analysis modes, check packs, recipes, etc.).
 * Independent of the core TOOL_CONTRACT_VERSION (the generic Tool bus).
 * Bumped only on actual changes to this surface; value = major.minor of the
 * CLI release shipping the change (see ADR-0047).
 */
export declare const FITNESS_CONTRACT_VERSION = "1.0.0";
export declare const FITNESS_STABLE_ID = "afd68bd3-ff3c-4935-a5b6-76d8fc7a5224";
export declare const fitnessTool: Tool;
//# sourceMappingURL=tool.d.ts.map