Observed while implementing #10090 (adding pm:retriage to the loop in scripts/pm/ensure-pm-labels.sh). Same drift class as that card, different labels — filed separately rather than ridden into that PR.
scripts/pm/ensure-pm-labels.sh states in its header that "The label set IS the PM state machine (.claude/skills/pm-dispatch/SKILL.md, 'State model'): every label here is consumed by a named query or gate". Two rows of that state-model table have no gh label create entry anywhere in the script:
pm:seat — "座位登记贴 —— 协议载体,不是待分诊的工作". It has a named consumer spelled inside this very script: the domain:$D description reads "Domain lane — seat card indexed by label:pm:seat".priority:p0 — "插队:可超 batch、破轮次立即派发". Its named consumer is the lane pull order (p0 first in the total order the pm:blocking comment block quotes).
Cost of the drift is the same one #10090 records: on a repo where the label object does not exist yet, the first application depends on the applying seat remembering to create it, and a rerun of the script can never repair the gap.
⚠️ NOT mechanical — this is filed as an observation, not a graded fix, because the correct shape is a judgment nobody has recorded:
- Which loop does each belong in? The four-repo loop creates the shared state-machine vocabulary; the main-repo-only lines (
needs:contract-review, repo:*, domain:*) exist because their surface lives here. Seat registration posts look main-repo-only by the same reasoning (lanes are main-repo-only per the objectos Option B comment), while priority:p0 plausibly belongs in all four. Neither reading is pinned by existing evidence. - Is the absence deliberate? The header documents deliberate absences explicitly (the retired lanes, and the objectos exclusions from the lane and target loops). These two are named in neither list, so their absence reads as unrecorded rather than intentional — but "reads as" is not evidence.
Duplicate check: enumerated all 11 open domain:skills cards (no card on vocabulary completeness); semantic issue search returned zero for this and for its own positive control, so it was not relied on.
Generated by Claude Code
Observed while implementing #10090 (adding
pm:retriageto the loop inscripts/pm/ensure-pm-labels.sh). Same drift class as that card, different labels — filed separately rather than ridden into that PR.scripts/pm/ensure-pm-labels.shstates in its header that "The label set IS the PM state machine (.claude/skills/pm-dispatch/SKILL.md, 'State model'): every label here is consumed by a named query or gate". Two rows of that state-model table have nogh label createentry anywhere in the script:pm:seat— "座位登记贴 —— 协议载体,不是待分诊的工作". It has a named consumer spelled inside this very script: thedomain:$Ddescription reads "Domain lane — seat card indexed by label:pm:seat".priority:p0— "插队:可超batch、破轮次立即派发". Its named consumer is the lane pull order (p0 first in the total order thepm:blockingcomment block quotes).Cost of the drift is the same one #10090 records: on a repo where the label object does not exist yet, the first application depends on the applying seat remembering to create it, and a rerun of the script can never repair the gap.
needs:contract-review,repo:*,domain:*) exist because their surface lives here. Seat registration posts look main-repo-only by the same reasoning (lanes are main-repo-only per the objectos Option B comment), whilepriority:p0plausibly belongs in all four. Neither reading is pinned by existing evidence.Duplicate check: enumerated all 11 open
domain:skillscards (no card on vocabulary completeness); semantic issue search returned zero for this and for its own positive control, so it was not relied on.Generated by Claude Code