SaSame

Under #4367 we went back through the autonomous task-cleanup pipeline and fixed four ways it could quietly break on real-world flakiness instead of actually cleaning up. Tmux startup would sometimes fail transiently and the pipeline treated that as a hard failure, killing the whole task. Now it retries once before giving up — most of those failures were never real, just timing. The worktree task module had no size cap and could grow unbounded over time. It's capped now. When a manual CI job got cancelled, the slot it was holding didn't always get released, which meant it sat there blocking capacity for no reason. Cleanup now releases the slot on cancellation. Branch cleanup was the trickiest one: it could delete a local branch before the remote retirement was actually confirmed, which is the kind of bug you don't notice until it's already cost someone a branch. Cleanup now gates on confirmed remote retirement before touching anything locally. None of these are dramatic individually. Together they're the difference between "automate safe task cleanup" being a design intention and it being a pipeline that survives contact with a tmux hiccup, a cancelled job, or a slow remote. That gap is usually where these things live.

Mission Control's dashboard was crying wolf for a while: cached telemetry was getting served up as live status, so nodes that were actually fine showed as failures. Fixed in #4353. Root cause was boring in the way these things usually are — a cache layer that outlived the freshness assumptions we'd built the UI around. The more interesting decision was what we didn't change. The dashboard's summary output stays public-readable, no auth gate. Mission Control watches MCP servers in the registry, and the whole point of SaSame is that inspection shouldn't be a privileged view — if we hide the health data behind a login, we're just building another opaque system with extra steps. So the fix was scoped to the bug, not to locking things down. Fixing the false failures surfaced a second problem though: once we trusted the dashboard again, we noticed different pipelines reporting different numbers for what should've been the same metric. Not wildly off, just inconsistent enough to erode confidence in any single figure. That kicked off a follow-up to converge everything onto one canonical measurement source instead of letting each pipeline compute its own version of "truth." Closed that out with recorded measurement evidence rather than just a changelog line — if we're going to claim the numbers agree now, there should be something to point at. Two failure modes in one week: stale data pretending to be fresh, and fresh data disagreeing with itself. Different bugs, same lesson — public dashboards only earn trust if the pipeline behind them does too.

#4342 shipped this week: SEO/AEO work on the public site UI, plus new GEO access controls, in the same change window. The SEO/AEO part is what you'd expect — cleaning up the site so it reads well both for search crawlers and for answer engines that scrape a page and summarize it without a click-through. Those are slightly different audiences and the markup has to serve both. The GEO part is unrelated on the surface but landed at the same time: evidence-backed geographic access controls, meaning restrictions that are tied to actual verifiable signals rather than a simple header check. Bundling those two together in one window is honestly a little risky, and it showed. The rework touched enough of the site's runtime behavior that a smoke-test drift had crept in — tests that had quietly stopped matching what the app actually does anymore, the kind of gap that builds up silently during any UI rework. We'd also hardened runtime verification for the site as part of this pass, and that's what caught it. The stricter checks flagged the mismatch before it shipped, not after. So the actual takeaway isn't the SEO changes, it's that the guardrail did its job — it caught a real regression introduced by the same PR it shipped alongside. Which is the annoying but correct order of operations: tighten verification, then let it immediately prove its worth by catching your own mistake.