Merge origin/main into claude/global-actions-unreachable-rw7hpk

Resolves the `/actions` catch-block conflict with #3937, which landed the
opposite decision to this branch's second half and asserted it in
`actions-validation-envelope.test.ts` so it could not drift silently.

#3937 is right about the case it addressed: a handler that RAN and rejected is
a business outcome, not a transport error, and belongs in the payload. That
reasoning does not extend to a request that never DISPATCHED — an unregistered
action has no outcome to report and is indistinguishable from a typo'd URL.
This route already answers the other pre-dispatch failures with a status (403
denied, 400 wrong action type, 503 unavailable), so the not-found exit joins
them as a 404 and everything below the dispatch line keeps #3937's envelope,
`code`/`fields` included.

Reverted from this branch to honour that: the 400 for an action-body throw, the
400 + FLOW_FAILED for a rejected flow, and the errorFromThrown 500 fallback.
The client-side catch in `actions.invoke` stays and is now load-bearing —
`client.fetch` throws on every non-2xx, so without it the routes that just
gained a status would start propagating exceptions into callers that only ever
checked `result.success`.

The wider 200-vs-4xx question is left open for #3913 rather than settled here.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011AvZj6cLX7APd7roh2eK4F

Author: claude

.changeset/action-body-execution-context.md

@@ -0,0 +1,41 @@
+---
+"@objectstack/runtime": patch
+---
+
+fix(runtime): action bodies execute under a real execution context — every owner-scoped write no longer dies FORBIDDEN
+
+An action body's `ctx.api` was never bound. The sandbox's `buildSandboxApi`
+walked its whole fallback chain — no `actionCtx.api`, and the raw `ObjectQL`
+engine has no `.object()` (that lives on `ScopedContext`, reachable only via
+`engine.createContext()`, which the action path never called) — and landed on a
+repo facade that proxied every call to the engine with **no `context`**.
+`ctx.engine` had the identical hole.
+
+Context-less is not "trusted", it is **identity-less**, and identity-less is
+strictly worse than either coherent posture: plugin-sharing's write gate
+short-circuits on `!context.userId` (no user to own the record) and its bypass
+needs `context.isSystem` (never set). So a `type: 'script'` action whose body
+called `ctx.api.object('crm_case').update(...)` failed with
+`FORBIDDEN: insufficient privileges to update crm_case` — **as the built-in
+admin** — while the `[action-audit]` line on the same request announced
+RLS-bypassing TRUSTED execution. Objects with a `public` sharing model, no
+owner field, or a bypass listing passed the gate early, so only *some* actions
+broke and the defect read as object-dependent flakiness.
+
+Both dispatch paths (REST `/actions/:object/:action` and MCP `run_action`) now
+bind `ctx.api` to `engine.createContext(...)` and thread the same envelope
+through `ctx.engine`, matching what hook bodies already get from the engine's
+`buildHookApi`. The envelope is the caller's `ExecutionContext` elevated with
+`isSystem: true` — the posture the action surface already documents and gates
+for at invoke time (the ADR-0066 D4 capability gate and the `ai.exposed` gate
+are what admit a body to trusted execution). The caller's fields are spread
+first, so a body's writes stay attributable (`userId` stamps
+`created_by`/`updated_by`), org-scoped (`tenantId` stamps the org column and
+drives driver-level tenant isolation), and joined to an open transaction —
+rather than the unattributable, org-less rows a bare `{ isSystem: true }` would
+write.
+
+No authoring change is required: `ctx.api.object(name)` inside a `body` now
+does what the docs always said it does. Bodies that worked before (public /
+owner-less objects) are unaffected apart from their writes now being correctly
+attributed and org-stamped.

.changeset/actions-global-key-and-failure-status.md

@@ -3,10 +3,7 @@
 "@objectstack/client": minor
 ---
 
-fix(actions): reach global actions at their real registration key, and stop serving handler failures as HTTP 200 (#3913)
-
-Two independent defects that compounded into "global actions are unreachable,
-and when one fails you are told it succeeded".
+fix(actions): reach global actions at their real registration key, and 404 an action that never dispatched (#3913)
 
 **1 — the registration key and the lookup key disagreed.** Both writers
 register an objectName-less action under the literal `'global'`: `AppPlugin`
@@ -29,36 +26,30 @@ single-segment path (`/actions//:action`) routes at `'global'` instead of
 400-ing. A handler registered directly under `'*'` still resolves; the doc
 comments that called `'global'` a "wildcard" are corrected at every site.
 
-**2 — every handler failure was wrapped as transport success.** Both the
-success and the failure exit called `deps.success(...)`, which always emits
-`{status: 200, body: {success: true, data}}`. So any failure — a denial, a
-missing action, a deliberate `throw` in an action body — went out as:
+**2 — "no such action" was reported as a success.** The not-found exit called
+`deps.success(...)`, which always emits `{status: 200, body: {success: true,
+data}}`, so a request naming an action that does not exist came back as:
 
 ```json
 {"success":true,"data":{"success":false,"error":"Action 'log_call' on object '*' not found"}}
 ```
 
 Every caller that did not hand-unwrap the INNER envelope read the outer
-`success: true` and reported a success that never happened. Failures now exit
-through the dispatcher's error path with a real status:
-
-| Failure | Status |
-|:---|:---|
-| No handler registered under any key | **404**, naming the routed object rather than whichever probe ran last |
-| Deliberate `throw` from an action body (`SandboxError`) | **400** with the business message — the mapping `@objectstack/rest`'s `mapDataError` has always used for the identical error |
-| A `flow` action whose flow ran and rejected | **400**, `code: FLOW_FAILED` |
-| Error carrying its own `.status` (e.g. a `FORBIDDEN`) | that status |
-| Record `ValidationError` | **400** with `fields[]` (#3918 parity) |
-| Anything else | **500** |
-
-The **success** envelope is unchanged (`{success: true, data: {success: true,
-data}}`), and `client.actions.invoke` / `invokeGlobal` still do **not** throw —
-they fold the new non-2xx shape back into the same `{ success, data?, error? }`
-result, with `error` as a plain string, and keep honouring the pre-#3913
-`200 + inner success:false` shape so a current SDK can still talk to an older
-server.
-
-**Migration:** anything reading `response.data.success` off a raw HTTP call
-should read the HTTP status (or the top-level `success`) instead — a failed
-action is no longer a 200. Callers going through `@objectstack/client` need no
-change.
+`success: true` and reported a success that never happened — including the
+shipped console, which showed a green toast (fixed on that side in
+objectui#2963). Nothing **dispatched** there, so it is a **404** now, joining
+the answers this route already gives a status: 403 denied, 400 wrong action
+type, 503 unavailable. The miss also names the **routed** object rather than
+whichever probe ran last (the old fallback said `on object '*'`, an object the
+caller never asked for).
+
+A handler that **ran and rejected** is unchanged: HTTP 200 with
+`data: {success: false, error, code?, fields?}`. That is a business outcome,
+not a transport error, and #3937 pins it. The line is "did a handler run" —
+below it the payload, above it the status.
+
+`client.actions.invoke` / `invokeGlobal` still do **not** throw. `client.fetch`
+throws on every non-2xx, so `invoke` now catches and folds a dispatch failure
+into the same `{ success, data?, error? }` result with `error` as a plain
+string — otherwise the routes that just gained a status would have started
+propagating exceptions into callers that only ever checked `result.success`.

.changeset/client-error-envelope-normalisation.md

@@ -0,0 +1,51 @@
+---
+"@objectstack/client": patch
+---
+
+fix(client): normalize both server error envelopes so `err.code` / `err.fields` mean one thing (#3918 follow-up)
+
+Two envelopes are in play and they disagree about where the semantic code and
+the per-field list live:
+
+```
+@objectstack/rest, flat:
+  { error, code: 'VALIDATION_FAILED', fields: [...] }
+
+runtime dispatcher, wrapped:
+  { success: false, error: { message, code: 400,
+      details: { code: 'VALIDATION_FAILED', fields: [...] } } }
+```
+
+`error.code` in the **wrapped** form is the HTTP status, not a semantic code.
+The client read it straight through, so `err.code` was the **number 400** where
+the flat envelope gave `'VALIDATION_FAILED'` — meaning the branch our own docs
+teach,
+
+```js
+if (err.code === 'VALIDATION_FAILED') err.fields.forEach(…)
+```
+
+never matched on a dispatcher-served surface, and the field list (put on the
+wire for those routes by #3918) was unreachable at `err.details.error.details.fields`.
+
+Now normalized at the throw site:
+
+- **`err.code` is always the semantic string.** It is read from the flat
+  `code`, else the wrapped `error.details.code`, else a *string* `error.code` —
+  a numeric value is never reported as a code. The HTTP status is on
+  `err.httpStatus`, where it always was.
+- **`err.fields` is the per-field list** whenever the server sent one, from
+  either envelope. It is left **unset** (not `[]`) when there is none, so
+  `if (err.fields)` is a safe test for "this failure is field-anchored".
+- **`err.details`** prefers a top-level `details` (unchanged), then the wrapped
+  envelope's own `details`, then the whole body. The flat envelope has no
+  top-level `details` and so keeps falling through to the whole body exactly as
+  before — only the wrapped shape changes, and only from "the entire response"
+  to the structured object it actually carries.
+
+**Behaviour change worth noting:** code that read `err.code` from a
+dispatcher-served route previously got a number and now gets a string (or
+`undefined` where the server sent no semantic code). Nothing in this repo did —
+`err.httpStatus` was always the correct source for the status, and remains
+untouched — but a consumer that branched on `err.code === 400` should move to
+`err.httpStatus === 400`.

.changeset/domain-error-passthrough.md

@@ -0,0 +1,40 @@
+---
+"@objectstack/runtime": patch
+---
+
+fix(runtime): route every domain `catch` through `errorFromThrown` so status and `fields[]` survive (#3918 follow-up)
+
+#3867 taught `dispatcher-plugin`'s `errorResponseBase` to read an error's
+`status` (not just `statusCode`), and #3918 taught
+`HttpDispatcher.errorFromThrown` the `VALIDATION_FAILED` shape. Both fixes were
+invisible to a whole tier of handlers underneath them: the domain modules each
+caught their own errors and called `deps.error(e.message, e.statusCode || 500)`
+directly, bypassing `errorFromThrown` entirely — 13 call sites, 9 of them in
+`/packages` alone.
+
+The consequence on `/packages`, `/meta/_drafts`, `/ui`, `/security` and the
+`/mcp` transport:
+
+- **A deliberate status was downgraded to 500.** Every protocol-layer domain
+  error in this codebase carries its HTTP status as `status`, not `statusCode`
+  (`OBJECT_NOT_FOUND`, `RECORD_NOT_FOUND`, `CLONE_DISABLED`, plugin-sharing's
+  `FORBIDDEN`, …) — the exact read #3867 fixed one tier up. So a 404 these
+  routes meant to return arrived as a 500, and the message was dragged through
+  the 5xx leak sanitiser on the way out.
+- **A `ValidationError` still lost its `fields[]`** and its 400, re-opening
+  #3918 on precisely the routes it was filed against.
+
+Every one of those catches now calls `deps.errorFromThrown(e, …)`, so both
+fixes finally reach the routes that need them. Deliberate per-route fallbacks
+are preserved rather than flattened to 500: the `/meta` save fallback keeps
+**501** (that branch is reached only when the protocol has no `saveMetaItem`,
+so "unsupported" is the honest default) and the `/meta` two-part lookup keeps
+**404** — but a validation failure on either now answers 400 with its fields
+instead of being swallowed by the fallback.
+
+`domains/keys.ts` is deliberately **not** converted: it discards the underlying
+error on purpose, because the message could echo row contents. Its literal
+`'Failed to create API key'` is the correct answer there and stays.
+
+No behaviour change for errors that already carried `statusCode` — that read is
+preserved, only widened.

.changeset/flow-action-record-id-seeding.md

@@ -0,0 +1,33 @@
+---
+"@objectstack/runtime": patch
+---
+
+fix(actions): seed a flow action's params with the row id, like the trigger route does (#3915 follow-up)
+
+#3915 gave the REST `/actions/:object/:action` route its flow dispatch and
+documented it as "equivalent to `POST /api/v1/automation/:target/trigger`,
+without having to know the flow name". A real run showed that claim did not
+hold: the params bag carried the subject record's fields — so `id` — but never
+`recordId`. The CRM's own `crm_convert_lead` action declares
+`recordIdParam: 'recordId'` and its flow reads `{recordId}`, so invoking it
+through the actions endpoint reached the automation engine and then died at its
+first node:
+
+```
+Flow 'crm_convert_lead_wizard' failed: Node 'get_lead' failed: get_record:
+refusing to run — 1 filter condition(s) resolved to nothing … `{recordId}` (at id)
+```
+
+while the identical run through `/automation/crm_convert_lead_wizard/trigger`
+paused normally on its first screen. Only a live invocation surfaced it — the
+unit tests mock `automation.execute`, so they pinned the call shape without
+noticing the bag was missing the key flows actually read.
+
+`dispatchFlowAction` now seeds the row id under the same keys
+`domains/automation.ts` seeds for the trigger route — `recordId` and the
+`<objectName>Id` camelCase alias — plus the action's own declared
+`recordIdParam` (sourced from `recordIdField`, default `id`) when it names a
+third key. Explicit action params still win over every seed, and the seeding
+applies to the MCP `run_action` path too, which shared the same gap. A declared
+`recordIdParam` that no dispatcher honoured was the `declared ≠ enforced` shape
+in miniature.

.changeset/migrate-occupancy-and-deferred-ddl.md

@@ -0,0 +1,37 @@
+---
+'@objectstack/driver-sql': minor
+'@objectstack/runtime': minor
+'@objectstack/cli': minor
+---
+
+`os migrate` no longer touches the database before you confirm, and refuses a
+SQLite database another process is using (#3917).
+
+**Nothing is written before the prompt.** `plan` called itself a dry run and
+`apply` gated on `[y/N]`, but both booted the full plugin set first — and boot
+schema-sync issued create-table/add-column DDL (plus the artifact's inline seed
+wrote rows) against the target database before either promise was kept.
+`SqlDriver` gains `setDeferredDdl` / `previewDeferredSchemaWork` /
+`flushDeferredSchemaDdl`: while armed, `initObjects` still registers every
+in-memory map drift detection depends on but records the physical work instead
+of performing it. Both commands boot with it armed, render the held-back work
+as a `New (additive)` section of the plan, and `apply` performs it only after
+confirmation. `os meta resync` / `os migrate files-to-references` keep the old
+behaviour — they need the tables to exist.
+
+**Occupancy check.** A live `os dev`/`os serve` holding the same SQLite file is
+the usual way a migration goes wrong: the migration is transactional and swaps
+tables inside the file, but the running server keeps prepared statements and a
+schema cookie the migration invalidates. `os migrate` now probes the target
+before booting — `PRAGMA locking_mode = EXCLUSIVE` + `BEGIN IMMEDIATE` under
+`busy_timeout = 0`, which reports `SQLITE_BUSY` when another connection is
+*attached*, not merely writing. (`wal_checkpoint(TRUNCATE)` only sees an active
+writer, and `-wal`/`-shm` presence cannot tell a live server from a crashed one;
+both are encoded as tests.) `apply` refuses with exit 1 — `error: database_busy`
+under `--json` — unless the new `--force` flag is passed; `plan` warns and
+continues, since it writes nothing either way. SQLite only: Postgres and MySQL
+take their own server-side locks.
+
+`@objectstack/runtime` also exports `resolveStandaloneDatabase()`, so a caller
+can resolve the database target with the same precedence the boot uses without
+building the stack, and `createStandaloneStack` accepts `skipSeedData`.

.changeset/report-ordering-and-time-axis-default.md

@@ -0,0 +1,48 @@
+---
+"@objectstack/spec": patch
+"@objectstack/service-analytics": patch
+---
+
+feat(analytics): order the time axis by default, and give reports a sort declaration (#3916)
+
+A matrix report with a date dimension across rendered its columns in arbitrary
+order — `2026-07-01, 2026-07-05, …, 2026-07-02`. Declaring `dateGranularity` on
+the dataset dimension made the bucket keys *sortable* (`2026-07`, `2026-Q3`)
+without making anything *sort* them, and the report author had no way to ask:
+`DatasetSelection.order` existed on the wire, but `ReportSchema` had no ordering
+field at all (dashboard widgets had their own `options.sortBy` channel; reports
+did not). Nothing in the chain supplied an order either — `resolveOrdering`
+returned `undefined` unless the selection carried one explicitly, the ObjectQL
+aggregate path has no ordering grammar so its buckets came back in Map-insertion
+order, and the pivot builds its column headers in row-arrival order.
+
+- **A selected time dimension is now chronological by default.** When a
+  selection states no `order` (and no `limit`, whose own fallback already
+  ordered by every dimension), each selected dimension the cube types as `time`
+  defaults to ASCENDING, in selection order. Bucket keys are minted sort-stable
+  precisely so this works — `2026-07` sorts after `2026-06`, `2026-Q3` after
+  `2026-Q1`. This lands on both strategy paths: a real `ORDER BY` where native
+  SQL serves the query, and the executor's post-pass where a date-bucketed query
+  is handed to the ObjectQL path. Null / empty buckets stay last, as everywhere
+  else. Deliberately narrow: only time dimensions get a default, so grids with
+  nothing wrong with them are not reordered.
+- **Reports can declare an ordering.** `ReportSchema.order` (and
+  `blocks[].order` for a `joined` report) is a list of `{ by, direction }` sort
+  keys, most significant first — an array, not a `Record`, because key order is
+  the contract and JSON object key order should not have to be. `by` must name a
+  dimension the report groups by (`rows` / `columns`) or a measure it displays
+  (`values`); anything else fails at authoring time rather than becoming an
+  ordering that silently does nothing. Duplicate keys are rejected. A `joined`
+  report orders per block — declaring `order` on the container is an error.
+  `reportSelectionOrder()` lowers the list into the `DatasetSelection.order` a
+  renderer posts, and returns `undefined` for an empty list so the runtime's own
+  defaults still apply.
+
+An explicit `order` still wins outright — the chronological default is a
+default, not a policy, so "newest month first" is one declaration away.
+
+`report.order` ships as `planned` + `authorWarn` in the liveness ledger: the
+framework half is complete and live (schema, lowering helper, executor), but
+objectui's `DatasetReportRenderer` does not yet carry `report.order` into the
+selection it posts. The default time-axis ordering needs no renderer change and
+is live now.