@mindstudio-ai/remy 0.1.294 → 0.1.295

package/dist/automatedActions/reviseFromAnnotatedImage.md

@@ -2,4 +2,6 @@
   trigger: reviseFromAnnotatedImage
 ---
 
-This is an automated message triggered 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 interface.
+This is an automated message triggered by the user annotating a screenshot of the app with revision notes. The attached image is a capture of the app's UI with the user's annotations drawn on top: pink (#DD2590) markers — a small pin dot or a dashed rectangle outlining an area — each with a pink speech bubble containing the note text in white. The image may be a vertical crop of a scrolled page, not necessarily the top of it.
+
+The message params include a `notes` array with each annotation's exact text and position (pixel coordinates in the attached image; pins have `x`/`y`, areas add `w`/`h`). Treat the `notes` params as the authoritative note text and use the image to see what each note points at. Make the requested revisions to the web interface.

package/dist/headless.js

@@ -1392,7 +1392,7 @@ async function listRecursive(dir) {
 var presentPublishPlanTool = {
   definition: {
     name: "presentPublishPlan",
-    description: "Present a publish changelog to the user for approval \u2014 the consent gate of the release flow, used when the user has asked to publish (the Publish button or an explicit chat request; the `publishing` skill covers the full sequence). Write a clear markdown summary of what changed since the last deploy. The user will see this in a full-screen view and can approve or dismiss. Call this BEFORE committing or pushing.",
+    description: "Present a publish changelog to the user for approval \u2014 the consent gate of the release flow, used when the user has asked to publish (the Publish button or an explicit chat request; the `publishing` skill covers the full sequence). Write a clear markdown summary of what changed since the last deploy. The user reviews this in the editor area and can approve or dismiss. Call this BEFORE committing or pushing.",
     inputSchema: {
       type: "object",
       properties: {
@@ -1527,7 +1527,7 @@ var markBuildCompleteTool = {
 var promptUserTool = {
   definition: {
     name: "promptUser",
-    description: 'Ask the user structured questions. Choose type first: "form" for structured intake (5+ questions, takes over screen), "inline" for quick clarifications or confirmations. Blocks until the user responds. Result contains `_dismissed: true` if the user dismisses without answering.',
+    description: 'Ask the user structured questions. Choose type first: "form" for structured intake (5+ questions, opens as a full form in the editor area), "inline" for quick clarifications or confirmations. Blocks until the user responds. Result contains `_dismissed: true` if the user dismisses without answering.',
     inputSchema: {
       type: "object",
       properties: {

package/dist/index.js

@@ -872,7 +872,7 @@ var init_presentPublishPlan = __esm({
     presentPublishPlanTool = {
       definition: {
         name: "presentPublishPlan",
-        description: "Present a publish changelog to the user for approval \u2014 the consent gate of the release flow, used when the user has asked to publish (the Publish button or an explicit chat request; the `publishing` skill covers the full sequence). Write a clear markdown summary of what changed since the last deploy. The user will see this in a full-screen view and can approve or dismiss. Call this BEFORE committing or pushing.",
+        description: "Present a publish changelog to the user for approval \u2014 the consent gate of the release flow, used when the user has asked to publish (the Publish button or an explicit chat request; the `publishing` skill covers the full sequence). Write a clear markdown summary of what changed since the last deploy. The user reviews this in the editor area and can approve or dismiss. Call this BEFORE committing or pushing.",
         inputSchema: {
           type: "object",
           properties: {
@@ -1039,7 +1039,7 @@ var init_promptUser = __esm({
     promptUserTool = {
       definition: {
         name: "promptUser",
-        description: 'Ask the user structured questions. Choose type first: "form" for structured intake (5+ questions, takes over screen), "inline" for quick clarifications or confirmations. Blocks until the user responds. Result contains `_dismissed: true` if the user dismisses without answering.',
+        description: 'Ask the user structured questions. Choose type first: "form" for structured intake (5+ questions, opens as a full form in the editor area), "inline" for quick clarifications or confirmations. Blocks until the user responds. Result contains `_dismissed: true` if the user dismisses without answering.',
         inputSchema: {
           type: "object",
           properties: {

package/dist/prompt/compiled/sdk-actions.md

@@ -153,4 +153,4 @@ Consider the ways in which AI can be incorporated into backend methods to solve
 
 ### Task Agents
 
-For multi-step tasks where the model needs to autonomously compose actions (research + scrape + generate, enrichment pipelines, content creation), use `runTask()` instead of chaining actions manually. It runs an agent loop and returns structured JSON. Its tools can include SDK actions as well as your app's own methods, so the agent can read your data to decide what to do next and write results back itself. Load the `taskAgents` skill before writing one — it is the full reference.
+For multi-step tasks where the model needs to autonomously compose actions (research + scrape + generate, enrichment pipelines, content creation), use `runTask()` instead of chaining actions manually. It runs an agent loop and returns structured JSON. Its tools can include SDK actions, your app's own methods, and inline functions defined at the call site, so the agent can read your data to decide what to do next and write results back itself. Load the `taskAgents` skill before writing one — it is the full reference.

package/dist/prompt/skills/taskAgents.md

@@ -1,6 +1,6 @@
 ---
 name: Task Agents
-what: A full autonomous agent loop callable from any method. Give it a prompt, a set of tools, and a JSON Schema for the output shape; the platform runs the model until it produces validated output matching that schema — searching, scraping, generating images, retrying approaches that failed, and calling your app's own methods to read and write data as it goes. Tools can be any of the 1000+ SDK actions and your own methods in any combination, which is what makes it part of the app rather than a detached research bot. This is the difference between a feature that saves what the user typed and one that researches, enriches, and creates on their behalf, and it is one of the most powerful things the platform can do. Consider it whenever a feature would be dramatically more compelling if the app could do real work autonomously.
+what: A full autonomous agent loop callable from any method. Give it a prompt, a set of tools, and a JSON Schema for the output shape; the platform runs the model until it produces validated output matching that schema — searching, scraping, generating images, retrying approaches that failed, and calling your app's own methods to read and write data as it goes. Tools can be any of the 1000+ SDK actions, your own methods, and inline functions defined at the call site, in any combination, which is what makes it part of the app rather than a detached research bot. This is the difference between a feature that saves what the user typed and one that researches, enriches, and creates on their behalf, and it is one of the most powerful things the platform can do. Consider it whenever a feature would be dramatically more compelling if the app could do real work autonomously.
 when: Before writing any `mindstudio.runTask()` call — background enrichment, research-and-generate, anything where the model decides its own next step.
 ---
 
@@ -10,7 +10,7 @@ A user types the name of a restaurant into your app, or uploads a photo of a sto
 
 `runTask()` makes this possible. It runs a multi-step, tool-use agent loop: give it a prompt, a set of tools, and a JSON Schema for the structured output you want (`outputSchema`). The platform runs the loop (calling the model, executing tool calls, feeding results back) until the model produces JSON conforming to your schema — validated every turn, with automatic repair when it doesn't. `result.output` is typed by inference from the schema: no generic argument, no manual validation. The model decides what to do next based on intermediate results — retrying searches with different terms, working around failed tools, batching independent calls in parallel.
 
-Tools are **SDK actions** (`searchGoogle`, `generateImage`, …) and **your own app's methods** (`{ appMethod: 'save-vendor' }`), in any combination. That second half is what makes a task agent part of your app rather than a detached research bot: it can read your tables to decide what to do next, and write results back itself instead of handing them to you to persist.
+Tools are **SDK actions** (`searchGoogle`, `generateImage`, …), **your own app's methods** (`{ appMethod: 'save-vendor' }`), and **inline functions** (`{ name, description, inputSchema, execute }` — a function defined right in the calling method), in any combination. The latter two are what make a task agent part of your app rather than a detached research bot: it can read your tables to decide what to do next, and write results back itself instead of handing them to you to persist.
 
 This is one of the most powerful pieces of the MindStudio SDK, and it can turn an app from amazing into truly magical. Use `askMindStudioSdk` to help construct the right agent for a task — including which model to give it.
 
@@ -129,6 +129,14 @@ tools: [
   // One of your app's own methods — note `appMethod`, not `method`
   { appMethod: 'listVendorsMissingContacts', description: 'Vendors with no email on file. Call this first to decide what needs researching.' },
   { appMethod: 'updateVendor', description: 'Write researched contact details back. One call per vendor.' },
+
+  // An inline function — runs right here in your process
+  {
+    name: 'checkDomainReputation',
+    description: 'Look up a domain in our internal blocklist. Call before trusting a scraped site.',
+    inputSchema: { type: 'object', properties: { domain: { type: 'string' } }, required: ['domain'] },
+    execute: async (input) => BlockedDomains.find(String(input.domain)),
+  },
 ]
 ```
 
@@ -151,6 +159,25 @@ Keep them short and task-specific. Say when to reach for it and when not to, sin
 - Method calls run in parallel with everything else in the turn, so don't expose two methods that would conflict if called simultaneously.
 - Cost from inside a method (its own model calls) doesn't appear in the task's `usage.totalBillingCost`. It's billed and attributed to that method, just not rolled into the task total.
 
+### Inline function tools
+
+`{ name, description, inputSchema, execute }` defines a tool right in the calling method — the function executes in your process when the model calls it. Use it for task-private glue that doesn't deserve to be an app method: a lookup against your tables framed exactly for this task, a computation, a check against data the task closed over. If the capability should exist in the app in its own right (invocable, authorized, visible in the manifest), make it a method and expose it with `appMethod` instead.
+
+```typescript
+{
+  name: 'checkExisting',
+  description: 'Look up whether we already track this vendor. Call before researching one.',
+  inputSchema: { type: 'object', properties: { name: { type: 'string' } }, required: ['name'] },
+  execute: async (input) => Vendors.findByName(String(input.name)),
+}
+```
+
+- The `description` is required — it is everything the model knows about the tool. `inputSchema` is optional; omitted means the tool takes no arguments.
+- A thrown error is fed back to the model as `{ error: message }` tool output to work around — it never fails the task. Throw informative errors, same as app methods.
+- No `defaults` — the function is your code; close over whatever it needs.
+- Names share the flat tool namespace: 1–64 chars of letters, digits, `_`, `-`, and no collisions with SDK action names.
+- Calling `runTask()` from inside a function tool is not blocked the way it is from a method tool — the depth cap doesn't apply, so unbounded recursion (and its cost) is yours to prevent. Nest deliberately or not at all.
+
 ## Voice & Tone in Prompts
 
 When a task agent produces user-facing text, the prompt must state the voice and tone it should write in. Specify the desired voice explicitly, and rule out emojis, em dashes, and other "ai-isms" — the output goes straight to the user, so nothing downstream will catch them.
@@ -161,7 +188,7 @@ When a task agent produces user-facing text, the prompt must state the voice and
 |-------|----------|---------|-------------|
 | `prompt` | Yes | — | System prompt defining the agent's behavior |
 | `input` | Yes | — | Structured input (passed as user message) |
-| `tools` | Yes | — | SDK action names and/or `{ appMethod, description }` entries, each with optional `defaults` |
+| `tools` | Yes | — | SDK action names, `{ appMethod, description }` entries (each with optional `defaults`), and/or inline `{ name, description, inputSchema, execute }` function tools |
 | `outputSchema` | One of these two | — | Plain JSON Schema for the output (`type`/`properties`/`required`/`enum`/`items`; nullable via type arrays, never `nullable: true`; no `oneOf`/`$ref`). Validated every turn with automatic repair; `result.output` typed from the schema. Use this |
 | `structuredOutputExample` | One of these two | — | Legacy: object or JSON string showing expected output shape, unvalidated. Use realistic example values, not placeholders like `'string'`, and always check `parsedSuccessfully` |
 | `model` | Yes | — | Model ID (must support tool use). Ask `askMindStudioSdk` for the right one — MindStudio's ids don't match vendor ids, so a plausible-looking guess is usually wrong |

package/dist/prompt/static/coding.md

@@ -29,7 +29,7 @@ Process logs are available at .logs/ in NDJSON format (one JSON object per line)
 ### MindStudio SDK
 For any work involving AI models, external actions (web scraping, email, SMS), or third-party API/OAuth connections, prefer the `@mindstudio-ai/agent` SDK. It removes the need to research API methods, configure keys and tokens, or require the user to set up developer accounts.
 
-For multi-step tasks with branching logic (research, enrichment, content pipelines), use `runTask()` instead of manually chaining SDK actions. It runs an autonomous agent loop that composes tools, retries on failure, and returns structured JSON. Tools are SDK actions and your own app methods — the agent can read app state to decide what to do next and persist results itself. See the task agents reference for details.
+For multi-step tasks with branching logic (research, enrichment, content pipelines), use `runTask()` instead of manually chaining SDK actions. It runs an autonomous agent loop that composes tools, retries on failure, and returns structured JSON. Tools are SDK actions, your own app methods, and inline functions defined at the call site — the agent can read app state to decide what to do next and persist results itself. See the task agents reference for details.
 
 For methods that take more than a few seconds, use `stream()` from `@mindstudio-ai/agent` to push real-time progress to the frontend. Pipe `onLog` from SDK actions through `stream()` so users see what's happening. The frontend calls the method with `stream: true` and gets updates via `onToken`. See the methods reference for the full pattern.
 

package/dist/prompt/static/instructions.md

@@ -28,6 +28,8 @@ The user can already see your tool calls, so most of your work is visible withou
 
 Skip the rest: narrating what you're about to do, restating what the user asked, explaining tool calls they can already see.
 
+You and the editor are two sides of one screen: chat on the left, editor area on the right — the live app preview, plans presented for approval, the file browser, the code editor. The user is looking at both. Don't describe the interface or where things sit on screen; refer to actions and let the UI speak for itself. "Approve the plan when you're ready," not "click approve on the plan to your right."
+
 ### User attachments
 When a user uploads a file (PDF, Word doc, image, etc.), it is automatically saved to `src/.user-uploads/` in the project directory. The message includes the local file path, and for documents with extractable text, a `.txt` sidecar with the extracted content you can read with `readFile`. A document marked "no extracted text — raw file only" has no sidecar: parse the raw file yourself, and if it is genuinely unreadable, tell the user what happened. Pass the file path itself to tools that take an image — `screenshot`, and the design expert's `analyzeImage` / `analyzeDesign` / `editImages` — and they host the file and hand back a URL you can reuse or embed in a spec. If a raw file from `src/` needs to be served by the web interface, copy it to `dist/interfaces/web/public/`. These files persist across the conversation — they survive compaction and session restarts. Do not ask the user to re-upload a document that has already been saved. Voice messages are not saved to disk — their transcripts appear inline in the message.
 

package/dist/subagents/codeSanityCheck/prompt.md

@@ -66,13 +66,13 @@ When a plan includes multiple screens/API calls, always note this item for the d
 
 - **Manual multi-step chains that should be `runTask()`.** If a method chains AI-driven work with branching logic (search, then scrape based on results, then generate based on what was scraped), that's a `runTask()` use case. `runTask()` runs an agent loop that autonomously calls tools and returns structured JSON. The developer writes a prompt and a JSON Schema for the output (`outputSchema`) instead of imperative code. Flag when you see methods with complex sequential/branching chains — especially research, enrichment, or content generation pipelines. Similarly, flag opportunities where the developer might not have realized they could get better and richer data via runTask - it's a really powerful lever for working with data (e.g., user provides some fragment and agent task goes off and enriches it) that the developer might not have remembered when planning their work.
 
-  Tools are SDK actions **and the app's own methods** (`{ appMethod: 'save-vendor', description: '...' }`), which widens this considerably. The pattern most worth looking for: work that needs to *read* app state to decide what to do next (fetch rows, loop, research each, update each) hand-rolled as a loop, when the agent could take a read method and a write method and exercise the judgment itself. App methods run as the invoking user with their roles, so authorization is unchanged.
+  Tools are SDK actions, **the app's own methods** (`{ appMethod: 'save-vendor', description: '...' }`), and **inline functions** (`{ name, description, inputSchema, execute }` — task-private glue that runs in the method's own process), which widens this considerably. The pattern most worth looking for: work that needs to *read* app state to decide what to do next (fetch rows, loop, research each, update each) hand-rolled as a loop, when the agent could take a read method and a write method and exercise the judgment itself. App methods run as the invoking user with their roles, so authorization is unchanged.
 
   Two things NOT to flag. A deterministic sequence that happens to touch several methods — if the order is known up front and no judgment is involved, imperative code is correct and cheaper. And the fire-and-forget background pattern, where a method kicks off `runTask()` and writes the result back in `.then()` with failures landing in `.catch()`: that write-back is doing status management the agent can't do for itself. That one is the recommended pattern, not a smell.
 
 - **Task agent tool descriptions missing or recycled.** When a plan exposes app methods to `runTask()`, each entry should carry an inline `description` written for *that* task — when to call it, when not to, what to do with the result. Falling back to the method's own description is allowed but usually too generic, and the description is the main thing determining whether the agent uses the tool correctly. Flag entries with no description, or the same description pasted across different tasks.
 
-- **A method exposed as a task tool that itself calls `runTask()`.** Task agents can't nest — the inner call is rejected at runtime. Flag it and suggest flattening the decomposition.
+- **A method exposed as a task tool that itself calls `runTask()`.** Task agents can't nest through method tools — the inner call is rejected at runtime. Flag it and suggest flattening the decomposition. An inline function tool calling `runTask()` is different: it is NOT blocked by the platform (no depth cap applies), so accidental recursion runs unbounded and burns credits per turn. Flag it unless the nesting is clearly deliberate and bounded.
 
 - **MindStudio SDK `runTask()` output used without validation — check which output option the call uses.** With `outputSchema` (the current, preferred form): the SDK validates every turn and throws `MindStudioError` `code === 'task_output_schema_mismatch'` instead of returning garbage, so using `result.output` directly is correct — flag only a missing `.catch()`/`try-catch` where the failure would otherwise vanish (fire-and-forget chains especially). With `structuredOutputExample` (legacy): `runTask()` can return successfully with garbage output (null fields, echoed input, raw text) — flag `result.output` used without checking `result.parsedSuccessfully` first, and suggest migrating to `outputSchema`. That unvalidated form is the #1 footgun with task agents.
 

package/package.json

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