@marketrix.ai/widget 4.0.135 → 4.0.136

package/dist/src/components/views/ChatView.d.ts

@@ -6,7 +6,11 @@
  * shell's toolbar button fills with a share toggle, and the composer textarea ref. `MODES` pairs the
  * mode chips' display order with the tenant setting enabling each, so the composer offers only what
  * the workspace turned on. `ChatView` owns the draft text; `handleSendMessage` posts the turn and
- * `handleModeChange` announces a mode switch in the transcript before flipping state.
+ * `handleModeChange` announces a mode switch in the transcript before flipping state. A POST failure
+ * restores the composed text to the (now-cleared) composer — `messageDispatch`'s resolved `false` —
+ * unless the visitor already started typing a new message in the meantime, so a resend is one tap on
+ * Send rather than a retype, and the failed turn's own bubble (added optimistically, unconditionally)
+ * still shows what was said either way.
  *
  * The composer is locked both while a reply is outstanding and while a screen-access request is open,
  * since a second turn queued behind an unanswered permission card has nowhere to land. `use_screenshare`

package/dist/src/context/ChatContext.d.ts

@@ -8,15 +8,30 @@
  * defers updaters and loses the effects captured in them, so tool calls never execute. `messageDispatch`
  * POSTs fire-and-forget: the reply arrives over SSE, so only a POST failure resolves the placeholder
  * locally, and a stale-reply watchdog keyed on id AND part count re-arms on every progress line.
+ * `messageDispatch` resolves `false` on that same POST failure (`true` otherwise, including preview
+ * mode) so a caller holding the composed text — `ChatView`'s composer — can restore it instead of the
+ * visitor having to retype a message the widget already dropped from the input box.
  *
  * The stream effect subscribes to the `StreamClient` singleton: `handleMessage` does the bookkeeping the
- * pure reducer cannot hold (`tool_call_id` dedupe in a bounded set, cleared on a terminal status), then
- * each effect runs its browser tool, stamps progress, replies `tool/response` and only then fires
- * `afterResponseAttempt`. `handleError` converts only a `StreamGaveUpError` into a transport failure, as a
- * retriable blip settles when the reply lands on the reconnected stream. `stopTask` sends `chat/stop`,
- * which carries no task id. Every failure on the tool and stop paths reaches `uiActions.setError` as well
- * as the console: an undelivered `tool/response` leaves the agent waiting on a reply that never comes, so
- * the run stalls with nothing on screen unless the visitor is told, and `do` mode may still be clicking.
+ * pure reducer cannot hold (`tool_call_id` dedupe in a bounded set, cleared on a terminal status; the
+ * mirror-shaped `respondedRequestIds` below), then each effect runs its browser tool, stamps progress,
+ * replies `tool/response` and only then fires `afterResponseAttempt`. `handleError` converts only a
+ * `StreamGaveUpError` into a transport failure, as a retriable blip settles when the reply lands on the
+ * reconnected stream. `stopTask` sends `chat/stop`, which carries no task id. Every failure on the tool
+ * and stop paths reaches `uiActions.setError` as well as the console: an undelivered `tool/response`
+ * leaves the agent waiting on a reply that never comes, so the run stalls with nothing on screen unless
+ * the visitor is told, and `do` mode may still be clicking.
+ *
+ * `respondedRequestIds` closes the other half of the reconnect-replay contract `StreamClient.ts`
+ * documents (the api replays a chat_id's whole turn history, not just the tail a client missed):
+ * `reduceText`'s own exact-repeat guard (`sseReducer.ts`) only catches an identical FINAL
+ * `chat/response` replayed after the answer already closed, because it only ever compares against the
+ * message's LAST part. A replayed `chat/delta` fails that same-string check (it's a partial fragment,
+ * not the full closed text) and would otherwise be appended as a brand-new, visibly duplicated text
+ * segment ahead of the closing response that then only overwrites the one it just added — leaving two
+ * copies of the same answer on screen. Scoped by `request_id`, not globally, so an unrelated later
+ * turn's genuinely new `chat/delta`/`chat/response` is untouched; marked closed only once, on the
+ * request's own terminal `chat/response`, since a delta is by definition still open.
  *
  * `lastStreamErrorRef`/`currentErrorRef` close the loop `handleError` alone leaves open: `StreamClient`
  * calls `onError` on every failed dial, not only a terminal give-up, so the visitor sees "Stream
@@ -43,7 +58,7 @@ interface ChatActions {
     removeMessage: (messageId: string) => void;
     setMessages: (messages: ChatMessage[]) => void;
     clearMessages: () => void;
-    messageDispatch: (content: string, mode?: InstructionType, skipUserMessage?: boolean) => Promise<void>;
+    messageDispatch: (content: string, mode?: InstructionType, skipUserMessage?: boolean) => Promise<boolean>;
 }
 interface TaskActions {
     resetTask: () => void;

package/dist/src/hooks/useWidget.d.ts

@@ -21,7 +21,7 @@ export declare const useWidget: () => {
         removeMessage: (messageId: string) => void;
         setMessages: (messages: import("..").ChatMessage[]) => void;
         clearMessages: () => void;
-        messageDispatch: (content: string, mode?: import("..").InstructionType, skipUserMessage?: boolean) => Promise<void>;
+        messageDispatch: (content: string, mode?: import("..").InstructionType, skipUserMessage?: boolean) => Promise<boolean>;
         resetTask: () => void;
         stopTask: () => Promise<void>;
         setActiveView: (view: import("../types").WidgetView) => void;

package/dist/src/sdk/contracts/entities.d.ts

@@ -135,6 +135,12 @@ export declare const WorkspaceSummarySchema: z.ZodObject<{
     notify_all_members_on_question: z.ZodBoolean;
 }, z.core.$strip>;
 export type WorkspaceSummary = z.infer<typeof WorkspaceSummarySchema>;
+export declare const ApplicationSkillDistillationStatusSchema: z.ZodEnum<{
+    failed: "failed";
+    idle: "idle";
+    pending: "pending";
+}>;
+export type ApplicationSkillDistillationStatus = z.infer<typeof ApplicationSkillDistillationStatusSchema>;
 export declare const ApplicationEntitySchema: z.ZodObject<{
     id: z.ZodNumber;
     created_at: z.ZodCoercedDate<unknown>;
@@ -150,6 +156,12 @@ export declare const ApplicationEntitySchema: z.ZodObject<{
     username: z.ZodNullable<z.ZodString>;
     password: z.ZodNullable<z.ZodString>;
     allowed_domains: z.ZodArray<z.ZodString>;
+    skill_distillation_status: z.ZodEnum<{
+        failed: "failed";
+        idle: "idle";
+        pending: "pending";
+    }>;
+    skill_distillation_error: z.ZodNullable<z.ZodString>;
 }, z.core.$strip>;
 export type ApplicationData = z.infer<typeof ApplicationEntitySchema>;
 /** Used for all API responses; password is write-only and never returned to clients. */
@@ -167,6 +179,12 @@ export declare const ApplicationReadSchema: z.ZodObject<{
     workspace_id: z.ZodNumber;
     username: z.ZodNullable<z.ZodString>;
     allowed_domains: z.ZodArray<z.ZodString>;
+    skill_distillation_status: z.ZodEnum<{
+        failed: "failed";
+        idle: "idle";
+        pending: "pending";
+    }>;
+    skill_distillation_error: z.ZodNullable<z.ZodString>;
 }, z.core.$strip>;
 export type ApplicationReadData = z.infer<typeof ApplicationReadSchema>;
 export declare const WidgetChipSchema: z.ZodObject<{

package/dist/src/services/StorageService.d.ts

@@ -5,7 +5,12 @@
  * browser-local key shares via `scopedKey`, so the chat-context, drag-position and resize keys all
  * partition by tenant identically. `readLocal`/`writeLocal` are the only `localStorage` access in `src/`;
  * a host page can deny storage outright (third-party cookies off, sandboxed iframe), so both degrade to
- * a warn and the widget keeps working unpersisted.
+ * memory and the widget keeps working unpersisted. `updateContext` calls `writeLocal` on every UI-state
+ * change (a drag, a resize, every chat message), so without `warnOnce` a denied host page would spam one
+ * console line per write for the visitor's whole session; a single warn on first denial says everything
+ * a customer's console needs. `warnOnce` is keyed by read vs. write since `readLocal` also fires once on
+ * its own (`loadContext` at module init, before any write) and both should still surface if a page
+ * somehow denies one and not the other.
  *
  * `loadContext` merges one parsed key over `DEFAULT_CONTEXT`, so an older widget version's payload reads
  * as incomplete rather than corrupt, and discards anything past `CONTEXT_EXPIRY_MS` (7 days).
@@ -55,6 +60,10 @@ type MarketrixChatContext = Omit<ChatSnapshot, 'messages'> & {
 };
 export declare function tenantScope(config: MarketrixConfig): string;
 export declare function scopedKey(name: string, config: MarketrixConfig): string;
+/** Test-only: `warned` is module-level so a "denies storage, keeps working" proof isn't the last test in
+ * the file to touch a denied `Storage.prototype`, and a later test in the same `bun test` process (one
+ * process per file, not per test) would otherwise see zero warns instead of one. Never called from `src/`. */
+export declare function resetStorageWarningsForTests(): void;
 export declare function readLocal(key: string): string | null;
 export declare function writeLocal(key: string, value: string): void;
 declare class StorageService {

package/dist/src/services/StreamClient.d.ts

@@ -6,7 +6,10 @@
  *
  * `open` is the transport, `registered` is the chat: only the latter can carry a reply, so `isConnected` reads
  * `registered` and nothing waits on `open`. Backoff counters reset only on `registered` — resetting at `open` would
- * defeat the max-attempts cap if registration never lands and the stream flaps open→closed. Tabs share the
+ * defeat the max-attempts cap if registration never lands and the stream flaps open→closed. `scheduleReconnect`'s
+ * EQUAL JITTER (the doubling delay's own second half, chosen uniformly) keeps every dial within the documented
+ * schedule's bound while stopping every tab across every open customer page from redialing on the exact same
+ * clock tick after a shared outage — a thundering herd the deterministic schedule alone cannot prevent. Tabs share the
  * localStorage chat id, so the server keys SSE by (chat_id, tab_id) and `tabId` stops tabs evicting each other's
  * stream. Credentials are read at connect time, not captured at init, so a reconnect after `updateMarketrixConfig`
  * dials with the current ones.