/**
 * Dashboard-scoped wizard endpoints. These are the read/run surface the
 * `/_dashboard` SPA consumes when an operator clicks "Add adapter" or
 * "Add provider" — they mirror the older `/api/wizards/*` routes but live
 * under `/api/dashboard/*` so they sit behind `requireDashboardAuth`
 * (admin scope) instead of the broader API auth.
 *
 * Surface:
 *   GET  /api/dashboard/wizard/list?category=adapter|provider|memory|webhook
 *        → { modules: Array<{ id, kind, name, description?, version? }> }
 *   GET  /api/dashboard/wizard/spec/:moduleKind/:moduleId
 *        → full WizardModule spec (steps[], secrets[], etc.) — configSchema
 *          stripped because Zod isn't JSON-serializable and the dashboard
 *          doesn't need it (validation happens server-side in `run`).
 *   POST /api/dashboard/wizard/run  body: { moduleKind, moduleId, answers }
 *        → { ok: true, filesWritten, reloaded } on success
 *          { ok: false, errors: { [stepKey]: message } } on validation failure
 *
 * All admin-gated. CSRF on POST enforced by `requireDashboardAuth`.
 *
 * Why a parallel surface to `/api/wizards`?
 *   - The legacy `/api/wizards` is hit by the pyre-web embed via a
 *     gateway secret. The dashboard runs as a first-class browser app
 *     and needs cookie/bearer scoping with admin-only mutation. Putting
 *     it under the dashboard namespace keeps the gate consistent across
 *     every page the SPA loads.
 *   - The dashboard's request body uses a flat `{ answers }` shape that
 *     matches the wizard renderer's react-hook-form state, instead of
 *     the split `{ config, secrets }` the gateway path uses. The split
 *     happens server-side here from the wizard's declared secret list.
 */
import type { IncomingMessage, ServerResponse } from "node:http";
import type { RouteContext } from "../route-context.js";
export declare function handle(req: IncomingMessage, res: ServerResponse, ctx: RouteContext): Promise<boolean>;
//# sourceMappingURL=dashboard-wizard.d.ts.map