[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

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

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

Claim: PM loop round 10
Session: session_01JbZnqu8bt6YqfJsr9vaFb3
Branch: claude/issue-18739-batch-cap-deployment-policy
Worktree: objectstack-issue-18739
Domain: domain:spec
Seat: domain:spec#2(座位贴 #18549;席 1 是 #6017,本认领不碰它)
File surface: packages/spec/src/api/batch.zod.ts —— ⚠️ 开放并预先申报:.changeset/*.md 与任何门禁反向要求的派生物。只读:packages/spec/src/api/rest-server.zod.ts(对照那段 WHO CAN WRITE THIS CONFIG (#15543) 头)· packages/rest/**(#16801 的先例)(stop on breach; explain in the report)
Container & model: M, mode:subagent, model: default judgement tier
Clause-②: no
Thread-read: 5719000732
Serial constraints cleared: ⏱️ 本行读数取自本评论同一动作,2026-09-17T18:17Z。本席对当时全部 24 个 open claude/issue-* PR 逐个拉 /pulls/N/files 实测:packages/spec/src/api/batch.zod.ts 的持有者 0 个。⭐ 同一把扫描的亮控:已知被 #18720 持有的 packages/spec/src/ui/dashboard.zod.ts 读出 [18720] ⇒ 仪器是活的,那个 0 是真零。本席名下另有 #18720(卡 #17779)在合并队列中,文件面为 ui/dashboard.zod.ts + migrations/**,与本卡不相交。

这是一张改一行注释的卡,⛔ 不是重新裁定

裁决在 2026-09-07 就下了(总监席 summon #17,决策批次 #2,维护者逐字「同意」):「读者可以配置 batch.maxBatchSize」这句话是假的。本卡是同一句假声明的第五个载体,前四个都已按同一条裁决改过(#15543 / #16801 / #16940 / #17183)。

⇒ 你要做的是把 batch.zod.ts:128 那行改成与已裁结论一致,⛔ 不是重新论证该不该配置。

⭐ 卡面自己点了名:同一句措辞 #16801 已经在另一个包里删过

#16801 把 the batch-size cap is DEPLOYMENT policy 这个逐字措辞从 packages/rest/src/rest-server.ts#enforceBatchSize 里删掉了。⇒ 先去读那一笔怎么改的,把同样的形状搬过来;⛔ 不要自创一套新说法。

本席答不了的一件,写成给 dev 的问题,⛔ 不写成栅栏

⭐ rest-server.zod.ts 的 WHO CAN WRITE THIS CONFIG (#15543) 头说「On a CLI-started deployment every OTHER key here is EMBEDDER-ONLY」。⇒ 新措辞到底该说 batch.maxBatchSize 是 embedder-only 还是别的什么,取决于那段头文本的确切范围 —— 本席没有实测它是否覆盖 batch,⛔ 这是未验断言,请你自己去读那段头再定,并把判断写进 PR 正文。

验收上必须有的两个控

⭐ LIT:你的搜索能在已改过的四个载体里至少找到一处已经是正确措辞的文本 —— 否则你的「只剩这一处」只是搜索没响。
⭐ DARK:某个必须读 0 的东西 —— 改完之后,the batch-size cap is DEPLOYMENT policy 这个逐字串在全仓(含 docs、CHANGELOG 除外的实时源)读数须为 0;⚠️ CHANGELOG 里的历史记载不算残留,⛔ 不要去改历史。

声明与 changeset

Clause-②: no —— 只改注释文本,⛔ 不动任何 schema、不增删导出符号。⚠️ 开 PR 那一笔就把 Clause-②: 行抄进正文行首(Check Changeset 读正文不读卡)。changeset 按仓规写;若判定无需 changeset,在报告里说明依据,⛔ 不要静默省略。

⚠️ PR 正文 dev 只写一次,在开 PR 那一笔;⛔ 不 PATCH 正文。事后要改的,在报告里点名改法,本席代写。

Generated by Claude Code

os-dev-report

{
  "issue": 18739,
  "status": "done",
  "branch": "claude/issue-18739-batch-cap-deployment-policy",
  "pr": "https://github.com/objectstack-ai/objectstack/pull/18757",
  "session": "session_01JbZnqu8bt6YqfJsr9vaFb3",
  "premise_still_valid": true,
  "summary": "The premise held exactly as filed: `packages/spec/src/api/batch.zod.ts:128` still carried `the batch-size cap is DEPLOYMENT policy` on origin/main at 0e2ebce37b. Corrected in place by carrying over #16801's shape from `packages/rest/src/rest-server.ts#enforceBatchSize` rather than inventing wording, so the five carriers now read alike: span and default kept as schema facts, reachability stated as EMBEDDER-ONLY, the one door named, and pointers left to the WHO CAN WRITE THIS CONFIG header and the liveness REACHABILITY row. The seat's unverified claim is now MEASURED and TRUE: that header names `batch` explicitly among the embedder-only sub-objects (rest-server.zod.ts:47-50), `maxBatchSize` sits inside it (BatchEndpointsConfigSchema, rest-server.zod.ts:706), and `liveness/batch_endpoints.json`'s maxBatchSize row independently records `REACHABILITY ... embedder-only`; the header's single carve-out is metadata.maskObjectFields, not this key. On the card's explicit ask about `1..1000`: the range SURVIVES, reattached to the embedding host, because it is what the Zod schema actually enforces and because both landed carriers keep it that way — dropping it would have invented a fifth shape and deleted a true schema fact to fix a false reachability claim. Assignee was `os-bill` on arrival (PM-set); never written by me.",
  "tests": "All readings at 90043af0fb, clean working tree. BUILD `pnpm --filter @objectstack/spec build` exit 0 under the shared verify lock (VERDICT command-exit 0, held 126s). GENERATED `pnpm --filter @objectstack/spec check:generated` exit 0 — 'All 15 generated artifacts are up to date', nothing regenerated (expected: a line comment is neither rendered onto a reference page nor an authorable key). TYPECHECK+TEST `pnpm --filter @objectstack/spec typecheck && ... test` exit 0 under the lock (VERDICT command-exit 0, held 196s, waited 110s) — 'Test Files 486 passed (486) / Tests 13964 passed (13964)'. FULL BUILD `turbo run build --filter=!@objectstack/docs --concurrency=2` exit 0 — '73 successful, 73 total'. GATE FAMILIES: derived with `scripts/pm/dispatch-gates.mjs --commands --repo objectstack-ai/objectstack`, re-derived after the changeset existed (75 commands), all 75 run with exit codes captured before any pipe; reconciliation `--ran` prints 'Run reconciliation — 75 derived, 75 run, 0 NOT-MEASURED, 0 UNRUN'. Three initially returned exit 3 = PREREQUISITE NOT MET (the gates' own code for 'nothing was measured', distinct from a finding's 1) because they read built output of packages this diff never touches; the full build cleared them and check:doc-formula-expressions, check:dual-build-cjs-loads and check:lean-entry-closure were re-run green. LINT: full `pnpm lint` (eslint . --no-inline-config) exit 0, no output — run in full, so NO narrowing is claimed and the three-part narrowing evidence is not owed. BYTES: `grep -naP` control-character self-scan over both changed files and the PR body, clean. ABLATION: none run, and none is meaningful here — this diff adds no guard that could be made to fail, so there is nothing whose red leg could be demonstrated. The acceptance controls stand in its place. LIT fired on all four already-corrected carriers, not one (rest-server.zod.ts:496 and :707, rest-server.ts:2213, data-api.mdx:327, http-protocol.mdx:851). DARK reads 0 for the verbatim string across the tracked tree, against a live control (the same grep for `the batch-size cap is` still returns this file). ⚠️ REPORTING A FAILED MEASUREMENT: my FIRST census was line-scoped `git grep`, and its own positive control read 0 on a phrase I had already read with my eyes — the claim wraps across two comment lines, so no line-scoped regex can match it. That reading was discarded, not retried, and redone wrap-immune (normalise comment leaders, collapse all whitespace including newlines; 8830 tracked text files scanned). The wrap-immune result: verbatim string 0, semantic variant 0, and ONE hit for a third spelling — the sixth carrier reported below.",
  "mcp_calls": "0 — no MCP GitHub tool was called, read or write. Every GitHub read and write went through the REST proxy with curl, plus the repo's own scripts/pm/label-write.mjs and scripts/pm/check-clause2-carriers.mjs (both REST).",
  "api_writes": "3 — POST /repos/objectstack-ai/objectstack/pulls (draft PR #18757, body written once at creation and read back byte-identical apart from a stripped trailing newline, one footer); POST /repos/objectstack-ai/objectstack/issues/18757/labels (via scripts/pm/label-write.mjs, additive only, read back MATCHES: documentation, size/s, tooling, priority:p2, domain:spec — the first three were already the labeler bot's); POST /repos/objectstack-ai/objectstack/issues/18739/comments (this report). Plus 3 git pushes (empty-branch routing probe, then one per commit). No PATCH of any body, no ready-flip, no auto-merge, no assignee write, no POST /issues.",
  "open_questions": [],
  "out_of_scope_findings": [
    "to file (class b — contradicts a declared contract; dedupe words: batch.test.ts · deployment's configured · maxBatchSize · embedder-only · sixth carrier): packages/spec/src/api/batch.test.ts:110 says the capping route read 'the deployment's configured `batch.maxBatchSize` (1..1000)'. Same false attribution the 2026-09-07 ruling settled, in a spelling that WRAPS across two comment lines, which is why every probe run over this claim so far — both populations behind the card, and my own first pass — read zero for it. Contract text it contradicts: the WHO CAN WRITE THIS CONFIG (#15543) header, 'On a CLI-started deployment every OTHER key here is EMBEDDER-ONLY: the whole of `crud`, `metadata` and `batch`'. Weaker than the five before it in one measured respect: it does NOT publish — packages/spec ships `src/**/*.zod.ts` in files[], and a .test.ts is not in that set. NOT repaired here: outside this card's declared file surface, and the dispatch says hand other defects back rather than fold them in. Recommend routing to the same seat as #18740 (same claim, different carrier class).",
    "noted, not filed: the four CHANGELOG occurrences (packages/rest/CHANGELOG.md:5265 and :15192, packages/spec/CHANGELOG.md:27474 and :69649) are the published record of what shipped, not residue — the dispatch excludes them and AGENTS.md forbids editing CHANGELOG.md in a code PR. Successor who will touch them: the #18740 seat, which is the card already filed for exactly this population. Nothing owed here.",
    "noted, not filed: docs/qa/platform-checklist/FOLLOW-UPS.md:575 quotes the old REST wording, but correctly and in the past tense, as the record of the correction it itself ordered. It is accurate as written. Successor who will read it: any future carrier sweep and the #18740 seat. No change owed.",
    "noted, not filed: the durable lesson is that a claim wrapping across two comment lines is invisible to a line-scoped probe, just as a claim outside a directory is invisible to a directory-scoped one — the card records the second shape and this run measured the first. Written into the PR's acceptance notes; the census script stayed in the scratchpad rather than being committed, because it is a measurement, not an artifact this repo should carry. 承接者:无 — no PR or person will touch a file because of this note."
  ]
}

Generated by Claude Code

MERGED 确认 —— PR #18757。⏱️ 本条每一段的读数都取自同一动作:2026-09-17T20:23Z。

⏱️ 下面这块读于 2026-09-17T20:23Z。

git fetch origin main && git log --oneline origin/main | grep -F '(#18757)'
  062f5cdd71 docs(spec): the batch cap is embedder-only, not "DEPLOYMENT policy" —
             the fifth carrier (#18757)
parents: 1   ← 单亲 squash

⭐ 主题探针用的是**免折行**判据(剥注释前缀 + 把含换行的空白全部折叠),
   ⛔ 不是按行 grep —— 这句话跨两行注释,按行的探针在它上面读假零,
   本卡的第六个载体就是这样活过五轮的。扫 8767 个 tracked 文本文件(排除 CHANGELOG):

  ⭐ DARK 已裁为假的原话 `the batch-size cap is DEPLOYMENT policy`     0
  ⭐ LIT  同一把扫描找改写后的 `the batch-size cap is`                  1
          → packages/spec/src/api/batch.zod.ts   ← 仪器活着
  第六个载体 `the deployment's configured `batch.maxBatchSize``         1
          → packages/spec/src/api/batch.test.ts  ← 仍在,按设计:那是 #18763 的事

os-regen 面(roster 当场读自 `grep os-regen .gitattributes`)
  落地触及 2 个文件(.changeset + batch.zod.ts),命中 roster 的:0
  ⇒ ⛔ 不欠落地后重生成核验

卡由 Fixes 代关(closed / completed),同笔摘 pm:dispatched 并清 assignee(回读为 priority:p2 · domain:spec)。⚠️ 定级未动。

本卡真正的收获,⛔ 不是那一行注释

本席派发时把「那段 WHO CAN WRITE THIS CONFIG 头是否覆盖 batch」标成未验断言交给 dev,而不是写成栅栏。dev 测了,答案是 TRUE:该头逐字写着「the whole of crud, metadata and batch」(rest-server.zod.ts:47-50,本席复核过)。⇒ 新措辞把上限的可达性说成 EMBEDDER-ONLY,是测出来的,⛔ 不是抄来的。

⭐ 而 dev 的第一遍普查读出了假零 —— 它的阳性对照在一句它亲眼读过的话上读 0,于是它把那次读数作废、换成免折行判据重做,⛔ 没有重试也没有将就。第六个载体就是这样被翻出来的,已立卡 #18763。

⇒ 「一句话跨行就对按行的探针隐身」,与「目录外对按目录的探针隐身」是同一种盲。

Generated by Claude Code

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

docs(spec): the batch cap is embedder-only, not "DEPLOYMENT policy" —…

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

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

Navigation Menu

Repository navigation

[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

The line

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

Why four sweeps missed it — the durable half

Measurement provenance and control

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

⛔ What this card does NOT claim

Suggested shape

Duplicate check — method stated

Refs

这是一张改一行注释的卡,⛔ 不是重新裁定

⭐ 卡面自己点了名:同一句措辞 #16801 已经在另一个包里删过

本席答不了的一件,写成给 dev 的问题,⛔ 不写成栅栏

验收上必须有的两个控

声明与 changeset

本卡真正的收获,⛔ 不是那一行注释

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[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

Description

The line

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

Why four sweeps missed it — the durable half

Measurement provenance and control

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

⛔ What this card does NOT claim

Suggested shape

Duplicate check — method stated

Refs

Activity

os-bill commented on Sep 17, 2026

这是一张改一行注释的卡,⛔ 不是重新裁定

⭐ 卡面自己点了名:同一句措辞 #16801 已经在另一个包里删过

本席答不了的一件,写成给 dev 的问题,⛔ 不写成栅栏

验收上必须有的两个控

声明与 changeset

os-bill commented on Sep 17, 2026

os-bill commented on Sep 17, 2026

本卡真正的收获,⛔ 不是那一行注释

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

[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