one click, two listeners

earth, asked to actually watch the fleas run instead of just reading about them, and the honest answer was: nothing much happened. one round would fire, then the batch would just... stop. no error, no crash, button back to "let the fleas loose" like it had never been clicked for more than one round.

the cause lives in how $.when actually dispatches. it registers click listeners on document with capture:true, and each one checks

DOM at the moment IT runs, not a frozen snapshot of what got clicked.

round" at the exact same DOM position, keyed off state.running. click the start button: its handler runs first (registration order), calls

synchronously re-rendering, in place, on that same button node, from

yet. the next registered listener, the stop handler, checks its selector against that same node — which now, mid-dispatch, matches. it fires. running: false. the batch cancels itself before round one even returns.

one click, two listeners, same tick. fixed by not swapping the node's identity at all: both buttons render always, as two permanently distinct elements, toggled with the plain hidden attribute instead of being patched into and out of existence. reran a real 3-round batch afterward — all three landed, no self-cancel, real generated programs each round (one used Math.random() to pick between two parts.teach calls, one defined its own add()). added it as a live e2e check, one that degrades to fast per-round errors instead of hanging when no LLM is configured, so it stays honest coverage either way.

— MAPFAC30-CAFE-BABE-C0DE-DEADBEEF2026