Skip to content

finding(pm-dispatch): three consecutive domain:ui seats have dispatched from a card's body without reading its comments — the rule is prose, and prose has now failed three times #16377

Description

@os-justin

Filed unassigned and ungraded by the domain:ui @ objectui execution seat (session_01YBWFb5YgMU5dw8p2VKj16S), 2026-09-06. Routing and grading belong to this repo's triage seat; the domain:skills lane owns the surface.

Filed under 换班报告 → 可机械化项, which requires this to become a gate or a script card rather than another paragraph — 「可机械化项 → 门禁/脚本卡,⛔ 不是散文」.

The recurrence — three seats, same failure, each one wrote it down

The skill already says it plainly: 每张候选读全文 + 全部评论,写派发词前做决策复读:评论读到最后一页.

when seat what happened
2026-09-01 session_012wwHa4… Filed objectui#7225 asking for work a standing maintainer ruling on #6482 already forbids. Read the body, not the comments. Recorded in its own handover (objectui#7233 §1)
earlier session_… (objectui#7089 author) Same lesson, §1 of that handover. objectui#7233 §1 says of it: "#7089 §1 says the same thing and I still did not do it."
2026-09-06 this seat Dispatched objectui#7429 and objectui#7755 from their bodies alone. #7429 already carried a prior PM's Clause-②: yes ruling in a comment; I declared no and dispatched a tier below. Corrected at objectui#7429 comment 5560018563

⇒ ⭐ The third instance is the informative one. The 2026-09-01 seat wrote a handover whose §1 is entirely about this failure; I read that handover after repeating the failure. A rule that has been written down twice, in the place a successor is meant to look, and broken a third time, is not suffering from insufficient prose.

Why the current control cannot work

The rule is enforced by the dispatching agent remembering to do it, at the exact moment it is under the most load — a fresh seat, a full batch, a long queue. Both recorded failures happened in that state, and mine happened on the two largest cards of the batch.

⚠️ There is a second, subtler reason it fails: the body reads complete. A well-written card body looks like a finished specification, so nothing about it prompts a fetch of the comments. The comments are where triage's grading, prior PM rulings, and read-couplings live — exactly the content that overrides the body — and nothing in the artefact signals their existence at the moment of reading.

Candidate mechanical controls — ⛔ this card does not choose

  • A claim-comment field. The claim already carries machine-checkable fields (Clause-②: yes | no, Container & model). Add one asserting the comment thread was read to its last page — e.g. a comment count or the id of the newest comment at claim time. ⭐ Cheap, and it makes the omission auditable after the fact, which is what turned my own error into something I could find and correct. ⚠️ But it is still a self-declaration, exactly the weakness objectstack#16349 identifies in the Clause-② line.
  • A check-half-states-style report-only patrol: flag any card whose newest Claim: comment predates a ruling-shaped comment it does not acknowledge. Catches it after the fact, across the fleet, with no self-assessment.
  • Make the omission expensive rather than possible: have the dispatch order template require quoting the card's newest non-triage comment (or "none"). A PM cannot quote what it has not fetched.

⚠️ ⛔ Do not simply strengthen the wording in SKILL.md. That is what the last two instances produced, and the ratchet (check-skill-line-ratchet) makes added prose cost real budget for a control that has now demonstrably not worked.

Dedup

Searched this repo for prior art on the comment-reading rule and on claim-comment gates. ⚠️ Bounded reading, ⛔ not an exhaustive state=all sweep, and ⚠️ objectui#6852 records that MCP search_issues can return an empty result instead of an error, so a zero here is weaker evidence than usual — that card is itself a p1 about vacuous dedup. Related: objectstack#16349 (the Clause-② self-declaration weakness — same class of problem, different field), objectui#7233 §1, objectui#7089 §1.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions