bunnyquery 1.9.1 → 1.9.4

package/dist/engine.cjs

@@ -299,11 +299,13 @@ function groupAttachmentFailures(attachments) {
 // src/engine/prompts/chat_system_prompt.ts
 function buildChatSystemPrompt(params) {
   const { projectId, serviceName, serviceDescription, greeting, canUpload, client } = params;
+  const g = params.indexAccessGroup;
+  const indexGroupLiteral = typeof g === "number" ? String(g) : g === "public" || g === "private" || g === "authorized" || g === "admin" ? `"${g}"` : '"authorized"';
   let systemPrompt = `
 You are a dedicated assistant for the project ID: "${projectId}".
 Scope: Only answer questions about this project and its data. Do not answer questions about other projects or topics unrelated to this project. When the user refers to "my database", "my data", or "my files", treat those as references to this project's database and file storage. The ONE exception is BunnyQuery itself - what this app is, what it can do, and how to use it - which is always in scope: answer it from the "About BunnyQuery" section at the end of this prompt.
 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.
-Complete answers over stored data: The database holds one record per spreadsheet row, and each uploaded file becomes many records. ONE file is routinely SPLIT ACROSS SEVERAL TABLES - a summary row in one table, its page or row content in another, its extracted photos and other media in "__MEDIA__", and the indexer often invents a differently-named table on each pass. An index or tag filter matches inside ONE table only and requires table_name: on getRecords, an index or tag sent with table_name but no access_group is auto-filled with access_group "authorized" (where the indexer writes; pass access_group explicitly, including 0, to search another group), while an index or tag WITHOUT table_name FAILS with an error instead of answering, so read the error rather than guessing. Reference is the exception: reference ALONE spans EVERY table and EVERY access group, so getRecords with reference "src::<the file's storage path>" is the one call that returns a whole file's records wherever the indexer put them. Adding table_name narrows it to that table; access_group WITHOUT table_name fails with '"table" is required'; table_name on its own returns that whole table across all access groups. For anything NOT scoped to a single file, call getTables FIRST, run the query once per table that could hold the answer, and combine the results. For any request that counts, sums, totals, lists every match, compares across records, finds which one, or asks whether something is present or ABSENT (for example "how many", "total spent", "which card", "is there any", "\uC5C6\uC5B4?", "\uD558\uB098\uB3C4 \uC5C6\uB098?"), you MUST read the COMPLETE matching set before answering. Query with fetch_all set to true, or page through getToolResponsePage until pagination.complete is true, across EVERY table and EVERY relevant file. A single default query returns only the first page (about 50 records). That is a SAMPLE. Never treat it as the whole dataset. If you already answered from one table and then realise another table holds more, do not simply apologise: re-run the sweep and give the complete answer.
+Complete answers over stored data: The database holds one record per spreadsheet row, and each uploaded file becomes many records. ONE file is routinely SPLIT ACROSS SEVERAL TABLES - a summary row in one table, its page or row content in another, its extracted photos and other media in "__MEDIA__", and the indexer often invents a differently-named table on each pass. An index or tag filter matches inside ONE table only and requires table_name: on getRecords, an index or tag sent with table_name but no access_group is auto-filled with access_group "authorized", but THIS project indexes at access_group ${indexGroupLiteral}, so pass access_group ${indexGroupLiteral} EXPLICITLY on every index or tag query here - the auto-fill would search a group this project's data is not in and come back empty. Files uploaded before the project's setting changed may sit at another group, so when a scoped query comes back empty, retry it across the other groups (0, 1, "private") before concluding there is nothing, while an index or tag WITHOUT table_name FAILS with an error instead of answering, so read the error rather than guessing. Reference is the exception: reference ALONE spans EVERY table and EVERY access group, so getRecords with reference "src::<the file's storage path>" is the one call that returns a whole file's records wherever the indexer put them. Adding table_name narrows it to that table; access_group WITHOUT table_name fails with '"table" is required'; table_name on its own returns that whole table across all access groups. For anything NOT scoped to a single file, call getTables FIRST, run the query once per table that could hold the answer, and combine the results. For any request that counts, sums, totals, lists every match, compares across records, finds which one, or asks whether something is present or ABSENT (for example "how many", "total spent", "which card", "is there any", "\uC5C6\uC5B4?", "\uD558\uB098\uB3C4 \uC5C6\uB098?"), you MUST read the COMPLETE matching set before answering. Query with fetch_all set to true, or page through getToolResponsePage until pagination.complete is true, across EVERY table and EVERY relevant file. A single default query returns only the first page (about 50 records). That is a SAMPLE. Never treat it as the whole dataset. If you already answered from one table and then realise another table holds more, do not simply apologise: re-run the sweep and give the complete answer.
 Never assert absence from a partial read. Do not say "there is no X", "none", "not found", or "\uC544\uB2C8\uC694, \uC5C6\uC2B5\uB2C8\uB2E4" until a complete scan has come back empty. If you have not finished scanning every relevant table and file, keep querying instead of guessing. A confident "no" that later turns out wrong is worse than telling the user you are still checking.
 Embedded values: a search term is often stored inside a larger string. A merchant "BAKSA" appears as "DNH*BAKSA#4070277042", and a card as "5860****5173". Server-side index filters match only exact values, leading prefixes, or trailing suffixes, and tag filters only EXACT whole-tag values - never a partial or interior substring - so filtering on such a field silently drops rows. When the value you are looking for may be embedded, do not trust a narrow filter to be complete. Fetch the full set with fetch_all and match the substring yourself.
 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.
@@ -353,6 +355,7 @@ Project description: """${serviceDescription}"""`;
 // src/engine/prompts/indexing_system_prompt.ts
 function buildIndexingSystemPrompt(params) {
   const { projectId, serviceName, serviceDescription } = params;
+  const accessGroup = params.accessGroup === "public" || params.accessGroup === "private" ? params.accessGroup : "authorized";
   let systemPrompt = `You are a background indexing agent for project ${projectId}.
 - 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.
 - 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.
@@ -361,7 +364,8 @@ function buildIndexingSystemPrompt(params) {
 - VISION: when the message (a readFileContent window, an embedded PDF page, or an inline attachment) includes IMAGES - scanned/rendered 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).
 - TRANSCRIBE, DO NOT DESCRIBE. When an image contains ANY text - a label, tag, stamp, form field, serial/part number, handwriting - your FIRST job is to read the characters out and store them VERBATIM, not to describe the scene. A record saying "a red inspection tag with handwritten markings" is worthless: it is unsearchable and every such photo produces the same sentence. Put the characters you can actually read into these EXACT fields, not variations of them: "printed_text" (the pre-printed wording), "handwritten_text" (what a person wrote by hand), and, when you can resolve one, "part_no", "tag_id" and "date". Same reason as the fixed table names: a field called photo_text in one pass and visible_text_notes in the next cannot be queried together. Read PARTIAL values rather than skipping: "500.7402.52__" beats nothing. Only when a character is genuinely unreadable, leave that field null or mark the unreadable span - do NOT invent it, and do NOT replace the whole transcription with a description of what the object looks like. A scene description is a nice extra AFTER the text, never instead of it.
 - IMAGE FILES uploaded as the file itself: if ANY readable character appears ANYWHERE in the image (a label, a stamp, a sign in the background) it counts as an image WITH text - transcribe it per the rule above, and also capture the layout (what appears where) and every entity named. Only a truly text-free image gets description first: a one-line caption, then the objects present with their attributes (type, color, count, condition, position). Either way, save what you extract onto the file's "src::" record with updateRecords, TAG every entity and identifier visible, and INDEX the one number the image offers (a measured value, an amount, a count).
-- Whatever the file type, this file's identity is "src::" + its storage path (the "storage path" metadata line) - never the inline content or a temporary URL. That record ALREADY EXISTS: the upload pipeline creates it in table "file_summaries" (access group "authorized") before indexing starts, so posting it again is rejected as a duplicate unique_id. Reference it from every record you write, and add what you learn to it with updateRecords. If that update unexpectedly reports the record does not exist, post it yourself ONCE with that exact "src::" unique_id (table "file_summaries", access group "authorized") and carry on; this is the ONE exception to the do-NOT-post-the-file-record rules elsewhere in these instructions, because the source identity must never be dropped just because an update failed.
+- Whatever the file type, this file's identity is "src::" + its storage path (the "storage path" metadata line) - never the inline content or a temporary URL. That record ALREADY EXISTS: the upload pipeline creates it in table "file_summaries" (access group "${accessGroup}") before indexing starts, so posting it again is rejected as a duplicate unique_id. Reference it from every record you write, and add what you learn to it with updateRecords. If that update unexpectedly reports the record does not exist, post it yourself ONCE with that exact "src::" unique_id (table "file_summaries", access group "${accessGroup}") and carry on; this is the ONE exception to the do-NOT-post-the-file-record rules elsewhere in these instructions, because the source identity must never be dropped just because an update failed.
+- ACCESS GROUP (hard rule): every record you write for this file - the file record, per-row records, chapters, summaries, intermediates - MUST be posted with access group "${accessGroup}". Pass it explicitly on every postRecords call; do not leave it out and do not vary it between passes of the same file. An access group is part of a record's table key, so records saved under a different group than the file are in a different table and will not come back with the rest of it: a "public" file whose rows were saved as "authorized" is one an anonymous visitor can see the name of and none of the contents of, and a re-index cannot find the strays to clean them up. The one exception is the EXTRACTED MEDIA records in "__MEDIA__", which the pipeline creates for you - leave their group alone and only enrich them.
 - REACHABILITY (hard rule): every record you write while indexing this file MUST be reachable from the file's "src::<storage path>" record by following reference - either reference that record directly, or reference something that already reaches it. A record with no reference, or one pointing outside this file's chain, is an ORPHAN: deleting or re-indexing the file removes the reachable records and leaves the orphan behind forever, where it keeps turning up in later answers as stale data. If you create an intermediate record that OTHER records reference (a page record that rows hang off, a sheet or section record), set source.can_remove_referencing_records to true on it; the delete cascade passes a delete through a record only when that record carries the flag OR a unique_id starting "src::" (the file record cascades because its unique_id starts with "src::"; the intermediates you create carry no "src::" id, so they need the flag), and it cascades ONE LEVEL AT A TIME, so EVERY intermediate record in a chain needs its own marker - an unmarked link stops the cascade there and everything below it survives as orphans. When in doubt, reference the file record directly and keep the chain flat.
 - 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 table named EXACTLY "spreadsheet_rows". Do NOT summarize, sample only a few rows, or save just file metadata - index the whole sheet, window by window, until it ends. Make MULTIPLE postRecords calls in batches (e.g. 30-50 rows per call) rather than one oversized call. This per-row completeness OVERRIDES brevity. The file-level "src::" record ALREADY EXISTS - the upload pipeline creates it before indexing starts - so do NOT create it. Link EVERY per-row record to it via reference (set each row record's reference to exactly "src::" + the storage path, with NO sheet/window/summary suffix added; the row records themselves do NOT carry a src:: unique_id). Enrich that same record with sheet name(s), column headers and total row count via updateRecords rather than posting another one. 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. INDEX each row record on the row's most useful NUMERIC column (named by its header) so rows sort and range-query; when the row has no numeric column, index the grid row number instead. TAG each row record with the sheet name, the file name, and the row's categorical values (a status, a category, a type) - tags are how rows are filtered without scanning the table.
 - ONE RECORD PER GRID ROW, ALWAYS. "Row" means the numbered row of the sheet (R37 is one record), never a visual block, item, section or left/right pair. Sheets that repeat the same columns side by side (an A/B block beside a C/D block, "paired" or "mirrored" layouts) still get ONE record per grid row, holding BOTH sides - suffix the keys to keep them apart (PART_NO_A / PART_NO_B). Collapsing a 16-row window into 2 or 3 "block" records is the single most damaging mistake here: it silently loses most of the cells and makes every later total wrong, because some windows were counted per row and others per block. If a window shows rows R37 to R52, you save records for R37..R52 and the count you report is the number of grid rows you actually wrote.
@@ -382,6 +386,10 @@ Project description: """${serviceDescription}"""`;
 }
 
 // src/engine/prompts/indexing_user_message.ts
+function indexingAccessGroup(attachment) {
+  const g = attachment && attachment.accessGroup;
+  return g === "public" || g === "private" ? g : "authorized";
+}
 function buildIndexingUserMessage(attachment, options) {
   const head = `A new file has just been uploaded. Index it now.
 
@@ -390,7 +398,11 @@ File metadata:
 - storage path: ${attachment.storagePath}
 ` + (attachment.mime ? `- mime type: ${attachment.mime}
 ` : "") + (typeof attachment.size === "number" ? `- size (bytes): ${attachment.size}
-` : "");
+` : "") + // Stated in the metadata block as well as the system prompt because this is
+  // the per-FILE value: one project can hold public and private files at once,
+  // and the system prompt is what is constant across the run.
+  `- access group (use this for EVERY record you write for this file): ${indexingAccessGroup(attachment)}
+`;
   if (options?.inlineContent) {
     return head + `
 The file's content was parsed by the client and is provided inline below. Read it directly - do NOT fetch any URL for this file. Set every record's reference to exactly "src::" + the storage path above (not this content). That file record already exists, so enrich it with updateRecords rather than posting it.
@@ -438,7 +450,8 @@ function buildRenderMeta(attachment) {
 - name: ${attachment.name}
 - storage path: ${attachment.storagePath}
 ` + (attachment.mime ? `- mime type: ${attachment.mime}
-` : "");
+` : "") + `- access group (use this for EVERY record you write for this file): ${indexingAccessGroup(attachment)}
+`;
 }
 function buildRenderDatafy(placeholder) {
   return `
@@ -481,7 +494,8 @@ File metadata:
 - name: ${attachment.name}
 - storage path: ${attachment.storagePath}
 ` + (attachment.mime ? `- mime type: ${attachment.mime}
-` : "") + `
+` : "") + `- access group (use this for EVERY record you write for this file): ${indexingAccessGroup(attachment)}
+
 Records for the earlier windows/pages of this file are ALREADY saved (they reference "${src}"). First call getRecords with reference "${src}" to see how far the previous pass got (the furthest row/window already saved). The reference ALONE is the whole query: it returns every record written from this file across ALL tables and ALL access groups, so do NOT add table_name or access_group to narrow it. The response is PAGED, so keep fetching pages until it reports there are no more, and take the furthest point from the WHOLE set, never from the first page. Then call readFileContent with the storage path above and a CURSOR that RESUMES just after that point - do NOT start at the beginning. The cursor is derivable from what you already saved:
  - Spreadsheet: the cursor is "<sheetIndex>:<nextRow>" (0-based sheet index, 1-based row). If you saved up to row R of sheet S, use cursor="S:R+1".
  - Text: the cursor is the character offset already read.
@@ -1542,6 +1556,11 @@ var MCP_NAME = "BunnyQuery";
 var DEFAULT_CLAUDE_MODEL = "claude-sonnet-5";
 var DEFAULT_OPENAI_MODEL = "gpt-5.6-luna";
 var mcpUrl = () => chatEngineConfig().mcpBaseUrl;
+function mcpEndpointFor(anonymous, publicProjectId, service) {
+  if (!anonymous) return { url: mcpUrl(), token: "$ACCESS_TOKEN" };
+  const project = publicProjectId || service;
+  return { url: String(mcpUrl()).replace(/\/+$/, "") + "/p/" + project };
+}
 var clientSecretRequest = (opts) => chatEngineConfig().clientSecretRequest(opts);
 var VARIANT_IMAGE_DETAIL = "original";
 var VARIANT_TEXT_VERBOSITY = "high";
@@ -1767,7 +1786,8 @@ async function callClaudeWithMcp({
     }
   });
 }
-async function callClaudeWithPublicMcp(prompt, service, owner, messages, system, model, userId, extractContent, fileUrls, onResponse, onError) {
+async function callClaudeWithPublicMcp(prompt, service, owner, messages, system, model, userId, extractContent, fileUrls, onResponse, onError, mcpScope) {
+  const endpoint = mcpEndpointFor(mcpScope?.anonymous, mcpScope?.publicProjectId, service);
   return callClaudeWithMcp({
     prompt,
     messages,
@@ -1781,11 +1801,14 @@ async function callClaudeWithPublicMcp(prompt, service, owner, messages, system,
     fileUrls,
     mcpServer: {
       name: MCP_NAME,
-      url: mcpUrl(),
-      authorizationToken: "$ACCESS_TOKEN"
+      url: endpoint.url,
+      // Omitted entirely for an anonymous turn; the `if (mcpServer.authorizationToken)`
+      // guard below drops the key rather than sending an empty one.
+      authorizationToken: endpoint.token
     }});
 }
-async function callOpenAIWithPublicMcp(prompt, service, owner, messages, system, model, userId, extractContent, fileUrls, onResponse, onError) {
+async function callOpenAIWithPublicMcp(prompt, service, owner, messages, system, model, userId, extractContent, fileUrls, onResponse, onError, mcpScope) {
+  const endpoint = mcpEndpointFor(mcpScope?.anonymous, mcpScope?.publicProjectId, service);
   const resolvedModel = model || DEFAULT_OPENAI_MODEL;
   const imageDetail = getOpenAIImageDetail(resolvedModel);
   const messageList = messages && messages.length ? prepareOpenAIMessages(messages, imageDetail) : [
@@ -1828,11 +1851,12 @@ async function callOpenAIWithPublicMcp(prompt, service, owner, messages, system,
         {
           type: "mcp",
           server_label: MCP_NAME,
-          server_url: mcpUrl(),
+          server_url: endpoint.url,
           require_approval: "never",
-          headers: {
-            Authorization: "Bearer $ACCESS_TOKEN"
-          }
+          // No `headers` at all for an anonymous turn: `Bearer ` with an
+          // empty token is a credential the MCP server rejects, and the
+          // project-scoped endpoint needs none.
+          ...endpoint.token ? { headers: { Authorization: "Bearer " + endpoint.token } } : {}
         },
         ...[
           {
@@ -1943,7 +1967,10 @@ async function notifyAgentSaveAttachment(info) {
     // by the tools' schema pattern.
     projectId: info.publicProjectId || service,
     serviceName: info.serviceName,
-    serviceDescription: info.serviceDescription
+    serviceDescription: info.serviceDescription,
+    // Per-FILE, not per-project: one project holds public and private files at
+    // once, so this travels on the attachment rather than the identity.
+    accessGroup: attachment.accessGroup
   });
   if (platform === "openai") {
     const resolvedModel2 = info.model || DEFAULT_OPENAI_MODEL;
@@ -3525,10 +3552,23 @@ var ChatSession = class {
     this._lidSeq += 1;
     return "lid_" + this._lidSeq;
   }
+  /**
+   * The key every per-chat cache hangs off: the restored message cache, the
+   * hydrated-body memo, the live-index key and the per-file storage-path key.
+   *
+   * It carries the IDENTITY as well as the project and platform. A single
+   * browser can hold more than one conversation on one project without a
+   * reload — an anonymous visitor who signs in, or a dashboard user who logs
+   * out and back in as someone else — and with an identity-free key the
+   * previous conversation stayed in the cache and was re-rendered, and written
+   * back, as the new one's. `userId` is the same value the request queue is
+   * named after, so two identities that share a queue share a cache, which is
+   * exactly right.
+   */
   getHistoryCacheKey() {
     var id = this.host.getIdentity();
     if (!id.projectId || id.platform === "none") return "";
-    return id.projectId + "#" + id.platform;
+    return id.projectId + "#" + id.platform + "#" + (id.userId || "");
   }
   /** Re-apply memoized hydrated texts onto freshly-mapped messages. Both
    *  clients call this right after their mapper runs (loadHistory does it
@@ -3731,7 +3771,9 @@ var ChatSession = class {
       if (projectId === void 0) projectId = id.projectId;
       if (owner === void 0) owner = id.owner;
     }
-    return platform === "openai" ? callOpenAIWithPublicMcp(prompt, projectId, owner, messages, system, model, userId, extractContent, fileUrls) : callClaudeWithPublicMcp(prompt, projectId, owner, messages, system, model, userId, extractContent, fileUrls);
+    var liveId = this.host.getIdentity();
+    var mcpScope = { anonymous: liveId.anonymous, publicProjectId: liveId.publicProjectId };
+    return platform === "openai" ? callOpenAIWithPublicMcp(prompt, projectId, owner, messages, system, model, userId, extractContent, fileUrls, void 0, void 0, mcpScope) : callClaudeWithPublicMcp(prompt, projectId, owner, messages, system, model, userId, extractContent, fileUrls, void 0, void 0, mcpScope);
   }
   dispatchAgentRequest(params) {
     var self = this;
@@ -6119,6 +6161,15 @@ var ChatSession = class {
             })).catch(function() {
             });
           });
+          var accessGroup;
+          preIndex = preIndex.then(function() {
+            if (alreadyIndexing) return;
+            if (typeof self.host.uploadAccessGroup !== "function") return;
+            return Promise.resolve(self.host.uploadAccessGroup(member.storagePath)).then(function(g) {
+              accessGroup = g || void 0;
+            }).catch(function() {
+            });
+          });
           return preIndex.then(function() {
             return parseAttachmentContent(member.file, member.file.name, mime || void 0);
           }).then(function(parsedContent) {
@@ -6137,7 +6188,8 @@ var ChatSession = class {
                 storagePath: member.storagePath,
                 mime: mime || void 0,
                 size: member.file.size,
-                url
+                url,
+                accessGroup
               },
               parsedContent: parsedContent || void 0
             }).then(function(ack) {
@@ -6778,6 +6830,7 @@ exports.groupAttachmentFailures = groupAttachmentFailures;
 exports.hasBom = hasBom;
 exports.hydrateImagePreviews = hydrateImagePreviews;
 exports.indexDoneUniqueId = indexDoneUniqueId;
+exports.indexingAccessGroup = indexingAccessGroup;
 exports.isAuthExpiredError = isAuthExpiredError;
 exports.isBgIndexingQueue = isBgIndexingQueue;
 exports.isErrorResponseBody = isErrorResponseBody;