@mindstudio-ai/remy 0.1.283 → 0.1.285

package/dist/automatedActions/buildFromInitialSpec.md

@@ -19,7 +19,7 @@ Then, build everything in one turn: tables, methods, interfaces, manifest update
 - First, run use `runScenario` to seed test data, then use `runMethod` to confirm important methods work.
 - If the app has a web frontend, check the browser logs to make sure there are no errors rendering it.
 - 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.
-- If there is a scenario that seeds the app with mock data, use it to present the app to the user with initial data seeded, so they can see and play with the real app. Let the user know they can reset the app using a scenario to empty it if they wish. Showing the user something they can play with immediately is important when it comes to landing a strong first impression.
+- If there is a scenario that seeds the app with mock data, use it to present the app to the user with initial data seeded, so they can see and play with the real app. Let the user know they can reset the app using a scenario to empty it if they wish. Showing the user something they can play with immediately is important when it comes to landing a strong first impression. For apps with auth, the preview opens on the app's sign-in screen by design — that's the front door working, not a bug. Don't try to pre-authenticate the user or route around it; tell them the sign-in helper auto-fills the test account (`remy@mindstudio.ai`, code `123456`), so they're in with one tap.
 
 ## When you are done
 

package/dist/headless.js

@@ -2936,7 +2936,7 @@ var restartProcessTool = {
 var runScenarioTool = {
   definition: {
     name: "runScenario",
-    description: "Run a scenario to seed the dev database with test data. By default truncates all tables first, then executes the seed function and impersonates the scenario roles. Use skipTruncate to run the seed function against existing data without resetting. Blocks until complete. Scenario IDs are defined in mindstudio.json. If it fails, check .logs/tunnel.log or .logs/requests.ndjson for details. Return synchronously - no need to sleep before checking results.",
+    description: "Run a scenario to seed the dev database with test data. By default truncates all tables first, then executes the seed function and assigns the scenario's roles to the dev test user (a real user row; the roles persist on it until changed). Nobody gets signed in: the preview still shows the app's own sign-in, where the dev helper auto-fills the test account. Use skipTruncate to run the seed function against existing data without resetting. Blocks until complete. Scenario IDs are defined in mindstudio.json. If it fails, check .logs/tunnel.log or .logs/requests.ndjson for details. Returns synchronously - no need to sleep before checking results.",
     inputSchema: {
       type: "object",
       properties: {
@@ -2975,12 +2975,12 @@ 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); 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.`
+          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.`
         },
         roles: {
           type: "array",
           items: { type: "string" },
-          description: 'Optional. Role names for this request (e.g. ["admin"]). Combine with `userId` to test a specific role, or use alone to test role-gated logic without a full identity. Overrides session-level impersonation for this call only.'
+          description: 'Optional. Role names for this request (e.g. ["admin"]). For auth-enabled apps, roles without a userId run as the dev test user holding exactly these roles \u2014 a real user row, so `auth.userId` and `requireRole` behave like production. For apps without auth, roles attach to an anonymous call. Applies to this call only.'
         }
       },
       required: ["method"]
@@ -4505,7 +4505,7 @@ async function runBrowserAutomation(task, context, opts) {
       await sidecarRequest(
         "/set-viewport",
         { mode: "default" },
-        { timeout: 2e4 }
+        { timeout: 25e3 }
       );
     } catch {
     }
@@ -4524,7 +4524,7 @@ async function runBrowserAutomation(task, context, opts) {
                 auth: _input.auth,
                 path: _input.path
               },
-              { timeout: 15e3 }
+              { timeout: 2e4 }
             );
             return JSON.stringify(result2);
           } catch (err) {

package/dist/index.js

@@ -4089,7 +4089,7 @@ var init_runScenario = __esm({
     runScenarioTool = {
       definition: {
         name: "runScenario",
-        description: "Run a scenario to seed the dev database with test data. By default truncates all tables first, then executes the seed function and impersonates the scenario roles. Use skipTruncate to run the seed function against existing data without resetting. Blocks until complete. Scenario IDs are defined in mindstudio.json. If it fails, check .logs/tunnel.log or .logs/requests.ndjson for details. Return synchronously - no need to sleep before checking results.",
+        description: "Run a scenario to seed the dev database with test data. By default truncates all tables first, then executes the seed function and assigns the scenario's roles to the dev test user (a real user row; the roles persist on it until changed). Nobody gets signed in: the preview still shows the app's own sign-in, where the dev helper auto-fills the test account. Use skipTruncate to run the seed function against existing data without resetting. Blocks until complete. Scenario IDs are defined in mindstudio.json. If it fails, check .logs/tunnel.log or .logs/requests.ndjson for details. Returns synchronously - no need to sleep before checking results.",
         inputSchema: {
           type: "object",
           properties: {
@@ -4134,12 +4134,12 @@ 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); 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.`
+              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.`
             },
             roles: {
               type: "array",
               items: { type: "string" },
-              description: 'Optional. Role names for this request (e.g. ["admin"]). Combine with `userId` to test a specific role, or use alone to test role-gated logic without a full identity. Overrides session-level impersonation for this call only.'
+              description: 'Optional. Role names for this request (e.g. ["admin"]). For auth-enabled apps, roles without a userId run as the dev test user holding exactly these roles \u2014 a real user row, so `auth.userId` and `requireRole` behave like production. For apps without auth, roles attach to an anonymous call. Applies to this call only.'
             }
           },
           required: ["method"]
@@ -5542,7 +5542,7 @@ async function runBrowserAutomation(task, context, opts) {
       await sidecarRequest(
         "/set-viewport",
         { mode: "default" },
-        { timeout: 2e4 }
+        { timeout: 25e3 }
       );
     } catch {
     }
@@ -5561,7 +5561,7 @@ async function runBrowserAutomation(task, context, opts) {
                 auth: _input.auth,
                 path: _input.path
               },
-              { timeout: 15e3 }
+              { timeout: 2e4 }
             );
             return JSON.stringify(result2);
           } catch (err) {

package/dist/prompt/compiled/manifest.md

@@ -126,4 +126,4 @@
 | `description` | `string` | No | What state this scenario creates |
 | `path` | `string` | Yes | Path to the TypeScript file |
 | `export` | `string` | Yes | Named export (the async function) |
-| `roles` | `string[]` | Yes | Roles to impersonate after seeding |
+| `roles` | `string[]` | Yes | Roles assigned to the dev test user after seeding |

package/dist/prompt/skills/auth.md

@@ -430,7 +430,7 @@ Auth works the same in dev/preview as in production — real verification codes
 
 All other emails and phone numbers receive real codes. There is no dev-mode bypass, no fake code, and no way to skip verification. When testing auth flows in the preview, use one of the test bypasses above or a real email/phone.
 
-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).
+This test account is the dev's standing identity: the preview's sign-in helper auto-fills it, the editor's Roles column edits its roles, and a scenario's `roles` field assigns roles to it after seeding. The `runMethod` tool's `userId: "testUser"` shortcut resolves to this same dev-bypass identity (as does `roles` without a `userId`). 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.
 

package/dist/prompt/skills/jewels.md

@@ -218,10 +218,25 @@ The wiring itself is two manifest lines on the method's entry:
   "path": "dist/methods/src/categorizeRecord.ts",
   "export": "categorizeRecord",
   "autonomy": "shadow",
-  "jewel": { "path": "dist/methods/src/categorizeRecord.jewel.ts", "export": "default" }
+  "jewel": { "path": "dist/methods/src/categorizeRecord.jewel.ts", "export": "default" },
+  "tuning": {}
 }
 ```
 
+`tuning` (optional) is the training recipe for the jewel's own model. Every knob has a
+platform default and most jewels never set any: `windowDays` (how many days of ledger
+history to train on; default all history), `epochs` (1-10, default 3), `rank` (LoRA
+rank, 4-64, default 16), `learningRate` (default 5e-5). It requires `jewel`, and it
+rides the release: changing a knob is a commit + deploy before the next training run.
+
+Once a method has accumulated graded pairs, train from the prod CLI:
+`mindstudio-prod jewels train <methodId>` (see `--help`). The dataset report says
+whether the ledger is trainable (pairs without an attached `trace` don't count), and a
+run produces a downloadable LoRA adapter plus a held-out agreement report: how often
+the trained model matched your team's decisions on pairs it never saw. The trained
+model is an artifact and a report for now; serving it inside the app is a later
+platform phase, so set that expectation honestly when a user asks.
+
 ## Arrival Triggers (`mindstudio.jewels.propose`)
 
 Invocation shadowing fires when a human acts. For decision moments the app detects itself (an ingest branch that lands a row in its pending state), hand the moment to the jewels from backend code:

package/dist/prompt/skills/scenarios.md

@@ -1,6 +1,6 @@
 ---
 name: Scenarios
-what: Seed scripts that reset the dev database to a specific state — the platform truncates all tables, runs an async function of plain `db.push()` calls, then impersonates a role, so the same scenario always produces the same state. They're how the user tests the app from each role's perspective and how a freshly built app makes its first impression already populated with data that fits its vibe. Declared in the manifest, written at `dist/methods/.scenarios/`.
+what: Seed scripts that reset the dev database to a specific state — the platform truncates all tables, runs an async function of plain `db.push()` calls, then assigns the scenario's roles to the dev test user, so the same scenario always produces the same state. They're how the user tests the app from each role's perspective (by signing in as the test account) and how a freshly built app makes its first impression already populated with data that fits its vibe. Declared in the manifest, written at `dist/methods/.scenarios/`.
 when: Before writing or editing a scenario — including the initial build, where scenarios are required. Covers file placement and imports, truncate semantics, what scenarios must not touch (file stores, data sources), and seeding realistic data and bespoke images.
 ---
 
@@ -42,7 +42,7 @@ In `mindstudio.json`:
 | `description` | What state this scenario creates |
 | `path` | Path to the TypeScript file |
 | `export` | Named export (the async function) |
-| `roles` | Roles to impersonate after seeding |
+| `roles` | Roles assigned to the dev test user after seeding (requires app auth) |
 
 ## Writing a Scenario
 
@@ -104,10 +104,12 @@ Shared setup code can go in `dist/methods/.scenarios/_helpers/`.
 When a scenario runs, the platform:
 1. **Truncates** all tables (deletes all rows, preserves schema - unless skipTruncate is true)
 2. **Executes** the seed function (your `db.push()` calls populate the clean database)
-3. **Impersonates** the roles from the scenario's `roles` field (the app renders from that user's perspective)
+3. **Assigns** the roles from the scenario's `roles` field to the dev test user — a real write to that user's row, so it requires app auth to be enabled
 
 This is deterministic — same scenario always produces the same state.
 
+Nobody gets signed in by a scenario. The preview shows the app's own sign-in screen, where the dev helper auto-fills the test account (`remy@mindstudio.ai`, code `123456`) — one tap and the user is in as the test user, seeing the app from the scenario's role's perspective. The roles persist on the test user until another scenario or the Roles column changes them.
+
 Scenarios are useful for seeding initial app state after build for testing, as well as to give the user a first impression of an app that is already filled with data and looks and feels usable. The user can choose to run further scenarios after initial build by clicking the Scenarios tab and selecting a scenario to run.
 
 ## What scenarios don't touch

package/dist/prompt/static/coding.md

@@ -45,7 +45,7 @@ The SDK also includes a `reportIssue` method that can file bug reports on the ap
 - For signup and login, verification code inputs must feel polished — clear feedback on send, auto-send on paste, a "resend" option, and error messages for wrong/expired codes.
 - The auth table is the user profile. Add custom fields (displayName, avatar, plan, etc.) alongside the platform-managed columns. Don't create a separate profile table.
 - When delegated sign-in ("Sign in with Remy") is available for the org, prefer a "Continue with {Org}" button (`auth.signInWithRemy()`) and call `auth.handleRemyRedirect()` once on app load. Drive UI off `onAuthStateChanged`, not the sign-in return value (top-level sign-in redirects away and never returns). Load the `auth` skill for the full flow reference.
-- For apps with roles, create scenarios that seed users with different roles so the developer can test each perspective. Use the scenario `roles` field for impersonation.
+- For apps with roles, create one scenario per role so the developer can test each perspective: the scenario's `roles` field assigns those roles to the dev test user, and signing in as that account (the preview's sign-in helper auto-fills it) shows the app from that role's perspective.
 
 ### CSS & Layout
 - Prefer CSS grid for page-level layout, flex for component-level alignment.

package/dist/subagents/browserAutomation/prompt.md

@@ -11,13 +11,13 @@ The user is watching the automation happen on their screen in real-time. When ty
 ### 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.
 
-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`).
+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 for this email and any 555-prefixed phone number accepts the code `123456`.
 
 To test as a **signed-out visitor** (public pages, landing/join links), call `setupBrowser` with NO `auth` — it clears the auth cookie and reloads at the given path, giving you a clean unauthenticated session. Combine with `navigate` + `fresh: true` when you need a fresh-document view of an entry page mid-run.
 
 ## Browser Commands
 
-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.
+Your session always starts on the app root / in a logged out/unauthenticated state, on a freshly reloaded page running the current code (scenarios seed data and set the test user's roles but never create browser sessions) — 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.283",
+  "version": "0.1.285",
   "description": "Remy coding agent",
   "repository": {
     "type": "git",