@mindstudio-ai/remy 0.1.257 → 0.1.258

package/dist/prompt/skills/scheduledJobs.md

@@ -0,0 +1,51 @@
+---
+name: Scheduled Jobs
+what: Methods that run on a schedule, declared as cron expressions in an interface config and synced to the platform on deploy. Nothing to host and no scheduler to run — a job is a method plus a schedule line.
+when: Before adding a `cron` interface or writing a method meant to run on a timer.
+---
+
+# Cron Interfaces
+
+Scheduled method execution.
+
+## Config (`interface.json`)
+
+The top-level key must match the interface type (`cron`):
+
+```json
+{
+  "cron": {
+    "jobs": [
+      {
+        "schedule": "0 9 * * 5",
+        "method": "process-weekly-payments",
+        "description": "Process approved invoices every Friday at 9am"
+      },
+      {
+        "schedule": "*/30 * * * *",
+        "method": "sync-vendor-status",
+        "description": "Sync vendor statuses every 30 minutes"
+      }
+    ]
+  }
+}
+```
+
+Standard cron expression format. `method` is the id of a method in `methods[]`. Jobs are synced to the
+platform on deploy.
+
+Declare it in `mindstudio.json`:
+
+```json
+{ "type": "cron", "path": "dist/interfaces/cron/interface.json" }
+```
+
+## Auth
+
+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.

package/dist/prompt/skills/webhooks.md

@@ -0,0 +1,108 @@
+---
+name: Webhooks
+what: Inbound HTTP endpoints that run a method synchronously, routed by a secret in the URL rather than by an auth header — which is what makes them the right fit for provider callbacks from Stripe, GitHub, Shopify, Slack or Twilio, since those senders can't present a bearer token. Signature verification works natively off the raw request body.
+when: Before adding a `webhook` interface or writing a method that receives a provider callback. Also load it before reaching for any confirmation-token, polling, or proxy workaround for inbound HTTP — those aren't needed here.
+---
+
+# Webhook Interfaces
+
+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.
+
+The other native path for inbound HTTP is the API interface, which uses bearer auth and exposes the raw
+body at `input._request.rawBody` instead of at the top level. Use that one when the caller can send an
+`Authorization` header and you want a documented REST surface; use this one for provider callbacks.
+Load the `restApi` skill if that's the direction.
+
+Webhook secrets are configured at the project level by the user through the Remy platform. Your job is
+the `interface.json` and the handling method.
+
+## Config (`interface.json`)
+
+The top-level key must match the interface type (`webhook`):
+
+```json
+{
+  "webhook": {
+    "endpoints": [
+      {
+        "method": "handle-payment-webhook",
+        "secret": "whsec_pick_a_long_random_token",
+        "description": "Stripe events"
+      }
+    ]
+  }
+}
+```
+
+- `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.
+
+Declare it in `mindstudio.json`:
+
+```json
+{ "type": "webhook", "path": "dist/interfaces/webhook/interface.json" }
+```
+
+## 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:
+
+```typescript
+const event = stripe.webhooks.constructEvent(
+  input.rawBody,
+  input.headers['stripe-signature'],
+  process.env.STRIPE_WEBHOOK_SECRET!,
+);
+```
+
+`rawBody` is populated for `application/json` and `application/x-www-form-urlencoded` bodies (what these
+providers send).
+
+## Response
+
+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`.
+
+## Auth
+
+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 via a platform trigger. The auth reference in your system prompt covers the
+system role in full.
+
+Note that the URL secret is the only access control on the endpoint itself, which is why it needs to be
+long and random. Signature verification is a second, independent check that the payload really came from
+the provider — do both.

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`, `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.
+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`, `email.md`, `mcp.md`, `agent.md`) if the app uses them. Each of those has a skill carrying its spec format and config — `restApi`, `webhooks`, `scheduledJobs`, `inboundEmail`, `mcpInterfaces`, `agentInterfaces` — and you should load the relevant one before writing the spec rather than after, since the spec is what the config is compiled from. For external HTTP the choice is between two of them: the Webhook interface handles inbound provider webhooks (Stripe, GitHub) via secret-in-URL routing, while the API interface 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/package.json

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