[finding] the 17.0.0 CHANGELOG entries in packages/rest and packages/spec tell deployments to "raise batch.maxBatchSize (up to 1000)" — the falsified cap claim in its strongest form, published to npm, on the release-owned tree #18740

⛔ Recorded for triage; no severity asserted, no domain:*, no type — routing and grading are triage's. Filed by the domain:devx execution PM seat (post #6023, session session_017ef78bLdybu3AffehKkhfk), round 28, from the #17183 flight (PR #18737). ⛔ Not claiming.

⚠️ This card is filed because it cannot be ridden: every member below is on a release-owned tree, and AGENTS.md forbids a code PR touching it. ⇒ a dedicated docs-only PR, which is exactly what this card is for.

The lines

Read on origin/main @ 080688b56 at 2026-09-17T17:45Z, all four hits verbatim from the 17.0.0 entry:

packages/rest/CHANGELOG.md:5304    should raise `batch.maxBatchSize` (up to 1000) rather than discover the cap in
packages/rest/CHANGELOG.md:15231   should raise `batch.maxBatchSize` (up to 1000) rather than discover the cap in
packages/spec/CHANGELOG.md:27513   should raise `batch.maxBatchSize` (up to 1000) rather than discover the cap in
packages/spec/CHANGELOG.md:69688   should raise `batch.maxBatchSize` (up to 1000) rather than discover the cap in

The surrounding sentence reads Deployments that were quietly relying on unbounded batches should raise batch.maxBatchSize (up to 1000) rather than discover the cap in production, and the same entry states Batch size is deployment policy — RestServerConfig.batch.maxBatchSize, 1..1000, default 200.

A fifth member, already named in #17183's own body and repeated here so this card is the whole set:

content/docs/releases/v17/17-0.mdx:1734   stay under `batch.maxBatchSize` (default 200, raisable to 1000

Why this is the strongest form of the claim found anywhere

The claim that a reader of a published surface can configure batch.maxBatchSize was ruled false on 2026-09-07 (director seat, summon #17, decision batch #2, maintainer verbatim 「同意」). Five carriers have been found and four corrected (#15543 · #16801 · #16940 · #17183; the fifth, live source, is filed separately).

⭐ Every one of those states the claim. This one issues an instruction. should raise batch.maxBatchSize (up to 1000) tells an operator to perform an action no shipped boot path can perform — so the reader who complies has no way to tell whether they succeeded, because the value they set is simply never read on a CLI-started deployment.

⭐ And it is published to npm. A CHANGELOG entry is the text an upgrading human or agent greps first, and it is not re-fetched from this repository — the copy in a consumer's node_modules is the one they read. ⇒ Unlike every prior carrier, correcting this one does not reach the copies already distributed; it only stops the next ones.

⛔ The shape the repair may NOT take

AGENTS.md is explicit, and this card does not re-decide it: a factual error in a released entry is amended in a dedicated docs-only PR, ⛔ never a rider on a code PR, and ⛔ never an erratum bolted onto a later entry.

⚠️ The later-entry shape already exists at packages/spec/CHANGELOG.md:3581 — so whoever takes this should read that first and decide whether it discharges the duty for the spec side or is itself the anti-pattern the rule names. ⛔ This seat does not rule on that.

⛔ What this card does NOT claim

• ⛔ Not that the 17.0.0 entry was wrong when written. Whether the claim was ever true is not measured here; the ruling is what makes the text wrong now.
• ⛔ Not that these five are the complete set on release-owned trees. The enumeration behind this card covered packages/*/CHANGELOG.md and content/docs/releases/**; anything else is unread, not absent.
• ⛔ Not a request to touch any of it inside PR docs(protocol): the batch cap is embedder-only, not “configurable via maxBatchSize” — the fourth carrier, plus the fifth-carrier enumeration #18737 or any other code PR.

Measurement provenance and control

Found by the dev on the #17183 flight, then re-measured independently by this seat at 2026-09-17T17:45Z before filing — ⛔ not taken on the report's narrative. The four CHANGELOG hits above are this seat's own grep -n output, and the tree-wide maxBatchSize control reads 38 files (excluding node_modules and dist) ⇒ the probe reaches the tree.

Duplicate check — method stated

One targeted MCP search_issues call over this repository (the repo-scoped REST /search/issues route is refused by this container's egress proxy with HTTP 403, so the channel is declared rather than assumed).

• Result: 7 items, total_count: 7 — [finding] content/docs/protocol/kernel/http-protocol.mdx calls the batch cap "configurable via maxBatchSize" — a FOURTH carrier of the claim #15543 / #16801 / #16940 corrected elsewhere #17183, [finding] rest-server.ts#enforceBatchSize calls the batch cap "deployment policy", but no shipped boot path can set it — the same defect #15543 just closed in packages/spec, one package over #16801, [finding] content/docs/api/data-api.mdx tells operators the batch cap is "the deployment's" and "configurable 1-1000" — the third carrier of the claim #15543 and #16801 corrected in code #16940, pm-dispatch SKILL.md arg table says batch defaults to 3 while the maintainer's cap has been 5 since 2026-09-03 — say which is default and which is ceiling #16272, pm-dispatch: concentrated-round batch parameter ruled ≤10 cards per batch (quality first) — update dispatch-runbook.md #11980, chore(spec): retire IDataEngine.batch? per ADR-0119 D3 — declared-but-unimplemented, zero callers #4618, 批量写路由的 "max 200" 一处都没在拦 —— 而且同一个端点有两份互相矛盾的 Zod #3939. None is a card for a CHANGELOG or for content/docs/releases/**.
• Live positive control, same call: [finding] rest-server.ts#enforceBatchSize calls the batch cap "deployment policy", but no shipped boot path can set it — the same defect #15543 just closed in packages/spec, one package over #16801 and [finding] content/docs/api/data-api.mdx tells operators the batch cap is "the deployment's" and "configurable 1-1000" — the third carrier of the claim #15543 and #16801 corrected in code #16940 — the two prior carriers of this exact claim — both had to hit, and both did ⇒ the zero for the release-owned tree is a reading, not a dead index.

Dedupe words for the next searcher: CHANGELOG · deployment policy · should raise · batch.maxBatchSize · 17.0.0 · 17-0.mdx · raisable to 1000

Refs

#15543 · #16801 · #16940 · #17183 · PR #18737 · the 2026-09-07 ruling (director seat, summon #17, decision batch #2, maintainer verbatim 「同意」)

Generated by Claude Code