docs(changelog): correct the falsified batch-cap claim in the published 17.0.0 and 17.0.0-rc.1 entries - #18852
Merged
os-try-charles merged 1 commit intoSep 18, 2026
Conversation
…ed 17.0.0 and 17.0.0-rc.1 entries
A dedicated docs-only PR, which AGENTS.md's Documentation Guardrails row for
`packages/*/CHANGELOG.md` requires: a factual error in a released entry is
amended in that entry, never as an erratum in a later one and never as a rider
on code changes. This diff is exactly two files, adds no source, no schema, no
export and no changeset.
The 2026-09-07 ruling found that no reader of a published surface can configure
`batch.maxBatchSize`. The `789ad63` entry carries that falsified claim in two
wordings, and the copy under `## 17.0.0` and the copy under `## 17.0.0-rc.1` are
both published text, so all four copies are corrected:
- "Batch size is deployment policy" -> "embedder policy", and the counterfactual
beside it ("a deployment raising the limit to 500") now reads "a host".
- The behaviour bullet stopped issuing an instruction no shipped boot path can
carry out. It read "Deployments ... should raise `batch.maxBatchSize` (up to
1000) rather than discover the cap in production"; it now states where the cap
actually comes from.
One dated erratum line closes each entry, carrying the in-repo tail this
repository already uses, and quoting both published wordings verbatim so the
record of what shipped is still readable. The 1..1000 range, the 200 default and
the enforcement this release shipped are unchanged.
Vocabulary is copied from the four prior landings of this same correction rather
than invented.
Claude-Session: https://claude.ai/code/session_017ef78bLdybu3AffehKkhfk
Co-authored-by: Claude <noreply@anthropic.com>
Contributor
📓 Docs Drift Check
What this run could not see
Coarse fallback — 138 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): |
os-try-charles
marked this pull request as ready for review
September 18, 2026 01:11
os-try-charles
deleted the
claude/issue-18740-changelog-batch-cap-claim
branch
September 18, 2026 01:48
This was referenced Sep 18, 2026
This was referenced Sep 18, 2026
Draft
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Part of #18740
A dedicated docs-only PR, which
AGENTS.md's Documentation Guardrails row forpackages/*/CHANGELOG.mdrequires: a factual error in a released entry is amended in that entry, ⛔ never as an erratum in a later entry and ⛔ never as a rider on code changes — "the reader greps the tombstoned symbol and lands on the old entry, so a correction anywhere else is one it never reaches".The diff is exactly two files. No source, no schema, no export, no test, and no changeset (see below).
What was false
The 2026-09-07 ruling found that no reader of a published surface can configure
batch.maxBatchSize. The cap is embedder policy:RestServerConfig.batch.maxBatchSizeis the argument a host passes when it constructs the server, through the one doorcreateRestApiPlugin({ api }). Neither shipped boot path passes it —os serveforwards exactly two keys out of the stack config'sapi:block (api.enableProjectScoping,api.projectResolution), and the dev plugin callscreateRestApiPlugin()with no config at all. A CLI-started deployment therefore always gets the 200 default, and no flag, config file or CLI option moves it.The
789ad63entry carries that falsified claim in two wordings, and it is duplicated under two published version headings, so there are eight carriers, not four.The eight sites corrected
Located by content, across lines on this tree at
631dcbd4b— ⛔ not by the line numbers carried on the card, and ⛔ not with a single-line match. TheBatch size is / deployment policysentence is wrapped across two lines: a single-line grep for it returns 0 and reads as a false absence.packages/rest/CHANGELOG.md## 17.0.0(L4733)should raiseinstruction +deployment policypackages/rest/CHANGELOG.md## 17.0.0-rc.1(L14992)packages/spec/CHANGELOG.md## 17.0.0(L15658)packages/spec/CHANGELOG.md## 17.0.0-rc.1(L67924)Per copy:
Batch size is deployment policynow readsBatch size is embedder policy, and the counterfactual beside it —(a deployment raising the limit to 500 would still have been refused at 200)— now saysa host, since it presupposed the same unreachable knob.Deployments that were quietly relying on unbounded batches should raisebatch.maxBatchSize(up to 1000) rather than discover the cap in production. That told an operator to perform an action no shipped boot path can perform, so a reader who complied had no way to tell whether they had succeeded. It now states where the cap actually comes from and issues no instruction.Where this landed between "faithful to the record" and "no longer misleading"
This is a CHANGELOG, so the job is to record what happened in that version — ⛔ not to rewrite history into "this is what we said at the time". I did not invent a shape for that: this repository has already settled it, in #18569 / #17849, and I copied it. The published words are corrected in place, and the old words are kept as a marked quotation in a dated erratum line closing the entry — the in-repo tail already used at
packages/spec/CHANGELOG.md(three sites),packages/lint/CHANGELOG.mdandpackages/metadata-protocol/CHANGELOG.md. So the entry no longer instructs, and what shipped is still readable verbatim.The factual vocabulary is likewise copied, ⛔ not invented — from
ec5db7b(packages/rest/CHANGELOG.md:351) and the pending.changeset/18739-batch-cap-embedder-only.md, which are the fourth and fifth landings of this same correction.⛔ No new entry at the top, ⛔ no version heading added, ⛔ nothing this release published is changed: the 1..1000 range, the 200 default and the enforcement are all untouched.
⛔ Deliberately no changeset
A changeset would compile this correction into a new release note — which is precisely the erratum-in-a-later-entry shape
AGENTS.mdforbids. Nothing published moves here either: the diff is prose inside already-shipped entries.content/docs/releases/v17/17-0.mdx:1734carries the same claim (stay underbatch.maxBatchSize(default 200, raisable to 1000) or chunk) and the dispatch listed it as the ninth site.I did not touch it. My standing operating rules carry an unconditional prohibition on editing
content/docs/releases/, and they state that such a clause wins over the dispatch word.AGENTS.mdpermits a docs-only PR there; it does not require one — a permission does not override the prohibition, so there is no conflict withAGENTS.md, only with the dispatch. Flagging rather than choosing a side: that line is still a live carrier and needs either a separate actor or an explicit release of the prohibition.packages/spec/CHANGELOG.md:3581says the phrase "exists verbatim in the REST server ... atpackages/rest/src/rest-server.ts:2071... it is owed to a follow-up inpackages/rest". Re-measured on631dcbd4b:grep -c "deployment policy" packages/rest/src/rest-server.ts= 0, andpackages/rest/CHANGELOG.md:351recordsec5db7bretiring exactly that phrase. That follow-up is done and the note is now stale — a debt recorded as outstanding that has been paid. It is a different error from the one this card names, so it is reported, ⛔ not ridden.#18740does not cover it.Firing controls
Computed from
git diff -U0hunk headers so that context lines cannot contaminate the reading, and taken from the probed files themselves.should raise+batch.maxBatchSize: 0 outside the diff. Its only four hits are the verbatim quotations inside the new erratum lines.deployment policyclaim, multiline-aware: 4 hits outside the diff, each classified and none a live carrier —packages/rest/CHANGELOG.md:351(records the phrase's retirement),packages/spec/CHANGELOG.md:3581(the stale note above),.changeset/18739-batch-cap-embedder-only.md(the sibling correction),docs/qa/platform-checklist/FOLLOW-UPS.md:575(states the correct embedder-only fact).Batch size is/deployment policysentence: 0 hits anywhere in the tree.grep -naPover both changed files exits 1 (no match).A bare
deployment policystring is ⛔ not a usable control — it matches unrelated scheduling prose in about 30 files.Generated by Claude Code
Generated by Claude Code