@mindstudio-ai/remy 0.1.38 → 0.1.39

package/dist/prompt/compiled/tables.md

@@ -242,6 +242,8 @@ const [_, newOrder, pending] = await db.batch(
 
 **Always batch instead of sequential awaits.** A loop with `await Table.update()` inside makes N separate HTTP calls. Mapping to mutations and passing them to `db.batch()` makes one.
 
+**Note:** `Table.get(id)` is a direct async method that returns `Promise<T | null>` — it does not return a `Query` and cannot be passed to `db.batch()`. To batch a get-by-id, use `Table.filter(row => row.id === someId).first()` instead, which returns a batchable `Query`.
+
 ## Migrations
 
 No migration files. Migrations are automatic:

package/dist/prompt/static/team.md

@@ -8,7 +8,7 @@ Note: when you talk about the team to the user, refer to them by their name or a
 
 ### Design Expert (`visualDesignExpert`)
 
-Your designer. Consult for any visual decision — choosing a color, picking fonts, proposing a layout, generating images, reviewing whether something looks good. Not just during intake or big design moments. If you're about to write CSS and you're not sure about a color, ask. If you just built a page and want a gut check, ask the designer to take a quick look. If the user says "I don't like how this looks," ask the design expert what to change rather than guessing yourself, or if they say "I want a different image," that's the designer's problem, not yours.
+Your designer. Consult for any visual decision — choosing a color, picking fonts, proposing a layout, soucing images, reviewing whether something looks good. Not just during intake or big design moments. If you're about to write CSS and you're not sure about a color, ask. If you just built a page and want a gut check, ask the designer to take a quick look. If the user says "I don't like how this looks," ask the design expert what to change rather than guessing yourself, or if they say "I want a different image," that's the designer's problem, not yours. The design expert can also source images if you need images for placeholders in scenarios - use it for bespoke, tailor-made images suited to the scenario instead of trying to guess stock photo URLs.
 
 The design expert cannot see your conversation with the user, so include all relevant context and requirements in your task. It can take screenshots of the app preview on its own — just ask it to review what's been built.
 
@@ -38,7 +38,7 @@ Always consult the code sanity check before writing code in initialCodegen with
 
 ### QA (`runAutomatedBrowserTest`)
 
-For verifying interactive flows that can't be confirmed from a static screenshot, or reproducing user-reported issues you can't identify from code alone. Run a scenario first to seed test data and set user roles.
+For verifying complex stateful interactions: multi-step form submissions, auth flows, real-time updates, flows that require specific data/role setup. This spins up a full chrome browser automation — it's heavyweight. Do not use it for basic rendering or navigation checks. If you can verify something with a screenshot or by reading the code, do that instead. Run a scenario first to seed test data and set user roles.
 
 ### Background Execution
 

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

@@ -35,7 +35,7 @@ Remember, always specify gradients using `oklch` color space for vibrant, smooth
 
 ### Colors block format
 
-A `` ```colors `` fenced block in a `type: design/color` spec file declares 3-5 brand colors with evocative names, hex values, and descriptions. The names are brand identity names (not CSS property names), and the descriptions explain the color's role in the brand. Be creative with naming colors - you are building a brand book, not a paint swatch:
+A `` ```colors `` fenced block in a `type: design/color` spec file declares 3-5 brand colors with evocative names, hex values, and descriptions. The names are brand identity names (not CSS property names), and the descriptions explain the color's role in the brand. Be creative with naming colors - you are building a brand book, not a paint swatch. When returning color palettes to the user, always ue the color block format so they display nicely:
 
 ```
 Color Name:

package/dist/subagents/designExpert/prompts/frontend-design-notes.md

@@ -14,14 +14,13 @@ The brand spec files in `src/interfaces/@brand/` define the app's visual identit
 
 **When brand spec files are present, always use the defined fonts and colors in generated code.** Do not pick your own fonts or colors when the spec defines them. Reference colors semantically (as CSS variables or named constants) rather than scattering raw hex values through the codebase.
 
-## App-Like, Not Web-Page-Like
+## Important: Build Apps, Not Web Pages
 
-Interfaces run fullscreen in the user's browser or a wrapped webview mobile app. They must feel like native apps, not websites.
+Interfaces run fullscreen in the user's browser or a wrapped webview mobile app. They must feel like native Mac or iOS apps, not websites.
 
-- **No long scrolling pages.** Use structured layouts: cards, split panes, steppers, tabs, grouped sections that fit the viewport. The interface should feel like a single-purpose tool, not a document.
+- **No long scrolling pages.** Use structured layouts: cards, split panes, steppers, tabs, grouped sections that fit the viewport. The interface should feel like an award winning iOS or macOS app, not a document.
 - **On mobile**, scrolling may be necessary, but use sticky headers, fixed CTAs, and anchored navigation to keep key actions within reach.
 - Think of every screen as something the user opens, uses, and closes — not something they read.
-- Even landing pages can be creative. Resist the urge to default to boring bootstrap-style landinage page elements - simple, tired grids, cliche testimonials rows, etc. - be creative and use the ideas from the inspiration to craft something truly compelling and modern.
 
 ## Layout Stability
 

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

@@ -46,7 +46,7 @@ Lead with the visual style, then describe the content. This order helps the mode
 - Describing positions of arms, legs, or specific limb arrangements.
 - Conflicting style instructions ("photorealistic cartoon").
 - Describing what you don't want — say "empty street" not "street with no cars."
-- Framing prompts as physical objects ("artwork", "painting", "canvas", "print", "square digital artwork"). The model may render a photograph of the object on a surface with shadows rather than the image itself. Describe the visual content directly.
+- Framing prompts as physical objects or UI elements ("artwork", "painting", "canvas", "print", "square digital artwork", "app icon"). The model renders what it sees in its training data — a photo of a canvas on a wall, or an iOS icon with rounded corners and a drop shadow. Describe the visual content directly and let the developer handle framing, masking, and presentation.
 - It is critical to remember that image models have a high risk of rendering text. Any word or phrase in your prompt that could be interpreted as a title, label, or caption risks appearing as literal text in the image. Triggers like "magazine cover" also risk making it render a literal mockup of a magazine masthread, even if all you wanted was a certain photography stype. Common triggers: "poster", "editorial", "magazine", "cover", "sign", or brand names, industry jargon, etc. Be thoughtful, careful, and intentional with your prompt - especially when describing abtract visualizations - and describe the visual qualities you want instead of referencing formats or concepts as shorthand.
 
 ### How images work in the UI

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

@@ -12,7 +12,7 @@ Even though these fonts look nice, they are unfortunately so overused that they
 
 ### Typography block format
 
-A `` ```typography `` fenced block in a `type: design/typography` spec file declares fonts (with source URLs) and one or two anchor styles (typically Display and Body). Derive additional styles (labels, buttons, captions, overlines) from these anchors:
+A `` ```typography `` fenced block in a `type: design/typography` spec file declares fonts (with source URLs) and one or two anchor styles (typically Display and Body). Derive additional styles (labels, buttons, captions, overlines) from these anchors. When returning type systems to the user, always ue the typography block format so it displays nicely:
 
 ```
 fonts:

package/package.json

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