bunnyquery 1.9.6 → 1.9.10

package/README.md

@@ -124,6 +124,7 @@ Mounts the widget. Returns the `BunnyQuery` object.
 | `hostDomain`             | `string`  | `null`   | db-CDN host for temporary file URLs. Defaults to `skapi.app` (dev) / `skapi.com` (prod).     |
 | `attachmentParsers`      | `array`   | `null`   | Client-side attachment parsers. See [Attachment parser plugins](#attachment-parser-plugins). |
 | `windowedIndexing`       | `boolean` | `true`   | Server-driven windowed indexing for text and grid files (see [file types](#supported-file-types)). Pass `false` to fall back to agent-driven paging, which keeps the traversal inside the model's turn budget and the tab open. |
+| `liveStreaming`          | `boolean` | `false`  | Paint a chat answer into its bubble as it arrives, instead of at the end. A **request**, not a switch: the widget honours it only when your page's `skapi-js` actually carries skapi's half of the stream flag (it checks for `clientSecretRequestStream` and `clientSecretRequestFinalize`), and otherwise warns once and falls back to buffered replies. An older SDK silently drops the flag, which would leave the destination streaming SSE into a buffered row that reads back empty. It still also needs a polling worker that relays the response bytes, which the widget cannot check, so leave it off until the region you talk to is deployed. |
 
 ### Methods
 
@@ -428,6 +429,10 @@ helpers. See the `.d.ts` shipped with `bunnyquery/engine`.
 | `poll`                        | `number?`  | Value attached as `poll` on every request. Omit it if your `clientSecretRequest` already resolves with the final body; pass `0` for the deployed `skapi-js@latest` (needed for the early ack + a manual `.poll()` handle that powers queued-send cancel, the widget's case). |
 | `attachmentParsers`           | `array?`   | Client-side attachment parsers, registered at configure time. More can be added later with `registerAttachmentParser()`. See [Attachment parser plugins](#attachment-parser-plugins). |
 | `windowedIndexing`            | `boolean?` | Opt in to **server-driven** windowed indexing for text and grid files (see [file types](#supported-file-types)). Off by default in the engine; the widget passes it as `true`. The deployed skapi workers support it; only leave it off against a self-hosted worker that does not yet strip the `_skapi_window` directive, where it would reach the provider as an unknown body field and fail the call terminally with no retry. |
+| `liveStreaming`               | `boolean?` | Opt in to **live streaming** of chat turns. Off by default, and the backend ships first: a streamed row settles with a status and NO body (the answer was the stream), so against a worker that does not relay, the turn reads back empty. Pair it with `clientSecretRequestFinalize` and `clientSecretRequestStream`, and gate it on `skapiSupportsStreaming(skapi)`. |
+| `clientSecretRequestFinalize` | `function?` | `skapi.clientSecretRequestFinalize`, bound to your Skapi instance. Stores the version of a streamed turn that history keeps (the engine sends the assembled provider body, so it reads back exactly like a buffered turn) and releases that request's chunks. Without it a streamed turn is never finalized and its row stays empty. |
+| `clientSecretRequestStream`   | `function?` | `skapi.clientSecretRequestStream`, bound to your Skapi instance. The **second half of the durability guarantee**: a row that settles while no poll is attached (closed tab, discarded background tab, slept device) is never finalized, so its answer stays in the chunk store and its history row is terminal and empty. Given the request id this drains that turn's chunks in one pass; the engine parses them exactly as it parses a live stream and finalizes what it read, so each row is recovered at most once. Without it the engine mints no recovery marker at all and behaves as it did before streaming. |
+| `onLiveStreamUpdate`          | `function?` | Observation hook for a streaming turn (`{ serverItemId, ownerKey, phase, text, thinkingText, toolNames, complete, errored }`). The engine already paints the answer text itself, so this is only for affordances it does not decide the presentation of. Never throw from it. |
 
 ### Display and paging helpers
 

package/bunnyquery.css

@@ -664,23 +664,42 @@
     background: var(--bq-paper);
 }
 
+/* ZERO HEIGHT IN FLOW, DELIBERATELY. Mirrors agent.vue, where the reasoning is
+   written out in full: this bar mounts when a history fetch starts and unmounts
+   when the page lands, both while the reader sits at the top of the list, and as
+   an in-flow sticky element it moved every row by its own height each time
+   (measured in Chrome with overflow-anchor:none). The outer box now contributes
+   nothing to layout and the inner strip overflows it, so the bar still sits
+   pinned at the top of the viewport while mounting it moves nothing. */
 .bq-history-loading {
     position: sticky;
     top: 0;
     z-index: 1;
+    height: 0;
+    padding: 0;
+    overflow: visible;
+    pointer-events: none;
+}
+.bq-history-loading-inner {
     display: flex;
+    align-items: center;
     justify-content: center;
     gap: 0.1em;
     padding: 0.5rem 0 1rem;
     font-size: 0.8rem;
     color: var(--bq-muted);
-    background: var(--bq-paper);
+    background: linear-gradient(to bottom, var(--bq-paper) 70%, transparent);
 }
-/* initial first-page load: center it in the (empty) messages area */
+/* initial first-page load: center it in the (empty) messages area. A full-box
+   overlay rather than a top strip, so it takes its height back - and it replaces
+   an EMPTY messages area, so it has nothing to move. */
 .bq-history-loading.is-initial {
     position: absolute;
     inset: 0;
+    height: auto;
+    display: flex;
     align-items: center;
+    justify-content: center;
     padding: 0;
 }
 
@@ -1236,6 +1255,38 @@
 .bq-cancel-queue-btn:hover:not(.is-disabled) { background: var(--bq-warning-bg); color: var(--bq-warning); }
 .bq-cancel-queue-btn.is-disabled { opacity: 0.3; cursor: not-allowed; pointer-events: none; }
 
+/* ---- unfinalized streamed answer (ask for it) ----------------------------
+   A turn whose answer was streamed and never finalized keeps its bytes in the
+   chunk store, and this bubble is what the reader gets when nothing is currently
+   fetching them: the per-load recovery cap left this one behind, or a read failed.
+   It is deliberately NOT the danger red of an error bubble - nothing is broken and
+   nothing is lost, the answer is simply not here yet - and deliberately not a
+   spinner, which would promise an arrival nobody has scheduled. Shared by both
+   chatboxes (this file is bunnyquery/styles/chat.css, which agent.vue imports). */
+.bq-stream-recover-note {
+    display: block;
+    font-size: 0.72rem;
+    color: var(--bq-muted);
+    font-style: italic;
+}
+.bq-bubble.is-stream-failed .bq-stream-recover-note { color: var(--bq-warning); }
+.bq-stream-recover-btn {
+    display: inline-block;
+    margin-top: 0.4rem;
+    padding: 0.18rem 0.55rem;
+    min-height: 0;
+    border: 1px solid var(--bq-line);
+    background: transparent;
+    color: inherit;
+    font-size: 0.72rem;
+    line-height: 1.3;
+    cursor: pointer;
+    box-shadow: none;
+    border-radius: 0;
+}
+.bq-stream-recover-btn:hover { background: rgba(127, 127, 127, 0.12); }
+.bq-bubble.is-stream-failed .bq-stream-recover-btn { border-color: var(--bq-warning-border); color: var(--bq-warning); }
+
 /* ---- collapsed background-indexing group ---------------------------------*/
 /* One file's many indexing passes (first pass + every CONTINUE pass, each with
    a request AND a response bubble) render as a single status row instead of