@retinue/agentkit 0.1.0

package/dist/files/index.js

@@ -0,0 +1,338 @@
+/**
+ * The attachment lifecycle — `docs/05-knowledge-and-documents.md`, REQ-026 (#129).
+ *
+ * The ports are in `persistence/`; what lives here is the sequencing that makes them safe together, and it
+ * is the part that cannot be a rule someone remembers:
+ *
+ * - an upload is two writes, metadata then bytes, and the window between them is where orphans live
+ * - a declared size is a claim, and the only real defence is a cap enforced while reading
+ * - object storage cannot join a database transaction, so deletion is scheduled rather than performed
+ */
+import { AgentPlatformError } from "../core/errors.js";
+import { asId } from "../core/ids.js";
+/**
+ * The ceiling on a signed URL's life.
+ *
+ * A signed URL is a bearer token in a query string: it goes into logs, into a browser's history, and — if a
+ * tool result ever carried one — into the run event log, where anyone who can read the conversation can read
+ * it long after the check that produced it. #118 refused to return one from a tool for exactly that reason.
+ *
+ * Fifteen minutes is long enough to load a document and short enough that a leaked URL is usually already
+ * dead. `signedReadUrl` clamps rather than trusting the caller.
+ */
+export const MAX_SIGNED_URL_SECONDS = 900;
+/** A conservative default set. A deployment narrows or widens it deliberately. */
+export const DEFAULT_UPLOAD_LIMITS = {
+    maxBytes: 25 * 1024 * 1024,
+    allowedMediaTypes: [
+        "image/png",
+        "image/jpeg",
+        "image/webp",
+        "image/gif",
+        "application/pdf",
+        "text/plain",
+        "text/csv",
+        "text/markdown",
+    ],
+    signedUrlSeconds: 300,
+};
+const refuse = (code, message) => new AgentPlatformError({ code, message, retryable: false });
+/**
+ * The cheap early refusal — AC-2's first half.
+ *
+ * *"Refused before the bytes are accepted, with the limit stated."* The limit is in the message because an
+ * error saying "too large" sends someone to guess; one saying "25 MB" does not.
+ *
+ * **This check can only ever see the declared size.** A client that declares 1 KB and sends 1 GB passes it,
+ * which is why `streamWithCap` exists and is not optional.
+ */
+export const validateUpload = (input, limits) => {
+    // Normalised, because a browser sends `text/plain; charset=utf-8` and a bare-string comparison would
+    // refuse it — a refusal the user cannot act on, for a file that is fine.
+    const mediaType = input.mediaType.split(";")[0]?.trim().toLowerCase() ?? "";
+    if (!limits.allowedMediaTypes.includes(mediaType))
+        throw refuse("invalid_input", `${mediaType || "that file type"} is not accepted. Accepted types: ${limits.allowedMediaTypes.join(", ")}`);
+    if (!Number.isFinite(input.declaredBytes) || input.declaredBytes <= 0)
+        throw refuse("invalid_input", "the file's size must be stated and greater than zero");
+    if (input.declaredBytes > limits.maxBytes)
+        throw refuse("invalid_input", `that file is ${input.declaredBytes} bytes and the limit is ${limits.maxBytes} bytes`);
+};
+/**
+ * AC-2's second half, and the one that holds.
+ *
+ * Wraps a byte stream so it **stops** at the cap rather than reading to the end and then complaining. The
+ * difference is the whole point: reading a hostile 1 GB body into memory and *then* returning an error is a
+ * denial of service that happens to report itself politely.
+ *
+ * `safefetch.py` in ShareFlow exists for the same reason, and says it plainly: *"the callers parse whole
+ * documents in memory, so an unbounded download is a denial-of-service vector on a container capped at
+ * 600 MB."*
+ */
+export const streamWithCap = async function* (bytes, maxBytes) {
+    let seen = 0;
+    for await (const chunk of bytes) {
+        seen += chunk.byteLength;
+        if (seen > maxBytes) {
+            // Thrown from inside the generator, so the consumer stops pulling and the producer is cancelled. The
+            // partial object is the adapter's to discard — `putFile` says so.
+            throw refuse("invalid_input", `the file exceeds the ${maxBytes} byte limit`);
+        }
+        yield chunk;
+    }
+};
+/**
+ * The attachment lifecycle.
+ *
+ * Every method takes an `ExecutionContext`, and entitlement to a file *is* entitlement to its conversation —
+ * so there is no second permission model to keep in step with the first.
+ */
+export const createFileService = (deps) => {
+    const limits = deps.limits ?? DEFAULT_UPLOAD_LIMITS;
+    const clock = deps.clock ?? (() => new Date().toISOString());
+    const newKey = deps.contentKey ?? (() => `f_${crypto.randomUUID()}`);
+    const newId = deps.fileId ?? (() => `file_${crypto.randomUUID()}`);
+    return {
+        limits,
+        /**
+         * Upload: validate, record `pending`, write bytes, then move to `stored`.
+         *
+         * The order is the point, and the alternative is worse in a specific way. Writing bytes first and
+         * metadata second means a crash between them leaves an object nothing references — invisible, and
+         * billed for. Metadata first means a crash leaves a row in `pending`, which reconciliation can see and
+         * a user cannot. **An orphan you can find beats an orphan you cannot.**
+         */
+        async upload(context, input) {
+            validateUpload({ mediaType: input.mediaType, declaredBytes: input.declaredBytes }, limits);
+            // Before anything is written. An unentitled upload that got as far as creating a `pending` row would
+            // put a filename of someone else's choosing into a conversation they cannot read.
+            const decision = await deps.authorization.can(context, "write", {
+                type: "conversation",
+                id: input.conversationId,
+            });
+            if (!decision.allow)
+                throw refuse("not_found", "no such conversation");
+            const id = asId(newId());
+            const contentKey = newKey();
+            const createdAt = clock();
+            const pending = {
+                id,
+                conversationId: input.conversationId,
+                filename: input.filename,
+                mediaType: input.mediaType,
+                byteSize: input.declaredBytes,
+                contentKey,
+                state: "pending",
+                uploadedBy: context.principalId,
+                createdAt,
+            };
+            await deps.metadata.create({ tenantId: context.tenantId, file: pending });
+            // A failure here leaves the row in `pending`, deliberately and with no cleanup. That row is the
+            // evidence reconciliation uses to find a partial object; deleting it would hide exactly the case this
+            // ordering exists to make visible.
+            const stored = await deps.content.putFile({
+                tenantId: context.tenantId,
+                contentKey,
+                mediaType: input.mediaType,
+                bytes: streamWithCap(input.bytes, limits.maxBytes),
+                maxBytes: limits.maxBytes,
+            });
+            const moved = await deps.metadata.transition({
+                tenantId: context.tenantId,
+                id,
+                from: "pending",
+                to: "stored",
+                at: clock(),
+                checksum: stored.checksum,
+            });
+            if (!moved.moved) {
+                // Something else moved it — a conversation deleted mid-upload is the realistic case. The bytes are
+                // now unreferenced, so they are removed here rather than left for the sweep.
+                await deps.content.deleteFile({ tenantId: context.tenantId, contentKey });
+                throw refuse("conflict", "that conversation was deleted while the file was uploading");
+            }
+            // Extraction is *requested*, not performed — AC-2 of #131. Deliberately after the transition to
+            // `stored`, so a worker picking the job up immediately finds a file it can read.
+            //
+            // The `catch` is not laziness. The upload has succeeded; the bytes and the row are both durable. An
+            // unreachable queue must not turn that into a failed upload, and the extraction sweep exists precisely
+            // to pick up what a lost enqueue dropped.
+            if (deps.requestExtraction !== undefined) {
+                try {
+                    await deps.requestExtraction({
+                        tenantId: context.tenantId,
+                        fileId: id,
+                        mediaType: input.mediaType,
+                    });
+                }
+                catch (error) {
+                    (deps.log ?? (() => { }))("extraction request failed after upload", { id, error });
+                }
+            }
+            // The size as *written*, not as declared. They differ when a client lies, and the record should say
+            // what is actually there.
+            return { ...pending, state: "stored", byteSize: stored.byteSize, checksum: stored.checksum };
+        },
+        /** AC-3: only through the owning conversation, and a foreign file is `not_found`, never `forbidden`. */
+        async get(context, id) {
+            const file = await deps.metadata.get({ tenantId: context.tenantId, id });
+            // Indistinguishable from absent, so the endpoint cannot be used to probe which ids exist — the same
+            // rule ShareFlow's `getPost` states: "the two must be indistinguishable, or the endpoint confirms the
+            // existence of other tenants' ids."
+            if (file === null || file.deletedAt !== undefined)
+                throw refuse("not_found", "no such file");
+            if (file.state !== "stored")
+                throw refuse("not_found", "that file is not available");
+            // The decision is about the *conversation*, so there is no second permission model to keep in step
+            // with the first: whoever may read the thread may read what is attached to it.
+            const decision = await deps.authorization.can(context, "read", {
+                type: "conversation",
+                id: file.conversationId,
+            });
+            // `not_found` again, and the same message: a `forbidden` here would confirm the file exists to
+            // exactly the caller who is not allowed to know that.
+            if (!decision.allow)
+                throw refuse("not_found", "no such file");
+            return file;
+        },
+        /**
+         * A short-lived URL, or a stream when the adapter proxies.
+         *
+         * The expiry is clamped rather than trusted: a caller asking for a day gets fifteen minutes. AC-6 is
+         * about what is *reachable*, and a caller's optimism is not a reason to widen it.
+         */
+        async signedReadUrl(context, id) {
+            const file = await this.get(context, id);
+            return deps.content.signedUrl({
+                tenantId: context.tenantId,
+                contentKey: file.contentKey,
+                expiresInSeconds: Math.min(limits.signedUrlSeconds, MAX_SIGNED_URL_SECONDS),
+            });
+        },
+        /** The proxied read, for an adapter that cannot sign — and the fallback when one can. */
+        async read(context, id) {
+            const file = await this.get(context, id);
+            const bytes = await deps.content.readFile({
+                tenantId: context.tenantId,
+                contentKey: file.contentKey,
+            });
+            if (bytes === null)
+                // Metadata says `stored` and the bytes are gone: the other orphan direction, seen from the read
+                // path. Reported as what it is rather than as an empty file, because an empty file is something a
+                // caller might reasonably use.
+                throw refuse("not_found", "that file's contents are missing");
+            return bytes;
+        },
+        /**
+         * The listing is authorised on the conversation before it runs, not filtered afterwards.
+         *
+         * Filtering results would mean the query ran, which for an unentitled caller is a query whose *shape*
+         * — a page count, a cursor, a timing difference — still answers "does this conversation have files".
+         */
+        async listForConversation(context, input) {
+            const decision = await deps.authorization.can(context, "read", {
+                type: "conversation",
+                id: input.conversationId,
+            });
+            if (!decision.allow)
+                throw refuse("not_found", "no such conversation");
+            return deps.metadata.listByConversation({ tenantId: context.tenantId, ...input });
+        },
+        /**
+         * AC-4: deleting a conversation removes the metadata and schedules the bytes.
+         *
+         * Two steps, and they cannot be one: object storage does not join a database transaction. So the
+         * metadata moves to `deleting` — gone from the user's view — and `sweepDeletions` removes the bytes
+         * afterwards. The intermediate state is named rather than pretended away.
+         */
+        async deleteConversationFiles(context, conversationId) {
+            return deps.metadata.scheduleConversationDeletion({
+                tenantId: context.tenantId,
+                conversationId,
+                at: clock(),
+            });
+        },
+        /**
+         * Remove the bytes of files marked `deleting`.
+         *
+         * Bytes first, then the state — the opposite order from upload, and for the mirrored reason. Marking
+         * `deleted` first means a crash leaves an object nothing references and nothing will look for again.
+         * Deleting bytes first means a crash leaves the row in `deleting`, and the next sweep retries it;
+         * `deleteFile` is idempotent so the retry costs nothing.
+         */
+        async sweepDeletions(context, input) {
+            const page = await deps.metadata.listByState({
+                tenantId: context.tenantId,
+                state: "deleting",
+                olderThan: input.olderThan,
+                limit: input.limit,
+            });
+            let deleted = 0;
+            let failed = 0;
+            for (const file of page.items) {
+                try {
+                    await deps.content.deleteFile({ tenantId: context.tenantId, contentKey: file.contentKey });
+                    await deps.metadata.transition({
+                        tenantId: context.tenantId,
+                        id: file.id,
+                        from: "deleting",
+                        to: "deleted",
+                        at: clock(),
+                    });
+                    deleted += 1;
+                }
+                catch {
+                    // Counted, not thrown. One unreachable object must not stop the sweep — the row stays `deleting`
+                    // and the next run retries it, which is the whole reason bytes are deleted before the state moves.
+                    failed += 1;
+                }
+            }
+            return { deleted, failed };
+        },
+    };
+};
+/**
+ * AC-5: detect and report orphans.
+ *
+ * **Reports, never deletes**, and that is the AC's own wording rather than caution for its own sake: a
+ * reconciliation job that deletes is a job that can delete a file whose metadata write is merely slow. The
+ * threshold makes that unlikely; deleting on the strength of "unlikely" is how data goes missing.
+ *
+ * Both directions are covered, and only one of them is visible to the metadata store — bytes with no
+ * metadata can only be found by listing the objects, which is why `FileContentStore.listObjects` exists.
+ */
+export const reconcileFiles = async (context, deps, input) => {
+    const scope = { tenantId: context.tenantId };
+    const [pending, deleting] = await Promise.all([
+        deps.metadata.listByState({ ...scope, state: "pending", olderThan: input.olderThan, limit: input.limit }),
+        deps.metadata.listByState({ ...scope, state: "deleting", olderThan: input.olderThan, limit: input.limit }),
+    ]);
+    const objects = await deps.content.listObjects({ ...scope, limit: input.limit });
+    const known = new Set();
+    const missingContent = [];
+    const storedKeys = new Set(objects.items.map((o) => o.contentKey));
+    // Every state, not only the live ones: an object referenced by a `deleting` row is not an orphan, it is
+    // a sweep that has not run yet. Reporting it as orphaned would send someone to delete something already
+    // scheduled for deletion, and the report would never come clean.
+    for (const state of ["pending", "stored", "deleting"]) {
+        const page = await deps.metadata.listByState({
+            ...scope,
+            state,
+            // Everything, not only the old: this pass is building the set of referenced keys, and a recent file
+            // is still a reference.
+            olderThan: new Date(8_640_000_000_000).toISOString(),
+            limit: input.limit,
+        });
+        for (const file of page.items) {
+            known.add(file.contentKey);
+            if (state === "stored" && !storedKeys.has(file.contentKey))
+                missingContent.push(file.id);
+        }
+    }
+    return {
+        stuckPending: pending.items.map((f) => f.id),
+        stuckDeleting: deleting.items.map((f) => f.id),
+        orphanedObjects: objects.items.filter((o) => !known.has(o.contentKey)).map((o) => o.contentKey),
+        missingContent,
+    };
+};
+//# sourceMappingURL=index.js.map

package/dist/files/read-tool.d.ts

@@ -0,0 +1,81 @@
+/**
+ * `read_attachment` and `list_attachments` — the explicit, bounded read step (#130, AC-3).
+ *
+ * Attaching a file puts a *reference* in context. Nothing loads its content, and that is the whole design:
+ * "referenced, not injected" only means something if bringing content in is a separate, deliberate act.
+ * These two tools are that act, and both are bounded on purpose.
+ *
+ * **The bound is the point, not a nicety.** A read step with no ceiling reintroduces exactly what the
+ * reference part avoided — one call and a 100 MB file is in the transcript, permanently, because a tool
+ * result is a message part. So a read returns at most `MAX_READ_BYTES`, says so, and reports the offset to
+ * continue from. The model can page; it cannot flood.
+ *
+ * **Reads go through `FileService`, not the stores.** That is where AC-3's entitlement check lives, and
+ * duplicating it here would be a second permission model to keep in step with the first. A tool that reached
+ * for `FileContentStore` directly would be tenant-scoped but not conversation-scoped, which is the exact hole
+ * #129 closed.
+ */
+import type { Tool } from "../tools/index.js";
+import type { FileService } from "./index.js";
+/**
+ * The most one call returns.
+ *
+ * 32 KiB is roughly 8k tokens — a large but survivable share of a context window, and small enough that a
+ * model paging a long document has to decide it is worth the budget rather than getting there by accident.
+ */
+export declare const MAX_READ_BYTES: number;
+/**
+ * Media types this tool will decode as text.
+ *
+ * An exact list, for the same reason `DEFAULT_UPLOAD_LIMITS` uses one: `text/*` is how a `text/html` payload
+ * with a script becomes "just text". A PDF or an image is refused *with the reason and the alternative*, so
+ * the model redirects instead of retrying — a refusal that does not say what to do next produces a loop.
+ */
+export declare const READABLE_AS_TEXT: readonly string[];
+export type ReadAttachmentInput = {
+    readonly fileId: string;
+    readonly offset?: number;
+    readonly maxBytes?: number;
+};
+export type ReadAttachmentOutput = {
+    readonly fileId: string;
+    readonly filename: string;
+    readonly mediaType: string;
+    readonly text: string;
+    readonly byteOffset: number;
+    readonly bytesReturned: number;
+    readonly totalBytes: number;
+    /** True when there is more to read. The model pages from `nextOffset` rather than guessing. */
+    readonly truncated: boolean;
+    readonly nextOffset?: number;
+};
+/**
+ * Read a bounded window of an attachment.
+ *
+ * The window is taken by consuming the stream and discarding what precedes the offset, rather than by
+ * assembling the whole file and slicing it: a 100 MB file must not be held in memory to read its first
+ * kilobyte, which is the mistake that makes a "bounded" read unbounded in the only dimension that matters.
+ */
+export declare const createReadAttachmentTool: (deps: {
+    readonly files: FileService;
+}) => Tool;
+export type ListAttachmentsOutput = {
+    readonly attachments: readonly {
+        readonly fileId: string;
+        readonly filename: string;
+        readonly mediaType: string;
+        readonly size: string;
+    }[];
+    readonly nextCursor?: string;
+};
+/**
+ * The rest of the list, when the context section capped it.
+ *
+ * The section names this tool rather than silently truncating, because a list that ends without saying so is
+ * a model concluding a file is not there.
+ */
+export declare const createListAttachmentsTool: (deps: {
+    readonly files: FileService;
+    readonly conversationId: string;
+}) => Tool;
+//# sourceMappingURL=read-tool.d.ts.map

package/dist/files/read-tool.js

@@ -0,0 +1,163 @@
+/**
+ * `read_attachment` and `list_attachments` — the explicit, bounded read step (#130, AC-3).
+ *
+ * Attaching a file puts a *reference* in context. Nothing loads its content, and that is the whole design:
+ * "referenced, not injected" only means something if bringing content in is a separate, deliberate act.
+ * These two tools are that act, and both are bounded on purpose.
+ *
+ * **The bound is the point, not a nicety.** A read step with no ceiling reintroduces exactly what the
+ * reference part avoided — one call and a 100 MB file is in the transcript, permanently, because a tool
+ * result is a message part. So a read returns at most `MAX_READ_BYTES`, says so, and reports the offset to
+ * continue from. The model can page; it cannot flood.
+ *
+ * **Reads go through `FileService`, not the stores.** That is where AC-3's entitlement check lives, and
+ * duplicating it here would be a second permission model to keep in step with the first. A tool that reached
+ * for `FileContentStore` directly would be tenant-scoped but not conversation-scoped, which is the exact hole
+ * #129 closed.
+ */
+import { AgentPlatformError } from "../core/errors.js";
+import { asId } from "../core/ids.js";
+import { defineTool } from "../tools/define.js";
+import { MAX_LISTED_ATTACHMENTS, humanSize, truncateFilename } from "./context.js";
+/**
+ * The most one call returns.
+ *
+ * 32 KiB is roughly 8k tokens — a large but survivable share of a context window, and small enough that a
+ * model paging a long document has to decide it is worth the budget rather than getting there by accident.
+ */
+export const MAX_READ_BYTES = 32 * 1024;
+/**
+ * Media types this tool will decode as text.
+ *
+ * An exact list, for the same reason `DEFAULT_UPLOAD_LIMITS` uses one: `text/*` is how a `text/html` payload
+ * with a script becomes "just text". A PDF or an image is refused *with the reason and the alternative*, so
+ * the model redirects instead of retrying — a refusal that does not say what to do next produces a loop.
+ */
+export const READABLE_AS_TEXT = [
+    "text/plain",
+    "text/csv",
+    "text/markdown",
+    "application/json",
+];
+const refuse = (code, message) => new AgentPlatformError({ code, message, retryable: false });
+/**
+ * Read a bounded window of an attachment.
+ *
+ * The window is taken by consuming the stream and discarding what precedes the offset, rather than by
+ * assembling the whole file and slicing it: a 100 MB file must not be held in memory to read its first
+ * kilobyte, which is the mistake that makes a "bounded" read unbounded in the only dimension that matters.
+ */
+export const createReadAttachmentTool = (deps) => defineTool({
+    name: "read_attachment",
+    label: "Read attachment",
+    description: `Read up to ${MAX_READ_BYTES} bytes of a text attachment, from an optional byte offset. ` +
+        "Attachments are referenced in context but never loaded; this is the only way to see their contents.",
+    category: "files",
+    effect: "read",
+    inputSchema: {
+        type: "object",
+        required: ["fileId"],
+        additionalProperties: false,
+        properties: {
+            fileId: { type: "string", description: "The id from the attachment reference, without the `file:` prefix." },
+            offset: { type: "integer", minimum: 0, description: "Byte offset to start from. Defaults to 0." },
+            maxBytes: {
+                type: "integer",
+                minimum: 1,
+                maximum: MAX_READ_BYTES,
+                description: `At most ${MAX_READ_BYTES}. A larger value is clamped, not refused.`,
+            },
+        },
+    },
+    async execute(input, context) {
+        const id = asId(input.fileId.replace(/^file:/, ""));
+        // Entitlement, existence and state all come from the service, so a tool cannot see a file a user
+        // cannot.
+        const file = await deps.files.get(context, id);
+        if (!READABLE_AS_TEXT.includes(file.mediaType.split(";")[0]?.trim().toLowerCase() ?? ""))
+            throw refuse("invalid_input", `${file.filename} is ${file.mediaType}, which this tool cannot decode as text. ` +
+                "Use a document-extraction tool for that type.");
+        const offset = Math.max(0, Math.floor(input.offset ?? 0));
+        // Clamped rather than refused: a model asking for more than the ceiling has made a reasonable request
+        // that the platform answers with less, and refusing it would just be answered by a retry.
+        const limit = Math.min(Math.max(1, Math.floor(input.maxBytes ?? MAX_READ_BYTES)), MAX_READ_BYTES);
+        const collected = [];
+        let seen = 0;
+        let taken = 0;
+        for await (const chunk of await deps.files.read(context, id)) {
+            // Past the window: stop pulling. The generator is abandoned here, which cancels the underlying read
+            // rather than draining the rest of a large object for bytes nobody asked for.
+            if (taken >= limit)
+                break;
+            const chunkStart = seen;
+            seen += chunk.byteLength;
+            if (seen <= offset)
+                continue;
+            const from = Math.max(0, offset - chunkStart);
+            const slice = chunk.subarray(from, from + (limit - taken));
+            collected.push(slice);
+            taken += slice.byteLength;
+        }
+        const joined = new Uint8Array(taken);
+        let at = 0;
+        for (const slice of collected) {
+            joined.set(slice, at);
+            at += slice.byteLength;
+        }
+        const end = offset + taken;
+        // `file.byteSize` is the size as *written* (#129), not as declared, so "is there more" is answered
+        // against what is actually stored.
+        const truncated = end < file.byteSize;
+        return {
+            fileId: id,
+            filename: file.filename,
+            mediaType: file.mediaType,
+            // `fatal: false` on purpose: a window boundary can land mid-codepoint, and a decode error would turn
+            // a legitimate paged read into a failure. The replacement character is the honest answer.
+            text: new TextDecoder("utf-8", { fatal: false }).decode(joined),
+            byteOffset: offset,
+            bytesReturned: taken,
+            totalBytes: file.byteSize,
+            truncated,
+            ...(truncated ? { nextOffset: end } : {}),
+        };
+    },
+});
+/**
+ * The rest of the list, when the context section capped it.
+ *
+ * The section names this tool rather than silently truncating, because a list that ends without saying so is
+ * a model concluding a file is not there.
+ */
+export const createListAttachmentsTool = (deps) => defineTool({
+    name: "list_attachments",
+    label: "List attachments",
+    description: "List this conversation's attachments as references. Contents are not returned.",
+    category: "files",
+    effect: "read",
+    inputSchema: {
+        type: "object",
+        additionalProperties: false,
+        properties: { cursor: { type: "string", description: "From a previous call's `nextCursor`." } },
+    },
+    async execute(input, context) {
+        const page = await deps.files.listForConversation(context, {
+            conversationId: asId(deps.conversationId),
+            limit: MAX_LISTED_ATTACHMENTS,
+            ...(input.cursor === undefined ? {} : { cursor: input.cursor }),
+        });
+        return {
+            // The same fields the reference line carries, and no others. A listing that returned more than the
+            // reference does would be a second, richer view of an attachment for no reason — and the place a
+            // content field would eventually be added.
+            attachments: page.items.map((file) => ({
+                fileId: file.id,
+                filename: truncateFilename(file.filename),
+                mediaType: file.mediaType,
+                size: humanSize(file.byteSize),
+            })),
+            ...(page.nextCursor === undefined ? {} : { nextCursor: page.nextCursor }),
+        };
+    },
+});
+//# sourceMappingURL=read-tool.js.map