Skip to content

Reclassification worklist: the 7 live pm:awaiting-maintainer carriers entered before the Maintainer-action: line existed — each is read per thread and either given its line or moved to needs-user-decision #17269

Description

@os-justin

Filed by the skills seat (session session_01MoTv7pn338AZ71owsp19gQ, 2026-09-10T01:3xZ) as the bounded follow-up promised on #17017's ACCEPT (5606849939) and its landing record: PR #17220 MERGED 2026-09-10T01:28Z (8efe2753) — pm:awaiting-maintainer now owes a line-anchored Maintainer-action: <one action a seat cannot perform> — done when <checkable evidence> on entry (references/state-machine.md §pm:awaiting-maintainerpm:retriage; SKILL.md 状态模型 row), and H55 reports an entry without it. ⛔ Filed bare and unrouted — domain:* and grading are the triage seat's. ⛔ Not a dispatch: no dev relabels cards; each item is a per-card judgement by the seat that owns the card (or the triage seat in its 逐卡改判 duty), and this card is the bounded list, not a rider on any PR.

Why it exists as a card

PR #17220 deliberately did NOT backfill the population (#17017's own constraint: 「Do not backfill the 55 in the same PR … Sequence: rule first, then a bounded reclassification worklist」). H55 renders the legacy entries as ONE census clause on the patrol anchor rather than as rows — pinned at MAINTAINER_ACTION_LINE_SINCE = 2026-09-10T00:00:00Z by updated_at — so nothing on the board will name these cards one by one. This card does.

The census, measured 2026-09-10T01:3xZ (open, non-PR, label pm:awaiting-maintainer)

repo card lane Maintainer-action: line present note
objectstack #17151 domain:services p3 no 0 comments
objectstack #17129 domain:services p3 no 0 comments
objectstack #16804 domain:cli p3 no ⚠️ also carries needs-user-decision — H25 fires today; read first
objectstack #16737 domain:services p2 no 7 comments
objectstack #15233 domain:devx p2 no 4 comments
objectui #6596 domain:skills no 6 comments
objectui #5828 domain:ui no 8 comments; oldest (2026-08-29)
hotcrm 0 carriers

Maintainer-action: in any of the seven bodies: 0 (grep over the listing payloads; comment threads not read here — that is the per-card act). Total 7 (the 55 the filing card measured were reclassified on 2026-09-09 02:29–05:12Z, per PR #17220's measurement).

The per-card act (from the landed rule)

For each card, read the whole thread, then exactly one of:

  1. the card really waits for one action only the maintainer can perform (决定已做) ⇒ post the line Maintainer-action: <the action> — done when <evidence a reader can check> in a comment (or the body), and nothing else changes;
  2. the card waits for a judgement (决定待做 — 「裁完之后」 in its own words) ⇒ the state is needs-user-decision: one label replace, plus the four-facet block if the card lacks one;
  3. neither (bookkeeping, dedup, wording — the four classes 具名不升级类 now names) ⇒ the owning seat decides it on the spot and closes or re-queues.

⛔ A batch relabel without reading each thread is the shape this rule was written to stop. Order suggested: #16804 first (double state), then by age.

Done when

Awaiting-maintainer entries (H55): 0 open … last touched before 2026-09-10T00:00:00Z on the patrol anchor's summary line, and no H55 row — i.e. every carrier either carries its line or has left the state.

Refs: #17017 (the rule; ACCEPT 5606849939) · PR #17220 (8efe2753) · references/state-machine.md · scripts/pm/check-half-states.mjs (H55, MAINTAINER_ACTION_LINE_SINCE) · #9857 (the anchor whose summary clause counts these).


Generated by Claude Code

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