fix(engine): don't throw rendering a track record for a login containing a blocklisted word (#6772)

[shin-core]

Summary

• PUBLIC_FIELD_BLOCKLIST catches leaked computed fields, but renderTrackRecordSummaryMarkdown ran assertPublicSummaryText over the whole rendered block — including the - GitHub login: identity line.
• A hyphen is a legal GitHub username character, so a genuine login like team-wallet, payout-bot, or coldkey-labs matches a word-boundary pattern (/\bwallet\b/iu, …) and threw while rendering that contributor's own summary.
• Fix: compose the identity line after the scan and re-insert it at its original position (index 2, right after the heading's blank line). Ordinary logins render byte-identically; every computed field (merge-rate/tenure/conduct labels, evidence URLs, counts) still goes through assertPublicSummaryText, so a genuinely-injected blocked term still fails closed.

Closes #6772

Test plan

• New root test test/unit/track-record-summary-login-blocklist.test.ts (5 cases) — required for Codecov, since this module's only prior coverage was the engine's node --test suite, which Codecov never sees:
  • REGRESSION: team-wallet, payout-bot, coldkey-labs, hotkey-ops, reward-guild, ranking-labs all render instead of throwing.
  • The login stays on its original line (no positional drift); an ordinary login still renders lowercased + markdown-escaped exactly as before.
  • Injection guard intact: a blocked term in a computed field (evidence URL) still throws.
  • A disabled summary still renders empty.
• npm run test --workspace @loopover/engine green — 588 pass / 0 fail (the existing injection test unchanged).
• npm run typecheck clean.
• Coverage: every changed line (426-455) is exercised; the file's remaining uncovered lines (348-349, 408-417) are pre-existing and outside this diff.

[superagent-security]

🚨 Contributor flagged. Click here for more info: Superagent Dashboard

[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 93.73%. Comparing base (a740bce) to head (afafb49).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #6808      +/-   ##
==========================================
+ Coverage   93.63%   93.73%   +0.09%     
==========================================
  Files         683      683              
  Lines       68148    68149       +1     
  Branches    18703    18703              
==========================================
+ Hits        63812    63881      +69     
+ Misses       3350     3255      -95     
- Partials      986     1013      +27     

Flag	Coverage Δ
shard-1	43.63% <0.00%> (-0.01%)	⬇️
shard-2	36.85% <0.00%> (+0.12%)	⬆️
shard-3	32.87% <100.00%> (+0.11%)	⬆️
shard-4	34.20% <0.00%> (+0.40%)	⬆️
shard-5	31.56% <0.00%> (-0.26%)	⬇️
shard-6	45.67% <0.00%> (-0.01%)	⬇️

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

Files with missing lines	Coverage Δ
...ckages/loopover-engine/src/track-record-summary.ts	53.06% <100.00%> (+46.89%)	⬆️

[loopover-orb]

Warning

⏸️ LoopOver review result - manual review recommended

_{Review updated: 2026-07-17 07:41:42 UTC}

2 files · 1 AI reviewer · no blockers · CI green · unstable

⏸️ Suggested Action - Manual Review

Review summary
Fixes #6772 by excluding the identity line from the blocklist scan, then re-inserting it at its original index (2) after scanning. Logic is correct: the login is composed and inserted at a fixed position that matches the array's actual shape (heading, blank line, then login), and computed fields still pass through assertPublicSummaryText so the injection guard remains intact. The splice(2, 0, ...) approach is a bit fragile since it depends on the scannedLines array always having exactly 2 lines before the insertion point, but that invariant is stable in this file and is exercised by the new positional test.

Nits — 5 non-blocking

• The `lines.splice(2, 0, ...)` in track-record-summary.ts relies on the scannedLines array always starting with exactly heading + blank line before any insertion; a future refactor that reorders those two lines would silently misplace the login with no compile-time signal — consider inserting via a named constant or building the array in final order directly with a filter for the scan.
• The large comment block above `scannedLines` (track-record-summary.ts:426-431) restates the PR description almost verbatim; could be trimmed to the non-obvious constraint (hyphen is a legal username char) per repo convention of terse WHY-only comments.
• The new test file duplicates significant setup logic with the existing packages/loopover-engine/test/track-record-summary.test.ts suite instead of extending it, per the description's justification (Codecov visibility) — worth confirming this dual-suite pattern is the established convention rather than incidental duplication.
• Consider building the final line array directly (e.g., compute login line separately, then `[heading, blank, loginLine, ...scannedRest]`) rather than splicing at a hardcoded index, to make the identity-line position self-evident from the code rather than a magic index.
• Link the PR to issue Track-record summary throws on a legitimate GitHub login that collides with the safety blocklist #6772 explicitly in the repo's tracking format if not already auto-closed by the 'Closes Track-record summary throws on a legitimate GitHub login that collides with the safety blocklist #6772' description line.

Flagged checks (non-blocking)

• Contributor trust — Contributor flagged for review

Decision drivers

• ✅ Code review — No blockers (1 reviewer)
• ✅ Gate result — Passing (No configured blocker found.)

Context & advisory signals — never blocks the verdict

Signal	Result	Evidence
Linked issue	✅ Linked	#6772
Related work	✅ No active overlap found	No same-issue or scoped active PR overlap found.
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: 44 registered-repo PR(s), 25 merged, 0 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	shin-core; Gittensor profile; 44 PR(s), 0 issue(s).
Improvement	✅ Minor	risk: clean · value: minor

Review context

• Author: shin-core
• Role context: outside_contributor
• Public audience mode: oss maintainer
• Lane context: Repository is configured for direct PR review.
• Public profile languages: TypeScript, JavaScript, Solidity, Dart, Python, CSS, PHP, Rust
• Official Gittensor activity: 44 PR(s), 0 issue(s).
• PR-specific overlap: none found.

Contributor next steps

• Start here: Add a concise scope and risk note.
• Then work through the remaining 1 step in the Signals table above.

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.

🧪 Chat with LoopOver

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

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

Full command reference: https://loopover.ai/docs/loopover-commands

🧪 Experimental — new and may change.

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

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

[JSONbored]

Please find a better implementation:

The splice(2, 0, ...) approach is a bit fragile since it depends on the scannedLines array always having exactly 2 lines before the insertion point