docs(miner): add MCP client config example combining gittensory-mcp and gittensory-miner-mcp

[joaovictor91123]

Summary

• Adds a "Client config" subsection to packages/gittensory-miner/README.md's MCP server section with a copy-pasteable mcpServers JSON snippet registering both gittensory-mcp (ORB's hosted contributor-workflow tools) and gittensory-miner-mcp (AMS's own local state-visibility tools) in one client session.
• Cross-references the @jsonbored/gittensory-mcp README's own Client config section for generating ORB's half via init-client --print <host>.
• No source or runtime changes — documentation only.

Test plan

• New test/unit/miner-mcp-client-config-doc.test.ts: asserts the doc section exists, the JSON snippet parses and has the exact command/args shape for both servers, and the cross-reference link/anchor exists on both sides.
• npm run typecheck passes.
• npm run docs:drift-check passes.
• npm audit --audit-level=moderate: 0 vulnerabilities.
• Full local npm run test:coverage run reviewed — no failures introduced by this change (pre-existing, unrelated failures on this machine confirmed via git stash to reproduce identically on a clean main checkout).

Closes #5163

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

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #5416   +/-   ##
=======================================
  Coverage   94.45%   94.45%           
=======================================
  Files         553      553           
  Lines       44357    44357           
  Branches    14659    14659           
=======================================
  Hits        41898    41898           
  Misses       1784     1784           
  Partials      675      675           

Flag	Coverage Δ
shard-1	43.88% <ø> (-0.25%)	⬇️
shard-2	34.75% <ø> (+0.14%)	⬆️
shard-3	31.58% <ø> (+<0.01%)	⬆️
shard-4	31.22% <ø> (-0.21%)	⬇️
shard-5	32.91% <ø> (-0.39%)	⬇️
shard-6	43.94% <ø> (+0.53%)	⬆️

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

🚀 New features to boost your workflow:

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[loopover-orb]

Tip

🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩

✅ Gittensory review result - approve/merge recommended

_{Review updated: 2026-07-12 17:47:12 UTC}

2 files · 2 AI reviewers · no blockers · readiness 100/100 · CI green · clean

✅ Suggested Action - Approve/Merge

• safe to merge

Review summary
This is a docs-only PR adding a 'Client config' subsection to the miner README with a combined mcpServers JSON snippet for gittensory-mcp and gittensory-miner-mcp, plus a cross-reference to the ORB MCP README's Client config section, backed by a new unit test that validates the doc content, JSON shape, and cross-link. The change is narrow, closes the linked issue #5163, matches its description exactly, and the accompanying test meaningfully exercises the actual README content rather than a fabricated payload. CI is green and no source/runtime files are touched.

Nits — 5 non-blocking

• The cross-reference test only checks that '### Client config' exists in the ORB MCP README, not that the specific anchor '#client-config' actually resolves to that heading (anchors are usually auto-derived so this is likely fine, but it's an indirect check).
• The JSON snippet in the README is manually kept in sync with the test's expected shape; a doc edit that changes args/command without updating the test would be the only defense against drift.
• Consider generating or linking the JSON snippet from a shared fixture/constant used by both the README example and the test, to reduce future doc/test drift risk.
• packages/gittensory-miner/README.md:154 — could explicitly state that the two servers must have distinct keys in mcpServers to avoid client-side key collisions for operators who already have an existing config file.
• nit: test/unit/miner-mcp-client-config-doc.test.ts:10 scopes `extractFirstJsonBlock` to the first JSON fence in the whole miner README, so a future unrelated JSON example above `### Client config` would make this test validate the wrong block; change it to slice from `### Client config` before extracting the fence, or tell me why whole-document-first is intentional.

Signal	Result	Evidence
Code review	✅ No blockers	2 reviewers, synthesized
Linked issue	✅ Linked	#5163
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: 127 registered-repo PR(s), 74 merged, 11 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	joaovictor91123; Gittensor profile; 127 PR(s), 11 issue(s).
Gate result	✅ Passing	No configured blocker found.
Improvement	⚠️ ℹ️ Insufficient signal	risk: clean · value: insufficient-signal — Nothing measurable for the structural-improvement analyzers on this PR (e.g. no code files changed). LLM value judgment: minor — A small, well-targeted documentation addition that closes a linked issue by providing a concrete, tested example config, with limited but real value for dual-role operators.

Linked issue satisfaction

Partially addressed
The PR adds a clear Client config section with a valid JSON mcpServers snippet, explanatory text distinguishing ORB's contributor-workflow tools from AMS's state-visibility tools, and a cross-link to the ORB README, satisfying most of the issue's requirements. However, the issue explicitly specifies the new bin entry as the subcommand `gittensory-miner mcp`, while the diff registers a differently-

Review context

• Author: joaovictor91123
• 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: 127 PR(s), 11 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.

[BETA] Chat with Gittensory

Ask Gittensory a question about this PR directly in a comment — grounded only in the same cached, public-safe facts shown above, never a new claim.

• @gittensory ask <question> answers contribution-quality Q&A with source citations and freshness.
• @gittensory chat <question> answers in natural prose from cached decision-pack facts via local inference (maintainer/collaborator; read-only).
• A plain-language @gittensory mention with a real question is routed to the closest matching read-only command automatically -- no exact syntax required.

Full command reference: https://gittensory.aethereal.dev/docs/gittensory-commands

_{🟩 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 Gittensory, a quiet PR intelligence layer for OSS maintainers.

• Re-run Gittensory review

[loopover-orb]

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