Merge remote-tracking branch 'origin/main' into claude/issue-21365-objectql-echo-window

Author: claude

.changeset/21376-boolean-comparand-compilers.md

@@ -0,0 +1,17 @@
+---
+'@objectstack/plugin-security': minor
+'@objectstack/service-analytics': minor
+---
+
+Row-level security policies and the analytics native-SQL path judge a comparand against a declared boolean field by the platform's boolean-comparand rule, the one the data engine's `where` already applies
+
+Clause-②: no (narrowing)
+
+<!-- adr-0087: not-required (no-migration-prescription) a refusal or narrowing of a filter comparand against a declared boolean column at two compilers outside the engine's where door, the same comparand that door already judges: no authorable key, spelling, export or stored shape moves. RowLevelSecurityPolicySchema, every permission set, every dataset, cube and analytics query parse and save as before, the predicate's and the filter's text are untouched, @objectstack/plugin-security and @objectstack/service-analytics export the same names with the same types, and no stored row is read or rewritten. Which boolean the author meant by a refused comparand is not something a ledger entry can decide, so there is nothing for objectstack migrate meta to rewrite. The other categories are closed on facts: both packages publish (not unpublished); no ADR-0087 id covers a filter comparand's type and this diff adds none (not registered / already-registered); and the change is runtime behaviour with no published interface or type changed (not runtime-interface-only / type-surface-only). -->
+
+**BREAKING**: this narrows what two compilers outside the engine's `where` door accept. The RLS compile seam now drops a row-level policy, and the analytics native-SQL face now refuses a query, when either compares a declared boolean field with a comparand outside the accepted set. It ships as `minor` under the launch-window convention for accept-set narrowings. No export, type or error code changes.
+
+- **Row-level security (`@objectstack/plugin-security`).** A compiled `using` / `check` predicate on a `boolean` or `toggle` column (or a `formula` returning `boolean`) is judged by `booleanComparandDoorVerdict` from `@objectstack/spec/data`, in the same pass as the number rule. `'true'` / `'false'`, `'1'` / `'0'` and `1` / `0` are read as the boolean each names. Anything else the rule refuses (a string such as `'yes'`, `'TRUE'` or `''`, a number other than `1` / `0`) drops the policy as a refused comparand: the read is filtered by the deny sentinel, the write is refused 403, and the WARN line names the clause, the field and the position. Before, `record.flag != 'true'` kept every row on SQLite and the write check admitted every row, so the exclusion the author wrote was not applied.
+- **Analytics native SQL (`@objectstack/service-analytics`).** The query's `where` (and the dataset query's `runtimeFilter`, which is merged into it), each measure's own `filter` and a dataset's own `filter` are judged by the same rule before the statement compiles. An accepted spelling is read as its boolean, and anything else the rule refuses is refused `INVALID_FILTER` / 400 with the rule's own message, before any statement runs. The native strategy now answers what the engine-aggregate strategy answers. Before, `{ flag: 'true' }` counted no rows on SQLite, `{ flag: { $ne: 'true' } }` counted every row, and `{ flag: 'yes' }` answered 200.
+- **What you may notice.** A policy or analytics filter that compared a boolean field with a value outside the accepted set now refuses instead of answering. Write `true` / `false`. A policy `record.flag == 1` now admits writing a `true` row, which its read already showed.
+- **Unchanged.** A boolean literal, a column that is not boolean, a `{ $field }` reference, and an object whose declaration cannot be read (nothing is judged without one).

.changeset/21397-null-ordering-message-faces.md

@@ -0,0 +1,25 @@
+---
+'@objectstack/spec': patch
+---
+
+fix(spec): the null ordering-comparand refusals name only evaluation faces that exist, and say only what was measured
+
+Clause-②: no
+
+`FieldOperatorsSchema` and `ComparisonOperatorSchema` refuse a `null` comparand of `$gt` / `$gte` /
+`$lt` / `$lte` with a pointed message. Its example of the evaluation faces disagreeing named
+driver-memory's reference matcher, which has been deleted, so an author or agent reading the
+refusal went looking for a face that no longer exists. The example now names two faces that exist
+and were measured to disagree: driver-memory's query path reads a stored `null` as equal to the
+comparand, so `{"$gte": null}` admits that row, while driver-sql compares against SQL `NULL` and
+admits no row.
+
+That refusal and its runtime twin, the `parseFilterAST` refusal for the same comparand
+(`Operator "$gt" on field "…" does not accept a null comparand …`), both said "no two evaluation
+faces agree" on what an ordering against `null` matches. Measured, two faces do agree (driver-sql
+and formula both admit no row), so both now say "the evaluation faces do not agree".
+
+Text only: each message's first sentence, its prescription (`{"$eq": null}` / `{"$ne": null}`), the
+schema door's ruling sentence and the runtime door's "NOT applied" sentence are unchanged, and both
+doors accept and refuse exactly the same filters. A client or log filter that matches the old
+wording needs the new spelling.

content/docs/permissions/rls.mdx

@@ -197,14 +197,23 @@ Layer 1 (business RLS)       ─┘
 
 ## The fail-closed contract
 
-Four ways a policy denies rather than leaks:
+Five ways a policy denies rather than leaks:
 
 1. A policy exists but **every** applicable expression fails to compile → a
    deny-everything filter.
 2. A referenced context variable is missing, null, or an empty array → that
    policy drops out (it cannot match).
 3. A policy references a column the object doesn't have → deny.
-4. `check` is omitted → `using` stands in as the `check`. The choice is
+4. A policy compares a column with a literal its declared type cannot be
+   compared with → that policy drops out, for `using` and `check` alike: on a
+   `boolean` / `toggle` column, anything but `true` / `false` and the
+   spellings `'true'` / `'false'`, `1` / `0` and `'1'` / `'0'`
+   (`active == 'yes'`, `active != 'TRUE'`, `active == 2`); on a numeric
+   column, a comparand that is not a number (a string with no numeric reading,
+   a boolean). These are the comparisons a caller's `where` is refused for
+   (`INVALID_FILTER`). An accepted spelling is read as the value it names, so
+   `active != 'true'` hides the `true` rows exactly as `active != true` does.
+5. `check` is omitted → `using` stands in as the `check`. The choice is
    made per operation across all the applicable policies, not policy by
    policy: when any of them declares a `check`, only the declared checks
    decide, and a USING-only sibling's `using` is not part of the check.