chore(deps-dev): bump @docusaurus/types from 3.10.1 to 3.10.2

.github/workflows/deploy.yml

@@ -16,7 +16,7 @@ jobs:
         uses: actions/checkout@v6.0.3
 
       - name: Set up Node.js
-        uses: actions/setup-node@v6
+        uses: actions/setup-node@v7
         with:
           node-version: '20'
 

.github/workflows/pr-check.yml

@@ -0,0 +1,27 @@
+name: PR Check
+
+on:
+  pull_request:
+    branches: ["main"]
+
+jobs:
+  check:
+    runs-on: ubuntu-latest
+
+    steps:
+      - name: Checkout code
+        uses: actions/checkout@v6.0.3
+
+      - name: Set up Node.js
+        uses: actions/setup-node@v6
+        with:
+          node-version: '20'
+
+      - name: Install dependencies
+        run: npm ci
+
+      - name: Typecheck
+        run: npm run typecheck
+
+      - name: Build
+        run: npm run build

README.md

@@ -112,13 +112,34 @@ store.
 
 ### Background: issue #161
 
-Search on the production site failed because `docusaurus.config.ts` was
-configured to connect over HTTPS while the Typesense server at
+Search on the production site originally failed because `docusaurus.config.ts`
+was configured to connect over HTTPS while the Typesense server at
 `docs.operaton.org:8108` only ever served plain HTTP — the TLS handshake
 fails before any CORS headers can be returned, which browsers surface as a
-CORS error. Confirmed via direct query against the production server (over
-HTTP, using the public search key from the deployed site) that the
-`docusaurus` collection is indexed correctly (15k+ documents, real search
-results) — only the protocol mismatch was broken. The fix is to keep
-`docusaurus.config.ts` and the scraper step in
-`.github/workflows/deploy.yml` on `protocol: http`, matching the server.
+CORS error. The first fix switched the client config to `protocol: http` to
+match the server.
+
+That traded one broken state for another: `docs.operaton.org` is served over
+HTTPS, and browsers block an HTTPS page from making a plain-HTTP XHR request
+to anything ("mixed content"), regardless of whether the server would have
+answered correctly. Search still failed in a real browser — silently, with no
+network request even showing up in devtools, only a `Mixed Content` console
+error and an `ERR_NETWORK` from the Typesense client. A visible symptom of
+the same root cause: the "See all N results" footer in the search modal
+stayed stuck on the literal `{count}` placeholder, because `nbHits` never
+got populated. A direct `curl` against the production server (over HTTP,
+using the public search key) had confirmed the `docusaurus` collection was
+indexed correctly (15k+ documents) — that check bypasses the browser's
+mixed-content policy, so it didn't catch this.
+
+The actual fix: nginx on `docs.operaton.org` reverse-proxies `/typesense/` to
+the local Typesense container (`proxy_pass http://127.0.0.1:8108/`), so the
+browser talks to Typesense same-origin over HTTPS. `docusaurus.config.ts`
+defaults to `protocol: https`, `port: 443`, `path: /typesense` accordingly.
+Local dev keeps talking to the Docker Typesense instance directly — see
+`.env` above, which sets `TYPESENSE_PROTOCOL=http`, `TYPESENSE_PORT=8108`,
+and `TYPESENSE_PATH=` (empty, no proxy prefix) to override those defaults.
+The CI scraper step in `.github/workflows/deploy.yml` is unaffected: it runs
+on a GitHub Actions runner, not in a browser, so it keeps talking to
+`docs.operaton.org:8108` directly over plain HTTP — mixed content is a
+browser-only restriction.

docs/documentation/reference/release-notes/2_1/index.md

@@ -430,6 +430,12 @@ No configuration or code changes are required on the client side.
 
 ## Patch Releases
 
+### 2.1.3
+
+#### Security Vulnerabilities
+
+- **[fix(deps): pin vulnerable transitive dependencies](https://github.com/operaton/operaton/pull/3401)** — Pinned `netty` to `4.2.16.Final` (fixes [CVE-2026-56745](https://nvd.nist.gov/vuln/detail/CVE-2026-56745) and related netty advisories) and `jackson-bom` to `3.1.5` (fixes [CVE-2026-59889](https://nvd.nist.gov/vuln/detail/CVE-2026-59889)), overriding the vulnerable transitive versions managed by Spring Boot 4 and the Quarkus extension until those frameworks ship fixed versions. Backport of [#3390](https://github.com/operaton/operaton/pull/3390). (#3401)
+
 ### 2.1.2
 
 #### Bug Fixes

docs/documentation/reference/release-notes/2_2/index.md

@@ -112,6 +112,49 @@ content byte array has been fixed.
 
 This resolves [PR #3088](https://github.com/operaton/operaton/pull/3088).
 
+---
+
+### FEEL Engine Switched to the Unshaded Artifact
+
+Operaton 2.2 replaces the shaded `feel-engine` classifier from `org.camunda.feel` with the
+plain, unshaded artifact, and manages its real dependency tree (Scala, fastparse, geny,
+sourcecode, jackson-module-scala) explicitly instead.
+
+The shaded jar relocated Scala and fastparse to `camundajar.impl.*`, but bundled Jackson and
+paranamer without relocation. This caused duplicate-class conflicts with applications' own
+Jackson dependency (flagged by Maven Enforcer's `banDuplicateClasses`), and classpath-order
+dependent version mixing when the bundled Jackson classes clashed with a differing
+`jackson-annotations` version on the classpath. With the unshaded artifact, FEEL deterministically
+uses the platform's Jackson, governed by the shared `jackson-bom` import.
+
+Applications embedding the engine no longer need to work around these conflicts; the WildFly and
+Tomcat distributions now ship proper modules/libraries for the additional third-party jars this
+change pulls in.
+
+This implements [PR #3342](https://github.com/operaton/operaton/pull/3342).
+
+---
+
+### Security: Pinned Vulnerable Transitive Netty and Jackson Versions
+
+Operaton 2.2 pins `netty-bom` to **4.2.16.Final** and adds a `jackson-bom` (Jackson 3,
+`tools.jackson`) import at **3.1.5**, overriding the vulnerable transitive versions still
+managed by the current Quarkus (Netty **4.2.15**, affected by CVE-2026-56745 and related
+advisories) and Spring Boot (Jackson 3 **3.1.4**, affected by CVE-2026-59889) dependency
+platforms. Both pins are temporary and documented as removable once the respective upstream
+BOMs ship a fixed version.
+
+This resolves [PR #3390](https://github.com/operaton/operaton/pull/3390).
+
+---
+
+### Quarkus Updated to 3.33.2.1
+
+The Quarkus platform dependency has been updated to **3.33.2.1**, the latest patch release on
+the 3.33 LTS line.
+
+This implements [PR #3386](https://github.com/operaton/operaton/pull/3386).
+
 ## API
 
 ### Database Schema
@@ -159,7 +202,7 @@ Operaton is based on:
 
 ### Quarkus Extension
 
-The Operaton Quarkus extension is based on **Quarkus 3.33.1 LTS**.
+The Operaton Quarkus extension is based on **Quarkus 3.33.2.1 LTS**.
 
 ### Distributions
 

docs/documentation/user-guide/quarkus-integration/version-compatibility.md

@@ -55,6 +55,10 @@ Only these default combinations are recommended (and supported) by Operaton.
     <td>1.1.4</td>
     <td>3.30.8</td>
   </tr>
+  <tr>
+    <td>1.1.5</td>
+    <td>3.30.8</td>
+  </tr>
   <tr>
     <td>2.0.0</td>
     <td>3.32.0</td>
@@ -71,6 +75,14 @@ Only these default combinations are recommended (and supported) by Operaton.
     <td>2.1.2</td>
     <td>3.33.2.1 (LTS)</td>
   </tr>
+  <tr>
+    <td>2.1.3</td>
+    <td>3.33.3 (LTS)</td>
+  </tr>
+  <tr>
+    <td>2.1.4</td>
+    <td>3.33.3.1 (LTS)</td>
+  </tr>
 </table>
 
 In case a certain Quarkus version has a bug, you can override the existing Quarkus version by adding the following

docs/documentation/user-guide/spring-boot-integration/version-compatibility.md

@@ -54,6 +54,10 @@ Operaton and its compatible Spring Boot Starter always share the same version. E
     <td>1.1.4</td>
     <td>3.5.15</td>
   </tr>
+  <tr>
+    <td>1.1.5</td>
+    <td>3.5.16</td>
+  </tr>
   <tr>
     <td>2.0.0</td>
     <td>4.0.4</td>
@@ -70,4 +74,12 @@ Operaton and its compatible Spring Boot Starter always share the same version. E
     <td>2.1.2</td>
     <td>4.0.7</td>
   </tr>
+  <tr>
+    <td>2.1.3</td>
+    <td>4.0.7</td>
+  </tr>
+  <tr>
+    <td>2.1.4</td>
+    <td>4.0.8</td>
+  </tr>
 </table>

docusaurus.config.ts

@@ -7,10 +7,16 @@ import rehypeRegisterCustomIds from './src/plugins/rehype-register-custom-ids.js
 import remarkBpmnDiagram from './src/plugins/remark-bpmn-diagram.js';
 // This runs in Node.js - Don't use client-side code here (browser APIs, JSX...)
 
+// Defaults match the nginx reverse proxy at /typesense/ on the production
+// domain (see docker/typesense/README or the root README's Local Search
+// section) - the site is served over HTTPS, so the browser can't reach a
+// bare-HTTP endpoint on a different port (mixed content). Local dev overrides
+// all of these via .env to talk to the Docker Typesense instance directly.
 const typesenseApiKey = process.env.TYPESENSE_API_KEY?.trim();
 const typesenseHost = process.env.TYPESENSE_HOST?.trim() || 'docs.operaton.org';
-const typesensePort = Number(process.env.TYPESENSE_PORT) || 8108;
-const typesenseProtocol = process.env.TYPESENSE_PROTOCOL?.trim() || 'http';
+const typesensePort = Number(process.env.TYPESENSE_PORT) || 443;
+const typesenseProtocol = process.env.TYPESENSE_PROTOCOL?.trim() || 'https';
+const typesensePath = process.env.TYPESENSE_PATH?.trim() ?? '/typesense';
 
 const config: Config = {
   title: 'Operaton Documentation',
@@ -99,6 +105,7 @@ const config: Config = {
                   host: typesenseHost,
                   port: typesensePort,
                   protocol: typesenseProtocol,
+                  path: typesensePath,
                 },
               ],
               apiKey: typesenseApiKey,