Merge remote-tracking branch 'origin/main' into claude/issue-21409-star-count-only

Author: claude

.changeset/20301-lint-list-view-tabs-walk-deleted.md

@@ -0,0 +1,11 @@
+---
+"@objectstack/lint": patch
+---
+
+The list-view field-reference rule no longer walks a list view's own `tabs[].filter`
+
+Clause-②: no
+
+The list view's own `tabs` is a `retiredKey` tombstone on every list-view shape, and this rule judges the parsed stack, so the key could never reach the walk: the parse refuses it first, with its prescription. The dead branch is deleted. The rule still judges `filter` and `userFilters.tabs[].filter` exactly as before.
+
+No finding changes for any stack that `os validate`, `os lint` or `os build` accepts.

.changeset/20301-metadata-protocol-list-view-tabs-walk-deleted.md

@@ -0,0 +1,9 @@
+---
+"@objectstack/metadata-protocol": patch
+---
+
+`computeViewReferenceDiagnostics` no longer walks a list view's own `tabs[].filter`
+
+Clause-②: no
+
+The list view's own `tabs` is a `retiredKey` tombstone on every list-view shape. The write door refuses it, and a stored or artifact-shipped body has it stripped by the conversion replay before it is served, so the read could never see it. A served body that still carries it is already badged by the spec diagnostics (`computeMetadataDiagnostics`), with the tombstone's prescription. The `userFilters.tabs[].filter`, `filterableFields` and `kanban` checks are unchanged.

.changeset/20301-spec-view-container-name-ledger-note.md

@@ -0,0 +1,15 @@
+---
+"@objectstack/spec": patch
+---
+
+Liveness ledger: the view container's body `name` row stays `dead`, and its note now states what the platform actually does with the key
+
+Clause-②: no
+
+- The old note said the body copy was "a copy nobody reads". Measured, the metadata door stamps the save name into every saved view body that has none, containers included (`normalizeViewMetadata` in `@objectstack/metadata-protocol`). Its overlay paths key on that stamped copy: `hydrateOverlayIntoRegistry` registers no body without a `name`, and `mergePackageAwareOverlay` slots an overlay row by it.
+- The verdict is unchanged, because the ledger's `live` means that authoring the key changes runtime behaviour. An authored container `name` only restates the key the container already registers under, or contradicts it. `os validate` and `os lint` keep warning `liveness-dead-property` ("drop it").
+- The note records why the key is kept rather than tombstoned: the door's own saves stamp it, so a tombstone would refuse the platform's own writes. A maintainer ruling also refused a spec-level forbid of a container's `name`.
+- It corrects the old attribution too. Artifact-shipped containers and the metadata-validation sweep author no `name`; what was read as theirs is the door's stamp.
+- The ledger README's `view` cell says the same. The `view.list.tabs` row's note now records that the two author-time walks that still read a list view's own `tabs` are deleted.
+- A comment in `system/i18n-resolver.ts` that still called the list view's own `tabs` a live carrier now says the key is a tombstone and `UserFiltersSchema.tabs` is the one carrier.
+- ⛔ No schema, parse, export, status or accept-set change.

.changeset/21279-record-activity-host-feed-guidance.md

@@ -0,0 +1,12 @@
+---
+'@objectstack/spec': patch
+---
+
+fix(spec): `record:activity`'s props row names `items` / `loading` as the host's feed slot when it refuses them
+
+Clause-②: no
+
+`ComponentPropsMap['record:activity']` (`RecordActivityProps`) refused an authored `properties.items` or `properties.loading` with only the generic "Unrecognized key(s) on this `record:activity`" line. Both are keys the objectui `record:activity` renderer reads, as a feed a host that composes the block in code already owns, so an author copying a TSX composition into a JSON page met no reason for the refusal.
+
+- The refusal now says who reads each key on each mount the row reaches. On a standalone `record:activity`, `items` is the host's data channel and `loading` the host's fetch state for that feed. On a `record:chatter` / `record:discussion` `feed`, which is the same object, nothing reads either. The remedy is the same on both: omit them. The block then presents the record page's discussion feed, and a standalone `record:activity` with no discussion context fetches the record's own `sys_activity` rows. This is the same `guidance` shape `record:history`'s row already uses for `entries` / `loading`.
+- The accept set does not change. Both keys stay refused, through the row and through `record:chatter` / `record:discussion`'s `feed`, which is the same object. Only the message text changes; `record:history` is unchanged.

.changeset/21293-single-series-multi-measure-refused.md

@@ -0,0 +1,66 @@
+---
+'@objectstack/spec': minor
+---
+
+feat(spec)!: a `pie` / `donut` / `funnel` / `treemap` / `sankey` dashboard widget takes ONE measure with a dimension too — two or more are refused at `values`, and the check export is renamed `checkDashboardWidgetChartMeasureArity` (#21293; extends #20958)
+
+Clause-②: yes (narrowing) — the accept set NARROWS (that is the change), and the published surface swaps one export for another: `checkDashboardWidgetDimensionlessMeasureArity` is removed and `checkDashboardWidgetChartMeasureArity` is added in its place, the same check with a second arm.
+
+<!-- adr-0087: registered dashboard-widget-single-series-multi-measure-refused -->
+
+**BREAKING** accept-set narrowing at `dashboard.widgets[].values`, plus one renamed
+export, shipped as `minor` under this repo's launch-window convention for breaking
+changes (`check-changeset-no-major` refuses `major` while the window is open, so
+breaking-ness is carried by this banner and by the ADR-0087 disposition above,
+never by the bump level). The prescription is registered under protocol major 18
+as `dashboard-widget-single-series-multi-measure-refused`.
+
+**What was wrong.** The previous release refused two or more measures on a
+dimensionless `pie` / `donut` / `funnel` / `scatter` / `radar` / `treemap` /
+`sankey`, and stepped aside for any widget that declared a dimension. Five of those
+types draw ONE series whatever the dimension: objectui's chart renderer binds the
+first series on its `pie` / `donut`, `funnel`, `treemap` and `sankey` arms and reads
+no other, so `{ type: 'pie', dimensions: ['stage'], values: ['revenue', 'cost'] }`
+drew one slice per stage for `revenue` and no trace of `cost`. Measured on this tree
+before the change: that body parsed through `DashboardWidgetSchema` on all five
+types (and on `scatter` / `radar` / `bar` / `table`), while `bogusProp` on the same
+widget was refused by name, the lit control. After it, the five are refused at
+`widgets[N].values`; `scatter` and `radar` with a dimension are outside the ruling
+and parse as before.
+
+### Write instead
+
+| wrote | write instead |
+|---|---|
+| `{ id: 'mix', type: 'pie', dataset: 'sales', dimensions: ['stage'], values: ['revenue', 'cost'] }` | `{ id: 'mix', type: 'table', dataset: 'sales', dimensions: ['stage'], values: ['revenue', 'cost'] }` — a column per measure |
+| the same, wanting a chart | `type: 'bar'` (or `column` / `horizontal-bar`) — one bar per measure in each stage |
+| the same, wanting the pie | `{ id: 'mix', type: 'pie', …, values: ['revenue'] }` **and** `{ id: 'mix_cost', type: 'pie', …, values: ['cost'] }` — one widget per measure, each with its own `id` (and `layout`, if you pin positions) |
+| `import { checkDashboardWidgetDimensionlessMeasureArity } from '@objectstack/spec/ui'` | `import { checkDashboardWidgetChartMeasureArity } from '@objectstack/spec/ui'` — same `(widget, ctx)` signature; chain it where the old name was chained |
+
+No conversion does this for you: whether a two-measure pie by stage meant a table, a
+grouped bar chart or two pies is an authoring choice. The refusal is ONE `custom`
+issue at `widgets[N].values` naming the widget's `id`, the number of measures and
+the authored `type`, and saying that type draws one series whatever its
+`dimensions`.
+
+**Why the export is renamed.** The dimensionless rule's check now has a second arm
+that judges widgets WITH a dimension, so its old name described a boundary that no
+longer exists. It refuses everything the old name refused, word for word on a
+dimensionless widget. No first-party consumer chained the old name: objectui's
+`DashboardWidgetSchema` mirror chains `checkDashboardWidgetStageOrder` and
+`checkDashboardWidgetMetricMeasureArity` only, measured at the pinned objectui
+commit and on objectui's `main`.
+
+**Nothing else moves.** One measure parses on every type; `scatter` and `radar`
+keep accepting several measures with a dimension; every type in
+`DASHBOARD_WIDGET_MULTI_MEASURE_TYPES` keeps accepting any number of measures with
+or without a dimension; a dimensionless widget of the five keeps the dimensionless
+refusal, word for word and still ONE issue; the metric family's refusal is
+unchanged; an empty `values` keeps its `too_small`; a `type` outside
+`ChartTypeSchema` reports the type refusal alone. Census at the branch point
+(`4b20c8474`), every tracked `.ts` / `.tsx` / `.js` / `.mjs` / `.cjs` / `.json` /
+`.md` / `.mdx` / `.yml`: 496 literals carry `values: [...]`, 33 of them on one of
+the seven types, and the only dimensioned multi-measure one on the five is a spec
+test fixture that pinned the old acceptance (moved to the refusal in this change).
+The same scan over objectui at its pinned commit (`89cad75d5`) finds no authored
+widget of that shape — its one hit is the prose example in a changeset.

.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/21388-activity-withheld-update-row.md

@@ -0,0 +1,17 @@
+---
+'@objectstack/plugin-audit': patch
+---
+
+fix(plugin-audit): an activity row recording an update whose every changed field the reader is withheld is no longer served to that reader, on any listing face
+
+Clause-②: no
+
+A `sys_activity` row's recorded change (`metadata.old` / `metadata.new`) is narrowed key by key for each reader, through the security service's served-fields answer. An update whose every changed field the reader is withheld still reached that reader as a row with an empty change, and its summary, actor and timestamp said that the record changed, and when. An org member holding object-level `sys_activity` read was served that row for each sign-in stamp on a colleague's identity record (`last_login_at`), and for each failed-sign-in counter bump, lockout, password-change stamp and MFA-required stamp.
+
+Such a row is now withheld from that reader as a row:
+
+- **What counts as one.** An update row (its stored change has both an `old` and a `new` side) whose stored change had at least one key, where the reader is served none of those keys. The keys are read from the STORED change, not the redacted one.
+- **What is unaffected.** A create or a delete keeps its row. A row whose stored change is empty on both sides (an update that touched only `internal` fields) is unaffected. A mixed update keeps its row, with the served keys only. A reader served every field (an administrator) still reads every row with its change, within the pre-scan's bound. A system-context read is not narrowed.
+- **Every face agrees.** The rule is a WHERE built from a system-context pre-scan on `find`, `findOne`, `count` and `aggregate`. So a list's `total`, its pages, a by-id read (`404`) and a grouped count agree with the rows served. A pre-scan that reaches its 2,000-row bound answers a broad read from the rows it judged, for every reader, administrators included, and logs a warning. The remedy is to scope the query by `object_name` and `record_id`.
+
+No migration: no key, export or config changes. A reader the security service gives no answer for (no security plugin wired) is not narrowed, as before.

.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.

.changeset/21405-permission-denied-status.md

@@ -0,0 +1,9 @@
+---
+'@objectstack/plugin-security': patch
+---
+
+`PermissionDeniedError` declares its 403 as `status` as well as `statusCode`, so a permission refusal answers 403 at every door (#21405).
+
+Clause-②: no
+
+The class declared `statusCode` alone, unlike every other error class in `errors.ts`, and a door that reads `status` alone derived no status from it. On a showcase boot, a plain member's `POST /api/v1/share-links` on a record they cannot read answered `500` with code `PERMISSION_DENIED` through `plugin-sharing`'s route door, while the runtime dispatcher's `/share-links` domain answered the same refusal with `403`. Both doors now answer `403 PERMISSION_DENIED`. The code, the message and `statusCode` are unchanged.

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.