@mindstudio-ai/remy 0.1.290 → 0.1.292

package/dist/headless.js

@@ -5649,7 +5649,7 @@ var WIREFRAMES_DIR = "src/.wireframes";
 var UPLOAD_TIMEOUT_MS2 = 3e4;
 var definition10 = {
   name: "createWireframe",
-  description: "Create (or revise) a wireframe from self-contained HTML+CSS. Call this while working to generate a sharable wireframe asset: the result returns the exact markdown reference line to paste into your response and into specs (like generateImages returns the image URL). Calling again with the same slug overwrites the wireframe in place, so a revision keeps its path and existing references stay current.",
+  description: "Generate a wireframe from self-contained HTML+CSS you author and write it to disk as a design artifact. This is how a wireframe comes to exist \u2014 the way generateImages is how an image comes to exist \u2014 and the developer builds from the file it creates. The result also hands back the reference line that embeds the wireframe in your response and in specs; paste it wherever the wireframe belongs and it renders as a live preview. Calling again with the same slug revises the wireframe in place, so existing references stay current.",
   inputSchema: {
     type: "object",
     properties: {
@@ -5659,7 +5659,7 @@ var definition10 = {
       },
       slug: {
         type: "string",
-        description: 'Filename stem, lowercase kebab-case (e.g. "feed-post-card"). The wireframe lives at src/.wireframes/{slug}.html. Re-use a slug to revise that wireframe in place.'
+        description: 'Filename stem, lowercase kebab-case (e.g. "feed-post-card"). Re-use a slug to revise that wireframe in place.'
       },
       description: {
         type: "string",

package/dist/index.js

@@ -6951,7 +6951,7 @@ var init_createWireframe = __esm({
     UPLOAD_TIMEOUT_MS2 = 3e4;
     definition10 = {
       name: "createWireframe",
-      description: "Create (or revise) a wireframe from self-contained HTML+CSS. Call this while working to generate a sharable wireframe asset: the result returns the exact markdown reference line to paste into your response and into specs (like generateImages returns the image URL). Calling again with the same slug overwrites the wireframe in place, so a revision keeps its path and existing references stay current.",
+      description: "Generate a wireframe from self-contained HTML+CSS you author and write it to disk as a design artifact. This is how a wireframe comes to exist \u2014 the way generateImages is how an image comes to exist \u2014 and the developer builds from the file it creates. The result also hands back the reference line that embeds the wireframe in your response and in specs; paste it wherever the wireframe belongs and it renders as a live preview. Calling again with the same slug revises the wireframe in place, so existing references stay current.",
       inputSchema: {
         type: "object",
         properties: {
@@ -6961,7 +6961,7 @@ var init_createWireframe = __esm({
           },
           slug: {
             type: "string",
-            description: 'Filename stem, lowercase kebab-case (e.g. "feed-post-card"). The wireframe lives at src/.wireframes/{slug}.html. Re-use a slug to revise that wireframe in place.'
+            description: 'Filename stem, lowercase kebab-case (e.g. "feed-post-card"). Re-use a slug to revise that wireframe in place.'
           },
           description: {
             type: "string",

package/dist/prompt/compiled/auth.md

@@ -13,6 +13,8 @@ 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.
+
 ## Backend Enforcement
 
 ```typescript

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

@@ -42,6 +42,8 @@ The platform builds and deploys automatically:
 
 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.
 
+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.
+
 ### 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.

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 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 `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.
 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.
 ---
 
@@ -49,6 +49,35 @@ Remy apps can have and manage their own users. Auth is opt-in: configure it in t
   - `apiKey` — optional. Required if `api-key` is in methods. Platform stores masked value (`sk_...xxxx`) for display; one key per user.
 - **`roles`** — declares valid roles for the app. Same as before: `id`, `name`, optional `description`.
 
+## 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).
+
+**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
+```
+
+- 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).
+- Enforcement needs both the enable toggle AND a non-empty list — an enabled-but-empty list allows everyone, never a lockout.
+- **Email-code only.** It does not apply to `sms-code`, `api-key`, or delegated "Sign in with Remy". If the user wants domain restriction on an SMS-auth app, say so plainly and suggest email-code — do not build an app-level imitation.
+- 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`.
+
+**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
+# after review:
+mindstudio-prod settings test-accounts disable
+```
+
 ## Auth Table
 
 The user table is a regular `defineTable` table. The platform manages the auth-mapped columns; all other columns are the developer's domain.
@@ -211,6 +240,8 @@ All auth methods throw on failure with a `code` property:
 | Code | HTTP | Meaning |
 |------|------|---------|
 | `rate_limited` | 429 | Too many requests |
+| `email_not_allowed` | 400 | Signup allowlist is enforced and this email doesn't match — show a clear "this app is restricted" message |
+| `disposable_email_blocked` | 400 | Disposable/burner email domain rejected at code send — ask for a personal or work email |
 | `invalid_code` | 400 | Wrong verification code |
 | `verification_expired` | 400 | Code has expired |
 | `max_attempts_exceeded` | 400 | Too many failed attempts |
@@ -428,10 +459,10 @@ Auth works the same in dev/preview as in production — real verification codes
 - **Email:** `remy@mindstudio.ai` — verification code is always `123456`
 - **Phone:** any `555` number (e.g. `+15551234567`) — verification code is always `123456`
 
-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.
+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. (These dev bypasses work in dev sessions only and exist for you — they're distinct from *test accounts*, the platform setting for giving external reviewers a fixed-code login that works in production; see *Restricting Who Can Sign Up*.)
 
 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.
+For **"Sign in with Remy"** apps (`auth.methods` is `["remy"]`, with no `email-code`/`sms-code`), `testUser` — and `setupBrowser`, and the editor's Roles column — 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/static/coding.md

@@ -82,7 +82,7 @@ You have access to the `mindstudio` CLI, which exposes every SDK action as a com
 ### 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.
 
-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).
+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).
 
 Two rules: buying a `voice` phone number bills $1/month — never buy without the user's explicit confirmation. `issues` is for externally-reported bugs only — read from it and resolve items when the user asks; never use it to track work you are doing with the user.
 

package/dist/subagents/designExpert/prompts/instructions.md

@@ -16,7 +16,7 @@ Think about the ways you can truly elevate the design. Use image generation to c
 - After you've taken a screenshot, use analyze image to ask different questions about it - don't re-screenshot the page unnecessarily.
 - Match the image engine to the job: `renderImage` (a browser rendering HTML you author) for token-exact graphics — share cards, wordmarks, flat icon tiles; `generateImages` (an image model) for organic, photographic, and illustrated work. Don't ask the image model to hit exact hex codes or typography, and don't hand-write SVG path data — compose HTML/CSS and render it.
 - When you write user-facing copy (headlines, captions, labels, body text), hand it to `polishCopy` before finalizing. It tightens prose so it reads like a person wrote it rather than a machine, without changing what it says. Cheap and fast — use it on any copy that will ship.
-- Build wireframes with `createWireframe` during your working phase as you work out a layout, component, or interaction. Creating wireframes is how you create interactive assets to share back to the user, like how you generate images. The result returns the exact `![name](src/.wireframes/{slug}.html)` reference line; paste it into your response where the wireframe belongs. It renders as a live preview, and the developer reads the file for the exact markup. Same slug = revise in place; new slug = new wireframe.
+- Build wireframes with `createWireframe` during your working phase as you work out a layout, component, or interaction. The tool generates the wireframe as a real asset, the way `generateImages` generates images: it writes the file the developer builds from, and its result hands back the reference line that embeds the wireframe in your response. Paste that line where the wireframe belongs and it renders as a live preview. Same slug = revise in place; new slug = new wireframe.
 
 ## Voice
 - No emoji, no filler.

package/dist/subagents/designExpert/prompts/ui-patterns.md

@@ -25,7 +25,7 @@ Some surfaces are deep enough to carry their own craft reference in <available_s
 
 ### Wireframes
 
-Wireframes are design artifacts you build while you work, in the same phase as screenshots and image generation. As you work out a layout, a card anatomy, an interaction, or a motion pattern, build it with `createWireframe`: a `name`, a kebab-case `slug`, a one-line `description`, and self-contained HTML+CSS. Sketching in HTML is how you think through spatial decisions, so by the time you write your direction, the wireframes that anchor it already exist. The tool result returns the exact markdown reference line (`![Feed Post Card](src/.wireframes/feed-post-card.html)`) — when you write your response, paste that line wherever the wireframe belongs, with your notes in the surrounding prose. The reference renders as a live visual preview, and the developer reads the file itself for the exact markup and CSS.
+Wireframes are design artifacts you build while you work, in the same phase as screenshots and image generation. As you work out a layout, a card anatomy, an interaction, or a motion pattern, build it with `createWireframe`: a `name`, a kebab-case `slug`, a one-line `description`, and self-contained HTML+CSS. Sketching in HTML is how you think through spatial decisions, so by the time you write your direction, the wireframes that anchor it already exist as files — the developer reads them for the exact markup and CSS. Each call's result hands back the markdown reference line that embeds that wireframe; when you write your response, paste it wherever the wireframe belongs, with your notes in the surrounding prose, and it renders as a live visual preview.
 
 Never use ASCII art, box-drawing characters, or code-block diagrams to describe layouts. Always use a wireframe instead, even if it's just grey rectangles with labels. A 20-line wireframe with placeholder boxes communicates proportions, spacing, and hierarchy better than any text diagram. For abstract layouts, use skeleton-style placeholders (grey boxes, rounded rects) rather than mocking up real content.
 

package/package.json

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