@burdenoff/fe-libs 2026.1027.10 → 2026.1027.12

package/dist/shared/assistant/voice/assistantPollSchedule.d.ts

@@ -1,9 +1,8 @@
 /**
  * How often to re-check for the assistant's reply while a turn is in flight.
  *
- * The assistant has no streaming transport: the prompt is a fire-and-forget POST
- * and the reply is discovered by re-fetching the message list. So this interval
- * is the granularity of the whole experience — it bounds how late the answer
+ * When the streaming transport is unavailable, the reply is discovered by
+ * polling the message list. This interval bounds how late the answer
  * appears in chat AND how late speech can start, because auto-speak only fires
  * once a poll observes the reply completed.
  *
@@ -11,14 +10,11 @@
  * after the answer was already sitting on the server, and made streamed text
  * arrive in visible jerks rather than flowing.
  *
- * ★ The schedule is a compromise, not free. Every poll re-fetches the newest
- * messages in full rather than a delta, so a faster interval is a real increase
- * in request rate. It is spent where it buys the most — the first few seconds,
+ * The pollers request a creation-time delta (`sinceMs`), retaining the in-flight
+ * message so edits are picked up, with full snapshots for older images. A faster
+ * interval still increases request rate. It is spent in the first few seconds,
  * where most replies land — and given back afterwards, so a long-running turn
  * costs no more than it used to.
- *
- * The proper fix is a delta fetch (`sinceMs`, which the shared client already
- * supports) or a streaming transport; both are larger changes than this.
  */
 /** While the answer is most likely to land. */
 export declare const POLL_FAST_MS = 600;