You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The required freshness gate (check:objectui-pin-fresh on the Version Packages PR, #3340) prevents loss — you cannot cut a release with a stale pin — but not lateness: the red light turns on at cut time, and the bump chore still has to be filed and driven by hand at that moment. Tonight's instance #6159 was filed manually only because the maintainer happened to ask in chat; nothing mechanical converts "the objectui window has settled" into a queued action. Coordination rule 3 (the seat accepting a repo:objectui PR files the linkage chore) is per-PR on paper but the work lands per-window in practice — it did not fire tonight.
The queue steward (#5810) already carries "cross-repo pin-chain observation" as a duty, but its only outputs are briefing mentions and a hint comment — observation with no mechanical product.
Maintainer decision (2026-08-07, in the PM session; quoted verbatim)
A. 队列管家加一条例行职责(推荐,先做)。
Selecting option A of the proposal: the steward's pin watch gains a mechanical output — file-or-refresh the bump chore when a window settles. (Option B, a standing auto-bump draft PR, stays a possible later upgrade and is blocked on #6099.)
Design
Two triggers, each producing ONE chore issue (the steward still never executes the bump — its authority face is unchanged: no code, no claims, no merges):
objectstack → cloud (post-release side): 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: search for the open same-title chore first; if it exists, refresh it with a comment updating the range — never open a second.
Rule 3 stays the first producer: the accepting seat filing at accept time is still correct; this duty is the window-level backstop, and collisions are absorbed by the one-open-chore cap.
New pin-toolchain findings (digest blind spots etc.) still go to the anchor issue as 提请 only.
Implementation
.claude/skills/pm-dispatch/SKILL.md: new paragraph in 「入队与落地 B」 + the steward duty-table row + the 现役两例 enumeration (PR to follow; Fixes this issue).
Problem
The required freshness gate (
check:objectui-pin-freshon the Version Packages PR, #3340) prevents loss — you cannot cut a release with a stale pin — but not lateness: the red light turns on at cut time, and the bump chore still has to be filed and driven by hand at that moment. Tonight's instance #6159 was filed manually only because the maintainer happened to ask in chat; nothing mechanical converts "the objectui window has settled" into a queued action. Coordination rule 3 (the seat accepting arepo:objectuiPR files the linkage chore) is per-PR on paper but the work lands per-window in practice — it did not fire tonight.The queue steward (#5810) already carries "cross-repo pin-chain observation" as a duty, but its only outputs are briefing mentions and a hint comment — observation with no mechanical product.
Maintainer decision (2026-08-07, in the PM session; quoted verbatim)
Selecting option A of the proposal: the steward's pin watch gains a mechanical output — file-or-refresh the bump chore when a window settles. (Option B, a standing auto-bump draft PR, stays a possible later upgrade and is blocked on #6099.)
Design
Two triggers, each producing ONE chore issue (the steward still never executes the bump — its authority face is unchanged: no code, no claims, no merges):
.objectui-shalags objectuimainand objectui's merge queue is empty (the window-settled predicate) ⇒ file/refresh a console-bump chore in objectstackpm: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.shprocedure, objectui pin bump 生成的 console changeset 对破坏性变更零标注 —— digest 只认major声明级别,而 objectui 在 v17 窗口内把破坏性声明为minor+ 正文标注 #6099 breaking-annotation re-check, ordering constraint vs the Version Packages PR)..objectstack-shabump chore in cloud's queue (cloud'scheck:pin-stalenessstays advisory — the output is an issue, not a new gate).Boundaries:
Implementation
.claude/skills/pm-dispatch/SKILL.md: new paragraph in 「入队与落地 B」 + the steward duty-table row + the 现役两例 enumeration (PR to follow; Fixes this issue).Related
#5810 (steward anchor) · #6159 (tonight's hand-filed instance, template) · #6099 (digest breaking-annotation blind spot — prerequisite for any future auto-bump) · #6121 (adjacent freshness-workflow observation) · #3340 (the freshness gate this complements) · SKILL Multi-repo coordination rule 3