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

.claude/skills/pm-dispatch/SKILL.md

@@ -1338,7 +1338,8 @@ connector grant 只能传递调用会话自身持有的,CCR 平台注入的 gith
 **现役两例(都由维护者从 UI 创建、都先过一轮烟测)。** 首例是**分诊座位**(#5474):
 只扫/分类/打标签,⛔ 永不认领。第二例是维护者 2026-08-06 拍板的**三仓队列管家**(锚点
 #5810,座位贴在 `pm:seat` 索引,cron 与分诊错开半个周期),管「入队与落地 B」里入队之后的那一
-半:签名分诊四分支、队列停滞检测、跨仓 pin 链观测。**档位按职责挑,不按重要性挑** ——
+半:签名分诊四分支、队列停滞检测、跨仓 pin 链观测(含 #6162 的机械立单,见「入队与
+落地 B」)。**档位按职责挑,不按重要性挑** ——
 管家的正确性主要来自**查表**(#5810 的签名台账 + 座位贴说明段,两者都优先于它的现场
 判断)与**机械兜底**(每轮限量、双向让行、只守落地的授权面),判断面窄、判例法已写死,
 因此**不需要最强档**;吃最强档的是要现场设计取舍的执行座位。档位与 cron 一样是维护者
@@ -1637,7 +1638,7 @@ git grep "<上一单实现体符号>" origin/main -- <实现文件>        # 实
 | 谁 | 管什么 |
 |---|---|
 | **车道 PM**(权责不变) | 验收(step 7);**首次入队**(转 ready + 挂 auto-merge);确认 **MERGED** —— 每轮同时读**队列分支**与 `origin/main`(Operational notes 1) |
-| **队列管家**(三仓一座,#5810) | 入队之后的看护:红/踢出的**签名分诊四分支**、队列停滞检测、跨仓 pin 链观测 |
+| **队列管家**(三仓一座,#5810) | 入队之后的看护:红/踢出的**签名分诊四分支**、队列停滞检测、跨仓 pin 链观测及其**机械产出**(窗口收口/发版后立 bump 单,#6162,见下) |
 
 车道 PM 的「首次入队」有一个标准动作:**ACCEPT 后立即挂 6–9 分钟的 send_later
 flip 定点**,到点核对门禁 job 结论(notes 10)、绿即转 ready + 挂 auto-merge,
@@ -1668,6 +1669,25 @@ flip 定点**,到点核对门禁 job 结论(notes 10)、绿即转 ready + 挂 au
 写签名与台账依据、拦截写判定、让行写让行),让行判据因此始终是 GitHub 上的一个读数,
 不靠猜 —— 实测最紧的一次是车道回报早于管家读数 50 秒,少了这条纪律就是两份诊断。
 
+**Pin 链观测的机械产出 —— 窗口收口即立单,不等发版红灯(维护者 2026-08-07 拍板,
+#6162)。** required 新鲜度门(#3340)只防「带旧 pin 切版丢变更」,不防「切版现场才
+发现要 bump」:红灯亮在发版 PR 上时,杂事单还得有人现场立 —— #6159 实测就是靠维护者
+在聊天里问了一句才补上的(多仓协调 rule 3 的「接受时立联动单」纸面按 PR 粒度,实际
+工作按窗口节奏收口,当晚没有触发)。自本条起,管家的 pin 链观测每轮附带机械产出,
+两个触发各产一张杂事单(⛔ 仍**只立单,不执行 bump** —— 授权面一字不变):
+
+- **objectui → objectstack(发版前侧)**:`.objectui-sha` 落后 objectui main **且**
+  objectui 合并队列已空(窗口收口判据)⇒ 在 objectstack 立/刷新 console bump 单
+  (`pm:queue`;模板照 #6159:滞后读数、releasing changeset 清单、`bump-objectui.sh`
+  口径、#6099 破坏性标注复核项、与 Version Packages PR 的顺序约束)。
+- **objectstack → cloud(发版后侧)**:观测到新 rc/正式 tag 族发布 ⇒ 在 cloud 队列立
+  同款 `.objectstack-sha` bump 单(cloud 的 `check:pin-staleness` 保持 advisory 不动
+  —— 本条的产出是单,不是新门)。
+
+三条边界:**单张封顶** —— 立单前先查同题 open 单,已有就追评刷新区间与读数,⛔ 不开
+第二张;**rule 3 仍是第一产者** —— 接受座位随手立联动单照旧,本条是窗口级兜底,撞上
+由单张封顶去重;**pin 工具链新形态**(digest 盲区一类)照旧只在锚点单提请,不自行扩面。
+
 **依赖前棒才能转绿的 PR:draft 停放 + 一份精确的预期红清单。** 串行链里后棒常常先行
 实现(#5365 的四条进一致性表依赖 #5323 的 mongodb 归约才成立)。这种 PR **停在
 draft**,PR body 写两样东西:**精确的预期红清单**(逐条列失败测试名 + 报错签名)与
@@ -1859,6 +1879,17 @@ Stop the loop and report when any of these hits:
   挂队 —— 授权出处(维护者原话/指令记录)**必须引用在 PR 正文**;复核仍需
   另一个座位或维护者 walkthrough,⛔ 不得自审自合。授权是逐 PR(或逐项明示
   指令)的,不是常设豁免。
+- **版本发布必须人工(维护者 2026-08-07 拍板,#6170)。** 任何 AI 座位(PM / dev /
+  Routine / 队列管家)⛔ 不得执行或触发发布动作:跑 `changeset publish` /
+  `pnpm run release`、推版本 tag、`workflow_dispatch` 触发 Release/发布类
+  workflow、**合并 Version Packages(`chore: version packages`)PR** —— 发布只在
+  维护者亲手动作时发生。围绕发布的工作(发版板、pin bump、版本对账、发布状态
+  核验)照旧归座位;「发布」本身(把包推上 registry / 打版本 tag / 出 GitHub
+  Release / 推运行时镜像)不归任何座位。发现未经人工的发布痕迹(tag / npm 版本
+  凭空出现)按事故立案通知维护者,⛔ 不代跑任何「补救性发布」。先例:2026-08-07
+  rc.4 —— release.yml 的 on-push 自动通道在无人指令下完整发出了 rc.4
+  (#6169/#6170);机械通道的存在不构成授权 —— 读到这条的座位遇到那类通道,
+  当缺陷上报,不当工具使用。
 - Never force-push, never push `main`, never reassign an issue claimed by
   someone else, never dispatch a `needs-user-decision` issue.
 - Every dev agent works in its **own worktree per repo** (enforced by