/**
 * dsh-edit-approval — host half.
 *
 * Two mirror-image approval features on the `tools/pre-execute` waterfall:
 *
 * 1. **edit approval** (`editEnabled`) — intercepts `write` / `edit` (and
 *    `str_replace_editor` when a deployment opts that tool in), reads the
 *    target file's current content, computes a line-level diff against the
 *    proposed content, and returns `{ kind: 'ask', reason }` when a human
 *    decision is needed (see `./guard.ts`).
 * 2. **bash approval** (`bashEnabled`) — intercepts command tools, asking for
 *    every command that is neither allow-listed nor a sandbox escalation (see
 *    `./bash-guard.ts`). fs-free by design.
 *
 * The harness's own `serviceAsk` routes every `ask` through `ctx.approval` —
 * the session policy (`ask`/`never`) keeps applying, and an `allowed-once`
 * proceeds while `rejected` denies the call. Every non-blocking case delegates
 * via `next()` so later policy listeners still run.
 *
 * **Settings (DSH 0.1.7).** The settings-namespace registry this plugin used to
 * register (`edit-approval` / `bash-approval`) is gone. Both features now read
 * ONE profile entry's `Config` — the bundle patch's row id, which equals the
 * package name — and the two master switches are the only `.volatile()` fields,
 * so they are the only ones the config page shows and the only ones a write may
 * address. Everything else stays ordinary config, edited in the profile file
 * exactly as before. `./config.ts` owns the adapter; the guards stay pure.
 *
 * @module dsh-edit-approval
 */
import type { Context } from '@deepseek-ai/cordis';
import z from '@deepseek-ai/schemastery';
import { type ApprovalConfig } from './config.ts';
export { DEFAULT_BASH_ALLOW, DEFAULT_BASH_TOOLS, DEFAULT_TOOLS } from './config.ts';
/** Stable Cordis plugin name. */
export declare const name = "dsh-edit-approval";
/**
 * Required services: the human command registry and the settings service the
 * config page and the two toggle commands write through. `tools` and `fs` are
 * awaited separately (see `apply`) so the commands and the config page still
 * work in a deployment without the file tools.
 */
export declare const inject: string[];
/**
 * Deployment configuration: the plugin entry's document.
 *
 * The two `*Enabled` switches are `.volatile()`; every other field is ordinary
 * config. See `./config.ts` for why that split is where it is.
 */
export interface Config extends ApprovalConfig {
}
/**
 * The `Config` schema the host resolves and projects as this entry's form.
 *
 * Deliberately NOT annotated `z<Config>`: a `.volatile()` field makes the
 * schema's INPUT side non-total, which that annotation's variance rejects (the
 * sister project omits it for the same reason). The pairing is pinned instead
 * by `tests/config.spec.ts`, which reads the schema's own serialized envelope
 * (`Config.toJSON()` — the same projection the settings wire uses) and asserts
 * its volatile field set equals the config page's field list.
 */
export declare const Config: z<Schemastery.ObjectS<NoInfer<{
    editEnabled: z<boolean, boolean, "volatile-defined">;
    bashEnabled: z<boolean, boolean, "volatile-defined">;
    editTools: z<string[], string[], "defined">;
    editMinDiffLines: z<number, number, "defined">;
    editIncludeCreate: z<boolean, boolean, "defined">;
    editIncludeDelete: z<boolean, boolean, "defined">;
    bashTools: z<string[], string[], "defined">;
    bashAllow: z<string[], string[], "defined">;
}>>, Schemastery.ObjectT<NoInfer<{
    editEnabled: z<boolean, boolean, "volatile-defined">;
    bashEnabled: z<boolean, boolean, "volatile-defined">;
    editTools: z<string[], string[], "defined">;
    editMinDiffLines: z<number, number, "defined">;
    editIncludeCreate: z<boolean, boolean, "defined">;
    editIncludeDelete: z<boolean, boolean, "defined">;
    bashTools: z<string[], string[], "defined">;
    bashAllow: z<string[], string[], "defined">;
}>>, "plain">;
/**
 * The profile entry id this plugin's configuration is addressed by: the bare
 * row id the bundle patch declares, which the config editor keys on
 * (`entry.options.id`). The fiber's own `entry.id` carries the loader's
 * ancestor prefix (`include:dsh-edit-approval`), so reading the local option is
 * both simpler and exactly the key the write path looks up.
 *
 * Read from the plugin's OWN fiber, never from an `ctx.inject` child: a child
 * fiber has no loader entry.
 *
 * @param ctx - the plugin context.
 * @returns the entry id, or undefined for an entry-less mount.
 */
export declare function approvalConfigKey(ctx: Context): string | undefined;
/**
 * Mount the host plugin: the config page policy, the two toggle commands, and
 * the `tools/pre-execute` interception dispatching to the edit or the bash
 * guard by tool name (edit wins on an overlap; defaults never overlap).
 *
 * @param ctx - plugin context.
 * @param config - the resolved entry configuration (live volatile references).
 */
export declare function apply(ctx: Context, config?: Config): void;