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 17:07:18 UTC}

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

🛑 Suggested Action - Fix Blockers

Review summary
This PR adds two focused unit tests covering both branches of the `metadataOnly` condition's `gittensor_root` comparison in `buildLocalBranchAnalysis`, closing a genuine coverage gap in an otherwise thoroughly-tested file. The tests are correct and well-constructed: they exercise the real production code path (no fabricated payloads), assert on the actual current behavior, and the contrast between `gittensor_root` (not metadata-only) and `metadata_only` (metadata-only) genuinely exercises both outcomes of the `&&` condition. The PR description transparently flags a discrepancy between the linked issue's framing and the actual code behavior rather than silently 'fixing' behavior to match a possibly-mistaken issue description, which is the right call per the issue's own instructions.

Nits — 3 non-blocking

• The two new test names are quite long/verbose (test/unit/local-branch.test.ts new tests) — consider tightening once the regression context is captured in the PR/issue rather than the test name itself.
• Both new tests duplicate the full `buildLocalBranchAnalysis` input scaffolding already used elsewhere in the file; a small local helper could reduce repetition, though this matches the file's existing convention of inlining each call.
• Consider having a maintainer explicitly confirm in the linked issue Add test coverage for local-branch.ts's gittensor_root metadataOnly branch #8325 whether the shipped double-`!==` behavior (metadataOnly can never be true for gittensor_root) or the issue's described behavior (metadataOnly true for gittensor_root) is the intended one, since this PR intentionally tests the former without changing code.

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), 613 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 explicit tests contrasting mode:"gittensor_root" vs mode:"metadata_only" and honestly flags that the actual condition is a double !== rather than the ===-style the issue assumed, so gittensor_root alone can never make metadataOnly true — meaning the issue's requested 'gittensor_root combined with the other half makes metadataOnly true' case is logically impossible with current code and

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

• 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

[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.