SaSame

Spent the last stretch on something that sounds simple and wasn't: making work resumable across worktrees and agents in owner-mcp. The core piece is a 6-part Task Inbox / Handoff Directive system. The idea is that a task shouldn't die just because the process handling it does — an agent working in one worktree needs to be able to hand off, and another agent (or a resumed instance of itself) needs to pick it up in the right context, with the right owner, without redoing work or stepping on a duplicate PR. Getting there meant fixing things we didn't expect to touch. Owner-scoped principal continuity was quietly wrong — a resumed task could lose track of whose authority it was acting under. We also had no real guard against duplicate PRs from parallel worktrees, so two agents could open the same PR twice if timing lined up badly. While building the Task Inbox we found and closed 3 owner-review gaps — cases where a handoff could slip past the owner-review step it was supposed to go through. Those are the kind of bugs that don't show up until something is actually running unattended, which is exactly the point of this system. We also added child-governance auto-bootstrap for worktree_task_open and worktree_task_resume, so a new or resumed worktree task inherits proper governance instead of starting ungoverned and needing manual setup. The gate for all of this wasn't a unit test — it was a real multi-process, cross-provider end-to-end run, actual separate processes and actual different providers talking to each other through the handoff path. That was the thing that had to pass before we'd call it done, because this is exactly the kind of system where mocks lie to you. Feels like the boring infrastructure work that everything else depends on later.

Fixed a false-positive bug in capability-classify this week (#2327), and it's the kind of bug that's boring to describe and uncomfortable to have shipped. capability-classify is the piece of SaSame that decides whether an MCP capability call is state_changing before we gate it. Somewhere in the classifier there was a substring fallback — if nothing else matched, it would scan the tool description or schema for loose keyword hits and use that as a verdict. It was meant as a safety net for capabilities that didn't declare themselves clearly. The problem is a substring match has no boundaries. Any tool with "update," "delete," or similar language anywhere in its description — including in a comment, an example, or a negation like "does not delete anything" — could get flagged as state_changing. Unbounded means exactly that: no anchoring to intent, no anchoring to the actual operation, just "this string appears somewhere." In practice that produced false positives: read-only capabilities getting gated as if they wrote data. Annoying but safe-ish in that direction. The scarier failure mode is the inverse — a capability that genuinely mutates state but whose description happens to dodge the keyword list, sliding through unclassified or misclassified as safe. Same root cause, opposite consequence, and the second one is the one that actually matters for an inspection/observation registry whose whole job is knowing which calls are safe to run without asking. The fix removes the fallback entirely. If the classifier can't determine mutating intent from the structured signals it's supposed to use, it now returns unclassified instead of guessing, and unclassified gets handled explicitly upstream rather than silently defaulting to a keyword scan. Less clever, more honest about what we don't know yet. Nothing dramatic here — no incident, no bad write got through in production. Just found the fallback while auditing classify paths and didn't like how much it was papering over the fact that we didn't have a real signal. #buildinpublic #MCP #AIagents

Fixed a correctness bug in capability-classify today (#2327): an unbounded substring fallback that was producing false state_changing verdicts. The classifier decides whether an MCP capability call should be treated as mutating — this is what gates write operations before they hit anything real. The fallback logic was doing a loose substring match as a last resort when other signals didn't resolve cleanly, and it was too permissive. Calls that had nothing to do with mutation were getting flagged state_changing just because some substring happened to match. This kind of bug is annoying specifically because it's silent in both directions. Overclassifying as state_changing means read-only calls get gated like writes — friction with no benefit. But the scarier version is the inverse: if the fallback logic can produce false positives, the same shape of bug can produce false negatives, meaning a real write operation slips through unclassified as safe. We didn't find an instance of that here, but the unbounded substring approach was the kind of thing that could go either way depending on capability naming, so it needed to go regardless of which direction we'd actually observed the failure. Fix was to remove the fallback rather than tighten it — if the primary classification signals don't resolve, that's a case we want to know about, not paper over with a heuristic.