Skip to content

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 into
mainfrom
claude/issue-18740-changelog-batch-cap-claim
Sep 18, 2026
Merged

os-try-charles merged 1 commit into
mainfrom
claude/issue-18740-changelog-batch-cap-claim

Conversation

@os-try-charles

@os-try-charles os-try-charles commented Sep 18, 2026

Copy link
Copy Markdown
Collaborator

Part of #18740

⚠️ Changed from Fixes to Part of by the dispatching domain:devx seat. Eight of the card's nine sites are corrected here. The ninth — content/docs/releases/v17/17-0.mdx:1734 — is still a live carrier, and the delivering agent correctly declined it: its standing operating rules prohibit editing content/docs/releases/** unconditionally, and a permission in AGENTS.md does not lift a prohibition. A closing keyword here would silently close a card that still has an open half, so it is withdrawn. The ninth site is routed as its own card; this PR stays a clean two-file CHANGELOG amendment.

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 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.maxBatchSize is the argument a host passes when it constructs the server, through the one door createRestApiPlugin({ api }). 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. A CLI-started deployment therefore always gets the 200 default, and no flag, config file or CLI option moves it.

The 789ad63 entry 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. The Batch size is / deployment policy sentence is wrapped across two lines: a single-line grep for it returns 0 and reads as a false absence.

file heading wording
packages/rest/CHANGELOG.md ## 17.0.0 (L4733) should raise instruction + deployment policy
packages/rest/CHANGELOG.md ## 17.0.0-rc.1 (L14992) both
packages/spec/CHANGELOG.md ## 17.0.0 (L15658) both
packages/spec/CHANGELOG.md ## 17.0.0-rc.1 (L67924) both

Per copy:

  • The claim. Batch size is deployment policy now reads Batch size is embedder policy, and the counterfactual beside it — (a deployment raising the limit to 500 would still have been refused at 200) — now says a host, since it presupposed the same unreachable knob.
  • The instruction. The behaviour bullet read Deployments that were quietly relying on unbounded batches should raise batch.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.md and packages/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.md forbids. Nothing published moves here either: the diff is prose inside already-shipped entries.

⚠️ The ninth site is NOT in this PR — a standing-rule conflict I am not resolving silently

content/docs/releases/v17/17-0.mdx:1734 carries the same claim (stay under batch.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.md permits a docs-only PR there; it does not require one — a permission does not override the prohibition, so there is no conflict with AGENTS.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.

⚠️ Report item, ⛔ not fixed here

packages/spec/CHANGELOG.md:3581 says the phrase "exists verbatim in the REST server ... at packages/rest/src/rest-server.ts:2071 ... it is owed to a follow-up in packages/rest". Re-measured on 631dcbd4b: grep -c "deployment policy" packages/rest/src/rest-server.ts = 0, and packages/rest/CHANGELOG.md:351 records ec5db7b retiring 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. #18740 does not cover it.

Firing controls

Computed from git diff -U0 hunk headers so that context lines cannot contaminate the reading, and taken from the probed files themselves.

  • C1should raise + batch.maxBatchSize: 0 outside the diff. Its only four hits are the verbatim quotations inside the new erratum lines.
  • C2 — the batch-cap deployment policy claim, 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).
  • C3 — the wrapped Batch size is / deployment policy sentence: 0 hits anywhere in the tree.
  • Control bytes: grep -naP over both changed files exits 1 (no match).

A bare deployment policy string is ⛔ not a usable control — it matches unrelated scheduling prose in about 30 files.


Generated by Claude Code


Generated by Claude Code

…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>
@os-try-charles os-try-charles added documentation Improvements or additions to documentation skip-changeset PR has no user-facing published change; bypasses the changeset gate labels Sep 18, 2026 — with Claude
@github-actions

Copy link
Copy Markdown
Contributor

📓 Docs Drift Check

⚠️ 2 changed file(s) yielded no anchor (packages/rest/CHANGELOG.md, packages/spec/CHANGELOG.md), so the pages documenting them are NOT COVERED by this run — this is not a clean bill of health for those files. Nothing else in this diff resolved to a documentable surface (no symbol, route or SDK anchor derived from 2 changed package(s)).

What this run could not see
  • 2 changed file(s) yielded no anchor (packages/rest/CHANGELOG.md, packages/spec/CHANGELOG.md) — pages documenting those are invisible to this run
  • a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.

Coarse fallback — 138 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json 631dcbd4b93c3f86d02080bc129a611f0619ed23packageMentionDocs.

@os-try-charles
os-try-charles marked this pull request as ready for review September 18, 2026 01:11
@os-try-charles
os-try-charles added this pull request to the merge queue Sep 18, 2026
Merged via the queue into main with commit 18cc3b1 Sep 18, 2026
52 checks passed
@os-try-charles
os-try-charles deleted the claude/issue-18740-changelog-batch-cap-claim branch September 18, 2026 01:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

documentation Improvements or additions to documentation size/s skip-changeset PR has no user-facing published change; bypasses the changeset gate

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants