Merge remote-tracking branch 'origin/main' into claude/issue-15702-half-states-h45-parent-half

Author: claude

.changeset/driver-memory-notcontains-non-string-value.md

@@ -0,0 +1,9 @@
+---
+"@objectstack/driver-memory": patch
+---
+
+fix(driver-memory): the reference matcher's `$notContains` arm answers the predicate, not a type test, for a stored non-string value
+
+`match()` used to answer `{ n: { $notContains: '5' } }` with NO for `{ n: 5 }` — the arm read `typeof value !== 'string' || value.includes(target)`, so a number failed `$contains` (correct) AND its negation (wrong: for the very reason a number cannot contain the substring, it does not contain it). This package's own live mingo path admitted the row, so one filter answered two ways depending on which face was asked; on this face the failure mode was silently dropped rows.
+
+The arm now answers what `FILTER_TEXT_CASES`' new `score` rows declare on every face (maintainer ruling 2026-09-05 on the contract card): a stored value that is not a string never satisfies a positive text operator and always satisfies `$notContains`. The no-value cells keep their #13166 answer; nothing else in the matcher moved.

.changeset/driver-sql-text-operator-non-text-column.md

@@ -0,0 +1,11 @@
+---
+"@objectstack/driver-sql": minor
+---
+
+A text operator over a column whose declared type stores no text (`Field.number` and its numeric siblings, `Field.boolean`) now compiles to the contract's declared answer on every dialect, instead of a dialect accident.
+
+Before: `{ score: { $contains: '5' } }` over a numeric column compiled `col GLOB '*5*'` on SQLite and coerced the REAL in its storage class's spelling (`5` as `'5.0'`, so `$endsWith: '0'` matched every row), `col LIKE $1 ESCAPE $2` on Postgres and was refused at query time with SQLSTATE 42883 (`operator does not exist: real ~~ text` — a 500 for a filter the spec accepts), and `CAST(col AS BINARY) LIKE ?` on MySQL.
+
+Now (`FILTER_TEXT_CASES`' `score` rows, maintainer ruling 2026-09-05): the positive operators (`$contains` / `$startsWith` / `$endsWith` / `$icontains` / `$like` / `$ilike`) compile to `1 = 0` and `$notContains` to `1 = 1` — the same row set as every JS face, decided from the declared type at compile time because the stored value is not visible until run time. Postgres: a 500 becomes a result. The gate reads the `numericFields` / `booleanFields` registries `initObjects` and `registerExternalObject` already fill; a table this driver was never told about keeps the `LIKE` / `GLOB` it always compiled, every comparand refusal still runs first, and the constants compose with the NULL-safe rules (`$notContains` admits a NULL row already) and the `$not` rewrite. Temporal columns are untouched: their stored value IS text on SQLite, so the contract declares nothing for them.
+
+`driver-sqlite-wasm` and `driver-turso`'s local transport inherit this compiler.

.changeset/driver-turso-remote-text-operator-non-text-column.md

@@ -0,0 +1,7 @@
+---
+"@objectstack/driver-turso": minor
+---
+
+The remote transport compiles a text operator over a declared numeric or boolean column to the contract's declared answer, in step with the local transport.
+
+`RemoteTransport.buildWhereSQL` compiles filters independently of `SqlDriver` and keeps no schema, so a text operator over a `Field.number` used to compile `"col" GLOB ?` and coerce the REAL in the storage class's spelling (`5` as `'5.0'`). `TursoDriver` now hands the transport its declared-type rule (`setNonTextColumnResolver`, the same shape as the temporal `setFilterColumnSql` rule), answered from the registries `registerRemoteFieldMetadata` already fills at schema sync — so a positive text operator over such a column compiles to `1 = 0` and `$notContains` to `1 = 1` on BOTH transports (`FILTER_TEXT_CASES`' `score` rows, maintainer ruling 2026-09-05), instead of a dialect accident. A transport nobody handed the rule to compiles exactly as before, and every comparand refusal still runs ahead of the constant.

.changeset/filter-text-non-string-stored-value.md

@@ -0,0 +1,15 @@
+---
+"@objectstack/spec": minor
+---
+
+`FILTER_TEXT_CASES` declares what a text operator answers over a stored value that is NOT a string, and the fixture gains its first non-string column.
+
+Measured before this row existed, one filter over one numeric column answered four ways across the platform: `driver-memory`'s reference matcher said NO to `$contains` and to `$notContains` for the same row; its live mingo path, `formula`, objectql's `having`, `driver-mongodb` and the analytics face type-gated (`$contains` NO, `$notContains` YES); the SQLite family coerced the number to text in its storage class's spelling (REAL renders `5` as `'5.0'`); and live Postgres refused at query time with SQLSTATE 42883 — a 500.
+
+The maintainer ruled the cell on 2026-09-05 (option A, type-gate): a stored value that is not a string never satisfies a positive text operator (`$contains` / `$startsWith` / `$endsWith` / `$icontains` / `$like` / `$ilike`) and satisfies `$notContains` — complementarity holds, on every face. Coercion was refused on the measurement; a declared-type door that refuses the filter before any backend runs is deferred to its own decision card, not rejected.
+
+- `FilterTextRow` is now `{ id, name, score }` — `score` is a NUMBER on every row (a `0` among them), chosen so a coercing backend answers a visibly non-empty set and a truthiness guard drops a row.
+- Five new evaluated rows over `score`: the four positive operators the table can carry answer `[]`, `$notContains` answers all nine. (`$like` / `$ilike` follow the same rule and are pinned on the faces that answer them — the table is a driver's enrolment and `driver-mongodb` refuses those two.)
+- `NON_TEXT_STORED_VALUE_TYPES` (`field-value.zod.ts`) — the numeric and boolean value classes, i.e. the declared field types whose stored value is never text — is the list the SQL faces classify a column by at compile time, since they cannot read the value. Temporal types are deliberately absent: their stored form is a dialect question (ADR-0053) the row does not decide.
+
+Every suite that materialises the fixture adds the column (SQL `initObjects` DDL included).

.changeset/service-analytics-text-operator-non-text-column.md

@@ -0,0 +1,7 @@
+---
+"@objectstack/service-analytics": minor
+---
+
+The three SQL compilers in this package — the RLS read-scope lowering (`compileScopedFilterToSql`), `NativeSQLStrategy`'s own `where` and the `ObjectQLStrategy` SQL echo — compile a text operator over a column whose declared type stores no text to the contract's declared answer.
+
+`compileScopedFilterToSql(filter, alias, options?)` takes a new optional `nonTextColumn(field)` predicate; when it answers `true`, a positive text operator compiles to `1 = 0` and `$notContains` to `1 = 1` instead of a `LIKE` that coerces on SQLite (`5` renders `'5.0'`) and is refused at query time on Postgres (SQLSTATE 42883 — a 500 on a read scope the platform accepted). The service answers the predicate from the field metadata hook it already holds (`sourceFieldMeta`), exposed to strategies as `DatasetScopedStrategyContext.declaredFieldType`, and the two strategies pass it for the read scope and for the query's own text filters, so a query and its RLS scope answer one cell one way and the echo prints the statement that ran (`FILTER_TEXT_CASES`' `score` rows, maintainer ruling 2026-09-05). A host that wires no field metadata keeps the `LIKE` it always got, and every comparand refusal still runs ahead of the constant.

.changeset/spec-notification-event-migration-id.md

@@ -0,0 +1,11 @@
+---
+"@objectstack/spec": minor
+---
+
+`@objectstack/spec/system` now names the ADR-0030 notification cut-over, so "has this deployment run it?" has a place to be answered.
+
+`sys_migration` is the ledger a deployment writes to record that a data migration ran against its own database, and consumers read it instead of the platform version. Its well-known ids were `adr-0104-file-references` and `adr-0104-value-shapes` — the two ADR-0104 scans, both driven by an `os migrate` command that records the row. `migrateSysNotificationToEvent` (`@objectstack/metadata/migrations`) had none. It is destructive and one-way, operators are handed the call verbatim in `docs/handoff/adr-0030-notification-convergence.md`, and it recorded nothing when it ran: a deployment that performed the cut-over and one that never did are indistinguishable from the ledger. A row can only be keyed by an id, so without one the question had nowhere to be answered even in principle.
+
+Added: `NOTIFICATION_EVENT_MIGRATION_ID = 'adr-0030-notification-event'`, exported from `@objectstack/spec/system`. Purely additive — no existing export, schema or predicate changes, and nothing reads the new id yet.
+
+Deliberately NOT decided here, and the constant's docblock says so rather than leaving its silence to be read as an answer: what a `sys_migration` row under this id means. The two ADR-0104 ids get their `last_run_at` / `applied_at` / `verified_at` / `blocking` semantics from a command that scans, self-checks and only then records; this migration has no command and no self-check, and reports `migrated` / `already_done` / `not_applicable` / `error` to its caller instead. Which of those columns one of its runs may claim, whether anything may gate on the row, and whether a datastore created after the cut-over belongs in `CREATION_ATTESTED_MIGRATION_IDS`, are contract questions on this surface and are left open.

content/docs/protocol/kernel/error-handling.mdx

@@ -346,27 +346,27 @@ deriving it from this page.
 - Check user has permission to see resource (row-level security)
 - Resource may have been deleted
 
-#### `DUPLICATE_RECORD`
+#### `UNIQUE_VIOLATION`
 **HTTP Status:** 409  
-**Meaning:** Resource with unique constraint already exists
+**Meaning:** The write collides with a unique constraint — a record already holds that value
 
 **Example:**
 ```json
 {
-  "success": false,
-  "error": {
-    "code": "DUPLICATE_RECORD",
-    "message": "Account with email 'john@acme.com' already exists",
-    "details": {
-      "resource": "account",
-      "constraint": "unique",
-      "field": "email",
-      "value": "john@acme.com"
-    }
-  }
+  "error": "A record with this email already exists",
+  "code": "UNIQUE_VIOLATION",
+  "field": "email",
+  "object": "account"
 }
 ```
 
+The engine throws `DuplicateRecordError`, whose in-process `code` is
+`DUPLICATE_RECORD`; the REST door translates that envelope at the boundary, so
+every route answers the wire code `UNIQUE_VIOLATION` and the in-process spelling
+never crosses HTTP. The refusal is emitted as the flat body shown above, and
+`field` is best-effort — see
+[HTTP API](/docs/protocol/kernel/http-protocol) for the degraded shape.
+
 **How to fix:**
 - Check for existing resource before creating
 - Update existing resource instead of creating new one
@@ -947,7 +947,7 @@ Even error responses can be abused:
 // Attacker tries to enumerate user emails
 for (let i = 0; i < 1000000; i++) {
   await register({ email: `user${i}@example.com` });
-  // Response: "DUPLICATE_RECORD" or "VALIDATION_ERROR"
+  // Response: "UNIQUE_VIOLATION" or "VALIDATION_ERROR"
 }
 ```
 

docs/adr/0130-release-artifact-as-co-ownership-boundary.md

@@ -1,8 +1,6 @@
 # ADR-0130: The release artifact is the co-ownership boundary — one artifact, N packages
 
-**Status**: Proposed (2026-09-01) — awaiting the maintainer's hand-merge, which is itself the
-acceptance act for a governed surface (Prime Directive #14). ⛔ Nothing below is settled until
-this record merges; the implementation cards are cut **from** the merged ADR, never ahead of it.
+**Status**: Accepted (2026-09-01) — accepted by the merge that landed it on `main` ([#14151](https://github.com/objectstack-ai/objectstack/pull/14151), commit `682d03ba7`), which is itself the acceptance act for a governed surface (Prime Directive #14).
 **Scope bounded by the 2026-09-02 addendum**
 ([#14487](https://github.com/objectstack-ai/objectstack/issues/14487)): the permission matrix
 §1.3(a) measures is **not** part of this boundary's payoff — permission sets stay whole in the

packages/drivers/driver-memory/src/memory-filter-text-conformance.test.ts

@@ -94,8 +94,11 @@ describe('[#6682] InMemoryDriver — text-operator conformance, the query path',
 
   it('the fixture is all nine rows, stored verbatim', async () => {
     const rows = await driver.find(TABLE, { orderBy: [{ field: 'id', order: 'asc' }] });
-    expect((rows as any[]).map((r) => [String(r.id), r.name]))
-      .toEqual(FILTER_TEXT_ROWS.map((r) => [r.id, r.name]));
+    expect((rows as any[]).map((r) => [String(r.id), r.name, r.score]))
+      .toEqual(FILTER_TEXT_ROWS.map((r) => [r.id, r.name, r.score]));
+    // [#14079] The premise of the non-string rows: `score` is stored as a
+    // NUMBER on this driver, not stringified on the way in.
+    for (const r of rows as any[]) expect(typeof r.score, `row ${r.id}`).toBe('number');
   });
 
   for (const c of rowCases) {
@@ -137,7 +140,17 @@ describe('[#5374] the two general-purpose faces agree, case by case', () => {
    * this card are about.
    */
   it('no case answers every row — a dropped predicate WIDENS', async () => {
+    // [#14079] ONE case legitimately selects the whole fixture: `$notContains`
+    // over the non-string column, whose declared answer IS every row (a number
+    // never contains the substring, so every number "does not contain" it).
+    // It is named here so the property stays a property, not a loophole — a
+    // second whole-set answer is the widening this pin exists to catch, and a
+    // dropped predicate on THAT case is caught by its positive twins (whose
+    // declared answer is NO rows) and by the face-agreement row above.
+    const WHOLE_SET = '$notContains is satisfied by every stored value that is not a string — complementarity holds';
+    expect(rowCases.filter((c) => c.expected.length === ROWS.length).map((c) => c.name)).toEqual([WHOLE_SET]);
     for (const c of rowCases) {
+      if (c.name === WHOLE_SET) continue;
       expect((await queryIds(driver, c.filter)).length, c.name).toBeLessThan(ROWS.length);
       expect(matcherIds(c.filter).length, c.name).toBeLessThan(ROWS.length);
     }
@@ -207,6 +220,9 @@ describe('[#6682] the analytics face answers the same text rules', () => {
     dimensions: {
       id: { name: 'id', label: 'Id', type: 'string', sql: 'id' },
       name: { name: 'name', label: 'Name', type: 'string', sql: 'name' },
+      // [#14079] The fixture's non-string column, declared as the number it is
+      // so the `score` rows reach this face through its own vocabulary.
+      score: { name: 'score', label: 'Score', type: 'number', sql: 'score' },
     },
   } as unknown as Cube;
 
@@ -247,12 +263,15 @@ describe('[#6682] the analytics face answers the same text rules', () => {
       .every((ops) => Object.keys(ops).every((op) => EXPRESSIBLE.includes(op))),
   );
 
-  it('covers the whole expressible subset — twelve cases, not an accidental one', () => {
+  it('covers the whole expressible subset — fifteen cases, not an accidental one', () => {
     // Twelve since #8934: the infix `icontains` spelling's `%`-literal case is
     // computed through `parseFilterAST` and lands as `$icontains`, so it joins
     // this face's expressible subset automatically — exactly the mechanism the
-    // selection note above promises.
-    expect(analyticsCases.length).toBe(12);
+    // selection note above promises. Fifteen since #14079: three of the five
+    // non-string rows (`$contains` / `$icontains` / `$notContains` over
+    // `score`) are in this face's vocabulary and join the same way; the
+    // `$startsWith` / `$endsWith` pair stays outside it, refused loudly.
+    expect(analyticsCases.length).toBe(15);
   });
 
   for (const c of analyticsCases) {
@@ -275,3 +294,51 @@ describe('[#6682] the analytics face answers the same text rules', () => {
     expect(await analyticsIds({ name: { $icontains: 'CAFÉ' } })).toEqual(['3']);
   });
 });
+
+/**
+ * [#14079] `$like` / `$ilike` over a stored value that is not a string.
+ *
+ * The ruling names all six positive operators, but the shared table cannot
+ * carry `$like` rows — a driver's enrolment is the whole table (rule 2 of its
+ * header) and `driver-mongodb` refuses those two operators — so the pair is
+ * pinned per face that answers it. Same shape as the table's `score` rows:
+ * the positive pattern matches NOTHING, its `$not` matches EVERYTHING, on
+ * both faces, and the two faces agree before either is checked against the
+ * answer. Under coercion `'%5%'` would match seven rows and `'%0'` every row
+ * on a REAL column (`5` renders `'5.0'`), which is the wrong answer the
+ * assertion keeps out.
+ */
+describe('[#14079] $like / $ilike over a stored non-string value, on both faces', () => {
+  let driver: InMemoryDriver;
+  beforeEach(async () => { driver = await seed(); });
+
+  const ALL = FILTER_TEXT_ROWS.map((r) => r.id);
+  const CASES: Array<[string, unknown, string[]]> = [
+    ['$like never matches a stored number', { score: { $like: '%5%' } }, []],
+    ['$like with a trailing wildcard never matches a stored number', { score: { $like: '%0' } }, []],
+    ['$ilike never matches a stored number', { score: { $ilike: '%5%' } }, []],
+    ['$not over $like admits every stored number — complementarity', { $not: { score: { $like: '%5%' } } }, ALL],
+    ['$not over $ilike admits every stored number', { $not: { score: { $ilike: '%5%' } } }, ALL],
+  ];
+
+  for (const [name, filter, expected] of CASES) {
+    it(name, async () => {
+      const fromQuery = await queryIds(driver, filter);
+      const fromMatcher = matcherIds(filter);
+      expect(fromMatcher, 'the reference matcher disagrees with the query path').toEqual(fromQuery);
+      expect(fromQuery).toEqual(expected);
+    });
+  }
+
+  it('the reference matcher answers BOTH polarities for a valued non-string row — the #14079 cell itself', () => {
+    // The measured defect: `{ n: 5 }` failed `$contains: '5'` AND
+    // `$notContains: '5'`. A type test in place of the predicate says NO to an
+    // operator and to its negation; the predicate says NO to one and YES to
+    // the other.
+    const row = { id: 'x', n: 5 };
+    expect(match(row, { n: { $contains: '5' } })).toBe(false);
+    expect(match(row, { n: { $notContains: '5' } })).toBe(true);
+    expect(match({ id: 'y', n: 0 }, { n: { $notContains: '0' } })).toBe(true);
+    expect(match({ id: 'z', n: true }, { n: { $notContains: 'true' } })).toBe(true);
+  });
+});

packages/drivers/driver-memory/src/memory-matcher-no-value-negated-operators.test.ts

@@ -102,12 +102,21 @@ describe('[#13166] no-value rows and the negation-carrying operators', () => {
       expect(ids(MISSING, { name: { $contains: 'one' } })).toEqual(['1']);
     });
 
-    it('a present non-string value still fails $notContains on the type test', () => {
-      // Out of scope for this card, and stated so a later reader does not read
-      // the fix above as "any non-string satisfies the negation". Only the
-      // no-value readings moved; a value that is there and is not a string
-      // keeps the answer it had.
-      expect(ids([{ id: '9', name: 42 }], { name: { $notContains: 'one' } })).toEqual([]);
+    it('[#14079] a present non-string value SATISFIES $notContains — the predicate, not the type test', () => {
+      // This pin used to assert the opposite (`toEqual([])`), stated as out of
+      // #13166's scope: "a value that is there and is not a string keeps the
+      // answer it had". That answer was NO to `$notContains` AND to
+      // `$contains` for the same row — a type test standing in for the
+      // predicate — and it disagreed with this package's own live mingo path.
+      // The maintainer ruled the cell on 2026-09-05 (option A, type-gate):
+      // a stored value that is not a string never satisfies a positive text
+      // operator and always satisfies `$notContains`. Flipped here in its new
+      // direction, and asserted with substance: the row IS in the negation,
+      // is NOT in the positive twin, and the two still partition the rows.
+      const rows = [{ id: '1', name: 'alpha-one' }, { id: '9', name: 42 }];
+      expect(ids(rows, { name: { $notContains: 'one' } })).toEqual(['9']);
+      expect(ids(rows, { name: { $contains: 'one' } })).toEqual(['1']);
+      expect(ids([{ id: '0', name: 0 }, { id: 'f', name: false }], { name: { $notContains: 'one' } })).toEqual(['0', 'f']);
     });
   });