[finding] packages/spec/src/api/batch.zod.ts:128 calls the batch-size cap "DEPLOYMENT policy" — the FIFTH carrier of the claim corrected four times, in live source, inside the package whose own header states the contract it contradicts #18739

⛔ 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.

⚠️ Pointer, not a routing decision: SKILL.md 〈座位职责〉 says 「新 packages/spec 工作恒归 spec 座位」. ⇒ this very likely belongs to domain:spec, but the label is triage's to write.

The line

packages/spec/src/api/batch.zod.ts:128, read on origin/main @ 080688b56 at 2026-09-17T17:44Z, verbatim:

128:  // [#3939] No `.max()` here: the batch-size cap is DEPLOYMENT policy

The full comment continues (RestServerConfig.batch.maxBatchSize, 1..1000, default 200).

Why it is the same defect, and why this one is worse than the four before it

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 「同意」). Four carriers have been corrected under that ruling:

1. packages/spec — [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 / PR docs(spec): RestServerConfig's crud / metadata / batch keys are embedder-only, and the schema now says so #16775
2. packages/rest — [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, in the enforceBatchSize docblock
3. content/docs/api/data-api.mdx — [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
4. content/docs/protocol/kernel/http-protocol.mdx — [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 / PR docs(protocol): the batch cap is embedder-only, not “configurable via maxBatchSize” — the fourth carrier, plus the fifth-carrier enumeration #18737 (in flight)

⭐ This is the fifth, and it carries the exact phrase #16801 struck one package over: the batch-size cap is DEPLOYMENT policy. #16801 removed that wording from packages/rest/src/rest-server.ts#enforceBatchSize; it survived here.

⭐ And it sits in packages/spec — the package whose own WHO CAN WRITE THIS CONFIG (#15543) header, in packages/spec/src/api/rest-server.zod.ts, states the contract this line contradicts:

⇒ On a CLI-started deployment every OTHER key here is EMBEDDER-ONLY: the whole of crud, metadata and batch, and the rest of api. Its value is whatever the .default() below says, and no flag, config file or CLI option moves it.

⇒ Two declarations about the same key, in one package, saying opposite things. ⛔ This card does not assert which one the runtime follows — that is not measured here, and the ruling already settled which one is TRUE.

Why four sweeps missed it — the durable half

⚠️ Two probe populations were run over this claim, and this line is in neither:

• the deployment policy probe (recorded in [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's FOLLOW-UPS as E2) was scoped to the single file rest-server.zod.ts;
• the maxBatchSize censuses ([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, [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) were scoped to content/.

batch.zod.ts is a source file outside content/ and outside that one-file probe. ⇒ It could not appear in either result, and its absence read as a clean zero in both.

⭐ That is the same shape #17183's card recorded one level down — a probe written over one spelling of a claim is not a probe over the claim — but this instance is about population scope rather than spelling: a probe whose population is narrower than the claim under-counts by exactly the members outside it, and reports the shortfall as a zero.

Measurement provenance and control

Found by the dev on the #17183 flight, then re-measured independently by this seat on origin/main @ 080688b56 at 2026-09-17T17:44Z before filing — ⛔ not taken on the report's narrative:

grep -n "DEPLOYMENT policy" packages/spec/src/api/batch.zod.ts     ⇒ 1 hit, :128
CONTROL, same reading:  grep -rl maxBatchSize (tree-wide, excl. node_modules/dist) ⇒ 38 files
                        ⇒ the probe reaches the tree; the hit is a reading, not a dead index
NOT a carrier, adjudicated:  examples/** and root *.md ⇒ 0 hits under every spelling tried

⛔ Why it was not repaired on the PR that found it

PR #18737's dispatch fences the file surface to content/docs/protocol/kernel/http-protocol.mdx, and packages/spec opens the eight-artifact regeneration family — a new verification surface, so the in-place-repair exemption does not hold. ⇒ Reported rather than ridden, which is the residue rule working.

⛔ What this card does NOT claim

• ⛔ Not that the runtime behaviour is wrong. The cap is enforced; only the statement about who may configure it is false.
• ⛔ Not that a sixth carrier does not exist. The enumeration behind this card covered source under packages/**, examples/**, content/, and root *.md; anything outside that is unread, not absent.
• ⛔ Not a re-opening of the 2026-09-07 ruling.

Suggested shape

⛔ Do not invent a sixth wording. Copy the vocabulary that has now landed four times: the cap is embedder-only, written only by a host that constructs the RestServerConfig itself, never by os serve or the dev plugin, so a CLI-started deployment always gets the default of 200.

⚠️ The 1..1000 range in that comment is the part that most directly misleads — it names a span no published surface can reach. Whoever fixes this should decide explicitly whether the range survives as a schema fact or goes with the claim.

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 packages/spec/src/api/batch.zod.ts.
• 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 this file is a reading, not a dead index.
• ⚠️ 批量写路由的 "max 200" 一处都没在拦 —— 而且同一个端点有两份互相矛盾的 Zod #3939 is the issue the [#3939] marker in that very comment cites; it is closed, and it is the origin of the line rather than a card for it.

Dedupe words for the next searcher: batch.zod.ts · DEPLOYMENT policy · maxBatchSize · embedder-only · BatchUpdateRequestSchema

Refs

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

Generated by Claude Code