feat(ci): upload loopover-ui bundle stats to Codecov

[JSONbored]

Summary

• Adds Codecov Bundle Analysis for apps/loopover-ui (the deployed marketing/product site) so JS bundle-size regressions surface on every PR, the same way patch coverage already does.
• Uses @codecov/bundle-analyzer's standalone CLI against the already-built dist/client directory rather than a bundler-plugin hook: @codecov/vite-plugin's latest release (2.0.1) declares peerDependencies: { vite: '4.x || 5.x || 6.x' }, and this repo is on Vite 8 (which runs on rolldown internally, not classic rollup, so @codecov/rollup-plugin doesn't fit either). Verified with a real dry-run install -- hard ERESOLVE conflict, not just a warning. Will revisit wiring the plugin in directly once upstream adds Vite 8 support.
• New "Upload UI bundle stats to Codecov" step in ci.yml, placed right after "UI build": fork-excluded (github.event.pull_request.head.repo.fork != true, same boundary as the existing coverage-upload steps) and continue-on-error: true -- unlike coverage, nothing gates a merge on bundle size, so an upload hiccup must never fail CI.
• apps/loopover-miner-ui is intentionally NOT included: it's a self-hosted operator dashboard (deployed via systemd/loopover-miner-ui.service.example, run locally by AMS miners), not something we deploy to Cloudflare -- its production build has no step in this CI job at all (an existing test asserts this deliberately), so there's nothing to hook bundle analysis into automatically, and the bandwidth/load-time value proposition doesn't really apply to a local tool anyway.

Test plan

• npx bundle-analyzer ./dist/client --bundle-name=loopover-ui --dry-run against a real local build -- produces a valid report
• New test in test/unit/codecov-policy.test.ts asserting the CI step wiring (placement, fork exclusion, non-blocking, env) and the package.json script
• npm run actionlint clean
• npm audit --audit-level=moderate clean on the new dependency
• Full npm run test:ci gate green locally

Note on the package-lock.json @loopover/engine version changes

The lockfile diff also shows @loopover/engine's recorded range dropping from ^3.1.1 to ^1.0.0 (for packages/loopover-mcp) and ^3.0.0 (for packages/loopover-miner). This is not a regression from this PR -- both packages' own package.json files already declare those exact ranges on main today (unrelated to bundle analysis, untouched by this diff). main's committed lockfile was already out of sync with that -- it recorded ^3.1.1 for both, matching neither package.json. Installing @codecov/bundle-analyzer in apps/loopover-ui triggered a full lockfile re-resolution, which incidentally corrected this pre-existing drift back to what the package.json files have always said. Reverting it would just reintroduce the mismatch. Confirmed via git show origin/main:package-lock.json vs. git show origin/main:packages/loopover-m{cp,iner}/package.json.

[superagent-security]

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

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 95.15%. Comparing base (1b62bf0) to head (17b4237).
✅ All tests successful. No failed tests found.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #5961   +/-   ##
=======================================
  Coverage   95.15%   95.15%           
=======================================
  Files         589      589           
  Lines       46695    46695           
  Branches    14902    14902           
=======================================
  Hits        44434    44434           
  Misses       1511     1511           
  Partials      750      750           

Flag	Coverage Δ
shard-1	43.95% <ø> (ø)
shard-2	36.04% <ø> (ø)
shard-3	32.05% <ø> (ø)
shard-4	32.85% <ø> (-0.03%)	⬇️
shard-5	31.50% <ø> (ø)
shard-6	44.55% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

[loopover-orb]

Warning

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

⏸️ LoopOver review result - manual review recommended

_{Review updated: 2026-07-15 02:07:50 UTC}

4 files · 1 AI reviewer · 2 blockers · readiness 91/100 · CI green · clean

⏸️ Suggested Action - Manual Review

Review summary
This PR wires up Codecov Bundle Analysis for loopover-ui via the standalone bundle-analyzer CLI (justified since @​codecov/vite-plugin caps at Vite 6.x and this repo runs Vite 8), adds a fork-excluded, continue-on-error CI step right after "UI build", and backs the wiring with a new policy test plus the new devDependency. The core CI/package.json/test changes are correct and narrowly scoped to the stated intent, but the package-lock.json diff also silently downgrades @​loopover/engine from ^3.1.1 to ^1.0.0 and ^3.0.0 in two workspace entries, which has nothing to do with bundle analysis and looks like stale/regressed lockfile drift bundled into this PR.

Blockers

• package-lock.json (two occurrences near the end of the diff) downgrades @​loopover/engine's required range from ^3.1.1 to ^1.0.0 and ^3.0.0 respectively — unrelated to the Codecov bundle-analysis change and, if intentional elsewhere, undocumented here; if accidental, it silently reverts an engine version bump for two workspaces and should be reverted or explained.

Nits — 6 non-blocking

• ci.yml: the new step's `if` only checks fork status and doesn't also guard on `secrets.CODECOV_TOKEN` being set, so on a same-repo PR from a contributor without token access the CLI will still run and presumably fail (harmless since continue-on-error is set, but worth a comment noting that's the expected failure mode).
• apps/loopover-ui/package.json: `--upload-token=$CODECOV_TOKEN` relies on shell env-var expansion working the same way across the various ways this script might be invoked locally vs. in CI — worth confirming `npm run bundle-analysis` locally without the env var set fails gracefully rather than uploading an empty token.
• test/unit/codecov-policy.test.ts: the new test checks the exact `run` string and `if` substring but not that the step's `if` also preserves the `github.event_name == 'push' || needs.changes.outputs.ui == 'true'` build-trigger condition as a whole (only a `toContain` on the fork clause), so a change that drops the ui-changed gate but keeps the fork clause would slip through undetected.
• Split or explain the package-lock.json @​loopover/engine version changes in the PR description, or revert them if they're an artifact of an unrelated lockfile regeneration.
• Consider asserting the full `if` expression (not just `toContain` on the fork clause) in codecov-policy.test.ts so the build-trigger gate is also locked in.
• Diff looks like trivial or whitespace-only churn — Reduce whitespace-only or formatting-only churn and keep the diff focused on substantive changes.

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	1 reviewer
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: 43 registered-repo PR(s), 35 merged, 411 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	JSONbored; Gittensor profile; 43 PR(s), 411 issue(s).
Gate result	❌ Blocking	Repo-configured hard blocker found.
Improvement	⚠️ ℹ️ Insufficient signal	risk: low · value: insufficient-signal — Nothing measurable for the structural-improvement analyzers on this PR (e.g. no code files changed).

Review context

• Author: JSONbored
• Role context: owner (maintainer lane)
• 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: 43 PR(s), 411 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.
• No action.
• 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

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