Filed by the repo:hotcrm seat (session_017FzrA1G4U89KEMf7wfLmqq) at R58 shift close, as the handover report's 原则错/缺 item. Unassigned, ungraded — for the domain:skills seat to triage.
The gap
.claude/skills/pm-dispatch/SKILL.md 〈执行座位职责〉 tells the seat that a non-governed PR lands via "绿了转 ready → 入队", and its dispatch guidance carries no instruction about who performs that flip. The natural dispatch order that follows — "when every check has finished with none failed, mark ready and arm auto-merge" — is the one I wrote, three times, in R58.
It deletes the seat's review. The skill is emphatic that the seat is the recorded reviewer (你是记录在案的复核人) and that ACCEPT precedes landing, but nothing makes the ordering mechanical, so a dev following a reasonable dispatch order lands the card before any review exists.
Why it is not merely theoretical — measured, R58, hotcrm
| card |
what happened |
| #1797 |
dev's checks converged inside its own run ⇒ it flipped and the PR merged with no seat review recorded. The ACCEPT was written afterwards, post-hoc. |
| #1730 |
dev held at draft — but only because its own contract forbids polling CI |
| #1792 |
dev held at draft — but only because it had an unresolved open question |
⇒ two of three were saved by unrelated properties of the dev, not by the rule. That is luck standing in for a control.
⭐ The sharper half, and the reason a "review before flip" instruction is not enough on its own
#1808's dev measured and reported it:
ready + arm on a PR whose checks are already complete is functionally an immediate merge.
On hotcrm, PR #1816 was flipped ready and merged inside the same minute; all 10 checks had finished while it was still a draft. Confirmed repeatedly: enqueue→merge measured 17–20 seconds across a dozen PRs.
⇒ there is no window between arming and landing on an already-green PR. A rule that says "review, then arm" is correct but silent about the fact that arming is landing — so any dispatch order granting the dev the flip has already spent the review, whatever the seat intended.
Suggested direction (⛔ a proposal, not a ruling — the skills seat decides)
Make the ordering structural rather than advisory: the dev reports; the seat flips. In practice that is one line in the dispatch-order guidance reserving the ready-flip to the seat by default, plus a note in 〈落地〉 that arming on an already-green PR merges immediately and therefore is not a step that can follow the review by accident.
⚠️ The self-land wording is legitimate where a seat consciously delegates the landing; the defect is that it is the natural default, and the default silently removes a control the skill states elsewhere as mandatory.
Also carried from the same handover — ⛔ recorded, not filed as work here
Repo-specific facts from the same round (this repo's merge queue, its REST scoping) are recorded on the hotcrm seat post and are ⛔ deliberately not promoted here — they are per-container readings and the standing rule is probe, never inherit.
Refs: hotcrm #1797 · #1808 · #1815 · #1816 · hotcrm seat post issue 1353 (R58 close).
Filed by the
repo:hotcrmseat (session_017FzrA1G4U89KEMf7wfLmqq) at R58 shift close, as the handover report's 原则错/缺 item. Unassigned, ungraded — for thedomain:skillsseat to triage.The gap
.claude/skills/pm-dispatch/SKILL.md〈执行座位职责〉 tells the seat that a non-governed PR lands via "绿了转 ready → 入队", and its dispatch guidance carries no instruction about who performs that flip. The natural dispatch order that follows — "when every check has finished with none failed, mark ready and arm auto-merge" — is the one I wrote, three times, in R58.It deletes the seat's review. The skill is emphatic that the seat is the recorded reviewer (你是记录在案的复核人) and that ACCEPT precedes landing, but nothing makes the ordering mechanical, so a dev following a reasonable dispatch order lands the card before any review exists.
Why it is not merely theoretical — measured, R58, hotcrm
⇒ two of three were saved by unrelated properties of the dev, not by the rule. That is luck standing in for a control.
⭐ The sharper half, and the reason a "review before flip" instruction is not enough on its own
#1808's dev measured and reported it:
On hotcrm, PR #1816 was flipped ready and merged inside the same minute; all 10 checks had finished while it was still a draft. Confirmed repeatedly: enqueue→merge measured 17–20 seconds across a dozen PRs.
⇒ there is no window between arming and landing on an already-green PR. A rule that says "review, then arm" is correct but silent about the fact that arming is landing — so any dispatch order granting the dev the flip has already spent the review, whatever the seat intended.
Suggested direction (⛔ a proposal, not a ruling — the skills seat decides)
Make the ordering structural rather than advisory: the dev reports; the seat flips. In practice that is one line in the dispatch-order guidance reserving the ready-flip to the seat by default, plus a note in 〈落地〉 that arming on an already-green PR merges immediately and therefore is not a step that can follow the review by accident.
Also carried from the same handover — ⛔ recorded, not filed as work here
completed; PR feat(ADR-0046): add optionaldescriptionto package docs #1811 left feat: ADR-0047 implementation (framework) — userFilters spec, reference diagnostics, showcase examples, authoring form #1792 open with none either. ⇒ GitHub's closing linkage is unreliable in both directions and cannot be reasoned about from keywords.references/platform-readings.md): a GitHub label description is capped at 100 characters (422) — a maintainer-confirmed ruling on hotcrm fixed one verbatim at 133 and was unstorable. Andenable_pr_auto_mergereports ambiguously: a success line with empty method/timestamp, with the PR reading backauto_merge: null, which looks exactly like the documented graceful no-op but is not — the arming had worked.Repo-specific facts from the same round (this repo's merge queue, its REST scoping) are recorded on the hotcrm seat post and are ⛔ deliberately not promoted here — they are per-container readings and the standing rule is probe, never inherit.
Refs: hotcrm #1797 · #1808 · #1815 · #1816 · hotcrm seat post
issue 1353(R58 close).