/**
 * GENERATED — DO NOT EDIT BY HAND.
 *
 * Source: schemas/qar/qodo-task-start-payload.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.
 */
/**
 * Typed shape of ``task.start.input`` — owned by QAR, consumed by the SDK.
 *
 * QAR is the runtime, so it owns every wire shape; the SDK is the
 * typed bindings, never a parallel source of truth.
 *
 * Fields:
 *
 * * ``user_query`` — natural-language prompt the agent receives. Optional
 *   because non-prompt agents (pure-tool sub-agents driven by orchestrators)
 *   may carry only ``params``. When unset, the dispatcher passes
 *   an empty user prompt to the agent — ``params`` and
 *   ``metadata`` are NEVER serialised into the prompt string (they may
 *   carry tenant-scoped credentials; see ``_input_to_prompt`` in
 *   ``qar.protocol.ws_handler`` for the secrecy boundary).
 * * ``params`` — opaque per-tenant / per-session deps the runtime
 *   merges into the agent's typed ``deps`` schema before dispatch.
 *   Values are validated against the agent's ``deps_schema``.
 *   Dispatcher-owned keys win the merge: ``tenant_id`` and ``session_id``
 *   are always written from server-trusted state, so a malicious
 *   client cannot spoof either by stuffing them into this map. The
 *   ``bulletin`` key is dispatcher-owned *for orchestrator agents* —
 *   i.e., topologies declaring ``multi_agent.bulletin_topics``;
 *   non-orchestrator topologies don't have a ``bulletin`` field on
 *   their deps schema and rejecting it falls out of Pydantic
 *   ``extra="forbid"`` validation. This field stays ``dict`` here
 *   because the wire envelope is generic over the union of every
 *   agent's deps schema.
 * * ``metadata`` — string-keyed/string-valued tracing metadata. Cardinality
 *   is the operator's concern (don't put session ids here — they're already
 *   on the envelope); included so Studio + downstream traces can stamp
 *   arbitrary correlation tags without growing the envelope shape.
 * * ``content`` — optional ordered list of :data:`ContentPart` carrying a
 *   multimodal user turn (text interleaved with inline files). Additive
 *   and mutually exclusive with ``user_query``: a message carries the user
 *   turn as the plain string OR as ordered parts, never both. Order is
 *   semantically meaningful. The dispatcher maps a ``text`` part to a
 *   ``str`` and a ``file`` part to a ``pydantic_ai.BinaryContent`` (see
 *   ``_input_to_prompt`` / :mod:`qar.protocol.content`); ``params``
 *   and ``metadata`` are still never serialised into the prompt.
 *
 * Back-compat: ``content`` is additive and optional, so an old client that
 * only sends ``user_query`` works against the new server unchanged. The
 * new field uses ``extra="forbid"`` like every payload, so a new client
 * sending ``content`` is rejected by an old server — the rollout rule is
 * therefore server-before-client.
 */
export interface QodoTaskStartPayload {
    content?: ((TextPart | FilePart)[] | null);
    params?: ({
        [k: string]: unknown | undefined;
    } | null);
    metadata?: ({
        [k: string]: string | undefined;
    } | null);
    schema_version?: 1;
    user_query?: (string | null);
}
/**
 * A text segment of a multimodal user message.
 *
 * Carries the same natural-language content the flat ``user_query``
 * string would; it exists as a part so a message can interleave text
 * and files in a single ordered sequence.
 */
export interface TextPart {
    text: string;
    type?: "text";
}
/**
 * An inline file (image or PDF) segment of a multimodal user message.
 *
 * One part type serves both images and PDFs — the kind is carried by
 * ``media_type``, never by a separate image/file shape, so there is a
 * single code path downstream.
 *
 * ``media_type`` is a plain validated ``str``, NOT a frozen
 * :class:`~typing.Literal`. The set of *accepted* media types is an
 * operator-extensible allowlist enforced at dispatch (see
 * :mod:`qar.protocol.content`), deliberately kept OUT of this wire
 * schema: enabling a new provider/format is then an operator-config
 * change, not a wire-schema bump that would ripple to every generated
 * SDK binding.
 *
 * ``data`` is the base64-encoded file bytes (decoded + validated at
 * dispatch). ``filename`` is optional client metadata; it is treated as
 * sensitive downstream (kept out of span attributes), so it is never
 * required and never load-bearing.
 */
export interface FilePart {
    data: string;
    filename?: (string | null);
    media_type: string;
    type?: "file";
}
//# sourceMappingURL=qodo-task-start-payload.d.ts.map