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 then 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 pre-existing "one slash, non-empty halves" check is unchanged; this only rejects the ./../control-char cases it let through.

Tests

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

Closes #7795

[superagent-security]

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

[codecov]

Codecov Report

❌ Patch coverage is 0% with 4 lines in your changes missing coverage. Please review.
✅ Project coverage is 87.72%. Comparing base (299c842) to head (8cf3570).

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/replay-snapshot.ts	0.00%	1 Missing ⚠️
packages/loopover-miner/lib/run-state.ts	0.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #7837      +/-   ##
==========================================
- Coverage   88.85%   87.72%   -1.13%     
==========================================
  Files          88       92       +4     
  Lines       21214    21486     +272     
  Branches     3675     3733      +58     
==========================================
  Hits        18849    18849              
- Misses       2187     2459     +272     
  Partials      178      178              

Flag	Coverage Δ
shard-1	0.00% <0.00%> (?)
shard-2	0.00% <0.00%> (?)
shard-3	0.00% <0.00%> (?)

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

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

[loopover-orb]

Caution

🛑 LoopOver review result - fixes required

_{Review updated: 2026-07-21 15:02:22 UTC}

8 files · 1 AI reviewer · no blockers · CI failing · blocked

🛑 Suggested Action - Fix Blockers

Review summary
This PR closes a narrow, well-scoped security gap: four `normalizeRepoFullName` parsers (contribution-profile-cache, prediction-ledger, replay-snapshot, run-state) were missing the `isValidRepoSegment` guard that #5831/#7525 already applied to their ten siblings, letting `.`/`..`/control-char segments through into a SQLite key. The fix imports the shared guard from `repo-clone.js` and adds the same one-line check in all four, with matching path-traversal test cases added to each corresponding test file. This is exactly the kind of narrow, issue-linked operator-facing correctness fix this repo prioritizes, and the diff is consistent with its stated intent.

Nits — 3 non-blocking

• The `// 4 sibling normalizeRepoFullName parsers still skip the path-safety guard #5831/#7525 already added to every other sibling #7795: ...` comment is duplicated verbatim across all four files; consider a single shared JSDoc on `isValidRepoSegment` in repo-clone.ts instead of repeating the same multi-line comment four times.
• codecov/patch shows 0.00% hit despite tests exercising the new branch in each file — worth confirming coverage tooling is actually picking up these four files rather than a reporting gap.
• Since 10 siblings already have this guard and these were the stragglers, consider a regression test (e.g. a static/lint check or a single meta-test) that greps for `normalizeRepoFullName` definitions lacking `isValidRepoSegment` to prevent a future 15th sibling from being missed.

CI checks failing

• codecov/patch — 0.00% of diff hit (target 99.00%)
• validate
• validate-tests-merge

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: 6 registered-repo PR(s), 3 merged, 0 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	bidobird; Gittensor profile; 6 PR(s), 0 issue(s).
Improvement	✅ Minor	risk: clean · value: minor · LLM: moderate

Linked issue satisfaction

Addressed
The PR adds the exact isValidRepoSegment(owner)/isValidRepoSegment(repo) guard imported from repo-clone.js to all four named files (contribution-profile-cache.ts, prediction-ledger.ts, replay-snapshot.ts, run-state.ts), matching the required pattern from the ten already-fixed siblings, and adds regression tests in each corresponding test file asserting rejection of '../etc' and 'owner/..' style in

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: 6 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 (CI is failing (codecov/patch, validate, validate-tests-merge)). 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.