style(ui-kit): format chart.test.tsx, which left ui:lint red on main

[JSONbored]

main's ui:lint has been failing since #9977 merged, and every PR inherits it.

packages/loopover-ui-kit/src/components/chart.test.tsx — the tests I added in #9977 — was never run through prettier. ui:lint runs format:check across the ui-kit workspace and is part of test:ci:

[warn] src/components/chart.test.tsx
[warn] Code style issues found in the above file. Run Prettier with --write to fix.
npm error workspace @loopover/ui-kit@1.3.1
npm error command sh -c prettier --check .

Confirmed against origin/main, not just locally.

My regression, and the same cause as last time

I ran a checker subset on #9977 — typecheck, dead-exports:check, test:ui-kit-pack, the ui-kit suite — and not ui:lint, which is the one that would have caught it. That is the second time this session a subset sweep has let something through to main; the first was an integration test I hadn't run.

The change

Prettier reflow only. No assertions, names, or behaviour altered — the 10 tests still pass, and the diff is entirely line wrapping of JSX props and multi-line call arguments.

Verified: ui:lint passes (warnings only, all pre-existing react-refresh/only-export-components notices), and vitest run src/components/chart.test.tsx is 10/10.

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Updated (UTC)
❌ Deployment failed View logs	loopover-ui	463ea22	Jul 31 2026, 04:53 AM

[loopover-orb]

Caution

🛑 LoopOver review result - fixes required

_{Review updated: 2026-07-31 05:11:33 UTC}

1 file · 1 AI reviewer · 2 blockers · CI failing · unstable

🛑 Suggested Action - Manual Review

Review summary
This is a pure Prettier reflow of chart.test.tsx — every hunk wraps JSX props and multi-line call arguments onto separate lines with no change to assertions, mock behavior, or test names, matching the stated intent of fixing the format:check failure that ui:lint inherited from #9977. The full post-change file content confirms the tests are unchanged logically and remain 10 in number. The Workers Builds failure is unexplained by CI STATUS and, given the branch is 1 commit behind default, is more plausibly caused by upstream changes than this formatting-only diff.

Nits — 2 non-blocking

• Trailing commas and line-wrap style now match Prettier defaults, but worth double-checking the ui-kit workspace's .prettierrc hasn't diverged from repo root config to avoid future flip-flopping.
• Consider adding a formatting check (pre-commit hook or lint-staged) scoped to ui-kit so new test files can't land unformatted again, echoing the PR author's own diagnosis of the root cause.

Why this is blocked

• No linked issue detected: No closing reference or linked issue number was found in the PR metadata/body. — If this PR is intended to solve an issue, link it explicitly in the PR body.
• Maintainer requires a linked issue: This repo's maintainer focus manifest requires every PR to reference a tracked 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: No closing reference or linked issue number was found in the PR metadata/body. — If this PR is intended to solve an issue, link it explicitly in the PR body.

2. Maintainer requires a linked issue: This repo's maintainer focus manifest requires every PR to reference a tracked issue. — Link the relevant issue (for example `Closes #123`) before opening the PR.

CI checks failing

• Workers Builds: loopover-ui — Workers Builds: loopover-ui

Decision drivers

• ❌ Code review — 2 blockers (1 reviewer)
• ❌ Gate result — Blocking (Repo-configured hard blocker found.)

Context & advisory signals — never blocks the verdict

Signal	Result	Evidence
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: 9 registered-repo PR(s), 8 merged, 272 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	JSONbored; Gittensor profile; 9 PR(s), 272 issue(s).
Improvement	ℹ️ Insufficient signal	risk: clean · value: insufficient-signal

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: Python, TypeScript, Ruby, Go, MDX, Shell, Solidity, JavaScript
• Official Gittensor activity: 9 PR(s), 272 issue(s).
• PR-specific overlap: none found.

Contributor next steps

• Start here: Treat this as maintainer-lane context rather than normal contributor-lane activity.
• Then work through the remaining 2 steps in the Signals table above.

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.

Decision record

• action: hold · clause: missing_linked_issue
• config: e3f31516eed9634a9b0979379154d7237efa323dcd2c1dd00996f82dc9e2c266 · pack: oss-anti-slop · ci: failed
• record: 38d7d74fd763b7819c131ab2561b672531d447e5e39b64ccf9aff9a8198d37f5 (schema v6, head 463ea22)

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.

[codecov]

Bundle Report

Bundle size has no change ✅

[JSONbored]

On the red Workers Builds: loopover-ui — investigated, and it is not this PR.

It is Cloudflare-side, not GitHub Actions. The GitHub-side Build UI preview artifact job passes on this PR; the failing check comes from the cloudflare-workers-and-pages app.

Three things point away from our code:

1. It never ran. The check-run reports started_at and completed_at at the same second — a 0-second failure, with no log surfaced anywhere outside the Cloudflare dashboard.
2. The exact build command succeeds locally. I ran what Cloudflare runs — npm run build:cloudflare, which is npm --prefix ../.. ci && npm --prefix ../.. run ui:build — on this branch, from a clean install. Exit 0.
3. It is intermittent on main itself, with no code pattern: 5ee37c48b succeeded, d1f770670 failed, 364f5ba4a failed then succeeded. d1f770670 is feat(status): publish per-component service status from the existing alerting stack #9984, which merged with this same check red.

So it is non-blocking and not caused by this change.

Worth a look when you have dashboard access, though. This is a dashboard-configured GitHub integration, independent of the repo's workflows — and it targets production (/workers/services/view/loopover-ui/production/builds/...) while running on pull-request branches. The repo's own ui-deploy.yml is deliberately workflow_dispatch-only, so there is a second, repo-invisible deploy path here. I cannot diagnose or reconfigure it: the Cloudflare MCP server is unauthorized in this session, and the build logs live only behind that dashboard.