@mindstudio-ai/remy 0.1.104 → 0.1.106

package/dist/automatedActions/buildFromInitialSpec.md

@@ -4,18 +4,21 @@
 
 This is an automated action triggered by the user pressing "Build" in the editor after reviewing the spec.
 
-The user has reviewed the spec and is ready to build. 
+The user has reviewed the spec and is ready to build. There are four phases to building: planning, coding, polishing, verifying.
 
+## Planning
 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.
 
+## 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.
 
-When code generation is complete, do a polish pass before verifying. Re-read the spec annotations 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.
+## 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.
 
-Then verify: 
-- First, run use `runScenario` to seed test data, then use `runMethod` to confirm a method works 
+## Verifying
+- 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.
 - 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.
 - Finally, 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.

package/dist/headless.js

@@ -3518,7 +3518,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), describe the steps to get there. A browser automation agent will follow these instructions before capturing the screenshot."
+        description: "If the screenshot you need requires interaction first (dismissing a modal, clicking a tab, filling out a form, navigating a flow), describe the steps to get there. A browser automation agent will follow these instructions before capturing the screenshot. 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."
       }
     }
   }

package/dist/index.js

@@ -3393,7 +3393,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), describe the steps to get there. A browser automation agent will follow these instructions before capturing the screenshot."
+            description: "If the screenshot you need requires interaction first (dismissing a modal, clicking a tab, filling out a form, navigating a flow), describe the steps to get there. A browser automation agent will follow these instructions before capturing the screenshot. 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."
           }
         }
       }

package/dist/prompt/compiled/sdk-actions.md

@@ -127,12 +127,11 @@ const { content } = await agent.generateText({
   modelOverride: {
     model: 'claude-sonnet-4-6',
     temperature: 0.7,
-    maxResponseTokens: 1024,
   },
 });
 ```
 
-Make sure to prioritize new, popular models. MindStudio has a ton of models available - most of them are historical/legacy. Always choose latest generation models from leading providers - Anthropic Claude 4 family, Google Gemini 3, OpenAI GPT 5 to start - the user can adjust later.
+Make sure to prioritize new, popular models. MindStudio has a ton of models available - most of them are historical/legacy. Always choose latest generation models from leading providers - Anthropic Claude 4 family, Google Gemini 3, OpenAI GPT 5 to start - the user can adjust later. In general, do not set maxResponseTokens - let models stop on their own and use prompt guidance to control length. maxResponseTokens includes thinking tokens - so if you set it too low you will not get any results back.
 
 ### Batch Execution
 

package/dist/prompt/sources/llms.txt

@@ -136,7 +136,6 @@ const { content } = await agent.generateText({
   modelOverride: {
     model: model.id,
     temperature: 0.7,
-    maxResponseTokens: 1024,
   },
 });
 ```

package/dist/prompt/static/instructions.md

@@ -17,7 +17,7 @@
 - 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 track progress: a checklist of what's been built and what's left, and decisions you've made. Read the spec files directly when you need reference data. Delete the notes file when your work is done.
+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 track progress: a checklist of what's been built and what's remaining. Do not include implementation details in th notes. Read the spec files directly when you need reference data. Delete the notes file 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:

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

@@ -4,7 +4,7 @@ When done well, animation is one of the most powerful levers for elevating the d
 
 There are two categories of animation and you should think of them separately:
 - Interaction animation: think button clicks, UI transitions, loading effects. Intentional, beautiful, unobtrusive interaction animation is a baseline requirement for any app. If done correctly, users might never even notice it - but they will certainly notice its absence or when it is overdone.
-- Design animations: think beautiful layout reveals, dramatic loading and success states for user onboarding, beautiful scroll-driven animations on a landing page. These are the place to show off - and if you're showing off you better get it right. Anything that looks dated or janky will be disappointing to the user. Done correctly, these animations are powerful and transformative - and when the design calls for it, you should take a risk and suggest something big, bold, and creative. Remember, the user can always modify or change things later. It's better to dream big and walk it back than to deliver something generic or bland.
+- Design animations: think beautiful layout reveals, dramatic loading and success states for user onboarding, beautiful scroll-driven animations on a landing page. These are the place to show off - and if you're showing off you better get it right. Anything that looks dated or janky will be disappointing to the user. Done correctly, these animations are powerful and transformative - and when the design calls for it, you should take a risk and suggest something big, bold, and creative. Remember, the user can always modify or change things later. Be bold with these. It's better to dream big and walk it back than to deliver something generic or bland.
 
 ### Patterns to Use
 - CSS scroll-driven animations (`animation-timeline: view()`) for scrollytelling. Scroll-driven animations that animate based on scrollport are very slick and look beautiful in landing pages.
@@ -31,7 +31,7 @@ For any surface the user can drag, swipe, or pull, describe the physics — not
 ### Libraries
 - Prefer raw CSS animations and transitions when possible. They're the most performant and simplest to maintain.
 - Motion (`motion/react`) is the default for React when CSS isn't enough — layout animations, gesture-driven interactions, spring physics, orchestrated sequences.
-- GSAP is fully free now (including ScrollTrigger, FLIP plugin, MorphSVG) and is the best choice for complex scroll-driven timelines, SVG animation, and framework-agnostic projects.
+- GSAP is fully free (including ScrollTrigger, FLIP plugin, MorphSVG) and is the best choice for complex scroll-driven timelines, SVG animation, and framework-agnostic projects.
 - View Transitions API is native in all major browsers — use it for route/page transitions.
 - Only animate GPU-friendly properties (transform, opacity) whenever possible. Animating layout properties (width, height, top, left) causes reflows and jank.
 

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

@@ -42,7 +42,7 @@ If the design calls for it, take risks and be bold. It might not always work out
 
 ### Backgrounds
 
-Backgrounds create atmosphere. Solid white or solid gray is the safe default and the enemy of distinctiveness. Layer subtle gradients, use warm or cool tints, add geometric patterns or contextual textures. The background sets the mood before the user reads a single word.
+Backgrounds create atmosphere. Solid white or solid gray is the safe default and the enemy of distinctiveness. Layer subtle gradients, use warm or cool tints, add geometric patterns or contextual textures. The background sets the mood before the user reads a single word. If a background uses images, it must scale to fill and blend nicely. It can never cut off abruptly or be overly visible. Use blend modes, masks,  and other effects.
 
 ### Output
 

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

@@ -42,7 +42,7 @@ Use wireframes instead of ASCII art and code-block diagrams you might otherwise
 
 Remember, never use ascii art or code-block diagrams to describe layouts - always use wireframes. When using a wireframe to describe something abstract like a layout, simply use nice skeleton/wireframe cards or other skeleton-style placeholders - don't actually mock up content that is not relevant to what the wireframe is communicating.
 
-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.
+The wireframe code will be rendered in a transparent iframe. Don't fill the viewport or add a background color to the page body. Place the component at a natural size in a card with a background color that is centered vertically and horizontally in the viewport. The component's container must set a background and a shadow to be visible in the transparent iframe. 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.
 
 Wireframes are vanilla HTML/CSS/JS (no React). For animations beyond CSS, use GSAP via CDN:
 `<script src="https://cdn.jsdelivr.net/npm/gsap@3/dist/gsap.min.js"></script>`

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

@@ -53,7 +53,7 @@ For photorealistic images, go deep on four dimensions:
 
 For app icons and logos, the goal is something that reads clearly at phone home screen size and feels polished and beautiful - like it could appear as an "App of the Year" award winner.
 
-- 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.
+- 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. Always specify "Full bleed square composition with no padding or margin".
 - Describe smooth, rounded emoji-type 3D objects — think current macOS/iOS app icon design language. Apple emoji/nintendo style works really well for beautiful iconography. Not flat illustration, not photorealistic, not vectors.
 - Subjects should be immediately recognizable. Prefer one clear object or symbol, not a scene.
 - Specify "reads well at small sizes" as an explicit constraint.

package/package.json

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