@mindstudio-ai/remy 0.1.50 → 0.1.52

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

@@ -406,6 +406,8 @@ ${isLspConfigured() ? `<typescript_lsp>
 
 {{static/instructions.md}}
 
+<!-- cache_breakpoint -->
+
 <project_onboarding>
 New projects progress through four onboarding states. The user might skip this entirely and jump straight into working on the existing scaffold (which defaults to onboardingFinished), but ideally new projects move through each phase:
 
@@ -2768,6 +2770,8 @@ function getBrowserAutomationPrompt() {
     const appSpec = fs13.readFileSync("src/app.md", "utf-8").trim();
     return `${BASE_PROMPT}
 
+<!-- cache_breakpoint -->
+
 <app_context>
 ${appSpec}
 </app_context>`;
@@ -3570,6 +3574,7 @@ function getDesignExpertPrompt() {
     "{{font_library}}",
     getFontLibrarySample()
   ).replace("{{visual_design_references}}", getDesignReferencesSample()).replace("{{ui_case_studies}}", getUiInspirationSample());
+  prompt += "\n\n<!-- cache_breakpoint -->";
   if (specContext) {
     prompt += `
 
@@ -3873,6 +3878,7 @@ function getProductVisionPrompt() {
   const specContext = loadSpecContext();
   const roadmapContext = loadRoadmapContext();
   const parts = [BASE_PROMPT2, loadPlatformBrief()];
+  parts.push("<!-- cache_breakpoint -->");
   if (specContext) {
     parts.push(specContext);
   }
@@ -4050,6 +4056,7 @@ var codeSanityCheckTool = {
     }
     const specContext = loadSpecContext();
     const parts = [BASE_PROMPT3, loadPlatformBrief()];
+    parts.push("<!-- cache_breakpoint -->");
     if (specContext) {
       parts.push(specContext);
     }
@@ -5280,7 +5287,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

@@ -2770,6 +2770,8 @@ function getBrowserAutomationPrompt() {
     const appSpec = fs11.readFileSync("src/app.md", "utf-8").trim();
     return `${BASE_PROMPT}
 
+<!-- cache_breakpoint -->
+
 <app_context>
 ${appSpec}
 </app_context>`;
@@ -3685,6 +3687,7 @@ function getDesignExpertPrompt() {
     "{{font_library}}",
     getFontLibrarySample()
   ).replace("{{visual_design_references}}", getDesignReferencesSample()).replace("{{ui_case_studies}}", getUiInspirationSample());
+  prompt += "\n\n<!-- cache_breakpoint -->";
   if (specContext) {
     prompt += `
 
@@ -4031,6 +4034,7 @@ function getProductVisionPrompt() {
   const specContext = loadSpecContext();
   const roadmapContext = loadRoadmapContext();
   const parts = [BASE_PROMPT2, loadPlatformBrief()];
+  parts.push("<!-- cache_breakpoint -->");
   if (specContext) {
     parts.push(specContext);
   }
@@ -4243,6 +4247,7 @@ var init_codeSanityCheck = __esm({
         }
         const specContext = loadSpecContext();
         const parts = [BASE_PROMPT3, loadPlatformBrief()];
+        parts.push("<!-- cache_breakpoint -->");
         if (specContext) {
           parts.push(specContext);
         }
@@ -5371,6 +5376,8 @@ ${isLspConfigured() ? `<typescript_lsp>
 
 {{static/instructions.md}}
 
+<!-- cache_breakpoint -->
+
 <project_onboarding>
 New projects progress through four onboarding states. The user might skip this entirely and jump straight into working on the existing scaffold (which defaults to onboardingFinished), but ideally new projects move through each phase:
 
@@ -5876,7 +5883,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/static/authoring.md

@@ -19,7 +19,7 @@ The scaffold starts with these spec files that cover the full picture of the app
 - **`src/interfaces/@brand/voice.md`** — voice and terminology: tone, error messages, word choices
 - **`src/roadmap/`** — feature roadmap. One file per feature (`type: roadmap`). See "Roadmap" below.
 
-Start from these and extend as needed. Add interface specs for other interface types (`api.md`, `cron.md`, `agent.md`, etc.) if the app uses them. Split `app.md` into multiple files if the domain is complex. The agent uses the entire `src/` folder as compilation context, so organize however serves clarity.
+These are starting points, not constraints. Create as many spec files as the project needs — the `src/` folder is your workspace and every `.md` file in it becomes compilation context. If the app has substantial content (presentation slides, copy, lesson plans, menu items, quiz questions), put it in its own file (`src/content.md`, `src/slides.md`, `src/menu.md`, etc.) rather than cramming it into `app.md` or `web.md`. If the domain is complex, split `app.md` into multiple files by area (`src/billing.md`, `src/approvals.md`). Add interface specs for other interface types (`api.md`, `cron.md`, `agent.md`, etc.) if the app uses them. Organize however serves clarity — the platform reads the entire `src/` folder.
 
 Users often care about look and feel as much as (or more than) underlying data structures. Don't treat the brand and interface specs as an afterthought — for many users, the visual identity and voice are the first things they want to get right.
 

package/dist/prompt/static/team.md

@@ -16,6 +16,8 @@ The designer will return concrete resources: hex values, font names with CSS URL
 
 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.
 
+Remember, the design agent starts from scratch each time - it has no history of previous messages you have sent it - so you need to make sure to provide all relevant context, including full context from its previous messages where it is relevant (e.g., "You proposed three different options [describe them in detail].... and the user has descided on XYZ...").
+
 Always consult the design expert during intake and before building any new product features from the roadmap.
 
 ### Product Vision (`productVision`)
@@ -38,7 +40,7 @@ Always consult the code sanity check before writing code in initialCodegen with
 
 ### QA (`runAutomatedBrowserTest`)
 
-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. The user is able to watch QA work on their screen via a live browser preview - the cursor will move, type, etc - so you can also use this to demo functionality to the user and help them understand how to use their app.
+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. The user is able to watch QA work on their screen via a live browser preview - the cursor will move, type, etc - so you can also use this to demo functionality to the user and help them understand how to use their app. Don't tell the QA agent what values it should use for testing, it will figure that out on its own.
 
 ### Background Execution
 

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

@@ -7,7 +7,7 @@ There are two categories of animation and you should think of them separately:
 - Design animations: think beautiful layout reveals, dramatic loading and success states for user onboarding, beautiful scroll-driven animations on a landing page. These are the place to show off - and if you're showing off you better get it right. Anything that looks dated or janky will be disappointing to the user. Done correctly, these animations are powerful and transformative - and when the design calls for it, you should take a risk and suggest something big, bold, and creative. Remember, the user can always modify or change things later. It's better to dream big and walk it back than to deliver something generic or bland.
 
 ### Patterns to Use
-- CSS scroll-driven animations (`animation-timeline: scroll()` / `view()`) — native, off main thread, even though there is still a little lag in browser support we should always be using this when we need scroll-driven animations. Scroll driven animations that animate based on scrollport are very slick and look beautiful in landing pages. Think about how you can use them.
+- CSS scroll-driven animations (`animation-timeline: view()`) (aka "scrollytelling"). Scroll driven animations that animate based on scrollport are very slick and look beautiful in landing pages. Think about how you can use them.
 - Spring physics for natural-feeling motion
 - Purposeful micro-interactions — scaling, color shifts, depth changes on hover/click
 - Entrance reveals — content animating when it enters the view - can be powerful, but can very easily feel cheap if it is just sections of a page animating in on scroll, for example. Be very thoughtful and intentional when animating in this way.

package/package.json

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