/** * GENERATED — DO NOT EDIT BY HAND. * * Source: schemas/qar/qar-tools-invoke.json * QAR commit: c0157c5c4aaa9304910c6be075e81d253f15c763 * QAR ref: c0157c5c4aaa9304910c6be075e81d253f15c763 * Fetched: 2026-10-07 * * Edit the upstream Pydantic models in qodo-ai/qodo-agent-runtime, * re-run `python scripts/export-schemas.py` there, bump * schemas/qar/.qar-version + the vendored JSON files, then * `npm run codegen:qar` regenerates this file. */ /** * Umbrella carrier for the direct-invoke / operation / error wire set. * * The runtime never instantiates this model; it exists only so a single * ``model_json_schema()`` call emits every non-catalog tools-API model into * one document's ``$defs``. The SDK codegen runs with * ``declareExternallyReferenced``, so each ``$def`` (``ToolInvokeRequest``, * ``OperationStatusResponse``, ``ToolErrorEnvelope`` + nested * ``ToolErrorDetail``, …) becomes its own TypeScript interface — the * consumer generates from the ``$defs``, not this wrapper's fields, which * are merely the references that pull each model in. ``OperationStatus`` and * ``ManagedToolErrorCode`` ride along inline (string unions) on the fields * that use them. */ export interface ToolsInvokeSchemas { error: ToolErrorEnvelope; invoke_request: ToolInvokeRequest; invoke_result: ToolInvokeResult; operation_accepted: OperationAccepted; operation_status: OperationStatusResponse; } /** * The typed ``{ok:false, error:{...}}`` body every 4xx/5xx response carries. * * Declared so the OpenAPI contract documents the error shape on non-200 * responses (the routes return this on 401/404/409/429/4xx/5xx), not only the * 200 model — SDK codegen then types both the success and the failure branch. */ export interface ToolErrorEnvelope { error: ToolErrorDetail; ok: false; } /** * The ``error`` block of a typed failure response. * * ``code`` is the closed :data:`ToolApiErrorCode` union — the tool ``MT-*`` * family (single source of truth in :data:`~qar.managed_tools.ManagedToolErrorCode`) * plus the two endpoint-protocol conflict codes — so the exported schema * constrains it to that enum and SDK codegen types it as a string union a * client can branch on exhaustively (rather than a bare ``string``). The * sibling ``metadata`` stays an open object: its keys are stage-dependent. */ export interface ToolErrorDetail { code: (("MT-AUTH-MISSING" | "MT-AUTH-INVALID" | "MT-AUTH-FORBIDDEN" | "MT-TENANT-UNCONFIGURED" | "MT-UPSTREAM-DOWN" | "MT-RATE-LIMITED" | "MT-CATALOG-STALE" | "MT-VALIDATION" | "MT-REPO-NOT-IN-SCOPE" | "MT-REPO-NO-CREDENTIAL" | "MT-WORKSPACE-NO-REPOS" | "MT-NOT-FOUND" | "MT-CONFLICT" | "MT-TOOL-LOOP" | "TOOL-PREVIEW-GATED") | ("IDEMPOTENCY_KEY_CONFLICT" | "OPERATION_OUTCOME_UNKNOWN")); message: string; metadata?: { [k: string]: unknown | undefined; }; } /** * The ``POST /v1/tools/{name}:invoke`` request body. * * ``arguments`` is the tool's call arguments — coerced then validated against * the tool's JSON-Schema before any upstream round-trip. ``extra="forbid"`` so * a mis-shaped envelope (a stray top-level key) is a clear 422, distinct from a * typed ``MT-VALIDATION`` on the arguments themselves. */ export interface ToolInvokeRequest { arguments?: { [k: string]: unknown | undefined; }; } /** * A ``200`` synchronous invoke result — the tool completed in the window. */ export interface ToolInvokeResult { ok: true; result: { [k: string]: unknown | undefined; }; } /** * A ``202`` escalation — the invocation runs on; poll ``operation_id``. */ export interface OperationAccepted { operation_id: string; poll_interval: number; status: ("working" | "completed" | "failed" | "cancelled" | "input_required"); ttl: number; } /** * The ``GET /v1/tools/operations/{id}`` body — status + outcome if terminal. */ export interface OperationStatusResponse { error?: ({ [k: string]: unknown | undefined; } | null); operation_id: string; result?: ({ [k: string]: unknown | undefined; } | null); status: ("working" | "completed" | "failed" | "cancelled" | "input_required"); } //# sourceMappingURL=qar-tools-invoke.d.ts.map