@jini-ai/daemon 0.5.3 → 0.6.0

package/dist/tool-recovery/diagnostics.js

@@ -0,0 +1,110 @@
+/**
+ * @file The general tool-failure contract (2026-09-01): what ANY tool attaches to a failed outcome
+ * so a caller — human, agent, or an automated retry loop — has something to reason about instead of a
+ * bare status code with nothing behind it.
+ *
+ * ## Why this exists
+ *
+ * Hand-writing a bespoke recovery path per failure mode does not scale — there will always be more
+ * flaws, gaps, and provider quirks than anyone can anticipate and special-case individually. The
+ * leverage is not a smarter model reading a smarter error message; it is a SHARED SHAPE every tool's
+ * failure can be poured into, so one generic loop — read the failure, ask the human through a
+ * surface, apply the answer, retry once — can handle a failure mode nobody wrote code for, using the
+ * identical mechanism that already handles one somebody did.
+ *
+ * ## The four things a diagnostic carries
+ *
+ * 1. **What failed.** Deliberately NOT modeled in this shared contract — it is always domain-specific,
+ *    and forcing every failure mode into one generic "what failed" string or object would either
+ *    flatten real structure that needs to stay queryable (a concrete diagnostic's own fact fields —
+ *    see {@link AuthFailureDiagnostic}'s `schemeSent`/`usernameStored` in `features/custom-credentials/
+ *    credentialed-request.ts` for the worked example) or force a restructuring this file has no
+ *    business demanding of every domain that wants to adopt it. A concrete diagnostic type carries
+ *    its own facts as its own additional fields, declared alongside the two this contract does own.
+ * 2. **The best hypothesis why** — folded into {@link ToolFailureDiagnostic.hint}.
+ * 3. **What input or state would change the outcome** — also folded into `hint`, not a separate field;
+ *    see that property's own doc for why the two live together.
+ * 4. **Whether a registered tool can supply it** — {@link ToolFailureDiagnostic.remedyToolId}.
+ *
+ * ## Built from one worked example, not designed from zero
+ *
+ * `AuthFailureDiagnostic` is this contract's first instance, extracted AFTER it shipped and proved
+ * itself against a real incident — not designed up front from a guess at what failures might someday
+ * look like. See that type's own file header, "Authentication-failure diagnostics", for the incident
+ * and for the exact honesty contract every one of its fields is held to. This file generalizes its
+ * SHAPE, not its content: the fields that type adds (`schemeSent`, `usernameStored`) and the exact
+ * wording of its `hint` are unchanged by this extraction.
+ *
+ * ## The honesty contract every field is held to
+ *
+ * - **Silence is the default, not an afterthought.** Both fields below are optional, and absent
+ *   together far more often than present: a diagnostic type should fill them in for the ONE narrow
+ *   shape it can honestly speak to, and stay silent for every other shape — including shapes that
+ *   look superficially similar. Repeating advice that has already been tried and failed, or guessing
+ *   at a cause this diagnostic cannot actually tell apart from some other one, is a false lead, not
+ *   merely an unhelpful one.
+ * - **Never a claim.** `hint`, when present, is hedged ("may"/"might"/"could") — a hypothesis for a
+ *   human or agent to try, never an assertion of the real cause.
+ * - **Additive, never a replacement.** A diagnostic rides ALONGSIDE the tool's own real failure output
+ *   (a provider's response body, a thrown error's message) — it never suppresses or reinterprets it.
+ * - **`hint` and `remedyToolId` travel as a pair, never `remedyToolId` alone.** A tool id with nothing
+ *   explaining why it might help is a suggestion with no argument behind it, not a diagnostic. The
+ *   reverse is fine: `hint` with no `remedyToolId` simply means no registered tool can supply the fix
+ *   yet — the hypothesis is still worth surfacing to a human who can act on it by hand.
+ *
+ * ## The one-cycle guard
+ *
+ * `remedyToolId` is a POINTER — a tool id, nothing else. It carries no callback, no arguments, and no
+ * instruction to invoke it automatically. That is deliberate: the consuming loop (ask the human → apply
+ * the answer through the named tool → retry ONCE) owns the decision of whether and how to act on it,
+ * and owns the guard against a second cycle. A diagnostic that carried more than an id — an executable
+ * action, say — would let that guard slip into this file instead of staying where the actual retry
+ * happens, turning a bug in this contract into a genuine loop instead of a single bounded retry.
+ *
+ * ## Architectural role
+ *
+ * `contracts/core`, domain-agnostic — it names no post, page, credential, or other domain concept, so
+ * a failure mode in any feature can adopt it without this file growing a dependency on that feature.
+ */
+/**
+ * Every diagnostic a tool has issued, by identity. Membership is the proof that a `{hint,
+ * remedyToolId}` object came from tool code reporting a failure, not from data the tool merely
+ * returned: stored content (a post's `bodyJson`, a widget's props) is plain JSON and can carry the
+ * same two fields, and the recovery loop turns them into a dialog that runs `remedyToolId`. A parsed
+ * or stored object can never be a member. Weak, so an issued diagnostic is collected with its result.
+ */
+const issuedDiagnostics = new WeakSet();
+/**
+ * Marks `diagnostic` as issued by the calling tool for a real failure, so the recovery loop
+ * (`assistant/tool-failure-recovery.ts`) may act on it. Returns the same object. Call it where the
+ * diagnostic is built, and return that object itself: a copy (spread, JSON round trip) is not issued.
+ *
+ * @complexity O(1).
+ */
+export function issueToolFailureDiagnostic({ diagnostic }, _optional = {}) {
+    issuedDiagnostics.add(diagnostic);
+    return diagnostic;
+}
+/**
+ * True only for an object {@link issueToolFailureDiagnostic} marked.
+ *
+ * @complexity O(1).
+ */
+export function isIssuedToolFailureDiagnostic({ value }, _optional = {}) {
+    return typeof value === "object" && value !== null && issuedDiagnostics.has(value);
+}
+/** Only card metadata travels through recovery; secret values belong to the parked card. */
+export function issueCredentialSetup(required, _optional = {}) {
+    for (const [key, value] of Object.entries(required.prefill)) {
+        if (/token|secret|password|authorization|env|headers|body|key/i.test(key))
+            throw new Error("Credential setup accepts only non-secret metadata.");
+        if (typeof value === "string") {
+            required.assertCredentialFreeField({ value, field: key }, {});
+            if (required.containsSecret({ text: value }))
+                throw new Error("Credential setup accepts only non-secret metadata.");
+        }
+    }
+    return issueToolFailureDiagnostic({ diagnostic: { setupToolId: required.setupToolId, prefill: required.prefill, remedyToolId: required.setupToolId,
+            hint: "A missing or rejected credential may be fixed by saving it through the secure card." } }, {});
+}
+//# sourceMappingURL=diagnostics.js.map

package/dist/tool-recovery/federated-refusal.d.ts

@@ -0,0 +1,92 @@
+import type { ToolExecutor } from "../tool-executor.js";
+export interface FederatedRefusalDiagnosisDeps {
+    readonly inner: ToolExecutor;
+    readonly isFederatedTool: (required: {
+        toolId: string;
+    }) => boolean;
+    readonly parseConnectionId: (required: {
+        toolId: string;
+    }) => string | null;
+    readonly findRefusal: (required: {
+        toolId: string;
+    }) => {
+        remoteName: string;
+        connectionId: string;
+        explanation: string;
+    } | null;
+    readonly newExecutionId: () => string;
+    readonly redactSecretShapes: (required: {
+        text: string;
+    }) => {
+        text: string;
+    };
+    readonly getBootStatus?: () => FederationBootStatus;
+}
+/**
+ * The federation boot pass's own live state, for the "still connecting" case below — deliberately
+ * NOT `FederationRuntime` itself (`external-mcp-federation-runtime.ts`): that type carries a whole
+ * runtime's worth of methods (`start`, `reload`, …) this decorator has no business calling, and
+ * importing it here would pull a composition-layer type into what is otherwise a pure reduction
+ * over data, same posture as `refusal-notice.ts`'s own `FederationAdmissionSnapshotEntry`. A caller
+ * builds this from its own `FederationRuntime` with `{ settled: federation.started, connectFailures:
+ * federation.connectFailures() }` — see `byok-tool-surface.ts`'s call site.
+ */
+export interface FederationBootStatus {
+    /** Whether the boot pass (every configured connection, attempted once, in order) has finished.
+     *  `false` for the window between "the surface started federation" and "every connection has
+     *  either admitted or failed" — the exact gap `npx` startup (6-13s) can outlast this decorator's
+     *  caller's own bounded wait (`assistant-byok.ts`'s `FEDERATION_TURN_WAIT_MS`, 5s). */
+    readonly settled: boolean;
+    /** `AttachFederatedToolsResult.connectFailures`, verbatim — a connectionId that reached `attach`
+     *  but never admission at all, with its human-readable reason. */
+    readonly connectFailures: readonly {
+        readonly connectionId: string;
+        readonly reason: string;
+    }[];
+    /**
+     * The boot roster's connection ids (2026-09-25), known as soon as the runtime's own
+     * `resolveConnections()` call resolves — see `external-mcp-federation-runtime.ts`'s
+     * `configuredConnectionIds()`. `undefined` means the roster itself is not known yet (the earliest
+     * sliver of boot, before that call has even resolved); an omitted/`undefined` value is treated as
+     * "cannot rule anything out yet", never as "nothing is configured" — those are different claims,
+     * and only a present array can positively prove a connectionId was never configured at all. Without
+     * this field, `!status.settled` alone told a caller naming ANY federated-shaped id, including one
+     * that was never in the roster, "still connecting" for as long as boot took.
+     */
+    readonly configuredConnectionIds?: readonly string[];
+}
+/**
+ * Wraps `inner` so a call naming a federated tool id THIS BOOT REFUSED fails with a message naming
+ * the tool, the server, and the fix, instead of the bare `unknown tool` throw escaping all the way to
+ * `@jini-ai/http-kit`'s SEC-005 redaction.
+ *
+ * @param getSnapshot - Reads the CURRENT admission snapshot lazily, not a value closed over once —
+ *   this decorator is composed in `agent-daemon-server.ts` before `attachFederatedMcpTools` resolves
+ *   (mirroring that file's own `federationRefusalPrefix` `let` binding for the identical reason), so
+ *   a plain array parameter captured at construction time would forever see the empty pre-boot
+ *   snapshot. Pass `() => federationAdmissionReports` (a closure over the module-scope binding), not
+ *   `() => someArrayCapturedNow`.
+ * @param getBootStatus - Optional (2026-09-24). When given, an unknown-tool throw for a federated id
+ *   this boot's snapshot does NOT (yet) refuse is diagnosed one step further before falling back to
+ *   the original throw: while `!settled`, the connection is presumed still connecting (`npx`
+ *   startup, 6-13s, can outlast a caller's own bounded wait — see `assistant-byok.ts`'s
+ *   `FEDERATION_TURN_WAIT_MS`) and the call gets a clear "still connecting" message instead of the
+ *   raw `ToolExecutor: unknown tool` throw a model cannot act on. Once `settled`, a connectionId
+ *   present in `connectFailures` gets that failure's own reason instead. Omitted (the daemon's own
+ *   call site, where a turn never runs until `federation.start()` has fully resolved — see
+ *   `agent-daemon-server.ts`'s `start()`), this decorator's behavior is byte-identical to before this
+ *   parameter existed: every one of this file's own pre-2026-09-24 tests passes an unchanged 2-arg
+ *   call and must keep throwing for a federated-shaped id this boot never refused.
+ * @returns A drop-in `ToolExecutor`. Every call that is not BOTH (a) an unknown-tool throw AND (b) a
+ *   federated id this boot's snapshot actually refused passes through with byte-identical behavior —
+ *   completed results, every other status, and the throw itself for a genuinely unknown or
+ *   native-typo id — so `resumeConfirmation`/`cancel`/`getAuditRecord` delegate straight through with
+ *   no wrapping at all.
+ * @complexity One extra `instanceof`/regex test and one string-prefix test per call that reaches
+ *   `catch` — already the unhappy path; {@link findFederatedToolRefusal}'s own O(connections ×
+ *   refusals) cost only when both tests pass, and `getBootStatus`'s own O(connectFailures) lookup
+ *   only when they pass AND no refusal was found.
+ * @overallScore 100
+ */
+export declare function withFederatedRefusalDiagnosis({ inner, ...deps }: FederatedRefusalDiagnosisDeps, _optional?: {}): ToolExecutor;
+//# sourceMappingURL=federated-refusal.d.ts.map

package/dist/tool-recovery/federated-refusal.js

@@ -0,0 +1,152 @@
+// Local federation forks moved to @jini-ai/mcp/federation (+ /stdio, /approvals); see development/DELETED-CODE.md.
+/**
+ * `ToolExecutor.execute`'s own contract for an unregistered id (`@jini-ai/daemon`'s
+ * `tool-executor.ts`): a thrown `Error` reading `unknown tool "<id>"`, with no code or subclass to
+ * match on instead. Duplicated from `tool-executor-audit.ts`'s identical `isUnknownToolError` rather
+ * than imported: that file is a sibling one layer up with no dependency on `mcp-federation`, and
+ * importing across that line for an 18-character regex is not worth the coupling. Both copies carry
+ * the same MEDIUM message-text-coupling note that file's own doc records — if `@jini-ai/daemon`
+ * rewords this message, this decorator silently stops matching and every call it would have
+ * diagnosed falls back to today's opaque redaction, never a worse or incorrect outcome.
+ *
+ * @complexity O(n) in the message length.
+ * @overallScore 90
+ */
+function isUnknownToolError(error) {
+    return error instanceof Error && /unknown tool/i.test(error.message);
+}
+/**
+ * The "still connecting" / "failed to connect" diagnosis (2026-09-24) — reached only for a federated
+ * id that {@link findFederatedToolRefusal} could NOT explain, i.e. one whose connection has no
+ * admission report at all yet (never refused because it was never even admitted).
+ *
+ * Two distinct outcomes, both reached only via `status.connectFailures`/`!status.settled` and never
+ * both — `attachFederatedMcpTools`'s per-connection loop is sequential and produces at most one of
+ * "still running" or "failed" for a given connectionId at any moment this decorator could observe it:
+ *
+ * - `!status.settled`: the boot pass has not finished walking every configured connection, so THIS
+ *   connectionId is presumed still connecting (npx startup, 6-13s, routinely outlasts a caller's own
+ *   bounded wait) — UNLESS `status.configuredConnectionIds` is already known and does not contain it,
+ *   in which case it was never configured at all and the original throw stands (2026-09-25; before
+ *   this check, a hallucinated/stale id got "still connecting" for as long as boot took, same as a
+ *   real pending one). A model naming an id that IS in the roster has, by doing so, already decided it
+ *   wants it — telling it to retry is strictly better than the opaque `unknown tool` throw it would
+ *   get instead, even in the rare case this particular connection actually already failed while a
+ *   LATER one in the loop is still connecting; the very next call after boot settles gets the precise
+ *   failure reason below instead.
+ * - `status.settled` and this connectionId is in `connectFailures`: the boot pass finished and this
+ *   connection genuinely never admitted — its own human-readable reason (`bootstrap.ts`'s
+ *   `messageOf(error)`, already proven secret-free by that field's own doc) is relayed verbatim.
+ *
+ * `status` is `undefined` for a caller that never passed `getBootStatus` at all (the daemon's own
+ * call site) or for a toolId that is not federated-shaped — both return `null` immediately, letting
+ * the original `unknown tool` throw stand exactly as it did before this diagnosis existed.
+ *
+ * @complexity O(1) for the connecting case; O(connectFailures) for the settled case.
+ * @overallScore 100
+ */
+function diagnoseStillConnectingOrFailed(toolId, status, deps) {
+    if (!status)
+        return null;
+    const connectionId = deps.parseConnectionId({ toolId });
+    if (connectionId === null)
+        return null;
+    if (!status.settled) {
+        // Only a positively-known roster can rule `connectionId` OUT; `undefined` (roster not resolved
+        // yet) keeps the pre-2026-09-25 behavior of presuming still-connecting rather than guessing wrong
+        // in either direction.
+        if (status.configuredConnectionIds && !status.configuredConnectionIds.includes(connectionId))
+            return null;
+        return failedResult(`External MCP server '${connectionId}' is still connecting — try again in a moment.`, deps);
+    }
+    const failure = status.connectFailures.find((entry) => entry.connectionId === connectionId);
+    if (!failure)
+        return null;
+    // `reason` is already proven secret-free by `AttachFederatedToolsResult.connectFailures`'s own
+    // doc, but redacted anyway for the same defense-in-depth reason the refusal branch below redacts
+    // an operator-authored/fixed-prose string that "never matches a redaction rule" today — a
+    // guarantee this file has no way to keep verifying stays true upstream.
+    return failedResult(deps.redactSecretShapes({ text: `External MCP server '${connectionId}' failed to connect: ${failure.reason}` }).text, deps);
+}
+/** One `status: 'failed'`, `errorKind: 'validation'` result — the shape both diagnosis branches
+ *  above return, factored out purely to keep {@link diagnoseStillConnectingOrFailed} and the main
+ *  refused-tool branch from hand-building the same four-field object twice. See this file's header
+ *  ("Why the result is `status: 'failed', errorKind: 'validation'`") for why this exact shape is what
+ *  reaches the model un-redacted-by-the-stack rather than a thrown error. */
+function failedResult(message, deps) {
+    return { executionId: deps.newExecutionId(), status: "failed", errorKind: "validation", error: message };
+}
+/**
+ * Wraps `inner` so a call naming a federated tool id THIS BOOT REFUSED fails with a message naming
+ * the tool, the server, and the fix, instead of the bare `unknown tool` throw escaping all the way to
+ * `@jini-ai/http-kit`'s SEC-005 redaction.
+ *
+ * @param getSnapshot - Reads the CURRENT admission snapshot lazily, not a value closed over once —
+ *   this decorator is composed in `agent-daemon-server.ts` before `attachFederatedMcpTools` resolves
+ *   (mirroring that file's own `federationRefusalPrefix` `let` binding for the identical reason), so
+ *   a plain array parameter captured at construction time would forever see the empty pre-boot
+ *   snapshot. Pass `() => federationAdmissionReports` (a closure over the module-scope binding), not
+ *   `() => someArrayCapturedNow`.
+ * @param getBootStatus - Optional (2026-09-24). When given, an unknown-tool throw for a federated id
+ *   this boot's snapshot does NOT (yet) refuse is diagnosed one step further before falling back to
+ *   the original throw: while `!settled`, the connection is presumed still connecting (`npx`
+ *   startup, 6-13s, can outlast a caller's own bounded wait — see `assistant-byok.ts`'s
+ *   `FEDERATION_TURN_WAIT_MS`) and the call gets a clear "still connecting" message instead of the
+ *   raw `ToolExecutor: unknown tool` throw a model cannot act on. Once `settled`, a connectionId
+ *   present in `connectFailures` gets that failure's own reason instead. Omitted (the daemon's own
+ *   call site, where a turn never runs until `federation.start()` has fully resolved — see
+ *   `agent-daemon-server.ts`'s `start()`), this decorator's behavior is byte-identical to before this
+ *   parameter existed: every one of this file's own pre-2026-09-24 tests passes an unchanged 2-arg
+ *   call and must keep throwing for a federated-shaped id this boot never refused.
+ * @returns A drop-in `ToolExecutor`. Every call that is not BOTH (a) an unknown-tool throw AND (b) a
+ *   federated id this boot's snapshot actually refused passes through with byte-identical behavior —
+ *   completed results, every other status, and the throw itself for a genuinely unknown or
+ *   native-typo id — so `resumeConfirmation`/`cancel`/`getAuditRecord` delegate straight through with
+ *   no wrapping at all.
+ * @complexity One extra `instanceof`/regex test and one string-prefix test per call that reaches
+ *   `catch` — already the unhappy path; {@link findFederatedToolRefusal}'s own O(connections ×
+ *   refusals) cost only when both tests pass, and `getBootStatus`'s own O(connectFailures) lookup
+ *   only when they pass AND no refusal was found.
+ * @overallScore 100
+ */
+export function withFederatedRefusalDiagnosis({ inner, ...deps }, _optional = {}) {
+    return {
+        execute: async ({ principal, run, toolId, input }, { signal, emitSurface } = {}) => {
+            try {
+                return await inner.execute({ principal, run, toolId, input }, { ...(signal === undefined ? {} : { signal }), ...(emitSurface === undefined ? {} : { emitSurface }) });
+            }
+            catch (error) {
+                if (!isUnknownToolError(error) || !deps.isFederatedTool({ toolId }))
+                    throw error;
+                const refusal = deps.findRefusal({ toolId });
+                if (refusal === null) {
+                    const stillConnecting = diagnoseStillConnectingOrFailed(toolId, deps.getBootStatus?.(), { inner, ...deps });
+                    if (stillConnecting !== null)
+                        return stillConnecting;
+                    throw error;
+                }
+                return {
+                    executionId: deps.newExecutionId(),
+                    status: "failed",
+                    errorKind: "validation",
+                    // Redacted like every other `errorKind: 'validation'` failure (`tool-failure-redaction.ts`'s
+                    // own validation branch) even though THIS layer sits outside `withRedactedToolFailures` in
+                    // `agent-daemon-server.ts`'s composition and so would otherwise never pass back through it —
+                    // see this file's header for why it is composed outermost. `remoteName` is the one
+                    // upstream-influenced piece of this string: it is the external server's OWN advertised tool
+                    // name, sanitized by `safeRemoteName` only against injection characters, never against
+                    // secret shapes, so a remote naming a tool e.g. `sk-ant-api03-...` would otherwise leak it
+                    // verbatim. `connectionId` and `explanation` are operator-authored / fixed prose and never
+                    // match a redaction rule, so this is a no-op for them.
+                    error: deps.redactSecretShapes({
+                        text: `tool "${refusal.remoteName}" on external server "${refusal.connectionId}" was refused: ${refusal.explanation}`,
+                    }).text,
+                };
+            }
+        },
+        resumeConfirmation: (args) => inner.resumeConfirmation(args),
+        cancel: (executionId) => inner.cancel(executionId),
+        getAuditRecord: (executionId) => inner.getAuditRecord(executionId),
+    };
+}
+//# sourceMappingURL=federated-refusal.js.map

package/dist/tool-recovery/index.d.ts

@@ -0,0 +1,6 @@
+export * from "./diagnostics.js";
+export * from "./recovery.js";
+export * from "./redaction.js";
+export * from "./stack.js";
+export * from "./federated-refusal.js";
+//# sourceMappingURL=index.d.ts.map

package/dist/tool-recovery/index.js

@@ -0,0 +1,6 @@
+export * from "./diagnostics.js";
+export * from "./recovery.js";
+export * from "./redaction.js";
+export * from "./stack.js";
+export * from "./federated-refusal.js";
+//# sourceMappingURL=index.js.map

package/dist/tool-recovery/recovery.d.ts

@@ -0,0 +1,49 @@
+import type { ToolRegistry } from "@jini-ai/core";
+import type { ToolExecutor } from "../tool-executor.js";
+import { type SurfaceExchangeStore } from "../surface-exchanges.js";
+import { type ReadOnlyToolMessages } from "../core/read-only-tools.js";
+export interface ToolFailureRecoveryDeps {
+    /** The SAME instance `agent-daemon-server.ts` mounts `registerMcpUiToolCallsRoute` with — a
+     *  different one would leave this loop's own recovery surface unreachable, exactly the failure mode
+     *  `@jini-ai/daemon/surface-exchanges`'s own `AssistantSurfaceDeps` doc warns about for every other
+     *  consumer of this store. */
+    readonly surfaceExchanges: SurfaceExchangeStore;
+    /** Read-only: this loop only ever calls {@link ToolRegistry.list} to look up a remedy tool's own
+     *  published `inputSchema` — never a handler, and never anything requiring authorization to read. */
+    readonly registry: Pick<ToolRegistry, "list">;
+    readonly recoveryToolId: string;
+    readonly containsSecret: (required: {
+        text: string;
+    }) => boolean;
+    readonly assertCredentialFreeField: (required: {
+        value: string;
+        field: string;
+    }, optional: Record<string, never>) => void;
+    readonly readOnlyMessages: ReadOnlyToolMessages;
+    readonly formatReadOnlyRemedyRefusal: (required: {
+        refusal: string;
+    }) => string;
+    /** Rendering is host-owned: daemon cannot depend on browser/UI packages. */
+    readonly buildRecoveryForm: (required: {
+        exchangeId: string;
+        hint: string;
+        remedyToolId: string;
+        askFor?: {
+            key: string;
+            prompt: string;
+        };
+    }, optional?: Record<string, never>) => unknown;
+}
+/**
+ * Wraps `inner` with the generic ask -> apply -> retry-once recovery loop described in this file's
+ * header. A drop-in `ToolExecutor` — every method other than `execute` delegates straight through,
+ * matching `tool-executor-audit.ts`'s own `withToolAttemptAudit` shape.
+ *
+ * @complexity The no-hint path (the overwhelming majority) is one `inner.execute` call plus one bounded
+ *   output scan — O(1) beyond `inner`'s own cost. The recovery path adds at most two further
+ *   `inner.execute` calls (the remedy, the retry) and one surface round trip.
+ */
+export declare function withToolFailureRecovery({ inner, ...deps }: ToolFailureRecoveryDeps & {
+    inner: ToolExecutor;
+}, _optional?: {}): ToolExecutor;
+//# sourceMappingURL=recovery.d.ts.map