🐤 Coding Canary
Code is not the deliverable. The running app a human sees is. A coding AI will happily call something "done" because it compiles — without ever looking at the screen a person actually uses. Coding Canary closes that gap: after a change ships, it flies to each change in the live UI and makes the builder say, in plain words, what it does. If the Canary can't fly to it, it isn't done.
One concept: a change-escort. Give it a list of changes — each a {where it lives, what changed, which version} — plus a little config, and it escorts the viewer to each one in place, explains it, and leaves until the next version. Drop in, no dependencies, no build step.
Two more things worth knowing
Guided tours: force a press
Add force: true to a step and it stops being optional. Everything outside that one element dims and stops responding to clicks — the "Next" button disappears — and the only way through is actually pressing the real thing. Its own click still works normally underneath; the tour just also notices. Good for "press this button and see what happens" onboarding, where you want to know the visitor genuinely did it, not just clicked past a tooltip.
press me
The "press me" chip does nothing on its own — it's only here so the demo has something harmless to spotlight instead of gating a real button on the page.
Cadence: make it a true one-off
cadence: 'once-per-version' is meant for you, re-verifying your own changes after every release — it comes back when you bump the version. A first-run tour for your actual visitors wants cadence: 'once-ever' instead: it shows exactly once on that device, full stop, and nothing brings it back later. (If a canary tour has ever shown up over and over on the same app: that's what happens when a one-time tour is wired to 'once-per-version' instead of 'once-ever'.)
Free to use and share, no attribution required (though we won't say no). No account, no tracking, no dependencies — it's about 130 lines you can read in a few minutes.