/**
 * Performance baseline scaffolding for the RD stage.
 *
 * peaks-code's RD stage runs before the QA stage. The user-facing pain is
 * that performance tests (lighthouse / k6 / project-local benches / etc.)
 * have historically only been run at QA Gate A4 — too late in the loop,
 * because a slow regression discovered at QA triggers a return-to-rd
 * cycle, the RD ships another "fix", QA re-runs, and the same cycle
 * repeats up to 3 times before the slice ships.
 *
 * `peaks perf baseline` is the user-visible artifact of a deliberate
 * compromise: keep the heavy performance measurement as something the
 * RD runs themselves (lighthouse is project-shape dependent and we
 * don't want to bake a lighthouse dependency into the CLI), but capture
 * the result in a stable, scaffolded file under
 * `.peaks/_runtime/<sid>/rd/perf-baseline.md` so QA Gate A4 has a known-good
 * reference to diff against. The CLI itself only writes the scaffold
 * and records the path; the actual measurement is a project-local
 * concern that lives in the README, not in peaks-loop.
 *
 * The four-grounds check (per the skill-primary-CLI-auxiliary dev
 * preference):
 *   1. hook/script/CI invokability  — yes, a hook can call this CLI
 *                                     to scaffold the file on session
 *                                     init, similar to session bootstrap.
 *   2. JSON envelope that gates a downstream decision — yes,
 *                                     peaks-rd reads the result and
 *                                     attaches it to the handoff.
 *   3. Destructive --apply side effect — yes, default dry-run.
 *   4. Machine-enforced gate that prose cannot enforce — no, the
 *                                     measurement still lives in
 *                                     the LLM / project tools. We do
 *                                     NOT add a lint gate here.
 *
 * Net: CLI is justified. The destructive --apply default is dry-run,
 * matching the rest of peaks-loop's scaffolding pattern.
 */
export type PerfBaselineInitOptions = {
    projectRoot: string;
    apply?: boolean;
    reason?: string;
};
export type PerfBaselinePlan = {
    apply: boolean;
    projectRoot: string;
    sessionId: string | null;
    perfBaselinePath: string | null;
    plannedWrites: Array<{
        path: string;
        kind: 'directory' | 'file';
        bytes: number;
        content: string;
    }>;
    alreadyInitialized: boolean;
    existingFiles: string[];
};
export type PerfBaselineResult = PerfBaselinePlan & {
    writtenFiles: string[];
    createdDirectories: string[];
    reason?: string;
};
export declare function executePerfBaselineInit(options: PerfBaselineInitOptions): Promise<PerfBaselineResult>;
/**
 * Re-exported so the CLI command can fall back to a project-root
 * resolution when the caller did not pass --project. The CLI does
 * the same findProjectRoot walk that `workspace init` does; this
 * helper exists for the command layer to import without reaching
 * into config-safety directly.
 */
export declare function resolveProjectRootFromCwd(cwd: string): string;