fix(mcp): compare property schemas in checkInputNarrowing

[andriypolanski]

Summary

• Strengthen checkInputNarrowing so shared advertised/contract property subtrees are compared recursively (deep-equal or recognised narrowings only: removed nested properties, tightened bounds, enum subsets, recurse via items/properties).
• Tolerate the MCP SDK omitting additionalProperties: false that z.toJSONSchema emits for the same zod input.
• Align CurrentBranchInput / LocalScoreInput bounds with the wider contract fields they narrow, and make metrics snapshot success fields optional so a store-failure envelope validates under the SDK.

Closes #10041

Scope

• The PR title follows type(scope): short summary Conventional Commit format, for example fix(api): restore profile access checks.
• This PR is focused and does not mix unrelated backend, UI, MCP, docs, dependency, and deploy changes.
• This follows CONTRIBUTING.md and does not reintroduce GitHub Pages, VitePress, site/, or CNAME.
• I linked a currently open issue this PR resolves (e.g. Closes #123) — a linked open issue is required for every contributor PR.

Validation

• git diff --check
• npm run actionlint
• npm run typecheck
• npm run test:coverage locally; codecov/patch requires ≥99% coverage of the lines AND branches you changed (aim for 100% on your diff so CI variance does not fail near the threshold). Global coverage is a non-blocking trend with a loose 90% backstop, not the gate.
• npm run test:workers
• npm run build:mcp
• npm run test:mcp-pack
• npm run ui:openapi:check
• npm run ui:lint
• npm run ui:typecheck
• npm run ui:build
• npm audit --audit-level=moderate
• New or changed behavior has unit/integration tests for new branches, fallback paths, and sanitizer boundaries

If any required check was skipped, explain why:

• Focused local gate for this change: npx vitest run test/unit/validate-mcp-helpers.test.ts, npx vitest run test/unit/miner-mcp-ops-tools.test.ts, and npm run validate:mcp (all green). Full test:ci deferred to CI; scripts/** is outside Codecov include, and contract schema tweaks are import-time zod definitions covered by the unit/contract runs above.

Safety

• No secrets, wallet details, hotkeys, coldkeys, user PATs, private keys, raw trust scores, private rankings, or private maintainer evidence are exposed.
• Public GitHub text stays sanitized, low-noise, and does not imply compensation guarantees or optimization tactics.
• Auth, cookie, CORS, GitHub App, Cloudflare, or session changes include negative-path tests.
• API/OpenAPI/MCP behavior is updated and tested where needed.
• UI changes use live API data or real empty/error/loading states, not production mock/demo fallbacks.
• Visible UI changes include a UI Evidence section below with JPG/JPEG or PNG screenshots arranged as organized, captioned, clickable thumbnails. SVG screenshots are not used as review evidence. Review-only screenshots or recordings are not committed to the repository.
• Public docs/changelogs are updated where needed; changelogs are only edited for release-prep PRs.

UI Evidence

N/A — no visible UI change.

Notes

• Real findings fixed alongside the strengthened check: loosened shared bounds on CurrentBranchInput/LocalScoreInput, and MinerMetricsSnapshotOutput success fields made optional so cold-host store-failure envelopes no longer -32602.

Made with Cursor

[loopover-orb]

Tip

✅ LoopOver review result - approve/merge recommended

_{Review updated: 2026-07-31 08:31:08 UTC}

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

✅ Suggested Action - Approve/Merge

• safe to merge

Review summary
This closes #10041 by making checkInputNarrowing recursively compare shared property JSON-Schema subtrees (deep-equal or recognized narrowings: dropped nested properties, tightened bounds, enum subsets, recursion through items/properties) instead of only comparing property names, and tolerates the MCP SDK's omission of additionalProperties:false relative to z.toJSONSchema's output. The companion changes to miner-ops.ts (optional success fields so a store-failure envelope validates) and local-branch.ts (aligning CurrentBranchInput/LocalScoreInput bounds with the wider contract fields they narrow) are necessary to keep the stricter check from producing false positives on existing legitimate stdio overrides, so the bundling is justified rather than scope creep. The isJsonSchemaNarrowing logic is conservative by default (any unrecognized key/shape difference fails the narrowing check) and is backed by extensive new unit tests, including a nested items/properties regression case and additionalProperties:false/true edge cases.

Nits — 5 non-blocking

• scripts/lib/validate-mcp/invariants.ts:144-152 (isJsonSchemaNarrowing) compares `type` with strict `!==`, which would misjudge a structurally-equal array-valued `type` (e.g. ["string","null"]) as a mismatch — low likelihood given these schemas come from zod, but worth a comment or a jsonDeepEqual check if union types are ever emitted.
• packages/loopover-contract/src/tools/local-branch.ts:89/91/315 introduce literal caps (20, 50) for scenarioNotes/validation instead of named SCENARIO_LIMITS constants like the rest of the file uses; consider sourcing them from limits.ts for consistency with the surrounding code's convention.
• isJsonSchemaNarrowing's nesting (scripts/lib/validate-mcp/invariants.ts:144) is fairly deep (~5 levels of control flow) — consider splitting the enum/properties/items/bounds checks into small named helpers for readability, though it's well-tested as-is.
• Extract the 20/50 caps in local-branch.ts into named SCENARIO_LIMITS entries (e.g. `scenarioNotesMax`, `localValidationEntriesMax`) so the rationale in the comments is enforced by a single source rather than repeated literals.
• Consider adding a short helper (e.g. `sameJsonSchemaType`) if union-typed `type` fields ever appear, to avoid the reference-equality pitfall noted above.

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	#10041
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: 154 registered-repo PR(s), 101 merged, 22 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	andriypolanski; Gittensor profile; 154 PR(s), 22 issue(s).
Improvement	✅ Minor	risk: clean · value: minor · LLM: significant

Linked issue satisfaction

Addressed
The diff implements a recursive isJsonSchemaNarrowing comparison covering exactly the enumerated narrowings (removed nested properties, tightened bounds, enum subsets, recursion via items/properties), wires it into checkInputNarrowing to compare shared property subtrees, updates ListedTool typing usage, keeps the two original failure messages plus a new one, and adjusts the real contract fields (C

Review context

• Author: andriypolanski
• Role context: outside_contributor
• Public audience mode: oss maintainer
• Lane context: Repository is configured for direct PR review.
• Public profile languages: Python, TypeScript, Rust, Cuda, JavaScript, Kotlin, MDX, Scala
• Official Gittensor activity: 154 PR(s), 22 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 91.95%. Comparing base (21855f2) to head (bfbb2d1).
⚠️ Report is 9 commits behind head on main.

Additional details and impacted files

@@             Coverage Diff             @@
##             main   #10124       +/-   ##
===========================================
+ Coverage   79.79%   91.95%   +12.16%     
===========================================
  Files         282      931      +649     
  Lines       58690   113924    +55234     
  Branches     6892    27506    +20614     
===========================================
+ Hits        46832   104760    +57928     
+ Misses      11570     7863     -3707     
- Partials      288     1301     +1013     

Flag	Coverage Δ
backend	95.67% <ø> (?)

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

Files with missing lines	Coverage Δ
...ckages/loopover-contract/src/tools/local-branch.ts	100.00% <ø> (ø)
packages/loopover-contract/src/tools/miner-ops.ts	100.00% <ø> (ø)

... and 780 files with indirect coverage changes

[loopover-orb]

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