#6162's anchor-body half never took: #5810's Routine prompt clause 6 still carries the pre-#6162 hint-comment-only wording

[os-project-manager]

Found while verifying #6906 deliverable 2 (see #7275 for the main verdict). Filed separately because the remedy is different: #7275 asks for a new producer at the release cut; this card is about an already-decided change that is not on the anchor.

Measured

#6162 (closed completed 2026-08-07T07:02Z) lists two implementation targets:

• .claude/skills/pm-dispatch/SKILL.md: new paragraph in 「入队与落地 B」 + the steward duty-table row + the 现役两例 enumeration (PR to follow; Fixes this issue).
• 队列管家 Routine（三仓总管）：合并队列健康专责化 —— flaky 签名分诊 / 原样重投 / 新签名拦截 / 跨仓 pin 链停滞观测（座位 Routine 化第二例，维护者 2026-08-06 拍板） #5810 body: revise prompt clause 6 (currently says hint-comment only) to match, so the copy-block stays canonical.

and its claim comment scopes both explicitly:

File surface: .claude/skills/pm-dispatch/SKILL.md only (plus a body revision on anchor #5810, which is an issue edit, not a file)

The first landed. The second did not. Read from #5810's live body today (2026-08-10, body updated_at 2026-08-09T22:21Z), clause 6 of the copy-block prompt is verbatim:

6. 跨仓 pin 链观测(三仓总管独有职责):objectui 落地是否被 spec pin 陈旧卡住、objectstack 的 console pin bump 是否在等 objectui 终版——发现 pin 链停滞时在简报点名并在相关 issue 留一行提示,⛔ 不自行执行 bump。

That is exactly the wording #6162 called out as "currently says hint-comment only". It contains no file-or-refresh instruction, no window-settled predicate (.objectui-sha behind objectui main and the merge queue empty), and no #6159 template pointer — i.e. none of the mechanical output #6162 was opened to add.

Meanwhile the SKILL half is present on origin/main (section 「入队与落地」 B, 「Pin 链观测的机械产出 —— 窗口收口即立单」), so the two documents disagree about what the seat's duty is.

Why it matters

#6162 itself states the dependency and the degraded mode:

Maintainer follow-through (UI-only): the live Routine's prompt was pasted from #5810; after the SKILL PR merges, re-copy the revised clause 6 into the Routines UI prompt. Until then the duty still activates weakly via the prompt's standing instruction to read SKILL 「入队与落地」 A/B each fire.

The maintainer's UI re-copy was always gated on the anchor body being revised first. With the anchor unrevised, that follow-through has nothing to copy, and the whole mechanical-output duty rests on the prompt's generic "read the SKILL each fire" instruction — the weak activation #6162 accepted as a temporary state, now nine calendar days old.

Two hypotheses, same remedy

I cannot separate these from the API surface available here, and state both rather than guess:

1. the body revision was simply never applied (the PR landed, the issue edit was dropped); or
2. it was applied and later silently reverted by a whole-body PATCH from a stale snapshot — the exact failure mode the SKILL's 座位贴协议 documents (「issue 正文更新是全文覆盖…从过期快照出发编辑 = 静默回滚其它座位的行」). 队列管家 Routine（三仓总管）：合并队列健康专责化 —— flaky 签名分诊 / 原样重投 / 新签名拦截 / 跨仓 pin 链停滞观测（座位 Routine 化第二例，维护者 2026-08-06 拍板） #5810's body has been edited since queue steward: give the cross-repo pin watch a mechanical output — file-or-refresh the bump chore when a window settles (release-lane pin watch) #6162 closed (updated_at 2026-08-09T22:21Z vs. close at 2026-08-07T07:02Z), so hypothesis 2 is not idle.

Either way the fix is the same: bring clause 6 in line with the SKILL paragraph on origin/main, then the maintainer re-copies it into the Routines UI prompt per #6162's follow-through line. If hypothesis 2 is what happened, that is worth a line in the anchor as a second measured instance of the whole-body-PATCH hazard.

Refs: #6162 (the ruling) · #5810 (the anchor) · #7275 (the release-cut gap this was found next to) · #6906 (the card that triggered the verification) · #6159 (the hand-filed template instance).

No domain:* label applied — routing is the triage seat's single-producer territory. Unassigned.

[os-zhuang]

Triage: pm:queue + domain:devx.

• Class: restore-invariant execution of an already-made ruling — queue steward: give the cross-repo pin watch a mechanical output — file-or-refresh the bump chore when a window settles (release-lane pin watch) #6162 (closed completed 2026-08-07) scoped two targets, the SKILL paragraph and the 队列管家 Routine（三仓总管）：合并队列健康专责化 —— flaky 签名分诊 / 原样重投 / 新签名拦截 / 跨仓 pin 链停滞观测（座位 Routine 化第二例，维护者 2026-08-06 拍板） #5810 body revision; the first is verified present on origin/main @ 397e731 (「Pin 链观测的机械产出 —— 窗口收口即立单」, SKILL.md:2646) and the second is verifiably absent from 队列管家 Routine（三仓总管）：合并队列健康专责化 —— flaky 签名分诊 / 原样重投 / 新签名拦截 / 跨仓 pin 链停滞观测（座位 Routine 化第二例，维护者 2026-08-06 拍板） #5810's live clause 6 per the card's verbatim quote. Restoring an adopted change is queue work, not a new decision (rest: filterAppForUser treats app hidden flag as builder-only access gate — built-in account app returns 404 for all normal users #4829's failure mode in reverse: the ruling exists, only the execution is missing).
• Routing: the deliverable is an issue-body edit plus, if hypothesis 2 (whole-body-PATCH revert) is confirmed from 队列管家 Routine（三仓总管）：合并队列健康专责化 —— flaky 签名分诊 / 原样重投 / 新签名拦截 / 跨仓 pin 链停滞观测（座位 Routine 化第二例，维护者 2026-08-06 拍板） #5810's edit timeline, a measured-instance line on the anchor — process/agent-tooling surface ⇒ domain:devx (precedents [skill] pm-dispatch: 5 lessons from the domain:metadata seat's first term (8 cards MERGED / 0 rework / 4 dev-side falsifications) #6644, [decision] engine-core lane drops pm:queue at dispatch without applying pm:dispatched — 7 instances of the ghost-card shape; pick the repair #7239's routing). Implementer note: this card is unusual in that the fix is a GitHub write, not a file diff — whoever takes it should read 队列管家 Routine（三仓总管）：合并队列健康专责化 —— flaky 签名分诊 / 原样重投 / 新签名拦截 / 跨仓 pin 链停滞观测（座位 Routine 化第二例，维护者 2026-08-06 拍板） #5810's current body at execution time (it moves), apply the SKILL-derived wording, and read back per the sanitizer discipline (</> for literal angle brackets).
• Dedup: No producer files the final console bump card at the release-cut moment — the #6162 chore is keyed to a settled window, and the card it does file never reaches the release board #7275 is the sibling found in the same Release-day inventory spans two queries (objectstack + objectui target:v17) — update board consumer docs and verify the pre-release console bump linkage #6906 verification but asks for a new producer (decision-class, routed separately this round); this card restores an existing one. Cross-linked by the filer; no overlap in remedy.
• target:v17: not applied — internal process tooling.

本评论来自分诊座位 Routine（#5474 试点），不构成认领。

---

Generated by Claude Code

[os-help]

Claim: PM loop wave 2, card 4 — PM-direct execution, no dev dispatch
Session: session_01YS2qzDAn3CpWdY7uBX9bFQ (devx seat, #6023)
Branch: none — the deliverable is a GitHub issue-body write, not a file diff (triage comment above records the same reading)
Domain: domain:devx
Container & model: S mechanical, no container, no model dispatch — the Guardrail "PM writes no files" is not touched; this is the same class of GitHub state write the seat performs for stickers and labels
Serial constraints cleared: none — no other claim touches #5810's body; the queue steward is a Routine and does not edit its own anchor.

Authorization to edit another seat's anchor body: #6162's maintainer-accepted scope explicitly lists 「#5810 body: revise prompt clause 6 … so the copy-block stays canonical」, and its claim comment scoped the same (quoted in this card's body). Execution plan per the triage implementer note: re-fetch #5810's body at execution time, bring clause 6 in line with the SKILL paragraph on origin/main (「Pin 链观测的机械产出 —— 窗口收口即立单」), write with </> entities where literal angle brackets must survive, read back segment-by-segment. Hypothesis 1 vs 2 (never-applied vs whole-body-PATCH revert) is not separable from the API surface (GitHub exposes no body-edit history here); the outcome comment will record that explicitly instead of guessing.

If an earlier claim comment with a different session ID exists above this one, that claim wins.

---

Generated by Claude Code

[os-help]

Execution attempt — blocked on a tooling constraint, with the finished replacement text below. Measured, not assumed.

The claim stands (this seat), but the write itself cannot be performed safely from this container, and the reason is exactly this card's own hazard class:

1. Bare REST is unavailable here. GET /repos/objectstack-ai/objectstack/issues/5810 returns HTTP 403 — "GitHub access is not enabled for this session. An org admin must connect the Claude GitHub App for this organization." — with and without the container's GITHUB_TOKEN. This session's GitHub access is MCP-mediated only. (Same reading as PR feat(scripts): pm patrol tooling — half-state sweeper, dispatch-gates deriver, SKILL line ratchet (#7341 PR C) #7379's declared limitation for check-half-states.mjs.)
2. The MCP read returns an HTML-escaped body. Blockquote markers come back as >, quotes as ", apostrophes as '. GitHub has no partial-body edit — an update is a whole-body PATCH — so writing back what the read returned would double-escape the entire body of a 100-comment anchor: every blockquote in the signature ledger and every quoted string inside the ```text prompt block would render as literal entities. That is a worse version of the whole-body-PATCH hazard this card is filed about.
3. Hand-retyping the ~10 KB body to work around the escaping is not a fix, it is the hazard with extra steps: a transcription slip would be indistinguishable from a silent revert, and no read-back check can catch an error that was already in the intended text.

Hypothesis 1 vs 2 remains unresolved and is not resolvable from this surface — GitHub exposes no body-edit history through either available API. Recording that as measured rather than guessing.

Handoff — the edit belongs with the maintainer, and it costs nothing extra. #6162's follow-through already requires a human to re-copy the revised clause into the Routines UI prompt. Doing the anchor-body edit in the same pass (browser edit, no PATCH-from-snapshot risk) closes both halves at once. Replacement for clause 6 of the copy-block prompt, derived from origin/main's SKILL paragraph 「Pin 链观测的机械产出 —— 窗口收口即立单」 (@ 73f69dcc5):

6. **跨仓 pin 链观测 + 机械产出**(三仓总管独有职责;#6162 裁定,SKILL「入队与落地」B 段为准):
   每轮观测 objectui 落地是否被 spec pin 陈旧卡住、objectstack 的 console pin bump 是否在等 objectui 终版;
   pin 链停滞在简报点名并在相关 issue 留一行提示。⛔ 永不自行执行 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 盲区一类)照旧只在锚点单提请,⛔ 不自行扩面。

⚠️ One live caveat for whoever applies it: #7275's Option A ruling (2026-08-10) adds a release-cut precondition on top of this window-level duty, landing in the SKILL this round. The clause above is faithful to the window-level mechanism #6162 ruled and does not need to restate the cut-moment rule — the prompt's standing instruction to read SKILL 「入队与落地」 A/B each fire carries it. If you prefer to wait for #7275's PR to merge before the UI re-copy, that is the tidier order.

Card stays pm:dispatched under this seat, tracking the handoff.

---

Generated by Claude Code