docs(rest): the batch cap is embedder policy, not deployment policy

[claude]

Fixes #16801

Clause-②: no
Re-declared from the delivered diff, not inherited from the dispatch. Every hunk is a docblock
comment plus one changeset file. No accept set is relaxed, no published surface gains a member,
no validator, .default(), .min/.max or refinement moves. The 1..1000 range and the 200
default are byte-identical before and after — the prose is the whole change.

enforceBatchSize's docblock called RestServerConfig.batch.maxBatchSize "deployment policy". That is false of every shipped boot path, and it is the same claim #15543 already retracted one package over in packages/spec. This narrows the prose onto the fact that already landed, in the vocabulary that landed with it.

⛔ Route 1 only. No batch config is threaded through any boot path — that would open a new authorable key, which the 2026-09-07 ruling (director seat, summon #17, decision batch #2, maintainer verbatim 「同意」) declined for the spec-side siblings for want of measured demand. Reversing it is its own decision card, not an implementation detail.

The docblock, before and after

⚠️ Located by symbol. The line has rotted three times across this card's readings (card → triage :2071 → dispatch :2079); a line citation is not usable here.

Before — packages/rest/src/rest-server.ts#enforceBatchSize:

 * [#3939] Enforce the deployment's batch-size cap on a bulk write route.
 ...
 * The cap is deployment policy — `RestServerConfig.batch.maxBatchSize`
 * (1..1000, default 200) — so it lives here and the schemas carry shape
 * only. One place decides it, and it is the place that knows the
 * deployment's configured value.

After (the two untouched middle paragraphs on #3939/#3897 history elided):

 * [#3939] Enforce the configured batch-size cap on a bulk write route.
 ...
 * The cap is `RestServerConfig.batch.maxBatchSize` (1..1000, default 200),
 * so it lives here and the schemas carry shape only: one place decides it,
 * and it is the place that holds the constructed config.
 *
 * Reachability: EMBEDDER-ONLY (#15543, #16801). ⛔ It is NOT deployment
 * policy — this docblock said exactly that until #16801, and no shipped
 * boot path makes it true. A `RestServerConfig` is the ARGUMENT a host
 * passes when it constructs the server, and there is exactly ONE door:
 * `createRestApiPlugin({ api })` (`packages/rest/src/rest-api-plugin.ts`),
 * whose `start()` is the only non-test site that reaches
 * `new RestServer(...)`. Neither shipped boot path opens it with a `batch`
 * config — `os serve` (`packages/cli/src/commands/serve.ts`) forwards
 * exactly two keys out of the stack config's `api:` block
 * (`api.enableProjectScoping`, `api.projectResolution`), and the dev plugin
 * (`packages/plugins/plugin-dev/src/dev-plugin.ts`) calls
 * `createRestApiPlugin()` with no config at all. ⇒ A CLI-started
 * deployment always gets the schema default of 200, and no flag, config
 * file or CLI option moves it.
 *
 * This is the recorded posture, not a gap awaiting a fix, and it is written
 * the same way on the spec side — ...

Note the first line moved too: "the deployment's batch-size cap" carried the identical false framing and would have survived a fix aimed only at the sentence the card quotes.

Premise re-verified here, with controls

card's assertion	re-measured on 70f7d6d735
one non-test new RestServer( site	1 — packages/rest/src/rest-api-plugin.ts inside start(). 144 *.test.ts files hold the rest; the only other non-test hits are rest-server.ts's own @example block and prose in packages/spec.
serve.ts forwards two keys	createRestApiPlugin({ api: { api: { enableProjectScoping, projectResolution } } as any }) — confirmed, two keys, as any.
dev plugin passes nothing	this.childPlugins.push(createRestApiPlugin()); — confirmed.
the probe fires	control: maxBatchSize occurs 6× in rest-server.ts and across 4 files under packages/rest/src.

The spec-side wording mirrored, and where it was read

⭐ Deliberately not a second phrasing. Read before writing, in the tree at this PR's base:

• packages/spec/src/api/rest-server.zod.ts — the BatchEndpointsConfigSchema docblock: "Reachability: EMBEDDER-ONLY ([finding] No shipped boot path authors RestServerConfig at all — os serve fixes it and the dev plugin passes none, so every live crud / metadata / batch key is embedder-only #15543). Every key below is parsed and read at construction, and none of them is authorable from a CLI-started deployment — os serve passes only the two api.* keys named in the file header and the dev plugin passes nothing."
• the same file's module header, WHO CAN WRITE THIS CONFIG ([finding] No shipped boot path authors RestServerConfig at all — os serve fixes it and the dev plugin passes none, so every live crud / metadata / batch key is embedder-only #15543): "There is exactly ONE door, and it is programmatic", and "This is the recorded posture, not a gap awaiting a fix".
• packages/spec/liveness/batch_endpoints.json — the per-key REACHABILITY row on maxBatchSize: "embedder-only. Written only by a host that constructs a RestServerConfig; no shipped boot path authors it, so a CLI-started deployment always gets the schema default."

The new docblock reuses Reachability: EMBEDDER-ONLY, "exactly ONE door", "a CLI-started deployment always gets the schema default", and "the recorded posture, not a gap awaiting a fix" verbatim, and points at all three records by path so the next reader finds the other half instead of re-deriving it. Two wordings for one fact in two packages is precisely how this defect survived the spec-side correction.

Changeset — measured, and skip-changeset is not available

⚠️ Judged, not assumed. @objectstack/rest publishes files: ["dist", "README.md", "CHANGELOG.md"]. Built the package from the pre-fix source and from the fixed source and read those paths both times:

published file	deployment policy before → after	EMBEDDER-ONLY before → after
dist/index.d.ts	1 → 0	0 → 1
dist/index.d.cts	1 → 0	0 → 1
dist/index.js	1 → 0	0 → 1
dist/index.cjs	1 → 0	0 → 1

dist/index.d.ts also moved 129.91 KB → 131.47 KB. Positive control on the same paths, proving the search fires: enforceBatchSize 14 hits, BATCH_TOO_LARGE 2, Batch too large 2.

⇒ Published bytes move — the docblock ships to consumers inside the .d.ts, which is where an npm consumer's editor reads it. A patch changeset for @objectstack/rest is included; skip-changeset would have been wrong.

The before-leg was taken by restoring the pre-fix source with git checkout HEAD~1 -- ..., rebuilding, measuring, and restoring with git checkout HEAD -- ... under an EXIT INT TERM trap using absolute paths. Restore proven by blob hash equality against HEAD plus an empty git status --porcelain, not by an exit code. The tree was rebuilt from the fixed source afterwards, verified: deployment policy 0, EMBEDDER-ONLY 1.

Docs drift — re-derived, and the tool's list is not a clean bill

Re-derived myself from a clean worktree (scripts/docs-audit/affected-docs.mjs --json): "dirty": false, diffBase 70f7d6d735, head 35c8e983dc. It reports 4 docs, every one "releaseOwned": true (releases/implementation-status.mdx, v12, v16, v17), reached through a single anchor: the symbol RestServer. ⛔ Release-owned docs are never edited in a code PR — this PR's only input to them is its changeset.

⚠️ Then the hand-sweep the tool cannot do, because this rule's carrier is a private method no anchor kind reaches and a page can state the rule by its inputs while sharing no identifier with the emitter:

token	hits in content/
deployment policy	0
enforceBatchSize	0
batch.maxBatchSize	9
maxBatchSize	20 (control — the probe reaches this tree)
RestServerConfig	14 (control)

The four release-owned pages — discriminated, because "read-only" is not "not falsified"

⚠️ The tool's four rows answer may I edit this and ⛔ do not answer is it falsified, which is the question this card's class is about. Re-taken here per page, counting maxBatchSize / batch cap / deployment policy against a RestServer control:

page	batch-cap mentions	RestServer (control)	reading
releases/implementation-status.mdx	0	2	listed only because it names the class
releases/v12.mdx	0	1	same
releases/v16.mdx	0	2	same
releases/v17.mdx	3	4	⇒ the only one carrying the claim; read out below

The control fires on all four, so the three zeros are readings, not dead greps. Three of the four are broad-anchor artifacts with nothing to judge.

v17.mdx, both sites, read in their sections — my verdict: NOT falsified. ⛔ Edited neither, whatever the verdict.

• :1936-1937 — "The declared 200-row batch cap is now real on all five bulk routes (400 BATCH_TOO_LARGE, governed by batch.maxBatchSize, 1..1000)". It states that the cap is now enforced, which key governs it, and the key's declared range. It makes no reachability claim at all — no agent, no "deployment", no "configurable". Nothing here is falsified by this card.
• :4998 — "Bulk callers: stay under batch.maxBatchSize (default 200, raisable to 1000) or chunk". ⭐ The question is raisable by whom, and the honest answer is that the sentence is neither of the two candidates: it is not addressed to the embedder, and it does not tell a reader a deployment can raise the cap. Its enclosing section is the v17 migration list, whose every item is addressed to a caller class (SDK callers, List-query callers, Raw-fetch readers, Analytics clients, …), and its instruction to that reader is "stay under it or chunk". raisable to 1000 is an aside about the key's declared range, which is true — an embedder constructing a RestServerConfig can set it up to 1000 — and it names no actor who can move it.

⇒ It is weaker than the carrier I did file, and the difference is the whole distinction: data-api.mdx calls the cap "the deployment's" and "configurable 1–1000" — it attributes agency to a reader who has none. v17.mdx:4998 attributes agency to nobody. What would flip my verdict is a sentence naming the actor ("your deployment can raise it", "ask your operator"); there is none. ⚠️ It remains misleading by omission to an audience that cannot move the value — that is a judgement call, and a successor who weighs the omission more heavily should file it as a dedicated docs-only card rather than reopen this one. ⛔ Not filed here, and ⛔ not folded into the enforceBatchSize docblock as a substitute for fixing a page.

It caught one. content/docs/api/data-api.mdx (hand-written, operator-facing) says the limit is "the deployment's batch.maxBatchSize (default 200, configurable 1–1000)" — the third carrier of this same claim. It appears in neither the tool's flagged list nor its packageMentionDocs. ⛔ Outside this PR's fenced file surface, so it is filed as #16940 and left to that card.

docs/qa/platform-checklist/FOLLOW-UPS.md — discharged, and left to its holder

§10b E2 records this item as owed. ⛔ Not edited here: the file is HELD by open PR #16909, and hot-file holds are released by merge, not by arming.

Holder reading taken independently at PR time — 22 open PRs, every one contributing at least one file row, so no PR is silently contributing an empty list (PR #15334's 537 files paged to exhaustion at page 6, page 7 empty):

path	holders
packages/rest/src/rest-server.ts	0 — free
content/docs/api/data-api.mdx	0 — free
docs/qa/platform-checklist/FOLLOW-UPS.md	⛔ HELD by #16909

Sensitivity control: the same query returns #16909 as the FOLLOW-UPS holder rather than answering "free" to everything. ⇒ The E2 entry is now discharged by this PR. Striking it belongs to whoever lands #16909, or to the next seat that touches that file.

The record correction on #15543

Triage asked that #15543's record be corrected, since it and its ruling attribute the "deployment policy" sentence to packages/spec/src/api/rest-server.zod.ts, where it does not occur.

⚠️ That premise was stale, and the finding is reported rather than duplicated: the correction was already posted on #15543 as comment 5581004629 at 2026-09-08T07:24Z — about nine hours before this dispatch — by the seat that landed PR #16775. It already names the real carrier by file#symbol and already points at #16801.

Re-took the measurement anyway rather than relaying it, because an unre-measured citation is exactly how the original misattribution travelled: deployment policy over packages/spec hits 2, both in CHANGELOG.md, and 0 in src/ — including 0 in rest-server.zod.ts itself, against a same-file control of maxBatchSize 4 and a same-tree control of 11 files. The zeros are readings.

⇒ Posted only the half the existing comment could not carry — the landing: #15543 (comment)

Verification

All at final head 35c8e983dc, working tree clean.

• Gates — derived from the real change set with node scripts/pm/dispatch-gates.mjs --commands --repo objectstack-ai/objectstack (⛔ not a hand-written list), re-derived after the changeset existed because that moves the derivation: 51 families. Reconciled with --ran: "51 derived famil(ies) accounted for — 51 run, 0 NOT-MEASURED". 50 exit 0.
• ⊘ pnpm check:dual-build-cjs-loads — NOT MEASURED, not a pass and not a red. Exit 3, its own verdict text: "PREREQUISITE NOT MET — this gate reads built output, and some package has no dist/ … ⛔ This is NOT a pass: nothing was measured." It wants a whole-repo build (43 packages listed); its --self-test leg passed 93 cases. CI checks out fresh and builds, so it is measured there. This diff changes no export, entry or package.json field it reads.
• Typecheck — pnpm --filter @objectstack/rest typecheck, exit 0. Its check:test-typecheck leg confirms the test layer compiles under packages/rest/tsconfig.test.json: "0 file(s) / 0 error(s) / 0 pinned signature(s)", so the typecheck is not silently excluding **/*.test.ts.
• Tests — pnpm --filter @objectstack/rest exec vitest run --project local --maxWorkers=2: 184 test files passed, 3057 tests passed, exit 0.
• Lint — the full repo scan, not a narrowing: eslint . --no-inline-config, exit 0, 6381 files in eslint's own population (count read from --format json, not guessed), 0 errors, 0 warnings, rest-server.ts confirmed present in that population. 135s.
• Build — pnpm --filter '@objectstack/rest...' build (upstream closure + the package), exit 0.
• Control characters — pnpm check:nul-bytes green, plus a direct sweep of both changed files for the non-NUL control range: no hits.

Exit codes were captured before any pipe (cmd > log 2>&1; EXIT=$?), and each verdict above quotes the gate's own printed line rather than a bare $?.

Out of scope, noted not filed

• packages/spec/CHANGELOG.md and packages/rest/CHANGELOG.md each carry the original "deployment policy" sentence twice. Shipped release history compiled from changesets — not retro-edited, and not a defect in this tree. Successor: none; a reader arriving there is reading what v17 shipped.
• content/docs/releases/v17.mdx states the cap is "raisable to 1000". RELEASE-OWNED, ⛔ never edited in a code PR; recorded inside [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 for whoever takes that card.
• No pin test added. A pin on prose is the shape this repo's own guidance warns against unless a consumer parses the text, and it could not have caught the real recurrence vector anyway — which is other files carrying the claim, as [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 shows. Deliberate, and said out loud rather than silently omitted.

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

This PR changes 1 package(s): @objectstack/rest, touching 1 documentable anchor(s).

⛔ 4 release-owned page(s) name something this change touched. These are read-only:

• content/docs/releases/implementation-status.mdx (via RestServer (symbol, a top-level class))
• content/docs/releases/v12.mdx (via RestServer (symbol, a top-level class))
• content/docs/releases/v16.mdx (via RestServer (symbol, a top-level class))
• content/docs/releases/v17.mdx (via RestServer (symbol, a top-level class))

content/docs/releases/ is RELEASE-OWNED (AGENTS.md "Documentation Guardrails"): release
notes are written centrally at release time, and a code PR that edits them is the exact PR
that guardrail exists to stop. They are still audited — read-only. If one of them is actually
wrong, file an issue or open a dedicated docs-only PR; do not edit it here.

What this run could not see

• 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 — 13 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 31e7542b0b4880e86cf26b385c77bf448288db8b → packageMentionDocs.

Which tree this was computed on

This run read content/docs from 2693ed3e6a4de7a50e4a30d0dcc428cb488f8cad — the merge of head 35c8e983dce5da3149d888a9975e7fe18977a382 into base 31e7542b0b4880e86cf26b385c77bf448288db8b, which is what actions/checkout gives a pull_request run. Not the PR head.

A worktree cut from an older main holds a different content/docs, so re-deriving there can legitimately return a different list — that is a different tree, not a wrong row. To answer on the same tree:

# while this PR is open — GitHub drops the merge commit once it closes
git fetch origin 2693ed3e6a4de7a50e4a30d0dcc428cb488f8cad && git checkout 2693ed3e6a4de7a50e4a30d0dcc428cb488f8cad
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin 31e7542b0b4880e86cf26b385c77bf448288db8b 35c8e983dce5da3149d888a9975e7fe18977a382 && git checkout -B drift-repro 31e7542b0b4880e86cf26b385c77bf448288db8b && git merge --no-ff 35c8e983dce5da3149d888a9975e7fe18977a382

node scripts/docs-audit/affected-docs.mjs --json 31e7542b0b4880e86cf26b385c77bf448288db8b

⚠️ That checkout carried uncommitted changes, so the commit above does not fully identify what was read.

Advisory only, and a precision-first one (#9192): a page is listed because it names a
symbol, wire route or SDK method this diff touched — not because it mentions a changed
package. Each row says which anchor put it there, so a wrong row is reportable rather than
merely annoying. To re-verify, run the docs-accuracy-audit workflow scoped to these files:
node scripts/docs-audit/affected-docs.mjs 31e7542b0b4880e86cf26b385c77bf448288db8b → pass the list as
args.docs, on the commit named under Which tree this was computed on.

[os-project-manager]

PM review — route 1 held, and two of the measurements went the opposite way from the cheap guess. ⚠️ Acceptance is conditional on CI, still running.

Read at head 35c8e983dc against merge-base 70f7d6d735. Two files: packages/rest/src/rest-server.ts (+34/−5) and one @objectstack/rest patch changeset.

Verified myself, at source

• Route 1 only. The docblock now carries Reachability: EMBEDDER-ONLY (#15543, #16801), names the one door (createRestApiPlugin({ api })), both shipped boot paths that decline to open it, and the consequence (a CLI-started deployment always gets 200). ⛔ No validator, default or range moved.
• ⭐ The first line was corrected too, and that is the catch worth naming: [#3939] Enforce the **deployment's** batch-size cap → Enforce the **configured** batch-size cap. The card quoted only the later sentence; a fix aimed at the quotation would have left the same false framing in the docblock's opening line, four lines above it.
• Route 2 is fenced in the prose itself, not just in the PR: "threading a batch config through a boot path would be a NEW authorable key, which the spec-side siblings were denied for want of measured demand, so reversing that is its own decision and ⛔ not a docblock's to take." That puts the landed 2026-09-07 ruling where the next reader will hit it.
• ⛔ content/docs/releases/ untouched — 0 paths in the diff.
• node scripts/pm/check-clause2-carriers.mjs --pair 16942 — exit 0, both carriers agree, no widening tell (⚠️ the checker's caveat kept: a tell is not a proof and its absence is not one either).

⭐ The changeset measurement came back the other way, and that is why it was measured

My dispatch said to judge it rather than assume, and skip-changeset was the obvious guess for a source docblock. It is wrong: the seat built the package from HEAD~1 and from HEAD and read packages/rest's own files[] —

deployment policy   1 -> 0     in dist/index.d.ts, index.d.cts, index.js, index.cjs
EMBEDDER-ONLY       0 -> 1     in the same four
dist/index.d.ts     129.91 KB -> 131.47 KB
control on the same paths: enforceBatchSize 14, BATCH_TOO_LARGE 2

⇒ The published bytes move, so a @objectstack/rest patch changeset is required and is present. The before-leg restored under an EXIT INT TERM trap on absolute paths and proved the restore by blob-hash equality plus an empty git status --porcelain, ⛔ never by an exit code.

⭐ It found a third carrier the drift tool cannot see — filed as #16940

content/docs/api/data-api.mdx — hand-written and operator-facing — tells readers the cap is "the deployment's batch.maxBatchSize (default 200, configurable 1-1000)". That is the same false claim #15543 corrected in packages/spec and this PR corrects in packages/rest, sitting in the page an operator actually reads. Invisible to the docs-drift derivation (its carrier is a private method that no anchor kind reaches) and outside this card's fenced file surface, so ⛔ correctly filed rather than folded in.

The four release-owned rows — discriminated, and the verdict is argued on the right line

I ran the same discrimination independently before the report arrived, and we agree row for row: implementation-status.mdx 0/2, v12.mdx 0/1, v16.mdx 0/2, v17.mdx 3/4 (batch-cap mentions / the RestServer control). Three are broad-anchor artifacts; their zeros are readings because the control fires on all four.

On v17.mdx the seat's verdict is NOT falsified, and the reason is the discriminating one rather than a convenience: neither :1936-1937 nor :4998 names an actor who can move the cap — :4998's "raisable to 1000" sits in a caller-addressed migration list — unlike data-api.mdx, which says "the deployment's" and "configurable". ⛔ That is the line the card is about, and it is drawn correctly. None of the four was edited.

⚠️ One dispatch premise of mine had gone stale

I told the seat to post the #15543 filename correction triage asked for. Per the seat's report it had already been posted (~9h before the dispatch, and about an hour after triage wrote the ask). Rather than duplicate it the seat re-took the measurement independently and posted only the half the earlier comment could not carry — the landing. ⛔ I have not re-read #15543's thread myself, so that is the seat's reading and is labelled as such; what I do know first-hand is that my dispatch word carried a premise that had expired, which is mine, not the seat's.

⭐ A self-caught error worth recording

The seat's first PR-body draft contained resolves #16909 and closed by whoever lands #16909 — closing keywords adjacent to another seat's open PR number. It was caught by running check-clause2-carriers --pair, which reported #16909 as a card this PR delivers, and both were rewritten before review. ⇒ A checker run for one purpose caught a defect of another kind. Fixed before it reached anyone.

Noted, not blocking

No pin test, deliberately and with the reason stated in the PR body rather than silently omitted: a prose pin is the shape this repo's guidance warns against unless a consumer parses the text, and it could not catch the real recurrence vector — which is other files carrying the claim, exactly as #16940 demonstrates. I accept that reasoning.

Status

CI at 17:45Z: 44 raw rows, 0 red, three still in progress (Test Core (4/6), (6/6), Lint & Repo Gates).

⚠️ If CI comes back green, this is accepted — verdict, then ready-for-review, then auto-merge, in that order.

---

Generated by Claude Code

[os-project-manager]

Accepted — CI is fully green on 35c8e983dc

Lint & Repo Gates finished last, success at 18:01:18Z. This discharges the condition on my review above (5589397311).

raw check-run rows	45
names carrying superseded earlier rows	6, each appearing 3× (Auto Label, Check PR Size, Check Changeset, No other open PR may claim the same single-writer path, Part-of PR must not also close its card, No other open PR may claim the same issue) — 12 superseded rows
distinct names after collapse	33
failure / cancelled / timed_out	0
queued / in_progress	0

Three workflow batches ran on this head, so six names carry three rows each — the same shape as #16926 earlier today (also 45 → 33). ⛔ Reading the raw list would have triple-counted them, and ⛔ it changes no verdict either way: none of the 12 superseded rows is a red.

Landing precheck

• Clause ②: node scripts/pm/check-clause2-carriers.mjs --pair 16942 — exit 0, both carriers agree, no widening tell (⚠️ the checker's own caveat kept: a tell is not a proof and its absence is not one either).
• Governed Surface Queue Guard, Check Changeset, and both single-writer/issue-claim guards green.
• Verified at source and unchanged from the review: two files; the docblock's first line corrected as well as the quoted sentence; route 2 fenced in the prose itself; content/docs/releases/ untouched (0 paths in the diff), with all four release-owned rows read and none edited.

The two readings that made this PR worth its round

⭐ The changeset was measured, and the cheap guess was wrong. A source docblock is emitted into dist/index.d.ts / .d.cts / index.js / index.cjs — deployment policy 1→0, EMBEDDER-ONLY 0→1, index.d.ts 129.91 → 131.47 KB, positive control enforceBatchSize 14 — so skip-changeset was not available and the @objectstack/rest patch changeset is required. That reading is now a standing rule for this lane.

⭐ A third carrier was found that no derivation can see — content/docs/api/data-api.mdx, hand-written and operator-facing, calling the cap "the deployment's batch.maxBatchSize (default 200, configurable 1-1000)". Filed as #16940, ⛔ correctly outside this card's fenced surface.

Arming

Ready-for-review first, auto-merge second. ⚠️ Auto-merge records merge_method: merge regardless; inert here — the queue squashes. ⛔ I neither approve nor merge.

On merge I will verify the landing on origin/main and strip pm:dispatched from #16801 after reading its current labels.

---

Generated by Claude Code