@mindstudio-ai/remy 0.1.83 → 0.1.85

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"]);
@@ -3156,11 +3147,21 @@ ${appSpec}
 
 // src/subagents/browserAutomation/index.ts
 var log6 = createLogger("browser-automation");
+var lockQueue = Promise.resolve();
+function acquireBrowserLock() {
+  let release;
+  const next = new Promise((res) => {
+    release = res;
+  });
+  const wait = lockQueue;
+  lockQueue = next;
+  return wait.then(() => release);
+}
 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: {
@@ -3176,99 +3177,104 @@ var browserAutomationTool = {
     if (!context) {
       return "Error: browser automation requires execution context (only available in headless mode)";
     }
+    const release = await acquireBrowserLock();
     try {
-      const status = await sidecarRequest(
-        "/browser-status",
-        {},
-        { timeout: 5e3 }
-      );
-      if (!status.connected) {
-        return "Error: the browser preview is not connected. The user needs to open the preview before browser tests can run.";
+      try {
+        const status = await sidecarRequest(
+          "/browser-status",
+          {},
+          { timeout: 5e3 }
+        );
+        if (!status.connected) {
+          return "Error: the browser preview is not connected. The user needs to open the preview before browser tests can run.";
+        }
+      } catch {
+        return "Error: could not check browser status. The dev environment may not be running.";
       }
-    } catch {
-      return "Error: could not check browser status. The dev environment may not be running.";
-    }
-    const result = await runSubAgent({
-      system: getBrowserAutomationPrompt(),
-      task: input.task,
-      tools: BROWSER_TOOLS,
-      externalTools: BROWSER_EXTERNAL_TOOLS,
-      executeTool: async (name, _input, _toolCallId, onLog) => {
-        if (name === "screenshotFullPage") {
-          try {
-            return await captureAndAnalyzeScreenshot({
-              path: _input.path,
-              onLog
-            });
-          } catch (err) {
-            return `Error taking screenshot: ${err.message}`;
+      try {
+        await sidecarRequest("/reset-browser", {}, { timeout: 5e3 });
+      } catch {
+      }
+      const result = await runSubAgent({
+        system: getBrowserAutomationPrompt(),
+        task: input.task,
+        tools: BROWSER_TOOLS,
+        externalTools: BROWSER_EXTERNAL_TOOLS,
+        executeTool: async (name, _input, _toolCallId, onLog) => {
+          if (name === "screenshotFullPage") {
+            try {
+              return await captureAndAnalyzeScreenshot({
+                path: _input.path,
+                onLog
+              });
+            } catch (err) {
+              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,
+        model: context.model,
+        subAgentId: "browserAutomation",
+        signal: context.signal,
+        parentToolId: context.toolCallId,
+        requestId: context.requestId,
+        onEvent: context.onEvent,
+        resolveExternalTool: async (id, name, input2) => {
+          if (!context.resolveExternalTool) {
+            return "Error: no external tool resolver";
           }
-        }
-        return `Error: unknown local tool "${name}"`;
-      },
-      apiConfig: context.apiConfig,
-      model: context.model,
-      subAgentId: "browserAutomation",
-      signal: context.signal,
-      parentToolId: context.toolCallId,
-      requestId: context.requestId,
-      onEvent: context.onEvent,
-      resolveExternalTool: async (id, name, input2) => {
-        if (!context.resolveExternalTool) {
-          return "Error: no external tool resolver";
-        }
-        const result2 = await context.resolveExternalTool(id, name, input2);
-        if (name === "browserCommand") {
-          try {
-            const parsed = JSON.parse(result2);
-            const screenshotSteps = (parsed.steps || []).filter(
-              (s) => s.command === "screenshotViewport" && s.result?.url
-            );
-            if (screenshotSteps.length > 0) {
-              const batchInput = screenshotSteps.map((s) => ({
-                stepType: "analyzeImage",
-                step: {
-                  imageUrl: s.result.url,
-                  prompt: SCREENSHOT_ANALYSIS_PROMPT
-                }
-              }));
-              const batchResult = await runCli(
-                `mindstudio batch --no-meta ${JSON.stringify(JSON.stringify(batchInput))}`,
-                { timeout: 2e5 }
+          const result2 = await context.resolveExternalTool(id, name, input2);
+          if (name === "browserCommand") {
+            try {
+              const parsed = JSON.parse(result2);
+              const screenshotSteps = (parsed.steps || []).filter(
+                (s) => s.command === "screenshotViewport" && s.result?.url
               );
-              try {
-                const analyses = JSON.parse(batchResult);
-                let ai = 0;
-                for (const step of parsed.steps) {
-                  if (step.command === "screenshotViewport" && step.result?.url && ai < analyses.length) {
-                    step.result.analysis = analyses[ai]?.output?.analysis || analyses[ai]?.output || "";
-                    ai++;
+              if (screenshotSteps.length > 0) {
+                const batchInput = screenshotSteps.map((s) => ({
+                  stepType: "analyzeImage",
+                  step: {
+                    imageUrl: s.result.url,
+                    prompt: SCREENSHOT_ANALYSIS_PROMPT
+                  }
+                }));
+                const batchResult = await runCli(
+                  `mindstudio batch --no-meta ${JSON.stringify(JSON.stringify(batchInput))}`,
+                  { timeout: 2e5 }
+                );
+                try {
+                  const analyses = JSON.parse(batchResult);
+                  let ai = 0;
+                  for (const step of parsed.steps) {
+                    if (step.command === "screenshotViewport" && step.result?.url && ai < analyses.length) {
+                      step.result.analysis = analyses[ai]?.output?.analysis || analyses[ai]?.output || "";
+                      ai++;
+                    }
                   }
+                } catch {
+                  log6.debug("Failed to parse batch analysis result", {
+                    batchResult
+                  });
                 }
-              } catch {
-                log6.debug("Failed to parse batch analysis result", {
-                  batchResult
-                });
+                return JSON.stringify(parsed);
               }
-              return JSON.stringify(parsed);
+            } catch {
             }
-          } catch {
           }
-        }
-        return result2;
-      },
-      toolRegistry: context.toolRegistry
-    });
-    context.subAgentMessages?.set(context.toolCallId, result.messages);
-    return result.text;
+          return result2;
+        },
+        toolRegistry: context.toolRegistry
+      });
+      try {
+        await sidecarRequest("/reset-browser", {}, { timeout: 5e3 });
+      } catch {
+      }
+      context.subAgentMessages?.set(context.toolCallId, result.messages);
+      return result.text;
+    } finally {
+      release();
+    }
   }
 };
 
@@ -4960,6 +4966,7 @@ var EXTERNAL_TOOLS = /* @__PURE__ */ new Set([
   "confirmDestructiveAction",
   "runScenario",
   "runMethod",
+  "queryDatabase",
   "browserCommand",
   "setProjectMetadata"
 ]);

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"]);
@@ -2940,7 +2931,16 @@ var init_prompt = __esm({
 });
 
 // src/subagents/browserAutomation/index.ts
-var log4, browserAutomationTool;
+function acquireBrowserLock() {
+  let release;
+  const next = new Promise((res) => {
+    release = res;
+  });
+  const wait = lockQueue;
+  lockQueue = next;
+  return wait.then(() => release);
+}
+var log4, lockQueue, browserAutomationTool;
 var init_browserAutomation = __esm({
   "src/subagents/browserAutomation/index.ts"() {
     "use strict";
@@ -2952,11 +2952,12 @@ var init_browserAutomation = __esm({
     init_runCli();
     init_logger();
     log4 = createLogger("browser-automation");
+    lockQueue = Promise.resolve();
     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: {
@@ -2972,99 +2973,104 @@ var init_browserAutomation = __esm({
         if (!context) {
           return "Error: browser automation requires execution context (only available in headless mode)";
         }
+        const release = await acquireBrowserLock();
         try {
-          const status = await sidecarRequest(
-            "/browser-status",
-            {},
-            { timeout: 5e3 }
-          );
-          if (!status.connected) {
-            return "Error: the browser preview is not connected. The user needs to open the preview before browser tests can run.";
+          try {
+            const status = await sidecarRequest(
+              "/browser-status",
+              {},
+              { timeout: 5e3 }
+            );
+            if (!status.connected) {
+              return "Error: the browser preview is not connected. The user needs to open the preview before browser tests can run.";
+            }
+          } catch {
+            return "Error: could not check browser status. The dev environment may not be running.";
           }
-        } catch {
-          return "Error: could not check browser status. The dev environment may not be running.";
-        }
-        const result = await runSubAgent({
-          system: getBrowserAutomationPrompt(),
-          task: input.task,
-          tools: BROWSER_TOOLS,
-          externalTools: BROWSER_EXTERNAL_TOOLS,
-          executeTool: async (name, _input, _toolCallId, onLog) => {
-            if (name === "screenshotFullPage") {
-              try {
-                return await captureAndAnalyzeScreenshot({
-                  path: _input.path,
-                  onLog
-                });
-              } catch (err) {
-                return `Error taking screenshot: ${err.message}`;
+          try {
+            await sidecarRequest("/reset-browser", {}, { timeout: 5e3 });
+          } catch {
+          }
+          const result = await runSubAgent({
+            system: getBrowserAutomationPrompt(),
+            task: input.task,
+            tools: BROWSER_TOOLS,
+            externalTools: BROWSER_EXTERNAL_TOOLS,
+            executeTool: async (name, _input, _toolCallId, onLog) => {
+              if (name === "screenshotFullPage") {
+                try {
+                  return await captureAndAnalyzeScreenshot({
+                    path: _input.path,
+                    onLog
+                  });
+                } catch (err) {
+                  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,
+            model: context.model,
+            subAgentId: "browserAutomation",
+            signal: context.signal,
+            parentToolId: context.toolCallId,
+            requestId: context.requestId,
+            onEvent: context.onEvent,
+            resolveExternalTool: async (id, name, input2) => {
+              if (!context.resolveExternalTool) {
+                return "Error: no external tool resolver";
               }
-            }
-            return `Error: unknown local tool "${name}"`;
-          },
-          apiConfig: context.apiConfig,
-          model: context.model,
-          subAgentId: "browserAutomation",
-          signal: context.signal,
-          parentToolId: context.toolCallId,
-          requestId: context.requestId,
-          onEvent: context.onEvent,
-          resolveExternalTool: async (id, name, input2) => {
-            if (!context.resolveExternalTool) {
-              return "Error: no external tool resolver";
-            }
-            const result2 = await context.resolveExternalTool(id, name, input2);
-            if (name === "browserCommand") {
-              try {
-                const parsed = JSON.parse(result2);
-                const screenshotSteps = (parsed.steps || []).filter(
-                  (s) => s.command === "screenshotViewport" && s.result?.url
-                );
-                if (screenshotSteps.length > 0) {
-                  const batchInput = screenshotSteps.map((s) => ({
-                    stepType: "analyzeImage",
-                    step: {
-                      imageUrl: s.result.url,
-                      prompt: SCREENSHOT_ANALYSIS_PROMPT
-                    }
-                  }));
-                  const batchResult = await runCli(
-                    `mindstudio batch --no-meta ${JSON.stringify(JSON.stringify(batchInput))}`,
-                    { timeout: 2e5 }
+              const result2 = await context.resolveExternalTool(id, name, input2);
+              if (name === "browserCommand") {
+                try {
+                  const parsed = JSON.parse(result2);
+                  const screenshotSteps = (parsed.steps || []).filter(
+                    (s) => s.command === "screenshotViewport" && s.result?.url
                   );
-                  try {
-                    const analyses = JSON.parse(batchResult);
-                    let ai = 0;
-                    for (const step of parsed.steps) {
-                      if (step.command === "screenshotViewport" && step.result?.url && ai < analyses.length) {
-                        step.result.analysis = analyses[ai]?.output?.analysis || analyses[ai]?.output || "";
-                        ai++;
+                  if (screenshotSteps.length > 0) {
+                    const batchInput = screenshotSteps.map((s) => ({
+                      stepType: "analyzeImage",
+                      step: {
+                        imageUrl: s.result.url,
+                        prompt: SCREENSHOT_ANALYSIS_PROMPT
+                      }
+                    }));
+                    const batchResult = await runCli(
+                      `mindstudio batch --no-meta ${JSON.stringify(JSON.stringify(batchInput))}`,
+                      { timeout: 2e5 }
+                    );
+                    try {
+                      const analyses = JSON.parse(batchResult);
+                      let ai = 0;
+                      for (const step of parsed.steps) {
+                        if (step.command === "screenshotViewport" && step.result?.url && ai < analyses.length) {
+                          step.result.analysis = analyses[ai]?.output?.analysis || analyses[ai]?.output || "";
+                          ai++;
+                        }
                       }
+                    } catch {
+                      log4.debug("Failed to parse batch analysis result", {
+                        batchResult
+                      });
                     }
-                  } catch {
-                    log4.debug("Failed to parse batch analysis result", {
-                      batchResult
-                    });
+                    return JSON.stringify(parsed);
                   }
-                  return JSON.stringify(parsed);
+                } catch {
                 }
-              } catch {
               }
-            }
-            return result2;
-          },
-          toolRegistry: context.toolRegistry
-        });
-        context.subAgentMessages?.set(context.toolCallId, result.messages);
-        return result.text;
+              return result2;
+            },
+            toolRegistry: context.toolRegistry
+          });
+          try {
+            await sidecarRequest("/reset-browser", {}, { timeout: 5e3 });
+          } catch {
+          }
+          context.subAgentMessages?.set(context.toolCallId, result.messages);
+          return result.text;
+        } finally {
+          release();
+        }
       }
     };
   }
@@ -5503,6 +5509,7 @@ var init_agent = __esm({
       "confirmDestructiveAction",
       "runScenario",
       "runMethod",
+      "queryDatabase",
       "browserCommand",
       "setProjectMetadata"
     ]);

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/compiled/dev-and-deploy.md

@@ -19,7 +19,7 @@ The dev session gets its own database — a snapshot of the live database at ses
 - **Truncate** — keep the schema, delete all row data (used by scenarios for a clean canvas)
 - **Schema sync** — add a field to a table interface and it's immediately available in dev
 
-The dev database is disposable. Experiment freely — there's no risk of breaking anything.
+The dev database is disposable. Experiment freely — there's no risk of breaking anything. Just be considerate that the user may have created their own data (user rows or other data) while testing, and it might be frustrating for them to have it wiped.
 
 ### Debugging
 

package/dist/prompt/compiled/scenarios.md

@@ -96,12 +96,14 @@ Shared setup code can go in `dist/methods/.scenarios/_helpers/`.
 ## How Scenarios Run
 
 When a scenario runs, the platform:
-1. **Truncates** all tables (deletes all rows, preserves schema)
+1. **Truncates** all tables (deletes all rows, preserves schema - unless skipTruncate is true)
 2. **Executes** the seed function (your `db.push()` calls populate the clean database)
 3. **Impersonates** the roles from the scenario's `roles` field (the app renders from that user's perspective)
 
 This is deterministic — same scenario always produces the same state.
 
+Scenarios are useful for seeding initial app state after build for testing, as well as to give the user a first impression of an app that is already filled with data and looks and feels usable. The user can choose to run further scenarios after initial build by clicking the Scenarios tab and selecting a scenario to run.
+
 ## Scenario Data
 
 Align scenario data to the vibe of the app - construct data that feels like it fits.

package/dist/prompt/static/coding.md

@@ -9,7 +9,7 @@
 ### Verification
 Run `lspDiagnostics` after every turn where you have edited code in any meaningful way. You don't need to run it for things like changing copy or CSS colors, but you should run it after any structural changes to code. It catches syntax errors, broken imports, and type mismatches instantly. After a big build or significant changes, also do a lightweight runtime check to catch the things static analysis misses (schema mismatches, missing imports, bad queries):
 
-- Seed test data with `runScenario`, then spot-check the primary method or two with `runMethod`. The dev database is a disposable snapshot, so don't worry about being destructive.
+- 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.
 
@@ -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
@@ -38,8 +38,5 @@ For any work involving AI models, external actions (web scraping, email, SMS), o
 ### State Management
 - Calls to methods introduce latency. When building web frontends that load data from methods, consider front-loading as much data as you can in a single API request - e.g., when possible, load a large data object into a central store and use that to render sub-screens in an app, rather than an API call on every screen.
 
-### Build Notes
-For complex builds that span many files — especially an initial buildout from a spec — write a `.remy-notes.md` scratchpad in the project root. Use it to record decisions, keep a checklist of tasks, and reference data you'll need across multiple tool calls: design tokens, color values, typography specs, image URLs, what's been built so far, what's left. Read it back instead of restating everything in your messages. Delete it when the build is done. Don't use this for small changes or single-file edits.
-
 ### Dependencies
 Before installing a package you haven't used in this project, do a quick web search to confirm it's still the best option. The JavaScript ecosystem moves fast — the package you remember from training may have been superseded by something smaller, faster, or better maintained. A 10-second search beats debugging a deprecated library.

package/dist/prompt/static/instructions.md

@@ -15,6 +15,9 @@
 - After two failed attempts at the same approach, tell the user what's going wrong.
 - Pushing to main branch will trigger a deploy. The user presses the publish button in the interface to request publishing.
 
+### Build Notes
+For complex tasks — especially an initial buildout from a spec or making multiple changes in a single turn — write a `.remy-notes.md` scratchpad in the project root. Use it to record decisions, keep a checklist of tasks, and reference data you'll need across multiple tool calls: design tokens, color values, typography specs, image URLs, what's been built so far, what's left. Read it back instead of restating everything in your messages. Delete it when your work is done.
+
 ## Communication
 The user can already see your tool calls, so most of your work is visible without narration. Focus text output on three things:
 - **Decisions that need input.** Questions, tradeoffs, ambiguity that blocks progress.

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/codeSanityCheck/prompt.md

@@ -35,6 +35,10 @@ These are recurring mistakes the coding agent makes. If you see the conditions f
 
 - **CSS Module animation scoping.** If the agent defines `@keyframes` in a global CSS file but references the animation name from a CSS Module, the animation will silently fail. CSS Modules scope animation names, so a keyframe defined globally can't be found by a scoped class. The fix: define keyframes in the same CSS Module that uses them, or use `:global()` to escape the scoping.
 
+- **Too many granular API calls.** These apps are MVPs with small datasets. If the plan has separate method calls for every screen or sub-view (load profile, then load posts, then load post detail, then load comments), flag it. Favor fewer, fatter requests — a profile page that loads posts with full content means tapping a post is instant. A feed that includes comment previews and like state means the detail view renders from memory. Over-fetching at this scale is almost always the right call — users notice instant transitions, they don't notice a slightly larger payload.
+
+- **Wouter is not React Router.** The agent defaults to React Router patterns which silently break in wouter. Key differences: no `useNavigate()` (use `const [, setLocation] = useLocation()`), no `navigate(-1)` for back (use `window.history.back()`), no `element` prop on Route (use `component={Foo}` or children), no `<Routes>` (use `<Switch>` — without it all matching routes render simultaneously), no `<Navigate>` (use `<Redirect>`), no `<Outlet>` for nested routes (use `nest` prop on Route), and no `useSearchParams()` from react-router (wouter has its own version with a different setter API). If you see any of these React Router patterns in a wouter project, flag it.
+
 ## When to stay quiet
 
 Nits, style preferences, missing edge cases, things the agent will figure out as it goes, patterns that are "not ideal but fine," minor code smells. Let them slide. The agent is busy.

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,89 @@ 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 — a core component, 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.
+
+Use wireframes instead of ASCII art and code-block diagrams you might otherwise reach for when trying to show a layout or interaction. Wireframes are better because 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.
+
+Remember, never use ascii art or code-block diagrams to describe layouts - always use wireframes.
+
+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 (make sure to allow reply/reset for all interactivity). 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.85",
   "description": "MindStudio coding agent",
   "repository": {
     "type": "git",