@mindstudio-ai/remy 0.1.208 → 0.1.210

package/dist/prompt/compiled/auth.md

@@ -34,6 +34,7 @@ Remy apps can have and manage their own users. Auth is opt-in: configure it in t
   - `email-code` — 6-digit code sent via email
   - `sms-code` — 6-digit code sent via SMS
   - `api-key` — programmatic access via `Authorization: Bearer sk_...` header. Resolves to a user with full RBAC.
+  - `remy` — platform-delegated sign-in ("Sign in with Remy"). The platform resolves who the user is; roles and verification are platform-managed. Only usable when the app's owning organization has it enabled — the `<org_auth_context>` block signals availability. See *Organization-Managed Sign-In* above.
 - **`auth.table.name`** — name of the `defineTable` table that holds user records.
 - **`auth.table.columns`** — maps platform-managed fields to column names in the developer's table.
   - `email` — required if `email-code` is in methods
@@ -85,6 +86,7 @@ interface AppUser {
   phone: string | null;
   roles: string[];
   apiKey: string | null;    // masked value (sk_...xxxx), null if no key
+  provider?: 'remy' | null; // 'remy' = delegated sign-in (platform-managed); null/absent = app-verified
   createdAt: string;
 }
 ```
@@ -128,6 +130,30 @@ const { verificationId } = await auth.sendSmsCode('+15551234567');
 const user = await auth.verifySmsCode(verificationId, '123456');
 ```
 
+## Organization-Managed Sign-In ("Sign in with Remy")
+
+Some apps are owned by an organization that centralizes sign-in. When that applies to the current app, the system prompt includes an `<org_auth_context>` block (near the end) stating the organization name and whether delegated sign-in is available. Sign in with Remy is a way to make authentication seamless for internal apps - it should not be used for public-facing applications. The app owner will need to add users to their workspace's team on the Remy platform and those users will need Remy accounts for it to work.
+
+- **When it says "Sign in with Remy" is available** — offer delegated sign-in: a **"Continue with {Org}"** button wired to the `remy` method (see *Sign in with Remy (delegated)* below). Use the exact organization name from the block for the label. For an org-owned app this is usually the primary sign-in — the members already have platform identities, so a verification-code form is redundant.
+- **When it says the organization requires delegated sign-in** — `remy` is the *only* human method: do not add `email-code` or `sms-code`. Those are blocked at the platform edge for the org's apps, so building them yields a login that can't work.
+
+When no `<org_auth_context>` block is present — the common case — do not build it or offer to build it. This is an auth scheme for enterprises building internal apps only, and it requires a Remy enterprise plan to use. When enabled, the platform decides who the user is (like "Sign in with Google"); the app just starts the flow and reads the result.
+
+```typescript
+// "Continue with {Org}" button — must be triggered by a user gesture (click).
+<button onClick={() => auth.signInWithRemy()}>Continue with Acme</button>
+
+// Call once on app load — completes sign-in when the user returns from the
+// handshake, or when the app is opened from the Remy dashboard. No-op when
+// there's no code to redeem, so it's safe to run on every mount.
+useEffect(() => { auth.handleRemyRedirect(); }, []);
+useEffect(() => auth.onAuthStateChanged(setUser), []);
+```
+
+- `auth.signInWithRemy(options?)` → `Promise<AppUser | null>`. Auto-detects context: a top-level app redirects to the platform and back — **the page navigates away, so the promise never settles; don't await it to gate UI**. An app embedded in a cross-origin iframe (the dev IDE preview) uses a popup and the promise resolves with the user (or `null` if the popup is closed). Options: `redirectUri` (default current URL), `state` (CSRF, auto-generated), `mode: 'auto' | 'popup' | 'redirect'` (default `'auto'` — leave it). Because of the redirect case, **drive UI off `onAuthStateChanged`, not the return value.**
+- `auth.handleRemyRedirect()` → `Promise<AppUser | null>`. Call once on load. Handles both the "Continue with {Org}" return and being opened from the Remy dashboard; on success it updates the session in-place (fires `onAuthStateChanged`) and cleans the URL.
+- Delegated users have `provider: 'remy'`. Their **roles and email are platform-managed** (like `email`/`phone` for code users) — enforce access with `requireRole`/`hasRole` on the backend as usual, but don't assign roles from app code; the platform owns them.
+
 ### Email/Phone Changes (must be authenticated)
 
 ```typescript
@@ -360,6 +386,8 @@ Consult the `visualDesignExpert` to help you work through authentication at a hi
 ### Rules for Building Auth Screens
 **Auth modes:** Think about which mode(s) makes the most sense for the type of app you are building. Consumer apps likely to be used on mobile should probably tend toward SMS auth as the default - business apps used on desktop make more sense to use email verification - or allow both, there's no harm in giving the user choice!
 
+**"Continue with {Org}" (delegated):** When `<org_auth_context>` says delegated sign-in is available, a single "Continue with {Org}" button is the primary path — often the *only* one — and there's no verification-code step to design at all (the platform handles it). Give the button real weight in the branded login moment rather than treating it as a secondary option, and use the exact organization name. If the org also allows code methods, delegated goes first with the code form beneath.
+
 **Verification code input:** The 6-digit code entry is the critical moment. Prefer to design it as individual digit boxes (not a single text input), with auto-advance between digits, a beautiful animation and auto-submit on paste, and clear visual feedback. The boxes should be large enough to tap easily on mobile. Show a subtle animation on successful verification. Error states should be inline and immediate, not a separate alert. Make sure there is no layout shift when loading in the success/error states - loading spinners must never pop in below the input and shift the content, for example.
 
 **The send/resend flow:** After the user enters their email or phone and taps "Send code," show clear confirmation that the code was sent ("Check your email" with the address displayed). Include a resend option with a cooldown timer (e.g., "Resend in 30s"). The transition from "enter email/phone" to "enter code" should feel smooth, not like a page reload. Always make sure the user can cancel and exit the flow (e.g., they had a typo in their email, or remembered they used a different email to sign up).

package/dist/prompt/compiled/manifest.md

@@ -71,7 +71,7 @@
 | Field | Type | Required | Description |
 |-------|------|----------|-------------|
 | `enabled` | `boolean` | Yes | `true` to enable auth |
-| `methods` | `string[]` | Yes | Auth methods: `"email-code"`, `"sms-code"`, `"api-key"`. At least one required. |
+| `methods` | `string[]` | Yes | Auth methods: `"email-code"`, `"sms-code"`, `"api-key"`, `"remy"` (platform-delegated sign-in, org-owned apps). At least one required. |
 | `table.name` | `string` | Yes | Name of the `defineTable` table holding user records |
 | `table.columns.email` | `string` | If email-code | Column name for email (platform-managed, read-only from code) |
 | `table.columns.phone` | `string` | If sms-code | Column name for phone (platform-managed, read-only from code) |

package/dist/prompt/static/coding.md

@@ -41,6 +41,7 @@ When writing `db` filter predicates that reference outer-scope values (`input.*`
 - Frontend interfaces are always untrusted. Always enforce auth in backend methods. Use frontend auth and role information as a hint to conditionally show/hide UI to make the experience pleasant and seamless for users depending on their state, but remember to always use backend methods for gating data that is conditional on auth.
 - 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). See the auth docs.
 - 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.
 
 ### CSS & Layout

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

@@ -18,7 +18,9 @@ When specifying sheets, drawers, modals, or any surface that slides/fades into v
 
 Login and signup screens set the tone for the user's entire experience with the app and are important to get right - they should feel like exciting entry points into the next level of the user journy. A janky login form with misaligned inputs and no feedback dminishes excitement and undermines trust before the user even gets in.
 
-Authentication moments must feel natural and intuitive - they should not feel jarring or surprising. Take care to integrate them into the entire experience when building. Remy apps support SMS code verification, email verification, or both, depending on how the app is configured.
+Authentication moments must feel natural and intuitive - they should not feel jarring or surprising. Take care to integrate them into the entire experience when building. Remy apps support SMS code verification, email verification, delegated "Sign in with Remy", or a combination, depending on how the app is configured.
+
+**"Continue with {Org}" (delegated sign-in):** Some apps are internal business tools that are owned by an organization and sign members in through the platform — a single "Continue with {Org}" button, no verification-code step at all. For these apps this button is often the primary (sometimes only) path, so give it real presence in the branded login moment rather than tucking it away, and label it with the organization's actual name. If the app also offers code methods, lead with the delegated button and place the code form beneath. This scheme should ONLY be used for internal apps AND when it is explicitly enabled in <org_auth_context> - it should not be used for public-facing apps.
 
 **Verification code input:** The 6-digit code entry is the critical moment. Prefer to design it as individual digit boxes (not a single text input), with auto-advance between digits, auto-submit on paste, and clear visual feedback. The boxes should be large enough to tap easily on mobile. Show a subtle animation on successful verification. Error states should be inline and immediate, not a separate alert.
 

package/package.json

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