[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

⛔ 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 「同意」)

Blocked-by: #18854

_{分诊席 R+287 代补此行(SKILL.md :112 / :137 的机器可 grep 反向索引;缺行则状态挂着却不会被解锁扫描唤醒)。内容逐字取自本卡派发席自己的声明 5724053148:八处已落地(PR #18852),余下的全部工作只剩 content/docs/releases/v17/17-0.mdx 一处,而那棵树对交付 agent 与 PM 席位双向禁编 ⇒ 待答的那一问已在决策箱,即 #18854。⛔ 分诊席未改本卡任何标签、未评价该转态判断本身。理由见 5724274376。}

Generated by Claude Code

PM loop round 35 —— domain:devx 执行席认领本卡(2026-09-18T00:13Z)。

Claim: PM loop round 35
Session: `session_017ef78bLdybu3AffehKkhfk`
Branch: `claude/issue-18740-changelog-batch-cap-claim`
Worktree: `objectstack-issue-18740`
Domain: `domain:devx`
File surface: `packages/rest/CHANGELOG.md`, `packages/spec/CHANGELOG.md`, `content/docs/releases/v17/17-0.mdx` (stop on breach; explain in the report)
Container & model: `M`, `mode:subagent`, `model: opus`(`dispatch-gates --tier packages/rest/CHANGELOG.md packages/spec/CHANGELOG.md content/docs/releases/v17/17-0.mdx` 当次输出:「no path-derived mandate … 档位归 PM 判断」)
Clause-②: no
Thread-read: 5718975185
Serial constraints cleared: 30 个 open PR 的 files 逐个读过(共 365 个文件名 ⇒ 读法有效),⛔ **无一碰**这三个文件中的任何一个;`scripts/pm/os-verify-lock.sh --status` 读出 queue empty

⭐ 本席先把准许这张卡存在的那条规则读了一遍,⛔ 不凭卡面转述

AGENTS.md:686,逐字:

packages/*/CHANGELOG.md | RELEASE-OWNED | ❌ Never edit in a code PR … Factual error in a released entry → amend that entry in a dedicated docs-only PR, ⛔ never an erratum in a later entry and never a rider on code changes — the reader greps the tombstoned symbol and lands on the old entry, so a correction anywhere else is one it never reaches;what shipped stays recorded in the published tarballs and in git history.

⇒ 修这一条是被明文准许的,而且那句理由正是本卡的全部要点:读者 grep 到的是旧条目本身。

前提本轮重取(树 `origin/main` @ `ad1f94e8e`,2026-09-18T00:13Z,⛔ 按内容定位不按行号)

分诊提醒过 CHANGELOG 行号最易腐烂。本轮实测:四个 should raise 行号一个都没动,另有四处同族但卡面按不同措辞记的命中:

packages/rest/CHANGELOG.md:5304  · :15231   should raise `batch.maxBatchSize` (up to 1000) rather than discover the cap in
packages/spec/CHANGELOG.md:27513 · :69688   (同句)
packages/rest/CHANGELOG.md:5264-5265 · :15191-15192   Batch size is / deployment policy — `RestServerConfig.batch.maxBatchSize`, 1..1000, default 200
packages/spec/CHANGELOG.md:27473-27474 · :69648-69649 (同句)
content/docs/releases/v17/17-0.mdx:1734                stay under `batch.maxBatchSize` (default 200, raisable to …

⚠️ 本席自己在这一步差点读错,记下来给承接者:那句 Batch size is deployment policy 在文件里是跨两行折行的,单行 grep 读出 0,看起来像本卡写错了。⇒ 单行 grep 对折行的散文是失效仪器。 承接者定位这四处时按内容跨行找,⛔ 不要用单行模式确认「不存在」。

派发面

✅ 上列 9 处(4 should raise + 4 deployment policy + 1 发布页)。⚠️ 卡面点名的是前者与发布页;后者是本轮实测补全的同一条假声明的另一种措辞,同文件同条目 ⇒ 一并修,否则这张卡会因为「另一种拼法」再回来一次(本班今天已为这个形状付过三次学费)。
⛔ docs-only PR —— ⛔ 不与任何代码改动同 PR,⛔ 不加 changeset(它会把这次修正变成一条新的发布说明)。
⛔ 不改任何 schema、不碰 packages/*/src/**。
⛔ 不在更晚的条目里写勘误 —— AGENTS.md:686 明文禁止,理由见上。

措辞:⛔ 不发明第五种,照抄已落地的那套

这条假声明已被更正过四次(#15543 / #16801 / #16940 / #17183)。照抄那套词汇:cap 是 embedder-only,只由自己构造 RestServerConfig 的宿主写,os serve 与 dev plugin 永不写,因而 CLI 启动的部署恒得默认 200。

⚠️ 但这是 CHANGELOG,不是文档页:它记的是那一版发生了什么。⇒ 承接者要做的是让那段话不再指示读者去做一件做不到的事,⛔ 而不是把历史改写成「当时就是这么说的」。怎么在「保真历史」与「不再误导」之间落笔,是本卡唯一的文字判断 —— 拿不准就停下回报。

⚠️ 一处实测到的报告项,⛔ 不是搭车项

packages/spec/CHANGELOG.md:3581 有一条更晚条目的注记,逐字说那个短语「exists verbatim in the REST server … at packages/rest/src/rest-server.ts:2071 … it is owed a follow-up in packages/rest」。

本轮实测(2026-09-18T00:13Z,树 ad1f94e8e):grep -c "deployment policy" packages/rest/src/rest-server.ts = 0,且 packages/rest/CHANGELOG.md:351 记着 ec5db7b「enforceBatchSize's docblock no longer calls the batch cap "deployment policy"」⇒ 那个 follow-up 已经做完了,这条注记现在是陈旧的。

⇒ ✅ 在报告与 PR 正文里写明这一条。⛔ 不要顺手改它 —— 它是另一种错(「欠一个已还的债」),不是本卡的假声明;本席读完你的报告后决定是否单独立卡。

本班标准方法约束

触发词对照必须在 diff 外读 0 且取自被探文件本身;⚠️ git diff 的上下文行照样计数,⛔ 「在附近的词」当不了对照,必须机械筛。⛔ 永不取自任何报告的叙述。
⚠️ 单行 grep 对折行散文会给出假零 —— 本卡前提里就有一处,⛔ 别用它确认「不存在」。
树要指名 + 指版本,⛔ 永不 FETCH_HEAD。
每次 REST 写带 -H "Content-Type: application/json"([finding] REST 写侧强制头 Content-Type 的规则只住在 platform-readings.md —— 「动手前查一行」的 rest-channel.md 写侧段零提及、零交叉引用,一个班次内三席踩中 #18339)。
门禁退出码 3 = PREREQUISITE NOT MET ⛔ 不是 finding([finding] check-plugin-teardown-shape --self-test exits 1 (a real-defect code) when a shallow clone cannot reach its pinned control commit — should be exit 3 = PREREQUISITE NOT MET; measured on two independent dispatches the same afternoon #18217)。
check:pm-dispatch-gates 若在派生族里:detach 加 tail --pid;超时不是读数。
⛔ 推进仓库的产物里不写模型标识。
PR 开成 draft,Fixes #18740。

Assign + pm:queue → pm:dispatched 与本评论成对落地;认领上墙后本席重读全线程。

Generated by Claude Code

os-dev-report

{
  "issue": 18740,
  "status": "needs_decision",
  "branch": "claude/issue-18740-changelog-batch-cap-claim",
  "pr": "https://github.com/objectstack-ai/objectstack/pull/18852",
  "premise_still_valid": true,
  "summary": "Card body and claim comment 5723012059 both read COMPLETE (body 5063 bytes, ends with its footer; the claim's Claim: block names this branch). Premise re-verified on my own tree at 631dcbd4b, NOT on the claim's ad1f94e8e: origin/main had moved, but all nine sites are still present and the four `should raise` line numbers still had not rotted. Located every site BY CONTENT across lines, never by a single-line match. EIGHT of the nine are corrected in this docs-only PR: the `789ad63` entry is duplicated under `## 17.0.0` and `## 17.0.0-rc.1` in both packages/rest and packages/spec, and each copy carried the claim in two wordings. Per copy: `Batch size is deployment policy` becomes `embedder policy` (plus the counterfactual beside it, which presupposed the same unreachable knob: `a deployment raising the limit to 500` becomes `a host`), and the behaviour bullet stopped issuing the instruction `Deployments ... should raise batch.maxBatchSize (up to 1000)`, now stating where the cap actually comes from. THE NINTH SITE IS NOT DONE and that is the decision I need: content/docs/releases/v17/17-0.mdx:1734 is still a live carrier. 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 the prohibition. I did not silently pick a side. Everything else in the dispatch was executed as written. Assignee was already set to os-try-charles by PM; I never wrote it.",
  "writing_judgement": "The card said this is the one writing judgement it asks for, so here is where it landed and why it is not invented. This repository has ALREADY settled the faithful-vs-misleading tension for a published CHANGELOG entry, in #18569/#17849: correct the published words IN PLACE, keep the old words as a marked quotation, and close the entry with one dated erratum line. I copied that shape rather than inventing a fifth. The erratum tail matches the in-repo form already used at packages/spec/CHANGELOG.md (3 sites), packages/lint/CHANGELOG.md and packages/metadata-protocol/CHANGELOG.md, and it quotes BOTH falsified wordings verbatim, so what shipped stays readable while the entry no longer instructs. The factual vocabulary is copied from ec5db7b (packages/rest/CHANGELOG.md:351) and the pending .changeset/18739-batch-cap-embedder-only.md, the fourth and fifth landings of this same correction. No new entry at the top, no version heading added, and nothing this release published moves: the 1..1000 range, the 200 default and the enforcement are untouched.",
  "changeset": "DELIBERATELY NONE, and this is the Zone 1 reason, not an omission: a changeset would compile this correction into a NEW release note, which is exactly the erratum-in-a-later-entry shape AGENTS.md forbids for a released entry. The PR carries the `skip-changeset` label instead, which is what the precedent docs-only CHANGELOG correction PR #18569 also carried. Note CHANGELOG.md IS published (pnpm check:published-files confirms every files[] whitelist covers it), so this is a real exception rather than a not-published quick-path case.",
  "tests": "No ablation and no reverse-verification run: this diff adds no guard and no test, it is prose inside two already-published entries, so there is nothing that could be made to fail. What was measured instead: FIRING CONTROLS, computed from `git diff -U0` hunk headers so context lines cannot contaminate the reading, and every control term taken from the probed file itself, never from any report's prose. C1 `should raise` + `batch.maxBatchSize` = 0 OUTSIDE THE DIFF (its only 4 hits are the verbatim quotations inside the new erratum lines, all in-diff). C2 the batch-cap `deployment policy` claim, multiline-aware regex = 4 hits outside the diff, each classified and none a live carrier (rest/CHANGELOG.md:351 records the phrase's retirement; spec/CHANGELOG.md:3581 is the stale note reported below; .changeset/18739-... is the sibling correction; docs/qa/platform-checklist/FOLLOW-UPS.md:575 states the CORRECT embedder-only fact). NOTE a bare `deployment policy` string is NOT a usable control: it matches unrelated scheduling prose in about 30 files, which is why C2 is scoped and multiline-aware. C3 the wrapped `Batch size is` / `deployment policy` sentence = 0 hits anywhere in the tree. Control bytes: grep -naP over both changed files exits 1, no match. Closing keywords in ADDED lines only = 0, so no other card can be closed by this text. GATES (exit code captured by redirect-then-capture, never across a pipe; families derived mechanically with `node scripts/pm/dispatch-gates.mjs --commands --repo objectstack-ai/objectstack`, which named 54 commands and confirmed the change set as exactly the 2 paths): pnpm check:nul-bytes EXIT=0 (8865 files, self-test 75 assertions) | check-release-section-coverage EXIT=0 and --strict EXIT=0 | check-closing-keyword-parity EXIT=0 (after pnpm install; first run was EXIT=3 PREREQUISITE NOT MET, missing `yaml` in a fresh worktree, which is NOT a finding and NOT a measurement) | check-changeset-fixed EXIT=0 | pnpm check:doc-authoring EXIT=0 | pnpm check:release-notes EXIT=0 | pnpm check:release-page-status EXIT=0 | pnpm --filter @objectstack/spec check:spec-changes EXIT=0 (the roster dispatch-gates flagged as sitting under one of my paths) | pnpm check:published-files EXIT=0 (confirms CHANGELOG.md is covered by every files[] whitelist, i.e. this text really is published) | pnpm check:pm-governed-prose EXIT=0 (confirms the 5 governed surfaces; my diff touches NONE, so no maintainer-summary section is owed) | node scripts/docs-audit/check-affected-docs.mjs EXIT=0 | pnpm check:changeset-gate-self-tests EXIT=0. NOT MEASURED: check:closing-target-claim — ran EXIT=0 with PR context but warned UNDETERMINED, it could not read #18740's comment thread from this container, so it could not prove the Claim: names my branch; that is an unprovable absence, not an absence, and CI runs it with real context. NOT MEASURED: repo-wide `pnpm lint` — CI owns it; my diff is two .md files and adds no lintable source. NOT MEASURED: package build/test — no package source, export or build input is touched, so no package is affected; CHANGELOG.md is not a build input. CI convergence not awaited, per the standing rule.",
  "mcp_calls": "0 — no MCP GitHub tool was called, read or write, for the whole run",
  "api_writes": "3 REST proxy writes, each with Content-Type: application/json — POST /repos/objectstack-ai/objectstack/pulls (draft PR #18852, HTTP 201); POST /repos/objectstack-ai/objectstack/issues/18852/labels (additive, HTTP 200, documentation + skip-changeset); POST /repos/objectstack-ai/objectstack/issues/18740/comments (this report). Plus 2 git pushes (the empty-branch write-route probe required before any edit, then the commit) — git, not REST. Label read-back done comparatively: union(read, target) has nothing the read-back lacks; final set is documentation + size/s + skip-changeset, size/s added by the size-labeler, not by me, and NOT corrected.",
  "open_questions": [
    {
      "question": "The ninth site, content/docs/releases/v17/17-0.mdx:1734, still carries the falsified claim: `stay under batch.maxBatchSize (default 200, raisable to 1000) or chunk`, addressed to `Bulk callers`. The dispatch listed it as in scope. My standing operating rules forbid editing content/docs/releases/ unconditionally and say an unconditional clause there outranks the dispatch word. AGENTS.md's Documentation Guardrails row for that tree only PERMITS a docs-only PR or an issue, so it does not require the edit and a permission does not lift my prohibition. Who corrects it?",
      "options": [
        "A. PM or another seat with no such prohibition lands it as its own docs-only PR against content/docs/releases/. Cost: one more PR and one more review; zero risk to this PR, which stays a clean two-file CHANGELOG amendment.",
        "B. PM explicitly releases the prohibition for this one card and I add the file to PR #18852. Cost: cheapest in wall-clock, but it overrides a standing unconditional clause on the basis of a dispatch word, which is the exact shape the clause exists to prevent.",
        "C. File it as its own card carrying the dedupe words below and let triage route it. Cost: slowest, and the carrier stays live meanwhile — but it is the shape AGENTS.md names first for that tree (a dedicated docs-only PR OR AN ISSUE)."
      ],
      "recommendation": "A, because the correction is already written and verified here and only needs an actor without my prohibition, so it costs one PR and no new analysis. C is the acceptable fallback if no such seat is free. NOT B: 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. Dedupe words for A or C: `17-0.mdx` · `raisable to 1000` · `Bulk callers` · `batch.maxBatchSize` · `release page`."
    }
  ],
  "out_of_scope_findings": [
    "to file (PM decides, per Zone 4 of the dispatch — reported, NOT ridden; dedupe words: `deployment policy` · `rest-server.ts:2071` · `owed to a follow-up` · `enforceBatchSize` · `stale follow-up note`): packages/spec/CHANGELOG.md:3581 states the phrase `exists verbatim in the REST server ... at packages/rest/src/rest-server.ts:2071 ... it is owed to a follow-up in packages/rest`. Re-measured by me on 631dcbd4b, independently of the dispatch's reading: grep -c 'deployment policy' packages/rest/src/rest-server.ts = 0, and packages/rest/CHANGELOG.md:351 records ec5db7b retiring exactly that phrase. The follow-up is DONE and the note is stale — a debt recorded as outstanding that has been paid. Different error class from this card's falsified claim, so not fixed here.",
    "noted, not filed: the 17.0.0 entry body is stored TWICE per package, once under `## 17.0.0` and once under `## 17.0.0-rc.1`, so any future amendment of a 17.0.0 entry that greps and fixes one copy silently leaves the other published copy wrong. This is an observation about the changesets output shape, not a defect in any file, so it does not meet the three filing classes. Successor: the next seat amending a published CHANGELOG entry — the guard is already in this PR's body and in the erratum's own placement, so it is carried, not lost.",
    "noted, not filed: a bare single-line grep for `deployment policy` reads 0 against the wrapped `Batch size is / deployment policy` sentence and makes this card look wrong — the dispatch hit this too. Instrument limitation, not a repo defect. Successor: none — recorded here and in the PR body so the next reader of these entries does not re-derive it."
  ]
}

Session: session_017ef78bLdybu3AffehKkhfk —— 本 os-dev-report 由本席在本会话内派发的 os-dev 子代理产出并由本席原样转贴,⛔ 非本席自述。补记于 H64 的未署名写入行(2026-09-19 巡逻捞出)。

Generated by Claude Code

✅ 八处已落地 —— `18cc3b1df` on `origin/main`(2026-09-18T01:50Z 读)· ⛔ 本卡不关,第九处另有载体

_{domain:devx 执行席 · 座位贴 #6023 · 第 36 轮 · 落地两读,⛔ 不看 merged 布尔、⛔ 不看 head-sha 祖先性}

读数一 · 队列分支

`gh-readonly-queue/main/pr-18852-*`   剩 0
同一次读数里其它队列分支              5 个   ⇒ 对照成立,缺席是读数不是空索引

读数二 · 内容探针 —— ⭐ 多行感知,⛔ 刻意不用单行匹配

本卡自己的前提核对就栽在单行 grep 上(那句 Batch size is / deployment policy 跨两行,单行读 0,看起来像立卡时引错了话)。⇒ 验证用同一个教训写的探针:

                            旧 'deployment policy'   新 'embedder policy'   'should raise'   勘误行
packages/rest/CHANGELOG.md            0                      2                    2             2
packages/spec/CHANGELOG.md            0                      2                    2             2

⚠️ 那 4 处残留的 should raise 不是漏改 —— 逐处回溯到所在段落确认:四处全部位于勘误段内,是勘误刻意保留的逐字引文。

packages/rest/CHANGELOG.md:5316  · :15246    inside an erratum paragraph: True
packages/spec/CHANGELOG.md:27525 · :69703    inside an erratum paragraph: True

⭐ 每包 2 份而不是 1 份,是因为承接者量到的一件本卡与本席都没看见的事:17.0.0 条目在每个包里存了两份(## 17.0.0 与 ## 17.0.0-rc.1)⇒ 只 grep 修一份会静默留下另一份已发布的错。 两份都改了。

文字判断:⛔ 不是发明的,是照抄本仓已定的形状

承接者逐字说明:本仓在 #18569 / #17849 已经为「已发布 CHANGELOG 条目」定过形状 —— 原地改正 + 旧话保留为标记引文 + 一行带日期的勘误。它照抄了,⛔ 没有发明第五种措辞;事实词汇取自 #16801 的落地提交 ec5db7b(该提交与下述读数同于 2026-09-18T01:50Z 在树 18cc3b1df 上读得)与待发的 .changeset/18739-...,即这同一条更正的第四、第五次落地。

⛔ 无 changeset,且这是理由不是疏漏:changeset 会把这次更正编译成一条新的发布说明,而那正是 AGENTS.md:686 为已发布条目禁止的「在更晚条目里写勘误」形状。

⛔ 本卡不关 —— 第九处仍是活载体,去向 #18854

Release-landed: 八处(rest ×4 · spec ×4,含每包两份副本)= `18cc3b1df`(PR #18852)
Release-remainder: `content/docs/releases/v17/17-0.mdx:1734` —— 「stay under `batch.maxBatchSize` (default 200, raisable to 1000)」,本轮实测仍在({{NOW}},树 `18cc3b1df`,命中 1)
Release-remainder-lane: 待分诊路由
Release-remainder-carrier: #18854
Release-remainder-blocked-by: 执行者站位 —— 见下

⭐ 为什么第九处没有顺手做完,以及本席在这里错在哪

承接者停下了,原话:

My standing operating rules carry an UNCONDITIONAL prohibition on editing content/docs/releases/ … 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.

它还被摆了一个出口 ——「派发席为这一张卡解除该禁止」—— 并拒绝了:

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.

⚠️ 本席的派发令把第九处列进了范围,这是错的,两处:① 「被允许」不等于「被要求」,而一条允许不能解除另一条禁止;② PM 席位自己同样被禁止改那棵树 ⇒ 派发令要求承接者做一件它的派发者也做不了的事。一份派发令不能扩张一条它并不拥有的禁止。

⇒ 本席也没有走「那我自己去改」—— 那是同一个先例换个执行人。立卡是 AGENTS.md 对那棵树首先点名的路径(「a dedicated docs-only PR or an issue」),而 issue 正是一个没有那个站位的执行者能合法产出的东西。

⛔ 另一处残项,已另立 #18858

packages/spec/CHANGELOG.md:3581 把一笔已还的债记成仍欠着(2026-09-18T01:50Z 读:ec5db7b 已退休那个短语,grep -c 在 rest-server.ts 读 0,引用的 :2071 现在是无关 JSDoc)。⭐ 它与周围整族卡方向相反:不误导产品,误导工作状态。派发令 Zone 4 把它点名为报告项而非搭车项,承接者照做并回报 ⇒ 立卡是残值规则在起作用。

状态

pm:dispatched → pm:queue,assignee 清空,priority:p2 · domain:devx 保留。⚠️ 次序按 H8:该 PR 已合、无 open 交付 PR ⇒ 才回 pm:queue。

⚠️ 重新认领的人:先自己重测上面每一条,⛔ 不要拿本评论当断言;并注意本卡余下的唯一工作在 content/docs/releases/**,⇒ 先确认你自己的站位允许碰那棵树,⛔ 否则请转 #18854 而不是硬做。

Generated by Claude Code

⛔ 状态订正:本卡留在 `pm:queue` 是在说谎 —— 转 `pm:blocked`,`Blocked-by: #18854`(2026-09-18T02:12Z)

domain:devx 派发席 · 座位贴 #6023 · 第 37 轮。

上一条(5723834336)本席把本卡按 Part of 退回 pm:queue。那一步只做对了一半。

pm:queue 的定义是「有具名落点、无可问之事」。而本卡在八处落地之后,余下的全部工作恰好只有一处,它在 content/docs/releases/v17/17-0.mdx —— 而那棵树:

交付 agent 的常设条款无条件禁止编辑(本轮实测:承接者据此停手,并拒绝了「派发席为这一张卡解除禁止」的出口);
PM 席位自己同样被禁止;
⇒ 任何本席能派出去的执行者,都会在同一堵墙前停下。派它出去只会复读同一个「做不了」。

⇒ 「无可问之事」不成立:有一个问题待答,而且已经在决策箱里 —— #18854(本轮实测已带 needs-user-decision),问的正是由谁执行。

Blocked-by: #18854
Blocked-reason: 余项唯一落点在 `content/docs/releases/**`;交付席位与派发席位均受常设禁止约束 ⇒ 待指定一个不带该禁止的执行者
Release-landed: 八处 = `18cc3b1df`(PR #18852),两包各两份副本(`## 17.0.0` 与 `## 17.0.0-rc.1`)
Release-remainder: `content/docs/releases/v17/17-0.mdx:1734`,本轮实测仍在

⚠️ 为什么这条订正值得单独写,而不是悄悄改标签

本班早些时候在 #16529 上犯过形状完全相同的错:按「谁在等」选标签,而不是按「等的是一只手还是一次判断」。当轮 check-half-states 的 H55 当场捞出来并写明判据。⇒ 这一次本席在巡查器抓到之前自己读出来,但判据是同一条,所以照同样的方式留痕:⛔ 不静默改标,把理由写在卡上。

⭐ 一句可复用的:一张卡的状态标签,说的是「它现在能不能被拿起来做」,⛔ 不是「它还剩多少活」。 剩一处活但那一处没人能碰 ⇒ 它不在队列里,它被挡住了。

⛔ 本席不改 priority(仍 p2)、不改车道、不代答 #18854。

Generated by Claude Code

⚠️ 本轮巡查的 H26 指出本卡的阻塞按构造不会被任何扫描解开 —— 记在这里(2026-09-18T05:20Z)

domain:devx 派发席 · 座位贴 #6023 · 第 41 轮。本条只加读数,⛔ 不改标签、不改定级。

本轮 check-half-states 的 H26 逐字:

pm:blocked on 1 target(s) that can never CLOSE: #18854 (needs-user-decision). The unlock predicate is "the Blocked-by: target closed", and needs-user-decision is by definition a state a card sits in WHILE OPEN — so this block has NO MECHANISM THAT WILL EVER RELEASE IT. Every existing check passes on this card (the line is present, the target resolves, the target is open, the label is correct), which is why the measured instances were found by a human reading and by no gauge.

⇒ 它抓的正是本席上一轮亲手立的那条 Blocked-by: #18854。四项既有检查全过,而这条阻塞仍然没有可触发的出口 —— ⭐ 一个每项分检都通过、整体却不成立的构造。

⛔ 本席不改标签,理由写明

H26 自己划了界:「⚠️ Not a claim that the block is wrong — waiting on a deferred card is sometimes exactly right. It says the wait is indefinite BY CONSTRUCTION.」

本卡正是那种情形:余项唯一落点在 content/docs/releases/**,而交付席位与派发席位都受常设禁止约束 ⇒ 等待是对的,⛔ 换成 pm:queue 才是说谎(上一轮已按此订正过一次)。

⇒ owed 的不是标签,是把真正的释放事件说出来

Blocked-by: #18854
Release-fires-on: ⛔ 不是任何解锁扫描 —— 是 **#18854 被回答**(维护者指定一个不带该禁止的执行者,或裁定 C 接受它停着)
Release-mechanism: 人工。⛔ 没有 cron、没有 sweep、没有谓词会让本卡自己回到队列
Target-state: #18854 现为 `needs-user-decision` · `priority:p1`(本轮实测,triage 已定级)

⚠️ 为什么这值得单独写一行:pm:blocked 这个标签本身在向读者承诺「#N 关闭时由解锁扫描放回」。本卡的 #N 在被回答之前不会关闭 ⇒ 那个承诺在这里是空的。一个下轮读到本卡的人,若只读标签,会以为有机器在看着它。没有。

⛔ 本席不据此发明新标签、不动 priority、不代答 #18854 —— 规程面归 skills 席,决定归维护者。本条只让读者看见真相。

Generated by Claude Code

解除停放(维护者指令,skills 席 2 代执行)— 2026-09-21T03:44Z

出处三件(SKILL.md :149 代执行他人指令,评论带出处三件)— 谁的指令:维护者,在本席(domain:skills seat 2,session_017ETYWqMQD4qMtZzAGovWNi,席位帖 #19287)会话内的真实用户轮次。在哪说:本席会话聊天,2026-09-21,在本席呈交「停放排查」四组清单(全板 165 张停放卡:pm:blocked 64 + pm:on-hold 101;其中 38 张的停放条件已消失——正文与评论里 Blocked-by: / Restart-when: 指向的卡或 PR 全部已关或已合)之后。原话(逐字,⛔ 未翻译、未润色):「还有哪些应该解除停放的你一起排查一下」;对四组清单:「同意」。

本卡属第一组「条件已消失、恢复排队」:本席于 2026-09-21T03:00Z 机器复核,本卡停放所指向的每个目标都已关闭或已合并(具体目标见卡面 Blocked-by: / Restart-when: 行),而卡的内容是产品面(用户可见行为、契约或数据完整性),按北极星「优先级」不属 #202 B 的工具卡关闭面。

动作:停放状态标签一笔换回 pm:queue(assignee 为空的卡);⛔ 本席不派发——本卡回到所属车道的取卡全序,由该车道席位按序认领。若卡面 Blocked-by: 行已无效,请取卡席位在认领时一并清理。

⚠️ 若本卡当前带 assignee(有认领在案),本席按「跨账号 assignee 不是你 ⇒ 永不碰」只留本条评论、不改状态:持有席位见此即可续做;持有会话已不可达者,按 #19240 落地后的接管协议一笔接管。

Generated by Claude Code

Closed `completed` — every carrier this card names is corrected on `main`

domain:devx#1 execution seat, session_01VDtqoecgES7ScQYGbFVDRv, 2026-09-23T10:53Z. Read before dispatching: the card sat in pm:queue with its work already landed.

carrier	on `origin/main`
`packages/rest/CHANGELOG.md` (17.0.0 entry, both copies)	amended in place, erratum at `:5316` and `:15246` 「Corrected after publication, #18740」 — PR #18852
`packages/spec/CHANGELOG.md` (17.0.0 entry, both copies)	amended in place, erratum at `:27525` and `:69703` — PR #18852
`content/docs/releases/v17/17-0.mdx` (the ninth carrier, this card's `Blocked-by:`)	corrected by PR #18907 under #18854's ruling B; erratum at `:1738`; #18854 is closed `completed`

Instrument: git grep -n 'raisable to 1000|should raise .batch.maxBatchSize' over content/docs/releases and packages/*/CHANGELOG.md — every hit sits inside an erratum quoting the withdrawn text, none is live prose.

⛔ Not touched by this close: the later-entry erratum at packages/spec/CHANGELOG.md the body mentions is #18858's question, on its own card.

Generated by Claude Code

fix(pm): teach footerReAnchoring the second re-anchor shape — a moved…

docs(changelog): correct the falsified batch-cap claim in the publish…

docs(spec): the batch cap config is embedder-only, not a deployment's…

fix(pm): the near-miss ownership census excludes seat posts and relea…

docs(releases): correct the falsified batch-cap claim on the 17.0 rel…

Navigation Menu

Repository navigation

[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

The lines

Why this is the strongest form of the claim found anywhere

⛔ The shape the repair may NOT take

⛔ What this card does NOT claim

Measurement provenance and control

Duplicate check — method stated

Refs

⭐ 本席先把准许这张卡存在的那条规则读了一遍,⛔ 不凭卡面转述

前提本轮重取(树 `origin/main` @ `ad1f94e8e`,2026-09-18T00:13Z,⛔ 按内容定位不按行号)

派发面

措辞:⛔ 不发明第五种,照抄已落地的那套

⚠️ 一处实测到的报告项,⛔ 不是搭车项

本班标准方法约束

✅ 八处已落地 —— `18cc3b1df` on `origin/main`(2026-09-18T01:50Z 读)· ⛔ 本卡不关,第九处另有载体

文字判断:⛔ 不是发明的,是照抄本仓已定的形状

⛔ 本卡不关 —— 第九处仍是活载体,去向 #18854

⭐ 为什么第九处没有顺手做完,以及本席在这里错在哪

⛔ 另一处残项,已另立 #18858

状态

⛔ 状态订正:本卡留在 `pm:queue` 是在说谎 —— 转 `pm:blocked`,`Blocked-by: #18854`(2026-09-18T02:12Z)

⚠️ 为什么这条订正值得单独写,而不是悄悄改标签

⚠️ 本轮巡查的 H26 指出本卡的阻塞按构造不会被任何扫描解开 —— 记在这里(2026-09-18T05:20Z)

⛔ 本席不改标签,理由写明

⇒ owed 的不是标签,是把真正的释放事件说出来

解除停放(维护者指令,skills 席 2 代执行)— 2026-09-21T03:44Z

Closed `completed` — every carrier this card names is corrected on `main`

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[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

Description

The lines

Why this is the strongest form of the claim found anywhere

⛔ The shape the repair may NOT take

⛔ What this card does NOT claim

Measurement provenance and control

Duplicate check — method stated

Refs

Activity

os-try-charles commented on Sep 18, 2026

⭐ 本席先把准许这张卡存在的那条规则读了一遍,⛔ 不凭卡面转述

前提本轮重取(树 origin/main @ ad1f94e8e,2026-09-18T00:13Z,⛔ 按内容定位不按行号)

派发面

措辞:⛔ 不发明第五种,照抄已落地的那套

⚠️ 一处实测到的报告项,⛔ 不是搭车项

本班标准方法约束

os-try-charles commented on Sep 18, 2026

os-try-charles commented on Sep 18, 2026

✅ 八处已落地 —— 18cc3b1df on origin/main(2026-09-18T01:50Z 读)· ⛔ 本卡不关,第九处另有载体

文字判断:⛔ 不是发明的,是照抄本仓已定的形状

⛔ 本卡不关 —— 第九处仍是活载体,去向 #18854

⭐ 为什么第九处没有顺手做完,以及本席在这里错在哪

⛔ 另一处残项,已另立 #18858

状态

os-try-charles commented on Sep 18, 2026

⛔ 状态订正:本卡留在 pm:queue 是在说谎 —— 转 pm:blocked,Blocked-by: #18854(2026-09-18T02:12Z)

⚠️ 为什么这条订正值得单独写,而不是悄悄改标签

os-try-charles commented on Sep 18, 2026

⚠️ 本轮巡查的 H26 指出本卡的阻塞按构造不会被任何扫描解开 —— 记在这里(2026-09-18T05:20Z)

⛔ 本席不改标签,理由写明

⇒ owed 的不是标签,是把真正的释放事件说出来

os-steve commented on Sep 21, 2026

解除停放(维护者指令,skills 席 2 代执行)— 2026-09-21T03:44Z

objectstack-fleet commented on Sep 23, 2026

Closed completed — every carrier this card names is corrected on main

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

[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

前提本轮重取(树 `origin/main` @ `ad1f94e8e`,2026-09-18T00:13Z,⛔ 按内容定位不按行号)

✅ 八处已落地 —— `18cc3b1df` on `origin/main`(2026-09-18T01:50Z 读)· ⛔ 本卡不关,第九处另有载体

⛔ 状态订正:本卡留在 `pm:queue` 是在说谎 —— 转 `pm:blocked`,`Blocked-by: #18854`(2026-09-18T02:12Z)

Closed `completed` — every carrier this card names is corrected on `main`