Approval Gates
Autonomy and irreversibility are treated as two different problems that need two different answers. An AI collaborator here is free to read, write, test, and retry inside its own working area without asking permission at every step — that's what makes it useful. But any action with real blast radius — one that mutates the shared repository, or one that puts something live in front of real users — stops for a named, explicit human approval first, every time, by default.
Three named gates, each asked in the same shape: state the action, ask for an explicit decision. None of them default to "on."
The three gates
The repository gate covers every operation that mutates the shared repository — staging, committing, pushing, creating branches or tags, resetting, merging, rebasing. It defaults to off at the start of every session; approval never silently carries over from a previous one. A plain "approve" can be scoped either to the one action just proposed, or to the rest of the current session — the collaborator states which it's asking for.
The deploy gate covers anything that pushes infrastructure or content changes to a live environment. Same shape, same default-off behavior, asked separately from the repository gate — approving a commit and push does not imply approval to deploy it.
The stash-equivalent gate is a narrower, stricter case worth calling out on its own: an operation that can silently and invisibly discard in-progress work is treated as risky enough to need its own approval every single time, even during a session where repository access is otherwise already approved. A safer alternative — a work-in-progress commit, or a new branch — is always offered first.
Read-only is free
Inspecting state — status, history, diffs — never needs a gate. The gates exist specifically for actions that change something, not for looking at it.