fix(ui): wire fleetAccuracy.basis into the homepage tile and /fairness

[bitfathers94]

fix(ui): wire fleetAccuracy.basis into the homepage tile and /fairness

Both public surfaces read fleetAccuracy once it clears the volume gate but
never checked basis, so a lone self-hosted instance's own self-report was
labelled identically to genuine cross-operator corroboration -- the exact
overclaim the field was added to prevent. Add isFleetBasis() as the single
source of truth for that distinction and route the homepage tile's hint,
the fairness page's accuracy caption, and its "why the fleet number"
methodology paragraph through it; the accuracy figure itself never changes,
only the label.

Closes #9673

UI Evidence

Route /fairness

Viewport · Theme	Before	After
Desktop · Dark	before	after
Tablet · Dark	before	after
Mobile · Dark	before	after

Route /

Viewport · Theme	Before	After
Desktop · Dark	before	after
Tablet · Dark	before	after
Mobile · Dark	before	after

[loopover-orb]

Tip

✅ LoopOver review result - approve/merge recommended

_{Review updated: 2026-07-29 23:05:14 UTC}

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

✅ Suggested Action - Approve/Merge

• safe to merge

Review summary
This PR adds `isFleetBasis()` as a single source of truth checking `fleetAccuracy.basis === "fleet"` and wires it into three previously-basis-blind render sites (homepage tile hint, fairness page caption, and the fleet-methodology paragraph), so a lone self-hosted instance's self-report is no longer labeled as fleet corroboration. The logic is consistent across all three call sites, the accuracy figure itself is left untouched (only the label text changes), and the diff comes with matching unit/component tests for both the `fleet` and `single_instance_self_report` bases plus the undefined/missing-field fallback cases. One inconsistency worth a reason: the fairness page's inline card note still gates on `!isFleetBasis(data.fleetAccuracy)` combined with `fleetEligible` while the caption above it already branches on the same condition, so the same check is evaluated three times per render in that file — functionally fine but slightly duplicative.

Nits — 5 non-blocking

• apps/loopover-ui/src/components/site/fairness-report-page.tsx: `isFleetBasis(data.fleetAccuracy)` is now computed three separate times in the same render (caption, card note, methodology paragraph) — consider hoisting it to a single `const accuracyIsFleetBasis = fleetEligible && isFleetBasis(data.fleetAccuracy)` the way proof-of-power-stats.tsx does, for consistency between the two files.
• apps/loopover-ui/src/components/site/proof-of-power-stats-model.ts:16-19: `isFleetBasis` takes `PublicStats["fleetAccuracy"] | undefined` but the schema (public-api.ts) marks `fleetAccuracy` as always present (non-optional) going forward — the `| undefined` branch only exists for backward-compat with a payload predating the field, so a one-line comment stating that would help a future reader avoid 'simplifying' the signature.
• The external brief flags issue ui(public): wire fleetAccuracy.basis into the homepage and /fairness #9673 coverage as 'partial' — worth confirming the issue is fully closed by this diff before merge, per the review's issue-linkage requirement.
• Hoist the repeated `isFleetBasis(data.fleetAccuracy)` calls in fairness-report-page.tsx into one local variable, mirroring the `accuracyIsFleetBasis` pattern already used in proof-of-power-stats.tsx:171.
• Possible screenshot-table issue: pair 1 — Advisory only — verify the screenshot-table images against the stated change before deciding.

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	#9673
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	⚠️ 20/25	Preflight is ready, but the PR body does not name the validation run.
Contributor workload	✅ 10/10	Author activity: 101 registered-repo PR(s), 69 merged, 1 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	bitfathers94; Gittensor profile; 101 PR(s), 1 issue(s).
Improvement	✅ Minor	risk: clean · value: minor · LLM: moderate

Linked issue satisfaction

Addressed
The PR adds isFleetBasis() with the exact required signature, corrects the accuracyTrend/decidedCount types, and routes both proof-of-power-stats.tsx and fairness-report-page.tsx through it to relabel the caption/hint and gate the fleet-methodology paragraph, exactly matching the issue's requirements and #9068-style pattern. It also includes the required unit tests for isFleetBasis and new render-

Review context

• Author: bitfathers94
• Role context: outside_contributor
• Public audience mode: oss maintainer
• Lane context: Repository is configured for direct PR review.
• Public profile languages: TypeScript
• Official Gittensor activity: 101 PR(s), 1 issue(s).
• PR-specific overlap: none found.

Contributor next steps

• Start here: Add validation command/output.

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.

Visual preview

Route	Viewport	Before (production)	After (this PR's preview)	Diff
/	desktop	before /	after /	—
/	mobile	before / (mobile)	after / (mobile)	—

Click any thumbnail to open the full-size screenshot. Before = production · After = this PR's preview deploy.

Scroll preview

Route	Before (production)	After (this PR's preview)
/	before / (scroll)	after / (scroll)

A short scroll-through clip (desktop) — click either thumbnail to open the full animation. Evidence for scroll-linked behavior a single screenshot can't show.

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

[loopover-orb]

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