@@ -0,0 +1,40 @@
+---
+"@objectstack/driver-mongodb": patch
+---
+
+fix(driver-mongodb): the `$contains` family is case-SENSITIVE — the hardcoded `$options: 'i'` is gone (#6682)
+
+**Row-set change for anyone filtering text on MongoDB.** `$contains`,
+`$notContains`, `$startsWith` and `$endsWith` translated to a `$regex` with a
+hardcoded `$options: 'i'` beside it, which is MongoDB's full-Unicode case fold.
+That flag is off all four arms. `{ name: { $contains: 'acme' } }` no longer
+returns `ACME Corp`.
+
+This is #4706 **Q2 = A** — the family is case-sensitive on every backend —
+arriving at the last driver that was on the wrong side of it. #6518 flipped the
+SQL family (`GLOB` on the SQLite dialects, `LIKE` over a binary cast on MySQL,
+`LIKE` unchanged on Postgres); `formula`, ObjectQL's `having` and
+service-analytics' compilers were already case-exact.
+
+**Both directions of the defect mattered.** The fold OVER-matched — it returned
+rows the filter excludes, which on an RLS read scope is over-reach rather than a
+loose filter (#3948) — and it folded the whole Unicode range, overshooting the
+ASCII-only boundary Q1 = A holds `$icontains` to.
+
+**If you were relying on the fold, write `$icontains`.** It is the deliberate
+case-insensitive spelling, implemented on this driver since #6520, and it folds
+ASCII only (`café` does not match `CAFÉ`) — the one domain every backend can
+deliver.
+
+Unchanged: `escapeRegex`, so the comparand is still matched LITERALLY (`a.b`
+matches `a.b`, not `axb`), and `$icontains`, whose fold has always lived in the
+pattern rather than in `$options`. Every face of this driver —
+`find`/`count`/`update`/`delete` and the aggregation `$match` — routes through
+the one `translateFilter`, so there is no second answer to align.
+
+The driver's `FILTER_TEXT_CASES` conformance cell is now CLEARED: the new
+server-free suite `mongodb-filter-text-conformance.test.ts` imports the shared
+case-set and drives all seventeen cases, rejection rows included, and the DEBT
+row for this cell is deleted from `scripts/check-driver-conformance.mjs`.
+`driver-memory`'s half of #6682 stays open under the #5499 freeze, so that card
+remains open.
@@ -0,0 +1,10 @@
+---
+'@objectstack/metadata-protocol': patch
+'@objectstack/metadata': patch
+---
+
+Fix commit-revert answering `VERSION_NOT_FOUND` over a row `/history` lists, and the package-level revert route answering 500
+
+**Revert (`revertCommit` / `rollbackMetaItem`).** Both revert callers resolved their overlay repository from the caller's *active organization*, while the publish that recorded the commit routes each draft to the draft's **own** scope (the ADR-0005 / #3115 rule `SysMetadataRepository.listDrafts` states, and `publishPackageDrafts` already follows). So an env-wide artifact — what Studio and AI authoring write — published from a console request carrying an active org stored its `sys_metadata_history` rows at `organization_id = NULL` and was then read back at `organization_id = <org>`: no match, and the revert answered `VERSION_NOT_FOUND: No history row at version 2` for a version the history endpoint lists. The revert now resolves the scope the item's lineage actually lives in (the caller's own overlay first, env-wide second), per item for a batch revert. The same resolution reaches the `#6602` registry heal and the `#4636` package-binding read, which an org-scoped revert of an env-wide row was previously skipping while reporting success.
+
+**`POST /packages/:id/revert`.** The route now answers a declared 4xx instead of 500 (ADR-0112). The cause was entirely in the thrown shape, not the route: `MetadataManager.revertPackage` threw bare `Error`s carrying no `code` or `status`, and `errorFromThrown` — which the route's handler already reaches through one enclosing `catch` — falls back to 500 only when it finds neither. An unknown package id now answers `RESOURCE_NOT_FOUND` / 404 and a never-published package `RESOURCE_CONFLICT` / 409; 500 remains only as the fallback for a genuinely unexpected throw.
@@ -339,12 +339,13 @@ metacharacters — `{ name: { $icontains: 'a.b' } }` matches `a.b` and not `axb`
 
   One half of the case rules above is still landing: `$contains` /
   `$startsWith` / `$endsWith` / `$notContains` are case-**sensitive** by ruling and
-  are so on the SQL family, but the in-memory driver's query path and MongoDB still
-  fold them over the whole Unicode range —
-  [#6682](https://github.com/objectstack-ai/objectstack/issues/6682). Until that
-  lands, prefer `$icontains` when you *want* a fold rather than relying on
-  `$contains` being loose on those two backends. The shared standard both halves
-  are measured against is `FILTER_TEXT_CASES` (`@objectstack/spec/data`).
+  are so on the SQL family and on MongoDB —
+  [#6682](https://github.com/objectstack-ai/objectstack/issues/6682) removed the
+  hardcoded `$options: 'i'` that had folded them there. The in-memory driver's
+  query and analytics faces still fold over the whole Unicode range. Until that
+  half lands, prefer `$icontains` when you *want* a fold rather than relying on
+  `$contains` being loose on that backend. The shared standard both halves are
+  measured against is `FILTER_TEXT_CASES` (`@objectstack/spec/data`).
 </Callout>
 
 ### `$regex` — removed
@@ -963,13 +964,15 @@ a user typing `acme` does not find `ACME Corp`. Only `select` / `status` option
 *labels* are matched case-insensitively by the expansion itself.
 
 <Callout type="warn">
-  **Measured today, and it does not match that rule yet.** The `$contains` alignment
-  is [#5702](https://github.com/objectstack-ai/objectstack/issues/5702), so until it
-  lands the answer is still the driver's: `SqlDriver` compiles a parameterised
-  `LIKE '%…%'` and the dialect decides (SQLite folds ASCII, Postgres does not),
-  `driver-mongodb` folds the full Unicode range through a hardcoded `$options: 'i'`,
-  and `driver-memory`'s query path matches with a case-insensitive regex. Which
-  driver you run therefore still changes which rows a search returns. Whether the
+  **Measured today: one driver still does not match that rule.** The `$contains`
+  alignment landed in two steps —
+  [#6518](https://github.com/objectstack-ai/objectstack/issues/6518) made `SqlDriver`
+  case-exact per dialect (`GLOB` on the SQLite dialects, `LIKE` unchanged on
+  Postgres, `LIKE` over a binary cast on MySQL), and
+  [#6682](https://github.com/objectstack-ai/objectstack/issues/6682) removed
+  `driver-mongodb`'s hardcoded `$options: 'i'`. `driver-memory`'s query path still
+  matches with a case-insensitive regex, so running your tests on the in-memory
+  double can still return rows a SQL or MongoDB deployment would not. Whether the
   expansion should emit `$icontains` instead of `$contains` — i.e. whether search is
   case-insensitive by definition — is a separate question that rides with that issue,
   because it can only be answered once both operators mean one thing everywhere.
 
@@ -276,7 +276,7 @@
       "title": "Every demonstrable flow node type authors in the designer, executes in a run, and surfaces its step in run logs",
       "since": "v15",
       "status": "active",
-      "revision": 2,
+      "revision": 3,
       "priority": "P1",
       "surface": "mixed",
       "personas": [
@@ -323,7 +323,8 @@
         "approval chain: PATCH a showcase_expense_report to submitted (approval via showcase_expense_signoff); PATCH a showcase_project budget above 100000 to open showcase_budget_approval, then POST /api/v1/approvals/requests/:id/revise so the run parks at the approval_revise node",
         "webhook chain: POST /api/v1/automation/hooks/showcase_inbound_task_webhook/intake with a valid x-objectstack-signature HMAC (secret 'showcase-webhook-secret') to exercise create_record",
         "for EACH variant: GET the owning flow's runs (GET /api/v1/automation/<name>/runs + /runs/:runId) and locate a step whose nodeType equals the variant; record run id, step status, and — for suspending types — the paused-then-resumed transition",
-        "screenshot the Runs panel of one composite run (showcase_project_escalation or showcase_fan_out_notify) showing the container-nested steps"
+        "screenshot the Runs panel of one composite run (showcase_project_escalation or showcase_fan_out_notify) showing the container-nested steps",
+        "unknown-type probe (the late-binding contract, ruled status quo in #7545): POST /api/v1/automation a flow whose one non-start node carries type 'bogus_node' — capture the HTTP status and the server log record the registration emits, then POST /api/v1/automation/<that flow>/trigger and read GET /api/v1/automation/<that flow>/runs/:runId"
       ],
       "acceptance": [
         {
@@ -355,10 +356,16 @@
           "oracle": "api",
           "verify": "spot-check one body step per container kind for parentNodeId + regionKind (deep coverage lives in automation.flow-run-step-nesting)",
           "evidence": "tagged step excerpts"
+        },
+        {
+          "clause": "an UNKNOWN node type is late-bound, not refused — and a run reads that as PASS BY DESIGN (maintainer ruling on #7545, 2026-08-11: registration-time soft-fail on an unknown node type is the intended posture, 'deliberate late binding with a declaration — not tolerance masking an error'). The contract has four parts and ALL FOUR must hold: (1) POST /api/v1/automation with type 'bogus_node' answers 200 and really registers the flow; (2) the registration emits a located WARN whose message carries the load-bearing phrase 'no registered executor or descriptor' and names the offending flow, with unknownTypes + the FULL knownTypes vocabulary in the record's structured meta slot (#6654 — both lists ride meta, never the message text); (3) triggering that flow answers success:false carrying the NO_EXECUTOR-class message \"No executor registered for node type 'bogus_node'\"; (4) the run is recorded status 'failed', with the offending step status 'failure' and error.code 'NO_EXECUTOR'. Rationale, do not re-litigate: ADR-0018 §M1 has registerFlow() soft-validate node types against the live registry ('warn, don't hard-fail') so a flow authored against a currently-absent plugin still registers, and #4771 is the ordering incident that seam protects — the check fires only once sealNodeTypeVocabulary() has closed the vocabulary, and only for an ENABLED flow",
+          "oracle": "api",
+          "verify": "from the unknown-type probe step, cite all four: the 200 + the stored flow read-back; the WARN record (message phrase + meta.unknownTypes + meta.knownTypes); the trigger response success:false + its message; and the run detail status 'failed' with the NO_EXECUTOR step. The 200 at registration is the EXPECTED answer and is never on its own a finding — the finding is any of the other three parts missing",
+          "evidence": "registration status + WARN log record (message and meta) + trigger response + run-detail excerpt"
         }
       ],
       "negative": [
-        "registering a flow with an unregistered node type (e.g. type 'bogus_node') must be REFUSED at registerFlow / POST /api/v1/automation — the type is validated against the live action registry (ADR-0018), and silent acceptance of an inert node is the #1887 failure shape"
+        "the unknown-type probe going SILENT is the FAIL this clause guards — registration answering 200 with no WARN at all, or a WARN that drops the phrase 'no registered executor or descriptor' / omits meta.unknownTypes / omits the full meta.knownTypes vocabulary, is the #1887 silent-inert-node failure shape. So is the run side going quiet: a trigger answering success:true, a run not recorded 'failed', or a failed run whose step carries no NO_EXECUTOR error code. ⛔ The 200 itself is NOT a finding — #7545 ruled the registration-time soft-fail intended (ADR-0018 §M1, #4771); a run reporting FAIL on the 200 alone is misreading this item"
       ],
       "traps": [
         "wrong-panel",
@@ -375,7 +382,10 @@
         "packages/spec/src/automation/approval.zod.ts (APPROVAL_NODE_TYPE, APPROVAL_REVISE_NODE_TYPE)",
         "examples/app-showcase/src/coverage.ts (flowNodeTypes + FLOW_NODE_WAIVERS)",
         "examples/app-showcase/src/automation/flows/index.ts",
-        "packages/runtime/src/route-ledger.ts (GET /automation/actions, POST /automation/:name/trigger, GET /automation/:name/runs)"
+        "packages/runtime/src/route-ledger.ts (GET /automation/actions, POST /automation/:name/trigger, GET /automation/:name/runs)",
+        "docs/adr/0018-unified-node-action-registry.md §M1 (registerFlow() soft-validates node types against the live registry — 'warn, don't hard-fail')",
+        "packages/services/service-automation/src/engine.ts (registerFlow's ADR-0018 §M1 comment + the post-seal warn branch; warnUnknownNodeTypes's message and its unknownTypes/knownTypes meta; the NO_EXECUTOR step error in executeNode)",
+        "#7545 (maintainer ruling 2026-08-11 — status quo upheld: soft-fail at registration is the intended posture, so 200-on-unknown-type is pass-by-design)"
       ],
       "history": [
         {
@@ -389,6 +399,12 @@
           "date": "2026-08-08",
           "change": "pinned enumSource for the variants-freshness ratchet — spec enum drift is caught by the manual check on this item directly",
           "ref": "claude/platform-test-checklist-ocwugl"
+        },
+        {
+          "revision": 3,
+          "date": "2026-08-11",
+          "change": "recorded the #7545 ruling: the unknown-node-type clause demanded a registration-time REFUSAL the platform never promised, so run #7516 read a by-design 200 as a FAIL. The clause now asserts the real four-part late-binding contract (200 + located WARN with unknownTypes/knownTypes in meta + trigger success:false with NO_EXECUTOR + run 'failed') as pass-by-design, and the negative names silence — not the 200 — as the failure shape",
+          "ref": "#7545 (ADR-0018 §M1, #4771; QA run #7516)"
         }
       ],
       "enumSource": {