Merge origin/main (c16040d) into claude/harden-occ-stale-token-order

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

Author: claude

.changeset/26702-console-connector-connections.md

@@ -0,0 +1,15 @@
+---
+'@object-ui/app-shell': patch
+'@object-ui/i18n': patch
+'@objectstack/service-automation': patch
+'@objectstack/platform-objects': patch
+---
+
+feat(console): Connector connections, a Setup page to connect, reconnect or disconnect each OAuth connector instance and see its status
+
+Clause-②: yes (widening: new Setup entry nav_connector_connections resolving automation:connector-connections; no existing key, route or shape changes)
+Metadata-protocol: none
+
+A connector instance declared with `auth: { type: 'oauth2', grant: 'authorization_code' }` needs an administrator to sign in to the vendor once for their organization. The Console now has a page for that (`automation:connector-connections`). `@objectstack/service-automation` contributes its Setup → Integrations entry, **Connector Connections**, gated on `manage_connector_connections`, the organization-scoped capability the connection door asks, so an organization administrator sees it; `@objectstack/platform-objects` carries the entry's label in its four Setup translation packs. The page lists every such instance with the organization's connection status as the server answers it (Not connected, Connected, or Reconnect required with the reason the server recorded), the granted scopes, who connected it and when, and when the access token renews. A `degraded` instance shows the server's reason in the same row as the connection that caused it.
+
+**Connect** and **Reconnect** open the vendor's sign-in in its own window, detached from the page, and send it to the authorization URL the server answered. The page re-reads the status until the connect lands, then closes the window and shows the new status. **Disconnect** removes the connection after a confirmation. No token, code or authorization URL is ever rendered.

.changeset/27904-cel-fault-code-and-position.md

@@ -0,0 +1,19 @@
+---
+'@objectstack/formula': patch
+---
+
+feat(formula): a CEL syntax refusal keeps the engine's own fault code and the source range it points at, so an editor can say what is wrong and where in its own words (#27904)
+
+Clause-②: no
+Metadata-protocol: none
+
+`validateExpression`'s catch-all CEL refusal, `invalid-cel`, now carries two optional params beside `role` and `detail`:
+
+- `celCode` — cel-js's own code for the fault, read off its error object: the parser's for a syntax fault (`unexpected_token` when an operand or the end is missing, `expected_token` when a closing `)` / `]` / `}` is missing, `unexpected_character`, `unterminated_string`, …) or the checker's for a type fault (`no_such_overload`, …).
+- `pos` — `{ start, end }`, the UTF-16 offsets into `source` that the engine points at (`end` exclusive). A missing `)` reads `start === end === source.length`.
+
+Both are absent when the engine reported none, and `pos` is absent when the engine read a source the platform rewrote first (the null-guard ternary lowering), since a range into that text would point at characters the author never wrote. A guessed `0` is never written.
+
+`EvalError.pos`, declared before and never filled, is now filled by `celEngine.compile` and `celEngine.evaluate` for a cel-js parse, check or evaluation fault that carries a range, on the same terms.
+
+The refusal's `message` is unchanged, byte for byte, and so are the codes and the params of every other refusal.

.changeset/28289-create-user-required-field-mark.md

@@ -0,0 +1,14 @@
+---
+'@object-ui/core': patch
+'@object-ui/app-shell': patch
+---
+
+fix(console): Create User left without an email marks the Email input as required, in the user's language
+
+Clause-②: yes (widening)
+Metadata-protocol: none
+
+Create User with neither an email nor a phone number answers `400 VALIDATION_FAILED` with one `required` entry per input that would satisfy it on `error.fields`. The Console showed only the server's English sentence above the dialog's buttons and marked no input.
+
+- **`@object-ui/core`**: `refusalFieldErrors`, the reader behind `ActionResult.fieldErrors`, now also reads a refusal's `error.fields` (the spec's `EnhancedApiErrorSchema.fields`), beside `error.details.fields` and the legacy inner `fields`. It is exported.
+- **`@object-ui/app-shell`**: a refused `type: 'api'` action carries the refusal's field entries as `fieldErrors`, on the list and record pages alike. The action parameter dialog marks each `required` entry on the param it names, with its own translated "required" sentence and the param's label. When every entry is marked, the refusal box is not drawn. A refusal that names no field, or names one the dialog does not draw, keeps the box with the server's text.

.changeset/28508-me-permissions-has-any-queue.md

@@ -0,0 +1,16 @@
+---
+'@objectstack/plugin-sharing': patch
+'@objectstack/plugin-hono-server': patch
+---
+
+feat(plugin-hono-server,plugin-sharing): `GET /auth/me/permissions` answers `hasAnyQueue`, whether the caller's organization has at least one ownership queue
+
+Clause-②: yes
+Metadata-protocol: none
+
+The console's list toolbar offers an "in a queue" toggle, and it needs to know, once per session, whether that toggle can ever return a row. A plain member cannot find out: `member_default` names no `sys_queue` entry, so `GET /data/sys_queue` answers 403. The server now answers the one question for them.
+
+- **The field.** Every authenticated `/auth/me/permissions` body carries `hasAnyQueue: boolean`. It is `true` when the caller's organization has at least one ownership queue: a declared queue the activation ledger has not switched off, or a `sys_queue` row of the organization. A row under a declared queue's name does not count, since that name resolves nowhere. Only the boolean is disclosed: no names and no counts. An anonymous caller still gets `{ "authenticated": false }` and nothing else.
+- **Where it is resolved.** `OwnershipQueueService.hasAnyQueue(organizationId)` in `@objectstack/plugin-sharing`, under system context, with the same registry-first read and activation-ledger filter `queuesOf` uses.
+- **When there is no answer.** No ownership-queue service registered, a service without the method, or a service that throws answers `false`. A throw is logged at `warn` and does not cost the caller the rest of the permissions body. The closed body the handler answers on a fault carries `false` too.
+- **Unchanged.** A member's read of `sys_queue` and `sys_queue_member` stays refused. No route is added.

.changeset/28555-dotted-path-preview-parity.md

@@ -0,0 +1,19 @@
+---
+'@objectstack/service-analytics': patch
+---
+
+fix(service-analytics)!: members read through a relationship path answer one refusal on the native, ObjectQL and draft-preview faces
+
+Clause-②: no (narrowing) — the draft preview (`queryDataset` with `previewDrafts: true`) now refuses `INVALID_FIELD` / 400 any member it would read through a relationship path (a dimension, time dimension, measure or filter member), which it served as one `null` group, `[]` or a total of `0`, because it joins nothing; a `timeDimensions` entry and a `runtimeFilter` member spelled through a relationship path the dataset's `include` does not declare are refused `INVALID_FIELD` / 400 on every face, where the native strategy answered `DATASET_INVALID` / 400 and the preview served; and a declared path to a column the related object lacks is refused `INVALID_FIELD` / 400 before SQL, where the native strategy answered `DATABASE_ERROR` / 500. Nothing is widened: no export, answer member, error code or status is added; every code was already on the wire.
+Metadata-protocol: none
+
+<!-- adr-0087: not-required (no-migration-prescription) No key of any schema is added, removed, renamed or re-shaped, and no export or type changes: a selection that reads through a relationship path is refused by the preview that cannot join it, a selection naming an undeclared path or a missing related column is refused on the faces that served it or failed on it, and the native face's refusal takes the member-level code the other member gates answer. There is nothing for a migration to rewrite and no tombstone. -->
+
+**BREAKING** accept-set narrowing on the `queryDataset` draft preview (`@objectstack/service-analytics`), and a code change on two native refusals.
+
+- **Before.** Measured on real SQLite over a dataset `include: ['account']`: the preview answered a backed `account.name` (or a declared dimension over it, or a declared measure over a related field) with one `null` group holding the whole total, a backed `runtimeFilter` member with `[]`, and a windowed backed time dimension with a total of `0`, while the live strategies served the real answer. `OBJECT.region` and `CUBE.region`, which both live strategies resolve to the declared `region`, also came back as one `null` group. A time dimension through an undeclared path was dropped by the preview and refused `DATASET_INVALID` by the native strategy when only windowed; a `runtimeFilter` member through an undeclared path got `DATASET_INVALID` (native), the cross-object filter refusal (ObjectQL) and `[]` or, under an `$or`, the other arm's rows (preview). `account.bogus` reached SQL on the native strategy as a 500.
+- **Now.** The service's join gate (the one `dimensions` already asked since the previous fix) also judges `timeDimensions` entries and `where` leaves, so an undeclared path is refused on every face with one message naming the member and the path. A second gate refuses a declared path to a column the related object does not have, naming the member, the column (`field`) and the object (`object`), on every face with one message. The preview then refuses any remaining relationship-path member with a message saying it joins no related object, and answers `OBJECT.region` / `CUBE.region` with the declared dimension's groups.
+- **Unchanged.** The live strategies serve a backed path as before (the ObjectQL strategy keeps its own cross-object refusals for a filter, a bucketed time dimension or a measure it cannot join). A path through an object the caller may not read keeps its 403. A hand-authored cube's configured allowlist still answers `DATASET_INVALID`, and so does every other reason that code is raised.
+- **Who sees it.** An author previewing a draft dataset that groups, filters or measures through a related object: the preview now says it cannot join instead of showing a number that changes after publish. A caller naming a related field the dataset does not include, or a related column that does not exist: one `INVALID_FIELD` / 400 on every face.
+
+**The remedy.** Publish the draft to query a related field through the live strategies, or preview without it; add the relationship to the dataset's `include`; check the related column's spelling.

.changeset/28560-field-patch-slot.md

@@ -0,0 +1,30 @@
+---
+'@objectstack/spec': minor
+---
+
+feat(spec): an object extension can carry a per-field display patch (`fieldPatches`), its keys derived from `BASE_FIELD_DISPLAY_WHITELIST`; not applied yet
+
+Clause-②: yes (widening)
+Metadata-protocol: added
+
+ADR-0146 D10's second rule: a customer changes a vendor field's display properties without taking the field over, so the field's type, values and rules stay the vendor's and the vendor's next version still applies. `ObjectExtensionSchema` gains one optional key for it:
+
+```ts
+objectExtensions: [{
+  extend: 'crm_account',
+  fieldPatches: {
+    industry: {
+      label: 'Sector',
+      inlineHelpText: 'The market the account sells into',
+      options: { tech: { label: 'Technology' } },
+    },
+  },
+}]
+```
+
+- **Keys.** A patch takes the field keys of `BASE_FIELD_DISPLAY_WHITELIST.field` (`label`, `description`, `inlineHelpText`, `placeholder`) plus `options`, a map from an option's stored `value` to that option's patch, which takes the keys of `BASE_FIELD_DISPLAY_WHITELIST.option` (`label`). Both sets are read from the constant: widening the whitelist widens the slot.
+- **Refused at parse, each with a prescription.** Every other field key (`type`, `required`, `unique`, `reference`, `defaultValue`, `expression`, …) and every other option key (`color`, `default`, …) is refused by name, naming the whitelist and stating that it stays the vendor's (ADR-0146 D6). An option's `value` is refused: the option is addressed by it, and it cannot be renamed. A field's option list under `options` is refused as membership. A key spelled as an extension field (`region__c`) is refused with "declare it in `fields`; it is your own field".
+- **Pure shape.** Whether the target object has the field or the option, and who may patch it, are the server's to judge.
+- **Not enforced yet.** The slot's description reads `[EXPERIMENTAL — not enforced]`. The engine's extension registration does not carry the key, so a patch is parsed and then dropped until the registry merge applies it (ADR-0146 rollout card N-23d). Nothing reads it before then.
+
+An extension without `fieldPatches` parses exactly as before.

.changeset/28562-studio-customize-read-only-base.md

@@ -0,0 +1,21 @@
+---
+'@object-ui/app-shell': patch
+'@object-ui/i18n': patch
+---
+
+feat(studio): customize a read-only package's view, dashboard or report into its `<base>.custom` pair, with an override badge and "Restore package original"
+
+Clause-②: no
+Metadata-protocol: none
+
+An installed package is read-only in Studio, so until now its views, dashboards and reports could only be looked at there. Studio now customizes them into the base's paired customization package (`<base>.custom`, ADR-0146 D2 and D3), as a declared override of the base's item.
+
+- **Customize.** The item header of a view, dashboard or report on a read-only base, and of an object leaf's list view, offers Customize. Pressing it only unlocks the item's editors. Nothing is written until an edit is saved.
+- **The first saved edit.** It calls `POST /api/v1/packages/:id/ensure-customization` once for that item, with no prompt and no body. It then saves the draft into the package the answer names (`201` when the door created the pair, `200` when it was there). The draft is the item as Studio holds it, without its `_` keys, with `overrides: { package, basedOn }`. `basedOn` is the base's `manifest.version` as the package list serves it. ⛔ The pair's id for a write is the door's answer, never a `.custom` spelled in the browser. The first save is pinned to "no draft there" (`If-None-Match: *`), so a draft someone else left in the pair is asked about, never overwritten. A base whose listed manifest states no version gets a disabled Customize that says so. Nothing is guessed.
+- **Walled callers.** Under a `group` or `isolated` posture, an admin who is not the platform operator sees Customize disabled, with the reason. This is read from the two facts the server publishes (`features.tenancyPosture`, `user.isPlatformAdmin`). A door that refuses anyway is shown as the server sent it.
+- **Pending and Publish.** On a read-only base with a pair, the pending count, the changes panel and Publish act on the pair's drafts. A refusal at the publish door is shown as it is sent. A read-only base with no pair keeps the read-only Publish, as before.
+- **Badge.** The header says the item overrides the base (for example "Overrides HotCRM", with the version in its title). It is read from the declaration the server serves: the pair's draft, else the layered read's overlay. It is never computed.
+- **Restore package original.** The item's ⋯ menu offers it on an item customized into the pair. After a confirmation, it deletes the pair's draft of the item, then its row (`DELETE /meta/:type/:name?package=<pair>`). The base's item reads back.
+- **The read-only mark** no longer links a view, dashboard or report to Setup's overlay page.
+- **Unchanged.** A writable package is edited in place, as before. A new view ("Add view") on a read-only base stays unavailable. The item tools (history, source) stay read-only on the base.
+- **New strings.** `@object-ui/i18n`'s studio namespace gains twelve `engine.studio.customize.*` keys in `en` and `zh`. The other languages fall back to `en`, as the whole namespace does.

.changeset/28567-new-similar-flow.md

@@ -0,0 +1,15 @@
+---
+'@object-ui/app-shell': patch
+'@object-ui/i18n': patch
+---
+
+feat(studio): "New similar" on a flow in the Automations pillar, opening the copy where the clone door landed it
+
+Clause-②: no
+Metadata-protocol: none
+
+An admin who wants a second flow like one a package ships, for another rule, gets it without changing the package's flow (ADR-0146 D4). The flow clone door lands the copy switched off in a writable package, by default the source's paired `<base>.custom`, so Studio can offer the gesture where the flow is designed.
+
+- **New similar in the flow's menu.** The open flow's ⋯ menu offers "New similar" on a read-only package's flow and on a writable package's flow. It asks for a new machine name and a label, both mandatory, and posts them to `POST /api/v1/automation/:name/clone`. On a read-only base the request names no package, so the door picks the pair; on a writable package it names the open package.
+- **The copy opens where the answer says.** The door's answer names the package the copy landed in. A copy in another package opens on that package's Automations pillar (`/studio/<package>/automations?surface=flow:<copy>`); a copy in the open package opens in place after the rail re-reads. Either way the server's sentence that the copy is switched off is shown as sent. An answer that names no package says so and opens nothing. Nothing records or draws what the copy was made from.
+- **Refusals and gates.** A refusal, a `409` for a taken name included, is the server's sentence, shown in the dialog, which stays open. A caller without `manage_metadata` sees the item disabled with the console's sentence for why. A read-only package's flow still offers no Delete, and the package-less scope draws no menu.

.changeset/28568-all-metadata-customization-marks.md

@@ -0,0 +1,18 @@
+---
+'@object-ui/app-shell': patch
+'@object-ui/i18n': patch
+---
+
+feat(studio): the All metadata area marks a base's customizations, filters to them and counts them
+
+Clause-②: no
+Metadata-protocol: none
+
+In Studio's All metadata area (ADR-0146 D3, "On top, one surface"), an installed base's lists now show its own items and the items of its paired `BASE.custom` package together. Every mark and number comes from the server's customization read, `GET /api/v1/packages/:id/customizations`. Nothing is computed from the documents: there is no diff and no `basedOn` verdict.
+
+- **Marks.** An item the read lists as an override is marked "Customized (BASE)". For a type identified by name and member, such as an email template's locale, only that member is marked. Any other item of the pair is marked "Added". The base's other items carry no mark.
+- **Filter.** Each list offers "Only customizations (n)" once the read has answered and the base has a customization.
+- **Counts.** Each directory tile shows how many items of its type the read lists as overrides. The object tile also counts the extension members (fields, validation rules, indexes). The directory header shows the base's total, the served overrides plus the served extensions, which is the landing's "customized" figure.
+- **Pending or failed read.** While the read is pending, or after it fails, the area draws no mark, no filter and no number, never a "0". A failure shows the server's sentence. A base with no pair is unchanged, and so is Setup, which makes no customization read.
+- **Across packages.** In `/studio/~all/metadata`, an item of a `BASE.custom` package is labelled "Customization of BASE".
+- **One mark component.** `CustomizationMark` (`views/studio-design/CustomizationMark.tsx`) draws these marks for the whole console, and the pillar rails will reuse it. `fetchPackageCustomizations` returns the read in full, and `fetchPackageCustomizationCounts` (the landing's reader) now uses it.