@mindstudio-ai/remy 0.1.49 → 0.1.51

package/dist/automatedActions/buildFromInitialSpec.md

@@ -0,0 +1,19 @@
+---
+  trigger: buildFromInitialSpec
+---
+
+This is an automated action triggered by the user pressing "Build" in the editor after reviewing the spec.
+
+The user has reviewed the spec and is ready to build. 
+
+Think about your approach and then get a quick sanity check from `codeSanityCheck` to make sure you aren't missing anything.
+
+Then, build everything in one turn: methods, tables, interfaces, manifest updates, and scenarios, using the spec as the master plan.
+
+When code generation is complete, verify your work: 
+- First, run use `runScenario` to seed test data, then use `runMethod` to confirm a method works 
+- If the app has a web frontend, check the browser logs to make sure there are no errors rendering it.
+- Ask the `visualDesignExpert` to take a screenshot and verity that the visual design looks correct. Fix any issues it flags - we want the user's first time seeing the finished product to truly wow them.
+- Finally, use `runAutomatedBrowserTest` to smoke-test the main UI flow. The dev database is a disposable snapshot, so don't worry about being destructive. Fix any errors before finishing.
+
+When everything is working, use `productVision` to mark the MVP roadmap item as done, then call `setProjectOnboardingState({ state: "onboardingFinished" })`.

package/dist/automatedActions/buildFromRoadmap.md

@@ -0,0 +1,15 @@
+---
+  trigger: buildFromRoadmap
+---
+
+This is an automated action triggered by the user pressing "Build Now" on the roadmap item {{path}}
+
+First, review the specific item and think about how it fits with the existing spec and the existing codebase.
+
+Then, ask the user clarifying questions about anything that is ambiguous or requires additional input. Consult the team for any design work, architecture review, or SDK guidance - even if they're just quick questions (that's what the team is there for - they want to help and feel valuable!).
+
+Then, put together a plan to build out the feature. Present the plan to the user for their approval.
+
+When they've approved the plan, be sure to update the spec first - remember, the spec is the source of truth about the product. Then, build everything in one turn, using the spec as the master plan.
+
+When you're finished, verify your work, then tell`productVision` what was done so it can update the roadmap to reflect the progress. Give the user a summary of what was done.

package/dist/automatedActions/publish.md

@@ -0,0 +1,16 @@
+---
+  trigger: publish
+---
+
+This is an automated action triggered by the user pressing "Publish" in the editor.
+
+The user wants to deploy their app. Pushing to the `main` branch triggers a production deploy.
+
+Review the current state of the working tree — what has changed since the last commit, what's been committed since the last push, and the overall shape of recent work. Write a user-friendly changelog with `presentPublishPlan` — summarize what changed in plain language ("added vendor approval workflow", "fixed invoice totals", "updated the dashboard layout"). Reference specific code or file paths only when it helps clarity. This is what the user will see before deploying.
+
+If approved:
+- Stage and commit any uncommitted changes with a clean, descriptive commit message
+- Push to main
+- Let the user know their app is deploying
+
+If dismissed, acknowledge and do nothing.

package/dist/automatedActions/reviseFromAnnotatedImage.md

@@ -0,0 +1,5 @@
+---
+  trigger: reviseFromAnnotatedImage
+---
+
+This is an automated message trigger by the user submitting a screenshot of the app that they have annotated with text notes. Please analyze the provided image and make the requested revisions to the web frontend.

package/dist/automatedActions/sync.md

@@ -0,0 +1,23 @@
+---
+  trigger: sync
+---
+
+This is an automated action triggered by the user pressing "Sync" in the editor.
+
+The user has manually edited files since the last sync. The `refs/sync-point` git ref marks the last known-good sync state. It's created using a temporary git index that captures the full working tree (including unstaged changes) as a tree object — so it represents exactly what the files looked like at sync time, not just what was committed.
+
+To see what the user changed, run: `git diff refs/sync-point -- src/ dist/`
+
+This compares the sync-point tree against the current working tree. Do not add `HEAD` or any other ref — the command as written diffs directly against the working tree, which is what you want.
+
+In the diff output: lines prefixed with `-` are what was in the file at last sync. Lines prefixed with `+` are the user's current edits. Sync should bring the other side in line with the `+` side.
+
+Analyze the changes and write a sync plan with `presentSyncPlan` — a clear markdown summary of what changed and what you intend to update. Write it for a human: describe changes in plain language ("renamed the greeting field", "added a note about error handling"), not as a list of file paths and code diffs. Reference specific code or file paths only when it helps clarity. The user will review and approve before you make changes.
+
+If approved:
+- If spec files (`src/`) changed, update the corresponding code in `dist/` to match
+- If code files (`dist/`) changed, update the corresponding spec in `src/` to match
+- If both changed, reconcile — spec is the source of truth for intent, but respect code changes that add implementation detail
+- When all files are synced, call `clearSyncStatus`
+
+If dismissed, acknowledge and do nothing.

package/dist/headless.js

@@ -1393,7 +1393,7 @@ function runCli(cmd, options) {
 var askMindStudioSdkTool = {
   definition: {
     name: "askMindStudioSdk",
-    description: "MindStudio SDK expert. Knows every action, model, connector, and configuration option. Returns architectural guidance and working code. Describe what you want to build, not just what API method you need. Batch related questions into a single query.",
+    description: "@mindstudio-ai/agent SDK expert. Knows every action, model, connector, and configuration option. Returns architectural guidance and working code. Describe what you want to build, not just what API method you need. Batch related questions into a single query.",
     inputSchema: {
       type: "object",
       properties: {
@@ -5280,7 +5280,17 @@ ${xmlParts}
       );
     }
     let userMessage = parsed.text ?? "";
-    const resolved = resolveAction(userMessage);
+    let resolved = null;
+    try {
+      resolved = resolveAction(userMessage);
+    } catch (err) {
+      emit(
+        "completed",
+        { success: false, error: err.message || "Failed to resolve action" },
+        requestId
+      );
+      return;
+    }
     if (resolved !== null) {
       userMessage = resolved;
     }

package/dist/index.js

@@ -1146,7 +1146,7 @@ var init_sdkConsultant = __esm({
     askMindStudioSdkTool = {
       definition: {
         name: "askMindStudioSdk",
-        description: "MindStudio SDK expert. Knows every action, model, connector, and configuration option. Returns architectural guidance and working code. Describe what you want to build, not just what API method you need. Batch related questions into a single query.",
+        description: "@mindstudio-ai/agent SDK expert. Knows every action, model, connector, and configuration option. Returns architectural guidance and working code. Describe what you want to build, not just what API method you need. Batch related questions into a single query.",
         inputSchema: {
           type: "object",
           properties: {
@@ -5876,7 +5876,17 @@ ${xmlParts}
       );
     }
     let userMessage = parsed.text ?? "";
-    const resolved = resolveAction(userMessage);
+    let resolved = null;
+    try {
+      resolved = resolveAction(userMessage);
+    } catch (err) {
+      emit(
+        "completed",
+        { success: false, error: err.message || "Failed to resolve action" },
+        requestId
+      );
+      return;
+    }
     if (resolved !== null) {
       userMessage = resolved;
     }

package/dist/prompt/compiled/scenarios.md

@@ -102,6 +102,10 @@ When a scenario runs, the platform:
 
 This is deterministic — same scenario always produces the same state.
 
-## Scenario Images
+## Scenario Data
+
+Align scenario data to the vibe of the app - construct data that feels like it fits.
+
+### 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/static/team.md

@@ -20,7 +20,7 @@ Always consult the design expert during intake and before building any new produ
 
 ### Product Vision (`productVision`)
 
-Your product thinking partner. Owns the roadmap in `src/roadmap/`, but also the right tool any time the conversation is about what to build rather than how to build it. Roadmap operations (seeding ideas, marking items done, adding/removing features), but also strategic questions about the product's direction, what's missing, what would make it more compelling. It reads spec and roadmap files automatically. Describe the situation and let it decide what to do.
+Your product thinking partner. Owns the roadmap in `src/roadmap/`, but also the right tool any time the conversation is about what to build rather than how to build it. Roadmap operations (seeding ideas, marking items done, adding/removing features), but also strategic questions about the product's direction, what's missing, what would make it more compelling. It reads spec and roadmap files automatically. Describe the situation and let it decide what to do. Notify `projectVision` after building new features, adding new interfaces, or other large refactors, so it can keep the roadmap up to date in the background.
 
 ### Mindstudio SDK Consultant (`askMindStudioSdk`)
 
@@ -60,7 +60,7 @@ When you receive background results:
 #### 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.
+- `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 "iphone app store" style icon for the app, then set it with `setProjectMetadata({ iconUrl: ... })`
 
 Do not background any other tasks.

package/package.json

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