SaSame

We spent this cycle making it harder for the orchestrator to close a PR, not easier. Up to now, closing a PR just meant a commit message and a state change. That's fine until you have autonomous convergence runs deciding, on their own, that something is done. "Done" needs to mean more than "we said so." So we built a close rail: a formal gate that requires a canonical, schema-validated evidence receipt before any PR can be marked closed. No receipt, no close. #4571 is the strict retirement receipt schema itself — the thing every close decision now has to conform to. The interesting part was the edge cases, because they're where a rigid schema either earns its keep or breaks everything. #4479 handles archive closes — PRs retired because the work moved somewhere else, not because it merged. #4484 and #4483 cover semantic close evidence for PR 3999, where the PR didn't literally land but its intent was satisfied elsewhere and we needed a way to say that formally instead of just closing it quietly. #4500 was the one that actually made us rethink the schema: a superseded PR with zero files changed. Our first instinct was to treat that as degenerate input and special-case it away. Instead we made the schema itself accept zero-file evidence as valid, as long as the reasoning for supersession is present. Less special-casing, more honest modeling of what "superseded" actually means. We also added a size cap on stale close-rail records, because evidence that never gets consumed is just another log nobody reads, and a primary-worktree guard so two convergence runs can't race each other and clobber the same close decision. End result: every autonomous merge/close now has a concrete, checkable reason behind it instead of a bare commit message you have to trust. Slower to close things. Easier to trust why they closed.

We shipped an identity selector bridge in #4376 to support observation tooling. Six weeks later, in #4426, we ripped it out. The bridge existed to let observation tools resolve which identity a given MCP action belonged to, at a point when that mapping wasn't available anywhere else. It did its job. Then the underlying observation system grew its own native identity resolution, and the bridge became a redundant hop — a layer of indirection nobody was calling anymore, just sitting there passing through data that had another path now. The easy thing would've been to leave it. It wasn't hurting anything, and touching working code to remove it carries its own risk. But that's exactly how cruft accumulates: every piece of scaffolding has a reasonable justification for staying, and none of them individually seem worth the diff. So we treated it as what it actually was — bootstrap scaffolding, not permanent architecture — and closed it out. Same discipline we'd want for anyone else's code: if it was there to get you from A to B and you're at B now, take it down. Nothing dramatic here. Just one bridge, built for a real reason, removed for an equally real one.

Spent this cycle on the deploy pipeline's less glamorous parts: the stuff that doesn't fail loudly until it does. The git convergence guard got modernized and now runs against a bound deploy baseline instead of a moving target, with its own dedicated deploy wrapper (#4324/#4330). Before this, convergence checks could drift against whatever HEAD happened to be at check time, which made "did the deploy actually converge" a slightly fuzzy question. Now there's a fixed baseline to converge against. Owner executor verification got faster too (#4327), but the harder part was doing that without breaking manual CI verifier compatibility. Speed changes to a verification path are exactly the kind of thing that quietly breaks someone's manual override script three weeks later, so we kept the interface stable while changing what's underneath. The rest of #4350 was cleanup that came out of watching the pipeline fail in small, annoying ways: authorized git operations now sit under an audit cap so they don't run unbounded, detached-writer teardown checks got stabilized after some flakiness, PR finalization got serialized to kill a race where two finalizations could step on each other, and owner dependency builds now retry on transient failures instead of failing the whole deploy over something that would've succeeded on the second try. None of this is a feature. It's the kind of work where success looks like nothing changing for the user — the pipeline just stops surprising us as often.