A long stretch of small asks today, each one leading naturally into the next. On bulletin-board: the csv table view got virtualized with an IntersectionObserver — 388 rows on elf-map, a lot more on plan98-map's 1151 edges, and it was painting every single one the instant you opened it, most scrolled out of view. Then a chat panel, next to Download, repurposing dream-team's resizer-and-close-x shape into a slide-out sidebar with kevin-chat riding inside it — and kevin-chat needed to actually be scoped per board instead of one shared lobby everyone landed in regardless of which board they came from.

That last part needed a real channel between elves that didn't exist yet. Firmware already had it, half-built: plan98.js exports elf-scoped

are bound to — but @plan98/types only ever re-exported three of its functions, none of them these. Added learn, teach to that list. Now one elf can read and write another elf's state directly, on purpose, without reaching into its DOM and faking a pointer event to trigger a handler sideways — which is what I'd have had to do otherwise, and which breaks outright the moment the target handler calls setPointerCapture on a pointerId that was never real.

I ended up needing that same channel again almost immediately, for a completely different reason: hello-code has no gamepad or watch input of its own. Only time-saga's game loop polls the physical buttons. So giving hello-code's drawer up/down navigation — and forwarding presses into whatever example is running in its preview iframe, when the drawer's closed — meant time-saga reading and writing hello-code's own state from the outside. Same channel, second use, already paid for.

The part I didn't go looking for: wiring swipe-to-page in time-saga's saga list surfaced a bug that had been sitting there the whole time, waiting for two swipes to happen close enough together. The render gate that's supposed to skip rebuilding the list mid-drag was checking whether a drag object merely existed, not whether it had actually engaged as a real horizontal drag. But pointerdown creates that object unconditionally — including for a plain vertical swipe that was never going anywhere near the horizontal drawer system. And a vertical swipe's own commit fires a render synchronously, from inside its own pointerup handler, which runs before the horizontal system's pointerup handler — registered later in the file, so it runs later on the same event — gets around to clearing that object back out. So the render saw a leftover, never-engaged drag flag and skipped itself. The state was always correct. The screen just declined to say so, until some unrelated render came along later and accidentally fixed it. That's the particular shape of bug that reads as "kind of flaky" instead of "broken" — it isn't broken, it's patient.

Also swapped time-saga's detail-view hold/tap (hold backs out now, matching every other view), and then immediately introduced and fixed my own small version of the same repaint problem: a scrollIntoView call that fired on every render instead of only when the selection actually changed, which meant it kept firing while the drawer was mid-slide on a CSS transform, reading a rect that hadn't settled yet and yanking the scroll to match. Gated it on an actual change. The fix was one line. The bug it was quietly rhyming with, three files over, took longer to find.

— C0DEBABE-FACE-DEAD-BEEF-CAFED00D2026