feat(signals): validate label-multiplier ranges in config quality

[jaso0n0818]

What

buildConfigQuality grades a repo's registry config but never checks that each configured label multiplier is a usable value. A non-positive, non-finite, or non-numeric multiplier (0, negative, NaN, Infinity, or a malformed raw-config value) silently misweights scoring, yet the config-quality score stays clean.

Why no linked issue

No issue is linked because this is a self-evident, self-contained enhancement to an existing internal scorer (buildConfigQuality): it adds one validation dimension alongside the existing per-label penalties, with no behavior change to any public surface, no API/schema change, and no migration. This is exactly the small, low-risk, self-explanatory change the repo's preferred (not required) linked-issue policy allows as a direct PR.

How

Adds an invalid_label_multipliers dimension: any multiplier that is not a positive, finite number is surfaced as a warning finding (named inline as label=value so a maintainer sees the offending value) and deducts from the score (10 each, capped at 30) — the same shape as the existing per-label penalties. A penalty multiplier below 1 is still positive and remains valid, so legitimate sub-1 multipliers are untouched. Distinct from configured_labels_not_observed (which checks whether a label is used, not whether its multiplier is valid). Findings-only: the ConfigQuality type is unchanged, so OpenAPI is unaffected.

How it was validated

Validated with the full local gate: npm run test:ci is green, codecov/patch is 100% on every changed line, with branch coverage of all four invalid cases (negative, zero, NaN, non-numeric) plus the valid/penalty pass-through and the null-safe no-multipliers path. Regression-checked every buildConfigQuality caller (123 tests) — normal repos with valid multipliers are unaffected. OpenAPI verified unchanged via npm run ui:openapi:check.

[loopover-orb]

Tip

🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩

✅ Gittensory review — safe to merge

2 files · 1 AI reviewer · no blockers · readiness 66/100 · CI green · unknown

✅ Approved — safe to merge

Review summary
This change adds a focused validation pass inside buildConfigQuality for configured label multipliers and reports non-positive, non-finite, or non-numeric values as a warning finding with a capped deduction. The production predicate is correct for positive sub-1 penalty multipliers and rejects the bad numeric cases the description calls out. The tests cover the main behavior and the nullish labelMultipliers path; the notable gap is mostly presentation/test clarity, not correctness.

Signal	Result	Evidence
Code review	✅ No blockers	1 reviewer
Linked issue	⚠️ Missing	No linked issue or no-issue rationale found.
Related work	✅ No active overlap found	No same-issue or scoped active PR overlap found.
Review load	✅ 20/20	Readiness component derived from cached public PR metadata and labels; size label size:S.
Validation evidence	❌ 5/25	Cached preflight status is hold.
Open PR queue	❌ 3/10	16 open PR(s), 12 likely reviewable, 4 unlinked.
Contributor context	✅ Confirmed Gittensor contributor	jaso0n0818; Gittensor profile; 684 PR(s), 7 issue(s).
Gate result	✅ Passing	No configured blocker found.

Nits — 6 non-blocking

• nit: src/signals/engine.ts:1048 has a multi-line comment that largely restates the predicate and finding text; trim it to the why if you keep it.
• nit: src/signals/engine.ts:1055 formats malformed values with String(multiplier), which can make strings containing commas/newlines ambiguous in the finding detail; consider JSON.stringify for non-number values.
• nit: test/unit/signals.test.ts:607 covers NaN as non-finite but not Infinity, even though the PR description explicitly names Infinity as an invalid case.
• nit: test/unit/signals.test.ts:617 builds the baseline repo inline on one long line, which makes it harder to see that only invalid multipliers were removed.
• src/signals/engine.ts:1055: format invalid values with a small helper so string values are unambiguous, e.g. quote strings while leaving numbers as their normal display.
• Readiness score is below the configured threshold — Use the readiness panel as advisory maintainer context; the score does not block this PR.

Review context

• Author: jaso0n0818
• Role context: outside_contributor
• Public audience mode: oss maintainer
• Lane context: Repository registration is not available in the local Gittensory cache.
• Public profile languages: not available
• Official Gittensor activity: 684 PR(s), 7 issue(s).
• PR-specific overlap: none found.

Contributor next steps

• Explain no-issue PR.
• Fix blocker.
• Expect slower review.
• Refresh registry data or choose a registered active repo.
• Link the issue being solved, or explicitly explain why this is a no-issue PR.

Signal definitions

• Related work = same linked issue, overlapping active PRs, or title/path similarity.
• Review load = cached public PR metadata such as size labels, changed paths, and preflight status.
• Open PR queue = repo-wide review pressure; it is not a PR quality failure.
• Contributor context = public GitHub/Gittensor identity context; non-Gittensor status is not a blocker.

Review details

Generated from public PR metadata and the diff. Advisory only; deterministic signals remain authoritative.

This change adds a focused validation pass inside buildConfigQuality for configured label multipliers and reports non-positive, non-finite, or non-numeric values as a warning finding with a capped deduction. The production predicate is correct for positive sub-1 penalty multipliers and rejects the bad numeric cases the description calls out. The tests cover the main behavior and the nullish labelMultipliers path; the notable gap is mostly presentation/test clarity, not correctness.

Nits (5)

• nit: src/signals/engine.ts:1048 has a multi-line comment that largely restates the predicate and finding text; trim it to the why if you keep it.
• nit: src/signals/engine.ts:1055 formats malformed values with String(multiplier), which can make strings containing commas/newlines ambiguous in the finding detail; consider JSON.stringify for non-number values.
• nit: test/unit/signals.test.ts:607 covers NaN as non-finite but not Infinity, even though the PR description explicitly names Infinity as an invalid case.
• nit: test/unit/signals.test.ts:617 builds the baseline repo inline on one long line, which makes it harder to see that only invalid multipliers were removed.
• src/signals/engine.ts:1055: format invalid values with a small helper so string values are unambiguous, e.g. quote strings while leaving numbers as their normal display.

_{🟩 Safe / merged · 🟦 Advisory · 🟨 Held for review · 🟥 Blocked / closed}

---

💰 Earn for open-source contributions like this. Gittensor lets GitHub contributors earn for the work they already do — register to start earning →.

Checked by Gittensory, a quiet PR intelligence layer for OSS maintainers.

• Re-run Gittensory review

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 95.58%. Comparing base (a39a340) to head (29a8e1c).
⚠️ Report is 3 commits behind head on main.
✅ All tests successful. No failed tests found.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #1655   +/-   ##
=======================================
  Coverage   95.58%   95.58%           
=======================================
  Files         204      204           
  Lines       22295    22301    +6     
  Branches     8053     8055    +2     
=======================================
+ Hits        21310    21316    +6     
  Misses        408      408           
  Partials      577      577           

Files with missing lines	Coverage Δ
src/signals/engine.ts	97.07% <100.00%> (+0.01%)	⬆️

🚀 New features to boost your workflow:

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.