test(signals): cover the gittensor_root branch of metadataOnly (#8325)

[philluiz2323]

Summary

• buildLocalScoreInput's metadataOnly condition (src/signals/local-branch.ts:497, scorer?.mode !== "gittensor_root" && scorer?.mode !== "external_command") had zero test coverage for the "gittensor_root" comparison, despite test/unit/local-branch.test.ts (2600+ lines) covering every other localScorer.mode value.
• Adds two tests contrasting both outcomes: mode: "gittensor_root" (metadataOnly is false — no "metadata_only" entry in scorePreview.blockedBy) versus mode: "metadata_only" (metadataOnly is true — the entry is present). Pure test-addition; no production code in local-branch.ts was changed, per the issue's explicit scope.

Note for a maintainer (per the issue's own instruction to note discrepancies rather than change behavior unilaterally): the issue description frames this as "mode: 'gittensor_root' combined with the other half... makes metadataOnly true." The actual condition is a double !== (not ===), so mode === "gittensor_root" always makes the first operand false, which always makes the whole && false — metadataOnly can never be true when mode is "gittensor_root". The tests here cover the real, current behavior (verified against the actual source and confirmed by running them) rather than the issue text's framing, which appears to have inverted the comparison. Flagging this in case it's worth a maintainer double-checking whether the intended behavior was actually the opposite of what's shipped.

Closes #8325

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 an issue, or this is small enough that the summary explains why an issue is not needed.

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:

• This PR only touches test/unit/local-branch.test.ts (test-only, no src/ production-code change) — no UI/MCP/workers/OpenAPI surface is affected. Verified via npx vitest run test/unit/local-branch.test.ts: 74/75 tests pass, including both new ones. The single pre-existing failure (local MCP git metadata collection > classifies a type change (regular file replaced by a symlink) as unknown, not modified) is an unrelated, local-Windows-only environment limitation (git/filesystem symlink support requires elevated privileges on Windows) — confirmed by reproducing it identically on a clean stash of this branch's base commit before any of this PR's changes existed; it exercises collectLocalBranchMetadata's git symlink handling, a function this PR does not touch. Coverage on the changed condition (verified directly against coverage/lcov.info): line 497's branch shows both outcomes hit (BRDA:497,35,0,2 / BRDA:497,35,1,1).

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. (N/A — no auth/session/CORS changes.)
• API/OpenAPI/MCP behavior is updated and tested where needed. (N/A — no API/OpenAPI/MCP surface changed.)
• UI changes use live API data or real empty/error/loading states, not production mock/demo fallbacks. (N/A — no UI changes.)
• Visible UI changes include a UI Evidence section below with JPG/JPEG or PNG screenshots. (N/A — no visible UI changes.)
• Public docs/changelogs are updated where needed; changelogs are only edited for release-prep PRs. (N/A.)

Notes

• No production logic changed, per the issue's explicit instruction to note behavioral discrepancies for maintainer triage rather than fix them unilaterally.

[superagent-security]

Superagent didn't find any vulnerabilities or security issues in this PR.

[loopover-orb]

Caution

🛑 LoopOver review result - fixes required

_{Review updated: 2026-07-24 15:35:13 UTC}

1 file · 1 AI reviewer · no blockers · CI failing · blocked

🛑 Suggested Action - Fix Blockers

Review summary
The AI review returned non-blocking notes for this change but did not include a separate narrative summary. Review the nits below before deciding this PR.

Nits — 3 non-blocking

• The maintainer note in the description flags a possible inversion between issue intent and actual behavior — worth a maintainer follow-up decision, but that's a documentation/product question, not a defect in this diff.
• If the maintainer confirms the issue's framing was correct and the double `!==` is itself a bug, a follow-up PR should fix `src/local-branch.ts:497` and update these two tests to match the corrected behavior.
• Consider a short comment or test-name tweak noting which specific line/condition in `local-branch.ts` each test targets, similar to other REGRESSION-tagged tests in this file.

CI checks failing

• validate
• validate-tests-merge

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	#8325
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: 1040 registered-repo PR(s), 615 merged, 126 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	philluiz2323; Gittensor profile; 1040 PR(s), 126 issue(s).
Improvement	ℹ️ Insufficient signal	risk: clean · value: insufficient-signal · LLM: minor

Linked issue satisfaction

Partially addressed
The PR adds real tests exercising the gittensor_root condition and correctly identifies that the issue's premise (gittensor_root can make metadataOnly true) doesn't match the actual `!==` logic, flagging this discrepancy for maintainer triage as instructed rather than changing production code. However, the issue explicitly asked for a case where 'the other half of the condition is false' while mod

Review context

• Author: philluiz2323
• Role context: outside_contributor
• Public audience mode: oss maintainer
• Lane context: Repository is configured for direct PR review.
• Public profile languages: Python, JavaScript, MDX, TypeScript, CSS, Cuda, HTML, Kotlin
• Official Gittensor activity: 1040 PR(s), 126 issue(s).
• PR-specific overlap: none found.

Contributor next steps

• Start here: Triage stale or unlinked PRs.

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 (CI is failing (validate, validate-tests-merge)). 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.