/**
 *
 * Holds the fixed-order, code-driven list of `DoctorCheckPlugin`
 * instances that `runDoctor` iterates. The order is the same as the
 * legacy monolithic function body — preserving the on-disk check
 * ordering keeps the existing `report.checks` array unchanged for
 * every consumer (CLI summary, JSON output, schema self-check).
 *
 * Why code-driven (not data-driven):
 *   - Each check has distinct typed inputs (skills, presence, layout
 *     probe, gateguard probe, …) and conditional logic that a config
 *     table cannot express without losing type safety.
 *   - The check ordering is load-bearing — `skill-presence:workspace`
 *     depends on `presence` being probed, `doctor-self:check-id-pattern`
 *     depends on every prior check's IDs, and `L3:l3-orphan-sessions` /
 *     `L3:l3-memory-health` run last so they observe a clean post-F3
 *     layout. A config-driven registry would obscure that ordering
 *     and force callers to read two files to understand execution
 *     flow. Code-driven keeps it auditable in one place.
 *   - Adding a check is a code change in any case (the typed probe
 *     surface has to grow). A code-driven registry makes the diff
 *     self-contained.
 *
 * Adding a new check:
 *   1. Create `checks/<your-check>.ts` exporting
 *      `export const check: DoctorCheckPlugin`.
 *   2. Append `check` to the `PLUGINS` array below IN THE EXACT
 *      POSITION THE LEGACY MONOLITHIC FUNCTION EMITS IT.
 *   3. If you need new context state, extend `DoctorContext` in
 *      `types.ts` and populate it in `index.ts`.
 */
import type { DoctorCheckPlugin } from './types.js';
/**
 * Ordered list of doctor check plugins. The order mirrors the legacy
 * monolithic `runDoctor` function body verbatim — DO NOT REORDER
 * without first re-reading the consumer-side tests in
 * and updating the expected check-id list.
 */
export declare const PLUGINS: ReadonlyArray<DoctorCheckPlugin>;