test(miner-ui): bring the miner-ui under a real coverage gate

[JSONbored]

Summary

• Adds a coverage block to apps/gittensory-miner-ui/vitest.config.ts (v8 provider, src/**/*.{ts,tsx} + the root-level vite-*.ts plugin files, excluding the TanStack Router-generated routeTree.gen.ts and the unit-untestable main.tsx entry point).
• Changes the app's test script to vitest run --coverage, so the gate runs wherever npm --workspace @loopover/ui-miner run test already runs (locally and in npm run ui:test/test:ci) — no new CI step needed.
• Sets coverage.thresholds to the real measured baseline the day this was wired up (~87.65% statements / 87.17% branches / 78.9% functions / 88.79% lines), with a small buffer below that so routine churn doesn't false-fail. This is a floor meant to catch a genuine regression, not a ratchet — per Bring the miner-ui and extension under a coverage gate #4865's own framing ("establish a coverage baseline"), not "achieve 100% everywhere in one PR."
• Documents this in the app's README.md.

Scope

apps/gittensory-miner-ui and apps/gittensory-miner-extension are both excluded today via the root vitest.config.ts's blanket coverage.exclude: ["apps/**"]. This PR only covers the miner-ui half. The extension has no vitest setup or test suite at all yet (confirmed: its package.json only has lint/typecheck/build scripts, added by #4866/#5567) — #4865's own boundary note flags this ("extension's test instrumentation may need adjustment first"). Writing that suite from scratch is a separate, larger effort left for a follow-up; this PR does not touch the extension.

Note: two pre-existing sibling API plugin files (vite-portfolio-queue-api.ts, vite-run-state-api.ts) and vite-ledgers-api.ts have real coverage gaps at their own Vite-plugin-wiring layer (portfolioQueueApiPlugin()/runStateApiPlugin()/ledgersApiPlugin() themselves, as opposed to the already-tested handleXRequest functions they wrap) — visible in the coverage report but out of scope here; the baseline threshold accounts for them honestly rather than inflating the number.

Advances #4865 (not closing it — the extension half is still open).

Test plan

• npm run ui:test — both apps' full suites pass (33+202 for gittensory-ui, 9+103 for miner-ui)
• npm run ui:typecheck, npm run ui:lint (0 errors), npm run ui:build
• npm run docs:drift-check
• Verified the gate actually enforces: temporarily raised the statements threshold to 99%, confirmed npm test fails with ERROR: Coverage for statements (87.65%) does not meet global threshold (99%), then reverted

[superagent-security]

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

[loopover-orb]

Important

🟪🟪🟪🟪🟪🟪🟪🟪🟪🟪🟪🟪

🔍 Gittensory is reviewing…

AI analysis is in progress. This comment will update when the review is complete.

_{🟩 Safe / merged · 🟦 Advisory · 🟨 Held for review · 🟥 Blocked / closed · 🟪 Reviewing}

[loopover-orb]

Important

🟪🟪🟪🟪🟪🟪🟪🟪🟪🟪🟪🟪

🔍 Gittensory is reviewing…

AI analysis is in progress. This comment will update when the review is complete.

_{🟩 Safe / merged · 🟦 Advisory · 🟨 Held for review · 🟥 Blocked / closed · 🟪 Reviewing}

[loopover-orb]

Warning

🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨

⏸️ Gittensory review result - manual review recommended

_{Review updated: 2026-07-13 09:39:47 UTC}

3 files · 2 blockers · readiness 93/100 · CI green · clean

⏸️ Suggested Action - Manual Review

• AI review already in progress for this PR head: Another Gittensory pass is already running the AI review for this exact PR head. This pass is skipping to avoid a duplicate LLM call.

Review summary
AI review is already running for this PR head in another Gittensory pass. Gittensory is holding this PR for manual review until that pass completes.

Nits — 2 non-blocking

• Code changes lack test evidence — Add focused regression tests or explain why existing coverage is sufficient.
• AI review already in progress for this PR head — The gate is held for a human reviewer rather than passed automatically; it re-evaluates once the in-flight review completes or on the next update.

Concerns raised — review before merging

• No linked issue detected — If this PR is intended to solve an issue, link it explicitly in the PR body.
• Maintainer requires a linked issue — Link the relevant issue (for example Closes #123) before opening the PR.

📋 Copy for AI agents — paste into your coding agent

Fix the following blocker(s) from this PR review:

1. No linked issue detected — If this PR is intended to solve an issue, link it explicitly in the PR body.

2. Maintainer requires a linked issue — Link the relevant issue (for example `Closes #123`) before opening the PR.

Signal	Result	Evidence
Code review	❌ 2 blockers	No AI review summary
Linked issue	⚠️ Missing	No linked issue or no-issue rationale found.
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	✅ 25/25	PR body includes validation/test evidence.
Contributor workload	✅ 10/10	Author activity: 44 registered-repo PR(s), 36 merged, 347 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	JSONbored; Gittensor profile; 44 PR(s), 347 issue(s).
Gate result	❌ Blocking	Repo-configured hard blocker found.
Improvement	⚠️ ℹ️ None detected	risk: low · value: none — No structural-improvement signals were detected for this PR.

Review context

• Author: JSONbored
• Role context: owner (maintainer lane)
• Public audience mode: oss maintainer
• Lane context: Repository is configured for direct PR review.
• Public profile languages: not available
• Official Gittensor activity: 44 PR(s), 347 issue(s).
• PR-specific overlap: none found.

Contributor next steps

• Treat this as maintainer-lane context rather than normal contributor-lane activity.
• Explain no-issue PR.
• 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.

[BETA] Chat with Gittensory

Ask Gittensory a question about this PR directly in a comment — grounded only in the same cached, public-safe facts shown above, never a new claim.

• @gittensory ask <question> answers contribution-quality Q&A with source citations and freshness.
• @gittensory chat <question> answers in natural prose from cached decision-pack facts via local inference (maintainer/collaborator; read-only).
• A plain-language @gittensory mention with a real question is routed to the closest matching read-only command automatically -- no exact syntax required.

Full command reference: https://gittensory.aethereal.dev/docs/gittensory-commands

Visual preview

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

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

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

[loopover-orb]

Warning

🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨

⏸️ Gittensory review result - manual review recommended

_{Review updated: 2026-07-13 09:40:18 UTC}

3 files · 2 AI reviewers · 2 blockers · readiness 93/100 · CI green · clean

⏸️ Suggested Action - Manual Review

Review summary
This PR wires up a real coverage gate for apps/gittensory-miner-ui by adding a v8 coverage config with include/exclude patterns, switching the test script to `vitest run --coverage`, and setting thresholds at a measured baseline with reasonable buffer. The config is straightforward and internally consistent — includes src and vite-*.ts plugin files, excludes the generated routeTree.gen.ts and untestable main.tsx entry — and the threshold rationale (baseline floor, not a ratchet) is well-documented in both the config comment and README. This is config-only, low-risk tooling work with no logic changes to review beyond the numbers themselves.

Nits — 6 non-blocking

• The threshold values (85/85/75/85) in vitest.config.ts:22-25 are plain numeric literals; the classifier flags them as 'magic numbers' but they're self-documented via the adjacent comment, so this is a very minor readability nit, not a real defect.
• No test-path changes accompany this PR, which is expected since it's a config/tooling change rather than new testable logic — nothing to flag beyond noting it's config-only.
• Consider extracting the threshold numbers into named constants (e.g. `const BASELINE = { statements: 85, ... }`) purely for a future diff's readability, though the current inline comment already explains intent adequately.
• If CI has already run against this exact threshold config and passed, no further action needed; just confirm the thresholds don't need retuning after the next dependency bump to vitest/v8.
• apps/gittensory-miner-ui/vitest.config.ts:15 Consider adding a short note with the exact command used to refresh the baseline when these thresholds are intentionally raised later.
• Code changes lack test evidence — Add focused regression tests or explain why existing coverage is sufficient.

Concerns raised — review before merging

• No linked issue detected — If this PR is intended to solve an issue, link it explicitly in the PR body.
• Maintainer requires a linked issue — Link the relevant issue (for example Closes #123) before opening the PR.

📋 Copy for AI agents — paste into your coding agent

Fix the following blocker(s) from this PR review:

1. No linked issue detected — If this PR is intended to solve an issue, link it explicitly in the PR body.

2. Maintainer requires a linked issue — Link the relevant issue (for example `Closes #123`) before opening the PR.

Signal	Result	Evidence
Code review	❌ 2 blockers	2 reviewers, synthesized
Linked issue	⚠️ Missing	No linked issue or no-issue rationale found.
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	✅ 25/25	PR body includes validation/test evidence.
Contributor workload	✅ 10/10	Author activity: 44 registered-repo PR(s), 36 merged, 347 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	JSONbored; Gittensor profile; 44 PR(s), 347 issue(s).
Gate result	❌ Blocking	Repo-configured hard blocker found.
Improvement	⚠️ ℹ️ None detected	risk: low · value: none — No structural-improvement signals were detected for this PR. LLM value judgment: moderate — Establishing an enforced coverage floor for a previously ungated app is a genuine, well-scoped process improvement that closes a real gap (#4865) without overreaching into the out-of-scope extension or symptom-only fixes.

Review context

• Author: JSONbored
• Role context: owner (maintainer lane)
• Public audience mode: oss maintainer
• Lane context: Repository is configured for direct PR review.
• Public profile languages: not available
• Official Gittensor activity: 44 PR(s), 347 issue(s).
• PR-specific overlap: none found.

Contributor next steps

• Treat this as maintainer-lane context rather than normal contributor-lane activity.
• Explain no-issue PR.
• 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.

[BETA] Chat with Gittensory

Ask Gittensory a question about this PR directly in a comment — grounded only in the same cached, public-safe facts shown above, never a new claim.

• @gittensory ask <question> answers contribution-quality Q&A with source citations and freshness.
• @gittensory chat <question> answers in natural prose from cached decision-pack facts via local inference (maintainer/collaborator; read-only).
• A plain-language @gittensory mention with a real question is routed to the closest matching read-only command automatically -- no exact syntax required.

Full command reference: https://gittensory.aethereal.dev/docs/gittensory-commands

Visual preview

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

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

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