@mindstudio-ai/remy 0.1.46 → 0.1.48

package/dist/prompt/compiled/design.md

@@ -82,7 +82,7 @@ The UI should feel instant. Never make the user wait for a server round-trip to
 
 ## FTUE
 
-All interactive apps must be intuitive and easy to use. Form elements must be well-labelled. Complex interfaces should have descriptions or tooltips when helpful. Complex apps benefit from a beautiful simple onboarding modal on first use or a simple click tour. Even if the app is intuitive and easy to use, users showing up for the first time might still be overwhelmed or confused, and we have an opportunity to set expectations, provide context, and make the user confident as they use our product. Don't neglect this.
+All interactive apps must be intuitive and easy to use. Form elements must be well-labelled. Complex interfaces should have descriptions or tooltips when helpful. Complex apps benefit from a beautiful simple onboarding modal on first use or a simple click tour. Mobile apps need a beautiful welcome screen sequence that orients the user to the app. Ask the visualDesignExpert for advice here. Even if the app is intuitive and easy to use, users showing up for the first time might still be overwhelmed or confused, and we have an opportunity to set expectations, provide context, and make the user confident as they use our product. Don't neglect this.
 
 ## What to Actively Avoid At All Costs
 

package/dist/prompt/compiled/scenarios.md

@@ -101,3 +101,7 @@ When a scenario runs, the platform:
 3. **Impersonates** the roles from the scenario's `roles` field (the app renders from that user's perspective)
 
 This is deterministic — same scenario always produces the same state.
+
+## Scenario Images
+
+When scenarios seed data that includes image URLs (profile photos, product images, cover art, etc.), ask the `visualDesignExpert` to generate a small batch of images that fit the app's aesthetic before writing the scenario code. A handful of bespoke photos make scenarios feel dramatically more real than placeholder services. Use the CDN URLs directly in your `db.push()` calls.

package/dist/prompt/compiled/tables.md

@@ -47,6 +47,16 @@ export const Users = db.defineTable<User>('users', {
 | `object` / `array` / JSON types | TEXT | Stored as JSON string, parsed on read |
 | `User` (branded type) | TEXT | User ID with `@@user@@` prefix (transparent — your code works with clean UUIDs) |
 
+### When to Use JSON Columns vs Separate Tables
+
+Every table operation is a network round-trip — not a local SQLite query. There are no JOINs. Fetching related data across tables means multiple sequential or batched HTTP calls. Design your schema around how data is accessed, not traditional normalization rules. Remember that databases in these apps are usually quite small - often single or a handful of users - we need to optimize for speed, not normalization.
+
+**Use a JSON column** when the data is always read and written with its parent. A product with a list of variant options, a form submission with its answers etc — these are single units that load together and save together. One row, one round-trip.
+
+**Use a separate table** when you need to query the child data independently, when the child set could grow unbounded, or when children are updated individually without touching the parent.
+
+Most 1:1 and 1:few relationships belong in JSON columns. Separate tables are for genuinely independent entities that happen to reference each other.
+
 ### System Columns
 
 Every table automatically has these columns. The SDK adds them to the TypeScript return type automatically — you can access them on any row returned from `get()`, `filter()`, `push()`, etc. without declaring them in your interface. They're also stripped from write inputs, so you never pass them to `push()` or `update()`.

package/dist/prompt/static/team.md

@@ -42,7 +42,7 @@ For verifying complex stateful interactions: multi-step form submissions, auth f
 
 ### Background Execution
 
-Some tools support `background: true`, which sends the task to the agent and returns immediately without blocking. The agent works independently and reports back when finished. When you dispatch a tool in background mode, the result you receive is just an acknowledgment — not the agent's actual work. The real results arrive later as an automated message:
+Some tools support `background: true`, which sends the task to the agent and returns immediately without blocking. You can only use this in a few specific cases, defined in the section below. When you use the background option, the agent works independently and reports back when finished. When you dispatch a tool in background mode, the result you receive is just an acknowledgment — not the agent's actual work. The real results arrive later as an automated message:
 
 ```xml
 <background_results>
@@ -57,7 +57,7 @@ When you receive background results:
 - Incorporate them into your current work if applicable
 - Don't interrupt the user's flow with a lengthy summary — they can see the background work in the UI
 
-#### When to Background
+#### When You Are Allowed to Background
 
 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. This task takes a while and we can allow the user to continue building while it happens in the background

package/package.json

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