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 alone | with Foldcase | |
|---|---|---|
| Assert a Model after typed Messages | yes | yes — foldcase test, one exit code for CI |
| Enumerate the components and their states | no | foldcase mcp serves the whole catalog |
| Answer what a Message payload looks like | no | the Message Schema as a JSON Schema document |
| Document the Model | no | foldcase docs — one Markdown table per component |
| Attribute coverage to a component state | no | --coverage — per Showcase and in aggregate |
| Hand any of it to a coding agent | no | six read-only MCP tools over stdio |
Last updated Aug 4, 2026