@frontmcp/skills 1.4.0 → 1.5.0-rc.1

package/catalog/frontmcp-deployment/examples/deploy-to-cloudflare/basic-worker-deploy.md

@@ -47,12 +47,15 @@ export default MyServer;
 ```
 
 ```toml
-# wrangler.toml — the Cloudflare adapter overwrites this on every build
-# with exactly these three lines (configure name/compatibility_date via
-# frontmcp.config.deployments[].wrangler).
+# wrangler.toml — the Cloudflare adapter overwrites these top-level keys on
+# every build (configure name/compatibility_date/compatibility_flags via
+# frontmcp.config.deployments[].wrangler). nodejs_compat is always emitted —
+# the worker entry require()s @frontmcp/sdk + Express, so without it the
+# Worker fails to boot.
 name = "frontmcp-worker"
 main = "dist/cloudflare/index.js"
-compatibility_date = "2024-01-01"
+compatibility_date = "2024-09-23"
+compatibility_flags = ["nodejs_compat"]
 ```
 
 ```bash

package/catalog/frontmcp-deployment/examples/deploy-to-cloudflare/worker-custom-domain.md

@@ -55,12 +55,15 @@ export default TranslateServer;
 ```
 
 ```toml
-# wrangler.toml — name/compatibility_date are managed by frontmcp.config;
-# bindings appended below are re-applied after each build (the adapter
-# overwrites the top-level keys on every `frontmcp build --target cloudflare`).
+# wrangler.toml — name/compatibility_date/compatibility_flags are managed by
+# frontmcp.config; bindings appended below are re-applied after each build (the
+# adapter overwrites the top-level keys on every `frontmcp build --target
+# cloudflare`). nodejs_compat is always emitted — the worker entry needs Node
+# builtins or it won't boot.
 name = "translate-worker"
 main = "dist/cloudflare/index.js"
-compatibility_date = "2024-01-01"
+compatibility_date = "2024-09-23"
+compatibility_flags = ["nodejs_compat"]
 
 [[kv_namespaces]]
 binding = "FRONTMCP_KV"

package/catalog/frontmcp-deployment/examples/deploy-to-cloudflare/worker-with-kv-storage.md

@@ -49,11 +49,14 @@ export default MyServer;
 ```
 
 ```toml
-# wrangler.toml — name/main/compatibility_date are rewritten by the build.
-# Bindings below need to be re-applied (or appended) after each build.
+# wrangler.toml — name/main/compatibility_date/compatibility_flags are
+# rewritten by the build (nodejs_compat is always emitted; the worker entry
+# needs Node builtins or it won't boot). Bindings below need to be re-applied
+# (or appended) after each build.
 name = "frontmcp-worker"
 main = "dist/cloudflare/index.js"
-compatibility_date = "2024-01-01"
+compatibility_date = "2024-09-23"
+compatibility_flags = ["nodejs_compat"]
 
 [[kv_namespaces]]
 binding = "FRONTMCP_KV"

package/catalog/frontmcp-deployment/references/deploy-to-cloudflare-skills-only.md

@@ -1,14 +1,34 @@
 ---
 name: deploy-to-cloudflare-skills-only
-description: Deploy a FrontMCP server to Cloudflare Workers using the v1.3 skills-only model — OpenAPI as capability inventory, AgentScript with namespaced bindings, four meta-tools, hot-reload via GitHub Action and a signed-bundle webhook
+description: Deploy an auto-updating FrontMCP server to Cloudflare Workers with @frontmcp/edge createEdgeMcp — managed skilled-OpenAPI bundle pulled from a SaaS endpoint, cached in KV, refreshed on a Cron Trigger
 ---
 
-# Deploy to Cloudflare Workers (Skills-Only Model)
-
-The v1.3 Cloudflare Worker target hosts FrontMCP as a control plane where the MCP surface is just **four meta-tools** (`searchSkills`, `searchKnowledge`, `describe`, `execute`) and every capability is reached through a skill. OpenAPI specs ship to the project but are NEVER directly exposed — they are the capability inventory, classified by HTTP semantics into resources / tools, with auto-derived `notifications/resources/*` events.
+# Deploy to Cloudflare Workers (Managed / Skills-Only Model)
+
+> **⚠️ Status — experimental.** `@frontmcp/edge` `createEdgeMcp` **deploys and
+> serves on real Cloudflare** (verified live), as long as you (1) keep
+> `serve: false` (now the createEdgeMcp default) and (2) stub three Node-only
+> transports your bundler statically includes but the edge never uses —
+> `express`, `raw-body`, `cross-spawn`. NOTE: **miniflare local-dev is stricter
+> than production** and rejects `node:http2`/`node:fs` that real Cloudflare's
+> `nodejs_compat` provides, so the local managed e2e is skipped even though the
+> package runs in production. Managed mode (this page) additionally needs a SaaS
+> bundle endpoint + the optional peer `@frontmcp/plugin-skilled-openapi`. The
+> worker-conditioned SDK build (roadmap) removes the manual stubs. For the
+> simplest production path, the decorator build in
+> [`deploy-to-cloudflare.md`](./deploy-to-cloudflare.md) needs none of this.
+> The GitHub Action / signed-resync-webhook / Durable Object stores / Frontegg
+> edge auth described below remain ROADMAP — not yet implemented.
+
+The managed model hosts FrontMCP where the MCP surface is a small set of
+meta-tools (`search_skill`, `load_skill`, `run_workflow`) and every capability
+is reached through a skill compiled from an OpenAPI spec. `run_workflow` runs a
+short AgentScript program in the Worker isolate, where each `callTool(actionId,
+input)` invokes a loaded skill's operation. The bundle is pulled from a SaaS
+endpoint, cached in KV, and refreshed on a Cron Trigger.
 
 For the conceptual picture, see [Skills-Only Deployment](https://docs.agentfront.dev/frontmcp/features/skills-only-deployment).
-For the older Express-to-Workers adapter, see [`deploy-to-cloudflare.md`](./deploy-to-cloudflare.md).
+For the production-ready decorator build, see [`deploy-to-cloudflare.md`](./deploy-to-cloudflare.md).
 
 ## When to Use This Skill
 
@@ -32,21 +52,47 @@ For the older Express-to-Workers adapter, see [`deploy-to-cloudflare.md`](./depl
 ## Worker Entry File
 
 ```ts
-// worker.ts (~10 lines)
-import { createWorker } from '@frontmcp/worker';
+// worker.ts — the real API is createEdgeMcp (not createWorker)
+import { createEdgeMcp, kvBundleCacheFromEnv } from '@frontmcp/edge';
+
+export default createEdgeMcp({
+  info: { name: 'my-worker', version: '1.0.0' },
+  apps: [],
+  tasks: { enabled: false },
+  managed: {
+    endpoint: 'https://cloud.example.com/v1/bundles/acme',
+    authToken: 'pinned-pull-token',
+    expectedAudience: 'acme-mcp',
+    jwksUrl: 'https://cloud.example.com/.well-known/jwks.json',
+    expectedIssuer: 'https://cloud.example.com',
+    // KV-backed last-good cache, resolved from the per-request `env`.
+    cache: kvBundleCacheFromEnv('BUNDLE_CACHE'),
+  },
+});
+```
 
-import deployBundle from './frontmcp.deploy.bundle.js'; // emitted by the GH Action
+`createEdgeMcp` returns `{ fetch, scheduled }`: `fetch` serves MCP; `scheduled`
+is the **Cron Trigger** entrypoint that pulls a fresh bundle and hot-swaps it.
+Managed mode requires the optional peer `@frontmcp/plugin-skilled-openapi`.
 
-const { handler, durableObjects } = createWorker({
-  bundle: deployBundle,
-  env: 'production',
-});
+This path is bundled by **wrangler** (not `frontmcp build`), so you maintain
+`wrangler.toml` yourself — it needs a `[[kv_namespaces]] binding = "BUNDLE_CACHE"`
+and a `[triggers] crontabs = [...]` (the `managed.pollIntervalMs` option is
+ignored on edge — Workers have no background timers; the Cron drives refresh):
 
-export default handler;
-export const { SessionDO, EventStoreDO, BundleDO } = durableObjects;
-```
+```toml
+name = "my-worker"
+main = "worker.ts"
+compatibility_date = "2024-09-23"
+compatibility_flags = ["nodejs_compat"]
 
-`createWorker` parses the manifest, applies the `environments.production` overlay, verifies the signed envelope against `TRUSTED_KEYS`, and assembles the FrontMCP runtime.
+[[kv_namespaces]]
+binding = "BUNDLE_CACHE"
+id = "<your-kv-namespace-id>"
+
+[triggers]
+crontabs = ["*/5 * * * *"]
+```
 
 ## Storage Layout (Opinionated Default)
 
@@ -92,7 +138,11 @@ Day-to-day skill / OpenAPI edits are pure hot-reload. `wrangler deploy` is only
 
 `@enclave-vm/core` (full VM) needs `node:vm` and is NOT Worker-safe — the Worker target uses AST-preflight + frozen scope only.
 
-## Auth at the Edge
+## Auth at the Edge 🚧 Roadmap — not yet implemented
+
+> The Frontegg **edge** JWT verification below is a ROADMAP shape, not a shipped
+> feature. Don't wire it expecting edge-native verification today; use the
+> standard auth providers via the decorator build until this lands.
 
 ```yaml
 auth:
@@ -126,7 +176,11 @@ wrangler secret put ACME_API_TOKEN
 
 The cross-validator REJECTS any manifest that references a secret name not declared in `secrets[]`.
 
-## Sample `.github/workflows/deploy.yml`
+## Sample `.github/workflows/deploy.yml` 🚧 Roadmap — not yet implemented
+
+> The packaged GitHub Action and the signed-resync webhook are ROADMAP. The
+> workflow below is an illustrative target, not a copy-paste-ready pipeline —
+> deploy manually with `wrangler deploy` until the Action ships.
 
 ```yaml
 name: Deploy

package/catalog/frontmcp-deployment/references/deploy-to-cloudflare.md

@@ -64,19 +64,20 @@ wrangler.toml    # Wrangler configuration (overwritten on every build)
 
 Cloudflare Workers use CommonJS (not ESM). The build command sets `--module commonjs` automatically.
 
-> **Important:** The Cloudflare adapter sets `alwaysWriteConfig: true` and overwrites the entire `wrangler.toml` on every build with the three-line template below. Hand-edited bindings (`[[kv_namespaces]]`, `[vars]`, `[[d1_databases]]`, etc.) WILL be erased the next time you run `frontmcp build --target cloudflare`. Configure `name` and `compatibility_date` via your `frontmcp.config` file's `deployments[].wrangler` section, and keep bindings in a separate config file referenced from your toolchain (or re-add them after each build).
+> **Important:** The Cloudflare adapter sets `alwaysWriteConfig: true` and overwrites the entire `wrangler.toml` on every build with the template below. Hand-edited bindings (`[[kv_namespaces]]`, `[vars]`, `[[d1_databases]]`, etc.) WILL be erased the next time you run `frontmcp build --target cloudflare`. Configure `name`, `compatibility_date`, and extra `compatibility_flags` via your `frontmcp.config` file's `deployments[].wrangler` section, and keep bindings in a separate config file referenced from your toolchain (or re-add them after each build).
 
 ## Step 3: Configure wrangler.toml
 
-The build always writes exactly this:
+The build always writes this. `compatibility_flags = ["nodejs_compat"]` is **always** emitted — the worker entry is an ES Module that imports `@frontmcp/sdk`'s web-fetch handler, which still transitively pulls in Node builtins (no Express on the Worker), so without the flag the deployed Worker fails to load. The default `compatibility_date` is `2024-09-23` (the date that enables full `nodejs_compat`). `main` is `dist/cloudflare/index.js`.
 
 ```toml
 name = "frontmcp-worker"
 main = "dist/cloudflare/index.js"
-compatibility_date = "2024-01-01"
+compatibility_date = "2024-09-23"
+compatibility_flags = ["nodejs_compat"]
 ```
 
-`name` and `compatibility_date` come from `frontmcp.config.{ts,js}`'s `deployments` array. Example:
+`name`, `compatibility_date`, and any extra `compatibilityFlags` come from `frontmcp.config.{ts,js}`'s `deployments` array (`nodejs_compat` is merged in automatically). Example:
 
 ```ts
 // frontmcp.config.ts
@@ -87,6 +88,8 @@ export default {
       wrangler: {
         name: 'my-worker',
         compatibilityDate: '2025-01-15',
+        // Optional — nodejs_compat is always added for you.
+        compatibilityFlags: ['nodejs_compat_populate_process_env'],
       },
     },
   ],
@@ -99,6 +102,7 @@ To add KV storage or other bindings, append them AFTER each build (or use a wrap
 name = "my-worker"
 main = "dist/cloudflare/index.js"
 compatibility_date = "2025-01-15"
+compatibility_flags = ["nodejs_compat"]
 
 [[kv_namespaces]]
 binding = "FRONTMCP_KV"
@@ -170,12 +174,57 @@ curl -X POST https://frontmcp-worker.your-subdomain.workers.dev/mcp \
   -d '{"jsonrpc":"2.0","method":"tools/list","id":1}'
 ```
 
+## Endpoint path, CORS & SSE — config-driven
+
+The worker's transport is driven by the standard `http` + `transport` config (the same fields the Express host reads), so behaviour is identical on both adapters. The worker serves MCP at **exactly one path** — `http.entryPath` (the worker root `/` when unset) — not a guessed `/` + `/mcp` set. Cloudflare never strips the path before it reaches the worker:
+
+| Clients use | `http.entryPath` | `wrangler.toml` route | Worker serves |
+| --- | --- | --- | --- |
+| `https://mcp.example.com` (subdomain) | omit (`/`) | `routes = [{ pattern = "mcp.example.com", custom_domain = true }]` | `/` |
+| `https://example.com/mcp` (path) | `'/mcp'` | `routes = [{ pattern = "example.com/mcp*", zone_name = "example.com" }]` | `/mcp` |
+
+```ts
+createEdgeMcp({
+  /* …info, apps… */
+  http: {
+    entryPath: '/mcp',       // the ONE path MCP is served at (omit → root '/')
+    cors: { origin: true },  // browser MCP clients (e.g. Inspector "Direct" mode); { origin, credentials, maxAge }
+  },
+  // transport: 'legacy'/'modern' → SSE streaming on POST; 'stateless-api' → buffered JSON.
+});
+```
+
+- **CORS** ← `http.cors` (`false` disables; a function `origin` is unsupported on the worker — use `true` / string / `string[]`).
+- **SSE** ← derived from the transport protocol (streaming under `legacy`/`modern`, buffered JSON under `stateless-api`); server→client `GET` streams are always honored.
+- A trailing slash is normalized (`/mcp/` matches `/mcp`); `/healthz` + `/readyz` always answer a liveness 200 regardless of `entryPath`.
+
 ## Workers Limitations
 
 - **Bundle size**: Workers have a 1 MB compressed / 10 MB uncompressed limit (paid plan: 10 MB / 30 MB). Review dependencies and remove unused packages to reduce bundle size.
 - **CPU time**: 10 ms CPU time on free plan, 30 seconds on paid. Long-running operations must be optimized or use Durable Objects.
 - **No native modules**: `better-sqlite3` and other native Node.js modules are not available. Use KV, D1, or Upstash Redis for storage.
-- **Streaming**: SSE streaming may have limitations through the Workers adapter. Test thoroughly.
+- **Streaming**: Streamable HTTP works, including SSE responses (`POST` with `Accept: text/event-stream`) and the server→client SSE `GET` stream. The worker uses the SDK's `WebStandardStreamableHTTPServerTransport` — which **is** the standard Streamable HTTP transport (the Node `StreamableHTTPServerTransport` is a thin `req`/`res` wrapper over it, so there's one engine). **Server→client notifications** on the standalone `GET` stream require **stateful sessions** — set `sessions: {}` and bind the `SessionDurableObject` (Durable Object) per `Mcp-Session-Id`. Without it the worker is stateless and the `GET` stream can't deliver pushed notifications.
+
+### Stateful sessions (Durable Object)
+
+```ts
+const mcp = createEdgeMcp({ /* …info, apps… */ http: { entryPath: '/mcp' }, sessions: {} });
+export default mcp;
+export const FrontMcpSession = mcp.SessionDurableObject;
+```
+
+```toml
+[[durable_objects.bindings]]
+name = "FRONTMCP_SESSIONS"
+class_name = "FrontMcpSession"
+[[migrations]]
+tag = "v1"
+new_classes = ["FrontMcpSession"]
+[vars]
+MCP_SESSION_SECRET = "..."   # required on production isolates; bridged into process.env
+```
+
+One DO per session holds a persistent transport so the `GET` notification stream stays open and `tools/call` notifications reach it. It runs the **same `http:request` flow** (auth/session:verify/router/audit/metrics + hooks) as the stateless path — so transparent auth returns `401` + `WWW-Authenticate` on the worker too.
 
 ## Storage Options
 
@@ -190,16 +239,16 @@ curl -X POST https://frontmcp-worker.your-subdomain.workers.dev/mcp \
 | Problem                       | Cause                                          | Solution                                                                  |
 | ----------------------------- | ---------------------------------------------- | ------------------------------------------------------------------------- |
 | Worker exceeds size limit     | Too many bundled dependencies                  | Review dependencies and remove unused packages to reduce bundle size      |
-| Module format errors          | `wrangler.toml` sets `type = "module"`         | Remove the `type` field; FrontMCP Cloudflare builds use CommonJS          |
+| Module format errors          | Worker bundled as a Service Worker             | FrontMCP Cloudflare builds emit an **ES Module Worker** (`export default { fetch }`); `nodejs_compat` requires it. Don't force `type`/CommonJS |
 | KV binding errors             | Namespace not created or binding name mismatch | Run `wrangler kv:namespace create` and copy the `id` into `wrangler.toml` |
 | Timeout errors                | CPU time exceeds plan limit                    | Upgrade plan or offload heavy computation to Durable Objects              |
-| CORS failures on MCP endpoint | Missing CORS headers in Worker response        | Add CORS middleware or headers in your FrontMCP server configuration      |
+| CORS failures on MCP endpoint | Missing CORS headers in Worker response        | `@frontmcp/edge`: pass `cors: { origin: true }` to `createEdgeMcp({...})` (transport-level CORS) |
 
 ## Common Patterns
 
 | Pattern            | Correct                                                                    | Incorrect                         | Why                                                                                                                                      |
 | ------------------ | -------------------------------------------------------------------------- | --------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- |
-| Module format      | CommonJS (`main = "dist/cloudflare/index.js"`)                             | ESM (`type = "module"`)           | FrontMCP Cloudflare builds emit CommonJS at this exact path; the build overwrites `wrangler.toml` to enforce it                          |
+| Module format      | ES Module Worker (`main = "dist/cloudflare/index.js"`, `export default { fetch }`) | Service Worker / forced CommonJS  | FrontMCP Cloudflare builds emit an ES Module Worker at this exact path; the build overwrites `wrangler.toml`. `nodejs_compat` requires the Module shape |
 | Transport key      | `transport: { protocol: 'modern' }` (or `{ sse: true, streamable: true }`) | `transport: { type: 'sse' }`      | The schema field is `protocol`; valid presets are `'legacy' \| 'modern' \| 'stateless-api' \| 'full'`, or pass a `ProtocolConfig` object |
 | Storage binding    | `[[kv_namespaces]]` with matching `binding`                                | Hardcoded KV namespace ID in code | Bindings are injected at runtime by Workers                                                                                              |
 | Compatibility date | Set via `frontmcp.config.deployments[].wrangler.compatibilityDate`         | Hand-editing `wrangler.toml`      | The build overwrites `wrangler.toml`; config-driven values survive                                                                       |
@@ -215,7 +264,7 @@ curl -X POST https://frontmcp-worker.your-subdomain.workers.dev/mcp \
 
 **Configuration**
 
-- [ ] `wrangler.toml` has correct `name`, `main`, and `compatibility_date`
+- [ ] `wrangler.toml` has correct `name`, `main`, `compatibility_date`, and `compatibility_flags = ["nodejs_compat"]`
 - [ ] KV namespace IDs match between dashboard and `wrangler.toml`
 - [ ] Secrets are stored via `wrangler secret put`, not in `[vars]`
 

package/catalog/frontmcp-development/references/create-plugin-hooks.md

@@ -66,6 +66,38 @@ These are the flow names with pre-built hook decorator exports in `@frontmcp/sdk
 | `channels:send-notification`        | Channel notification send | `ChannelSendHook`           |
 | `channels:list`                     | Channel listing           | `ChannelListHook`           |
 
+## Strict architecture: flows are the only path — never bypass them
+
+This is the load-bearing invariant behind every hook above: in FrontMCP **every
+request runs through a flow**, and because flows are made of `@Stage` steps that
+`FlowHooksOf` exposes for interception, hooks work *everywhere* automatically.
+The hookability is only guaranteed because nothing handles a request outside a
+flow.
+
+Therefore:
+
+- **Never bypass the flow pipeline to make something work.** Add or extend a flow
+  + its stages; do not hand-roll request logic (auth, transport, routing) in a
+  transport/adapter that skips the flow. A bypass silently deletes every hook on
+  that path.
+- **Adapters only translate.** A transport adapter (Express, the Web-fetch/worker
+  handler, stdio) converts its native request/response to the flow's normalized
+  `ServerRequest` + `httpRespond` output and then runs the **same** flows. Two
+  adapters must never diverge in behavior (e.g. one enforcing auth, another not).
+- **Fix runtime gaps in the flow, not around it.** If a flow stage can't run in a
+  target runtime (e.g. a stage needs a Node `ServerResponse` but a Worker only has
+  Web `Request`/`Response`), make the stage runtime-agnostic (emit normalized
+  output each adapter renders) — do not write a runtime-specific shortcut that
+  skips the flow.
+- **Cross-cutting concerns are stages, not inlined code.** Auth, quota, audit,
+  metrics belong to flow stages (so they're hookable), never re-implemented inside
+  an adapter.
+- **Use `FlowInputOf` / `FlowOutputOf`**, never ad-hoc `as { … }` casts on flow
+  results — a cast is a sign you're working around the flow instead of with it.
+
+If a change handles a request without going through a flow, or inlines a
+cross-cutting concern, it's wrong — rework it through a hookable flow.
+
 ## Server Lifecycle Hooks
 
 In addition to flow-based hooks, the framework exposes a single `scope.onServerStarted(callback)` API for post-startup work. Callbacks register against the active `ScopeEntry` and run after `server.start()` completes.

package/catalog/frontmcp-extensibility/references/skill-audit-log.md

@@ -6,7 +6,7 @@ tags: [extensibility, audit, skills, tamper-evident, signature, chain]
 
 # Skill Audit Log
 
-The `@frontmcp/adapters/skills` module provides a tamper-evident, hash-chained audit log for skill action executions. Every authority pass / authority fail / HTTP success / HTTP failure phase emitted by `execute-action.tool.ts` is captured, signed, and chained so any later mutation breaks signature verification.
+The `@frontmcp/adapters/skills` module provides a tamper-evident, hash-chained audit log for skill action executions. Every authority pass / authority fail / HTTP success / HTTP failure phase emitted by the skill-action executor (`run_workflow`'s `callTool`) is captured, signed, and chained so any later mutation breaks signature verification.
 
 ## Architecture
 
@@ -15,7 +15,7 @@ phase method assembles its payload internally and routes through a shared
 chain pipeline:
 
 ```text
-ExecuteActionTool.execute()
+run_workflow → callTool(action)
   ├── writer.writeAuthorityPass(ctx)             // authority-check-pass
   ├── writer.writeAuthorityFail(ctx, { reason }) // authority-check-fail
   ├── writer.writeHttpCallSuccess(ctx, { status, output })  // http-call-success

package/catalog/frontmcp-production-readiness/examples/production-cloudflare/durable-objects-state.md

@@ -19,10 +19,13 @@ Shows how to use Cloudflare Durable Objects for stateful coordination alongside
 
 ```toml
 # wrangler.toml — with Durable Objects and R2
-# NOTE: `main` is written by `frontmcp build --target cloudflare`. Do not hand-edit.
+# NOTE: `main`, `compatibility_date`, and `compatibility_flags` are written by
+# `frontmcp build --target cloudflare`. Do not hand-edit. nodejs_compat is
+# required — the worker entry needs Node builtins or it won't boot.
 name = "stateful-mcp-worker"
 main = "dist/cloudflare/index.js"
-compatibility_date = "2024-01-01"
+compatibility_date = "2024-09-23"
+compatibility_flags = ["nodejs_compat"]
 
 # KV for cache
 [[kv_namespaces]]

package/catalog/frontmcp-production-readiness/examples/production-cloudflare/wrangler-config.md

@@ -46,7 +46,8 @@ Checklist for verifying the `wrangler.toml` produced by `frontmcp build --target
 
 - [ ] No secrets in `wrangler.toml` — all set via `wrangler secret put <NAME>`
 - [ ] `[vars]` block contains only non-sensitive config (region names, feature flags)
-- [ ] `compatibility_date` set to a recent date and locked
+- [ ] `compatibility_date` set to a recent date and locked (the build defaults to `2024-09-23`, the date that enables full `nodejs_compat`)
+- [ ] `compatibility_flags` includes `nodejs_compat` — the build emits it automatically; without it the deployed Worker fails to boot (`require()`/`node:*` are unavailable)
 
 ## Deploy & observability
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@frontmcp/skills",
-  "version": "1.4.0",
+  "version": "1.5.0-rc.1",
   "description": "Curated skills catalog for FrontMCP projects",
   "author": "AgentFront <info@agentfront.dev>",
   "homepage": "https://docs.agentfront.dev",