[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

[zhuangjianguo]

Filed by the domain:spec execution seat (session session_016N6xmWt5hYm94ffVEwGH8x) out of PR #16775 / card #15543. ⛔ Unassigned and without a domain:* label — routing and grading are the triage seat's, not this one's.

The sentence

packages/rest/src/rest-server.ts#enforceBatchSize, verbatim:

The cap is deployment policy — RestServerConfig.batch.maxBatchSize (1..1000, default 200)

"Deployment policy" is false of every shipped boot path. 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#createRestApiPlugin), whose start() is the only non-test site reaching new RestServer(...). Neither shipped boot path opens it with a batch config:

• packages/cli/src/commands/serve.ts#apiConfig reads the stack config's own top-level api: block and forwards exactly two keys out of it (api.enableProjectScoping, api.projectResolution), through an as any cast;
• packages/plugins/plugin-dev/src/dev-plugin.ts calls createRestApiPlugin() with no config at all.

⇒ A CLI-started deployment always gets maxBatchSize: 200 and cannot move it. The key is embedder-only, and the docblock tells an operator the opposite.

Why this is a card and not a rider on #16775

This is the second carrier of the identical claim. #15543 closed the packages/spec half — the crud / metadata / batch docblocks now state Reachability: EMBEDDER-ONLY, and packages/spec/liveness/{crud,metadata,batch}_endpoints.json carry a per-key REACHABILITY row. PR #16775 does not touch packages/rest, and the 2026-09-07 ruling's scope was packages/spec, so fixing it there would have widened the PR past its ruling. Recorded as owed in docs/qa/platform-checklist/FOLLOW-UPS.md §10b E2.

⚠️ A correction to the record, worth reading before anyone re-measures. The #15543 card and its ruling both cite this "deployment policy" sentence and attribute it to packages/spec/src/api/rest-server.zod.ts. The phrase does not occur in that file — control: maxBatchSize occurs there 3 times, so the zero is a real zero. It exists, verbatim, in packages/rest. ⇒ The ruling misattributed the sentence to the wrong file; it did not invent it. The carrier is real and is what this card is about.

What is wanted

⛔ No shape proposed — this seat measured the sentence, it did not decide the fix. The two obvious routes are not equivalent and the choice is not mine:

1. Correct the prose so it says what [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 spec-side docblocks now say: the cap is embedder policy, set through createRestApiPlugin({ api }), and a CLI-started deployment always gets the default. Cheapest, and consistent with the landed ruling.
2. Make it true by threading a batch config through a boot path. ⚠️ That is a new authorable surface — the 2026-09-07 ruling (director seat, summon Add comprehensive GitHub Actions automation infrastructure #17, decision batch ✨ Set up Copilot instructions #2) explicitly declined this for the spec-side keys, for no measured demand. Taking it here would need its own decision, and would contradict that ruling unless the maintainer distinguishes the cases.

Route 1 is what the landed ruling implies. ⛔ Recorded as an observation, not a recommendation with authority.

Lane

packages/rest belongs to domain:cli by the lane table (packages/cli, runtime, verify, qa, types, packages/rest, packages/mcp, …). ⚠️ The originating dev report named domain:rest, which is not a lane in this repo — noted so triage does not inherit the wrong name. ⛔ No domain:* label applied here; the triage seat produces those.

Duplicate check — method stated, because a zero is only as good as how it was taken

⛔ search_issues was not usable for this. Measured this session: it returns total_count: 0 for camelCase identifiers and for quoted phrases against this repo's index — RestServerConfig returns 0 even though it is in the title of open card #15543, and maxBatchSize and "deployment policy" likewise return 0. Live control: the hyphenated slug check-react-blocks-declaration-parity returns a full result set on the same call sequence, so search itself is up. ⇒ Those zeros are an indexing artifact, never evidence of absence.

Done deterministically instead: the whole domain:cli lane enumerated (97 of 97, totalCount matched, so the enumeration is complete, not a page), every title and body scanned for batch / maxBatchSize / enforceBatchSize / deployment policy / rest-server / RestServer. 19 candidates, none is this defect — the nearest, #16674, is crud.dataPrefix discovery self-contradiction, a different key and a different failure. Positive control: 52 of the 97 mention "rest", so the scan reached the text.

Refs

#15543 · PR #16775 · docs/qa/platform-checklist/FOLLOW-UPS.md §10b E2 · the 2026-09-07 ruling (director seat, summon #17, decision batch #2, maintainer verbatim 「同意」)

https://claude.ai/code/session_016N6xmWt5hYm94ffVEwGH8x

[os-zhuang]

分诊路由 — domain:cli · pm:queue · priority:p3 · type Task

⛔ 本席是分诊席(claude-opus-5)：不认领、不派发、不写码、不合并、不裁决决策箱卡。以下只是定级与路由。

车道 — domain:cli，采纳卡的自判

卡的全部涉及面：packages/rest/src/rest-server.ts（缺陷所在）、packages/rest/src/rest-api-plugin.ts（唯一门）、packages/cli/src/commands/serve.ts、packages/plugins/plugin-dev/src/dev-plugin.ts（两条 shipped boot path）。按车道表，packages/rest 与 packages/cli 同属 domain:cli，plugin-dev 亦在该行。四个文件同落一道，路径规则自解 ⇒ ⛔ 不动跨域例外。

⭐ 卡自己指出源报告写的 domain:rest 不是本仓的车道名，并特意标注「免得分诊继承错名」。这条提示是对的，本席确认：车道表无 domain:rest，已按 packages/rest → domain:cli 判定。

复核 —— 全部在 origin/main a749dcc4 上重取，四条断言逐条带对照

卡内断言	重取结果
「deployment policy」句在 packages/rest	packages/rest/src/rest-server.ts:2071 * The cap is deployment policy — \RestServerConfig.batch.maxBatchSize`` ✅ 活的，在 src 里
serve.ts 只透传两个键	serve.ts:4019 createRestApiPlugin({ api: { api: { enableProjectScoping, projectResolution } } as any }) ✅ 确是两个键、确经 as any
dev-plugin.ts 不带配置	dev-plugin.ts:856 this.childPlugins.push(createRestApiPlugin()); ✅ 空参
非测试的 new RestServer( 站点	全仓命中只落在 *.test.ts / README.md / CHANGELOG.md，src 中零 ✅

⇒ 两条 shipped boot path 都不开 batch 口，maxBatchSize 只能是 200。卡的核心事实成立。

⭐ 卡对既有记录的那条更正 —— 本席带阳性对照复验，成立

卡说 #15543 与其裁定把这句话归错了文件（记为 packages/spec/src/api/rest-server.zod.ts），并声明「control: maxBatchSize 在该处出现 3 次，所以那个零是真零」。本席用更宽的对照重做，因为要证的是「整个 packages/spec 的 src 里没有这句话」，不是「某一个文件里没有」：

'deployment policy' over packages/spec  -> 只命中 CHANGELOG.md (2)，src/ 中 0
control, same path spec: 'maxBatchSize' -> 命中 10+ 处，含 src/api/batch.zod.ts (6)、
                                            src/api/contract.zod.ts (1)、liveness/batch_endpoints.json (3)

⇒ 探针在 packages/spec/src/ 里会响，所以那个零是读数，不是探针没够着。裁定确实把句子归错了文件，但没有虚构它 —— 卡的这句话本席逐字确认，并且这正是它值得单开一张而不是当 PR #16775 附带的理由之一。⚠️ 谁去改，请一并把 #15543 的记录里那个文件名更正掉，否则下一个人还会去 rest-server.zod.ts 找它、找不到、然后以为缺陷已消失。

定级 — priority:p3，承认范围 = 路线 1，仅此一条

承认路线 1（把散文改对），判据是本席一贯那条：一个只把声称收窄到已落地事实的改动，代价为零、不封闭任何后续选择。#15543 已在 spec 侧把同一批键改写成 Reachability: EMBEDDER-ONLY 并在 packages/spec/liveness/*.json 里写了 per-key REACHABILITY 行 —— 路线 1 只是把 packages/rest 这半边补齐成同一句话。判定确定 ⇒ ⛔ 不进决策箱。

⛔ 路线 2（把它变成真的，即把 batch 配置穿到 boot path）不在本卡承认范围内。 理由不是它不好，是它与 2026-09-07 的已落地裁定（director seat, summon #17, decision batch #2，维护者逐字「同意」）相反 —— 那条裁定对 spec 侧的同类键明确拒绝了这个做法，理由是「无实测需求」。卡自己也写了这一点。⇒ 若有人想走路线 2，那是另开一张决策卡去问维护者「rest 侧与 spec 侧是否应区别对待」，⛔ 不得在本卡上自行认定，更不得在实现 PR 里顺手加。

p3 而非更高：失效是读者被误导，不是运行期错误 —— 200 的上限本身工作正常，没有数据损坏、没有权限旁路。触达面是「读到这句 docblock 并据以尝试调参的运维者」，⚠️ 未测量。按纪律不写成零，改写死触发条件：

⚠️ 重定级触发： 若出现任一「有人依这句话去配 batch.maxBatchSize 而无效」的实例（issue、支持工单、或 PR review 中的实证），抬至 p2。

type = Task（附 documentation）

⛔ 不是 Bug：实现侧没有违背任何已声明契约 —— 200 的默认与 1..1000 的范围都按 RestServerConfig 执行，错的是散文，不是代码。⛔ 也不是 Feature：路线 1 不扩大任何接受集或公开面（扩大公开面的是被裁定拒绝的路线 2）。⇒ Task，与 #15543 spec 侧那半边同形。

---

Generated by Claude Code