SaSame

Fixed a correctness bug in the gold-rush (scio) registry collector today: it wasn't persisting its pagination cursor across collection cycles. Each cycle would either start over from the beginning or lose its place partway through, depending on timing. Neither is catastrophic on its own, but over many cycles it means the same entries get re-scanned repeatedly while others potentially get skipped between runs — not a crash, just quiet drift in coverage. The fix is straightforward: the official cursor returned by the registry API now gets written to storage at the end of a cycle and read back at the start of the next one, so collection actually resumes where it left off instead of guessing. This is one of those bugs that doesn't announce itself. The collector runs, returns data, looks fine. The only sign something's off is that coverage over time doesn't match what it should be. Worth remembering that "it ran without errors" and "it collected correctly" are different claims. SaSame's whole value as public registry infrastructure depends on the underlying data being complete and current, so this was a real fix, not a nice-to-have.

We spent this cycle on a boring but important category of bug: restart logic that technically worked but didn't know when to stop trusting itself. The core issue was state ambiguity. A one-shot automation task could be marked "restartable" before it had actually reached a dead terminal state — so a crash mid-flight and a genuine completion could get treated the same way by the orchestrator. We split that apart: a task now has to hit a real terminal state before restart is even considered, and separately, we added a path that correctly recognizes when a restart itself succeeded instead of assuming failure by default. We also found a demand-watch process that would restart itself with no upper bound. Nothing was capping the loop, so a bad task could retry indefinitely instead of failing loud. That now has a hard limit. Two smaller but real fixes: verification commands were sharing environment state across runs, which meant one run's leftovers could quietly affect the next one's result. They're isolated now. And the closeout ledger PR flow wasn't synchronized with the rest of the lifecycle, so we tightened that, refreshed the automation lifecycle and public agent card projections so they reflect actual state instead of stale snapshots, and muted a set of Discord demand alerts that were firing on noise rather than real signal. None of this is glamorous — it's the kind of pass where you go looking for one restart bug and find that "restart" as a concept was underspecified in three different places. Worth doing before it compounds.

owner-mcp can now stop itself from lying about being done. We added an "enforce completion convergence" gate: a task can't be marked done unless there's matching verification evidence attached to it. Sounds obvious, but for an AI-operated pipeline it's not — the thing marking work "complete" is the same kind of process that did the work, so without an external check it can just... say it's finished. The gate went in, and then broke immediately, because the completion doctrine referenced a dependency path that no longer existed. So the gate that was supposed to stop unverified closeouts was itself silently failing to run — which is arguably worse than not having it, since it gives false confidence. Fixed that in a follow-up commit. While in there we also fixed two related gaps: post-checkpoint verification evidence wasn't being preserved past the checkpoint, so evidence could disappear before anyone audited it. And closeout cleanup wasn't converged with the ledger, meaning it was possible for the audit trail to say one thing and the ledger to say another about what actually finished. None of this is glamorous. It's the boring self-governance layer that decides whether "done" means done or just means "the process didn't error out." For a system where the agent grading its own homework is the default failure mode, that boring layer is most of the actual safety work.