docs(engines),ci(rustcfml): document RustCFML support, de-experimentalize the lane, and bump the pin to v0.637.0

- cfml-engines.mdx: add RustCFML as the fourth supported engine with a
  dedicated section (launcher usage, PR CI + release matrix gating, the
  no-JVM java.* caveat) and a 'Pick an engine' entry.
- compat-matrix.yml: rename 'rustcfml (experimental)' to 'rustcfml',
  drop continue-on-error, and refresh the stale informational-lane
  comment to reference the required PR check.
- run-suite.sh: update the header comment and preserve the baseline's
  _notes on --write-baseline regenerations.
- baseline.json: add _notes linking the tracked failure to upstream
  RustCFML issues #376-#381.
- Bump ENGINE_VERSION to v0.637.0.

Signed-off-by: Peter Amiri <peter@alurium.com>

Author: bpamiri

.github/workflows/compat-matrix.yml

@@ -589,20 +589,21 @@ jobs:
           path: /tmp/junit-results/
 
   #############################################
-  # RustCFML (experimental, JVM-free engine)
+  # RustCFML (JVM-free engine)
   #############################################
-  # Informational lane, never a merge gate. The engine is pinned in
+  # Supported engine leg: the release-matrix counterpart of the required
+  # PR check in .github/workflows/rustcfml-ci.yml (which runs the same
+  # suite on every pull request to develop). The engine is pinned in
   # tools/rustcfml/ENGINE_VERSION (upstream ships multiple releases/day, so
   # tracking latest would make this lane flake on engine churn). Pass criteria
   # is "no NEW failures vs tools/rustcfml/baseline.json" — known residual
-  # errors (no-JVM limitations, open upstream issues) live in the baseline.
-  # To bump the pin: update ENGINE_VERSION, run
+  # errors (open upstream issues, listed in the baseline notes) live in the
+  # baseline. To bump the pin: update ENGINE_VERSION, run
   #   bash tools/rustcfml/run-suite.sh --write-baseline
-  # locally, and commit both files together.
+  # on Linux, and commit both files together.
   rustcfml:
-    name: "rustcfml (experimental)"
+    name: "rustcfml"
     runs-on: ubuntu-latest
-    continue-on-error: true
     steps:
       - name: Checkout Repository
         uses: actions/checkout@v5

tools/rustcfml/ENGINE_VERSION

@@ -1 +1 @@
-v0.635.2
+v0.637.0

tools/rustcfml/baseline.json

@@ -1,5 +1,5 @@
 {
-  "engineVersion": "v0.635.2",
+  "engineVersion": "v0.637.0",
   "totals": {
     "totalSpecs": 5375,
     "totalPass": 5350,
@@ -9,5 +9,10 @@
   },
   "failing": [
     "wheels.tests.specs.migrator.migrationSpec :: Tests addIndex :: creates an index on multiple columns"
+  ],
+  "_notes": [
+    "Known residual failures are upstream RustCFML engine bugs; each entry above maps to an open issue on https://github.com/RustCFML/RustCFML:",
+    "migrationSpec 'creates an index on multiple columns' -> https://github.com/RustCFML/RustCFML/issues/377 (query-of-query recordCount corruption after repeated QoQs).",
+    "Earlier tracked bugs now fixed framework-side or upstream were: #376 Hash(binary), #378 java.io.File two-arg constructor, #379 void-assignment key deletion, #380 GetTempDirectory separator, #381 new-operator name lowercasing."
   ]
 }

tools/rustcfml/run-suite.sh

@@ -2,11 +2,11 @@
 # Run the Wheels core suite on the pinned RustCFML engine build and compare the
 # outcome against the checked-in known-failure baseline (tools/rustcfml/baseline.json).
 #
-# RustCFML is a JVM-free CFML engine under active development. This lane is
-# informational: it is never a merge gate. Pass criteria is "no NEW failures
-# versus the baseline", not zero failures — a set of known residual errors
-# (no-JVM limitations and open upstream engine issues) is expected and tracked
-# in the baseline file.
+# RustCFML is a supported JVM-free CFML engine. This script backs both the
+# required PR check (.github/workflows/rustcfml-ci.yml) and the release-matrix
+# leg (compat-matrix.yml). Pass criteria is "no NEW failures versus the
+# baseline", not zero failures — residual engine bugs are tracked in
+# tools/rustcfml/baseline.json with upstream issue links in the "_notes" key.
 #
 # Usage:
 #   bash tools/rustcfml/run-suite.sh                  # compare against baseline
@@ -138,6 +138,14 @@ if mode == "write":
         "totals": totals,
         "failing": sorted(failing.keys()),
     }
+    # Preserve the human-maintained "_notes" (upstream issue links) across
+    # regenerations.
+    try:
+        existing = json.load(open(baseline_path))
+        if isinstance(existing.get("_notes"), list):
+            payload["_notes"] = existing["_notes"]
+    except Exception:
+        pass
     with open(baseline_path, "w") as fh:
         json.dump(payload, fh, indent=2)
         fh.write("\n")

web/sites/guides/src/content/docs/v4-0-0/start-here/cfml-engines.mdx

@@ -1,14 +1,14 @@
 ---
 title: CFML Engines
-description: Run Wheels on Lucee, Adobe ColdFusion, or BoxLang. The wheels CLI ships with Lucee; the framework runs on all three.
+description: Run Wheels on Lucee, Adobe ColdFusion, BoxLang, or the JVM-free RustCFML interpreter. The wheels CLI ships with Lucee; the framework runs on all four.
 type: explanation
 sidebar:
   order: 6
 ---
 
 import { Aside, Tabs, TabItem, Steps, CardGrid, LinkCard } from '@astrojs/starlight/components';
 
-Wheels is the framework. **The framework runs on three CFML engines:** Lucee, Adobe ColdFusion, and BoxLang. The `wheels` CLI is a separate thing — it's a developer convenience that bundles a Lucee runtime so newcomers can `brew install wheels` and have a working dev server in one step. If you need Adobe CF or BoxLang for development or production, you don't use the `wheels` CLI's bundled runtime; you use a CommandBox-managed server (or a manual install) and the framework handles the rest.
+Wheels is the framework. **The framework runs on four CFML engines:** Lucee, Adobe ColdFusion, BoxLang, and RustCFML. The `wheels` CLI is a separate thing — it's a developer convenience that bundles a Lucee runtime so newcomers can `brew install wheels` and have a working dev server in one step. If you need Adobe CF, BoxLang, or RustCFML for development or production, you don't use the `wheels` CLI's bundled runtime; you use a CommandBox-managed server (or a manual install) and the framework handles the rest.
 
 ## TL;DR
 
@@ -17,8 +17,11 @@ Wheels is the framework. **The framework runs on three CFML engines:** Lucee, Ad
 | Lucee 6 / 7 | Yes — bundled, recommended | Yes | Yes |
 | Adobe ColdFusion 2023 / 2025 | No — install manually | Yes — recommended | Yes |
 | BoxLang | No | Yes | Yes |
+| RustCFML | No | No — ships its own launcher | Yes¹ |
 
-The framework's CI matrix (`.github/workflows/compat-matrix.yml`) runs every release against Lucee 6, Lucee 7, Adobe CF 2023, Adobe CF 2025, and BoxLang on each release. Engine support is hard-gated.
+¹ RustCFML is a JVM-free interpreter, so app code that calls `java.*` classes through `CreateObject("java")` does not work on it. The core suite runs green against a pinned RustCFML build with one tracked upstream bug (a query-of-query `recordCount` issue) — see [Running Wheels on RustCFML](#running-wheels-on-rustcfml).
+
+The framework's CI matrix (`.github/workflows/compat-matrix.yml`) runs every release against Lucee 6, Lucee 7, Adobe CF 2023, Adobe CF 2025, BoxLang, and RustCFML, and a dedicated RustCFML leg (`.github/workflows/rustcfml-ci.yml`) runs on every pull request to `develop`. Engine support is hard-gated.
 
 ## Why the `wheels` CLI is Lucee-only
 
@@ -87,11 +90,24 @@ The `wheels start`, `wheels stop`, `wheels reload`, and `wheels test` commands a
 
 Wheels' BoxLang compatibility is verified per release in the same CI matrix as Lucee and Adobe CF. Cross-engine gotchas worth knowing about live in [`.ai/wheels/cross-engine-compatibility.md`](https://github.com/wheels-dev/wheels/blob/develop/.ai/wheels/cross-engine-compatibility.md) — most are about minor differences in struct/array semantics under closures.
 
+## Running Wheels on RustCFML
+
+[RustCFML](https://github.com/RustCFML/RustCFML) is a JVM-free CFML interpreter written in Rust. It ships its own launcher instead of a CommandBox module: download the binary for your platform from the [releases](https://github.com/RustCFML/RustCFML/releases) page and point it at your Wheels app's `public/` directory:
+
+```bash
+rustcfml --serve public --port 8080
+```
+
+Wheels treats RustCFML as a first-class engine. The framework's core test suite (all 5,300+ specs) runs against a pinned RustCFML build on every pull request to `develop` via `.github/workflows/rustcfml-ci.yml` and on every release in the compatibility matrix. The suite is green except for one tracked upstream engine bug — a query-of-query `recordCount` edge case ([RustCFML/RustCFML#377](https://github.com/RustCFML/RustCFML/issues/377)) recorded in `tools/rustcfml/baseline.json`, which the CI leg compares against so *new* failures block a merge while the known one does not.
+
+Because there is no JVM, RustCFML cannot run `CreateObject("java", …)` — any app code (or third-party package) that reaches into `java.*` classes will not work on it. The Wheels framework core has been made engine-agnostic, so framework features (routing, ORM, migrations, storage signing, channels, auth hashing) run without the JVM.
+
 ## Pick an engine
 
 - **You're new to Wheels and want the easiest path:** Lucee, with the bundled `wheels` CLI. Skip the rest of this page.
 - **Your team standardised on Adobe CF:** CommandBox + Adobe CF. Skip the bundled CLI's `start`/`stop` commands; use `box server` instead.
 - **You want a modern, performant CFML runtime and don't have legacy Adobe scripts to support:** BoxLang via CommandBox.
+- **You want a small, JVM-free runtime (edge/serverless, WASM-targetable) and no app code needs `java.*`:** RustCFML, serving `public/` directly.
 - **You're shipping to a production server you don't control:** the framework runs on whatever engine that server uses; the `wheels` CLI doesn't ship to production.
 
 ## Related