docs(pm-dispatch): state both the batch default and the maintainer ceiling in one row

[yinlianghui]

Fixes #16272

What changed

One in-place cell edit in .claude/skills/pm-dispatch/SKILL.md — the /pm-dispatch [args] argument table's batch row. The row's default column carried a single number, 3, while the maintainer's dispatch ceiling has been 5 since 2026-09-03, so a reader of the table could not tell which number a seat is expected to run at. The row now names both numbers and labels each by role, inside the existing row.

Before / after

before (50 bytes):  | `batch:N` | 同时在飞的 dev 上限 | `3` |
after  (87 bytes):  | `batch:N` | 同时在飞的 dev 上限 | 默认 `3`;`n` 的维护者天花板 `5` |

⚠ N above stands in for the argument placeholder the real cell uses (a lowercase n wrapped in angle brackets); the literal fragment is spelled out here so it survives GitHub's body sanitizer. The file on disk is unchanged in that respect — only the third column moved.

Line-neutral: the file is 811 lines before and after. No new line was added, no 3 was changed to 5.

Provenance — the two records the reviewer would otherwise have to look up

1. #14944's ruling 5548762263 — the text the triage seat read to settle which of the two readings the evidence supports, verbatim:

"The nominal cap of 5 (the 2026-09-03 ruling) is unchanged"

It speaks of the cap, not the default. 2. the 2026-09-03 cap decision it cites moved the maintainer's dispatch cap 3 → 5; nothing in it moves the per-invocation default. A ruling that raises a ceiling from 3 to 5 does not by itself raise the default from 3 to 5.

3. this card's triage ruling 5579798462 ruled reading A and fixed the shape of the fix (Chinese, kept verbatim and untranslated):

⇒ 修法:在同一行里把两个数都说出来,并标明哪个是默认、哪个是上限。 ⛔ 不要把 3 改成 5(那是读法 B,无文本支持,且会把默认并发直接抬高,属行为变更而非文档更正)。

and, as a hard constraint, because the file sits at line-ratchet headroom 0:

⇒ ⛔ 不能新起一行写「上限是 5」。 必须在已有的那一行内把两个数说清

Both are honoured: 3 stays the default, 5 is labelled the maintainer ceiling on the argument, and the change is line-neutral.

One deliberate departure from the dispatch's example wording

The dispatch offered `5`(维护者上限,2026-09-03 裁) as an example shape. The date is not in the landed cell. The pm-dispatch corpus standard is rules-only — scripts/pm/check-skill-id-lint.mjs states it as "The scanned corpus carries rules only — no ruling dates, no quotations, no issue numbers; a rule's provenance lives in the PR that landed it", and AGENTS.md says the same of its own text. So the provenance lives in this PR body instead, which is also what the card asked for.

Evidence

Line ratchet — the gate's own verdict lines, verbatim

✓ check-skill-line-ratchet: .claude/skills/pm-dispatch/SKILL.md: widest table row is 342 bytes (pin 342; headroom 0).
✓ check-skill-line-ratchet: .claude/skills/pm-dispatch/SKILL.md is 811 lines (ceiling 811; headroom 0).

Both pins on this file are at headroom 0 and both stay green: the line count did not move, and the edited row (87 bytes) is nowhere near the 342-byte widest-row pin, so the widest-row measurement did not move either.

Merge-tree probe — the line count of the file as merged

Run on the merge of origin/main and this branch, as the triage ruling asked, because the file's headroom is 0 and siblings are in flight on it:

git merge-tree --write-tree origin/main HEAD   ->  exit 0 (clean), tree 399999cec00b5f5b434da20c0f557382e3cd2aac
git cat-file -p TREE:.claude/skills/pm-dispatch/SKILL.md | wc -l   ->  811

811 in the merged tree = the ceiling, headroom 0, green. The branch also carries a real git merge origin/main (at d127f9ba), which was clean and left the row untouched. Sibling PR #17021 (which would take this file to 812) is not on main yet; if it lands first this branch must be re-merged and the probe re-read before landing.

Gates — derived from the actual change set, all green

Derived with node scripts/pm/dispatch-gates.mjs --commands --repo objectstack-ai/objectstack (change set taken from git by the tool itself, three-dot against merge base d127f9ba), then reconciled with --ran:

✓ dispatch-gates --ran: 16 derived famil(ies) accounted for — 16 run, 0 NOT-MEASURED.
Run reconciliation — 16 derived, 16 run, 0 NOT-MEASURED, 0 UNRUN.

gate	exit
node scripts/check-closing-keyword-parity.mjs (and --self-test)	0
node scripts/check-comment-mask-corpus.mjs	0
node scripts/pm/check-governed-queue-guard.mjs --self-test	0
pnpm check:agent-test-spelling	0
pnpm check:doc-authoring	0
pnpm check:driver-memory-census	0
pnpm check:nul-bytes	0
pnpm check:pm-governed-merges	0
pnpm check:pm-governed-prose	0
pnpm check:pm-skill-id-lint	0
pnpm check:pm-skill-ratchet	0
pnpm check:refd-timer-probe	0
pnpm check:skill-frame-sync	0
pnpm check:watch-hint-literal	0
pnpm --filter @objectstack/lint run check:doc-formula-expressions	0
pnpm check:required-contexts (not derived; run because the previous flight's derivation carried it)	0

Every exit code was captured before any pipe (cmd > log 2>&1; EXIT=$?), never through | head/| tail.

check:doc-formula-expressions first returned exit 3 — PREREQUISITE NOT MET (unbuilt @objectstack/formula / @objectstack/lint), which is NOT MEASURED, not a finding. @objectstack/formula + @objectstack/lint were then built through the shared verify lock (scripts/pm/os-verify-lock.sh, VERDICT command-exit 0 · held the lock 197s · waited 0s) and the gate re-run to a real green.

check:skill-frame-sync is green and reports 2 copies of the decision frame are structurally isomorphic across 2 files — the four-axis frame block is untouched by this PR, as expected.

Repo-wide lint — measured narrowing, not a skipped run

pnpm lint is eslint . --no-inline-config, a repo-wide scan CI owns. The narrowing here is a measurement, not an omission:

1. Population, read from eslint's own configuration rather than guessed: running pnpm exec eslint --no-inline-config --format json on the one changed file returns "File ignored because no matching configuration was supplied." — .md under .claude/ is outside the configured lint surface entirely.
2. File count, read from the --format json output: 1 file examined, errorCount: 0, fatalErrorCount: 0.
3. Invariance for untouched files: this diff is one markdown table row in a file eslint does not configure. No type-aware linting is involved and no config file was touched, so nothing in this diff can move the verdict on any file it did not touch.

Union of gates re-run after the final commit; git rev-parse --short HEAD at that run = bd310fd6.

Control characters

grep -naP '[\x00-\x08\x0b\x0c\x0e-\x1f\x7f]' over the changed file: no matches (exit 1). pnpm check:nul-bytes green.

Why skip-changeset

Nothing published moves: .claude/** is not shipped in any package's files[] — it is agent operating text read from the repo, not from an installed artifact.

Governance

.claude/** is a governed surface (AGENTS.md Prime Directive #14). This PR is a draft and stays one: no seat merges it, queues it, arms auto-merge on it, or flips it out of draft. Landing is the maintainer's, by hand.

维护者速读(草稿)

改了什么 —— /pm-dispatch 参数表里 batch 那一行的默认值单元格,原来只写 3。现在同一行里写清两个数各自的角色:默认是 3,维护者给这个参数的天花板是 5。只动这一个单元格,文件行数 811 → 811 不变。

为什么改 —— 维护者 2026-09-03 把派发 cap 从 3 抬到 5,但表格只有一个数,读表的人看不出席位到底该按几跑:照表走会把并发压到 3,照别人实践走又不知道 3 是哪来的。分诊席读了 #14944 的裁定原文(说的是 cap 不是 default),裁定按读法 A —— 表格里的 3 作为默认值没有过期,过期的是「表格只说了一个数」。所以 ⛔ 没有把 3 改成 5;若您本意其实是让默认值也跟到 5,那是一处单字修改,请在这里直说。

风险与代价(含回滚) —— 纯文档、单行、零行为、零发布面,风险接近零。唯一的机械风险是这个文件行数余量为 0:本 PR 行数中性,合并树探针读到 811 = 天花板,绿。但姊妹 PR #17021 会把它抬到 812,若它先落地,本分支需重新合 main 并重跑一次探针再合。回滚 = revert 这一个 commit,无依赖、无迁移。

席位意见 ——(留空,待席位填写)

你要做的 —— 只有两件:① 确认读法 A 是您的本意(默认 3 / 上限 5),不是 B(默认也是 5);② 手动合并这个 draft PR —— 治理面不进合并队列、不挂 auto-merge。

验收备注

No out-of-scope findings. Two things checked and found clean rather than filed:

• The default 3 is restated nowhere else in the pm-dispatch corpus. A literal-backtick-3 scan across .claude/skills/pm-dispatch/**/*.md returns exactly this one row; the other batch mentions (SKILL.md at the priority-override, capacity, parallelism and effective-cap lines, and references/core-rules.md's two) all refer to batch as a cap concept without restating any number. Nothing else needed aligning.
• references/core-rules.md was therefore not touched.

---

Generated by Claude Code

[yinlianghui]

维护者速读 — PR #17024(#16272,skills 席终稿,2026-09-09T03:01Z)

改了什么 — /pm-dispatch [args] 参数表的 batch:<n> 一行,默认列原来只写一个数 3;现在同一单元格内写成「默认 3;n 的维护者天花板 5」。一文件一行,行数 811 不动,棘轮各上限不动,3 没有被改成 5,也没有新起一行。

为什么改 — 你在 2026-09-03 把派发上限从 3 抬到 5,各执行席按 5 在跑,但表格只写了 3:新席位照表跑就把并发压到 3,照别人的实践跑又不知道 3 从哪来。分诊席已裁读法 A(5579798462):抬上限的裁定不自动抬默认值,所以两个数都要写、各标角色。溯源(#14944 的裁定与 2026-09-03 的上限决定)在 PR 正文里引全,单元格本身不带日期——技能语料只放规则,出处归 PR。

风险与代价(含回滚) — 纯指令文本,不改任何门禁行为、不改默认并发;回滚 = revert 本 PR。零代价:同行改写,离 120 字节行宽还有余,最宽表行 342 未动。

席位意见 — 接受。本席在分支头上复核:第 60 行单元格与裁定一致;语料内 batch 默认数无第二份副本;棘轮 811/811、id-lint 26 文件干净、frame-sync 两副本同构、控制字节 0;mergeable: true。

你要做的 — 合并;或由 os-zhuang / hotlong 批准,本席随即入队。⚠️ 若你本意其实是读法 B(默认值也跟到 5),改这一个单元格即可,⛔ 本席不代裁。

---

Generated by Claude Code