docs(pm-dispatch): steward pin-watch mechanical output + Guardrails「版本发布必须人工」(#6162, #6170)

[hotlong]

Fixes #6162

Authorization

Maintainer-authorized .claude/ tooling PR (Guardrails exception, #5925-6; precedents #5597 / #5872). Two maintainer rulings from 2026-08-07, quoted verbatim:

Ruling 1 (pin-watch duty, option A of the anti-forgetting proposal):

A. 队列管家加一条例行职责(推荐,先做)。

Ruling 2 (after the rc.4 auto-publish incident #6169 / #6170):

刚才我也没提出要求,是哪个ai自己替我发了 rc.4,版本发布必须是人工的。这个要写入规范。

Per the same Guardrails clause this PR is not self-accepted: it stays draft until another seat or the maintainer walks it through.

What changed (one file: .claude/skills/pm-dispatch/SKILL.md, 2 commits, +33/−2)

Commit 1 — steward pin-chain watch gains a mechanical output (#6162):

1. New paragraph in 「入队与落地 B」 — the duty itself:
   • Trigger 1 (pre-release, objectui → objectstack): .objectui-sha lags objectui main and objectui's merge queue is empty (the window-settled predicate) ⇒ file/refresh the console-bump chore in objectstack pm:queue. Template = chore(console): bump objectui pin f995a452 → a4cff5b (17 commits / 7 releasing changesets) — required before cutting rc.4 #6159 (lag readings, releasing-changeset list, bump-objectui.sh procedure, objectui pin bump 生成的 console changeset 对破坏性变更零标注 —— digest 只认 major 声明级别,而 objectui 在 v17 窗口内把破坏性声明为 minor + 正文标注 #6099 breaking-annotation re-check, ordering vs the Version Packages PR).
   • Trigger 2 (post-release, objectstack → cloud): a new rc/stable tag family is observed ⇒ file the same-shape .objectstack-sha bump chore in cloud's queue (cloud's check:pin-staleness stays advisory — the output is an issue, not a new gate).
   • Boundaries: one open chore max (refresh by comment, never a second issue); coordination rule 3 (accepting seat files the linkage chore) stays the first producer — this duty is the window-level backstop; new pin-toolchain findings still go to the anchor issue as 提请 only. The steward still never executes the bump — its authority face (no code, no claims, no merges) is unchanged.
2. Steward duty-table row in the same section — appends the mechanical output to the pin-chain-watch entry.
3. 「现役两例」 enumeration (座位 Routine 化 section) — kept in sync with the table so the two enumerations don't diverge.

Commit 2 — Guardrails: 「版本发布必须人工」 (#6170):

4. All AI seats (PM / dev / Routine / queue steward) are forbidden every publish action: running changeset publish / pnpm run release, pushing version tags, dispatching Release-class workflows, merging Version Packages (chore: version packages) PRs. Release-adjacent work (release board, pin bumps, version reconciliation, post-publish verification) stays with the seats; the publish itself happens only by the maintainer's own hand. Unauthorized publish traces (tags / npm versions appearing without a human action) are incident-filed — never "repaired" by a counter-publish. Precedent recorded in the rule: the 2026-08-07 rc.4 auto-publish (release: 17.0.0-rc.4 published from a10cbc77 but the version commit never landed on main — 2026-08-03 shape repeated; merge it back before ANY further release action #6169 / release workflow: publish pushes tags + npm but its version commit never reaches main — twice now (rc.3 c6a52d3, rc.4 a10cbc77); landing the commit must be part of the publish lane #6170) — the existence of a mechanical lane does not constitute authorization; a seat that finds such a lane reports it as a defect, not uses it as a tool.

Why

• Commit 1: check:objectui-pin-fresh (required on the release PR, Release process: prevent frontend (objectui) changesets being missed when the console pin lags #3340) prevents loss, not lateness — tonight's chore(console): bump objectui pin f995a452 → a4cff5b (17 commits / 7 releasing changesets) — required before cutting rc.4 #6159 existed only because the maintainer happened to ask in chat. This converts that hand-step into a steward-round mechanical product.
• Commit 2: rc.4 shipped with nobody clicking anything — release.yml runs on every push to main and its recover-publish step published the freshly versioned workspace (mechanism confirmed with run evidence on release workflow: publish pushes tags + npm but its version commit never reaches main — twice now (rc.3 c6a52d3, rc.4 a10cbc77); landing the commit must be part of the publish lane #6170). The workflow fix is release workflow: publish pushes tags + npm but its version commit never reaches main — twice now (rc.3 c6a52d3, rc.4 a10cbc77); landing the commit must be part of the publish lane #6170's; this commit lands the policy half so no seat ever treats a publish lane as usable authority.

Activation note

The live steward Routine's prompt instructs it to read SKILL 「入队与落地」 A/B on every fire, so the pin-watch duty activates on merge. The pasted prompt block on anchor #5810 (clause 6, currently hint-comment only) is deliberately not body-patched from this session — full-body PATCH on a co-edited anchor is the #5885 corruption class; the revised clause is posted as a comment on #5810 for the maintainer's next UI re-copy (flagged as follow-through in #6162).

🤖 Generated with Claude Code

https://claude.ai/code/session_01BickTBKm2JYSNnrtPT8ysa

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
objectstack	Ignored		Aug 7, 2026 6:18am

[github-actions]

⛔ merge queue 构建失败 — 先分诊，再决定要不要重排

队列构建 31155540281 红了。队列跑的是全量套件（PR 侧 CI 只跑 affected 子集），
所以失败的测试可能在本 PR 没碰过的包里 —— 那不是重排能修的。每次盲目重排都会让排在后面的所有 PR 重建一轮。

失败的 job（日志抽取，best effort）：

• Test Core (1/3) — 失败步骤: Run this shard's tests

  �[41m�[1m FAIL �[22m�[49m scripts/build-schemas-check-mode.test.ts�[2m > �[22mbuild-schemas.ts — --update-base moves the anchor forward or not at all (#5370)�[2m > �[22mrefuses while a merge is uncomm
  �[41m�[1m FAIL �[22m�[49m scripts/build-schemas-check-mode.test.ts�[2m > �[22mbuild-schemas.ts — --update-base moves the anchor forward or not at all (#5370)�[2m > �[22mrefuses while a merge is uncomm
  �[41m�[1m FAIL �[22m�[49m scripts/build-schemas-check-mode.test.ts�[2m > �[22mbuild-schemas.ts — --update-base moves the anchor forward or not at all (#5370)�[2m > �[22mrefuses a re-anchor whose new r
  �[41m�[1m FAIL �[22m�[49m scripts/build-schemas-check-mode.test.ts�[2m > �[22mbuild-schemas.ts — --update-base moves the anchor forward or not at all (#5370)�[2m > �[22mrefuses rather than guesses whe
  �[41m�[1m FAIL �[22m�[49m scripts/build-schemas-check-mode.test.ts�[2m > �[22mbuild-schemas.ts — --update-base moves the anchor forward or not at all (#5370)�[2m > �[22man origin/main rewound BEHIND t
  

历史信号：

• 本 PR 过去 24h 无队列失败记录（首次）。
• 过去 24h 队列共有 78 个失败构建（不含本次）。

分诊清单：

1. 失败测试在本 PR 改动的包里 → 真回归，修 PR。
2. 失败测试与本 PR 无关 → 在其他 PR 的同类评论里搜同名测试；出现过 ⇒ flaky 实锤，开 issue 修/隔离那条测试。修好前重排只会再烧一轮全队列。
3. 两者都不是 → 可能与同组 PR 语义冲突；等前面的 PR 落地或失败出队后再重排一次即可，不要连续重排。

---

Generated by Claude Code · merge-queue-triage workflow (#4859)