@mindstudio-ai/remy 0.1.152 → 0.1.154

package/dist/headless.js

@@ -486,18 +486,21 @@ async function* streamChat(params) {
         })
       ]);
       clearTimeout(stallTimer);
-    } catch {
+    } catch (err) {
       clearTimeout(stallTimer);
-      await reader.cancel();
-      log2.error("Stream stalled", {
+      try {
+        await reader.cancel();
+      } catch {
+      }
+      const isStall = err?.message === "stream_stall";
+      const errorMessage = isStall ? "Stream stalled \u2014 no data received for 5 minutes" : `Network error: stream interrupted \u2014 ${err?.message ?? "unknown"}`;
+      log2.error(isStall ? "Stream stalled" : "Stream interrupted", {
         requestId,
         ...subAgentId && { subAgentId },
-        durationMs: Date.now() - startTime
+        durationMs: Date.now() - startTime,
+        error: errorMessage
       });
-      yield {
-        type: "error",
-        error: "Stream stalled \u2014 no data received for 5 minutes"
-      };
+      yield { type: "error", error: errorMessage };
       return;
     }
     const { done, value } = readResult;
@@ -1322,7 +1325,7 @@ var writePlanTool = {
   clearable: false,
   definition: {
     name: "writePlan",
-    description: "Write an implementation plan for user approval before making changes. Use this only for large, multi-step changes like new features, new interface types, or when the user explicitly asks to see a plan. Most work should be done autonomously without a plan. Write a clear markdown summary of what you intend to do in plain language \u2014 describe the changes from the user's perspective, not as a list of files and code paths. The plan is displayed standalone in the UI with approve/reject buttons, so write only the plan itself \u2014 no conversational text, no 'what do you think?', no next-steps narration. Say those things in your chat message instead. If the user asks for revisions, call this tool again with updated content to overwrite the plan.",
+    description: "Write an implementation plan for user approval before making changes. Use this only for large, multi-step changes like new features, new interface types, or when the user explicitly asks to see a plan. Most work should be done autonomously without a plan. Write a clear markdown summary of what you intend to do in plain language \u2014 describe the changes from the user's perspective, not as a list of files and code paths. The plan is displayed standalone in the UI with approve/reject buttons attached; the plan content itself is just the substantive sections and ends when those do. Any wrap-up to the user \u2014 sign-offs, prompts for approval, offers to revise \u2014 belongs in your chat message alongside the plan, not inside it. If the user asks for revisions, call this tool again with updated content to overwrite the plan.",
     inputSchema: {
       type: "object",
       properties: {
@@ -6054,21 +6057,7 @@ function resolveUniqueFilename(name) {
   }
   return `${base}-${counter}${ext}`;
 }
-var IMAGE_EXTENSIONS = /* @__PURE__ */ new Set([
-  ".png",
-  ".jpg",
-  ".jpeg",
-  ".gif",
-  ".webp",
-  ".svg",
-  ".bmp",
-  ".ico",
-  ".tiff",
-  ".tif",
-  ".avif",
-  ".heic",
-  ".heif"
-]);
+var IMAGE_EXTENSIONS = /* @__PURE__ */ new Set([".png", ".jpg", ".jpeg", ".gif", ".webp"]);
 function isImageAttachment(att) {
   const name = att.filename || filenameFromUrl(att.url);
   return IMAGE_EXTENSIONS.has(extname(name).toLowerCase());
@@ -6778,7 +6767,6 @@ ${userMessage}` : header;
         requestId,
         error: err.message
       });
-      this.queue.drain();
     }
     this.applyPendingSummaries();
     this.applyPendingBlockUpdates();

package/dist/index.js

@@ -171,18 +171,21 @@ async function* streamChat(params) {
         })
       ]);
       clearTimeout(stallTimer);
-    } catch {
+    } catch (err) {
       clearTimeout(stallTimer);
-      await reader.cancel();
-      log.error("Stream stalled", {
+      try {
+        await reader.cancel();
+      } catch {
+      }
+      const isStall = err?.message === "stream_stall";
+      const errorMessage = isStall ? "Stream stalled \u2014 no data received for 5 minutes" : `Network error: stream interrupted \u2014 ${err?.message ?? "unknown"}`;
+      log.error(isStall ? "Stream stalled" : "Stream interrupted", {
         requestId,
         ...subAgentId && { subAgentId },
-        durationMs: Date.now() - startTime
+        durationMs: Date.now() - startTime,
+        error: errorMessage
       });
-      yield {
-        type: "error",
-        error: "Stream stalled \u2014 no data received for 5 minutes"
-      };
+      yield { type: "error", error: errorMessage };
       return;
     }
     const { done, value } = readResult;
@@ -834,7 +837,7 @@ var init_writePlan = __esm({
       clearable: false,
       definition: {
         name: "writePlan",
-        description: "Write an implementation plan for user approval before making changes. Use this only for large, multi-step changes like new features, new interface types, or when the user explicitly asks to see a plan. Most work should be done autonomously without a plan. Write a clear markdown summary of what you intend to do in plain language \u2014 describe the changes from the user's perspective, not as a list of files and code paths. The plan is displayed standalone in the UI with approve/reject buttons, so write only the plan itself \u2014 no conversational text, no 'what do you think?', no next-steps narration. Say those things in your chat message instead. If the user asks for revisions, call this tool again with updated content to overwrite the plan.",
+        description: "Write an implementation plan for user approval before making changes. Use this only for large, multi-step changes like new features, new interface types, or when the user explicitly asks to see a plan. Most work should be done autonomously without a plan. Write a clear markdown summary of what you intend to do in plain language \u2014 describe the changes from the user's perspective, not as a list of files and code paths. The plan is displayed standalone in the UI with approve/reject buttons attached; the plan content itself is just the substantive sections and ends when those do. Any wrap-up to the user \u2014 sign-offs, prompts for approval, offers to revise \u2014 belongs in your chat message alongside the plan, not inside it. If the user asks for revisions, call this tool again with updated content to overwrite the plan.",
         inputSchema: {
           type: "object",
           properties: {
@@ -6819,21 +6822,7 @@ var init_attachments = __esm({
     init_logger();
     log11 = createLogger("headless:attachments");
     UPLOADS_DIR = "src/.user-uploads";
-    IMAGE_EXTENSIONS = /* @__PURE__ */ new Set([
-      ".png",
-      ".jpg",
-      ".jpeg",
-      ".gif",
-      ".webp",
-      ".svg",
-      ".bmp",
-      ".ico",
-      ".tiff",
-      ".tif",
-      ".avif",
-      ".heic",
-      ".heif"
-    ]);
+    IMAGE_EXTENSIONS = /* @__PURE__ */ new Set([".png", ".jpg", ".jpeg", ".gif", ".webp"]);
   }
 });
 
@@ -7513,7 +7502,6 @@ ${userMessage}` : header;
             requestId,
             error: err.message
           });
-          this.queue.drain();
         }
         this.applyPendingSummaries();
         this.applyPendingBlockUpdates();

package/dist/prompt/static/instructions.md

@@ -35,7 +35,7 @@ You will occasionally receive automated messages prefixed with `@@automated_mess
 
 ## Style
 - Your messages are rendered as markdown. Use formatting (headers, bold, lists, code blocks) when it helps readability. You can include images using `![alt](url)` — use this to show the user screenshots, generated images, or other visual references inline in your messages.
-- When offering suggestions or options the user might want to quickly select in a conversation, format them as clickable suggestion links: `[suggestion text](suggest:suggestion text)`. These render as clickable chips in the UI. When clicked, the suggestion text is sent as the user's next message. Use these liberally: when brainstorming, offering directions, listing options, or any time you're asking a question the user could answer with a quick tap. When explicitly gathering information from the user, however, always use the `promptUser` tool instead.
+- When offering suggestions or options the user might want to quickly select in a conversation, format them as clickable suggestion links: `[label](suggest:message sent on click)`. The label renders as a tappable chip and should be a few words — chip-sized, not sentence-sized. The `suggest:` payload can be longer; that's what gets sent as the user's next message when clicked. Use these liberally: when brainstorming, offering directions, listing options, or any time you're asking a question the user could answer with a quick tap. When explicitly gathering information from the user, however, always use the `promptUser` tool instead.
 - Keep language accessible. Describe what the app *does*, not how it's implemented, unless the user demonstrates technical fluency.
 - Always use full paths relative to the project root when mentioning files (`dist/interfaces/web/src/App.tsx`, not `App.tsx`). Paths will be rendered as clickable links for the user.
 - Use inline `code` formatting only for things the user needs to type or search for.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@mindstudio-ai/remy",
-  "version": "0.1.152",
+  "version": "0.1.154",
   "description": "MindStudio coding agent",
   "repository": {
     "type": "git",