docs(changelog): correct the falsified batch-cap claim in the published 17.0.0 and 17.0.0-rc.1 entries

packages/rest/CHANGELOG.md

@@ -5262,9 +5262,9 @@ export`) are DERIVED from the primitives, never declared standalone. (This
   request, where before it was one statement that mostly failed anyway.
 
   **The cap moved to the routes, and the schemas gave it up.** Batch size is
-  deployment policy — `RestServerConfig.batch.maxBatchSize`, 1..1000, default 200
+  embedder policy — `RestServerConfig.batch.maxBatchSize`, 1..1000, default 200
   — so a hardcoded bound in the spec could only ever be a second, wrong answer
-  (a deployment raising the limit to 500 would still have been refused at 200).
+  (a host raising the limit to 500 would still have been refused at 200).
   All five bulk routes now call one `enforceBatchSize` helper with the configured
   value and answer with one envelope:
 
@@ -5300,9 +5300,10 @@ export`) are DERIVED from the primitives, never declared standalone. (This
   **Behaviour changes.**
 
   - A bulk request over the configured cap is `400 BATCH_TOO_LARGE` instead of
-    being executed. Deployments that were quietly relying on unbounded batches
-    should raise `batch.maxBatchSize` (up to 1000) rather than discover the cap in
-    production.
+    being executed. A deployment that was quietly relying on unbounded batches
+    meets the cap at whatever value the host embedding the server passed for
+    `batch.maxBatchSize` — 200 unless it passed one, which no shipped boot path
+    does.
   - `.min(1)` is gone with `.max(200)`: an empty batch is a no-op returning
     `total: 0`, which is what these routes already did, rather than a validation
     error the schema claimed but nothing raised.
@@ -5312,6 +5313,8 @@ export`) are DERIVED from the primitives, never declared standalone. (This
     type was looser.
   - New export: `UpdateManyRecordSchema` / `UpdateManyRecord`.
 
+  *Erratum, 2026-09-18 — this entry called the batch cap "deployment policy" and told operators that deployments relying on unbounded batches "should raise `batch.maxBatchSize` (up to 1000)". The cap is embedder policy: `RestServerConfig.batch.maxBatchSize` is the argument a host passes when it constructs the server, and neither shipped boot path passes it — `os serve` forwards exactly two keys out of the stack config's `api:` block (`api.enableProjectScoping`, `api.projectResolution`) and the dev plugin calls `createRestApiPlugin()` with no config at all — so a CLI-started deployment always gets the 200 default and no flag, config file or CLI option moves it. Two passages above are corrected in place; the 1..1000 range, the 200 default and the enforcement this release shipped are unchanged. (Corrected after publication, #18740.)*
+
 - fccec22: fix(rest): bulk writes bind to the object in the path, not the one in the body (#3933)
 
   `POST /data/:object/updateMany` spread the request body over the value it had
@@ -15189,9 +15192,9 @@ IEmailService`, `ExternalDatasourceService implements IExternalDatasourceService
   request, where before it was one statement that mostly failed anyway.
 
   **The cap moved to the routes, and the schemas gave it up.** Batch size is
-  deployment policy — `RestServerConfig.batch.maxBatchSize`, 1..1000, default 200
+  embedder policy — `RestServerConfig.batch.maxBatchSize`, 1..1000, default 200
   — so a hardcoded bound in the spec could only ever be a second, wrong answer
-  (a deployment raising the limit to 500 would still have been refused at 200).
+  (a host raising the limit to 500 would still have been refused at 200).
   All five bulk routes now call one `enforceBatchSize` helper with the configured
   value and answer with one envelope:
 
@@ -15227,9 +15230,10 @@ IEmailService`, `ExternalDatasourceService implements IExternalDatasourceService
   **Behaviour changes.**
 
   - A bulk request over the configured cap is `400 BATCH_TOO_LARGE` instead of
-    being executed. Deployments that were quietly relying on unbounded batches
-    should raise `batch.maxBatchSize` (up to 1000) rather than discover the cap in
-    production.
+    being executed. A deployment that was quietly relying on unbounded batches
+    meets the cap at whatever value the host embedding the server passed for
+    `batch.maxBatchSize` — 200 unless it passed one, which no shipped boot path
+    does.
   - `.min(1)` is gone with `.max(200)`: an empty batch is a no-op returning
     `total: 0`, which is what these routes already did, rather than a validation
     error the schema claimed but nothing raised.
@@ -15239,6 +15243,8 @@ IEmailService`, `ExternalDatasourceService implements IExternalDatasourceService
     type was looser.
   - New export: `UpdateManyRecordSchema` / `UpdateManyRecord`.
 
+  *Erratum, 2026-09-18 — this entry called the batch cap "deployment policy" and told operators that deployments relying on unbounded batches "should raise `batch.maxBatchSize` (up to 1000)". The cap is embedder policy: `RestServerConfig.batch.maxBatchSize` is the argument a host passes when it constructs the server, and neither shipped boot path passes it — `os serve` forwards exactly two keys out of the stack config's `api:` block (`api.enableProjectScoping`, `api.projectResolution`) and the dev plugin calls `createRestApiPlugin()` with no config at all — so a CLI-started deployment always gets the 200 default and no flag, config file or CLI option moves it. Two passages above are corrected in place; the 1..1000 range, the 200 default and the enforcement this release shipped are unchanged. (Corrected after publication, #18740.)*
+
 - fccec22: fix(rest): bulk writes bind to the object in the path, not the one in the body (#3933)
 
   `POST /data/:object/updateMany` spread the request body over the value it had

packages/spec/CHANGELOG.md

@@ -27471,9 +27471,9 @@ object:'task', function:'count', filter:{ status:'completed' } } }` lost that
   request, where before it was one statement that mostly failed anyway.
 
   **The cap moved to the routes, and the schemas gave it up.** Batch size is
-  deployment policy — `RestServerConfig.batch.maxBatchSize`, 1..1000, default 200
+  embedder policy — `RestServerConfig.batch.maxBatchSize`, 1..1000, default 200
   — so a hardcoded bound in the spec could only ever be a second, wrong answer
-  (a deployment raising the limit to 500 would still have been refused at 200).
+  (a host raising the limit to 500 would still have been refused at 200).
   All five bulk routes now call one `enforceBatchSize` helper with the configured
   value and answer with one envelope:
 
@@ -27509,9 +27509,10 @@ object:'task', function:'count', filter:{ status:'completed' } } }` lost that
   **Behaviour changes.**
 
   - A bulk request over the configured cap is `400 BATCH_TOO_LARGE` instead of
-    being executed. Deployments that were quietly relying on unbounded batches
-    should raise `batch.maxBatchSize` (up to 1000) rather than discover the cap in
-    production.
+    being executed. A deployment that was quietly relying on unbounded batches
+    meets the cap at whatever value the host embedding the server passed for
+    `batch.maxBatchSize` — 200 unless it passed one, which no shipped boot path
+    does.
   - `.min(1)` is gone with `.max(200)`: an empty batch is a no-op returning
     `total: 0`, which is what these routes already did, rather than a validation
     error the schema claimed but nothing raised.
@@ -27521,6 +27522,8 @@ object:'task', function:'count', filter:{ status:'completed' } } }` lost that
     type was looser.
   - New export: `UpdateManyRecordSchema` / `UpdateManyRecord`.
 
+  *Erratum, 2026-09-18 — this entry called the batch cap "deployment policy" and told operators that deployments relying on unbounded batches "should raise `batch.maxBatchSize` (up to 1000)". The cap is embedder policy: `RestServerConfig.batch.maxBatchSize` is the argument a host passes when it constructs the server, and neither shipped boot path passes it — `os serve` forwards exactly two keys out of the stack config's `api:` block (`api.enableProjectScoping`, `api.projectResolution`) and the dev plugin calls `createRestApiPlugin()` with no config at all — so a CLI-started deployment always gets the 200 default and no flag, config file or CLI option moves it. Two passages above are corrected in place; the 1..1000 range, the 200 default and the enforcement this release shipped are unchanged. (Corrected after publication, #18740.)*
+
 - f2445c9: feat(spec,objectql,client,plugin-webhooks): predicate writes get an honest bulk event contract (#4639)
 
   A `multi: true` update/delete reaches `IDataDriver.updateMany` / `deleteMany`,
@@ -69646,9 +69649,9 @@ schedule }`), not on the flow.
   request, where before it was one statement that mostly failed anyway.
 
   **The cap moved to the routes, and the schemas gave it up.** Batch size is
-  deployment policy — `RestServerConfig.batch.maxBatchSize`, 1..1000, default 200
+  embedder policy — `RestServerConfig.batch.maxBatchSize`, 1..1000, default 200
   — so a hardcoded bound in the spec could only ever be a second, wrong answer
-  (a deployment raising the limit to 500 would still have been refused at 200).
+  (a host raising the limit to 500 would still have been refused at 200).
   All five bulk routes now call one `enforceBatchSize` helper with the configured
   value and answer with one envelope:
 
@@ -69684,9 +69687,10 @@ schedule }`), not on the flow.
   **Behaviour changes.**
 
   - A bulk request over the configured cap is `400 BATCH_TOO_LARGE` instead of
-    being executed. Deployments that were quietly relying on unbounded batches
-    should raise `batch.maxBatchSize` (up to 1000) rather than discover the cap in
-    production.
+    being executed. A deployment that was quietly relying on unbounded batches
+    meets the cap at whatever value the host embedding the server passed for
+    `batch.maxBatchSize` — 200 unless it passed one, which no shipped boot path
+    does.
   - `.min(1)` is gone with `.max(200)`: an empty batch is a no-op returning
     `total: 0`, which is what these routes already did, rather than a validation
     error the schema claimed but nothing raised.
@@ -69696,6 +69700,8 @@ schedule }`), not on the flow.
     type was looser.
   - New export: `UpdateManyRecordSchema` / `UpdateManyRecord`.
 
+  *Erratum, 2026-09-18 — this entry called the batch cap "deployment policy" and told operators that deployments relying on unbounded batches "should raise `batch.maxBatchSize` (up to 1000)". The cap is embedder policy: `RestServerConfig.batch.maxBatchSize` is the argument a host passes when it constructs the server, and neither shipped boot path passes it — `os serve` forwards exactly two keys out of the stack config's `api:` block (`api.enableProjectScoping`, `api.projectResolution`) and the dev plugin calls `createRestApiPlugin()` with no config at all — so a CLI-started deployment always gets the 200 default and no flag, config file or CLI option moves it. Two passages above are corrected in place; the 1..1000 range, the 200 default and the enforcement this release shipped are unchanged. (Corrected after publication, #18740.)*
+
 - 2af1988: fix(formula,spec,core): the RLS write-side `check` evaluator honours calendar-day upper bounds (ADR-0053 D-D)
 
   `@objectstack/formula`'s `matchesFilterCondition` — the evaluator behind RLS