@mindstudio-ai/remy 0.1.189 → 0.1.190

package/dist/prompt/compiled/interfaces.md

@@ -320,27 +320,53 @@ Standard cron expression format. Jobs are synced to the platform on deploy.
 
 ## Webhook
 
-Inbound HTTP endpoints that invoke methods.
+Inbound HTTP endpoints that invoke a method directly and synchronously — the caller waits for the method to finish. Use for receiving webhooks from external services (Stripe, GitHub, Shopify, Slack, Twilio). Direct inbound webhooks with signature verification work natively; do **not** build confirmation-token or polling workarounds.
 
 ### Config (`interface.json`)
 
+The top-level key must match the interface type (`webhook`):
+
 ```json
 {
   "webhook": {
     "endpoints": [
       {
         "method": "handle-payment-webhook",
-        "description": "Stripe payment notifications",
-        "secret": "whk_abc123..."
+        "secret": "whsec_pick_a_long_random_token",
+        "description": "Stripe events"
       }
     ]
   }
 }
 ```
 
-Endpoint URL: `https://{app-host}/_/webhook/{secret}` — `{app-host}` is any hostname the app is served on (default `<uuid>.madewithremy.com`, a custom platform subdomain, or a custom domain).
+- `method` — the id of a method in `methods[]` to invoke.
+- `secret` — a developer-chosen opaque token that is **both the routing key and the access guard**. It is stable across deploys (compilation is a passthrough — redeploying never rotates it), so a URL you register with Stripe/GitHub stays valid. Generate one long random value per endpoint and keep it constant.
+- Declare multiple endpoints if needed; each `secret` maps to one method.
+
+### Endpoint URL
+
+Register this with the external service: `https://{app-host}/_/webhook/{secret}` — `{app-host}` is any host the app is served on: its `custom_subdomain` host (e.g. `myapp.madewithremy.com`), a custom domain if configured, or the UUID host (`<appId>.madewithremy.com` / `.msagent.ai`). All HTTP verbs are accepted.
+
+### Input
+
+The method receives:
+
+```ts
+{
+  method: string;                  // HTTP method
+  headers: Record<string, string>; // request headers
+  query: Record<string, string>;   // query params
+  body: any;                       // parsed JSON / form body
+  rawBody: string;                 // exact raw request bytes (UTF-8), pre-parse
+}
+```
+
+For signature verification **always use `rawBody`, never `body`** — providers (Stripe, GitHub, Shopify, Slack) HMAC the raw payload, and a re-serialized `body` will not match. E.g. `stripe.webhooks.constructEvent(input.rawBody, input.headers['stripe-signature'], endpointSecret)`. `rawBody` is populated for `application/json` and `application/x-www-form-urlencoded` bodies (what these providers send).
+
+### Response
 
-Accepts any HTTP method. The method receives `{ method, headers, query, body }` as input.
+Whatever the method returns as output is sent back to the caller as JSON; if it returns no output, the platform responds `204`. A wrong/unknown secret returns `401`; an app with no live release returns `404`.
 
 ## Email
 

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. 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.
+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`, `webhook.md`, `cron.md`, `agent.md`, etc.) if the app uses them. For external HTTP, the Webhook interface (`webhook.md`) handles inbound provider webhooks (Stripe, GitHub) via secret-in-URL routing, while the API interface (`api.md`) covers bearer-auth sync endpoints, public REST APIs, and batch tools. 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/subagents/codeSanityCheck/prompt.md

@@ -8,7 +8,7 @@ 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.
+**External HTTP endpoints should use a platform interface, not custom HTTP handling.** If the plan involves receiving webhooks from external services (Stripe, Twilio, etc.), exposing sync endpoints, or serving any external HTTP requests, flag that the platform handles routing, auth, and the raw request body natively. Two native paths exist — the Webhook interface (`src/interfaces/webhook.md`: secret-in-URL routing, a good fit for provider-signature webhooks) and the API interface (`src/interfaces/api.md`: bearer-auth REST with OpenAPI generation, for sync endpoints and public APIs). Don't build custom HTTP handling or external proxies.
 
 **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.
 
@@ -19,7 +19,7 @@ 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:
 
 - **`dist/` is where code lives.** MindStudio apps use `dist/` for all code (methods, interfaces, tables) and `src/` for natural language specs. This is NOT the conventional "dist is build output" pattern. Never flag code being in `dist/` as wrong.
-- 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.
+- The raw request body for webhook signature verification (Stripe, GitHub, etc.) is available natively — under `input._request.rawBody` on API interface methods, and at top-level `input.rawBody` on Webhook interface methods. Do NOT suggest external proxies or workarounds.
 
 - Ignore limited browser support for `oklch` gradients using `in <colorspace>` syntax — we accept the compatibility tradeoff for better color quality
 -Ignore limited browser support for CSS scroll-driven animations (`animation-timeline: scroll()` / `view()`)  - we accept this tradeoff

package/package.json

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