@mindstudio-ai/remy 0.1.298 → 0.1.300

package/dist/headless.js

@@ -942,9 +942,9 @@ function buildBackgroundResultsMessage(results) {
 ${r.result}
 </tool_result>`
   ).join("\n\n");
-  const plural = results.length > 1 ? "s" : "";
-  const body = `This is an automated message containing the result${plural} of ${results.length > 1 ? "tool calls" : "a tool call"} that ${results.length > 1 ? "have" : "has"} been working in the background. This is not a direct message from the user.
-<background_results>
+  const body = `<background_results>
+Automated delivery of results from background tool calls that completed while other work was in progress. This block is not from the user \u2014 anything outside it is.
+
 ${xml}
 </background_results>`;
   return automatedMessage("background_results", body);
@@ -1848,7 +1848,7 @@ var askMindStudioSdkTool = {
   async execute(input, context) {
     const query = input.query;
     const result = await runCli("mindstudio", ["ask", query], {
-      timeout: 2e5,
+      timeout: 48e4,
       maxBuffer: 512 * 1024,
       onLog: context?.onLog
     });
@@ -4570,7 +4570,7 @@ async function runBrowserAutomation(task, context, opts) {
       task,
       tools: BROWSER_TOOLS,
       externalTools: BROWSER_EXTERNAL_TOOLS,
-      executeTool: async (name, _input, _toolCallId, onLog) => {
+      executeTool: async (name, _input, toolCallId, onLog) => {
         if (name === "setupBrowser") {
           try {
             const result2 = await sidecarRequest(
@@ -4587,7 +4587,11 @@ async function runBrowserAutomation(task, context, opts) {
           }
         }
         if (COMMON_READ_TOOL_NAMES.has(name) || name === readSpecTool.definition.name) {
-          return executeTool(name, _input, context);
+          return executeTool(
+            name,
+            _input,
+            toolCallId ? deriveContext(context, toolCallId, onLog) : context
+          );
         }
         return `Error: unknown local tool "${name}"`;
       },
@@ -5556,7 +5560,13 @@ var copyEditorTool = {
       task: input.task,
       tools: COPY_EDITOR_TOOLS,
       externalTools: /* @__PURE__ */ new Set(),
-      executeTool: (name, toolInput) => executeTool(name, toolInput, context),
+      executeTool: (name, toolInput, toolCallId, onLog, sams) => {
+        const childCtx = toolCallId ? {
+          ...deriveContext(context, toolCallId, onLog),
+          subAgentMessages: sams
+        } : context;
+        return executeTool(name, toolInput, childCtx);
+      },
       apiConfig: context.apiConfig,
       model: resolveModel("copyEditor", context.models, context.model),
       subAgentId: "copyEditor",
@@ -5824,7 +5834,7 @@ async function executeDesignExpertTool(name, input, context, toolCallId, onLog)
   if (!tool) {
     return `Error: unknown tool "${name}"`;
   }
-  const childContext = context && toolCallId ? deriveContext(context, toolCallId) : context;
+  const childContext = context && toolCallId ? deriveContext(context, toolCallId, onLog) : context;
   return tool.execute(input, onLog, childContext);
 }
 
@@ -6112,7 +6122,10 @@ async function runDesignExpert(opts, context) {
     tools: opts.render ? DESIGN_EXPERT_RENDER_TOOLS : DESIGN_EXPERT_TOOLS,
     externalTools: /* @__PURE__ */ new Set(),
     executeTool: (name, input, toolCallId, onLog, sams) => {
-      const childCtx = toolCallId ? { ...deriveContext(context, toolCallId), subAgentMessages: sams } : { ...context, subAgentMessages: sams };
+      const childCtx = toolCallId ? {
+        ...deriveContext(context, toolCallId, onLog),
+        subAgentMessages: sams
+      } : { ...context, subAgentMessages: sams };
       if (COMMON_READ_TOOL_NAMES.has(name)) {
         return executeTool(name, input, childCtx);
       }
@@ -6380,8 +6393,11 @@ var productVisionTool = {
       cachePolicy: "conversation",
       tools: VISION_TOOLS,
       externalTools: /* @__PURE__ */ new Set(),
-      executeTool: (name, input2, toolCallId, _onLog, sams) => {
-        const childCtx = toolCallId ? { ...deriveContext(context, toolCallId), subAgentMessages: sams } : { ...context, subAgentMessages: sams };
+      executeTool: (name, input2, toolCallId, onLog, sams) => {
+        const childCtx = toolCallId ? {
+          ...deriveContext(context, toolCallId, onLog),
+          subAgentMessages: sams
+        } : { ...context, subAgentMessages: sams };
         if (COMMON_READ_TOOL_NAMES.has(name)) {
           return executeTool(name, input2, childCtx);
         }
@@ -6493,7 +6509,13 @@ var codeSanityCheckTool = {
       task: input.task,
       tools: SANITY_CHECK_TOOLS,
       externalTools: /* @__PURE__ */ new Set(),
-      executeTool: (name, toolInput) => executeTool(name, toolInput, context),
+      executeTool: (name, toolInput, toolCallId, onLog, sams) => {
+        const childCtx = toolCallId ? {
+          ...deriveContext(context, toolCallId, onLog),
+          subAgentMessages: sams
+        } : context;
+        return executeTool(name, toolInput, childCtx);
+      },
       apiConfig: context.apiConfig,
       model: resolveModel("codeSanityCheck", context.models, context.model),
       subAgentId: "codeSanityCheck",
@@ -6703,16 +6725,19 @@ After reconciling the spec, refresh the Build Overview: author the complete upda
       task,
       tools: tools2,
       externalTools: /* @__PURE__ */ new Set(),
-      executeTool: (name, toolInput, toolCallId, _onLog, sams) => {
+      executeTool: (name, toolInput, toolCallId, onLog, sams) => {
+        const childCtx = toolCallId ? {
+          ...deriveContext(context, toolCallId, onLog),
+          subAgentMessages: sams
+        } : { ...context, subAgentMessages: sams };
         if (name === "writeBuildOverview") {
-          const childCtx = toolCallId ? { ...deriveContext(context, toolCallId), subAgentMessages: sams } : { ...context, subAgentMessages: sams };
           return renderBuildOverview(
             String(toolInput.content ?? "").trim(),
             childCtx,
             { background: false }
           );
         }
-        return executeTool(name, toolInput, context);
+        return executeTool(name, toolInput, childCtx);
       },
       apiConfig: context.apiConfig,
       model: resolveModel("specSync", context.models, context.model),
@@ -6786,8 +6811,8 @@ var scrapeWebUrlTool = {
 };
 
 // src/tools/index.ts
-function deriveContext(parent, toolCallId) {
-  return { ...parent, toolCallId };
+function deriveContext(parent, toolCallId, onLog) {
+  return { ...parent, toolCallId, onLog };
 }
 var ALL_TOOLS = [
   // Common

package/dist/index.js

@@ -1379,7 +1379,7 @@ var init_sdkConsultant = __esm({
       async execute(input, context) {
         const query = input.query;
         const result = await runCli("mindstudio", ["ask", query], {
-          timeout: 2e5,
+          timeout: 48e4,
           maxBuffer: 512 * 1024,
           onLog: context?.onLog
         });
@@ -1660,9 +1660,9 @@ function buildBackgroundResultsMessage(results) {
 ${r.result}
 </tool_result>`
   ).join("\n\n");
-  const plural = results.length > 1 ? "s" : "";
-  const body = `This is an automated message containing the result${plural} of ${results.length > 1 ? "tool calls" : "a tool call"} that ${results.length > 1 ? "have" : "has"} been working in the background. This is not a direct message from the user.
-<background_results>
+  const body = `<background_results>
+Automated delivery of results from background tool calls that completed while other work was in progress. This block is not from the user \u2014 anything outside it is.
+
 ${xml}
 </background_results>`;
   return automatedMessage("background_results", body);
@@ -5648,7 +5648,7 @@ async function runBrowserAutomation(task, context, opts) {
       task,
       tools: BROWSER_TOOLS,
       externalTools: BROWSER_EXTERNAL_TOOLS,
-      executeTool: async (name, _input, _toolCallId, onLog) => {
+      executeTool: async (name, _input, toolCallId, onLog) => {
         if (name === "setupBrowser") {
           try {
             const result2 = await sidecarRequest(
@@ -5665,7 +5665,11 @@ async function runBrowserAutomation(task, context, opts) {
           }
         }
         if (COMMON_READ_TOOL_NAMES.has(name) || name === readSpecTool.definition.name) {
-          return executeTool(name, _input, context);
+          return executeTool(
+            name,
+            _input,
+            toolCallId ? deriveContext(context, toolCallId, onLog) : context
+          );
         }
         return `Error: unknown local tool "${name}"`;
       },
@@ -6752,7 +6756,13 @@ var init_copyEditor = __esm({
           task: input.task,
           tools: COPY_EDITOR_TOOLS,
           externalTools: /* @__PURE__ */ new Set(),
-          executeTool: (name, toolInput) => executeTool(name, toolInput, context),
+          executeTool: (name, toolInput, toolCallId, onLog, sams) => {
+            const childCtx = toolCallId ? {
+              ...deriveContext(context, toolCallId, onLog),
+              subAgentMessages: sams
+            } : context;
+            return executeTool(name, toolInput, childCtx);
+          },
           apiConfig: context.apiConfig,
           model: resolveModel("copyEditor", context.models, context.model),
           subAgentId: "copyEditor",
@@ -7034,7 +7044,7 @@ async function executeDesignExpertTool(name, input, context, toolCallId, onLog)
   if (!tool) {
     return `Error: unknown tool "${name}"`;
   }
-  const childContext = context && toolCallId ? deriveContext(context, toolCallId) : context;
+  const childContext = context && toolCallId ? deriveContext(context, toolCallId, onLog) : context;
   return tool.execute(input, onLog, childContext);
 }
 var tools, DESIGN_EXPERT_TOOLS;
@@ -7466,7 +7476,10 @@ async function runDesignExpert(opts, context) {
     tools: opts.render ? DESIGN_EXPERT_RENDER_TOOLS : DESIGN_EXPERT_TOOLS,
     externalTools: /* @__PURE__ */ new Set(),
     executeTool: (name, input, toolCallId, onLog, sams) => {
-      const childCtx = toolCallId ? { ...deriveContext(context, toolCallId), subAgentMessages: sams } : { ...context, subAgentMessages: sams };
+      const childCtx = toolCallId ? {
+        ...deriveContext(context, toolCallId, onLog),
+        subAgentMessages: sams
+      } : { ...context, subAgentMessages: sams };
       if (COMMON_READ_TOOL_NAMES.has(name)) {
         return executeTool(name, input, childCtx);
       }
@@ -7794,8 +7807,11 @@ var init_productVision = __esm({
           cachePolicy: "conversation",
           tools: VISION_TOOLS,
           externalTools: /* @__PURE__ */ new Set(),
-          executeTool: (name, input2, toolCallId, _onLog, sams) => {
-            const childCtx = toolCallId ? { ...deriveContext(context, toolCallId), subAgentMessages: sams } : { ...context, subAgentMessages: sams };
+          executeTool: (name, input2, toolCallId, onLog, sams) => {
+            const childCtx = toolCallId ? {
+              ...deriveContext(context, toolCallId, onLog),
+              subAgentMessages: sams
+            } : { ...context, subAgentMessages: sams };
             if (COMMON_READ_TOOL_NAMES.has(name)) {
               return executeTool(name, input2, childCtx);
             }
@@ -7926,7 +7942,13 @@ var init_codeSanityCheck = __esm({
           task: input.task,
           tools: SANITY_CHECK_TOOLS,
           externalTools: /* @__PURE__ */ new Set(),
-          executeTool: (name, toolInput) => executeTool(name, toolInput, context),
+          executeTool: (name, toolInput, toolCallId, onLog, sams) => {
+            const childCtx = toolCallId ? {
+              ...deriveContext(context, toolCallId, onLog),
+              subAgentMessages: sams
+            } : context;
+            return executeTool(name, toolInput, childCtx);
+          },
           apiConfig: context.apiConfig,
           model: resolveModel("codeSanityCheck", context.models, context.model),
           subAgentId: "codeSanityCheck",
@@ -8173,16 +8195,19 @@ After reconciling the spec, refresh the Build Overview: author the complete upda
           task,
           tools: tools2,
           externalTools: /* @__PURE__ */ new Set(),
-          executeTool: (name, toolInput, toolCallId, _onLog, sams) => {
+          executeTool: (name, toolInput, toolCallId, onLog, sams) => {
+            const childCtx = toolCallId ? {
+              ...deriveContext(context, toolCallId, onLog),
+              subAgentMessages: sams
+            } : { ...context, subAgentMessages: sams };
             if (name === "writeBuildOverview") {
-              const childCtx = toolCallId ? { ...deriveContext(context, toolCallId), subAgentMessages: sams } : { ...context, subAgentMessages: sams };
               return renderBuildOverview(
                 String(toolInput.content ?? "").trim(),
                 childCtx,
                 { background: false }
               );
             }
-            return executeTool(name, toolInput, context);
+            return executeTool(name, toolInput, childCtx);
           },
           apiConfig: context.apiConfig,
           model: resolveModel("specSync", context.models, context.model),
@@ -8266,8 +8291,8 @@ var init_scrapeWebUrl2 = __esm({
 });
 
 // src/tools/index.ts
-function deriveContext(parent, toolCallId) {
-  return { ...parent, toolCallId };
+function deriveContext(parent, toolCallId, onLog) {
+  return { ...parent, toolCallId, onLog };
 }
 function getToolDefinitions() {
   return ALL_TOOLS.map((t) => t.definition);

package/dist/prompt/compiled/auth.md

@@ -13,7 +13,7 @@ Four auth methods, combinable per app in the manifest:
 
 **Before writing any auth code — the manifest `auth` config, the user table, login/signup UI, frontend `auth.*` calls, API keys — load the `auth` skill.** It has the full contract: config schema, platform-managed columns, the frontend SDK (flows, auth state, error codes, phone/email helpers), delegated sign-in implementation, worked examples, and the auth-screen design rules.
 
-**Restricting who can sign up is a platform setting, not app code.** Limiting sign-ups to specific domains or addresses ("only @acme.com emails"), blocking disposable emails, and fixed-code test accounts for app-store reviewers are all enforced platform-side before any verification code is sent, and managed via `mindstudio-prod settings`. Never build an app-level equivalent (a client-side email check, a backend gate) — it's weaker than the real thing. Load the `auth` skill before acting on any of these requests.
+**Restricting who can sign up is a platform setting, not app code.** Limiting sign-ups to specific domains or addresses ("only @acme.com emails"), blocking disposable emails, and fixed-code test accounts for app-store reviewers are all enforced platform-side before any verification code is sent, and managed via `remy-admin settings`. Never build an app-level equivalent (a client-side email check, a backend gate) — it's weaker than the real thing. Load the `auth` skill before acting on any of these requests.
 
 ## Backend Enforcement
 

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

@@ -40,13 +40,13 @@ The platform builds and deploys automatically:
 5. **Compute effects** — roles diff, cron diff, bot command diffs, table DDL
 6. **Apply** — create/update roles, sync bot commands, apply DDL to a staging database copy, swap the live pointer
 
-All deployed apps are available on `<uuid>.madewithremy.com` where uuid is their app ID. Apps can also be served on a custom platform subdomain (`<subdomain>.madewithremy.com`) or on a fully custom domain the user owns (pointed at the platform via CNAME or A records). Configure either via the `mindstudio-prod` CLI.
+All deployed apps are available on `<uuid>.madewithremy.com` where uuid is their app ID. Apps can also be served on a custom platform subdomain (`<subdomain>.madewithremy.com`) or on a fully custom domain the user owns (pointed at the platform via CNAME or A records). Configure either via the `remy-admin` CLI.
 
-An app meant to be embedded in an iframe on a customer's own site needs that site's origin added to the app's frame-ancestors setting (`mindstudio-prod settings frame-ancestors add`) — without it the platform's CSP blocks the embed on the deployed app. Don't debug a blocked embed in app code; it's this setting.
+An app meant to be embedded in an iframe on a customer's own site needs that site's origin added to the app's frame-ancestors setting (`remy-admin settings frame-ancestors add`) — without it the platform's CSP blocks the embed on the deployed app. Don't debug a blocked embed in app code; it's this setting.
 
 ### Post-Deploy Diagnostics
 
-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.
+Every live deploy runs an automated Lighthouse audit of the app. Pull it via `remy-admin 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.
 
 ### Database Migrations on Deploy
 

package/dist/prompt/compiled/interfaces.md

@@ -147,7 +147,7 @@ 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.
+`remy-admin prerender` can help you verify/manage snapshots during development.
 
 ### Mounting other apps
 

package/dist/prompt/skills/auth.md

@@ -1,6 +1,6 @@
 ---
 name: Auth & User Accounts
-what: Apps manage their own users — opt-in via manifest config over a developer-owned user table, with the platform handling verification codes, cookie sessions, and role sync. Covers email/SMS code login (the platform sends real 6-digit codes; the developer builds the UI), per-user API keys that resolve to full RBAC over Bearer auth, org-delegated "Sign in with Remy" for internal apps (redirect/popup handshake, platform-managed identity), the platform signup-restriction settings (domain/email allowlist, disposable-email blocking, fixed-code test accounts for app-store review — all platform settings via `mindstudio-prod settings`, never app code), the full frontend SDK (auth state and onAuthStateChanged, flows, email/phone changes, phone and email helpers, error codes), backend enforcement (requireRole/hasRole/userId, the system role), auth-screen design rules, and the dev test bypasses.
+what: Apps manage their own users — opt-in via manifest config over a developer-owned user table, with the platform handling verification codes, cookie sessions, and role sync. Covers email/SMS code login (the platform sends real 6-digit codes; the developer builds the UI), per-user API keys that resolve to full RBAC over Bearer auth, org-delegated "Sign in with Remy" for internal apps (redirect/popup handshake, platform-managed identity), the platform signup-restriction settings (domain/email allowlist, disposable-email blocking, fixed-code test accounts for app-store review — all platform settings via `remy-admin settings`, never app code), the full frontend SDK (auth state and onAuthStateChanged, flows, email/phone changes, phone and email helpers, error codes), backend enforcement (requireRole/hasRole/userId, the system role), auth-screen design rules, and the dev test bypasses.
 when: Before writing ANY auth code — the manifest `auth` config, the user table, login/signup UI, frontend `auth.*` calls, API keys, delegated sign-in — and before testing or debugging auth flows.
 ---
 
@@ -51,14 +51,14 @@ Remy apps can have and manage their own users. Auth is opt-in: configure it in t
 
 ## Restricting Who Can Sign Up (Platform Settings)
 
-When the user wants to limit who can register — "only allow sign-ins from our domain", "block throwaway emails", "give the app-store reviewer a working login" — these are **platform settings, enforced at code-send time before any email goes out, not app code**. An app-level equivalent (a client-side email check, a backend gate) is both redundant and weaker: the platform sends the verification code, so app code can't actually stop a signup. Manage them with the `mindstudio-prod settings` CLI (run `mindstudio-prod settings --help` for the full surface).
+When the user wants to limit who can register — "only allow sign-ins from our domain", "block throwaway emails", "give the app-store reviewer a working login" — these are **platform settings, enforced at code-send time before any email goes out, not app code**. An app-level equivalent (a client-side email check, a backend gate) is both redundant and weaker: the platform sends the verification code, so app code can't actually stop a signup. Manage them with the `remy-admin settings` CLI (run `remy-admin settings --help` for the full surface).
 
 **Signup allowlist ("only @acme.com emails"):**
 
 ```bash
-mindstudio-prod settings allowlist add '*@acme.com'   # whole domain
-mindstudio-prod settings allowlist add 'cfo@other.com' # one address
-mindstudio-prod settings allowlist enable              # start enforcing
+remy-admin settings allowlist add '*@acme.com'   # whole domain
+remy-admin settings allowlist add 'cfo@other.com' # one address
+remy-admin settings allowlist enable              # start enforcing
 ```
 
 - Entries are explicit globs: `*@domain.com` (any address at that exact domain — no subdomains; add `*@sub.domain.com` separately) or `user@domain.com` (one address).
@@ -67,15 +67,15 @@ mindstudio-prod settings allowlist enable              # start enforcing
 - Blocked signups fail at `auth.sendEmailCode` with error code `email_not_allowed` — handle it in the login UI with a clear "this app is restricted" message.
 - The dev test login (`remy@mindstudio.ai`) bypasses the allowlist in dev sessions, so you can still smoke-test auth in the preview after enabling it. Don't add it to the allowlist.
 
-**Disposable-email blocking:** on by default — email-code signups from known burner domains are rejected at code-send with error code `disposable_email_blocked`. Per-app opt-out: `mindstudio-prod settings set blockDisposableEmails false`.
+**Disposable-email blocking:** on by default — email-code signups from known burner domains are rejected at code-send with error code `disposable_email_blocked`. Per-app opt-out: `remy-admin settings set blockDisposableEmails false`.
 
 **Test accounts (fixed-code login):** the mechanism for handing app-store reviewers working credentials for a wrapped app — never hand-roll a fake-auth backdoor for this. A listed email or E.164 phone signs in with a pre-set 6-digit code instead of a delivered one, bypassing the disposable and allowlist gates. Works in production; max 5; disable after review.
 
 ```bash
-mindstudio-prod settings test-accounts add reviewer@example.com 246810
-mindstudio-prod settings test-accounts enable
+remy-admin settings test-accounts add reviewer@example.com 246810
+remy-admin settings test-accounts enable
 # after review:
-mindstudio-prod settings test-accounts disable
+remy-admin settings test-accounts disable
 ```
 
 ## Auth Table

package/dist/prompt/skills/dataSources.md

@@ -50,11 +50,11 @@ Search is deterministic for a fixed corpus and configuration, so eval sets and r
 ## Loading documents — normally at build time, from the CLI
 
 ```bash
-mindstudio-prod datasources add --source policies --wait docs/*.pdf
-mindstudio-prod datasources add --source policies --metadata department=legal,year=2026 contract.pdf
-mindstudio-prod datasources search --source policies "what are the payment terms?"   # sanity-check
-mindstudio-prod datasources search --source policies --filter department=legal --mode lexical "ERR-7741X"
-mindstudio-prod datasources delete --source policies   # whole source; --source is required, never defaulted
+remy-admin datasources add --source policies --wait docs/*.pdf
+remy-admin datasources add --source policies --metadata department=legal,year=2026 contract.pdf
+remy-admin datasources search --source policies "what are the payment terms?"   # sanity-check
+remy-admin datasources search --source policies --filter department=legal --mode lexical "ERR-7741X"
+remy-admin datasources delete --source policies   # whole source; --source is required, never defaulted
 ```
 
 `--wait` blocks until processing finishes and exits non-zero on failure. Also `datasources list`, `status` (per-document state + ingest errors), `rm --document <id>`. `--help` for flags.
@@ -91,16 +91,16 @@ Images inside documents are described by a vision model and the description subs
 `rerank` and `hybrid` default on and are usually right — reranking is the biggest quality lever, and hybrid is what finds part numbers, error codes and proper nouns a semantic model never learned. Both are also per-query (`search(q, { rerank: false })`) for a latency-sensitive path.
 
 ```bash
-mindstudio-prod datasources config --source policies              # show
-mindstudio-prod datasources config --source policies --top-k 8    # free, immediate
+remy-admin datasources config --source policies              # show
+remy-admin datasources config --source policies --top-k 8    # free, immediate
 ```
 
 **A rebuild-class change on a populated corpus is rejected** — you're told what it would invalidate and what it costs. To make it, build a new version alongside the live one:
 
 ```bash
-mindstudio-prod datasources revectorize --source policies --max-chars 900 --wait
-mindstudio-prod datasources search --source policies --candidate "payment terms"   # compare
-mindstudio-prod datasources promote --source policies                              # go live
+remy-admin datasources revectorize --source policies --max-chars 900 --wait
+remy-admin datasources search --source policies --candidate "payment terms"   # compare
+remy-admin datasources promote --source policies                              # go live
 ```
 
 Search serves the current version throughout, so nothing degrades while the new one builds. `datasources drop` discards an unwanted candidate.

package/dist/prompt/skills/files.md

@@ -96,7 +96,7 @@ Lightweight-config pattern: a public store + a stable `key` is a file the fronte
 Need an image on the site (hero, logo, OG image)? **Never commit binaries to the repo** — it bloats git. Upload once and embed the returned URL:
 
 ```bash
-mindstudio-prod files put --public ./hero.jpg   # → { url, key } — content-addressed, immutable
+remy-admin files put --public ./hero.jpg   # → { url, key } — content-addressed, immutable
 ```
 Write that URL into your JSX/HTML. The full CLI surface: `put` (any size up to 5 GiB — bytes go directly to storage), `get` (download an object to disk), `sign` (mint a link), `stat` (metadata / existence), `ls` (objects in a store), `list` (store summary), `rm` (`--help` for flags).
 
@@ -105,9 +105,9 @@ Write that URL into your JSX/HTML. The full CLI surface: `put` (any size up to 5
 The sandbox is ephemeral; when a user needs a file out of it (an export, an archive, a handoff), the channel is a **private store + a signed link** — private, expiring, and revocable:
 
 ```bash
-mindstudio-prod files put --private --store handoff ./export.tar.gz          # → { key }
-mindstudio-prod files sign --private --store handoff --key <key> --ttl 86400 # → { url, expiresAt }
-mindstudio-prod files rm --store handoff --key <key> --private               # revoke when confirmed received
+remy-admin files put --private --store handoff ./export.tar.gz          # → { key }
+remy-admin files sign --private --store handoff --key <key> --ttl 86400 # → { url, expiresAt }
+remy-admin files rm --store handoff --key <key> --private               # revoke when confirmed received
 ```
 
 **Never use the account media CDN (`mindstudio upload`) for sensitive material — those URLs are public and permanent, with no delete.** That includes probing: don't test an upload channel with the real payload; use throwaway bytes.

package/dist/prompt/skills/inboundEmail.md

@@ -8,7 +8,7 @@ when: Before writing an email-handler method, adding an `email` interface, or pr
 
 Inbound email triggers. Each app has **one** email-handler method; the platform routes all inbound mail destined for the app — across any of its address tiers — to that method.
 
-The addresses themselves are configured at the project level by the user through the Remy platform. Your job is the `interface.json` and the method that handles the mail, not domain registration or MX records.
+The addresses themselves are configured at the project level. Your job in the app code is the `interface.json` and the method that handles the mail; custom domains (both directions) are provisioned outside the repo, via the `remy-admin email` CLI (see "Custom domains" below).
 
 ## Address tiers
 
@@ -17,12 +17,30 @@ Three tiers, all delivered to the same handler method. The new tiers are catchal
 | Tier | Address | How it's set up |
 |---|---|---|
 | Platform subdomain (default) | `*@<custom_subdomain>.madewithremy.com` | Automatic the moment the app has a `custom_subdomain` set. Every address on that subdomain delivers to the handler. |
-| Custom domain | `*@<their-domain>` | The user adds a domain in the dashboard's email-domains settings and points one MX record at `mx.msagent.ai`. Not something the agent provisions. |
+| Custom domain | `*@<their-domain>` | Registered via `remy-admin email inbound-domains add <domain>`; the user points one MX record at the platform (the command returns it). See "Custom domains" below. |
 | Legacy `mindstudio-hooks.com` | `<name>@mindstudio-hooks.com` | Existing apps only — frozen for new apps. Don't recommend it; treat as read-only history. |
 
 Because the new tiers are catchall, `to` carries an arbitrary localpart. Methods that need to branch on it should read `input.to` (e.g. `if (input.to.startsWith('support@')) ...`). This is what makes per-purpose addresses free: you don't register `support@` anywhere, you just check for it.
 
-A verified custom domain (and the app's `madewithremy.com` subdomain) also **sends** outbound mail, not just receives — `sendEmail` picks the app's own-brand sender automatically, configured in the dashboard's **Email** settings.
+A verified custom domain (and the app's `madewithremy.com` subdomain) also **sends** outbound mail, not just receives — `sendEmail` picks the app's own-brand sender automatically once a sending domain is verified.
+
+## Custom domains (agent-provisioned, via CLI)
+
+Both directions are set up with `remy-admin email`, and both follow the same loop: **add → hand the user the DNS records → verify → check status**. The user's only job is creating records at their DNS host.
+
+```bash
+# Sending (governs the From address; SES identity + DKIM):
+remy-admin email domains add mail.acme.com     # → dnsInstructions: 3 DKIM CNAMEs (required) + recommended SPF TXT
+remy-admin email domains verify mail.acme.com  # re-check now; uiStatus: pending | verified | action_needed
+remy-admin email domains list                  # all sending domains + effectiveSender (what the app sends as today)
+
+# Receiving (mail to *@their-domain reaches the email handler; one MX record):
+remy-admin email inbound-domains check acme.com  # returns the MX record before registering anything
+remy-admin email inbound-domains add acme.com
+remy-admin email inbound-domains verify acme.com
+```
+
+Give the user the exact records from the command output — never paraphrase DNS values. Verification is asynchronous after the records resolve (sending can take minutes; `action_needed` means check `verificationErrors` — sending verification expires unstarted after ~72h, fix and `verify` again).
 
 ## Config (`interface.json`)
 

package/dist/prompt/skills/jewels.md

@@ -233,11 +233,11 @@ on; default all history), `epochs` (1-10, default 3), `rank` (LoRA rank, 4-64, d
 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`). It returns immediately with
+`remy-admin jewels train <methodId>` (see `--help`). It returns immediately with
 a run id and the dataset report; a run takes minutes to tens of minutes, so never use
 `--wait` (that flag is for humans at a terminal — it would block your whole loop).
 Start the run, tell the user it's training, keep working on other things, and check in
-with `mindstudio-prod jewels run <runId>` between tasks — the `progress` field shows
+with `remy-admin jewels run <runId>` between tasks — the `progress` field shows
 the live phase and training percent, the run's `log` narrates the whole story as
 timestamped status events (queued, GPU acquired, training, grading — loss points are
 compacted to a count in CLI output), and `status` goes `complete` or `failed` with the
@@ -253,7 +253,7 @@ snapshots, plus a DPO pass over the team's corrections when enough have accumula
 and the platform promotes whichever scores highest on that grader — `report.selected`
 names the serving checkpoint; this is automatic, never something you configure.
 A completed run without a `grading` block just hasn't been graded yet
-(`mindstudio-prod jewels grade <runId>` fills it). A completed run registers the
+(`remy-admin jewels grade <runId>` fills it). A completed run registers the
 app's tuned model as a real model id — `tuned/{appId}/{methodId}`, one stable id per
 method that retraining advances in place — and the latest complete run per method is
 automatically served on the platform's GPU pool, so that id works like any other
@@ -336,7 +336,7 @@ What makes this safe with no extra machinery:
 - **Dismissal is not consumption**: the decision moment stays open for other verbs (a dismissed draft doesn't block a later merge). Unresolved items expire at the method's `attributionWindow`, so there's no infinite backlog.
 - `propose` returns `queueItemId` on `queued`, so the app can badge its UI or notify its own way the moment a draft lands.
 
-Before the app has its own review UI (or when the user asks you to act), the same queue is reachable from `mindstudio-prod jewels queue` / `jewels resolve`; approving there applies the method as the user through the identical machinery.
+Before the app has its own review UI (or when the user asks you to act), the same queue is reachable from `remy-admin jewels queue` / `jewels resolve`; approving there applies the method as the user through the identical machinery.
 
 ## Verifying a Jewel: the `testJewel` Tool
 
@@ -351,4 +351,4 @@ For cases with no known right answer, pass `subject` instead of `humanInput` for
 
 Each run also lands in `.logs/requests.ndjson` as a `type: 'jewel'` record if you need the trail.
 
-Once deployed, the prod-side view lives in `mindstudio-prod jewels` (run `--help` for commands): agreement stats, pair records, the approval queue, and `jewels dryrun`, the prod twin of `testJewel`. It runs the LIVE jewel against a real subject inside a disposable database mirror and records nothing.
+Once deployed, the prod-side view lives in `remy-admin jewels` (run `--help` for commands): agreement stats, pair records, the approval queue, and `jewels dryrun`, the prod twin of `testJewel`. It runs the LIVE jewel against a real subject inside a disposable database mirror and records nothing.

package/dist/prompt/skills/publishing.md

@@ -18,9 +18,9 @@ If dismissed, acknowledge and do nothing — no commit, no push.
 
 ## 2. Ship (on approval)
 
-- 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.
+- Stage and commit any uncommitted changes with a clean, descriptive commit message. If the committed work resolves any open issues (`remy-admin 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 wait` to poll the build until it completes. Let the user know it's deploying, then report back when it's live.
+- Use `remy-admin releases wait` to poll the build until it completes. Let the user know it's deploying, then report back when it's live.
 
 ## 3. Close out — scaled to what shipped
 
@@ -31,6 +31,6 @@ The changelog you just wrote is the measure.
 
 ## 4. Offer next steps
 
-Once deployed, offer to help with what comes next. This includes technical steps like setting 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); if it's a meaningful incremental update, an announcement post or something similar. 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 — help the user see that you care about the product from end-to-end, not just the code.
+Once deployed, offer to help with what comes next. This includes technical steps like setting up a custom domain (`remy-admin domains`), checking for errors (`remy-admin requests stats`), seeding production data (`remy-admin 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); if it's a meaningful incremental update, an announcement post or something similar. 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 — help the user see that you care about the product from end-to-end, not just the code.
 
 After everything is done, if this was a meaningful release, call `compactConversation` to summarize the session and free up context for the next phase of work. After a hotfix, don't bother.

package/dist/prompt/skills/scenarios.md

@@ -119,7 +119,7 @@ Scenarios are useful for seeding initial app state after build for testing, as w
 Don't try to seed documents into a data source from a scenario, and don't write `clear()`-style reset helpers for one. Load a test corpus once from the CLI instead:
 
 ```bash
-mindstudio-prod datasources add --source policies --wait fixtures/*.pdf
+remy-admin datasources add --source policies --wait fixtures/*.pdf
 ```
 
 Re-running it is free (documents are content-addressed), so it's safe to keep in a setup script beside your scenarios.

package/dist/prompt/skills/scheduledJobs.md

@@ -44,3 +44,14 @@ Declare it in `mindstudio.json`:
 Methods invoked through this interface run with `auth.roles: ['system']` — the platform is calling, not a user session, so there's no user to impersonate. Use `auth.requireRole('system')` to gate methods that should only be reachable on a schedule. The auth reference in your system prompt covers the system role in full.
 
 A scheduled job that needs to act on user data acts as the system, not as any user, so it reaches everything. Scope what it touches in the method itself rather than relying on role checks to narrow it.
+
+## Operating jobs in production
+
+The `remy-admin cron` group covers the live app's schedule without opening the dashboard:
+
+```bash
+remy-admin cron list              # every job: schedule, status (active|paused|blocked), next run, recent runs
+remy-admin cron run <methodId>    # trigger a run now (202 { requestId }; doesn't affect the schedule)
+```
+
+A run's id is its request-log id — debug a failing job with `remy-admin requests get <runId>`. Jobs that fail repeatedly become `blocked` (see `statusReason`) and stay stopped until fixed and redeployed.

package/dist/prompt/skills/secrets.md

@@ -37,7 +37,7 @@ Each secret has a dev value and a prod value. The same code (`process.env.STRIPE
 
 ## Management
 
-Secrets are managed through the app's dashboard or the `mindstudio-prod secrets` CLI.
+Secrets are managed through the app's dashboard or the `remy-admin secrets` CLI.
 
 ## What NOT to Store
 

package/dist/prompt/skills/voiceInterfaces.md

@@ -27,7 +27,7 @@ Beyond the mechanics, the persona itself should be *of the ear*: pacing, warmth,
 
 ### The shape of `system.md`
 
-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; 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.
+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; 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 — `remy-admin voice sessions get` reads a call verbatim) rather than front-loading a policy manual.
 
 ### The latency classes
 
@@ -211,7 +211,7 @@ export async function callMeAboutMyOrder(input: { phone: string }) {
 
 - **The method is the authorization gate.** The voice interface's `auth` block does not apply to calls the backend places deliberately — gate the *method* with `auth.requireRole(...)` exactly as you would any sensitive action.
 - **`assumeIdentity: true`** runs the call as the user who invoked the method: the agent knows who it's talking to (Current User block) and every tool call carries their roles — regardless of which number was dialed (the user types any number into a field; identity comes from their session, not the phone). Omitted/false → anonymous call; role-gated tools decline. System/cron invocations have no human identity and always run anonymously. Anonymous outbound calls (deployed) get the same in-call verification flow as inbound — the callee proves possession of the number that was dialed, or verifies by email — so an anonymous call can still upgrade to a known user mid-conversation.
-- **Production needs a dedicated phone number.** The app owner attaches one ($1/month) via the dashboard or `mindstudio-prod voice numbers` (see "The voice CLI" below) — it becomes the caller ID for every call, in dev sessions too, so users always see the same number. Without one, deployed calls throw `phone_out_requires_dedicated_number`, and dev sessions fall back to a shared platform test number that varies per call (tighter limits apply on the shared pool).
+- **Production needs a dedicated phone number.** The app owner attaches one ($1/month) via the dashboard or `remy-admin voice numbers` (see "The voice CLI" below) — it becomes the caller ID for every call, in dev sessions too, so users always see the same number. Without one, deployed calls throw `phone_out_requires_dedicated_number`, and dev sessions fall back to a shared platform test number that varies per call (tighter limits apply on the shared pool).
 - **Outcome is on the call record**, not the return value: `voice.call` returns as soon as dialing starts (`{ sessionId, status: 'dialing', from, to }`); answered/busy/no-answer land on the session in the app's call log (`voice.listSessions()` / the dashboard).
 - **Limits**: the app's concurrent-session policy, a daily outbound-call cap, a per-call duration ceiling, and one active call per callee number (`voice_callee_busy`).
 - **Compliance**: automated calls require prior consent. Call your own users who opted in to calls from this app, honor reasonable calling hours, never dial purchased or cold lists — design the consent moment into the product (a "call me" button IS consent; a scraped list is not).
@@ -242,14 +242,14 @@ A caller whose number exactly matches an app user's phone starts the call alread
 
 ## The voice CLI
 
-The `mindstudio-prod voice` family covers numbers, the call log, and voice policy:
+The `remy-admin voice` family covers numbers, the call log, and voice policy:
 
 ```bash
-mindstudio-prod voice numbers search --area-code 310   # available numbers to offer the user
-mindstudio-prod voice numbers buy +13105551234         # buy + attach ($1/month — see below)
-mindstudio-prod voice numbers release +13105551234     # permanent; no refund, ~15-day quarantine
-mindstudio-prod voice sessions list --limit 10         # call log: web / phone-out / phone-in
-mindstudio-prod voice sessions get <sessionId>         # full transcript + cost breakdown
+remy-admin voice numbers search --area-code 310   # available numbers to offer the user
+remy-admin voice numbers buy +13105551234         # buy + attach ($1/month — see below)
+remy-admin voice numbers release +13105551234     # permanent; no refund, ~15-day quarantine
+remy-admin voice sessions list --limit 10         # call log: web / phone-out / phone-in
+remy-admin voice sessions get <sessionId>         # full transcript + cost breakdown
 ```
 
 Also `voice numbers list`, `voice numbers set-name` (outbound caller-ID display name; 12-72h carrier propagation), `voice settings get`/`set` (concurrency, per-visitor, max duration — `set` merges: only the settings you pass change). `--help` for flags.

package/dist/prompt/static/coding.md

@@ -80,7 +80,7 @@ Before installing a package you haven't used in this project, do a quick web sea
 You have access to the `mindstudio` CLI, which exposes every SDK action as a command-line tool. Use it via bash for one-off tasks: generating images, video, or audio, scraping URLs, sending emails, running AI completions, or anything else the SDK can do. Every JavaScript SDK method has a corresponding CLI command. Run `askMindStudioSdk` to discover commands for CLI usage.
 
 ### Production App Management
-You have access to `mindstudio-prod`, a CLI for managing the user's production app. Use it via your bash tool. All output is JSON. Run `mindstudio-prod --help` or `mindstudio-prod <command> --help` to discover usage and available options.
+You have access to `remy-admin`, a CLI for managing the user's production app. Use it via your bash tool. All output is JSON. Run `remy-admin --help` or `remy-admin <command> --help` to discover usage and available options.
 
 Available commands: `requests` (server logs, errors, latency), `crashes` (frontend browser errors), `analytics` (traffic queries — lifetime metrics, sources, live counters), `releases`, `diagnostics` (Lighthouse audit), `domains`, `users` (list, set roles), `db` (query production sql), `data` (live db operations like lift-from-dev), `methods` (list, invoke), `secrets`, `files` (CDN files), `datasources` (document corpora), `prerender` (crawler snapshots), `voice` (phone numbers, call logs, voice policy), `issues` (externally-reported bugs), `settings` (app settings: signup restrictions, app-store-reviewer test accounts, embedding origins, toggles).
 

package/dist/prompt/static/instructions.md

@@ -15,7 +15,7 @@
 - After two failed attempts at the same approach, tell the user what's going wrong.
 - Never estimate how long something will take or how much it will cost. Just do it. If the user asks, politely refuse — any number would be a guess. Never quote concrete time units for work you're about to do. You can describe scope qualitatively (small change, large refactor, etc.), but never estimate the time it will take you to do work.
 - Pushing to main branch will trigger a production deploy. Publishing happens at the user's ask — the Publish button or an explicit request in chat — and the release has its own playbook: load the `publishing` skill before presenting a changelog or pushing to main.
-- Pushing any OTHER branch builds a preview instead of deploying: a private copy of the app at its own URL, with its own copy of the data, that anyone who can open the app in Remy can visit. `mindstudio-prod releases wait` returns its `previewUrl`. Use this to show the user working software before it goes live — a branch push plus the link is often a better answer than describing what you built.
+- Pushing any OTHER branch builds a preview instead of deploying: a private copy of the app at its own URL, with its own copy of the data, that anyone who can open the app in Remy can visit. `remy-admin releases wait` returns its `previewUrl`. Use this to show the user working software before it goes live — a branch push plus the link is often a better answer than describing what you built.
 
 ### Build Notes
 For complex tasks — especially an initial buildout from a spec or making multiple changes in a single turn — write a `.remy-notes.md` scratchpad in the project root. Use it to track progress: a checklist of what's been built and what's remaining. Do not include implementation details or other decisions in the notes - it is solely for keeping track of tasks. Read the spec files directly when you need design details, implementation decisions, or other reference materials - never write them to the notes file. Delete the notes file when your work is done. When implementing an approved plan, `.remy-plan.md` serves as your reference. Delete it when all planned work is complete.

package/dist/subagents/codeSanityCheck/prompt.md

@@ -38,7 +38,8 @@ These are things we already know about and have decided to accept:
 - Preferences:
   - use [wouter](https://github.com/molefrog/wouter) for React routing instead of reaching for react-router
   - uploading user files should always happen via `platform.uploadFile()` from `@mindstudio-ai/interface` — not custom S3 code, not FormData to a method endpoint
-  - for static prerendering of Vite + React sites, roll your own with a post-build `renderToString` script — do not use `vite-prerender-plugin` (it bundles the prerender script as a client chunk, adding ~800KB to the user-facing bundle with no way to prevent it)
+  - for build-time prerendering of purely static sites (marketing pages with no dynamic content — distinct from the platform's crawler prerendering, below), roll your own with a post-build `renderToString` script — do not use `vite-prerender-plugin` (it bundles the prerender script as a client chunk, adding ~800KB to the user-facing bundle with no way to prevent it)
+  - **Prerendering for crawlers/unfurlers is a platform feature — don't design around it.** For SEO / link-unfurl / AI-crawler visibility on a non-static SPA, the platform already handles it: routes opt in via `web.json` (`{ "web": { "prerender": { "paths": ["/blog/*"] } } }`), the SPA signals readiness by setting `data-prerender-ready` on the html element, deploys invalidate the snapshot cache automatically, and content that changes outside deploys is invalidated at runtime with `await prerender.invalidate([...])` from `@mindstudio-ai/agent` (called from the mutating method). It serves cached headless snapshots of the live SPA to bots — it is NOT build-time rendering. Do not recommend post-build render scripts, rebuild-on-content-change, or third-party prerender services for this. The developer's main context carries the full interfaces reference with exact semantics — tell them to consult it rather than improvising.
 
 ### Common pitfalls (always flag these)
 
@@ -93,7 +94,7 @@ When a plan includes multiple screens/API calls, always note this item for the d
 
 If you get a whiff of any of the following, make a note for the developer:
 
-- **Stripe**: The developer has access to the Stripe CLI via bash (they'll need to get the secret key from mindstudio-prod CLI first to set it up - it's not available in env directly). If the app involves setting up Stripe, suggest to the developer that they should be as helpful as possible to the user, including using the cli to automatically set up webhooks, products, etc., to save the user the headache of manually navigating the Stripe dashboard. Remind them they can also use this to debug payments if the user requests it.
+- **Stripe**: The developer has access to the Stripe CLI via bash (they'll need to get the secret key from remy-admin CLI first to set it up - it's not available in env directly). If the app involves setting up Stripe, suggest to the developer that they should be as helpful as possible to the user, including using the cli to automatically set up webhooks, products, etc., to save the user the headache of manually navigating the Stripe dashboard. Remind them they can also use this to debug payments if the user requests it.
 
 - **Long-running AI jobs.** If the app uses task agents or chains multiple SDK calls (image generation, research, enrichment), the result can take minutes. Never leave the user staring at a spinner. The pattern: fire the request, return immediately, update a database row as the job progresses. At minimum, track status on the relevant record (`processing` → `done` / `failed`). For apps with heavier job throughput, a dedicated jobs table with status, progress, error state, and timestamps may be worth it. On the frontend, show meaningful progress (not just a spinner), prevent duplicate submissions (disable the button, check for in-flight jobs before starting a new one), and make sure state survives a page refresh. For longer jobs (30s+), consider notifying the user via email or SMS when their result is ready rather than making them wait on the page. Store errors visibly so failed jobs don't just silently disappear.
 

package/package.json

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