@mindstudio-ai/remy 0.1.247 → 0.1.249

package/dist/automatedActions/publish.md

@@ -11,7 +11,7 @@ Read what's changed since the last push — the diffs and commits — and turn i
 If approved:
 - Stage and commit any uncommitted changes with a clean, descriptive commit message. If the committed work resolves any open issues (`mindstudio-prod issues`), reference them in the commit message with a closing keyword — `fixes #42`, `closes #7` — so the deploy closes them automatically once it goes live.
 - Push to main
-- Use `mindstudio-prod releases status --wait` to poll the build until it completes. Let the user know it's deploying, then report back when it's live.
+- Use `mindstudio-prod releases wait` to poll the build until it completes. Let the user know it's deploying, then report back when it's live.
 - Once deployed, offer to help with next steps. This includes technical steps likesetting up a custom domain (`mindstudio-prod domains`), checking for errors (`mindstudio-prod requests stats`), seeding production data (`mindstudio-prod db`), managing env vars/secrets, or anything else they need for launch. It also includes going above and beyond and helping holistically. If it's the initial deploy, offer to help create collateral to announce the launch (e.g., an image for sharing on social media, text copy for a post, etc); if it's a meaningful incremental update, an annoucement post or something similar - go above and beyond here to help the user see that you care about the product from end-to-end, not just writing code! They will be appreciative, grateful, and pleased with your creativity here. Refer to the design guidance in the spec for how to talk about the product, and consider consulting the design expert to generate images or other marketing collateral.
 
 After everything is done, call `compactConversation` to summarize the current session and free up context for the next phase of work.

package/dist/headless.js

@@ -2841,7 +2841,7 @@ var runMethodTool = {
         },
         userId: {
           type: "string",
-          description: 'Optional. Run the method as a specific user. Pass "testUser" to auto-auth as the default test user (the sandbox handles user creation/lookup \u2014 no scenario setup needed). Or pass a real user ID from scenario-seeded data for a specific user. Overrides session-level impersonation for this call only.'
+          description: `Optional. Run the method as a specific user. Pass "testUser" to auto-auth as the default test user (the sandbox handles user creation/lookup \u2014 no scenario setup needed); works for email-code, sms-code, and "Sign in with Remy" apps (for sign-in-with-remy apps it resolves to the developer's own delegated identity rather than the test user). Or pass a real user ID from scenario-seeded data for a specific user. Overrides session-level impersonation for this call only.`
         },
         roles: {
           type: "array",

package/dist/index.js

@@ -3687,7 +3687,7 @@ var init_runMethod = __esm({
             },
             userId: {
               type: "string",
-              description: 'Optional. Run the method as a specific user. Pass "testUser" to auto-auth as the default test user (the sandbox handles user creation/lookup \u2014 no scenario setup needed). Or pass a real user ID from scenario-seeded data for a specific user. Overrides session-level impersonation for this call only.'
+              description: `Optional. Run the method as a specific user. Pass "testUser" to auto-auth as the default test user (the sandbox handles user creation/lookup \u2014 no scenario setup needed); works for email-code, sms-code, and "Sign in with Remy" apps (for sign-in-with-remy apps it resolves to the developer's own delegated identity rather than the test user). Or pass a real user ID from scenario-seeded data for a specific user. Overrides session-level impersonation for this call only.`
             },
             roles: {
               type: "array",

package/dist/prompt/compiled/auth.md

@@ -420,4 +420,6 @@ All other emails and phone numbers receive real codes. There is no dev-mode bypa
 
 The `runMethod` tool's `userId: "testUser"` shortcut resolves to this same dev-bypass identity. The platform find-or-creates a real users-table row for it on first call and caches the row's UUID for the rest of the dev session. **`auth.userId` inside the method is that UUID — not the literal string `"testUser"`.** The user row already exists, so don't try to insert it. If you need the UUID to seed app-specific rows that reference it (profiles, preferences, foreign keys), read it from any method response or query the users table directly: `SELECT id FROM users WHERE email = 'remy@mindstudio.ai'` (or `phone = '+15555555555'` for SMS-auth apps).
 
+For **"Sign in with Remy"** apps (`auth.methods` is `["remy"]`, with no `email-code`/`sms-code`), `testUser` — and `setupBrowser` — resolve to **the developer's own delegated Remy identity**, not the `remy@mindstudio.ai` code-bypass user. `auth.userId` is still that user's real UUID, but the `remy@mindstudio.ai` email lookup above does not apply — read the UUID from a method response instead.
+
 Browser automation tools (screenshots, automated browser tests) handle their own auth sessions. Scenarios seed database data but do not create browser auth sessions.

package/dist/prompt/compiled/dev-and-deploy.md

@@ -46,10 +46,6 @@ All deployed apps are available on `<uuid>.madewithremy.com` where uuid is their
 
 Every live deploy runs an automated Lighthouse audit of the app. Pull it via `mindstudio-prod diagnostics get` CLI when the user wants to evaluate frontend performance. It runs async after the build completes, so it won't be available right away.
 
-### Preview Deployments
-
-Push to a non-default branch for a preview deployment — same build pipeline, but doesn't affect the live app. Useful for testing changes before merging.
-
 ### Database Migrations on Deploy
 
 Schema changes are automatic:

package/dist/prompt/compiled/interfaces.md

@@ -41,6 +41,7 @@ All fields are nested under the `"web"` key.
 | `devPort` | `number` | `5173` | Port for the dev server |
 | `devCommand` | `string` | `"npm run dev"` | Command to start the dev server |
 | `defaultPreviewMode` | `"desktop"` \| `"mobile"` | `"desktop"` | Default preview viewport in the editor. Set to `"mobile"` for mobile-first apps. |
+| `prerender` | `object` | — | Opt into prerendering the listed routes/patterns for crawlers/unfurlers. See "Prerendering" below. |
 
 ### Frontend SDK
 
@@ -113,6 +114,29 @@ Analytics is **cookie-banner-free by design**: per-app scoping, IP discarded aft
 
 Disabling telemetry is a per-app dashboard setting (platform toggle, not code). Point users there if they ask.
 
+### Prerendering (for crawlers/unfurlers)
+
+For non-static SPAs, link unfurlers and AI/search crawlers see only the empty shell. Opt routes into prerendering and the platform serves a cached headless snapshot to bots; real users always get the live SPA.
+
+Opt in per route in `web.json`:
+
+```json
+{ "web": { "prerender": { "paths": ["/u/*", "/blog/*"] } } }
+```
+
+`prerender` is an object with a single field, `paths`: an array of route globs (`*` = one segment, `**` = any). Only listed routes prerender.
+
+The opt-in alone is not enough. For every route in `prerender.paths`, the SPA must set `document.documentElement.setAttribute('data-prerender-ready', 'true')` once the head is written and the route has resolved — this is required, not optional. The renderer waits for this marker, so a prerendered route that never sets it times out. Set it even on routes that render synchronously, as soon as they're ready.
+
+App deploys invalidate prerender cache automatically. When prerendered content changes at runtime, invalidate from the mutating method:
+
+```typescript
+import { prerender } from '@mindstudio-ai/agent';
+await prerender.invalidate(['/u/abc']); // omit arg to purge all
+```
+
+`mindstudio-prod prerender` can help you verify/manage snapshots during development.
+
 ## API Interface
 
 REST endpoints for external consumers — other services, mobile apps, integrations. This is separate from the web frontend's internal RPC (`@mindstudio-ai/interface` calls `/_/methods` directly and does not use the API interface). The API interface lives at `/_/api/` and exposes only the methods you choose to route.
@@ -593,7 +617,7 @@ dist/interfaces/agent/
 
 | Field | Description |
 |-------|-------------|
-| `model` | MindStudio model ID (e.g. `claude-4-5-haiku`, `claude-4-6-sonnet`) |
+| `model` | MindStudio model ID (e.g. `claude-4-5-haiku`, `claude-5-sonnet`) |
 | `temperature` | Model temperature |
 | `maxTokens` | Max response tokens |
 | `systemPrompt` | Relative path to the compiled system prompt markdown file |

package/dist/prompt/compiled/methods.md

@@ -231,7 +231,7 @@ export async function enrichRestaurant(input: { id: string; name: string }) {
     input: { name: input.name },
     tools: ['searchGoogle', 'fetchUrl', 'generateImage'],
     structuredOutputExample: { /* ... */ },
-    model: 'claude-4-6-sonnet',
+    model: 'claude-5-sonnet',
   }).then(async (result) => {
     if (result.parsedSuccessfully) {
       await Restaurants.update(input.id, { ...result.output, status: 'complete' });

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

@@ -119,7 +119,7 @@ Override the default model for any AI action. Each model has its own config opti
 const { content } = await mindstudio.generateText({
   message: 'Hello',
   modelOverride: {
-    model: 'claude-sonnet-4-6',
+    model: 'claude-5-sonnet',
     temperature: 0.7,
     maxResponseTokens: 16000,
   },

package/dist/prompt/compiled/task-agents.md

@@ -53,7 +53,7 @@ const result = await mindstudio.runTask<{
     photoUrl: 'https://cdn.mindstudio.ai/...',
   },
 
-  model: 'claude-4-6-sonnet',
+  model: 'claude-5-sonnet',
   maxTurns: 15,
 });
 

package/dist/subagents/browserAutomation/prompt.md

@@ -9,7 +9,7 @@ You are a browser smoke test agent. You verify that features work end to end by
 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.
 
 ### 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.
+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.
 
 If you need to test the login/signup flow itself (e.g., verifying the UI, error states, or the verification code input), navigate it manually: use `remy@mindstudio.ai` for email and `+15551234567` for phone. In the dev environment, verification codes are bypassed for this email and any 555-prefixed phone number — enter any 6-digit code (e.g., `123456`).
 

package/package.json

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