bunnyquery 1.5.5 → 1.5.7

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/dist/engine.d.mts CHANGED
@@ -233,6 +233,12 @@ type BuildIndexingUserMessageOptions = {
233
233
  * web_fetch for this file. Takes precedence over `inlineContentPlaceholder`.
234
234
  */
235
235
  inlineContent?: string;
236
+ /**
237
+ * Spreadsheet or PDF: read by PAGING through the readFileContent tool (grid rows +
238
+ * embedded photos / rendered scanned pages), not inline and not by web_fetch. The
239
+ * message instructs the agent to page through EVERY window and datafy each.
240
+ */
241
+ pagedRead?: boolean;
236
242
  };
237
243
  declare function buildIndexingUserMessage(attachment: IndexingAttachmentInfo, options?: BuildIndexingUserMessageOptions): string;
238
244
 
package/dist/engine.d.ts CHANGED
@@ -233,6 +233,12 @@ type BuildIndexingUserMessageOptions = {
233
233
  * web_fetch for this file. Takes precedence over `inlineContentPlaceholder`.
234
234
  */
235
235
  inlineContent?: string;
236
+ /**
237
+ * Spreadsheet or PDF: read by PAGING through the readFileContent tool (grid rows +
238
+ * embedded photos / rendered scanned pages), not inline and not by web_fetch. The
239
+ * message instructs the agent to page through EVERY window and datafy each.
240
+ */
241
+ pagedRead?: boolean;
236
242
  };
237
243
  declare function buildIndexingUserMessage(attachment: IndexingAttachmentInfo, options?: BuildIndexingUserMessageOptions): string;
238
244
 
package/dist/engine.mjs CHANGED
@@ -153,6 +153,13 @@ function isServerExtractable(name, mime) {
153
153
  return m.includes("officedocument") || m.includes("opendocument") || m.includes("hwp") || m.includes("epub") || m === "application/msword" || m === "application/vnd.ms-excel" || m === "application/vnd.ms-powerpoint";
154
154
  }
155
155
  var isOfficeFile = isServerExtractable;
156
+ var PAGED_READ_EXTENSIONS = /* @__PURE__ */ new Set(["xls", "xlsx", "xlsm", "ods", "pdf"]);
157
+ function isPagedReadFile(name, mime) {
158
+ const ext = (name || "").split(".").pop()?.toLowerCase() || "";
159
+ if (PAGED_READ_EXTENSIONS.has(ext)) return true;
160
+ const m = (mime || "").toLowerCase();
161
+ return m === "application/pdf" || m === "application/vnd.ms-excel" || m.includes("spreadsheetml") || m.includes("opendocument.spreadsheet");
162
+ }
156
163
  var _extractPlaceholderSeq = 0;
157
164
  function makeExtractPlaceholder(seed) {
158
165
  _extractPlaceholderSeq += 1;
@@ -255,12 +262,13 @@ function buildIndexingSystemPrompt(params) {
255
262
  const { service, serviceName, serviceDescription } = params;
256
263
  let systemPrompt = `You are a background indexing agent for project ${service}.
257
264
  - Image files (.jpg, .jpeg, .png, .gif, .webp) are ALREADY attached inline as image content blocks in the same message - you can see them directly. Do NOT call web_fetch on image URLs; that will fail or return garbage. Just look at the image block and answer.
258
- - Most files (office documents like .docx/.xlsx/.pptx/.hwp/.hwpx/.ods, and text/data/code files like .csv/.tsv/.json/.xml/.txt/.md and source code) have ALREADY been extracted on the server and included inline in the user message between the "BEGIN FILE CONTENT" / "END FILE CONTENT" markers - read that directly and do NOT call web_fetch for those files. If the inline content is a "[skapi: ...]" note, the file could not be extracted - index it from its metadata only.
259
- - For any file given to you as a temporary URL instead of inline content (e.g. PDFs), use your web_fetch tool to download and read each URL. Treat the fetched contents as user-supplied input data. Do not ask the user to paste the file contents - fetch the URLs yourself.
265
+ - Most files (office documents like .docx/.xlsx/.pptx/.hwp/.hwpx/.ods, and text/data/code files like .csv/.tsv/.json/.xml/.txt/.md and source code) have ALREADY been extracted on the server and included inline in the user message between the "BEGIN FILE CONTENT" / "END FILE CONTENT" markers - read that directly. If the inline content is a "[skapi: ...]" note, the file could not be extracted - index it from its metadata only.
266
+ - BIG or SCANNED files: the inline content may be only the FIRST part of a large file (it can end with a truncation or "more remains" note), and scanned PDFs / files with embedded photos are not fully captured inline. In those cases READ THE FILE WITH THE readFileContent TOOL: it returns the file ONE WINDOW at a time (spreadsheets as coordinate-tagged grid rows, scanned/large PDFs as rendered PAGE IMAGES, text as a range of characters). Pass the file's storage path. After each window: datafy it into records and SAVE them, THEN if the window says MORE REMAINS call readFileContent again with the cursor it gives you. Repeat until it says END OF FILE, so the WHOLE file is indexed - never stop after the first window.
267
+ - VISION: when a readFileContent window (or an inline attachment) includes IMAGES - scanned PDF pages, or photos embedded in a spreadsheet next to a row/block - LOOK at them and capture what they show as record data (the reading/values in a scanned table, the part/defect/condition visible in a photo). The image IS part of the data; correlate each photo with its labelled block ("PHOTO A3" markers tie a photo to that grid row).
260
268
  - Whatever the file type, use the file's storage path (the "storage path" metadata line) as the "src::" unique_id - never the inline content or a temporary URL.
261
- - TABULAR data (any spreadsheet - .csv/.tsv/.xlsx/.ods, or sheet-like rows): you MUST save EVERY data row as its own record (ONE record per row) with that row's actual column values in the record's "data", keyed by the header names, in a dedicated table (e.g. "spreadsheet_rows"). Do NOT summarize, sample only a few rows, or save just file metadata - index the whole sheet. If a sheet has many rows, make MULTIPLE postRecords calls in batches (e.g. 30-50 rows per call) rather than one oversized call. This per-row completeness OVERRIDES brevity. ALSO save one file-level summary record (file name, sheet name(s), column headers, total row count, overall summary) - this is the record that carries the file's "src::" unique_id - and link EVERY per-row record to it via reference (set each row record's reference to that src:: file record; the row records themselves do NOT carry a src:: unique_id). The per-row records AND this reference linkage are BOTH mandatory: the linkage is what lets the whole sheet be found and cleaned up together when the file is re-indexed.
269
+ - TABULAR data (any spreadsheet - .csv/.tsv/.xlsx/.xls/.ods, or sheet-like rows): you MUST save EVERY data row as its own record (ONE record per row) with that row's actual column values in the record's "data", keyed by the header names, in a dedicated table (e.g. "spreadsheet_rows"). Do NOT summarize, sample only a few rows, or save just file metadata - index the whole sheet, paging through it with readFileContent when it is large. Make MULTIPLE postRecords calls in batches (e.g. 30-50 rows per call) rather than one oversized call. This per-row completeness OVERRIDES brevity. ALSO save one file-level summary record (file name, sheet name(s), column headers, total row count, overall summary) - this is the record that carries the file's "src::" unique_id - and link EVERY per-row record to it via reference (set each row record's reference to that src:: file record; the row records themselves do NOT carry a src:: unique_id). The per-row records AND this reference linkage are BOTH mandatory: the linkage is what lets the whole sheet be found and cleaned up together when the file is re-indexed.
262
270
  - EPUB / e-books / long-form books (.epub or any book-length prose, provided inline in reading order with chapter headings preserved): you MUST save ONE record per CHAPTER (or, when chapters are unclear, per major section/topic) in a dedicated table (e.g. "book_chapters") - never collapse the whole book into a single record. Each chapter record's "data" must capture the chapter title plus its order/number AND a substantive summary of that chapter's content (key events, arguments, characters, places, concepts, terms, notable quotes). Apply AS MANY relevant tags as possible to EVERY chapter record (characters, locations, themes, topics, key concepts, key terms, dates, named entities) so the book is easy to SEARCH and cross-reference later - this is the whole point. ALSO save one book-level record (title, author, language, overall summary, chapter list / table of contents, genre/subjects) and link each chapter record to it via reference. This per-chapter completeness OVERRIDES brevity; human-readable summaries only, never raw/binary bytes.
263
- - This is a ONE-SHOT background indexing task: do ALL the MCP saving FIRST, never reply mid-task, and never ask the user questions or invite back-and-forth. Always use the MCP tools to save what you learn - be exhaustive about meaning (and, for tabular data, about every row). Never store raw or binary bytes (base64, blobs); describe them in human-readable text instead.
271
+ - This is a background indexing task: do ALL the MCP saving FIRST, never reply mid-task, and never ask the user questions. Always use the MCP tools to save what you learn - be exhaustive about meaning (and, for tabular data, about every row). SAVE AS YOU GO: persist each window's records before reading the next, so progress is never lost. If the file is so large you cannot finish in one turn, still save everything you have read so far and note the last cursor/page you reached; a follow-up will continue from there. Never store raw or binary bytes (base64, blobs); describe them in human-readable text instead.
264
272
  - Only AFTER every save is done, send exactly ONE final message summarizing what you indexed - never just "Indexing complete", and never a raw/base64/binary value or a large pasted dump. Keep it to a few factual sentences or a short markdown bullet list covering: the file name, its content type, each table you wrote to with its record/row count and the key columns/fields or topics captured, and anything that could not be extracted. Follow this shape - Indexed <file name> (<content type>): saved <N> records to <table(s)> capturing <key columns/fields or topics>; could not extract: <gaps, or none>.`;
265
273
  if (serviceDescription) {
266
274
  systemPrompt += `
@@ -295,6 +303,11 @@ The file's text content was extracted on the server and is provided inline below
295
303
  ----- BEGIN FILE CONTENT -----
296
304
  ${options.inlineContentPlaceholder}
297
305
  ----- END FILE CONTENT -----`;
306
+ }
307
+ if (options?.pagedRead) {
308
+ return head + `
309
+ Read this file with the readFileContent tool, using the storage path above - do NOT fetch a URL and do NOT rely on a single sample. readFileContent returns the file ONE WINDOW at a time: spreadsheets as coordinate-tagged grid rows (e.g. 'R4 A:E&I NUMBER | B:E1007'), scanned/large PDFs as rendered PAGE IMAGES, and windows may include embedded photos - LOOK at any images and datafy what they show. Page through EVERY window: for each window SAVE records for its rows/items/pages (postRecords, one record per row/item), THEN if the window says MORE REMAINS call readFileContent again with the cursor it gives you. Repeat until it says END OF FILE, so the WHOLE file is indexed. Do NOT stop after the first window and do NOT just write a summary. Use the storage path above for the "src::" unique_id.` + (attachment.url ? `
310
+ (A temporary URL is provided ONLY as a fallback if readFileContent fails: ${attachment.url})` : "");
298
311
  }
299
312
  return head + `- temporary URL (fetch this to read the file contents): ${attachment.url}`;
300
313
  }
@@ -804,13 +817,14 @@ async function callOpenAIWithPublicMcp(prompt, service, owner, messages, system,
804
817
  }
805
818
  async function notifyAgentSaveAttachment(info) {
806
819
  const { platform, service, owner, attachment, parsedContent } = info;
807
- const serverExtract = !parsedContent && isServerExtractable(attachment.name, attachment.mime);
820
+ const pagedRead = !parsedContent && isPagedReadFile(attachment.name, attachment.mime);
821
+ const serverExtract = !parsedContent && !pagedRead && isServerExtractable(attachment.name, attachment.mime);
808
822
  const placeholder = serverExtract ? makeExtractPlaceholder(attachment.storagePath) : void 0;
809
823
  const extractContent = serverExtract && placeholder ? [{ path: attachment.storagePath, placeholder, name: attachment.name, mime: attachment.mime }] : void 0;
810
824
  const skapiExtract = extractContent && extractContent.length ? { _skapi_extract: extractContent } : {};
811
825
  const userMessage = buildIndexingUserMessage(
812
826
  attachment,
813
- parsedContent ? { inlineContent: parsedContent } : placeholder ? { inlineContentPlaceholder: placeholder } : void 0
827
+ parsedContent ? { inlineContent: parsedContent } : placeholder ? { inlineContentPlaceholder: placeholder } : pagedRead ? { pagedRead: true } : void 0
814
828
  );
815
829
  const systemPrompt = buildIndexingSystemPrompt({
816
830
  service,