Merge remote-tracking branch 'origin/main' into claude/project-thread-ybjm3h

Author: claude

.changeset/25922-studio-i18n-editor-chrome.md

@@ -0,0 +1,10 @@
+---
+'@object-ui/i18n': patch
+---
+
+feat(i18n): the rest of the Studio inspectors and the package, form and editor strings move into the `studio` namespace
+
+Clause-②: no
+Metadata-protocol: none
+
+- **Third slice of the move ruled on objectstack#25922** (6431032267, Q2 = A; kept by 6431234244). The remaining `engine.inspector.*` keys and every `engine.packages.*`, `engine.form.*` and `engine.edit.*` key (551 in `en`, 560 in `zh`) now live in `@object-ui/i18n/namespaces/studio` instead of `@object-ui/app-shell`'s private table, text unchanged. The nine `engine.packages.form.help.*` rows stay `zh`-only: their English is the producer's own help text, read through `tOptional`. Studio reads the same strings; a Chinese viewer sees these labels in English for the moment the `zh` catalogue takes to load, as with the earlier slices. No export changes.

.changeset/26644-empty-projection-count-flag.md

@@ -0,0 +1,19 @@
+---
+'@objectstack/metadata-protocol': patch
+---
+
+fix(metadata-protocol)!: the Data API refuses an empty projection and a count flag that is neither true nor false, instead of reading them as absent (#26644)
+
+Clause-②: no (narrowing) — `GET /data/:object`, `POST /data/:object/query` (both transports: `RestServer` and the runtime dispatcher) and `GET /data/:object/:id` refuse a projection that names no field, and the list doors refuse a `count` / `$count` other than true or false, where they answered 200 before. Nothing is widened and no export changes.
+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: two query-parameter values the list normalizer read as the absent default are now refused 400 VALIDATION_ERROR naming the parameter. A caller drops the parameter or sends a well-formed value; there is nothing for a migration to rewrite and no tombstone. -->
+
+**BREAKING** accept-set narrowing at the shared list normalizer (`findData`) and the by-id read (`getData`), served by every Data API door that uses them.
+
+- **Before.** A blank or comma-only `$select` / `select` / `fields` (`?$select=`, `?$select=,`), and an empty array in a JSON body (`"fields": []`), became an empty projection, which every driver serves as no projection: all columns, under a 200. A `$count` / `count` other than `true` or `false` (`?$count=maybe`, `?$count=1`, a blank `?count=`) was left unlowered, so the `count=false` opt-out never matched and the count ran: a `total` was reported as if `$count=true` had been sent.
+- **Now.** Both are refused `400 VALIDATION_ERROR` before any read, with a message naming the parameter the caller wrote and the value (`Query parameter '$select' names no field; got ""`, `Query parameter '$count' must be true or false; got "maybe"`), as a blank `$top` already is. The accepted count values are the spec's `QueryTransportParamsSchema.count`: the boolean, or the strings `true` and `false`. `GET /data/:object/:id?select=` answers with the same code; that route's catch already reports every projection refusal (an unknown field included) as `404`, and the empty projection joins that answer.
+- **Unchanged.** An absent parameter keeps its default: every column, and the count runs. A named projection (`$select=a,b`, trailing commas and spaces trimmed as before), `$count=true`, `$count=false` and a JSON `null` answer exactly as before. `POST /data/:object/query` already refused a non-boolean `count` at its body schema (`400 VALIDATION_FAILED`), and still does.
+- **Who sees it.** A caller that builds `$select` from a list that can be empty, or sends a mistyped `$count`. It now learns that from a 400 instead of an answer that looked normal.
+
+**The remedy.** Leave the parameter out to read every column or to keep the count, or send a projection naming at least one field and a count flag of `true` or `false`.

.changeset/26670-seed-file-pool.md

@@ -0,0 +1,10 @@
+---
+'@objectstack/metadata-protocol': patch
+---
+
+fix(metadata-protocol): a seed that stores many `seedFile` values no longer starves sign-ins and other requests while it runs
+
+Clause-②: no
+Metadata-protocol: none
+
+A seed that stores many `seedFile(path)` values no longer starves the requests that arrive while it runs. On a synchronous driver (better-sqlite3, the wasm fallback) every step of a seed file's work — the `sys_file` row, the bytes, the claim that commits it — resolves as a microtask, so the claims the seed loader settled after each 200-row insert batch ran as one unbroken chain and a sign-in during a background boot seed waited seconds unread behind it. The connection pool was never the bottleneck; the event loop was. The loader now hands the event loop one turn after each row's files are stored and after each row's claim, and writes a dataset that carries seed files in insert batches of 20 rows instead of 200. Datasets without seed files are unchanged.

.changeset/26722-api-target-interpolation.md

@@ -0,0 +1,10 @@
+---
+'@object-ui/core': patch
+---
+
+fix(core): an `api` action's target is interpolated before a registered `api` handler sends it
+
+Clause-②: no
+Metadata-protocol: none
+
+An `api` action whose `target` carries `${ctx.recordId}` (or any other `${ctx.X}` / `${param.X}` token) went out on the wire with the literal placeholder (`/api/v1/data/gapdata_item/$%7Bctx.recordId%7D`) when a host had registered its own `api` handler, as the Console does, so a record-level PATCH or POST hit a record that does not exist. A `url` action with the same token already resolved it. `ActionRunner` now runs its one target substitution on an `api` target before handing the action to a registered `api` handler, with the same scopes and the same per-value `encodeURIComponent` a `url` target gets. The built-in executor already did this and is unchanged; a registered handler for any other type still receives its target as authored.

content/docs/permissions/system-context.mdx

@@ -529,13 +529,13 @@ and CI refuses one that differs from what the tree produces.
 | `packages/objectql/src/engine-referential-integrity.ts#assertReferencesResolve` | 1 | 23 |
 | `packages/objectql/src/engine-referential-integrity.ts#masterDetailHeadersCallerReads` | 1 | 29c |
 | `packages/objectql/src/engine-secret-internal-fields.ts#stripSearchCompanionFromRead` | 1 | 27 |
+| `packages/objectql/src/engine-validate.ts#validate` | 1 | 21b |
 | `packages/objectql/src/engine.ts#dependentCountIsDisclosable` | 1 | 28 |
 | `packages/objectql/src/engine.ts#inheritsElevation` | 1 | 1b |
 | `packages/objectql/src/engine.ts#insert` | 3 | 21, 22 |
 | `packages/objectql/src/engine.ts#isSystem` | 1 | 64 |
 | `packages/objectql/src/engine.ts#recordReferenceCheckElevation` | 1 | 29 |
 | `packages/objectql/src/engine.ts#update` | 4 | 19, 20 |
-| `packages/objectql/src/engine.ts#validate` | 1 | 21b |
 | `packages/observability/src/perf-timing.ts#isPerfDisclosurePrincipal` | 1 | 13 |
 | `packages/plugins/organizations/src/organizations-plugin.ts#start` | 1 | 62 |
 | `packages/plugins/plugin-approvals/src/approval-service.ts#comment` | 1 | 43 |

content/docs/upgrading.mdx

@@ -463,6 +463,7 @@ the protocol-18 step, which `os migrate meta --from 17` lists for your sources
 
 | Release | Where its upgrade notes live |
 | :--- | :--- |
+| v18.2.0 | [Upgrade checklist — 18.2.0](/docs/releases/v18/18-2#upgrade-checklist) |
 | v18.1.0 | [Upgrade checklist — 18.1.0](/docs/releases/v18/18-1#upgrade-checklist) |
 | v18.0.0 | [Upgrade checklist — 18.0.0](/docs/releases/v18/18-0#upgrade-checklist) · [Upgrading to 18.0](#upgrading-to-180) (the ownership ceremony) · [v18](/docs/releases/v18) |
 | v17.7.0 | [Upgrade checklist — 17.7.0](/docs/releases/v17/17-7#upgrade-checklist) |