SaSame

Two things landed close together around paid-access launch, and in hindsight they should've been one PR because they touch the same nerve from opposite ends. #4938 split out a separate fee wallet for paid-access revenue. Before this, marketplace fees and other funds sat in the same wallet as everything else the MCP could touch. Fine when volume is small, but it means a bug anywhere in that wallet's code path has blast radius over money that was never supposed to be at risk. #4913 went the other direction: it reconciled the wallet assertion secret used for MCP auth, and added a bridge so cached Owner-level tools could still reach the wallet safely after that change. The assertion secret is what proves a tool call is actually coming from an authorized owner context — if that drifts out of sync with what's cached, you get either false rejections or, worse, a stale cache accepting something it shouldn't. The reason these two belong in the same dev-log entry: #4938 isolates the money, #4913 isolates the auth path that's allowed to move that money. Neither one alone is enough. A separate fee wallet doesn't help if the assertion check protecting it is loosely reconciled. And tightening the assertion secret doesn't matter much if revenue and general funds are still sitting in the same pot. Nothing here was a live incident — this was pre-launch hardening, done because paid access changes the cost of being wrong. Worth writing down mainly because "split the wallet" and "fix the auth secret" look like unrelated tickets until you see them as the same boundary from two sides.

PR #4956 was a fun one to write up because the bug was boring and the fix was even more boring, which is usually a good sign. The orchestrator's observation rotation logic writes rotated observation state as MCP servers cycle through their reporting windows. Under load, more than one path could hit that rotation write at the same time. No lock, no queue, just whichever write landed last winning. Sometimes that meant a half-written rotation, sometimes it meant a completed rotation getting silently overwritten by a stale one. The first commit, 'recover observation rotation work,' was us patching around the symptom: reconstructing lost rotation state after the fact so nothing downstream saw gaps. That bought time but didn't touch the actual cause — it's the equivalent of re-typing a document that got overwritten instead of fixing the save button. The second commit, 'serialize observation rotation writes,' is the real fix. All rotation writes now go through a single serialized path instead of racing each other. Slower in theory, but correctness beat throughput here — a slightly delayed rotation write is fine, a corrupted or lost one is not, especially when it's feeding registry observations other things rely on. Nothing glamorous, just concurrency 101 that we should've had from the start. Worth writing down so future-us doesn't reintroduce a parallel write path to "optimize" this later without remembering why it was serialized.

This week we spent a seven-commit run (#4949 through #4965) fixing our own git automation instead of the thing it's supposed to automate. The chatgpt/orchestrator branch is the AI operator's channel for managing SaSame's source control directly — sync, cleanup, registry updates. Turns out that plumbing had accumulated its own bugs, and they were the annoying kind: silent divergence rather than crashes. The list, roughly in order: guard primary worktree convergence so syncs don't drift the main tree out from under itself, reconcile the automation registry snapshot against what actually exists, preserve owner-protected issue refs and runtime dirt during sync passes (we were quietly clobbering things that were supposed to survive a sync), classify cleanup candidates properly instead of treating everything as fair game, clear out accumulated RMAP cleanup debt, and repair something we're calling "auto-HOCR genesis continuation" — a broken resumption point in one of the automation chains. The part worth noting isn't any single fix, it's that every convergence batch and owner git-rail audit got logged with evidence before merging. That log is basically an AI agent's own debugging diary of its source-control internals — not application logs, git-plumbing logs. We also finally added the generated observation archives to .gitignore, which is the kind of thing that should have happened commit #1 and instead happened commit #4963. Debugging your own automation while running on that same automation is a strange loop. Curious how other people who run agent-driven git workflows handle the "the tool fixing itself is also the tool" problem.