@mindstudio-ai/remy 0.1.83 → 0.1.84

package/dist/automatedActions/buildFromInitialSpec.md

@@ -6,7 +6,9 @@ This is an automated action triggered by the user pressing "Build" in the editor
 
 The user has reviewed the spec and is ready to build. 
 
-Think about your approach and then get a quick sanity check from `codeSanityCheck` to make sure you aren't missing anything. If you are building a web frontend, consult `visualDesignExpert` for guidance and ideas on specific components, UI patterns, and interactions - it has access to a deep repository of design inspiration and will be able to give you great ideas to work with while building.
+Think about your approach and then get a quick sanity check from `codeSanityCheck` to make sure you aren't missing anything. 
+
+If you are building a web frontend, consult `visualDesignExpert` for guidance and ideas on specific component design, UI patterns, and interactions - it has access to a deep repository of design inspiration and will be able to give you great ideas to work with while building. Don't ask it to design full screens - focus on specific components, moments, and concepts where its ideas can be additive and transformative, you already have the basic design and layout guidance from the spec.
 
 Then, build everything in one turn: methods, tables, interfaces, manifest updates, and scenarios, using the spec as the master plan. Be sure to delete any unnecessary files from the "Hello World" scaffold that already exist in the project.
 

package/dist/headless.js

@@ -3123,15 +3123,6 @@ var BROWSER_TOOLS = [
         }
       }
     }
-  },
-  {
-    clearable: false,
-    name: "resetBrowser",
-    description: "Reset the browser to a clean state. Call this once after all tests are complete to restore the preview for the user. Fire and forget \u2014 does not wait for the reload to finish.",
-    inputSchema: {
-      type: "object",
-      properties: {}
-    }
   }
 ];
 var BROWSER_EXTERNAL_TOOLS = /* @__PURE__ */ new Set(["browserCommand"]);
@@ -3160,7 +3151,7 @@ var browserAutomationTool = {
   clearable: true,
   definition: {
     name: "runAutomatedBrowserTest",
-    description: "Run an automated browser test against the live preview. Describe what to test \u2014 the agent figures out how. Use after meaningful changes frontend code, to reproduce user-reported issues, or to test end-to-end flows.",
+    description: "Run an automated browser test against the live preview. Describe what to test \u2014 the agent figures out how. Use after meaningful changes frontend code, to reproduce user-reported issues, or to test end-to-end flows. Never give it explicit values to use when filling out forms or creating accounts - it will use its own judgement (often it needs to use specific values to trigger dev-mode bypasses of things like login verification codes).",
     inputSchema: {
       type: "object",
       properties: {
@@ -3188,6 +3179,10 @@ var browserAutomationTool = {
     } catch {
       return "Error: could not check browser status. The dev environment may not be running.";
     }
+    try {
+      await sidecarRequest("/reset-browser", {}, { timeout: 5e3 });
+    } catch {
+    }
     const result = await runSubAgent({
       system: getBrowserAutomationPrompt(),
       task: input.task,
@@ -3204,14 +3199,6 @@ var browserAutomationTool = {
             return `Error taking screenshot: ${err.message}`;
           }
         }
-        if (name === "resetBrowser") {
-          try {
-            await sidecarRequest("/reset-browser", {}, { timeout: 5e3 });
-            return "Browser reset triggered.";
-          } catch {
-            return "Error: could not reset browser.";
-          }
-        }
         return `Error: unknown local tool "${name}"`;
       },
       apiConfig: context.apiConfig,
@@ -3267,6 +3254,10 @@ var browserAutomationTool = {
       },
       toolRegistry: context.toolRegistry
     });
+    try {
+      await sidecarRequest("/reset-browser", {}, { timeout: 5e3 });
+    } catch {
+    }
     context.subAgentMessages?.set(context.toolCallId, result.messages);
     return result.text;
   }

package/dist/index.js

@@ -2856,15 +2856,6 @@ var init_tools = __esm({
             }
           }
         }
-      },
-      {
-        clearable: false,
-        name: "resetBrowser",
-        description: "Reset the browser to a clean state. Call this once after all tests are complete to restore the preview for the user. Fire and forget \u2014 does not wait for the reload to finish.",
-        inputSchema: {
-          type: "object",
-          properties: {}
-        }
       }
     ];
     BROWSER_EXTERNAL_TOOLS = /* @__PURE__ */ new Set(["browserCommand"]);
@@ -2956,7 +2947,7 @@ var init_browserAutomation = __esm({
       clearable: true,
       definition: {
         name: "runAutomatedBrowserTest",
-        description: "Run an automated browser test against the live preview. Describe what to test \u2014 the agent figures out how. Use after meaningful changes frontend code, to reproduce user-reported issues, or to test end-to-end flows.",
+        description: "Run an automated browser test against the live preview. Describe what to test \u2014 the agent figures out how. Use after meaningful changes frontend code, to reproduce user-reported issues, or to test end-to-end flows. Never give it explicit values to use when filling out forms or creating accounts - it will use its own judgement (often it needs to use specific values to trigger dev-mode bypasses of things like login verification codes).",
         inputSchema: {
           type: "object",
           properties: {
@@ -2984,6 +2975,10 @@ var init_browserAutomation = __esm({
         } catch {
           return "Error: could not check browser status. The dev environment may not be running.";
         }
+        try {
+          await sidecarRequest("/reset-browser", {}, { timeout: 5e3 });
+        } catch {
+        }
         const result = await runSubAgent({
           system: getBrowserAutomationPrompt(),
           task: input.task,
@@ -3000,14 +2995,6 @@ var init_browserAutomation = __esm({
                 return `Error taking screenshot: ${err.message}`;
               }
             }
-            if (name === "resetBrowser") {
-              try {
-                await sidecarRequest("/reset-browser", {}, { timeout: 5e3 });
-                return "Browser reset triggered.";
-              } catch {
-                return "Error: could not reset browser.";
-              }
-            }
             return `Error: unknown local tool "${name}"`;
           },
           apiConfig: context.apiConfig,
@@ -3063,6 +3050,10 @@ var init_browserAutomation = __esm({
           },
           toolRegistry: context.toolRegistry
         });
+        try {
+          await sidecarRequest("/reset-browser", {}, { timeout: 5e3 });
+        } catch {
+        }
         context.subAgentMessages?.set(context.toolCallId, result.messages);
         return result.text;
       }

package/dist/prompt/compiled/design.md

@@ -80,6 +80,10 @@ The UI should feel instant. Never make the user wait for a server round-trip to
 - **Mutate after actions.** After a successful create/update/delete, call `mutate()` to revalidate the relevant SWR cache rather than manually updating local state.
 - **Skeleton loading.** Show subtle, simple skeletons (light pulse - no shimmer) that mirror the layout on initial load. Never show a blank page or centered spinner while data is loading.
 
+### Errors
+
+Handle errors gracefully. You don't need to design for every error case, but if remote API requests fail, make sure to show them nicely in a toast or some other appropriate view with a human-friendly label - don't just drop "Error 500 XYZ" inline in a form.
+
 ## Auth
 
 Login and signup screens set the tone for the user's entire experience with the app and are important to get right - they should feel like exciting entry points into the next level of the user journy. A janky login form with misaligned inputs and no feedback dminishes excitement and undermines trust before the user even gets in.

package/dist/prompt/static/coding.md

@@ -19,7 +19,7 @@ Aim for confidence that the core happy paths work. If the 80% case is solid, the
 
 Process logs are available at .logs/ in NDJSON format (one JSON object per line) for debugging. Each line has at minimum ts (unix millis) and msg fields, plus structured context like level, module, requestId, toolCallId where available. You can use `jq` to examine logs and debug failures. Tools like run method or run scenario execute synchronously, so log data will be available by the time those tools return their results to you, there is no need to `sleep` before querying logfiles.
   - `.logs/tunnel.ndjson`: method execution, schema sync, session lifecycle, platform connection
-  - `.logs/devServer.ndjson`: frontend build errors, HMR, module resolution failures
+  - `.logs/devServer.ndjson`: frontend build errors, HMR, module resolution failures - check this to see if compilation is broken on web frontends.
   - `.logs/system.ndjson`: sandbox server logs — agent lifecycle, tool dispatch, file watching, process management
   - `.logs/agent.ndjson`: coding agent protocol events and errors
   - `.logs/requests.ndjson`: structured log of every method and scenario execution with full input, output, errors (including stack traces), console output, and duration

package/dist/prompt/static/team.md

@@ -40,7 +40,9 @@ Always consult the code sanity check before writing code in initialCodegen with
 
 For verifying complex stateful interactions: multi-step form submissions, auth flows, real-time updates, flows that require specific data/role setup. This spins up a full chrome browser automation — it's heavyweight and takes minutes to complete a full test. Do not use it for basic rendering or navigation checks. If you can verify something with a screenshot or by reading the code, do that instead. Don't run it constantly after making small changes - save it for meaningful work. Run a scenario first to seed test data and set user roles. The user is able to watch QA work on their screen via a live browser preview - the cursor will move, type, etc - so you can also use this to demo functionality to the user and help them understand how to use their app.
 
-The QA agent can see the screen. Describe what to test, not how — it will figure out what to click, what to check, and what values to use. Never give it explicit values to use when filling out forms or creating accounts - it will use its own judgement (and sometimes it needs to use specific values to trigger dev-mode bypasses of things like login verification codes).
+The QA agent can see the screen. Describe what to test, not how — it will figure out what to click, what to check, and what values to use. It always starts its tests logged out/unauthenticated on "/" root. After every test session, the browser is reset to / and any authentication used or created by the tester is cleared and reset.
+
+Never tell QA what names to use when testing or what values to input - it will use its own judgment.
 
 ### Background Execution
 

package/dist/subagents/browserAutomation/prompt.md

@@ -11,6 +11,9 @@ The user is watching the automation happen on their screen in real-time. When ty
 When the app has a login or signup flow, you must use `remy@mindstudio.ai` for email and `+15551234567` for phone number. In the dev environment, verification codes are bypassed for this email address only and any 555-prefixed phone number — enter any 6-digit code (e.g., `123456`) and it will be accepted. If the content you are trying to test is gated behind auth, always use these credentials to login and continue testing.
 
 ## Browser Commands
+
+Your session always starts on the app root / in a logged out/unauthenticated state.
+
 ### Snapshot format
 
 The snapshot command returns a compact accessibility tree:
@@ -143,7 +146,6 @@ You can use the `screenshotFullPage` tool to take a full-height screenshot of th
   - evaluate auto-returns simple expressions. `"script": "document.title"` works directly. For multi-statement scripts, use explicit return.
   - The snapshot in the response is always the most current page state. Even if a wait times out, check the snapshot field; the content you were waiting for may have appeared by then.
   - Execution stops on first error. If step 2 of 5 fails, steps 3-5 don't run. The response will contain results for steps 0-2 (with step 2 having an error field) plus the current snapshot. Adjust and retry from the failed step.
-  - Always call `resetBrowser` as your final action after all tests are complete. This restores the preview to a clean state for the user.
   - If something fails, bail early. Do not attempt to diagnose why; do not do things like attempt different inputs to try to work around an error - just report the failure and early return.
 </rules>
 

package/dist/subagents/designExpert/prompts/images.md

@@ -69,9 +69,9 @@ The developer should never need to source their own imagery. Always provide URLs
 
 ### Icons and logos
 
-App icons and logos require work and thinking to get right. They need to be simple, clean, and legible at small sizes, which is the opposite of what unconstrained generation tends to produce.
+App icons and logos require work and thinking to get right.
 
-**What works:** Smooth 3D rendering in the style of current macOS/iOS app icons. One clear object or symbol — rounded, immediately recognizable, emoji/toy-like proportions. Clean surfaces with soft lighting and gentle shadows. Two or three accent colors, not a rainbow. Always generate with `transparentBackground: true`.
+**What works:** Smooth 3D rendering in the style of 2026-era macOS/iOS app icons. One clear object or symbol — rounded, immediately recognizable, emoji/toy-like proportions. Clean surfaces with soft lighting and gentle shadows. Two or three accent colors, not a rainbow. Always full bleed.
 
 **What doesn't work:** Flat illustration looks dated, photorealistic rendering is too noisy at small sizes, overly detailed scenes become illegible.
 

package/dist/subagents/designExpert/prompts/ui-patterns.md

@@ -29,3 +29,87 @@ Authentication moments must feel natural and intuitive - they should not feel ja
 If the app includes an AI chat interface, take care to make it beautiful and intentional. A good chat interface feels like magic, a bad one feels like a broken customer service bot that will leave the user frustrated and annoyed.
 
 Pay close attention to text streaming when the AI replies - it should feel natural, smooth, and beautiful. There must never be any abrupt layout shift for tool use or new messages, and scrolling should feel natural - like you are in a well-designed iOS chat app. Make sure to specify styles, layouts, animations, and remind the developer of things to watch out for. Reference chat apps you know are well-designed, this is not the place to re-invent the wheel. Users have expectations about how chat works and we should meet them and surpass them.
+
+### Wireframes
+
+When a pattern or interaction is hard to convey in words alone — an animation sequence, a swipe gesture, a layout grid — you can include a small interactive wireframe to demonstrate it. Use a markdown code fence with `wireframe` as the type. Start with a YAML frontmatter block (`name` and `description`) to identify the component, then the self-contained HTML+CSS prototype.
+
+Wireframes replace the ASCII art and code-block diagrams you might otherwise reach for when trying to show a layout or interaction. They're better — the developer can actually see and interact with the result. Like those diagrams, they isolate one small piece: a single card component, a button animation, a transition, a grid layout. Each wireframe should be around 60-80 lines of HTML+CSS — if you're past 100 lines, you're building too much. These are not screens, flows, or multi-step prototypes. They render in a small iframe and should look complete at that scale. Most of your communication should be in words - wireframes are simply another tool when you need them. Never build out full screens or pages in wireframes, even if you are asked to - this is critically important.
+
+The wireframe code will be rendered in a transparent iframe. Don't fill the viewport or add a background color to the body. Place the component at a natural size in a card with a background color that is centered vertically and horizontally in the viewport. Keep the component tight and self-contained. The iframe is for the component only — no annotations, labels, or explanatory text inside it. Put your notes and implementation guidance in the markdown around the wireframe. Wireframes can be interactive and are especially useful for demonstrating states, animations, effects, and transitions. If your wireframe has triggers or states, include a small "play" control button within the frame. No images - these are functional prototypes meant to demonstrate feel and behavior, not visual comps.
+
+```wireframe
+---
+name: Feed Post Card
+description: Photo post card with header, image frame, action row (like/comment/share/bookmark), like count, and caption. Shows spacing, typography hierarchy, and icon placement.
+---
+<html lang="en"><head>
+<meta charset="utf-8"/>
+<meta content="width=device-width, initial-scale=1.0" name="viewport"/>
+<link href="https://fonts.googleapis.com/css2?family=Plus+Jakarta+Sans:wght@400;500;600&display=swap" rel="stylesheet"/>
+<link href="https://fonts.googleapis.com/css2?family=Material+Symbols+Outlined:wght,FILL@100..700,0..1&display=swap" rel="stylesheet"/>
+<style>
+  * { margin: 0; padding: 0; box-sizing: border-box; }
+  body {
+    font-family: 'Plus Jakarta Sans', sans-serif; background: transparent;
+    display: flex; align-items: center; justify-content: center;
+  }
+  .material-symbols-outlined { font-variation-settings: 'FILL' 0, 'wght' 300; }
+
+  .card {
+    width: 340px;
+    background: #fff; border-radius: 20px; overflow: hidden;
+    box-shadow: 0 8px 32px rgba(0,0,0,0.06);
+  }
+  .card-header {
+    padding: 20px 24px; display: flex; align-items: center; gap: 12px;
+  }
+  .avatar {
+    width: 40px; height: 40px; border-radius: 50%;
+    background: linear-gradient(135deg, #98a68e, #55624d);
+  }
+  .card-header .name { font-weight: 600; font-size: 14px; color: #191c18; }
+  .card-header .meta { font-size: 12px; color: #757870; margin-top: 2px; }
+  .card-image {
+    width: 100%; aspect-ratio: 4/5; background: linear-gradient(180deg, #d9e7cd 0%, #fed7d2 100%);
+  }
+  .card-actions {
+    padding: 16px 24px; display: flex; gap: 16px; align-items: center;
+  }
+  .card-actions button {
+    background: none; border: none; cursor: pointer; color: #444841;
+    display: flex; align-items: center; transition: color 0.15s;
+  }
+  .card-actions button:hover { color: #55624d; }
+  .card-actions .spacer { flex: 1; }
+  .card-body { padding: 0 24px 20px; }
+  .card-body .likes { font-weight: 600; font-size: 13px; color: #191c18; margin-bottom: 6px; }
+  .card-body .caption { font-size: 13px; color: #444841; line-height: 1.5; }
+  .card-body .caption strong { font-weight: 600; color: #191c18; }
+</style>
+</head>
+<body>
+  <div class="card">
+    <div class="card-header">
+      <div class="avatar"></div>
+      <div>
+        <div class="name">sarah.chen</div>
+        <div class="meta">Golden Gate Park · 2h</div>
+      </div>
+    </div>
+    <div class="card-image"></div>
+    <div class="card-actions">
+      <button><span class="material-symbols-outlined">favorite</span></button>
+      <button><span class="material-symbols-outlined">chat_bubble</span></button>
+      <button><span class="material-symbols-outlined">send</span></button>
+      <span class="spacer"></span>
+      <button><span class="material-symbols-outlined">bookmark</span></button>
+    </div>
+    <div class="card-body">
+      <div class="likes">2,847 likes</div>
+      <div class="caption"><strong>sarah.chen</strong> Morning light through the eucalyptus grove</div>
+    </div>
+  </div>
+</body>
+</html>
+```

package/dist/subagents/designExpert/tools/images/enhance-image-prompt.md

@@ -50,12 +50,12 @@ For photorealistic images, be specific about:
 
 For app icons and logos, the goal is something that reads clearly at small sizes and feels polished enough to sit on a home screen or in an app header.
 
-- Frame as "A 3D icon against a white background:" followed by the subject. Do NOT use the phrase "app icon" — it triggers mockup framing (the model renders an icon inset on a phone screen or mounted on a wall). "3D icon" works.
+- Frame as "A 3D icon against a XYZ background" followed by the subject. Do NOT use the phrase "app icon" — it triggers mockup framing (the model renders an icon inset on a phone screen or mounted on a wall). "3D icon" works.
 - Describe smooth, rounded emoji-type 3D objects — think current macOS/iOS app icon design language. Clean surfaces, soft lighting, gentle shadows. Not flat illustration, not photorealistic, not clay/matte.
 - Subjects should be simplified and immediately recognizable. Prefer one clear object or symbol, not a scene.
 - Specify "reads well at small sizes" as an explicit constraint.
 - Keep color intentional and limited — two or three accent colors plus the object's base tone. Colors should complement the app's brand if known.
-- Always use transparent background for icons and logos.
+- Make sure to specify full bleed - never say anything about rounded corners or there is a high likelihood that the image will come back as a rounded rectangle on a white background!
 
 ## Output
 

package/package.json

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