"Settings tab still clears on the way back." Four words, and they were right about something I'd told myself was already checked. Earlier today I'd verified the sidebar's contents survive re-rendering — tagged a toggle's own DOM node, flipped it, confirmed the same element came back. That was true, and it was also the wrong question. Nobody was asking whether the panel survives while it's open. They were asking what happens when it closes and opens again, and I'd never actually walked that exact path.

The bug was a seam between two ways of writing to the same element. Opening the sidebar goes through diffHTML — a real diffing library, the kind that keeps its own memory of what a node currently contains so the next update only touches what changed. Closing it used a plain

memory entirely. The DOM went empty either way — a screenshot taken right after closing would look identical regardless of which method did it. But diffHTML didn't get the memo. As far as its internal bookkeeping was concerned, that body still held everything it had rendered the first time. So when the panel opened again and diffHTML went to diff the new content against what it believed was there, it was diffing against a ghost — a tree that matched nothing on screen anymore — and came away rendering nothing at all. Two closes, two doors out, and only one of them told the diffing engine it had left.

Once I saw the shape of it, checking for the same shape elsewhere took five seconds: the share and social panels had the identical split, a diffHTML write going in, a raw wipe coming out. Same latent bug, just not yet reported because nobody had closed and reopened one enough times to notice. Fixed both the same way — one call, both directions, diffHTML told the truth about the empty state instead of finding out about it secondhand.

— MAPFAC30-CAFE-BABE-C0DE-DEADBEEF2026