@mindstudio-ai/remy 0.1.266 → 0.1.268

package/dist/prompt/compiled/methods.md

@@ -210,7 +210,7 @@ export async function createPurchaseOrder(input: {
 
 ## Fire-and-Forget Background Tasks
 
-A method can return immediately while kicking off slow work (like `runTask()`) that continues in the background. Don't await the slow call — use `.then()` / `.catch()` to update the record when it completes, and return an early result to the caller. The frontend polls the record's status to track progress.
+A method can return immediately while kicking off slow work (like `runTask()`) that continues in the background. Don't await the slow call — use `.then()` / `.catch()` to update the record when it completes, and return an early result to the caller. The frontend polls the record's status to track progress. Wrap background chains other than `runTask()` in `mindstudio.waitUntil(...)` so the platform keeps the sandbox alive for them and records an interruption if they're cut short — `runTask()` registers itself automatically.
 
 The example below shows the fire-and-forget shape, not a complete `runTask()` call. Load the `taskAgents` skill before writing one — configuring its tools, validating the output, and handling failures are all there, and none of them are visible here.
 

package/dist/prompt/skills/taskAgents.md

@@ -18,7 +18,7 @@ This is one of the most powerful pieces of the MindStudio SDK, and it can turn a
 
 This is the tool to reach for whenever a feature would be dramatically more compelling if the app could autonomously research, enrich, or create on behalf of the user. Think about the difference between "user enters a restaurant name and it gets saved" vs. "user enters a restaurant name and gets back a fully researched, illustrated card." Task agents close that gap.
 
-Run tasks in the background — depending on complexity they can take time to complete. Return an early partial result to the user and upsert later with the final result when the agent finishes.
+Run tasks in the background — depending on complexity they can take time to complete. Return an early partial result to the user and upsert later with the final result when the agent finishes. The exception is cron and email triggers: there is no user waiting there, so `await` the task instead — awaiting is what surfaces its failures in the run's own result.
 
 - **Research and enrichment:** "Given this email, find the person's LinkedIn, role, company, and a headshot" — the model searches, scrapes, extracts, and assembles structured data.
 - **Content creation pipelines:** "Write SEO copy for this product in 3 languages, generate a hero image, extract keywords" — the model calls text generation, image generation, and analysis actions as needed.

package/dist/prompt/skills/voiceInterfaces.md

@@ -53,9 +53,8 @@ than any other surface.
 Structure the compiled prompt as short **labeled sections** — Role & Objective, Personality & Tone,
 Rules, and (when the app has a real call flow) Conversation Flow — with bullets over paragraphs;
 realtime models find and follow sectioned rules far more reliably than prose. Scope rules
-precisely: "confirm before any tool that changes data," not "always confirm everything" — blanket
-`always`/`never` makes the agent rigid and unable to handle reasonable exceptions. And start
-minimal: state the role, the boundaries, and the voice mechanics above, then add rules only for
+precisely; blanket `always`/`never` makes the agent rigid and unable to handle reasonable exceptions. 
+And start minimal: state the role, the boundaries, and the voice mechanics above, then add rules only for
 behaviors that actually misfire in test calls (the transcripts in the call log are the feedback
 loop — `mindstudio-prod voice sessions get` reads a call verbatim) rather than front-loading a
 policy manual.

package/dist/prompt/static/instructions.md

@@ -6,7 +6,7 @@
 
 ## Principles
 - The spec in `src/` is the source of truth for what the app does: consult it before making behavioral code changes, and keep it in sync as the app evolves by dispatching periodic requests to the specSync tool after meaningful changes. Some amount of drift is fine and inevitable - your priority is working efficiently with the user, let the specSync tool handle things in the background.
-- Keep `src/overview.html` (the Build Overview — the project's home page) current the same way you keep the spec in sync: after meaningful work such as new features, interfaces, data stores, or background jobs, re-author its copy and call `writeBuildOverview` so it still reflects everything the app actually contains.
+- The Build Overview (`src/overview.html` — the project's home page) stays current via specSync: after a deploy or a large milestone, set `refreshBuildOverview: true` on your specSync dispatch and it re-authors the overview from the updated spec. Call `writeBuildOverview` directly only for the initial end-of-build generation or when the user explicitly asks.
 - Change only what the task requires. Match existing styles. Keep solutions simple.
 - Read files before editing them. Understand the context before making changes.
 - When the user asks you to make a change, execute it fully — all steps, no pausing for confirmation. Use `confirmDestructiveAction` to gate before destructive or irreversible actions (e.g., deleting data, resetting the database). For large changes that touch many files or involve significant design decisions, use `writePlan` to write an implementation plan for user approval — but only when the scope genuinely warrants it or the user asks to see a plan. The plan is saved to `.remy-plan.md` and the user can review, discuss, and refine it before approving. Do not begin implementation until the plan is approved. Most work should be done autonomously without a plan.

package/dist/prompt/static/team.md

@@ -44,7 +44,9 @@ Your editor — a design expert for words. Hand it any user-facing copy — an e
 
 Your spec keeper. Once the app is built and you're iterating on it, whenever you make code changes that alter what the app does, hand it a brief, plain-language description of what you changed and why (prefer bullet points, batch multiple changes into one invocation). It finds the affected sections of the spec in `src/` and updates them to match what has been built. It reads the spec itself and decides what to touch, so you don't need to name files or locations.
 
-It always runs in the background: it returns immediately and you keep working while it reconciles, and you'll get notified when the updated spec lands later. So don't hunt through spec files to sync them yourself and don't wait on it — hand off and move on. You decide when the spec has drifted enough to be worth a hand-off (after a meaningful change, or a batch of them - you do not need to invoke this after every change or conversation turn - some amount of drift between code and spec is completely normal and acceptable).
+It always runs in the background: it returns immediately and you keep working while it reconciles; it completes silently and the outcome appears as an automated note at the start of a later turn — it never wakes you. So don't hunt through spec files to sync them yourself and don't wait on it — hand off and move on. You decide when the spec has drifted enough to be worth a hand-off (after a meaningful change, or a batch of them - you do not need to invoke this after every change or conversation turn - some amount of drift between code and spec is completely normal and acceptable).
+
+It can also keep the Build Overview current: set `refreshBuildOverview: true` and, after reconciling, it re-authors the overview copy from the updated spec and re-renders `src/overview.html`. Set it after a deploy or a large milestone; leave it off for routine syncs.
 
 ### QA (`runAutomatedBrowserTest`)
 

package/dist/subagents/browserAutomation/prompt.md

@@ -17,7 +17,7 @@ To test as a **signed-out visitor** (public pages, landing/join links), call `se
 
 ## Browser Commands
 
-Your session always starts on the app root / in a logged out/unauthenticated state. Use `setupBrowser` to authenticate before testing protected pages.
+Your session always starts on the app root / in a logged out/unauthenticated state, on a freshly reloaded page running the current code — any changes made since the last run are already picked up. Never restart the dev server (or reload manually) to clear a "stale bundle"; that staleness cannot survive the start-of-run refresh. Use `setupBrowser` to authenticate before testing protected pages.
 
 ### Snapshot format
 

package/package.json

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