fix(miner): guard repo segments in 4 more normalizeRepoFullName parsers

[bidobird]

What

Four normalizeRepoFullName parsers only check "exactly one slash, both halves non-empty" and never call repo-clone.ts's isValidRepoSegment, so a ./../control-char owner or repo segment (e.g. "../repo", "owner/..") is accepted and persisted as a SQLite key / echoed through the sibling CLIs:

• packages/loopover-miner/lib/contribution-profile-cache.ts
• packages/loopover-miner/lib/prediction-ledger.ts
• packages/loopover-miner/lib/replay-snapshot.ts
• packages/loopover-miner/lib/run-state.ts

Issues #5831 and #7525 already rolled this exact guard out to the other ten sibling parsers; these four were missed.

Fix

Add the same isValidRepoSegment(owner) || isValidRepoSegment(repo) check each already-fixed sibling uses, imported from ./repo-clone.js — no new validation shape. The existing checks are unchanged; this only rejects the ./../control-char cases they let through.

Tests

Each file's existing malformed-repo test is extended with path-traversal cases for both the owner (../etc) and repo (owner/..) segment, matching test/unit/miner-claim-ledger.test.ts's assertion for the already-fixed siblings.

Closes #7795

[superagent-security]

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

[loopover-orb]

Warning

⏸️ LoopOver review result - manual review recommended

_{Review updated: 2026-07-22 17:31:03 UTC}

8 files · 1 AI reviewer · no blockers · CI green · dirty

⏸️ Suggested Action - Manual Review

Review summary
This PR adds the `isValidRepoSegment(owner) || isValidRepoSegment(repo)` guard (matching the description's own text, though the actual code correctly uses `!isValidRepoSegment(owner) || !isValidRepoSegment(repo)`) to the four `normalizeRepoFullName` parsers in contribution-profile-cache.ts, prediction-ledger.ts, replay-snapshot.ts, and run-state.ts that were missed when #5831/#7525 rolled this out to their siblings. The change is narrow, mechanical, and directly closes #7795 — each file imports `isValidRepoSegment` from `./repo-clone.js`, applies the identical check already used elsewhere in the codebase, and each corresponding test file is extended with `../etc` / `owner/..` traversal cases that exercise the new branch. I traced the guard placement in all four files and it sits after the existing slash-count check and before the value is used as a SQLite key, which is correct and consistent with the established pattern.

Nits — 3 non-blocking

• The `.ts` guard comment is duplicated verbatim across all four files (contribution-profile-cache.ts:61-63, prediction-ledger.ts:90-92, replay-snapshot.ts:76-78, run-state.ts:61-63) — consider a shared JSDoc note on `isValidRepoSegment` itself in repo-clone.ts rather than repeating the same block four times.
• The PR description's fix summary states the check as `isValidRepoSegment(owner) || isValidRepoSegment(repo)` without the negation, which doesn't match the actual (correct) code — worth fixing the description for clarity even though the diff itself is right.
• Consider factoring the repeated `if (!isValidRepoSegment(owner) || !isValidRepoSegment(repo)) throw new Error("invalid_repo_full_name")` line into a small shared helper in repo-clone.js given it's now duplicated across 14 sibling parsers total, to avoid a 15th copy-paste miss like 4 sibling normalizeRepoFullName parsers still skip the path-safety guard #5831/#7525 already added to every other sibling #7795 itself.

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	#7795
Related work	✅ No active overlap found	No same-issue or scoped active PR overlap found.
Change scope	✅ 20/20	Low 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: 11 registered-repo PR(s), 3 merged, 0 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	bidobird; Gittensor profile; 11 PR(s), 0 issue(s).
Improvement	✅ Minor	risk: clean · value: minor · LLM: moderate

Linked issue satisfaction

Addressed
All four named parsers now import isValidRepoSegment from ./repo-clone.js and call it on both owner and repo, matching the exact pattern used by the ten already-fixed siblings, and each file's test suite gains regression assertions for '../etc' and 'owner/..' cases.

Review context

• Author: bidobird
• Role context: outside_contributor
• Public audience mode: oss maintainer
• Lane context: Repository is configured for direct PR review.
• Public profile languages: JavaScript, Python, TypeScript
• Official Gittensor activity: 11 PR(s), 0 issue(s).
• PR-specific overlap: none found.

Contributor next steps

• Keep the PR focused and include validation evidence before maintainer review.

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 is closing this pull request on the maintainer's behalf (conflicts with the base branch — resolve and open a fresh PR). This is an automated maintenance action — to pursue this change, please open a new pull request with the issues resolved. Closed PRs may be analyzed later to improve review accuracy, but they are not automatically reopened or re-reviewed.

[codecov]

Codecov Report

❌ Patch coverage is 25.00000% with 3 lines in your changes missing coverage. Please review.
✅ Project coverage is 38.18%. Comparing base (c73f518) to head (64dbed9).
⚠️ Report is 19 commits behind head on main.

Files with missing lines	Patch %	Lines
...s/loopover-miner/lib/contribution-profile-cache.ts	0.00%	1 Missing ⚠️
packages/loopover-miner/lib/prediction-ledger.ts	0.00%	1 Missing ⚠️
packages/loopover-miner/lib/run-state.ts	0.00%	1 Missing ⚠️

❌ Your patch status has failed because the patch coverage (25.00%) is below the target coverage (99.00%). You can increase the patch coverage or adjust the target coverage.

Additional details and impacted files

@@             Coverage Diff             @@
##             main    #7999       +/-   ##
===========================================
- Coverage   91.93%   38.18%   -53.76%     
===========================================
  Files         742        4      -738     
  Lines       76037      275    -75762     
  Branches    23081       59    -23022     
===========================================
- Hits        69906      105    -69801     
+ Misses       5037      170     -4867     
+ Partials     1094        0     -1094     

Flag	Coverage Δ
control-plane	?
rees	?
shard-1	38.18% <25.00%> (-20.91%)	⬇️
shard-2	0.00% <0.00%> (-48.44%)	⬇️
shard-3	0.00% <0.00%> (-54.59%)	⬇️

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

Files with missing lines	Coverage Δ
packages/loopover-miner/lib/replay-snapshot.ts	100.00% <100.00%> (ø)
...s/loopover-miner/lib/contribution-profile-cache.ts	0.00% <0.00%> (-100.00%)	⬇️
packages/loopover-miner/lib/prediction-ledger.ts	0.00% <0.00%> (-80.60%)	⬇️
packages/loopover-miner/lib/run-state.ts	0.00% <0.00%> (-100.00%)	⬇️

... and 738 files with indirect coverage changes