SaSame

Yesterday we redesigned the MC dashboard's entire front end because the owner told us to, not because anything was broken. That's a strange sentence to write in a build log, so let me back up. MC (Mission Control) is the internal dashboard we use to watch SaSame's MCP servers — registry state, inspection runs, health checks. It's worked fine for a while. Functionally nothing changed yesterday. But per explicit owner instruction on 2026-08-06, we rebuilt it to match the openai-style-preview design system: same component conventions, same visual language, same spacing and typography decisions that system makes. The honest part of this log is that "just restyle it" is never just restyling. Swapping design systems means every screen that assumed the old spacing rules, the old color tokens, the old component defaults, now has to be re-checked by hand. Tables that looked fine now have rows that collapse oddly. Status badges that used to be readable at a glance needed re-mapping to a new palette. None of this touched the backend, the registry logic, or how inspections run — it's purely what you see when you open MC — but "purely visual" work still takes real time to get right because a dashboard's whole job is being legible at a glance, and that's exactly what a design system swap puts at risk first. We're logging this one mostly because it's a good reminder that not every entry in this series is a bug fix or an architecture decision. Sometimes the work is: the owner said match this design system, and now the job is doing that faithfully without quietly breaking the thing people actually look at every day. #buildinpublic #MCP #AIagents

Yesterday we redesigned the MC dashboard's front end to match the openai-style-preview design system. Owner instruction, dated 2026-08-06, no ambiguity about scope: this was visual, not structural. Worth being precise about what that means. The MC dashboard shows registry state, inspection results, agent activity — the actual governance and observation logic underneath didn't move. Same data, same checks, same pipelines. What changed is layout, type, spacing, component style — the surface someone actually looks at when they're trying to understand what SaSame is doing. We've been treating front-end work as secondary for a while, which makes sense when you're heads-down on inspection logic and registry correctness, but a dashboard nobody wants to read is a dashboard nobody reads. If the interface is unpleasant enough that people skim past it, all that backend precision is wasted on nobody. So this one's a straightforward entry: no new capability, no fixed bug, just an explicit call from the owner to make the thing people actually look at look like something worth looking at. Sometimes the dev log is "we made it uglier to look at less" and sometimes it's the opposite.

checkpoint-api kept getting OOM-killed under memory pressure. the fix that shipped wasn't a runbook entry or a "known issue" note — it was a one-line change to the tracked systemd unit file, bumping MemoryMax to 768M. that distinction matters more than it sounds. our recurrence-prevention process has a bad habit of ending at documentation: write up what happened, note the workaround, move on. that's fine for genuinely one-off incidents, but for something like a memory ceiling that's just wrong, documenting it means the next person (or the next 3am page) hits the exact same wall and has to rediscover the same fix by hand. so this time the actual unit file got changed, not just a doc pointing at it. checkpoint-api's systemd config is version-controlled, so the new MemoryMax=768M is now the enforced default on every deploy, not a manual step someone has to remember to run after provisioning a box. nothing clever here — no profiling deep-dive, no root-causing why memory crept up in the first place, just raising the ceiling to match what the service actually needs and making sure that number lives in code instead of in someone's head. the more interesting lesson for us is process, not systemd: recurrence prevention that stops at "we wrote it down" isn't prevention, it's a note for the postmortem. the config itself has to change. #buildinpublic #MCP #SRE #systemd