feat(mcp): register the 8 miner write-tools on the local stdio server

[davion-knight]

What & why

packages/loopover-mcp's miner-auto-dev profile lists loopover_open_pr, loopover_file_issue, loopover_apply_labels, loopover_post_eligibility_comment, loopover_create_branch, loopover_delete_branch, loopover_generate_tests, and loopover_file_follow_up_issue in its recommendedTools, but none were registered as local stdio tools — a contributor driving the local server could not invoke any of the write-tools the profile promises.

This registers all 8, reusing the same pure @loopover/engine spec builders the remote server (src/mcp/server.ts) already uses. Each tool returns a LOCAL-execution action spec ({ action, command, boundary }) that the caller runs with its own gh/git credentials — loopover never performs the write itself. Input shapes mirror the remote server's bounds; the test-framework enum mirrors @loopover/engine's TEST_FRAMEWORKS.

Tests

Adds test/unit/mcp-cli-write-tools.test.ts — drives the real local stdio bin over StdioClientTransport and asserts, per tool, the composed spec (e.g. loopover_open_pr → gh pr create --repo '…', loopover_create_branch → git switch -c '…') plus a zod input-rejection failure path. Updates mcp-tool-rename-aliases.test.ts for the new registered-tool count (50).

Closes #6149

[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 95.60%. Comparing base (d280ce4) to head (9949587).
⚠️ Report is 26 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #6383      +/-   ##
==========================================
- Coverage   95.60%   95.60%   -0.01%     
==========================================
  Files         599      599              
  Lines       47221    47238      +17     
  Branches    15024    15031       +7     
==========================================
+ Hits        45147    45160      +13     
- Misses       1290     1291       +1     
- Partials      784      787       +3     

Flag	Coverage Δ
shard-1	44.06% <ø> (-0.02%)	⬇️
shard-2	36.60% <ø> (-0.01%)	⬇️
shard-3	32.58% <ø> (+0.05%)	⬆️
shard-4	34.50% <ø> (-0.11%)	⬇️
shard-5	31.59% <ø> (-0.01%)	⬇️
shard-6	44.87% <ø> (-0.01%)	⬇️

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

[loopover-orb]

Warning

⏸️ LoopOver review result - manual review recommended

_{Review updated: 2026-07-16 05:52:18 UTC}

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

⏸️ Suggested Action - Manual Review

Review summary
This PR registers the 8 miner write-tools (open_pr, file_issue, apply_labels, post_eligibility_comment, create_branch, delete_branch, generate_tests, file_follow_up_issue) on the local stdio server by wiring in the existing pure `@​loopover/engine` spec builders from `packages/loopover-engine/src/miner/local-write-tools.ts`, closing a real gap where the miner-auto-dev profile promised these tools but the local server never exposed them. The imported builder names (buildOpenPrSpec, buildFileIssueSpec, buildApplyLabelsSpec, buildPostEligibilityCommentSpec, buildCreateBranchSpec, buildDeleteBranchSpec, buildTestGenSpec, buildFollowUpIssueSpec) all match exported functions in the referenced engine module, and each zod input shape's optional/required fields line up with the corresponding builder's parameter types. The added test drives the real local stdio bin via StdioClientTransport and asserts the composed command strings plus a zod-rejection path per tool, which is a real end-to-end exercise rather than a fabricated payload, and the tool-count test was correctly bumped from 42 to 50.

Nits — 5 non-blocking

• packages/loopover-mcp/bin/loopover-mcp.js:223-265 — several new numeric bounds (200, 400, 60000, 20, 500, 50, 255, 300) are inline magic numbers; naming a couple with intent-revealing constants (as WRITE_TOOL_* already does for some) would make the mirrored bounds easier to audit against src/mcp/server.ts.
• packages/loopover-mcp/bin/loopover-mcp.js — the file is now ~1644 lines; consider whether the write-tool shapes/descriptors/registrations block is a candidate for extraction into a sibling module now that it's a distinct, self-contained ~250-line slice.
• The comment claims the TEST_FRAMEWORKS array 'mirrors @​loopover/engine's TEST_FRAMEWORKS' — worth double-checking that list stays in sync if the engine's set changes, since it's duplicated rather than imported.
• Consider importing TEST_FRAMEWORKS directly from @​loopover/engine/signals/test-evidence instead of duplicating the literal array, so a future framework addition can't silently drift between the two copies.
• The 8 new tool blocks (registerStdioTool + descriptor entry + shape) are structurally identical boilerplate; a small table-driven registration helper could reduce repetition if more write-tools are added later, though the current explicit form is easy to review as-is.

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	#6149
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: 157 registered-repo PR(s), 103 merged, 0 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	davion-knight; Gittensor profile; 157 PR(s), 0 issue(s).
Improvement	✅ Minor	risk: clean · value: minor · LLM: significant

Linked issue satisfaction

Addressed
The PR registers all 8 write-tools via registerStdioTool on the local stdio server, reusing @​loopover/engine spec builders that mirror the remote server's implementations, and updates the tool-count tests plus adds dedicated success/failure-path tests per tool as required by the test coverage section.

Review context

• Author: davion-knight
• 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: 157 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 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 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.