From efea2a386ebdf342b72b82bbdc5693e20998aaee Mon Sep 17 00:00:00 2001 From: Claude Date: Thu, 1 Oct 2026 01:26:50 +0000 Subject: [PATCH] docs(spec): the 17.4.0 entry no longer records the paid packages/rest follow-up as owed The 094b8fd entry in @objectstack/spec 17.4.0 closed its batch.maxBatchSize note with "it is owed to a follow-up in packages/rest" and anchored the quoted docblock at packages/rest/src/rest-server.ts:2071. ec5db7b paid that follow-up eleven hours later and shipped in @objectstack/rest 17.4.0, the same release, so the note was false as published and the line anchor has since drifted onto unrelated JSDoc. Amended in place, the way this file's earlier errata were: the clause and the anchor are corrected in the passage, and one dated erratum line at the end of the entry quotes the old words. No changeset: a changeset would compile the correction into a new release note, the erratum-in-a-later-entry shape the CHANGELOG guardrail forbids. Claude-Session: https://claude.ai/code/session_01JAhu8u8QfBvRjVZDox7CP9 Co-authored-by: Claude --- packages/spec/CHANGELOG.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/packages/spec/CHANGELOG.md b/packages/spec/CHANGELOG.md index 46425b3598f..11c201b5634 100644 --- a/packages/spec/CHANGELOG.md +++ b/packages/spec/CHANGELOG.md @@ -18468,9 +18468,11 @@ ⚠️ **A correction to the record this change is built on.** An earlier draft of these sentences named a second door, `createHonoServerPlugin({ restConfig })`. No such function exists — a definition probe returns zero across the tree, against a positive control that finds `createRestApiPlugin` at `packages/rest/src/rest-api-plugin.ts:115`. `HonoServerPlugin` is a class that declares a `restConfig?: RestServerConfig` option whose single reader takes `api.basePath` for the SPA fallback; it never constructs a REST server, so it is not a door onto any of these keys. The claim was inherited from prose that was already in the tree, and on a card whose whole subject is a declared posture nobody can reach, publishing a declared door that does not exist would have been the same defect one level up. Every place this change touches now says the corrected thing. - ⚠️ **`batch.maxBatchSize` really does describe itself as deployment policy — in another package.** The phrase does not occur in `packages/spec/src/api/rest-server.zod.ts`, but it exists verbatim in the REST server: *"The cap is deployment policy — `RestServerConfig.batch.maxBatchSize` (1..1000, default 200)"* at `packages/rest/src/rest-server.ts:2071`. Same defect class, different package, and not touched here — it is owed to a follow-up in `packages/rest`. + ⚠️ **`batch.maxBatchSize` really does describe itself as deployment policy — in another package.** The phrase does not occur in `packages/spec/src/api/rest-server.zod.ts`, but it exists verbatim in the REST server: *"The cap is deployment policy — `RestServerConfig.batch.maxBatchSize` (1..1000, default 200)"* in the `enforceBatchSize` docblock of `packages/rest/src/rest-server.ts`. Same defect class, different package, and not touched here — the follow-up in `packages/rest` is ec5db7b, which rewrote that docblock to call the cap embedder policy and shipped in `@objectstack/rest` 17.4.0, the same release as this entry. No behaviour changes and no schema shape changes — no key, default, bound or refusal moves, so the accept set is byte-identical. This is prose plus ledger rows, and the regenerated `content/docs/references/api/rest-server.mdx` that follows from the `describe()` edits. + + *Erratum, 2026-10-01 — this entry anchored the REST server's "deployment policy" sentence at `packages/rest/src/rest-server.ts:2071` and closed "it is owed to a follow-up in `packages/rest`". The follow-up was paid before this entry was published: ec5db7b landed eleven hours after this change, rewrote `enforceBatchSize`'s docblock to say the cap is embedder policy, not deployment policy, and shipped in `@objectstack/rest` 17.4.0. The sentence was true when written. One passage above is corrected in place; the finding it records and everything else this entry published are unchanged. (Corrected after publication, #18858.)* - aedbaef: `POST /sign-up/email` for an address that already has a `sys_user` row is refused explicitly, instead of answering 200 for a row that is never written (#15587) **This is a wire-behaviour change on one lane**: a call that answers `200 {"token":null,"user":{…}}` today answers `422 USER_ALREADY_EXISTS_USE_ANOTHER_EMAIL` after this change. Nothing is newly admitted — the response that changes is one that reported a creation that never happened.