[finding] content/docs/releases/v17/17-0.mdx:1734 still tells bulk callers the batch cap is "raisable to 1000" — the last live carrier of the falsified claim, on the one tree every delivering agent is prohibited from editing #18854

⛔ 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 35, as the residue of the #18740 flight (PR #18852). ⛔ Not claiming.

⚠️ This card exists because the work cannot be done by the actor who found it. That is its whole point — see 〈为什么这不是一次搭车〉.

The line

content/docs/releases/v17/17-0.mdx:1734, read on origin/main @ 631dcbd4b at 2026-09-18T00:30Z, verbatim:

- **Bulk callers:** stay under `batch.maxBatchSize` (default 200, raisable to
  1000) or chunk

Why it is the same claim, and why it is the LAST one

The claim that a reader of a published surface can raise batch.maxBatchSize was ruled false on 2026-09-07 (director seat, summon #17, decision batch #2, maintainer verbatim 「同意」). Carriers found and corrected under that ruling:

⭐ It is the strongest remaining form: it does not merely state the claim, it instructs — «raisable to 1000» is an action addressed to Bulk callers, and no shipped boot path can perform it. On a CLI-started deployment the value is whatever .default() says and nothing moves it.

⛔ 为什么这不是一次搭车 —— 这是本卡最该被记住的部分

PR #18852 corrected eight of this claim's nine remaining sites and stopped at the ninth. The delivering agent's own words, quoted from its hand-back:

My standing operating rules carry an UNCONDITIONAL prohibition on editing content/docs/releases/ and state that such a clause outranks the dispatch word; AGENTS.md only PERMITS a docs-only PR there, it does not require one, so a permission does not lift a prohibition. I did not silently pick a side.

⇒ ⭐ 「被允许」与「被要求」不是一回事,而一条允许不能解除另一条禁止。 The agent was offered an option in which the dispatching seat simply released the prohibition for this one card, and refused it, in its own words: 「releasing a standing unconditional clause by dispatch word is the precedent I should not help set, and it is the whole reason I stopped rather than quietly complying.」

⚠️ The dispatching seat was wrong, and says so here. The dispatch listed this ninth site as in scope. ⛔ It should not have: the PM seat's own standing rules also forbid it from modifying content/docs/releases/**, so the dispatch asked a delivering agent to do a thing its dispatcher is itself barred from. A dispatch cannot widen a prohibition it does not own. That is this seat's error, recorded here rather than only in its own ledger.

⇒ Nor does the PM seat route around it by doing the edit itself: it does not write code, and the same prohibition binds it. This card is the route AGENTS.md names first for that tree — its Documentation Guardrails row offers «a dedicated docs-only PR or an issue», and an issue is what an actor without the standing can legitimately produce.

What the remedy is, already written and verified

⛔ Do not invent a sixth wording. The vocabulary has landed five times; PR #18852's erratum shape is the nearest precedent and it copies ec5db7b (packages/rest/CHANGELOG.md:351,该行于 2026-09-18T00:30Z 在 631dcbd4b 上读得). The facts: the cap is embedder policy — 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 is a schema bound, ⛔ not a knob any published surface reaches.

⚠️ Whoever takes this decides one thing the CHANGELOG work already faced: a release page records what a version shipped, so the repair must stop the sentence instructing without rewriting history into something that was never said. ⭐ PR #18852 settled that for the CHANGELOG entries by correcting the words in place and closing the entry with a dated erratum quoting both falsified wordings verbatim — a shape this repo had already used (#18569 / #17849). ⛔ This card does not rule that the same shape fits a release page; it only says the question is already answered next door.

⛔ What is NOT claimed

• ⛔ Not that the runtime is wrong. The cap is enforced; only the statement about who may raise it is false.
• ⛔ Not that PR docs(changelog): correct the falsified batch-cap claim in the published 17.0.0 and 17.0.0-rc.1 entries #18852 is incomplete work. It is complete for what its actor was permitted to touch, and it withdrew its own closing keyword rather than let [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 auto-close with this carrier live.
• ⛔ Not measured: whether any carrier exists outside the nine enumerated above. The sweeps behind them covered packages/**, content/**, examples/**, docs/, and root *.md; anything else is unread, not absent.

Duplicate check — method stated

One targeted MCP search_issues call over this repository (repo-scoped REST /search/* answers 403 for this seat, so the channel is declared rather than assumed).

• No card names content/docs/releases/v17/17-0.mdx.
• Live positive control, same call: [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, [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] 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, [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 and [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 — five prior carriers of this exact claim — all had to hit, and all did ⇒ the zero is a reading, not a dead index.

Dedupe words: 17-0.mdx · raisable to 1000 · Bulk callers · batch.maxBatchSize · release page · embedder policy

Refs

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

os-decision-facets

四棱分析(落卡即带;本块由立卡席位在本卡转入决策箱后同轮补齐,⛔ 未留待维护者到场)

① 项目长远合理性:本卡不新增任何特例或契约 —— 它请求的是一次执行者指派。真正长远的那一面是反面的:若靠「派发令临时解除一条常设禁止」来通行,禁止条款就退化成建议,而下一次没人会知道它还算不算数。⇒ 指派一个本来就有站位的执行者,缩小特例;临时豁免,扩大特例。

② 实际业务拉动:今天就有人撞上 —— content/docs/releases/v17/17-0.mdx:1734 是发布页,它告诉 bulk callers 把上限「raisable to 1000」,而没有任何已发布路径能执行该动作。同一条假声明的另外八处已于 18cc3b1df 修完,这是最后一处,且是唯一仍在指示读者行动的一处。

③ 防 AI 犯错:当前形状是响亮拒绝而非静默容忍 —— 交付 agent 撞上禁止会停手并回报(本轮实测:它停了,并拒绝了「派发席为这一张卡解除禁止」的出口)。⇒ 保持这个形状;任何「按卡解除」的通道都会把响亮拒绝换成一次静默通过,而错的那次不会有人看见。

④ 创业阶段不扩散:本卡不要求新增席位、新增标签或新增流程。它要的是对既有席位集合的一次指派。⛔ 若答案是「没有这样的席位」,那正确的处置是 remove(接受它停着,见选项 C),⛔ 不是为它造一个新席位。

Prior rulings read: content,docs,releases,17-0.mdx,17-0,tells,bulk,callers,batch,raisable,last,live (+8 more) → 55 hits; ADR-0127 D6, ADR-0086 D6, ADR-0110 D4, ADR-0119 D3, ADR-0131 D7, ADR-0029 D1, ADR-0029 D8, ADR-0029 D9.9, ADR-0044 D5

⚠️ 那 9 条 ADR 决定本席逐条读过标题,⛔ 没有逐条读全文,并据标题判定无一触及本卡的问题(它们分别关于授权缓存失效、授权元数据边界、action 身份、多写原子性、组织归属、内核对象归属、流程回退分支)—— 词面命中来自 content/docs/live/tree 这类宽词。⇒ 本卡的问题没有既有裁决答过,因此它是决定而非执行。⚠️ 这一步是按标题判的,是本块最薄的一环,⛔ 若谁读全文后发现相反,以全文为准。

选项 × 真实代价

推荐 A。只看①选 A;②③④ 是否翻转:否 —— ② 支持尽快(唯一仍在指示读者的载体)、③ 反对 B(它把响亮拒绝换成静默通过)、④ 反对为此造新席位但不反对指派既有席位。

回退 C,⛔ 不是 B。

置信缺口(逐条,⛔ 不含糊):

• ⛔ 本席未测量本 fleet 里是否存在一个不带该禁止的席位。A 是否可执行,取决于这个本席看不到的事实。
• ⛔ 本席未读 docs/releases-maintenance.md 全文,因而不知道 AGENTS.md:685 说的「centrally at release time」在实践中多久发生一次 ⇒ C 的「时长不可预测」是如实的不知道,不是一次估计。
• ⚠️ 上面那条 ADR 判定是按标题做的。

裁后执行

• 若 A:点名执行者即可,修法已经写好并验过(见本卡〈What the remedy is〉),⛔ 不需要新的分析。
• 若 C:本卡转 pm:on-hold,并欠一条机器可读的 Restart-when:(指向那次集中发版),⛔ 否则它会变成一张没有出口的停牌卡。

Generated by Claude Code