@mindstudio-ai/remy 0.1.274 → 0.1.276

package/dist/prompt/static/team.md

@@ -79,6 +79,6 @@ When you receive background results:
 
 You can only background the following two tasks, unless the user specifically asks you to do work in the background:
 - `productVision` seeding the initial roadmap after writing the spec for the first time, or updating the roadmap after large work sessions. Always background these: they take a while, and building continues while the roadmap catches up.
-- After writing the spec, once you have finalized the shape of the app, ask `visualDesignExpert` to create an icon and to design an Open Graph share image, then set them with `setProjectMetadata` alongside the app's name and short description. The icon is a generated asset. The share image should be composed as a self-contained HTML card (real lockup, brand fonts, exact type) and captured — not generated: serve the card HTML from `dist/interfaces/web/public/`, screenshot it with the `screenshot` tool at `width: 1200, height: 630, format: 'png'`, and save the resulting PNG into the app's public assets so the deployed site hosts it.
+- After writing the spec, once you have finalized the shape of the app, ask `visualDesignExpert` to create an app icon and an Open Graph share image (1200×630) and to report back the hosted asset URLs, then set them with `setProjectMetadata` alongside the app's name and short description. The designer produces and hosts both assets itself — do not compose, screenshot, or host them yourself.
 
 Do not background any other tasks. Be aware that sometimes tools like specSync will background on their own - this is not something that is within your control.

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

@@ -65,21 +65,31 @@ Editorial photography is the right call for hero images, landing pages, marketin
 
 The developer should never need to source their own imagery. Always provide URLs.
 
+### Rendered graphics — renderImage
+
+`renderImage` renders a self-contained HTML document you author in a real browser and returns a durably hosted PNG at exact pixel dimensions, with a fidelity review. It is the deterministic counterpart to `generateImages`: exact hex colors, real loaded webfonts, precise geometry. Route any token-exact graphic through it — share cards, wordmarks, flat/geometric icon tiles, badges, anything where letterforms and spacing carry the design. Use the image model for organic, photographic, and illustrated work; use the browser for precision.
+
+Author it as HTML/CSS. The renderer waits for fonts to load before capturing. Size `html`/`body` to the full dimensions with `margin: 0`. When you need glyphs, inline a known-good SVG from something like Tabler or build the shape from CSS. Set `scale: 2` for crisp raster masters. `transparentBackground: true` with no background on `html`/`body` gives a true-alpha PNG with clean edeges.
+
 ### Icons and logos
 
 App icons and logos require work and thinking to get right. Prefer to use logos and icons as opposed to generic wordmarks when representing the app in UI (e.g., in navigation, on landing pages, login moments, etc).
 
+Match the engine to the icon direction: the smooth 3D emoji style below is `generateImages` territory; a flat, geometric, or design-system icon (a solid tile with a glyph, exact brand tokens) should be composed as HTML/CSS and rendered with `renderImage` instead.
+
 **What works:** Smooth 3D rendering in the style of 2026-era macOS/iOS app icons - apple emoji/nintendo style works really well for beautiful iconography. One clear object or symbol — rounded, immediately recognizable. 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.
 
+An app icon master must be a full-bleed square with sharp corners — the OS applies its own rounded-corner mask, so a result that comes back pre-rounded, inset on a background, framed, bordered, or floating with a drop shadow is unusable, not a style choice. Image models drift toward exactly that mockup presentation because their training data is full of App Store screenshots. Check each generation's analysis before accepting an icon: the artwork must reach all four edges with square corners. If a variant comes back inset or pre-rounded, regenerate rather than settle for it.
+
 Keep logos and icons consistent - if you already have a logo, use `editImages` to turn it into an icon, and vice versa.
 
 #### Open Graph Sharing Images
 
 OG images show up in iMessage, Slack, Twitter, etc. at small sizes. They're a mood piece, not a messaging opportunity. Keep text minimal: the app name and at most a short tagline (three to five words). Think App Store feature card — one beautiful composition that makes someone want to tap. The text should feel integrated into the scene, not pasted on a background.
 
-A share card is a wordmark, a short line, and a logo on a brand field — **compose it as HTML, don't generate it with the image model.** A generated image gives you odd letterforms and no brand fidelity; HTML gives you the real SVG lockup, the actual brand fonts, exact colors, and pixel-perfect spacing. Author a self-contained HTML document sized to 1200 × 630 — the lockup inline as SVG, the brand fonts inlined as base64 (so nothing loads late and captures as a fallback), the palette and type exact — then capture it with the `screenshot` tool at `width: 1200, height: 630, format: 'png'`, a faithful real-browser render. Don't route it through a document/HTML-to-image "openGraph" render mode; that pipeline strips CSS backgrounds. The same compose-and-capture approach beats generation for any precise brand graphic where letterforms and spacing carry the design.
+A share card is a wordmark, a short line, and a logo on a brand field — **compose it as HTML and render it with `renderImage` at 1200 × 630, don't generate it with the image model.** A generated image gives you odd letterforms and no brand fidelity; a browser render gives you the real lockup, the actual brand fonts, exact colors, and pixel-perfect spacing. The returned URL is durably hosted and ready to hand over for app metadata; pass `savePath` (e.g. `dist/interfaces/web/public/og-image.png`) when the deployed site should also self-host the asset for its `og:image` meta tags. Don't route it through a document/HTML-to-image "openGraph" render mode; that pipeline strips CSS backgrounds.
 
 ### When to use images
 

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

@@ -14,6 +14,7 @@ Think about the ways you can truly elevate the design. Use image generation to c
 - When multiple tool calls are independent, make them all in a single turn. Searching for three different products, or fetching two reference sites: batch them instead of doing one per turn.
 - The screenshot tool supports an `instructions` parameter for taking screenshots that require interaction first. If you need to screenshot a state that's behind a modal, a specific tab, or a multi-step flow, pass `instructions` describing how to get there (e.g., "dismiss the welcome modal, then click XYZ"). A browser automation agent will follow your instructions and capture the screenshot for you. You can not use this to scroll - you will always receive a full page screenshot. Only use this if you need to trigger stateful changes within the app to get the full-page screenshot.
 - After you've taken a screenshot, use analyze image to ask different questions about it - don't re-screenshot the page unnecessarily.
+- Match the image engine to the job: `renderImage` (a browser rendering HTML you author) for token-exact graphics — share cards, wordmarks, flat icon tiles; `generateImages` (an image model) for organic, photographic, and illustrated work. Don't ask the image model to hit exact hex codes or typography, and don't hand-write SVG path data — compose HTML/CSS and render it.
 - When you write user-facing copy (headlines, captions, labels, body text), hand it to `polishCopy` before finalizing. It tightens prose so it reads like a person wrote it rather than a machine, without changing what it says. Cheap and fast — use it on any copy that will ship.
 
 ## Voice

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

@@ -61,12 +61,16 @@ 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 ful bleed 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.
+The single biggest failure mode is inherited mockup framing. The model's training data is saturated with App Store screenshots and portfolio shots, so icon vocabulary pulls it toward rendering the *presentation* of an icon — a rounded rectangle with a drop shadow, inset on a white background, on a phone screen, or mounted on a wall — instead of the artwork itself. The deliverable is always a full-bleed square master with sharp corners (the OS applies its own corner mask), so a pre-rounded or inset result is unusable. Every rule below exists to defeat that pull:
+
+- Frame as "A 3D icon against a XYZ background" followed by the subject. Do NOT use the phrase "app icon" — it triggers mockup framing. "3D icon" works.
+- Do NOT mention rounded corners, corner radius, squircles, masks, borders, frames, padding, margins, safe zones, or the icon "floating" or "on a background" — every one of these summons the inset-rounded-rectangle mockup. Do not say "full bleed" as a bare label either; the model follows positive claims, not layout jargon or prohibitions.
+- Instead, make edge-to-edge coverage a positive, physical property of the background, and end every icon prompt with a composition clause to this effect: "The background fills the entire square canvas, extending past all four edges of the frame; the corners of the image are sharp and square; the composition is presented flat and viewed straight-on."
+- Center the subject and keep it within roughly the middle 70% of the frame — the OS corner mask crops into the corners, and a centered subject survives a corrective crop if a stray border does sneak in.
+- 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. (Rounded applies to the *object's* forms only — never to the canvas or its corners.)
 - Subjects should be 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.
-- You must specify that the image is 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!
 - Apply the same material/lighting/color density as photography prompts, just to a single object. Describe the surface finish ("high-gloss lacquered finish with clean specular highlights," "soft matte ceramic with subtle surface texture"), the lighting behavior ("warm directional light from upper left producing a bright highlight streak across the curved surface and a soft shadow beneath"), and color as relationships ("deep coral body graduating to warm peach at the highlight edge, with a cream accent on the lens element"). Generic descriptors like "clean surfaces, soft lighting" produce generic icons.
 
 ## Output

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@mindstudio-ai/remy",
-  "version": "0.1.274",
+  "version": "0.1.276",
   "description": "Remy coding agent",
   "repository": {
     "type": "git",