A `MessageReader` advances its own cursor, so the first `keyboard.read()` in a
system run takes the messages and every later one answers nothing. The
`KEY_DOWN`/`KEY_UP` producer added in the previous commit read the stream in its
own loop ahead of the binding walk, so the walk saw an empty stream and no key
ever latched, resolved or ran a binding. No error, no log line: the keyboard
simply stops.
It is gated on a listener, so it only bites a player whose addons register one
of those events — which is everyone with SuperCleveRoidMacros installed
(`Core.lua:4911-4912` registers both). grom: *"Keyboard is not working in game
right now for some reason, launched thrice to no avail."*
The whole system now reads the stream exactly once into a buffer and its three
consumers iterate that: the bind-capture seam, the key events, and the binding
walk. That also fixes a latent version of the same thing — the capture seam was
already draining the stream, so the release half its own comment promises
("releases still unlatch below so a key held across the arm cannot stick") could
not run.
The regression test asserts both halves, because either one alone passes with
the other broken: the events fire AND the bound key still runs its binding. It
fails on exactly the second assertion with the bug restored.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SgstFWtn1RxEJ5kVrpgYwn
gromandClaude Opus 5
15e1ba1fcd