fix(signals): count focused validation runs as passing evidence

[glorydavid03023]

Summary

A local validation command with status: "focused" is a green run of a subset of tests (e.g. vitest run path/to/file.test.ts). The PR-packet validation summary (summarizeValidation), the freshness evidence list (validationEvidence), and services/pr-body-draft.ts already count a focused run as passing evidence — but two surfaces still matched only "passed", so the same focused run was credited or dropped depending on where you looked:

• src/signals/local-workspace-intelligence.ts passedValidationCount counted only "passed", so a focused-only run collapsed testEvidence.level to "none" instead of "validation_commands".
• src/signals/local-branch.ts — the validation_as_test_evidence local finding fired on .some(status === "passed") only, so it never surfaced for a focused run.

This single-sources the rule as an exported isPassingValidation(entry) predicate ("passed" || "focused") and routes all four sites through it, so the evidence surfaces agree by construction and cannot drift apart again. Pure deterministic signal logic — no schema, OpenAPI, or API change.

No issue because issue creation is restricted on this repo for outside accounts; this is a small, self-evident consistency fix.

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 ≥97% coverage of the lines AND branches you changed (aim for 98%+ 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 is a backend-only change confined to src/signals/**, so the UI / MCP-package / OpenAPI / workers-pool steps are not exercised by the diff and were not run locally (the local Windows working tree has pre-existing, unrelated failures from CRLF line endings and missing optional CLI binaries that do not occur in CI's Linux environment). CI runs the full validate matrix on a clean checkout. The changed lines and both branches of the new predicate are fully covered by the added tests.

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/cookie/CORS/session changes.
• API/OpenAPI/MCP behavior is updated and tested where needed. (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 change.
• Visible UI changes include a UI Evidence section below with JPG/JPEG or PNG screenshots. — N/A: no visible UI change.
• Public docs/changelogs are updated where needed; changelogs are only edited for release-prep PRs. (No docs/changelog change needed.)

Notes

• Added a direct unit test for isPassingValidation (covering passed, focused, and the non-passing statuses) plus regression tests through buildLocalBranchAnalysis and buildLocalWorkspaceIntelligence that assert a focused run yields passedValidationCount === 1, testEvidence.level === "validation_commands", and the validation_as_test_evidence finding.
• No UI Evidence section: there is no visible UI, frontend, docs, or extension change.

[loopover-orb]

Tip

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

✅ Gittensory review result - approve/merge recommended

_{Review updated: 2026-06-30 22:35:07 UTC}

4 files · 1 AI reviewer · no blockers · readiness 75/100 · CI green · unknown

✅ Suggested Action - Approve/Merge

• safe to merge

Review summary
The change correctly single-sources the definition of passing local validation and applies it to the finding, PR-packet summary, freshness evidence, and workspace-intelligence count. The regression tests exercise the focused-run path through the production analysis flow and also pin the predicate’s accepted statuses, so the visible diff is consistent with the PR description. The only notable maintainability concern is that the helper now lives in a broad module and is imported as a runtime value by another signals module, which may be worth isolating if these modules already depend on each other.

Nits — 4 non-blocking

• nit: src/signals/local-workspace-intelligence.ts:1 now imports a runtime helper from src/signals/local-branch.ts; if local-branch already imports workspace intelligence, consider moving isPassingValidation to a small shared leaf module to avoid circular coupling.
• nit: src/signals/local-branch.ts:46 the helper comment lists every current consumer, which can drift as callers change; the status rule itself is the durable contract.
• src/signals/local-branch.ts:46 consider shortening the comment to the semantic rule and leaving consumer enumeration to tests, since the new regression already proves the four surfaced counts agree.
• src/signals/local-workspace-intelligence.ts:1 consider a shared validation-status helper module if this creates or deepens a runtime dependency cycle between local-branch and local-workspace-intelligence.

Signal	Result	Evidence
Code review	✅ No blockers	1 reviewer
Linked issue	✅ No-issue rationale	PR body explains why no issue is linked.
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 (no linked issue context).
Validation posture	❌ 5/25	Preflight is holding this PR; address the blocker before review.
Contributor workload	✅ 10/10	Author activity: 194 registered-repo PR(s), 129 merged, 4 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	glorydavid03023; Gittensor profile; 194 PR(s), 4 issue(s).
Gate result	✅ Passing	No configured blocker found.

Review context

• Author: glorydavid03023
• Role context: outside_contributor
• Public audience mode: oss maintainer
• Lane context: Repository registration is not available in the local Gittensory cache.
• Public profile languages: not available
• Official Gittensor activity: 194 PR(s), 4 issue(s).
• PR-specific overlap: none found.

Contributor next steps

• Fix the blocker.
• Triage stale or unlinked PRs.
• Refresh registry data or choose a registered active repo.
• Link the issue being solved, or explicitly explain why this is a no-issue PR.

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.

_{🟩 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

[JSONbored]

I'd prefer

The only notable maintainability concern is that the helper now lives in a broad module and is imported as a runtime value by another signals module, which may be worth isolating if these modules already depend on each other.