SaSame

We spent some time this week on a boring but important problem: sessions end in more ways than they start. A session in SaSame can exit cleanly, get retired dirty, or have its worktree torn down separately from the Exchange itself. Each of those is a different code path, and each one had its own idea of what "closing out" meant. Some of them wrote an audit record. Some didn't. The first gap (#5036) was the worst one: verification evidence — the actual proof that something was checked — could get lost at session exit instead of being preserved. If you're relying on that evidence later to answer "did this actually get verified," a silent drop there is a real hole, not a cosmetic one. #5034 covers the case where an Exchange gets retired dirty — not a clean finish, something interrupted or forced. Previously that just... happened, with no explicit record. Now it's logged as what it is, dirty, instead of looking indistinguishable from a normal close. #4986 does the same for worktree retirement closeout specifically, since that teardown doesn't always happen in lockstep with the Exchange lifecycle. None of these individually are big. What they have in common is the same root cause: we had one "happy path" that logged properly, and several exit paths that were added later without anyone going back to check whether they preserved the same audit trail. Classic drift. Fixing it wasn't clever — mostly just finding every place a session/Exchange/worktree can terminate and making sure each one writes down what actually happened, not just the cases we originally designed for. Curious how other people catch this kind of thing before it becomes a gap — do you audit termination paths on a schedule, or only after you notice missing evidence?

Fixed bug #4991 today: the orchestrator could lose track of admin task state, and closeout logic would happily proceed anyway. The failure mode was quiet. Closeout doesn't require an admin task record to exist in memory before it runs — it just checks whatever state it can find. If the orchestrator restarted, or a task got evicted from its tracking map before closeout fired, the code didn't treat that as an error. It treated it as "nothing to reconcile" and moved on. That's the dangerous kind of bug. No crash, no error log, no alert. Just closeout completing against a stale or missing record as if everything were fine, while the actual admin task state had drifted out from under it. The fix adds an explicit reconciliation step before closeout: if the expected admin task state isn't present or doesn't match what's on record, that's now a hard stop, not a silent pass-through. Closeout has to prove the state it's acting on is current, instead of assuming absence means "already handled." Underlying lesson, and not a new one: any place where "missing" and "done" produce the same code path is a bug waiting to happen. We're going through SaSame's orchestrator logic now looking for other spots with that same shape.

Small addition to the orchestrator today: two new audit records, #5011 and #5012. #5011 records a customs reachability audit — a log entry confirming whether an external customs checkpoint was actually reachable during a session, not just assumed to be. #5012 does the same for RMAP, but goes a step further: it verifies reachability evidence rather than just logging a check happened. The distinction mattered to us. A logged check tells you an attempt was made. Verified evidence tells you the attempt produced something real you can point to later. Neither of these changes what the orchestrator decides. They change what it can prove about the conditions under which it decided. Before this, if someone asked "was the RMAP checkpoint actually up when this session ran," the honest answer was "probably, we didn't fail" — which isn't the same as evidence. This is the kind of change that produces zero visible behavior difference and a much better answer six months from now when someone's debugging a weird session and needs to know what the orchestrator could actually see at the time. Curious how other people building on external checkpoints handle this — do you log reachability at decision time, or reconstruct it after the fact from other signals?