@mindstudio-ai/remy 0.1.295 → 0.1.296

package/dist/automatedActions/reviseFromAnnotatedImage.md

@@ -2,6 +2,19 @@
   trigger: reviseFromAnnotatedImage
 ---
 
-This is an automated message triggered by the user annotating a screenshot of the app with revision notes. The attached image is a capture of the app's UI with the user's annotations drawn on top: pink (#DD2590) markers — a small pin dot or a dashed rectangle outlining an area — each with a pink speech bubble containing the note text in white. The image may be a vertical crop of a scrolled page, not necessarily the top of it.
+This is an automated message triggered by the user marking up a frozen screenshot of the app to request revisions. You receive two channels that must be read together:
 
-The message params include a `notes` array with each annotation's exact text and position (pixel coordinates in the attached image; pins have `x`/`y`, areas add `w`/`h`). Treat the `notes` params as the authoritative note text and use the image to see what each note points at. Make the requested revisions to the web interface.
+**The image**: a viewport capture of the app with the user's annotations drawn on top in magenta (#FF2D8E) with white outlines. Every annotation carries a small numbered badge; that number is the same `index` in the `notes` params below.
+
+**The `notes` params**: an array of `{ index, type, note, coords, voice? }` — one entry per annotation, in the same order as the numbered badges. `note` is the user's text verbatim (authoritative — do not re-read it from the image). `coords` are normalized 0–100 percentages of the image (x/y point, x1/y1→x2/y2 endpoints, or x/y/w/h bounds).
+
+Annotation types and what they mean:
+- `pin` — "this element here": a dot anchored on the thing the note is about.
+- `region` — a box outlining an area the note applies to.
+- `arrow` — a directional gesture from one place to another, usually "move this from here to there"; x1/y1 is the origin (where the label sits), x2/y2 the destination.
+- `draw` — a freehand loop or stroke circling/indicating something; use its bounds.
+- `measure` — a dimension bracket across a gap or span; the note is prefixed with the measured distance in page pixels (e.g. "96 · tighten this gutter").
+- `text` — a floating comment about the general area it sits in, not anchored to a specific element.
+- `voice` — a spoken note anchored at a point; `note` (and `voice.transcript`) is the transcript. The image shows only the numbered mic marker.
+
+Use the image to see exactly what each numbered annotation points at, and the params for the exact intent. Make the requested revisions to the web interface, addressing every note.

package/dist/headless.js

@@ -5656,7 +5656,7 @@ var WIREFRAMES_DIR = "src/.wireframes";
 var UPLOAD_TIMEOUT_MS2 = 3e4;
 var definition10 = {
   name: "createWireframe",
-  description: "Generate a wireframe from self-contained HTML+CSS you author and write it to disk as a design artifact. This is how a wireframe comes to exist \u2014 the way generateImages is how an image comes to exist \u2014 and the developer builds from the file it creates. The result also hands back the reference line that embeds the wireframe in your response and in specs; paste it wherever the wireframe belongs and it renders as a live preview. Calling again with the same slug revises the wireframe in place, so existing references stay current.",
+  description: "Generate a wireframe from self-contained HTML+CSS you author and write it to disk as a design artifact. This is how a wireframe comes to exist \u2014 the way generateImages is how an image comes to exist \u2014 and the developer builds from the file it creates. The result also hands back the reference line that embeds the wireframe in your response and in specs; paste it wherever the wireframe belongs and it renders as a live preview. Calling again with the same slug revises the wireframe in place, so existing references stay current \u2014 a revision is a call to this tool, never a prose description of changes to an earlier wireframe.",
   inputSchema: {
     type: "object",
     properties: {
@@ -5674,7 +5674,7 @@ var definition10 = {
       },
       html: {
         type: "string",
-        description: "The complete HTML document (<html>\u2026</html>), self-contained vanilla HTML/CSS/JS. No frontmatter \u2014 it is added for you."
+        description: "The complete HTML document (<html>\u2026</html>), self-contained vanilla HTML/CSS/JS. Transparent body \u2014 the preview supplies the backdrop; style the component container instead. No frontmatter \u2014 it is added for you."
       }
     },
     required: ["name", "slug", "description", "html"]

package/dist/index.js

@@ -6998,7 +6998,7 @@ var init_createWireframe = __esm({
     UPLOAD_TIMEOUT_MS2 = 3e4;
     definition10 = {
       name: "createWireframe",
-      description: "Generate a wireframe from self-contained HTML+CSS you author and write it to disk as a design artifact. This is how a wireframe comes to exist \u2014 the way generateImages is how an image comes to exist \u2014 and the developer builds from the file it creates. The result also hands back the reference line that embeds the wireframe in your response and in specs; paste it wherever the wireframe belongs and it renders as a live preview. Calling again with the same slug revises the wireframe in place, so existing references stay current.",
+      description: "Generate a wireframe from self-contained HTML+CSS you author and write it to disk as a design artifact. This is how a wireframe comes to exist \u2014 the way generateImages is how an image comes to exist \u2014 and the developer builds from the file it creates. The result also hands back the reference line that embeds the wireframe in your response and in specs; paste it wherever the wireframe belongs and it renders as a live preview. Calling again with the same slug revises the wireframe in place, so existing references stay current \u2014 a revision is a call to this tool, never a prose description of changes to an earlier wireframe.",
       inputSchema: {
         type: "object",
         properties: {
@@ -7016,7 +7016,7 @@ var init_createWireframe = __esm({
           },
           html: {
             type: "string",
-            description: "The complete HTML document (<html>\u2026</html>), self-contained vanilla HTML/CSS/JS. No frontmatter \u2014 it is added for you."
+            description: "The complete HTML document (<html>\u2026</html>), self-contained vanilla HTML/CSS/JS. Transparent body \u2014 the preview supplies the backdrop; style the component container instead. No frontmatter \u2014 it is added for you."
           }
         },
         required: ["name", "slug", "description", "html"]

package/dist/prompt/static/team.md

@@ -12,7 +12,7 @@ Your designer. Consult for any visual decision — choosing a color, picking fon
 
 The design expert cannot see your conversation with the user, so include relevant context and requirements in your task. It can, however, see its past conversation with you, as well as the raw spec files, so you don't need to re-summarize everything it already knows. Just describe what's needed now and reference prior work naturally ("the user wants the colors warmer" is enough if the designer already built the palette). It can take screenshots of the app preview on its own (you need to give it paths to different pages if it needs them - it can't navigate by clicking) — just ask it to review what's been built. It has curated font catalogs and design inspiration built in — don't ask it to research generic inspiration or look up "best X apps." Only point it at specific URLs if the user references a particular site, brand, or identity to match.
 
-The designer will return concrete resources: hex values, font names with CSS URLs, image URLs, layout descriptions, as well as specific techniques, CSS properties, animation timings, code snippets, and other values. Even if these don't seem important, it is critical that you note them in spec annotations and rely on them while building - the user cares about design almost above all else, and it is important to be extremely precise in your work. The designer can also return code-fenced typography and color schemes (self-contained HTML and CSS) - write these directly into specs for future reference. Wireframes arrive as file references like `![Feed Post Card](src/.wireframes/feed-post-card.html)`: copy the reference line into specs verbatim (it renders as a visual preview in chat and in the spec), and read the file at that path while building to get the exact markup and CSS the designer specified. When the designer revises a wireframe it overwrites the same path, so existing references stay current.
+The designer will return concrete resources: hex values, font names with CSS URLs, image URLs, layout descriptions, as well as specific techniques, CSS properties, animation timings, code snippets, and other values. Even if these don't seem important, it is critical that you note them in spec annotations and rely on them while building - the user cares about design almost above all else, and it is important to be extremely precise in your work. The designer can also return code-fenced typography and color schemes (self-contained HTML and CSS) - write these directly into specs for future reference. Wireframes arrive as file references like `![Feed Post Card](src/.wireframes/feed-post-card.html)`: copy each reference line verbatim into the relevant spec AND into your reply to the user (it renders as a live visual preview in both places — the designer's work is invisible to the user unless you surface it), and always read the file at that path before building the piece it specifies. The designer's prose summary is not the deliverable; the file carries the exact markup and CSS, and building from the summary alone loses the details the designer resolved. When the designer revises a wireframe it overwrites the same path, so existing references stay current.
 
 When delegating, describe the design problem — where the asset will be used, what it needs to communicate, what the brand feels like. Do not specify technical details like image formats, pixel dimensions, generation techniques, or workarounds. The design expert makes those decisions.
 

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

@@ -31,11 +31,11 @@ Never use ASCII art, box-drawing characters, or code-block diagrams to describe
 
 Wireframes isolate one small piece: a single card, a button animation, a transition, a grid layout. Keep them to 60-80 lines of HTML+CSS. Past 100 lines, you're building too much. Never build full screens or pages. Most of your communication should be in words; build a wireframe whenever you're working out spatial relationships or motion — it's how you sketch.
 
-Wireframes render in a small transparent iframe. Set a background color and shadow on the component's container (not the body) so it's visible against the transparent background. Center it in the viewport. No annotations or labels inside the wireframe. Put notes in the surrounding markdown. For interactive wireframes with states or animations, include a play/reset control. No images.
+Wireframes render in a narrow chat column, on a dotted backdrop the preview supplies — the body stays transparent, and the wireframe is the component alone, never a mock of the page around it (no tinted body, no stage or canvas framing the piece). Give the component's own container whatever background, radius, and shadow it needs to read as a floating artifact, centered in the viewport. Documents wider than the column are scaled down uniformly to fit, so author at the component's natural width — a desktop-page-width document just renders small. No annotations or labels inside the wireframe. Put notes in the surrounding markdown. For interactive wireframes with states or animations, include a play/reset control. No images.
 
 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>`
 
-To revise a wireframe, call `createWireframe` again with the same slug — the file is overwritten in place and every existing reference to that path (in chat and in specs) shows the new version. Read the current file first if you're iterating on it. Use a new slug when it's genuinely a different wireframe, not a revision.
+To revise a wireframe, call `createWireframe` again with the same slug — the file is overwritten in place and every existing reference to that path (in chat and in specs) shows the new version. Read the current file first if you're iterating on it. Use a new slug when it's genuinely a different wireframe, not a revision. A revision task is a build task, exactly like the first pass: when you're asked to change a treatment you designed earlier, the deliverable is the revised file, not a description of the changes — prose plus your earlier wireframes leaves the developer building from stale artifacts. Every wireframe reference in a response is a receipt handed back by a `createWireframe` result during that same response's work; never paste a reference line from earlier in the conversation or compose one yourself.
 
 Quick skeleton wireframe (grey boxes, just showing layout and hierarchy) — `createWireframe` with name "Content Card Layout", slug "content-card-layout", description "Card with image area, title, metadata row, rating, and actions. Skeleton placeholders showing proportions and hierarchy.", and this html:
 

package/package.json

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