PR And Issue Labels

August 9, 2026 ยท View on GitHub

LoopX uses GitHub labels so maintainers, contributors, and agent monitors can filter, route, and aggregate issues and pull requests by lifecycle and product area.

Lifecycle Labels

These labels describe the item lifecycle and are applied by issue templates or maintainer triage:

LabelApplied byMeaning
bugBug report templateReproducible incorrect or unexpected behavior.
enhancementFeature request templateConcrete product or documentation improvement.
triageIssue templatesNeeds maintainer triage or routing before work starts.
duplicate / question / invalid / wontfixMaintainer triageStandard GitHub lifecycle states.
good first issue / help wantedMaintainer triageContributor onboarding signals.
workflow-auditContributor task boardPublic or synthetic agent workflows for LoopX audit.

Area Labels

Area labels describe the public product surface a change touches. Issue templates ask contributors to select an area, and pull request templates ask for a self-tagged primary area; maintainers apply the matching label:

LabelPublic surface
control-planeGoals, todos, quota, scheduler, registry, runtime, state, and gate lifecycle.
benchmark-boundaryBenchmark adapters, runners, verifiers, scoring, leaderboards, and public benchmark evidence.
capability-extensionCapability, extension, provider, adapter, or skill contracts.
public-docsREADME, protocol docs, frontstage, dashboard, and first-screen presentation surfaces.
build-or-ciBuild, packaging, installer, CI workflows, and release pipelines.

Anything not clearly covered by an area label keeps only its lifecycle label.

Triage Policy

  1. Issue templates auto-apply triage plus bug or enhancement.
  2. Maintainers (or an approved bot) move triaged items forward: route to an area label, mark duplicate/question/invalid/wontfix, or link a contributor task.
  3. Pull requests self-tag a primary area in the template. Reviewers verify the area matches the diff and correct the label when it does not.
  4. Agent monitors (PR review queue, issue intake) may read area labels as routing hints, but labels never grant review, merge, or write authority.

Staged Auto-Classification

Today labels are human-selected through templates and triage. The next stage may add a rule-based classifier that suggests area labels from title, changed files, and review areas, followed by an offline model for long-tail cases. This staged path follows the classification practice used by the OpenViking feedback observability design: start with deterministic rules as an enhancement, then move to a model, then stabilize the taxonomy. Until then, labels are guidance, not an automated contract.