feat(hub-ui): inherit panel accents from startup branding

[SaKaNa-Y]

Important

Please take a moment to read this. Thank you!

I should include a brief explanation of the problem in my own words in every PR. If that explanation is missing, please @mention me and do not merge this PR until I have added it. You may also leave this PR unaddressed (because this means I have not fulfilled my responsibilities as the author).

If my explanation is unclear or difficult to follow, please ask me to clarify or provide reproduction steps or supporting evidence.

I welcome suggestions and counterarguments, especially questions about anything I may have overlooked. (Your feedback helps me learn and improve. 🙏)

I hold myself to this standard for every PR, regardless of its size.

Intent

Let built-in devframe panels inherit the hub UI provider's primary accent. A branded dock can otherwise appear blue while its Git and Inspector panels retain green accents.

Behavior and implementation

• Read branding.primaryColor from existing connection metadata when an iframe SPA starts, and set --devframe-primary through an internal design adapter.
• Reuse the existing hub UI primary-ramp stylesheet after each SPA's default styles. No public theme API or separate theme communication channel is introduced.
• Keep standalone SPAs on their default accent and preserve independent status, chart, and social-preview palettes. Missing, invalid, or unavailable branding retains the default palette.
• Use the existing active-color token for query-completion matches: the light-mode highlight uses primary 600 instead of 700; dark mode remains primary 300.
• Track the shared stylesheet and adapter in all nine panel build tasks so changes invalidate cached panel output.

Branding is applied at startup; panels must reload to pick up changed configuration. Runtime theme broadcasts and arbitrary external iframe theming are outside this implementation.

This extends the branding work in #177. #203 and #253 concern dock and popup branding; #382 concerns SVG mask icons.

Verification

• pnpm lint, pnpm knip, pnpm typecheck, and pnpm build: completed successfully. Knip emitted UnoCSS configuration lookup messages.
• pnpm exec vitest run: 1525 passed, 9 skipped.
• Browser checks on Git and Inspector: branded primary colors in light and dark modes, inheritance after iframe reload, and exact default primary values when opened independently.
• Turbo dry-run: both shared files are included in all nine panel build-task inputs.

The other seven panel SPAs were built and their entry points reviewed, but were not individually exercised in the browser.

[vercel]

@SaKaNa-Y is attempting to deploy a commit to the NuxtLabs Team on Vercel.

A member of the Team first needs to authorize it.

[SaKaNa-Y]

I noticed that Vite DevTools’ accent color doesn’t carry through to the built-in iframe panels, so I added a mechanism that lets panels opt into the host’s accent color. I’m not sure whether this aligns with your design intentions, and I’d love to hear your thoughts.

[coldtea-pr-lens]

◈ PR Lens

🟢 +1 new · 🟠 ~11 changed · 🔴 -0 removed · 1 flow · 23 files · commit 1ec2822

Architecture

12 components touched across 6 lanes.

Play the interactive walkthrough

Inside the changed components — 2 views

Component view — Theme Derivation & RPC Connection

Startup branding extraction via client RPC and CSS custom property derivation across shadow and light DOM surfaces.

Component view — Built-in Devframe Panels

Built-in devframe iframe SPAs applying startup panel branding and adopting shared design tokens.

Data flow

Panel branding startup synchronization

Follow each request, response and payload

View

• Architecture lens
• Data flow lens
• Expand every detail

Tip

Open a diagram on the canvas, then press W or click play to walk through the change one step at a time

🪧 More tips

• Run npx skills add coldteadotai/pr-lens, then tell your coding agent: "Diagram the change you just made with PR Lens and attach it to the pull request."
• Run npx @coldtea/pr-lens-cli analyze --base origin/main on a branch, then npx @coldtea/pr-lens-cli render .pr-lens/graph.json. Same lenses, your own model key, before the pull request exists
• Untick Architecture lens or Data flow lens under View to hide a diagram, or tick Expand every detail to open every section. The comment redraws in a few seconds
• Click the link under each diagram to open it on a canvas you can zoom, pan and step through
• The diagrams are links. Click one to open it on the canvas, then press W or click play to walk through the change
• The CLI's render reads .github/pr-lens.yml and applies your renames, exclusions and lane pins at draw time
• Set github.comment.collapsed: true in .github/pr-lens.yml to fold the comment behind one View architecture and data flow row. Drawing still runs on every push
• Set github.draw: on-demand in .github/pr-lens.yml and PR Lens stops drawing every push. Comment @pr-lens draw on a pull request when you want that one drawn
• Add .github/workflows/pr-lens.yml with coldteadotai/pr-lens/packages/action@v0 and your model provider's key as its api-key to run PR Lens from your own CI. Any /chat/completions endpoint works
• Push a commit and the comment redraws for the new head. A slow older run never overwrites a newer one
• Switch GitHub to dark mode and the diagrams follow. The moving dots are this pull request's data in motion

---

Thanks for using PR Lens! It's built by Coldtea, free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Bluesky
• Mastodon
• Reddit
• LinkedIn

[antfu]

Ideally, I would like to avoid introducing these APIs, as devframe itself should be agnostic, the theme is more like a hub-ui concept. And if possible, I'd also like to keep this at CSS level as much as possible instead of relying on JS apis.

[antfu]

The branding is shipped with the connection meta and forwarded to the sub-frames; we might be able to leverage that without creating a new communication channel for that?

[SaKaNa-Y]

Thanks for pointing that out! Reusing the branding from the existing connection metadata looks feasible. I’ll update the implementation to use that and keep the styling in CSS as much as possible, without introducing new theme APIs or a separate communication channel.

[SaKaNa-Y]

Updated the implementation to read branding.primaryColor from the existing connection metadata and reuse the shared primary-ramp CSS. The added public theme APIs and separate messaging protocol have been removed.

The panel adapter now sets only --devframe-primary at startup. Styles are loaded after the default theme, and all nine panel builds track the shared CSS and adapter for cache invalidation. Query-completion matches use the existing active-color token instead of requiring an additional ramp stop.

Standalone defaults and independent status/preview palettes are preserved. Configuration changes take effect after a panel reload. Git and Inspector browser checks passed, and the test suite reports 1525 passed and 9 skipped.

[SaKaNa-Y]

Reworked the implementation to reuse the existing CSS and connection metadata, reduce reliance on JS APIs, and slightly adjust the query-completion highlight color.