feat(signals): add test-coverage classification to test-evidence

[jaso0n0818]

Add classifyTestCoverage() which maps a list of changed paths to a TestCoverageClassification band — strong (≥40% test ratio), adequate (≥20%), weak (>0% but below 20%), or absent (no test files at all).

Slop signals currently detect the presence of any test file but have no lightweight way to express how well-covered a change is relative to its source footprint. This helper fills that gap: callers pass the full list of changed paths and receive a single band they can include in advisory output or weight against the contribution score.

[ghost]

Tip

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

✅ Gittensory review — safe to merge

2 files · 2 AI reviewers · no blockers · readiness 93/100 · CI green

✅ Approved — safe to merge

Review summary
The PR introduces a new `classifyTestCoverage` helper with comprehensive unit tests. The implementation correctly handles empty inputs, counts test files using existing `isTestPath`, and applies the specified ratio thresholds. All CI checks pass, and no build or runtime issues are evident.

Suggestions

• Consider exporting `classifyTestCoverage` from the module's public index if it should be used elsewhere.
• Document the behavior when the input list contains non‑file entries (e.g., directories) to clarify ratio calculation.
• Add a test case for duplicate paths to ensure the function's behavior is well‑defined in that scenario.
• Consider adding a comment explaining why the ratio thresholds (40%, 20%) were chosen.
• The function `classifyTestCoverage` could benefit from early returns to reduce nesting.

Risks

• If callers pass a mixed list containing many non‑source files (e.g., docs), the coverage ratio may be lower than expected, potentially affecting downstream weighting.
• The classification bands (`strong`, `adequate`, `weak`, `absent`) are subjective and may not align with all users' expectations.

Signal	Result	Evidence
Code review	✅ No blockers	2 reviewers, synthesized
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	✅ 25/25	PR body includes validation/test evidence.
Open PR queue	✅ 10/10	0 open PR(s), 0 likely reviewable.
Contributor context	✅ Confirmed Gittensor contributor	jaso0n0818; Gittensor profile; 1360 PR(s), 5 issue(s).
Gate result	✅ Passing	No configured blocker found.

Nits — 1 non-blocking

• No linked issue detected — If this PR is intended to solve an issue, link it explicitly in the PR body.

Review context

• Author: jaso0n0818
• Role context: outside_contributor
• Public audience mode: oss maintainer
• Lane context: Repository is configured for direct PR review.
• Public profile languages: Python, Rust, Shell, C++, Dart, Ruby, Scala, TypeScript
• Official Gittensor activity: 1360 PR(s), 5 issue(s).
• PR-specific overlap: none found.

Contributor next steps

• Explain no-issue PR.
• 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.

The PR introduces a new `classifyTestCoverage` helper with comprehensive unit tests. The implementation correctly handles empty inputs, counts test files using existing `isTestPath`, and applies the specified ratio thresholds. All CI checks pass, and no build or runtime issues are evident.

Suggestions

• Consider exporting `classifyTestCoverage` from the module's public index if it should be used elsewhere.
• Document the behavior when the input list contains non‑file entries (e.g., directories) to clarify ratio calculation.
• Add a test case for duplicate paths to ensure the function's behavior is well‑defined in that scenario.
• Consider adding a comment explaining why the ratio thresholds (40%, 20%) were chosen.
• The function `classifyTestCoverage` could benefit from early returns to reduce nesting.

Risks

• If callers pass a mixed list containing many non‑source files (e.g., docs), the coverage ratio may be lower than expected, potentially affecting downstream weighting.
• The classification bands (`strong`, `adequate`, `weak`, `absent`) are subjective and may not align with all users' expectations.

_{🟩 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

[superagent-security]

Superagent didn't find any vulnerabilities or security issues in this PR.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 95.28%. Comparing base (d7f4ccf) to head (608b271).
⚠️ Report is 25 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #1046   +/-   ##
=======================================
  Coverage   95.28%   95.28%           
=======================================
  Files         149      149           
  Lines       18053    18060    +7     
  Branches     6535     6539    +4     
=======================================
+ Hits        17202    17209    +7     
  Misses        363      363           
  Partials      488      488           

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

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

[ghost]

🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨

🛠️ Maintainer review — Held for maintainer review

Reviewed 2 changed file(s) — two independent AI reviewers, synthesized. ✅ Safe to merge — both reviewers found no blocking issues.

ℹ️ Correct and all CI green — held for maintainer review.

Merge readiness: ✅ Mergeable · all CI checks green/neutral/skipped.

Summary

The change introduces a pure utility for classifying test coverage and adds comprehensive unit tests. The implementation follows project conventions, does not expose any security concerns, and all CI checks pass. No correctness or safety defects are found.

💡 Nits — non-blocking, optional

• Test description contains unusual Unicode characters (â��) which could be cleaned up.
• Add edge‑case tests for ratios exactly 0.2 and 0.4 to verify threshold boundaries.
• Consider normalizing paths (e.g., using path.sep) before applying regexes for cross‑platform consistency.
• Replace the non‑ASCII dash in the test description with a plain hyphen for readability.
• Consider adding more edge cases in the tests, such as empty strings or invalid file paths.

[ghost]

Held for maintainer (guardrail_area) — correct + CI green

[ghost]

Gittensory approves — the gate is satisfied and CI is green.