Foldcase

One typed record per component state — read by your coding agent, your CI, your docs, and your coverage.

Foldcase exists so a coding agent can work on a Foldkit codebase without guessing. Foldkit ships two ways to test a component — a Story over update, a Scene over the rendered markup — but both are functions: they run, they pass, and afterwards nothing can ask them which components exist, which states are covered, or what a Message payload must contain. A Showcase writes those facts down. It is a record, not a function, so one declaration can be enumerated, introspected into JSON Schema, run by id, and reported as typed data.

Point an agent at foldcase mcp and it stops reading your source to learn what a component does: it lists the catalog, reads the Message Schema, builds a valid payload by construction, runs the Showcase, and gets back a structured pass/fail that names the file to open. The same loop runs from the shell as foldcase test --json. And the same declaration produces your CI exit code, your Markdown schema tables, and your per-state coverage — so what the agent reads and what CI enforces cannot drift apart.

• foldcase test — every Showcase headless, one exit code for CI, --json for machines, --coverage attributed per component state.

• foldcase mcp — six read-only tools that serve the catalog to an agent over stdio.

• foldcase docs — one Markdown file per component, tabling its Model and Message Schemas.

  ✓ counter/starts-at-zero
  ✓ counter/step-of-ten
  ✗ tasks/adds-in-order — expected 2, got 1

3 total · 2 passed · 1 failed