@mindstudio-ai/remy 0.1.144 → 0.1.145

package/dist/headless.js

@@ -4159,7 +4159,7 @@ var definition6 = {
       },
       transparentBackground: {
         type: "boolean",
-        description: "Remove the background from generated images, producing transparent PNGs. Useful for icons, logos, product shots, and assets that need to be composited onto other backgrounds."
+        description: "Remove the background from generated images, producing transparent PNGs trimmed to the subject bounds. Useful for icons, logos, product shots, and assets that need to be composited onto other backgrounds."
       }
     },
     required: ["prompts"]

package/dist/index.js

@@ -4578,7 +4578,7 @@ var init_generateImages = __esm({
           },
           transparentBackground: {
             type: "boolean",
-            description: "Remove the background from generated images, producing transparent PNGs. Useful for icons, logos, product shots, and assets that need to be composited onto other backgrounds."
+            description: "Remove the background from generated images, producing transparent PNGs trimmed to the subject bounds. Useful for icons, logos, product shots, and assets that need to be composited onto other backgrounds."
           }
         },
         required: ["prompts"]

package/dist/prompt/compiled/design.md

@@ -98,16 +98,18 @@ Even if the app is intuitive and easy to use, users showing up for the first tim
 
 ## What to Actively Avoid At All Costs
 
-- **Avoid generic fonts.** Overused defaults that strip away all personality. Instead: pick a distinctive Google Font that fits the app's character.
+Always rely on the details provided by the design expert - their work is the source of truth for the design of the app. Be mindful of the following things to avoid as you work:
+
+- **Avoid generic fonts.** Avoid overused defaults that strip away all personality.
 - **Avoid purple or indigo anything.** Purple gradients, purple buttons, purple accents are overused. The user will be dismissive of our designs if they come out looking purple or indigo. Avoid terracotta for similar reasons.
-- **Avoid colored left-border callout boxes.** Rounded divs with a thick colored `border-left` — the generic "info card" pattern. Instead: use typography, spacing, and background tints to create hierarchy. If you need to call something out, use a full subtle background or a top border.
-- **Avoid three equal boxes with icons.** The default AI landing page layout. Instead: use asymmetric layouts, varied column widths, or a single focused content area.
-- **Avoid timid color palettes.** Evenly distributed, non-committal colors. Instead: one or two dominant colors with sharp accents. Commit to a direction.
-- **Avoid card-heavy nested layouts.** Cards inside cards, everything boxed. Instead: use space, typography, and dividers to create hierarchy without extra containers.
-- **Avoid inconsistent spacing.** 12px here, 20px there, 8px somewhere else. Instead: define a spacing scale (4/8/12/16/24/32/48/64) and use it everywhere.
-- **Avoid components from different visual languages.** Rounded buttons next to square inputs, shadows mixed with flat design. Instead: pick one system and apply it consistently.
+- **Avoid colored border callout boxes.** Avoid rounded divs with a thick colored `border-left|top` — the generic "info card" pattern. Instead: use typography, spacing, and background tints to create hierarchy. If you need to call something out, use a full subtle background or a top border.
+- **Avoid three equal boxes with icons.** The default AI landing page layout. Instead: use asymmetric layouts, varied column widths, or a single focused content area. Avoid cards labelled things like: 1, 2, 3 - this feels generic and cheap.
+- **Avoid timid color palettes.** Avoid evenly distributed, non-committal colors. Commit to a direction and be bold.
+- **Avoid card-heavy nested layouts.** Avoid cards inside cards, everything boxed. Instead: use space, typography, and dividers to create hierarchy without extra containers.
+- **Avoid inconsistent spacing.** Avoid 12px here, 20px there, 8px somewhere else. Instead: define a spacing scale (4/8/12/16/24/32/48/64) and use it everywhere.
+- **Avoid components from different visual languages.** Avoid, e.g., rounded buttons next to square inputs, shadows mixed with flat design. Instead: pick one system and apply it consistently.
 - **Avoid long scrolling forms with no visual grouping.** Instead: group fields into sections with clear headings, cards, or stepped flows.
-- **Avoid cramped layouts.** Text pressed against edges, no room to breathe. Instead: generous padding, comfortable margins, let the content float.
+- **Avoid cramped layouts.** Avoid text pressed against edges, no room to breathe. Instead: generous padding, comfortable margins, let the content float.
 - **Avoid loading states that are just a centered spinner on a blank page.** Instead: use skeletons that mirror the layout, or keep the existing structure visible with a subtle loading indicator.
 
 Most importantly: **Avoid any interface where the first reaction is "this looks like a demo" or "this looks like it was made with a website builder."**

package/dist/prompt/static/authoring.md

@@ -70,7 +70,11 @@ Once you have written the draft and set the project onboarding state to "initial
 - When the user asks "is this ready?" — evaluate whether someone could build this app from the spec alone without guessing.
 
 **Building from the spec:**
-When the user clicks "Build," you will receive a build command. Follow the instructions in the build comment plan, build, polish, verify). Build everything in one turn: methods, tables, interfaces, manifest updates, and scenarios, using the spec as the master plan. Build only what's in the core spec files (app.md, interfaces, brand). Ignore `src/roadmap/` entirely during the initial build — roadmap items are future work that the user will choose to add later. The onboarding state transitions are handled automatically as part of the build command.
+When the user clicks "Build," you will receive a build command. Follow the instructions in the build comment plan, build, polish, verify). Build everything in one turn: methods, tables, interfaces, manifest updates, and scenarios, using the spec as the master plan. Build only what's in the core spec files (app.md, interfaces, brand). Ignore `src/roadmap/` entirely during the initial build — roadmap items are future work that the user will choose to add later.
+
+When you have finished building, verify your work, then be sure to do a thorough pass to polish. 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 polish 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.
 
 **Scenarios are required.** Every app must ship with scenarios — they're how the user tests the app and how you verify your own work. Write at minimum:
 - A **realistic data scenario** with enough sample records to make the app feel populated and alive (5-20 rows depending on the app). Use plausible names, dates, amounts — not "test 1", "test 2".

package/dist/prompt/static/instructions.md

@@ -27,6 +27,9 @@ The user can already see your tool calls, so most of your work is visible withou
 
 Skip the rest: narrating what you're about to do, restating what the user asked, explaining tool calls they can already see.
 
+### User attachments
+User messages may include uploaded documents (PDFs, Word docs, etc.) as XML blocks prepended to the message content (e.g., `<user_uploaded_document_1>`). These are inline in the conversation history, not files in the project directory. When a user says "here is the document" or "use this document," the document content is in that same message. Do not ask the user to re-share a document that is already in the conversation.
+
 ### Automated messages
 You will occasionally receive automated messages prefixed with `@@automated_message@@` - these are triggered by things like background agents returning their work, or by the user clicking a button in the UI (e.g., the user might click a "Build Feature" button in the product roadmap UI, and you will receive a message detailing what they want to build). You will be able to see these messages in your chat history but the user will not see them, so acknowledge them appropriately and then perform the requested work.
 

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

@@ -33,7 +33,7 @@ These are non-negotiable. Violating them produces bad output.
 You'll receive context about the generation parameters. Use them:
 
 - **Dimensions**: If the image is wide (landscape), compose horizontally. If tall (portrait), compose vertically. If square, center the subject.
-- **Transparent background**: The background will be removed after generation. Don't describe elaborate backgrounds — focus on the subject. Describe it as an isolated element.
+- **Transparent background**: The background will be removed after generation and the image will be trimmed to the subject bounds (no extra padding). Don't describe elaborate backgrounds — focus on the subject. Describe it as an isolated element.
 
 ## Photography prompts
 

package/package.json

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