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 16:19:24 UTC}

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

🛑 Suggested Action - Fix Blockers

Review summary
This PR adds two pure test cases to test/unit/local-branch.test.ts covering the previously-untested `mode !== "gittensor_root"` operand of the metadataOnly `&&` condition in buildLocalScoreInput, contrasting it against the `metadata_only` case. The tests are correct and exercise the real code path — no production code changed. Notably, the PR description transparently flags that the linked issue's framing of the bug (claiming `gittensor_root` should make metadataOnly `true`) appears to be inverted relative to actual behavior, and the author chose to test current behavior rather than silently 'fix' it — a reasonable call worth a maintainer's explicit sign-off.

Nits — 4 non-blocking

• The two FAILED CI checks ('changes', 'validate') are undetailed and this branch is 6 commits behind default — likely stale-branch fallout rather than a defect in this diff; worth a rebase to confirm.
• test/unit/local-branch.test.ts:216-217 — the first test only asserts the negative (`not.toEqual(...arrayContaining...)`); consider also asserting `blockedBy` doesn't error/degrade in some other way (e.g. snapshot the full array) for stronger regression protection, though the current assertion is sufficient to catch the described bug.
• Given the PR's own note that the issue's bug framing may be inverted from actual behavior, flag this explicitly to a maintainer before closing Add test coverage for local-branch.ts's gittensor_root metadataOnly branch #8325 — merging tests that codify current (possibly wrong) behavior without a maintainer decision risks locking in a bug rather than fixing it.
• Consider filing a follow-up issue (or amending Add test coverage for local-branch.ts's gittensor_root metadataOnly branch #8325) to resolve the discrepancy between the issue text and the actual `&&`/`!==` logic in local-branch.ts:497, so the next contributor doesn't have to re-derive this.

CI checks failing

• validate
• changes

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 gittensor_root coverage and correctly documents that the actual condition (double !==) makes metadataOnly always false when mode is gittensor_root, but this means the second test case only exercises 'metadata_only' mode rather than the 'other operand' varying while mode stays 'gittensor_root' as the issue explicitly required ('mode: gittensor_root but the other half of the condition is

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, changes)). 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.