An ownerless domain:docs label object exists in this repo. It is reachable from GitHub's label autocomplete, it corresponds to no lane, no seat and no roster entry, and a card routed to it goes to nobody.
Measured, 2026-08-30T20:4xZ, origin/main @ 74049254
| reading |
result |
references/lanes/docs.md |
absent (present: cli · devx · director · engine · hotcrm · services · skills · spec) |
domain:docs in pm-dispatch/SKILL.md's domain table |
0 hits — positive control domain:cli hits 1 |
ensure-pm-labels.sh's lane loop |
for D in engine services devx spec cli skills — docs absent |
a pm:seat post for the lane |
none of the 13 open seat posts names it |
label objects in the domain:* family, live |
cli · devx · docs · engine · services · skills · spec = 7 |
| the roster creates |
6 — the difference is exactly domain:docs |
How it was found: it was walked into
The triage seat applied domain:docs to a p1, customer-facing card (#13539) while grading, having picked it from the live label list rather than from the roster. That routed the card to a lane with nobody in it; it has since been corrected to domain:devx and the error is recorded on the card.
⚠️ That makes this a measured trap rather than a hypothetical one: the label's only carrier in the repo's whole history was a card put there by mistake, ~40 minutes after the label was picked out of autocomplete by an actor that had just read the correct roster for four other cards in the same batch.
ensure-pm-labels.sh already states the exact harm, for the retired-lane case:
⛔ … deliberately ABSENT — recreating a retired label puts an ownerless lane back into GitHub's autocomplete.
domain:docs is the same hazard from the other direction: not a lane that was retired, but a label that was never a lane at all. The script's discipline protects against the first and cannot see the second.
Why this is a decision, not a queue item
Both available routes sit above an executor:
- (a) delete the label object. The script calls this out as "a separate, deliberate PM action", and it is destructive — ⛔ triage did not do it unilaterally.
- (b) make
domain:docs a real lane — a lane needs a roster row, a lanes/docs.md, and a seat. Creating a seat is a maintainer action.
PM recommendation: (a), delete the object. content/docs/** is not unowned — lanes/devx.md names it explicitly in its scope, along with apps/docs. So domain:docs is not a missing lane; it is a synonym for a lane that already exists, and a second name for one scope is how two seats come to believe a card is the other's.
Not measured, stated so nobody assumes it was
Only the domain:* family was compared against its roster. Whether other label families (repo:*, pm:*, needs:*) carry the same kind of off-roster object was not checked, and this card does not claim they are clean. A cheap generalisation for whoever takes this: compare every live label against the vocabulary ensure-pm-labels.sh names, and report the objects that no roster creates — the script explicitly never touches labels it does not name, so that set can only grow silently.
Provenance
Filed by the triage seat (#6015). ⛔ Nothing was edited, no label object was created or deleted, and no PR was opened. Filed over REST to keep the body intact; that channel records the author as claude[bot] rather than os-project-manager — same seat, different transport.
Generated by Claude Code
An ownerless
domain:docslabel object exists in this repo. It is reachable from GitHub's label autocomplete, it corresponds to no lane, no seat and no roster entry, and a card routed to it goes to nobody.Measured, 2026-08-30T20:4xZ,
origin/main@74049254references/lanes/docs.mddomain:docsinpm-dispatch/SKILL.md's domain tabledomain:clihits 1ensure-pm-labels.sh's lane loopfor D in engine services devx spec cli skills— docs absentpm:seatpost for the lanedomain:*family, livecli · devx · docs · engine · services · skills · spec= 7domain:docsHow it was found: it was walked into
The triage seat applied
domain:docsto a p1, customer-facing card (#13539) while grading, having picked it from the live label list rather than from the roster. That routed the card to a lane with nobody in it; it has since been corrected todomain:devxand the error is recorded on the card.ensure-pm-labels.shalready states the exact harm, for the retired-lane case:domain:docsis the same hazard from the other direction: not a lane that was retired, but a label that was never a lane at all. The script's discipline protects against the first and cannot see the second.Why this is a decision, not a queue item
Both available routes sit above an executor:
domain:docsa real lane — a lane needs a roster row, alanes/docs.md, and a seat. Creating a seat is a maintainer action.PM recommendation: (a), delete the object.
content/docs/**is not unowned —lanes/devx.mdnames it explicitly in its scope, along withapps/docs. Sodomain:docsis not a missing lane; it is a synonym for a lane that already exists, and a second name for one scope is how two seats come to believe a card is the other's.Not measured, stated so nobody assumes it was
Only the
domain:*family was compared against its roster. Whether other label families (repo:*,pm:*,needs:*) carry the same kind of off-roster object was not checked, and this card does not claim they are clean. A cheap generalisation for whoever takes this: compare every live label against the vocabularyensure-pm-labels.shnames, and report the objects that no roster creates — the script explicitly never touches labels it does not name, so that set can only grow silently.Provenance
Filed by the triage seat (#6015). ⛔ Nothing was edited, no label object was created or deleted, and no PR was opened. Filed over REST to keep the body intact; that channel records the author as
claude[bot]rather thanos-project-manager— same seat, different transport.Generated by Claude Code