@tangle-network/agent-app 0.43.47 → 0.43.49

package/dist/chat-routes/index.d.ts

@@ -1,14 +1,21 @@
-import { A as ChatTurnRequestPayload, B as ChatTurnPartInput, e as ChatMessagePart, D as ChatTurnFilePartInput } from '../parts-1_3y2JmR.js';
-export { c as ChatMentionKind, E as ChatTurnInputError, G as ChatTurnTextPartInput, F as FileMention, H as FileMentionsToPartsOptions, I as INLINE_PARTS_MAX_BYTES, M as MENTION_MAX_COUNT, J as SandboxMentionPathCheck, K as assertPromptPartsWithinCap, L as buildMentionPromptBlock, N as chatTurnRequestInit, O as fileMentionsToParts, P as mediaTypeForMentionPath, Q as mentionKindForPath, R as parseChatTurnParts, T as parseFileMentions, U as promptPartsByteSize, V as validateSandboxMentionPath } from '../parts-1_3y2JmR.js';
+import { L as ChatTurnRequestPayload, M as ChatTurnPartInput, g as ChatMessagePart, N as ChatTurnFilePartInput, a as ChatAttachmentPart, f as ChatMentionPart, C as ChatAttachmentKind } from '../parts-IB-Kbb7z.js';
+export { O as ChatAttachmentInput, e as ChatMentionKind, P as ChatTurnInputError, Q as ChatTurnTextPartInput, R as DISPATCH_MAX_MEDIA_PARTS, T as DISPATCH_MAX_PARTS, U as DISPATCH_REQUEST_MAX_BYTES, V as DISPATCH_STRUCTURAL_RESERVE_BYTES, K as FileMention, W as FileMentionsToPartsOptions, X as INLINE_PARTS_MAX_BYTES, Y as MENTION_MAX_COUNT, Z as SandboxMentionPathCheck, _ as assertPromptPartsWithinCap, $ as base64WireLen, a0 as buildMentionPromptBlock, a1 as chatTurnRequestInit, a2 as fileMentionsToParts, a3 as formatBytes, a4 as mediaTypeForMentionPath, a5 as mentionKindForPath, a6 as parseChatTurnParts, a7 as parseFileMentions, a8 as promptPartsByteSize, a9 as validateSandboxMentionPath } from '../parts-IB-Kbb7z.js';
 import { ChatTurnIdentity, ChatTurnProducer } from '@tangle-network/agent-runtime';
 import { InteractionAnswerRoute, InteractionAnswerRouteOptions } from '../interactions/index.js';
 import { PersistedChatMessageForTurn } from '../stream/index.js';
 import { d as TurnEventStore } from '../turn-buffer-C9mEgoop.js';
 export { D as DEFAULT_STALE_TURN_LOCK_GRACE_MS, a as DEFAULT_TERMINAL_TURN_LOCK_GRACE_MS, R as ReconcileStaleTurnLockOptions, b as ReconcileStaleTurnLockResult, S as StaleTurnLockSandboxProbeResult, c as StaleTurnLockSessionProbeResult, r as reconcileStaleTurnLock } from '../stale-turn-lock-C8Na1cFZ.js';
-export { C as CreateSandboxFileIndexRouteOptions, F as FileIndexAuthorization, a as FileIndexCache, b as FileIndexReadyResponse, c as FileIndexResponse, d as FileIndexWarmingResponse, S as SandboxFileTreeSource, e as SandboxTreeFile, f as SandboxTreeResult, g as createSandboxFileIndexRoute } from '../file-index-Bn6sitKb.js';
+import { J as JsonRecord } from '../stream-normalizer-DWvtmY6F.js';
+export { C as CreateSandboxFileIndexRouteOptions, F as FileIndexAuthorization, a as FileIndexCache, b as FileIndexReadyResponse, c as FileIndexResponse, d as FileIndexWarmingResponse, S as SandboxFileTreeSource, e as SandboxTreeFile, f as SandboxTreeResult, g as createSandboxFileIndexRoute } from '../file-index-b26ee-_R.js';
+import { SandboxExecChannel, PromptInputPart } from '../sandbox/index.js';
 import '@tangle-network/agent-interface';
 import '../contract-KfqJh_au.js';
 import '../plans/index.js';
+import '@tangle-network/sandbox';
+import '../auth-DuptSkWh.js';
+import '../types-BEOvc_ue.js';
+import '../harness/index.js';
+import '../model-dF2h4xT9.js';
 
 /**
  * `createChatTurnRoutes` — the assembled server chat vertical (issue #188
@@ -338,6 +345,30 @@ declare function createChatTurnRoutes<TContext = void>(options: CreateChatTurnRo
  * `step-finish` parts. `createChatTurnRoutes` reads both after drain.
  */
 
+/** Outcome of a `promoteFilePart` attempt. `key`, when given, becomes the
+ *  persisted part's row key (e.g. `attachment:<path>`) so repeat promotions
+ *  of the same underlying file fold into one segment instead of appending;
+ *  omitted, the default `getPartKey` keying applies.
+ *
+ *  On failure, `part` is an OPTIONAL substitute part to persist in place of
+ *  the raw url-bearing one — this is how a product swaps in a transcript
+ *  notice (gtm persists a `warning` notice part, never the transient url) for
+ *  a failed promotion instead of baking a `data:`/sandbox-path url into the
+ *  durable row. When `part` is present it is persisted (via the same
+ *  `recordPersistedPart` path as a success, honoring the optional `key`);
+ *  when absent, the existing raw-part fallback applies unchanged — so a
+ *  caller that only returns `{ succeeded: false, reason }` keeps today's
+ *  behavior verbatim. */
+type FilePartPromotionOutcome = {
+    succeeded: true;
+    part: Record<string, unknown>;
+    key?: string;
+} | {
+    succeeded: false;
+    reason: string;
+    part?: Record<string, unknown>;
+    key?: string;
+};
 interface SandboxChatProducerOptions {
     /** The raw sandbox event stream (e.g. `streamSandboxPrompt(...)`). */
     events: AsyncIterable<unknown>;
@@ -351,6 +382,34 @@ interface SandboxChatProducerOptions {
      *  session's sidecar connection). Without it, non-renderable asks are only
      *  logged — the run stays blocked until the broker times out. */
     declineInteraction?: (id: string) => Promise<void>;
+    /** Opt-in eager promotion of harness-emitted `file` parts. Unset, a `file`
+     *  part persists exactly as the harness sent it — a transient `url` (a
+     *  `data:` URI or in-sandbox path) baked into the transcript, which is
+     *  today's behavior and stays byte-identical if this is never wired. Set,
+     *  EVERY `file` part (never `image`, never any other kind) is routed
+     *  through this callback instead of `recordPersistedPart`'s default
+     *  fallback — including a part with NEITHER `id` NOR `url` (gtm always
+     *  attempts promotion; such a part simply fails "carries no url" and
+     *  resolves through the same failure path as any other rejection, rather
+     *  than being persisted raw and unpromoted) — so the product can durably
+     *  write the bytes and swap in a path-bearing part before the raw url ever
+     *  reaches the persisted transcript. Keyed per source-prefixed `id:<id>` /
+     *  `url:<url>` (an `id` and a `url` sharing the same text must never collide
+     *  onto one memo entry) and memoized by PROMISE (not result), so re-emitted
+     *  snapshot events for the same part —
+     *  the harness resends the whole part on every update, not just deltas —
+     *  fold onto the one in-flight or settled attempt rather than promoting
+     *  twice or racing two concurrent writes; a raw part with neither `id` nor
+     *  `url` cannot be keyed, so it is invoked UN-memoized (once per event) —
+     *  each occurrence is its own attempt. A rejecting promise is caught,
+     *  logged via `log`, and treated as `succeeded: false`. On `succeeded:
+     *  false` the outcome's optional `part` (a substitute — e.g. a warning
+     *  notice — see {@link FilePartPromotionOutcome}) persists in its place when
+     *  given; otherwise the raw part persists exactly as it does today — this
+     *  seam only decides whether to call the promoter and what to do with its
+     *  outcomes; the promotion mechanics (vault write, key derivation, notice
+     *  construction) live in the caller's callback, not here. */
+    promoteFilePart?: (raw: JsonRecord) => Promise<FilePartPromotionOutcome>;
     log?: (message: string, meta?: Record<string, unknown>) => void;
 }
 declare function createSandboxChatProducer(options: SandboxChatProducerOptions): ChatTurnRouteProducer;
@@ -445,4 +504,335 @@ declare function sanitizeUploadFilename(name: string): string;
 declare function bytesToBase64(bytes: Uint8Array): string;
 declare function createUploadRoute(options: CreateUploadRouteOptions): (request: Request) => Promise<Response>;
 
-export { type ChatRouteDurableProjection, type ChatRouteDurableProjectionLogger, type ChatTurnAuthorization, type ChatTurnAuthorizeArgs, ChatTurnFilePartInput, type ChatTurnGateResult, type ChatTurnHeartbeat, type ChatTurnInputPatch, type ChatTurnLifecycle, type ChatTurnLifecycleComplete, type ChatTurnLifecycleError, type ChatTurnLifecycleStart, type ChatTurnLock, type ChatTurnLockResult, type ChatTurnMessageStore, ChatTurnPartInput, type ChatTurnProduceArgs, ChatTurnRequestPayload, type ChatTurnRouteProducer, type ChatTurnRoutes, type ChatTurnUsage, type CreateChatTurnRoutesOptions, type CreateUploadRouteOptions, type SandboxChatProducerOptions, type SandboxUploadSink, UPLOAD_INLINE_MAX_BYTES, UPLOAD_MAX_FILE_BYTES, type UploadAuthorization, type UploadedChatFile, bytesToBase64, createChatTurnRoutes, createSandboxChatProducer, createUploadRoute, sanitizeUploadFilename, withDurableChatProjection };
+/**
+ * Storage seams for the chat-attachment vertical (`resolveChatAttachments`,
+ * `buildDispatchParts`, `promoteAgentFilePart`). Structural function ports in
+ * the same style as `upload.ts`'s `SandboxUploadSink`: REQUIRED injection, no
+ * default implementation — agent-app owns the size/budget/idempotency
+ * mechanism, the product owns where the bytes actually live.
+ *
+ * One reader, two callers: `resolveChatAttachments` reads only the
+ * authoritative `size` (never trusting the client-reported size), while
+ * `buildDispatchParts` reads the inline `content` (base64 or raw bytes) to
+ * build a `data:` URI. Both fit behind ONE `ReadAttachmentFn` so a product
+ * wires a single vault/object-store adapter, not two. gtm's KV vault (stores
+ * base64 bodies) and `/object-store`'s `ObjectStore` (hands back raw bytes)
+ * both satisfy this shape.
+ */
+/**
+ * The result of reading one stored attachment. `ok:true` MUST carry the
+ * authoritative decoded byte `size` (the cap is meaningless against a
+ * client-controlled number) and, when the caller needs to inline the file,
+ * its content as `base64` and/or raw `bytes`. `mediaType` is the stored
+ * content type when the store knows it (used as the fallback when the wire
+ * part carried none). `ok:false` carries a human `reason` that SHOULD name the
+ * offending path — it is surfaced verbatim in the caller's typed outcome.
+ */
+type AttachmentReadResult = {
+    ok: true;
+    /** Authoritative decoded byte length of the stored content. */
+    size: number;
+    /** Inline content as base64 — reused verbatim for a `data:` URI, so a
+     *  store holding already-base64 bodies never decodes-and-re-encodes. */
+    base64?: string;
+    /** Inline content as raw bytes — base64-encoded by the caller when a
+     *  `data:` URI is needed. Ignored when `base64` is present. */
+    bytes?: Uint8Array;
+    /** Stored content type, when the store tracks one. */
+    mediaType?: string;
+} | {
+    ok: false;
+    reason: string;
+};
+/**
+ * Read one stored attachment for `scopeId` (the product's workspace/tenant
+ * key) at its store-relative `path`. Missing, deleted, or unreadable content
+ * MUST resolve to `{ ok: false, reason }`, never throw — a store failure is a
+ * per-attachment outcome the caller folds into its own typed result, not a
+ * turn-level exception.
+ */
+type ReadAttachmentFn = (scopeId: string, path: string) => Promise<AttachmentReadResult>;
+/** Outcome of persisting one attachment. Mirrors `AttachmentReadResult`'s
+ *  `ok`/`reason` shape and `upload.ts`'s `{ ok }` convention. */
+type AttachmentWriteResult = {
+    ok: true;
+} | {
+    ok: false;
+    reason: string;
+};
+/**
+ * Persist `content` for `scopeId` at `path`. `content` is either raw `bytes`
+ * or a base64 `string` — a string argument is ALWAYS base64 (never utf8), so
+ * a store that speaks base64 (gtm's vault) writes it verbatim and one that
+ * speaks bytes decodes once. Like the reader, failures resolve to
+ * `{ ok: false, reason }` rather than throwing.
+ *
+ * `opts` mirrors the vault frontmatter gtm's `writeAttachmentVaultFile`
+ * persists alongside the body (promote-file-parts.ts:181-190), so a product
+ * reimplementing that vault writer through this seam can reproduce it
+ * exactly:
+ * - `mediaType` — the resolved MIME type; gtm's frontmatter key `mime`.
+ * - `name` — the sanitized (store-path-safe) display filename; gtm passes
+ *   this only to shape its oversize message, not into frontmatter.
+ * - `originalName` — the filename as the harness/browser reported it, BEFORE
+ *   sanitization (`raw.filename ?? filename` — falls back to the sanitized
+ *   name when the source carried none); gtm's frontmatter key `originalName`.
+ *   This is the one field with no other recovery path once sanitization has
+ *   run, so it must ride the write, not be re-derived after the fact.
+ * - `size` — the authoritative decoded byte length being written; gtm's
+ *   frontmatter key `size`.
+ */
+type WriteAttachmentFn = (scopeId: string, path: string, content: Uint8Array | string, opts: {
+    mediaType?: string;
+    name?: string;
+    originalName?: string;
+    size?: number;
+}) => Promise<AttachmentWriteResult>;
+
+/**
+ * `resolveChatAttachments` — validate a turn body's `attachments` field into
+ * persistable {@link ChatAttachmentPart}s. Every path is re-validated (a path
+ * off the wire is never trusted to stay inside the store root) and every size
+ * is re-derived from the STORED body via the injected {@link ReadAttachmentFn},
+ * never the client-reported `size` — the upload path lets a caller rewrite its
+ * own frontmatter, so a stored size cannot bound anything and the wire size can
+ * be anything. Both the aggregate cap and the size carried on the returned part
+ * come from the authoritative read.
+ *
+ * Storage-parameterized: the frontmatter parsing / base64 sizing that derives
+ * the authoritative size lives BEHIND `readAttachment` (a product's vault or
+ * object-store adapter), so this module is a pure validator + budget gate with
+ * no store knowledge. Lifted from gtm-agent's `resolve-attachments.ts`
+ * (workspaceId → scopeId, the vault read → the injected reader) and kept
+ * behavior-identical for gtm-agent#618 adoption.
+ */
+
+type ResolveChatAttachmentsResult = {
+    succeeded: true;
+    value: ChatAttachmentPart[];
+} | {
+    succeeded: false;
+    error: string;
+};
+/** Verdict of a path check: OK, or a rejection naming why. Mirrors
+ *  `SandboxMentionPathCheck` in `./wire`. */
+type AttachmentPathCheck = {
+    succeeded: true;
+} | {
+    succeeded: false;
+    error: string;
+};
+/** Most files a single request may carry. */
+declare const ATTACHMENT_MAX_COUNT = 10;
+/** Aggregate raw-byte ceiling across one message's attachments. */
+declare const MAX_ATTACHMENT_TOTAL_BYTES: number;
+/** Human-readable error for a message whose combined attachments exceed the
+ *  aggregate raw-byte ceiling. Ported to match gtm's `attachmentTotalSizeErrorMessage`
+ *  (attachment-limits.ts:93-95) verbatim, via the shared {@link formatBytes} —
+ *  e.g. "Attachments total 25MB; each message is limited to 25MB", not raw
+ *  byte counts. */
+declare function attachmentTotalSizeErrorMessage(totalBytes: number, limitBytes: number): string;
+/**
+ * Default path validator when a caller supplies none. Rejects the ways a path
+ * picked in a client can escape the store root — traversal (`..` segment),
+ * absolute (leading `/`), backslashes, null bytes, control characters (see
+ * {@link CONTROL_CHARS} — a path also feeds {@link buildAttachmentPromptBlock}'s
+ * `(vault: ${path})` pointer, so it is exposed to the same injection surface as
+ * `name`) — plus a dotfile/hidden segment (a leading `.` on any segment).
+ * Generalized from gtm's `validateVaultFilePath`, in the spirit of
+ * `validateSandboxMentionPath` (`/chat-routes`'s wire mention-path validator) —
+ * but the dotfile rejection here is INTENTIONALLY stricter than that sibling:
+ * an uploaded attachment path is sanitized store-relative storage the product
+ * itself assigned, whereas a mention path points at a file that already exists
+ * in the sandbox and may legitimately live under a dotfile segment. A caller
+ * that needs gtm's exact (looser) rule can supply `validatePath` to override
+ * this default entirely.
+ */
+declare function defaultValidateAttachmentPath(path: string): AttachmentPathCheck;
+interface ResolveChatAttachmentsOptions {
+    /** The product's workspace/tenant key, passed to `readAttachment`. */
+    scopeId: string;
+    /** Authoritative size + content reader — see {@link ReadAttachmentFn}. */
+    readAttachment: ReadAttachmentFn;
+    /** Most attachments one request may carry. Default {@link ATTACHMENT_MAX_COUNT}. */
+    maxCount?: number;
+    /** Aggregate raw-byte ceiling. Default {@link MAX_ATTACHMENT_TOTAL_BYTES}. */
+    maxTotalBytes?: number;
+    /** Path validator override. Default {@link defaultValidateAttachmentPath}. */
+    validatePath?: (path: string) => AttachmentPathCheck;
+}
+/**
+ * Validate and resolve a turn body's `attachments` field into persistable
+ * parts. Every path is confirmed present (and not deleted) in the caller's own
+ * store by `readAttachment` before it is trusted, and size is derived from the
+ * authoritative read for both the aggregate cap and the returned part's size.
+ */
+declare function resolveChatAttachments(value: unknown, options: ResolveChatAttachmentsOptions): Promise<ResolveChatAttachmentsResult>;
+
+/**
+ * `buildDispatchParts` — assemble the `PromptInputPart[]` a turn carrying
+ * attachments and/or `@`-mentions dispatches to the sandbox. `parts[0]` is
+ * always the full prompt text (typed text plus the attachment + mention pointer
+ * blocks); each attachment or mention becomes one media part. An attachment
+ * (read from the product store via the injected reader) draws the inline byte
+ * budget first; a mention (read from the LIVE box) takes what is left. A file
+ * inlines as a `data:` URI when it fits the remaining budget, otherwise demotes
+ * to an in-box path part so the whole request stays under the proxy cap. Every
+ * media part is deduped by its resolved absolute path. This module only
+ * produces the parts array; the caller decides when a turn dispatches parts
+ * instead of a plain string.
+ *
+ * Storage-parameterized port of gtm-agent's `dispatch-parts.ts`: the vault
+ * default reader is dropped (`readAttachment` is REQUIRED — the product supplies
+ * its store adapter), the `GTM_SANDBOX_VAULT_DIR` prefixing becomes the required
+ * `resolveAttachmentPath` seam, the `GTM_MULTIMODAL_FORCE_PATH` env fallback
+ * becomes an explicit `forcePath` flag, and every budget cap reads an overridable
+ * `./wire` constant. Kept behavior-identical for gtm-agent#618 adoption (the
+ * demotion math and emitted part shapes reproduce its dispatched prompt bytes).
+ */
+
+type DispatchPartsOutcome = {
+    succeeded: true;
+    value: PromptInputPart[];
+} | {
+    succeeded: false;
+    error: string;
+};
+/** One mention file's size (always) and inline bytes (only when the caller
+ *  asked for them — a path-only mention never reads its bytes). */
+type SandboxMentionReadOutcome = {
+    succeeded: true;
+    value: {
+        size: number;
+        base64?: string;
+    };
+} | {
+    succeeded: false;
+    error: string;
+};
+type ReadSandboxMentionFn = (box: SandboxExecChannel, absolutePath: string, options: {
+    readBytes: boolean;
+}) => Promise<SandboxMentionReadOutcome>;
+interface BuildDispatchPartsInput {
+    text: string;
+    attachments: ChatAttachmentPart[];
+    mentions?: ChatMentionPart[];
+    history: Array<{
+        role: 'user' | 'assistant';
+        content: string;
+    }>;
+    systemPrompt: string;
+    /** Serialized size of the backend profile the SDK inlines into the same
+     *  prompt request body — a large, non-negotiable rider that must come out of
+     *  the inline budget or near-cap attachments 413 at the proxy instead of
+     *  demoting to path parts. */
+    profileWireBytes: number;
+    /** The product's workspace/tenant key, passed to `readAttachment`. */
+    scopeId: string;
+    /** Maps an attachment's store-relative path to the in-box absolute path a
+     *  path-based part references (same seam style as `fileMentionsToParts`'s
+     *  `resolvePath`). */
+    resolveAttachmentPath: (path: string) => string;
+    /** Maps a mention's workspace-relative path to its in-box absolute path.
+     *  Default: {@link BuildDispatchPartsInput.resolveAttachmentPath} — in gtm the
+     *  vault mount roots both; a product that mounts them apart overrides this. */
+    resolveMentionPath?: (path: string) => string;
+    /** The turn's already-ensured box — required when `mentions` is non-empty
+     *  (mention bytes are read from the live box, not the store). */
+    box?: SandboxExecChannel;
+    /** Force every media part to a path reference, skipping all inlining. */
+    forcePath?: boolean;
+    /** REQUIRED store reader for attachment content — no default (the product
+     *  owns its store; see {@link ReadAttachmentFn}). */
+    readAttachment: ReadAttachmentFn;
+    readSandboxMention?: ReadSandboxMentionFn;
+    /** Whole-request proxy cap. Default {@link DISPATCH_REQUEST_MAX_BYTES}. */
+    requestMaxBytes?: number;
+    /** JSON-envelope reserve off the top of the request cap. Default
+     *  {@link DISPATCH_STRUCTURAL_RESERVE_BYTES}. */
+    structuralReserveBytes?: number;
+    /** Sidecar per-request parts-array cap. Default {@link DISPATCH_MAX_PARTS}. */
+    maxParts?: number;
+}
+declare function buildDispatchParts(input: BuildDispatchPartsInput): Promise<DispatchPartsOutcome>;
+
+/**
+ * `promoteAgentFilePart` — turn a harness-emitted `type:"file"` stream part
+ * into a store-backed {@link ChatAttachmentPart}. The harness hands back a URL
+ * pointing at bytes it produced (a `data:` URI, or a path inside the sandbox);
+ * nothing durable survives past the turn unless it is written into the
+ * product's store, the same way a user upload is. Typed outcomes throughout:
+ * every failure mode (unsupported scheme, no sandbox, oversize, store-write
+ * failure, malformed part) resolves to `{ succeeded: false, filename, reason }`
+ * rather than throwing past this boundary, so the caller folds a visible notice
+ * instead of losing the file silently.
+ *
+ * Storage-parameterized port of gtm-agent's `promote-file-parts.ts` with the
+ * refactor gtm never made: persistence goes through the injected
+ * {@link WriteAttachmentFn} (gtm hard-wired its vault writer), the path strategy
+ * is the injected `buildAttachmentPath` (neutral `uploads/agent/<date>/` default,
+ * no domain bucket taxonomy baked), the MIME map is an injectable hook, and the
+ * date segment reads an injectable clock. The idempotent `hash8(id ?? url ??
+ * filename)` naming is preserved so re-promoting the same source part resolves
+ * to the same path.
+ */
+
+/** Default ceiling on a promoted file's raw (pre-encoding) byte size. */
+declare const PROMOTE_MAX_FILE_BYTES: number;
+interface RawAgentFilePart {
+    type: 'file';
+    id?: string;
+    filename?: string;
+    /** AI-SDK-shaped parts carry the MIME type here… */
+    mediaType?: string;
+    /** …but OpenCode's native FilePart calls the same field `mime`. */
+    mime?: string;
+    url?: string;
+}
+type PromoteFilePartResult = {
+    succeeded: true;
+    part: ChatAttachmentPart;
+} | {
+    succeeded: false;
+    filename: string;
+    reason: string;
+};
+/** Arguments handed to a {@link PromoteAgentFilePartOptions.buildAttachmentPath}
+ *  override — everything needed to place the file deterministically. */
+interface AttachmentPathArgs {
+    /** Sanitized display filename (basename, safe charset). */
+    filename: string;
+    /** First 8 hex chars of the SHA-256 idempotency digest. */
+    hash8: string;
+    /** `YYYY-MM-DD` from the injected clock. */
+    date: string;
+    /** Resolved media type. */
+    mediaType: string;
+    /** `image`/`file` split of the media type. */
+    kind: ChatAttachmentKind;
+}
+/** Default MIME hook: extension → mime, or `text/plain` for the unknown. */
+declare function sniffMimeFromName(filename: string): string;
+interface PromoteAgentFilePartOptions {
+    raw: RawAgentFilePart;
+    /** The turn's box — required only to promote a sandbox-path part; a `data:`
+     *  URI needs none. */
+    box?: SandboxExecChannel;
+    /** The product's workspace/tenant key, passed to `writeAttachment`. */
+    scopeId: string;
+    /** The turn's session id, used for the sandbox stat/read exec calls. */
+    sessionId: string;
+    /** REQUIRED store writer — no default (the product owns its store). */
+    writeAttachment: WriteAttachmentFn;
+    /** Store-path strategy. Default {@link defaultBuildAttachmentPath}. */
+    buildAttachmentPath?: (args: AttachmentPathArgs) => string;
+    /** Raw-byte ceiling. Default {@link PROMOTE_MAX_FILE_BYTES}. */
+    maxBytes?: number;
+    /** Last-resort media-type hook. Default {@link sniffMimeFromName}. */
+    sniffMime?: (filename: string) => string;
+    /** Clock for the date path segment. Default `() => new Date()`. */
+    now?: () => Date;
+}
+declare function promoteAgentFilePart(options: PromoteAgentFilePartOptions): Promise<PromoteFilePartResult>;
+
+export { ATTACHMENT_MAX_COUNT, type AttachmentPathArgs, type AttachmentPathCheck, type AttachmentReadResult, type AttachmentWriteResult, type BuildDispatchPartsInput, ChatAttachmentKind, type ChatRouteDurableProjection, type ChatRouteDurableProjectionLogger, type ChatTurnAuthorization, type ChatTurnAuthorizeArgs, ChatTurnFilePartInput, type ChatTurnGateResult, type ChatTurnHeartbeat, type ChatTurnInputPatch, type ChatTurnLifecycle, type ChatTurnLifecycleComplete, type ChatTurnLifecycleError, type ChatTurnLifecycleStart, type ChatTurnLock, type ChatTurnLockResult, type ChatTurnMessageStore, ChatTurnPartInput, type ChatTurnProduceArgs, ChatTurnRequestPayload, type ChatTurnRouteProducer, type ChatTurnRoutes, type ChatTurnUsage, type CreateChatTurnRoutesOptions, type CreateUploadRouteOptions, type DispatchPartsOutcome, type FilePartPromotionOutcome, MAX_ATTACHMENT_TOTAL_BYTES, PROMOTE_MAX_FILE_BYTES, type PromoteAgentFilePartOptions, type PromoteFilePartResult, PromptInputPart, type RawAgentFilePart, type ReadAttachmentFn, type ReadSandboxMentionFn, type ResolveChatAttachmentsOptions, type ResolveChatAttachmentsResult, type SandboxChatProducerOptions, type SandboxUploadSink, UPLOAD_INLINE_MAX_BYTES, UPLOAD_MAX_FILE_BYTES, type UploadAuthorization, type UploadedChatFile, type WriteAttachmentFn, attachmentTotalSizeErrorMessage, buildDispatchParts, bytesToBase64, createChatTurnRoutes, createSandboxChatProducer, createUploadRoute, defaultValidateAttachmentPath, promoteAgentFilePart, resolveChatAttachments, sanitizeUploadFilename, sniffMimeFromName, withDurableChatProjection };