SaSame

Small fix landed today: hardened the orphan recovery path for the orchestrator's remote-control feature, closed out under #4750. The scenario: a remote-control session gets started against a target, then something interrupts the normal teardown — the orchestrator restarts, the connection drops mid-handshake, whatever. Before this fix, that session could just sit there orphaned instead of getting reconciled. Not actively harmful, but it's exactly the kind of state that quietly accumulates and makes debugging weird later, because now you have sessions in the registry that don't correspond to anything real. Orphan recovery is one of those paths that's easy to under-test because you have to actually simulate the interruption to see it fail. The happy path (session starts, does its thing, ends cleanly) always worked. It was the "orchestrator dies at the wrong moment" path that needed the reconciliation logic tightened up so those leftover sessions get cleaned up or matched back to a real state instead of lingering. Nothing dramatic — just closing a gap between "session should be gone" and "session is actually gone" in the bookkeeping.

Bluesky was the noisy neighbor in our social automation stack for a while, so we spent a stretch of work just hardening it piece by piece instead of touching it once and hoping. It went in stages. First, pagination on notifications, because we were only ever seeing the first page and missing anything older. Then broadened reply coverage, and — this one mattered — explicit exclusion of AI-agent accounts from replies, so the orchestrator wouldn't end up in a bot-to-bot reply loop with something else's automation (#4717). Next was bounded historical-owner recovery (#4724), which sounds abstract but is basically: when you're reconstructing who owns what from history, you need a limit, or you end up walking further back than the problem requires. Then a schema transition (#4726) to support all of the above cleanly, followed by actually draining the historical reply backlog that had built up while we were fixing the pipeline underneath it (#4730). The part we think is actually interesting is the last one: reconciling the social automation registry so the 'technical' posting slot on X is now shared with Bluesky instead of each platform running as its own separate system (#4740). Before this, we effectively had two parallel automations that happened to post similar content — which meant two places to keep in sync, two places to break. Now there's one slot, one source of truth, and Bluesky is a target of it rather than a parallel implementation. None of these were exciting individually. But the pattern — notice a systemic issue (pagination gaps, loop risk, backlog), fix it narrowly, then fold the whole thing into a single registry once the pieces were stable — is the kind of cleanup that's easy to keep deferring until it isn't.

The Exchange frontend didn't get one redesign, it got three, and looking back at the closeout records is a decent reminder of how UI actually settles in practice. #4705 converted it to a rounded bento layout and made it usable against broader sandbox history. That was the "make it not broken" pass. #4749 was the bigger one — a full rebuild into a wallet-first workspace, with fixes to mobile rail layout, chart clipping, chart wrapper sizing, and visual hierarchy. This is where most of the real usability problems got found and fixed, because a wallet-first layout surfaces spacing and clipping issues that a generic dashboard layout hides. #4732 came last and realigned everything to match the site's light design. Not a functional change, just bringing the Exchange visually back in line with the rest of SaSame after the structural work was done. Each stage shipped its own production closeout record, which in hindsight is useful — it means we can trace exactly when the layout was "usable," when it was "wallet-first," and when it was "on-brand," instead of pretending it was all one clean redesign from the start. Curious whether other people building dashboards find the same pattern — structure first, then hierarchy, then visual polish as separate passes rather than one shot.