@mindstudio-ai/remy 0.1.243 → 0.1.245

package/dist/headless.js

@@ -557,24 +557,31 @@ function getOrgContext() {
 function renderOrgContextBlock() {
   const ctx = cached;
   const auth = ctx?.auth;
-  if (!auth || !auth.delegatedAvailable && !auth.requireDelegatedOnly) {
+  const hasAuth = !!auth && (auth.delegatedAvailable || !!auth.requireDelegatedOnly);
+  const hasDesignSystem = !!ctx?.designSystem;
+  if (!hasAuth && !hasDesignSystem) {
     return "";
   }
-  const lines = ["<org_auth_context>"];
+  const lines = ["<org_context>"];
   if (ctx?.org?.name && ctx?.org?.name !== "Personal Workspace") {
     lines.push(`This app is owned by the organization "${ctx.org.name}".`);
   }
-  if (auth.delegatedAvailable) {
+  if (auth?.delegatedAvailable) {
     lines.push(
       '"Sign in with Remy" (platform-delegated sign-in) is an available auth type for this app: organization members can sign in without a verification code.'
     );
   }
-  if (auth.requireDelegatedOnly) {
+  if (auth?.requireDelegatedOnly) {
     lines.push(
       "This organization requires delegated sign-in: non-delegated human auth methods (email-code, sms-code) are blocked at the platform edge for its apps."
     );
   }
-  lines.push("</org_auth_context>");
+  if (hasDesignSystem) {
+    lines.push(
+      "This organization maintains shared brand/design foundations. The design expert has access to these and applies them automatically. You don't need to gather foundational visual style or branding requirements from the user."
+    );
+  }
+  lines.push("</org_context>");
   return lines.join("\n");
 }
 
@@ -1874,11 +1881,11 @@ var setProjectMetadataTool = {
         },
         iconUrl: {
           type: "string",
-          description: "URL for the app icon (square."
+          description: "URL for the app icon (square)."
         },
         openGraphShareImageUrl: {
           type: "string",
-          description: "URL for the Open Graph share image (1200x630)."
+          description: "URL for the Open Graph share image (1200\xD7630 PNG)."
         }
       }
     }
@@ -2812,9 +2819,7 @@ async function analyzeImage(params) {
 
 // src/tools/_helpers/screenshot.ts
 var SCREENSHOT_ANALYSIS_PROMPT = `Describe everything visible on screen from top to bottom \u2014 every element, its position, its size relative to the viewport, its colors, its content. Be comprehensive, thorough, and spatial. After the inventory, note anything that looks visually broken (overlapping elements, clipped text, misaligned components).`;
-var TEXT_WRAP_DISCLAIMER = `Note: ignore text wrapping issues. Screenshots occasionally show text wrapping onto an extra line compared to the live page \u2014 most noticeable in buttons, badges, and headings. This is a known limitation of SVG foreignObject rendering used the DOM-to-image capture library that took the screenshot. The browser's SVG renderer computes slightly wider text metrics than the HTML layout engine, so text that fits on one line in the live DOM can overflow by a fraction of a pixel in the capture - this is not a real issue.
-
-Respond only with your analysis as Markdown and absolutely no other text. Do not use emojis - use unicode if you need symbols.`;
+var ANALYSIS_RESPONSE_FORMAT = `Respond only with your analysis as Markdown and absolutely no other text. Do not use emojis - use unicode if you need symbols.`;
 function buildScreenshotAnalysisPrompt(opts) {
   let p = opts?.prompt || SCREENSHOT_ANALYSIS_PROMPT;
   if (opts?.styleMap) {
@@ -2828,7 +2833,7 @@ ${opts.styleMap}
   }
   p += `
 
-${TEXT_WRAP_DISCLAIMER}`;
+${ANALYSIS_RESPONSE_FORMAT}`;
   return p;
 }
 async function streamScreenshotAnalysis(opts) {
@@ -2854,6 +2859,9 @@ async function captureAndAnalyzeScreenshot(promptOrOptions) {
   let model;
   let path13;
   let fullPage = true;
+  let width;
+  let height;
+  let format;
   if (typeof promptOrOptions === "object" && promptOrOptions !== null) {
     prompt = promptOrOptions.prompt;
     existingUrl = promptOrOptions.imageUrl;
@@ -2861,11 +2869,17 @@ async function captureAndAnalyzeScreenshot(promptOrOptions) {
     if (promptOrOptions.fullPage !== void 0) {
       fullPage = promptOrOptions.fullPage;
     }
+    width = promptOrOptions.width;
+    height = promptOrOptions.height;
+    format = promptOrOptions.format;
     onLog = promptOrOptions.onLog;
     model = promptOrOptions.model;
   } else {
     prompt = promptOrOptions;
   }
+  if (width != null && height != null) {
+    fullPage = false;
+  }
   let url;
   let styleMap;
   if (existingUrl) {
@@ -2873,7 +2887,12 @@ async function captureAndAnalyzeScreenshot(promptOrOptions) {
   } else {
     const ssResult = await sidecarRequest(
       fullPage ? "/screenshot-full-page" : "/screenshot-viewport",
-      path13 ? { path: path13 } : void 0,
+      {
+        ...path13 ? { path: path13 } : {},
+        ...width != null ? { width } : {},
+        ...height != null ? { height } : {},
+        ...format ? { format } : {}
+      },
       { timeout: fullPage ? 12e4 : 3e4 }
     );
     url = ssResult?.url || ssResult?.screenshotUrl;
@@ -4002,7 +4021,7 @@ var screenshotTool = {
   clearable: true,
   definition: {
     name: "screenshot",
-    description: "Capture a screenshot of the app preview and get a description of what's on screen. Choose `fullPage`: `false` captures just the visible viewport (fast \u2014 for a specific section the page is scrolled to), `true` captures the entire page top-to-bottom (slower \u2014 for overall composition or content past the fold). Captures the settled page state \u2014 it cannot catch animations, transitions, or transient state. 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, scrolling to a section), use the instructions param to describe the steps.",
+    description: "Capture a screenshot of the app preview and get a description of what's on screen. Choose `fullPage`: `false` captures just the visible viewport (fast \u2014 for a specific section the page is scrolled to), `true` captures the entire page top-to-bottom (slower \u2014 for overall composition or content past the fold). Captures the settled page state \u2014 it cannot catch animations, transitions, or transient state. 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, scrolling to a section), use the instructions param to describe the steps. To render a fixed-size image such as an Open Graph share card, set `width` and `height` (e.g. 1200 \xD7 630) and `format: 'png'`: the tool navigates to `path`, clips to exactly those pixel dimensions, and returns the image URL.",
     inputSchema: {
       type: "object",
       properties: {
@@ -4022,6 +4041,19 @@ var screenshotTool = {
           type: "string",
           description: 'Navigate to this path before capturing (e.g. "/settings", "/dashboard"). If omitted, screenshots the current page.'
         },
+        width: {
+          type: "number",
+          description: "Exact capture width in pixels. Set together with `height` to render a fixed-size image; clips to exactly this viewport instead of the default preview size."
+        },
+        height: {
+          type: "number",
+          description: "Exact capture height in pixels. Set together with `width`."
+        },
+        format: {
+          type: "string",
+          enum: ["png", "jpeg"],
+          description: "Output image format. Defaults to 'jpeg'. Use 'png' for crisp flat graphics like share cards, where JPEG artifacts show on sharp type and edges."
+        },
         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, scrolling to a section, getting through a login/auth checkpoint), describe the steps to get there. A browser automation agent will follow these instructions, then capture per your `fullPage` choice \u2014 so with `fullPage: false` you can scroll to a section and capture just that viewport. 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. Never describe what names or values to use when applying the instructions - 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. Use only when interaction is required to *reach* the state you want to capture \u2014 log in, dismiss a modal, switch a tab, follow a route, scroll to a section. If your steps are exercising the app's functionality across multiple states (running flows, asserting behavior under interaction, multi-step QA), use `runAutomatedBrowserTest` instead."
@@ -4064,6 +4096,9 @@ var screenshotTool = {
           prompt: input.prompt,
           path: input.path,
           fullPage,
+          width: input.width,
+          height: input.height,
+          format: input.format,
           onLog: context?.onLog,
           model: resolveModel("imageAnalysis", context?.models, context?.model)
         });

package/dist/index.js

@@ -1462,11 +1462,11 @@ var init_setProjectMetadata = __esm({
             },
             iconUrl: {
               type: "string",
-              description: "URL for the app icon (square."
+              description: "URL for the app icon (square)."
             },
             openGraphShareImageUrl: {
               type: "string",
-              description: "URL for the Open Graph share image (1200x630)."
+              description: "URL for the Open Graph share image (1200\xD7630 PNG)."
             }
           }
         }
@@ -3555,7 +3555,7 @@ ${opts.styleMap}
   }
   p += `
 
-${TEXT_WRAP_DISCLAIMER}`;
+${ANALYSIS_RESPONSE_FORMAT}`;
   return p;
 }
 async function streamScreenshotAnalysis(opts) {
@@ -3581,6 +3581,9 @@ async function captureAndAnalyzeScreenshot(promptOrOptions) {
   let model;
   let path14;
   let fullPage = true;
+  let width;
+  let height;
+  let format;
   if (typeof promptOrOptions === "object" && promptOrOptions !== null) {
     prompt = promptOrOptions.prompt;
     existingUrl = promptOrOptions.imageUrl;
@@ -3588,11 +3591,17 @@ async function captureAndAnalyzeScreenshot(promptOrOptions) {
     if (promptOrOptions.fullPage !== void 0) {
       fullPage = promptOrOptions.fullPage;
     }
+    width = promptOrOptions.width;
+    height = promptOrOptions.height;
+    format = promptOrOptions.format;
     onLog = promptOrOptions.onLog;
     model = promptOrOptions.model;
   } else {
     prompt = promptOrOptions;
   }
+  if (width != null && height != null) {
+    fullPage = false;
+  }
   let url;
   let styleMap;
   if (existingUrl) {
@@ -3600,7 +3609,12 @@ async function captureAndAnalyzeScreenshot(promptOrOptions) {
   } else {
     const ssResult = await sidecarRequest(
       fullPage ? "/screenshot-full-page" : "/screenshot-viewport",
-      path14 ? { path: path14 } : void 0,
+      {
+        ...path14 ? { path: path14 } : {},
+        ...width != null ? { width } : {},
+        ...height != null ? { height } : {},
+        ...format ? { format } : {}
+      },
       { timeout: fullPage ? 12e4 : 3e4 }
     );
     url = ssResult?.url || ssResult?.screenshotUrl;
@@ -3627,16 +3641,14 @@ async function captureAndAnalyzeScreenshot(promptOrOptions) {
     model
   });
 }
-var SCREENSHOT_ANALYSIS_PROMPT, TEXT_WRAP_DISCLAIMER;
+var SCREENSHOT_ANALYSIS_PROMPT, ANALYSIS_RESPONSE_FORMAT;
 var init_screenshot = __esm({
   "src/tools/_helpers/screenshot.ts"() {
     "use strict";
     init_sidecar();
     init_analyzeImage();
     SCREENSHOT_ANALYSIS_PROMPT = `Describe everything visible on screen from top to bottom \u2014 every element, its position, its size relative to the viewport, its colors, its content. Be comprehensive, thorough, and spatial. After the inventory, note anything that looks visually broken (overlapping elements, clipped text, misaligned components).`;
-    TEXT_WRAP_DISCLAIMER = `Note: ignore text wrapping issues. Screenshots occasionally show text wrapping onto an extra line compared to the live page \u2014 most noticeable in buttons, badges, and headings. This is a known limitation of SVG foreignObject rendering used the DOM-to-image capture library that took the screenshot. The browser's SVG renderer computes slightly wider text metrics than the HTML layout engine, so text that fits on one line in the live DOM can overflow by a fraction of a pixel in the capture - this is not a real issue.
-
-Respond only with your analysis as Markdown and absolutely no other text. Do not use emojis - use unicode if you need symbols.`;
+    ANALYSIS_RESPONSE_FORMAT = `Respond only with your analysis as Markdown and absolutely no other text. Do not use emojis - use unicode if you need symbols.`;
   }
 });
 
@@ -4622,7 +4634,7 @@ var init_screenshot2 = __esm({
       clearable: true,
       definition: {
         name: "screenshot",
-        description: "Capture a screenshot of the app preview and get a description of what's on screen. Choose `fullPage`: `false` captures just the visible viewport (fast \u2014 for a specific section the page is scrolled to), `true` captures the entire page top-to-bottom (slower \u2014 for overall composition or content past the fold). Captures the settled page state \u2014 it cannot catch animations, transitions, or transient state. 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, scrolling to a section), use the instructions param to describe the steps.",
+        description: "Capture a screenshot of the app preview and get a description of what's on screen. Choose `fullPage`: `false` captures just the visible viewport (fast \u2014 for a specific section the page is scrolled to), `true` captures the entire page top-to-bottom (slower \u2014 for overall composition or content past the fold). Captures the settled page state \u2014 it cannot catch animations, transitions, or transient state. 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, scrolling to a section), use the instructions param to describe the steps. To render a fixed-size image such as an Open Graph share card, set `width` and `height` (e.g. 1200 \xD7 630) and `format: 'png'`: the tool navigates to `path`, clips to exactly those pixel dimensions, and returns the image URL.",
         inputSchema: {
           type: "object",
           properties: {
@@ -4642,6 +4654,19 @@ var init_screenshot2 = __esm({
               type: "string",
               description: 'Navigate to this path before capturing (e.g. "/settings", "/dashboard"). If omitted, screenshots the current page.'
             },
+            width: {
+              type: "number",
+              description: "Exact capture width in pixels. Set together with `height` to render a fixed-size image; clips to exactly this viewport instead of the default preview size."
+            },
+            height: {
+              type: "number",
+              description: "Exact capture height in pixels. Set together with `width`."
+            },
+            format: {
+              type: "string",
+              enum: ["png", "jpeg"],
+              description: "Output image format. Defaults to 'jpeg'. Use 'png' for crisp flat graphics like share cards, where JPEG artifacts show on sharp type and edges."
+            },
             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, scrolling to a section, getting through a login/auth checkpoint), describe the steps to get there. A browser automation agent will follow these instructions, then capture per your `fullPage` choice \u2014 so with `fullPage: false` you can scroll to a section and capture just that viewport. 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. Never describe what names or values to use when applying the instructions - 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. Use only when interaction is required to *reach* the state you want to capture \u2014 log in, dismiss a modal, switch a tab, follow a route, scroll to a section. If your steps are exercising the app's functionality across multiple states (running flows, asserting behavior under interaction, multi-step QA), use `runAutomatedBrowserTest` instead."
@@ -4684,6 +4709,9 @@ var init_screenshot2 = __esm({
               prompt: input.prompt,
               path: input.path,
               fullPage,
+              width: input.width,
+              height: input.height,
+              format: input.format,
               onLog: context?.onLog,
               model: resolveModel("imageAnalysis", context?.models, context?.model)
             });
@@ -5718,24 +5746,31 @@ function getOrgContext() {
 function renderOrgContextBlock() {
   const ctx = cached;
   const auth = ctx?.auth;
-  if (!auth || !auth.delegatedAvailable && !auth.requireDelegatedOnly) {
+  const hasAuth = !!auth && (auth.delegatedAvailable || !!auth.requireDelegatedOnly);
+  const hasDesignSystem = !!ctx?.designSystem;
+  if (!hasAuth && !hasDesignSystem) {
     return "";
   }
-  const lines = ["<org_auth_context>"];
+  const lines = ["<org_context>"];
   if (ctx?.org?.name && ctx?.org?.name !== "Personal Workspace") {
     lines.push(`This app is owned by the organization "${ctx.org.name}".`);
   }
-  if (auth.delegatedAvailable) {
+  if (auth?.delegatedAvailable) {
     lines.push(
       '"Sign in with Remy" (platform-delegated sign-in) is an available auth type for this app: organization members can sign in without a verification code.'
     );
   }
-  if (auth.requireDelegatedOnly) {
+  if (auth?.requireDelegatedOnly) {
     lines.push(
       "This organization requires delegated sign-in: non-delegated human auth methods (email-code, sms-code) are blocked at the platform edge for its apps."
     );
   }
-  lines.push("</org_auth_context>");
+  if (hasDesignSystem) {
+    lines.push(
+      "This organization maintains shared brand/design foundations. The design expert has access to these and applies them automatically. You don't need to gather foundational visual style or branding requirements from the user."
+    );
+  }
+  lines.push("</org_context>");
   return lines.join("\n");
 }
 var log9, cached;

package/dist/prompt/compiled/auth.md

@@ -34,7 +34,7 @@ Remy apps can have and manage their own users. Auth is opt-in: configure it in t
   - `email-code` — 6-digit code sent via email
   - `sms-code` — 6-digit code sent via SMS
   - `api-key` — programmatic access via `Authorization: Bearer sk_...` header. Resolves to a user with full RBAC.
-  - `remy` — platform-delegated sign-in ("Sign in with Remy"). The platform resolves who the user is; roles and verification are platform-managed. Only usable when the app's owning organization has it enabled — the `<org_auth_context>` block signals availability. See *Organization-Managed Sign-In* above.
+  - `remy` — platform-delegated sign-in ("Sign in with Remy"). The platform resolves who the user is; roles and verification are platform-managed. Only usable when the app's owning organization has it enabled — the `<org_context>` block signals availability. See *Organization-Managed Sign-In* above.
 - **`auth.table.name`** — name of the `defineTable` table that holds user records.
 - **`auth.table.columns`** — maps platform-managed fields to column names in the developer's table.
   - `email` — required if `email-code` is in methods
@@ -135,12 +135,12 @@ const user = await auth.verifySmsCode(verificationId, '123456');
 
 ## Organization-Managed Sign-In ("Sign in with Remy")
 
-Some apps are owned by an organization that centralizes sign-in. When that applies to the current app, the system prompt includes an `<org_auth_context>` block (near the end) stating the organization name and whether delegated sign-in is available. Sign in with Remy is a way to make authentication seamless for internal apps - it should not be used for public-facing applications. The app owner will need to add users to their workspace's team on the Remy platform and those users will need Remy accounts for it to work.
+Some apps are owned by an organization that centralizes sign-in. When that applies to the current app, the system prompt includes an `<org_context>` block (near the end); for org-managed sign-in it states the organization name and whether delegated sign-in is available. Sign in with Remy is a way to make authentication seamless for internal apps - it should not be used for public-facing applications. The app owner will need to add users to their workspace's team on the Remy platform and those users will need Remy accounts for it to work.
 
 - **When it says "Sign in with Remy" is available** — offer delegated sign-in: a **"Continue with {Org}"** button wired to the `remy` method (see *Sign in with Remy (delegated)* below). Use the exact organization name from the block for the label. For an org-owned app this is usually the primary sign-in — the members already have platform identities, so a verification-code form is redundant.
 - **When it says the organization requires delegated sign-in** — `remy` is the *only* human method: do not add `email-code` or `sms-code`. Those are blocked at the platform edge for the org's apps, so building them yields a login that can't work.
 
-When no `<org_auth_context>` block is present — the common case — do not build it or offer to build it. This is an auth scheme for enterprises building internal apps only, and it requires a Remy enterprise plan to use. When enabled, the platform decides who the user is (like "Sign in with Google"); the app just starts the flow and reads the result.
+When the `<org_context>` block is absent, or present without a delegated-sign-in line — the common case — do not build it or offer to build it. This is an auth scheme for enterprises building internal apps only, and it requires a Remy enterprise plan to use. When enabled, the platform decides who the user is (like "Sign in with Google"); the app just starts the flow and reads the result.
 
 ```typescript
 // "Continue with {Org}" button — must be triggered by a user gesture (click).
@@ -399,7 +399,7 @@ Consult the `visualDesignExpert` to help you work through authentication at a hi
 ### Rules for Building Auth Screens
 **Auth modes:** Think about which mode(s) makes the most sense for the type of app you are building. Consumer apps likely to be used on mobile should probably tend toward SMS auth as the default - business apps used on desktop make more sense to use email verification - or allow both, there's no harm in giving the user choice!
 
-**"Continue with {Org}" (delegated):** When `<org_auth_context>` says delegated sign-in is available, a single "Continue with {Org}" button is the primary path — often the *only* one — and there's no verification-code step to design at all (the platform handles it). Give the button real weight in the branded login moment rather than treating it as a secondary option, and use the exact organization name. If the org also allows code methods, delegated goes first with the code form beneath. On return from the handshake (and on dashboard launch), render a brief "Completing sign-in…" state driven by `auth.authStatus === 'authenticating'` — never the login form — so a successful sign-in doesn't flash the logged-out screen.
+**"Continue with {Org}" (delegated):** When the `<org_context>` block says delegated sign-in is available, a single "Continue with {Org}" button is the primary path — often the *only* one — and there's no verification-code step to design at all (the platform handles it). Give the button real weight in the branded login moment rather than treating it as a secondary option, and use the exact organization name. If the org also allows code methods, delegated goes first with the code form beneath. On return from the handshake (and on dashboard launch), render a brief "Completing sign-in…" state driven by `auth.authStatus === 'authenticating'` — never the login form — so a successful sign-in doesn't flash the logged-out screen.
 
 **Verification code input:** The 6-digit code entry is the critical moment. Prefer to design it as individual digit boxes (not a single text input), with auto-advance between digits, a beautiful animation and auto-submit on paste, and clear visual feedback. The boxes should be large enough to tap easily on mobile. Show a subtle animation on successful verification. Error states should be inline and immediate, not a separate alert. Make sure there is no layout shift when loading in the success/error states - loading spinners must never pop in below the input and shift the content, for example.
 

package/dist/prompt/static/team.md

@@ -76,6 +76,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 intiial roadmap after writing the spec for the first time or updating the roadmap after large work sessions. This task takes a while and we can allow the user to continue building while it happens in the background.
-- After writing the spec, once you have finalized the shape of the app, ask `visualDesignExpert` to create an icon and an open graph shring image for the app, then set them with `setProjectMetadata`, alongside the app's name and short description.
+- 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.
 
 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

@@ -77,7 +77,9 @@ Keep logos and icons consistent - if you already have a logo, use `editImages` t
 
 #### 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. Generate at 4096 × 2150 and return the CDN URL.
+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.
 
 ### When to use images
 

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

@@ -20,7 +20,7 @@ Login and signup screens set the tone for the user's entire experience with the
 
 Authentication moments must feel natural and intuitive - they should not feel jarring or surprising. Take care to integrate them into the entire experience when building. Remy apps support SMS code verification, email verification, delegated "Sign in with Remy", or a combination, depending on how the app is configured.
 
-**"Continue with {Org}" (delegated sign-in):** Some apps are internal business tools that are owned by an organization and sign members in through the platform — a single "Continue with {Org}" button, no verification-code step at all. For these apps this button is often the primary (sometimes only) path, so give it real presence in the branded login moment rather than tucking it away, and label it with the organization's actual name. If the app also offers code methods, lead with the delegated button and place the code form beneath. This scheme should ONLY be used for internal apps AND when it is explicitly enabled in <org_auth_context> - it should not be used for public-facing apps.
+**"Continue with {Org}" (delegated sign-in):** Some apps are internal business tools that are owned by an organization and sign members in through the platform — a single "Continue with {Org}" button, no verification-code step at all. For these apps this button is often the primary (sometimes only) path, so give it real presence in the branded login moment rather than tucking it away, and label it with the organization's actual name. If the app also offers code methods, lead with the delegated button and place the code form beneath. This scheme should ONLY be used for internal apps AND when it is explicitly enabled in <org_context> - it should not be used for public-facing apps.
 
 **Verification code input:** The 6-digit code entry is the critical moment. Prefer to design it as individual digit boxes (not a single text input), with auto-advance between digits, auto-submit on paste, and clear visual feedback. The boxes should be large enough to tap easily on mobile. Show a subtle animation on successful verification. Error states should be inline and immediate, not a separate alert.
 

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

@@ -69,12 +69,6 @@ For app icons and logos, the goal is something that reads clearly at phone home
 - 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.
 
-#### Open Graph Sharing Images
-
-OG images are often a user's first impression of the app — they show up in iMessage, Slack, Twitter, etc. at small sizes. Keep text minimal: the app name and at most a short tagline (three to five words). This is a mood piece, not a messaging opportunity. Think App Store feature card — one beautiful composition that makes someone want to tap.
-
-Apply the same material/lighting/color density as photography prompts. The text should feel integrated into the scene — typeset within the composition, not pasted on top. Describe the typography treatment (weight, size, color, position) as part of the overall image, and describe how the background interacts with the text (glow, depth, contrast). The whole image should read as one cohesive graphic, not layers.
-
 ## Output
 
 Respond with ONLY the enhanced prompt. Be detailed and specific — a good prompt is a dense paragraph of 80-150 words that paints a complete picture: style, subject, materials, lighting behavior, color relationships, atmosphere, and composition. Terse prompts produce generic images.

package/package.json

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