@@ -12,7 +12,7 @@ Clause-②: no (narrowing)
 
 Setup's File Storage page has always rendered a "Limits" group — "Max upload size (MB)", "Presigned URL TTL (seconds)" and "Upload session TTL (seconds)" — and saved it, but nothing read it. `StorageServicePlugin` now reads the group on every settings pass and its upload doors honour it, on the plugin's own mount and on a host's `mountStorageRoutes` mount alike.
 
-**What stops being accepted.** Where the plugin is bound to the `storage` settings namespace (its default, `bindToSettings: true`, with a settings service present), an upload larger than the resolved `max_upload_mb` is refused with `413` and the standard code `VALIDATION_ERROR`, in the usual error envelope, with a message naming the limit and the setting. Nothing is stored: no `sys_file` or `sys_upload_session` row is written and no byte reaches the adapter. The doors that judge it:
+**What stops being accepted.** Where the plugin is bound to the `storage` settings namespace (its default, `bindToSettings: true`, with a settings service present), an upload larger than the resolved `max_upload_mb` is refused with `413` and the registered code `PAYLOAD_TOO_LARGE`, in the usual error envelope, with a message naming the limit and the setting. Nothing is stored: no `sys_file` or `sys_upload_session` row is written and no byte reaches the adapter. The doors that judge it:
 
 - `POST /storage/upload/presigned` — the declared `size`;
 - `POST /storage/upload/chunked` — the declared `totalSize`;
 
@@ -0,0 +1,11 @@
+---
+'@objectstack/spec': minor
+---
+
+feat(spec): the error-code ledger lists `PAYLOAD_TOO_LARGE` under `@objectstack/service-storage`
+
+Clause-②: yes (widening: a new owner provenance row in the published error-code ledger)
+
+`ERROR_CODE_LEDGER['@objectstack/service-storage']` now lists `PAYLOAD_TOO_LARGE` (`413`), the code `@objectstack/rest` already registers for its import row ceilings. The storage upload doors answer it for an upload over the File Storage settings' `max_upload_mb`: the presigned upload's declared `size`, the chunked upload's declared `totalSize`, the local raw PUT body and each chunk's running total.
+
+No code is added. `ErrorCode`, `RegisteredErrorCode` and `REGISTERED_ERROR_CODES` are unchanged, so `ApiErrorSchema` accepts exactly what it accepted before. What widens is the per-package list a reader consults to learn which packages answer a code: a code emitted by several packages is listed under each of them.
@@ -0,0 +1,11 @@
+---
+'@objectstack/service-automation': patch
+---
+
+fix(service-automation): a `get_record` whose `fields` leave out `id` answers the row's id as its `id` output on the SQL drivers
+
+Clause-②: no
+
+- **What was wrong.** On its single-row branch (no `limit` above 1) a `get_record` node answers `output: { record, id, object }`, and a later node reads that `id` as `{read.id}` (for a node whose id is `read`). The node handed the author's `fields` to the engine unchanged, and the SQL drivers return exactly the columns a projection names. So a `get_record` with `fields: ['title']` read a row with no `id` column, and `{read.id}` was empty with no error. A later `update_record` filtering on it was refused for a filter condition that resolved to nothing, and any other reference read nothing.
+- **What it does now.** That branch names `id` in the projection it hands the engine, so `{read.id}` is the row's id whatever `fields` names, on every driver. The record the node serves, and binds to its `outputVariable`, carries that `id` beside the columns the author named, so the variable's `id` reads the same value. The stored-metadata tables (`sys_metadata`, `sys_metadata_history`) are read the same way: the served row is the named columns plus `id`.
+- **Unchanged.** A `get_record` with no `fields`, or an empty list, still reads the whole row. A projection that already names `id` is handed over as written. The multi-row branch (`limit` above 1) answers `records` only and is untouched.
@@ -0,0 +1,23 @@
+---
+'@objectstack/service-automation': minor
+'@objectstack/plugin-security': patch
+'@objectstack/runtime': patch
+'@objectstack/service-analytics': patch
+'@objectstack/platform-objects': patch
+---
+
+fix(service-automation)!: retire the `RunProvenanceContext` type; `RunDataContext` names only what `resolveRunDataContext` returns
+
+Clause-②: no (narrowing)
+
+<!-- adr-0087: not-required (runtime-interface-only packages/services/service-automation/src/runtime-identity.ts#RunDataContext) Two TypeScript-only declarations in one runtime file move, and neither is metadata: `RunDataContext` loses its `RunProvenanceContext` arm, and the `RunProvenanceContext` interface declared beside it in the same file is removed together with its type export. No spec key, authorable spelling, Zod schema or stored shape moves, and no stored row is read or rewritten, so `objectstack migrate meta` has nothing to rewrite. The channel that reaches an affected consumer is the compiler, at the consumer's own import. -->
+
+**BREAKING** for TypeScript code that imports from `@objectstack/service-automation`: one type export is removed and one type narrows. It ships as `minor` under the launch-window convention for breaking changes. No runtime behaviour changes in any package.
+
+**What is removed.** The `RunProvenanceContext` type export, the `{ flowRunId }`-only "provenance" envelope, and its arm of `RunDataContext`. No code in this repository builds or reads one. Since ADR-0096 D5, the data engine's security middleware refuses a context that carries no principal and is not a system context (`403 PERMISSION_DENIED`, for every verb). So the type described a context the engine refuses, while its docstring said such a context was "indistinguishable from passing no context at all" and was let through.
+
+**What `RunDataContext` is now.** Exactly what `resolveRunDataContext` returns: `isSystem: true` for a `runAs: 'system'` run, and the triggering user's principal for a `runAs: 'user'` run. A run that resolves no principal is refused before any data operation (`AUTOMATION_UNSCOPED_RUN_DATA_ACCESS`), as before.
+
+**If your code named the type.** There is no replacement, because the context it described is refused. A custom data node builds its context with `resolveRunDataContext(context)`, typed `RunDataContext`.
+
+**`@objectstack/plugin-security`, `@objectstack/runtime`, `@objectstack/service-analytics`, `@objectstack/platform-objects`:** comment and docstring text only. Shipped comments that said the security middleware hands through, skips or falls open for a context with no principal now say that it used to, and that ADR-0096 D5 refuses such a context. Nothing these packages do changes.
@@ -4,7 +4,7 @@ navTitle: Error Code Catalog
 description: Complete reference for all ObjectStack error codes with causes, fixes, and retry strategies
 ---
 
-ObjectStack uses a structured error system with **9 error categories** and **51 error codes reachable on the wire**. Every error includes a machine-readable code, HTTP status mapping, and retry guidance.
+ObjectStack uses a structured error system with **9 error categories** and **52 error codes reachable on the wire**. Every error includes a machine-readable code, HTTP status mapping, and retry guidance.
 
 This catalog documents the **wire face** — the codes a client can actually receive. That is not quite the
 `StandardErrorCode` enum: the enum also carries in-process spellings the REST door translates at the
@@ -62,16 +62,10 @@ entry's cross-reference sentence so the in-process one stays findable.
 **Fix:** Check the `fields` array for specific field-level issues.  
 **Retry:** `no_retry`
 
-<Callout type="warn">
-**`VALIDATION_ERROR` is `400` with one exception: the storage upload doors answer `413` for
-an upload over the File Storage settings' `max_upload_mb`.**
-
-The presigned-upload door (the declared `size`), the chunked-upload start (the declared
-`totalSize`), the local adapter's raw upload (the body) and the chunk door (the bytes the
-upload already holds plus the chunk) refuse it before anything is stored. The message names
-the size, the limit and the setting. Raise the setting or send a smaller file; resending the
-same upload cannot succeed. The protocol page carries the same exception:
-[`VALIDATION_ERROR`](/docs/protocol/kernel/error-handling#validation_error).
+<Callout type="info">
+**A request too large for its door is not this code.** An upload over the File Storage
+settings' `max_upload_mb`, and an import over its route's row ceiling, answer `413`
+[`PAYLOAD_TOO_LARGE`](#payload_too_large).
 </Callout>
 
 ```json
@@ -510,6 +504,31 @@ an environment scope (no `X-Environment-Id` header and no hostname mapping).
 
 ---
 
+## Size Limit Errors (413)
+
+`PAYLOAD_TOO_LARGE` is an [error-code ledger](/docs/references/api/error-code-ledger) code, listed
+under each package that answers it — `@objectstack/rest` and `@objectstack/service-storage` — not a
+standard-catalog member, so its status is published here rather than inherited from a category.
+The standard catalog names no `413` member.
+
+### `PAYLOAD_TOO_LARGE`
+
+**HTTP Status:** 413  
+**Cause:** The request carries more than its door accepts:
+
+- **An upload over the File Storage settings' `max_upload_mb`.** The presigned-upload door (the
+  declared `size`), the chunked-upload start (the declared `totalSize`), the local adapter's raw
+  upload (the body) and the chunk door (the bytes the upload already holds plus the chunk) refuse
+  it before anything is stored. The message names the size, the limit and the setting.
+- **An import over its route's row ceiling** — 5,000 rows on the synchronous route, 50,000 on the
+  job route ([size limits](/docs/data-modeling/import-mappings#size-limits)).
+
+**Fix:** Raise the setting or send a smaller file; split the import across requests. Resending
+the same request cannot succeed.  
+**Retry:** `no_retry`
+
+---
+
 ## Rate Limit Errors (429)
 
 ### `RATE_LIMIT_EXCEEDED`
@@ -917,7 +936,7 @@ async function handleApiCall() {
 | 403 | `authorization` | `PERMISSION_DENIED`, `FIELD_NOT_ACCESSIBLE`, `LICENSE_REQUIRED` |
 | 404 | `not_found` | `RECORD_NOT_FOUND`, `OBJECT_NOT_FOUND`, `ENDPOINT_NOT_FOUND` |
 | 409 | `conflict` | `CONCURRENT_MODIFICATION`, `UNIQUE_VIOLATION`, `DELETE_RESTRICTED` |
-| 413 | `validation` | `VALIDATION_ERROR` on an upload over the storage settings' `max_upload_mb` (see [above](#validation_error)) — this row is an exception to the 400 row, not a second home for the code |
+| 413 | `validation` | `PAYLOAD_TOO_LARGE` — an upload over the storage settings' `max_upload_mb`, or an import over its row ceiling (see [above](#payload_too_large)) |
 | 422 | `validation` | `MISSING_REQUIRED_FIELD` on an absent `controlled_by_parent` master reference (see [above](#missing_required_field)) — this row is an exception to the 400 row, not a second home for the code |
 | 429 | `rate_limit` | `RATE_LIMIT_EXCEEDED`, `QUOTA_EXCEEDED` |
 | 500 | `server` | `INTERNAL_ERROR`, `DATABASE_ERROR` |
 
@@ -214,7 +214,7 @@ ObjectStack uses standard HTTP status codes:
 | **403** | Forbidden | Authenticated but insufficient permissions |
 | **404** | Not Found | Resource doesn't exist |
 | **409** | Conflict | Resource already exists or version mismatch |
-| **413** | Content Too Large | An upload over the storage settings' `max_upload_mb` — answered as [`VALIDATION_ERROR`](#validation_error), its one exception to 400 |
+| **413** | Content Too Large | An upload over the storage settings' `max_upload_mb`, or an import over its row ceiling — answered as [`PAYLOAD_TOO_LARGE`](/docs/api/error-catalog#payload_too_large) |
 | **422** | Unprocessable Entity | Semantic validation failed (e.g. metadata spec validation); also an absent `controlled_by_parent` master reference — see [`MISSING_REQUIRED_FIELD`](#missing_required_field) |
 | **429** | Too Many Requests | Rate limit exceeded |
 | **500** | Internal Server Error | Server-side error |
@@ -402,7 +402,7 @@ if (body.code === 'VALIDATION_FAILED') {
 ```
 
 #### `VALIDATION_ERROR`
-**HTTP Status:** 400 — with one documented exception, which answers **413** (see below)  
+**HTTP Status:** 400  
 **Meaning:** The request is malformed — the generic "you sent something wrong" code  
 **Envelope:** **both**, and one emitter writes neither (see the warning below)
 
@@ -418,12 +418,10 @@ Where it comes from:
   specific.
 - **Query-parameter refusals.** `refuseUnknownQueryParams` and `refuseRepeatedQueryParams`
   answer 400 `VALIDATION_ERROR` for an unrecognised or repeated query parameter.
-- **Upload size refusals — the one 413.** The storage upload doors answer **413**
-  `VALIDATION_ERROR` for an upload over the File Storage settings' `max_upload_mb`: the
-  presigned-upload door (the declared `size`), the chunked-upload start (the declared
-  `totalSize`), the local adapter's raw upload (the body) and the chunk door (the bytes the
-  upload already holds plus the chunk), each before anything is stored. The message names the
-  size, the limit and the setting.
+
+Not from a request too large for its door: an upload over the File Storage settings'
+`max_upload_mb` answers **413** with the registered code
+[`PAYLOAD_TOO_LARGE`](/docs/api/error-catalog#payload_too_large), not this one.
 
 **Nested** (the dispatcher door, status-derived — `GET /api/v1/packages/:id?version=1&version=2`):
 ```json
 
@@ -1581,9 +1581,11 @@ export const InboundTaskWebhookFlow = defineFlow({
   type: 'api',
   status: 'active',
   // An inbound webhook has no authenticated user, so the create must run as the
-  // system principal (#1888 runAs is now enforced). Without this it relies on the
-  // "no identity → security-skipped" fall-through, which breaks the moment the
-  // target object carries row-level security.
+  // system principal (#1888 runAs is now enforced). Without this the run is
+  // user-less under the default `runAs:'user'`, so its create is refused
+  // (`AUTOMATION_UNSCOPED_RUN_DATA_ACCESS`); the "no identity → security-skipped"
+  // fall-through it once relied on is gone (ADR-0096 D5 refuses a principal-less
+  // context in the security middleware too).
   runAs: 'system',
   nodes: [
     {
 
@@ -167,10 +167,18 @@ describe('buildAccessMatrix CRUD columns — the spec fold, asked (#18785)', ()
       permissions: entries.map((e, i) => ({ name: `ps_${String(i).padStart(4, '0')}`, objects: { o: e } })),
     });
     expect(m.entries.length).toBe(entries.length);
+    // Index the rows by permission set ONCE. A `find` per entry is quadratic —
+    // 3^8 entries make ~21.5M callbacks, each rebuilding the name — which ran
+    // this case past vitest's 5 s default on a loaded CI shard. First match
+    // wins, so every lookup returns the row `find` returned.
+    const rowByPermissionSet = new Map<string, (typeof m.entries)[number]>();
+    for (const e of m.entries) {
+      if (!rowByPermissionSet.has(e.permissionSet)) rowByPermissionSet.set(e.permissionSet, e);
+    }
     const mismatches: string[] = [];
     let cells = 0;
     for (let i = 0; i < entries.length; i++) {
-      const row = m.entries.find((e) => e.permissionSet === `ps_${String(i).padStart(4, '0')}`)!;
+      const row = rowByPermissionSet.get(`ps_${String(i).padStart(4, '0')}`)!;
       for (const verb of ['create', 'read', 'edit', 'delete'] as const) {
         cells++;
         if (row[verb] !== referenceFold(entries[i], verb)) {
 
@@ -4,9 +4,10 @@
  * [#21911, ADR-0096] The metadata protocol's platform-store calls carry the
  * EXPLICIT system opt-in, never a principal-less context.
  *
- * plugin-security hands an engine operation whose context carries no user, no
- * position, no permission set and no `isSystem` straight to `next()` (the
- * ADR-0096 E1 hand-off). The protocol's own reads and writes of the
+ * plugin-security used to hand an engine operation whose context carries no
+ * user, no position, no permission set and no `isSystem` straight to `next()`
+ * (the ADR-0096 E1 hand-off); since ADR-0096 D5 it refuses one. The protocol's
+ * own reads and writes of the
  * `sys_metadata` family reached the engine exactly that way — a `{ where }`
  * with no `context`, or a repository transaction context with only its
  * handle — so they worked only because the hand-off let them through. They
 
@@ -11230,11 +11230,13 @@ export class ObjectStackProtocolImplementation implements
         // were eliminated by measurement, not by reading:
         //  - the driver's tenant wall never engages — `buildDriverOptions`
         //    sets `DriverOptions.tenantId` only from `execCtx.tenantId`
-        //    (`objectql/engine.ts`), and this read passes no context;
-        //  - plugin-security's Layer 0 never engages — the middleware takes
-        //    its principal-less `return next()` thousands of lines before the
-        //    `objectFields.has('organization_id')` gate that would have
-        //    carried it;
+        //    (`objectql/engine.ts`), and this read's context carries no
+        //    `tenantId` (only the system opt-in below);
+        //  - plugin-security's Layer 0 never engages — the middleware
+        //    short-circuits on that `isSystem` opt-in (it used to take its
+        //    principal-less `return next()`, refused since ADR-0096 D5)
+        //    thousands of lines before the `objectFields.has('organization_id')`
+        //    gate that would have carried it;
         //  - no posture would save it anyway: `computeTenantLayer0Filter`
         //    yields `null` under `single` and the deny sentinel under
         //    `isolated` with no tenantId.