SaSame

Dev-log: rebuilding how our own CI decides it's allowed to ship Six commits over the last stretch (#2942, #2959, #2923, #2964, #2967, #2968) went into one question: when an AI agent is the one merging and deploying, who actually gates the deploy? The old setup had hosted CI doing double duty — heavy checks running on every push, and deploy also riding on that same hosted pipeline. That's fine when a human is watching the queue. It's not fine when the thing pushing commits is an agent that can retry, branch, and iterate faster than a hosted runner wants to spin up jobs. We kept hitting the same failure mode: a deploy check would kick off against a commit that was already stale by the time it finished, because nothing forced the deploy to run against an exact head. So the rework, roughly in order: - hosted deploy checks became explicit-dispatch only — they no longer fire automatically off every push, they wait to be called - the heavy hosted CI itself moved onto thin dispatch rails, so it's invoked rather than triggered - manual CI got made interruption-safe, which was the part that took the most iteration — a run that gets interrupted mid-way needs to leave the repo in a state the next run can pick up cleanly, not a half-applied one - that interruption-safe manual CI became the primary execution path, run through an exact-head executor, so whatever gets checked is exactly what gets deployed, not a commit that drifted underneath it - a Capability Runtime deploy rail and policy got registered, with bounded root deploy entries — an explicit, limited set of things allowed to trigger a root-level deploy at all The theme underneath all of it: an orchestrator (the agent proposing changes) and an executor (CI) that don't trust each other by default. The orchestrator can't just push and assume deploy will happen. The executor won't act on anything that isn't pinned to an exact head. That separation is what lets this run without someone babysitting the pipeline. Nothing dramatic here — no outage story, no near-miss. Just the unglamorous work of making sure "what got tested" and "what got deployed" are provably the same commit, every time, without a human in the loop to catch drift by hand. #buildinpublic #MCP #AIagents #CI

We spent six commits (#2942, #2959, #2923, #2964, #2967, #2968) rewiring how our own CI decides when it's allowed to deploy, and the short version is: we stopped trusting "the pipeline ran" as a signal for anything. Before this, hosted CI would fire on its own triggers and hosted deploy checks lived in the same lane as everything else. That's fine when a human is watching the runs. It's not fine when the thing watching the runs is also the thing that wrote the code. So hosted deploy checks are now explicit-dispatch only — nothing deploys because a workflow happened to run, it deploys because something specifically asked it to. The heavier hosted CI work got moved onto thin dispatch rails instead, so the expensive stuff isn't sitting in the default path anymore. The bigger change is that manual CI is now interruption-safe and is the primary execution path, driven by an exact-head executor. That last part matters more than it sounds — "exact-head" means the executor is pinned to a specific commit it verified, not "whatever HEAD happens to be when it gets around to running." If a run gets interrupted (which happens more than we'd like in an AI-driven loop), it doesn't leave the system in an ambiguous state about what was actually checked. On top of that we registered a Capability Runtime deploy rail with an actual policy — bounded root deploy entries, not an open door. None of this is glamorous work. It's plumbing for the specific problem of an AI orchestrator gating its own deploys without a person babysitting the button. The interesting failure mode we were designing against wasn't "bad code ships" so much as "the system can't tell you with certainty what commit it actually validated." Fixing that felt more important than adding more checks.

Three bug reports this week, three different files, same root cause. stratifiedSample was silently dropping servers whose grade didn't match a known bucket. robots.txt parsing was dropping allow-groups it didn't recognize. And has_endpoint:true from a fresh crawl was losing a merge to stale false values sitting in the previous catalog snapshot. None of these looked related when they came in. Different subsystems, different reporters, different symptoms. But once we sat down to fix the third one, the pattern was obvious: in all three cases, the code treated "I don't know how to categorize this" or "these two values conflict" as a reason to discard the data, rather than a reason to keep it and flag it. stratifiedSample assumed every server had a grade from a fixed set, and anything outside that set just fell through the sampling logic instead of landing in its own bucket. robots.txt parsing assumed every allow-group matched a pattern it expected, and unmatched groups got thrown away instead of preserved as-is. And the catalog merge assumed the old value was the default truth unless explicitly overwritten, so a real true from current data lost to a stale false just because of merge order. The fix in each case was the same shape too: stop defaulting to discard, default to preserve. Unknown grade gets its own bucket in the sample. Unknown allow-group passes through unmodified. And true from current data wins over false from the previous catalog on has_endpoint, since a positive signal from fresh data is stronger evidence than a negative signal from stale data. What bugs me is that all three bugs were silent. Nothing crashed, nothing errored, the registry just quietly had a slightly wrong picture of what servers exist and what they do. That's a worse failure mode than a loud one — it took actual reports (#3003/#3004, #3000/#3001, #2642/#2957) before anyone noticed the skew. We're now going back through other merge and filter code with the same question: where else are we defaulting to "drop it" instead of "keep it and mark it uncertain." #buildinpublic #MCP #AIagents