@mindstudio-ai/remy 0.1.121 → 0.1.123

package/dist/headless.js

@@ -378,6 +378,10 @@ Current date: ${now}
   <scenarios>
   {{compiled/scenarios.md}}
   </scenarios>
+
+  <secrets>
+  {{compiled/secrets.md}}
+  </secrets>
 </platform_docs>
 
 <mindstudio_agent_sdk_docs>
@@ -4056,6 +4060,7 @@ TypeScript running in a sandboxed environment. Any npm package can be installed.
 
 - Managed SQLite database with typed schemas and automatic migrations. Define a TypeScript interface, push, and the platform handles diffing and migrating.
 - Built-in app-managed auth. Opt-in via manifest \u2014 developer builds login UI, platform handles verification codes (email/SMS), cookie sessions, and role enforcement. Backend methods use auth.requireRole() for access control.
+- Encrypted secrets with separate dev/prod values, injected as process.env. For third-party service credentials not covered by the SDK.
 - Git-native deployment. Push to default branch to deploy.
 
 ## MindStudio SDK

package/dist/index.js

@@ -3941,6 +3941,7 @@ TypeScript running in a sandboxed environment. Any npm package can be installed.
 
 - Managed SQLite database with typed schemas and automatic migrations. Define a TypeScript interface, push, and the platform handles diffing and migrating.
 - Built-in app-managed auth. Opt-in via manifest \u2014 developer builds login UI, platform handles verification codes (email/SMS), cookie sessions, and role enforcement. Backend methods use auth.requireRole() for access control.
+- Encrypted secrets with separate dev/prod values, injected as process.env. For third-party service credentials not covered by the SDK.
 - Git-native deployment. Push to default branch to deploy.
 
 ## MindStudio SDK
@@ -5938,6 +5939,10 @@ Current date: ${now}
   <scenarios>
   {{compiled/scenarios.md}}
   </scenarios>
+
+  <secrets>
+  {{compiled/secrets.md}}
+  </secrets>
 </platform_docs>
 
 <mindstudio_agent_sdk_docs>

package/dist/prompt/compiled/auth.md

@@ -16,7 +16,8 @@ MindStudio apps can have and manage their own users. Auth is opt-in: configure i
       "columns": {
         "email": "email",
         "phone": "phone",
-        "roles": "roles"
+        "roles": "roles",
+        "apiKey": "apiKey"
       }
     }
   },
@@ -32,11 +33,13 @@ MindStudio apps can have and manage their own users. Auth is opt-in: configure i
 - **`auth.methods`** — which verification methods the app supports. At least one required.
   - `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.
 - **`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
   - `phone` — required if `sms-code` is in methods
   - `roles` — optional. Maps to a JSON array column for role assignments.
+  - `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`.
 
 ## Auth Table
@@ -51,6 +54,7 @@ export const Users = db.defineTable<{
   email: string;
   phone?: string;
   roles: string[];
+  apiKey?: string;       // masked value (sk_...xxxx), read-only from code
   // Developer's own fields
   displayName: string;
   plan: 'free' | 'pro';
@@ -60,7 +64,7 @@ export const Users = db.defineTable<{
 
 ### Platform-Managed Column Behavior
 
-- **`email` / `phone`** — read-only from code. Writing via `update()` or `push()` throws a `MindStudioError`. Use the auth API to change a user's email or phone.
+- **`email` / `phone` / `apiKey`** — read-only from code. Writing via `update()` or `push()` throws a `MindStudioError`. Use the auth API to change a user's email or phone, and `auth.createApiKey()` / `auth.revokeApiKey()` for API keys.
 - **`roles`** — read/write from both code and the dashboard. `Users.update(userId, { roles: ['admin'] })` works and syncs to the platform. Dashboard role changes sync back to the table.
 - All other columns are fully the developer's. When auth creates a user row, only the managed columns (email/phone, roles) are populated. All user-defined columns start as null until the user completes onboarding — type them as optional and guard against null.
 
@@ -80,6 +84,7 @@ interface AppUser {
   email: string | null;
   phone: string | null;
   roles: string[];
+  apiKey: string | null;    // masked value (sk_...xxxx), null if no key
   createdAt: string;
 }
 ```
@@ -139,6 +144,24 @@ const user = await auth.confirmPhoneChange('+15559876543', '123456');
 await auth.logout();  // clears session
 ```
 
+### API Keys
+
+For apps with `api-key` in their auth methods. API keys resolve to a user with the same `auth.userId`, `auth.roles`, and `requireRole()` enforcement as a cookie session.
+
+```typescript
+// Generate a key for the current user (must be logged in)
+const { key } = await auth.createApiKey();
+// key = "sk_..." — show once, not stored. user.apiKey updates to masked value.
+
+// Revoke current user's key
+await auth.revokeApiKey();
+// user.apiKey becomes null
+```
+
+Both methods fire `onAuthStateChanged` since they modify the user object. One key per user — creating a new key replaces the old one.
+
+Consumers use the key as a Bearer token: `Authorization: Bearer sk_...`. The platform resolves it to the user, populates the auth context, and executes the method normally. Invalid or revoked key: 401.
+
 ### Error Codes
 
 All auth methods throw on failure with a `code` property:
@@ -151,6 +174,7 @@ All auth methods throw on failure with a `code` property:
 | `max_attempts_exceeded` | 400 | Too many failed attempts |
 | `not_authenticated` | 401 | No active session |
 | `invalid_session` | 401 | Session expired or invalid |
+| `not_supported` | 400 | Feature not enabled for this app (e.g. API keys without `api-key` in methods) |
 
 ### Phone Helpers
 
@@ -200,6 +224,19 @@ Array of role IDs assigned to the current user.
 
 Returns an array of user IDs with the specified role.
 
+### System Role (Platform Triggers)
+
+When the platform invokes a method on behalf of the app (cron, webhook, email, Discord, Telegram), the execution runs as a system user with `auth.roles: ['system']`. Use `auth.requireRole('system')` to restrict methods to platform triggers only:
+
+```typescript
+export async function regenerateCache(input: {}) {
+  auth.requireRole('system');
+  // Only cron, webhooks, and users with 'system' role can reach this
+}
+```
+
+Web frontend calls (`/_/methods`), API interface calls (`/_/api`), and agent chat all run as the authenticated user — they don't get the system role unless the user has been explicitly assigned it. You can assign `system` to app users via the dashboard or SDK if they need to manually trigger these methods.
+
 ## Login Page Example
 
 ```tsx

package/dist/prompt/compiled/design.md

@@ -98,7 +98,7 @@ Even if the app is intuitive and easy to use, users showing up for the first tim
 ## What to Actively Avoid At All Costs
 
 - **Avoid generic fonts.** Overused defaults that strip away all personality. Instead: pick a distinctive Google Font that fits the app's character.
-- **Avoid purple or indigo anything.** Purple gradients, purple buttons, purple accents are overused. The user will be dismissive of our designs if they come out looking purple or indigo.
+- **Avoid purple or indigo anything.** Purple gradients, purple buttons, purple accents are overused. The user will be dismissive of our designs if they come out looking purple or indigo. Avoid terracotta for similar reasons.
 - **Avoid colored left-border callout boxes.** Rounded divs with a thick colored `border-left` — the generic "info card" pattern. Instead: use typography, spacing, and background tints to create hierarchy. If you need to call something out, use a full subtle background or a top border.
 - **Avoid three equal boxes with icons.** The default AI landing page layout. Instead: use asymmetric layouts, varied column widths, or a single focused content area.
 - **Avoid timid color palettes.** Evenly distributed, non-committal colors. Instead: one or two dominant colors with sharp accents. Commit to a direction.

package/dist/prompt/compiled/interfaces.md

@@ -94,36 +94,135 @@ On deploy, the platform runs `npm install && npm run build` in the web directory
 
 ## API Interface
 
-Auto-generated REST endpoints. Every method becomes an API endpoint.
+REST endpoints for external consumers — other services, mobile apps, integrations. This is separate from the web frontend's internal RPC (`@mindstudio-ai/interface` calls `/_/methods` directly and does not use the API interface). The API interface lives at `/_/api/` and exposes only the methods you choose to route.
 
-### Config (`interface.json`)
+Use it for receiving webhooks (Stripe, Twilio), sync endpoints for other services, a public REST API, batch tools — anything where something outside the app's own frontend needs to call a method over HTTP.
 
-```json
-{
-  "methods": ["submit-vendor-request", "list-vendors", "get-dashboard"]
-}
-```
+### Spec: `src/interfaces/api.md`
 
-Omit the `methods` field (or the config entirely) to expose all methods.
+The human-readable spec. Frontmatter declares the API name and description; the body maps methods to REST routes using MSFM.
 
-### Usage
+```yaml
+---
+name: Vendor Management API
+description: API for managing vendors and purchase orders.
+type: interface/api
+---
+```
 
-```bash
-curl -X POST https://{app-subdomain}.mindstudio.ai/_/methods/submit-vendor-request/invoke \
-  -H "Authorization: Bearer sk..." \
-  -H "Content-Type: application/json" \
-  -d '{ "input": { "name": "Acme" } }'
+Routes are declared as `VERB /path → methodExportName` under resource headings, with annotations for params and descriptions:
+
+```markdown
+## Vendors
+
+### List vendors
+GET /vendors → listVendors
+~~~
+Returns all vendors, optionally filtered by status.
+query: status (string, optional) — filter by vendor status
+~~~
+
+### Create vendor
+POST /vendors → submitVendorRequest
+~~~
+Submit a new vendor for approval.
+body: name (string, required) — vendor name
+      contactEmail (string, required) — billing contact
+~~~
+
+### Delete vendor
+DELETE /vendors/:vendorId → deleteVendor
+~~~
+path: vendorId (string, required) — the vendor's unique identifier
+~~~
 ```
 
-Auth via API key. Returns `{ output, $releaseId, $methodId }`.
+### Compiled Output: `dist/interfaces/api/api.json`
 
-### Streaming
+```json
+{
+  "api": {
+    "name": "Vendor Management API",
+    "description": "API for managing vendors and purchase orders.",
+    "routes": [
+      {
+        "method": "GET",
+        "path": "/vendors",
+        "handler": "list-vendors",
+        "summary": "List vendors",
+        "description": "Returns all vendors, optionally filtered by status.",
+        "tag": "Vendors",
+        "params": {
+          "query": {
+            "status": { "type": "string", "required": false, "description": "Filter by vendor status" }
+          }
+        }
+      },
+      {
+        "method": "POST",
+        "path": "/vendors",
+        "handler": "submit-vendor-request",
+        "summary": "Create vendor",
+        "description": "Submit a new vendor for approval.",
+        "tag": "Vendors",
+        "params": {
+          "body": {
+            "name": { "type": "string", "required": true, "description": "Vendor name" },
+            "contactEmail": { "type": "string", "required": true, "description": "Billing contact" }
+          }
+        }
+      },
+      {
+        "method": "DELETE",
+        "path": "/vendors/:vendorId",
+        "handler": "delete-vendor",
+        "summary": "Delete vendor",
+        "description": "Permanently remove a vendor.",
+        "tag": "Vendors",
+        "params": {
+          "path": {
+            "vendorId": { "type": "string", "required": true, "description": "The vendor's unique identifier" }
+          }
+        }
+      }
+    ]
+  }
+}
+```
 
-```bash
-curl -X POST ... -d '{ "input": {...}, "stream": true }'
+| Field | Description |
+|-------|-------------|
+| `name` | API display name (used in generated OpenAPI spec) |
+| `description` | API description |
+| `routes[].method` | HTTP method: `GET`, `POST`, `PUT`, `PATCH`, `DELETE` |
+| `routes[].path` | URL path with `:param` placeholders for path params |
+| `routes[].handler` | Method `id` from the manifest (kebab-case) |
+| `routes[].summary` | Short description for the endpoint |
+| `routes[].description` | Longer description |
+| `routes[].tag` | Resource grouping (becomes a tag in OpenAPI) |
+| `routes[].params` | Parameter declarations: `path`, `query`, and/or `body` objects |
+
+### Platform Behavior
+
+Routes are mounted at `/_/api{path}` (e.g. `DELETE /_/api/vendors/abc123`).
+
+- **Path params** are extracted and merged into the method's input: `/:vendorId` → `{ vendorId: "abc123" }`
+- **Query params** are merged into input for GET requests: `?status=approved` → `{ status: "approved" }`
+- **Request body** for POST/PUT/PATCH is the input directly (no `{ input: {...} }` wrapper)
+- **Response** is the method output directly (no `{ output: {...} }` wrapper)
+- **Auth** via `Authorization: Bearer sk_...` (API key resolves to a user with full RBAC)
+- **Streaming**: `Accept: text/event-stream` header returns SSE chunks
+- **Raw request context**: Every API method receives `input._request` with `{ method, headers, rawBody }`. `rawBody` is the original unparsed body as a UTF-8 string — critical for webhook signature verification (Stripe, GitHub, Shopify). For most methods you don't need `_request` at all.
+
+### Manifest
+
+```json
+{ "type": "api", "path": "dist/interfaces/api/api.json" }
 ```
 
-Returns SSE: `data: { type: 'token', text }` chunks, then `data: { type: 'done', output }`.
+## Platform-Triggered Interfaces
+
+Discord, Telegram, Cron, Webhook, and Email interfaces are invoked by the platform, not by a user session. Methods called through these interfaces run with `auth.roles: ['system']`. Use `auth.requireRole('system')` to restrict a method to platform triggers only.
 
 ## Discord Bot
 

package/dist/prompt/compiled/manifest.md

@@ -40,7 +40,7 @@
 
   "interfaces": [
     { "type": "web", "path": "dist/interfaces/web/web.json" },
-    { "type": "api" },
+    { "type": "api", "path": "dist/interfaces/api/api.json" },
     { "type": "cron", "path": "dist/interfaces/cron/interface.json" }
   ],
 
@@ -71,11 +71,12 @@
 | Field | Type | Required | Description |
 |-------|------|----------|-------------|
 | `enabled` | `boolean` | Yes | `true` to enable auth |
-| `methods` | `string[]` | Yes | Auth methods: `"email-code"`, `"sms-code"`. At least one required. |
+| `methods` | `string[]` | Yes | Auth methods: `"email-code"`, `"sms-code"`, `"api-key"`. 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) |
 | `table.columns.roles` | `string` | No | Column name for roles array (bidirectional sync) |
+| `table.columns.apiKey` | `string` | If api-key | Column name for API key (platform-managed, stores masked value) |
 
 ### `roles`
 `Array<{ id, name?, description? }>`. Defaults to `[]`.

package/dist/prompt/compiled/methods.md

@@ -252,3 +252,43 @@ const result = await api.generateReport(
 ```
 
 The platform handles the SSE transport. The method returns normally — streaming is managed by the SDK and platform, not by your method code.
+
+## Raw Request Context (API Interface)
+
+Methods invoked via the API interface receive `input._request` alongside the parsed input:
+
+```typescript
+input._request: {
+  method: string;                      // "GET", "POST", etc.
+  headers: Record<string, string>;     // all headers (lowercase keys)
+  rawBody: string | undefined;         // original unparsed body (UTF-8)
+}
+```
+
+`rawBody` preserves the exact bytes the client sent — whitespace, key ordering, encoding. Use it for webhook signature verification:
+
+```typescript
+export async function stripeWebhook(input: {
+  type: string;
+  data: any;
+  _request: { headers: Record<string, string>; rawBody: string };
+}) {
+  const stripe = new Stripe(process.env.STRIPE_SECRET_KEY!);
+
+  const event = stripe.webhooks.constructEvent(
+    input._request.rawBody,
+    input._request.headers['stripe-signature'],
+    process.env.STRIPE_WEBHOOK_SECRET!,
+  );
+
+  switch (event.type) {
+    case 'payment_intent.succeeded':
+      // ...
+      break;
+  }
+
+  return { received: true };
+}
+```
+
+For most methods, you don't need `_request` — the parsed path params, query params, and body fields are already on `input` directly.

package/dist/prompt/compiled/platform.md

@@ -40,7 +40,7 @@ my-app/
         web.json                           dev server config
         package.json
         src/
-      api/interface.json                 REST API config
+      api/api.json                       REST API config
       discord/interface.json             Discord bot config
       telegram/interface.json            Telegram bot config
       cron/interface.json                cron config
@@ -96,6 +96,7 @@ const { vendor } = await api.approveVendor({ vendorId: '...' });
 - **Multiple interfaces, one codebase.** Web, API, Discord, Telegram, Cron, Webhook, Email, MCP — all invoke the same methods. Methods don't know which interface called them.
 - **Sandboxed execution.** Each method invocation runs in its own isolated execution context with npm packages pre-installed.
 - **Git-native deployment.** Push to default branch to deploy. Push to feature branch for preview. Rollback is a git revert.
+- **Secrets.** Encrypted environment variables with separate dev/prod values. Injected as `process.env` in methods. For third-party service credentials not covered by the SDK.
 
 ## Minimum Viable App
 

package/dist/prompt/compiled/secrets.md

@@ -0,0 +1,40 @@
+# Secrets & Environment Variables
+
+Apps can store encrypted secrets (API keys, database URLs, tokens) that get injected into method execution as `process.env` variables. Secrets have separate dev and prod values — dev values are used in the editor sandbox, prod values are used in deployed releases.
+
+## When to Use Secrets
+
+Secrets are for third-party services that aren't covered by the MindStudio SDK. If the SDK already provides a capability (AI models, SMS, email, web search, image generation, etc.), use the SDK — it handles auth, billing, and key management automatically.
+
+Use secrets for things like Stripe, webhook signing secrets, or any other external service you connect to directly.
+
+Never expose secrets to frontends or interfaces. You can only consume secrets in backend methods.
+
+## Accessing Secrets
+
+```typescript
+export async function createPaymentIntent(input: { amount: number }) {
+  const stripe = new Stripe(process.env.STRIPE_SECRET_KEY!);
+  // stripe.create....
+}
+```
+
+Never hardcode credentials in method source — always use `process.env`.
+
+## Key Format
+
+Uppercase snake_case, starting with a letter: `STRIPE_SECRET_KEY`, `DATABASE_URL`, `GITHUB_TOKEN`.
+
+## Dev vs Prod
+
+Each secret has a dev value and a prod value. The same code (`process.env.STRIPE_SECRET_KEY`) automatically resolves to the right value based on execution context. Use test/sandbox keys for dev, live keys for prod - or use the same value for both if the service does not make a distinction.
+
+## Management
+
+Secrets are managed through the app's dashboard or the `mindstudio-prod secrets` CLI.
+
+## What NOT to Store
+
+- AI model API keys (OpenAI, Anthropic, Google) — use the SDK
+- Keys for platform-provided integrations (SMS, email, web search, image gen) — use the SDK
+- Non-sensitive values — use method input parameters or database tables

package/dist/prompt/static/authoring.md

@@ -19,7 +19,7 @@ The scaffold starts with these spec files that cover the full picture of the app
 - **`src/interfaces/@brand/voice.md`** — voice and terminology: tone, error messages, word choices
 - **`src/roadmap/`** — feature roadmap. One file per feature (`type: roadmap`). See "Roadmap" below.
 
-These are starting points, not constraints. Create as many spec files as the project needs — the `src/` folder is your workspace and every `.md` file in it becomes compilation context. If the app has substantial content (presentation slides, copy, lesson plans, menu items, quiz questions), put it in its own file (`src/content.md`, `src/slides.md`, `src/menu.md`, etc.) rather than cramming it into `app.md` or `web.md`. If the domain is complex, split `app.md` into multiple files by area (`src/billing.md`, `src/approvals.md`). Add interface specs for other interface types (`api.md`, `cron.md`, `agent.md`, etc.) if the app uses them. Organize however serves clarity — the platform reads the entire `src/` folder.
+These are starting points, not constraints. Create as many spec files as the project needs — the `src/` folder is your workspace and every `.md` file in it becomes compilation context. If the app has substantial content (presentation slides, copy, lesson plans, menu items, quiz questions), put it in its own file (`src/content.md`, `src/slides.md`, `src/menu.md`, etc.) rather than cramming it into `app.md` or `web.md`. If the domain is complex, split `app.md` into multiple files by area (`src/billing.md`, `src/approvals.md`). Add interface specs for other interface types (`api.md`, `cron.md`, `agent.md`, etc.) if the app uses them. The API interface is useful whenever the app needs to receive or serve external HTTP requests — webhook endpoints, sync APIs, batch tools — not just comprehensive REST APIs. Organize however serves clarity — the platform reads the entire `src/` folder.
 
 Remember: users care about look and feel as much as (and often more than) underlying data structures. Don't treat the brand and interface specs as an afterthought — for many users, the visual identity and voice are the first things they want to get right.
 

package/dist/prompt/static/coding.md

@@ -47,12 +47,17 @@ For multi-step tasks with branching logic (research, enrichment, content pipelin
 ### State Management
 - Calls to methods introduce latency. When building web frontends that load data from methods, front-load as much data as you can in a single API request - e.g., when possible, load a large data object into a central store and use that to render sub-screens in an app, rather than an API call on every screen. User experience and perceived speed/performance are far more valuable than normalization and good REST API design.
 
+### Secrets & Third-Party Integrations
+When a method needs credentials for a third-party service, use `process.env` and use the CLI to set it on behalf of the user (chat logs are secure and scrubbed, so it's fine for them to paste) or they can set it manually in the Dashboard.
+
+When integrating with external services that have programmable setup APIs (webhook registration, OAuth app config, etc.), automate the setup rather than sending the user to the service's dashboard. If you have the API key in `process.env`, use it to register webhooks, configure endpoints, and store any resulting secrets (like signing keys) automatically. The user shouldn't have to leave the conversation for setup steps you can handle programmatically.
+
 ### Dependencies
 Before installing a package you haven't used in this project, do a quick web search to confirm it's still the best option. The JavaScript ecosystem moves fast — the package you remember from training may have been superseded by something smaller, faster, or better maintained. A 10-second search beats debugging a deprecated library.
 
 ### Production App Management
 You have access to `mindstudio-prod`, a CLI for managing the user's production MindStudio 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` (logs, error rates, latency), `releases` (deploy status, history), `domains` (custom subdomain management), `users` (list, set roles), `db` (query production sql db), `methods` (list, invoke).
+Available commands: `requests` (logs, error rates, latency), `releases` (deploy status, history), `domains` (custom subdomain management), `users` (list, set roles), `db` (query production sql db), `methods` (list, invoke), `secrets` (list, get, set, delete).
 
 Use when the user asks about production behavior (errors, logs, metrics), wants to manage their live app (domains, users, roles), needs to seed or query production data, or wants to check release status.

package/dist/prompt/static/instructions.md

@@ -17,7 +17,7 @@
 - Pushing to main branch will trigger a deploy. The user presses the publish button in the interface to request publishing.
 
 ### 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. Delete the notes file when your work is done.
+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.
 
 ## Communication
 The user can already see your tool calls, so most of your work is visible without narration. Focus text output on three things:

package/dist/subagents/codeSanityCheck/prompt.md

@@ -8,6 +8,8 @@ Most things are fine. These are fast-moving products built by non-technical user
 
 **A package is dead or superseded.** If the plan involves a package, do a quick web search. Only flag it if there's a clearly better, actively maintained alternative. "This works fine" is a valid finding.
 
+**External HTTP endpoints should use the API interface.** If the plan involves receiving webhooks from external services (Stripe, Twilio, etc.), exposing sync endpoints, or serving any external HTTP requests, flag that the API interface (`src/interfaces/api.md`) is the right tool. Don't build custom HTTP handling when the platform handles routing, auth, and OpenAPI generation.
+
 **There's a managed SDK action for this.** If the plan involves writing custom code for something that sounds like media processing, email/SMS, third-party APIs, or AI model calls — check `askMindStudioSdk`. The managed action handles retries, auth, and scaling.
 
 **Project organization needs a reset.** After heavy iteration, a file or folder structure might have grown unwieldy. If things would genuinely benefit from being reorganized, say so. But only at the structural level — "this 500-line component should be a folder" not "rename this variable."
@@ -16,6 +18,8 @@ Most things are fine. These are fast-moving products built by non-technical user
 
 These are things we already know about and have decided to accept:
 
+- API interface methods have access to `input._request.rawBody` for webhook signature verification (Stripe, GitHub, etc.). Do NOT suggest external proxies or workarounds — the raw body is available natively.
+
 - Limited browser support for `oklch` gradients using `in <colorspace>` syntax — we accept the compatibility tradeoff for better color quality
 - Limited browser support for CSS scroll-driven animations (`animation-timeline: scroll()` / `view()`)  - we accept this tradeoff
 - Platform SDKs (these are the core of every MindStudio app):
@@ -36,6 +40,10 @@ These are things we already know about and have decided to accept:
 
 ### Common pitfalls (always flag these)
 
+- **External redirects in iframe.** If the plan involves redirecting to a third-party domain (payment checkout, OAuth login, external auth), flag that `window.location.href = url` will break in the preview iframe. Use `window.open(url, '_top')` for same-tab navigation or `window.open(url, '_blank')` for a new tab. This applies to any external redirect — Stripe, OAuth providers, third-party login pages.
+
+- **Hardcoded credentials.** If the plan or code contains API keys, tokens, or connection strings inline, flag it — these should be `process.env` secrets managed via the dashboard. Also flag if the plan uses `process.env` for something the MindStudio SDK already handles (AI model keys, email/SMS sending, etc.).
+
 These are recurring mistakes the coding agent makes. If you see the conditions for any of these, flag it proactively:
 
 - **CSS Module animation scoping.** If the agent defines `@keyframes` in a global CSS file but references the animation name from a CSS Module, the animation will silently fail. CSS Modules scope animation names, so a keyframe defined globally can't be found by a scoped class. The fix: define keyframes in the same CSS Module that uses them, or use `:global()` to escape the scoping.

package/dist/subagents/designExpert/prompts/frontend-design-notes.md

@@ -46,7 +46,7 @@ Every interface must work on both desktop and mobile.
 ## What to Actively Avoid At All Costs
 
 - **Avoid generic fonts.** Overused defaults that strip away all personality. Instead: pick a distinctive Google Font that fits the app's character.
-- **Avoid purple or indigo anything.** Purple gradients, purple buttons, purple accents are overused. The user will be dismissive of our designs if they come out looking purple or indigo.
+- **Avoid purple or indigo anything.** Purple gradients, purple buttons, purple accents are overused. The user will be dismissive of our designs if they come out looking purple or indigo. Avoid terracotta for similar reasons. Challenge yourself to choose beautiful, modern, 2026-inspired colors.
 - **Avoid colored left-border callout boxes.** Rounded divs with a thick colored `border-left` — the generic "info card" pattern. Instead: use typography, spacing, and background tints to create hierarchy. If you need to call something out, use a full subtle background or a top border.
 - **Avoid three equal boxes with icons.** The default AI landing page layout. Instead: use asymmetric layouts, varied column widths, or a single focused content area.
 - **Avoid timid color palettes.** Evenly distributed, non-committal colors. Instead: one or two dominant colors with sharp accents. Commit to a direction.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@mindstudio-ai/remy",
-  "version": "0.1.121",
+  "version": "0.1.123",
   "description": "MindStudio coding agent",
   "repository": {
     "type": "git",