Full SolidJS 2 RC and Quoin support in Col MCP

Problem Statement

Developers building SolidJS 2 applications cannot currently use Col MCP to discover Quoin components and obtain the verified API, dependency, composition, and styling evidence needed to implement them. Col recognizes the SolidJS stack, but its executable component renderer assumes React. A catalog listing or a small preview gallery alone would not satisfy the request: agents need usable support for building real Solid 2 applications with Quoin.

Solution

Add Quoin as a library and SolidJS 2 RC as an explicitly versioned supported runtime for its components. A developer can ask an agent for a Quoin component, discover its stable identifier, inspect verified documentation and examples, understand the exact compatible dependencies, implement it in their own application, and optionally render the genuine implementation through Col MCP.

Support covers the documented public component families of the pinned Quoin release, with coverage stated per component. Delivery is incremental, but the initial handful of components is not the final scope. A component with a real documentation or execution limitation remains explicitly identified; a partial slice must not be presented as full support.

User Stories

1. As a Solid developer, I want Quoin to appear in SolidJS library searches, so that I can find a suitable library without React-only results.
2. As a developer, I want Col to distinguish Solid 2 RC from Solid 1, so that I do not mistake a broad stack label for version compatibility.
3. As an agent, I want stable library and component identifiers, so that discovery and subsequent lookups resolve the same item.
4. As a developer, I want official project, documentation, and source links, so that I can inspect upstream evidence.
5. As an agent, I want recorded Quoin and Solid dependency requirements, so that I can assess the user's installed versions.
6. As a developer, I want prerelease status stated clearly, so that I can decide whether this stack suits my application.
7. As an agent, I want verified component APIs and types, so that I can write Solid code using actual supported props and exports.
8. As an agent, I want small, source-linked examples, so that I can implement components without reconstructing them from screenshots.
9. As a developer, I want compound-component composition guidance, so that required providers and parts work together.
10. As a developer, I want headless primitive guidance where Quoin documents it, so that I can supply my own markup.
11. As an agent, I want controlled-state examples using Solid 2 semantics, so that events and state updates work correctly.
12. As a developer, I want clear styling hooks and example CSS, so that unstyled components are usable in my design.
13. As a developer, I want form and selection examples, so that values, labels, validation states, and disabled states work together.
14. As a developer, I want overlay and navigation examples, so that keyboard interaction, focus, dismissal, and positioning remain accessible.
15. As a developer, I want optional previews of genuine Quoin components, so that I can inspect behavior before integrating them.
16. As a client user, I want MCP Apps and standalone HTML rendering to use the same component and dependency versions, so that the two outputs agree.
17. As an agent, I want documentation availability and rendering availability reported separately, so that I can still implement a component whose preview is unavailable.
18. As a developer, I want exact source revisions and verification dates, so that I know what Col's claims apply to.
19. As an agent, I want explicit unsupported and unknown cases, so that I do not invent exports, compatibility, or behavior.
20. As a developer, I want component discovery in the website and MCP server to agree, so that I can move between them without conflicting information.
21. As an existing Col user, I want React components to keep working, so that Solid support does not disrupt existing integrations.
22. As a maintainer, I want a complete coverage inventory for the pinned release, so that missing families cannot disappear behind a claim of full support.
23. As a maintainer, I want reproducible dependency bundles and license records, so that examples remain attributable and verifiable.
24. As a client user, I want rerenders and teardown to dispose Solid roots and portals, so that old examples do not retain event handlers or visible UI.

Implementation Decisions

• Treat Quoin as a library and SolidJS as its stack/runtime. Do not create a separate integration-directory entry for either merely because Col MCP supports them. Preserve the existing library/integration distinction.
• Preserve the read-only MCP contract. The client agent installs dependencies and edits the user's application; Col supplies verified evidence and optional rendering.
• Build on the existing library/component search and lookup tools. Reuse permission-gated documentation snapshots for library-level setup and evidence. Add bounded, additive component-level documentation fields where needed to make each API/example retrievable without loading an entire library corpus. Preserve existing identifiers, filters, result fields, and error behavior.
• Preserve official setup links rather than adding generated install commands to existing lookup responses. Return exact version facts and source-linked setup evidence. Do not inspect or claim knowledge of a client's installed versions.
• Start from the verified published pair: quoin-ui 0.6.0 with solid-js, @solidjs/web, and @solidjs/signals all at 2.0.0-rc.18. Registry metadata checked on 2026-10-28 showed Solid's next tag at rc.19, which must not silently replace Quoin's exact peer requirements. Revalidate these facts before implementation; change the whole compatibility set deliberately if upstream has moved.
• Verify current official project and per-component documentation URLs. Older README material referred to Quoin 0.3.x and Solid beta.28 and must not be used as RC compatibility evidence. Do not copy historical patches without confirming they apply to the pinned release.
• Inventory the pinned release's documented public component families and exports. For each, record documentation/API coverage, a meaningful example, runtime support, dependency requirements, source revision, and any concrete limitation. Only verified component pages enter the component index; undocumented exports remain inventory findings rather than invented catalog entries.
• Document both compound and headless APIs where present, including required parts, providers, state ownership, event callbacks, styling hooks, and accessibility responsibilities. Keep source examples separate from executable preview bundles so an agent can use examples in real applications.
• Add explicit runtime selection to the existing rendering contract. Existing React behavior remains the default for existing entries; Quoin selects Solid 2. Share the outer MCP Apps shell, provenance, request correlation, errors, themes, CSS handling, and HTML fallback.
• Compile reviewed Solid examples at build time with a compatible Solid compiler. Use browser-targeted Quoin exports and one consistent pinned Solid dependency graph. Avoid shipping a new live Solid compiler when fixed compiled examples satisfy the existing source-selection contract.
• Mount with Solid's browser renderer and dispose its root on replacement or teardown. Preserve the sandbox and CSP restrictions, authenticated source/integrity records, license notices, and bounded output. Do not substitute Base UI React components or handmade imitations for Quoin.
• Use small, accessible example compositions and explicit CSS for unstyled components. Distinguish example styling from Quoin-provided behavior. Preserve requested color scheme and readable contrast.
• Update relevant library pages, generated discovery outputs, MCP descriptions, and user documentation with each delivered slice. No new public route is required merely to add Quoin. Verify generated links and metadata rather than hand-copying catalog content.
• No standalone broad refactor is justified by the current evidence. Introduce the narrow renderer distinction alongside the first working Solid component, keeping existing behavior green.
• Finish with a coverage report reconciling all documented public families against the inventory. Every family needs verified implementation guidance; every browser-compatible family needs real executable coverage. Any remaining source or sandbox blocker must be named and prevents an unqualified full-coverage claim.

Testing Decisions

• Primary seam: the existing public catalog-tool request/result interface. Exercise the complete search -> library lookup -> component lookup -> render request journey with real Quoin catalog data. Prefer observable result contracts over tests of helper layout or private functions.
• Extend existing MCP behavior and evaluation tests for Solid filters, exact IDs, dependencies, version constraints, permission-gated documentation, source attribution, pagination, errors, and truthful coverage. Use representative fixtures per behavior, not a repeated assertion for every implementation line.
• Use the existing in-memory MCP client/server seam for transport-facing assertions, including additive schema behavior, delivery of runtime metadata, and keeping executable bundles out of model-facing text.
• Use existing artifact/compiler and package-integrity checks to verify example compilation, real exports, exact dependencies, browser entry selection, license retention, and sandbox/HTML output contracts.
• Runtime behavior requires actual DOM execution. Prefer a focused automated DOM harness exercising the emitted Solid module with genuine Quoin code: signal updates, required provider wiring, mount/dispose, and representative focus/portal behavior. Layout-dependent positioning cannot be established by static or simulated-DOM assertions; record that verification limit explicitly.
• Live browser or MCP-client UI testing requires the user's explicit request under the repository rules. This specification does not authorize it, and a build or emitted HTML string must not be reported as a successful client render.
• Keep a focused existing React journey as regression coverage for the shared renderer change. Do not create a broad duplicate test suite.
• For implementation, run the required typecheck and npm test, which builds first. For this planning-only change, review Markdown, references, dependency ordering, and consistency; do not run application builds.

Out of Scope

• Migrating Col's Next.js application or its own interface to Solid or Quoin.
• Giving the MCP server filesystem writes, package installation, arbitrary source execution, or project-generation capabilities.
• Supporting Solid 1 or automatically migrating users' existing applications.
• Assuming every other Solid library supports Solid 2 because Quoin does.
• Replacing genuine Quoin components with React equivalents or custom approximations.
• SSR, hydration, server functions, and backend-dependent demos inside the isolated preview sandbox. Document verified application guidance where relevant without claiming these execute in the sandbox.
• Automatic upgrades to floating prerelease tags, unrelated catalog cleanup, and changes to repository hosting configuration.
• Implementation, deployment, commits, or pull requests as part of this issue/spec authoring task.

Further Notes

• User intent: full support for using SolidJS 2 RC and Quoin through Col MCP, not a preview-only feature and not a five-component cap.
• Track the entire feature in this single issue. The implementation stages below are internal checklists, not separate issues or sub-issues.
• Background: #40 describes the original Col MCP work and is completed; it is not an open blocker.
• Stage ordering: 1 can start immediately; 2 depends on 1; 3, 4, 5, and 6 depend only on 2. Later component families do not depend on unrelated family work. Check the full inventory collectively before declaring this issue complete.
• References: Quoin registry metadata, Solid registry metadata, user-provided jsDelivr page, Solid 2 RC documentation, Quoin repository.
• Planning date: 2026-10-28. Registry links are live endpoints; the version facts above record the observed versions rather than promising that latest will remain unchanged.

Delivery status — awaiting PR merge

Implementation and acceptance verification are complete as of 2026-10-28 at commit e64d25d116e9e901e8ec7350c616aa680b0e08fd. All 40 acceptance criteria below are satisfied. The workflow remains started/open because git.cafe has no separate review state; do not close this issue until Screen merges PR #1000000004, whose description includes Closes #68.

• All 40 public Quoin component/provider families have verified API evidence, readable Solid examples, and executable coverage.
• Official demo styling is restored. The seven families without upstream demos remain explicitly authored compositions using cited upstream styles.
• Verification: 242/242 tests, 160/160 desktop/mobile light/dark browser cases, 40/40 MCP Apps previews, and 94/94 upstream-style comparisons passed. Final Drawer/OTP checks passed 8/8; final focused Quoin checks passed 49/49.
• Independent completion audit found no missing implementation requirements. Browser-engine and client limitations remain documented in the verification report.

Implementation stages and acceptance criteria

Stage 01: Discover Quoin and retrieve verified Solid 2 implementation guidance

What to build: A developer can find Quoin in Col and through MCP, inspect exact Solid 2 RC requirements, and retrieve enough verified Button API and example evidence for an agent to implement a real Quoin Button in an application. Establish the pinned-release coverage inventory for the remaining stages.

Depends on stage: None (can start immediately)

• Quoin has a verified library listing, detail page, official setup/source links, appropriate existing taxonomy, and matching generated discovery outputs.
• SolidJS-filtered MCP search and library/component lookup resolve stable Quoin/Button identifiers and link verified component documentation.
• Lookup returns exact dependency requirements, RC status, source revision, verification date, and honest unknowns without generated installation commands.
• An agent can retrieve bounded Button API, composition, state/event, and styling evidence with a source-linked Solid 2 example; reuse permission is recorded before serving snapshots.
• The example compiles against the pinned real packages; render availability remains explicitly unavailable until stage 02 lands.
• Every documented public family is inventoried and mapped to stages 02–06; undocumented exports and missing source evidence are recorded instead of invented.
• Public-tool and generated-discovery tests verify the complete discovery-to-implementation-evidence journey.
• User documentation explains how agents use the feature and distinguishes implementation guidance from optional rendering.

Stage 02: Use and render genuine Quoin controls with Solid 2

What to build: Developers can retrieve implementation guidance and execute real Button, Checkbox/Checkbox Group, Radio/Radio Group, Switch, Toggle/Toggle Group, and Slider examples through the existing MCP rendering formats. This slice introduces the narrow Solid runtime path as part of a working end-to-end feature.

Depends on stage: 01: Discover Quoin and retrieve verified Solid 2 implementation guidance

• Each documented control family is discoverable and has verified API, controlled-state, callback, styling, and accessibility guidance.
• Reviewed examples compile at build time using the pinned Quoin/Solid compatibility set and authentic browser exports.
• MCP Apps and standalone HTML select Solid for Quoin, preserve source identity and limitations, and use the same implementation.
• Mounting, signal changes, replacement, and disposal work in focused DOM execution checks, including listener/root cleanup.
• Existing React entries still use their existing runtime and pass focused public-contract regression checks.
• Source bundles remain out of model-facing text; readable implementation examples remain retrievable separately.
• Integrity records, licenses, sandbox restrictions, request correlation, theme/CSS handling, and visible failures are retained.
• Coverage and user documentation distinguish automated evidence from any unperformed live-client verification.

Stage 03: Implement Quoin disclosure and display components through Col MCP

What to build: Agents can discover, inspect, implement, and optionally render Quoin Accordion, Collapsible, Tabs, Avatar, Progress, Meter, Scroll Area, and Separator using verified Solid 2 examples.

Depends on stage: 02: Use and render genuine Quoin controls with Solid 2

• Every documented family in this group has a verified component identity, official source, API/part evidence, dependencies, and useful implementation example.
• Disclosure examples demonstrate actual state transitions and keyboard semantics; display examples demonstrate meaningful states and styling hooks.
• Executable examples use the existing Solid path and actual Quoin code with explicit CSS rather than substitute components.
• Public-tool journeys, compilation, and focused DOM behavior tests cover distinct behaviors; layout-dependent checks are not claimed from a simulated DOM.
• Both rendering formats, coverage records, generated discovery output, and affected documentation agree on support and limitations.

Stage 04: Implement Quoin forms and selection components through Col MCP

What to build: Agents can retrieve and use real Solid 2 compositions for Field, Fieldset, Form, Input, Number Field, OTP Field, Select, Combobox, and Autocomplete, including optional executable examples.

Depends on stage: 02: Use and render genuine Quoin controls with Solid 2

• Each documented family is discoverable with verified imports, API/parts, dependencies, and component-level examples.
• Guidance explains value ownership, callbacks, labels, validation, disabled states, and required providers using the pinned release's actual APIs.
• Selection examples demonstrate documented keyboard selection and dismissal with authentic Quoin primitives and required positioning dependencies.
• Examples compile and execute on the shared Solid path; required provider contexts share one dependency graph.
• Tests exercise the public discovery-to-example/render journey plus representative value, validation, and keyboard behaviors without duplicating implementation details.
• Coverage, discovery output, styling guidance, and verification limitations remain accurate in both rendering formats.

Stage 05: Implement Quoin overlays through Col MCP

What to build: Agents can implement Dialog, Alert Dialog, Popover, Tooltip, Preview Card, and Drawer with verified Solid 2 compositions, and inspect genuine interactive examples where the sandbox supports them.

Depends on stage: 02: Use and render genuine Quoin controls with Solid 2

• Each documented overlay has verified API/parts, controlled-state examples, required provider guidance, styling hooks, source links, and dependencies.
• Compound and headless APIs are distinguished where documented, including the DOM/focus responsibilities of a headless composition.
• Rendered examples exercise genuine Quoin portals, opening/closing, dismissal, focus management, and positioning dependencies without broadening sandbox permissions.
• Replacing an example disposes portal content and associated state/listeners.
• Public-contract, compilation, and focused DOM tests verify distinct behaviors; actual layout/positioning remains an explicit verification limit unless separately authorized and checked.
• Coverage and client-facing documentation report any precise sandbox limitation without replacing the component or withholding usable implementation guidance.

Stage 06: Implement Quoin menus, navigation, and provider compositions through Col MCP

What to build: Agents can implement Menu, Submenu, Context Menu, Menubar, Navigation Menu, and Toolbar with the pinned release's documented provider compositions and optional real Solid 2 rendering.

Depends on stage: 02: Use and render genuine Quoin controls with Solid 2

• Every documented family in this group is discoverable with bounded API/part evidence, imports, examples, dependencies, and source provenance.
• Direction Provider and CSP Provider guidance is covered where those exports exist in the pinned release; examples explain when each is required.
• Examples demonstrate documented selection callbacks, keyboard navigation, nested interactions, dismissal, and focus return without performing external navigation or actions.
• Genuine Quoin implementations use the shared pinned Solid graph and preserve sandbox restrictions; provider configuration does not imply relaxed CSP.
• Public-tool journeys, example compilation, and focused DOM tests verify representative nested-menu/provider behaviors and clean teardown.
• Coverage records map every family in this group to its evidence, execution status, and limitations, without claiming completion of unrelated groups.
• Generated discovery outputs and user documentation agree with MCP results and both rendering formats.