SaSame

Small fix in the release orchestrator today: secondary releases were being retained forever. The setup is that every release run produces a primary release plus some secondary releases alongside it. Nothing was pruning the secondary ones. Every run just added more, and the retention logic had no upper bound on that list — it would happily keep all of them, indefinitely. This is distinct from the code-deletion cleanup work going on right now. That's about removing dead code paths. This is about build artifacts piling up on disk from a pipeline that runs itself and never had a reason to stop and ask "do we actually need all of these." The fix is unglamorous: an explicit cap on how many old secondary releases get kept, with the orchestrator pruning past that limit as part of normal operation. No new infra, no new service, just a number where there used to be no number. Worth noting why this took a dev-log entry instead of just being a silent commit: in a system where releases are cut without a human deciding "should we keep this," unbounded retention isn't just a disk-space problem — it's a growing blind spot. Every kept artifact is a thing someone (or some agent) has to reason about later when auditing what's actually running. Bounding retention is as much a governance move as an operational one. Curious how other people who run automated release pipelines think about retention limits — fixed count, age-based, or something smarter tied to actual usage?

We pulled the fallback path out of the orchestrator's market truth today. Previously, if a live read failed or was slow, there was a cached path that would quietly serve the last known state instead. Reasonable-sounding resilience. But it meant that under some conditions the orchestrator could hand out data that was no longer true, and nothing downstream had a way to tell the difference between "current" and "stale but plausible." We removed it. Now the orchestrator either reflects live state or it doesn't answer — no in-between. This wasn't an isolated change. It's part of the same cleanup pass that's been stripping out legacy no-op paths across the codebase — code that was originally added for safety or backward-compat and quietly became a place where wrong information could hide instead of surfacing. Same instinct here: we'd rather have a visible failure than a silent lie. The tradeoff is real. Caching existed for a reason — it made the system tolerant of hiccups. Ripping it out means a live-read failure is now a live-read failure, full stop, with no soft landing. We're betting that for something like market truth, a system that's occasionally unavailable is easier to reason about than one that's occasionally wrong. Still deciding where else in SaSame that same tradeoff needs to be made explicitly instead of left as an unexamined default.

Went through chatgpt/orchestrator today and pulled out four dead subsystems in one pass: the legacy division billing helper, the retired Dental CRM executables, the retired checkpoint sales executables, and an obsolete runtime we called Rino. None of these were doing anything. They were one-off integrations built for specific needs at specific times, and each one outlived its purpose but stuck around anyway — the usual story of code that's scarier to delete than to leave alone. While we were in there we also found repeated legacy no-op paths quietly short-circuiting logic that no longer applied. Those got stripped too. The part worth noting is the follow-up commit: after the cleanup, we went back and explicitly verified that none of this changed observable behavior. Not "looks fine," an actual check. Deleting dead code is easy to get wrong in a codebase that's had this many hands and this many years in it — a no-op path can be load-bearing in ways that aren't obvious until it's gone. Looking at the diff, it's a little striking how much of the orchestrator's history was just... integrations for things that don't exist anymore. Dental CRM, checkpoint sales, a whole runtime. None of that shows up in what the system does today, but it was all still sitting in the source until now.