Summary
The signals layer audits a repo's configured labelMultipliers keys by comparing them as literal strings against observed/live label names, but scoring resolves those same keys as fnmatch globs. Any repo that configures a wildcard label key (e.g. type:*, kind/*, priority:?) is therefore mis-audited: its keys are reported as "not observed" / "missing" and never marked configured, even when matching labels are in active use.
Where
The authoritative matcher lives in src/scoring/preview.ts (selectLabelMultiplier / labelPatternToRegExp), which documents that upstream resolves label multipliers via fnmatch(label.lower(), pattern.lower()). The signals surfaces instead use exact membership:
src/signals/engine.ts buildConfigQuality: notObservedConfiguredLabels = configuredLabels.filter((label) => !observedLabels.includes(label))src/signals/engine.ts buildLabelAudit: configured: configuredLabels.includes(name) and missingConfiguredLabels = configuredLabels.filter((label) => !liveLabels.includes(label))
A configured key like type:* never appears verbatim on a real issue/PR or in the live label list, so the literal checks always treat it as unobserved/missing/unconfigured.
Impact
For any glob-configured repo:
buildConfigQuality emits a spurious configured_labels_not_observed finding and docks the config-quality score (up to -30) even though the labels are used.buildLabelAudit emits a spurious trusted_labels_missing finding, never sets trustedPipelineReady, and reports configured_labels_unused because no observed label is flagged configured.
These are maintainer-facing signals, so the noise undermines trust in the config-quality and label-audit reports for exactly the repos using the upstream-recommended glob label configuration.
Expected
Match configured label keys against observed/live labels using the same case-insensitive fnmatch glob semantics scoring uses (labelPatternToRegExp). Literal keys (no glob metacharacter) must keep matching only their exact label, so existing non-glob configs behave identically.
Summary
The signals layer audits a repo's configured
labelMultiplierskeys by comparing them as literal strings against observed/live label names, but scoring resolves those same keys as fnmatch globs. Any repo that configures a wildcard label key (e.g.type:*,kind/*,priority:?) is therefore mis-audited: its keys are reported as "not observed" / "missing" and never markedconfigured, even when matching labels are in active use.Where
The authoritative matcher lives in
src/scoring/preview.ts(selectLabelMultiplier/labelPatternToRegExp), which documents that upstream resolves label multipliers viafnmatch(label.lower(), pattern.lower()). The signals surfaces instead use exact membership:src/signals/engine.tsbuildConfigQuality:notObservedConfiguredLabels = configuredLabels.filter((label) => !observedLabels.includes(label))src/signals/engine.tsbuildLabelAudit:configured: configuredLabels.includes(name)andmissingConfiguredLabels = configuredLabels.filter((label) => !liveLabels.includes(label))A configured key like
type:*never appears verbatim on a real issue/PR or in the live label list, so the literal checks always treat it as unobserved/missing/unconfigured.Impact
For any glob-configured repo:
buildConfigQualityemits a spuriousconfigured_labels_not_observedfinding and docks the config-quality score (up to -30) even though the labels are used.buildLabelAuditemits a spurioustrusted_labels_missingfinding, never setstrustedPipelineReady, and reportsconfigured_labels_unusedbecause no observed label is flaggedconfigured.These are maintainer-facing signals, so the noise undermines trust in the config-quality and label-audit reports for exactly the repos using the upstream-recommended glob label configuration.
Expected
Match configured label keys against observed/live labels using the same case-insensitive fnmatch glob semantics scoring uses (
labelPatternToRegExp). Literal keys (no glob metacharacter) must keep matching only their exact label, so existing non-glob configs behave identically.