Labels

Labels are a small, fixed set. Two whole categories that would otherwise be labels are not labels here: they live in first-class GitHub fields instead, and labels are reserved for the axes those fields do not cover.

What is not a label

• Kind of work is a native Issue Type (Task, Bug, Feature, Epic), set on the issue itself, never a type:* label. It maps to the conventional-commit type the eventual PR carries: Task = ci/docs/chore/refactor/test/perf, Bug = fix, Feature = feat, Epic groups a body of work. One field, filterable, with no parallel label to drift out of sync.
• Priority is a single-select field on the Omniglass Project board (High/Medium/Low), never a prio:* label. It sorts and groups on the board, where planning actually happens.

Using a label for either would duplicate a field GitHub already models, and two systems for one fact drift apart.

What is a label

Everything left is one of two prefixed families. The prefix encodes the one distinction that matters: does the label describe the issue, or does it trigger automation?

area:<subsystem> describes

The subsystem a change touches, matching the architecture glossary:

area:foundation area:api area:storage area:auth area:collection area:expr area:ui area:node

Purely descriptive: it filters the issue list by subsystem. An issue can carry more than one.

run:<task> triggers

A label that makes CI do something when it is applied. The run: prefix is a two-way promise: if a label runs automation it is named run:<task>, and if a label is named run:<task> then applying it runs that task.

Label	Applying it	Wired
run:preview	spins up a live PR preview environment; removing it tears the preview down	yes
run:build	rebuilds the release binaries and container image for the PR head on demand	reserved
run:test	runs the full test suite on demand	reserved

run:preview is live today (the PR previews guide covers it, and preview-comment.yml is the workflow behind it). run:build and run:test are reserved: the expensive build and test tiers run on every PR today, and issue #78 tracks moving them behind these labels so they run only on demand. Wire the workflow in the same PR that first relies on a reserved label, rather than leaving a label that silently does nothing.

The fixed set

That is the whole taxonomy: a native Issue Type, the Project priority field, area:*, and run:*. There are no stock GitHub labels (bug, enhancement, good first issue and the rest were removed) and no bare type:* or prio:* labels. Adding a label means either a new subsystem (area:*) or a new automation task (run:*); anything else belongs in a field.