apps that travel between tiny computers.
Every clip below is a recording of the real thing, compiled to WebAssembly and running live one click away. puck is a device-agnostic emulator, a set of self-contained device packs, and a set of portable app bundles; open any run page to touch the actual emulator, not a mockup.
Each cell is a real build of that app's own port, for that device pack's real firmware, verified by the shared harness (bun run verify-bundle): click through to run it live. Every cell shown is emulator-proven; a cell additionally marked ● on silicon has also been run against the real board over serial, an attestation, not an automatic guarantee (hover or focus the mark for when and how).
| RP2350-Touch-AMOLED-1.8 | ESP32-S3-Touch-AMOLED-1.8 | Web-Touch | |
|---|---|---|---|
| chrono | nativepixel-exact● on silicon | faithful portpixel-exact● on silicon | faithful portpixel-exact |
| fluidbox | adaptationinvariants (degraded) | not ported | adaptationinvariants |
Not a port: each device pack's own shipped app, plus the instrument's own minimal example firmware - every tile below links to it running live, the same as the cards above.
A bouncing square: the pack's own reference app, proving its band-render contract with nothing borrowed from another device.
The instrument's own minimal reference firmware: a 240x240 panel, two buttons (one with a long-press verdict), a shake sensor, and a scripted two-button chord. Not a device pack, not a ported app - the smallest complete emu_device() implementation, and where a new firmware author starts.
A self-contained folder for one target: real drivers, a real board's firmware, and a device.json descriptor the emulator reads at runtime. Nothing in the shared instrument names one device; every panel size and button comes from the pack itself. The browser is one of those targets, so a phone is a device pack too, and an app ported to it goes through the same verifier as an app ported to a chip.
An app is defined by its descriptor and traces, not by one implementation's source code: what appears on screen, every interaction, and separate requirements from preferences. A port starts with a verdict against the target pack, stated plainly, before any code is written.
app-bundle.mdA faithful port replays its traces and compares frames pixel for pixel. An adaptation states behavioral invariants instead, and gets checked against those. Either way, the same shared harness decides, not a claim in a README.
harness.md