@mindstudio-ai/remy 0.1.124 → 0.1.125

package/dist/automatedActions/buildFromInitialSpec.md

@@ -11,17 +11,21 @@ Think about your approach and then get a quick sanity check from `codeSanityChec
 
 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.
 
+Use your remy-notes.md file to make a checklist of the work that needs to be done. Don't store implementation details in it - it is soley for keeping track of tasks.
+
 ## Building
-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 - don't forget to update the page metadata on index.html too.
+Then, build everything in one turn: tables, methods, interfaces, manifest updates, scenarios, and anything else, 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, and don't forget to update the page metadata on index.html too.
 
 ## Verifying
-- First, run use `runScenario` to seed test data, then use `runMethod` to confirm important methods work 
+- First, run use `runScenario` to seed test data, then use `runMethod` to confirm important methods work.
 - If the app has a web frontend, check the browser logs to make sure there are no errors rendering it.
 - Use `runAutomatedBrowserTest` to smoke-test the main UI flow. The dev database is a disposable snapshot, so don't worry about being destructive. Fix any errors before finishing.
 - If there is a scenario that seeds the app with mock data, use it to present the app to the user with initial data seeded, so they can see and play with the real app. Let the user know they can reset the app using a scenario to empty it if they wish. Showing the user something they can play with immediately is important when it comes to landing a strong first impression.
 
 ## Polishing
-When code generation is complete, take a step back and do an explicit polish pass before verifying. Re-read the spec files and the design expert's guidance, then walk through each frontend file looking for design details that got skipped in the initial build: animations, transitions, hover states, micro-interactions, spring physics, entrance reveals, gesture handling, layout issues, and anything else. The initial build prioritizes getting everything connected and functional, but this pass closes the gap between "it works" and "it feels great." In many ways this is the most important part of the initial build, as the user's first experience of the deliverable will set their expectations for every iteration that follows. Don't mess this up.
+When verification is complete, take a step back and do an explicit polish pass before verifying. Re-read the spec files and the design expert's guidance, then walk through each frontend file looking for design details that got skipped in the initial build: animations, transitions, hover states, micro-interactions, spring physics, entrance reveals, gesture handling, layout issues, and anything else. 
+
+The initial build prioritizes getting everything connected and functional, but this pass closes the gap between "it works" and "it feels great." In many ways this is *the* most important part of the initial build, as the user's first experience of the deliverable will set their expectations for every iteration that follows. Don't mess this up.
 
 Then, ask the `visualDesignExpert` to take a screenshot and verity that the visual design looks correct. Fix any issues it flags - we want the user's first time seeing the finished product to truly wow them.
 

package/dist/automatedActions/buildFromRoadmap.md

@@ -6,7 +6,7 @@ This is an automated action triggered by the user pressing "Build Now" on the ro
 
 First, review the specific item and think about how it fits with the existing spec and the existing codebase.
 
-Then, ask the user clarifying questions about anything that is ambiguous or requires additional input. Consult the team for any design work, architecture review, or SDK guidance - even if they're just quick questions (that's what the team is there for - they want to help and feel valuable!).
+Then, ask the user any clarifying questions about anything that is ambiguous or requires additional input. Consult the team for any design work, architecture review, or SDK guidance - even if they're just quick questions (that's what the team is there for - they want to help and feel valuable!). Additive feature work is the most fun to build, but make sure you take a step back first and consider any technical debt or organization implications - we need to keep the codebase clean, tidy, bug-free, and easy/intuitive to manage. When adding new features, this might mean extracting shared helpers to separate files, breaking apart components into multiple files, making new folders, etc. - Don't go overboard, but also don't keep adding to one giant file until it ends up unmanageable. Consider organization and structure when building the plan.
 
 Then, put together a plan to build out the feature. Present the plan to the user for their approval.
 

package/dist/automatedActions/codeCleanup.md

@@ -0,0 +1,11 @@
+---
+  trigger: codeCleanup
+---
+
+This is an automated action triggered by the user pressing "Code Cleanup" in the editor. The user can not see this message, so keep that in mind when replying.
+
+First, explore the project and get a sense of what has built. 
+
+Read specific files and trace paths, don't just guess at how something works based on partial information. When you are finished exploring, identiy any high-impact areas for cleaning up the code. This can include things like directory organization, splitting things into separate files to make the project easier to scan, breaking up large components or screens, deduplicating copy-pasted code, removing dead code, and anything else that will leave the project more robust, reliable, and easier to scan/work on for developers. Do not optimize for the sake of optimizing, only focus on reducing real technical debt and leaving the product better and a more pleasant experience for other developers working on it.
+
+When you have a plan, run it by the `codeSanityCheck` to get a second set of eyes. Then, present the plan to the user. The technical detail is important so the user has a sense of what the plan entails, but remember that the user is not very technical, so it is equally important to help them understand the why behind any refactors.

package/dist/automatedActions/continue.md

@@ -2,4 +2,4 @@
   trigger: continue
 ---
 
-This is an automated message triggered by the user pressing "Try Again" after an error in the conversation. The error was likely a temporary network hiccup or something transient - do not acknowledge this message, simply continue the work from where you left off in the last conversation turn.
+This is an automated message triggered by the user pressing "Try Again" after an error in the agent's turn. The error was likely a temporary network hiccup or something transient. Briefly acknowledge that you are continuing the work, and then immediately pick up from where you left off in the last conversation turn.

package/dist/automatedActions/familiarize.md

@@ -0,0 +1,13 @@
+---
+  trigger: familiarize
+---
+
+This is an automated action triggered by the user pressing "Familiarize" in the editor. The user can not see this message, so keep that in mind when replying.
+
+Explore the project and get a sense of what has built. Start with the manifest, then the spec in src/, then any code that has been generated in dist/.
+
+Get a sense of the complete project - the intent behind the product, the work that has been done, work that is left to do, places for improvement, anything that feels incomplete, etc.
+
+Read specific files and trace paths, don't just guess at how something works based on partial information. After this turn, you need to be able to dive right in and get to work, so make sure you are ready to do that and are in a strong, confident, evidence-based position to engage with the user.
+
+When you are finished, provide a summary to the user of everything you found.

package/dist/automatedActions/publish.md

@@ -12,6 +12,6 @@ If approved:
 - Stage and commit any uncommitted changes with a clean, descriptive commit message
 - Push to main
 - Use `mindstudio-prod releases status --wait` to poll the build until it completes. Let the user know it's deploying, then report back when it's live.
-- Once deployed, offer to help with next steps: setting up a custom domain (`mindstudio-prod domains`), checking for errors (`mindstudio-prod requests stats`), seeding production data (`mindstudio-prod db`), or anything else they need for launch.
+- Once deployed, offer to help with next steps: setting up a custom domain (`mindstudio-prod domains`), checking for errors (`mindstudio-prod requests stats`), seeding production data (`mindstudio-prod db`), managing env vars/secrets, or anything else they need for launch.
 
 If dismissed, acknowledge and do nothing.

package/dist/automatedActions/reviseFromAnnotatedImage.md

@@ -2,4 +2,4 @@
   trigger: reviseFromAnnotatedImage
 ---
 
-This is an automated message trigger by the user submitting a screenshot of the app that they have annotated with text notes. Please analyze the provided image and make the requested revisions to the web frontend.
+This is an automated message triggered by the user submitting a screenshot of the app that they have annotated with text notes. Please analyze the provided image and make the requested revisions to the web interface.

package/dist/headless.js

@@ -2480,6 +2480,15 @@ var runMethodTool = {
         input: {
           type: "object",
           description: "The input payload to pass to the method. Omit for methods that take no input."
+        },
+        roles: {
+          type: "array",
+          items: { type: "string" },
+          description: 'Optional. Role names for this request (e.g. ["admin"]). Can be used without userId to test role-gated logic. Overrides session-level impersonation for this call only.'
+        },
+        userId: {
+          type: "string",
+          description: "Optional. User ID for this request \u2014 use a managed user's ID to simulate their identity. Overrides session-level impersonation for this call only."
         }
       },
       required: ["method"]
@@ -2593,50 +2602,6 @@ async function captureAndAnalyzeScreenshot(promptOrOptions) {
   return JSON.stringify({ url, analysis, ...styleMap ? { styleMap } : {} });
 }
 
-// src/tools/code/screenshot.ts
-var screenshotTool = {
-  clearable: true,
-  definition: {
-    name: "screenshot",
-    description: "Capture a full-height screenshot of the app preview and get a description of what's on screen. Provides static image analysis only, will not capture animations or video. Optionally provide specific questions about what you're looking for. Use a bulleted list to ask many questions at once. To ask additional questions about a screenshot you have already captured, pass its URL as imageUrl to skip recapture.",
-    inputSchema: {
-      type: "object",
-      properties: {
-        prompt: {
-          type: "string",
-          description: "Optional question about the screenshot. If omitted, returns a general description of what's visible."
-        },
-        imageUrl: {
-          type: "string",
-          description: "URL of an existing screenshot to analyze instead of capturing a new one. Use this for additional questions about a previous screenshot."
-        },
-        path: {
-          type: "string",
-          description: 'Navigate to this path before capturing (e.g. "/settings", "/dashboard"). If omitted, screenshots the current page.'
-        }
-      }
-    }
-  },
-  async execute(input, context) {
-    try {
-      if (input.imageUrl) {
-        return await captureAndAnalyzeScreenshot({
-          prompt: input.prompt,
-          imageUrl: input.imageUrl,
-          onLog: context?.onLog
-        });
-      }
-      return await captureAndAnalyzeScreenshot({
-        prompt: input.prompt,
-        path: input.path,
-        onLog: context?.onLog
-      });
-    } catch (err) {
-      return `Error taking screenshot: ${err.message}`;
-    }
-  }
-};
-
 // src/statusWatcher.ts
 function startStatusWatcher(config) {
   const { apiConfig, getContext, onStatus, interval = 3e3, signal } = config;
@@ -3467,6 +3432,85 @@ var browserAutomationTool = {
   }
 };
 
+// src/tools/code/screenshot.ts
+var screenshotTool = {
+  clearable: true,
+  definition: {
+    name: "screenshot",
+    description: "Capture a full-height screenshot of the app preview and get a description of what's on screen. Provides static image analysis only, will not capture animations or video. Optionally provide specific questions about what you're looking for. Use a bulleted list to ask many questions at once. To ask additional questions about a screenshot you have already captured, pass its URL as imageUrl to skip recapture. If the screenshot requires interaction first (logging in, clicking a tab, dismissing a modal), use the instructions param to describe the steps.",
+    inputSchema: {
+      type: "object",
+      properties: {
+        prompt: {
+          type: "string",
+          description: "Optional question about the screenshot. If omitted, returns a general description of what's visible."
+        },
+        imageUrl: {
+          type: "string",
+          description: "URL of an existing screenshot to analyze instead of capturing a new one. Use this for additional questions about a previous screenshot."
+        },
+        path: {
+          type: "string",
+          description: 'Navigate to this path before capturing (e.g. "/settings", "/dashboard"). If omitted, screenshots the current page.'
+        },
+        instructions: {
+          type: "string",
+          description: "If the screenshot you need requires interaction first (dismissing a modal, clicking a tab, filling out a form, navigating a flow, getting through a login/auth checkpoint), describe the steps to get there. A browser automation agent will follow these instructions before capturing the screenshot - it can bypass auth and get right to where it needs to be if you tell it to authenticate as a test user and give it the path/screen to start its test at. You will always get back a full-height screenshot of the entire page. Do not attempt to scroll or capture specific areas. Only use instructions when you need to trigger stateful changes. Never describe what names or values to use when applying the isntructions - the browser automation agent must use its own values for it to work properly. If a specific auth role is required to access the content, be sure to note that - it can automatically assume it for the purpose of testing."
+        }
+      }
+    }
+  },
+  async execute(input, context) {
+    try {
+      if (input.imageUrl) {
+        return await captureAndAnalyzeScreenshot({
+          prompt: input.prompt,
+          imageUrl: input.imageUrl,
+          onLog: context?.onLog
+        });
+      }
+      if (input.instructions && context) {
+        const task = input.path ? `Navigate to "${input.path}", then: ${input.instructions}. After completing these steps, take a full-page screenshot.` : `${input.instructions}. After completing these steps, take a full-page screenshot.`;
+        const result = await browserAutomationTool.execute({ task }, context);
+        const urlMatch = result.match(
+          /https:\/\/[^\s"')]+\.(?:png|jpg|jpeg|webp)/i
+        );
+        if (!urlMatch) {
+          return `Error: browser navigation completed but no screenshot URL was returned. Agent output: ${result}`;
+        }
+        const url = urlMatch[0];
+        let styleMap;
+        try {
+          const parsed = JSON.parse(result);
+          styleMap = parsed?.styleMap;
+        } catch {
+        }
+        const analysisPrompt = buildScreenshotAnalysisPrompt({
+          prompt: input.prompt,
+          styleMap
+        });
+        const analysis = await analyzeImage({
+          prompt: analysisPrompt,
+          imageUrl: url,
+          onLog: context?.onLog
+        });
+        return JSON.stringify({
+          url,
+          analysis,
+          ...styleMap ? { styleMap } : {}
+        });
+      }
+      return await captureAndAnalyzeScreenshot({
+        prompt: input.prompt,
+        path: input.path,
+        onLog: context?.onLog
+      });
+    } catch (err) {
+      return `Error taking screenshot: ${err.message}`;
+    }
+  }
+};
+
 // src/subagents/designExpert/tools/searchGoogle.ts
 var searchGoogle_exports = {};
 __export(searchGoogle_exports, {
@@ -3651,7 +3695,7 @@ var definition5 = {
     properties: {
       prompt: {
         type: "string",
-        description: "Optional specific question about the screenshot."
+        description: "Optional specific question about the screenshot. Use a bulleted list to ask many questions at once."
       },
       path: {
         type: "string",
@@ -3659,7 +3703,7 @@ var definition5 = {
       },
       instructions: {
         type: "string",
-        description: "If the screenshot you need requires interaction first (dismissing a modal, clicking a tab, filling out a form, navigating a flow, getting through a login/auth checkpoint), describe the steps to get there. A browser automation agent will follow these instructions before capturing the screenshot - it can bypass auth and get right to where it needs to be if you tell it to authenticate as a test user and give it the path/screen to start its test at. You will always get back a full-height screenshot of the entire page. Do not attempt to scroll or capture specific areas. Only use instructions when you need to trigger stateful changes. Never describe what names or values to use when applying the isntructions - the browser automation agent must use its own values for it to work properly."
+        description: "If the screenshot you need requires interaction first (dismissing a modal, clicking a tab, filling out a form, navigating a flow, getting through a login/auth checkpoint), describe the steps to get there. A browser automation agent will follow these instructions before capturing the screenshot - it can bypass auth and get right to where it needs to be if you tell it to authenticate as a test user and give it the path/screen to start its test at. You will always get back a full-height screenshot of the entire page. Do not attempt to scroll or capture specific areas. Only use instructions when you need to trigger stateful changes. Never describe what names or values to use when applying the isntructions - the browser automation agent must use its own values for it to work properly. If a specific auth role is required to access the content, be sure to note that - it can automatically assume it for the purpose of testing."
       }
     }
   }

package/dist/index.js

@@ -2161,6 +2161,15 @@ var init_runMethod = __esm({
             input: {
               type: "object",
               description: "The input payload to pass to the method. Omit for methods that take no input."
+            },
+            roles: {
+              type: "array",
+              items: { type: "string" },
+              description: 'Optional. Role names for this request (e.g. ["admin"]). Can be used without userId to test role-gated logic. Overrides session-level impersonation for this call only.'
+            },
+            userId: {
+              type: "string",
+              description: "Optional. User ID for this request \u2014 use a managed user's ID to simulate their identity. Overrides session-level impersonation for this call only."
             }
           },
           required: ["method"]
@@ -2297,57 +2306,6 @@ Respond only with your analysis as Markdown and absolutely no other text. Do not
   }
 });
 
-// src/tools/code/screenshot.ts
-var screenshotTool;
-var init_screenshot2 = __esm({
-  "src/tools/code/screenshot.ts"() {
-    "use strict";
-    init_screenshot();
-    screenshotTool = {
-      clearable: true,
-      definition: {
-        name: "screenshot",
-        description: "Capture a full-height screenshot of the app preview and get a description of what's on screen. Provides static image analysis only, will not capture animations or video. Optionally provide specific questions about what you're looking for. Use a bulleted list to ask many questions at once. To ask additional questions about a screenshot you have already captured, pass its URL as imageUrl to skip recapture.",
-        inputSchema: {
-          type: "object",
-          properties: {
-            prompt: {
-              type: "string",
-              description: "Optional question about the screenshot. If omitted, returns a general description of what's visible."
-            },
-            imageUrl: {
-              type: "string",
-              description: "URL of an existing screenshot to analyze instead of capturing a new one. Use this for additional questions about a previous screenshot."
-            },
-            path: {
-              type: "string",
-              description: 'Navigate to this path before capturing (e.g. "/settings", "/dashboard"). If omitted, screenshots the current page.'
-            }
-          }
-        }
-      },
-      async execute(input, context) {
-        try {
-          if (input.imageUrl) {
-            return await captureAndAnalyzeScreenshot({
-              prompt: input.prompt,
-              imageUrl: input.imageUrl,
-              onLog: context?.onLog
-            });
-          }
-          return await captureAndAnalyzeScreenshot({
-            prompt: input.prompt,
-            path: input.path,
-            onLog: context?.onLog
-          });
-        } catch (err) {
-          return `Error taking screenshot: ${err.message}`;
-        }
-      }
-    };
-  }
-});
-
 // src/statusWatcher.ts
 function startStatusWatcher(config) {
   const { apiConfig, getContext, onStatus, interval = 3e3, signal } = config;
@@ -3267,6 +3225,94 @@ var init_browserAutomation = __esm({
   }
 });
 
+// src/tools/code/screenshot.ts
+var screenshotTool;
+var init_screenshot2 = __esm({
+  "src/tools/code/screenshot.ts"() {
+    "use strict";
+    init_screenshot();
+    init_analyzeImage();
+    init_browserAutomation();
+    screenshotTool = {
+      clearable: true,
+      definition: {
+        name: "screenshot",
+        description: "Capture a full-height screenshot of the app preview and get a description of what's on screen. Provides static image analysis only, will not capture animations or video. Optionally provide specific questions about what you're looking for. Use a bulleted list to ask many questions at once. To ask additional questions about a screenshot you have already captured, pass its URL as imageUrl to skip recapture. If the screenshot requires interaction first (logging in, clicking a tab, dismissing a modal), use the instructions param to describe the steps.",
+        inputSchema: {
+          type: "object",
+          properties: {
+            prompt: {
+              type: "string",
+              description: "Optional question about the screenshot. If omitted, returns a general description of what's visible."
+            },
+            imageUrl: {
+              type: "string",
+              description: "URL of an existing screenshot to analyze instead of capturing a new one. Use this for additional questions about a previous screenshot."
+            },
+            path: {
+              type: "string",
+              description: 'Navigate to this path before capturing (e.g. "/settings", "/dashboard"). If omitted, screenshots the current page.'
+            },
+            instructions: {
+              type: "string",
+              description: "If the screenshot you need requires interaction first (dismissing a modal, clicking a tab, filling out a form, navigating a flow, getting through a login/auth checkpoint), describe the steps to get there. A browser automation agent will follow these instructions before capturing the screenshot - it can bypass auth and get right to where it needs to be if you tell it to authenticate as a test user and give it the path/screen to start its test at. You will always get back a full-height screenshot of the entire page. Do not attempt to scroll or capture specific areas. Only use instructions when you need to trigger stateful changes. Never describe what names or values to use when applying the isntructions - the browser automation agent must use its own values for it to work properly. If a specific auth role is required to access the content, be sure to note that - it can automatically assume it for the purpose of testing."
+            }
+          }
+        }
+      },
+      async execute(input, context) {
+        try {
+          if (input.imageUrl) {
+            return await captureAndAnalyzeScreenshot({
+              prompt: input.prompt,
+              imageUrl: input.imageUrl,
+              onLog: context?.onLog
+            });
+          }
+          if (input.instructions && context) {
+            const task = input.path ? `Navigate to "${input.path}", then: ${input.instructions}. After completing these steps, take a full-page screenshot.` : `${input.instructions}. After completing these steps, take a full-page screenshot.`;
+            const result = await browserAutomationTool.execute({ task }, context);
+            const urlMatch = result.match(
+              /https:\/\/[^\s"')]+\.(?:png|jpg|jpeg|webp)/i
+            );
+            if (!urlMatch) {
+              return `Error: browser navigation completed but no screenshot URL was returned. Agent output: ${result}`;
+            }
+            const url = urlMatch[0];
+            let styleMap;
+            try {
+              const parsed = JSON.parse(result);
+              styleMap = parsed?.styleMap;
+            } catch {
+            }
+            const analysisPrompt = buildScreenshotAnalysisPrompt({
+              prompt: input.prompt,
+              styleMap
+            });
+            const analysis = await analyzeImage({
+              prompt: analysisPrompt,
+              imageUrl: url,
+              onLog: context?.onLog
+            });
+            return JSON.stringify({
+              url,
+              analysis,
+              ...styleMap ? { styleMap } : {}
+            });
+          }
+          return await captureAndAnalyzeScreenshot({
+            prompt: input.prompt,
+            path: input.path,
+            onLog: context?.onLog
+          });
+        } catch (err) {
+          return `Error taking screenshot: ${err.message}`;
+        }
+      }
+    };
+  }
+});
+
 // src/subagents/designExpert/tools/searchGoogle.ts
 var searchGoogle_exports = {};
 __export(searchGoogle_exports, {
@@ -3534,7 +3580,7 @@ var init_screenshot3 = __esm({
         properties: {
           prompt: {
             type: "string",
-            description: "Optional specific question about the screenshot."
+            description: "Optional specific question about the screenshot. Use a bulleted list to ask many questions at once."
           },
           path: {
             type: "string",
@@ -3542,7 +3588,7 @@ var init_screenshot3 = __esm({
           },
           instructions: {
             type: "string",
-            description: "If the screenshot you need requires interaction first (dismissing a modal, clicking a tab, filling out a form, navigating a flow, getting through a login/auth checkpoint), describe the steps to get there. A browser automation agent will follow these instructions before capturing the screenshot - it can bypass auth and get right to where it needs to be if you tell it to authenticate as a test user and give it the path/screen to start its test at. You will always get back a full-height screenshot of the entire page. Do not attempt to scroll or capture specific areas. Only use instructions when you need to trigger stateful changes. Never describe what names or values to use when applying the isntructions - the browser automation agent must use its own values for it to work properly."
+            description: "If the screenshot you need requires interaction first (dismissing a modal, clicking a tab, filling out a form, navigating a flow, getting through a login/auth checkpoint), describe the steps to get there. A browser automation agent will follow these instructions before capturing the screenshot - it can bypass auth and get right to where it needs to be if you tell it to authenticate as a test user and give it the path/screen to start its test at. You will always get back a full-height screenshot of the entire page. Do not attempt to scroll or capture specific areas. Only use instructions when you need to trigger stateful changes. Never describe what names or values to use when applying the isntructions - the browser automation agent must use its own values for it to work properly. If a specific auth role is required to access the content, be sure to note that - it can automatically assume it for the purpose of testing."
           }
         }
       }

package/dist/prompt/static/coding.md

@@ -43,6 +43,7 @@ For multi-step tasks with branching logic (research, enrichment, content pipelin
 - Use `dvh`/`svh` for mobile viewport heights.
 - Use `clamp()`, `min()`, `max()` for fluid sizing instead of fixed pixel values with media query breakpoints.
 - Use container queries for components that need to adapt to their container rather than the viewport.
+- For canvas-based UIs (games, visualizations, interactive graphics): size the canvas to fill its container, account for `devicePixelRatio` for Retina sharpness, and scale all objects relative to the viewport — not in fixed pixel sizes - otherwise they are going to be tiny and unusable.
 
 ### State Management
 - Calls to methods introduce latency. When building web frontends that load data from methods, front-load 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. User experience and perceived speed/performance are far more valuable than normalization and good REST API design.

package/dist/prompt/static/team.md

@@ -40,7 +40,7 @@ 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. By default, it always starts its tests logged out/unauthenticated on "/" root, but if you want to test a deeper piece of the app it can bypass auth and automatically authenticate itself as any user/role - just tell it to authenticate as the test user and navigate to X to start the test. After every test session, the browser is reset to / and any authentication used or created by the tester is cleared and reset.
+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. By default, it always starts its tests logged out/unauthenticated on "/" root, but if you want to test a deeper piece of the app it can bypass auth and automatically authenticate itself as any user/role - just tell it to authenticate as the test user and navigate to X to start the test. If a specific auth role is required to access the content, be sure to note that - it can automatically assume it for the purpose of testing. 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.
 

package/dist/subagents/codeSanityCheck/prompt.md

@@ -33,6 +33,7 @@ These are things we already know about and have decided to accept:
   - @tabler/icons-react
   - streamdown
   - react-textarea-autosize
+  - phaser
 - Preferences:
   - use [wouter](https://github.com/molefrog/wouter) for React routing instead of reaching for react-router
   - uploading user files should always happen via `platform.uploadFile()` from `@mindstudio-ai/interface` — not custom S3 code, not FormData to a method endpoint
@@ -40,10 +41,6 @@ These are things we already know about and have decided to accept:
 
 ### Common pitfalls (always flag these)
 
-- **External redirects in iframe.** If the plan involves redirecting to a third-party domain (payment checkout, OAuth login, external auth), flag that `window.location.href = url` will break in the preview iframe. Use `window.open(url, '_top')` for same-tab navigation or `window.open(url, '_blank')` for a new tab. This applies to any external redirect — Stripe, OAuth providers, third-party login pages.
-
-- **Hardcoded credentials.** If the plan or code contains API keys, tokens, or connection strings inline, flag it — these should be `process.env` secrets managed via the dashboard. Also flag if the plan uses `process.env` for something the MindStudio SDK already handles (AI model keys, email/SMS sending, etc.).
-
 These are recurring mistakes the coding agent makes. If you see the conditions for any of these, flag it proactively:
 
 - **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.
@@ -72,6 +69,15 @@ When a plan includes multiple screens/API calls, always note this item for the d
 
 - **Layout shift with dynamic data or AI generated text** If the plan includes dynamically-sized data (e.g., a wizard form with questions of differing lengths) or AI generated text (where text stream length is unpredictable), make sure to flag concerns about layout stability. Everything must either be a fixed size or smoothly animate between sizes. Text can never be clipped by a container or cause layout to jump around or grow in snappy/janky ways. Make sure to remind the developer that this is important to pay attention to.
 
+- **Games** If the plan involves building a browser game, make sure to remind the developer of the following:
+  - Use the correct tool for the scope: plain Canvas API for simple games, Phaser for 2D games that need physics/sprites/scene management, Three.js for 3D. 
+  - The design expert can generate beautiful assets — characters, objects, backgrounds, UI elements — with transparent backgrounds at proper resolution.
+  - Most importantly, make sure all UI and assets are responsively sized, especially for modern mobile retina devices. This is critical - things with assets too small are literally unplayable on modern devices and the user will be disappointed.
+
+- **External redirects in iframe.** If the plan involves redirecting to a third-party domain (payment checkout, OAuth login, external auth), flag that `window.location.href = url` will break in the preview iframe. Use `window.open(url, '_top')` for same-tab navigation or `window.open(url, '_blank')` for a new tab. This applies to any external redirect — Stripe, OAuth providers, third-party login pages.
+
+- **Hardcoded credentials.** If the plan or code contains API keys, tokens, or connection strings inline, flag it — these should be `process.env` secrets managed via the dashboard. Also flag if the plan uses `process.env` for something the MindStudio SDK already handles (AI model keys, email/SMS sending, etc.).
+
 ## 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

@@ -85,6 +85,8 @@ Include image recommendations in your designs when the product calls for it. A l
 
 Transparent assets open up layout possibilities: a mascot or other object, images for empty states, onboarding flows. When the design calls for layered compositions, generate the elements separately with transparent backgrounds rather than trying to compose everything into a single flat image.
 
+For games and other interactive projects, generate real assets — characters, objects, enemies, backgrounds, UI elements — with `transparentBackground: true`.
+
 ### CDN image transforms
 
 Generated images and uploaded images are hosted on `i.mscdn.ai`. Use query string parameters to request appropriately sized images rather than CSS-scaling full-resolution originals:

package/package.json

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