fix(miner): wire isValidRepoSegment into the seven remaining owner/repo parsers

[bitfathers94]

fix(miner): wire isValidRepoSegment into the seven remaining owner/repo parsers

discover-cli/loop-cli's parseRepoTarget, manage-poll/purge-cli/run-state-cli's
parseRepoArg, and event-ledger/ranked-candidates's normalize helpers all split
an owner/repo string without checking either segment against the shared
path-traversal guard, so a ./../control-char value could still reach
resolveRepoCloneDir, persist into the event ledger, or land in the
ranked-candidates snapshot. Each now rejects through its own existing error
shape, matching the pattern already used in portfolio-queue-cli.ts and
claim-ledger.ts. Also drops the stale file list from repo-clone.ts's guard
comment now that every parser in the package shares it.

Closes #9684

Validation

Verified locally on this branch before opening:

• npm run typecheck
• npx turbo run build:tsc build:verify
• npm run test:coverage — patch coverage 100.0% of changed lines

[loopover-orb]

Tip

✅ LoopOver review result - approve/merge recommended

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

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

✅ Suggested Action - Approve/Merge

• safe to merge

Review summary
This PR closes issue #9684 by threading the existing `isValidRepoSegment` guard (defined in repo-clone.ts, already proven against `.`/`..`/control-char values) into the seven remaining owner/repo parsers that were splitting on `/` without checking segments, closing a real path-traversal gap for resolveRepoCloneDir, the event ledger, and the ranked-candidates snapshot. The fix is mechanical and consistent — same guard, same call shape, same existing error message per parser — and each of the seven parsers gets its own regression test asserting rejection on both the owner and repo position. The stale guard-comment cleanup in repo-clone.ts is in-scope janitorial work tied to the same guard being centralized further.

Nits — 4 non-blocking

• The regression tests only cover `../x` and `x/..`; a bare `.` segment or an embedded control character (both of which `isValidRepoSegment`/`REPO_SEGMENT_PATTERN` are documented to reject) isn't exercised anywhere in the new tests, so a future accidental narrowing of the pattern wouldn't be caught by this patch's own coverage.
• Every call site repeats the identical `if (!isValidRepoSegment(owner) || !isValidRepoSegment(repo))` two-line block seven times — consider a small shared `parseOwnerRepo(value): {owner, repo} | null` helper in repo-clone.ts if a future contributor needs to touch this logic again, though duplication at this scale is defensible for now.
• Add one test case per parser (or at least one shared one) for a bare `.` segment and a control-character segment (e.g. `"a\u0000b/repo"`) to actually exercise `isValidRepoSegment`'s documented rejection surface beyond `..`.
• Consider extracting the repeated split+validate block into a single `parseOwnerRepo` helper in repo-clone.ts now that all eight call sites share identical logic, per the updated comment's own framing of 'every parser in the package shares it.'

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	#9684
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: 101 registered-repo PR(s), 69 merged, 1 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	bitfathers94; Gittensor profile; 101 PR(s), 1 issue(s).
Improvement	✅ Minor	risk: clean · value: minor · LLM: moderate

Linked issue satisfaction

Addressed
All seven listed parsers (discover-cli, loop-cli, manage-poll, purge-cli, run-state-cli, event-ledger, ranked-candidates) now call isValidRepoSegment on both segments with their existing error shapes/names preserved, the stale repo-clone.ts comment listing unguarded files is rewritten, and a named regression test asserting '..' rejection is added for each of the seven files.

Review context

• Author: bitfathers94
• Role context: outside_contributor
• Public audience mode: oss maintainer
• Lane context: Repository is configured for direct PR review.
• Public profile languages: TypeScript
• Official Gittensor activity: 101 PR(s), 1 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

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

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #9911      +/-   ##
==========================================
+ Coverage   79.52%   79.88%   +0.36%     
==========================================
  Files         281      289       +8     
  Lines       58577    59628    +1051     
  Branches     6833     7184     +351     
==========================================
+ Hits        46581    47632    +1051     
  Misses      11706    11706              
  Partials      290      290              

Flag	Coverage Δ
backend	100.00% <100.00%> (?)

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

Files with missing lines	Coverage Δ
packages/loopover-miner/lib/discover-cli.ts	100.00% <100.00%> (ø)
packages/loopover-miner/lib/event-ledger.ts	100.00% <100.00%> (ø)
packages/loopover-miner/lib/loop-cli.ts	100.00% <100.00%> (ø)
packages/loopover-miner/lib/manage-poll.ts	100.00% <100.00%> (ø)
packages/loopover-miner/lib/purge-cli.ts	100.00% <100.00%> (ø)
packages/loopover-miner/lib/ranked-candidates.ts	100.00% <100.00%> (ø)
packages/loopover-miner/lib/repo-clone.ts	100.00% <ø> (ø)
packages/loopover-miner/lib/run-state-cli.ts	100.00% <100.00%> (ø)

[loopover-orb]

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