Summary
The score preview's label-multiplier resolution matches a repo's configured labelMultipliers keys by exact string equality, but the upstream gittensor validator matches them as fnmatch glob patterns. Any repo that configures a wildcard trusted-label key (e.g. type:*, kind/*, priority:?) has those labels silently scored at the neutral default in the preview, so estimatedMergedScore diverges from the score the validator actually awards.
Area
Signal logic
Expected behavior
selectLabelMultiplier should mirror upstream gittensor/validator/oss_contributions/label_resolution.py, where get_label_multiplier matches each configured key with fnmatch(label.lower(), pattern.lower()) and returns the highest matching multiplier. A configured key type:* should match a PR label type:bug-fix; kind/* should match kind/bug; priority:? should match priority:1. Upstream explicitly tests these patterns (kind/* -> kind/bug, type:* -> type:bug-fix, *-dev -> backend-dev, 3.*/feature -> 3.0/feature).
Actual behavior
src/scoring/preview.ts builds a Set of the literal lowercase label keys and checks membership, so a wildcard key never matches any real label and the PR falls back to defaultLabelMultiplier. A repo with { "type:*": 1.5 } and a PR labeled type:bug-fix is previewed at multiplier 1.0 instead of 1.5 — a 33% under-estimate of the merged-score projection (and the inverse error whenever the default is a penalty).
Reproduction
buildScorePreview with registryConfig.labelMultipliers = { "type:*": 1.5 } and input.labels = ["type:bug-fix"] returns scoreEstimate.labelMultiplier === 1 (expected 1.5).
Validation
A unit test drives buildScorePreview with wildcard (*, ?, [seq], [!seq]), unclosed-bracket, regex-metacharacter, multi-match, and literal label keys, asserting parity with upstream fnmatch semantics. Literal keys remain exact-match, so existing configs score identically (no regression).
Public-safety check
Summary
The score preview's label-multiplier resolution matches a repo's configured
labelMultiplierskeys by exact string equality, but the upstream gittensor validator matches them asfnmatchglob patterns. Any repo that configures a wildcard trusted-label key (e.g.type:*,kind/*,priority:?) has those labels silently scored at the neutral default in the preview, soestimatedMergedScorediverges from the score the validator actually awards.Area
Signal logic
Expected behavior
selectLabelMultipliershould mirror upstreamgittensor/validator/oss_contributions/label_resolution.py, whereget_label_multipliermatches each configured key withfnmatch(label.lower(), pattern.lower())and returns the highest matching multiplier. A configured keytype:*should match a PR labeltype:bug-fix;kind/*should matchkind/bug;priority:?should matchpriority:1. Upstream explicitly tests these patterns (kind/*->kind/bug,type:*->type:bug-fix,*-dev->backend-dev,3.*/feature->3.0/feature).Actual behavior
src/scoring/preview.tsbuilds aSetof the literal lowercase label keys and checks membership, so a wildcard key never matches any real label and the PR falls back todefaultLabelMultiplier. A repo with{ "type:*": 1.5 }and a PR labeledtype:bug-fixis previewed at multiplier1.0instead of1.5— a 33% under-estimate of the merged-score projection (and the inverse error whenever the default is a penalty).Reproduction
buildScorePreviewwithregistryConfig.labelMultipliers = { "type:*": 1.5 }andinput.labels = ["type:bug-fix"]returnsscoreEstimate.labelMultiplier === 1(expected1.5).Validation
A unit test drives
buildScorePreviewwith wildcard (*,?,[seq],[!seq]), unclosed-bracket, regex-metacharacter, multi-match, and literal label keys, asserting parity with upstreamfnmatchsemantics. Literal keys remain exact-match, so existing configs score identically (no regression).Public-safety check