import{type TemplateResult,type PropertyValues}from'lit';import{LyraElement}from'../../../internal/lyra-element.js';import type{LyraTextWrap}from'../../../internal/shared-unions.js';import type{ApprovalAction}from'../approval-state.js';import'../../utility/json-viewer/json-viewer.class.js';import'../../forms/button/button.class.js';
/** Retained name for the shared native `<textarea wrap>` vocabulary. */
export type ToolApprovalDialogWrap=LyraTextWrap;
/**
* Reason the dialog was dismissed, forwarded as the `lr-close` event detail
* -- mirrors `<lr-dialog>`'s own `DialogCloseReason` shape. `'escape'`/
* `'backdrop'` come from the dialog's own built-in dismiss triggers,
* `'approve'`/`'deny'` from the built-in action buttons (fired in addition
* to, and immediately after, their own dedicated `lr-approve`/`lr-deny`
* event -- see the class doc), and any other string is whatever a caller
* passes to `close()` directly.
*/
export type ToolApprovalDialogCloseReason='escape'|'backdrop'|'approve'|'deny'|'api'|(string&Record<never,never>);
/**
* Which decision is awaiting host resolution, mirrors `ToolApprovalDialogCloseReason`'s own
* present-tense `'approve'`/`'deny'` vocabulary (not `<lr-confirm-bar>`'s unrelated past-tense
* `ConfirmBarDecision`).
*/
export type ToolApprovalDialogPending=ApprovalAction|null;export interface LyraToolApprovalDialogEventMap{'lr-approve':CustomEvent<{args:unknown;}>;'lr-deny':CustomEvent<null>;'lr-close':CustomEvent<ToolApprovalDialogCloseReason>;blur:CustomEvent<null>;focus:CustomEvent<null>;}
/**
* `<lr-tool-approval-dialog>` — a human-in-the-loop gate: presents one
* proposed tool/function call (`toolName` + `args`) and blocks an agent from
* executing it until a person explicitly approves or denies it, with an
* optional inline "edit the arguments before approving" step.
*
* This renders its own dialog panel rather than nesting a `<lr-dialog>` in
* its shadow template. Shared overlay infrastructure coordinates stacking,
* focus trapping, Escape dismissal, optional backdrop dismissal, and focus
* return with every other overlay in the same document.
*
* Approve/Deny/Edit are built-in chrome (not a `footer` slot a consumer must
* assemble) — this component's interaction shape is fixed enough (there is
* exactly one correct set of actions for "approve this call") that requiring
* every consumer to re-build it would just be boilerplate. A `footer` slot is
* still offered for *supplementary* content a consumer wants alongside those
* buttons (e.g. a "remember this choice for this tool" checkbox) — its
* content renders to the start of the action row, before Deny/Edit/Approve.
*
* Editing: while `editable`, an Edit button swaps the read-only
* `<lr-json-viewer>` for a plain `<textarea>` pre-filled with
* `JSON.stringify(args, null, 2)`. Every keystroke is re-validated with
* `JSON.parse` — the Approve button is `disabled` for as long as the current
* textarea content fails to parse, so a malformed edit can never be silently
* approved as either the broken text or a stale copy of the original args.
* The editor defaults to `spellcheck="false"`, `autocapitalize="off"`,
* `autocorrect="off"`, and `autocomplete="off"` because its content is raw
* JSON, never prose. The corresponding native editing properties remain
* configurable for integrations that need different browser behavior.
* The raw-JSON editor deliberately fixes native `resize` to `vertical`: a
* user can make a long draft taller without changing the dialog's constrained
* inline size. This focused approval flow exposes neither a generic `resize`
* surface nor auto-grow behavior; consumers that need either compose a
* dedicated editor around their approval UI.
* The same button relabels to "Cancel" while editing; clicking it discards
* the draft entirely and returns to the read-only view of the *original*
* `args` — there is no separate "save" step independent of Approve itself.
* Both `editing` and any in-progress draft reset back to the read-only view
* every time the dialog transitions from closed to open or its open proposal (`proposalKey`,
* `toolName`, or `args`) changes, so a reused instance never leaks one proposal's half-finished
* edit into the next.
* `editable` flipping to `false` mid-edit does the same (see `willUpdate()`)
* and, if the textarea it unmounts still held focus, `updated()` refocuses
* Deny so the focus trap keeps engaging instead of silently letting focus
* fall through to the document.
*
* Initial focus deliberately does *not* land on Approve:
* approving a tool call is a consequential, potentially irreversible action,
* so a user who opens this dialog and reflexively presses Enter/Space before
* reading anything should deny, not approve. Deny gets the initial focus
* instead — the same "focus the safe action" convention a native destructive-
* confirmation dialog (delete, discard, etc.) typically follows for its own
* Cancel button — rather than the inert dialog panel, which would need an
* extra Tab press before *any* action is reachable at all.
*
* Deny/Approve are `<lr-button>`s. Deny is `variant="neutral" appearance="outlined"`, Approve is
* `variant="brand"` at lr-button's default `appearance="accent"`, so the primary action is the loud
* one and the safe action recedes. Both appearances are stated rather than inherited: a dialog whose
* look depends on another component's default changes silently when that default does. Both are
* composed children rendered by this component (which offers no `variant` knob of its own, unlike
* `<lr-confirm-bar>`), each re-exporting `lr-button`'s own `base`/`label`/`start`/
* `end`/`spinner` parts under `{deny,approve}-button-{base,label,start,end,spinner}`. An
* `lr-approve`/`lr-deny` listener can call `preventDefault()` to keep the decision open while its
* own async work (e.g. a network call) is in flight: `pending` is set to `'approve'`/`'deny'`,
* showing `loading` on that button and `disabled` on the other (and, for Approve, alongside the
* existing invalid-JSON `disabled` gate), until the host finalizes by calling
* `close('approve'|'deny')` or bounces back by clearing `.pending` to `null`. A listener that
* instead resolves the decision itself synchronously (calling `close('approve'|'deny')` or setting
* `.pending` directly before returning from the `preventDefault()`ed handler) wins outright:
* `onApprove`/`onDeny` only fall back to their own `pending` bookkeeping when the listener left both
* `pending` and `open` untouched. While `pending` is
* set, Escape and an enabled backdrop dismissal are suppressed -- a decision in flight should not
* be abandonable out from under the host mid-request -- and `pending` itself resets to `null` every
* time the dialog transitions from closed to open, mirroring `editing`'s own reset-on-reopen
* contract.
*
* @customElement lr-tool-approval-dialog
* @slot footer - Optional supplementary content (e.g. a "remember this
* choice" checkbox), rendered before the built-in Deny/Edit/Approve buttons.
* @event lr-approve - The call was approved. `detail: { args }` — the
* current, already-parsed arguments object: the original `args` prop, or (if
* an edit was in progress) the user's edited-and-validated version. Cancelable: a listener
* calling `preventDefault()` sets `pending` to `'approve'` instead of closing. Otherwise always
* followed by `lr-close` with reason `'approve'`.
* @event lr-deny - The call was denied (no detail). Cancelable, same `pending` mechanism as
* `lr-approve` (`pending` is set to `'deny'`). Otherwise always followed by `lr-close` with
* reason `'deny'`.
* @event lr-close - `detail: ToolApprovalDialogCloseReason`. Fired exactly
* once per dismissal — via Escape, an opted-in backdrop click, the Approve/Deny
* buttons, or a `close()` call — so there is one consistent "this dialog is
* now closed" signal regardless of which path triggered it.
* @event focus - Re-dispatched when the raw-JSON editor receives focus.
* @event blur - Re-dispatched when the raw-JSON editor loses focus.
* @csspart backdrop - The full-viewport scrim behind the panel.
* @csspart panel - The dialog panel itself (`role="dialog"` while open).
* @csspart header - The wrapper around the heading.
* @csspart tool-name - The `toolName` text within the heading.
* @csspart body - The wrapper around the args view/editor.
* @csspart args-view - The read-only `<lr-json-viewer>` shown while not editing.
* @csspart args-editor - The raw-JSON `<textarea>` shown while editing.
* @csspart error - The inline "invalid JSON" message, shown only while editing with unparseable content.
* @csspart footer - The action row wrapping the `footer` slot and the built-in buttons.
* @csspart deny-button - The built-in Deny `<lr-button>`.
* @csspart deny-button-base - Forwarded from the internal Deny `<lr-button>`'s same-node `base`
* and `button` wrapper aliases.
* @csspart deny-button-label - Forwarded from the internal Deny `<lr-button>`'s own `label` part.
* @csspart deny-button-start - Forwarded from the internal Deny `<lr-button>`'s own `start` part.
* @csspart deny-button-end - Forwarded from the internal Deny `<lr-button>`'s own `end` part.
* @csspart deny-button-spinner - Forwarded from the internal Deny `<lr-button>`'s own `spinner`
* part, present only while `pending` is `'deny'`.
* @csspart edit-button - The built-in Edit/Cancel toggle button (only rendered while `editable`).
* @csspart approve-button - The built-in Approve `<lr-button>` — `disabled` while an in-progress edit is invalid JSON (or while Deny is pending).
* @csspart approve-button-base - Forwarded from the internal Approve `<lr-button>`'s same-node
* `base` and `button` wrapper aliases.
* @csspart approve-button-label - Forwarded from the internal Approve `<lr-button>`'s own `label` part.
* @csspart approve-button-start - Forwarded from the internal Approve `<lr-button>`'s own `start` part.
* @csspart approve-button-end - Forwarded from the internal Approve `<lr-button>`'s own `end` part.
* @csspart approve-button-spinner - Forwarded from the internal Approve `<lr-button>`'s own
* `spinner` part, present only while `pending` is `'approve'`.
* @cssprop [--lr-tool-approval-dialog-overlay-color=var(--lr-color-overlay)] - Backdrop scrim color.
* @cssprop [--lr-tool-approval-dialog-mono-font=var(--lr-font-mono)] - Font family for the tool name and the raw-JSON args editor.
* @cssprop [--lr-tool-approval-dialog-invalid-border-color=var(--lr-color-danger)] - Border color of an invalid raw-JSON editor.
* @cssprop [--lr-tool-approval-dialog-hover-border-color=var(--lr-color-brand)] - Border color of a valid, editable raw-JSON args editor on hover. Invalid and pending states retain their semantic chrome.
* @status stable
* @since 4.0.0
*/
export declare class LyraToolApprovalDialog extends LyraElement<LyraToolApprovalDialogEventMap>{static styles:import("lit").CSSResultGroup[];private _open;private _pending;
/** Marked on every write to `open`/`pending`, from any source. `onApprove`/`onDeny` open it
*  immediately before dispatching `lr-approve`/`lr-deny` and read it back afterward: since the
*  dispatch is synchronous, only a listener invoked during that same `emit()` call can have
*  marked it in between. */
private readonly dispatchWriteGuard;
/** Whether the dialog is open. Set this directly or use `show()`/`hide()`/`close()`. */
get open():boolean;set open(value:boolean);
/** Dismisses the dialog on a backdrop click. Opt-in and `false` by default, matching
*  `<lr-dialog>`, `<lr-drawer>`, `<lr-lightbox>`, and the sibling tool dialogs. */
lightDismiss:boolean;
/** Stable identity/generation for the proposal. Changing it while open resets draft and pending
*  state even when the replacement proposal happens to reuse the same visible name/arguments. */
proposalKey:string;
/** The proposed tool/function's name, e.g. `web_search`. Drives the heading and the dialog's accessible name. */
toolName:string;
/** Accessible name for the component. When assigned directly as a property without a host
*  attribute it names the dialog panel; a host `aria-label` remains on the host and the panel
*  stays labelled by its visible heading to avoid cloning the same owner. */
accessibleLabel:string|null;
/** The proposed call's arguments — any JSON-serializable value, rendered via `<lr-json-viewer>` (or, while editing, stringified into the textarea). */
args:unknown;
/** Whether an "Edit" affordance is offered at all. When `false`, `args` is always shown read-only and can never be changed before approval. */
editable:boolean;
/** Which decision is awaiting host resolution, while an lr-approve/lr-deny listener has called
*  preventDefault(). Host-writable: set back to null to bounce back to the undecided state (e.g.
*  on failure, so the user can retry), or call `close('approve'|'deny')` to finalize. Also reset
*  to `null` every time the dialog transitions from closed to open, mirroring
*  `editing`/`draftText`/`draftError`'s own reset-on-reopen contract below, so a reused instance
*  never leaks one proposal's stuck pending state into the next. While non-null, Escape and an
*  enabled backdrop dismissal are suppressed (see `activateOverlay()`). */
get pending():ToolApprovalDialogPending;set pending(value:ToolApprovalDialogPending);
/** Native editing-assistance attributes forwarded to the raw-JSON textarea. */
spellcheck:boolean;autocapitalize:string;autoCorrect:string;autocomplete:string;wrap:ToolApprovalDialogWrap;inputMode:string;enterKeyHint:string;private editing;
/** The textarea's current raw text while editing — deliberately independent of `args` until Approve is pressed, so a malformed in-progress edit never overwrites it. */
private draftText;
/** `JSON.parse` failure message for `draftText`, or `''` while it parses cleanly. Empty string (not `undefined`) so it can drive `?hidden` directly. */
private draftError;private overlay?;private errorAnnouncementSink?;private suppressNextErrorAnnouncement;private readonly titleId;private readonly errorId;private resetProposalState;protected willUpdate(changed:PropertyValues):void;protected updated(changed:PropertyValues):void;connectedCallback():void;disconnectedCallback():void;private activateOverlay;
/**
* Close the dialog and return focus to whatever had it before the dialog
* opened. `reason` is forwarded as the `lr-close` detail — built-in
* triggers pass `'escape'`/`'backdrop'`/`'approve'`/`'deny'` (`'backdrop'` only while
* `lightDismiss` is enabled); a consumer's
* own close affordance (e.g. a footer-slotted button) should call this
* directly with its own reason string, so every dismissal path funnels
* through the same event instead of the consumer having to also toggle
* `open` itself.
*/
close(reason?:ToolApprovalDialogCloseReason):void;
/** Opens the dialog. No-op when already open. */
show():void;
/** Closes the dialog through the same reasoned lifecycle as `close()`. */
hide(reason?:ToolApprovalDialogCloseReason):void;private onBackdropClick;private stringifyArgs;private toggleEdit;private onDraftInput;private onEditorFocus;private onEditorBlur;private onApprove;private onDeny;render():TemplateResult;}declare global{interface HTMLElementTagNameMap{'lr-tool-approval-dialog':LyraToolApprovalDialog;}}