fix(metadata-core): retire the ARRAY where.id rows the shared face now refuses before dispatch

The engine-double dispatch tables carried three rows whose where.id is an
array. The shared comparand-shape face now refuses that input at the engine
lowering seam before the dispatch runs, so the real engine answered them with
the face's refusal and the objectql harness went red. The rows are retired
with a note; the predicates are unchanged. Also adapts driver-memory's
vocabulary probe helper, which fed an array through every AST spelling, and
records the analytics FilterArray reading in the migration entry.

Claude-Session: https://claude.ai/code/session_013RDBh5DqXd2xnLwvHLgLFr
Co-authored-by: Claude <noreply@anthropic.com>

Author: claude

.changeset/19757-dispatch-cases-array-where-id-retired.md

@@ -0,0 +1,17 @@
+---
+"@objectstack/metadata-core": patch
+---
+
+`ENGINE_DELETE_DISPATCH_CASES` and `ENGINE_UPDATE_DISPATCH_CASES` retire their three ARRAY `where.id` rows (#19757)
+
+The engine-double conformance tables no longer carry these three rows:
+
+- delete's `array id, no multi`
+- update's `array id, no multi`
+- update's `a SCALAR data.id beside an ARRAY where.id`
+
+Each row puts `where: { id: ['a', 'b'] }` in the equality slot. Since this release's `@objectstack/spec` change, the shared comparand-shape face refuses an array in that slot with `INVALID_FILTER` / 400. The face runs at the engine's lowering seam, which every verb crosses before the dispatch runs, so the real engine never reaches the dispatch predicate with such an input. A row claiming a dispatch verdict for it would pin a branch the engine cannot reach. It was measured red against the real engine: `ObjectQL.delete` / `ObjectQL.update` refused the input with the face's words, not the dispatch's.
+
+The predicates themselves are unchanged. `resolveEngineDeleteDispatch` / `resolveEngineUpdateDispatch` and the `assert*` helpers still answer an array `where.id` with `reject`, and `scalarDeleteId` / `scalarUpdateId` still treat an array as not-an-id. A test double bound to them therefore still refuses such a call, with the dispatch's sentence. No double runs the shared filter face, for this shape or for any other face refusal. The `$in` rows keep the "a non-scalar `where.id` is not an id" coverage, including the #11230 refusal beside a scalar payload id.
+
+If you run these tables against your own engine double, it has three fewer cases to answer. Nothing else changes.

.changeset/19757-equality-slot-array-refused.md

@@ -49,10 +49,12 @@ On `driver-mongodb`, check what the query is supposed to return, and do not assu
 
 ## Who is affected, measured
 
-Nothing in this repository's examples, seeds, docs or published skills authors the shape. The repo was grepped for the FilterArray triple on `=` / `==` / `equals` / `eq` carrying an array, for `$eq` carrying an array, and for filter / where objects whose field value is an array. The only hits are tests, and two of them pinned the old accept set and were re-judged rather than rewritten by rote:
+Nothing in this repository's examples, seeds, docs or published skills authors the shape. The repo was grepped for the FilterArray triple on `=` / `==` / `equals` / `eq` carrying an array, for `$eq` carrying an array, and for filter / where objects whose field value is an array. The hits are tests and the engine-double conformance tables. The full suites of `@objectstack/spec`, `objectql`, `driver-memory`, `driver-sql`, `driver-mongodb`, `driver-turso`, `driver-sqlite-wasm`, `formula`, `service-analytics`, `metadata-protocol`, `metadata-core`, `plugin-sharing` and `lint` were run, and four things went red. Each was re-judged, not rewritten by rote:
 
 - The comparand-shape suite pinned `{ tags: ['a','b'] }` and `$eq: ['a','b']` as shapes the face passes through. Both rows are inverted, and the shapes now live in the arm's refusal section.
 - The field-reference lowering suite pinned `['stage', '=', ['a','b']]` lowering to the implicit form. What that row proved still holds, because an array is not promoted to `$eq`. The row now asserts the refusal, which names the implicit slot and not `$eq`.
+- Two probe helpers passed a two-element array through every AST spelling to find its `$` operator. One is in this package's comparand-shape suite, the other in `driver-memory`'s vocabulary suite. Each assumed the array could never trip the face. The equality spellings now refuse it, so each helper reads that refusal as `undefined`, which is the answer the helper always gave those spellings.
+- `@objectstack/metadata-core`'s engine-double dispatch tables carried three ARRAY `where.id` rows. The real engine now refuses that input at the face before its dispatch runs, so the rows are retired. Their own changeset explains why.
 
 `FILTER_COMPARAND_TYPE_CASES` gains three `door-refusal` rows (implicit, `$eq`, and nested under `$or`). Every driver suite that consumes the table runs them through `parseFilterAST`.
 

packages/drivers/driver-memory/src/memory-filter-ast-vocabulary.test.ts

@@ -93,10 +93,21 @@ describe('InMemoryDriver filter vocabulary ↔ VALID_AST_OPERATORS', () => {
    * gets a list here without anyone remembering to edit this line.
    *
    * The probe uses a two-element array, which is legal for all three list
-   * operators, so it never trips the shape door it is used to satisfy.
+   * operators, so it never trips the shape door it is used to satisfy. The
+   * EQUALITY spellings (`=`, `==`, `equals`, `eq`) do refuse it, since the
+   * 2026-09-23 equality-slot ruling (#19757) — and they answer `undefined`
+   * either way: before that ruling they lowered it to the implicit form, which
+   * carries no `$` key. So a refusal here reads as `undefined`, exactly the
+   * answer this helper always gave them, and `valueFor` still hands them a
+   * scalar.
    */
   const loweredOperatorOf = (op: string): string | undefined => {
-    const lowered = parseFilterAST([['probe', op, ['a', 'b']]]) as Record<string, unknown> | undefined;
+    let lowered: Record<string, unknown> | undefined;
+    try {
+      lowered = parseFilterAST([['probe', op, ['a', 'b']]]) as Record<string, unknown> | undefined;
+    } catch {
+      return undefined;
+    }
     const spec = lowered?.probe;
     if (spec === null || typeof spec !== 'object' || Array.isArray(spec)) return undefined;
     return Object.keys(spec).find((key) => key.startsWith('$'));

packages/metadata-core/src/engine-delete-dispatch.ts

@@ -292,7 +292,17 @@ export const ENGINE_DELETE_DISPATCH_CASES: readonly EngineDeleteDispatchCase[] =
   //    accepted it, and what a running server answers 500 to.
   { what: 'predicate on a non-id column, no multi', options: { where: { rule_id: 'r1' } }, expect: 'reject' },
   { what: '$in over ids, no multi (an operator object is NOT an id)', options: { where: { id: { $in: ['a', 'b'] } } }, expect: 'reject' },
-  { what: 'array id, no multi', options: { where: { id: ['a', 'b'] } }, expect: 'reject' },
+  // [#19757] An 'array id, no multi' row — `where: { id: ['a', 'b'] }` — sat
+  // here. Since the 2026-09-23 ruling the shared comparand-shape face
+  // (`@objectstack/spec/data`) refuses an ARRAY in the equality slot at the
+  // engine's lowering seam, which every verb crosses BEFORE this dispatch runs:
+  // the real engine now answers that input with the face's INVALID_FILTER / 400,
+  // so no dispatch verdict for it is observable any more, and a row claiming
+  // one would pin a branch the engine never reaches. Retired rather than
+  // re-spelled — the `$in` row above keeps the "a non-scalar is not an id"
+  // coverage, and `scalarDeleteId`'s own array pin stays. A double bound to this
+  // predicate still refuses an array id with the dispatch sentence: no double
+  // runs the face, for this shape or any other face refusal.
   { what: 'null id, no multi', options: { where: { id: null } }, expect: 'reject' },
   // The two shapes objectstack#5747 was filed for: a fake pinned to
   // `assertEngineDeleteDispatch` ACCEPTED both until this case-set could

packages/metadata-core/src/engine-update-dispatch.ts

@@ -625,7 +625,12 @@ export const ENGINE_UPDATE_DISPATCH_CASES: readonly EngineUpdateDispatchCase[] =
   // inherits the refusal rather than each one re-deriving it.
   { what: 'a SCALAR data.id beside an $in where.id and multi:true — refused; the row SET and the declared bulk intent were BOTH silently dropped (#11230 reverses the remaining half of the #5748 pin)', data: { id: 'rec_1', title: 'x' }, options: { where: { id: { $in: ['a', 'b'] } }, multi: true }, expect: 'reject' },
   { what: 'a SCALAR data.id beside an $in where.id, no multi — refused (#11230)', data: { id: 'rec_1', title: 'x' }, options: { where: { id: { $in: ['a', 'b'] } } }, expect: 'reject' },
-  { what: 'a SCALAR data.id beside an ARRAY where.id — refused (#11230)', data: { id: 'rec_1', title: 'x' }, options: { where: { id: ['a', 'b'] } }, expect: 'reject' },
+  // [#19757] A 'SCALAR data.id beside an ARRAY where.id' row sat here. The
+  // shared comparand-shape face now refuses an ARRAY in the equality slot at
+  // the engine's lowering seam, BEFORE this dispatch runs (ruled 2026-09-23),
+  // so the real engine answers it with the face's INVALID_FILTER / 400 and no
+  // #11230 verdict for it is observable. Retired, not re-spelled: the two `$in`
+  // rows above carry the #11230 "declared non-scalar where.id" refusal.
   { what: 'a SCALAR data.id beside a NULL where.id — refused (#11230)', data: { id: 'rec_1', title: 'x' }, options: { where: { id: null } }, expect: 'reject' },
   // [#11230] The boundary that does NOT move: a FALSY scalar `where.id` IS a
   // scalar, so it is not this refusal's shape at all and keeps the #11142
@@ -653,7 +658,12 @@ export const ENGINE_UPDATE_DISPATCH_CASES: readonly EngineUpdateDispatchCase[] =
   //    by hand tends to accept, and a running server answers 500 to.
   { what: 'predicate on a non-id column, no multi', data: { title: 'x' }, options: { where: { tenant: 't1' } }, expect: 'reject' },
   { what: '$in over ids, no multi (an operator object is NOT an id)', data: { title: 'x' }, options: { where: { id: { $in: ['a', 'b'] } } }, expect: 'reject' },
-  { what: 'array id, no multi', data: { title: 'x' }, options: { where: { id: ['a', 'b'] } }, expect: 'reject' },
+  // [#19757] An 'array id, no multi' row (`where: { id: ['a', 'b'] }`) sat
+  // here — retired for the reason the #11230 block above gives: the shared
+  // face refuses that input before this dispatch runs. The `$in` row above
+  // keeps the "a non-scalar is not an id" coverage; `scalarUpdateId`'s own
+  // array pin stays, and a double bound to this predicate still refuses an
+  // array id with the dispatch sentence (no double runs the face).
   { what: 'null id, no multi', data: { title: 'x' }, options: { where: { id: null } }, expect: 'reject' },
   { what: 'falsy scalar where.id (0), no multi', data: { title: 'x' }, options: { where: { id: 0 } }, expect: 'reject' },
   { what: 'empty where, no multi', data: { title: 'x' }, options: { where: {} }, expect: 'reject' },

packages/spec/src/migrations/entries/semantic/18.filter-equality-array-comparand-refused.ts

@@ -43,7 +43,10 @@ export const entry: SemanticMigration = {
     + 'translateFilter emits the array unchanged, and MongoDB equality on an array operand '
     + 'selects a stored array equal to ["a"] or holding ["a"] as an element — mingo 7.2.4, the '
     + 'named proxy, over ["a"], "a", ["a","b"], ["b","a"], [["a"],"x"], [["a"]], "b" and [] '
-    + 'selected ["a"], [["a"],"x"] and [["a"]]. A live mongod, MySQL, PostgreSQL and a live '
+    + 'selected ["a"], [["a"],"x"] and [["a"]]. The service-analytics filter normalizer read the '
+    + 'FilterArray form as MEMBERSHIP: ["stage", "=", ["won", "lost"]] charted as stage IN '
+    + '(won, lost); that form now gets the refusal too, while its OBJECT form, which that '
+    + 'normalizer does not route through the shared face, still reads as membership. A live mongod, MySQL, PostgreSQL and a live '
     + 'Turso server were NOT measured. So one stored filter was a 400 on most backends and a '
     + 'silent, differently-shaped row set on one. The shared face now refuses it with '
     + 'INVALID_FILTER / 400 before any driver runs, naming the field, the path and both remedies. '
@@ -62,7 +65,9 @@ export const entry: SemanticMigration = {
     + 'what it meant: one of these values ($in), the stored list holds a value ($contains, an '
     + '$or of them for several), or one value. Each is refused at query time with INVALID_FILTER '
     + '/ 400 naming the field and the path, so a test suite that exercises the query finds '
-    + 'every one. On driver-mongodb re-check what the query is supposed to return rather than '
+    + 'every one. A dashboard or dataset filter written as the FilterArray sugar with an array on '
+    + 'equality charted as membership through the analytics normalizer; $in is the spelling that '
+    + 'charts the same rows. On driver-mongodb re-check what the query is supposed to return rather than '
     + 'assuming the old rows were right: the old answer was MongoDB array equality, which '
     + 'neither $in nor $contains reproduces.',
 };

packages/spec/src/migrations/registry.ts

@@ -8740,7 +8740,10 @@ const step18: MigrationStep = {
         + 'translateFilter emits the array unchanged, and MongoDB equality on an array operand '
         + 'selects a stored array equal to ["a"] or holding ["a"] as an element — mingo 7.2.4, the '
         + 'named proxy, over ["a"], "a", ["a","b"], ["b","a"], [["a"],"x"], [["a"]], "b" and [] '
-        + 'selected ["a"], [["a"],"x"] and [["a"]]. A live mongod, MySQL, PostgreSQL and a live '
+        + 'selected ["a"], [["a"],"x"] and [["a"]]. The service-analytics filter normalizer read the '
+        + 'FilterArray form as MEMBERSHIP: ["stage", "=", ["won", "lost"]] charted as stage IN '
+        + '(won, lost); that form now gets the refusal too, while its OBJECT form, which that '
+        + 'normalizer does not route through the shared face, still reads as membership. A live mongod, MySQL, PostgreSQL and a live '
         + 'Turso server were NOT measured. So one stored filter was a 400 on most backends and a '
         + 'silent, differently-shaped row set on one. The shared face now refuses it with '
         + 'INVALID_FILTER / 400 before any driver runs, naming the field, the path and both remedies. '
@@ -8759,7 +8762,9 @@ const step18: MigrationStep = {
         + 'what it meant: one of these values ($in), the stored list holds a value ($contains, an '
         + '$or of them for several), or one value. Each is refused at query time with INVALID_FILTER '
         + '/ 400 naming the field and the path, so a test suite that exercises the query finds '
-        + 'every one. On driver-mongodb re-check what the query is supposed to return rather than '
+        + 'every one. A dashboard or dataset filter written as the FilterArray sugar with an array on '
+        + 'equality charted as membership through the analytics normalizer; $in is the spelling that '
+        + 'charts the same rows. On driver-mongodb re-check what the query is supposed to return rather than '
         + 'assuming the old rows were right: the old answer was MongoDB array equality, which '
         + 'neither $in nor $contains reproduces.',
     },