Skip to content

An ownerless domain:docs label object routes cards to a lane that has no roster row, no lane file and no seat — measured by walking into it #13545

Description

@claude

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 skillsdocs 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

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions