Merge remote-tracking branch 'origin/main' into claude/drop-require-auth

# Conflicts:
#	packages/rest/src/rest.test.ts

Author: claude

.changeset/adr-0105-status-phase2-d8-d9.md

@@ -0,0 +1,7 @@
+---
+---
+
+Docs-only: record in ADR-0105's status line that Phase 2 D8 (scoped
+invitations, #3645/#3663/#3674/#3695/#3722/#3767) and D9 (cross-org approval
+targeting, #3824/#3873) are implemented, and that the membership-role channel
+D8 replaces is closed by ADR-0108. Releases nothing.

.changeset/adr-0111-depth-share-management.md

@@ -0,0 +1,27 @@
+---
+"@objectstack/spec": minor
+"@objectstack/plugin-sharing": minor
+"@objectstack/plugin-security": minor
+---
+
+feat(sharing): hierarchy managers may manage shares within their write DEPTH (ADR-0111 D1 DEPTH)
+
+`canManageShares` gains its named DEPTH extension: a caller whose effective
+WRITE scope on the object is a hierarchy scope (`unit` / `unit_and_below` /
+`own_and_reports`) may now manage shares on a record whose owner falls within
+that scope's owner set — the same set the write filter and `canEdit` already
+honour, resolved by the enterprise `hierarchy-scope-resolver`. This lets a
+manager grant/revoke/list shares on a subordinate's record, matching
+Salesforce (roles above the owner) and Dataverse (the `Share` privilege's BU
+depth), without expanding the MVP owner + Modify-All authority.
+
+- New `ISecurityService.resolveWriteScope(object, context)` — the effective
+  write scope, resolved by the same evaluator the CRUD middleware uses; fails
+  closed to `own`. Mirrored on the sharing plugin's structural probe.
+- The gate honours only the three hierarchy scopes. `org` from the probe is
+  deliberately ignored: it means both a genuine Modify-All holder (already
+  granted via `hasWriteBypass`) AND the fail-OPEN "no permission set mentions
+  this object" default, so honouring it here would reopen the hole
+  `hasWriteBypass` was chosen to avoid.
+- Fails closed with no security service or no enterprise resolver — the open
+  edition stays owner + Modify-All, exactly as before.

.changeset/adr-0113-required-write-contract.md

@@ -0,0 +1,40 @@
+---
+"@objectstack/spec": major
+"@objectstack/objectql": major
+"@objectstack/driver-sql": major
+---
+
+feat!: ADR-0113 — `required` is a write contract; the column constraint becomes the explicit `storage.notNull`
+
+`field.required` bound three meanings to one knob (write check, `NOT NULL` DDL,
+drift expectation), so tightening any invariant on a deployed object was a
+destructive migration blocked by the very legacy nulls that motivated it — the
+reason `criteria_json`'s mandatory-in-substance contract lived in three
+imperative guards instead of one declaration.
+
+Split, with the **non-regression invariant** as the unifying rule — *a write
+may not take a record from compliant to violating; a pre-existing violation
+does not block writes that leave it in place*:
+
+- `required: true` = the write contract, uniformly on new and deployed objects:
+  insert must provide; **an update PATCHing `null` into a required field is now
+  rejected** (it silently passed before); omitted fields never block, so legacy
+  null rows rest. The column stays nullable.
+- `storage: { notNull: true }` = the explicit physical constraint, owning the
+  DDL (`sql-driver` `createColumn`) and the destructive drift ceremony.
+  Orthogonal to `required` — all four combinations are legitimate, including
+  the engine-populated column (`storage.notNull` without `required`).
+- `requiredWhen` inherits the same invariant: flipping the condition true
+  without providing the field is rejected (the write *creates* the violation);
+  a row violating since before the rule tightened no longer locks out
+  unrelated edits (#3929's objection, cured). `storage.notNull` ×
+  `requiredWhen` rejects at parse (`FieldSchema.superRefine`).
+- **Pre-17 sources keep their exact meaning** via the migration-chain-only
+  `field-required-notnull-explicit` conversion: `os migrate meta` stamps
+  `storage.notNull` onto every previously-required field — writing down what
+  the old text already meant. The loader never infers semantics from the
+  physical column.
+- Drift compares nullability against `storage.notNull`; a column stricter than
+  its declaration is `needs_confirm` (never auto-applied — dev auto-reconcile
+  no longer silently strips a stray `NOT NULL`), and silent when the field is
+  write-gated by `required`.

.changeset/adr-0114-field-error-catalog.md

@@ -0,0 +1,53 @@
+---
+"@objectstack/spec": minor
+"@objectstack/rest": minor
+"@objectstack/objectql": minor
+---
+
+feat(spec,rest,objectql)!: a closed field-level error catalog, and Zod stops leaking onto the wire (#3977)
+
+Settles the vocabulary ADR-0112 D6 deferred, per [ADR-0114](https://github.com/objectstack-ai/objectstack/blob/main/docs/adr/0114-field-level-error-code-catalog.md).
+
+**`FieldErrorCode` — a closed, lowercase catalog.** 27 members covering what the
+six emitters already emit. `FieldErrorSchema.code` tightens from `z.string()` to
+this enum, so a validation body's per-field codes are validated for the first time.
+`FieldValidationError.code` (objectql) and `FieldCoerceError.code` (rest) stop
+being a hand-listed union and a bare `string` respectively and reference the
+catalog, so the three cannot drift apart.
+
+Lowercase is deliberate, not an oversight against ADR-0112's SCREAMING_SNAKE: a
+top-level code names the condition the *request* hit, while a field-level code
+names the *constraint* the value violated — and constraints are declared in the
+metadata's own snake_case, so `max_length` the code and `max_length: 50` the
+property are the same word on purpose.
+
+**Zod issue codes no longer reach the wire (wire-visible).** Routes that validate
+with Zod passed its vocabulary straight through, so `fields[]` spoke a different
+language depending on which route served it, and `too_small` was ambiguous between
+a short string, a small number and a short array. `zodIssuesToFields` now maps
+using Zod's `origin`/`format`:
+
+| Was | Now |
+|:---|:---|
+| `too_small` | `min_length` / `min_value` / `min_items` |
+| `too_big` | `max_length` / `max_value` / `max_items` |
+| `invalid_format` | `invalid_email` / `invalid_url` / `invalid_format` |
+| `invalid_value` | `invalid_option` |
+| `unrecognized_keys` | `unknown_field` |
+| `invalid_union`, `invalid_element`, `invalid_key` | `invalid_shape` |
+
+**A missing required property now reports `required`, not `invalid_type`.** Zod
+spells "absent" as a type mismatch against `undefined`, so passing it through made
+a form mark a *missing* input as the wrong *type*. The two are indistinguishable on
+the issue alone, so the mapper takes the parsed input as an optional argument and
+walks the issue path; a caller that cannot supply it keeps `invalid_type` rather
+than guessing.
+
+**`unknown_param` → `unknown_field`.** `ActionParamIssue.code` references the
+catalog instead of its own literal union; the `param` key beside it already says
+what was addressed.
+
+**Not changed:** `EnhancedApiErrorSchema.fieldErrors` keeps its name even though
+every producer emits `fields`. Retiring an authorable key needs a tombstone plus a
+migration (ADR-0104's contract guard), so it lands on its own — the property now
+carries a banner saying which name the wire uses.

.changeset/calendar-day-upper-bound.md

@@ -0,0 +1,39 @@
+---
+"@objectstack/core": minor
+"@objectstack/driver-sql": patch
+"@objectstack/driver-sqlite-wasm": patch
+"@objectstack/service-analytics": patch
+---
+
+fix(driver-sql,service-analytics): a bare-day upper bound covers the whole day on `Field.datetime` (#3777)
+
+A bare `YYYY-MM-DD` comparand anchors to midnight UTC. That is right for a
+lower bound and was silently wrong for an upper one: the dashboard date-range
+filter compiles `{ $gte: from, $lte: to }` with bare-day bounds, so on a
+`datetime` column every row created after 00:00 of the `to` day vanished from
+the result — no error, the chart renders, the numbers are just smaller. The
+default configuration hit it: the filter's default field is `created_at`
+(a system-injected `Field.datetime`) and 7 of the 13 presets end "today".
+
+The translation is operator-sensitive and half-open, applied at every
+comparison emitter:
+
+- `SqlDriver` (and `SqliteWasmDriver` by inheritance): `$lte`/`<=` with a
+  bare-day comparand on a `datetime` column compiles to `< next-day-midnight`
+  in the column's storage form; `$between [min, max]` with a bare-day max
+  decomposes to `>= min AND < next-day(max)`. Both the plain and the
+  legacy-repair (mixed-storage) column paths, both `where` spellings.
+- `NativeSQLStrategy`: `dateRange` windows and `lte` filters bind `< next-day`
+  instead of an inclusive `BETWEEN`/`<=` when the bound is a bare day.
+- The `/analytics/sql` rendering and the dataset preview evaluator apply the
+  same rule, so the echoed SQL and drafted numbers reproduce execution.
+
+`@objectstack/core` gains the shared primitive `nextUtcCalendarDay(value)`:
+the next calendar day of a valid bare `YYYY-MM-DD` (else `null` — instants,
+`Date`s and impossible days are never widened).
+
+Unchanged on purpose, per the semantics table on #3777: `date`/`time` columns
+(`<= day` is already whole-day-correct there), full-ISO/`Date` comparands
+(instant semantics), and `$gte`/`$gt`/`$lt` (midnight anchoring is correct for
+those). No authored metadata changes: a dashboard's existing
+`{ $gte, $lte }` window now simply includes its final day.

.changeset/console-96ee72e85439.md

@@ -0,0 +1,15 @@
+---
+"@objectstack/console": minor
+---
+
+Console (objectui) refreshed to `96ee72e85439`. Frontend changes in this range:
+
+- fix(console): render the redaction notice on the enveloped resolve body (objectstack#3983) (#2980)
+- feat(sdui): guard the public contract against silent drift (#2979)
+- fix(sdui): lazy public blocks reach a kind:'react' page scope; ReactRunner keeps its errors (#2976)
+- fix(list,data): bridge every spec view operator onto the filter AST (#2901) (#2974)
+- fix(errors): error-code branches survive the framework's ADR-0112 rename (objectstack#3841) (#2977)
+- fix(fields): a select no longer wipes itself when its value outruns its options (#2968) (#2969)
+- fix(approvals): decision outputs reach both decision surfaces (#2955) (#2961)
+
+objectui range: `e651c936870e...96ee72e85439`

.changeset/criteria-json-declaratively-required.md

@@ -0,0 +1,17 @@
+---
+"@objectstack/plugin-sharing": patch
+---
+
+feat(sharing): `sys_sharing_rule.criteria_json` is declaratively required (ADR-0113 P2)
+
+The field the ADR was written for: `required: true` as the write contract —
+insert must provide, update may not null out, legacy null rows rest, an admin
+can still `active: false` an over-broad legacy rule. Deliberately NO
+`storage.notNull`: deployed tenants' legacy nulls are the case the split
+exists for. The Setup form's required marker and client validation now derive
+from the declaration.
+
+Not breaking: a rule without criteria was already rejected by the #3929 hook
+guard; the guard narrows to the non-null match-all shapes `required` cannot
+express ('{}', vacuous $and/$or, unparsable JSON), `defineRule` keeps the API
+seam, and the evaluator stays fail-closed (ADR-0049).

.changeset/date-now-default-utc.md

@@ -0,0 +1,15 @@
+---
+"@objectstack/driver-sql": patch
+---
+
+fix(driver-sql): `Field.date` + `defaultValue: 'NOW()'` records the UTC calendar day on Postgres/MySQL (#4022)
+
+The bare `CURRENT_TIMESTAMP` default resolved the calendar day in the SERVER's
+timezone on Postgres — measured: a UTC-12 server recorded yesterday; an
+Asia/Shanghai server records tomorrow for every default after 16:00 UTC — and
+MySQL 8.0 rejects it on a DATE column outright (MariaDB is merely permissive,
+and the driver's UTC-pinned session masked the semantic half there).
+`nowColumnDefault` now emits a UTC expression default on both dialects, the
+#3994 D-C3 construction one type over. Defaults only govern newly created
+columns; existing columns keep their legacy default, per the standing D-B3
+policy.

.changeset/filter-no-silent-drop.md

@@ -0,0 +1,42 @@
+---
+"@objectstack/driver-memory": minor
+"@objectstack/driver-sql": patch
+---
+
+fix(driver-sql,driver-memory): an uncompilable filter now throws instead of matching everything (#3948)
+
+A filter the driver could not compile was **skipped**, not rejected. No predicate
+was emitted and the query returned every row — the caller asked to filter and
+silently received the unfiltered set.
+
+The reachable shape is a bare comparison triple. `['close_date','before','2024-01-01']`
+arrives at a driver only when `isFilterAST()` refused it — its operator is outside
+`VALID_AST_OPERATORS`, so `parseFilterAST()` never converted it and the raw array
+was assigned to `where`. `driver-sql`'s loop then saw three *strings*, matched
+neither `and` nor `or`, and `continue`d past all three. `driver-memory` was worse:
+it cast every string to a logic keyword, opening three empty groups and returning
+`{}` — a filter matching every record.
+
+This is reachable from ordinary authoring, not just malformed input: `before` and
+`after` are canonical `VIEW_FILTER_OPERATORS` members that `VALID_AST_OPERATORS`
+does not accept. Eight of the nineteen canonical view operators are in that
+position, including `equals`; the others were masked only because ObjectUI's
+adapter alias table happened to cover them.
+
+**Behaviour change.** Both drivers now throw on a filter element that is neither a
+logical keyword (`and`/`or`) nor a condition array, and `driver-memory` throws on
+an operator it cannot express rather than dropping the condition. The nested and
+`$`-object paths already threw on the same input, so this makes the three paths
+agree. A caller that was relying on the old silence was receiving wrong results;
+the error names the operator and the offending filter.
+
+**`driver-memory` also gains seven operators it silently ignored:** `not_in`,
+`is_null`, `is_not_null`, `isnull`, `isnotnull`, `is_empty`, `is_not_empty` — all
+members of `VALID_AST_OPERATORS`, all previously falling through to
+`default: return null`. `is_null` narrowed nothing instead of matching null rows.
+Alias sets and semantics mirror `driver-sql`'s `whereNull`/`whereNotNull` arms so
+the two backends accept one vocabulary.
+
+Migration: none for well-formed filters. If a query now throws, the filter was
+never being applied — fix the operator (the message names it), or lower it to an
+AST spelling. `before` → `<`, `after` → `>`, `'not in'` → `nin`.

.changeset/flow-node-expression-ledger.md

@@ -0,0 +1,48 @@
+---
+'@objectstack/spec': minor
+'@objectstack/service-automation': minor
+'@objectstack/lint': minor
+---
+
+Validate the expression slots a flow node's `configSchema` declares (#4027).
+
+A node type's designer `configSchema` and the keys its validators traverse were
+two unreconciled lists. Both the engine's `registerFlow` pass and the author-time
+`objectstack validate` pass hardcoded `config.condition` / `edge.condition` and
+assumed every other node string was a `{var}` template — so a declared expression
+property outside that hardcoded set was validated by nobody.
+
+That is how #3528 shipped. `screen.fields[].visibleWhen` has been on the `screen`
+descriptor since #3304, typed `xExpression: 'expression'` (bare CEL) and offered
+to authors in Studio, but no validator traversed it. An app authored the
+predicate in the *other* dialect — `'{createOpportunity} == true'` — and it passed
+`tsc`, `objectstack validate` and registration in silence. Because `required` *is*
+enforced, a field the author had made conditional rendered unconditionally and
+blocked Submit on an input the user was never shown: the run paused forever and no
+resume was ever issued.
+
+Now:
+
+- **`FLOW_NODE_EXPRESSION_PATHS`** (`@objectstack/spec`) is the declared ledger of
+  expression-bearing node config paths, each recording the dialect it takes.
+- **Both validators read it.** A malformed `visibleWhen` is a located, quoted
+  error at `registerFlow` *and* at `objectstack validate` — `node 'screen_1'
+  (screen) screen field visibleWhen at config.fields[1].visibleWhen`.
+- **A reconciliation ratchet** derives the expression properties from the live
+  descriptors and fails CI in both directions: a new `xExpression` property with
+  no ledger entry, or a stale entry no descriptor declares. It walks every
+  registered builtin, not just `screen`.
+
+Dialects are recorded rather than assumed because there are three, and two of them
+disagree about braces: bare CEL (`{…}` is the #1491 brace-trap), single-brace
+`{var}` flow interpolation (`{…}` is correct), and the ADR-0032 §3 double-brace
+text template. Only bare-CEL slots are checked — `loop.collection` and
+`map.collection` are recorded as `flow-template` and deliberately left alone,
+since no validator implements their dialect and checking them under either of the
+other two would reject every currently-valid flow.
+
+`ActionDescriptor.configSchema`'s TSDoc no longer claims `registerFlow()`
+validates `config` against it. It never did: `FlowNodeSchema.config` is
+`z.record(z.unknown())`, so types, `required`, `enum` and unknown keys are still
+unenforced. The doc now states exactly what is checked and what is designer-facing
+only, so nothing relies on a guard that does not exist.