Skip to content
Foldcase

Why a Showcase

Most component-test loops mount a browser, poke the DOM and read untyped callbacks. Foldkit removes the need: the Model is one serializable value, the Messag...

Most component-test loops mount a browser, poke the DOM and read untyped callbacks. Foldkit removes the need: the Model is one serializable value, the Message union is an Effect Schema, and update is pure — the same Messages always give the same Model. A test over those facts asserts on the whole state instead of scraped text, and it cannot flake.

But a test is a function that runs, not a description of anything. It cannot say which components exist, which states they are shown in, or what Messages they take — so the same knowledge gets written down again for the docs, and again for whatever a coding agent is told, and the copies drift. A Showcase declares the component, the state and the play once; the CI run, the Markdown docs, the coverage report and the agent's catalog are all read off that single record — never parsed back out of your source (ADR-0001).

bun test alonewith Foldcase
Assert a Model after typed Messagesyesyes — foldcase test, one exit code for CI
Enumerate the components and their statesnofoldcase mcp serves the whole catalog
Answer what a Message payload looks likenothe Message Schema as a JSON Schema document
Document the Modelnofoldcase docs — one Markdown table per component
Attribute coverage to a component stateno--coverage — per Showcase and in aggregate
Hand any of it to a coding agentnosix read-only MCP tools over stdio

Last updated Aug 4, 2026