chore(miner): migrate the CLI bin entry-points to TypeScript

[bitfathers94]

chore(miner): migrate the CLI bin entry-points to TypeScript

Phase 3, batch 3.4 of the plain-.js-to-TypeScript migration proposed in
#7290 (Phase 1's tsc build pipeline landed in #7299): converts the two bin
entry-points -- bin/loopover-miner.js and bin/loopover-miner-mcp.js -- to
real, compiler-verified .ts using the same in-place-emit pattern (tsc emits
the .js/.d.ts next to each .ts source, so the published bin layout and every
consumer's import path stay identical).

The MCP bin's hand-maintained MinerMcpServerOptions interface moves from its
now-removed .d.ts sibling into the source; tsc regenerates the declaration.
Two spots needed the source to satisfy types the untyped .js never had to:
the manage-status tool widens its minimal read-surface injection seams back
to the store types collectManageStatus/collectRunPortfolio ask for (both only
ever read, so it never reaches an omitted write method), and the package.json
version read resolves via fileURLToPath(import.meta.url) rather than a new URL(...) object so it also typechecks under the repo-root tsconfig the MCP
unit tests pull this file into.

The miner-package pack allowlist gains bin/loopover-miner.d.ts (tsc now emits
one for the CLI entry, mirroring the mcp bin's existing .d.ts entry).

Closes #7308

[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.82%. Comparing base (e3e85ab) to head (86d8ea6).

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #7318   +/-   ##
=======================================
  Coverage   93.82%   93.82%           
=======================================
  Files         706      706           
  Lines       69570    69570           
  Branches    18895    18895           
=======================================
  Hits        65275    65275           
  Misses       3302     3302           
  Partials      993      993           

Flag	Coverage Δ
shard-1	43.52% <ø> (ø)
shard-2	37.49% <ø> (ø)
shard-3	32.97% <ø> (ø)
shard-4	34.24% <ø> (ø)
shard-5	32.10% <ø> (ø)
shard-6	45.68% <ø> (ø)

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

[loopover-orb]

Tip

✅ LoopOver review result - approve/merge recommended

_{Review updated: 2026-07-19 16:16:42 UTC}

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

✅ Suggested Action - Approve/Merge

• safe to merge

Review summary
This is a mechanical .js-to-.ts port of the two bin entry points, preserving the in-place-emit pattern so published output paths stay byte-identical (the .js/.d.ts diffs are pure tsc emit re-runs, confirmed by the matching content shown in FULL FILE CONTENT). The two type-driven source changes are narrow and well-explained: widening the manage-status injection seam back to the store types via an `as` cast (justified since both aggregators only read), and switching the package.json version read from `new URL(...)` to `fileURLToPath` + `join` to satisfy the repo-root tsconfig. No new logic is introduced; CI is green and the .d.ts emission for loopover-miner.ts appears wired into the pack allowlist per the description.

Nits — 6 non-blocking

• The `as PortfolioQueueStore`/`as RunStateStore` casts in loopover-miner-mcp.ts around collectManageStatus/collectRunPortfolio (bin/loopover-miner-mcp.ts:125-136) silently bypass the compiler's structural check going forward — if either aggregator later starts calling a write method the minimal seam omits, this cast will hide it until runtime; a comment justifies it today but there's no test forcing the seam and the full store to stay in sync.
• This PR adds ~1124 source lines with zero new test files; since the port is claimed to be behavior-preserving, confirm the existing MCP/CLI test suites still import and exercise these files by their new .ts source (or updated .js output) rather than any now-stale path.
• createMinerMcpServer's body is long and deeply nested by necessity (12 tool registrations) — consider whether extracting each tool's handler into a named function would make future diffs to a single tool smaller and easier to review, though this is a style call given the existing pattern predates this PR.
• Double check the miner-package pack allowlist update (scripts/check-miner-package.mjs, not inlined here) actually references bin/loopover-miner.d.ts by the same relative path used for the mcp bin's existing .d.ts entry, since a mismatch there would silently drop the file from the published tarball.
• If the repo has a lint rule against `as` casts outside test files, run it on bin/loopover-miner-mcp.ts to confirm the two seam-widening casts are allowed under this project's conventions.
• Code changes lack test evidence — Add focused regression tests or explain why existing coverage is sufficient.

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	#7308
Related work	⚠️ 3 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: 41 registered-repo PR(s), 28 merged, 0 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	bitfathers94; Gittensor profile; 41 PR(s), 0 issue(s).
Improvement	ℹ️ None detected	risk: low · value: none · LLM: moderate

Linked issue satisfaction

Addressed
The PR converts both listed bin entry-points to real .ts sources (loopover-miner-mcp.ts shown in full, with the hand-maintained MinerMcpServerOptions interface moved into source and the .d.ts sibling presumably removed since tsc regenerates it), matching the issue's stated file list and using the same in-place-emit pattern from Phase 1 as requested.

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: not available
• Official Gittensor activity: 41 PR(s), 0 issue(s).
• Related work: Titles/paths share 19 meaningful terms. (issue #7300, issue #7301)
• Related work: Titles/paths share 19 meaningful terms. (issue #7300, issue #7302)
• Related work: Titles/paths share 19 meaningful terms. (issue #7301, issue #7302)

Contributor next steps

• Start here: Review top overlaps.
• Then work through the remaining 2 steps 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.