fix(review): trim the Improvement signal row to a concise value rating

[nickmopen]

Summary

The optional "Improvement" signal row (#4744/#4745) rendered its Evidence cell as a wall of text — the deterministic finding sentences plus the full LLM rationale concatenated into one cell (confirmed from a live rendering). The maintainer feedback in #5101 asks for "a quick, clean, simple score/rating … not a paragraph."

This makes the cell a concise rating:

• Just the risk × value quadrant (already computed, Maintainer risk x value triage view #4745) tagged with the LLM's one-word magnitude — e.g. risk: low · value: minor · LLM: significant.
• Falls back to value: <band> when slop wasn't computed this pass (no quadrant), never fabricating a risk reading.
• The raw finding sentences and the full LLM rationale are dropped from the cell.

Bonus safety win: because only closed-enum band/magnitude names are interpolated now (never free-text finding detail or LLM rationale), the cell is public-safe by construction — so the containsPrivatePublicTerm filtering the old free-text evidence needed is removed, and the now-unused improvementEvidenceText helper is deleted.

Scope

• The PR title follows type(scope): short summary Conventional Commit format.
• This PR is focused (one row's rendering) and does not mix unrelated changes.
• This follows CONTRIBUTING.md and does not reintroduce GitHub Pages, VitePress, site/, or CNAME.
• I linked a currently open issue this PR resolves — Closes #5101.

Validation

• git diff --check
• npm run typecheck — clean on the changed files
• Vitest — the improvement-row suites updated + green: signals-coverage, queue-4, plus ai-review, ai-review-advisory, feature-activation, visual-wire (431 tests across the 6 affected files)
• Branch coverage confirmed on the changed lines (both sides of the quadrant-nullish and magnitude-ternary hit by the existing band/LLM/slop combinations)

If any required check was skipped, explain why:

• Backend-only change (src/signals/engine.ts builds PR-comment markdown text, not a UI page), so there is no UI Evidence / screenshot to attach — the output is asserted via unit tests instead.

Safety

• No secrets, wallets, hotkeys, coldkeys, PATs, trust scores, private rankings, or reward/payout fields are exposed. This change strengthens that: the cell now interpolates only closed-enum band/magnitude names, never the free-text finding detail or LLM rationale — the existing public-safety regression test is updated to assert the row is structurally leak-proof.
• Public GitHub text stays sanitized, low-noise, and implies no compensation guarantees or optimization tactics.
• API/OpenAPI/MCP behavior updated and tested where needed (N/A — internal comment rendering only).
• No changelog edited.

Notes

• The Result cell (cell 1, the deterministic band label like "✅ Minor") is untouched — the deterministic and LLM tiers are still never blended into one number (epic Epic: PR improvement signal — quality-delta scoring as the positive-axis counterpart to slop-risk #4737 design constraint 1).

Closes #5101

[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.07%. Comparing base (58f7d5d) to head (517ebbc).
⚠️ Report is 7 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #5767      +/-   ##
==========================================
- Coverage   95.07%   95.07%   -0.01%     
==========================================
  Files         581      581              
  Lines       46181    46172       -9     
  Branches    14811    14807       -4     
==========================================
- Hits        43905    43896       -9     
  Misses       1516     1516              
  Partials      760      760              

Flag	Coverage Δ
shard-1	43.42% <50.00%> (-0.53%)	⬇️
shard-2	35.97% <0.00%> (+0.23%)	⬆️
shard-3	32.22% <0.00%> (-0.06%)	⬇️
shard-4	32.81% <100.00%> (-0.14%)	⬇️
shard-5	31.33% <0.00%> (-0.43%)	⬇️
shard-6	45.02% <0.00%> (+0.38%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
src/signals/engine.ts	97.49% <100.00%> (-0.02%)	⬇️

🚀 New features to boost your workflow:

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

[loopover-orb]

Tip

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

✅ LoopOver review result - approve/merge recommended

_{Review updated: 2026-07-14 13:10:55 UTC}

3 files · 1 AI reviewer · no blockers · readiness 82/100 · CI green · clean

✅ Suggested Action - Approve/Merge

• safe to merge

Review summary
This PR replaces the verbose Improvement Evidence cell (finding sentences + full LLM rationale) with a concise `risk: X · value: Y · LLM: Z` rating, directly addressing #5101's ask for 'a quick, clean, simple score/rating.' The `improvementEvidenceText` helper and its `containsPrivatePublicTerm` sanitization are removed since only closed-enum band/magnitude strings are interpolated now, which is a legitimate simplification and closes a free-text leak surface. Tests are updated consistently across all three files to match the new cell format, including the quadrant-present/absent and LLM-tag-present/absent branches.

Nits — 3 non-blocking

• The `rating` fallback `value: ${assessment.band}` in src/signals/engine.ts uses the raw band value (e.g. `insufficient-signal`) rather than the human-readable `IMPROVEMENT_BAND_LABELS` text, which is a minor inconsistency in label polish but matches what the tests expect.
• The large multi-line comment blocks explaining the Simplify the 'Improvement' signal row to a terse score instead of a text wall #5101 rationale inline in both engine.ts and the test files are quite verbose for what the diff itself already makes clear.
• Consider whether `magnitudeTag` should also include a short label prefix consistency check against `IMPROVEMENT_BAND_LABELS` for uniformity in future signal rows.

Signal	Result	Evidence
Code review	✅ No blockers	1 reviewer
Linked issue	✅ Linked	#5101
Related work	⚠️ 2 scoped overlaps	Top overlaps are listed below; lower-confidence bulk is hidden.
Change scope	❌ 8/20	High review scope from cached public metadata (1 linked issue).
Validation posture	✅ 25/25	PR body includes validation/test evidence.
Contributor workload	✅ 10/10	Author activity: 127 registered-repo PR(s), 78 merged, 9 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	nickmopen; Gittensor profile; 127 PR(s), 9 issue(s).
Gate result	✅ Passing	No configured blocker found.
Improvement	✅ Minor	risk: clean · value: minor — Code changes are accompanied by test evidence. LLM value judgment: moderate — The PR is a well-scoped, issue-linked simplification of a specific UI cell that also incidentally removes a private-term sanitization dependency, directly matching the maintainer feedback it cites.

Linked issue satisfaction

Addressed
The PR replaces the concatenated finding-sentences + full LLM rationale with a terse quadrant/band label plus a one-word LLM magnitude tag, matching the issue's ask for a scannable score instead of a paragraph, and preserves the underlying deterministic/LLM/quadrant signals per the 'presentation change, not re-scoring' requirement. It also updates comprehensive tests across ImprovementBand × risk-

Review context

• Author: nickmopen
• Role context: outside_contributor
• Public audience mode: oss maintainer
• Lane context: Repository is configured for direct PR review.
• Public profile languages: not available
• Official Gittensor activity: 127 PR(s), 9 issue(s).
• Related work: Titles/paths share 3 meaningful terms. (issue #4801, issue #5101)
• Related work: Titles/paths share 3 meaningful terms. (issue #4803, issue #5101)

Contributor next steps

• Review top overlaps.
• Add a concise scope and risk note.
• Check active issues and PRs before submitting.

Signal definitions

• Related work = same linked issue, overlapping active PRs, or title/path similarity.
• Change scope = cached public metadata such as size labels, draft state, and review-burden hints.
• Validation posture = whether the PR provides enough public validation/test evidence for maintainer review.
• Contributor workload = public contributor activity and cleanup pressure, not a repo-wide quality failure.
• Contributor context = public GitHub/Gittensor identity context; non-Gittensor status is not a blocker.

[BETA] Chat with Gittensory

Ask Gittensory a question about this PR directly in a comment — grounded only in the same cached, public-safe facts shown above, never a new claim.

• @gittensory ask <question> answers contribution-quality Q&A with source citations and freshness.
• @gittensory chat <question> answers in natural prose from cached decision-pack facts via local inference (maintainer/collaborator; read-only).
• A plain-language @gittensory mention with a real question is routed to the closest matching read-only command automatically -- no exact syntax required.

Full command reference: https://gittensory.aethereal.dev/docs/gittensory-commands

_{🟩 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 LoopOver, a quiet PR intelligence layer for OSS maintainers.

• Re-run LoopOver review

[loopover-orb]

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