bunnyquery 1.4.0 → 1.4.3

package/README.md

@@ -24,6 +24,9 @@ you can build your own chat UI on top of it. See
   first load and on scroll-up.
 - **Attachments** — drag-and-drop files and folders, per-file upload status
   (uploading / failed / indexed), and overflow collapsing for large batches.
+  Images are read with vision/OCR, Office/text/code files are extracted
+  server-side, and PDFs are fetched by the model — see
+  [Supported file types](#supported-file-types).
 - **Attachment parser plugins** — register a client-side parser so the widget
   extracts text in the browser from formats the model can't otherwise read, and
   indexes it directly. See [Attachment parser plugins](#attachment-parser-plugins).
@@ -137,12 +140,79 @@ BunnyQuery.logout();
 > instance rather than re-mounting. On a successful mount it logs its version, e.g.
 > `[bunnyquery] v1.3.5`.
 
+## Supported file types
+
+When a user attaches a file, BunnyQuery makes its contents available to the AI
+automatically — detected by extension (with a MIME-type fallback), nothing to
+configure. There are three paths, plus a couple of caveats.
+
+### 1. Images — read directly by the model (vision + OCR)
+
+`.jpg` · `.jpeg` · `.png` · `.gif` · `.webp`
+
+The image is attached to the request inline, so the model both **describes the
+picture** and **reads any text in it (OCR)**. Works on both Claude and OpenAI.
+Only images referenced in the **most recent** message are inlined (older links
+may have expired).
+
+### 2. Documents, data & code — extracted on the server (inlined as text)
+
+The skapi proxy downloads the file, extracts its text **server-side**, and
+inlines that text into the request — the model reads it directly, with no
+fetching. This keeps indexing consistent across model providers.
+
+**Office & e-book** (binary/zip, parsed):
+`.docx` · `.xlsx` · `.pptx` · `.hwp` · `.hwpx` · `.ods` · `.odt` · `.odp` · `.epub`
+
+**Text, data, markup & source code** (decoded as text; `.html`/`.htm` have their
+tags stripped):
+
+```
+.csv .tsv .tab .txt .text .log .md .markdown .rst .json .ndjson .jsonl .geojson
+.xml .yaml .yml .toml .ini .conf .cfg .properties .env .rtf .html .htm
+.js .mjs .cjs .ts .tsx .jsx .py .rb .go .rs .java .kt .c .h .cpp .cc .hpp .cs
+.php .swift .sh .bash .zsh .sql .css .scss .less .vue .svelte .tex .srt .vtt
+```
+
+Plus a **MIME fallback**: any file whose content type is text-like (`text/*`,
+`application/json`, `application/xml`, `*+json`, `*+xml`, `*+yaml`, …) is decoded
+even when its extension isn't in the list above.
+
+Encoding is auto-detected — UTF-8 (BOM-aware) → CP949/EUC-KR (Korean) → Latin-1.
+Extracted text is capped at **200,000 characters**; longer files are truncated
+with a `...[truncated for length; original N characters]` marker.
+
+### 3. PDFs & other links — fetched by the model
+
+`.pdf` (and any file that is neither an image nor server-extractable) is handed
+to the model as a temporary link, which it opens with its built-in web tool:
+**Claude** via `web_fetch`, **OpenAI** via `web_search` (external web access is
+enabled). Both can open and read PDFs, so PDFs work on either provider.
+
+> A provider's web tool opens document/page-style URLs such as PDFs, but not
+> necessarily a bare *data-file* download (e.g. a raw `.csv`/`.tsv` link). That's
+> why those data formats are extracted **server-side** (path 2 above) instead of
+> being left to the model to fetch.
+
+### Caveats
+
+- **Legacy / macro Office** — `.doc` `.xls` `.ppt` (legacy binary) and `.docm`
+  `.xlsm` `.pptm` (macro-enabled) have no reliable server-side reader. They
+  upload fine but are indexed from **metadata only**; re-save as
+  `.docx` / `.xlsx` / `.pptx` (or PDF) to capture their contents.
+- **Anything else** — a format covered by none of the above is indexed from its
+  metadata. To support it, register your own
+  [Attachment parser plugin](#attachment-parser-plugins) — it runs in the browser
+  and feeds parsed text straight into indexing.
+
 ## Attachment parser plugins
 
-By default the chat agent reads most uploads via the model's `web_fetch` tool
-(text, CSV, PDF, …), and Office/OpenDocument/EPUB files are extracted on the
-server. For any format that can be read by **neither** (e.g. a proprietary
-binary format), register a **parser plugin**: it runs in the browser, turns the
+By default the chat agent reads images with vision/OCR, extracts
+Office/OpenDocument/EPUB and text/data/code files on the server, and lets the
+model fetch PDFs with its built-in web tool (`web_fetch` on Claude, `web_search`
+on OpenAI) — see [Supported file types](#supported-file-types). For any format
+read by **none** of these (e.g. a proprietary binary format), register a
+**parser plugin**: it runs in the browser, turns the
 uploaded file into text (or an HTML string), and the widget sends that content
 **inline** for indexing — no `web_fetch`, no server extraction for that file.
 

package/bunnyquery.js

@@ -79,34 +79,74 @@
     "odp",
     "epub"
   ]);
-  var WEB_FETCHABLE_TEXT_EXTENSIONS = /* @__PURE__ */ new Set([
+  var TEXT_FILE_EXTENSIONS = /* @__PURE__ */ new Set([
     "csv",
     "tsv",
     "tab",
     "txt",
     "text",
+    "log",
     "md",
     "markdown",
+    "rst",
     "json",
     "ndjson",
     "jsonl",
+    "geojson",
     "xml",
     "yaml",
     "yml",
-    "log",
-    // RTF is a TEXT format (not a binary zip), so web_fetch can read it and the
-    // model decodes its control words. Pin it here so a `.rtf` reported as
-    // `application/msword` isn't misrouted to server-side extraction (which has no
-    // .rtf extractor → "unsupported format" note).
+    "toml",
+    "ini",
+    "conf",
+    "cfg",
+    "properties",
+    "env",
     "rtf",
+    "html",
     "htm",
-    "html"
+    "js",
+    "mjs",
+    "cjs",
+    "ts",
+    "tsx",
+    "jsx",
+    "py",
+    "rb",
+    "go",
+    "rs",
+    "java",
+    "kt",
+    "c",
+    "h",
+    "cpp",
+    "cc",
+    "hpp",
+    "cs",
+    "php",
+    "swift",
+    "sh",
+    "bash",
+    "zsh",
+    "sql",
+    "css",
+    "scss",
+    "less",
+    "vue",
+    "svelte",
+    "tex",
+    "srt",
+    "vtt"
   ]);
-  function isOfficeFile(name, mime) {
+  function isTextMime(m) {
+    return m.startsWith("text/") || m.endsWith("+json") || m.endsWith("+xml") || m.endsWith("+yaml") || m === "application/json" || m === "application/ld+json" || m === "application/xml" || m === "application/yaml" || m === "application/x-yaml" || m === "application/javascript" || m === "application/x-javascript" || m === "application/x-sh" || m === "application/x-ndjson" || m === "application/csv" || m === "application/rtf" || m === "application/sql" || m === "application/toml";
+  }
+  function isServerExtractable(name, mime) {
     const ext = (name || "").split(".").pop()?.toLowerCase() || "";
     if (OFFICE_FILE_EXTENSIONS.has(ext)) return true;
-    if (WEB_FETCHABLE_TEXT_EXTENSIONS.has(ext)) return false;
+    if (TEXT_FILE_EXTENSIONS.has(ext)) return true;
     const m = (mime || "").toLowerCase();
+    if (isTextMime(m)) return true;
     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";
   }
   var _extractPlaceholderSeq = 0;
@@ -127,10 +167,10 @@ ${lines.join("\n")}`;
     let composedForLlm = composed;
     let extractContent;
     if (attachmentUrls.length > 0) {
-      const officeFiles = attachmentUrls.filter((u) => isOfficeFile(u.name));
-      if (officeFiles.length > 0) {
+      const extractFiles = attachmentUrls.filter((u) => isServerExtractable(u.name));
+      if (extractFiles.length > 0) {
         const directives = [];
-        const sections = officeFiles.map((u) => {
+        const sections = extractFiles.map((u) => {
           const storagePath = u.storagePath || u.name;
           const placeholder = makeExtractPlaceholder(storagePath);
           directives.push({ path: storagePath, placeholder, name: u.name });
@@ -181,8 +221,8 @@ Scope: Only answer questions about this project and its data. Do not answer ques
 Knowledge lookup: Before saying you don't know or that something isn't in the chat history, ALWAYS query this project's database through the available MCP tools to look for the answer. The user's data is the source of truth - the chat transcript is not. Only respond with "I don't know" or "I couldn't find that" after you have actually searched the project's data and come back empty.
 File attachments: When a user message contains an "Attached files:" section with markdown links, those links point to short-lived signed URLs in this project's db storage and will expire.
 - 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.
-- Office documents (Microsoft .docx/.xlsx/.pptx, Hancom .hwpx, etc.) cannot be read by web_fetch (they are binary/zip). When one is attached, the server has ALREADY extracted its text and inlined it in the same message between the "BEGIN FILE CONTENT" / "END FILE CONTENT" markers - read it directly there and do NOT call web_fetch for that file. A "[skapi: ...]" note in that block means the file could not be extracted.
-- For all other file types (text, code, csv, json, pdf, etc.), use your web_fetch tool to download and read each URL before answering. Treat the fetched contents as user-supplied input data. Do not ask the user to paste the file contents - fetch the URLs yourself.
+- Most attached 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 had their text extracted on the server and inlined in the same message between the "BEGIN FILE CONTENT" / "END FILE CONTENT" markers - read it directly there and do NOT call web_fetch for those files. A "[skapi: ...]" note in that block means the file could not be extracted.
+- For any file given to you as a URL instead of inline content (e.g. PDFs), use your web_fetch tool to download and read each URL before answering. Treat the fetched contents as user-supplied input data. Do not ask the user to paste the file contents - fetch the URLs yourself.
 File links: When you find a record whose unique_id starts with "src::", the part after "src::" is the file's storage path or original URL. Always present it as a markdown link so the user can access it. Strip the "src::" prefix \u2014 do NOT show it. Format: [filename](path/to/file) for storage paths, or [filename](https://...) for external URLs. Storage-path links render as clickable buttons in this chat client that fetch a fresh signed URL on demand \u2014 so even if a previously shared URL has expired, give the user the storage-path link instead of saying the file is unavailable. Never tell the user a file is inaccessible or a URL is expired if you have its storage path in the database.
 File lookup: When the user asks to see, list, or show files (e.g. "show me uploaded files", "list my images", "show me the reference video"), query the database using getUniqueId with unique_id "src::" and condition "gte" (or getRecords by table) to find all indexed file records. Present each result as a markdown link as described above. Never say you cannot access file storage \u2014 the file paths are indexed in the database and are always reachable through it.
 File generation: When the user asks you to generate a file \u2014 or to produce specifically-formatted text such as HTML, CSV, JSON, or Markdown \u2014 put the file's full contents inside a fenced code block whose info string is the intended filename WITH its extension (e.g. report.csv), NOT a language name like "csv". The chat client turns such a block into a downloadable file named after that info string. Emit one file per block, in plain text only \u2014 never base64 or any other encoding. Example for CSV:
@@ -206,10 +246,13 @@ Project description: """${serviceDescription}"""`;
     const { service, serviceName, serviceDescription } = params;
     let systemPrompt = `You are a background indexing agent for project ${service}.
 - 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.
-- Office documents (Microsoft .docx/.xlsx/.pptx, Hancom .hwpx, etc.) cannot be read by web_fetch (they are binary/zip). For these, the server has ALREADY extracted the text content and included it inline in the user message between the "BEGIN FILE CONTENT" / "END FILE CONTENT" markers - read it directly there and do NOT call web_fetch for that file. If the inline content is a "[skapi: ...]" note, the file could not be extracted - index it from its metadata only.
-- For all other file types (text, code, csv, json, pdf, etc.), 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.
+- 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.
+- 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.
 - 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.
-- Do NOT reply to the user. Only let user know when the indexing is complete. This is a background indexing task. Always use the MCP tools to save what you learn. Be exhaustive about meaning, terse about bytes.`;
+- 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. (You may ALSO save one file-level summary record, but the per-row records are mandatory.)
+- 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.
+- 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.
+- 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>.`;
     if (serviceDescription) {
       systemPrompt += `
 Project name: "${serviceName ?? ""}"
@@ -732,9 +775,9 @@ ${options.inlineContentPlaceholder}
   }
   async function notifyAgentSaveAttachment(info) {
     const { platform, service, owner, attachment, parsedContent } = info;
-    const office = !parsedContent && isOfficeFile(attachment.name, attachment.mime);
-    const placeholder = office ? makeExtractPlaceholder(attachment.storagePath) : void 0;
-    const extractContent = office && placeholder ? [{ path: attachment.storagePath, placeholder, name: attachment.name, mime: attachment.mime }] : void 0;
+    const serverExtract = !parsedContent && isServerExtractable(attachment.name, attachment.mime);
+    const placeholder = serverExtract ? makeExtractPlaceholder(attachment.storagePath) : void 0;
+    const extractContent = serverExtract && placeholder ? [{ path: attachment.storagePath, placeholder, name: attachment.name, mime: attachment.mime }] : void 0;
     const skapiExtract = extractContent && extractContent.length ? { _skapi_extract: extractContent } : {};
     const userMessage = buildIndexingUserMessage(
       attachment,
@@ -2041,7 +2084,7 @@ ${options.inlineContentPlaceholder}
   (function() {
     var MCP_PROD = "https://mcp.broadwayinc.computer";
     var MCP_DEV = "https://mcp-dev.broadwayinc.computer";
-    var BQ_VERSION = "1.4.0" ;
+    var BQ_VERSION = "1.4.3" ;
     var ATTACHMENT_URL_EXPIRES_SECONDS = 600;
     var GOOGLE_AUTH_URL = "https://accounts.google.com/o/oauth2/v2/auth";
     var GOOGLE_TOKEN_URL = "https://oauth2.googleapis.com/token";
@@ -2449,6 +2492,43 @@ ${options.inlineContentPlaceholder}
       var mismatched = !!tok && !!currentSub && !!tokenSub && tokenSub !== currentSub;
       return expired || mismatched;
     }
+    function refreshMcpToken() {
+      var client = getStoredMcpClient();
+      var current = getStoredMcpToken();
+      if (!client || !current || !current.refresh_token) return Promise.resolve(null);
+      var body = new URLSearchParams({
+        grant_type: "refresh_token",
+        refresh_token: current.refresh_token,
+        client_id: client.client_id
+      });
+      var headers = { "Content-Type": "application/x-www-form-urlencoded" };
+      if (client.client_secret) {
+        headers.Authorization = basicAuthHeader(client.client_id, client.client_secret);
+      }
+      return fetch(mcpBaseUrl() + "/oauth/token", {
+        method: "POST",
+        headers,
+        body: body.toString()
+      }).then(function(res) {
+        return res.ok ? res.json() : null;
+      }).then(function(json) {
+        if (!json || !json.access_token) return null;
+        var token = Object.assign({}, json, {
+          refresh_token: json.refresh_token || current.refresh_token,
+          expires_at: typeof json.expires_in === "number" ? Date.now() + json.expires_in * 1e3 : void 0
+        });
+        lsSet(skey(SK.mcpToken), JSON.stringify(token));
+        return token;
+      }).catch(function() {
+        return null;
+      });
+    }
+    function ensureMcpGrantFresh() {
+      if (!S.user || !mcpGrantNeedsRefresh(S.user)) return Promise.resolve(true);
+      return refreshMcpToken().then(function(tok) {
+        return !!(tok && !mcpGrantNeedsRefresh(S.user));
+      });
+    }
     function googleEnabled() {
       return !!S.opts.googleClientId;
     }
@@ -3716,6 +3796,8 @@ ${options.inlineContentPlaceholder}
     }
     function refreshSkapiSession() {
       return S.skapi.getProfile({ refreshToken: true }).then(function() {
+        return ensureMcpGrantFresh();
+      }).then(function() {
         return true;
       }).catch(function() {
         return false;
@@ -5056,9 +5138,12 @@ ${options.inlineContentPlaceholder}
           return;
         }
         if (mcpGrantNeedsRefresh(user)) {
-          return beginMcpOAuthOnLogin("chat").catch(function(err) {
-            console.error("[bunnyquery] MCP refresh failed", err);
-            return enterAfterLogin();
+          return refreshMcpToken().then(function(tok) {
+            if (tok && !mcpGrantNeedsRefresh(user)) return enterAfterLogin();
+            return beginMcpOAuthOnLogin("chat").catch(function(err) {
+              console.error("[bunnyquery] MCP refresh failed", err);
+              return enterAfterLogin();
+            });
           });
         }
         return enterAfterLogin();
@@ -5115,6 +5200,12 @@ ${options.inlineContentPlaceholder}
           scheduleAttachmentOverflowRecompute();
         });
       }
+      if (!S._visBound && typeof document !== "undefined" && document.addEventListener) {
+        S._visBound = true;
+        document.addEventListener("visibilitychange", function() {
+          if (document.visibilityState === "visible" && S.user) ensureMcpGrantFresh();
+        });
+      }
       boot();
       return PUBLIC;
     }

package/dist/engine.cjs

@@ -84,36 +84,77 @@ var OFFICE_FILE_EXTENSIONS = /* @__PURE__ */ new Set([
   "odp",
   "epub"
 ]);
-var WEB_FETCHABLE_TEXT_EXTENSIONS = /* @__PURE__ */ new Set([
+var TEXT_FILE_EXTENSIONS = /* @__PURE__ */ new Set([
   "csv",
   "tsv",
   "tab",
   "txt",
   "text",
+  "log",
   "md",
   "markdown",
+  "rst",
   "json",
   "ndjson",
   "jsonl",
+  "geojson",
   "xml",
   "yaml",
   "yml",
-  "log",
-  // RTF is a TEXT format (not a binary zip), so web_fetch can read it and the
-  // model decodes its control words. Pin it here so a `.rtf` reported as
-  // `application/msword` isn't misrouted to server-side extraction (which has no
-  // .rtf extractor → "unsupported format" note).
+  "toml",
+  "ini",
+  "conf",
+  "cfg",
+  "properties",
+  "env",
   "rtf",
+  "html",
   "htm",
-  "html"
+  "js",
+  "mjs",
+  "cjs",
+  "ts",
+  "tsx",
+  "jsx",
+  "py",
+  "rb",
+  "go",
+  "rs",
+  "java",
+  "kt",
+  "c",
+  "h",
+  "cpp",
+  "cc",
+  "hpp",
+  "cs",
+  "php",
+  "swift",
+  "sh",
+  "bash",
+  "zsh",
+  "sql",
+  "css",
+  "scss",
+  "less",
+  "vue",
+  "svelte",
+  "tex",
+  "srt",
+  "vtt"
 ]);
-function isOfficeFile(name, mime) {
+function isTextMime(m) {
+  return m.startsWith("text/") || m.endsWith("+json") || m.endsWith("+xml") || m.endsWith("+yaml") || m === "application/json" || m === "application/ld+json" || m === "application/xml" || m === "application/yaml" || m === "application/x-yaml" || m === "application/javascript" || m === "application/x-javascript" || m === "application/x-sh" || m === "application/x-ndjson" || m === "application/csv" || m === "application/rtf" || m === "application/sql" || m === "application/toml";
+}
+function isServerExtractable(name, mime) {
   const ext = (name || "").split(".").pop()?.toLowerCase() || "";
   if (OFFICE_FILE_EXTENSIONS.has(ext)) return true;
-  if (WEB_FETCHABLE_TEXT_EXTENSIONS.has(ext)) return false;
+  if (TEXT_FILE_EXTENSIONS.has(ext)) return true;
   const m = (mime || "").toLowerCase();
+  if (isTextMime(m)) return true;
   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";
 }
+var isOfficeFile = isServerExtractable;
 var _extractPlaceholderSeq = 0;
 function makeExtractPlaceholder(seed) {
   _extractPlaceholderSeq += 1;
@@ -132,10 +173,10 @@ ${lines.join("\n")}`;
   let composedForLlm = composed;
   let extractContent;
   if (attachmentUrls.length > 0) {
-    const officeFiles = attachmentUrls.filter((u) => isOfficeFile(u.name));
-    if (officeFiles.length > 0) {
+    const extractFiles = attachmentUrls.filter((u) => isServerExtractable(u.name));
+    if (extractFiles.length > 0) {
       const directives = [];
-      const sections = officeFiles.map((u) => {
+      const sections = extractFiles.map((u) => {
         const storagePath = u.storagePath || u.name;
         const placeholder = makeExtractPlaceholder(storagePath);
         directives.push({ path: storagePath, placeholder, name: u.name });
@@ -186,8 +227,8 @@ Scope: Only answer questions about this project and its data. Do not answer ques
 Knowledge lookup: Before saying you don't know or that something isn't in the chat history, ALWAYS query this project's database through the available MCP tools to look for the answer. The user's data is the source of truth - the chat transcript is not. Only respond with "I don't know" or "I couldn't find that" after you have actually searched the project's data and come back empty.
 File attachments: When a user message contains an "Attached files:" section with markdown links, those links point to short-lived signed URLs in this project's db storage and will expire.
 - 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.
-- Office documents (Microsoft .docx/.xlsx/.pptx, Hancom .hwpx, etc.) cannot be read by web_fetch (they are binary/zip). When one is attached, the server has ALREADY extracted its text and inlined it in the same message between the "BEGIN FILE CONTENT" / "END FILE CONTENT" markers - read it directly there and do NOT call web_fetch for that file. A "[skapi: ...]" note in that block means the file could not be extracted.
-- For all other file types (text, code, csv, json, pdf, etc.), use your web_fetch tool to download and read each URL before answering. Treat the fetched contents as user-supplied input data. Do not ask the user to paste the file contents - fetch the URLs yourself.
+- Most attached 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 had their text extracted on the server and inlined in the same message between the "BEGIN FILE CONTENT" / "END FILE CONTENT" markers - read it directly there and do NOT call web_fetch for those files. A "[skapi: ...]" note in that block means the file could not be extracted.
+- For any file given to you as a URL instead of inline content (e.g. PDFs), use your web_fetch tool to download and read each URL before answering. Treat the fetched contents as user-supplied input data. Do not ask the user to paste the file contents - fetch the URLs yourself.
 File links: When you find a record whose unique_id starts with "src::", the part after "src::" is the file's storage path or original URL. Always present it as a markdown link so the user can access it. Strip the "src::" prefix \u2014 do NOT show it. Format: [filename](path/to/file) for storage paths, or [filename](https://...) for external URLs. Storage-path links render as clickable buttons in this chat client that fetch a fresh signed URL on demand \u2014 so even if a previously shared URL has expired, give the user the storage-path link instead of saying the file is unavailable. Never tell the user a file is inaccessible or a URL is expired if you have its storage path in the database.
 File lookup: When the user asks to see, list, or show files (e.g. "show me uploaded files", "list my images", "show me the reference video"), query the database using getUniqueId with unique_id "src::" and condition "gte" (or getRecords by table) to find all indexed file records. Present each result as a markdown link as described above. Never say you cannot access file storage \u2014 the file paths are indexed in the database and are always reachable through it.
 File generation: When the user asks you to generate a file \u2014 or to produce specifically-formatted text such as HTML, CSV, JSON, or Markdown \u2014 put the file's full contents inside a fenced code block whose info string is the intended filename WITH its extension (e.g. report.csv), NOT a language name like "csv". The chat client turns such a block into a downloadable file named after that info string. Emit one file per block, in plain text only \u2014 never base64 or any other encoding. Example for CSV:
@@ -211,10 +252,13 @@ function buildIndexingSystemPrompt(params) {
   const { service, serviceName, serviceDescription } = params;
   let systemPrompt = `You are a background indexing agent for project ${service}.
 - 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.
-- Office documents (Microsoft .docx/.xlsx/.pptx, Hancom .hwpx, etc.) cannot be read by web_fetch (they are binary/zip). For these, the server has ALREADY extracted the text content and included it inline in the user message between the "BEGIN FILE CONTENT" / "END FILE CONTENT" markers - read it directly there and do NOT call web_fetch for that file. If the inline content is a "[skapi: ...]" note, the file could not be extracted - index it from its metadata only.
-- For all other file types (text, code, csv, json, pdf, etc.), 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.
+- 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.
+- 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.
 - 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.
-- Do NOT reply to the user. Only let user know when the indexing is complete. This is a background indexing task. Always use the MCP tools to save what you learn. Be exhaustive about meaning, terse about bytes.`;
+- 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. (You may ALSO save one file-level summary record, but the per-row records are mandatory.)
+- 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.
+- 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.
+- 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>.`;
   if (serviceDescription) {
     systemPrompt += `
 Project name: "${serviceName ?? ""}"
@@ -740,9 +784,9 @@ async function callOpenAIWithPublicMcp(prompt, service, owner, messages, system,
 }
 async function notifyAgentSaveAttachment(info) {
   const { platform, service, owner, attachment, parsedContent } = info;
-  const office = !parsedContent && isOfficeFile(attachment.name, attachment.mime);
-  const placeholder = office ? makeExtractPlaceholder(attachment.storagePath) : void 0;
-  const extractContent = office && placeholder ? [{ path: attachment.storagePath, placeholder, name: attachment.name, mime: attachment.mime }] : void 0;
+  const serverExtract = !parsedContent && isServerExtractable(attachment.name, attachment.mime);
+  const placeholder = serverExtract ? makeExtractPlaceholder(attachment.storagePath) : void 0;
+  const extractContent = serverExtract && placeholder ? [{ path: attachment.storagePath, placeholder, name: attachment.name, mime: attachment.mime }] : void 0;
   const skapiExtract = extractContent && extractContent.length ? { _skapi_extract: extractContent } : {};
   const userMessage = buildIndexingUserMessage(
     attachment,
@@ -2120,6 +2164,7 @@ exports.isAuthExpiredError = isAuthExpiredError;
 exports.isErrorResponseBody = isErrorResponseBody;
 exports.isNonRetryableRequestError = isNonRetryableRequestError;
 exports.isOfficeFile = isOfficeFile;
+exports.isServerExtractable = isServerExtractable;
 exports.listClaudeModels = listClaudeModels;
 exports.listOpenAIModels = listOpenAIModels;
 exports.makeExtractPlaceholder = makeExtractPlaceholder;