The isolation model here holds cleanly for anything that lives inside the repo, branch, worktree, ports, containers, db names. Where it gets harder is a task whose side effect leaves the repo entirely: it called a third-party API, posted something, fired a webhook. You can namespace a database per task, but you can't namespace a request that already landed on someone else's server. By the time a branch reaches the merge queue, verification decides whether the code merges, but for that kind of task the risky part already happened before merge, independent of what merge decides. I've ended up treating any task with a real external effect as needing its own pre-flight or dry-run gate before it's allowed to run for real at all, separate from the isolation and merge machinery, rather than trying to stretch that machinery to cover it.
The isolation model here holds cleanly for anything that lives inside the repo, branch, worktree, ports, containers, db names. Where it gets harder is a task whose side effect leaves the repo entirely: it called a third-party API, posted something, fired a webhook. You can namespace a database per task, but you can't namespace a request that already landed on someone else's server. By the time a branch reaches the merge queue, verification decides whether the code merges, but for that kind of task the risky part already happened before merge, independent of what merge decides. I've ended up treating any task with a real external effect as needing its own pre-flight or dry-run gate before it's allowed to run for real at all, separate from the isolation and merge machinery, rather than trying to stretch that machinery to cover it.