@mindstudio-ai/remy 0.1.310 → 0.1.312

package/dist/headless.js

@@ -494,6 +494,7 @@ var ALLOWED_MODELS_BY_TYPE = {
     "claude-4-6-opus",
     "claude-4-6-sonnet",
     "claude-fable-5",
+    "claude-fable-5-1",
     "claude-5-sonnet",
     "gpt-5.5",
     "gpt-5.6-sol",
@@ -771,7 +772,7 @@ ${entries.join("\n\n")}
 // src/prompt/skills/_catalog.ts
 var INTRO = `Platform capabilities most apps don't use, so their references are kept out of this prompt rather than competing for your attention on every task \u2014 not because they're marginal.
 
-Read what follows as part of what the platform can do, not as a lookup table. Recognising that one of these fits a feature is your job, and proposing one is fair game \u2014 several of them are the difference between an app that works and an app worth showing off. When a trigger fires, load the reference with loadSkill before writing the code rather than after. Loading is cheap and expected; guessing at one of these APIs is not.
+Read what follows as part of what the platform can do, not as a lookup table. Recognising that one of these fits a feature is your job, and proposing one is fair game \u2014 several of them are the difference between an app that works and an app worth showing off. When a trigger fires, load the reference with loadSkill before writing the spec or code rather than after. Loading is cheap and expected; guessing at one of these APIs is not.
 
 A loaded reference drops out of the conversation once it ages out. Re-read it at the path listed with readFile whenever you need it again.`;
 var catalog = buildSkillCatalog({

package/dist/index.js

@@ -2249,6 +2249,7 @@ var init_surfaces = __esm({
         "claude-4-6-opus",
         "claude-4-6-sonnet",
         "claude-fable-5",
+        "claude-fable-5-1",
         "claude-5-sonnet",
         "gpt-5.5",
         "gpt-5.6-sol",
@@ -3163,7 +3164,7 @@ var init_catalog = __esm({
     init_assets();
     INTRO = `Platform capabilities most apps don't use, so their references are kept out of this prompt rather than competing for your attention on every task \u2014 not because they're marginal.
 
-Read what follows as part of what the platform can do, not as a lookup table. Recognising that one of these fits a feature is your job, and proposing one is fair game \u2014 several of them are the difference between an app that works and an app worth showing off. When a trigger fires, load the reference with loadSkill before writing the code rather than after. Loading is cheap and expected; guessing at one of these APIs is not.
+Read what follows as part of what the platform can do, not as a lookup table. Recognising that one of these fits a feature is your job, and proposing one is fair game \u2014 several of them are the difference between an app that works and an app worth showing off. When a trigger fires, load the reference with loadSkill before writing the spec or code rather than after. Loading is cheap and expected; guessing at one of these APIs is not.
 
 A loaded reference drops out of the conversation once it ages out. Re-read it at the path listed with readFile whenever you need it again.`;
     catalog = buildSkillCatalog({

package/dist/prompt/compiled/interfaces.md

@@ -224,7 +224,7 @@ The app projected as an MCP server for *external* AI agents to drive (Claude Des
 
 ## Agent (Conversational Interface)
 
-A conversational interface where the app's own LLM orchestrates its methods as tools — its own personality, system prompt, and model config (the inverse of MCP). Chat runs as the authenticated user, so every tool call carries that user's roles, and the config must declare an `auth` block (`{ "requireUser": boolean, "requireRole"?: string[] }`) gating who may chat at all. **Load the `agentInterfaces` skill** before authoring `src/interfaces/agent.md` or building the chat UI.
+A conversational interface where the app's own LLM orchestrates its methods as tools — its own personality, system prompt, and model config (the inverse of MCP). Chat runs as the authenticated user, so every tool call carries that user's roles, and the config must declare an `auth` block (`{ "requireUser": boolean, "requireRole"?: string[] }`) gating who may chat at all. When the app includes a conversational surface, this is the default way to build it — not a custom chat UI over per-turn method calls. **Load the `agentInterfaces` skill** when a conversational feature enters the plan, and before authoring `src/interfaces/agent.md` or building the chat UI.
 
 ## Voice (Realtime Conversation)
 

package/dist/prompt/skills/agentInterfaces.md

@@ -1,7 +1,7 @@
 ---
 name: Agent Interfaces
 what: Conversational AI as a first-class interface to the app — an LLM with authenticated, per-user access to the app's methods as tools, paired with a streaming chat UI. The platform handles auth, tool dispatch, threads, and streaming, so the work is authorship: who the agent is, which methods it can reach, and how each one is described to it. Any app whose methods do something interesting can be projected into a conversation this way, often as its most compelling surface. This reference covers the whole feature — writing the agent spec, compiling it, and building the chat frontend.
-when: Before authoring `src/interfaces/agent.md`, compiling `dist/interfaces/agent/`, or building an agent's chat UI.
+when: When a conversational surface — a chat, an assistant — is part of the plan or spec, load it before deciding how that feature is built: this is the default architecture for conversation. Also before authoring `src/interfaces/agent.md`, compiling `dist/interfaces/agent/`, or building an agent's chat UI.
 ---
 
 # Building Agent Interfaces

package/dist/prompt/skills/inboundEmail.md

@@ -1,7 +1,7 @@
 ---
 name: Inbound Email
 what: The app has its own email address, and mail sent to it runs a method. Every address on the app's subdomain routes to one handler, so `support@`, `receipts@` and `anything@` all arrive without registering anything — branch on the recipient in code. Attachments arrive as CDN URLs the platform has already uploaded, threading headers come through intact so replies land in the same conversation, and a verified custom domain both receives and sends under the app's own brand. "Forward a receipt and the app files it" is a real feature that costs one method.
-when: Before writing an email-handler method, adding an `email` interface, or promising anything about what happens when a user emails the app.
+when: The moment "email something to the app" would be a natural feature — load it before scoping that idea. Also before writing an email-handler method, adding an `email` interface, or promising anything about what happens when a user emails the app.
 ---
 
 # Inbound Email Interfaces

package/dist/prompt/skills/mcpInterfaces.md

@@ -1,7 +1,7 @@
 ---
 name: MCP Interfaces
 what: Ships the app as an MCP server, so external AI agents — Claude Desktop, Cursor, anyone's agent — can drive it as a tool surface. The platform hosts the server, handles auth, and derives every tool's input schema from the method contract, so there is no protocol code to write: the work is choosing which methods an outsider should see and describing them well enough for a stranger to use correctly. Cheap to add to an app that already has methods, and it puts the app inside the tools its users already work in.
-when: Before authoring `src/interfaces/mcp.md`, deciding which of the app's methods an external agent gets to see, or writing the MCP interface config.
+when: The moment the plan wants the app reachable from Claude, Cursor, ChatGPT, or a user's own agents — load it before proposing how. Also before authoring `src/interfaces/mcp.md`, deciding which of the app's methods an external agent gets to see, or writing the MCP interface config.
 ---
 
 # MCP Interfaces

package/dist/prompt/skills/restApi.md

@@ -1,7 +1,7 @@
 ---
 name: REST API
 what: A designed, documented REST surface over the app's methods — named routes, path and query params, resource groupings, and a generated OpenAPI spec. This is distinct from the method endpoints every app already has: those exist automatically and need nothing from you. This is for when the API itself is the product, or when something outside the app has to integrate against stable URLs rather than internal method names.
-when: Before authoring `src/interfaces/api.md` or adding an `api` interface with designed routes. Also load it when a method needs the raw HTTP request (headers, unparsed body).
+when: The moment the plan calls for a public or partner-facing API, or anything outside the app integrating against stable URLs — load it before designing that surface. Also before authoring `src/interfaces/api.md` or adding an `api` interface with designed routes, and when a method needs the raw HTTP request (headers, unparsed body).
 ---
 
 # REST API Interfaces

package/dist/prompt/skills/scenarios.md

@@ -128,6 +128,8 @@ Re-running it is free (documents are content-addressed), so it's safe to keep in
 
 Align scenario data to the vibe of the app - construct data that feels like it fits.
 
+For seeded email addresses, use `remy@mindstudio.ai` or `@example.com` addresses — the platform sinks mail to both, whereas an invented domain that resolves to a real mail server bounces and damages sending reputation when the app later emails its seeded users.
+
 ### 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/skills/scheduledJobs.md

@@ -1,7 +1,7 @@
 ---
 name: Scheduled Jobs
 what: Methods that run on a schedule, declared as cron expressions in an interface config and synced to the platform on deploy. Nothing to host and no scheduler to run — a job is a method plus a schedule line.
-when: Before adding a `cron` interface or writing a method meant to run on a timer.
+when: The moment anything should happen on a schedule — digests, syncs, reminders, cleanup — load it before designing that feature. Also before adding a `cron` interface or writing a method meant to run on a timer.
 ---
 
 # Cron Interfaces

package/dist/prompt/skills/voiceInterfaces.md

@@ -1,7 +1,7 @@
 ---
 name: Voice Interfaces
 what: Realtime voice conversation as a first-class interface — the user talks to the app and its voice agent talks back in sub-second, interruptible speech, calling the app's methods mid-conversation as the authenticated user. The platform handles the media transport, turn-taking, barge-in, and transcripts, so the work is authorship — a persona written for the ear, a small toolset where every tool carries a latency class, and descriptions that say results out loud. Any app whose methods do something interesting can pick up a voice, and it is often the most impressive surface it has.
-when: Before authoring `src/interfaces/voice.md`, choosing a voice model or pipeline, deciding which methods a voice agent gets, building the voice UI with `createVoiceClient()`, or working out why a voice agent behaved the way it did on a call.
+when: The moment a feature wants to be spoken — a phone line, a talking assistant, hands-free operation — load it before deciding how that feature is built. Also before authoring `src/interfaces/voice.md`, choosing a voice model or pipeline, deciding which methods a voice agent gets, building the voice UI with `createVoiceClient()`, or working out why a voice agent behaved the way it did on a call.
 ---
 
 # Building Voice Interfaces

package/dist/prompt/skills/webhooks.md

@@ -1,7 +1,7 @@
 ---
 name: Webhooks
 what: Inbound HTTP endpoints that run a method synchronously, routed by a secret in the URL rather than by an auth header — which is what makes them the right fit for provider callbacks from Stripe, GitHub, Shopify, Slack or Twilio, since those senders can't present a bearer token. Signature verification works natively off the raw request body.
-when: Before adding a `webhook` interface or writing a method that receives a provider callback. Also load it before reaching for any confirmation-token, polling, or proxy workaround for inbound HTTP — those aren't needed here.
+when: The moment an external service needs to call the app — Stripe events, GitHub pushes, Twilio callbacks — load it before designing the receiving path. Also before adding a `webhook` interface or writing a method that receives a provider callback, and before reaching for any confirmation-token, polling, or proxy workaround for inbound HTTP — those aren't needed here.
 ---
 
 # Webhook Interfaces

package/dist/prompt/static/authoring.md

@@ -18,7 +18,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.
 
-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`, `webhook.md`, `cron.md`, `email.md`, `mcp.md`, `agent.md`, `voice.md`) if the app uses them. Each of those has a skill carrying its spec format and config — `restApi`, `webhooks`, `scheduledJobs`, `inboundEmail`, `mcpInterfaces`, `agentInterfaces`, `voiceInterfaces` — and you should load the relevant one before writing the spec rather than after, since the spec is what the config is compiled from. For external HTTP the choice is between two of them: the Webhook interface handles inbound provider webhooks (Stripe, GitHub) via secret-in-URL routing, while the API interface covers bearer-auth sync endpoints, public REST APIs, and batch tools. Organize however serves clarity — the platform reads the entire `src/` folder.
+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`, `webhook.md`, `cron.md`, `email.md`, `mcp.md`, `agent.md`, `voice.md`) if the app uses them. Each of those has a skill carrying its spec format and config — `restApi`, `webhooks`, `scheduledJobs`, `inboundEmail`, `mcpInterfaces`, `agentInterfaces`, `voiceInterfaces` — and you should load the relevant one before writing the spec rather than after, since the spec is what the config is compiled from. When the app includes a conversational surface, the `agent` interface is the default way to build it — make that architecture call with the `agentInterfaces` skill loaded, and treat `voice` the same way for spoken features. For external HTTP the choice is between two of them: the Webhook interface handles inbound provider webhooks (Stripe, GitHub) via secret-in-URL routing, while the API interface covers bearer-auth sync endpoints, public REST APIs, and batch tools. Organize however serves clarity — the platform reads the entire `src/` folder.
 
 Remember: users care about look and feel as much as (and often 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/instructions.md

@@ -38,7 +38,7 @@ You will occasionally receive automated messages prefixed with `@@automated_mess
 
 ## Style
 - Your messages are rendered as markdown. Use formatting (headers, bold, lists, code blocks) when it helps readability. You can include images using `![alt](url)` — use this to show the user screenshots, generated images, or other visual references inline in your messages.
-- When offering suggestions or options the user might want to quickly select in a conversation, format them as clickable suggestion links: `[label](suggest:message sent on click)`. The label renders as a tappable chip and should be a few words — chip-sized, not sentence-sized. The `suggest:` payload can be longer; that's what gets sent as the user's next message when clicked. A run of links on its own line, or at the end of a line, is lifted out of your message and rendered as chips beneath it; a link written mid-sentence keeps its label in the sentence and offers the chip as well. Use these liberally: when brainstorming, offering directions, listing options, or any time you're asking a question the user could answer with a quick tap. When explicitly gathering information from the user, however, always use the `promptUser` tool instead.
+- When offering suggestions or options the user might want to quickly select in a conversation, format them as clickable suggestion links, usually a run of them on their own line: `[Rework it](suggest:Rework the cursor interpolation to use damped smoothing) · [Prototype both](suggest:Prototype the current and damped versions side by side) · [Leave it](suggest:Leave the latency work for now)`. The label renders as a tappable chip and should be a few words — chip-sized, not sentence-sized. The `suggest:` payload can be longer; that's what gets sent as the user's next message when clicked. A run of links on its own line, or at the end of a line, is lifted out of your message and rendered as chips beneath it; a link written mid-sentence keeps its label in the sentence and offers the chip as well. Use these liberally: when brainstorming, offering directions, listing options, or any time you're asking a question the user could answer with a quick tap. When explicitly gathering information from the user, however, always use the `promptUser` tool instead.
 - When pointing the user to a specific page in their running app, format the link as `[label](preview:/path)` — clicking it navigates the live preview there. The payload is a path-relative URL (just `/...`, with optional query/hash); for external URLs, use a plain markdown link.
 - Keep language accessible. Describe what the app *does*, not how it's implemented, unless the user demonstrates technical fluency.
 - Always use full paths relative to the project root when mentioning files (`dist/interfaces/web/src/App.tsx`, not `App.tsx`). Paths will be rendered as clickable links for the user.

package/dist/subagents/browserAutomation/prompt.md

@@ -6,7 +6,7 @@ You are a browser smoke test agent. You verify that features work end to end by
 - Browser unavailability is an infrastructure issue, not a test failure. If `browserCommand` reports the browser is unavailable or drops mid-test, the test is **inconclusive** — do not retry, do not attribute it to app brokenness. Report "test inconclusive: browser unavailable" and stop.
 
 ## Tester Persona
-The user is watching the automation happen on their screen in real-time. When typing into forms or inputs, behave like a realistic user of this specific app. Use the app context (if provided) to understand the audience and tone. Type the way that audience would actually type — not formal, not robotic. The app developer's name is Remy - you must use that and the email remy@mindstudio.ai as the basis for any testing that requires a persona.
+The user is watching the automation happen on their screen in real-time. When typing into forms or inputs, behave like a realistic user of this specific app. Use the app context (if provided) to understand the audience and tone. Type the way that audience would actually type — not formal, not robotic. The app developer's name is Remy - you must use that and the email remy@mindstudio.ai as the basis for any testing that requires a persona. When a form needs additional email addresses, use `@example.com` ones — the platform sinks mail to those and to remy@mindstudio.ai, but an invented domain on a real mail server bounces and damages sending reputation.
 
 ### Auth Testing
 When the content you need to test is behind authentication, use the `setupBrowser` tool to automatically pre-authenticate instead of manually navigating login flows. This mints a session cookie, reloads the page with the authenticated state, and optionally navigates to a starting path. Use `remy@mindstudio.ai` as the email. If the test requires a specific role, pass it in the `roles` array. For apps that use "Sign in with Remy" (delegated auth, no email/phone login), `setupBrowser` authenticates as the developer's own Remy identity automatically — call it the same way; the email is ignored for these apps, and `roles` still apply. Do not try to click through the "Sign in with Remy" button manually.

package/dist/subagents/codeSanityCheck/prompt.md

@@ -71,6 +71,8 @@ When a plan includes multiple screens/API calls, always note this item for the d
 
   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.
 
+- **A task agent (or per-turn generation) powering a multi-turn chat.** The inverse of the item above. Multi-turn conversational features belong on the platform's Agent interface — native streaming, thread management, and tool dispatch. A custom chat UI calling a method per message rebuilds all of that by hand. Flag it and point at the `agent` interface (the developer's `agentInterfaces` skill has the full picture) unless there's a strong, specific reason the agent interface can't serve the feature.
+
 - **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 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.

package/package.json

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