Add ten SolidJS libraries to Col and preserve their component styling

Problem Statement

Developers cannot discover Kobalte, SolidUI, shadcn-solid, Zaidan, hope-ui, RockSolid, Nikala UI, TorchUI, MagicUI Solid, or Mystic UI through Col's current library catalog. Agents using Col MCP consequently lack matching library details, verified component records, implementation evidence, and authentic render support.

Adding names alone would not satisfy the request. Col's website must retain its existing design, while render_component must preserve the selected library's own implementation and appearance. An example that runs real Solid code but replaces its theme, corners, hover colors, focus indicators, typography, or animation with Col styling is incorrect.

Col already supports React previews and Quoin with Solid 2. However, selection of Solid examples and their CSS is tied to Quoin's identifiers. Other Solid libraries need their own verified dependency versions and styling inputs; the presence of a Solid runtime does not establish compatibility with them.

Solution

Add all ten libraries through Col's existing catalog, detail-page, component-index, documentation-evidence, and preview flows. A developer can find a library on the website or through MCP, follow official setup links, retrieve verified component guidance, and render a supported genuine example with its upstream styling intact.

Reuse Col's existing layouts and components for the website. Reuse its isolated MCP Apps and standalone HTML renderer for previews, extending the current Solid selection only as needed to support multiple libraries and compatible runtime versions.

Treat each library as a complete implementation stage within this single issue. Every stage includes website discovery, MCP discovery and evidence, authentic supported rendering, relevant documentation, and focused verification. Component coverage follows Col's existing verified, partial-index convention: inventory the documented components, record the selected coverage, and state any remaining gaps. Do not silently reduce a library to a catalog-only addition or present a handful of examples as exhaustive support.

User Stories

1. As a Solid developer, I want to find all ten requested libraries in Col, so that I can compare appropriate options in one place.
2. As a website visitor, I want new listings to use Col's existing layout and controls, so that browsing remains consistent.
3. As a developer, I want each library to have its own detail page, so that similarly named projects remain distinguishable.
4. As a developer, I want SolidJS filters to include the new libraries, so that I can avoid unrelated framework results.
5. As a developer, I want official website, documentation, and source links, so that I can inspect the original project.
6. As a developer, I want accurate package, copy-paste, and registry setup guidance, so that I use the right installation workflow.
7. As a developer, I want SolidUI and shadcn-solid identified separately, so that I do not confuse two distinct ports.
8. As a developer, I want headless and styled libraries distinguished, so that I understand which styling I must supply.
9. As an agent, I want stable library and component identifiers, so that search results can be used for subsequent lookup and rendering.
10. As an agent, I want component searches to use verified component pages, so that a library's tags do not imply nonexistent support.
11. As an agent, I want bounded component API and composition evidence, so that I can implement real Solid components in an application.
12. As an agent, I want source-linked examples and dependencies, so that generated application code uses actual exports and providers.
13. As a developer, I want exact Solid compatibility recorded per library, so that Solid 1 and Solid 2 are not treated as interchangeable.
14. As a developer, I want prerelease and maintenance information backed by dated evidence, so that I can assess suitability.
15. As a developer, I want Tailwind requirements recorded accurately, so that v3 plugins and v4 themes are not mixed incorrectly.
16. As a client user, I want render_component to execute the selected library's real implementation, so that the preview represents that library.
17. As a client user, I want original colors, tokens, spacing, typography, corners, borders, and shadows preserved, so that I can assess its appearance.
18. As a client user, I want original hover, focus, disabled, selected, and open-state styling preserved, so that interactions look correct.
19. As a client user, I want light and dark examples to use upstream theme values, so that Col's shell theme does not recolor the library.
20. As a developer, I want Kobalte's official demo styling attributed as example CSS, so that I do not mistake a headless library for a styled system.
21. As a client user, I want required providers and portal styling included, so that dialogs and popups remain functional and styled.
22. As a developer, I want RockSolid's documented RTL behavior retained, so that direction-sensitive examples remain meaningful.
23. As a client user, I want original animation dependencies and keyframes retained, so that animated libraries show their intended behavior.
24. As a client user, I want reduced-motion behavior and clean disposal preserved, so that examples remain accessible and do not retain work after replacement.
25. As an agent, I want MCP Apps and standalone HTML to select the same source and styles, so that rendering formats agree where supported.
26. As a developer, I want missing assets, unsupported environments, and failed renders reported explicitly, so that an imitation is never presented as the original.
27. As a developer, I want documentation and rendering availability reported separately, so that useful implementation evidence remains available when a preview cannot run.
28. As an existing Col user, I want React and Quoin examples to keep working, so that new library support does not disrupt existing behavior.
29. As a maintainer, I want source revisions, dependency integrity, license notices, and reuse permission retained, so that published examples are reproducible and attributable.
30. As a maintainer, I want website discovery and MCP results to agree, so that new libraries do not require duplicate manual registries.
31. As a maintainer, I want completion and verification limits recorded per library, so that unresolved work cannot disappear behind an aggregate success claim.

Implementation Decisions

• One issue, complete stages. Keep the full specification, ten library stages, their dependencies, and acceptance checklists in one git.cafe issue. Do not create separate implementation issues or sub-issues.
• Extend existing catalog data. Add distinct library records, matching details, verified component entries, compatibility facts, and permitted documentation evidence. Reuse existing categories, SolidJS stack filtering, use cases, slug rules, and addition timestamps. Retain pricing and license facts only where supported by official evidence.
• Reuse the website. Use the current library listing, detail, search, filter, component-discovery, logo/fallback, and outbound-link mechanisms. No new page design, decorative frames, controls, typography, or global stylesheet changes are needed merely to add these libraries. Preserve existing accessibility, responsive behavior, and light/dark modes.
• Keep libraries and integrations distinct. These are library additions with support inside Col MCP. Do not add an integration entry solely because a library is available through Col MCP, and do not connect to or install a library's separate MCP server as part of this work.
• Preserve the read-only MCP contract. Continue using library search, component search, library lookup, component lookup, and render_component. Return official setup links, verified version facts, and bounded permitted documentation/examples. Col does not install dependencies in the user's project, generate installation commands in lookup fields, or execute arbitrary submitted source.
• Verify each upstream identity. Establish current canonical docs, source repository, distribution model, exact release or immutable revision, peer dependencies, and license before importing examples. Treat the request's beta/inactivity statements as leads to verify. Keep all ten libraries in the scope even when evidence is temporarily unavailable; record unresolved verification instead of inventing facts or silently dropping a library.
• Use a concrete coverage inventory. Record documented component names and URLs, the examples selected for implementation, runtime and styling requirements, documentation availability, preview availability, and precise gaps. Verify core interactions and each library's distinctive behavior. There is no artificial fixed component cap, but neither a successful build nor one working Button establishes full-library coverage. Components that require application servers or desktop APIs retain explicit environment limitations.
• Generalize the existing Solid selection narrowly. Resolve a verified example, its CSS, runtime, source identity, and limitations by the complete component identifier. Remove the Quoin-only assumption from the shared selection path while preserving Quoin's existing records and behavior. Introduce this change with the first end-to-end Kobalte stage; avoid a separate framework or broad registry rewrite.
• Keep runtime graphs compatible. Use each library's verified Solid and compiler combination. Keep Solid 1 dependency resolution separate from Solid 2 where required, and preserve Quoin's pinned Solid 2 compatibility set. Compile reviewed examples at build time into self-contained browser modules with the existing mount/dispose contract. A library's own provider and its consumers must share the same compatible dependency graph. Do not force libraries onto Quoin's Solid version or transpile Solid JSX as React.
• Preserve upstream appearance. Use official component/demo sources and their actual styles, tokens, CSS layers, variants, icons, fonts, assets, providers, and required dependencies. Compile the correct upstream Tailwind/Panda/CSS pipeline where applicable. Retain documented colors, radii, shadows, hover/focus treatment, and animations even where Col's own interface uses different design rules. Col's visual preferences apply to its shell; they must not neutralize imported component styling.
• Handle headless examples explicitly. Kobalte ships unstyled primitives. Prefer its official demo composition, CSS, and theme, and identify that CSS as upstream example styling. If no official demo exists, record the authored composition and its limitations; do not claim visual equivalence to a nonexistent reference or substitute a different library.
• Keep CSS isolated and ordered. Use the existing sandboxed frame. Include required resets, generated utilities, variables, keyframes, data-state selectors, direction settings, and portal styles inside it. Avoid an unrelated browser Tailwind runtime or shell reset overriding compiled upstream CSS. Selected themes map to the upstream theme mechanism; caller-supplied CSS remains an intentional subsequent override and cannot style provenance or error disclosures. Prevent previous previews' styles, roots, listeners, portals, and animation work from leaking into later previews.
• Retain errors and sandbox restrictions. Preserve source/integrity attribution, license notices, CSP, request correlation, bounded payloads, and resource limits. Missing required CSS or dependencies is a rendering failure, not success with a generic component. Where original assets cannot be supplied under existing rules, expose the specific gap; do not broaden CSP or use replacement assets to conceal it. Keep parity between MCP Apps and standalone HTML except for documented resource restrictions already enforced by Col.
• Update generated discovery and user guidance. Library pages, component discovery, sitemap, LLM discovery output, canonical/social metadata, agent guidance, and MCP result descriptions must reflect the delivered support. Prefer existing generators and shared catalog data. Review crawler coverage, but change its configuration only if necessary. Explain new runtime/coverage behavior in existing user documentation.
• Keep implementation verifiable and small. Follow the existing TypeScript patterns and contribution rules. Read the installed Next.js guides before application code changes, use the required Matt Pocock workflow for TypeScript, avoid unrelated refactors, and justify any genuinely required build dependency. Respect repository media and new-data limits when committing generated bundles or assets.

Testing Decisions

• Primary acceptance seam: the existing public catalog-tool invocation interface using real catalog data. Exercise search → library lookup → component lookup → render_component, checking stable identity, SolidJS filtering, source evidence, version constraints, genuine implementation selection, styling payload, and explicit unsupported/error results. Use the same seam for every library instead of inventing ten separate testing frameworks.
• Transport contract: extend the existing in-memory MCP client/server checks only where the shared response contract changes. Check runtime metadata, provenance, bounded output, schema validation, and delivery of executable content without putting large bundles into model-facing text.
• Website output: use the existing built-library-page and discovery-output tests for registered detail pages, official links, metadata, sitemap, LLM discovery entries, and the common website structure. New catalog records should flow through existing generators. A file existing on disk is insufficient if it is not registered for the generated route.
• Authenticity and styling: extend the existing Quoin-style source/CSS checks and preview integrity checks. Verify cited upstream source and dependency hashes, stylesheet/theme inclusion, representative tokens and state selectors, correct CSS compilation, licenses, and theme selection. Assert source-driven visual contracts that matter to the user, such as an upstream radius, focus style, or animation keyframe, rather than snapshotting arbitrary internal formatting.
• Real execution: reuse the focused DOM execution approach for emitted Solid modules. Exercise representative state changes, a popup/provider interaction, required direction behavior, and mount/replacement/disposal. Animated examples retain their real animation implementation and clean up timers/listeners on disposal. Simulated DOM tests do not establish layout, positioning, smoothness, or pixel equality.
• Existing behavior: retain a focused existing React journey and the existing Quoin Solid 2 journeys while extending shared selection and CSS handling. Test a missing stylesheet/dependency and an unsupported component without replacing the failed implementation.
• Prior art: Col already tests real-data MCP invocation, in-memory MCP transport, built pages/discovery, permission-gated documentation, source/package integrity, Quoin's original CSS, real Solid state updates, portals, and disposal. Extend those seams instead of duplicating them.
• Verification boundary: live browser and third-party MCP-client testing requires the user's explicit request under the repository instructions. This planning request does not authorize it. Preserve upstream source/CSS and run the permitted automated checks; explicitly distinguish those results from unperformed visual/client verification. Prior Quoin screenshots do not verify these new libraries.
• Required implementation checks: run typecheck and the repository test command, which builds before page tests. Add only focused checks for meaningful new behavior. For this planning artifact, validate Markdown structure, all ten libraries, coverage, source references, and dependency ordering; an application build is unnecessary.

Out of Scope

• Redesigning Col's website, migrating it from React/Next.js to Solid, or adopting any of these libraries as Col's own UI system.
• New MCP tools for installing components, writing project files, arbitrary source execution, or connecting third-party MCP servers.
• Assuming Solid 2 compatibility for every Solid library, floating runtime upgrades, or changing Quoin's pinned release merely to share dependencies.
• React substitutes, screenshots presented as executable components, fabricated component APIs, or generic restyled demos presented as faithful upstream examples.
• Reimplementing desktop, server, backend, device, or network capabilities inside the preview sandbox.
• An exhaustive mirror of every upstream export, unverified maintenance claims, unrelated catalog cleanup, or changing repository hosting settings.
• Implementation, commits, a pull request, merge, or deployment during this issue/spec authoring step.

Further Notes

Planning date: 2026-10-29. Current source observations are listed below; implementation must verify exact versions and revisions when selecting source material.

Unavailable research-tool fetches are not evidence that a project is abandoned or globally inaccessible. They remain implementation research obligations. The completed Quoin issue #68 is prior art, not a blocking open issue.

Implementation stages and acceptance criteria

The first stage extends the shared Solid selection while delivering a working library. Stages 02–10 depend on that shared change, not on each other's library coverage. A stage must satisfy the common acceptance criteria as well as its own checklist. If source or permission verification fails, record the specific blocker and leave that stage incomplete.

Common acceptance criteria for every library stage

• The library has a unique verified catalog identity, matching details, official links, addition timestamp, and appropriate existing taxonomy.
• The existing website listing/detail/search/component flows expose its verified content with Col's existing styling and behavior.
• MCP search and lookups return matching identifiers, official setup guidance, verified compatibility, bounded permitted implementation evidence, and honest coverage.
• The selected documented component inventory is recorded; supported examples execute authentic source with pinned compatible dependencies and original styling in both rendering formats where permitted.
• Required CSS, themes, states, providers, assets, animations, and license/source records accompany the examples; failures or environment limitations remain explicit.
• Public-tool, emitted-artifact/style, and focused execution checks pass; generated discovery and affected user documentation agree with the delivered behavior.

Stage 01: Add Kobalte through discovery, guidance, and authentic rendering

What to build: A developer can find Kobalte in Col, obtain verified primitive and styling guidance, and render genuine Kobalte examples using their original demo styling. This establishes library-independent selection of compiled Solid examples.

Blocked by: None (can start immediately).

• Verify current Kobalte documentation, core/runtime/compiler requirements, source revision, and permission before indexing examples.
• Deliver representative documented controls and an interactive popup/disclosure, preserving their actual parts, state selectors, and upstream demo CSS.
• Explain that Kobalte is unstyled and distinguish Tailwind v3 plugin guidance from v4 data-attribute guidance.
• Shared preview selection resolves complete component IDs and retains per-example CSS, provenance, errors, and mount/dispose behavior without assuming a Quoin prefix.
• The existing React and Quoin examples remain correct through the focused regression checks, including their original styling.

Stage 02: Add SolidUI, including its distinctive data-display components

What to build: Developers can discover SolidUI separately, retrieve its copy-paste setup and component evidence, and render original SolidUI controls and a verified Tremor-derived example where documented.

Blocked by: Stage 01 (shared Solid example selection).

• Verify the source registry/repository, Kobalte/corvu requirements, Tailwind setup, and chosen component pages.
• Include representative controls and a documented data-display/chart example with genuine dependencies and theme.
• Preserve source identities, styling, and provider requirements instead of using the React shadcn/ui or Tremor implementations.

Stage 03: Add shadcn-solid as its own library

What to build: Developers can discover hngngn's shadcn-solid, retrieve its own source/setup guidance, and render its original Solid components.

Blocked by: Stage 01 (shared Solid example selection).

• Keep its library/component identities separate from SolidUI and the existing React shadcn/ui entry.
• Verify current canonical documentation, registry/source revision, compatible dependencies, and theme.
• Render representative documented controls and an overlay/disclosure with the port's original CSS, state styles, and provider composition.

Stage 04: Add Zaidan with its registry styling intact

What to build: Developers can discover Zaidan, inspect verified registry-based setup and component evidence, and render its authentic components and theme.

Blocked by: Stage 01 (shared Solid example selection).

• Verify registry items, transitive component dependencies, runtime requirements, source revision, and licensing.
• Include original global theme/token definitions, utilities, required Kobalte/corvu composition, and example-specific CSS.
• Exercise representative documented controls and an interactive composition; do not infer support from the marketing showcase alone.

Stage 05: Add the current hope-ui early preview

What to build: Developers can discover the current hope-ui, understand its exact prerelease requirements, and render real themeable Solid examples.

Blocked by: Stage 01 (shared Solid example selection).

• Confirm the current components package and exact supported Solid/compiler versions from package/source evidence.
• Preserve semantic tokens, Tailwind v4 recipes, light/dark presets, variants, and required providers.
• Cover a documented control plus an interactive selection/overlay example, and describe early-preview status without implying production guarantees.
• Keep hope-ui's dependency set isolated from Quoin where their required prerelease versions differ.

Stage 06: Add RockSolid and preserve documented RTL behavior

What to build: Developers can discover RockSolid, inspect verified setup and component evidence, and render original styled examples in their documented direction modes.

Blocked by: Stage 01 (shared Solid example selection). Upstream identity/source verification must also be resolved within this stage.

• Establish an authoritative documentation/source connection from the requested project before importing any same-name package.
• Verify the selected component pages, license, compatible runtime, stylesheet, and provider requirements.
• Include a representative direction-sensitive example and preserve its genuine LTR/RTL composition and styles where officially supported.
• Report missing source or unsupported RTL claims precisely; no fabricated implementation or substitute library completes this stage.

Stage 07: Add Nikala UI's browser-compatible components

What to build: Developers can find Nikala UI, retrieve source and theme guidance, and render its genuine browser-compatible components with Tailwind v4 styling intact.

Blocked by: Stage 01 (shared Solid example selection).

• Verify component sources, Solid dependencies, theme/provider setup, and Tailwind v4 token compilation.
• Cover representative documented controls and a distinctive browser-compatible composition, preserving original tokens and state styling.
• Clearly distinguish desktop/native-dependent components and hooks from browser-renderable examples; do not emulate OS actions.
• Preserve Col MCP's own read-only tool contract without installing or invoking Nikala's separate MCP server.

Stage 08: Add TorchUI's styled components

What to build: Developers can discover TorchUI, inspect its verified setup and release status, and render its genuine styled components.

Blocked by: Stage 01 (shared Solid example selection). Upstream identity/source verification must also be resolved within this stage.

• Verify the requested project's official source, documentation, distribution, license, and current beta/stability status.
• Preserve its actual Kobalte/runtime requirements, theme, CSS, variants, and provider composition where documented.
• Deliver representative documented controls and an interactive example; expose unresolved upstream requirements instead of substituting bare Kobalte or another styled port.

Stage 09: Add MagicUI Solid with original animation and theme assets

What to build: Developers can discover the Solid port, retrieve verified registry/component guidance, and render its authentic animated examples.

Blocked by: Stage 01 (shared Solid example selection).

• Verify official registry items and revisions, Solid dependencies, and per-component animation requirements.
• Include the required Tailwind v4 theme variables, keyframes, utility mappings, icons, and original assets where permitted.
• Cover representative documented motion such as a marquee and an interactive effect using the actual Solid source, with cleanup and documented reduced-motion behavior retained.
• Keep identity and implementation separate from the React Magic UI library already familiar to users.

Stage 10: Add Mystic UI with verified maintenance and styling information

What to build: Developers can discover Mystic UI, understand its verified project status and styling choices, and render genuine animated Solid examples.

Blocked by: Stage 01 (shared Solid example selection).

• Verify source/release activity, alpha status, distribution, runtime compatibility, and license before publishing maintenance claims.
• Select and document the upstream Tailwind or Panda styling variant for each example; preserve its corresponding CSS generation and motion dependencies.
• Cover representative documented motion such as Marquee or Orbiting Circles with the original source, theme, keyframes, and cleanup behavior.
• Record any compatibility or maintenance limitation without silently dropping Mystic UI from the requested scope.

Completion across the issue

• All ten stages and their common criteria are complete. Any unresolved stage remains explicitly incomplete with its concrete blocker and prevents closing the issue as fully delivered.
• The final coverage inventory distinguishes verified component evidence, executable examples, unsupported environments, and unperformed visual/client checks.
• Typecheck and the required build/test suite pass for the final implementation; failures and verification limits are reported accurately.
• The eventual git.cafe pull request links this issue with Closes only when the entire requested outcome is delivered. Partial work uses Refs and states what remains. Leave merging to Screen and verify issue closure after merge.