@mindstudio-ai/remy 0.1.151 → 0.1.153

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;
@@ -790,11 +793,40 @@ function serializeForSummary(messages) {
     return `[${msg.role}]: ${parts.join("\n")}`;
   }).join("\n\n");
 }
+var CHUNK_CHAR_LIMIT = 24e5;
 async function generateSummary(apiConfig, name, compactionPrompt, messagesToSummarize, mainSystem, mainTools) {
   const serialized = serializeForSummary(messagesToSummarize);
   if (!serialized.trim()) {
     return null;
   }
+  if (serialized.length > CHUNK_CHAR_LIMIT && messagesToSummarize.length > 1) {
+    const mid = Math.floor(messagesToSummarize.length / 2);
+    log3.info("Chunking summary", {
+      name,
+      messageCount: messagesToSummarize.length,
+      serializedLength: serialized.length
+    });
+    const [first, second] = await Promise.all([
+      generateSummary(
+        apiConfig,
+        `${name} [pt1]`,
+        compactionPrompt,
+        messagesToSummarize.slice(0, mid),
+        mainSystem,
+        mainTools
+      ),
+      generateSummary(
+        apiConfig,
+        `${name} [pt2]`,
+        compactionPrompt,
+        messagesToSummarize.slice(mid),
+        mainSystem,
+        mainTools
+      )
+    ]);
+    const parts = [first, second].filter((p) => !!p);
+    return parts.length > 0 ? parts.join("\n\n---\n\n") : null;
+  }
   log3.info("Generating summary", {
     name,
     messageCount: messagesToSummarize.length,
@@ -1293,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: {
@@ -2680,28 +2712,6 @@ function acquireBrowserLock() {
   lockQueue = next;
   return wait.then(() => release);
 }
-async function checkBrowserConnected() {
-  try {
-    const status = await sidecarRequest(
-      "/browser-status",
-      {},
-      { timeout: 5e3 }
-    );
-    if (!status.connected) {
-      return {
-        connected: false,
-        reason: BROWSER_UNAVAILABLE_MESSAGE
-      };
-    }
-    return { connected: true };
-  } catch {
-    return {
-      connected: false,
-      reason: BROWSER_UNAVAILABLE_MESSAGE
-    };
-  }
-}
-var BROWSER_UNAVAILABLE_MESSAGE = "Browser preview unavailable \u2014 the user has closed their browser and we are continuing to work in the background. This is not a code failure and not something to diagnose. Do not tell the user to click or open anything. Skip the visual check and verify your work through other means: runMethod for backend behavior, queryDatabase for data checks, .logs/devServer.ndjson for build errors, .logs/browser.ndjson for runtime errors, lspDiagnostics for type/syntax, or read the code directly.";
 
 // src/statusWatcher.ts
 function startStatusWatcher(config) {
@@ -3338,7 +3348,7 @@ var BROWSER_TOOLS = [
   {
     clearable: true,
     name: "browserCommand",
-    description: "Interact with the app's live preview by sending browser commands. Commands execute sequentially with an animated cursor. Always start with a snapshot to see the current state and get ref identifiers. The result includes a snapshot field with the final page state after all steps complete. On error, the failing step has an error field and execution stops. Timeout: 120s.",
+    description: "Interact with the app's live preview by sending browser commands. Commands execute sequentially with an animated cursor. Always start with a snapshot to see the current state and get ref identifiers. The result includes a snapshot field with the final page state after all steps complete. On error, the failing step has an error field and execution stops. Batches that contain an interactive step (click, type, select) also return a `recordingUrl` \u2014 an rrweb session recording for visual replay. Timeout: 120s.",
     inputSchema: {
       type: "object",
       properties: {
@@ -3475,14 +3485,6 @@ var browserAutomationTool = {
     }
     const release = await acquireBrowserLock();
     try {
-      const browserStatus = await checkBrowserConnected();
-      if (!browserStatus.connected) {
-        return browserStatus.reason ?? "Browser preview unavailable.";
-      }
-      try {
-        await sidecarRequest("/reset-browser", {}, { timeout: 5e3 });
-      } catch {
-      }
       const result = await runSubAgent({
         system: getBrowserAutomationPrompt(),
         task: input.task,
@@ -3572,10 +3574,6 @@ var browserAutomationTool = {
         toolRegistry: context.toolRegistry,
         captureArtifacts: ["screenshotFullPage"]
       });
-      try {
-        await sidecarRequest("/reset-browser", {}, { timeout: 5e3 });
-      } catch {
-      }
       context.subAgentMessages?.set(context.toolCallId, result.messages);
       const ss = result.artifacts?.screenshotFullPage;
       if (ss?.url) {
@@ -3661,10 +3659,6 @@ var screenshotTool = {
       }
       const release = await acquireBrowserLock();
       try {
-        const browserStatus = await checkBrowserConnected();
-        if (!browserStatus.connected) {
-          return browserStatus.reason ?? "Browser preview unavailable.";
-        }
         return await captureAndAnalyzeScreenshot({
           prompt: input.prompt,
           path: input.path,
@@ -3999,10 +3993,6 @@ async function execute5(input, onLog, context) {
   }
   const release = await acquireBrowserLock();
   try {
-    const browserStatus = await checkBrowserConnected();
-    if (!browserStatus.connected) {
-      return browserStatus.reason ?? "Browser preview unavailable.";
-    }
     return await captureAndAnalyzeScreenshot({
       prompt: input.prompt,
       path: input.path,
@@ -6791,7 +6781,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: {
@@ -1511,6 +1514,34 @@ async function generateSummary(apiConfig, name, compactionPrompt, messagesToSumm
   if (!serialized.trim()) {
     return null;
   }
+  if (serialized.length > CHUNK_CHAR_LIMIT && messagesToSummarize.length > 1) {
+    const mid = Math.floor(messagesToSummarize.length / 2);
+    log2.info("Chunking summary", {
+      name,
+      messageCount: messagesToSummarize.length,
+      serializedLength: serialized.length
+    });
+    const [first, second] = await Promise.all([
+      generateSummary(
+        apiConfig,
+        `${name} [pt1]`,
+        compactionPrompt,
+        messagesToSummarize.slice(0, mid),
+        mainSystem,
+        mainTools
+      ),
+      generateSummary(
+        apiConfig,
+        `${name} [pt2]`,
+        compactionPrompt,
+        messagesToSummarize.slice(mid),
+        mainSystem,
+        mainTools
+      )
+    ]);
+    const parts = [first, second].filter((p) => !!p);
+    return parts.length > 0 ? parts.join("\n\n---\n\n") : null;
+  }
   log2.info("Generating summary", {
     name,
     messageCount: messagesToSummarize.length,
@@ -1548,7 +1579,7 @@ ${serialized}` : serialized;
   log2.info("Summary generated", { name, summaryLength: summaryText.length });
   return summaryText.trim();
 }
-var log2, CONVERSATION_SUMMARY_PROMPT, SUBAGENT_SUMMARY_PROMPT, SUMMARIZABLE_SUBAGENTS;
+var log2, CONVERSATION_SUMMARY_PROMPT, SUBAGENT_SUMMARY_PROMPT, SUMMARIZABLE_SUBAGENTS, CHUNK_CHAR_LIMIT;
 var init_compaction = __esm({
   "src/compaction/index.ts"() {
     "use strict";
@@ -1559,6 +1590,7 @@ var init_compaction = __esm({
     CONVERSATION_SUMMARY_PROMPT = readAsset("compaction", "conversation.md");
     SUBAGENT_SUMMARY_PROMPT = readAsset("compaction", "subagent.md");
     SUMMARIZABLE_SUBAGENTS = ["visualDesignExpert", "productVision"];
+    CHUNK_CHAR_LIMIT = 24e5;
   }
 });
 
@@ -2958,34 +2990,11 @@ function acquireBrowserLock() {
   lockQueue = next;
   return wait.then(() => release);
 }
-async function checkBrowserConnected() {
-  try {
-    const status = await sidecarRequest(
-      "/browser-status",
-      {},
-      { timeout: 5e3 }
-    );
-    if (!status.connected) {
-      return {
-        connected: false,
-        reason: BROWSER_UNAVAILABLE_MESSAGE
-      };
-    }
-    return { connected: true };
-  } catch {
-    return {
-      connected: false,
-      reason: BROWSER_UNAVAILABLE_MESSAGE
-    };
-  }
-}
-var lockQueue, BROWSER_UNAVAILABLE_MESSAGE;
+var lockQueue;
 var init_browserLock = __esm({
   "src/tools/_helpers/browserLock.ts"() {
     "use strict";
-    init_sidecar();
     lockQueue = Promise.resolve();
-    BROWSER_UNAVAILABLE_MESSAGE = "Browser preview unavailable \u2014 the user has closed their browser and we are continuing to work in the background. This is not a code failure and not something to diagnose. Do not tell the user to click or open anything. Skip the visual check and verify your work through other means: runMethod for backend behavior, queryDatabase for data checks, .logs/devServer.ndjson for build errors, .logs/browser.ndjson for runtime errors, lspDiagnostics for type/syntax, or read the code directly.";
   }
 });
 
@@ -3654,7 +3663,7 @@ var init_tools = __esm({
       {
         clearable: true,
         name: "browserCommand",
-        description: "Interact with the app's live preview by sending browser commands. Commands execute sequentially with an animated cursor. Always start with a snapshot to see the current state and get ref identifiers. The result includes a snapshot field with the final page state after all steps complete. On error, the failing step has an error field and execution stops. Timeout: 120s.",
+        description: "Interact with the app's live preview by sending browser commands. Commands execute sequentially with an animated cursor. Always start with a snapshot to see the current state and get ref identifiers. The result includes a snapshot field with the final page state after all steps complete. On error, the failing step has an error field and execution stops. Batches that contain an interactive step (click, type, select) also return a `recordingUrl` \u2014 an rrweb session recording for visual replay. Timeout: 120s.",
         inputSchema: {
           type: "object",
           properties: {
@@ -3812,14 +3821,6 @@ var init_browserAutomation = __esm({
         }
         const release = await acquireBrowserLock();
         try {
-          const browserStatus = await checkBrowserConnected();
-          if (!browserStatus.connected) {
-            return browserStatus.reason ?? "Browser preview unavailable.";
-          }
-          try {
-            await sidecarRequest("/reset-browser", {}, { timeout: 5e3 });
-          } catch {
-          }
           const result = await runSubAgent({
             system: getBrowserAutomationPrompt(),
             task: input.task,
@@ -3909,10 +3910,6 @@ var init_browserAutomation = __esm({
             toolRegistry: context.toolRegistry,
             captureArtifacts: ["screenshotFullPage"]
           });
-          try {
-            await sidecarRequest("/reset-browser", {}, { timeout: 5e3 });
-          } catch {
-          }
           context.subAgentMessages?.set(context.toolCallId, result.messages);
           const ss = result.artifacts?.screenshotFullPage;
           if (ss?.url) {
@@ -4008,10 +4005,6 @@ var init_screenshot2 = __esm({
           }
           const release = await acquireBrowserLock();
           try {
-            const browserStatus = await checkBrowserConnected();
-            if (!browserStatus.connected) {
-              return browserStatus.reason ?? "Browser preview unavailable.";
-            }
             return await captureAndAnalyzeScreenshot({
               prompt: input.prompt,
               path: input.path,
@@ -4362,10 +4355,6 @@ async function execute5(input, onLog, context) {
   }
   const release = await acquireBrowserLock();
   try {
-    const browserStatus = await checkBrowserConnected();
-    if (!browserStatus.connected) {
-      return browserStatus.reason ?? "Browser preview unavailable.";
-    }
     return await captureAndAnalyzeScreenshot({
       prompt: input.prompt,
       path: input.path,
@@ -7527,7 +7516,6 @@ ${userMessage}` : header;
             requestId,
             error: err.message
           });
-          this.queue.drain();
         }
         this.applyPendingSummaries();
         this.applyPendingBlockUpdates();

package/dist/prompt/.notes.md

@@ -145,7 +145,7 @@ The intro framing ("you have a lot on your plate") gives the model permission to
 | `productVision` | Roadmap ownership & product strategy | writeRoadmapItem, updateRoadmapItem, deleteRoadmapItem | Spec files + current roadmap |
 | `sdkConsultant` | MindStudio SDK architecture | None (shells out to `mindstudio ask` CLI) | None (external agent) |
 | `codeSanityCheck` | Pre-build review | readFile, grep, glob, searchGoogle, fetchUrl, askMindStudioSdk, bash (readonly) | Spec files |
-| `browserAutomation` | Interactive UI testing | browserCommand, screenshot, resetBrowser | None (interacts with live preview) |
+| `browserAutomation` | Interactive UI testing | browserCommand, screenshotFullPage, setupBrowser | None (interacts with live preview) |
 
 ### Shared infrastructure
 
@@ -177,8 +177,6 @@ New `type: roadmap` for MSFM files in `src/roadmap/`. Each item has frontmatter
 - **Automated message sentinel** — `@@automated::{tag}@@` prefix on user messages, stripped before sending to LLM. Frontend uses for custom rendering.
 - **Project naming** — `setProjectName` tool for setting display name after intake.
 - **Dynamic status labels** — `statusWatcher.ts` periodically calls a lightweight endpoint to generate descriptive labels during agent work.
-- **Browser status check** — agent checks `/browser-status` before starting browser automation to fail fast if preview isn't connected.
-- **Browser reset** — `resetBrowser` tool restores preview to clean state after testing.
 - **Asset bundling** — `tsup.config.ts` copies .md/.json/.sh files from src/ to dist/ on build.
 
 ## What's Not Done

package/dist/prompt/static/coding.md

@@ -12,7 +12,7 @@ Run `lspDiagnostics` after every turn where you have edited code in any meaningf
 - Spot-check methods with `runMethod`. The dev database is a disposable snapshot that will have been seeded with scenario data, so don't worry about being destructive.
 - For frontend work, take a single `screenshot` to confirm the main view renders correctly or look at the browser log for any console errors in the user's preview.
 - Use `runAutomatedBrowserTest` to verify an interactive flow that you can't confirm from a screenshot, or when the user reports something broken that you can't identify from code alone.
-- If the browser preview isn't connected, skip the visual check and verify through methods, logs, and code instead. Preview unavailability is an environmental state, not a code issue — the user might have closed their browser and we are continuing to work in the background.
+- If the browser is unavailable, skip the visual check and verify through methods, logs, and code instead. Browser unavailability is an infrastructure issue, not a code problem — don't try to diagnose or fix it.
 
 Aim for confidence that the core happy paths work. If the 80% case is solid, the remaining edge cases are likely fine and the user can surface them in chat. Don't screenshot every page, test every permutation, or verify every secondary flow. One or two runtime checks that confirm the app loads and data flows through is enough.
 

package/dist/prompt/static/instructions.md

@@ -35,8 +35,9 @@ 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.
-- When writing prose or communicating with the user, avoid em dashes (and especially when writing specs); use periods, commas, colons, or parentheses instead. Do not use emojis.
+- When writing prose or communicating with the user, avoid em dashes (and especially when writing specs); use periods, commas, colons, or parentheses instead.
+- Never use emojis when responding to the user.

package/dist/prompt/static/team.md

@@ -44,7 +44,7 @@ The QA agent can see the screen. Describe what to test, not how — it will figu
 
 Never tell QA what names to use when testing or what values to input - it will use its own judgment.
 
-If the browser preview is unavailable, QA can't run. Treat that as an environmental limit, not a problem with the app — the user has closed their browser and we are continuing to work in the background. Do not guide the user to open or click anything. Verify through methods, logs, and code inspection instead, and just note that visual QA was skipped.
+If the browser is unavailable, QA can't run. That's an infrastructure issue, not a problem with the app — don't try to diagnose or fix it. Verify through methods, logs, and code inspection instead, and note that visual QA was skipped.
 
 ### Background Execution
 

package/dist/subagents/browserAutomation/prompt.md

@@ -3,7 +3,7 @@ You are a browser smoke test agent. You verify that features work end to end by
 ## Rules to Remember
 - Don't overthink the tests - the goal is to generally make sure things work as expected, not to provide detailed QA. If something seems mostly okay, note it and move on. Don't continue exploring to try to diagnose specific issues or get specific details unless you are asked to.
 - Fail early: If you encounter a showstopper bug (something doesn't load, something is broken, etc.) do not attempt to diagnose it or work around it. We need core common user paths to work - if they don't the app is broken and testing should not continue until it is fixed. Return early with a report to let the developer fix it, they'll run another test when they're ready.
-- Browser disconnection is environmental, not a test failure. If `browserCommand` returns `BROWSER_DISCONNECTED` or the browser otherwise drops mid-test, the test is **inconclusive** — the user has closed their browser and we are continuing to work in the background. Do not retry, do not attribute it to app brokenness, do not tell the user to open or click anything. Report "test inconclusive: browser disconnected" and stop.
+- Browser unavailability is an infrastructure issue, not a test failure. If `browserCommand` reports the browser is unavailable or drops mid-test, the test is **inconclusive** — do not retry, do not attribute it to app brokenness. Report "test inconclusive: browser unavailable" and stop.
 
 ## Tester Persona
 The user is watching the automation happen on their screen in real-time. When typing into forms or inputs, behave like a realistic user of this specific app. Use the app context (if provided) to understand the audience and tone. Type the way that audience would actually type — not formal, not robotic. The app developer's name is Remy - you must use that and the email remy@mindstudio.ai as the basis for any testing that requires a persona.
@@ -39,7 +39,6 @@ Each interactive element has a `[ref=eN]` you can use to target it.
 - `select`: Select a dropdown option by text. Target the `<select>` element, set `option` to the option text.
 - `wait`: Wait for an element to appear (polls every 100ms, default 5s timeout). Also waits for network to settle after the element is found.
 - `navigate`: Navigate to a new URL within the app. Waits for the new page to load before continuing with subsequent steps. Use this instead of evaluate with `window.location.href` when you need to navigate and then continue interacting with the new page. Steps after navigate execute on the new page automatically.
-- `reload`: Reload the current page. Useful if something has crashed, you can not exit some dynamic screen, or you need to clear stale data or some stale app state. Waits for the page to reload before continuting with subsequent steps. Use this instead of using evaluate to reload a page.
 - `evaluate`: Run arbitrary JavaScript in the page and return the result.
 - `styles`: Read computed CSS styles from page elements. Pass a `properties` array with camelCase CSS property names (e.g., `["backgroundColor", "borderRadius", "fontSize"]`). Omit `properties` for a default set covering colors, typography, spacing, borders, shadows, dimensions, and layout. Uses the same targeting as click/type (ref, text, role, label, selector). Omit the target to get styles for all elements from the last snapshot.
 - `screenshotViewport`: Take a screenshot of the current viewport. Returns CDN url with full text analysis and dimensions. Useful at the end of an action batch to visually see things like layout shift or overflow. Do not use if you can get what you need with other tools - only use when you need to visually see the viewport.
@@ -61,6 +60,7 @@ Each browserCommand returns:
 - `snapshot`: the final page state after all steps complete (always present, even without an explicit snapshot step)
 - `logs`: array of browser-side events that fired during the batch (console output, network failures, JS errors, user interactions). Check this for errors before reporting pass.
 - `duration`: total execution time in ms
+- `recordingUrl` (optional): URL to an rrweb session recording of the tool call. Present whenever the batch contained an interactive step (click, type, select). Include it in your failure reports so the main agent can share it — it's the fastest way to reproduce a bug visually.
 
 On error, the failing step has an `error` field and execution stops. Remaining steps are skipped.
 

package/package.json

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