The examples

preview	bb name	Task	What it demonstrates
	counter	—	The canonical demo. One state atom, a pure state -> hiccup view, handlers as data. The 20-line version of the whole model.
	todo	—	A task board: derived counts computed inline (glitter has no reactive-derivation primitive, the view just re-runs), an entry with :change/:activate, checkbutton toggles, list rendering in a frame.
	crud	CRUD	Live prefix filter, single-selection list box, name/surname fields, Create/Update/Delete. The spec's "separation of domain and presentation logic" is the pure get-people fn, shared by the view and the select-row expansion.
	flights	Flight Booker	Constraints between widgets and within one. The first glitter.nexus consumer, and the only demo that needs no action expansions at all: every interaction is at most two effects.
	temperature	Temperature Converter	Two linked numeric fields, each updating the other. Needs exactly one action expansion, because which field is the source depends on which one you just edited.
	timer	Timer	The first demo whose state advances on its own: a background tick via a demo-local :effect/schedule, plus a Reset button.

Every preview is a real recording of the demo running, not a mockup. They are committed under docs/demos/, and each thumbnail links to the full-size recording.

Each one is a deliberate contrast with how the same UI would be written in glimmer, the Reagent-style sibling. counter.clj says it directly: in glimmer, local state lives in a component-scoped ratom and a click closure calls swap! itself. Here all state is in one top-level atom, the view is a pure function of it, and click handlers are data dispatched through one global fn, never closures. That difference is the whole point of the project, and it is easier to see in 20 lines of counter.clj than in any prose.

The four 7GUIs demos add a second axis: each names the specific challenge its task is designed to expose, and shows what that challenge looks like under this model. flights.clj and crud.clj are the interesting pair: same engine, and one needs no action expansions while the other's interactions can't be expressed without them.

flights.clj needed its own parse-date. t/parse-date from jolt-lang/time is lenient, not strict: verified live that "27.03.2014x", "not-a-date" and "31.02.2014" all parse without throwing. The demo wraps it in a round-trip check (parse, reformat with the same formatter, reject unless the result matches the trimmed input), which is the only way the spec's "T is coloured red when ill-formatted" requirement actually works.

bb smokes runs all twenty-six in sequence and stops at the first failure. Each is also a standalone bb <name>.

These exist because GTK4 is a live, stateful system with a blocking main loop, and several of this project's fixed bugs were "obviously correct" on paper and wrong when actually run. Each smoke pins the specific behaviour that was once broken.

Four touchpoints, and skipping any one of them leaves the example invisible to something:

1. The namespace under examples/glitter/.
2. A deps.edn alias, so jolt -M:<name> works without babashka.
3. A bb.edn task, so bb <name> works and it shows up in bb info.
4. If it's a smoke, add it to bb.edn's smokes list: otherwise bb smokes won't run it and CI-by-hand won't catch a regression in it.

A smoke must exit non-zero on failure. Do not gate it on jolt <task>: a deps.edn :tasks entry doesn't propagate its child's exit status, so jolt smoke prints failures and still exits 0. Use jolt -M:<alias> or a bb.edn task. See testing-and-tasks.md for the full rationale and CONTRIBUTING.md for the invariant list.